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

Индекс

    1. Прогресс открытых проектов (динамика GitHub)
      • 1.1 FlagGems-sglang: первая партия операторов конкурсных задач включена — 7 операторов SGLang Triton, 3 команды, пакетное внедрение сопутствующих benchmark и эталонных реализаций (09-06)
      • 1.2 build-infra: уникализация ветки записи тегов образов по бэкендам, контроль запуска по записям поставки (09-06)
      • 1.3 FlagCX: исправление зависания UIL p2p и шлюз CICD без ускорителей (09-06)
    1. Новости и экосистема
      • 2.1 Компонентные новости: пятое подряд спокойное окно, ноль попаданий в окне поиска (09-06~09-07)
    1. Углублённый анализ участников
      • 3.1 Iluvatar CoreX: регистрация образов двух линеек SDK 0.20.2 в один день, принудительный путь attention переведён с внедрения через env на конфигурацию плагина (09-06/09-07)
      • 3.2 Enflame: в tops1.9.10 открыта линия sglang 0.5.18, различия зависимостей явно зафиксированы pin (09-06/09-07)
      • 3.3 Moore Threads: запись поставки musa4.3.6 sglang 0.5.18 дополнена (09-07)
    1. Итоги
  • Приложение: полный список источников

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

Обзор окна: из 52 репозиториев организации 8 имели пуши в окне, commit search дал 25 коммитов в окне (FlagGems-sglang 13, build-infra 10, FlagCX 2), фактическое включение в default branch сосредоточено в указанных 3 репозиториях; изменения pushed_at в vllm-plugin-FL, sglang-plugin-FL, FlagTree, docs, release-info по коммитам default branch проверены и все являются действиями в не-default ветках (ветках PR), без фактического включения в окне. Проверка tags/releases показала отсутствие новых tag и новых release в окне (FlagCX v0.14.0-rc0.post1 создан 08-27, vllm-plugin-FL v0.3.0-rc0 создан 08-24, у FlagGems-sglang только v0.1.0-rc0.post1, build-infra v2.1.1 создан 08-03 — все до окна) — продолжается спокойный период релизов из п. 2.2. Основные линии окна: 1) FlagGems-sglang впервые получил включение результатов внешних конкурсных задач — первая партия из 7 операторов, созданных в рамках «Конкурса оптимизации операторов FlagOS X SGLang» (второй сезон, первая дорожка), была включена 3 командами в официальный репозиторий в предписанном формате PR, после чего мейнтейнеры пакетно внедрили сопутствующие benchmark/эталонные реализации и удалили устаревшие операторы — конвейер конкурса «пакетное ревью → захват → включение PR» впервые прошёл полностью; 2) два инженерных исправления самой системы записей поставки build-infra (конфликт ветки записи, ложные срабатывания на стартовой странице); 3) коррекция направления пути поставки iluvatar от Iluvatar CoreX — утверждённое накануне решение «внедрять переменные окружения FlagGems attention на уровне приложения» отменено, детерминированное исправление опущено в конфигурацию плагина в PR #450 vllm-plugin-FL (чёрный список silu_and_mul + откат к семплингу PyTorch + guard symm-mem), регистрация образов 0.20.2 для corex4.4.0 и 4.5.0 выполнена в один день.

1.1 FlagGems-sglang: первая партия операторов конкурсных задач включена — 7 операторов SGLang Triton, 3 команды, пакетное внедрение сопутствующих benchmark и эталонных реализаций (09-06)

Источники: PR #33 silu_and_mul, PR #34 causal_conv1d_fn, PR #37 chunk_local_cumsum_scalar, PR #38 merge_state, PR #39 per_group_transpose, PR #40 mrope_fused, PR #41 fused_moe_gemm, PR #54 сопроводительное внедрение batch1, PR #55 очистка, объявление о соревновании (21.08, см. CSDN)

  • Событие: 06.09 20:22–20:25 (пекинское время), репозиторий FlagGems-sglang за 4 минуты подряд принял 7 PR, оформленных по стандарту [FlagOS Competition-Track1] Add ... Triton Kernel for sglang, из трёх независимых форков контрибьюторов: yzw1128 (silu_and_mul #33, causal_conv1d_fn #34), xuanzhengdu-eng (chunk_local_cumsum_scalar #37, merge_state #38), c2flowDS (per_group_transpose #39, mrope_fused #40, fused_moe_gemm #41). Проверка показала, что среди всех 42 closed PR этого репозитория ранее не было ни одной записи о слиянии Competition — это первая партия операторов соревновательных задач, попавшая в официальный репозиторий с момента запуска соревнования (объявление о старте 21.08).
  • Сопроводительное внедрение: в 20:35 мейнтейнер liuhycs (Hongyu Liu) принял внутренний пакетный PR #54 “Flagos sglang batch1” (7 коммитов / 30 файлов / +2947 строк), который добавил для 7 новых операторов benchmark-тесты (семь групп benchmark/test_.py) и документацию по разработке (семь файлов docs/tasks/.md), а также разместил эталонные реализации в src/flaggems_sglang/reference/; в 22:08 был принят #55 “Remove deprecated operators and simplify benchmark utilities”, удаляющий устаревшие операторы и упрощающий инструменты бенчмаркинга. Ранее в 12:08/12:23 также были исправления, связанные с #44 — code style и импорт в тестах mrope_fused.
  • Контекст правил соревнования (старт уже зафиксирован в ежедневном отчёте от 23.08, здесь дополняются элементы замкнутого цикла): этот конкурс — трек 1 второго сезона глобального соревнования FlagOS Open Compute, совместно организованного сообществом Zhongzhi FlagOS и IEEE, при содействии SGLang, а также промышленных партнёров — MetaX/Kunlunxin/China Supercomputing Network и др.; более 200 реальных задач по операторам инференса SGLang разблокируются 13 партиями (старт фазы разработки 17.08, дедлайн 13.11, стандартный цикл партии — 7 дней), разработка ведётся на Triton/Triton-TLE, а единая оценка на нескольких чипах ранжируется по среднему коэффициенту ускорения; согласно правилам, после оценки каждой партии команда, получившая почётное звание «захвата», должна в течение окна мониторинга отправить код с наилучшими показателями в установленном формате через PR в FlagGems-sglang и подписать CLA — согласованность кода является обязательным условием для награды.

Толкование: семантический охват этих 7 операторов весьма типичен — silu_and_mul (слияние активаций), causal_conv1d_fn / chunk_local_cumsum_scalar / merge_state (свёрточные и состояния-ориентированные операторы SSM/Mamba-подобного типа), per_group_transpose / mrope_fused (групповой перенос и слияние mRoPE), fused_moe_gemm (слитый GEMM MoE) — они взаимно однозначно соответствуют реальным инференс-нагрузкам SGLang (гибридное внимание, MoE), что подтверждает установку соревновательной задачи «взято из реального инференс-бизнеса». Для FlagOS ещё важнее — первое замыкание цикла конвейера совместного построения сообществом: примерно через три недели после старта соревнования в середине августа первые результаты по правилам соревнования в унифицированном формате и по единым спецификациям кода вернулись в официальный репозиторий, а мейнтейнеры дополнили тесты и документацию — цикл коллективного разума операторов «открытая соревновательная задача → оценка на платформе → поощрение признанием → осаждение в официальном репозитории» начинает давать отдачу; при этом каждая партия (в дальнейшем оценка каждые 7 дней) будет приносить новый поток вливаемых PR, и FlagGems-sglang заменит FlagSparse, став новым окном наблюдения за «плотностью внешнего вклада» (внешняя очередь AlphaSparse в FlagSparse — это другой уже отлаженный канал коллективного разума, см. ежедневный отчёт от 09-05). Отдельно отметим, что silu_and_mul, отправленный yzw1128, одноимён с чёрным списком silu_and_mul flag_gems iluvatar в build-infra #763 (разные репозитории, разные предметные области, чистое совпадение).

1.2 build-infra: уникализация веток per-backend в записях тегов образов, гейтирование стартовой страницы по записям о поставке (09-06)

Источники: #756 (961c0fed), #759 (8f012fd4)

  • #756 (12:42): record_app_image_tag.py изначально накапливал все записи в единой общей ветке auto/app-image-tag, и любой исторически оставшийся открытый PR с записью (любое app/бэкенд) блокировал все последующие записи конфликтом rebase (запись mthreads-musa4.3.6 как раз один раз упала с run 34009399235) — изменено на вывод отдельной ветки per-record по auto/app-image-tag-<backend>-<app-key>, записи развязаны друг от друга.
  • #759 (14:48): gen_data изначально генерировал стартовую страницу app лишь по факту наличия ключа deps_app в configs, но ключ добавлялся до завершения валидации (чтобы запустить сборку), из-за чего невалидированные бэкенды (пример: vllm0.20.2-iluvatar-corex4.4.0, где deps_app есть, но launch_docs=false, cells не валидированы) тоже просачивались на стартовую страницу и попадали в каждый образ app — изменено на гейтирование по записи матрицы launch_docs, для невалидированных бэкендов стартовая страница больше не генерируется.

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

1.3 FlagCX: исправление p2p hang в UIL и гейт CICD без ускорителя (09-06)

Источники: PR #542 (511cdace, taozhiwei), PR #568 (8737bab4, MC952-arch)

  • #542 (влит в 20:21): [UIL] исправлена проблема зависания p2p при домене связи больше 2 — PR сопровождается полным воспроизведением в unittest (сценарий многорангового send_receive), относится к исправлению дефекта сходимости UIL (унифицированного коммуникационного слоя) при масштабировании на межкарточные топологии. Домен связи (communication domain) больше 2 означает, что этот путь ориентирован на реальную много-GPU кластерную топологию, а не на сценарий отладки «один к одному».
  • #568 (влит в 21:50): [CICD] пропуск API-тестов в среде без ускорителя — CI на раннерах без подключённого GPU/ускорителя больше не выполняет API-тесты, зависящие от железа, что позволяет избежать ложных падений/ложных прохождений; гейт тестов адаптируется к среде выполнения.

Разбор: после того как FlagCX 27-08 завершил полный цикл FlagOS Enflame collective (#554) и выпустил v0.14.0-rc0.post1, в данном окне два коммита представляют собой соответственно функциональный конвергентный фикс (зависание p2p в нескольких доменах) и инженерную оптимизацию CI (адаптивный гейткипинг без карт) — в том же ритме, что и build-infra: расширение функциональности временно приостановлено, приоритет отдан качеству верификации и поставки, что соответствует характеристикам завершающей фазы цикла 2.2 rc0 «верификация — простановка тега — фиксация».

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

2.1 Пятое подряд спокойное окно на уровне компонентных новостей, нулевые попадания в окне мониторинга (06-09~07-09)

Источники: Google News RSS (12 групп запросов на китайском и английском, через прокси), HN Algolia (4 группы), поиск Tavily/web (соревнования, динамика Zhiyuan, несколько групп), сообщество Zhiyuan, официальный аккаунт FlagOS в CSDN (подробности в приложении)

  • Комбинированные запросы gnews на китайском и английском (FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/FlagAttention/FlagCX/Zhiyuan Research Institute открытый исходный код/конкурс FlagOS when:7d~30d и др.) — нулевые попадания в окне; FlagOS when:14d возвращает лишь 3 старые публикации (перепечатки Day0 от 01-09 и др., уже освещённые/отфильтрованные), вся партия с шаблонным SEO-спамом букмекерской тематики отфильтрована.
  • HN Algolia (FlagOS/FlagGems/flagos-ai/FlagSparse) — ноль релевантных (шум от написания feature-flag); найденные через Tavily анонсы конкурса (SegmentFault/CSDN) и трансляция борьбы за «острова операторов» (03-09) — все до окна; последний контент официального аккаунта CSDN по-прежнему от 01-09 (GLM-5.3-Flash Day0) и 03-09 (запись трансляции), обновлений в окне нет.
  • Тренд за последние 3 дня (подтверждено pushed в GitHub org, на инженерной стороне неспокойно): 05-09 расширение матрицы бэкендов FlagSparse (MetaX/MUSA/Ascend, PR #51); 05-09~07-09 непрерывная регистрация поставок build-infra (реальная поставка исправления кракозябр для Cambricon 0.20.2, скользящая матрица образов для Iluvatar/Enflame/Moore Threads); 06-09 первая партия операторов, влитых в конкурс FlagGems-sglang (в этот день 1.1); в FlagCX/FlagTree/vllm-plugin-FL/sglang-plugin-FL присутствуют действия в ветках PR (FlagTree 07-09 в 10:14 всё ещё есть push, ветка по умолчанию остановилась на вливании бэкенда Qingwei 04-09).

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

3.1 Iluvatar: регистрация образов с двумя линейками SDK 0.20.2 в один день, принудительный путь attention сведён от инъекции через env к конфигурации плагина (06-09/07-09)

Источники: build-infra #763 (23e9681f, revert #753), #765 (bc18d971), #766 (7497b65b), vllm-plugin-FL PR #450 (tengqm, в процессе)

  • Корректировка пути (#763, 09-06 23:27): отменён только что внедрённый 09-06 09:44 в corex4.4.0 VLLM_FL_USE_FLAGGEMS_ATTN=1 (то есть #753, звено «финализация пути F» из вчерашнего ежедневного отчёта, раздел 1.2). Причина отмены однозначна: запечённый env — это старая идея «унифицированных переменных окружения», а сама проблема детерминизма flag_gems attention уже опровергнута — исправление детерминизма должно находиться на уровне конфигурации плагина (чёрный список flag_gems silu_and_mul, расположенный в vllm-plugin-FL PR #450 head 71b9482), и тест шлюза 4.5.0 подтверждает, что только чёрного списка silu достаточно для детерминизма обеих линий.
  • Одновременная регистрация поставки по двум линиям SDK (#765/#766, 09-06 23:51/23:59): corex4.4.0 и corex4.5.0 одновременно регистрируют тег образа vllm app 2.1.2-0.2.1_g71b9482.d20260906 (g71b9482 = отпечаток исходников vllm-plugin-FL PR #450 head) — 0.20.2 официально поставлен по обеим линиям инструментальных цепочек; #765 одновременно удаляет устаревшую заметку «путь F corex4.4.0 не поставляется (пробел во фронтенде triton)», заменяя её на «4.4.0 0.20.2 поставлен (guarded wheel)».
  • Исправление в процессе (vllm-plugin-FL PR #450, tengqm@BAAI, создан 09-05, обновлён 09-06 23:11): заголовок fix(iluvatar) pytorch sampler fallback + torch<2.8 symm_mem guard for corex (0.20.2). Содержание из двух пунктов: 587e2fe backport symm-mem stub guard (исправление из основной линии #434) и принудительное направление apply_top_k_top_p по пути отката к сэмплеру PyTorch (та же схема, что у iluvatar и metax), загружаемое через iluvatar/patches при импорте backend — host-side патч вчерашнего #745 на уровне колеса build-infra сводится к встроенному патчу плагина; ec9fded делает откат сэмплера зависимым от corex triton 3.1 fork (используется только на затронутых путях, 4.5.0/torch 2.10 сохраняет native-путь), классификация четырёх маршрутов распространения проверена. Покрывает corex4.4.0 и 4.5.0 (общее колесо).

Трактовка: Iluvatar CoreX — вендор с наиболее плотной активностью на стороне build-infra на этой неделе, и его путь поставки за два дня прошёл через одно направленное схождение: форма утра 09-05~09-06 была «старая линия обслуживания app + инъекция env на уровне приложения FlagGems attention + symm-mem guard на уровне колеса» (зафиксировано во вчерашнем ежедневном отчёте, раздел 1.2); вечером 09-06 практический тест шлюза (однопеременная проверка чёрного списка silu для 4.5.0) доказал избыточность инъекции env, откатил #753 и свёл исправление к конфигурации плагина (чёрный список) и патчу плагина (откат сэмплера/symm-mem stub) — точка исправления сместилась с «внешнего слоя поставки» (env/wheel patch) внутрь «самого плагина» (PR #450), и как только #450 будет влит, host-patch колеса на стороне build-infra, возможно, можно будет вывести из эксплуатации. Это также означает: дифференцированное суждение «F поставляется, T ждёт исправления» не изменилось (topk_topp по-прежнему остаётся корневой причиной отказа corex triton fork от native-ядра), изменилось лишь место приземления исправления и способ комбинирования.

3.2 Enflame (enflame): tops1.9.10 открывает линию sglang 0.5.18, различия зависимостей явно закреплены pin (09-06/09-07)

Источники: build-infra #761 (9113bbda), #768 (1fb6c0c5), #769 (79cc0937)

  • #761 (09-06 22:15): добавлен sglang app config для enflame-tops1.9.10 — линия 1.9.10 после «greedy topk fix» (sglang-plugin-FL PR #91) прошла проверку F/T и открыла поставку на стороне sglang; в конфигурации env.app.sglang намеренно не включён flashinfer, пропущена проверка shim, warmup 3600 (выровнено с зеркалом линии 1.10.6); и поскольку в 1.9.10 runtime отсутствует compressed-tensors (в 1.10.6 доступен через enflame-modelopt), для deps_app явно закреплена зависимость CT — различия зависимостей двух линий SDK одного вендора явно задокументированы.
  • #768 (09-07 00:01): зарегистрирован tag образа enflame-tops1.9.10 sglang app 2.1.2-0.1.dev1_g32eabf40e; #769 (00:17): в docs зафиксирована поставка enflame-tops1.9.10 sglang 0.5.18.

Разбор: линия поставки sglang 0.5.18 от Enflame официально открыта (ранее 09-05 #742/#743 регистрировали только два образа линий SDK на стороне vllm). Стоит отметить подход build-infra к «дрейфу зависимостей двух линий SDK одного вендора»: различия между 1.9.10 и 1.10.6 (наличие/отсутствие compressed-tensors, путь предоставления через modelopt) явно закреплены построчно, а не скопированы обобщённо — гранулярность конфигурационной дифференциации матрицы поставок для нескольких чипов достигла уровня зависимостей.

3.3 Moore Threads (mthreads): завершено пополнение записей о поставке musa4.3.6 sglang 0.5.18 (09-07)

Источники: build-infra #767 (b2c4799f), #770 (726e21fa)

  • #767 (00:00): зарегистрирован tag образа mthreads-musa4.3.6 sglang app 2.1.2-0.1.dev1_g607b9672c; #770 (00:24): в docs зафиксирована поставка mthreads-musa4.3.6 sglang 0.5.18 — ранее 09-05 #749/#751 уже включили содержимое поставки и конфигурацию compressed-tensors (#747/#755), а в данном окне tag образа и документация поставки замкнули цикл записи (вчерашний #756 исправлял именно сбой, когда эта запись Moore Threads была заблокирована общей веткой).

Разбор: записи о поставках трёх вендорных линий (Iluvatar vllm, Enflame/Moore Threads sglang) плотно легли в репозиторий в период с 09-06 22:15 по 09-07 00:24; вместе с исправлением развязки ветки записей в #756 это показывает, что регистрация поставок в build-infra входит в штатный режим «параллельного скольжения по нескольким бэкендам» — в цикле 2.2 rc0 изменений кода компонентов немного, но матрица поставок продолжает смещаться вправо.

4. Итоги

В данном окне (09-06 10:18 ~ 09-07 10:18) новостная сторона — пятое подряд спокойное окно (нулевые попадания в окне gnews/HN/Tavily, только SEO-мусор и перепосты старых статей), на стороне GitHub — 25 коммитов, 3 репозитория с фактическими слияниями, четыре основные линии:

  1. FlagGems-sglang получает первые результаты конкурса, конвейер Zhongzhi впервые замкнут (09-06 20:22~20:35): первые 7 операторов конкурсных задач (сезон 2, трек 1, старт 08-21) были объединены тремя командами (yzw1128, xuanzhengdu-eng, c2flowDS) в официальный репозиторий через PR согласно правилам конкурса — silu_and_mul, causal_conv1d_fn, chunk_local_cumsum_scalar, merge_state, per_group_transpose, mrope_fused, fused_moe_gemm, охватывающие типовые нагрузки SSM/слияния активаций/mRoPE/MoE; мейнтейнеры в тот же день дополнили benchmark, документацию разработки и эталонные реализации (#54, +2947 строк) и очистили устаревшие операторы (#55). Это первые в истории данного репозитория слияния Competition, конвейер «открытая конкурсная задача → оценка на платформе → завоевание награды → закрепление в официальном репозитории» впервые прошёл полный цикл, и последующие 13 партий будут приносить постоянный поток слияний.
  2. Путь поставки Iluvatar CoreX за два дня претерпел направленную конвергенцию: «инъекция env на уровне приложения для FlagGems attention» из #753 (окончательно оформленная вчера) в тот же вечер была отменена откатом в #763 на основе фактических испытаний шлюза, детерминированное исправление опустилось до конфигурации плагина в vllm-plugin-FL PR #450 (чёрный список flag_gems silu_and_mul) + патча плагина (откат сэмплирования topk_topp PyTorch, symm-mem stub guard, оба ограничены затронутыми путями corex triton 3.1 fork); corex4.4.0 и 4.5.0 с одинаковым отпечатком образа g71b9482 зарегистрированы в один день как официальная поставка 0.20.2 — точка приложения исправления сместилась с «внешнего слоя поставки» внутрь «самого плагина», и после слияния #450 wheel host-patch в build-infra, возможно, можно будет вывести из эксплуатации.
  3. Линия поставки sglang 0.5.18 расширяется горизонтально: открыт Enflame tops1.9.10 (#761/#768/#769, явный pin различия зависимостей при отсутствии compressed-tensors в 1.9.10), закрыт цикл записи Moore Threads musa4.3.6 (#767/#770); сама система записи build-infra завершила два исправления достоверности (#756 — развязка веток per-backend, #759 — стартовая страница по шлюзу launch_docs).
  4. Ритм завершения FlagCX продолжается: #542 исправляет зависание UIL p2p при домене связи >2 (с воспроизведением в unittest), #568 — адаптивный шлюз CICD без ускорителя.

Прогноз: как и вчера, цикл 2.2 rc0 находится в завершающей фазе «проверка — простановка тега — запись», следующий сигнал релиза по-прежнему зависит от действий репозитория списка community и version bump в build-infra; новая точка наблюдения: PR конкурсных операторов каждой партии (оценка раз в 7 дней) станут стабильным потоком внешнего вклада в FlagGems-sglang, 13 партий вплоть до 11-13, можно отслеживать ритм слияний и распределение типов операторов для оценки качества конкурса; после слияния vllm-plugin-FL PR #450 в основную ветку iluvatar конфигурационное исправление для Iluvatar CoreX 4.4.0/4.5.0 можно будет считать замкнутым.

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

Источники Результаты проверки
GitHub org repos API (flagos-ai, 52 репозитория) 8 репозиториев имели push в окне; vllm-plugin-FL/sglang-plugin-FL/FlagTree/docs/release-info по коммитам ветки по умолчанию проверены как действия в PR-ветках (FlagTree push 09-07 10:14, ветка по умолчанию остановилась на 09-04)
GitHub commit search (org полностью, 25 записей) FlagGems-sglang 13, build-infra 10, FlagCX 2; проверены построчно время committer и содержимое
GitHub PR API (FlagGems-sglang полностью + vllm-plugin-FL #450 + FlagCX #542/#568) Из 42 closed PR в Competition влито 7 (все 09-06, относятся к первой партии); #54/#55 сопутствующие; #450 в процессе open
GitHub tags/releases API + проверка дат В окне нет новых tag/release (FlagCX v0.14.0-rc0.post1=08-27, FlagGems-sglang v0.1.0-rc0.post1, build-infra v2.1.1=08-03, vllm-plugin-FL v0.3.0-rc0=08-24)
build-infra commits #756-770 10 записей проверены построчно (исправления инженерных записей поставки + регистрация трёхдневной поставки чипов + откат сходимости путей)
Объявления соревнований (CSDN/SegmentFault, 08-21) и регламент Предоставляют подтверждение предыстории соревнования 1.1 и правил именования PR (до окна, не новые новости)
Google News RSS (12 групп на китайском и английском, через прокси) Ноль попаданий в окне; шаблонное SEO-загрязнение от гемблинга исключено целиком; перепечатки старой статьи Day0 от 09-01 не являются новым контентом
HN Algolia (4 группы запросов) Ноль релевантных попаданий (шум feature-flag)
Tavily/web поиск (соревнования, Zhiyuan, производители, несколько групп) Нет репортажей о FlagOS в окне; объявление о конкурсе и трансляция “операторного острова” (09-03) — до окна
Сообщество Zhiyuan hub.baai.ac.cn / официальный аккаунт FlagOS в CSDN Последнее содержимое CSDN 09-01/09-03 (записано в предыдущий день), обновлений в окне нет