Research window: Past 24 hours (2026-09-15 10:18 ~ 2026-09-16 10:18, Beijing Time) Sources: GitHub (org: flagos-ai, full verification of pushed_at across 53 repositories + verification of 119 results from a single commit search by committer-date + review of commits on default branches of key repositories + releases/tags metadata for each repository + direct raw retrieval of the community release list and release timetable + patch details of key commits), Google News RSS (24 sets of Chinese and English query terms, via proxy), HN Algolia, MetaX official website, Guandian, Sina Finance, 21 Finance, Cailian Press, QbitAI, Xinhua Net, BAAI Community, CSDN FlagOS Community, etc. (see the appendix source list for details)

In This Issue

  • Today’s Highlights: Torch-FL’s six platforms pivot to FlagGems-first — PPU routing entries expand from 11 to 435 (09-15/09-16)
  • I. Open Source Project Progress (GitHub Activity)
    • 1.1 2.2 RC2 Round Two: FlagGems bumped to v5.4.0-rc2.post2, manifest entries re-versioned (09-15)
    • 1.2 Open3D-PIMC’s first code landing: 662 files in a single commit, compile layer and runtime both in place (09-16)
    • 1.3 Torch-FL: six platforms pivot to FlagGems-first together (09-15/09-16)
    • 1.4 FlagAttention: SageAttention and GDN2 merged the same day, Ascend version implemented separately (09-15)
    • 1.5 FlagGems quantization operator line: Hygon W8A8 INT8 GEMM, Moore Threads W8A16 FP8 RMSNorm (09-15)
    • 1.6 FlagGems KernelGen batch merge: twenty Nvidia operators and Kunlunxin tle.gpu migration (09-15/09-16)
    • 1.7 Inference plugin line: Ascend SparseAttnSharedKV, persistent_topk, and vLLM 0.24 adaptation (09-15/09-16)
    • 1.8 build-infra: FlagCX wheel packaging pipeline opened, six vLLM application image tags recorded (09-15)
    • 1.9 community: 2.2 release governance automated, status now derived from linked PRs (09-15/09-16)
    • 1.10 FlagSparse: external branch merged into main repo, Ascend precision work wrapping up (09-15)
    • 1.11 FlagQuantum: Twin evidence graded by circuit topology (09-15)
    • 1.12 Other activity: FlagTree, flir, FlagDNN, FlagCX (09-15/09-16)
  • II. News Coverage and Ecosystem
    • 2.1 Twelfth consecutive quiet window for component-level search: hits concentrated in member organizations rather than components (09-15~09-16)
    • 2.2 MetaX completes Day0 adaptation for Shanghai AI Laboratory’s ATRIA Dawn Preview (09-15)
    • 2.3 Enflame Technology’s STAR Market listing: two readings — capital-side framing and ecosystem positioning (09-15)
    • 2.4 Open3D-PIMC from announcement to code: the 48-hour gap between media and code (09-14~09-16)
  • III. Member Organization Deep Dive
    • 3.1 Tsingmicro: Open3D-PIMC code landing converges with the 3D reconfigurable roadmap (09-16)
    • 3.2 Hygon: quantization operators, CI images, and FlagCX wheel advance in parallel (09-15)
    • 3.3 Moore Threads: W8A16 FP8 RMSNorm and MUSA routing adjusted in both directions (09-15)
    • 3.4 MetaX: metax rc2 image rebuild records and the Day0 adaptation narrative (09-15)
    • 3.5 Enflame Technology: S60 enters the vLLM 0.24 line and the GCU CI pipeline (09-15)
    • 3.6 Iluvatar CoreX: iluvatar3.6 backend bound to FlagTree 0.6.1 (09-15)
    • 3.7 Kunlunxin: sum migrated to tle.gpu and paged-KV convention fixed (09-15)
    • 3.8 BAAI (lead organization): RC2 governance automation and 2.2 progress reconciliation (09-15/09-16)
  • IV. Summary and Trend Observations
  • Appendix: Complete Source List

Today’s Highlight: Torch-FL’s six platforms pivot to FlagGems-first — PPU routing entries expand from 11 to 435

Date: 2026-09-15 to 2026-09-16　Sources: Torch-FL #290 PPU routing, Torch-FL #276 CUDA FlagGems-first, Torch-FL operator support docs

The most concentrated engineering effort in this window took place in Torch-FL: this adaptation layer, responsible for dispatching PyTorch operator calls to each chip backend, received 12 commits within 24 hours, pushing six platforms together toward “FlagGems-first.” Among them, PPU (DAMO XuanTie) saw the most dramatic routing table change — FlagGems routing entries expanded from 11 to 478, with 467 overloads moved from cuda into flaggems and not a single one moved in the opposite direction; after an executability census, two rounds of CI-exposed routing-related failures, and a source-level audit, it settled at 435 FlagGems / 1601 cuda, meaning that of the 482 operators covered by FlagGems, 47 were left on vendor kernels (33 routing-related failures found by the census, the mm/bmm family, five addmm overloads, _conj, and four reflection padding routes).

This change also incidentally closed off a structural problem: PPU’s operator universe was originally read back from backends_cuda.conf, and codegen_ops.py rewrites that file, effectively making PPU’s operator universe a function of another platform’s routing table; it now reads from csrc/aten/generated/register.inc — the registry jointly compiled by the CUDA line and the PPU line. After the change, regenerating all nine confs produced byte-identical results, proving this was a pure provenance substitution. The repository also wrote each of the 47 remaining operators into BOXING_TRITON_GAPS with a failure description, and recorded the config files’ SHA-256 to ensure reproducibility.

The other five platforms are different facets of the same direction: the CUDA line (#276, 18 files, +1660/-533) now installs FlagTree 0.6.2a2 and FlagGems master within the job and takes on compilation of FlagGems C++ operators, with the workflow timeout raised from 60 minutes to 120 minutes accordingly; DCU (#277) enables FlagTree and FlagGems by default; GCU (#285) adopts FlagGems with vendor fallback; Ascend (#288) switches the pipeline to FlagTree while retaining dtype fallback; MUSA (#286) promotes four entries previously judged as gap-filling back to FlagGems routing.

Placing this line back in the context of FlagOS’s proposition, it comes closer to the core goal than any single operator landing: FlagOS’s thesis is “one operator library reused across chips,” and what determines whether that thesis holds is precisely the dispatch layer — how many operators actually go through FlagGems rather than quietly falling back to vendor kernels. The answer given in this window is: vendor kernels still carry the bulk (1601 versus 435 on PPU), but the trend is clear, and every exception has a named reason.

I. Open Source Project Progress (GitHub Activity)

Window Overview: Of the 53 repositories in the org, 20 had pushes during the window; a single commit search returned 119 in-window commits (4 pages, sorted by committer-date descending), distributed across 17 repositories: FlagGems 43, build-infra 14, community 13, Torch-FL 12, FlagSparse 11, FlagGems-vllm 5, FlagGems-sglang 4, FlagQuantum 3, FlagAttention 3, sglang-plugin-FL 2, vllm-plugin-FL 2, FlagTree 2, plus flir, FlagGems-Experimental, FlagCX, Open3D-PIMC, and FlagDNN with 1 each. In addition, three repos—docs, release-info, and FlagBLAS—had pushes during the window but no new in-window commits on the default branch (these were tag or side-branch pushes, with docs and release-info handling release-artifact site synchronization).

This window’s shape = two parallel tracks: “dispatch-layer refactoring” + “quantization and attention operator build-out”: On the governance side, FlagGems’ second RC2 tagging and community’s release-project automation drive 2.2 toward closure; on the engineering side, the focus shifts from “adding more operators” to “making operators actually get used”—Torch-FL’s six-platform FlagGems-first is the main trunk, while FlagGems’ quantization operators (W8A8 / W8A16) and FlagAttention’s SageAttention and GDN2 are the new capacity. In addition, Open3D-PIMC completed its first code landing at the end of the window, the only new codebase action this period.

1.1 2.2 RC2 Second Round: FlagGems Bumped to v5.4.0-rc2.post2, Manifest Entry Re-versioned (09-15)

Date: 2026-09-15　Source: community commit #110, FlagGems v5.4.0-rc2.post2

At 11:21 on 09-15, the Release Manager submitted release(2.2-rc2): bump flaggems to v5.4.0-rc2.post2 (#110), with only one line changed in the manifest: FlagGems switched from v5.4.0-rc2.post1 to v5.4.0-rc2.post2. The commit message spells out the two fixes driving the re-version—flash_attention_backward compatibility (#6253) and gating tl.map_elementwise on the flagtree/3.5 line (#6236)—with the new tag pointing to branch head 88acc0f7d. Checking the tag timeline: rc2.post1 and rc2.post2 are both validation snapshots on that branch, and the remaining 24 entries in the manifest still point to rc2.post1. This is the second tagging of 2.2 RC2, with 13 days remaining until the 09-28 GA.

1.2 Open3D-PIMC First Code Landing: 662 Files in a Single Commit, Compiler Layer and Runtime Both Arrive (09-16)

Date: 2026-09-16　Source: Open3D-PIMC first commit, project README

At 09:30 on 09-16, the Open3D-PIMC repository—empty since its creation on 08-15—received its sole root commit, bringing in 662 entries at once. The directory structure shows this is not a proposal document but usable engineering: source/raisa-inductor/ is the compiler layer (compiler.py, graph_manager.py, graph_executor.py, plus three categories of passes under passes/—communication operators, fusion, and subgraph—and the compilation cache key in utils/_graph_hash.py), while runtime/rcs2/ is the C++ runtime (engine.cpp, l1_workspace.cpp, CMake and kernel.cmake), along with demo/test_compiler.py, envsetup.sh, and two architecture diagrams. The README lays out the project’s four gaps to be filled clearly: the expressiveness of the memory hierarchy, the disconnect between sharding and topology, the conflict between dynamic inference and whole-graph compilation, and the reuse of compilation artifacts; the corresponding solution elevates hierarchical sharding, 3D-DRAM data residency, object lifecycle, and the Graph/Eager boundary into IR semantics that are verifiable, transformable, and optimizable. This follows the open-source announcement at the 09-14 China Computing Conference, completing the landing from “announcing open source” to “code going live.”

1.3 Torch-FL: Six Platforms Shift to FlagGems-first Together (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: Torch-FL #290, Torch-FL #276, Torch-FL #285

See “Today’s Highlights.” Two additional details: First, the environment reproducibility of PPU jobs was completely rewritten—previously it imported FlagGems via a host mount of /workspace/FlagGems on the runner pod; once the pod lacked that mount, set_env_ppu.sh would exit during environment preparation with “FlagGems source is not available,” and the job would never reach the operator step. Now it installs FlagTree (0.6.2a2+ppu3.6) from the FlagOS index and FlagGems master from git, so the environment depends only on the image plus two indexes. Second, mm/bmm remains pinned to vendor kernels because FlagGems’ _hygon kernel passes the num_ldmatrixes keyword to Triton’s mm_kernel, which the PPU version of Triton does not recognize; this has been reported as FlagGems #6225.

1.4 FlagAttention: SageAttention and GDN2 Land the Same Day, Ascend Version Implemented Separately (09-15)

Date: 2026-09-15　Source: FlagAttention #43 SageAttention, FlagAttention #44 GDN2, FlagAttention #62 Ascend version

Two new operator versions merged in a single day. #43 introduces a Triton implementation of SageAttention (10 files, +862/-7): QK uses INT8 per-block quantization, PV uses FP16 forward, both the QK quantization and attention forward kernels use triton.experimental.tle.language, accompanied by benchmark scripts covering sequence lengths from 1K to 32K and accuracy tests against a per-head reference implementation. #44 is an optimized GDN2 operator—the current hotspot in the linear attention direction. #62 implements GDN2 and SageAttention separately for Ascend: the entry point automatically routes to the _ascend backend based on torch.npu.is_available(), and the generic path then redirects to that implementation, avoiding code drift between the two; the Ascend benchmark script measures the same set of shapes against AscendC operators. Taken together, these three indicate FlagAttention has shifted from “filling out attention variants” to “following the structural hotspots of the latest inference models.”

1.5 FlagGems Quantization Operator Line: Hygon W8A8 INT8 GEMM, Moore Threads W8A16 FP8 RMSNorm (09-15)

Date: 2026-09-15　Source: FlagGems #6185 Hygon W8A8, FlagGems #6210 Moore Threads W8A16

The Hygon line adds two non-ATen quantized matrix multiplication operators, mm_w8a8_int8 and mm_w8a8_int8_out (5 files, +871): inputs are already-quantized INT8 matrices, paired with scalar or per-row/column-scaled FP32 scale and optional bias; quantization itself is done outside the operator, and the kernel implementation focuses on long-K reduction overflow protection under INT8 dot products; operator registration was also added per the conf/operators.yaml specification, with stage marked 5.4, aligned with the current RC branch. The Moore Threads line optimized the W8A16 FP8 RMSNorm path (#6210). In addition, fix: enable TLE for Hygon (#6247) adds Hygon to the TLE enablement list, indicating its backend is beginning to use Triton’s language extensions. Taken together, quantization (W8A8 / W8A16) is becoming the main line of this round of operator expansion.

1.6 FlagGems KernelGen Batch Landing: Twenty Nvidia Operators and Kunlunxin tle.gpu Migration (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: FlagGems #5722, FlagGems #6311 Kunlunxin, FlagGems #6188 backends.yaml

KernelGen-produced Nvidia operators entered the main repo in batches during this window, roughly twenty in total, covering three categories: linear algebra (the linalg series such as cond, solve, eigvals, vander, multi_dot, powsum), special functions (entr, Chebyshev polynomials, etc.), and attention- and training-related (native multi-head attention, quantized GRU, grid_sampler 2D sampling, 3D upsampling backward, multiple pseudo-quantization and embedding-bag sparse backward, batch normalization backward reduction, etc.). The KMCompiler line additionally added unsafe_index_put (Nvidia and Ascend), rnn_tanh performance optimization, and _dim_arange. On the Kunlunxin side, sum and sum_dim were migrated to tle.gpu (#6311), and a Legendre polynomial operator was added. On the quality front, the 16×16 hang in linalg_svd (#6301), the dtype mismatch in addmv scalar bias (#6149), and the CI container’s shm/ipc options were fixed, and the Hygon image was updated (#6304); backends.yaml also updated the iluvatar backend to flagtree==0.6.1+iluvatar3.6 (#6188).

1.7 Inference Plugin Line: Ascend SparseAttnSharedKV, persistent_topk, and vLLM 0.24 Adaptation (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: FlagGems-vllm #792 SparseAttnSharedKV, vllm-plugin-FL #464, sglang-plugin-FL #75 Hygon DCU CI

The largest single code volume this window comes from Ascend’s SparseAttnSharedKV (#792, 5 files, +9637): this is a Triton implementation on Ascend of the DeepSeek-V4 sparse attention shared KV structure, with six fixed validation shapes—three decode cases with KV length 8193, three prefill cases with Q=KV=8192, constants centered on 64 Q heads, 1 KV head, head dim 512, page size 128, accuracy threshold 2e-2, with timing benchmarked against AscendC operators on the same device (5 warmups, 20 samples) and recorded only, not asserted—i.e., accuracy serves as the acceptance criterion. The same line also added Ascend persistent_topk (two paths: segment-sort plus merge) and folded vendor fused_moe / persistent_topk under ops/, while switching the pre-commit configuration to the gitcode mirror to adapt to domestic networks. Two upgrades on the plugin side: vllm-plugin-FL adapted Enflame S60 to the vLLM 0.24 line (#464) and upgraded Kunlunxin to vLLM 0.24.0 (#516); sglang-plugin-FL set up CI pipelines for Hygon DCU (BW1000) and Enflame GCU (S60) respectively (#75/#88), where the Hygon line builds FlagCX v0.13.0 with the AMD adaptor (DCU belongs to the HIP lineage, and DTK ships librccl), with the e2e test matrix aligned with Ascend and MUSA. On the FlagGems-sglang side, upstream FlagGems’ test utilities and conftest were vendored into the repo (#76).

1.8 build-infra: FlagCX wheel Packaging Line Opened, Six vLLM Application Image Tags Recorded (09-15)

Date: 2026-09-15　Source: build-infra #886, build-infra #895, build-infra #888

During the window, build-infra became the second most active repository with 14 commits, mainly covering two things. The first is the newly opened FlagCX wheel packaging line (#886 adds the three steps of build, verify, and publish; #896 pins the scm node width and configures cu-bridge’s CUDA_PATH for MACA; #897 reverts excessive commenting; #899 makes the vllm-plugin wheel build retain the wheel as a run artifact); among these, #895 records an environment pitfall: torch’s installed headers mandate gflags—torch/headeronly/macros/cmake_macros.h directly defines C10_USE_GFLAGS, so c10/util/Flags.h includes <gflags/gflags.h> for every consumer, yet no runtime image ships that header (no /usr/include/gflags was found on the Hygon runtime image), causing the Hygon build to fail when compiling backend_flagcx.cpp, so libgflags-dev and libgoogle-glog-dev were installed in the build image. The second is recording six vLLM application image tags, unified as 2.1.2-0.2.2rc2.post1_gdb28502.d20260915, corresponding to metax-maca3.8.1.3, metax-maca3.7.2.1, ascend-cann9.0.0, ascend-cann8.5.0, and two 910c variants (#888 through #893), plus a changelog for the metax/ascend 0.20.2 rc2 rebuild (#887) and a record of the Kunlunxin paged-KV convention fix (#898).

1.9 community: 2.2 Release Governance Automation, Status Now Derived from Linked PRs (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: community 2.2 project sync workflow, community commit 29a04c6e

Beyond the manifest and tagging, nearly all 13 commits in the community repository this window were used to move 2.2’s release status from a manual board into automation. The newly added flagos-2.2-project-sync.yml runs every 15 minutes, syncing issues tagged flagos2.2-rc0/rc1/rc2 (regardless of open/closed state) to the org’s GitHub Project #9; because both the default Actions token and the old org token lack Projects permission, the workflow explicitly requires a dedicated token with project scope. Subsequent commits over the next day fixed along the same chain: syncing issues, deriving release status from linked PRs, aligning status with linked PRs, hardening reconciliation, preserving manually deferred issues, promoting assigned triage issues, standardizing the schedule interval, verifying the Actions scheduling heartbeat, and adding a note spelling out the RC validation rules. Reading this chain alongside the two RC2 taggings shows that 2.2’s Go/No-Go is shifting from “humans reading the manifest” to “derived from issue and PR status,” which also explains why every re-versioning of the manifest this window landed on the tag within half an hour.

1.10 FlagSparse: External Branch Merged into Main Repo, Ascend Accuracy Wrap-up (09-15)

Date: 2026-09-15　Source: FlagSparse commit list

All 11 commits in FlagSparse this window came from a single external collaboration line: the main repo introduced the NCIC-AlphaSparse/main branch via a merge commit (#60), containing Ascend accuracy adjustments (ascend accuracy refine, ascend refines), CI refinements (two rounds of ci refine), wrapper and documentation updates, and multiple cross-repo sync merges. This indicates that the sparse operator library’s progress is led by an external team with the main repo taking it in, in contrast to FlagAttention being driven by the org’s internal main line.

1.11 FlagQuantum: Twin Evidence Graded by Circuit Topology (09-15)

Date: 2026-09-15　Source: FlagQuantum #45, FlagQuantum #46

Following the previous window’s Twin API freeze, FlagQuantum made three commits this window: comparing Twin candidates across circuits (#44), grading Twin evidence by circuit topology (#45), and combining adjacent connected Twin regions (#46). Together, the three steps advance the equivalence determination of quantum processor digital twins from “single-circuit comparison” to “organizing evidence sets by topology,” a methodological fill-in following historical sequence management.

1.12 Other Activity: FlagTree, flir, FlagDNN, FlagCX (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: FlagTree #1178, FlagTree #1169, flir #75, FlagCX #599

Two FlagTree items: fix(hcu): allow extract_tile in the TLE whitelist (#1169) puts extract_tile on the Hygon line into the TLE whitelist, in the same direction as “enabling TLE for Hygon” on the FlagGems side; [Triton] Use triton version instead of llvm22 version (#1178) unifies the version identification convention. The same change also landed on flir (FlagTree IR, derived from microsoft/triton-shared) (#75). FlagDNN fixed operator implementations for the Nvidia backend. FlagCX’s #599 corrected the performance reporting convention: KV-equivalent throughput no longer uses a fixed text-box value but is instead computed from the measured per-request KV byte count.

II. News Coverage and Ecosystem

2.1 Twelfth Consecutive Quiet Window for Component-Level Search: Hits Concentrated in Member Organizations Rather Than Components (09-15~09-16)

Date: 2026-09-15 to 2026-09-16　Source: Google News RSS

A total of 24 query combinations (17 in Chinese, 7 in English, across when:7d and when:14d windows) were run using Chinese-English combinations of FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagCX, KernelGen, Open3D-PIMC, and BAAI-side terms. Component-name queries returned zero hits within the window; after broadening to member organizations and industry terms, 13 in-window results were obtained, of which only MetaX’s Day0 adaptation and Enflame’s IPO market activity were ecosystem-related, with the rest being stock market coverage, financial articles, or irrelevant content. HN Algolia queries for FlagOS, FlagGems, FlagScale, and BAAI likewise yielded no substantive technical discussion. This marks the twelfth consecutive quiet window for component-level news search; this period’s technical information again came almost entirely from code repositories, and for the first time a dispatch-layer change in Torch-FL provided a technical narrative substantial enough to stand on its own.

2.2 MetaX Completes Day0 Adaptation for Shanghai AI Laboratory’s ATRIA Dawn Preview (09-15)

Date: 2026-09-15　Source: MetaX Official Site, Guandian

On 09-14, Shanghai AI Laboratory open-sourced the ATRIA Dawn Preview model, and MetaX announced the same day that it had completed Day0 adaptation for the model ahead of others, leveraging its self-developed general-purpose GPU and MXMACA software stack. The company cited two cumulative figures: since December 2025 it has completed Day0 adaptation for 37 mainstream flagship models, covering Zhipu, Alibaba Qwen, MiniMax, DeepSeek, StepFun, Tencent Hunyuan, and others; the MXMACA software stack is compatible with over 40 AI frameworks and more than 1,000 models, has been validated across over 6,000 open-source projects, and fully supports all 2,410 GPU operators in PyTorch 2.8. One distinction is necessary: this adaptation runs through the vendor’s proprietary software stack, which is a parallel path to the metax backend in FlagOS (the metax routing in Torch-FL and the metax backend in FlagGems). Reading the two together reveals the dual-track investment by member organizations in “competing for Day0 on proprietary stacks” and “co-building a unified stack.”

2.3 Enflame Technology’s STAR Market Listing: Two Readings from the Capital Side and the Ecosystem Position (09-15)

Date: 2026-09-15　Source: 21 Finance, Hithink, Cailian Press

After Enflame Technology listed on the STAR Market on 09-11, related commentary continued to build during the window: issue price of 142.18 yuan, opening at 410 yuan on the first day for a gain of 188.37%, intraday high of 475 yuan, closing at 397 yuan for a gain of 179.22%, corresponding to a market capitalization of 170.85 billion yuan, with 6.14 billion yuan raised; revenue of 301 million, 722 million, and 990 million yuan for 2023 through 2025, and 1.12 billion yuan in H1 2026, up 279.08% year-over-year, with cumulative net losses attributable to parent exceeding 4.3 billion yuan over three years, uncovered losses of 4.441 billion yuan, and the company’s own estimate that it may turn profitable in 2026 or 2027. As a FlagOS member organization, Enflame’s corresponding ecosystem-side actions are code rather than market data: in this window its enflame backend appeared simultaneously in the FlagGems operator line, the vLLM 0.24 adaptation line, and sglang’s GCU CI. The capital narrative answers “whether sustained investment is possible,” while code commits answer “where the investment lands” — and both point to cloud inference this period.

2.4 Open3D-PIMC from Announcement to Code: The 48-Hour Gap Between Media and Code (09-14~09-16)

Date: 2026-09-14 to 2026-09-16　Source: Xinhua Net, Repository First Commit

When the China Computing Conference announced the open-source release of Open3D-PIMC on 09-14, there was no code in the repository; the sole root commit appeared only at 09:30 on 09-16, bringing in 662 entries at once (compilation layer, C++ runtime, examples, and architecture diagrams). The media-side wording was “the code is already live in the open-source community” and “the latest optimization results for 3D chip computing power will be released at a top global technology conference in Q4 this year,” while the code-side timestamps show that going live occurred roughly 44 hours after the announcement. This is not a contradiction, but it suggests a reading: for projects targeting next-generation chip form factors, the “release” is a roadmap declaration, and true availability depends on the repository’s subsequent commit cadence — this report will include it in routine monitoring going forward.

III. Deep Dive on Member Organizations

3.1 Qingwei Intelligent: Open3D-PIMC Code Lands, Converging with the 3D Reconfigurable Roadmap (09-16)

Date: 2026-09-16　Source: Open3D-PIMC README, Tsinghua University Official Site

Qingwei Intelligent’s move within the org this period is the first code commit for Open3D-PIMC. From the landed content, its technical thesis runs along the same line as the company’s reconfigurable roadmap: the README frames the core problem after 3D-DRAM stacking as “which memory layer the data resides in, how tensors are distributed across Chiplet/Die/Tile, and whether compute and communication can be co-scheduled at the right time points”—no longer single-operator throughput. The proposed solution writes hierarchical tiling, N3D data residency, object lifetimes, and Graph/Eager boundaries into the IR, and allows vendors to supply cost models, schedulers, and code generation as plugins while keeping the frontend, IR, and runtime ABI compatible. The naming raisa-inductor and the C++ engine in runtime/rcs2 indicate that what has landed is the open-source release of a self-developed compiler and runtime stack. Combined with publicly available roadmap information (second-generation 3D reconfigurable chips about to enter mass-production tape-out, cumulative compute-card orders exceeding 30,000 units, kilocard-scale intelligent computing centers deployed across more than ten provinces and regions), Qingwei’s positioning within the FlagOS ecosystem remains consistent: not a gap-filling operator contributor, but a contender for software-defined control over the next generation of chip form factors.

3.2 Hygon: Quantization Operators, CI Images, and FlagCX Wheels in Parallel (09-15)

Date: 2026-09-15　Source: FlagGems #6185, FlagGems #6247, build-infra #895

Hygon has the most dispersed yet also most complete engineering effort this window: on the operator side, it added W8A8 INT8 quantized matrix multiplication (including the _out variant) and added Hygon to the TLE enablement list; on the FlagTree side, it cleared the extract_tile whitelist for the Hygon line; on the CI side, it restored the container’s shm/ipc options and updated images; on the packaging side, because the Hygon build lacked gflags headers when compiling backend_flagcx.cpp, it added libgflags-dev to the FlagCX wheel build image; additionally, the DCU line of Torch-FL set FlagTree and FlagGems as enabled by default. Reading all five together, Hygon’s current bottleneck is not “missing operators” but toolchain and packaging environment adaptation—such issues are numerous and low-value individually, yet they are precisely the practical barrier to cross-chip usability.

3.3 Moore Threads: W8A16 FP8 RMSNorm and Bidirectional MUSA Routing Adjustments (09-15)

Date: 2026-09-15　Source: FlagGems #6210, Torch-FL #286

Moore Threads’ two moves this period point in opposite directions but follow consistent logic: first, on the FlagGems side, it optimized the W8A16 FP8 RMSNorm path—deepening an existing operator; second, on the Torch-FL side, it promoted four entries previously classified as “MUSA gap-fill” back to FlagGems routing—reclaiming operators that had been delegated to vendor kernels. The former is throughput, the latter is coverage; together they indicate that the MUSA backend has moved past the “it runs” stage and begun addressing the exception list at the dispatch layer.

3.4 MetaX: metax rc2 Rebuild Image Records and the Day0 Adaptation Narrative (09-15)

Date: 2026-09-15　Source: build-infra #888, build-infra #887, MetaX Official Site

MetaX’s moves within the org this period center on release artifacts: build-infra recorded one application image tag each for the two runtime combinations metax-maca3.8.1.3 and metax-maca3.7.2.1, and added a changelog entry for the metax/ascend 0.20.2 rc2 rebuild—two MACA version lines entered into the ledger side by side, indicating that the support breadth of its driver stack is explicitly preserved. Four days earlier, its vllm-plugin-FL metax CI and vLLM 0.24.0 upgrade belonged to the same inference-stack effort. On the external side is the Day0 adaptation described in section 2.2, following its own MXMACA stack. More critical for FlagOS is the former: the entry of image tags gives the metax side a reproducible baseline for multi-chip acceptance.

3.5 Enflame: S60 Enters the vLLM 0.24 Line and GCU CI Pipeline (09-15)

Date: 2026-09-15　Source: vllm-plugin-FL #464, sglang-plugin-FL #88

Enflame’s two moves this period are both adaptation efforts: vllm-plugin-FL adapted Enflame S60 to the vLLM 0.24 line, while sglang-plugin-FL established a CI pipeline for GCU (S60). Viewed together, S60’s inference path coverage within FlagOS expands from vLLM to sglang, and both come with CI—consistent with the overall tempo of this window: new chip onboarding by member organizations no longer stops at operator ingestion but must simultaneously provide a runnable end-to-end pipeline. Combined with the capital-side information in section 2.3, the destination of its R&D investment can be read directly from such commits.

3.6 Iluvatar CoreX: iluvatar3.6 Backend Bound to FlagTree 0.6.1 (09-15)

Date: 2026-09-15　Source: FlagGems #6188

Iluvatar CoreX’s move this period is a single CI configuration commit: FlagGems’ backends.yaml updates its backend to flagtree==0.6.1+iluvatar3.6, binding the iluvatar backend to a specified FlagTree build version. The information content of a single commit is modest, but it is a clue to understanding the acceptance matrix in section 2.2—the availability of each vendor backend actually depends on the combination of “FlagGems version + FlagTree build variant + vendor driver,” and such combinations are being written into configuration one by one to ensure reproducibility.

3.7 Kunlunxin: sum Migrated to tle.gpu and paged-KV Convention Fix (09-15)

Date: 2026-09-15　Source: FlagGems #6311, build-infra #898, vllm-plugin-FL #516

Kunlunxin’s three moves this period point in a consistent direction: on the FlagGems side, it migrated sum and sum_dim to the tle.gpu path and added the special_legendre_polynomial_p operator; on the inference side, it upgraded vllm-plugin-FL to vLLM 0.24.0; and build-infra recorded a fix to its paged-KV convention. The migration of a basic reduction operator like sum from a generic implementation to the TLE path means the Kunlunxin backend has entered the stage of “using language extensions to squeeze performance” rather than merely pursuing usability.

3.8 BAAI (Lead Organization): RC2 Governance Automation and 2.2 Progress Reconciliation (09-15/09-16)

Date: 2026-09-15 to 2026-09-16　Source: community commit list, 2.2 release schedule

The lead organization’s moves this window all fall on the governance side: first, the second round of RC2 re-tagging for FlagGems (one manifest line, one tag, completed within half an hour), followed by 13 community commits that migrated the 2.2 release status into a GitHub Project and derived it from linked PRs. Against the schedule, we are still in the testing and stabilization period (09-01 to 09-24), with GA set for 09-28 and the graduation criterion being that each FEP’s executable Test Plan passes acceptance on the multi-chip matrix. Worth noting is a detail of this governance overhaul: the workflow explicitly declares that it requires a dedicated token with project scope, because neither the default token nor the legacy organization token has Projects permissions—such “writing process into code” changes will not appear in any release notes, but they determine whether the 25 entries during the RC period can be tracked item by item.

IV. Summary and Trend Observations

  • The dispatch layer became the main battleground this period: Torch-FL pushed six platforms to FlagGems-first within a single day, expanded PPU from 11 routes to 435 and recorded item by item the 47 operators left on vendor kernels along with the reasons. FlagOS’s core promise is “one operator library reused across chips,” and the dispatch layer is where that promise is honored; this period saw the first complete, auditable quantitative accounting of this layer.
  • Quantization operators and attention variants are the two ends of new capacity: on the FlagGems side, Hygon’s W8A8 INT8 GEMM and Moore Threads’ W8A16 FP8 RMSNorm; on the FlagAttention side, SageAttention (QK INT8 per-block quantization) and GDN2; on the Ascend side, SparseAttnSharedKV (DeepSeek-V4 sparse attention, head dimension 512). What these operators share is that they correspond directly to the real structure of current inference models, not to test-suite coverage.
  • Release governance is moving from checklists to automation: RC2’s second tagging changed only one manifest line, and the new workflow immediately aligned issue status with linked PRs; the basis for Go/No-Go is shifting from “humans reading checklists” to “derivable status.” With 13 days until the 09-28 GA, it is worth watching whether this chain remains stable in the final week.
  • The ecosystem’s second step from “adapting chips” to “defining hardware form factors”: Open3D-PIMC completed code landing 44 hours after release, bringing in a hierarchical IR, compiler layer, and C++ runtime for 3D-DRAM near-memory computing. It does not enter 2.2’s acceptance scope, but it determines FlagOS’s position on the next generation of chip form factors.
  • The twelfth consecutive quiet window on the news front: component-level searches returned zero hits, and visible news on the member-organization side centered on capital markets and Day0 adaptation of proprietary stacks. The observation window for technical progress has fallen entirely on code repositories, which also means the value of the daily report is shifting from “aggregating coverage” to “interpreting commits.”

Appendix: Source Verification Table

Source Verification Result
GitHub org flagos-ai Full check of pushed_at across all 53 repos; 20 had pushes within the window; commit search returned 119 in-window commits, spread across 17 repos
GitHub releases / tags Checked twelve repos: FlagGems, FlagTree, FlagCX, FlagAttention, vllm-plugin-FL, FlagSparse, FlagScale, KernelGen, Torch-FL, FlagQuantum, build-infra, community; the only new tag in the window was FlagGems v5.4.0-rc2.post2; no new GitHub Releases
community release manifest 2.2 RC2 manifest has 25 entries (four tiers L0–L3); FlagGems bumped to rc2.post2, all others still point to rc2.post1; GA scheduled for 09-28
Google News RSS (17 Chinese query sets) Zero hits for component-name queries; member-organization and industry-term queries returned 13 in-window results, of which 2 were kept after removing market coverage and irrelevant articles
Google News RSS (7 English query sets) Zero in-window hits for queries including FlagOS, FlagGems, BAAI FlagOS, flagos-ai
HN Algolia No valid in-window technical discussion for FlagOS, FlagGems, FlagScale, BAAI queries
BAAI Community (hub.baai.ac.cn) Directly accessible; neither search nor homepage showed any in-window FlagOS-related entries
CSDN FlagOS Community Directly accessible; latest article dated 09-10, no updates within the window
MetaX official site / Guandian / Sina Finance Confirmed Day0 adaptation of ATRIA Dawn Preview (event 09-14, coverage 09-15 11:17 within the window)
21jingji / 10jqka / CLS / Hangzhou Net Confirmed Enflame Technology’s STAR Market debut first-day data (event 09-11, analysis pieces continued within the window)
Xinhua Net Confirmed Open3D-PIMC was open-sourced at the China Computing Conference (09-14), contrasting with the 09-16 code landing

Full Source List