Research window: Past 24 hours (2026-09-16 10:18 ~ 2026-09-17 11:40, Beijing time) Sources: GitHub (org: flagos-ai, full verification of pushed_at across 54 repositories + single commit search of 150 records verified by committer-date + commit review on default branches of key repositories + tags/releases metadata + direct raw retrieval of community release manifest and release schedule + details of key commit patches and file lists), Google News RSS (33 sets of query terms in Chinese and English, via proxy), HN Algolia, PEdaily, BAAI Community, Sina Finance, Leiphone, JiWei.com, etc. (see appendix source list for details)

In This Issue

  • Today’s Focus: build-infra raises the version field from 2.1.2 to 2.2.0—the last global switch before 2.2 GA is flipped (09-17)
  • I. Open-Source Project Progress (GitHub Activity)
    • 1.1 build-infra: base version 2.1.2 to 2.2.0, FlagGems pinned to 5.4.0-rc2.post2 (09-17)
    • 1.2 FlagTrain new repo lands: an empty placeholder repo appears on the training side (09-16)
    • 1.3 FlagFFT: 36 FFT operators accepted in one batch, with independent NumPy validation and runtime plans (09-16)
    • 1.4 FlagGems operator expansion: eighteen KernelGen Nvidia operators merged (09-16/09-17)
    • 1.5 FlagGems quantization operator line: Moore Threads native FP8 W8A8 MM, MetaX W8A16 RMSNorm (09-16/09-17)
    • 1.6 FlagGems-vllm: fused Marlin MoE and FP8 variable-length FlashAttention-2 (09-16/09-17)
    • 1.7 Torch-FL: from “routing switchover” to “fixing the aftermath of switchover” (09-16/09-17)
    • 1.8 FlagTree: FlagTune managed Manifest and iluvatar3.6 baseline workflow (09-16/09-17)
    • 1.9 FlagQuantum: JAX tests integrated, coverage floor raised to 60% (09-17)
    • 1.10 FlagCX and vllm-plugin-FL: PTD log streaming, T-Head PPU CI integration (09-16/09-17)
    • 1.11 Other activity: community, FlagGems-Experimental, flir, FlagScale-Agent, image tag records (09-16/09-17)
  • II. News Coverage and Ecosystem
    • 2.1 Thirteenth consecutive quiet window for component-level search: zero hits in 24 hours (09-16~09-17)
    • 2.2 FlagOS 2.2 timeline and RC2 checklist review: GA set for 09-28 (09-17 check)
    • 2.3 Horizon ecosystem: D-Robotics completes $400M Series C (09-17)
    • 2.4 Member company capital developments: MetaX interim results turn profitable, Enflame’s market cap tops 100 billion on debut day, domestic GPU semi-annual reports (09-16~09-17)
  • III. Member Company Deep Dive
    • 3.1 Hygon: linalg and dtype semantics both filled in simultaneously (09-16)
    • 3.2 Ascend: the densest operator line for MoE and linear attention (09-16/09-17)
    • 3.3 DAMO XuanTie: inference plugin integrated into PPU CI, MM/MV support NN/NT layouts (09-16/09-17)
    • 3.4 Moore Threads: native FP8 W8A8 MM and MUSA rotary position encoding back on the device side (09-16/09-17)
    • 3.5 MetaX: W8A16 RMSNorm and three routing workarounds (09-16/09-17)
    • 3.6 Kunlunxin: xCCL baked into base image, operator fix batch lands (09-17)
    • 3.7 Iluvatar CoreX: /dev/itrctl and iluvatar3.6 baseline workflow (09-17)
    • 3.8 Enflame: GCU300 recorded in 0.24.0 report and two image tags (09-16)
    • 3.9 BAAI (lead party): governance automation and version number bump (09-16/09-17)
  • IV. Summary and Trend Observations
  • Appendix: Source Verification Table
  • Appendix: Complete Source List

Today’s Highlight: build-infra raises the version field from 2.1.2 to 2.2.0 — the last global switch before 2.2 GA

Date: 2026-09-17　Sources: build-infra #916 version bump, build-infra configs.yaml, FlagOS 2.2 release schedule

At 08:49 on 09-17, build-infra received a commit with only two lines of changes, Bump base version to 2.2.0 (#916): the version field in configs.yaml changed from 2.1.2 to 2.2.0, and flaggems in the same place changed from 5.3.5 to 5.4.0-rc2.post2.

The weight of these two lines comes from the file’s own positioning. Its header states that it is the “single source of truth for all vendor/backend dependencies and build settings,” read by scripts/build_base.py and scripts/build_runtime.py; the version field is responsible for tagging all base images and runtime images (flagos-base-{vendor}-{backend}:{version} and flagos-runtime-{vendor}-{backend}:{version}), and the comments describe the release action in three steps: update these two fields, tag v<version>, done. In other words, the previous day’s rc tagging across modules only pushed candidate versions into the verification slot, whereas this bump points the entire image line at 2.2.0 — the only global switch within the org before 2.2 GA.

Cross-checked against other evidence, the cadence lines up: community’s 2.2 release schedule sets feature freeze at 08-31, the testing and stabilization period from 09-01 to 09-24, and GA at 2026-09-28; the “FlagOS 2.2” milestone currently has 7 open issues, none closed, with the same due date of 09-28. Among the 24 module entries in the RC2 list, only FlagGems has been tagged v5.4.0-rc2.post2, while the rest remain at rc2.post1. The build-infra repo’s own latest tag is still v2.1.1, prior to v2.2.0, indicating the image tags have yet to land — with 11 days left until GA, the window for multi-chip acceptance is narrowing.

Worth noting is the synchronization: on the same day, build-infra also submitted the Kunlunxin base image xCCL installation (#917) and a containerfile fix (#918), both filling in vendor dependencies before the 2.2 image line freezes — a typical “last mile before release” move.

I. Open-Source Project Progress (GitHub Activity)

Window Overview: Of the 54 repositories in the org, 19 had pushes during the window; a single commit search returned 150 in-window commits (two pages, sorted by committer-date descending, full set retrieved), distributed across 15 repositories: FlagGems 71, build-infra 18, Torch-FL 17, FlagGems-sglang 10, FlagTree 8, FlagFFT 7, FlagGems-Experimental 5, FlagGems-vllm 4, FlagQuantum 2, vllm-plugin-FL 2, community 2, plus FlagCX, FlagTrain, FlagScale-Agent, and flir with 1 each. Four additional repositories—docs, release-info, sglang-plugin-FL, and TransformerEngine-FL—had pushes during the window but no new in-window commits on their default branches (these were side-branch or tag pushes; docs and release-info handle release artifacts and documentation site synchronization).

This window’s shape = “release artifact freeze” + “post-switch fallout repair” on two tracks: On the governance side, build-infra bumped version numbers and community synchronized release priorities to close out 2.2; on the engineering side, attention shifted from “adding operators to the operator library” to two types of wrap-up work—first, registering newly merged operators into specifications (export checks, test markers, benchmark alignment), and second, absorbing the concrete issues exposed across chip platforms by last week’s routing switch (MetaX’s slice operators, MUSA’s complex rotary position encoding and RNG bridge, CUDA’s missing FlagTune). FlagTrain is the only new repository this period, but it is currently just a placeholder.

1.1 build-infra: base version 2.1.2 to 2.2.0, FlagGems pinned to 5.4.0-rc2.post2 (09-17)

Date: 2026-09-17　Source: build-infra #916, build-infra configs.yaml

See “Today’s Highlights.” One additional point of comparison: the flaggems field jumped directly from 5.3.5 to 5.4.0-rc2.post2, crossing a minor version and two rc rounds, indicating that the operator library previously bound to the 2.1.2 image line had already accumulated significant validation distance from the 2.2 candidate; meanwhile, build-infra’s latest tag remains at v2.1.1, with v2.2.0 not yet appearing—a point to watch in future daily reports.

1.2 FlagTrain repository lands: an empty placeholder repo appears on the training side (09-16)

Date: 2026-09-16　Source: FlagTrain repository

At 15:02 on 09-16, a new repository FlagTrain was added to the org. The repo creation and its sole commit (Initial commit) were less than a second apart; the repository is 5 KB, has no description, no language statistics, and a README with only a single title line—a typical placeholder creation. By naming, it falls on the training side of FlagOS: that direction currently has FlagScale (training framework entry point), Megatron-LM-FL and TransformerEngine-FL (training kernels and parallel operators), and FlagScale-Agent (automated tuning). The new repository’s positioning will have to wait until the README and directory are populated, but the act of “carving out another piece on the training side” is itself worth recording. Per org convention (FlagSparse and Open3D-PIMC were both created first and populated in batches later), code typically lands within days to weeks after repository creation.

1.3 FlagFFT: 36 FFT operators accepted in one pass, with independent NumPy validation and runtime plans (09-16)

Date: 2026-09-16　Source: FlagFFT operator acceptance commit, FlagFFT repository

At 15:38 on 09-16, FlagFFT received a +2151/-2298 commit feat: accept 36 FFT operators with NumPy validation and runtime plans, moving 36 FFT operators into acceptance status in one pass, with changes across 8 files: two configuration files for the operator list and test matrix, build declarations, an acceptance test runner, and a pair of reference implementation tools specifically for independent validation (the C++ side captures baseline output, the Python side performs per-operator comparison). Within the following two hours, two companion commits were added: test: enforce complete acceptance coverage and update CI reporting (15:44) made acceptance coverage mandatory and changed the CI reporting approach, and fix: preserve report compatibility and test interruption handling (15:58) fixed report compatibility and interruption handling.

Reading the three together, FlagFFT’s substantive change this round is not “36 more operators” but an upgrade in acceptance standards: using independently captured NumPy output as the reference implementation, compared item by item alongside runtime plans, rather than self-certifying unit tests. In the RC2 list, FlagFFT’s candidate version is v0.2.0-rc2.post1, and this acceptance line is precisely its basis for moving from rc to GA.

1.4 FlagGems operator expansion: eighteen Nvidia operators from KernelGen merged (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems repository commits, FlagGems #6135 histogramdd, FlagGems #5961 slice_copy

During the window, the KernelGen line continued feeding Nvidia operators into the main repository at a rate of over ten per day. A total of 18 newly merged operators with Triton kernels cover four categories: shape and indexing (dimension reduction, slice copy, channel shuffle, same-shape determination, dimension-wise gather), linear algebra and special functions (tensor inverse, log-determinant, Sobol sequence, exponential function), training and backward (trace backward, masked softmax backward, sparse embedding backward, random dropout), and pooling and sampling (fractional 3D pooling, nearest-neighbor 3D upsampling backward). The type distribution matches the previous window—linear algebra, special functions, and training backward operators each take a segment.

What truly reflects engineering effort are the three accompanying registration and test specification items: one adds sorting and consistency checks to operator exports, one narrows the “use FlagGems instead of ATen” check to newly added lines to avoid interference from historical code, and another automatically derives test markers for underscore operators per naming conventions. There is also a [Test] Align MM tests and parallel FP8 benchmark with scaled-MM API (#6329) aligning the scaled matrix multiplication interface on the test side. The side effect of batch merging is rising “registration cost,” and these items are precisely about codifying that cost into CI.

1.5 FlagGems quantization operator line: Moore Threads native FP8 W8A8 MM, MetaX W8A16 RMSNorm (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems #6211 Moore Threads FP8 W8A8, FlagGems #6326 MetaX W8A16 RMSNorm, FlagGems #4412 FP8 topk

The Moore Threads line adds a native FP8 W8A8 matrix multiplication backend (#6211, 5 files, +1100/-80): a vendor-native path implemented under the Moore Threads backend’s quantized matrix multiplication directory, existing alongside the Nvidia Hopper version, with complete benchmark scripts and tests, indicating this path is delivered as a “hardware-close native implementation” rather than “generic kernel plus fallback.” The MetaX line adds W8A16 RMSNorm (#6326), extending quantization scope from matrix multiplication to normalization layers; the same period also optimized FP8 topk dispatch (#4412). Together with test-side alignment of the scaled matrix multiplication API and batch fixes in fix ops bugs (#6259), there are 7 commits directly related to quantization this window. Taken together, W8A8/W8A16 coverage is spreading from “the matrix multiplication layer” to adjacent operators such as normalization and sampling, consistent with 2.2’s positioning of quantization operators as the main expansion line.

1.6 FlagGems-vllm: fused Marlin MoE and FP8 variable-length FlashAttention-2 (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems-vllm #750 fused Marlin MoE, FlagGems-vllm #749 FP8 variable-length attention

Two large changes apply the same approach at the inference operator layer. First, [QC] Add INT8 and FP8 W8A16 fused Marlin MoE (#750, 7 files, +3118/-46) adds fused Marlin MoE operators for both INT8 and FP8 W8A16 weights, with two benchmark scripts, one test, and an Nvidia backend tuning configuration tune_configs.yaml, and updates the operator selection tool. Second, [QC] Add FP8 W8A8 variable-length FlashAttention-2 (#749, 5 files, +4710) adds FP8 FlashAttention-2 for variable-length sequences, covering the most common shapes in the prefill stage, and registers it in conf/operators.yaml.

Both operators point to the same class of gap: inference-side quantization operators were previously concentrated on fixed shapes and dense paths, whereas variable-length batches and MoE sparse activation are the mainstream forms in actual serving. The acceptance bar for such operators is also higher—the fact that two benchmarks and tuning configurations are merged simultaneously means they are delivered to a “tunable, reproducible” standard rather than merely “it runs.”

1.7 Torch-FL: from “routing switch” to “post-switch fallout repair” (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: Torch-FL #306 MetaX workaround, Torch-FL #316 MUSA rotary position encoding, Torch-FL #310 pin back to FlagGems master

The main action of the previous window was redirecting operator dispatch across six platforms toward “FlagGems first.” The 17 commits this window are almost all echoes of that switch, divisible into three categories by handling approach.

The first category is named workarounds: on MetaX, slice.Tensor was moved out of the FlagGems route, and this was used to unblock the manual test flow for Qwen-Image-2512 (#306); on MUSA, the complex-form rotary position encoding operator was kept executing on the device side (#316, 8 files, +99/-7, including generated code under csrc/aten/backends/musa/ and generation rules in codegen_mudnn.py), while the RNG bridge on the vendor operator module was rebound (#298). The second category is explicit switches: due to a regression in upstream FlagGems master, CI was temporarily pinned back to the last usable commit (#310); on the CUDA line, USE_FLAGTUNE=0 was set before FlagTree brought in FlagTune (#311); and the build-time accelerator configuration was written into the wheel (#314, with unit tests) to avoid discovering the build target only after installation. The third category is gate construction: explicitly detecting PPU in the operator test gate (#309), changing the PPU test list to read from ppu.yml rather than an embedded JSON (#305), attaching platform pipelines uniformly after platform-independent checks (#304), and having CI track FlagGems master across all platforms (#301).

Taken together, the three categories form a reusable response pattern: what can be fixed goes through routing workarounds with tests left behind; what cannot be fixed is blocked with explicit switches; and finally the basis for judgment is collected into gates. For the proposition of “one operator library reused across chips,” the length of the workaround list is itself a usability metric.

1.8 FlagTree: FlagTune managed Manifest and iluvatar3.6 baseline workflow (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagTree #1103 FlagTune managed Manifest, FlagTree #1197 Iluvatar baseline workflow, FlagTree #1190 PPU benchmark results

The main change is a major overhaul of FlagTune (the auto-tuning subsystem) (#1103, 17 files, +687/-153): adding managed Manifest defaults and runtime compatibility handling, with changes spanning the contract layer (operator schemas and expression definitions), the search layer (genetic algorithm search and interface conventions), and the runtime layer (auto-tuner, benchmark protocol, device abstraction, and error definitions), plus four sets of tests (benchmark protocol, model profiles, model sources, runtime errors). So-called managed defaults mean that tuning configuration defaults no longer depend on local generation but are provided uniformly from one place—especially important for combinations of multiple chips and multiple Triton versions.

The companion engineering line advanced the same day: adding an iluvatar3.6 FlagGems baseline and test workflow for Iluvatar (#1197), updating PPU benchmark results (#1190), extracting backend initialization for FlagGems test templates into a unified interface (#1192), switching the hcu line’s benchmark scripts to a script that cleans up circuit-breaker processes (#1188), and adding ignores for intermittently failing Ascend TLE cases (#1185).

1.9 FlagQuantum: JAX tests integrated, coverage floor raised to 60% (09-17)

Date: 2026-09-17　Source: FlagQuantum #48 JAX tests and coverage floor

At 11:05 on 09-17, FlagQuantum received a +429/-5 commit formally integrating JAX tests into continuous integration: adding one hybrid frontend test and five unit tests (batch pullback, MPS kernel, state vector kernel, tensor network contraction, tensor network kernel), updating the CI workflow and test configuration in sync, and writing the 60% coverage floor into the coverage policy file under the contract directory—that is, fixing the quality threshold as a contract file rather than a workflow parameter. The repository is positioned as a “PyTorch-first quantum AI framework,” and integrating JAX shows it is bringing a second frontend under the same acceptance standard, consistent with FlagOS modules’ general practice of “define the contract first, then fill in the implementation.”

1.10 FlagCX and vllm-plugin-FL: PTD log streaming, T-Head PPU CI integration (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagCX #601 PTD log streaming, vllm-plugin-FL #518 DAMO XuanTie PPU CI, vllm-plugin-FL #528 Kunlunxin fix

FlagCX’s change is small but critical: the cross-chip communication library’s performance tool PTD read the entire log into memory at once when converting logs to OpenMetrics, causing the prepare stage to exit due to memory exhaustion under large-scale runs; #601 changes the conversion to streaming processing (tools/PTD/src/prom2openmetrics.py, +68/-29). The cost is an extra state machine layer; the benefit is that the tool itself no longer becomes a bottleneck on stress-test scale.

Two items on the inference plugin line: DAMO XuanTie PPU’s CI is formally integrated (#518, 9 files), adding platform configuration configs/thead.yml, environment preparation and check scripts, image docker/thead/Dockerfile, and platform test list tests/platforms/thead.yaml, while also fixing the MetaX platform list and cleanup tool; the Kunlunxin side fixes state pollution left after FlashAttention module import failure (#528). Reading PPU CI integration alongside Torch-FL’s explicit PPU detection in 1.7 of this report, the DAMO XuanTie line’s self-built test coverage clearly strengthened this window.

1.11 Other activity: community, FlagGems-Experimental, flir, FlagScale-Agent, image tag records (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: community 2.2 project sync, FlagGems-Experimental MetaX index_select, flir #74, build-infra Kunlunxin xCCL

  • community: Synchronized release priorities into the project view (workflow .github/workflows/flagos-2.2-project-sync.yml, +60/-1) and ensured 2.2 items remain visible during the release period; the governance action occurred on the same day as the version bump, part of the 2.2 closeout.
  • FlagGems-Experimental: Fixed MetaX’s index_select implementation (#419), added MetaX support for conv_depthwise2d (#391), and added the dense_dim operator (#639)—this repository continues to serve as a testing ground where “backend adaptations land first and enter the main repository after validation.”
  • flir: Removed the Pure marker from tile.to_tensor to align with upstream bufferization semantics (#74); the change relates to the Ascend TLE line.
  • FlagScale-Agent: Fixed the clone address in the documentation to point to its own repository (#42).
  • build-infra image line: Installed xCCL in the Kunlunxin base image (#917) and fixed its containerfile (#918); also recorded six vLLM application image tags (two each for Moore Threads musa5.2.0 and musa4.3.6, and Enflame tops1.9.10 and tops1.10.6), and cleaned up the outdated pending-release changelog for Kunlunxin 0.24.0 (#911).

II. News Coverage and Ecosystem

2.1 Thirteenth Consecutive Quiet Window for Component-Level Search: Zero Hits in 24 Hours (09-16 to 09-17)

Date: 2026-09-16 to 2026-09-17　Source: Google News RSS (33 query sets in Chinese and English, zero hits within the window)

This issue ran 33 searches, split evenly between Chinese and English, using keywords including FlagOS, FlagGems, FlagScale, FlagTree, FlagPerf, FlagCX, KernelGen, FlagAttention, as well as “智源研究院 开源”, “BAAI open source”, and “众智 FlagOS”. Zero hits within the 24-hour window. The most recent reports related to component names remain the 09-15 10:16 English piece on the Open3D-PIMC open-source release and the 09-14 Chinese hardware article. This is now the thirteenth consecutive quiet window.

Based on prior observations, FlagOS’s external visibility follows a “monthly rhythm”: only three types of events—version releases, industry conferences, and Day0 chip adaptations—generate coverage peaks, while the testing period before a release is precisely a silent period. The visibility peak for this cycle is expected around the 09-28 GA. Concurrent HN Algolia queries (FlagOS / FlagGems / FlagScale / FlagTree) also returned empty.

2.2 FlagOS 2.2 Timeline and RC2 Manifest Review: GA Set for 09-28 (09-17 Verification)

Date: 2026-09-17 (verification date)　Source: 2.2 release schedule, 2.2 RC2 source manifest, milestone FlagOS 2.2

A full check of the release artifacts was performed. Timeline: feature freeze 08-31, testing and stabilization period 09-01 to 09-24, GA 09-28; the freeze rules specify an exception channel (security patches, critical defects, and CI blockers may use the expedited channel, subject to TSC approval), as well as graduation criteria—only when an executable test plan passes during the testing period does an FEP’s status change from “implementable” to “implemented.”

Manifest: RC2’s 24 module entries cover the L0 infrastructure layer (FlagTree split into three tracks for Triton 3.6 / 3.5 / 3.3, FlagCX), the operator layer (FlagGems, FlagFFT, FlagSparse, FlagDNN, FlagBLAS, FlagTensor, FlagAudio, FlagAttention), the inference plugin layer (FlagGems-vllm, FlagGems-sglang, Torch-FL, vllm-plugin-FL, sglang-plugin-FL), the training layer (TransformerEngine-FL, Megatron-LM-FL, FlagScale), and the release and tooling layer (KernelGen, KernelGenBench, FlagRelease, compressor). In terms of versions, only FlagGems is at rc2.post2; the rest are at rc2.post1; FlagTree retains its own naming format of 0.7.0rc2.post1+triton3.x.

On the milestone side: all 7 issues for 2.2 are currently open, with a due date of 09-28, consistent with the timeline. Overall, 2.2 is in the “code frozen, acceptance wrap-up” stage, with no signs of delay.

2.3 Horizon Ecosystem: D-Robotics Completes $400 Million Series C (09-17)

Date: 2026-09-17　Source: PEdaily report

On 09-17, D-Robotics (Chinese name 地瓜机器人, a robotics software and hardware foundation company incubated by Horizon and spun off in 2024) announced the completion of a $400 million Series C round. The round was led by Mirae Asset, with participation from industrial and government investment platforms including Meituan Strategic Investment, Hefei State Investment, Nanshan Zhansin Investment, and Jingquan Capital, as well as institutions including Cathay Capital, Huamei International, GF Xinde, Beyond Moore, and the Xinchip Phase II Fund under Qihang Investment; existing shareholders including Hillhouse Venture Capital, Morningside Venture Capital, Linear Capital, Huangpu River Capital, Temasek’s Vertex Growth, Prosperity7, Hexuan Capital, Yunfeng Fund, Meituan Longzhu, and Jiuhe Venture Capital continued to increase their investments.

The use of funds is stated specifically: to strengthen the full-compute-range product lineup of the Sunrise chips, and to build a full-link software platform spanning “data collection—model training—simulation verification—inference deployment.” The accompanying operational data is also informative: revenue in the first half of 2026 grew severalfold year-over-year, cumulative shipments of the Sunrise series chips exceeded 8 million units, the embodied intelligence business has entered mass-production-level shipments, and the flagship S600 was adopted by more than 20 leading customers within half a year, with embodied intelligence customer coverage exceeding 50%.

The significance for this report’s topic lies in its position on the software stack side: Horizon (including its robotics arm) is one of FlagOS’s member organizations, and its chips and edge platforms are the landing points for FlagOS’s edge and embodied intelligence directions; the stated scope of building a “full-link software platform” overlaps heavily with the problems FlagOS-Robo aims to solve on the robotics side, and it will be worth watching whether its software platform subsequently incorporates FlagOS components.

2.4 Member Capital Developments: MetaX Interim Report Turns Profitable, Enflame’s Market Cap Tops 100 Billion on Debut, Domestic GPU Interim Reports (09-16 to 09-17)

Date: 2026-09-16 to 2026-09-17　Source: Huxiu MetaX interim report, Sina Finance Enflame debut day, Leiphone domestic GPU interim report analysis

Member organizations’ external narratives this period centered on the capital side, with three points: MetaX turned profitable in its 2026 interim report, with its core business still in an investment phase (09-16); Enflame Technology’s market capitalization exceeded 100 billion yuan on its first day of trading, with 09-17 analysis shifting to its ownership structure of “market-oriented GPs plus local state-owned enterprise LPs”; Leiphone on 09-17 summarized the interim reports of four domestic GPU companies, with the takeaway being secondary-market valuation tolerance. On the same day’s market side, Moore Threads, MetaX, and Cambricon all saw significant fluctuations, which constitute market information rather than ecosystem developments and are not included as items in this report.

It should be noted where the boundaries lie: none of the above three items can serve as evidence of FlagOS project progress; they are merely circumstantial evidence of member organizations’ operating and financing status. This period, technical activity related to FlagOS still appears only on GitHub, which is also a common feature of several consecutive windows.

III. Deep Dive into Member Organizations

3.1 Hygon: Filling Both Ends — linalg and dtype Semantics (09-16)

Date: 2026-09-16　Source: FlagGems #5390 linalg_lstsq, FlagGems #5959 linalg_matrix_power, FlagGems #6351 nansum dtype

Hygon had no single major move this period, but rather three parallel fill-ins: first, linalg_lstsq supports three backends at once (Hygon, MetaX, Iluvatar), indicating that multi-chip implementations of linear algebra operators like least squares are beginning to advance as a group; second, linalg_matrix_power supports Hygon and Iluvatar, part of the matrix function series; third, the integer dtype promotion fix for nansum covers Nvidia, Ascend, MetaX, and Hygon simultaneously, with int8/uint8 test cases added — this is semantic consistency work, fixing not performance but the problem of “the same operator yielding different types across backends.” In the previous window, Hygon’s focus was on toolchain and packaging environment adaptation (gflags headers, TLE whitelist, images); this window shifts to operators and semantics, and this directional switch indicates that its foundational environment issues have largely been closed out.

3.2 Ascend: The Densest Line of Operators Required for MoE and Linear Attention (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems #6324 swiglu, FlagGems #6325 grouped_matmul, FlagGems-vllm #789 compressor, FlagGems-vllm #788 chunk_gated_delta_rule_fwd

The Ascend line had the densest submissions this period, concentrated in two hotspots of current large model architectures. On the MoE side: swiglu activation (#6324) and grouped_matmul grouped matrix multiplication (#6325) — the former is the activation function of the MoE feed-forward network, the latter is the core operator for expert parallelism; together they mean a complete MoE layer computation can be closed within the operator library. On the linear attention side: compressor (#789) and chunk_gated_delta_rule_fwd (#788), two fused operators entering the inference plugin repo, corresponding to the chunked forward pass of GDN-type linear attention; combined with the semantic alignment of tile.to_tensor in flir (#74, involving the Ascend TLE line), and two norm implementations linalg_norm (#6355) and linalg_matrix_norm (#5670), Ascend has the most comprehensive operator-side coverage this period.

3.3 DAMO XuanTie: Inference Plugin Onboards PPU CI, MM/MV Supports NN/NT Layouts (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: vllm-plugin-FL #518 PPU CI, FlagGems #6302 MM/MV layout optimization, FlagTree #1190 PPU benchmark

The DAMO XuanTie (PPU) line this period ran on two tracks: test infrastructure and performance. On the testing side: vllm-plugin-FL brings PPU into continuous integration (#518, adding platform configuration, environment setup scripts, images, and a platform test checklist), Torch-FL explicitly probes for PPU in the operator test gate rather than relying on the default branch (#309), and the PPU test checklist now reads from ppu.yml (#305). On the performance side: FlagGems adds support and optimization for NN and NT layouts in matrix multiplication and matrix-vector multiplication (#6302), and FlagTree updates PPU benchmark results (#1190) and fixes tl.load/tl.dot behavior on PPU and MetaX (#1191). Pushing a platform from “can run operators” to “can be continuously validated in CI” is the dividing line between usability as a case-by-case matter and as the norm.

3.4 Moore Threads: Native FP8 W8A8 MM and MUSA Rotary Position Embedding Back on Device (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems #6211 native FP8 W8A8, Torch-FL #316 MUSA rotary position embedding, Torch-FL #298 RNG bridge

Three actions point to the same goal — reducing fallbacks for the MUSA backend in quantized inference and long-context models. On the operator side, a native FP8 W8A8 matrix multiplication backend is added (#6211); on the adaptation side, the complex-valued rotary position embedding operator is kept executing on-device (#316), avoiding what would otherwise be element-wise fallback to the host; on the stability side, the random number bridge on the vendor operator module is re-bound (#298), fixing seed and stream consistency. On the image side, build-infra records two application image tags for MUSA 5.2.0 and 4.3.6, and adds a pending-release changelog for the 0.24.0 rc2 rebuild (#913/#914/#915). The rotary position embedding and RNG bridge are “unremarkable but must-pass” threshold items, and are common dividing lines for whether cross-chip inference precision can be aligned.

3.5 MetaX: W8A16 RMSNorm and Three Routing Bypasses (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: FlagGems #6326 W8A16 RMSNorm, FlagGems-Experimental #419 index_select, Torch-FL #306 slice.Tensor bypass

The MetaX line this period was mainly “add one operator, bypass three paths.” On the operator side, W8A16 RMSNorm is added (#6326), extending quantization precision to the normalization layer; in the experimental repo, the index_select implementation issue is fixed (#419) and depthwise convolution support is added (#391). On the routing side, three bypasses: Torch-FL moves slice.Tensor out of FlagGems routing to unblock the manual test flow for Qwen-Image-2512 (#306), bypasses FlagGems routing for matrix multiplication in certain scenarios (paired with the gate in 1.7), and fixes the test reference implementation for linalg_solve_triangular on the FlagTree side (#6341). Bypass entries are not achievements in themselves, but only by recording them one by one by name can subsequent versions have a basis for convergence.

3.6 Kunlunxin: xCCL Baked into Base Image, Operator Fix Batch Lands (09-17)

Date: 2026-09-17　Source: build-infra #917 xCCL, FlagGems #6328 operator fixes, FlagGems #4540 topk_softmax stub

The Kunlunxin line this period consisted of three types of actions. On the image side: the base image incorporates xCCL (#917) and its containerfile is corrected (#918) — pre-installing the vendor communication library into the base image means cross-chip communication on its platform no longer depends on runtime external attachment, consistent with the direction of FlagCX toolchain improvements in section 1.10 of this report. On the operator side: a batch of fixes lands simultaneously, covering five operators masked_fill, sinh, mish, hardswish, index_fill (#6328); topk_softmax gets a kernel stub for the C++ launcher (#4540); and a dimension-skipping logic in softmax_backward that had already been resolved is removed (#4539). On the engineering side: tests are changed to run inside containers (#6343), and the residual state after FlashAttention module import failure in the inference plugin is fixed (#528). Taken together, this is a preparation action to “align the test environment and dependencies in one pass.”

3.7 Iluvatar: /dev/itrctl and iluvatar3.6 Baseline Workflow (09-17)

Date: 2026-09-17　Source: FlagGems #6376 /dev/itrctl, FlagTree #1197 iluvatar3.6 baseline, FlagGems #5390 linalg_lstsq

The Iluvatar line this period had two infrastructure changes plus one operator fill-in: FlagGems’ CI/CD configuration hooks into the /dev/itrctl device node and updates packaging configuration (#6376), indicating its test environment needs access to the device control interface; FlagTree adds a FlagGems baseline and test workflow for iluvatar3.6 (#1197), establishing a comparable performance and correctness baseline for that backend; on the operator side, it shares the multi-backend implementation of linalg_lstsq with Hygon and MetaX (#5390). Additionally, build-infra fixes a stale environment variable that would break corex clang (#901). Reading the three together, Iluvatar’s current stage is “getting the CI baseline up.”

3.8 Enflame: GCU300 Recorded in 0.24.0 Report and Two Image Tags (09-16)

Date: 2026-09-16　Source: build-infra #910 GCU300 record, build-infra #900 gate cases, FlagTree #1185 TLE test

The Enflame line this period fell entirely on the build and validation side: writing the GCU300 run record into the vLLM 0.24.0 report (#910), recording gate case run results and blockers under graph mode (#900), and recording one application image tag each for the tops1.9.10 and tops1.10.6 toolchains (#906/#907). Also on the FlagTree side, an ignore is added for the occasionally failing fused softmax case in the Ascend TLE line (#1185) — such “occasional failures” in cross-chip CI usually mean environment differences rather than logic defects, and marking rather than patching is a reasonable choice at the current stage. Enflame’s capital-side actions (09-15 listing, 09-16 first-day market cap breaking 100 billion) do not change its engineering focus; the technical line remains primarily about bringing the GCU platform into the multi-chip validation matrix.

3.9 BAAI (Lead Organization): Governance Automation and Version Bump (09-16/09-17)

Date: 2026-09-16 to 2026-09-17　Source: community 2.2 project sync, build-infra #916

As the lead organization, BAAI’s work this period focused on governance rather than code output: community syncs release priorities into the project view and ensures 2.2 items remain visible during the release period; build-infra bumps the version number, pointing the entire image line to 2.2.0. Combined with the role definition in the 2.2 schedule that “the Release Manager maintains the test matrix in the tracking issue and organizes Go/No-Go per the release process,” it is clear that the release mechanism has shifted from manual table-checking to being driven by the trio of “project view + tracking issue + checklist files.” With 11 days to GA, the next observable signal on BAAI’s side is the Go/No-Go conclusion and the acceptance status transitions of each FEP.

IV. Summary and Trend Observations

  • 2.2 has entered the release artifact freeze stage: build-infra bumps the version field to 2.2.0, the only global release switch within the org; thereafter rc tagging of individual modules only affects candidate snapshots and no longer changes the version number. GA is set for 09-28, with about one week left in the testing period.
  • The share of engineering quality work is rising: of the 150 commits, CI, testing, and fix categories together account for about a quarter (counting only commits starting with ci, test, fix, there are 23), and KernelGen’s bulk ingestion is forcing standards such as export checks, test marking, and benchmark alignment into place — the bottleneck for scaling has shifted from “writing kernels” to “registration and acceptance.”
  • Cross-chip usability advances via “routing plus bypass lists”: the main output of Torch-FL and vllm-plugin-FL this period is bypass entries and gates rather than new features; operators taken over by vendor kernels already have a named list (MetaX’s slice operators, MUSA’s complex rotary position embedding, CUDA’s missing FlagTune), and the length of this list is an inverse indicator of cross-chip reuse rate.
  • Two main operator scaling lines are clear: first, quantization (W8A8, W8A16, FP8), expanding from matrix multiplication to normalization and sampling, with representative commits being Moore Threads’ native FP8 W8A8 MM and fused Marlin MoE; second, MoE and linear attention (grouped matrix multiplication, swiglu, compressor, chunked gated delta rule forward), concentrated in the Ascend line.
  • Test infrastructure is converging toward platformization: DAMO XuanTie PPU onboarding into the inference plugin CI, Iluvatar establishing the iluvatar3.6 baseline, and FlagTree extracting a unified backend initialization interface — three different forms of action point to the same goal: enabling every backend to be continuously validated in CI rather than relying on manual runs.
  • The news side remains silent; the technical side is entirely in code: this is the thirteenth consecutive quiet window, and member organizations’ external visibility comes mainly from the capital side ($400 million Series C for D-Robotics, MetaX’s interim report, Enflame’s IPO). The next reporting peak is expected at the 09-28 release window.

Appendix: Source Verification Table

Source Verification Result
GitHub org repo pushed_at (54 repos) 19 repos had pushes within the window, all verified
GitHub commit search (committer-date) 150 commits within the window, both pages retrieved in full, spanning 15 repos
GitHub key repo default-branch commits FlagGems / build-infra / Torch-FL / FlagTree etc. reviewed commit by commit
GitHub tags and releases Latest tags for all modules are rc2.post1 (FlagGems is rc2.post2), no new releases
community release manifest and schedule RC2 manifest’s 24 entries, 2.2 schedule and milestone status reviewed
build-infra configs.yaml Version field bumped to 2.2.0, patch and full file contents retrieved
Google News RSS (33 Chinese/English queries) Zero hits within the window, most recent hit was 09-15
HN Algolia Zero hits within the window
BAAI Hub (hub.baai.ac.cn) No new FlagOS-related posts within the window
PEdaily / BAAI Hub / Sina Finance / Leiphone / JiWei Retrieved entries on member units such as D-Robotics Series C

Full Source List