Окно мониторинга: 2026-09-11 10:18 ~ 2026-09-14 10:18 пекинское время (окно понедельника, прошедшие 3 дня, охватывает выходные) Источники: GitHub (org: flagos-ai, 53 репозитория pushed_at + однократный поиск commit по 150 записям с полной проверкой по committer-date + перекрёстная проверка per-repo commits + детали коммитов и патчи + API дерева репозиториев), список релизов и график community-репозитория 2.2 (прямое получение raw), Google News RSS (18 групп поисковых запросов на китайском и английском, через прокси), HN Algolia, официальный сайт сообщества FlagOS (список версий и трансляций), поиск Tavily/web, отраслевые материалы Cailianshe/Securities Times/IT Home/Sina Finance и др. (подробности в приложении)

Индекс

    1. Открытые проекты (динамика GitHub)
      • 1.1 Список 2.2 RC1 переходит в итерацию rc1.postN: FlagGems обновлён до v5.4.0-rc1.post2 (09-11)
      • 1.2 Доставка FlagCX: libflagcx от «самостоятельной сборки из исходников» к «.deb по бэкендам + apt-репозитории по дистрибутивам» (09-11/09-12)
      • 1.3 Ядро FlagCX: рефакторинг net adaptor на 6601 строку, добавлен бэкенд device API по умолчанию для PAL (09-11/09-13)
      • 1.4 Линия sglang в build-infra: две прикладные линии — Kunlunxin xre5.37.1 и Iluvatar CoreX corex4.4.0 (09-12)
      • 1.5 Линия vllm в build-infra: Tsingmicro открывает 0.20.2, Iluvatar CoreX 0.24.0 сходится к единому plugin wheel (09-13)
      • 1.6 FlagTree: бенчмарки и синхронизация бэкендов после 0.7.0rc1 — кластер Kunlunxin +17604 строк, бенчмарки Iluvatar CoreX в CI (09-11/09-13)
      • 1.7 FlagGems: дополнение алгебры Ascend для KMCompiler, приём KernelGen от нескольких вендоров, миграция семейства copy Kunlunxin на TLE (09-11/09-14)
      • 1.8 Линия плагинов инференса и обучения: запуск workflow vLLM 0.24.0 для Hygon, слияние четырёх конкурсных веток на стороне SGLang (09-11/09-12)
      • 1.9 Научные вычисления и доменные библиотеки операторов: два пакета операторов для Hygon и MetaX сосредоточенно дополнены, L2 для Iluvatar CoreX в FlagBLAS, два бэкенда в FlagSparse (09-11)
      • 1.10 FlagQuantum: слияние архитектуры vNext + верификация артефактов релиза 0.2.0 + цифровой двойник QPU (09-11/09-13)
      • 1.11 Фреймворки обучения и инструменты: Megatron-LM-FL избавляется от жёсткой зависимости от CUDA, продвижение в FlagScale/FlagPrism/TransformerEngine-FL (09-11/09-14)
    1. Новости и экосистема
      • 2.1 Десятое подряд спокойное окно покомпонентного поиска: весь поток технической информации — из репозиториев кода (09-11~09-14)
      • 2.2 Три события в отрасли: релиз системы гетерогенного инференса Mobile Cloud, завершение первого дня торгов после IPO Enflame, приближение окна разблокировки акций MetaX (09-11~09-13)
      • 2.3 Активности сообщества и конкурсы: конкурс оптимизации операторов SGLang для разных чипов и сессия обмена по конкурсу наград за операторы, результаты конкурсов начинают попадать в основной репозиторий (09-11~09-12)
    1. Углублённый анализ организаций-участников
      • 3.1 Enflame: завершение капитализации «четырёх малых драконов отечественных GPU» на STAR Market, параллельное исправление адаптации устройства enflame (09-11)
      • 3.2 Iluvatar CoreX: вход в систему гетерогенного инференса Mobile Cloud, параллельная работа по пяти направлениям в FlagOS (09-11~09-13)
      • 3.3 Tsingmicro: открытие прикладной линии vLLM 0.20.2, сквозная верификация и замыкание цикла по тегам образов (09-13)
      • 3.4 Hygon: пробит deb-бэкенд коммуникационной библиотеки, запущен workflow vLLM, пакетное дополнение операторов — три линии одновременно (09-11/09-12)
      • 3.5 Moore Threads и MetaX: два пакета — генерирующие операторы и бэкенд-операторы, расхождение в капитальном ритме на стороне отрасли (09-11~09-13)
      • 3.6 Kunlunxin (внешний участник экосистемы): значительная синхронизация на стороне компилятора, но коммуникационная библиотека помечена как «непоставляемая» (09-11/09-12)
      • 3.7 Zhiyuan (ведущая сторона): дисциплина тестового периода 2.2 и поддержание списка RC1, GA назначен на 09-28 (09-11)
    1. Итоги
  • Приложение: полный список источников

1. Открытые проекты (динамика GitHub)

Обзор окна: из 53 репозиториев внутри org 21 имеет пуши в окне; commit search дал 150 коммитов в окне (полный объём 5 страниц, сортировка по committer-date по убыванию), после проверки через per-repo commits дополнительно добавлено 23, итого 173, распределённых по 18 репозиториям: FlagGems-Experimental 54, build-infra 33, FlagGems 21, FlagQuantum 15, FlagCX 7, FlagGems-vllm 6, Megatron-LM-FL 5, FlagTree 4, FlagBLAS 4, FlagGems-sglang 4, FlagDNN 4, FlagSparse 10 (из них 8 из per-repo проверки), FlagScale 1, FlagPrism 1, vllm-plugin-FL 1, TransformerEngine-FL 1, FlagOS-Compressor 1, community 1. Кроме того, у трёх репозиториев sglang-plugin-FL, docs, release-info pushed_at попадает в окно, но ни проверка через API ветки по умолчанию, ни проверка через API веток не выявила новых коммитов в окне (относятся к пушам веток или тегов). Новых репозиториев нет, новых записей GitHub Release нет.

Форма данного окна = двусторонняя линия “формирование поверхности поставки + усиление внешних бэкендов” в период тестирования RC: со стороны управления список 2.2 RC1 продвинут ко второму раунду верификации (flagems повышен до rc1.post2); со стороны поставки самая тяжёлая линия — полное прохождение упаковки .deb и публикации apt-репозитория FlagCX (от “пользователь сам компилирует под вендорский SDK” до apt-get install); со стороны компилятора и операторов четыре компании — Kunlunxin, Iluvatar CoreX, Qingwei, Hygon — одновременно продвинули свои прикладные линии, бенчмарк-линии и поверхность операторов. Предсказанный в прошлом окне “ритм возрастания rc1.postN перед 2.2 GA” в этом окне реализовался, при этом появился первый бэкенд, явно зафиксированный как “непоставляемый” (коммуникационная библиотека Kunlunxin), — границы инженерной работы начинают быть прописаны, а не только продвигаться.

1.1 Список 2.2 RC1 входит в итерацию rc1.postN: FlagGems повышен до v5.4.0-rc1.post2 (09-11)

Источник: community #108 (09-11 11:45) (единственное изменение в окне файла списка release/2.2/release-2.2-rc1.yaml)

  • Второй раунд валидации с фиксацией в репозитории: запись flaggems в списке обновлена с v5.4.0-rc1.post1 до v5.4.0-rc1.post2, tag указывает на голову ветки rc1 270bebe1, после post1 накоплено 4 исправления — откат Mul cost model в FlagTune, исправление randperm/sort для Iluvatar CoreX, исправление переполнения при int64-смещении в index, исправление упаковки отсутствующего __init__.py в DSA.
  • Текущее состояние списка RC1 (снимок из 25 компонентов): уровень L0 представлен тремя линейками FlagTree 0.7.0rc1.post1+triton3.3/3.5/3.6, FlagCX v0.14.0-rc1.post1; библиотеки операторов и предметных областей — FlagGems v5.4.0-rc1.post2, FlagGems-vllm v0.2.0-rc1.post1, FlagGems-sglang v0.1.0-rc1.post1, FlagAttention v0.4.0-rc1.post1, FlagFFT v0.2.0-rc1.post1, FlagSparse v0.3.0-rc1.post1, FlagBLAS/FlagDNN/FlagTensor/FlagAudio — все v0.3.0-rc1.post1; интеграция с фреймворками — vLLM-plugin-FL v0.3.0-rc1.post1 (также линейка 0.2 v0.2.2-rc1.post1), SGLang-plugin-FL v0.2.0-rc1.post1, Torch-FL v0.2.0-rc1.post1, TransformerEngine-FL / Megatron-LM-FL v0.3.0-rc1.post1; обучение и инструменты — FlagScale v2.1.0-rc1.post1, KernelGen v2.2.0-rc1.post1, KernelGenBench v0.2.0-rc1.post1, FlagRelease v0.3.0-rc1.post1, FlagOS-Compressor v0.1.0-rc1.post1.
  • Регламент сроков: цикл 2.2 — заморозка функций 08-31 → период тестирования и стабилизации с 09-01 по 09-24 (принимаются только исправления ошибок, новые функции не добавляются) → GA 09-28; критерий выпуска требует, чтобы Test Plan каждого FEP (команда + окружение + ожидаемый результат, покрытие нескольких чипов) был принят в течение периода тестирования, а непройденные части выносятся отдельным issue на приёмку.

Толкование: снимок из 25 записей списка и механизм «инкремента rc1.postN» вместе говорят об одном — облик релиза 2.2 больше не определяется списком функций, а определяется тем, «какой раунд валидации пройден». Единственное изменение списка в окне — продвижение FlagGems до post2, причём все 4 исправления относятся к дефектам численного/упаковочного класса (откат cost model, сортировка randperm, смещение int64, отсутствующий подпакет), и это прямое отражение дисциплины периода тестирования: после заморозки номер версии движется только исправлениями, а не функциями.

1.2 FlagCX как готовый продукт: libflagcx от «сборки из исходников своими силами» к «сборке .deb под каждый бэкенд + публикации apt-репозитория под каждый дистрибутив» (09-11/09-12)

Источники: build-infra #847 (09-11 18:02), #849 (09-11 18:50), #851 (09-11 19:18), #853 (09-11 21:37), #854 (09-11 22:00), #855 (09-11 22:06), #856 (09-12 11:20), #865 (09-12 17:20), #866 (09-12 18:25), #868 (09-12 21:08)

  • Зачем упаковывать (#847, +2449 строк): в описании коммита указано, что FlagCX распространяется в виде исходного кода, и downstream-пользователи должны сначала скомпилировать его под свой вендорский SDK, прежде чем что-либо линковать; сборка .deb внутри собственного base-образа вендора позволяет зафиксировать на этапе сборки soname, -dev-заголовки и минимальную версию glibc, а на стороне пользователя остаётся только «установить пакет». В реализации backends.yaml несёт факты упаковки (make-флаги, apt-зависимости, assert, доказывающий наличие вендорского SDK), deb-config.py и generate_matrix.py --runtime объединены, а --check служит сигналом об их расхождении; сборка внутри base/<backend> клонирует дерево FlagCX по фиксированному ref, канонизирует SONAME и удаляет rpath, разделяя runtime-библиотеки и заголовки на отдельные пакеты; на этапе verify установка проверяется исключительно по файлам — внутри base-образа доказывается разрешимость и загружаемость, а на чистом Ubuntu доказывается, что Depends не затянет вендорский SDK на машину пользователя.
  • Публикация в apt-репозиторий (#851): публикация опциональна по dispatch (publish по умолчанию false), попадает в репозиторий, названный по версии Ubuntu, использованной при сборке (flagos-apt-ubuntu24.04 / flagos-apt-ubuntu22.04), arch не является частью адреса и распределяется самим apt; шаг публикации размещён внутри задания verify, а не в отдельном post-publisher, по той причине, что «файл на пути к пользовательскому apt-get install должен быть именно тем файлом, который только что прошёл верификацию»; publish без verify отклоняется уже на этапе set-matrix, не-tag ref также отклоняется (номер версии берётся из клонированных tags).
  • Одноразовое включение шести бэкендов (#865): iluvatar-corex4.4.0/4.5.0, mthreads-musa4.3.6/5.2.0, sunrise-tangrt1.2.0, tsingmicro-tsm260610 — каждому добавлены assert, определённый зондированием внутри контейнера, и vendor_lib_dirs. Этот же коммит исправляет скрытый дефект: Makefile делал glob только по flagcx/adaptor/*.cc, из-за чего жёсткая ссылка flagcx_device.cc на devApiBackend оставалась неопределённым символом, когда вендорский .mk не предоставлял PLATFORM_EXTRA_SRCS, а -shared терпит неопределённые символы — обнаружить их может только dlopen(RTLD_NOW); для cambricon покрытие уже было, для iluvatar/sunrise/tsm его требовалось добавить.
  • Запущен бэкенд Hygon DTK (#866): результаты зондирования зафиксированы — DTK вообще не экспортирует CUDA_PATH, DEVICE_HOME ?=/CCL_HOME ?= в du.mk захватывают пустые значения, оба пути прибиты к /opt/dtk/cuda/cuda-12; на DTK -lnccl фактически разрешается в RCCL, поэтому NEEDED-запись артефакта — librccl.so.1, а написание nccl не находится в цикле shlibs в debian/rules; библиотеки DTK не зарегистрированы в ldconfig, LD_LIBRARY_PATH приходит из profile-скрипта, действующего только в bash, и dpkg-shlibdeps должен явно перечислять оба каталога. Этот же коммит исправляет проблему, когда гейт ldd в verify зависел от окружения самого образа (базовый образ указывал BASH_ENV на хук, переэкспортирующий LD_LIBRARY_PATH; ldd — это bash-скрипт, поэтому хук выполнялся первым).
  • Первая запись «невозможно поставить» (#868): deb-запись Kunlunxin xre5.37.1 остаётся отключённой, причина вписана в заметку зондирования в backends.yaml — библиотека CCL отсутствует в образе, используемом для сборки .deb (base Containerfile не устанавливает пакет CCL, полезная нагрузка установки XRE 5.37.1.0 не содержит xccl/bkcl, единственный libbkcl.so в стеке — runtime-артефакт внутри вендорского torch wheel), а даже если бы он нашёлся, его нельзя было бы слинковать (библиотека экспортирует C++ mangled-символы и не имеет чисто C-точек входа bkcl_*). Раздел triage в DESIGN.md перешёл от «1 зондирование в ожидании» к «19 готово + 1 с зафиксированной причиной».
  • Сопутствующие инженерные действия: #853 заставляет конвейер «по-пользовательски» читать обратно уже опубликованный apt-репозиторий; #854 позволяет при падении одной строки всё равно верифицировать успешно собранные строки; #855 позволяет диспетчеризации .deb принимать список бэкендов; #856 читает .deb тем же тулчейном, которым он собран; #859 пробрасывает прокси узла внутрь контейнера verify.

Интерпретация: эта линия — наиболее значимое с точки зрения продукта изменение в текущем выпуске. Ранее доступность FlagCX означала «сможет ли пользователь сам собрать библиотеку коммуникаций», а для программного стека, которому нужно одновременно охватить приватные инструментальные цепочки более десятка вендоров, это был последний ручной барьер на пути к масштабируемой поставке. Размещение .deb в apt-репозитории, разбитом по дистрибутивам, означает, что поверхность установки FlagCX впервые оказалась на том же уровне, что и pip install для плагинов vLLM/SGLang; а три ограничения — «публикация должна быть тем же самым файлом, что только что прошёл проверку», «publish не может обходить verify», «публикация из non-tag ref запрещена» — говорят о том, что этот слой построен с осознанием необходимости аудита. Kunlunxin явно зафиксирован как недоставляемый, а не туманно отложен, что также делает «19 готово / 1 по причине» поверхностью поставки, о которой можно заявлять публично.

1.3 Ядро FlagCX: рефакторинг net adaptor на 6601 строку, доукомплектование бэкенда device API по умолчанию в PAL (09-11/09-13)

Источники: FlagCX #578 (09-13 23:24), #582 (09-13 01:18), #584 (09-13 01:20), #585 (09-13 01:20), #586 (09-13 01:21), #588 (09-12 23:56), #580 (09-11 17:02)

  • Рефакторинг сетевого адаптера (#578, +5309/-1292): крупнейшее единичное изменение основного репозитория FlagCX в этом окне, по масштабу превышающее сумму остальных шести. Сетевой адаптер в направлении PAL (слой платформенной абстракции) переписан — это продолжение магистральной линии «библиотека коммуникаций собирает платформенные различия в слой абстракции».
  • Подключение бэкенда device API (#582): для оставшихся платформ подключён бэкенд device API по умолчанию — это две стороны одной проблемы с #865 на стороне build-infra, где «пустой вендорский .mk приводит к неопределённому devApiBackend»: основной репозиторий добавляет линковку, сторона поставки добавляет поле.
  • Доступность и документация: #586 при незаданном FLAGCX_PATH откатывается к системной библиотеке FlagCX, а не падает сразу; #584 перечисляет в getting_started все отсутствующие бэкенды (превращая «какие платформы поддерживаются» в документальный факт); #585 фиксирует версию clang-format, используемую хуком format.
  • Укрепление цепочки поставок (#588): CI-образ Hygon привязан к digest до SHCA, чтобы избежать тихого изменения среды сборки при изменении upstream-образа.
  • Правка вендорской адаптации (#580): исправлено имя типа topsDeviceProp в адаптере устройства Enflame.

Интерпретация: в этом окне FlagCX одновременно сделал три разнородные вещи — рефакторинг ядра (#578), доукомплектование платформенной линковки (#582/#580), укрепление поставки и CI (#584/#585/#586/#588). В сочетании с линией упаковки из 1.2 библиотека коммуникаций превращается из «библиотеки, которую можно слинковать» в «библиотеку, которую можно установить, локализовать и воспроизводимо собрать». Для многочипового программного стека библиотека коммуникаций как раз является компонентом, где легче всего накапливаются частные случаи между SDK разных вендоров (RCCL/ldconfig у Hygon, отсутствующий чисто C-вход у Kunlunxin, имена типов у Enflame); действия этого окна показывают, что эти частные случаи постепенно сводятся в тестируемый слой абстракции, а не остаются на ветках отдельных вендоров.

1.4 Линия sglang в build-infra: приземление двух прикладных линий — Kunlunxin xre5.37.1 и Iluvatar CoreX corex4.4.0 (09-12)

Источники: build-infra #857 (09-12 11:35), #860 (09-12 12:27), #861 (09-12 12:28), #862 (09-12 13:00), #863 (09-12 14:42), #864 (09-12 13:14), #867 (09-12 18:57), #869 (09-12 19:05), #870 (09-12 21:09), #871 (09-12 19:28)

  • Замкнутый цикл линии sglang Kunlunxin (#857→#864): сначала kunlunxin-xre5.37.1 был приведён в состояние «собираемо, запускаемо», затем зафиксированы результаты проверки F/T (функциональность и производительность), в репозиторий добавлен changelog sglang0.5.18-kunlunxin-xre5.37.1, записан тег образа приложения 2.1.2-0.1.dev1_g7fb22a0c2, а образ приложения Kunlunxin внесён в status matrix. В том же пакете исправлена проблема преждевременного завершения vllm-plugin-wheel по SIGPIPE при разборе plugin_ref (#860).
  • Линия приложений corex4.4.0 Iluvatar CoreX (#867→#871): дополнена и проверена конфигурация приложения corex4.4.0, в репозиторий добавлены changelog sglang0.5.18-iluvatar-corex4.4.0 и тег образа 2.1.2-0.1.dev1_g4d44a24cd.
  • Завершение линии 910C: #848 восстанавливает ожидающую релиза запись changelog для пересборки Ascend 910C, #850 (09-11 19:19) фиксирует тег образа CANN 8.5.0-910c 2.1.2-0.2.0_gf31b199.d20260911, #835 фиксирует сквозной результат 910C и уже поставленное исправление пути T для cann8.5.0, #852 (09-11 20:55) описывает в документации ловушку кэша слоёв docker, стоящую за «устареванием образа приложения».

Толкование: модели действий на стороне sglang уже стандартизированы в пятишаговый замкнутый цикл — сделать некий бэкенд собираемым, прогнать проверку F/T, зафиксировать changelog, записать тег образа, внести в status matrix. Kunlunxin и Iluvatar CoreX в одном и том же окне independently прошли этот цикл по одному разу, что показывает: этот путь замкнутого цикла (в предыдущем окне отдельно проверенный Ascend и Tsingmicro) теперь является воспроизводимой рутинной процедурой, а не разовым штурмом для каждого бэкенда. Для 2.2 GA реально определяющим масштаб релиза является число клеток «verified» в status matrix; в текущем окне добавились две клетки — Kunlunxin и Iluvatar CoreX corex4.4.0.

1.5 Линия build-infra vllm: Tsingmicro открывает 0.20.2, Iluvatar CoreX 0.24.0 сходится к единому plugin wheel (09-13)

Источники: build-infra #872 (09-12 21:09), #873 (09-13 10:27), #874 (09-13 20:10), #875 (09-13 22:38), #876, #877 (09-13 22:49), #878 (09-13 22:56)

  • Tsingmicro tsm260610 открывает vLLM 0.20.2 (#873): членство в матрице приложений определяется ключом deps_app для каждого бэкенда в configs.yaml; у Tsingmicro ранее был только vllm0.24.0, из-за чего generate_matrix.py --app vllm0.20.2 выводил пустой список include, и задание сборки пропускалось ещё до запуска. В этот раз добавлено vllm0.20.2: [] (plugin wheel 0.20.2 не требует дополнительных вендорских пакетов), а также приложена запись для предстоящего релиза; тег образа записан как 2.1.2-0.2.1_g90ffdf0.d20260912 (#874), plugin прибит к голове VPF #489, на которой проводилась сквозная проверка F/T (в #872 зафиксированы результаты F/T для 0.20.2 этого раунда).
  • Сходимость Iluvatar CoreX 0.24.0 (#875→#878): два образа приложений corex перестроены из головы vllm-plugin-FL одного коммита (symm_mem stub), так что corex4.4.0 и 4.5.0 сходятся к одной версии vllm_fl, а не прибиваются по отдельности к VPF #434 и варианту wheel g07063fd; тег образа записан как 2.1.2-0.2.1_gc9e2573.d20260913. Этот же коммит явно отклонил план «починить T-путь corex4.4.0 в том же wheel» — этот фикс так и не был влит, пробный патч лишь заставлял serve выдавать мусор, а поскольку модуль бэкенда Iluvatar CoreX общий, его включение поставило бы под риск уже проверенный T-путь corex4.5.0; в итоге это записано в разделе 14.4, а не продавлено силой.

Толкование: оба действия указывают на одну инженерную ориентацию — матрица должна «перечисляться», бэкенд должен «сходиться к одному и тому же плагину». Проблема Tsingmicro не в том, что чип непригоден, а в том, что ключи матрицы приложений были прописаны не полностью, и задание сборки молча пропускалось; такое отсутствие, когда «кажется, что ничего не произошло», труднее всего обнаружить в период RC, и оно лучше всего показывает, что configs.yaml уже стал реальным перечнем релизной поверхности. У Iluvatar CoreX же это типичная запись компромисса: отказаться от фикса, который загрязнил бы общий модуль, в обмен на определённость проверенного пути corex4.5.0 — дисциплина «только фиксы, никаких фич» в период RC-тестирования в конкретном коммите выражается как «лучше не чинить, чем сломать уже проверенную клетку».

1.6 FlagTree: бенчмарки и синхронизация бэкендов после 0.7.0rc1 — кластер Kunlunxin +17604 строк, бенчмарк Iluvatar CoreX в CI (09-11/09-13)

Источники: FlagTree #1150 (09-11 19:55), #1153 (09-13 22:28), #1155 (09-11 17:55), #1157 (09-11 17:24)

  • Синхронизация кластера Kunlunxin XPU (#1155, +17604/-1775): синхронизация анализа cluster и pass из внутреннего 5a664566 — внедрены анализ Scalar/Tile/Vectorizability, а также XPU-специфичные pass (Normalize, AsyncLoadSchedule, TLELegalize, LoopInvariantStaging, LegalizeExternEW), добавлены операторы stage_sm / load_scalar_indexed и lowering GM2SM, сохранены атрибуты рукописного OffsetAnalysis, а budget-tiling и loop-invariant-staging по умолчанию отключены; одновременно внедрён raw-фронтенд P-TLE (tle.raw), исправлен sinking size-one make range, а compiler.py получил передачу бюджетных ручек UnrollControl (pin_unroll_num=-1 направляет vector-add по существующему пути unroll). Источник помечен как baidu/xpu/triton 6848085b..5a664566.
  • Бенчмарки Iluvatar вошли в CI (#1153): vLLM benchmark от iluvatar добавлен в рабочий процесс, что согласуется с подходом линии PPU в предыдущем окне.
  • Обновление бенчмарков PPU (#1157): обновлены результаты PPU vLLM benchmark на 890P (33 строки данных).
  • Синхронизация с upstream Triton (#1150): из upstream triton внедрён warp layout broadcast.

Толкование: после сближения номеров версий 0.7.0 (в предыдущем окне) центр активности компилятора сместился к «бенчмаркизации бэкендов + синхронизации кластеров». Две бенчмарочные линии (vLLM benchmark Iluvatar в CI, обновление результатов PPU 890P) показывают, что данные о производительности начинают непрерывно фиксироваться по бэкендам; синхронизация кластера Kunlunxin на +17604 строк говорит о том, что линия XPU по-прежнему продвигается способом «внутренняя ветка → открытый кластер», причём с консервативной настройкой «какие pass отключены по умолчанию» — переключатели бенчмарков и pass также являются управляемыми объектами.

1.7 FlagGems: дополнение алгебры KMCompiler для Ascend, приёмка многопроизвольного KernelGen, миграция семейства copy Kunlunxin в TLE (09-11/09-14)

Источники: #6093 (09-11 18:59), #6136 (09-11 17:48), #6161 (09-11 17:13), #6201 (09-14 09:44), #6203 (09-11 17:16), #6205 (09-11 17:51), #6209 (09-14 09:48), #5671 (09-14 10:12), #6183 (09-11 17:33), #6192 (09-11 18:37), #6213 (09-13 20:15), #5642 (09-14 09:09)

  • Алгебра Ascend в KMCompiler продолжает пополняться: в окне мониторинга в бэкенд Ascend добавлены matrix_rank (#6161), igammac (#6136), gru (#6201), adaptive_max_pool3d (#5671, NVIDIA и Ascend совместно используют Triton kernel), пропуск базового пути Ascend для linalg_solve_triangular (#6209) и объявления зависимостей (#6205).
  • Сгенерированные KernelGen операторы вошли в репозитории нескольких производителей: на стороне NVIDIA добавлены split_with_sizes (#5590) и convolution_overrideable (#5642, с Triton kernel); на стороне Moore Threads за один раз добавлены четыре специализированных оператора — conv_transpose1d (#6174), upsample_linear1d_backward (#6175), fmod_ (#6170), matmuladd (#6180).
  • Семейство copy для Kunlunxin переведено на TLE (#6093): операторы семейства copy переведены с обычного пути на реализацию TLE (Triton Language Extension), что соответствует продвижению TLE на стороне FlagTree.
  • Корректность и инженерная часть: три партии исправлений категорий с префиксом [k] — индексация и сортировка (#5971), категория nn (#5969), категория математики (#5967); в кэше автотюнинга включены режим SQLite WAL и busy_timeout для исправления “database is locked” (#6203); в CI исправлено ошибочное удаление import в sort_exports при двойном __all__ (#6213); обновлены docker-образы FlagTree CI для Kunlunxin и Iluvatar CoreX (#6192).
  • Бенчмарки: добавлен независимый тест производительности матричного умножения FP8 с использованием vLLM в качестве базовой линии (#6183); в документацию fused_marlin_moe добавлено пояснение, что “раскладка весов не является раскладкой vLLM Marlin” (#6204).

Интерпретация: Структура 21 коммита FlagGems в данном окне мониторинга весьма показательна — Ascend по маршруту KMCompiler доукомплектовывается пооператорно (один оператор — один коммит), NVIDIA и Moore Threads по маршруту KernelGen загружаются пакетно, а KunlunXin переходит на модификацию под TLE. Смысл параллельного существования трёх путей в том, что одна и та же библиотека операторов одновременно несёт три вида производительности — «автоматическую генерацию компилятором», «пакетный выпуск генератором» и «ручную оптимизацию под TLE», — причём каждый соответствует бэкенду разной степени зрелости. С инженерной точки зрения наиболее примечательно исправление SQLite WAL для кэша автотюнинга — параллельная запись кэша при крупномасштабном прогоне бенчмарков на множестве чипов представляет собой типичный отказ длинного хвоста; подобные исправления обычно выявляются только при масштабной параллельной валидации и являются реальным результатом фазы RC-тестирования.

1.8 Линия плагинов для инференса и обучения: запуск рабочего процесса Hygon vLLM 0.24.0, слияние четырёх конкурсных веток на стороне SGLang (09-11/09-12)

Источники: vllm-plugin-FL #436 (09-11 10:54), FlagGems-vllm #756 (09-12 12:08), #768 (09-11 17:29), #769 (09-11 17:09), #771 (09-11 18:07), #775 (09-12 13:03), #753 (09-11 17:30), FlagGems-sglang #45 (09-12 11:43), #47 (09-12 12:16), #58 (09-12 12:21), #61 (09-12 11:44)

  • Hygon входит в рабочий процесс vLLM 0.24.0 (vllm-plugin-FL #436): включение рабочего процесса Hygon для vLLM 0.24.0 — очередная реализация пути «сначала запускаем рабочий процесс для нового чипа/новой версии, потом говорим о поставке» на уровне плагина.
  • Операторы и тестовый периметр FlagGems-vllm: на стороне Hygon добавлена реализация persistent_topk и выполнено подключение через fused __init__ (#756); на стороне Ascend добавлен per_token_group_quant_fp8 (#775); на стороне MetaX оптимизировано GDN chunk kernel (#771); добавлен fp8_einsum вместе с тестами и бенчмарком vLLM (#769); включены тесты кросс-бэкендных операторов FP8-последовательностей (#768); тесты и бенчмарки combine_topk_swa_indices переведены в vendor-agnostic вид (#753).
  • Слияние четырёх конкурсных веток FlagGems-sglang (09-12): четыре PR — add-chunk-local-cumsum-vec (#45), add-context-attention (#47), qkv-lora-b (#58), chunk-state-varlen-v2 (#61) — названные по competition/ и персональным ветками, были последовательно влиты в master в течение 40 минут.

Разбор: интересно смотреть на эти две вещи плагинной линии вместе. С одной стороны, такие изменения, как fp8_einsum и combine_topk_swa_indices, переписывают «тесты, специфичные для конкретного вендора», в vendor-agnostic вид — это то же направление, что и «сведение бэкендов к единому plugin wheel» на стороне build-infra, а именно сокращение вариантов, по одному на каждого вендора. С другой стороны, четыре слияния FlagGems-sglang пришли из конкурсных веток, что говорит о том, что результаты общественных конкурсов уже попадают в основной репозиторий, а не остаются на таблице лидеров; для 2.2 эти операторы войдут в список релиза вместе с flaggems-sglang v0.1.0-rc1.postN.

1.9 Научные вычисления и библиотеки доменных операторов: два пакета операторов для Hygon и MetaX сосредоточенно дополнены, FlagBLAS Iluvatar L2, FlagSparse с двумя бэкендами (09-11)

Источники: FlagGems-Experimental #586 (09-11 18:50), #567, #606 (09-11 16:56), #415 (09-11 17:25), #427 (09-11 17:14), FlagBLAS #115 (09-12 17:31), FlagSparse #57 (09-11 02:56), #58 (09-11 07:44), FlagDNN #10 (09-11 06:25)

  • FlagGems-Experimental: массовое добавление операторов Hygon в репозиторий: за один раз добавлена партия обратных и специальных функций: reflection_pad1d_backward (#567), embedding_bag_dense_backward (#575), upsample_nearest_exact2d_backward (#576), lift_fresh (#585), mse_loss_backward (#574), binary_cross_entropy_backward (#577), special_round (#582), special_chebyshev_polynomial_u (#583), amp_foreach_non_finite_check_and_unscale_ (#559), addmv_ (#572), diagonal_scatter (#570), special_shifted_chebyshev_polynomial_v (#584), baddbmm_ (#586) и другие; одновременно добавлен специализированный оператор linear для Damo Academy XuanTie (#606, маршрут KernelGen).
  • FlagGems-Experimental: параллельное добавление и удаление партий MetaX: около 35 коммитов, связанных с MetaX, половина — “Add MetaX support” (weight_int8pack_mm #415, unsafe_masked_index_put_accumulate #413, max_pool3d_with_indices_backward #402, cholesky_inverse #390, cudnn_convolution #392 и другие), половина — “Fix MetaX implementation” (special_gammaln #427, special_bessel_j0 #426, linear_backward #425, linalg_cholesky #423, histc #418, gcd_ #417, erfinv #416 и другие). Эти два потока чередуются в один и тот же день, что говорит о том, что данный бэкенд вошёл в фазу интенсивной калибровки “добавление реализации + исправление реализации”.
  • FlagBLAS: поддержка L2 для Iluvatar (#115, +5325 строк): для iluvatar добавлена поддержка уровня L2 (матрица-вектор) и выполнен merge с master.
  • FlagSparse: добавление MetaX и Ascend + калибровка SPMM: в окне мониторинга metax ascend added, ascend multi datatype, spmm bell out of metax test и проверки CI, PR #57/#58 от внешних контрибьюторов (NCIC-AlphaSparse) влиты в основной репозиторий.
  • FlagDNN: обновление бэкенда Damo Academy XuanTie + README производителей: обновлён бэкенд thead (#10), добавлены README для Moore Threads и Ascend.

Толкование: информационная ценность этого уровня доменных библиотек заключается в “гранулярности восполнения” — 54 коммита в экспериментальную библиотеку операторов за одно окно + поддержка уровня L2 в FlagBLAS + добавление двух бэкендов в FlagSparse говорят о том, что шесть библиотек AI for Science версии 2.2 движутся от “работает” к “полноте охвата”. Особенно примечательна форма партий MetaX: Add и Fix чередуются, что является типичным сигналом перехода бэкенда от “наличия операторов” к “корректности операторов”; такая калибровочная работа обычно не может быть выявлена проверкой на одном чипе — её можно обнаружить только путём сравнения нескольких бэкендов.

1.10 FlagQuantum: слияние архитектуры vNext + проверка релизных артефактов 0.2.0 + цифровой двойник QPU (09-11/09-13)

Источники: FlagQuantum #15 (09-11 18:26), #16, #17 (09-11 18:56), #18, #19 (09-11 20:31), #20 (09-11 22:11), #23 (09-13 15:06), #24 (09-13 18:29), #25 (09-13 19:33), #26 (09-13 20:05)

  • Архитектура vNext слита в основную ветку (#15): история публикаций vNext подключена к upstream main, ветка рефакторинга архитектуры влита.
  • Проверка релизных артефактов 0.2.0 (#17): метаданные Homepage/Repository/Issues Python-пакета направлены на flagos-ai/FlagQuantum и выровнены с опубликованным upstream-репозиторием; в описании коммита зафиксированы критерии проверки — wheel и sdist прошли проверку содержимого релиза и строгую проверку Twine, оба типа установочных артефактов прошли выполнение API, двухшаговый цикл обучения PyTorch, загрузку профилей операторов и верификацию численной согласованности Double-Single.
  • Квантовые бэкенды и возможности серверной стороны: #16 уточняет способ установки плагина QSteed для Quafu; #18 предоставляет контейнеры разработки для CUDA и QSteed; #19 поддерживает отправку схем Quafu на компиляцию на серверной стороне; #20 добавляет возобновляемые задания Quafu и нативные задания Цзюдин.
  • Цифровой двойник QPU (#24/#25/#26): в fq.twin представлен вендор-нейтральный цифровой двойник QPU, поддерживается офлайн-загрузка проверенных свидетельств Twin и персистентность свидетельств; #23 с сохранением обратной совместимости переносит публичные ключевые слова квантовых битов.

Толкование: квантовое направление в этом окне демонстрирует завершённую траекторию «продуктизации» — слияние архитектуры (vNext), выравнивание релизных артефактов и метаданных (0.2.0), контейнеры разработки и отправку на серверную сторону, а затем цифровой двойник и персистентность свидетельств. Если в июне, на момент выпуска «научно-интеллектуальной основы», FlagQuantum ещё находился в нарративе «первого шага слияния квантов и интеллекта», то действия текущего окна — это уже стандартный процесс выпуска открытого проекта (distribution content check, Twine strict, дымовой тест цикла обучения PyTorch, численная согласованность). Для ландшафта FlagOS: как только линия квантовых вычислений входит в самостоятельный ритм версионирования, способ управления её компонентами (FEP, ветка rc1, release manifest) также встанет в один ряд с остальными 25 компонентами.

1.11 Поверхность фреймворков обучения и инструментов: Megatron-LM-FL отвязывает жёсткую зависимость от CUDA, FlagScale/FlagPrism/TransformerEngine-FL продвигаются каждый по-своему (09-11/09-14)

Источники: Megatron-LM-FL #149 (09-11 10:41), #150 (09-11 14:04), #151 (09-11 19:04), #154 (09-12 18:06), #156 (09-14 09:00), TransformerEngine-FL #118 (09-11 14:10), FlagScale #1291 (09-11 19:01), FlagPrism #10 (09-11 21:24), FlagOS-Compressor #7 (09-11 14:27)

  • Де-CUDA-изация Megatron-LM-FL (пять коммитов): #156 заменяет жёстко закодированные операции с устройствами CUDA на API с учётом платформы, охватывая оптимизатор, инициализацию, обучение и служебные пути; создание и синхронизация потоков DDP переведены на реализацию текущей платформы, а также обновлены размещение устройств, создание тензоров, проверки доступности и инициализация во время выполнения — в описании коммита явно указана цель «предотвратить ошибочное использование CUDA или API, специфичных для Musa, на не-CUDA платформах при инициализации и выполнении обучения»; #154 заставляет машину состояний rerun использовать платформенное устройство; #151 исправляет имя платформы и имя устройства на стороне плагина; #149 заставляет экспертный параллелизм данных использовать world size из группы процессов; #150 убирает дублирующийся атрибут stage у P2P-коммуникатора при конвейерном параллелизме.
  • TransformerEngine-FL #118: заставляет путь внимания соблюдать переключатель «отключить flash attention» (ранее этот флаг не учитывался).
  • FlagScale #1291: добавлены оптимизированные runtime-операторы KERV.
  • FlagPrism #10: добавлена поддержка profiler и debugger для Moore Threads и обновлена документация (соответствует реализации «FlagTree DevTools» в FEP).
  • FlagOS-Compressor #7: влита ветка функции per-selector quantization.

Интерпретация: пять коммитов Megatron-LM-FL образуют чёткую основную линию: вычленение «CUDA или API, специфичных для Musa» из основной цепочки обучения. Для тяжёлых фреймворков обучения, нацеленных на мультичиповость, такого рода переработка является предварительным условием подключения новых ускорителей — если инициализация, DDP или размещение устройств хотя бы в одном месте всё ещё предполагают CUDA, не-CUDA платформы могут выживать только на ветках-патчах. Если рассматривать #156 вместе с аналогичными действиями из предыдущего окна, становится видно, что на стороне фреймворков обучения «платформенные различия» из разрозненных ветвей if собираются в единый платформенный API; это тот же инженерный словарь, что и абстракция PAL в FlagCX и абстракция бэкенда в FlagTree, повторяющийся на разных уровнях.

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

2.1 Десятое подряд спокойное окно компонентного поиска: вся техническая информационная картина исходит из репозиториев кода (09-11~09-14)

Источники: 18 групп поисковых запросов Google News RSS на китайском и английском (через прокси), HN Algolia (четыре группы: FlagOS / FlagGems / FlagScale / FlagTree), списки версий и трансляций на официальном сайте сообщества FlagOS, поиск Tavily/web

  • Компонентные запросы: нулевые совпадения: FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagAttention, FlagCX, KernelGen, FlagOS-Robo, FlagQuantum (when:7d~14d, на китайском и английском), BAAI open source — в пределах окна не дали ни одного релевантного совпадения, что образует десятое подряд спокойное окно компонентного поиска (предыдущее окно было девятым).
  • На стороне HN релевантных записей нет: четыре группы запросов в пределах окна вернули записи общего технического характера (публикация GrapheneOS получила флаг, DietPi v10.7, несколько проектов Show HN), не связанные с компонентами FlagOS; согласно установленному критерию все они исключены.
  • Запросы по членам организации: преобладает капитальный рынок: 燧原 when:2d (46), 沐曦 when:2d (27), 摩尔线程 when:2d (23), 海光 when:2d (11), 智源研究院 开源 when:7d (7), 天数智芯 when:2d (6), 地平线 开源 when:2d (1); подавляющее большинство составляют материалы о капитальном рынке и перепечатки, статьи сообщества Zhiyuan (конференция по AI, разбор открытых моделей и т. п.) напрямую не связаны с технологическим стеком FlagOS, а SEO-материалы со словами “спорт/вход/входная страница/официальный сайт/скачать/букмекерство” исключены целыми партиями. Отобранные по результатам фильтрации отраслевые материалы см. в 2.2.
  • На официальном сайте сообщества нет новых версий в пределах окна: последняя публикация с иллюстрациями на официальном сайте сообщества FlagOS по-прежнему датируется 28 августа (адаптация GLM-5.3-Flash Day0 к 9 чипам); в пределах окна добавились только записи о трансляциях и мероприятиях, что контрастирует с интенсивными действиями на стороне репозиториев кода.

Толкование: Десятое подряд спокойное окно само по себе является информацией — внешняя заметность FlagOS по-прежнему определяется преимущественно кодом и ритмом релизов, а отраслевые публикации ещё не сформировали устойчивого отслеживания компонентов. Для пользователей это означает, что ответ на вопрос “работает ли компонент” нужно читать из репозитория, а не из новостей; разрыв между 173 коммитами в текущем выпуске и нулём новостей также говорит о том, что до GA 2.2 (28 сентября) сообщество сосредотачивает внимание на стороне поставки, а не на стороне рекламы.

2.2 Три события на отраслевой стороне: выпуск гетерогенной системы вывода Mobile Cloud, итоги первого дня торгов после выхода Enflame на биржу, приближение окна разблокировки акций MetaX (11.09–13.09)

Источники: IT Home (13.09), Cailian Press / Star Market Daily (13.09), Securities Times (11.09 12:22), Cailian Press (11.09 21:00), Sina Finance (13.09/14.09)

  • Опубликована первая в Китае гетерогенная гибридная система инференса больших моделей «отечественный GPU + нейроморфный чип» (сообщение 09-13, выпуск 09-11~13): на конференции China Computing Conference 2026 в Ланфане (провинция Хэбэй) компания China Mobile Cloud совместно с CETC Nanhu Research Institute, Beijing Lynxi Technology, Shanghai Iluvatar CoreX, Университетом Цинхуа и Пекинским университетом представила эту систему. Технический подход — разделение PD/AF для Transformer: Prefill и Attention передаются отечественному GPU, а задержко-чувствительные модули, такие как FFN (эксперты MoE), передаются нейроморфному чипу, использующему преимущества вычислений в памяти и большой ёмкости SRAM на кристалле по пропускной способности; команда разработала собственный компилятор моделей, высокоскоростной протокол межсоединений и унифицированный движок инференса для декомпозиции задач, совместного планирования и агрегации результатов; решение ориентировано на гетерогенную архитектуру инференса следующего поколения Nvidia Vera Rubin with Groq. В ходе практических испытаний 3 сервера с GPU Iluvatar CoreX в паре с 3 нейроморфными стойками запускали DeepSeek V4 Flash: по сравнению с чисто GPU-кластером сопоставимого масштаба вложений производительность инференса и энергоэффективность инференса выросли более чем вдвое, а операционные затраты бизнеса снизились более чем на 40%; проект насчитывает 15 выданных патентов на изобретения, 6 свидетельств о регистрации ПО и уже вошёл в стадию мелкосерийного опытного производства.
  • Enflame Technology вышла на STAR Market, в первый день закрытие выросло на 179% (09-11): цена размещения 142,18 юаня за акцию, размещено 43 035 200 акций, общий объём привлечённых средств около 6,12 млрд юаней; открытие 410 юаней (+188,37% к цене размещения), максимум в течение дня 475 юаней, закрытие 397 юаней (+179%), рыночная капитализация за день около 170,9 млрд юаней, оборачиваемость 76%; коэффициент эффективных онлайн-заявок 6109 раз, доля удовлетворённых заявок 0,0246%. Компания пока не прибыльна и в соответствии с правилами включена в слой роста STAR Market; выручка в 2023–2025 годах составила 3,01/7,22/9,90 млрд юаней, выручка за первое полугодие 2026 года — 11,20 млрд юаней с ростом на 279,08% год к году; это единственная из четырёх отечественных GPU-компаний, сделавшая ставку на специализированную архитектуру DSA и не совместимая с экосистемой CUDA. С выходом Enflame на биржу все «четыре дракона отечественных GPU» (Moore Threads, MetaX, Enflame, Biren) завершили капитализацию.
  • Приближается окно разблокировки акций MetaX (анонс 09-13, вступление в силу 09-17): 13,966 млн ограниченных в обращении акций MetaX будут разблокированы 17 сентября, что соответствует рыночной стоимости около 6,829 млрд юаней, что составляет примерно 75% свободно обращающихся акций; в тот же период сообщалось, что в сентябре её акции упали почти на 30%, а от максимума — более чем на 50%. Справочные данные (полугодовой отчёт 08-30, вне данного окна): выручка за первое полугодие 2026 года 13,24 млрд юаней с ростом на 44,67% год к году, чистая прибыль, причитающаяся материнской компании, 6,12 млрд юаней — выход из убытков (при этом прибыль без учёта нерегулярных статей всё ещё -0,49 млрд юаней), из них чистая прибыль во втором квартале 7,11 млрд юаней; компания уже 2026-06-12 объявила о планах выпуска акций H, начав построение двухплатформенной структуры A+H.

Разбор: три события находятся на разных уровнях — гетерогенная система инференса China Mobile Cloud является сигналом на уровне технологического подхода (GPU больше не рассматривается как единственная форма вычислительной мощности, нейроморфный чип входит в цепочку инференса в позиции «модуля, чувствительного к пропускной способности», и Iluvatar CoreX является поставщиком GPU в этой системе); Enflame и MetaX — сигналы на уровне капитала (после капитализации всех четырёх драконов внимание рынка смещается от «способны ли сделать» к масштабным поставкам и реализации прибыли, а окно разблокировки MetaX — прямой стресс-тест этого смещения). Значение для FlagOS состоит в том, что оба типа сигналов повышают реальную ценность «единого программного стека для множества чипов» — гетерогенная система инференса требует компилятора и унифицированного движка инференса для планирования двух типов вычислительных мощностей, а после выхода отечественных GPU на масштабные поставки стоимость миграции их программного стека напрямую определяет, смогут ли заказы быть реализованы.

2.3 Активности сообщества и соревнования: соревнование по оптимизации операторов SGLang для разных чипов и встреча-обмен опытом по баунти-соревнованию операторов, результаты соревнований начинают попадать в основной репозиторий (09-11~09-12)

Источники: официальный сайт сообщества FlagOS (списки мероприятий и трансляций), записи о слияниях в репозитории FlagGems-sglang в пределах окна

  • Соревнование по оптимизации операторов SGLang для разных чипов: совместно организовано Zhongzhi FlagOS и IEEE, при содействии SGLang; трек первый — многочиповая оптимизация производительности операторов в рамках фреймворка SGLang, включает более 200 задач на реальные операторы инференса, участники свободно выбирают задачи, они открываются партиями, разработка ведётся с использованием Triton / Triton-TLE, унифицированная проверка и единое измерение ускорения на нескольких чиповых платформах, предусмотрены онлайн-лидерборд и три категории наград: «приз за захват всей области / приз за прорывное покорение / приз за предельную производительность на отдельной задаче».
  • Встреча-обмен опытом победителей баунти-соревнования по операторам: официальный сайт сообщества зафиксировал трансляцию с выступлением победителей 09-10 в 19:00 (история пути, ключевые решения, способы избежать ошибок, практические приёмы и интерактивные ответы на вопросы), что является частью серии постоянных соревнований.
  • Результаты соревнований попадают в основной репозиторий: FlagGems-sglang в течение 40 минут 09-12 слил четыре PR из competition/ и личных веток участников (add-chunk-local-cumsum-vec, add-context-attention, qkv-lora-b, chunk-state-varlen-v2), все они указывают на операторы chunked attention и LoRA в цепочке инференса SGLang.
  • Экосистемные мероприятия: форум «Открытые AI-вычисления: создание новой экосистемы открытого ПО для разнородного гетерогенного оборудования», организованный сообществом Zhongzhi FlagOS, состоялся 09-07 в Шанхае в рамках конференции KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China (участвовали Zhiyuan, Шанхайская лаборатория искусственного интеллекта, PyTorch Foundation, SGLang и другие).

Толкование: то, что результаты конкурса попадают в основной репозиторий FlagGems-sglang в виде PR, — это наиболее недооценённый пункт текущего выпуска. Типичная проблема конкурсов сообщества — «на лидерборде оживлённо, а в основном репозитории ничего не изменилось», однако четыре ветки competition/ были влиты в master в одно и то же утро, что говорит о том, что между источниками задач, средой верификации и основным репозиторием уже налажена связь — конкурс фактически стал внешней линией поставки операторов, и эти операторы вместе со следующим rc1.postN войдут в список релиза 2.2. Это также объясняет действия из пункта 1.8, где «слой плагинов переводит тестирование в независимый от производителя режим»: чтобы унифицировать измерение ускорения, тесты и бенчмарки прежде всего должны стать сопоставимыми между производителями.

3. Углублённое изучение членов-организаций

3.1 Enflame: завершение капитализации «четырёх малых драконов отечественных GPU» звонком на STAR Market, техническая сторона синхронно правит адаптацию устройств enflame (09-11)

Источники: Securities Times (09-11), Cailian Press (09-11), FlagCX #580 (09-11 17:02)

  • Капитальная сторона: 09-11 выход на STAR Market (688801), цена размещения 142,18 юаня за акцию, открытие 410 юаней, закрытие 397 юаней (+179%), рыночная капитализация около 170,9 млрд юаней; все четыре предприятия отечественных GPU завершили капитализацию, «последний фрагмент пазла» встал на место. Данные проспекта и финансовой отчётности показывают, что выручка за первое полугодие 2026 года составила 1,120 млрд юаней с ростом на 279,08% год к году, совокупные расходы на НИОКР с 2023 по 2025 год — 3,676 млрд юаней, на конец 2025 года 643 сотрудника НИОКР (76,73% персонала), участие в 12 государственных и местных проектах научно-технического прорыва, участие в разработке 58 ключевых государственных и отраслевых стандартов по AI-чипам и интеллектуальным вычислительным системам.
  • Техническая сторона (в пределах окна): FlagCX #580 исправляет имя типа topsDeviceProp в адаптере устройств Enflame (enflame), что относится к правкам адаптации производителя на уровне абстракции платформы коммуникационной библиотеки.
  • Позиция в FlagOS: Enflame в матрице приложений build-infra по-прежнему присутствует двумя линиями sglang — enflame-tops1.9.10 и enflame-tops1.10.6, а в списке бэкендов .deb FlagCX является одним из уже включённых и прошедших проверку пунктов.

Толкование: Enflame — единственное из четырёх малых драконов предприятие, идущее по пути специализированной архитектуры DSA и собственного программного стека, что определяет и его отношения с FlagOS: они скорее «самостоятельный программный стек + выборочная интеграция» — две прикладные линии enflame-tops давно существуют в матрице FlagOS, но техническое действие в этом окне — лишь исправление одного имени типа, носящее поддерживающий, а не расширяющий характер. Для сравнения: в том же окне Iluvatar CoreX, Qingwei и Hygon совершили содержательные продвижения как в бэкендах, так и в прикладных линиях. После завершения капитализации следующее испытание Enflame — монетизация НИОКР и исполнение заказов, что напрямую отразится на том, продолжит ли компания увеличивать инвестиции в мультичиповый программный стек.

3.2 Iluvatar CoreX: вход в гетерогенную систему инференса Mobile Cloud, параллельная работа по пяти фронтам внутри FlagOS (09-11~09-13)

Источники: IT Home (09-13), FlagBLAS #115 (09-12 17:31), build-infra #867/#869/#870/#871 (09-12), build-infra #875/#877/#878 (09-13), FlagTree #1153 (09-13 22:28)

  • Отраслевой аспект: в гетерогенной гибридной системе вывода «отечественный GPU + нейроморфный чип», выпущенной под руководством Mobile Cloud, Iluvatar CoreX выступает поставщиком GPU (3 сервера с GPU Iluvatar CoreX + 3 нейроморфных стойки, работающие с DeepSeek V4 Flash) и отвечает за вычисления Prefill и Attention.
  • Пять рабочих направлений внутри FlagOS: во-первых, поддержка L2-уровня FlagBLAS вошла в master (+5325 строк); во-вторых, в прикладной линейке sglang инфраструктуры сборки добавлен sglang0.5.18-iluvatar-corex4.4.0 (проверка конфигурации + changelog + тег образа); в-третьих, на стороне vllm версии corex4.4.0/4.5.0 для 0.24.0 сведены в единый plugin wheel; в-четвёртых, FlagTree добавил бенчмарк vLLM для iluvatar в рабочий процесс CI; в-пятых, в списке бэкендов .deb для FlagCX одновременно включены iluvatar-corex4.4.0/4.5.0.

Толкование: Iluvatar CoreX — членская организация, наиболее часто встречающаяся в этом выпуске, причём техническая и отраслевая линии не пересекаются — на отраслевой стороне это «вход в гетерогенную систему вывода в качестве отечественного GPU», на стороне FlagOS — одновременное продвижение на четырёх уровнях: «базовые библиотеки + прикладная линейка + бенчмарки + упаковка». Логически эти две вещи взаимодополняют друг друга: разбиение чувствительных к пропускной способности модулей в гетерогенной системе вывода в конечном счёте должно реализовываться через планирование на уровне библиотек операторов, компилятора и коммуникационной библиотеки, а FlagOS — наиболее прямой кандидат на роль программного фундамента для таких систем. Примечательно, что на стороне FlagTree бенчмарк внесён в CI, а значит, данные о производительности Iluvatar CoreX отныне будут существовать в виде непрерывной записи, а не разового отчёта.

3.3 Tsingmicro: открытие прикладной линейки vLLM 0.20.2, замкнутый цикл сквозной верификации и тега образа (09-13)

Источники: build-infra #872 (09-12 21:09), #873 (09-13 10:27), #874 (09-13 20:10)

  • Дополнение ключа в прикладной матрице: бэкенд Tsingmicro tsingmicro-tsm260610 ранее нёс только vllm0.24.0, из-за чего вывод --app vllm0.20.2 был пустым, а задание сборки молча пропускалось; после того как #873 добавил vllm0.20.2: [], эта строка вошла в матрицу сборки вместе с changelog и записью для предстоящего релиза.
  • Замкнутый цикл верификации: #872 фиксирует сквозные результаты F/T для 0.20.2, #874 фиксирует тег образа 2.1.2-0.2.1_g90ffdf0.d20260912, плагин привязан к голове VPF #489, соответствующей верификации; в списке бэкендов .deb для FlagCX tsingmicro-tsm260610 также является включённым элементом.
  • Линия продолжения: два рабочих процесса build-and-test и delivery для tsingmicro3.6, созданные в прошлом окне мониторинга (на стороне FlagTree), в текущем окне не пополнились и находятся в штатном состоянии линии поставки.

Толкование: ценность этой линии Tsingmicro не в новых возможностях, а в том, что она вскрыла системный риск — отсутствие ключа в прикладной матрице приводит к молчаливому пропуску сборки. В матрице, охватывающей более десятка производителей, у каждого из которых несколько комбинаций версий, «ошибки нет, но ничего не собрано» заметить сложнее, чем провал сборки. После добавления этой строки Tsingmicro на стороне vLLM одновременно располагает двумя линейками — 0.20.2 и 0.24.0, а с учётом двух рабочих процессов FlagTree и deb-бэкенда FlagCX глубина её интеграции уже сопоставима с самыми первыми членскими организациями.

3.4 Hygon Information: пробит deb-бэкенд коммуникационной библиотеки, запущен рабочий процесс vLLM, массово дополнены операторы — три линии в движении (09-11/09-12)

Источники: vllm-plugin-FL #436 (09-11 10:54), build-infra #866 (09-12 18:25), FlagCX #588 (09-12 23:56), FlagGems-vllm #756 (09-12 12:08), FlagGems-Experimental #586 (09-11 18:50)

  • Бэкенд .deb для коммуникационной библиотеки подключён (#866): бэкенд Hygon DTK перешёл из состояния «обнаружение отложено» в состояние «включён». В ходе этого были устранены три класса проблем окружения — DTK не экспортирует CUDA_PATH, из-за чего DEVICE_HOME/CCL_HOME оказываются пустыми; -lnccl фактически разрешается в RCCL (в продукте NEEDED указан librccl.so.1); а хук BASH_ENV в образе DTK загрязняет окружение ldd при verify.
  • Плагины и CI: #436 включает рабочий процесс Hygon для vLLM 0.24.0; #588 фиксирует образ Hygon CI на digest, предшествующий SHCA, чтобы избежать дрейфа upstream-образа.
  • Операторная часть: FlagGems-vllm дополнен persistent_topk и подключён к fused __init__; FlagGems-Experimental за один раз добавил более десятка обратных и специальных операторов для Hygon (reflection_pad1d_backward, embedding_bag_dense_backward, mse_loss_backward, binary_cross_entropy_backward, lift_fresh, baddbmm_ и другие).

Разбор: плотность действий Hygon в этом окне мониторинга наивысшая среди членов-организаций, и три направления взаимодополняют друг друга — на стороне коммуникационной библиотеки решается вопрос «можно ли вообще это установить» (пути DTK, именование RCCL и ldconfig — три частных случая представляют собой реальные точки трения в вендорском инструментарии, и все они были зафиксированы в описаниях коммитов, а не остались на чьей-то машине), на стороне плагинов решается вопрос «можно ли это запустить», на стороне операторов — «достаточно ли покрытие». Одна деталь заслуживает внимания: фиксация образа CI на digest — в мультивендорных конвейерах детерминированность окружения сборки зачастую игнорируется легче, чем сам код, и линия Hygon здесь proactively усиливает защиту.

3.5 Moore Threads и MetaX: две партии — генерирующие операторы и бэкенд-операторы — выходят в релиз, ритм капитала на отраслевой стороне расходится (09-11~09-13)

Источники: FlagGems #6174, #6175, #6170, #6180 (09-11 18:17~18:21), FlagPrism #10 (09-11 21:24), FlagGems-vllm #771 (09-11 18:07), FlagSparse #58 (09-11 07:44), Sina Finance (09-13/09-14)

  • Moore Threads: маршрут KernelGen обеспечил пакетное добавление в репозиторий четырёх специализированных операторов (conv_transpose1d, upsample_linear1d_backward, fmod_, matmuladd); FlagPrism добавил для них поддержку profiler и debugger и обновил документацию; FlagDNN дополнил README для Moore Threads; в списке .deb-бэкендов FlagCX включены две линии — mthreads-musa4.3.6 и mthreads-musa5.2.0; на отраслевой стороне продолжается сюжет о кластере на сто тысяч карт от JD Cloud (исходное событие 09-09, уже вошло в предыдущий выпуск; в текущем окне это перепечатки и аналитические материалы, повторно не учитываются).
  • MetaX: FlagGems-vllm оптимизировал GDN chunk kernel (#771); FlagGems-Experimental — около 35 коммитов, связанных с MetaX (добавление поддержки и исправления реализации идут вперемешку); FlagSparse добавил поддержку metax; в списке .deb-бэкендов FlagCX соответствующая линия MetaX в данном окне не включена.
  • Отраслевая дивергенция: 09-17 у MetaX наступает разблокировка 13,966 млн акций (около 6,829 млрд юаней); в рамках окна несколько публикаций сосредоточены на откате её котировок и давлении разблокировки; у Moore Threads в окне появилась публичная запись о новой заявке на регистрацию товарного знака «MT Lambda».

Трактовка: обе компании с технической точки зрения находятся на стадии «пакетного восполнения операторов», но источники возможностей различаются — четыре оператора Moore Threads пришли из маршрута генерации KernelGen, тогда как партия MetaX сосредоточена на рукописных реализациях и исправлениях в FlagGems-Experimental. Отраслевая дивергенция столь же отчётлива: MetaX вступает в цикл разблокировки акций и давления на котировки, а Moore Threads находится в восходящей фазе нарратива о заказах уровня ста тысяч карт. Для FlagOS темпы технических вложений обеих компаний не замедлились вслед за колебаниями рынка капитала — объём коммитов каждой из них в данном окне входит в число лидирующих среди организаций-участников.

3.6 Kunlunxin (внешний участник экосистемы): значительная синхронизация на стороне компилятора, но коммуникационная библиотека зафиксирована как «непоставляемая» (09-11/09-12)

Источники: FlagTree #1155 (09-11 17:55), FlagGems #6093 (09-11 18:59), build-infra #857/#861/#862/#864 (09-12), build-infra #868 (09-12 21:08)

  • Сторона компилятора: XPU-кластерная синхронизация FlagTree — самый крупный единичный коммит этого выпуска (+17604/-1775), вводит целый набор аналитических фреймворков и XPU-специфичных pass, P-TLE raw-фронтенд и передачу бюджета UnrollControl.
  • Сторона операторов: FlagGems переносит семейство операторов copy для Kunlunxin на реализацию TLE (#6093), что перекликается с продвижением TLE на стороне компилятора.
  • Прикладная линия: build-infra обеспечивает сборку и запуск kunlunxin-xre5.37.1 в линии sglang, а также завершает верификацию F/T, changelog, тег образа и запись в status matrix.
  • Запись границ: FlagCX явно помечает kunlunxin-xre5.37.1 как «не поставляемый» — библиотека CCL отсутствует в образе, используемом для сборки .deb (base-образ не устанавливает пакеты CCL, полезная нагрузка XRE 5.37.1.0 не содержит xccl/bkcl, единственная libbkcl.so находится внутри вендорского torch wheel и экспортирует C++ mangled-символы, не имея чистого C-входа).

Толкование: Kunlunxin в этом окне демонстрирует одновременно «продвижение» и «ограничение». +17604 строк на стороне компилятора говорят о наращивании усилий по синхронизации внутренней ветки с открытым кластером; прикладная сторона прошла полный замкнутый цикл sglang; однако уровень коммуникационной библиотеки признан текущим непоставляемым, причём причина описана весьма конкретно (библиотека отсутствует в сборочном образе, и даже если её найти, привязать не удастся). Такая граница — «компилируется и работает, но коммуникационную библиотеку не упаковать» — именно то состояние, которое многочиповому программному стеку необходимо явно управлять: оно определяет, способен ли данный бэкенд поддерживать одноузловой инференс или сценарии с интенсивной межузловой коммуникацией.

3.7 Zhiyuan (ведущая сторона): дисциплина тестового периода 2.2 и ведение списка RC1, GA назначен на 09-28 (09-11)

Источники: community #108 (09-11 11:45), расписание 2.2 и список RC1 в репозитории community (raw-выгрузка)

  • Управление тестовым периодом: цикл 2.2 — заморозка функций 08-31 → период тестирования и стабилизации с 09-01 по 09-24 (принимаются только исправления багов, новые функции не вносятся) → GA 09-28; критерий выпуска FEP требует, чтобы Test Plan, покрывающий многочиповые сценарии, был принят в течение тестового периода, а непройденные части оформляются отдельным issue приёмки, привязанным к milestone.
  • Ведение списка: единственное изменение списка за окно — продвижение FlagGems с v5.4.0-rc1.post1 до v5.4.0-rc1.post2 с внесением четырёх типов исправлений (откат cost model, сортировка randperm, переполнение int64, упаковка подпакетов) в описание коммита.
  • Версионная поверхность: три линии triton FlagTree в списке записаны как 0.7.0rc1.post1+triton3.x, FlagCX — v0.14.0-rc1.post1, всего в списке 25 снимков компонентов.

Толкование: действия ведущей стороны в этом окне носят исключительно управленческий характер — ведение списка, соблюдение дисциплины заморозки, оформление критериев приёмки в виде проверяемого Test Plan. Такая работа невидима во внешних публикациях, но именно она определяет, сможет ли 09-28 дать поверхность поставки, где «у каждого компонента есть тег, и каждый тег прошёл многочиповую верификацию». В сочетании с действиями инженерной стороны (упаковка FlagCX, прикладные линии вендоров) ядро проблемы 2.2 — уже не «сколько чипов поддерживается», а «можно ли эти поддержки воспроизвести, установить и проаудировать».

4. Итоги

  1. Поверхность поставки стала главной линией этого окна, коммуникационная библиотека — первый полностью инженерно оформленный компонент (важнейшее изменение): FlagCX прошёл полную цепочку «сборка .deb по бэкендам внутри вендорского base-образа → публикация в apt-репозиторий, разделённый по версиям Ubuntu → чтение и верификация способом пользователя», при этом одновременно включив шесть бэкендов; сопутствующие ограничения (публикуемый артефакт должен быть тем же самым файлом, что только что прошёл верификацию, publish не может обходить verify, публикация по нетэговым ref запрещена) показывают, что этот уровень строится с осознанием аудита. Ранее доступность FlagCX означала «сможет ли пользователь сам собрать её под вендорский SDK», теперь — одну команду apt-get install.

  2. 2.2 вошла во вторую половину тестового периода, продвижение версий полностью определяется исправлениями: 25 снимков компонентов списка RC1 на месте, единственное изменение списка за окно — продвижение FlagGems до v5.4.0-rc1.post2 (четыре исправления: откат cost model, сортировка randperm, переполнение смещения int64, отсутствие упаковки подпакетов); Tianshu Zhixin для 0.24.0 явно отказывается от исправления T-пути, способного загрязнить общий модуль, чтобы сохранить уже верифицированный путь 4.5.0 — «лучше не починить, чем сломать проверенную ячейку» есть прямое воплощение дисциплины RC в коде. GA назначен на 09-28, тестовый период с 09-01 по 09-24.

  3. «Замкнутый цикл из пяти шагов» матрицы приложений становится воспроизводимым процессом, а риск отсутствия ключа оказывается exposed: дать бэкенду возможность собираться → прогнать проверку F/T → зафиксировать changelog → записать тег образа → внести в status matrix; в этом окне мониторинга Kunlunxin (sglang xre5.37.1) и Iluvatar CoreX (sglang corex4.4.0) прошли его по одному разу каждая; проблема Qingwei (deps_app заполнен не полностью, из-за чего сборка молча пропускается) показывает, что эта матрица уже обладает режимом отказа «ошибок нет, но ничего не собрано», а полнота конфигурации сама по себе является частью поверхности релиза.

  4. Внешние бэкенды продолжают наращивать усилия, и впервые явно фиксируется граница поставки: синхронизация кластера Kunlunxin XPU (+17604 строк), библиотека L2 и бенчмарки Iluvatar CoreX в CI, Qingwei открывает vLLM 0.20.2, пробит бэкенд Haiguang DTK deb — четыре линии продвигаются одновременно; в то же время коммуникационная библиотека Kunlunxin помечена как «непоставляемая» с указанием причины (библиотека CCL отсутствует в образе сборки, нет чисто C-входа). Ценность программного стека измеряется уже не только тем, «сколько производителей чипов поддерживается», но и тем, «до какой степени поддерживается каждый» — через формулируемые границы.

  5. Производительность операторов демонстрирует три параллельных направления, а соревнование начинает становиться внешней линией поставки: из 21 коммита FlagGems Ascend идёт путём KMCompiler с постепенным закрытием пробелов, NVIDIA и Moore Threads идут путём KernelGen с пакетным внесением в индекс, Kunlunxin идёт путём переработки TLE; из 54 коммитов FlagGems-Experimental Haiguang единовременно вносит более десяти обратных и специальных функций-операторов, а MetaX — около 35 коммитов в смешанном режиме «добавление + исправление». Наиболее долгосрочно значимым является то, что FlagGems-sglang 12 сентября утром в течение 40 минут влил четыре PR из веток competition/ межчипового соревнования операторов — результаты соревнования впервые в форме коммитов в основной репозиторий попали в релизный список.

  6. Две линии на стороне индустрии повышают фактический вес мультичипового программного стека: China Mobile Cloud совместно с Lynxi Technologies, Iluvatar CoreX и другими выпустила первую в стране гетерогенную гибридную систему инференса «отечественный GPU + нейроморфный чип» (разделение PD/AF, 3 сервера с GPU Iluvatar CoreX + 3 нейроморфных стойки запускают DeepSeek V4 Flash, производительность и энергоэффективность выросли более чем вдвое, стоимость снижена более чем на 40%), что показывает: планирование гетерогенных вычислений уже вступило в стадию инженерии; Enflame в первый день выхода на STAR Market закрылась ростом на 179%, все четыре дракона стали капитализированы, а MetaX сталкивается с окном разблокировки 6,8 млрд юаней 17 сентября — фокус отечественных GPU смещается с «сделать» на масштабную поставку и реализацию прибыли, а стоимость миграции и стабильность кластера — это две переменные, которые в этом сдвиге наиболее зависят от системного программного стека.

Прогноз: дальнейшее наблюдение по четырём пунктам — во-первых, ритм наращивания rc1.postN перед GA 28 сентября и какие ещё пункты списка претерпят ещё одну итерацию; во-вторых, продвинется ли запись FlagTree в списке (0.7.0rc1.post1+triton3.x) до официального release tag, а также догонит ли pin-значение линии NVIDIA в build-infra значение 0.6.1 основной линии (указанное в прошлом окне мониторинга расхождение версий сохраняется); в-третьих, появятся ли у apt-репозитория FlagCX первые отзывы об установке от реальных пользователей и когда будут закрыты пробелы у неактивированных бэкендов, таких как MetaX; в-четвёртых, будет ли отменён статус «непоставляемая» у коммуникационной библиотеки Kunlunxin (например, последующие версии XRE будут нести CCL и предоставят чисто C-вход), а также приведёт ли масштабное опытное производство гетерогенной системы инференса China Mobile Cloud к конкретным требованиям к уровню операторов/компилятора FlagOS.

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

Источники Результаты проверки в окне
GitHub org repos API (flagos-ai, 53 репозитория) 21 репозиторий с пушами в окне: FlagGems, build-infra, FlagGems-Experimental, FlagQuantum, FlagCX, FlagGems-vllm, Megatron-LM-FL, FlagTree, FlagBLAS, FlagGems-sglang, FlagDNN, FlagSparse, FlagScale, FlagPrism, vllm-plugin-FL, TransformerEngine-FL, FlagOS-Compressor, community, sglang-plugin-FL, docs, release-info; новых репозиториев нет; в GitHub Releases нет новых записей в окне
GitHub commit search (org, всего 150 записей, 5 страниц, sort=committer-date) Реально влито в ветку по умолчанию в 11 репозиториях: FlagGems-Experimental 54 / build-infra 33 / FlagGems 21 / FlagQuantum 15 / FlagCX 7 / FlagGems-vllm 6 / FlagTree 4 / FlagBLAS 4 / FlagGems-sglang 4 / FlagPrism 1 / FlagScale 1
Перепроверка per-repo commits (активные репозитории, не попавшие в search) Добавлено 23 записи: FlagSparse 10, Megatron-LM-FL 5, FlagDNN 4, vllm-plugin-FL 1, FlagOS-Compressor 1, TransformerEngine-FL 1, community 1; в трёх репозиториях sglang-plugin-FL, docs, release-info в ветке по умолчанию нет новых коммитов в окне (пуши веток/тегов)
Детали и патчи GitHub commit #847 (+2449 строк, упаковка .deb и критерии verify); #851 (+85/-25, публикация apt-репозитория и ограничения publish/verify); #865 (+147/-75, включение шести бэкендов и неопределённый символ devApiBackend); #866 (+32/-19, путь DTK/RCCL/BASH_ENV); #868 (+30/-11, причины непоставляемости Kunlunxin); #873 (+46, отсутствующий ключ deps_app и открытие 0.20.2); #875 (+20/-6, унификация plugin wheel и отказ от исправления пути T); #1155 (+17604/-1775, синхронизация кластера XPU и внутренний источник 5a664566); #156 (+103/-54, платформо-зависимый API устройств); FlagCX #578 (+5309/-1292, рефакторинг net adaptor)
Материалы релиза 2.2 репозитория community (прямое получение raw) release/2.2/release-2.2-rc1.yaml — всего 25 снимков компонентов; release/2.2/schedule_CN.md указывает заморозку функций 08-31, период тестирования и стабилизации 09-01~09-24, GA 09-28, критерии выпуска FEP и исключительный канал [URGENT]; единственное изменение манифеста в окне — #108 (FlagGems → v5.4.0-rc1.post2, тег указывает на голову ветки rc1 270bebe1, включает четыре исправления)
Google News RSS (18 групп поисковых запросов на китайском и английском, через прокси) Запросы по компонентам (FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/KernelGen/FlagOS-Robo/FlagQuantum/BAAI open source) — ноль совпадений, десятое подряд спокойное окно; среди совпадений по названиям организаций-участников сохранены три категории записей: гетерогенная система инференса China Mobile Cloud, выход Enflame на биржу, снятие ограничений с MetaX; регулярные статьи сообщества Zhiyuan и SEO-материалы игорной тематики отфильтрованы целиком
HN Algolia (FlagOS / FlagGems / FlagScale / FlagTree) Записи, возвращённые в окне, — общие технические обсуждения (GrapheneOS, DietPi v10.7, серия Show HN), не связаны с компонентами FlagOS, все отфильтрованы
Официальный сайт сообщества FlagOS (список версий и мероприятий) Последняя публикация с текстом и изображениями по-прежнему 08-28 (адаптация GLM-5.3-Flash Day0 под 9 чипов), новых версий в окне нет; в окне добавлены записи о мероприятиях: соревнование по оптимизации операторов SGLang для кросс-чиповых платформ (организаторы Zhongzhi FlagOS × IEEE), 09-10 сессия обмена опытом победителей конкурса задач по операторам с вознаграждением, 09-07 форум «Открытые AI-вычисления» на KubeCon Шанхай
Поиск Tavily/web (проверка дат на первоисточниках) Гетерогенная система инференса China Mobile Cloud: ITHome 09-13, Cailian Press/STAR Market Daily 09-13 (3 GPU-сервера Tianshu Zhixin + 3 стоечных нейроморфных машины, DeepSeek V4 Flash, повышение производительности и энергоэффективности более чем вдвое, снижение затрат более чем на 40%, 15 патентов + 6 свидетельств о регистрации ПО, мелкосерийное опытное производство); выход Enflame на биржу: Securities Times 09-11, Cailian Press
09-11 (цена размещения 142,18 юаня, открытие 410 юаней, закрытие 397 юаней, рыночная капитализация около 170,9 млрд юаней, оборачиваемость 76%, коэффициент удовлетворения заявок 0,0246%, выручка за 2026H1 1,120 млрд юаней, +279,08%); разблокировка акций MetaX: Sina Finance 09-13/09-14 (13,966 млн акций, 6,829 млрд юаней, около 75% акций в свободном обращении)    
  Проверенные, но не учтённые повторно записи Кластер на сто тысяч ускорителей JD Cloud и Moore Threads (исходное событие 09-09, включено в предыдущий выпуск; в окне — перепечатки и аналитические материалы); полугодовой отчёт MetaX за 2026 год (раскрыт 08-30, используется только как справочные данные)

Пояснение об ограничениях: в этом выпуске техническая информационная картина по-прежнему опирается на репозитории кода, отраслевые публикации используются лишь для сопоставления данных о капитале и продуктах участников; доступ к Google News RSS осуществляется через прокси, количество совпадений и полнота охвата зависят от ритма индексации агрегирующих источников, последовательные нулевые совпадения по запросам на уровне компонентов сохраняются уже десять окон подряд. Обновление текстовых и графических материалов на официальном сайте сообщества FlagOS отстаёт от действий в репозиториях (последние материалы от 08-28), информация о мероприятиях сообщества взята из списка мероприятий на его сайте. Корпоративные финансовые и рыночные данные взяты из открытых публикаций и дополнительно не перепроверялись.