Окно мониторинга: 2026-09-05 10:18 ~ 2026-09-06 10:18 пекинское время Источники: GitHub (org: flagos-ai 52 репозитория + полный поиск по коммитам 21 запись + проверка ветки по умолчанию для каждого репозитория + проверка дат tags/releases), Google News RSS (13 групп запросов на китайском и английском, прокси-канал работает штатно), HN Algolia, поиск Tavily, сообщество Zhiyuan hub.baai.ac.cn, официальный аккаунт FlagOS в CSDN (подробности в приложении)

Индекс

    1. Прогресс открытых проектов (динамика GitHub)
      • 1.1 FlagSparse «more backends»: матрица бэкендов расширена до пяти — MetaX реализован, Moore Threads/Ascend зарегистрированы, миграция абстракции устройств в 269 местах (09-05)
      • 1.2 build-infra: линия поставки vLLM — пакетная регистрация двух линий SDK Enflame и тегов образов Cambricon, сборка wheel переведена на механизм host-side патчей, Iluvatar внедряет путь attention FlagGems (09-05/09-06)
      • 1.3 build-infra: локализована первопричина искажённого вывода при первом холодном запуске Cambricon 0.20.2 — flag_gems copy_ отравляет состояние устройства MLU, реальная поставка после исправления чёрным списком (09-05)
      • 1.4 build-infra: управление холодным запуском sglang 0.5.18 — реализованы регулятор тайм-аута/гейтинг готовности/watchdog, полная запись поставки Moore Threads 0.5.18 (09-05/09-06)
    1. Новости и экосистема
      • 2.1 Компонентные новости: четвёртое подряд спокойное окно, нулевые попадания в окне поиска (09-05~09-06)
      • 2.2 Справочник по экосистеме: сообщество Zhiyuan перепечатало круглый стол по SGLang — «верифицируемость — следующий узкий момент» (09-05)
    1. Углублённый анализ участников
      • 3.1 У участников нет новой динамики в окне (09-05~09-06)
      • 3.2 Предыстория команды соразработки FlagSparse: двухканальный AlphaSparse от Института вычислительной техники КАН продолжает вливаться (09-05)
    1. Итоги
  • Приложение: полный список источников

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

Обзор окна: из 52 репозиториев организации 7 имели push в окне, поиск по коммитам дал 21 коммит в окне (build-infra 17, FlagSparse 4); проверка tags/releases: в окне нет новых tag, нет новых release (FlagSparse v0.3.0-rc0.post1 опубликован 09-01 — до окна, vllm-plugin-FL v0.3.0-rc0 опубликован 08-24, FlagGems v5.4.0.dev0, серия FlagTree v0.4.0, build-infra v2.1.1 — все раньше); изменения pushed_at у docs, release-info, sglang-plugin-FL, vllm-plugin-FL, FlagTree по проверке коммитов ветки по умолчанию оказались действиями в не-дефолтных ветках (ветках PR), без существенных слияний в окне — период стабильных релизов 2.2 продолжается. Главные линии этого окна: 1. FlagSparse (библиотека разреженных операторов): матрица бэкендов расширена с двух (CUDA/DCU) до пяти — «more backends» (PR #51) завершил миграцию абстракции устройств (абстрагировано 269 вызовов CUDA-specific), бэкенд MetaX (MACA/Сийюнь C550) реализован в форме «перенос с CUDA + имитационная верификация» и прошёл spsv v0.1, Moore Threads (MUSA) и Ascend (CANN) зарегистрированы как provisional-бэкенды; 2. линия поставки vLLM в build-infra вступила в фазу «семантической верификации холодного запуска и аудита поставки» — первопричина искажённого вывода при первом холодном запуске Cambricon 0.20.2 полностью локализована (flag_gems copy_ отравляет состояние устройства MLU) и после итеративного исправления через чёрный список выполнена реальная поставка (опровергнут ложноположительный зелёный статус от 08-26 без семантического гейта); 3. путь поставки Iluvatar определён как приоритет F-пути (FlagGems) — включена старая линия поддержки 0.20.2 + внедрение VLLM_FL_USE_FLAGGEMS_ATTN=1 + патч guard импорта symm-mem, что замыкает контур с вердиктом 09-04 «T-путь не поставляется».

1.1 FlagSparse «more backends»: матрица бэкендов расширена до пяти — MetaX реализован, Moore Threads/Ascend зарегистрированы, миграция абстракции устройств в 269 местах (09-05)

Источники: FlagSparse PR #51 (dc076010b2), commit 41c7c102 (spsv on metax v0.1), docs/METAX_TESTING.md, README матрица бэкендов

  • 09-05 10:59~12:18, в ветке по умолчанию FlagSparse подряд 4 коммита (прямой push 41c7c102/7f41348d + апстрим merge 0cad7f78 + PR #51 “more backends”, влит в 12:18, всего 23 файла), все от внешней команды разрежённых вычислений NCIA-AlphaSparse (домен почты коммитов ict.ac.cn, происхождение — Институт вычислительной техники Китайской академии наук; NCIC-AlphaSparse — зеркало их upstream org, см. 3.2). Это реализованная версия коммита fb18e881 “metax musa ascend added, need to check” от 09-04 11:11 (начало до окна), пропущенного во вчерашнем отчёте.
  • Матрица бэкендов и миграция абстракции устройств: в README добавлена таблица пяти бэкендов — CUDA / DCU(ROCm) / MetaX(MACA, Xiyun C550) / Moore Threads(MUSA) / Ascend(CANN 910B); в sparse_operations/ 269 CUDA-специфичных вызовов абстрагированы (189 заменены на _ACCEL.* + 82 на _is_accel_tensor()). У CUDA/ROCm/MACA _ACCEL разрешается в torch.cuda, побайтово эквивалентно, zero kernel changes; Moore Threads и Ascend из-за того, что torch.musa/torch.npu не являются CUDA-совместимыми типами устройств, временно откатываются на torch.sparse (помечено provisional).
  • Механизм детекции MetaX: MACA совместим с исходниками CUDA (на машине torch.version.cuda имеет значение, torch.version.hip — None), существующие критерии ROCm не могут отличить MetaX от NVIDIA — детекция идёт по уровням: переменная окружения FLAGSPARSE_BACKEND → специфичный для MetaX атрибут torch.version → окружение MACA SDK (MACA_PATH/HOME) → имя устройства / строка модели C550; в документации рекомендуется явный pin на реальной машине (FLAGSPARSE_BACKEND=metax, FLAGSPARSE_MACA_MODEL=c550).
  • Статус реализации MetaX (честное заявление): 09-05 10:59 “spsv on metax v0.1” — разрежённое треугольное решение (spsv) запустило первую версию на бэкенде MetaX (изменения spsv.py и тестовой документации); однако добавленная документация на 274 строки METAX_TESTING.md явно указывает: путь MetaX “ни строчки не запускался на реальной машине”, код перенесён с пути CUDA, проверены только импорт/синтаксис/пути диспатча (эмуляция на машине NVIDIA с FLAGSPARSE_BACKEND=metax), цель документации — запустить на реальной машине и заменить параметры тюнинга на измеренные значения.

Толкование: FlagSparse в цикле 2.2 после первого завершения RC tag (v0.3.0-rc0.post1, 09-01) быстро дополнил матрицу бэкендов — поддержка DCU, вливаемая той же внешней командой с 8/20 (cuda/dcu merge → dcu tests → dcu bsr spmv/spmm), расширилась до пяти бэкендов MetaX/MUSA/Ascend. Три момента заслуживают внимания: во-первых, слой абстракции устройств (паттерн _ACCEL) превращает “добавление бэкенда” из изменения операторов в изменение детекции и диспатча — это ключевое архитектурное решение для мультичиповости разрежённых библиотек; во-вторых, MetaX идёт по пути “перенос CUDA + эмуляционная верификация” вперёд, с документированием верификации на реальной машине в качестве следующего шага, что соответствует инженерному ритму FlagGems/build-infra “сначала регистрация, потом верификация” — это чётко помеченный provisional-релиз, а не преувеличенное заявление; в-третьих, разрежённые библиотеки и FlagTree (DSA от Qingwei, 09-04), build-infra (матрица образов) одновременно продвигают мультичиповость, “расширение бэкендов” цикла FlagOS 2.2 разворачивается на всех уровнях компонентов.

1.2 build-infra: линия поставки vLLM — пакетная регистрация двух линий SDK Enflame и тегов образов Cambricon, переход сборки wheel на механизм host-side патчей, внедрение пути attention FlagGems для Iluvatar (05–06.09)

Источники: #742 (e810bc2362), #743 (d8e6dba980), #744 (6c8dddab33), #745 (546d46e5ad), #750 (0b8f6205ce), #753 (f64f4af640)

  • Пакетная регистрация тегов application-образов: 05.09 21:24/21:29 #742/#743 одновременно зарегистрировали для двух линий SDK Enflame — enflame-tops1.10.6 и tops1.9.10 — тег application-образа vllm 2.1.2-0.2.1_gc2e496d.d20260905 (один и тот же отпечаток исходников плагина в обеих линиях инструментария Enflame); в 22:01 #744 зарегистрировал тег 2.1.2-0.2.1_gcab2270.d20260905 для cambricon-neuware4.4.3 — этот образ и есть поставка исправленной версии с устранением искажённых символов, о которой говорилось в 1.3 (plugin wheel 0.2.1+gcab2270).
  • #745 (22:08): сборка vLLM wheel переведена на механизм host-side source patch — после загрузки/распаковки/наложения патчей на tarball с исходниками на хост-машине сборочный контейнер лишь использует уже пропатченное дерево исходников для сборки empty wheel и repack (существующий механизм в образах packaging/sglang; ограничения явные: патчи не накладываются внутри контейнера, изменения остаются в зоне аудита сборки; при недействительности hunk патча происходит loud fail, что предотвращает утечку непропатченного wheel). Попутно подтверждено, что с 2026-08-23 nvidia также унифицирована на режим empty (сборка из исходников), а режим pip-загрузки официального wheel выведен из эксплуатации. Первый патч 0001: для верхнеуровневого импорта с побочным эффектом torch.distributed._symmetric_memory в vllm/distributed/parallel_state.py добавлен guard try/except — в vendor torch ниже 2.8 (iluvatar corex 2.7.x) этот модуль отсутствует, и импорт на уровне модуля прервал бы запуск движка до срабатывания любого guard плагина; symm-mem используется в vLLM только при явном opt-in (по умолчанию отключён при развёртывании), поэтому guard безопасен и универсален.
  • Форма поставки Iluvatar зафиксирована: #750 (23:32) включает application vllm 0.20.2 старой сопроводительной линии для corex4.4.0; #753 (06.09 09:44) внедряет в окружение application vllm для corex4.4.0 переменную VLLM_FL_USE_FLAGGEMS_ATTN=1 (принудительное использование attention FlagGems).

Толкование: в сочетании с вынесенным 04.09 в #722 вердиктом «путь T в iluvatar 0.24.0 не поставляем», build-infra за считанные дни выстроил для Iluvatar полноценную поставочную форму с приоритетом пути F: включение application старой сопроводительной линии (0.20.2) плюс принудительное внедрение FlagGems attention, что позволяет вычислениям внимания и сэмплирования обойти дефект apply_top_k_top_p в проприетарном пути Triton; guard symm-mem из #745 дополнительно устраняет падение движка при запуске из-за отсутствующего модуля в vendor torch 2.7.x. Следует отметить, что все эти обходные решения реализованы на уровне wheel (патч запечён в сборку) и на уровне окружения (внедрение env), а исправление самого пути T по-прежнему остаётся задачей на стороне плагина — расхождение «F поставляем, T ждёт исправления» продолжает накапливаться в записях.

1.3 build-infra: локализация первопричины искажённого вывода при холодном первом запуске Cambricon 0.20.2 — копирование flag_gems copy_ отравляет состояние устройства MLU, после исправления чёрным списком — реальная поставка (09-05)

Источники: build-infra #748 (caccf829a3) (новая запись повторной проверки в cambricon.md), vllm-plugin-FL PR #411

  • Начало события: поставка vLLM 0.20.2 для cambricon-neuware4.4.3 была 26.08 помечена как «E2E пройдено» — но тогда не было семантического контроля, зелёная отметка матрицы оказалась ложноположительной. 05.09 при повторной проверке релизного app-образа с помощью «семантического якоря холодного первого запуска» (проверка семантики в холодном состоянии на промптах с известными ответами) выявился искажённый вывод; только после исправления поставку можно считать реальной.
  • Первопричина: LibTuner.run() из libentry.py в flag_gems 5.3.5 в ветке cache-miss config DB запускает онлайн-бенчмарк с таймингом на живых тензорах декодирования (шторм сброса кэша в triton do_bench) → отравление состояния устройства MLU → искажённый вывод при холодном первом запуске (пустая config DB) (воспроизводимый фрагмент «enim enim enim…»); при тёплой DB (попадание в кэш) вывод чистый. Специфично для 0.20.2 — 0.24.0 на том же стеке среды исполнения чист; и это не проблема argmax (после исключения argmax через чёрный список искажение сохраняется).
  • Путь исправления (решение пользователя): идти по существующему в репозитории методу итерации чёрного списка (поочерёдный откат отравляющих операторов на torch_mlu), не менять поведение bench в libentry — в одной из итераций была попытка заменить онлайн-бенчмарк на одиночный запуск без тайминга (эквивалент пути «первого компилируемого config»), на практике искажение устранилось, но пользователь отклонил (не модифицировать семантику upstream tuning).
  • Цепочка определения (холодный = каждый раз очищать flag_gems config DB): только чёрный список index → искажение сохраняется; убрать copy_+to_copy → искажение воспроизводится дословно; вернуть copy_ → чисто; copy_ отдельно / copy_+index → чисто. Минимальный отравляющий набор = flag_gems copy_; to_copy/fill/add/sub/fused-norm в запросах по-прежнему проходят bench, но безвредны.
  • Фиксация в репозитории и поставка: vllm-plugin-FL PR #411 (amend) расширяет flagos_blacklist в cambricon.yaml с [index] до [index, copy_] → head cab2270 → plugin wheel 0.2.1+gcab2270.d20260905; откат copy_ на torch_mlu для 4.7.2/0.24.0 семантически эквивалентен (общий config, downstream уже прошёл аудит), пропускная способность первого запроса около 1.3 tok/s без существенных потерь. Итоговая поставка app-образа 2.1.2-0.2.1_gcab2270.d20260905 (встроенная в config форма, без env чёрного списка); полностью холодная повторная проверка (перед serve удалить ~/.flaggems и ~/.triton): первый запрос 200/168 секунд (включая покомпиляцию по каждому shape) с чистым выводом, горячий запрос 200/2 секунд/7.75 tok/s; этот бэкенд в форме T-only (в 4.4.3 нет FlagTree).
  • Сопутствующий опыт: с 4.4.3 при serve обязательно монтировать напрямую /dev/cambricon_devN, в форме env MLU_VISIBLE_DEVICES=N устройство невидимо и происходит досрочный выход; семантический якорь холодного первого запуска — единственный надёжный критерий отравления онлайн-бенчмарком libentry, тёплые запросы его не выявляют; первопричина (libentry не должен выполнять бенчмарк с таймингом на живых тензорах) ожидает исправления в upstream flag_gems, чёрный список — переходное решение.

Толкование: это знаковая запись build-infra о повышении «верификации» с зелёных отметок/записей матрицы до семантической верификации в холодном состоянии — публичное признание ложноположительного результата отсутствия семантического контроля от 26.08, приведение воспроизводимой цепочки определения (дословное воспроизведение c1-c7) и чёткое очерчивание границ исправления (переходный чёрный список, без изменения семантики upstream, первопричина оставлена flag_gems). Такие «негативные записи + процедура повторной проверки» — именно фундамент достоверности многопроцессорных поставок, и вместе с записью от 04.09 о непригодности к поставке T-пути Iluvatar (#722) они принадлежат основной линии инженерного аудита цикла 2.2.

1.4 build-infra: управление холодным запуском sglang 0.5.18 — ручки тайм-аута/гейтинг готовности/watchdog внедрены, запись поставки Moore Threads 0.5.18 полная (09-05/09-06)

Источники: #737 (6dd6e454d4), #738 (c89a8e5e32), #739 (db50808507), #740 (11f18b8401), #741 (a0df0db9b6), #747 (5ce0796cc2), #749 (1569ce4057), #751 (e46627a1fa), #754 (b353ca3181), #755 (f9de45819c)

  • Инженеризация валидации холодного старта (cold-start) (05.09 12:28–18:15, #737-741): предыстория — после того как 04.09 прикладное окружение sglang 0.5.18 было развёрнуто на Cambricon/Enflame, тайминги запуска/готовности при холодном первом запуске (пустой кэш) стали нестабильными, и скрипт валидации не мог отличить «всё ещё warmup» от «завис намертво». В рамках окна последовательно выполнено: #737 — добавлен параметр тайм-аута холодного старта в скрипт валидации → #738 — фактическая передача параметров в app verify для Cambricon → #739 — гейтинг готовности признаёт только первую строку вывода после warmup → #740 — cold-start watchdog встроен непосредственно в образ sglang app для Cambricon (самовосстановление внутри контейнера, без зависимости от внешних скриптов) → #741 — зафиксирована реальность холодного старта для Cambricon/Enflame.
  • Завершение поставки sglang 0.5.18 для Moore Threads (mthreads): #747 (22:32) — в sglang deps_app для musa5.2.0 зафиксирована версия compressed-tensors; #749 (23:30) — зарегистрирован тег образа sglang app mthreads-musa5.2.0 2.1.2-0.1.dev1_g607b9672c; #751 (23:49) — зафиксирована поставка mthreads 0.5.18 (Moore Threads стала ещё одной компанией после Cambricon/Enflame/Moore Threads/Ascend с полной записью поставки sglang 0.5.18); #755 (06.09 10:05) — для старой линии musa4.3.6 также зафиксирована версия compressed-tensors.
  • #754 (06.09 09:54): для Cambricon neuware4.4.3 добавлен sglang app config (линия 0.5.18 продолжает разворачиваться на тулчейне 4.4.3).

Толкование: динамика «регистрация-валидация-исправление» в многопроизводительной матрице sglang, начавшаяся 03.09, в этом окне продвинулась дальше — семантика cold-start вошла в скрипты валидации и в сам образ (три уровня: параметр + гейтинг + встроенный watchdog), что вместе с «семантическим якорем холодного первого запуска» из раздела 1.3 относится к одному и тому же методологическому обновлению: валидация поставки многопроцессорного инференса переходит от «способности запуститься» к «семантической корректности первого запроса в холодном состоянии». Синхронная фиксация compressed-tensors на двух линиях тулчейнов mthreads (5.2.0/4.3.6) — типичная деталь управления зависимостями.

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

2.1 Новости компонентного уровня — четвёртое подряд спокойное окно, ноль попаданий в окне мониторинга (05.09–06.09)

  • 13 групп запросов на китайском и английском в gnews (FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/Институт Zhiyuan/открытый исходный код Zhiyuan/BAAI и др., when:7d-14d) — прямых попаданий в окне нет; единственное многократно повторяющееся — статья Day0 сообщества Zhiyuan от 09-01 (Qwen/GLM/Hunyuan — три Day0 за четыре дня) в перепечатках на разных каналах — не новый контент, о нём уже сообщалось ранее. Продолжается загрязнение шаблонами букмекерского SEO по запросу “Институт Zhiyuan when:7d” (агрегаторы вроде Tiyutan/Gelonghui, заголовки вида “результаты матчей португальской Примеры/официальный сайт Mile m6 онлайн/предпочтительный сайт для игроков Aiying” и прочие шаблоны-подстановки; описания вроде 710B/приближение к GPT-4o — это фрагменты старых материалов 2024 года, вся партия удалена).
  • Поиск Tavily: релевантных сообщений о FlagOS в окне нет; последний контент официального аккаунта сообщества FlagOS на CSDN (flagos.csdn.net) — статья от 09-01 об адаптации GLM-5.3-Flash Day0 под девять чипов и запись трансляции от 09-03, обе до окна и из того же источника, что и сообщество Zhiyuan.
  • HN Algolia: по запросам FlagOS/FlagGems/FlagSparse/FlagTree — ноль релевантных попаданий (в основном шум вроде feature-flag), что совпадает с предыдущими днями.

2.2 Справочный экосистемный материал: сообщество Zhiyuan перепечатало круглый стол по SGLang — «Верифицируемость — следующий узкий места» (09-05)

Источник: Сообщество Zhiyuan (оригинал — Geek Park/Founder Park)

  • 09-05 сообщество Zhiyuan перепечатало подготовленную Geek Park стенограмму круглого стола AGI Playground 2026: Axiom Math (соучредитель и CTO Shubho Sangupta), Radixark (ключевой технический участник Бао Кэ, компания инфраструктуры инференса на базе открытого фреймворка SGLang), SoTALab (соучредитель Юй Линьси) в разговоре о «верифицируемом AI» — для длинных задач агентов (успешность цепочек длиннее 50 шагов обвально падает) нужны пошаговая верификация и мелкозернистые награды (обратная связь в стиле доказателя теорем Lean), инфраструктура инференса нуждается в апгрейде до production-уровня (задержка первого токена, SLO межтокенного интервала, стресс-тестирование), а верифицируемость может оказаться следующим настоящим узким местом развития AI.

Толкование: связь с FlagOS слабая (SGLang — вышестоящий фреймворк для sglang-plugin-FL), но материал включён как экосистемный фон — в связке с «семантической якорной верификацией холодного старта» из 1.3/1.4 видно, что «верификация» одновременно становится ключевым словом и для сообщества фреймворков инференса, и для инженерных поставок FlagOS, направление совпадает (верифицируемые, прослеживаемые, заслуживающие доверия поставки), различается лишь гранулярность (у первых — уровень результата, у вторых — уровень развёртывания).

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

3.1 У участников нет новых динамик в окне (09-05~09-06)

  • Основные линии участников, о которых сообщалось вчера (отчёты 09-04/09-05) — завершение формирования цены размещения Enflame и график выхода на прибыль, GPU «Лушань» от Moore Threads и результаты H1/сотрудничество с Qubing по PD, разбор выхода из убытков на бумаге у MetaX и Tianshu Zhixin, найм software-специалистов в Cambricon — в этом окне не имеют последующих новых сообщений. Поиск по новостям (включая запросы по ключевым словам участников на китайском и английском) — ноль попаданий.
  • Динамики участников по компонентной части (подробно в главе 1 настоящего отчёта): Cambricon (0.20.2/0.24.0/sglang 0.5.18 — верификация и поставка исправлений кракозябр), Tianshu Zhixin (включение старой линии 0.20.2 + инъекция FlagGems attention), Enflame (регистрация зеркал двух линий SDK tops1.10.6/tops1.9.10), Moore Threads (поставка sglang 0.5.18 + фиксация compressed-tensors), MetaX (регистрация бэкенда FlagSparse MetaX, см. 1.1) — у всех есть динамика уровня коммитов — «настоящие динамики» участников сосредоточены в матрице поставок build-infra и бэкендах библиотек операторов, что контрастирует с затишьем в новостной плоскости.

3.2 Предыстория команды со-разработки FlagSparse: двухканальное непрерывное вливание AlphaSparse из Института вычислительной техники КАН (09-05)

  • Все 4 коммита FlagSparse в окне — от внешней команды разреженных вычислений: аккаунт коммитов NCIA-AlphaSparse, домен почты ict.ac.cn (Институт вычислительной техники КАН), её org NCIC-AlphaSparse выступает как вышестоящее зеркало (PR #51 влит именно из NCIC-AlphaSparse/main), команда также имеет право прямой отправки в flagos-ai/FlagSparse — со-разработка по двум каналам: «вливание из вышестоящего зеркала + прямая отправка в репозиторий».
  • Хронология: 8/20 “cuda and dcu merge” → 8/22 dcu tests (PR #45) → 8/24 dcu bsr spmv/spmm → 8/27 объединение структур spsv/spmm → 9/1 v0.3.0-rc0.post1 → 9/4-9/5 бэкенды metax/musa/ascend — каждая способность бэкендов после DCU идёт от этой команды, это репрезентативный кейс FlagOS в направлении разреженных вычислений по модели «участники + научные институты, краудсорсинг со-разработки» (ранее в ежедневных отчётах уже фиксировался их вклад в DCU, в этом окне восполнен командный фон: домен почты ict.ac.cn указывает на Институт вычислительной техники КАН).

4. Итоги

В данном окне (09-05 10:18 ~ 09-06 10:18) новостная сторона представляет собой четвёртое подряд спокойное окно (gnews/Tavily/HN — ноль попаданий внутри окна, только SEO-шаблонный мусор и перепосты старых материалов), однако на стороне GitHub продолжается инженерное продвижение цикла 2.2, три основные линии:

  1. Матрица бэкендов FlagSparse расширена до пяти участников (PR #51, 09-05): миграция абстракции устройств в 269 местах, MetaX (Moore Threads MACA/C550) реализован по схеме «перенос CUDA + симуляционная верификация» и успешно прошёл spsv v0.1, Moore Threads/Ascend зарегистрированы как provisional-бэкенды — мультичиповая экспансия библиотеки разреженных операторов и внешняя очередь (AlphaSparse от Института вычислительной техники КАН) продолжают задавать темп версионирования компонентов (держатель первого RC-тега 2.2).
  2. build-infra: инженерная поставка обновлена до «верификации семантики холодного состояния»: завершена локализация корневой причины искажённых символов при первом холодном запуске Cambricon 0.20.2 (отравление copy_ в flag_gems, промежуточная блокировка [index, copy_], исправление на стороне upstream в очереди), публично опровергнут ложноположительный результат семантических ворот без семантики от 08-26; линия sglang 0.5.18 включает трёхуровневое управление холодным стартом: таймаут-ручка/гейт готовности/встроенный watchdog.
  3. Путь поставки Iluvatar CoreX зафиксирован как приоритет F-пути: старая линия 0.20.2 + VLLM_FL_USE_FLAGGEMS_ATTN=1 + symm-mem guard, исправление T-пути (вендорный Triton) отложено на сторону плагина.

Прогноз совпадает со вчерашним: цикл 2.2 rc0 находится в середине «верификация — простановка тега — запись»; следующий сигнал о релизе по-прежнему зависит от действий в репозитории списка community и version bump в build-infra; следующей возможной точкой на новостной стороне компонентов является официальный срез rc линии 2.2 или адаптация следующей Day0-модели.

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

Источник Результат проверки
GitHub org repos API (flagos-ai, 52 репозитория) Push в 7 репозиториев внутри окна; docs/release-info/sglang-plugin-FL/vllm-plugin-FL/FlagTree по коммитам ветки по умолчанию подтверждены как действия в PR-ветках
GitHub commit search (org полностью, 21 запись) build-infra 17, FlagSparse 4; проверены время коммиттера и содержимое по каждой записи
GitHub tags API + проверка дат Новых тегов внутри окна нет (FlagSparse v0.3.0-rc0.post1 до 09-01, серия FlagTree v0.4.0 — 2026-01, build-infra v2.1.1 — 08-03 и т. д.)
GitHub releases API Новых релизов внутри окна нет (FlagSparse v0.3.0-rc0.post1 выпущен 09-01 02:02 CST, до окна)
FlagSparse PR #51 / commits / METAX_TESTING.md Матрица бэкендов, миграция абстракции устройств, статус реализации MetaX и механизм проверки (полный текст патча проверен)
build-infra commits #737-755 17 записей проверены поштучно (записи и исправления по обеим линиям поставки vllm/sglang)
vllm-plugin-FL PR #411 Блокировка cambricon [index, copy_] зафиксирована в репозитории (проверка перекрёстных ссылок между репозиториями)
Google News RSS (13 групп на китайском и английском, через прокси) Ноль попаданий внутри окна; шаблонный мусор беттинг-SEO исключён целиком; перепосты старых материалов Day0 от 09-01 не являются новым контентом
HN Algolia (4 группы запросов) Ноль релевантных попаданий
Tavily web-поиск (4 группы) Нет репортажей о FlagOS внутри окна; последнее на flagos.csdn.net — контент от 09-01/09-03
Сообщество Zhiyuan hub.baai.ac.cn 09-05 перепост круглого стола SGLang от Geek Park (экосистемная справка, слабая релевантность)