Отчётный период: с 19 октября 2026 года (понедельник) по 23 октября (пятница), всего 5 рабочих дней.

Источники материалов: 5 выпусков ежедневного отчёта о динамике FlagOS (10-19 / 10-20 / 10-21 / 10-22 / 10-23, без пропусков). Выпуск 10-19 является утренним отчётом понедельника, окно мониторинга отсчитывается от контрольной точки предыдущего выпуска 10-16 06:00 (около 72 часов, включая полный ход «Конференции по открытым вычислениям в области ИИ 2026 и Технической конференции Zhongzhi FlagOS» 10-17 — 10-18 и анонс Liangzhi Cloud); четыре выпуска с 10-20 по 10-23 имеют 24-часовое окно, стыкуются встык, последний выпуск охватывает период с 10-22 06:00 до 10-23 06:00. Таким образом, фактический интервал отчёта — с 10-16 по 10-22, часть с 10-16 по 10-18 маркирована исходными датами.

Пояснение к составлению: охватывает пять измерений — версии и релизы, совместная разработка компонентов и кода, адаптация членов сообщества и производителей, экосистема и сообщество, наблюдения за тенденциями. Пять выпусков ежедневного отчёта в сумме по своим окнам дают 654 коммита и 661 мерж; если взять только четыре полных 24-часовых окна (объединённые дни 10-19 — 10-22), то это 507 коммитов и 522 мержа. Количество репозиториев с пушами в каждом выпуске составило 16, 16, 19, 22, 16 соответственно, общее число организационных репозиториев — 61. Версии и теги независимо перепроверены по атомарным источникам (releases.atom) репозиториев соответствующих компонентов, что согласуется с данными ежедневного отчёта.

1. Главные новости недели

  • Два дня конференции завершились, масштабные показатели версии 2.2 впервые разложены на проверяемые четыре уровня (10-17 ~ 10-18): на главном форуме заместитель директора и главный инженер института Zhiyuan (BAAI) Линь Юнхуа выступил с докладом «Zhongzhi FlagOS 2.2: от экономики токенов к физическому ИИ», где раскрыл: 21 производитель чипов, 35 моделей чипов, 9 крупных библиотек операторов общей сложностью 1454 оператора (на 890 больше по сравнению с предыдущей версией), рост производительности кросс-чиповых операторов на 27,6% (охватывает 10 моделей чипов), 264 контрибьютора кода (рост на 55% за период). В сообществе также более 730 активных контрибьюторов, более 100 организаций-участников, охват более 30 стран, более 55 800 разработчиков; с 2.1 до 2.2 объединённые PR выросли с 1890 до 4890, новые issue — с 420 до 1423, коммиты — с 5100 до 9730. В тот же день выпущены инструмент кросс-чиповой отладки и анализа производительности FlagPrism и унифицированный инструмент квантизации FlagOS-Compressor. Сообщается, что версия 2.2 выпущена 30 сентября, тогда как список репозиториев фактически зафиксирован с 09-28 по 09-29; расхождение в два дня в тексте рассматривается по правилам учёта репозиториев.

  • Liangzhi Cloud представлен публично, стек исполнения FlagOS вышел на гибридное планирование квантовых и классических вычислений (10-18): на подфоруме по интеграции квантовых и интеллектуальных вычислений прошёл этап «Анонс платформы Liangzhi Cloud»; Liangzhi Cloud (Quantum-AI Cloud) совместно представлен институтом Zhiyuan (BAAI) и Пекинским институтом квантовой информатики, на базе FlagOS Execution Stack поддерживает FlagQuantum, сопряжён с системой ИИ-вычислений «Цзюдин» и квантовым компьютером «QUAFU», реализуя гибридное планирование квантовых и классических заданий. На уровне кода это взаимно подтверждается: в примечаниях к релизу FlagQuantum v0.3.0 уже указано, что задачи Цзюдин и Quafu восстанавливаемы, а результаты многосхемных вычислений Quafu сохраняют порядок, что свидетельствует: на момент релиза цепочка отправки заданий, подтверждений и сохранения порядка результатов уже была внутри пакета, а не только интерфейсы фреймворка. Границы также чётко определены — не выполняется на квантовом оборудовании, не включает MCP server и agent runtime, выполнение на оборудовании обеспечивается стороной Цзюдин и QUAFU.

  • В цикле 2.3 впервые появился однодневный замкнутый цикл «от требования к доказательству» (10-21 ~ 10-22): 10-21 объединены два FEP — FEP-0140 определяет для vllm-plugin-FL три линии версий (0.24 дополняет пять компаний, 0.28 как основной ноябрьский релиз поддерживает десять компаний, 0.32 вводит пять компаний), FEP-0141 закрепляет матрицу десяти производителей для SGLang 0.5.18 и цель DeepSeek-V4 W8A8; 10-22 Hygon в тот же день в репозиториях vllm-plugin-FL и sglang-plugin-FL завершил выравнивание с vLLM 0.28.0 и SGLang 0.5.18 (в сумме 84 файла, чистый прирост около 5700 строк). От «внести матрицу в документ» до «первое практическое прохождение» прошёл всего один день — это самый быстрый замкнутый цикл от требования к доказательству в этом сезоне.

  • На стороне поставки за одну неделю завершён переход от шести к семи бэкендам, а коммуникационная библиотека переведена из особого случая в общее правило (10-16 ~ 10-22): build-infra сначала создал для FlagCX по одному самодостаточному builder на 22.04 для каждого из шести бэкендов — nvidia, hygon, cambricon, metax, enflame, iluvatar, — снизив нижнюю границу glibc с 2.38 до 2.35; 10-19 перенёс четыре wheel-пакета Ascend из runtime 24.04 в ту же форму и дополнил Tsingmicro и Enflame; 10-21 подключил Tsingmicro и Moore Threads в качестве пятого и шестого бэкендов FlagTree; 10-22 Kunlunxin стал седьмым бэкендом. В тот же день flagcx==0.14.0 расширен с закрепления только в двух строках nvidia до всех двадцати бэкендов, а также добавлен скрипт установки одним кликом, сводящий зависимости множества репозиториев в одну команду.

  • Четыре инфраструктурных направления закрыты в один день, производственная мощность организации переключается на «как тестировать, как устанавливать, как делиться» (10-20): optest получил первый содержательный коммит с момента создания репозитория (PR #1, 38 файлов), включающий 12 конфигураций бэкендов и аппаратные пробы для оборудования 13 производителей; FlagOps поднял пять CI action из FlagGems до уровня общих на уровне организации; build-infra добавил скрипт установки одним нажатием (1 файл, +308); Torch-FL и TransformerEngine-FL в один день внедрили единую точку входа FlagCICD с поддержкой уровней от L0 до L2, FlagScale дополнил выборочный платформенный CI. Тестирование, action, установка и точка входа CI — четыре линии в одном окне каждая завершила одно структурное слияние.

  • Квантовый стек продвинулся от проектного контракта к исполняемому пути (10-21 ~ 10-22): 10-21 FlagQuantum — 84 коммита, 34 слияния, динамические схемы понижены до «булева SSA-результата на последующих кубитах» и перенесены в Program IR, а точное понижение и восстановление закреплены как обязательное предварительное условие развёртывания; 10-22 — ещё 53 коммита, 20 слияний, M3 нейтральные атомы из двух проектных документов превращены в исполняемый путь — нативный фронтенд Rydberg на стороне Core (PR #700), динамика плана 1.7 на стороне Simulation (#707), обучение импульсам перемещения атомов на стороне Examples (#714, 40 шагов, 128 интервалов, безусловный RR по результатам измерений вырос с 0.0431 до 0.1228).

  • Объём слияний достиг недельного максимума, но основной прирост — тестовые контракты, а не операторы (10-22): 163 слияния за день — максимум за последнюю неделю, из них FlagGems — 91, что составляет 56% от всей организации; при этом объём коммитов снизился на 18%, число репозиториев с пушами сократилось на 27% — это переработка накопившегося, а не расширение. Основную линию тестирования в одиночку тянет lukatao — 61 коммит (67% от этого репозитория), за семь минут с 23:40 до 23:47 открыто 10 пакетных PR, варианты использования переведены от обёрточных функций к прямому вызову операторов или внедрению кандидатов. За всю неделю новые операторы KernelGen сосредоточены в трёх пакетных слияниях и зачистке разреженного семейства, доля действительно новых возможностей — менее двух десятых.

  • На стороне экосистемы появились три информационных прироста не из репозиториев (10-19 ~ 10-22): China.com опубликовал первую после конференции полную техническую разборку стека (дополнена семью количественными кейсами и групповыми свидетельствами); клиенты «Синьцзин бао» и «Бэйцзин жибао» сделали вторичное распространение в отраслевой версии, новый цитируемый тезис — «новая модель завершила адаптацию к 12 чипам за один день»; Pandaily дал систематический пересказ 2.2 на английском — первый полный материал, ориентированный на зарубежных читателей. Кроме того, опубликовано предварительное уведомление о планируемом утверждении проектов программы ускорения FlagOS «Чжунчжи» 2026 года от Пекинского комитета по науке и технологиям и администрации Чжунгуаньцунь, проект компании Kuangwei Zhixin (Cross Dimensions) «Развёртывание и демонстрационное применение AlohaMini — воплощённого интеллектуального робота на периферийных устройствах на базе FlagOS-Robo» вошёл в список — впервые во воплощённом направлении появился внешний проект с ограничениями по результатам поставки.

2. Динамика версий и релизов

Список тегов и Release на этой неделе (пекинское время)

Время Компонент Тег / версия Описание
10-18 10:36 FlagCX v0.15.0.dev0 Тег линии разработки; в том же окне слиты Hygon UIL и попроцессный adaptor bitcode
10-19 13:01 FlagTree 0.7.1a1+ascend3.5 Сборочная линия Ascend 3.5, первый alpha в линейке 0.7.1
10-20 20:11 FlagTree 0.7.1.dev1 Базовая линия переведена из a1 в dev1, продукт ночной сборки
10-20 20:12 FlagTree 0.7.1.dev1+ppu3.6 Сборочная линия PPU 3.6, с предыдущей записью разница в одну минуту
  • Четыре тега, три компонента, ни один не является официальной версией: все теги в окне этой недели относятся к линиям разработки или сборочным линиям под оборудование. Помимо трёх вышеуказанных компонентов, репозитории FlagGems, FlagBLAS, FlagDNN, Torch-FL, vllm-plugin-FL, sglang-plugin-FL, FlagOps, FlagScale, FlagAttention, FlagSparse и другие в окне не имеют новых Release. Это типичный промежуток между выпуском 2.2 30 сентября и GA 2.3 30 декабря — внешние версии молчат, линия артефактов активна.
  • Продолжение предыдущего выпуска: FlagQuantum v0.3.0 (10-16 13:34) и v0.3.1 (10-16 19:20) уже указаны в таблице тегов предыдущего еженедельного отчёта, в этом выпуске используются как базовая версия квантового стека и не учитываются повторно.

FlagTree: ритм релизов нарезан по версиям оборудования

  • Сосуществуют четыре линии сборки: в линии 0.7.1 сейчас есть четыре ветки аппаратной сборки — ascend3.5, iluvatar3.6, xpu3.6, ppu3.6; базовая линия переведена с a1 на dev1. В примечаниях к релизу указано только «pypi плюс номер версии» — это автоматизированная ночная сборка, а не функциональный релиз; чтобы определить, был ли релиз, нужно смотреть на строку сборки, а не на семантику номера версии.
  • Матрица бэкендов на этой неделе расширилась до семи строк: Tsingmicro TX8 (21.10, пятая), Moore Threads MUSA (21.10, шестая), Kunlunxin XPU (22.10, седьмая) последовательно подключены к линии сборки FlagTree и к строке ежедневной сборки. В строке Kunlunxin есть пять уникальных ограничений, включая десять предкомпилированных входных данных, кэш, сопоставляемый по имени каталога, и два пакета LLVM 19 с общим корнем tarball, выбор фронтенда через переменные окружения, точное закрепление pybind11 на 3.0.1 (3.0.4 приводит к SIGSEGV диспетчера), а также отсутствие параметра сборки Release (вендорный wheel сам по себе является rel-with-asserts).
  • На стороне компилятора прирост функций невелик и сконцентрирован: AMD RDNA 21.10 продвинулась от декодирования одним крупным кооперативным ядром (M=1) к предзаполнению (M>1, PR #1365, 66 файлов); микрокернел RDNA предзаполнения WMMA GEMM по сравнению с циклом GEMV при M>1 ускоряется в 10–30 раз; на стороне декодирования split-K снижает lm_head с 17.0 до 14.9 мс/токен, а послойное широкое проецирование — с 14.9 до 10.5 мс/токен; MUSA добавляет персистентность кэша TME для каждой копии (#1385); бэкенд SpaceMiT RISC-V добавляет eDSL для голого ядра smt_rvisa и выводит из эксплуатации собственный диалект TLE (#1381, 16.10, относится к окну понедельника).

FlagGems: 5.4 — официальная линия, в линии разработки 5.5 нового нет

  • Критерии официальной линии не изменились: 5.4 по-прежнему является текущей официальной линией (релиз 28.09); после открытия линии 5.5.0.dev0 12.10 на этой неделе новых тегов не было, метаданные версии пакета по-прежнему показывают 0.1.0 — в записи приёмки Hygon vLLM 0.28 доказательство строится способом «установлено 1944 исходных файла, выполнено пофайловое сравнение с коммитом e12a220, метаданные версии недостоверны»; такой подход, когда содержимое заменяет метаданные VCS, на этой неделе снова появился.
  • Покрытие операторов выходит на финишную прямую: на этой неделе KernelGen тремя партиями влил 14 операторов Nvidia — все это граничные операторы для псевдонимов, представлений и разреженной семантики. Партия 10:43 — копирование, разреженное конструирование и конструирование вложенных тензорных таблиц (ger, sparse_bsc_tensor); партия 15:23 — представления значений и форм, а также дополнены смещения хранения вложенных тензоров и взаимное преобразование разреженных индексов csr в coo (_values_copy, _shape_as_tensor); партия 22:23 — перестановка измерений и комплексные представления (swapdims, moveaxis, view_as_complex_copy). На стороне проверки в ночь на 19.10 сразу открыто около 20 заявок разреженного семейства (серия _sparse_mm, copy_sparse_to_sparse_, взаимное преобразование индексов coo и csr и т. д.).
  • Предварительный сигнал релиза находится в build-infra: wheel vllm-plugin-native 21.10 дополнен четырьмя типами бэкендов — nvidia, metax, kunlunxin, hygon — и зарегистрирован для релиза; 22.10 для всех бэкендов единообразно закреплён flagcx==0.14.0 — всё это подготовка артефактов перед официальным релизом 2.3.

3. Совместная разработка компонентов и кода

Организационный ритм: за пять периодов накоплено 654 коммита и 661 слияние

Период Окно (пекинское время) Репозитории с пушами Коммиты Слияния На проверке (обновлено в окне)
19.10 16.10 06:00 ~ 19.10 06:00 (72 часа) 16 147 139 239
20.10 19.10 06:00 ~ 20.10 06:00 16 93 88 180
21.10 20.10 06:00 ~ 21.10 06:00 19 115 120 195
22.10 21.10 06:00 ~ 22.10 06:00 22 164 151 154
23.10 22.10 06:00 ~ 23.10 06:00 16 135 163 183
Итого — — 654 661 —
  • Суммарное количество влитых коммитов по субрепозиториям (по данным раскрытия в ежедневных отчётах за соответствующие периоды): FlagGems 290 (43,9%), build-infra 96 (14,5%), FlagQuantum 82 (12,4%), Torch-FL 53 (8,0%), FlagTree 25, FlagGems-vllm 21, vllm-plugin-FL 18, FlagGems-sglang 15, FlagBLAS 6, FlagCX 5, optest 5, FlagTrain 5, FlagGems-Experimental 3, sglang-plugin-FL 3, FlagOps 2, FlagAttention 2, community 2, FlagOS-Compressor 2, FlagSparse и TransformerEngine-FL по 1; кроме того, FlagCV, Trident, .github, flir по 1. В некоторых периодах статистика по субрепозиториям велась только по первым 100 объединённым PR, к субрепозиториям отнесено в сумме 641 коммит, разница в 20 коммитов приходится на неразвёрнутые хвостовые репозитории.
  • Структура двух движков не изменилась: FlagGems и FlagQuantum в сумме дают 56,3% влитых коммитов; с добавлением build-infra и Torch-FL четыре репозитория дают 79%. Картина в течение недели: «с понедельника по среду рост инфраструктуры и квантового стека, с четверга по пятницу сосредоточенная разгрузка очереди FlagGems».
  • Высокая концентрация выработки одного человека: lukatao в FlagGems по дате слияния в сумме дал 119 коммитов (20.10 — двадцать три, 21.10 — тридцать пять, 22.10 — шестьдесят один), все — исправления тестов и эталонных реализаций; tengqm полностью закрыл build-infra 35 коммитами (20.10 — семь, 21.10 — пятнадцать, 22.10 — тринадцать); lvyufeng взял на себя Torch-FL в части MPS и платформенной стороны; все влитые коммиты FlagQuantum выполнены одним и тем же аккаунтом.

FlagGems (влито 290 коммитов): тестовые контракты становятся главной линией

  • Три раунда отката и перестройки: PR #7361 от 20.10 сначала откатил предыдущие изменения общей тестовой инфраструктуры (17 файлов, +599/−1040), перенеся обработку совместимости в тесты каждого оператора; затем 22 исправления были выполнены в этом же направлении — снимки входных данных в режиме эталонных значений CPU, геометрия представлений тензоров, сравнение значений для комплексных и половинной точности, разреженные конструкции и преобразования, исполнимость сгенерированных тест-кейсов, границы утверждений, нормализация маркеров pytest. Это инженерная коррекция по принципу «сначала признать, что общее решение не работает, затем дополнить каждый оператор по отдельности».
  • Три серии переработки тест-кейсов от lukatao: 21.10 тридцать пять коммитов перевели сгенерированные тест-кейсы в кросс-бэкендовую исполнимость (split и squeeze, adjoint и mH и mT, as_strided, moveaxis и reshape_as и swapaxes, представления permutation, преобразования целочисленных и половинной точности), причём #7425–#7440 — это шестнадцать коммитов подряд; 22.10 ещё 61 коммит перевёл переопределения foreach на «прямую маршрутизацию», партии 01–09, а последние девять наборов операторов перевёл на общий API кандидатов, то есть «какую реализацию тестировать» из неявного стало явным.
  • Управление пропусками на бэкендах начинает фиксировать причины: пропуски на Ascend и Moore Threads поштучно ограничены входными областями (linalg_vander с комплексным входом, logdet с комплексными, row_stack_out с форматом памяти, trapz с complex32, orgqr с нулевыми столбцами на MUSA, серия qint32, проверка Hygon cuDNN), а в ранние часы 23.10 подряд влиты четыре коммита переноса разреженных наборов (кросс-бэкендовая переносимость разреженного log-softmax, прошивка валидатора разреженности и вызовы прямых эталонных кандидатов, валидатор сжатой разреженности, общий конструктор разреженных блоков).
  • Два крупных коммита со стороны производителей: массовое обновление от Enflame #7077 (26 файлов, +3520/−511, в заголовке только «update from enflame 20261013», без постатейной детализации); фьюзинг MoE от Kunlunxin #7107 (13 файлов), дополнены три варианта fused_experts и dispatch_fused_moe_kernel, агрегированный балл 1,324–1,329, при этом заявлено, что базовой линией является альтернативная реализация, а 0,626 у dispatch_fused_moe_kernel не достигает нормы.
  • Линия оптимизации Kunlunxin: 20.10 — девять коммитов, 21.10 — семнадцать, 22.10 — тринадцать; переход от дописывания реализаций к установке порогов по точности и форме — w8a8_block_fp8_matmul получил гейтинг возможностей FP8, fp64 и grouped-MM переведены на пропуск по возможностям с указанием причин, однослойный блок GRU переведён на плоский одномерный kernel, что подняло агрегированный балл с 0,4217 до 0,8253, путь sgn с большим numel переведён на дешёвое основное тело с настраиваемым одномерным тайлом.

FlagQuantum (влито 82 коммита): от контракта к коду, затем от кода к отказу

  • Динамические схемы в IR (21.10): PR #681 определяет типизированный контракт динамического Program IR; #683 понижает измерения средних схем до «последующих кубитов плюс булевых SSA-результатов», reset — до явных последующих кубитов, конъюнкция и дизъюнкция отображаются в каноническую DNF над активными булевыми значениями, причём восстановление выполняется только если результат понижения дословно совпадает с полным графом функций; #694 делает точное понижение и восстановление обязательным предусловием динамического развёртывания — непроверенная программа останавливается до вызова любого provider.
  • Нейтральные атомы M3: от контракта к запуску (22.10): На стороне Core #700 даёт нативному управлению Ридбергом фронтенд прямо на ProgramRecord (RydbergProgram предоставляет три действия — move, pulse, to_ir, — и явно указывает, что «управляемая позиция не означает физического присутствия»); на стороне Simulation #707 проводит нативную программу Ридберга через существующий план Lindblad, plan 1.7 запечатан ровно семью внешними полями; на стороне Examples #714 обучает две амплитуды импульсов и заставляет пару атомов двигаться — на 40 шагах и 128 интервалах измеренный безусловный RR растёт с 0.0431 до 0.1228, RR при условии выживания 0.1500, RR выбора no-flag 0.1439.
  • Половина объёма слияний уходит на отклонение и удаление: #701 от 22.10 заставляет нативную физическую программу при упаковке единообразно выбрасывать CapabilityError вместо AttributeError; #705 согласно предложению 082 напрямую удаляет NeutralAtomProvider и два Remote-экспорта, никогда не имевшие внешнего сервиса, — без псевдонимов и без пустых оболочек; #716 предлагает предложение 083, определяющее примитив Runtime sample_terminal, и в конце примера печатает «proposed, not implemented». Такие действия не добавляют возможностей, но определяют, будет ли граница M3 достоверной.
  • Дополнение цепочки визуализации и цитируемости: 21.10 #668 добавляет ленивый бэкенд LaTeX и представление гибридной модели «кодировщик — схема — измерительная головка» (43 файла, +14311), Notebook в приоритете показывает SVG; #684 добавляет CITATION.cff (версия 0.3.1, дата выпуска 2026-10-16, Apache-2.0); #687 инвентаризирует переиспользуемые возможности нейтральных атомов и недостающие контракты, приводя независимый числовой ориентир: физическое выживание 0.8187, безусловный RR 0.4094, RR при условии выживания 0.5.
  • Расширение вычислительных мощностей: 20.10 #653 и #661 переносят CPU-набор на восемь runner’ов A800 и автоматически запускают GPU-тесты, длинные задачи переводятся на параллельный режим — способ продвижения отныне крупномасштабная проверка согласованности, а не развёртывание функциональности.

build-infra (слито 96 коммитов): «N бэкендов на M типов артефактов» сжимается в одну строку

  • Формируется матрица builder’ов: каталог base/ за неделю расширяется с шести до девяти вендоров и семнадцати базовых образов — nvidia (cuda12.8 / 13.3), ascend (cann8.5.0 / 9.0.0, включая 910c), cambricon (neuware4.4.3 / 4.7.2), enflame (tops1.9.10 / 1.10.6), hygon (dtk26.04), iluvatar (corex4.4.0 / 4.5.0), metax (maca3.7.2.1 / 3.8.1.3), sunrise (tangrt1.2.0), tsingmicro (tsm260610).
  • Закрытие 22.04 в FlagCX: с 16.10 по 18.10 для шести бэкендов заводится по одному самодостаточному builder’у, каждый с ubuntu:22.04 в качестве нижней границы glibc, с предустановленным в образ вендорским SDK и следом в wheel-info; #1407 добавляет переключатель --no-bitcode уровня dispatch, чтобы тег v0.14.0, будучи раньше bindings/ir, не падал с ошибкой напрямую на не-nvidia adaptor’ах.
  • Строка сборки FlagTree: builder’ы объединяются из «двух workflow, делающих одно дело» в одну матрицу, одна строка backends.yaml несёт Containerfile, репозиторий образов, метку runner’а, бюджет диска и приёмочные утверждения. Три строки Tsingmicro, Moore Threads и Kunlunxin реализуются по одному шаблону, различие лишь в предкомпилированном дереве и путях разрешения инструментальной цепочки.
  • Схождение путей установки: 20.10 #1425 добавляет скрипт установки одной командой (1 файл, +308), впервые сводя процесс установки «множества репозиториев, множества наборов зависимостей» к одной команде; #1435 восстанавливает нативные колёса расширения vllm для бэкенда распространения CUDA и указывает на подводный камень: PEP 440 игнорирует метки сборки, и короткое закрепление установит не тот бэкенд.
  • Документация сборки становится сайтом: двенадцать коммитов от 22.10 (#1462–#1470) за пять часов подряд сливают записи проектирования и страницы сайта восьми компонентов — vllm-plugin-FL, FlagTree, FlagCX, FlagGems, FlagLibs, Megatron, SGLang, verl; это первый раз в сезоне, когда проектирование сборки оформлено как индексируемый контент.

Torch-FL (слито 53 коммита): после расширения платформенной поверхности — переход к поэлементному восполнению

  • Линия MPS завершила основную часть: с 10-19 по 10-21 за три дня влито восемь коммитов, связанных с MPS — нативные mm и bmm в категорию gemm MPSGraph, нативизация softmax, поэлементных neg и pow, кэширование скомпилированных планов MPSGraph, поддержание жизни поставленной в очередь работы и нативный masked_fill, нативные ядра MPSGraph для Qwen3.5, сбор продвинутого индексирования на Metal; #566 от 10-20 вошёл в репозиторий с 69 файлами +22929/−236, CI использует размещённый на GitHub runner Apple Silicon arm64 и явно заявляет, что «у macOS runner на x86_64 нет устройства Metal, провал проверки окружения — ожидаемый результат».
  • Три коммита Tsingmicro: torch.compile для TX8 (#541, 14 файлов, автор явно указывает, что запрос свойств устройства может возвращать только константы, а не измеренные значения оборудования), хост-сторонние ядра случайных чисел (#604), временная шкала устройства в torch.profiler (#630, DeviceTracer на основе rocprofiler-sdk, измерено на TX8110).
  • Два серьёзных исправления корректности многокарточности: CrossDeviceMemcpy у Kunlunxin ранее вызывал xpu_memcpy с семантикой одной карты, при передаче указателей двух карт возвращал −801 и целевая карта не записывалась, копирование между любыми картами молча не работало; 10-22 переведено на xpu_memcpy_peer (#634); undefined symbol: cudaMemcpy в liblaunch_shared.so разрешается только после dlopen загрузчика Triton, поэтому CUDA-совместимый рантайм Kunlunxin загружается заранее (#632). Эти два коммита не дают никаких цифр производительности, но заставляют пересчитать выводы всех прежних экспериментов с несколькими картами.
  • CI и платформенная линия: общая CI-линия BI-V150 (#569, 24 файла, разрешено сохранять известные падения при начальном запуске для завершения bring-up), единая точка входа FlagCICD и уровни L0–L2 (#599), AGENTS.md назначен единственным руководством для агентов (#601), линия стабильной ветки 2.9 для Kunlunxin P800 (#273), отчёт о результатах платформенного pytest в FlagCICD (#542 и #577).

FlagTree (влито 25 коммитов): матрица раскладывается по клеткам, языковой уровень ждёт стабилизации

  • Почти все вливания FlagTree на этой неделе относятся к трёхмерной матрице «бэкенд × версия × рабочий процесс»: базовый уровень FlagGems и рабочий процесс тестирования enflame3.6-gcu300 от Enflame, бенчмарк vLLM от Enflame в рабочем процессе, базовый уровень и тесты amd3.6 от AMD, поставка и исправления Ascend 3.5 py312, обновление codeowner ветки triton_v3.5.x, рабочий процесс бенчмарка vllm для XPU3.6.
  • Единственное структурное изменение — предзаполнение AMD: #1364 от 10-21 добавляет в FlagMega две цели amd-gfx1100 (W7900) и amd-gfx1201 (R9700), позволяя bf16 Qwen3-1.7B выполнять декодирование на RDNA одним скооперированным крупным ядром; чтобы избежать тупика на барьере из-за невозможности совместного размещения 128 рабочих групп, верхний предел варпов на вычисление на блок снижен до 4; #1365 от 10-22 дополнительно добавляет предзаполнение для M>1 и правило «предзаполнение выдаёт логиты только последнего token».
  • Интерфейс с RISC-V: smt_rvisa позволяет автору явно задавать SEW, VL, разбиение на блоки и выбор инструкций, ядро понижается через C++ builder API, есть также путь прямого вывода LLVM с полным пропуском spine-opt; бэкенд больше не хранит приватную копию диалекта TLE, а использует общий third_party/tle. Подобные изменения не попадают ни в какие внешние формулировки, но определяют, сможет ли бэкенд RVV пройти путь от «работает» до «давит производительность».

Стек инференса: vllm-plugin-FL (18), FlagGems-vllm (21), FlagGems-sglang (15), sglang-plugin-FL (3)

  • Согласование версий — главная тема недели: на стороне vllm-plugin-FL 19.10 бэкенд Damo XuanTie обновлён до vLLM 0.28.0, 22.10 Hygon зафиксирован на 0.28.0 (дистрибутив 0.28.0+empty, прогоны в режимах графа eager и FULL_AND_PIECEWISE, TP=2, максимальная длина модели 4096, использование памяти 0.85); на стороне sglang-plugin-FL 21.10 Ascend 910C отдельно адаптирован к 0.5.18 (67 файлов, приёмка включает проверку образа на четырёхкарточной машине), 22.10 Hygon BW1000 обновлён до 0.5.18 (65 файлов, включая TP2 на одной машине и TP4/PP1, TP2/PP2 на двух физических узлах). Одноимённые записи для MetaX, Tsingmicro, Enflame и Kunlunxin всё ещё на рассмотрении или не открыты.
  • Графовый режим охватил два китайских бэкенда: графовый режим Xiwang Sunrise и Enflame GCU300 (19.10, inductor плюс cudagraph) влит в один день; путь CUDA Graph на стороне vLLM больше не проверяется только на Ascend и Kunlunxin; 21.10 Ascend дополнен исполнением графа декодирования и адаптирован к текстовому и графическому выводу Qwen3.6-27B и 35B-A3B (26 файлов, +2513).
  • Модельная сторона опережает публичный релиз: публичные операторы GLM-5.3 Flash (#900) в FlagGems-vllm и три класса операторов HC / PLE / sparse QSA для Qwen4 (#896) — это названия новых архитектур, появившиеся только в октябре; операторы выходят в публичное пространство раньше моделей; затем #977 добавляет конфигурацию TP=2 для фьюзинг- MoE от MetaX, на C550 среднее ускорение по 14 значениям M составило 1.065 раза.
  • Соревнование впервые стало поставщиком основного репозитория: в FlagGems-sglang 20.10 десять коммитов соревнования влиты одним и тем же мейнтейнером в течение 40 минут (дорожка 1 tiny-k-gemm, pack-topk-ids, moe-topk-sum, indexed-scale-shift и другие), в комплекте #163 — снимок бенчмарка одним коммитом на +28940; #204 fused_pack_qkv и #201 fused_sigmoid_mul от 22.10 показывают, что результаты соревнования уже вошли в основную ветку, а не остались в виде коммитов.

Прочие компоненты и интеграционная инфраструктура

  • FlagBLAS (6 коммитов): Hygon gfx936 GEMM с шестью точностями (#151, от sgemm до zgemm, +7060/−127, dgemm использует точечное произведение fp64 MMAC и зависит от поддержки fp64 MMAC в FlagTree) и поддержка L1 (#149); 10-22 добавлены оптимизация L1 для Iluvatar CoreX (#153) и GEMM для Moore Threads (#152). Дополнение точностей в BLAS выявило пробел в возможностях на стороне компилятора — это одно из практических подтверждений кросс-репозиторной координации на этой неделе.
  • FlagCX (5 коммитов): включение Hygon Device API и HIP-бэкенда с единым IR (#643), генерация bitcode устройства по adaptor вместо жёстко заданного nvidia (#668), тег v0.15.0.dev0, многосегментные окна VMM (#658, 42 файла +7667, для CUDA, Hygon DU, MetaX и PPU добавлены многосегментные обратные вызовы, обмен сегментированных файловых дескрипторов через ограниченные дескрипторы, публикация окна только после коллективного успеха), унификация маршрутизации платформ и CI (#665).
  • FlagTrain (5 коммитов): бэкенд Moore Threads и два оператора (#20), поддержка Megatron и TransformerEngine в KMCompiler (#22), blocked_flash (Iluvatar CoreX) и mixed_moe_gemm (#23, #24), multi_tensor_lion (четыре бэкенда) и quick_gelu (#16, #26). Первая версия документации этого репозитория появилась только 10-15 — это самый молодой репозиторий операторов на данный момент.
  • Разреженность, внимание и квантизация: в FlagSparse влита оптимизация MUSA (#113, из ветки внешнего контрибьютора NCIC-AlphaSparse); в FlagAttention около 40 небольших хост-операторов и синхронизаций .item() в prefill разреженного внимания MiniMax M3 с kv-outer заменены на два Triton-ядра, сборка ускорена в 1,5–2,5 раза, реализована бессинхронизационная диспетчеризация и полный захват графа (#107); FlagOS-Compressor поддерживает экспорт только линейных слоёв в INT8 для DeepSeek V4.1 и MiMo V2.5 (#10) и конвертацию исходных контрольных точек MXFP8 и NVFP4 (#11, пройдено 143 теста).
  • optest (5 коммитов) и FlagOps (2 коммита): optest превратился из набора скриптов в устанавливаемый wheel (#4), переведён на layout src (#5), предоставлены console commands (#6), в имени задания CI отображаются репозиторий и бэкенд (#2); FlagOps принял пять action из FlagGems (#15), после чего на стороне FlagGems завершена миграция локальных action в общие action (#7346, #7416).
  • Новые и экспериментальные репозитории: FlagCV (создан 10-14) в ночь на 10-18 получил первый коммит, а ранним утром 10-19 влит PR #1 со скелетом — интерфейс согласован с OpenCV (две группы заголовочных файлов: core и imgproc), много-бэкендная структура повторяет FlagDNN, ядра написаны на Triton, в backends/ сразу развёрнуты шесть бэкендов: nvidia, thead, ascend, hygon, iluvatar, mthreads, но работающих операторов пока нет; Trident — созданный 10-12 экспериментальный слой-мост (Python-функции в стиле Triton или Torch компилируются в MLIR и LLVM, затем исполняются через tvm_ffi), на этой неделе в #3 дополнены тесты нескольких операторов ATen; в flir на рассмотрении #83 добавляет диалект TensorView и представления tile.load и tile.store — это содержательное действие в направлении CommonIR.

4. Членские организации и адаптация производителей

  • Kunlunxin: на этой неделе бэкенд с самой высокой инженерной плотностью, причём он не входит в публичный список членов. К нему можно отнести около 40 слитых коммитов (девять в день слияния 10-20, восемнадцать 10-21, тринадцать 10-22; 10-19 в окне отдельно не подсчитывался), содержание охватывает три слоя: операторы, сборку и среду исполнения. На стороне операторов работа перешла от добавления реализаций к установке порогов по точности и форме (гейтинг возможностей FP8, пропуск fp64 и grouped-MM по возможностям, агрегированный счёт плоского одномерного kernel GRU вырос с 0.4217 до 0.8253, три оператора fused MoE — с 1.324 до 1.329); на стороне сборки бэкенд стал седьмым бэкендом FlagTree; на стороне среды исполнения устранены два серьёзных дефекта — тихий отказ межкарточного копирования и порядок предзагрузки. Риск на стороне операторов: большинство изменений — это другой tile или фьюзинг того же оператора, единого порога производительности нет, а агрегированный счёт из-за замены базовой линии несопоставим между производителями.
  • Hygon: на этой неделе единственный производитель, который одновременно завершил выравнивание upstream-версий в двух репозиториях плагинов инференса. vLLM 0.28.0 и SGLang 0.5.18 слиты в один день (в сумме 84 файла, чистый прирост около 5700 строк), среда проверки — кластер BW1000 с одной картой на 64 GiB, на стороне vLLM выпускной пакет 0.28.0+empty, на стороне SGLang физические два узла TP4/PP1 и TP2/PP2, а также исправлен согласованный выход при конвейерном параллелизме. В комплекте — GEMM шести точностей в FlagBLAS и прошивка обратного прохода разреженного суммирования FP8 в L1, FlagGems, одно исправление hygon в FlagDNN. Его переносимую ценность составляет оформление процесса обновления empty-бэкенда в шаблон с таблицей версий.
  • Tsingmicro: на этой неделе восполнялись исключительно пробелы инфраструктуры, а не покрытие операторов — torch.compile на TX8 (#541, свойства устройства могут возвращать только константы), kernel генератора случайных чисел на стороне хоста (#604), временная шкала устройства в torch.profiler (#630, проверено на TX8110, одновременно закреплён флаг сборки производителя), подключение строки сборки FlagTree и привязка к дневной линии (#1436, #1440). Порядок стоит зафиксировать: сначала возможность собирать в CI, затем воспроизводимость случайности, затем возможность видеть производительность и лишь в конце — оптимизация.
  • Ascend: на этой неделе основная линия — версии и графовое исполнение в двух репозиториях плагинов — графовое исполнение полного декодирования vLLM 0.24 с текстовым и графическим инференсом Qwen3.6-27B и 35B-A3B (#606), отдельная адаптация 910C в SGLang 0.5.18 (#131), W8A16 FP8 TopK (#6030), гейтинг matmul по возможностям fp32 в зависимости от SoC (#616), перенос четырёх wheel-пакетов в builder 22.04 (build-infra #1414, нижняя граница glibc снижена с 2.38 до 2.35). На стороне тестов более десятка коммитов — конструирование входов FP8, ошибки tile block и справочная документация, по-прежнему преобладают исправления.
  • Moore Threads: MUSA стал шестым бэкендом FlagTree и вошёл в повседневную линию (#1449, #1456); локальные бинарники при изменении ref должны задаваться явно; в FlagTree добавлена персистентность кэша TME для каждого копирования (#1385); в FlagBLAS добавлена реализация GEMM (#152); на стороне FlagGems вход комплексного cholesky_solve перенесён в конструирование на CPU, слита MUSA-специфичная оптимизация moe_load_balance_loss. Пять пропусков тестов сосредоточены на ограничениях области входов этого бэкенда, что показывает: поверхность отказов по-прежнему связана в основном с «неподдерживаемым входом», а не с ошибками реализации.
  • Enflame: действия этой недели охватывают пять звеньев — базовая линия, бенчмарк, упаковка, утверждения, графовый режим: базовая линия enflame3.6-gcu300 и рабочий процесс тестирования, бенчмарк vLLM в рабочем процессе, проверка builder переведена на data-driven подход, предустановка toolkit deb в образ, слияние графового режима GCU300; пакетное обновление производителя в FlagGems #7077 (26 файлов +3520/−511) вошло в основную ветку за один раз, но в заголовке указана только дата, без постатейной детализации. На стороне FlagTree из-за эпизодической ошибки шины отключён тест-кейс 02-sparse-mla и обновлены параметры vllm benchmark; проблемы стабильности остаются на уровне тест-кейсов.
  • Iluvatar CoreX: обе стороны — CI и сборка — укомплектованы: слита общая строка CI для BI-V150 (#569, CoreX 4.5.0), независимая среда исполнения iluvatar позволяет wheel-пакетам линковаться с CPU-версией torch (#593), build-infra обновил pin до 22.04 и перевыпустил версию; на стороне кода по-прежнему преобладает прямая отправка в master (четыре коммита в FlagDNN плюс три, без процесса PR), эквивалентная базовая линия производительности (equivalent_baseline.cpp и др., +8157) — самый существенный результат этого репозитория за неделю. Нормализация процесса отстаёт от Torch-FL и FlagQuantum.
  • MetaX: усилия этой недели сосредоточены на профиле производительности и находящихся на рассмотрении парных схемах развёртывания — оптимизированный профиль MiniMax M3 BF16 на двух узлах C550, TP16 (#540, открыт 09-18, всё ещё обновлялся 10-18) и реализации Kimi K3 MXFP4 и BF16 на четырёх узлах C550, TP8 и PP4 (#607, открыт 10-19, работает на ветке совместимости с vLLM 0.28); уже слиты конфигурация fused MoE TP=2 в FlagGems-vllm (#977, на C550 среднее по 14 значениям M — 1.065 раза, а также исправлен выход конфигурации разделяемой памяти за границы при M≥4096) и честная маркировка нативных wheel-пакетов metax по платформам в build-infra.
  • Damо Academy XuanTie (включая Zhenwu PPU): FlagBLAS дополнен GEMM четырёх точностей для Zhenwu PPU и

Добавлены четыре варианта раскладки NN/TN/NT/TT (#148, множественный GEMM с транспонированием level3); FlagGems исправляет взаимную блокировку барьера GRU на бэкенде (#7203); FlagGems-vllm добавляет W8A8 block INT8 матричное умножение (#954, 9 файлов +1493, включая конфигурацию настройки и подключение автоматической настройки) и исправляет целочисленное накопление W8A8 MoE; vllm-plugin-FL обновлён до vLLM 0.28.0 (#574). Четыре линии соответствуют базовой библиотеке, корректности параллелизма, квантованным операторам и сопровождению версий.

  • Xiwang и SpaceMiT: Xiwang (sunrise) 10-19 выпустил самодостаточный builder для 22.04 и зафиксировал колёса для перевыпуска как 22.04-clean, 10-19 слит режим графов (#569), проба вошла в унифицированную инфраструктуру optest; smt_rvisa от SpaceMiT (FlagTree #1381) — это первый выход направления RISC-V AI на уровень языковых расширений компилятора, и вместе с рассматриваемым элементом FlagGems на том же бэкенде он составляет все действия линии RISC-V на этой неделе.
  • Horizon Robotics и Cambricon: на этой неделе у обеих компаний в организациях не было ни пушей, ни слияний в эксклюзивные репозитории, причём 10-21 и 10-22 два окна подряд прошли в тишине. Ежедневный отчёт уже два дня подряд отмечает это как пробел; если на следующей неделе действий по-прежнему не будет, это следует вынести отдельным пунктом как риск.

5. Экосистема и сообщество

  • Конференция и постконференционные материалы образовали три волны распространения (10-17 ~ 10-22): 10-18 главный форум впервые освещён репортажем с места DOIT; 10-19 Zhonghua Wang опубликовал первую постконференционную разборку полного технологического стека, организованную в пять блоков — «операторы и компиляция, вспомогательная разработка, плагины и квантизация, Token-сервисы,端侧 и платформа», — дополнив ранее не освещённые факты о квантизации: KernelGen уже поддерживает девять чипов, в этом квартале дополнительно сгенерировано 765 операторов, из которых 416 прошли проверку точности как минимум на пяти отечественных чипах и достигли более 80% производительности нативных операторов, все 40 операторов FlagGems-SGLang прошли проверку на NVIDIA, а после W8A8 для Qwen3.5-397B-A17B файл модели уменьшился с 751.41GB до 382.45GB (снижение на 49.1%), при этом GPQA-Diamond сохранился на уровне 84.85%; 10-20 Xinjing Bao и клиент Beijing Daily выпустили вторую волну распространения в отраслевой версии с новой цитируемой формулировкой «новая модель завершила адаптацию к 12 чипам за один день»; 10-22 Pandaily опубликовал систематический пересказ на английском языке и впервые обнародовал, что задержка первого токена при длинном вводе для China Telecom Xing4.0-29B-A4B снизилась на 19.87% по сравнению с нативными операторами.
  • Границы Liangzhiyun описаны яснее, чем в большинстве рекламных материалов: FlagOS отвечает за стек исполнения и планирование, Quantum Academy — за аппаратное обеспечение и облако; v0.3.0 и 0.3.1 явно указывают, что не работают на квантовом оборудовании и не включают MCP server и agent runtime (адаптер MCP поставляется отдельным пакетом). Внешние точки наблюдения — когда Liangzhiyun откроется для внешнего доступа и будут ли бэкенды Hygon и Moore Threads для FlagQuantum включены в облачное планирование.
  • Управленческий контур впервые зафиксировал объекты приёмки 2.3: FEP-0140 (три версионные линейки vLLM) и FEP-0141 (SGLang 0.5.18, десять производителей) влиты 10-21, тестирование переиспользует рабочий процесс 2.2, целевая версия плагина при необходимости устанавливается из исходников внутри образов производителей или FlagOS; приёмка включает установку, плотный и MoE-инференс текста и изображений, производительность, параллелизм и 24-часовую стабильность. Тогда же .github добавил на китайскую и английскую версии главной страницы организации вход с приглашением в Slack, решив проблему новых разработчиков, не находящих существующее приглашение.
  • В направлении具身 появился первый внешний проект с осязаемыми результатами (10-22): Пекинская municipal комиссия по науке и технологиям и администрация Чжунгуаньцюня опубликовали предварительное объявление о планируемых проектах по направлениям «центральное руководство местным развитием» и «инновации в области нового поколения информационно-коммуникационных технологий» на 2026 год в рамках программы ускорения Zhongzhi FlagOS; отобран проект Kuowei Zhixin «Развёртывание и демонстрационное применение端侧具身-интеллектуального робота AlohaMini на базе FlagOS-Robo». Приёмка включает адаптацию обучения具身-моделей и развёртывание инференса,端侧-применение на отечественных чипах, тестирование согласованности точности инференса на нескольких чипах, а также协同具身-модели, малого мозга управления движением и управления телом. Это третий внешний проект с осязаемыми ограничениями после матрицы FEP и соревнований.
  • Событие влияния на сообщество (10-19, обзорный материал опубликован 10-21): Triton Developer Conference 2026 прошла в Сан-Хосе, присутствовало более 500 разработчиков; KernelGen команды FlagOS стал единственным проектом на площадке, систематически демонстрирующим «Agent автоматической генерации операторов для множества чипов», причём построенным на компиляционной инфраструктуре FlagTree; в рамках методики 2.2 количество автоматически сгенерированных операторов на 8 чипах составило от 77 до 551, диапазон сравнения производительности — от 2.58 до 38.33 раз (в оригинале указано, что это условия тестирования каждого докладчика, и не следует экстраполировать между проектами).
  • Соревнования и работа с разработчиками: трек 1 соревнования по оптимизации кросс-чиповых операторов SGLang, размещённого на сайте CSDN FlagOS, уже начал выдавать в основной репозиторий результаты, пригодные к слиянию, но ритм остаётся пакетным, а не распределённым; 10-22 добавлена прямая трансляция круглого стола с вузами (внедрение преподавания в рамках программы развития преподавательских кадров глобальных открытых AI-вычислений) — это мероприятие сообщества, а не технический релиз.
  • Выводы проверки каналов: 24 группы китайских и английских поисковых запросов в пяти окнах — прямые запросы по именам компонентов (FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagAttention, FlagCX, KernelGen) стабильно дают ноль совпадений; все действительные записи происходят из материалов организаций-участников, отраслевых СМИ и собственных каналов сообщества. Последняя оригинальная публикация на главной странице колонки CSDN FlagOS по-прежнему датируется 08-28 материалом об адаптации Day0, страница поиска сообщества Zhiyuan рендерится на клиенте и выдаёт лишь каркас страницы, восемь групп запросов в HN Algolia не дают прямых совпадений по заголовкам. Проверяемый прогресс экосистемного строительства по-прежнему определяется репозиториями.

6. Обзор тенденций

  • Унификация контура поставки предшествует расширению функциональности: самая тяжёлая часть работы на этой неделе — не новые операторы, а базовый уровень glibc, форма builder, коммуникационные зависимости и команды установки — самодостаточный builder для 22.04 сведён с шести бэкендов к семи, flagcx==0.14.0 расширен с двух строк nvidia до двадцати бэкендов, скрипт установки в одно действие свёл зависимости множества репозиториев в одну команду, optest превратил тестовую инфраструктуру в устанавливаемый wheel. Общий эффект этих действий — «при смене бэкенда больше не нужно менять скрипт установки», и это напрямую определяет скорость поставки 2.3 сильнее, чем любой точечный прирост производительности.
  • Замкнутый контур от требования до доказательства на этой неделе сжат до одного дня: 21.10 слияние двух FEP оформило матрицу «версия × производитель», а 22.10 Hygon зажёг первую ячейку; аналогично, после внедрения optest и FlagCICD 20.10, 22.10 переработка тест-кейсов FlagGems сразу переключилась на «прямые кандидаты». Оставшиеся девять производителей и две линейки версий для 2.3 — основной объём работы на последующие шесть недель; точка наблюдения — будет ли один и тот же 0.28.0 повторно использован на Tsingmicro, MetaX, Enflame и Kunlunxin с шаблоном empty-бэкенда Hygon.
  • Ориентация на качество, а не на количество, уже стабилизировалась: из 661 слияния за неделю менее двух десятых действительно добавили новые возможности операторов; основная масса — тестовые контракты (как минимум 119 коммитов от одного человека), автоматизированные артефакты (три партии KernelGen на 14 операторов плюс разреженное семейство на рассмотрении) и инфраструктура сборки. Это согласуется с ориентацией после релиза 2.2 — «сначала точно измерить имеющиеся возможности», ценой является замедление роста числа операторов и замедление обновления внешних цифр производительности.
  • Квантовый стек формирует воспроизводимый способ продвижения: сначала записать контракт как реализацию, которую можно отклонить, затем открывать блок за блоком: расширять подпакеты, но запирать ядро (159 новых публичных имён вошли в подпакеты, 41 экспорт Stable Core не изменён), предварительная проверка развёртывания оформлена как обязательные ворота, поставщики без внешних сервисов удалены, неутверждённые интерфейсы сэмплирования заморожены. Половина объёма слияний на этой неделе ушла на отклонения и удаления — это определяет, будет ли граница M3 в дальнейшем вызывать доверие; риск в том, что все 20–34 слияния выполнены одной учётной записью, проверка физической семантики зависит от того, что те же люди пишут тесты и реализацию, внешняя независимая перепроверка невозможна.
  • Наблюдаемость и корректность многокарточности становятся новым слабым местом многобэкендности: у Tsingmicro впервые появилась временная шкала устройства, межкарточное копирование Kunlunxin ранее всегда было ошибочным (байты никогда не записывались, синхронный вызов этого не скрывал) — оба случая произошли после «заработало». Перенос тестов и переработка контрактов тест-кейсов за последние две недели, централизация optest на этой неделе — по сути разные выражения одного суждения: первое препятствие для многобэкендности после «заработало» — воспроизводимость, а не скорость.
  • Три риск-пункта требуют подтверждения в следующем выпуске: во-первых, коммиты типа «массовое обновление» не имеют проверяемой детализации (26 файлов Enflame +3520/−511 невозможно сопоставить с конкретными операторами и выгодами), а fused MoE Kunlunxin измерен на заменённой базовой линии — оба исказят последующие межпроизводительные сравнения; во-вторых, Horizon Robotics и Cambricon молчат два дня подряд, если это продолжится на следующей неделе, следует выделить их отдельно в еженедельном отчёте; в-третьих, на стороне обучения (Megatron-LM-FL, FlagScale) на этой неделе мало пушей, три NPU PR TransformerEngine-FL ещё не слиты, прогресс стека обучения в цикле 2.3 отстаёт от стека инференса.
  • Следующая точка наблюдения: перейдёт ли dev-сборка FlagTree 0.7.1 в официальную версию до 2.3; будет ли второй производитель (Tsingmicro или MetaX) в vLLM 0.28 повторно использовать шаблон Hygon; когда FlagCV получит первый работающий оператор; будут ли опубликованы протоколы каждой секции и воркшопа конференции; когда Liangzhiyun откроется для внешнего доступа.

Приложение: материалы и проверка

  • Материалы: пять выпусков ежедневного отчёта FlagOS за 2026-10-19, 10-20, 10-21, 10-22 и 10-23, окна мониторинга соответственно: с 10-16 06:00 по 10-19 06:00 (72 часа), с 10-19 06:00 по 10-20 06:00, с 10-20 06:00 по 10-21 06:00, с 10-21 06:00 по 10-22 06:00, с 10-22 06:00 по 10-23 06:00; пропусков выпусков за период нет.
  • Метод проверки GitHub: для всех 61 репозитория организации flagos-ai ежедневно проверялся статус пушей; мержи проверялись через поиск is:merged с merged:>=начало окна как истина, находящиеся на рассмотрении — через is:open с updated:>=начало окна; новые коммиты в основной ветке проверялись через commits?sha=<ветка>&since=<UTC>, пуши в неосновные ветки определялись по потоку событий организации и commits.atom как резервному методу. Количество мержей по репозиториям — сумма раскрытых в каждом выпуске ежедневного отчёта данных; в некоторых выпусках учитывались только первые 100 объединённых PR, итого по атрибутируемым репозиториям — 641, разница в 20 относится к неразвёрнутым хвостовым репозиториям.
  • Проверка версий и тегов: проведена поатомная проверка через releases.atom репозиториев компонентов; в окне текущей недели обнаружены четыре тега (FlagCX v0.15.0.dev0, FlagTree 0.7.1a1+ascend3.5, 0.7.1.dev1, 0.7.1.dev1+ppu3.6); в репозиториях FlagGems, FlagScale, FlagBLAS, FlagDNN, Torch-FL, vllm-plugin-FL, sglang-plugin-FL, build-infra, FlagAttention, FlagSparse, FlagOps и др. новых релизов нет, что совпадает с записями в ежедневном отчёте.
  • Проверка новостной стороны: перекрёстная проверка по 24 группам поисковых запросов на китайском и английском в Google News RSS (по компонентам — за 14 дней, по участникам и отраслевым терминам — за 7 дней), восьми группам в HN Algolia, колонке FlagOS на CSDN, сообществу Zhiyuan и оригинальным материалам членов организации, пункт за пунктом; действительные записи цитировались по принципу «приоритет первоисточника», поздно проиндексированные и повторно опубликованные старые новости (например, рыночные материалы характера Huorong, старые новости о наградах на промышленной выставке) исключены по правилам и не учитывались в записях.
  • Пояснение по методике: даты и время указаны по пекинскому времени; выпуск понедельника охватывает 72 часа, его содержание за 10-16 — 10-18 помечено по исходным датам и имеет пересечение по граничным дням с предыдущим еженедельным отчётом (охватывающим 10-12 — 10-16); теги и FEP пересекающейся части уже были перечислены в предыдущем выпуске и в этом выпуске не подсчитываются повторно; «мерж» означает PR, время слияния которых по данным поиска GitHub попадает в окно, что даёт расхождение примерно в один день с подсчётом по ежедневным окнам; в настоящем отчёте единообразно используется методика по дате мержа.
  • Ограничения: активность на уровне веток (например, отладочная ветка Enflame в FlagPrism, ветка bump-flagtree-tsm в FlagGems) невозможно полностью перечислить в рамках методики по основной ветке; действия в окне на стороне обучения — Megatron-LM-FL и FlagScale — разрежены, достоверность соответствующих суждений ниже, чем для стека инференса; по новостной стороне имён компонентов сохраняется нулевая выдача, экосистемный контент поступает главным образом от членов организации и отраслевых медиа; для частей, не являющихся официальными анонсами FlagOS, в тексте указан характер источника.

Список литературы

g/0.7.1.dev1%2Bppu3.6>

· https://hub.baai.ac.cn/ · https://hn.algolia.com/api · https://news.google.com/