Окно мониторинга: 2026-09-10 10:18 ~ 2026-09-11 10:18 пекинское время Источники: GitHub (org: flagos-ai, 53 репозитория pushed_at + однократный commit search 60 записей с полной проверкой по committer-date + перекрёстная проверка per-repo commits + API веток + детали коммитов и патчи), Google News RSS (13 групп поисковых запросов на китайском и английском, через прокси), HN Algolia, Tavily/web поиск, официальный аккаунт FlagOS в CSDN, сообщество Zhiyuan (подробности в приложении)

Индекс

    1. Прогресс open-source проектов (динамика GitHub)
      • 1.1 FlagTree: версия сведена к 0.7.0 — 29 рабочих процессов поставки от вендоров переключены за один раз (09-10/09-11)
      • 1.2 build-infra: Ascend 910C официально открыт на уровне приложений, vLLM с двумя версиями и четырьмя образами входит в матрицу (09-10)
      • 1.3 build-infra: полноматричная генерация документации запуска sglang0.5.18, sglang повышен до первоклассной линии приложений (09-10)
      • 1.4 build-infra: политика каналов упаковки зафиксирована письменно, границы каналов установки закреплены (09-10)
      • 1.5 FlagTensor: бэкенды Haiguang DCU и Kunlunxin XPU влиты в основную ветку, установочные скрипты сведены (09-10)
      • 1.6 vllm-plugin-FL: бэкенд внимания Xiwang Sunrise портирован на vLLM 0.24.0, статический граф Damo Academy XuanTie восстановлен (09-10)
      • 1.7 FlagGems: двухлинейное продвижение KMCompiler Ascend/MetaX и исправление дефектов установки (09-10)
      • 1.8 Доменные библиотеки и инструментарий: операторы Haiguang в FlagGems-vllm, документация бэкенда FlagDNN, FlagCX MUSA, маршрутизация Torch-FL DCU (09-10)
      • 1.9 Инженерная часть FlagTree: CI/CD Qingwei становится полноценным, оптимизация раскладки TLE NVIDIA влита и откачена в тот же день (09-10)
    1. Новости и экосистема
      • 2.1 Девятое подряд спокойное окно новостей на уровне компонентов, вся информационная картина поступает из репозиториев кода (09-10)
    1. Углублённое изучение организаций-участников
      • 3.1 Qingwei Intelligent: линия компилятора переходит от «бэкенд может компилировать» к «самоподдерживающемуся конвейеру» (09-10)
      • 3.2 Haiguang Information: одновременное продвижение по четырём линиям — операторы, тензорная библиотека, документация доменных библиотек, маршрутизация времени выполнения (09-10)
      • 3.3 Kunlunxin: бэкенд FlagTensor XPU влит, четыре уровня работ ведутся параллельно (09-10)
      • 3.4 Xiwang Xinke и Damo Academy XuanTie: внешний инференс GPU и бэкенд PPU усилены в одном окне (09-10)
      • 3.5 Zhiyuan (головной участник): два управленческих действия — унификация версий конвейера поставки и политика упаковки (09-10)
    1. Итоги
  • Приложение: полный список источников

1. Прогресс open-source проектов (динамика GitHub)

Обзор окна: из 53 репозиториев организации 13 имели push в окне; commit search выявил 60 коммитов в окне (одна страница полностью, по убыванию committer-date), при перекрёстной проверке per-repo commits дополнительно добавлен 1 коммит Megatron-LM-FL (не попал в индекс search из-за задержки), итого 61 коммит, распределённых по 12 репозиториям: build-infra 24, FlagGems 10, FlagTree 8, FlagTensor 5, vllm-plugin-FL 3, FlagDNN 3, FlagGems-vllm 2, Torch-FL 2, flir 1, FlagFFT 1, FlagCX 1, Megatron-LM-FL 1. Новых репозиториев нет, новых релизов компонентов нет.

Форма данного окна = двухлинейность «сведение версий + расширение матрицы чипов» в период RC-тестирования: на стороне компилятора FlagTree завершил сведение номера версии к 0.7.0 и переключил 29 конвейеров поставки от вендоров на 0.7.0 за один раз; на стороне поставки build-infra продвинул Ascend 910C от «только каркас base/runtime» к открытию уровня приложений и сделал sglang первоклассной линией приложений наравне с vllm; во внешней экосистеме появилось компонентное развёртывание бэкенда Xiwang Sunrise и влитие двух бэкендов FlagTensor — Haiguang DCU и Kunlunxin XPU. Предположение предыдущего окна «когда 910C дополнит deps_app и войдёт в матрицу сборки приложений» подтвердилось в данном окне.

1.1 FlagTree: версия сведена к 0.7.0 — 29 рабочих процессов поставки от вендоров переключены за один раз (09-10/09-11)

Источник: FlagTree #1144 (09-10 23:38), #1151 (09-11 02:31)

  • Основная версия поднята до 0.7.0 (#1144): функция версии изменена на "0.7.0+" + flagtree_backend + хеш коммита (без суффикса бэкенда возвращается 0.7.0 + хеш); в рамках коммита параллельно реализованы шесть сопутствующих изменений — обновление базовых показателей производительности benchmark qwen3.6 для PPU/HCU, добавление описания tsingmicro3.6 в README, добавление LICENSE в wheel, исправление загрузки third_party для TileIR, исправление путей к библиотекам в рабочем процессе Iluvatar; таблица производителей/бэкендов в README также переименована из “Installation” в “User Guide” и расширена.
  • 29 рабочих процессов поставки от производителей единообразно переведены на 0.7.0 (#1151): значение по умолчанию входного параметра версии в *_delivery.yml единовременно изменено с '0.6.0' на '0.7.0', одновременно обновлён рабочий процесс ключевого тестирования ppu3.6. Затронутые 29 линий: nvidia3.3/3.5/3.6/3.7/3.8, tileir3.6, amd3.6, ascend3.2/3.5, enflame3.5-gcu400/3.6-gcu400, iluvatar3.1/3.6, metax3.0/3.6, mthreads3.1/3.2/3.6, tsingmicro3.3/3.6, sunrise3.4, xpu3.0/3.6, hcu3.1/3.6, aipu3.3, thrive3.6, ppu3.6.
  • Состояние на стороне веток: головные коммиты трёх линий 0.7.0-rc0-triton3.3/3.5/3.6 остановились на 08-11, 08-27, 08-31 соответственно; 0.7.0-rc1-triton3.3/3.5/3.6 — на 09-01, 09-04, 09-04, при этом головной коммит rc1-triton3.6 — это [Tsingmicro] Add Tsingmicro backend integration (Triton 3.6)（#1071）.
  • Официальный релиз пока не появился: последняя запись FlagTree на GitHub Releases по-прежнему 0.6.0+triton3.x (2026-06-24); действия в этом окне относятся к категории “конвейер поставки идёт впереди, номера версий сходятся”, официальный tag ожидается.

Интерпретация: способ продвижения 0.7.0 очень ясно отражает дисциплину периода RC — не менять кодовый маршрут, а лишь сводить воедино номера версий и точки входа поставки: сначала в main версия пакета поднимается с 0.6.0 до 0.7.0, затем все 29 конвейеров поставки от производителей единообразно направляются на 0.7.0, тем самым подталкивая якорь из списка RC1 “flagtree три линии унифицированы 0.7.0rc1.post1” к официальной версии. Одно расхождение, заслуживающее отслеживания: в configs.yaml в build-infra линия NVIDIA по-прежнему закреплена на flagtree==0.6.1, то есть между “версией компилятора, зафиксированной в поставленных образах” и “основной версией компилятора” существует отставание на одну версию — именно этот зазор необходимо устранить перед GA.

1.2 build-infra: прикладной уровень Ascend 910C официально открыт, два версии vLLM и четыре образа вошли в матрицу (09-10)

Источники: build-infra #816 (09-10 18:36), #813 (15:07), #808 (11:00), #818/#819, #823/#824, #820, #825, #826, #828, #833, #834

  • Открытие прикладного уровня (#816, +257/-16): в описании коммита указано, что “runtime-образ для 910C уже собран и запушен, поэтому линия приложений vllm может быть открыта на двух линиях 910C (ascend-cann8.5.0-910c / ascend-cann9.0.0-910c)”. Одновременно добавлено 4 changelog — vllm0.20.2 и vllm0.24.0, каждый соответствует CANN 8.5.0 и 9.0.0; изменения охватывают vllm-app-image.yml, app/vllm/Containerfile, configs.yaml, docs/status-matrix.md, два файла status_matrix.vllm*.yaml и скрипт рендеринга.
  • Теги прикладных образов 910C начинают попадать в репозиторий: #818/#819 фиксируют 2.1.2-0.2.0_g2b6b635.d20260824 и 2.1.2-0.2.0_gcf8998c.d20260818 для CANN 8.5.0-910c, #823/#824 фиксируют соответствующие теги для CANN 9.0.0-910c.
  • Стабилизация в рамках подготовки к открытию: #808 удаляет hook apt Post-Invoke из базового образа 910C; #813 заставляет шаблон запуска Ascend раскрывать целую пару die (две карты в пределах одного die видны парой); #820 включает самодиагностику при сбое verify в ascend; #825 пробрасывает прокси runner в шаг установки verify; #826 выбирает python для runner, способный импортировать ruamel.yaml; #828 исправляет экранирование кавычек в verify Step 2; #833 собирает flashinfer stub только когда целевой ref содержит stub; #834 прокидывает pin плагинов cell в сборку прикладного образа vllm.

Толкование: это точная реализация прогноза предыдущего окна. Наблюдение в отчёте от 09-10 заключалось в том, что 910C «подключается как изоморфный вариант линейки чипов 910B, а отсутствие deps_app удерживает его за пределами матрицы приложений», и тогда был сделан прогноз «открыть после выпуска и проверки артефактов приложений». #816 в этом окне — это как раз открытие того самого шлюза: форма поставки 910C повышается с «доступен base/runtime» до «доступен для приложений», причём сразу выдаются 2 линии CANN × 2 версии vLLM = четыре записи образов приложений. Сопутствующие девять исправлений verify/шаблонов/образов как раз и представляют собой завершающую работу под дисциплиной «можно добавлять новую адаптацию, нельзя добавлять новые функции» — сначала такие проблемы окружения, как самодиагностика verify, проксирование и выбор зависимостей, перестают блокировать конвейер, и только затем открывается матрица.

1.3 build-infra: полноматричная генерация документации запуска sglang0.5.18, sglang повышен до первоклассной линии приложений (09-10)

Источники: build-infra #831 (09-10 21:38), #817 (19:13), #821 (19:20), #829 (20:42), #830 (20:55)

  • #831 исправляет логику фильтрации генератора (+2862/-34): в описании коммита указано, что генератор фильтровал ключи deps_app с помощью a in APP_IMAGE_DEFAULTS or a.startswith("vllm"), из-за чего sglang0.5.18 отбрасывался ещё до попадания в рендерер, и ранее ни один образ приложения sglang не имел страницы запуска; после исправления для всех образов приложений sglang генерируется двуязычная (китайско-английская) документация запуска.
  • Охваченные линии приложений sglang: ascend-cann8.5.0 / ascend-cann9.0.0 (Ascend), cambricon-neuware4.4.3 / 4.7.2 (Cambricon), enflame-tops1.9.10 / 1.10.6 (Enflame), hygon-dtk26.04 (Hygon), iluvatar-corex4.5.0 (Iluvatar CoreX), metax-maca3.7.2.1 / 3.8.1.3 (MetaX) и другие.
  • Сопутствующее: #817 подтягивает iluvatar-corex4.5.0 к линии sglang 0.5.18; #821 добавляет changelog для sglang0.5.18-iluvatar-corex4.5.0; #829 исправляет лишний ключ image в changelog; #830 фиксирует тег образа приложения 2.1.2-0.1.dev1_g201484665.
  • Синхронное обновление описаний образов: #810 и #814 соответственно обновляют текст описания 2.1.2 для образов base и runtime, #815 выводит тег образа runtime:v1 для flaggems-release из configs.yaml.

Толкование: этот пункт важнее, чем кажется на первый взгляд. vllm и sglang — две основные линии фреймворков, через которые FlagOS поставляет возможности инференса вовне, и ранее фактическая форма матрицы была «vllm — полная, sglang — разрозненная». Действия этого окна дополняют sglang0.5.18 как минимум на 10 линиях чипов документацией запуска и changelog, что означает, что в терминах поставки sglang уже поставлен в один ряд с vllm; это перекликается с соревновательной линией FlagGems-sglang этого окна и зафиксированным в отчёте от 09-07 «форумом открытых вычислений AI на KubeCon» — широта охвата фреймворков инференса становится главным измерением, которое сообщество демонстрирует вовне.

1.4 build-infra: политика канала упаковки оформлена письменно, границы каналов установки зафиксированы (09-10)

Источники: build-infra #812 (09-10 21:45)

  • Добавлены docs/content/en/usage/packaging-channels.md (122 строки) и docs/content/zh-cn/usage/packaging-channels.md (97 строк), которые закрепляют выводы предыдущих обсуждений в виде политики: каналы deb/rpm отвечают за чисто Python-пакеты и нативные библиотеки (один репозиторий на источник для целевого дистрибутива), приватные PyPI-индексы каждого производителя отвечают за зависимости со стороны производителя, и граница между ними чётко прописана.

Толкование: это управленческий коммит перед 2.2 GA, находящийся в той же логике, что и базовая линия changelog из 60 app-образов + push-гейтинг в предыдущем окне: сначала нужно ясно объяснить, «откуда берутся артефакты», а затем — «откуда устанавливаются зависимости». Для программного стека, которому предстоит охватить приватные инструментальные цепочки более десяти производителей чипов, политизация каналов установки является предварительным условием для масштабируемости многопроизводительной дистрибуции.

1.5 FlagTensor: двойные бэкенды Hygon DCU и Kunlunxin XPU влиты в основную ветку, установочные скрипты консолидированы (09-10)

Источники: FlagTensor #5153939 / #1be84f2 (09-10 10:37, по одному на каждый), #81c6214 (10:39), #2f895c1 (10:47), #efed2c4 (10:48)

  • Два новых бэкенда влиты: feat: merge Hygon DCU + Kunlunxin XPU backend support вливает ветку Hygon (включая результаты адаптации FlagTensor-haiguang) в main, статистика — +4225/-168 (4393 строки), основная часть изменений — benchmark и слой адаптации бэкендов; в ту же минуту прошёл ещё один коммит add Hygon DCU and Kunlunxin XPU backend support.
  • Консолидация установки и документации: #2f895c1 объединяет setup_muxi.sh в одну ветку унифицированного setup.sh --backend metax; #efed2c4 удаляет отдельный скрипт; #81c6214 удаляет специализированный отчёт о производительности Metax PERF_REPORT_metax.md.

Толкование: «количество бэкендов +2, поверхность поддержки -1 набор специализированных скриптов» — направление единое: с одной стороны, два новых типа оборудования Hygon DCU и Kunlunxin XPU включены в тензорную библиотеку, с другой — специализированные установочные пути производителей сведены к единой точке входа, чтобы избежать линейного роста затрат на поддержку скриптов по мере увеличения числа производителей. FlagTensor является одной из шести предметных библиотек, выпущенных в июне в рамках «базовой платформы для научного интеллекта»; расширение его многобэкендности показывает, что библиотеки научных вычислений продолжают разворачиваться в соответствии с целью «одна разработка, запуск на множестве чипов».

1.6 vllm-plugin-FL: бэкенд внимания Sunrise от XiWang портирован на vLLM 0.24.0, статический граф XuanTie от DAMO Academy восстановлен (09-10)

Источники: vllm-plugin-FL #391 (09-10 20:01), #472 (10:33), #480 (18:22)

  • #391 (+37/-1): заголовок — «портирование бэкенда Sunrise на vLLM 0.24.0», в описании коммита указано, что объектом является Sunrise (XiWang TANGRT 1.2.0), оба изменения находятся в пути sunrise vendor — attention.py использует режим CUSTOM для регистрации бэкенда внимания, patch.py добавляет слой совместимости ptpu для memory_stats.
  • #472: восстановление поддержки статического графа для бэкенда XuanTie от DAMO Academy (thead) (регрессионное исправление на основе предыдущего коммита).
  • #480: добавление для PR двух команд комментариев — /rerun-failed-ci и /cancel-ci; таблица производителей чипов в README репозитория уже указывает Sunrise как Supported.

Интерпретация: это наиболее содержательный шаг внешней экосистемы в данном окне. В окне 09-07/09-08 прогресс XiWang был зафиксирован лишь как «сначала настройка окружения runner, компоненты ещё не включены», а в текущем окне выполнено внедрение на уровне компонентов — версия инструментальной цепочки XiWang (TANGRT 1.2.0) подключена во входной форпост-плагин интеграции vLLM 0.24.0. Для FlagOS это означает, что стандартный путь «подключения нового чипа» (сначала создать runner с унифицированным окружением, затем разместить vendor-бэкенд в vllm-plugin-FL) уже пройден один раз и является многоразовым шаблоном интеграции; две команды CI-эксплуатации из #480 и самодиагностика verify в build-infra относятся к одному классу инженерного снижения затрат на «поддержку мультивендорного CI».

1.7 FlagGems: двухлинейное продвижение KMCompiler для Ascend/MetaX и исправление дефектов установки (09-10)

Источники: #6138, #5821, #6155, #6160, #6156, #6157, #6146, #6087, #6147, #6131

  • Путь генерации KMCompiler: [KMCompiler][Ascend] Opt replication pad2d backward (#6138), [KMCompiler][Ascend] Add ascend backend for linalg_solve_triangular (#5821), [KMCompiler][MetaX] Fix gru bug (#6155) — продолжение способа добавления операторов «одна разработка, несколько бэкендов».
  • Сокращение линии вендорного CI: fix(.github): remove metax-maca3720 info (#6160) — после более раннего удаления записей CI устраняется остаточная информация.
  • Исправления корректности установки и выполнения: #6146 добавляет отсутствующий DSA/__init__.py, благодаря чему неустанавливаемый через редактируемый режим пакет включает этот подпакет (напрямую влияет на полноту установки нижестоящих плагинов); #6087 приводит pid_p индексного оператора к int64, исправляя переполнение смещения int32; #6147 исправляет ошибку адресации планирования в adaptive_avg_pool3d_backward; #6131 исправляет именование бенчмарка irshift.
  • Инженерная часть: #6157 расширяет проверку init exports; #6156 удаляет ошибочно добавленный заголовок Apache 2.0 в сторонних файлах.

Интерпретация: по сравнению с предыдущим окном, где «39 коммитов были в основном массовым заведением операторов KernelGen в репозиторий», в текущем окне объём коммитов основного репозитория снизился до 10, а структура сместилась от «наращивания объёма» к «покрытию и укреплению»: путь генератора продолжает дополнять бэкенды для Ascend и MetaX, остальное сосредоточено на полноте установки и численной корректности. При этом такие дефекты, как #6146 («подпакет не устанавливается»), оказывают наибольшее влияние на нижестоящие компоненты — плагины vllm/sglang зависят от полной поверхности установки библиотеки операторов, и подобные исправления являются типичным действием периода RC по превращению «работает» в «устанавливается и работает правильно».

1.8 Доменные библиотеки и инструментальные цепочки: операторы Haiguang в FlagGems-vllm, документация бэкендов FlagDNN, FlagCX MUSA, маршрутизация Torch-FL DCU (09-10)

Источники: FlagGems-vllm #736, #704, Torch-FL #270, #247, FlagCX #576, FlagDNN, FlagFFT, Megatron-LM-FL #148

  • FlagGems-vllm: #736 [AdvancedCompiler] add hygon fused_add_rms_norm — добавлена реализация 325 строк специализированного оператора для Hygon с регистрацией в бэкенде _hygon, одновременно добавлена защита импорта TensorDescriptor для старой версии Triton; #704 добавляет быстрый путь pair-load для moe_sum.
  • Torch-FL: #270 perf: restore fused SDPA on the boxing route via a composite override (+658 строк), первопричина описана в коммите и сопроводительном документе (docs/bench_qwen3_dcu_route_perf.md) — aten::scaled_dot_product_attention является composite-оператором, выбор слитого бэкенда происходит внутри composite, поэлементное разбиение по leaf приводит к потере пути слияния, восстановление выполнено через переопределение на уровне composite; данная работа явно нацелена на маршрут DCU. Кроме того, #247 добавляет конвейер автоматической триажной диагностики для тестов transformers.
  • FlagCX: #576 [PAL] Link default device API backend for MUSA platform — подключение бэкенда device API по умолчанию для платформы MUSA от Moore Threads (makefiles/musa.mk).
  • FlagDNN: три последовательных коммита с документацией по бэкендам — добавлен readme для Hygon, исправлен readme для Hygon, добавлен readme для Iluvatar CoreX.
  • FlagFFT: обновлено описание поддержки бэкендов в README и уточнены зависимости.
  • Megatron-LM-FL: #148 fix(platform): prefer native accelerator detection — при обнаружении платформы приоритет отдаётся нативному распознаванию ускорителя.

Интерпретация: данная группа представляет собой горизонтальное развёртывание «доменных библиотек и цепочек инструментов обучения/инференса»: Hygon (операторы + тензорная библиотека + документация доменных библиотек + маршрутизация во время выполнения), Moore Threads (подключение платформы коммуникационной библиотеки), Iluvatar CoreX (документация) — в одном окне мониторинга у каждой из них есть свои действия. Результаты Torch-FL содержат независимый эталонный документ и исходный код stub, что относится к редкому типу коммитов «проблема производительности с полной цепочкой доказательств», показывая, что регрессии производительности на маршрутах обучения/инференса уже включены в регулярное отслеживание.

1.9 Инженерная сторона FlagTree: институционализация CI/CD Tsingmicro, оптимизация раскладки TLE NVIDIA принята и откачена в тот же день (09-10)

Источники: FlagTree #1118, flir #69, #1047, #1139 (revert), #1075, #1074, #1143

  • Инфраструктура компилятора на стороне Tsingmicro (#1118, +344/-10): исправлена совместная сборка бэкенда tsingmicro с FLIR, а также добавлены два новых workflow — tsingmicro3.6-build-and-test.yml (115 строк) и tsingmicro3.6-delivery.yml (191 строка); на стороне CMake добавлен переключатель FlagTreeOptions, синхронно скорректированы runtime Tx81 и примеры тестов в third_party/tsingmicro; коммит подписан совместно патчем со стороны Tsingmicro и ботом сообщества. Соответствующий коммит на стороне FLIR #69 синхронизирует патч FLIR от Tsingmicro для поддержки LLVM 22 (FLIR — это промежуточный слой IR для FlagTree, форк triton-shared).
  • Оптимизация раскладки TLE NVIDIA: в тот же день смержена и в тот же день откачена: #1047 в 12:35 был смержен с формулировкой «вынести преобразование layout внутри одного warp через shuffle», а в 13:47 уже откачен через #1139. В том же окне на стороне MTHREADS сохранены два содержательных мержа: #1074 (конфигурация SQMMA склоняется к чистому M-split при выборе) и #1075 (swizzled разделяемый доступ к памяти PH1 вынесен через LinearLayout).
  • Прочее: #1143 исправляет ошибку компиляции gcc7 в пространстве имён of для пути Enflame.

Толкование: эта линия Tsingmicro показывает, что компания уже обладает способностью «самостоятельно вести workflow сборки и доставки», а не ждёт, пока сообщество подключит её — для вендора, который ранее существовал в FlagTree лишь в форме бэкенда Triton 3.3, это довольно цельный шаг. Напротив, откат TLE NVIDIA в тот же день заслуживает того, чтобы стать заметкой об инженерном ритме: в период заморозки RC, если оптимизация производительности вносит регрессию, способ обработки — откат в тот же день, а не продвижение с проблемой, что согласуется с дисциплиной «можно принимать новые адаптации, но не новые фичи».

2. Новостные репортажи и экосистема

2.1 Девятое подряд спокойное окно новостей на уровне компонентов, вся информационная картина — из репозиториев кода (09-10)

Источники: Google News RSS 13 групп запросов на китайском и английском (09-10 10:18 ~ 09-11 10:18, через прокси)、HN Algolia、Официальный аккаунт FlagOS на CSDN、Сообщество Zhiyuan

  • Полное отсутствие попаданий по компонентным запросам: FlagOS when:2d, FlagOS when:14d, FlagGems when:3d/14d, FlagScale when:3d, FlagTree when:7d, FlagCX when:14d, FlagAttention OR FlagPerf when:14d, KernelGen when:7d, BAAI open source when:2d, Moxi open source operator when:2d и другие запросы на китайском и английском не дали попаданий, что составило девятое подряд спокойное окно компонентного поиска.
  • Слова членов-организаций — это шум или контент фондового рынка: Moore Threads Zhiyuan when:2d дал 12 попаданий, основу составили репосты о кластере на сто тысяч карт JD Cloud и отчёты о котировках (продолжение уже зафиксированного в окне 09-09), а также SEO-материалы игорной тематики; Zhiyuan Academy open source when:2d дал 9 попаданий — обычные статьи сообщества Zhiyuan и SEO игорной тематики (включая статьи сообщества по воплощённому интеллекту, судейство споров по AI и т. д.), прямой связи со стеком FlagOS нет, вся партия отсеяна по установленному критерию.
  • Попадания HN Algolia — ложные совпадения по подстроке: заголовки всех пяти групп запросов FlagOS/FlagGems/FlagTree/FlagScale/BAAI оказались нерелевантными записями типа flags/flagship (например, «15x10 Pixel Flags», серия Show HN), ни одна не указывает на данный стек, вся партия отсеяна.
  • Официальные каналы контента без новых публикаций: на официальном аккаунте FlagOS в CSDN в окне нет новых статей, последняя по-прежнему от 08-28 — адаптация GLM-5.3-Flash Day0 для 9 чипов; страницы однопрофильного форума KubeCon от 09-07 и темы по настройке операторов продолжают висеть, обновлений по времени публикации нет. В сообществе Zhiyuan и на официальном сайте в окне также нет новых публикаций, связанных с FlagOS.

Толкование: расхождение между новостной и кодовой сторонами в этом окне достигло максимума за последнее время — 61 коммит включает конвергенцию версий, открытие прикладного уровня Ascend 910C, полную матрицу документации sglang, вливание двух новых бэкендов и другие содержательные подвижки, тогда как внешних сообщений ноль. Это говорит о том, что текущая внешняя заметность FlagOS не синхронизирована с инженерным прогрессом, а информационные публикации сообщества по-прежнему сосредоточены на двух типах узлов — «адаптация модели Day0» и «форумы конференций»; прогресс этого окна следует читать по линиям поставки и компилятора, и эта оценка напрямую влияет на ритм отслеживания.

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

3.1 Qingwei Intelligent: линия компилятора перешла от «бэкенд умеет компилировать» к «самоподдержке конвейера» (09-10)

Источники: FlagTree #1118, flir #69

  • Три действия в окне указывают на одно: в FlagTree добавлены два рабочих процесса tsingmicro3.6 — build-and-test и delivery, исправлена совместная сборка с FLIR; FLIR синхронизировал патч Qingwei для поддержки LLVM 22; в журнале изменений README FlagTree зафиксировано «2026/09/10 бэкенд Qingwei обновлён до Triton 3.6 и добавлен CI/CD».
  • Сторона поставки: обе линии tsingmicro3.3 и tsingmicro3.6 входят в единый список переключения на 0.7.0 в этом окне.

Толкование: ранее Qingwei в FlagTree существовал в форме «интеграция бэкенда на базе Triton 3.3», после этого окна он превратился в «штатную линию поставки с собственными рабочими процессами сборки/доставки, выровненную по LLVM 22 и Triton 3.6». Ценность суждения для членов-организаций состоит в том, что поддержка нового поколения на уровне компилятора уже не зависит от аутсорсинга сообщества, что говорит о способности команды компиляторов на стороне Qingwei к самостоятельному сопровождению; одновременный вход двух продуктовых линий в матрицу поставки также означает, что смена поколений включена в штатный ритм версий FlagOS.

3.2 Haiguang Information: одновременное продвижение по четырём линиям — операторы, тензорная библиотека, документация доменных библиотек, маршрутизация времени выполнения (09-10)

Источники: FlagTensor #1be84f2, FlagGems-vllm #736, Torch-FL #270, FlagDNN, build-infra #831

  • В данном окне мониторинга у Hygon наблюдаются четыре разрозненных, но однонаправленных действия: в FlagTensor влит бэкенд DCU (+4225 строк); в FlagGems-vllm добавлен специализированный для Hygon fused_add_rms_norm (325 строк); в FlagDNN добавлена документация по бэкенду Hygon; в Torch-FL для маршрутизации DCU восстановлена фьюзинговая SDPA и оставлена документация с бенчмарками. Со стороны поставки также в полную матрицу вошла документация по запуску sglang0.5.18-hygon-dtk26.04.
  • В сочетании с зафиксированным в окне 09-09 «решением двухчипового ускорения Token-бизнеса Hygon», действия Hygon в программном стеке уже расширились от ранней специализации операторов до бэкендов тензорных библиотек, документации доменных библиотек и маршрутизации производительности среды исполнения.

Толкование: Hygon в настоящее время — одна из членских организаций с наиболее широким фронтом работ внутри FlagOS: библиотека операторов, тензорная библиотека, документация доменных библиотек, плагин инференса (прикладная линия sglang), а также маршрутизация среды исполнения в Torch-FL — везде есть работающие направления. Его коммерческая нарратив (фабрика Token) и покрытие программного стека продвигаются синхронно, что означает, что позиционирование Hygon DCU в FlagOS смещается от «адаптируемого чипа» к «участнику глубокого совместного строительства».

3.3 Kunlunxin: влит бэкенд XPU в FlagTensor, четыре уровня работ ведутся параллельно (09-10)

Источники: FlagTensor #1be84f2, список линий поставки FlagTree

  • В данном окне мониторинга FlagTensor влил в основную ветку бэкенд XPU Kunlunxin вместе с бэкендом DCU Hygon; со стороны поставки два workflow xpu3.0 и xpu3.6 включены в единый переключатель 0.7.0.
  • В связке с предыдущими записями: в окне 09-02 в FlagGems было исправление выхода за границы slice_scatter для бэкенда Kunlunxin, в окне 09-08 в FlagScale была поддержка обучения CI и среды исполнения для Kunlunxin P800, в окне 09-09 зафиксировано пакетное вливание операторов Kunlunxin KernelGen в FlagGems-Experimental.

Толкование: В настоящее время Kunlunxin имеет работающие фронты работ на четырёх уровнях: «тензорная библиотека (FlagTensor), библиотека операторов (FlagGems), фреймворк обучения (FlagScale), поставка компилятора (две линии FlagTree xpu)» — по форме это уже близко к производителю глубокой адаптации. Учитывая, что Kunlunxin не входит в публично оглашённый список членских организаций сообщества, интенсивность его вложений заслуживает постоянного отслеживания как образец внешней экспансии экосистемы.

3.4 Xiwang Xinke и Damo Academy XuanTie: внешний инференс GPU и бэкенд PPU наращиваются в одном окне (09-10)

Источники: vllm-plugin-FL #391, #472, FlagTree #1144

  • Sunrise (SiWang XinKe): vllm-plugin-FL перенёс свой backend внимания на vLLM 0.24.0 (объект — их инструментальная цепочка TANGRT 1.2.0), совершив переход от «только окружение runner» к «компонентному backend»; на стороне поставки sunrise3.4 включён в переключение 0.7.0; официальная таблица производителей чипов уже включает Sunrise.
  • T-Head (Damoyuan Xuantie): vllm-plugin-FL #472 восстановил поддержку статического графа для их backend; на стороне поставки ppu3.6 включён в переключение 0.7.0, FlagTree #1144 синхронно обновил базовую производительность benchmark qwen3.6 для PPU.

Интерпретация: обе относятся к «инвестициям в инференс на стороне непрофильных участников». Sunrise — отечественный производитель, специализирующийся на инференс-GPU (его продуктовые линейки S1/S2/S3 ориентированы на сценарии инференса), и выбор в пользу плагинной линии, следующей за upstream в vLLM 0.24.0, говорит о том, что привлекательность пути развёртывания инференса на стороне интернета/облака для отечественных производителей чипов продолжает расти; исправление статического графа T-Head и включение линии поставки PPU в 0.7.0 показывают, что он, как наиболее репрезентативный вычислительный backend в контексте RISC-V, сохраняет регулярный ритм обновлений в матрице поставки FlagOS.

3.5 Zhiyuan (головной участник): два управленческих действия — унификация версий конвейера поставки и политика упаковки (09-10)

Источники: FlagTree #1151, build-infra #812, release-info

  • Действия головного участника в этом окне сосредоточены на управлении, а не на функциональности: унификация номеров версий 29 рабочих процессов поставки от производителей FlagTree (коммит от мейнтейнеров со стороны сообщества), оформление границ каналов упаковки в виде двуязычного (китайско-английского) документа с политикой.
  • Репозиторий списка релизов release-info в окне не обновлялся (по-прежнему только начальный README), что говорит о том, что официальный список релизов 2.2 ещё не финализирован.

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

4. Итоги

В данном окне (09-10 10:18 ~ 09-11 10:18) на стороне GitHub — 61 коммит внутри окна, 13 репозиториев с пушами, инженерная сторона сохраняет высокую активность; на новостной стороне поиск на компонентном уровне — девятое подряд спокойное окно, внешних публикаций ноль, вся информация поступает из репозиториев кода. Четыре главные линии:

  1. FlagTree 0.7.0 входит в фазу конвергенции поставки (важнейшее изменение данного окна): номер версии основной линии повышен с 0.6.0 до 0.7.0, и входной параметр версии 29 рабочих процессов поставки от производителей разом переключён на 0.7.0, охватывая шесть линий triton от NVIDIA (включая TileIR и особые формы), AMD, Ascend, Enflame, Iluvatar CoreX, MetaX, Moore Threads, Tsingmicro, Sunrise, Kunlunxin XPU, HCU, AIPU, Thrive, PPU и другие; трёхуровневые ветки rc0/rc1 (triton 3.3/3.5/3.6) ранее уже были на месте, официальный тег release ещё не опубликован. Это означает, что конвергенция версий в период 2.2 RC уже на последнем шаге.
  2. Ascend 910C завершил двухуровневое внедрение «base → app», sglang повышен до первоклассной прикладной линии: после сборки и пуша runtime-образа 910C прикладная линия vllm открыта на двух линиях 910C с CANN 8.5.0 и 9.0.0 (охватывая четыре прикладных записи vLLM 0.20.2 и 0.24.0), а также дополнена девятью исправлениями стабилизации verify/шаблонов/зависимостей; одновременно для sglang0.5.18 как минимум 10 линий чипов сгенерированы стартовая документация и changelog, матрица фреймворков инференса из «vllm полностью, sglang разрозненно» превратилась в равновесное сочетание двух линий.
  3. Внешние и непрофильные производители продолжают наращивать усилия: Sunrise завершил внедрение компонентного backend (продвинувшись от окружения runner к vendor backend в vLLM 0.24.0), Kunlunxin XPU и Hygon DCU с двумя backend вошли в FlagTensor, Tsingmicro добавил двунаправленный CI/CD tsingmicro3.6 и выровнял LLVM 22 и Triton 3.6 — стандартный путь подключения новых чипов (сначала окружение → плагинный backend → включение линии поставки) подтверждён как воспроизводимый.
  4. Дисциплина периода RC многократно проявляется в инженерных деталях: оптимизация компоновки TLE NVIDIA в тот же день была включена и в тот же день откатана, FlagGems удалил остаточные записи CI для MetaX, исправление целостности подпакета установки, политика каналов упаковки оформлена документально — действия периода заморозки суть «исправлять корректность и формат, не вводить новые функции», откат в тот же день и исправления на стороне установки — наиболее прямое доказательство этой дисциплины.

Прогноз: четыре направления для дальнейшего наблюдения — во-первых, когда первый app image tag для 910C попадёт в записи registry и появится в столбце “проверено” матрицы статусов (это окончательный признак готовности к поставке 910C); во-вторых, когда официальный release tag FlagTree 0.7.0 и flagtree pin в build-infra будут синхронизированы (в настоящее время линия NVIDIA всё ещё закреплена на 0.6.1, существует расхождение в одну версию); в-третьих, ритм инкрементации rc1.postN перед 2.2 GA (09-28) и действия по списку community/release-info; в-четвёртых, будет ли путь подключения Xiwang расширен с линии vllm на линию sglang, и будет ли Kunlunxin включён в публичный список участников.

Пояснение ограничений: все пункты данного окна взяты из коммитов GitHub, файлов рабочих процессов и содержимого патчей; новостная сторона представляет собой девятое подряд спокойное окно без независимо перекрёстно проверяемых сторонних сообщений, поэтому суждения типа “сходимость версий” и “готовность к поставке” основаны исключительно на тексте коммитов и изменениях файлов, без доверия к сторонним пересказам. 13 групп запросов Google News на китайском и английском дали нулевые совпадения, совпадения в HN оказались ложными срабатываниями по подстроке — всё это добросовестно зафиксировано в приложении.

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

Источники Результаты проверки
GitHub org repos API (flagos-ai, 53 репозитория, сортировка по pushed) Пуш в окне у 13 репозиториев: build-infra (09-11 10:06), FlagTree (09-11 10:05), FlagBLAS (09-11 10:14, в ветке по умолчанию нет коммитов в окне, определено как действие с веткой), vllm-plugin-FL, FlagGems, FlagGems-vllm, FlagDNN, Torch-FL, flir, FlagFFT, FlagCX, FlagTensor, Megatron-LM-FL; новых репозиториев нет (последний созданный репозиторий — 08-15)
GitHub commit search (по всей org, committer-date > 2026-09-10T02:18Z, полная выдача 60 записей на одной странице) Построчная проверка времени committer и принадлежности к репозиторию: build-infra 24 / FlagGems 10 / FlagTree 8 / FlagTensor 5 / vllm-plugin-FL 3 / FlagDNN 3 / FlagGems-vllm 2 / Torch-FL 2 / flir 1 / FlagFFT 1 / FlagCX 1
Повторная проверка GitHub per-repo commits (Megatron-LM-FL, FlagBLAS, FlagGems-Experimental) Megatron-LM-FL #148 (09-10 10:47) попадает в окно, индекс search отстаёт и не включил его, добавлено; последний коммит ветки по умолчанию FlagBLAS — 09-09 (вне окна), пуш в окне пришёл из ветки; последний коммит FlagGems-Experimental — 09-10 09:11 (вне окна)
GitHub branches API (FlagTree) Время головы 0.7.0-rc0-triton3.3/3.5/3.6 — 08-11 / 08-27 / 08-31; 0.7.0-rc1-triton3.3/3.5/3.6 — 09-01 / 09-04 / 09-04 (голова rc1-triton3.6 — это интеграция бэкенда Tsingmicro #1071)
Детали коммитов и патчи GitHub #1151 всего 29 файлов рабочих процессов доставки, версия по умолчанию ‘0.6.0’ → ‘0.7.0’ (автор коммита zhengyang@baai.ac.cn); #816 (273 строки, 4 changelog vllm 910C + status matrix); #831 (2896 строк, матрица документации запуска sglang0.5.18); #1118 (354 строки, сборка и тестирование + доставка Tsingmicro); слияние бэкенда FlagTensor (4225 строк / 4393 строки); vllm-plugin-FL #391 (sunrise, объект — TANGRT 1.2.0); FlagGems-vllm #736 (оператор Hygon 325 строк); Torch-FL #270 (658 строк, включая документ бенчмарка маршрутизации DCU); FlagCX #576 (MUSA PAL)
GitHub tags / releases API В этом окне новых release нет. Последние опорные точки: FlagGems v5.4.0-rc1.post1, FlagTree 0.6.0+triton3.x (Releases) / линия доставки уже переключена на 0.7.0, FlagCX v0.14.0-rc1.post1, FlagGems-vllm v0.2.0-rc1.post1, vllm-plugin-FL v0.3.0-rc1.post1, FlagBLAS v0.3.0-rc1.post1, FlagTensor v0.3.0-rc1.post1, FlagDNN v0.3.0-rc1.post1, FlagFFT v0.2.0-rc1.post1, Torch-FL v0.2.0-rc1.post1, FlagOS-Robo v0.1.0
raw.githubusercontent (README и configs.yaml для FlagTree / vllm-plugin-FL / build-infra / flir) Таблица вендоров FlagTree включает NVIDIA (в том числе TileIR), AMD, Enflame, Iluvatar CoreX, Hygon, Moore Threads, DAMO Academy, Huixi Intelligence, MetaX, Stream Computing, Kunlunxin, T-Head DAMO Academy, Intilect Space-Time, Tsingmicro; таблица вендоров vllm-plugin-FL включает Sunrise (Supported); линия NVIDIA в build-infra configs.yaml по-прежнему pin flagtree==0.6.1, содержит ключи sunrise / tsingmicro / kunlun / hygon / mthreads / iluvatar / cambricon / metax / enflame; flir — промежуточный слой FlagTree IR (форк от triton-shared)
Google News RSS (13 групп поисковых запросов на китайском и английском, через прокси) Запросы по компонентам — ноль попаданий (девятое подряд спокойное окно); по словам участников — попадание на кластер JD Cloud на сто тысяч карт
Репoсты, материалы о ценах на акции/разблокировке долей и SEO-статьи о ставках — согласно установленному подходу не включаются в технические записи    
  HN Algolia (FlagOS / FlagGems / FlagTree / FlagScale / BAAI) Все нерелевантные записи, ошибочно совпавшие по подстрокам flags/flagship/flocked, исключены целым пакетом
  Официальный аккаунт FlagOS в CSDN (flagos.csdn.net) За окно мониторинга новых статей нет, последняя по-прежнему от 08-28 — адаптация GLM-5.3-Flash Day0 к 9 чипам; страница форума на KubeCon 09-07 и страница по теме настройки операторов — обновлений по времени публикации нет
  Сообщество Zhiyuan (hub.baai.ac.cn) Попадания в окне мониторинга — обычный контент сообщества (embodied intelligence, управление AI и т. д.), прямой связи с технологическим стеком FlagOS нет
  Tavily / web-поиск Проверка бэкграунда Xiwang Xinke (официальный сайт, Qbit, TMTPost — три источника); проверка исторических опорных точек ритма версий FlagOS (официальные пресс-релизы Zhongzhi FlagOS 1.6 / 1.5)