Research window: 2026-09-07 10:18 ~ 2026-09-08 10:18 Beijing Time Sources: GitHub (org: flagos-ai, 52 repos pushed_at + full verification of 91 commit search results by committer-date + per-repo default branch re-check + tags/releases/PR details), Google News RSS (14 query sets in Chinese and English, via proxy), HN Algolia, Tavily/web search, FlagOS official CSDN account (see appendix)

Index

  • I. Open-Source Project Progress (GitHub Activity)
    • 1.1 FlagOS 2.2 RC1 wrap-up: community publishes RC1 manifest, 25 manifest entries tagged in a batch with the first round of rc1.post1 verification tags (09-07)
    • 1.2 FlagScale triple play: KERV embodied speculative decoding training/inference integration, Megatron-LM v0.18.2 upgrade, CICD focus on training (09-07)
    • 1.3 FlagGems-Experimental: batch sync of KernelGen cross-backend operators into the repo + sync-to-kernelgen CI landed (09-07)
    • 1.4 FlagGems main repo: Hygon/Iluvatar fixes, QC fp8, external contributors and rollbacks (09-07)
    • 1.5 FlagGems-vllm: DAMO XuanTie PPU and Hygon dedicated fused-MoE backends (09-08)
    • 1.6 FlagBLAS: consecutive merges of Ascend L2 routines (CHER/CHER2/SSYR/CSYR) (09-07/09-08)
    • 1.7 FlagTree/FlagPrism: TLE multi-field pipe, CI/CD fixes, and debugging/profiling component merges (09-07)
    • 1.8 vllm-plugin-FL and FlagScale-Agent: FlagCX metrics connector, Agent reliability refactor (09-07/09-08)
  • II. News Coverage and Ecosystem
    • 2.1 FlagOS community “Open AI Computing” forum held alongside KubeCon + PyTorch Conference China in Shanghai (09-07)
    • 2.2 Sixth consecutive quiet window at the component level (09-07~09-08)
  • III. Member Company Deep Dive
    • 3.1 Tsingmicro: vllm-plugin-FL adds txda backend line, merged with vLLM 0.24.0 mainline (09-07)
    • 3.2 Iluvatar: 0.20.2 deterministic technical roadmap finalized — full-family blacklist for flag_gems GEMM family (09-07)
    • 3.3 MetaX and Cambricon: sglang 0.5.18 delivery line expanded (09-07/09-08)
    • 3.4 External ecosystem: Ascend verification records and from-scratch fixes, Kunlunxin KernelGen operators, sunrise new backend wiring (09-07/09-08)
  • IV. Summary
  • Appendix: Complete Source List

I. Open Source Project Progress (GitHub Activity)

Window Overview: Of the 52 repos in the org, 30 had pushes during the window, and commit search returned 91 in-window commits. Substantive merges to default branches were concentrated in 14 repos—community, FlagScale, FlagGems, FlagGems-vllm, FlagGems-Experimental, FlagBLAS, FlagTree, FlagPrism, FlagCX, Megatron-LM-FL, TransformerEngine-FL, vllm-plugin-FL, build-infra, and FlagScale-Agent—making this one of the most active windows recently. The headline event of this window is the official cut of FlagOS 2.2 RC1: at 09-07 11:11, community merged release/2.2/release-2.2-rc1.yaml (+252 lines, 25 manifest entries), followed by at least 12 repos pushing their first round of rc1.post1 verification tags in a burst between 11:22 and 11:33. Yesterday’s report’s prediction that “the next release signal still depends on action in the community manifest repo” was borne out within the window—and the action was larger than expected: not a version bump, but a release-pipeline switch from RC0 to RC1. On the component code side, the characteristics of the 2.2 test-stabilization period continued: the FlagGems operator matrix (new fused-MoE backends, Ascend L2, batch KernelGen syncs) and the FlagScale training stack (Megatron v0.18.2, KERV), plus verification fixes in the compiler and plugin layers.

1.1 FlagOS 2.2 RC1 Closeout: community publishes RC1 manifest, 25 manifest entries land alongside a burst of first-round rc1.post1 verification tags (09-07)

Sources: community PR #107 (703ea2184c, wbavon, merged 09-07 11:11), release-2.2-rc1.yaml, FlagSparse v0.3.0-rc1.post1 release (published 09-07 11:27), 2.2 schedule schedule_CN.md

  • Manifest merge: At 09-07 11:11, the community repo merged #107, adding release/2.2/release-2.2-rc1.yaml (252 lines) and switching the default manifest in .github/workflows/release-branch-tag.yml from 2.2/release-2.2-rc0.yaml to release-2.2-rc1.yaml. The manifest uses vcstool format and covers L0 infrastructure (flagtree × 3 Triton lines, flagcx) → L1 compute libraries (flaggems/flagfft/flagsparse/flagdnn/flagblas/flagtensor/flagaudio/flagattention/flaggems-vllm/flaggems-sglang) → L2 framework adaptation (torch-fl, vllm-plugin-fl × 2, sglang-plugin-fl, transformerengine-fl, megatron-lm-fl, flagos-compressor) → L3 application tools (flagscale, kernelgen, kernelgenbench, flagrelease), totaling 25 entries across 22 repos.
  • Key version anchors: flagcx v0.14.0-rc1.post1, flaggems v5.4.0-rc1.post1, flagscale v2.1.0-rc1.post1, kernelgen v2.2.0-rc1.post1, flagtree’s three lines unified at 0.7.0rc1.post1+triton{3.6|3.5|3.3}, and vllm-plugin-fl split into two lines (main tracking vLLM 0.24.0 → v0.3.0-rc1.post1; release/0.2 tracking vLLM 0.20.2 → v0.2.2-rc1.post1). The comments also record the engineering evolution from rc0 to rc1: FlagGems master has merged setuptools_scm only-version (upstream #5885), so post tags landing on master no longer trigger build failures—rc1 does not need the cherry-pick/tag-move remediation that rc0 required.
  • rc1.post1 tag wave: After the manifest merge at 11:11, at least 12 repos pushed in a burst within 11 minutes (FlagCX 11:22, FlagFFT 11:23, FlagSparse 11:27 with a release published, FlagTensor/FlagAttention/FlagGems-sglang/FlagAudio 11:28, Torch-FL 11:29, FlagOS-Compressor 11:31, KernelGen 11:32, KernelGenBench/FlagRelease 11:33), corresponding one-to-one with the manifest entries; none of these repos had substantive code merges to their default branches during the window (the tags API confirms rc1.post1 exists for all), i.e., this was a pure tag wave. The manifest header comment spells out the version evolution rule: each round of verification that passes gets an incrementing tag (rc1.post1 → rc1.post2 → …) with the version field written back, so .post1 marks “first round of verification passed.”

Interpretation: This is the third milestone signal in the FlagOS 2.2 release cycle—08-31 feature freeze (FEP gate closed), 09-01 entry into test stabilization (bug fixes only), and 09-07, when the RC1 manifest plus the first-round verification tag wave declared that the verification results of the rc0 integration segment have been frozen into the rc1 baseline. The schedule shows 09-01 to 09-24 as the multi-chip matrix testing window, with GA on 09-28; the RC1 cut comes 7 days after rc0, consistent with the expected cadence of “feature freeze → about a week of integration verification → rc1 freeze.” Two things stand out: first, the manifest’s entry granularity is finer than rc0’s (FlagTree’s three Triton lines and vllm-plugin’s two vLLM lines listed separately), indicating that the 2.2 delivery matrix genuinely covers multi-compiler/multi-framework version combinations; second, FlagGems’ upstream root-cause fix for the post-tag build issue (only-version) removes build noise from the rc cycle—post2/post3 iterations after RC1 will move faster. The implication for further observation: the next signal is the incrementing of each component’s rc1.postN (corresponding to round-by-round passes of the multi-chip matrix verification) and the RC-final/GA cut around 09-24; during RC1, component default branches can still take bug fixes, and external contribution streams such as the community challenge are unaffected.

1.2 FlagScale Triple: KERV embodied speculative decoding training/inference integration, Megatron-LM v0.18.2 upgrade, CICD focuses on training (09-07)

Sources: FlagScale PR #1278 (zhengzihaoPKU, merged 09-07 14:24), #1284 (b5741d04, 22:00), #1283 (b3708f0f, 10:34), Megatron-LM-FL #109 (e15cb692, 21:57)

  • KERV integration (#1278, 09-07 14:24): FlagScale merged training and inference integration for KERV embodied speculative decoding—adding LoRA/full-parameter training configs for the OpenVLA verifier, KERV draft data generation and drafter training, and LIBERO inference configs; in-process adaptation of KERV/OpenVLA’s public Python entry points (FlagScale orchestrates uniformly, producing no nested launchers); a bundled KERV control runtime (batch candidate generation, verification tree construction, relaxed acceptance, dynamic threshold adjustment, Kalman completion); the BF16 inference profile directly selects 14 KERV operators from the public runtime_opt package; and 33 model-agnostic unit tests (CI does not download checkpoints or start MuJoCo/LIBERO).
  • Megatron v0.18.2 upgrade (#1284 + Megatron-LM-FL #109, 09-07 evening): At 22:00, FlagScale upgraded its upstream dependency to Megatron-LM v0.18.2; the companion Megatron-LM-FL plugin repo synced to the same baseline at 21:57 (#109). The two training-stack repos aligned versions the same evening, a coordinated upgrade. Megatron-LM-FL also had two CICD commits: #140 (18:29) adding retries to the TE-FL prepare checkout, and #128 (15:01) handling TE-FL incremental builds and runtime integration.
  • CICD focuses on training (#1283, 10:34): FlagScale removed its inference and serve CI pipelines to “focus on training”—the training framework’s delivery boundary narrowed, making the division of labor whereby the inference side is handled by vllm-plugin-FL/sglang-plugin-FL more explicit.

Interpretation: The three commits correspond to three directional signals for FlagScale. KERV is the most notable: the FlagOS training stack is beginning to cover speculative decoding for embodied/robotics policies—KERV is a speculative decoding framework aimed at robot VLA deployment (OpenVLA as verifier, draft model running ahead, verification tree + Kalman completion to control acceptance rate), and FlagScale makes it a first-class citizen that is “trainable (verifier/drafter) + inferable (LIBERO) + evaluable.” This echoes FlagOS-Robo’s positioning as an embodied intelligence toolchain, and contrasts with the 2.2 test-period freeze rule of “bug fixes only, no new features”—the KERV PR was created on 08-30 and merged on 09-07, right at the edge of the feature freeze (08-31) and already implemented in advance, making it the wrap-up of a pre-freeze feature rather than something newly opened after the freeze. The same-evening alignment of both repos on Megatron v0.18.2 shows that the training stack’s dependency versions are already pinned in the 2.2 RC1 baseline; the CICD focus on training writes the division of “FlagScale = training, vllm/sglang plugins = inference” into the engineering pipeline.

1.3 FlagGems-Experimental: Batch sync of KernelGen cross-backend operators + sync-to-kernelgen CI lands (09-07)

Sources: FlagGems-Experimental commits (14:31 CICD × 3 + 16:27–16:58 batch of 60+), CICD sync-to-kernelgen (4973e875)

  • CI first (14:31): 103yiran merged CICD(.github): add sync to kernelgen, docs: add ci doc, and .github adjustments—establishing an automated sync workflow between the FlagGems-Experimental and KernelGen repos.
  • Batch landing at 16:58: 60+ commits landed at the same second (16:58:04–05), all operator commits prefixed [KernelGen][vendor], spanning backends: Kunlunxin (digamma, arctan minimax optimization, bernoulli), Metax (specialized math operators such as linalg_cholesky/log_normal_/erfinv/gcd_/lgamma + adaptive_max_pool3d_backward + special_shifted_chebyshev_polynomial_w + registration-name fixes), Iluvatar (addmm_, nonzero_numpy hybrid two-pass kernel optimization), Hygon (amp_foreach_non_finite_check_and_unscale), thead (lcm/lcm_ vendor specialization), MThreads (linalg_cholesky), Nvidia (new operators such as special_i0/softmax/xlog1py/shifted_chebyshev_t/spherical_bessel_j0/split_with_sizes/grid_sampler_3d), plus historical commits synced from upstream FlagGems (Apache 2.0 header completion, CI fixes, FlagTune topk config, ENFLAME updates, etc.; PR numbers #3540/#4646/#4829/#4873 and others point to upstream FlagGems). Contributors include yzw1128 (the same account as the FlagGems-sglang competition team), chx7514, ZhiwenDeng, KK, Dingxingdi, bwbwzzz, and others.

Interpretation: FlagGems-Experimental is the relay/experimental repo for the KernelGen operator stream, and this window’s combination of “CI sync workflow + one large batch merge” shows that KernelGen’s cross-vendor operator output is flowing from the experimental repo to the main KernelGen repo in batch syncs (sync-to-kernelgen is the pipeline itself). The semantic distribution of this batch says a lot about KernelGen’s current focus—the special function family (i0/softmax/xlog1py/Bessel/Chebyshev polynomials, etc.) appears densely on the Nvidia/Metax backends, indicating that the automatic generation coverage of math function operators is expanding; meanwhile, the Kunlunxin/Iluvatar/Hygon/thead/MThreads entries are mostly “vendor specialization” (rewriting general kernels for specific toolchains/instructions), corresponding to the last mile of multi-chip adaptation. Noteworthy are the thead (DAMO XuanTie) entries and integer operators like lcm—KernelGen support on the XuanTie side continues to ramp up. yzw1128 is active in both competition PRs and KernelGen operators, showing that external contributors are now producing through both the competition channel and the KernelGen channel simultaneously.

1.4 FlagGems Main Repo: Hygon/Iluvatar fixes, QC fp8, external contributors, and a revert (09-07)

Sources: FlagGems commits 11:34–20:39, #6040 hygon BLOCK_M fix, #6043 revert FlagTune, #5341 SiliconFlow cauchy

  • Hygon fix (15:23 #6040): Fixed a KeyError: 'BLOCK_M' in the Hygon backend’s flash attention when running ViT encoder inference—the path that reads block size from the quantization config came up empty for certain shapes.
  • Iluvatar optimization (17:27 #5341): [SiliconFlow] Optimize cauchy on Iluvatar—credited to SiliconFlow, optimizing the cauchy operator (SSM-family convolution) on Iluvatar and fixing cross-backend tests along the way.
  • QC fp8 (14:04, same commit c9bd738d as Experimental): [QC] Optimize GEMM(fp8)—the fp8 GEMM optimization landed in both the main repo and the experimental repo.
  • Engineering side: Three CI/test commits from 18:07–18:09 (approved operator tests alias, and_scalar pytest marker); AddMM public API tests at 17:37 (after the upstream beta-zero fix); a fix at 18:09 for the bucketize kernel reading past the end of input (#5231, Truong Vu); and an update to Hygon linalg_solve_triangular at 20:39 (#5943).
  • Revert (15:54 #6043): Reverted the previous day’s [FlagTune] Add multi-platform Mul cost model support (#5762)—the FlagTune multi-platform multiplication cost model was rolled back wholesale.

Interpretation: The 11 commits in the main repo during the window show a classic “test stabilization period” shape: no new architecture-level features, all backend correctness fixes (Hygon ViT-scenario BLOCK_M, bucketize out-of-bounds), single-operator performance optimizations (QC fp8, Iluvatar cauchy, Hygon linalg), and CI/test infrastructure. The SiliconFlow-credited Iluvatar cauchy optimization is worth flagging—after the CAS AlphaSparse team (FlagSparse), this is another external company contributing vendor operators directly to FlagGems, and the roster of “external contributions” in ecosystem co-building is growing. The FlagTune cost model revert shows that tuner-side changes are strictly vetted during the RC period: anything failing acceptance criteria is rolled back rather than kept, consistent with the 2.2 freeze discipline of “bug fixes only.”

1.5 FlagGems-vllm: DAMO XuanTie PPU and Hygon-specific fused-MoE backends (09-08)

Sources: FlagGems-vllm PR #696 (merged 09-08 09:54), #746 (09:56), #747 (10:05)

  • #696 DAMO XuanTie PPU backend: Adds a _thead backend implementing pure-Triton fused-MoE (fused_experts_impl) for T-Head PPU (ZW810E, compute_89 / AIU MMA instructions), modeled on the existing _metax/_mthreads vendor backends: a thead version of moe_align_block_size, transposed cached weights (reusing permute_copy synced from FlagGems), per-tile moe_sum reduction, with the production path not depending on deep_gemm; large-M GEMM-style kernels are tiered by token count (MOE_GEMM_TUNING_MIN_TOKENS, gemm1/gemm2 segmented).
  • #746 Hygon-specific fused-MoE: Implements a dedicated fused_experts_impl for Hygon DCU (gfx936), tuned against the vLLM-HCU Triton baseline on real Qwen3.6-35B-A3B shapes: the full fused_moe pipeline (moe_align→GEMM1→SiLU→GEMM2→moe_sum), a Hygon-specific align path (a 3-kernel small-batch variant that avoids the TLE cooperative kernel the HCU backend cannot compile); tiered by M (M≤16 non-fused single pass, TP4 BK=64, mid-M BK128, TP4 large-M num_warps=16, TP1 M≥8192 non-fused, etc.).
  • #747 KMCompiler: Changes persistent_topk tests/benchmarks to run in environments without vLLM native ops (the KMCompiler generation path self-tests independently of vLLM dependencies).

Interpretation: Two vendor fused-MoE backends merged the same day (2 minutes apart), both deep adaptations that “hand-write schedules for specific chip instruction sets”: XuanTie PPU-ZW810E goes through AIU MMA (compute_89 level), while Hygon DCU uses gfx936-specific tiering and deliberately avoids the TLE kernel the HCU backend cannot compile—the latter consistent with the known boundary in the KernelGen/FlagGems family that “TLE cooperative kernels are not compilable on some domestic toolchains.” The Hygon fused-MoE is tuned on real Qwen3.6-35B-A3B shapes and benchmarked directly against the vLLM-HCU Triton baseline, indicating this backend targets real 35B-class MoE inference workloads. Fused-MoE is a key operator for current inference throughput, and the per-chip specialization of it in the vllm plugin layer is the most direct example of “operator-level performance polishing” during the 2.2 test period.

1.6 FlagBLAS: Consecutive Ascend L2 routine merges (CHER/CHER2/SSYR/CSYR) (09-07/09-08)

Sources: FlagBLAS PR #96 (16:35), #93 (17:16), #97 (18:05), #98 (19:31), #99 (09-08 10:16)

  • During the window, FlagBLAS’s default branch had 9 commits, with the main line being Ascend backend L2 routine expansion: Ybanana252 submitted CHER (complex Hermitian rank-1 update, #97 18:05), CHER2 (rank-2, #98 19:31), SSYR/CSYR (real/complex symmetric rank-1 updates, #99 merged 09-08 10:16), and L2 triangular (the l2-triangular branch merged in #93 at 17:16), each accompanied by test documentation for Ascend input construction (test(her2): document Ascend input construction).
  • Two CI fixes (#96, merged 16:35, bin913): the nvidia line’s flagtree aligned to 0.6.1 (same version as FlagGems) and switched to uv pip install to ensure triton is available.

Interpretation: FlagBLAS’s Ascend L2 coverage is closing fast—CHER/CHER2/SSYR/CSYR are all rank-1/rank-2 update routines, forming a “routine-by-routine fill-in” cadence with the DCU/L2 main line recorded in the 09-05 report (the Ascend L2 triangular family had also already merged). Batches merged on three consecutive evenings plus the following morning indicate that Ascend L2 acceptance is a batch-pipelined process. On the CI side, pinning nvidia flagtree to 0.6.1 (consistent with FlagGems) is a routine multi-repo dependency alignment. Per the manifest, flagblas is an L1 compute library and can still take bug fixes and new routines after RC1—this Ascend routine-strengthening line will likely continue through GA.

1.7 FlagTree/FlagPrism: TLE multi-field pipe, CI/CD fixes, and debug/profiling component merge (09-07)

Sources: FlagTree #1110 (12:29), #1104 (15:31), #1115 (15:41), FlagPrism PR #8 (merged 10:47), FlagPrism README

  • FlagTree (first substantive merge to the default branch since 09-04): 12:29 #1110 [BUILD][CD] fixes the DEPENDS IncGen and nvidia3.7 delivery workflows; 15:31 #1104 [TLE][MTHREADS] supports multi-field pipe and multi-role ws (TLE’s communication/pipeline abstraction extension on the Moore Threads backend); 15:41 #1115 [CI][Nvidia] optimizes concurrency grouping for the nvidia3.6 workflow. The 09-08 09:58 push was PR-branch activity.
  • FlagPrism (new repo advancing): 10:47 merged #8 “Add profiler and debugger support”. FlagPrism is the repo that centrally maintains FlagTree’s optional debug and profiling components: flagtree.debugger (a debugger compiler plugin linked into libtriton, with runtime transport/decoding in a separate _native extension) and flagtree.profiler (Python package + native runtime + CLI); flagtree-debugger/flagtree-profiler no longer ship separate wheels—FlagTree consumes them as a third_party/FlagPrism submodule, and a single pip wheel . build produces one FlagTree wheel containing Debugger/Profiler.

Interpretation: After the rc0 verification period (following the 09-04 Qingwei backend merge), FlagTree’s default branch went quiet for 3 days; this window’s merges center on build/delivery workflow fixes and TLE backend capabilities—the nvidia3.7 delivery flow, IncGen dependencies, and Moore Threads TLE multi-field pipe are all engineering to “make the multi-chip CI/CD matrix run stably.” The FlagPrism merge is a component-architecture event: FlagTree’s debugger/profiler converge from “separate packages” to “main-repo submodule + single wheel.” In the RC1 manifest, flagtree’s three lines share the same version (0.7.0rc1.post1+tritonX); if Prism’s #8 entered before the freeze, it ships with 2.2, and debug/profiling capabilities will be built into FlagTree’s single wheel—a tangible experience improvement for operator developers (the debugger’s compiler plugin lives inside libtriton, and the profiler CLI is available in one stop).

1.8 vllm-plugin-FL and FlagScale-Agent: FlagCX metrics connector, Agent reliability overhaul (09-07/09-08)

Sources: vllm-plugin-FL #418 (489d22d5, 14:28), FlagScale-Agent commit 9e308807 (09-08 09:12)

  • vllm-plugin-FL #418 (09-07 14:28): feat(flagcx connector): Prometheus KV-transfer metrics + port #315 from release/0.2—the connector between the vLLM plugin and FlagCX adds Prometheus-observable metrics (KV transfer) and ports the release/0.2 branch’s #315 fix back to the mainline.
  • FlagScale-Agent (09-08 09:12, caozhou): feat: agent reliability overhaul—adds a runtime thinking cap, reasoning-aware retries, time-budget awareness, and health monitoring to FlagScale-Agent. FlagScale-Agent is the agent component for large-model training orchestration, and this is a comprehensive reliability overhaul.

Interpretation: Both are engineering to “make FlagOS’s upper-layer tools better suited to unattended long runs”: the FlagCX connector’s Prometheus metrics expose multi-GPU KV transfer status to operations (the vLLM 0.20.2 line’s #315 fix is synced back to the mainline, keeping both lines consistent); FlagScale-Agent’s four-piece set of “thinking budget/retries/time budget/health monitoring” is typical agent engineering hardening—preventing agent loops from running out of control or silently hanging during long training orchestration. Given the rising need for an “observable + self-healing” orchestration layer during the 2.2 test period’s multi-chip matrix runs, such hardening is timely.

II. News and Ecosystem

2.1 FlagOS Community “Open AI Computing” Forum Held Alongside KubeCon + PyTorch Conference China in Shanghai (09-07)

Source: FlagOS CSDN Official Account Announcement (published 2026-09-07 09:57)

  • On the afternoon of 09-07, the forum “Open AI Computing: Building a New Open-Source Software Ecosystem for Diverse Heterogeneous Hardware,” hosted by the Zhongzhi FlagOS Community, was held alongside the Shanghai KubeCon + CloudNativeCon + OpenInfra Summit + PyTorch Conference China. Speakers came from the Beijing Academy of Artificial Intelligence, Shanghai AI Laboratory, the PyTorch Foundation, the SGLang community, and others; the agenda centered on the technical roadmap and collaboration models for an open AI system software stack. The CSDN official account page provides a livestream/replay.
  • The announcement was published at 09-07 09:57 (immediately adjacent to the end of the previous window), while the forum itself took place that afternoon (within this window); yesterday’s report noted no updates from the CSDN official account, so this entry is a belated record of an in-window ecosystem event.

Interpretation: Holding the forum inside the Shanghai venue of PyTorch Conference China / KubeCon China is a continuation of FlagOS’s efforts on “horizontal open-source community collaboration”—sharing the stage with the PyTorch Foundation and the SGLang community, with an agenda aimed squarely at “a unified software stack across multiple chips,” the core of FlagOS’s proposition. Events of this kind do not themselves generate component code activity, but they show that around the RC1 cut, the community layer is using international conferences to amplify the open computing narrative; going forward, it is worth watching whether the forum yields any public roadmap or whitepaper-type output.

2.2 Sixth Consecutive Quiet Window at the Component Level (09-07~09-08)

Source: Google News RSS (14 Chinese/English query sets, via proxy), HN Algolia, Tavily/web search (see appendix)

  • The gnews Chinese/English combinations (FlagOS/FlagGems/FlagScale/FlagTree/FlagPerf/KernelGen/FlagOS 2.2 when:3d~30d, etc.) returned zero hits within the window; the only FlagGems hit was a re-post of an old 09-01 BAAI Community Day0 article (already reported). 智源研究院 when:7d returned 58 hits, all of them BAAI Community blog re-posts (Yao Qizhi’s opening ceremony speech, AI programming miscellany, etc.) and gambling SEO template noise, with no FlagOS content, so the entire batch was discarded. Queries for Iluvatar CoreX / MetaX returned mainly business news such as interim reports, share prices, and Hong Kong stock movements (not directly related to the FlagOS software ecosystem, so not included).
  • HN Algolia (FlagOS/FlagGems/flagos-ai/BAAI) returned no relevant hits; the only new content found via Tavily was the 2.1 forum announcement.
  • Trend over the past 3 days (corroborated by GitHub org pushed, the engineering side is anything but quiet): 09-07 11:11 FlagOS 2.2 RC1 manifest cut + first round of rc1.post1 tag wave (1.1 today); 09-07 FlagScale KERV embodied speculative decoding integration and Megatron v0.18.2 dual-repo alignment (1.2); 09-07/09-08 build-infra with 13 consecutive delivery records (Iluvatar CoreX 0.20.2 deterministic finalization, MetaX/Cambricon/Ascend sglang 0.5.18 line, see III); the evening of 09-07 batch merge of FlagBLAS Ascend L2 routines (1.6); the morning of 09-08 merge of FlagGems-vllm DAMO XuanTie/Hygon fused-MoE backends (1.5).

III. Deep Dive on Member Organizations

3.1 Tsingmicro: vllm-plugin-FL adds txda vendor backend line, merged with vLLM 0.24.0 mainline (09-07)

Source: vllm-plugin-FL PR #447 (tsingmicro-public-e, merged 09-07 16:58, base: main)

  • PR #447 was submitted and merged by Tsingmicro’s official account tsingmicro-public-e (PR Category: Vendor): it adds txda vendor code to vllm-plugin-FL, supports vLLM==0.24.0 (main line), and fixes txda-related bugs. Merged at 09-07 16:58, consistent with the RC1 manifest’s setting of pinning vLLM 0.24.0 on the vllm-plugin-fl main line.
  • The Tsingmicro line on the build-infra runner side is already in place (tsingmicro-tsm260610: [self-hosted, tsingmicro], registered before this window).

Interpretation: Tsingmicro had already entered the FlagTree backend matrix (09-05 report: 300-file-scale integration, TLE-DSA dataflow architecture); this is the first piece on the inference plugin side—the vendor backend roster of vllm-plugin-FL now includes txda (vLLM 0.24.0 line). As a relatively new chip vendor among FlagOS member organizations, Tsingmicro’s integration path shows a clear “compiler (FlagTree) first, inference framework (vLLM plugin) follows” sequence; the way the txda backend was merged (vendor submits its own PR, maintains it itself) is also a positive example of deep member participation.

3.2 Iluvatar: 0.20.2 deterministic technical route finalized—whole-family blacklist for flag_gems GEMM family (09-07)

Sources: build-infra #776/#777 (19:23/19:24, image tag registration), #779 (20:21, docs finalization), vllm-plugin-FL PR #450 (in flight, updated 09-07 16:59)

  • Image registration (#776/#777, 09-07 19:23/19:24): iluvatar-corex4.4.0 and corex4.5.0 registered the same day with vllm 0.20.2 app image tag 2.1.2-0.2.1_g16e8655.d20260907 (plugin source fingerprint g16e8655, same tag for both stacks)—an update from the previous day’s g71b9482.d20260906 fingerprint, corresponding to the new delivery after the deterministic solution iteration.
  • Technical route finalized (#779 docs, 20:21): The final deterministic route for iluvatar 0.20.2 is a whole-family blacklist for the flag_gems GEMM family (linear/mm/mm.out/addmm/addmm_/addmm.out/bmm/bmm.out → fall back to native corex ixblas). The root-cause narrative is thorough: vllm_fl’s flag_gems.enable() hijacks aten::linear etc. to flag_gems triton linear_kernel; that kernel, when compiled by flagtree, is per-launch non-deterministic in the live engine (~1-2 bf16 ulp; deterministic offline; temp=0 long-range decoding flips in near-tied sampling bands), whereas the same-source kernel compiled with the vendor’s corex triton is bitwise deterministic (== native). The blacklist must exclude the entire family (native linear degrades to addmm; blacklisting only linear still gets hijacked). After GEMM goes native, both F/T paths are 30/30 deterministic at temp=0, and throughput actually improves (F 14.0 tok/s vs flag_gems linear 12.3; native ixblas is faster than the flagtree-compiled flag_gems kernel); silu_and_mul stays on flagos (no longer flips under native GEMM). The compiler difference is the watershed: the same flag_gems source kernel is non-deterministic when compiled by flagtree and deterministic when compiled by corex triton—upstream handoff has opened FlagGems #6054-6057 (linear/mm/addmm/bmm). The 4.4.0 T path still requires VLLM_FL_USE_FLAGGEMS_ATTN=1 (corex triton 3.1 cannot compile vLLM native attention); 4.5.0 T (corex triton 3.2) needs no env; the known non-blocking limitation is a flip on the first request of a cold engine on 4.5.0 T.
  • PR #450 still in flight: the plugin-side patches for iluvatar 0.20.2 (symm-mem stub guard, PyTorch sampler fallback, base release/0.2) remained unmerged after being updated at 09-07 16:59.

Interpretation: This line represents the third pivot and convergence of Iluvatar’s delivery narrative since 09-05: 09-05 env injection approach → 09-06 evening revert, switch to plugin-config silu_and_mul blacklist (#450) → 09-07 evening finalization with 30/30 empirical results as whole-family blacklist for the GEMM family, and this time it is a “determinism + performance” double win (excluding the flagtree compilation path is actually faster). The documentation pins the root cause on the compiler watershed—the same kernel source is per-launch non-deterministic when compiled by flagtree and bitwise deterministic when compiled by the vendor’s triton. This is a deeper conclusion than “which operator”: until flagtree’s live-compilation determinism is fundamentally fixed (FlagGems #6054-6057 handed off to upstream), deterministic delivery of flag_gems operators on domestic chips will have to rely on blacklist/fallback mechanisms as a backstop. This is an important honest footnote to FlagOS’s “full flag_gems replacement” narrative; for Iluvatar, the deterministic delivery path for 0.20.2 on both corex4.4.0/4.5.0 stacks is now documented.

3.3 MetaX and Cambricon: sglang 0.5.18 delivery line expands (09-07/09-08)

Sources: build-infra #781 (09-07 22:49), #783 (09-08 07:18), #784 (07:27), #773 (09-07 13:10)

  • MetaX metax-maca3.7.2.1 sglang 0.5.18 line opened: at 22:49, #781 added the sglang app configuration for maca3.7.2.1 (deps_app/app env); at 09-08 07:18, #783 registered the app image tag 2.1.2-0.1.dev1_ga73b27b60; at 07:27, #784 docs recorded that maca3.7.2.1’s sglang 0.5.18 passed E2E on both F/T paths, and wrote plugin-side PR #86 into the verification matrix. The maca3.8.1.3 line is also already in place in the runner configuration.
  • Cambricon cambricon-neuware4.4.3: at 09-07 13:10, #773 docs recorded the sglang 0.5.18 delivery for neuware4.4.3 (continuing the cadence of the previous day’s 0.20.2-side records).

Interpretation: The sglang 0.5.18 delivery matrix continues to shift right after the RC1 branch cut—MetaX maca3.7.2.1 closed the loop with “F/T dual-path E2E pass + plugin PR #86 linkage,” and Cambricon neuware4.4.3 filled in its delivery record. Combined with the previous day’s sglang 0.5.18 records for Enflame tops1.9.10 / Moore Threads musa4.3.6, the delivery matrix of “vLLM 0.20.2 and sglang 0.5.18 dual inference frameworks × multiple vendor SDK lines” is now largely laid out, with each line’s registration carrying an image tag fingerprint and plugin commit linkage—this is precisely the engineering reality behind the dual entries (each rc1.post1) for vllm-plugin/sglang-plugin in the RC1 manifest.

3.4 External ecosystem: Ascend verification records and from-scratch fix, Kunlunxin KernelGen operators, sunrise new backend wiring (09-07/09-08)

Sources: build-infra #772 (sunrise env), #775/#780/#782 (Ascend), #778 (external blacklist lead), FlagGems-Experimental KernelGen Kunlunxin operators

  • Ascend sglang 0.5.18 verification and fixes: #780 (22:10) registered the cann8.5.0 sglang app image tag 2.1.2-0.1.dev1_g0f98ddc20; #782 (09-08 07:16) docs recorded sglang 0.5.18 verification for cann8.5.0; #775 (19:46) fixed env injection for sglang serve in the Ascend from-scratch build scenario (USE_FLAGGEMS=0 branch); #778 (20:19) recorded the lead that Ascend index_select requires an external blacklist (the same family of determinism investigation as in 3.2 spilling over to Ascend).
  • Kunlunxin: FlagGems-Experimental KernelGen merged in batch three Kunlunxin operators—digamma/arctan (minimax polynomial kernel)/bernoulli (1.3, ZhiwenDeng).
  • sunrise new backend wiring (#772, 12:49): build-infra added a sunrise vendor device-visibility env to the runner configuration (TANG_VISIBLE_DEVICES=all; the sunrise toolchain line tangrt1.2.0 was already listed in the runner manifest). sunrise has not yet appeared in the publicly disclosed member organization list; based on the toolchain naming (TANG RT), it is presumed to be an accelerator runtime prefixed with TANG; this window’s action was to complete its container startup parameters, which is an early stage of onboarding.

Interpretation: The three external-ecosystem lines correspond respectively to “deep-adaptation vendor” (Ascend—already on par with member organizations, sglang verification + determinism investigation spillover), “operator crowdsourcing” (Kunlunxin—KernelGen math-function operators), and “new backend reserve” (sunrise—runner configuration first, no component merged yet). The Ascend index_select external-blacklist lead is worth tracking: if 3.2’s “compiler watershed” conclusion also applies to Ascend’s flagtree path, it would indicate that the determinism issue is a systemic problem of the flagtree compilation path rather than an iluvatar-specific case.

IV. Summary

In this window (09-07 10:18 – 09-08 10:18), GitHub saw 91 in-window commits and pushes to 30 repos, making it one of the most active windows recently; on the news side, component-level searches remained quiet for the sixth consecutive time, but an ecosystem-side in-window event appeared (the Shanghai forum). Four main threads:

  1. FlagOS 2.2 RC1 officially branched (from 09-07 11:11): community merged release-2.2-rc1.yaml (25 manifest entries / 22 repos, +252 lines), the release-branch-tag workflow defaults to rc1, and within the following 11 minutes at least 12 repos concentratedly pushed their first round of rc1.post1 verification tags (FlagSparse published the rc1.post1 release at 11:27) — the prior day’s prediction of “watch the community manifest repo actions” materialized, and the RC0→RC1 release pipeline switchover is complete. Version anchors: flaggems v5.4.0, flagscale v2.1.0, kernelgen v2.2.0, flagcx v0.14.0, flagtree 0.7.0 (triton 3.6/3.5/3.3 three lines); per the schedule, 09-01~09-24 is the multi-chip matrix testing period, with GA on 09-28. Follow-up signals: the cadence of rc1.postN increments and RC-final around 09-24.
  2. Three FlagScale training-stack events: KERV embodied speculative-decoding training/inference integration merged (#1278, OpenVLA verifier + LIBERO inference + 14 operators + 33 unit tests, the training stack’s first coverage of embodied-policy speculative decoding); Megatron-LM-FL and FlagScale aligned with Megatron-LM v0.18.2 the same night; CICD removed the inference/serve pipelines to focus on training (inference responsibilities further consolidated into the vllm/sglang plugins).
  3. The determinism issue surfaces a “compiler watershed”: Iluvatar CoreX 0.20.2’s final resolution is a whole-family blacklist of the flag_gems GEMM family falling back to corex ixblas (#779, F/T 30/30 deterministic and throughput surpassing at 14.0 vs 12.3 tok/s); the root cause is that the same flag_gems kernel compiled in-engine by flagtree is non-deterministic per launch, while the vendor triton compilation is bitwise deterministic; upstream handoff to FlagGems #6054-6057; similar external blacklist clues appeared on the Ascend side. On the same day, the corex4.4.0/4.5.0 dual stacks registered the 0.20.2 new delivery with the g16e8655 fingerprint.
  4. The multi-chip delivery matrix and operator matrix continue shifting right: the sglang 0.5.18 line closed the loop on records for MetaX (maca3.7.2.1, F/T E2E passing), Cambricon (neuware4.4.3), and Ascend (cann8.5.0); the Tsingmicro txda backend merged into the vllm-plugin-FL main line via the vendor’s own PR (vLLM 0.24.0); FlagGems-vllm merged two dedicated fused-MoE backends on the same day, for DAMO XuanTie PPU-ZW810E and Hygon DCU; FlagBLAS Ascend L2 routines (CHER/CHER2/SSYR/CSYR) were filled in in bulk; FlagGems-Experimental set up the sync-to-kernelgen CI and bulk-synced cross-backend KernelGen operators.

Predictions: RC1 has branched, and component default branches enter a test-stabilization period of “bug fixes only”; over the next two weeks the GitHub-side focus shifts from “new feature merges” to the increment cadence of rc1.postN verification tags and the density of delivery records (build-infra’s recording frequency is the best proxy for RC progress); the compiler-determinism handoff in FlagGems #6054-6057 is worth tracking (if fixed at the root, “full flag_gems replacement” on domestic chips will truly be worry-free); the FlagTree single wheel (including the Prism debugger/profiler) and the KERV embodied training pipeline are two new capability points worth verifying at 2.2 GA; the onboarding progress of Tsingmicro (FlagTree backend + vLLM txda line) and external new backends (sunrise) can serve as observation items for member-unit ecosystem expansion.

Appendix: Complete Source List

Source Verification Result
GitHub org repos API (flagos-ai, 52 repos) 30 repos pushed in-window; 14 repos including community/FlagScale/FlagGems had substantive merges to default branches; FlagSparse/FlagDNN/sglang-plugin-FL/release-info/docs/FlagTree (09-08) etc. verified via default-branch commits as PR-branch or tag actions
GitHub commit search (org-wide 91 entries, sort=committer-date) Verified committer time and owning repo entry by entry; covers all substantive default-branch merges
GitHub PR/commit details (community #107, FlagScale #1278, FlagGems-vllm #696/#746, vllm-plugin-FL #447/#450, build-infra #779/#772, etc.) Provided manifest contents, KERV scope, fused-MoE details, txda attribution, and the full determinism roadmap text
GitHub tags/releases API + date verification FlagSparse v0.3.0-rc1.post1 release published 09-07 11:27; FlagCX/FlagGems-sglang/vllm-plugin-FL rc1.post1 tags exist; 12 repos concentratedly pushed 11:22~11:33 (RC1 tag wave)
community release/2.2 directory (raw) release-2.2-rc1.yaml full text, 25 entries; schedule_CN.md (08-31 freeze / 09-28 GA); release-branch-tag.yml defaults to rc1
Google News RSS (14 groups in Chinese and English, via proxy) Zero hits for component terms in-window; 58 entries for the BAAI term were entirely removed as community-blog + gambling SEO noise; Iluvatar/MetaX hits were business news and not included
HN Algolia (FlagOS/FlagGems/flagos-ai/BAAI) Zero relevant hits
Tavily/web search Only one in-window ecosystem event hit: the FlagOS community Shanghai forum (CSDN official account)
FlagOS CSDN official account (flagos.csdn.net) Forum announcement published 09-07 09:57 (6a9e1a10…); latest content confirms no other in-window updates