Окно мониторинга: 2026-09-07 10:18 ~ 2026-09-08 10:18 пекинское время Источники: GitHub (org: flagos-ai 52 репозитория pushed_at + commit search 91 запись с полной проверкой по committer-date + проверка per-repo по ветке по умолчанию + подробности tags/releases/PR), Google News RSS (14 групп запросов на китайском и английском, через прокси), HN Algolia, поиск Tavily/web, официальный аккаунт FlagOS в CSDN (подробности в приложении)

Индекс

    1. Завершение открытых проектов (динамика GitHub)
      • 1.1 Закрытие FlagOS 2.2 RC1: сообщество публикует манифест RC1, 25 пунктов списка одновременно отмечены тегами первой волны проверки rc1.post1 (09-07)
      • 1.2 FlagScale, три события: интеграция обучения/инференса спекулятивного декодирования KERV для встроенных систем, обновление Megatron-LM v0.18.2, фокус CICD на обучении (09-07)
      • 1.3 FlagGems-Experimental: пакетная синхронизация кросс-бэкендных операторов KernelGen в репозиторий + внедрение sync-to-kernelgen CI (09-07)
      • 1.4 Основной репозиторий FlagGems: исправления Hygon/Tianshu, QC fp8, внешние контрибьюторы и откаты (09-07)
      • 1.5 FlagGems-vllm: специализированный бэкенд fused-MoE для XuanTie PPU от DAMO Academy и Hygon (09-08)
      • 1.6 FlagBLAS: последовательное слияние процедур Ascend L2 (CHER/CHER2/SSYR/CSYR) (09-07/09-08)
      • 1.7 FlagTree/FlagPrism: многострочный pipe TLE, исправления CI/CD и слияние компонентов отладки/профилирования (09-07)
      • 1.8 vllm-plugin-FL и FlagScale-Agent: коннектор метрик FlagCX, рефакторинг надёжности Agent (09-07/09-08)
    1. Новости и экосистема
      • 2.1 Форум сообщества FlagOS «Открытые вычисления для AI» проходит в Шанхае параллельно с KubeCon + PyTorch Conference China (09-07)
      • 2.2 Шестое подряд спокойное окно на уровне компонентов (09-07~09-08)
    1. Углублённый анализ участников
      • 3.1 Tsingmicro: в vllm-plugin-FL добавлена линия бэкенда txda, слитая с основной веткой vLLM 0.24.0 (09-07)
      • 3.2 Iluvatar: окончательно определён курс на детерминизм 0.20.2 — целое семейство GEMM flag_gems внесено в чёрный список (09-07)
      • 3.3 Metax и Cambricon: расширение линейки поставки sglang 0.5.18 (09-07/09-08)
      • 3.4 Внешняя экосистема: записи валидации Ascend и исправления from-scratch, операторы KernelGen Kunlunxin, подключение нового бэкенда sunrise (09-07/09-08)
    1. Итоги
  • Приложение: полный список источников

1. Завершение открытых проектов (динамика GitHub)

Обзор окна: из 52 репозиториев организации 30 имели пуш в окне, commit search выявил 91 коммит в окне, фактические слияния в ветку по умолчанию сосредоточены в 14 репозиториях — community, FlagScale, FlagGems, FlagGems-vllm, FlagGems-Experimental, FlagBLAS, FlagTree, FlagPrism, FlagCX, Megatron-LM-FL, TransformerEngine-FL, vllm-plugin-FL, build-infra, FlagScale-Agent — что делает это окно одним из самых активных за последнее время. Главное событие этого окна — официальное отделение ветки FlagOS 2.2 RC1: 09-07 в 11:11 community сливает release/2.2/release-2.2-rc1.yaml (+252 строки, 25 пунктов списка), после чего с 11:22 по 11:33 как минимум 12 репозиториев одновременно отправляют теги первой волны проверки rc1.post1 — прогноз вчерашнего отчёта «следующий сигнал о релизе по-прежнему следует искать в действиях репозитория списка community» подтвердился в этом окне, причём действия оказались масштабнее ожидаемых: это не version bump, а переключение конвейера релиза с RC0 на RC1. На стороне кода компонентов сохраняются признаки периода стабилизации тестирования 2.2: матрица операторов семейства FlagGems (новый бэкенд fused-MoE, Ascend L2, пакетная синхронизация KernelGen), стек обучения FlagScale (Megatron v0.18.2, KERV), проверочные исправления уровня компилятора и плагинов.

1.1 Закрытие FlagOS 2.2 RC1: сообщество публикует манифест RC1, 25 пунктов списка одновременно отмечены тегами первой волны проверки rc1.post1 (09-07)

Источники: community PR #107 (703ea2184c, wbavon, влит 09-07 11:11), release-2.2-rc1.yaml, Релиз FlagSparse v0.3.0-rc1.post1 (опубликован 09-07 11:27), график 2.2 schedule_CN.md

  • Вливание manifest: 09-07 11:11, в репозиторий community влит PR #107, добавлен release/2.2/release-2.2-rc1.yaml (252 строки) и переключён манифест по умолчанию в .github/workflows/release-branch-tag.yml с 2.2/release-2.2-rc0.yaml на release-2.2-rc1.yaml. Manifest в формате vcstool охватывает L0 инфраструктура (flagtree × 3 линии Triton, flagcx) → L1 вычислительные библиотеки (flaggems/flagfft/flagsparse/flagdnn/flagblas/flagtensor/flagaudio/flagattention/flaggems-vllm/flaggems-sglang) → L2 адаптация фреймворков (torch-fl, vllm-plugin-fl × 2, sglang-plugin-fl, transformerengine-fl, megatron-lm-fl, flagos-compressor) → L3 прикладные инструменты (flagscale, kernelgen, kernelgenbench, flagrelease), всего 25 записей, 22 репозитория.
  • Ключевые якоря версий: flagcx v0.14.0-rc1.post1, flaggems v5.4.0-rc1.post1, flagscale v2.1.0-rc1.post1, kernelgen v2.2.0-rc1.post1, три линии flagtree унифицированы — 0.7.0rc1.post1+triton{3.6|3.5|3.3}, vllm-plugin-fl разделён на две линии (main следует за vLLM 0.24.0 → v0.3.0-rc1.post1; release/0.2 следует за vLLM 0.20.2 → v0.2.2-rc1.post1). В комментариях синхронно зафиксирована инженерная эволюция rc0→rc1: в FlagGems master влит setuptools_scm only-version (upstream #5885), post-тег на master больше не вызывает сбой сборки, для rc1 не требуется повторять cherry-pick/перенос тега, как это делалось для rc0.
  • Волна тегов rc1.post1: после вливания manifest в 11:11, в течение 11 минут сконцентрированно запушены теги как минимум в 12 репозиториях (FlagCX 11:22, FlagFFT 11:23, FlagSparse 11:27 с публикацией релиза, FlagTensor/FlagAttention/FlagGems-sglang/FlagAudio 11:28, Torch-FL 11:29, FlagOS-Compressor 11:31, KernelGen 11:32, KernelGenBench/FlagRelease 11:33), что соответствует записям manifest один к одному; ветки по умолчанию этих репозиториев в окне мониторинга не содержали существенных вливаний кода (проверка через tags API подтверждает наличие rc1.post1 во всех случаях), то есть это чистая волна тегов. В головном комментарии manifest прописано правило эволюции версий: каждый пройденный раунд верификации — инкрементный тег (rc1.post1 → rc1.post2 → …) с обратной записью в поле version, .post1 — это маркер «первый раунд верификации пройден».

Интерпретация: это третий сигнальный этап цикла релиза FlagOS 2.2 — 31.08 заморозка функций (закрытие ворот FEP), 01.09 переход в фазу стабилизации тестирования (принимаются только исправления ошибок), 07.09 через RC1 manifest + первая волна тегов верификации объявлено, что результаты верификации фазы интеграции rc0 зафиксированы как базовая линия rc1. График показывает, что 01.09–24.09 — окно мониторинга мультичиповой матрицы тестирования, 28.09 GA; момент ответвления RC1 на 7 дней позже rc0, что соответствует ритму «заморозка функций → примерно неделя интеграционной верификации → фиксация rc1». Заслуживают внимания два момента: во-первых, гранулярность записей manifest стала тоньше по сравнению с rc0 (три линейки Triton в FlagTree, две линейки vLLM в vllm-plugin выделены отдельно), что говорит о том, что матрица поставки 2.2 действительно охватывает комбинации версий множества компиляторов и фреймворков; во-вторых, радикальное решение проблемы сборки post-tag в upstream FlagGems (only-version) устранило шум сборки цикла rc из процесса — итерации post2/post3 после RC1 пойдут быстрее. Значение для последующего наблюдения: следующий сигнал — нарастание rc1.postN по компонентам (соответствующее прохождению раундов верификации мультичиповой матрицы) и момент ответвления RC-final/GA около 24.09; в период RC1 ветки компонентов по умолчанию всё ещё могут принимать исправления ошибок, на внешние потоки вклада, такие как челлендж сообщества, это не влияет.

1.2 Три события FlagScale: интеграция обучения/инференса KERV для embodied speculative decoding, обновление Megatron-LM v0.18.2, фокус CICD на обучении (07.09)

Источники: FlagScale PR #1278 (zhengzihaoPKU, 07.09 14:24, влит), #1284 (b5741d04, 22:00), #1283 (b3708f0f, 10:34), Megatron-LM-FL #109 (e15cb692, 21:57)

  • Интеграция KERV (#1278, 07.09 14:24): FlagScale влил интеграцию обучения и инференса KERV для embodied speculative decoding — добавлены конфигурации LoRA/полнопараметрического обучения верификатора OpenVLA, генерация draft-данных KERV и обучение drafter, конфигурации инференса LIBERO; внутрипроцессная адаптация к публичным точкам входа Python KERV/OpenVLA (единая оркестрация FlagScale, без вложенных launcher); собственный управляющий runtime KERV (пакетная генерация кандидатов, построение дерева верификации, мягкое принятие, динамическая настройка порогов, дополнение Kalman); профиль инференса BF16 напрямую использует 14 операторов KERV из публичного пакета runtime_opt; прилагаются 33 модульных теста, не зависящих от модели (CI не скачивает checkpoint, не запускает MuJoCo/LIBERO).
  • Обновление Megatron v0.18.2 (#1284 + Megatron-LM-FL #109, вечер 07.09): FlagScale в 22:00 обновил upstream-зависимость до Megatron-LM v0.18.2; сопутствующий репозиторий плагина Megatron-LM-FL в 21:57 синхронно поднялся до той же базовой линии (#109). Оба репозитория стека обучения выровняли версии в один вечер — это скоординированное обновление. В Megatron-LM-FL ещё два коммита CICD: #140 (18:29) добавляет повторные попытки для TE-FL prepare checkout, #128 (15:01) — инкрементальную сборку TE-FL и интеграцию во время выполнения.
  • Фокус CICD на обучении (#1283, 10:34): FlagScale удалил две линии CI — inference и serve, «focus on training» — границы поставки фреймворка обучения сузились, а разделение труда, при котором сторона инференса обеспечивается vllm-plugin-FL/sglang-plugin-FL, стало ещё более явным.

Разбор: три коммита соответствуют трём направлениям-сигналам FlagScale. KERV — наиболее заметный из них: стек обучения FlagOS начинает охватывать спекулятивное декодирование для стратегий embodied/робототехники — KERV представляет собой фреймворк спекулятивного декодирования для развёртывания роботизированных VLA (OpenVLA в роли verifier, draft-модель идёт первой, дерево верификации + Kalman для восполнения коэффициента принятия управления), а FlagScale делает его полноценным гражданином «обучаемый (verifier/drafter) + инференс (LIBERO) + оценка». Это перекликается с позиционированием инструментальной цепочки embodied-интеллекта FlagOS-Robo, а также образует контраст с правилом заморозки в течение тестового периода 2.2 — «принимаются только исправления багов, новые фичи не входят»: PR KERV был создан 30-08 и влит 09-07, точно на грани заморозки фич (31-08), причём реализован заранее, — это завершение унаследованных фич, вошедших до заморозки, а не открытие новых после неё. Выравнивание Megatron v0.18.2 в двух репозиториях в один и тот же вечер говорит о том, что версии зависимостей стека обучения в базовой линии 2.2 RC1 уже жёстко зафиксированы; CICD с фокусом на обучение вписывает разделение «FlagScale = обучение, плагины vllm/sglang = инференс» в инженерный конвейер.

1.3 FlagGems-Experimental: пакетная синхронизация кросс-бэкендовых операторов KernelGen в репозиторий + внедрение CI sync-to-kernelgen (09-07)

Источники: FlagGems-Experimental commits (14:31 три коммита CICD + 16:27~16:58 пакет 60+ коммитов), CICD sync-to-kernelgen (4973e875)

  • CI первым (14:31): 103yiran влил CICD(.github): add sync to kernelgen, docs: add ci doc и корректировки .github — между репозиториями FlagGems-Experimental и KernelGen установлен автоматизированный рабочий процесс синхронизации.
  • Пакетное поступление в 16:58: в одну и ту же секундную метку (16:58:04~05) в репозиторий легли 60+ коммитов, все — коммиты операторов с префиксом [KernelGen][вендор], с кросс-бэкендовым охватом: Kunlunxin (digamma, оптимизация arctan minimax, bernoulli), Metax (специализированные математические операторы linalg_cholesky/log_normal_/erfinv/gcd_/lgamma и др. + adaptive_max_pool3d_backward + special_shifted_chebyshev_polynomial_w + исправление регистрационных имён), Iluvatar (addmm_, оптимизация гибридного двухпроходного kernel nonzero_numpy), Hygon (amp_foreach_non_finite_check_and_unscale), thead (вендор-специфичные lcm/lcm_), MThreads (linalg_cholesky), Nvidia (новые операторы special_i0/softmax/xlog1py/shifted_chebyshev_t/spherical_bessel_j0/split_with_sizes/grid_sampler_3d и др.), а также исторические коммиты, синхронизированные из вышестоящего FlagGems (дополнение заголовков Apache 2.0, исправления CI, конфигурация FlagTune topk, обновления ENFLAME и др., номера PR #3540/#4646/#4829/#4873 и др. указывают на вышестоящий FlagGems). Среди контрибьюторов — yzw1128 (тот же аккаунт, что и у соревновательной команды FlagGems-sglang), chx7514, ZhiwenDeng, KK, Dingxingdi, bwbwzzz и др.

Толкование: FlagGems-Experimental — это промежуточный/экспериментальный репозиторий для потока операторов KernelGen; сочетание «workflow синхронизации CI + разовое крупномасштабное слияние» в этом окне указывает на то, что кроссвендорные операторные результаты KernelGen всё активнее перетекают из экспериментального репозитория в основной репозиторий KernelGen способом «пакетной синхронизации» (sync-to-kernelgen — это и есть сам конвейер). Семантическое распределение этой партии операторов хорошо показывает текущее основное направление KernelGen — семейство special-функций (i0/softmax/xlog1py/функции Бесселя/полиномы Чебышёва и т. д.) массово появляется на бэкендах Nvidia/Metax, что говорит о расширении охвата автоматической генерации операторов математических функций; а записи Kunlunxin/Iluvatar/Hygon/thead/MThreads по большей части представляют собой «вендорную специализацию» (переписывание универсального kernel под конкретный инструментарий/набор инструкций), что соответствует последней миле адаптации под многочиповые платформы. Стоит обратить внимание на записи thead (XuanTie от DAMO Academy) и целочисленные операторы вроде lcm — поддержка KernelGen на стороне XuanTie продолжает усиливаться. yzw1128 одновременно активен и в PR соревнований, и в операторах KernelGen, что говорит о том, что внешние контрибьюторы уже производят результаты параллельно как по каналу соревнований, так и по каналу KernelGen.

1.4 Основной репозиторий FlagGems: исправления Hygon/Tianshu, QC fp8, внешние контрибьюторы и откат (09-07)

Источники: FlagGems commits 11:34~20:39, #6040 hygon BLOCK_M fix, #6043 revert FlagTune, #5341 SiliconFlow cauchy

  • Исправление Hygon (15:23 #6040): исправлена ошибка KeyError: 'BLOCK_M' на бэкенде Hygon при выполнении flash attention в ходе инференса ViT encoder — путь получения размера блока в конфигурации квантизации при определённых формах возвращал пустое значение.
  • Оптимизация Tianshu (17:27 #5341): [SiliconFlow] Optimize cauchy on Iluvatar — под подписью SiliconFlow, оптимизирован оператор cauchy (свёртка семейства SSM) на Iluvatar, попутно исправлены кроссбэкендные тесты.
  • QC fp8 (14:04, тот же коммит c9bd738d, что и в Experimental): [QC] Optimize GEMM(fp8) — оптимизация fp8 GEMM одновременно внесена и в основной репозиторий, и в экспериментальный.
  • Инженерная часть: 18:07~18:09 три коммита по CI/тестам (алиасы approved operator tests, маркеры and_scalar pytest); 17:37 тесты публичного API AddMM (после исправления beta-zero в upstream); 18:09 исправлено чтение за границей хвоста input в kernel bucketize (#5231, Truong Vu); 20:39 обновлён Hygon linalg_solve_triangular (#5943).
  • Откат (15:54 #6043): откат внесённого накануне [FlagTune] Add multi-platform Mul cost model support (#5762) — поддержка многоплатформенной модели стоимости умножения FlagTune откачена целиком.

Толкование: 11 коммитов в основном репозитории за окно демонстрируют типичную форму «периода стабилизации тестов»: нет новых архитектурных функций, всё — исправления корректности бэкендов (BLOCK_M в сценарии Hygon ViT, выход за границы bucketize), оптимизация производительности отдельных операторов (QC fp8, Iluvatar cauchy, Hygon linalg) и инфраструктура CI/тестов. Оптимизация Iluvatar cauchy под подписью SiliconFlow заслуживает отметки — это после команды AlphaSparse (FlagSparse) из CAS ещё одна внешняя компания, напрямую вносящая вендорные операторы в FlagGems; список «внешних контрибьюторов» в совместном построении экосистемы удлиняется. Откат модели стоимости FlagTune говорит о том, что изменения на стороне тюнера в период RC будут строго контролироваться: если они не соответствуют критериям приёмки, их лучше откатить — это согласуется с замороженной дисциплиной из раздела 2.2 «принимаем только исправления багов».

1.5 FlagGems-vllm: PPU XuanTie от DAMO Academy и специализированный бэкенд fused-MoE для Hygon (09-08)

Источники: FlagGems-vllm PR #696 (09-08 09:54, влито), #746 (09:56), #747 (10:05)

  • #696 Бэкенд Damo Academy XuanTie PPU: добавлен бэкенд _thead, реализующий чистый Triton fused-MoE (fused_experts_impl) для T-Head PPU (ZW810E, compute_89 / инструкции AIU MMA), смоделированный по существующим вендорским бэкендам _metax/_mthreads: thead-версия moe_align_block_size, транспонированные кэшированные веса (переиспользованы из синхронизированного в FlagGems permute_copy), per-tile редукция moe_sum, продакшн-путь не зависит от deep_gemm; kernel в стиле large-M GEMM разбит по числу токенов на диапазоны (MOE_GEMM_TUNING_MIN_TOKENS, сегментация gemm1/gemm2).
  • #746 Специализированный fused-MoE для Hygon: реализован специализированный fused_experts_impl для Hygon DCU (gfx936), оптимизированный на реальных формах Qwen3.6-35B-A3B относительно базовой линии vLLM-HCU Triton: полный конвейер fused_moe (moe_align→GEMM1→SiLU→GEMM2→moe_sum), специализированный для Hygon путь align (3-kernel вариант для малых батчей, обходящий TLE-кооперативные kernel, которые не компилируются бэкендом HCU); разбиение по M на диапазоны (M≤16 неслитный однопроходный, TP4 BK=64, средний M BK128, TP4 большой M num_warps=16, TP1 M≥8192 неслитный и т. д.).
  • #747 KMCompiler: тесты/benchmark persistent_topk переведены в режим, работающий в среде без нативных операторов vLLM (путь генерации KMCompiler тестируется автономно, без зависимости от vLLM).

Толкование: два вендорских бэкенда fused-MoE влиты в один день (с интервалом 2 минуты), оба представляют собой глубокую адаптацию в духе «ручное написание расписания под конкретный набор инструкций чипа»: XuanTie PPU-ZW810E использует AIU MMA (уровня compute_89), Hygon DCU использует специализированное разбиение по диапазонам под gfx936 и намеренно обходит TLE kernel, которые не компилируются на HCU, — последнее согласуется с известной границей семейства KernelGen/FlagGems относительно того, что «TLE-кооперативные kernel не компилируются на части отечественных инструментальных цепочек». Hygon fused-MoE оптимизирован на реальных формах Qwen3.6-35B-A3B и напрямую сопоставляется с базовой линией vLLM-HCU Triton, что говорит о том, что данный бэкенд ориентирован на реальную инференс-нагрузку MoE уровня 35B. fused-MoE — ключевой оператор текущей пропускной способности инференса, и почиповая специализация его в слое плагина vllm является наиболее наглядным образцом «шлифовки производительности на уровне операторов» в период тестирования 2.2.

1.6 FlagBLAS: последовательное вливание L2-процедур Ascend (CHER/CHER2/SSYR/CSYR) (09-07/09-08)

Источники: FlagBLAS PR #96 (16:35), #93 (17:16), #97 (18:05), #98 (19:31), #99 (09-08 10:16)

  • В окне мониторинга 9 коммитов в ветку по умолчанию FlagBLAS, основная линия — расширение L2-процедур бэкенда Ascend: Ybanana252 последовательно отправил CHER (комплексное обновление Эрмитова ранга 1, #97 18:05), CHER2 (ранг 2, #98 19:31), SSYR/CSYR (вещественное/комплексное симметричное обновление ранга 1, #99 влито 09-08 10:16), а также L2 triangular (ветка l2-triangular, влитая #93 17:16), каждый с тестовой документацией по построению входных данных для Ascend (test(her2): document Ascend input construction).
  • Два исправления CI (#96, влито 16:35, bin913): на линии nvidia выравнивание flagtree до 0.6.1 (та же версия, что в FlagGems) и переход на установку через uv pip для гарантии доступности triton.

Толкование: Покрытие Ascend L2 в FlagBLAS быстро закрывается — CHER/CHER2/SSYR/CSYR относятся к классу процедур обновления rank-1/rank-2, что формирует ритм «покрытия процедура за процедурой» вместе с основной линией DCU/L2, зафиксированной в отчёте от 09-05 (ранее треугольное семейство L2 для ascend также было включено). Три вечера подряд плюс утро следующего дня — по одной партии за раз, что говорит о том, что приёмка L2 для Ascend идёт потоковым пакетным способом. Со стороны CI привязка nvidia flagtree к 0.6.1 (в соответствии с FlagGems) — это стандартное действие по выравниванию зависимостей между репозиториями. Согласно manifest, flagblas относится к вычислительным библиотекам L1, после RC1 всё ещё можно включать исправления ошибок и новые процедуры — эта линия усиления процедур Ascend, скорее всего, продолжится до GA.

1.7 FlagTree/FlagPrism: многострочный pipe TLE, исправления CI/CD и включение компонентов отладки/профилирования (09-07)

Источники: FlagTree #1110 (12:29), #1104 (15:31), #1115 (15:41), FlagPrism PR #8 (включён в 10:47), FlagPrism README

  • FlagTree (первое существенное включение в ветку по умолчанию после 09-04): 12:29 #1110 [BUILD][CD] исправление рабочего процесса доставки DEPENDS IncGen и nvidia3.7; 15:31 #1104 [TLE][MTHREADS] поддержка многострочного pipe и многоролевого ws (расширение абстракции коммуникации/конвейера TLE на бэкенде Moore Threads); 15:41 #1115 [CI][Nvidia] оптимизация групп параллелизма рабочего процесса nvidia3.6. Push от 09-08 09:58 является действием в ветке PR.
  • FlagPrism (продвижение нового репозитория): в 10:47 включён #8 “Add profiler and debugger support”. FlagPrism — это репозиторий централизованного сопровождения опциональных компонентов отладки и профилирования FlagTree: flagtree.debugger (цепочка плагинов компилятора отладчика, встраиваемая в libtriton, передача/декодирование во время выполнения в отдельном расширении _native) и flagtree.profiler (пакет Python + нативная среда выполнения + CLI); flagtree-debugger/flagtree-profiler больше не выпускаются отдельными wheel, FlagTree использует их как submodule third_party/FlagPrism, а pip wheel . за одну сборку создаёт единый FlagTree wheel, включающий Debugger/Profiler.

Толкование: FlagTree в период проверки rc0 (после включения бэкенда Qingwei 09-04) молчал в ветке по умолчанию 3 дня; включения в данном окне сосредоточены на исправлении рабочих процессов сборки/доставки и возможностях бэкенда TLE — поток доставки nvidia3.7, зависимость IncGen, многострочный pipe TLE для Moore Threads — всё это инженерия, «позволяющая стабильно работать матрице мультичипового CI/CD». Включение FlagPrism — событие архитектуры компонентов: отладчик/профилировщик FlagTree сходится из «отдельного пакета» в «submodule основного репозитория + единый wheel», в manifest RC1 три линии версии flagtree согласованы (0.7.0rc1.post1+tritonX), и если #8 от Prism войдёт до заморозки, то выйдет вместе с 2.2, а возможности отладки/профилирования будут встроены в единый wheel FlagTree — для разработчиков операторов это реальное улучшение опыта (плагин компиляции debugger внутри libtriton, CLI профилировщика доступен из единой точки).

1.8 vllm-plugin-FL и FlagScale-Agent: коннектор метрик FlagCX, рефакторинг надёжности Agent (09-07/09-08)

Источники: vllm-plugin-FL #418 (489d22d5, 14:28), FlagScale-Agent commit 9e308807 (09-08 09:12)

  • vllm-plugin-FL #418 (09-07 14:28): feat(flagcx connector): Prometheus KV-transfer metrics + port #315 from release/0.2 — в коннектор плагина vLLM и FlagCX добавлены наблюдаемые метрики Prometheus (передача KV), а исправление #315 из ветки release/0.2 перенесено обратно в основную линию.
  • FlagScale-Agent (09-08 09:12, caozhou): feat: agent reliability overhaul — в FlagScale-Agent добавлены верхний предел бюджета размышления во время выполнения (runtime thinking cap), повторы с учётом рассуждения (reasoning-aware retries), осведомлённость о временном бюджете (time-budget awareness) и мониторинг здоровья (health monitoring). FlagScale-Agent — это агентный компонент для оркестрации обучения больших моделей; на этот раз выполнена комплексная переработка надёжности.

Разбор: оба коммита — инженерные работы, направленные на то, чтобы «сделать инструменты верхнего уровня FlagOS более пригодными для длительной работы без присмотра»: метрики Prometheus коннектора FlagCX раскрывают состояние передачи KV между множеством карт для эксплуатации (исправление #315 линии vLLM 0.20.2 синхронизировано обратно в основную линию, что поддерживает согласованность двух линий); «четвёрка» FlagScale-Agent — бюджет размышления/повторы/временной бюджет/мониторинг здоровья — типичное инженерное усиление агента, предотвращающее выход цикла агента из-под контроля или тихое зависание при длительной оркестрации обучения. Учитывая, что в тестовый период 2.2 растёт потребность оркестрирующего слоя в «наблюдаемости + самовосстановлении» при прогонах многокристальной матрицы, такое усиление весьма своевременно.

2. Новости и экосистема

2.1 Форум сообщества FlagOS «Открытые AI-вычисления» прошёл в Шанхае параллельно с KubeCon + PyTorch Conference China (09-07)

Источник: объявление официального аккаунта FlagOS на CSDN (опубликовано 2026-09-07 09:57)

  • Днём 09-07 организованный сообществом Zhongzhi FlagOS форум «Открытые AI-вычисления: создание новой экосистемы открытого ПО для разнородного оборудования» прошёл параллельно с конференцией KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China в Шанхае; среди гостей были представители Пекинского института искусственного интеллекта Zhiyuan, Шанхайской лаборатории искусственного интеллекта, фонда PyTorch, сообщества SGLang и других, а темы вращались вокруг технического пути и моделей сотрудничества для стека системного ПО открытого AI. На странице официального аккаунта CSDN доступны трансляция/запись.
  • Это объявление было опубликовано 09-07 в 09:57 (непосредственно у границы предыдущего окна), сам форум состоялся днём того же дня (в пределах данного окна); вчерашний отчёт отмечал отсутствие обновлений официального аккаунта CSDN, так что эта запись — добавленное экосистемное событие в пределах окна.

Разбор: проведение форума на шанхайской площадке PyTorch Conference China / KubeCon China — это очередное последовательное действие FlagOS в области «горизонтального сотрудничества открытых сообществ»: на одной сцене с фондом PyTorch и сообществом SGLang, а темы напрямую указывают на «единый программный стек для множества чипов» — ядро позиции FlagOS. Подобные мероприятия сами по себе не порождают динамику кода компонентов, но показывают, что на уровне сообщества в период ответвления RC1 с помощью международных конференций усиливается нарратив открытых вычислений; в дальнейшем стоит следить за тем, появятся ли у этого форума публичные результаты вроде дорожной карты или белогой книги.

2.2 Шестое подряд спокойное окно на уровне новостей о компонентах (09-07~09-08)

Источник: Google News RSS (14 групп на китайском и английском, через прокси), HN Algolia, поиск Tavily/web (подробности в приложении)

  • Комбинация запросов gnews на английском и китайском (FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/KernelGen/FlagOS 2.2 when:3d~30d и т. д.) — нулевых попаданий в окне; единственное попадание FlagGems — перепечатка старой статьи Zhiyuan Community от 01.09 в Day0 (уже освещалось). Zhiyuan Research Institute when:7d — 58 попаданий, все — перепечатки блогов Zhiyuan Community (речь Яо Цичжи на церемонии открытия учебного года, заметки о программировании с AI и т. д.) и шаблонный SEO-шум от букмекеров, контента FlagOS нет, вся выборка отброшена. Запросы по Iluvatar CoreX/Moore Threads дали в основном коммерческие новости — промежуточные отчёты, котировки акций, движения на гонконгской бирже (прямой связи с программной экосистемой FlagOS нет, не включаются).
  • HN Algolia (FlagOS/FlagGems/flagos-ai/BAAI) — релевантных попаданий нет; из нового, найденного через Tavily, — только анонс на форуме 2.1.
  • Тренд за последние 3 дня (подтверждено GitHub org pushed, инженерная сторона крайне активна): 07.09 11:11 — переключение ветки manifest FlagOS 2.2 RC1 + первая волна тегов rc1.post1 (1.1 за день); 07.09 — интеграция спекулятивного декодирования KERV для воплощённого интеллекта в FlagScale и выравнивание двух репозиториев Megatron v0.18.2 (1.2); 07.09/08.09 — 13 последовательных записей о поставках build-infra (детерминированное решение по Iluvatar CoreX 0.20.2, линия sglang 0.5.18 для Moore Threads/Cambricon/Ascend, см. раздел 3); вечером 07.09 — массовое слияние примеров FlagBLAS Ascend L2 (1.6); утром 08.09 — слияние бэкендов fused-MoE XuanTie/Hygon в FlagGems-vllm (1.5).

3. Углублённое изучение участников

3.1 Tsingmicro (tsingmicro): в vllm-plugin-FL добавлена линия бэкенда txda, слита вместе с основной линией vLLM 0.24.0 (07.09)

Источник: vllm-plugin-FL PR #447 (tsingmicro-public-e, слит 07.09 16:58, base: main)

  • PR #447 отправлен и слит официальным аккаунтом Tsingmicro tsingmicro-public-e (PR Category: Vendor): в vllm-plugin-FL добавлен вендорный код txda, поддержка vLLM==0.24.0 (линия main), а также исправлены ошибки, связанные с txda. Время слияния — 07.09 16:58, что согласуется с закреплением линии vllm-plugin-fl main за vLLM 0.24.0 в манифесте RC1.
  • На стороне runner build-infra линия Tsingmicro уже присутствует (tsingmicro-tsm260610: [self-hosted, tsingmicro], зарегистрирована до этого окна).

Трактовка: Tsingmicro ранее уже вошла в матрицу бэкендов FlagTree (отчёт от 05.09: подключение масштабом 300 файлов, архитектура потоков данных TLE-DSA), на этот раз это первый фрагмент на стороне плагина инференса — в списке вендорных бэкендов vllm-plugin-FL появился txda (линия vLLM 0.24.0). Tsingmicro как относительно новый производитель чипов среди участников FlagOS демонстрирует чёткую последовательность адаптации: «сначала компилятор (FlagTree), затем фреймворк инференса (плагин vLLM)»; способ слияния бэкенда txda (вендор сам отправляет PR, сам поддерживает) — также положительный пример глубокого участия участников.

3.2 Iluvatar CoreX (iluvatar): окончательное решение по детерминированной технической линии 0.20.2 — чёрный список всего семейства GEMM в flag_gems (07.09)

Источники: build-infra #776/#777 (19:23/19:24, регистрация тега образа), #779 (20:21, окончательное решение в docs), vllm-plugin-FL PR #450 (в процессе, обновлён 07.09 16:59)

  • Регистрация образов (#776/#777, 09-07 19:23/19:24): iluvatar-corex4.4.0 и corex4.5.0 в один день зарегистрировали app-образ vllm 0.20.2 с тегом 2.1.2-0.2.1_g16e8655.d20260907 (отпечаток исходников plugin g16e8655, оба стека с одним тегом) — обновление отпечатка относительно предыдущего дня g71b9482.d20260906, соответствует новой поставке после итерации детерминированного решения.
  • Окончательное решение по техническому маршруту (#779 docs, 20:21): финальный детерминированный маршрут для iluvatar 0.20.2 — полный чёрный список всего семейства GEMM из flag_gems (linear/mm/mm.out/addmm/addmm_/addmm.out/bmm/bmm.out → откат к native corex ixblas). Описание первопричины достаточно полное: flag_gems.enable() в vllm_fl перехватывает aten::linear и др. в flag_gems triton linear_kernel; этот kernel после компиляции flagtree становится недетерминированным от запуска к запуску внутри live-движка (~1-2 bf16 ulp, offline детерминирован, при temp=0 длинное декодирование переключается в зоне почти равновероятной выборки), тогда как тот же самый kernel, скомпилированный вендорским corex triton, bitwise детерминирован (== native). Чёрный список должен исключать всё семейство (native linear деградирует до addmm, исключение только linear всё равно оставляет перехват). После перехода GEMM на native оба пути F/T дают 30/30 детерминированность при temp=0, да ещё и пропускная способность выше (F 14.0 tok/s против flag_gems linear 12.3, native ixblas быстрее скомпилированного flagtree kernel flag_gems); silu_and_mul остаётся на flagos (при native GEMM больше не переключается). Различие компиляторов — это водораздел: один и тот же исходный kernel flag_gems, скомпилированный flagtree, недетерминирован, скомпилированный corex triton — детерминирован — передача в upstream уже открыта: FlagGems #6054-6057 (linear/mm/addmm/bmm). Путь T в 4.4.0 всё ещё требует VLLM_FL_USE_FLAGGEMS_ATTN=1 (corex triton 3.1 не компилирует нативный attention vLLM); путь T в 4.5.0 (corex triton 3.2) не требует env; известное неблокирующее ограничение — переключение при первом запросе на холодном движке T в 4.5.0.
  • PR #450 всё ещё в процессе: патч на стороне плагина для iluvatar 0.20.2 (symm-mem stub guard, откат PyTorch sampler, base release/0.2) после обновления 09-07 16:59 всё ещё не влит.

Толкование: эта линия — третья смена направления и сходимость в нарративе поставки Tianshuzhixin (Iluvatar CoreX) с 09-05: 09-05 схема инъекции env → 09-06 вечером откат, переход на чёрный список silu_and_mul в конфигурации плагина (#450) → 09-07 вечером окончательное решение по результатам измерений 30/30: полный чёрный список всего семейства GEMM, и на этот раз это двойная победа «детерминированность + производительность» (исключение пути компиляции flagtree оказалось даже быстрее). Документ возводит первопричину к водоразделу компиляторов — один и тот же исходный код kernel, скомпилированный flagtree, недетерминирован от запуска к запуску, скомпилированный вендорским triton — bitwise детерминирован; это вывод более глубокий, чем «какой оператор»: пока детерминированность live-компиляции в flagtree не будет устранена в корне (FlagGems #6054-6057 переданы в upstream), детерминированная поставка операторов flag_gems на отечественных чипах будет опираться на чёрные списки/механизмы отката как страховку. Это важная честная сноска к нарративу FlagOS о «полной замене на flag_gems»; для Tianshuzhixin (Iluvatar CoreX) путь детерминированной поставки 0.20.2 на двух стеках corex4.4.0/4.5.0 отныне документирован и проверяем.

3.3 MetaX (metax) и Cambricon (cambricon): расширение линии поставки sglang 0.5.18 (09-07/09-08)

Источники: build-infra #781 (09-07 22:49), #783 (09-08 07:18), #784 (07:27), #773 (09-07 13:10)

  • Открытие линии Metax metax-maca3.7.2.1 sglang 0.5.18: в 22:49 #781 добавлена конфигурация приложения sglang для maca3.7.2.1 (deps_app/app env); 09-08 07:18 #783 зарегистрирован тег образа приложения 2.1.2-0.1.dev1_ga73b27b60; 07:27 #784 в docs зафиксирован успешный E2E-прогон sglang 0.5.18 по обоим путям F/T на maca3.7.2.1, а PR #86 со стороны плагина внесён в матрицу верификации. В конфигурации runner линия maca3.8.1.3 также уже присутствует.
  • Cambricon cambricon-neuware4.4.3: 09-07 13:10 #773 в docs зафиксирована поставка sglang 0.5.18 для neuware4.4.3 (продолжение ритма записей со стороны 0.20.2 предыдущего дня).

Разбор: матрица поставки sglang 0.5.18 после отсечения RC1 продолжает смещаться вправо — Metax maca3.7.2.1 замыкает цикл через «успешный E2E по обоим путям F/T + связь с PR #86 плагина», Cambricon neuware4.4.3 дополняет записи о поставке. В сочетании с записями sglang 0.5.18 для Enflame tops1.9.10 / Moore Threads musa4.3.6 предыдущего дня, матрица поставки «два инференс-фреймворка vLLM 0.20.2 и sglang 0.5.18 × множество линеек SDK вендоров» в основном развёрнута, и каждая регистрация в линейке несёт отпечаток тега образа и связь с коммитом плагина — это и есть инженерный факт, стоящий за двумя записями vllm-plugin/sglang-plugin (каждая rc1.post1) в манифесте RC1.

3.4 Внешняя экосистема: записи верификации Ascend и исправление from-scratch, операторы KernelGen для Kunlunxin, подключение нового бэкенда sunrise (09-07/09-08)

Источники: build-infra #772 (sunrise env), #775/#780/#782 (Ascend), #778 (внешний чёрный список, lead), операторы KernelGen Kunlunxin в FlagGems-Experimental

  • Верификация и исправления sglang 0.5.18 для Ascend (ascend): #780 (22:10) зарегистрирован тег образа приложения sglang для cann8.5.0 2.1.2-0.1.dev1_g0f98ddc20; #782 (09-08 07:16) в docs зафиксирована верификация sglang 0.5.18 для cann8.5.0; #775 (19:46) исправлена инъекция env для sglang serve в сценарии сборки ascend с нуля (ветка USE_FLAGGEMS=0); #778 (20:19) зафиксирована зацепка о необходимости внешнего чёрного списка для index_select на ascend (детерминистское расследование, родственное п. 3.2, перетекает на Ascend).
  • Kunlunxin (kunlunxin): в FlagGems-Experimental KernelGen пакетно влиты три оператора Kunlunxin — digamma/arctan (полиномиальные ядра minimax)/bernoulli (1.3, ZhiwenDeng).
  • Подключение нового бэкенда sunrise (#772, 12:49): build-infra добавил в конфигурацию runner env видимости устройств вендора sunrise (TANG_VISIBLE_DEVICES=all; линейка инструментария sunrise tangrt1.2.0 ранее уже была указана в списке runner). sunrise пока не фигурирует в опубликованном списке организаций-участников; судя по именованию инструментария (TANG RT), предполагается runtime ускорителя с префиксом TANG; действие в этом окне — дополнение параметров запуска его контейнера, что относится к ранней стадии подключения.

Разбор: три линейки внешней экосистемы соответствуют «вендору глубокой адаптации» (Ascend — уже на одном уровне с организациями-участниками, верификация sglang + перетекание детерминистского расследования), «краудсорсингу операторов» (Kunlunxin — математические функциональные операторы KernelGen) и «резерву нового бэкенда» (sunrise — конфигурация runner идёт первой, компоненты пока не влиты). Зацепку о внешнем чёрном списке для index_select на Ascend стоит отслеживать: если вывод п. 3.2 о «водоразделе компилятора» применим и к пути flagtree на Ascend, это означает, что проблема детерминизма — системная задача пути компиляции flagtree, а не отдельный случай iluvatar.

4. Итоги

В данном окне (09-07 10:18 ~ 09-08 10:18) на стороне GitHub — 91 коммит внутри окна, 30 пушей в репозитории, что делает его одним из самых активных окнов за последнее время; на стороне новостей шесть подряд спокойных компонентных поисков, но на стороне экосистемы появилось событие внутри окна (Шанхайский форум). Четыре основные линии:

  1. FlagOS 2.2 RC1 официально отрезан (с 09-07 11:11): в community влит release-2.2-rc1.yaml (25 пунктов манифеста/22 репозитория, +252 строки), workflow release-branch-tag по умолчанию переключён на rc1, затем в течение 11 минут как минимум 12 репозиториев массово проставили первый раунд проверочных tag rc1.post1 (FlagSparse в 11:27 выпустил релиз rc1.post1) — вчерашний прогноз «смотреть на действия в репозитории манифеста community» подтвердился, переключение конвейера релиза RC0→RC1 завершено. Версии-якоря: flaggems v5.4.0, flagscale v2.1.0, kernelgen v2.2.0, flagcx v0.14.0, flagtree 0.7.0 (линии triton 3.6/3.5/3.3); согласно графику 09-01~09-24 — период тестирования многопчиповой матрицы, 09-28 — GA. Дальнейшие сигналы: нарастающий ритм rc1.postN и RC-final около 09-24.
  2. Три события в тренировочном стеке FlagScale: влита интеграция обучения/инференса спекулятивного декодирования KERV для embodied-сценариев (#1278, OpenVLA verifier + инференс LIBERO + 14 операторов + 33 юнит-теста, тренировочный стек впервые покрывает спекулятивное декодирование embodied-политики); Megatron-LM-FL и FlagScale в тот же вечер выровнены по Megatron-LM v0.18.2; CICD удалил конвейеры inference/serve, сосредоточившись на обучении (ответственность за инференс дополнительно передана плагинам vllm/sglang).
  3. В теме детерминизма всплыл «водораздел компиляторов»: окончательное решение Iluvatar CoreX 0.20.2 — весь набор GEMM-семейства flag_gems занесён в чёрный список с откатом на corex ixblas (#779, детерминизм F/T 30/30 при превосходстве по пропускной способности 14.0 vs 12.3 tok/s); первопричина — один и тот же kernel flag_gems компилируется движком flagtree покомпиляционно недетерминированно на каждом launch, тогда как вендорский triton компилирует bitwise детерминированно, передача в upstream — FlagGems #6054-6057; на стороне Ascend появились аналогичные признаки внешнего чёрного списка. В тот же день оба стека corex4.4.0/4.5.0 зарегистрированы с отпечатком g16e8655 как новая поставка 0.20.2.
  4. Матрица многопчиповых поставок и матрица операторов продолжают сдвигаться вправо: по линии sglang 0.5.18 замкнут цикл записей для MetaX (maca3.7.2.1, E2E F/T пройден), Cambricon (neuware4.4.3), Ascend (cann8.5.0); бэкенд Tsingmicro txda влит в основную линию vllm-plugin-FL через собственный PR вендора (vLLM 0.24.0); FlagGems-vllm в тот же день влил два специализированных бэкенда fused-MoE — Damo Academy XuanTie PPU-ZW810E и Hygon DCU; примеры FlagBLAS Ascend L2 (CHER/CHER2/SSYR/CSYR) массово дополнены; в FlagGems-Experimental создан CI sync-to-kernelgen и массово синхронизированы кросс-бэкендные операторы KernelGen.

Прогноз: RC1 уже отрезан, ветки компонентов по умолчанию входят в фазу стабилизации тестирования в режиме «принимаются только исправления багов»; в ближайшие две недели главное на стороне GitHub смещается от «вливания новых функций» к нарастающему ритму проверочных tag rc1.postN и плотности записей о поставках (частота записей build-infra — лучший прокси-индикатор прогресса RC); передача детерминизма компилятора по FlagGems #6054-6057 заслуживает отслеживания (если проблема будет устранена в корне, «полная замена на flag_gems» на отечественных чипах станет по-настоящему безопасной); единый wheel FlagTree (с Prism debugger/profiler) и тренировочный контур embodied KERV — две новые возможности, которые стоит проверить при 2.2 GA; прогресс подключения Tsingmicro (бэкенд FlagTree + линия vLLM txda) и внешних новых бэкендов (sunrise) может служить наблюдаемым пунктом расширения экосистемы организаций-участников.

Приложение: полный список источников

Источники Результаты проверки
GitHub org repos API (flagos-ai, 52 репозитория) 30 репозиториев с push в окне; реальные слияния в ветки по умолчанию в 14 репозиториях, включая community/FlagScale/FlagGems; FlagSparse/FlagDNN/sglang-plugin-FL/release-info/docs/FlagTree (09-08) и др. по коммитам в ветке по умолчанию верифицированы как действия с PR-ветками или тегами
GitHub commit search (org всего 91 запись, sort=committer-date) Построчная верификация времени committer и принадлежности репозиторию; охватывает все реальные слияния в ветки по умолчанию
Детали GitHub PR/commit (community #107, FlagScale #1278, FlagGems-vllm #696/#746, vllm-plugin-FL #447/#450, build-infra #779/#772 и др.) Предоставлены содержимое манифеста, область KERV, детали fused-MoE, принадлежность txda, полный текст плана детерминированности
GitHub tags/releases API + верификация дат FlagSparse v0.3.0-rc1.post1 release опубликован 09-07 11:27; теги FlagCX/FlagGems-sglang/vllm-plugin-FL rc1.post1 существуют; массированный push в 12 репозиториев с 11:22 по 11:33 (волна тегов RC1)
Каталог community release/2.2 (raw) Полный текст release-2.2-rc1.yaml — 25 записей; schedule_CN.md (заморозка 08-31 / GA 09-28); release-branch-tag.yml по умолчанию rc1
Google News RSS (14 наборов на китайском и английском, через прокси) Ноль совпадений по компонентным словам в окне; 58 записей по ключевым словам Zhiyuan Research Institute отбракованы целым пакетом как блоги сообщества и SEO-шум для ставок; совпадения по Tianshu/Moore Threads являются коммерческими новостями и не включаются
HN Algolia (FlagOS/FlagGems/flagos-ai/BAAI) Ноль релевантных совпадений
Поиск Tavily/web В окне найдено только одно экосистемное событие — Шанхайский форум сообщества FlagOS (официальный аккаунт CSDN)
Официальный аккаунт FlagOS в CSDN (flagos.csdn.net) Анонс форума опубликован 09-07 09:57 (6a9e1a10…); последнее содержимое подтверждает отсутствие других обновлений в окне