Research window: 2026-09-10 10:18 ~ 2026-09-11 10:18 Beijing Time Sources: GitHub (org: flagos-ai, 53 repos pushed_at + single commit search 60 entries fully verified by committer-date + per-repo commits re-check + branch API + commit details and patches), Google News RSS (13 query sets in Chinese and English, via proxy), HN Algolia, Tavily/web search, FlagOS official CSDN account, BAAI Community (see appendix for details)

Index

    1. Open-Source Project Progress (GitHub Activity)
      • 1.1 FlagTree version converges to 0.7.0: 29 vendor delivery workflows switched in one pass (09-10/09-11)
      • 1.2 build-infra: Ascend 910C application layer officially opened, vLLM dual-version four-image enters the matrix (09-10)
      • 1.3 build-infra: sglang0.5.18 startup docs generated across the full matrix, sglang promoted to a first-class application line (09-10)
      • 1.4 build-infra: packaging channel policy formalized, installation channel boundaries locked down (09-10)
      • 1.5 FlagTensor: Hygon DCU and Kunlunxin XPU dual backends merged into mainline, install scripts consolidated (09-10)
      • 1.6 vllm-plugin-FL: Sunrise attention backend ported to vLLM 0.24.0, DAMO XuanTie static graph restored (09-10)
      • 1.7 FlagGems: KMCompiler’s Ascend/MetaX dual-track push and installation-surface defect fixes (09-10)
      • 1.8 Domain libraries and toolchain: FlagGems-vllm Hygon operators, FlagDNN backend docs, FlagCX MUSA, Torch-FL DCU routing (09-10)
      • 1.9 FlagTree engineering surface: Tsingmicro CI/CD becomes institutionalized, TLE NVIDIA layout optimization merged and reverted same day (09-10)
    1. News Coverage and Ecosystem
      • 2.1 Ninth consecutive quiet window for component-level news, all information comes from code repositories (09-10)
    1. Member Unit Deep Dive
      • 3.1 Tsingmicro: compiler line moves from “backend can compile” into “pipeline self-sustaining” (09-10)
      • 3.2 Hygon: four lines advance simultaneously — operators, tensor library, domain library docs, runtime routing (09-10)
      • 3.3 Kunlunxin: FlagTensor XPU backend merged, four layers of work advancing in parallel (09-10)
      • 3.4 Sunrise and DAMO XuanTie: external inference GPU and PPU backends both reinforced in the same window (09-10)
      • 3.5 BAAI (lead party): two governance actions — delivery pipeline version unification and packaging policy (09-10)
    1. Summary
  • Appendix: Complete Source List

I. Open Source Project Progress (GitHub Activity)

Window Overview: Of the 53 repos in the org, 13 had pushes during the window; commit search returned 60 in-window commits (full single page, sorted by committer-date descending), and per-repo commits review added 1 more from Megatron-LM-FL (missed due to search index lag), totaling 61 commits across 12 repos: build-infra 24, FlagGems 10, FlagTree 8, FlagTensor 5, vllm-plugin-FL 3, FlagDNN 3, FlagGems-vllm 2, Torch-FL 2, flir 1, FlagFFT 1, FlagCX 1, Megatron-LM-FL 1. No new repos, no new component release entries.

This window’s shape = the “version convergence + chip matrix expansion” dual track of the RC testing period: on the compiler side, FlagTree completed version-number convergence to 0.7.0 and switched all 29 vendor delivery pipelines to 0.7.0 in one shot; on the delivery side, build-infra advanced Ascend 910C from “only base/runtime skeleton” to application-layer availability, and made sglang a first-class application line alongside vllm; on the external ecosystem side, component-level backend landing appeared for Sunrise (曦望), and FlagTensor merged dual backends for Hygon DCU and Kunlunxin XPU. The previous window’s prediction of “when will 910C add deps_app to enter the app build matrix” was fulfilled in this window.

1.1 FlagTree version converges to 0.7.0: 29 vendor delivery workflows switched in one shot (09-10/09-11)

Sources: FlagTree #1144 (09-10 23:38), #1151 (09-11 02:31)

  • Mainline version number raised to 0.7.0 (#1144): the version function was changed to "0.7.0+" + flagtree_backend + commit hash (returns 0.7.0 + hash when there is no backend suffix); the commit landed six supporting items in parallel — refreshed PPU/HCU qwen3.6 benchmark performance baselines, added tsingmicro3.6 notes to the README, added LICENSE to the wheel, fixed TileIR’s third_party download, fixed the Iluvatar workflow’s library path; the README’s vendor/backend table was also changed from “Installation” to “User Guide” and expanded.
  • 29 vendor delivery workflows switched to 0.7.0 in one shot (#1151): the default value of the version input parameter in *_delivery.yml was changed from '0.6.0' to '0.7.0' in one shot, and the ppu3.6 core test workflow was updated at the same time. The 29 lines involved are: nvidia3.3/3.5/3.6/3.7/3.8, tileir3.6, amd3.6, ascend3.2/3.5, enflame3.5-gcu400/3.6-gcu400, iluvatar3.1/3.6, metax3.0/3.6, mthreads3.1/3.2/3.6, tsingmicro3.3/3.6, sunrise3.4, xpu3.0/3.6, hcu3.1/3.6, aipu3.3, thrive3.6, ppu3.6.
  • Branch-side status: the heads of 0.7.0-rc0-triton3.3/3.5/3.6 are at 08-11, 08-27, 08-31 respectively; 0.7.0-rc1-triton3.3/3.5/3.6 are at 09-01, 09-04, 09-04, where the head commit of rc1-triton3.6 is [Tsingmicro] Add Tsingmicro backend integration (Triton 3.6) (#1071).
  • No official release yet: the latest FlagTree entry on GitHub Releases is still 0.6.0+triton3.x (2026-06-24); this window’s actions are “delivery pipelines first, version-number convergence”, with the official tag still pending.

Interpretation: The way 0.7.0 is being advanced clearly reflects RC-period discipline — no change to the code roadmap, only convergence of version numbers and delivery entry points: first raise the package version from 0.6.0 to 0.7.0 on main, then point all 29 vendor delivery pipelines uniformly at 0.7.0, thereby pushing the RC1 checklist anchor of “flagtree three lines unified to 0.7.0rc1.post1” toward an official version. One misalignment worth tracking: in build-infra’s configs.yaml, the NVIDIA line is still pinned at flagtree==0.6.1, i.e. there is a one-version advancement gap between “the compiler version locked by delivered images” and “the compiler mainline version” — precisely the gap that needs to be closed before GA.

1.2 build-infra: Ascend 910C application layer officially opened, vLLM dual-version four images enter the matrix (09-10)

Sources: build-infra #816 (09-10 18:36), #813 (15:07), #808 (11:00), #818/#819, #823/#824, #820, #825, #826, #828, #833, #834

  • Application layer opened (#816, +257/-16): the commit message states that “the 910C runtime image has been built and pushed, so the vllm application line can be opened on both 910C lines (ascend-cann8.5.0-910c / ascend-cann9.0.0-910c)”. Four changelogs were added at the same time — vllm0.20.2 and vllm0.24.0 each corresponding to CANN 8.5.0 and 9.0.0; the changes cover vllm-app-image.yml, app/vllm/Containerfile, configs.yaml, docs/status-matrix.md, the two status_matrix.vllm*.yaml files, and the rendering script.
  • 910C application image tags begin to land: #818/#819 record CANN 8.5.0-910c’s 2.1.2-0.2.0_g2b6b635.d20260824 and 2.1.2-0.2.0_gcf8998c.d20260818; #823/#824 record the corresponding tags for CANN 9.0.0-910c.
  • Stabilization in preparation for opening: #808 removes the apt Post-Invoke hook from the 910C base image; #813 makes the Ascend startup template expose the full pair of dies (two cards within the same die visible as a pair); #820 makes Ascend verify self-diagnose on failure; #825 forwards the runner proxy into the verify installation step; #826 selects a runner python that can import ruamel.yaml; #828 fixes quote escaping in verify Step 2; #833 builds the flashinfer stub only when the target ref contains stub; #834 passes the cell’s plugin pin forward to the vllm application image build.

Interpretation: This is the precise fulfillment of the previous window’s prediction. The observation point in the 09-10 report was that 910C “was onboarded as a chip-isomorphic variant of the 910B line, blocked outside the app matrix by the absence of deps_app”, with the prediction at the time being “to be opened after app artifacts are produced and verified”. #816 in this window is exactly that gate being opened: 910C’s delivery form is upgraded from “base/runtime available” to “application available”, and it gives 2 CANN lines × 2 vLLM versions = four application image entries in one shot. The accompanying nine verify/template/image fixes show that this is the wrap-up engineering under the “new adaptations allowed, new features not allowed” discipline — first make environment issues like verify self-diagnosis, proxy forwarding, and dependency selection stop blocking the pipeline, then open the matrix.

1.3 build-infra: sglang0.5.18 startup docs generated for the full matrix, sglang elevated to a first-class application line (09-10)

Sources: build-infra #831 (09-10 21:38), #817 (19:13), #821 (19:20), #829 (20:42), #830 (20:55)

  • #831 fixes the generator’s filtering logic (+2862/-34): the commit message points out that the generator used a in APP_IMAGE_DEFAULTS or a.startswith("vllm") to filter deps_app keys, causing sglang0.5.18 to be discarded before reaching the renderer, so previously no sglang application image had a startup page; after the fix, bilingual (Chinese-English) startup docs are generated for all sglang application images.
  • sglang application lines covered: ascend-cann8.5.0 / ascend-cann9.0.0 (Ascend), cambricon-neuware4.4.3 / 4.7.2 (Cambricon), enflame-tops1.9.10 / 1.10.6 (Enflame), hygon-dtk26.04 (Hygon), iluvatar-corex4.5.0 (Iluvatar CoreX), metax-maca3.7.2.1 / 3.8.1.3 (MetaX), etc.
  • Supporting changes: #817 pulls iluvatar-corex4.5.0 onto the sglang 0.5.18 line; #821 adds the sglang0.5.18-iluvatar-corex4.5.0 changelog; #829 fixes a redundant image key in the changelog; #830 records app image tag 2.1.2-0.1.dev1_g201484665.
  • Image descriptions refreshed in the same period: #810 and #814 refresh the 2.1.2 description text for the base and runtime images respectively; #815 makes the flaggems-release runtime:v1 image tag derive from configs.yaml.

Interpretation: This is more important than it appears. vllm and sglang are the two main framework lines through which FlagOS delivers inference capability externally; previously the matrix’s actual shape was “vllm full, sglang scattered”. This window’s actions fill in startup docs and changelogs for sglang0.5.18 on at least 10 chip lines, meaning sglang is now on par with vllm in delivery terms; this echoes the FlagGems-sglang competition line in this window and the “KubeCon Open AI Computing Forum” recorded in the 09-07 report — the breadth of inference framework coverage is becoming a major dimension of the community’s external presentation.

1.4 build-infra: packaging channel policy formalized, installation channel boundaries fixed (09-10)

Sources: build-infra #812 (09-10 21:45)

  • Added docs/content/en/usage/packaging-channels.md (122 lines) and docs/content/zh-cn/usage/packaging-channels.md (97 lines), formalizing the conclusions of earlier discussions into policy: the deb/rpm channel handles pure Python packages and native libraries (one repo per source per target distribution), while each vendor’s private PyPI index handles vendor-side dependencies; the boundary between the two is explicitly written out.

Interpretation: This is a governance-type commit ahead of 2.2 GA, in the same vein as the previous window’s 60 app image changelog baseline + push gating: first be able to explain “where artifacts come from”, then explain “where dependencies are installed from”. For a software stack that must cover the private toolchains of more than a dozen chip vendors, making installation channels a matter of policy is a prerequisite for whether multi-vendor distribution can scale.

1.5 FlagTensor: Hygon DCU and Kunlunxin XPU dual backends merged into mainline, installation scripts converged (09-10)

Sources: FlagTensor #5153939 / #1be84f2 (09-10 10:37, one each), #81c6214 (10:39), #2f895c1 (10:47), #efed2c4 (10:48)

  • Two new backends merged: feat: merge Hygon DCU + Kunlunxin XPU backend support merges the Hygon branch (including the adaptation work from FlagTensor-haiguang) into main, with a diff of +4225/-168 (4393 lines); the bulk of the changes are in the benchmark and backend adaptation layers; another commit add Hygon DCU and Kunlunxin XPU backend support appears in the same minute.
  • Installation and documentation convergence: #2f895c1 merges setup_muxi.sh into a branch of the unified setup.sh --backend metax; #efed2c4 deletes the standalone script; #81c6214 removes the MetaX-specific performance report PERF_REPORT_metax.md.

Interpretation: “Backend count +2, maintenance surface -1 set of dedicated scripts” — a consistent direction: on one hand bringing two new hardware types, Hygon DCU and Kunlunxin XPU, into the tensor library; on the other hand converging vendor-specific installation paths into a unified entry point, avoiding script maintenance costs that grow linearly with the number of vendors. FlagTensor is one of the six domain libraries released in June as part of the “scientific intelligence foundation”; its multi-backend expansion shows that the scientific computing library is still being rolled out toward the goal of “develop once, run on many chips”.

1.6 vllm-plugin-FL: Sunrise attention backend ported to vLLM 0.24.0, DAMO XuanTie static graph restored (09-10)

Sources: vllm-plugin-FL #391 (09-10 20:01), #472 (10:33), #480 (18:22)

  • #391 (+37/-1): titled “port the Sunrise backend to vLLM 0.24.0”; the commit message states the target is Sunrise (曦望 TANGRT 1.2.0); both changes are under the sunrise vendor path — attention.py uses CUSTOM mode for attention backend registration, and patch.py adds a ptpu memory_stats compatibility layer.
  • #472: restores static graph support for the DAMO XuanTie (thead) backend (a regression fix originating from an earlier commit).
  • #480: adds two comment commands for PRs, /rerun-failed-ci and /cancel-ci; the repo README’s chip vendor table now lists Sunrise as Supported.

Interpretation: This is the most substantive step in the external ecosystem this window. The 09-07/09-08 window recorded Sunrise’s progress as merely “runner environment configuration first, no component merged yet”; this window completes component-level landing — plugging Sunrise’s toolchain version (TANGRT 1.2.0) into the vLLM 0.24.0 onboarding outpost plugin. For FlagOS, this shows that the standard path for “onboarding a new chip” (first stand up a runner with the unified environment, then land the vendor backend in vllm-plugin-FL) has now been run through once and is a reusable onboarding template; #480’s two CI ops commands and build-infra’s verify self-diagnosis both belong to engineering cost reduction for “multi-vendor CI maintenance cost”.

1.7 FlagGems: KMCompiler’s Ascend/MetaX dual-line advance and installation-surface defect fixes (09-10)

Sources: #6138, #5821, #6155, #6160, #6156, #6157, #6146, #6087, #6147, #6131

  • KMCompiler generation path: [KMCompiler][Ascend] Opt replication pad2d backward (#6138), [KMCompiler][Ascend] Add ascend backend for linalg_solve_triangular (#5821), [KMCompiler][MetaX] Fix gru bug (#6155) — continuing the “develop once, land on multiple backends” approach to new operators.
  • Vendor CI line contraction: fix(.github): remove metax-maca3720 info (#6160), cleaning up residual information after the earlier removal of the CI entry.
  • Installation and runtime correctness fixes: #6146 adds the missing DSA/__init__.py, so that non-editable installs include that subpackage (directly affecting the installation integrity of downstream plugins); #6087 converts the index operator’s pid_p to int64, fixing an int32 offset overflow; #6147 fixes a dispatch targeting error in adaptive_avg_pool3d_backward; #6131 fixes the benchmark naming for irshift.
  • Engineering surface: #6157 extends the init exports check; #6156 cleans up an erroneously added Apache 2.0 header on a third-party file.

Interpretation: Compared with the previous window’s “39 commits mainly consisting of high-traffic KernelGen operators landing”, this window’s main-repo commit count dropped to 10, and the structure shifted from “volume” to “coverage and consolidation”: the generator path continues to add backends for Ascend and MetaX, while the rest focuses on installation integrity and numerical correctness. Among these, defects like #6146 (“subpackage not installed”) have the greatest downstream impact — the vllm/sglang plugins all depend on the operator library’s complete installation surface, and such fixes are the typical RC-period action of turning “it runs” into “it installs and runs correctly”.

1.8 Domain libraries and toolchain: FlagGems-vllm Hygon operators, FlagDNN backend docs, FlagCX MUSA, Torch-FL DCU routing (09-10)

Sources: FlagGems-vllm #736, #704, Torch-FL #270, #247, FlagCX #576, FlagDNN, FlagFFT, Megatron-LM-FL #148

  • FlagGems-vllm: #736 [AdvancedCompiler] add hygon fused_add_rms_norm, adding 325 lines of Hygon-specific operator implementation and registering it into the _hygon backend, while also adding TensorDescriptor import protection for older Triton versions; #704 adds a pair-load fast path for moe_sum.
  • Torch-FL: #270 perf: restore fused SDPA on the boxing route via a composite override (+658 lines); the root cause is written in the commit and accompanying doc (docs/bench_qwen3_dcu_route_perf.md) — aten::scaled_dot_product_attention is a composite op, and the selection of the fused backend happens inside the composite, so leaf-by-leaf decomposition breaks up the fused path; the fix uses a composite-level override to restore it; this work is explicitly targeted at the DCU route. Separately, #247 adds an automated triage pipeline for transformers tests.
  • FlagCX: #576 [PAL] Link default device API backend for MUSA platform, wiring up the default device API backend for the Moore Threads MUSA platform (makefiles/musa.mk).
  • FlagDNN: three consecutive backend documentation commits — add Hygon readme, fix Hygon readme, add Iluvatar CoreX readme.
  • FlagFFT: updates the README’s backend support description and clarifies dependencies.
  • Megatron-LM-FL: #148 fix(platform): prefer native accelerator detection, platform detection prefers native accelerator identification.

Interpretation: This group is the horizontal rollout of “domain libraries and training/inference toolchain”: Hygon (operators + tensor library + domain library docs + runtime routing), Moore Threads (communication library platform wiring), and Iluvatar CoreX (docs) each had actions in the same window. Torch-FL’s deliverable has an independent benchmark doc and stub source, making it a rare commit of “performance issue with a complete evidence chain”, showing that performance regressions on the training/inference route have been brought into routine tracking.

1.9 FlagTree engineering surface: Tsingmicro CI/CD becomes full-fledged, TLE NVIDIA layout optimization merged and reverted the same day (09-10)

Sources: FlagTree #1118, flir #69, #1047, #1139 (revert), #1075, #1074, #1143

  • Compiler infrastructure on the Tsingmicro side (#1118, +344/-10): fixes the joint build of the tsingmicro backend with FLIR, and adds two workflows — tsingmicro3.6-build-and-test.yml (115 lines) and tsingmicro3.6-delivery.yml (191 lines); on the CMake side a FlagTreeOptions switch is added, and the Tx81 runtime and example tests under third_party/tsingmicro are fixed accordingly; the commit is co-signed by a Tsingmicro-side patch and the community bot. The corresponding FLIR-side commit #69 syncs Tsingmicro’s FLIR patch to support LLVM 22 (FLIR is FlagTree’s IR intermediate layer, forked from triton-shared).
  • TLE NVIDIA layout optimization merged and reverted the same day: #1047 was merged at 12:35 for “lowering layout conversion within the same warp via shuffle”, and was reverted by #1139 at 13:47. On the MTHREADS side in the same window, two substantive merges were retained: #1074 (SQMMA configuration favors pure M-split in selection), #1075 (PH1’s swizzled shared memory access lowered via LinearLayout).
  • Other: #1143 fixes a gcc7 compilation error in the of namespace under the Enflame path.

Interpretation: This Tsingmicro line shows it already has the capability to “bring its own build and delivery workflows” rather than waiting for the community to wire it up — for a vendor that previously existed in FlagTree only as a Triton 3.3 backend, this is a fairly complete step. Conversely, the same-day revert of TLE NVIDIA is worth noting as a footnote on engineering cadence: during the RC freeze period, if a performance optimization introduces a regression, the handling is to revert the same day rather than push forward with the problem, consistent with the “new adaptations allowed, new features not allowed” discipline.

II. News Coverage and Ecosystem

2.1 Ninth consecutive quiet window for component-level news, all information comes from code repos (09-10)

Sources: Google News RSS 13 query groups in Chinese and English (09-10 10:18 ~ 09-11 10:18, via proxy)、HN Algolia、FlagOS official CSDN account、BAAI Hub

  • All component-level queries returned zero hits: FlagOS when:2d, FlagOS when:14d, FlagGems when:3d/14d, FlagScale when:3d, FlagTree when:7d, FlagCX when:14d, FlagAttention OR FlagPerf when:14d, KernelGen when:7d, BAAI open source when:2d, 沐曦 开源 算子 when:2d and other Chinese and English queries all returned no hits, constituting the ninth consecutive quiet window for component-level searches.
  • Member-organization terms yielded noise or capital-market content: 摩尔线程 智源 when:2d returned 12 hits, mainly reposts about JD Cloud’s 100,000-card cluster and stock-price-type reports (continuing content already recorded in the 09-09 window), plus gambling-type SEO articles; 智源研究院 开源 when:2d returned 9 hits, consisting of routine BAAI Hub articles and gambling SEO (including embodied-intelligence community articles, AI dispute adjudication, etc.), with no direct connection to the FlagOS tech stack, and all were excluded per existing criteria.
  • HN Algolia hits were substring false matches: the titles for all five query groups — FlagOS/FlagGems/FlagTree/FlagScale/BAAI — were unrelated flags/flagship-type entries (such as “15x10 Pixel Flags”, Show HN series), with none pointing to this tech stack, and all were excluded.
  • No new releases on official content channels: the FlagOS official CSDN account had no new articles during the window, with the latest still being the 08-28 GLM-5.3-Flash Day0 adaptation to 9 chips; the 09-07 KubeCon co-located forum and operator tuning topic pages remain mounted, with no release-time updates. BAAI Hub and the official website also had no new FlagOS-related releases during the window.

Interpretation: The divergence between the news side and the code side reached a recent maximum in this window — the 61 commits include substantive progress such as version convergence, the opening of the Ascend 910C application layer, full-matrix sglang docs, and the merging of two new backends, while external coverage was zero. This shows that FlagOS’s current external visibility does not keep pace with engineering progress, and the community’s information releases remain concentrated on two types of nodes: “model Day0 adaptation” and “conference forums”; progress in this window must be read from the delivery and compiler mainlines, a judgment that has a direct impact on tracking cadence.

III. Deep Dive on Member Organizations

3.1 Tsingmicro: Compiler Line Moves from “Backend Can Compile” to “Pipeline Self-Sustaining” (09-10)

Sources: FlagTree #1118, flir #69

  • Three actions in this window point to the same thing: FlagTree adds two workflows for tsingmicro3.6 — build-and-test and delivery — and fixes the joint build with FLIR; FLIR syncs the Tsingmicro patch to support LLVM 22; the FlagTree README changelog records “2026/09/10 Tsingmicro backend upgraded to Triton 3.6 and added to CI/CD.”
  • Delivery surface: both the tsingmicro3.3 and tsingmicro3.6 lines are included in this window’s 0.7.0 unified switchover list.

Interpretation: Tsingmicro’s previous form in FlagTree was “a backend integration based on Triton 3.3”; after this window it becomes “a regular delivery line with its own build/delivery workflows, aligned with LLVM 22 and Triton 3.6.” The value for members’ assessment lies in this: compiler-level support for the new generation no longer depends on community contracting, indicating that Tsingmicro’s compiler team has independent maintenance capability; the fact that both product lines enter the delivery matrix simultaneously also shows that its generational switchover has been incorporated into FlagOS’s regular release cadence.

3.2 Hygon: Four Lines — Operators, Tensor Library, Domain Library Docs, Runtime Routing — Advance Simultaneously (09-10)

Sources: FlagTensor #1be84f2, FlagGems-vllm #736, Torch-FL #270, FlagDNN, build-infra #831

  • In this window Hygon shows four scattered but aligned actions: FlagTensor merges the DCU backend (+4225 lines); FlagGems-vllm adds a Hygon-specific fused_add_rms_norm (325 lines); FlagDNN adds Hygon backend documentation; Torch-FL restores fused SDPA for DCU routing and leaves behind benchmark documentation. On the delivery side, startup documentation for sglang0.5.18-hygon-dtk26.04 enters the full matrix.
  • Combined with the “Hygon Token Operations Dual-Chip Acceleration Solution” recorded in the 09-09 window, Hygon’s actions within the software stack have expanded from early operator specialization to tensor library backends, domain library documentation, and runtime performance routing.

Interpretation: Hygon is currently one of the member organizations with the broadest work surface within FlagOS — operator library, tensor library, domain library documentation, inference plugin (sglang application line), and Torch-FL runtime routing all have active work. Its commercial narrative (Token factory) advances in sync with its software stack coverage, meaning Hygon DCU’s positioning within FlagOS is shifting from “a chip being adapted” to “a deep co-building member.”

3.3 Kunlunxin: FlagTensor XPU Backend Merged, Four-Layer Work Surface in Parallel (09-10)

Sources: FlagTensor #1be84f2, FlagTree delivery line list

  • In this window FlagTensor merges the Kunlunxin XPU backend into the mainline alongside the Hygon DCU; on the delivery side, the xpu3.0 and xpu3.6 workflows are incorporated into the 0.7.0 unified switchover.
  • Connecting with earlier records: the 09-02 window had a Kunlunxin backend slice_scatter out-of-bounds fix in FlagGems, the 09-08 window had Kunlunxin P800 training CI and runtime support in FlagScale, and the 09-09 window recorded batch merging of Kunlunxin KernelGen operators in FlagGems-Experimental.

Interpretation: Kunlunxin currently has active work surfaces across all four layers — tensor library (FlagTensor), operator library (FlagGems), training framework (FlagScale), and compiler delivery (FlagTree xpu lines) — approaching the form of a deep adaptation vendor. Considering that Kunlunxin is not on the community’s publicly disclosed member organization list, its investment intensity is worth tracking continuously as a sample of external ecosystem expansion.

3.4 Sunrise and DAMO XuanTie: External Inference GPU and PPU Backend Both Step Up in the Same Window (09-10)

Sources: vllm-plugin-FL #391, #472, FlagTree #1144

  • Sunrise: vllm-plugin-FL ports its attention backend to vLLM 0.24.0 (targeting its TANGRT 1.2.0 toolchain), completing the leap from “runner environment only” to “component-level backend”; on the delivery side, sunrise3.4 is incorporated into the 0.7.0 switchover; the official chip vendor table already lists Sunrise.
  • DAMO XuanTie (T-Head): vllm-plugin-FL #472 restores its backend static graph support; on the delivery side, ppu3.6 is incorporated into the 0.7.0 switchover, and FlagTree #1144 simultaneously refreshes the PPU’s qwen3.6 benchmark performance baseline.

Interpretation: Both belong to “inference-side investment by non-member organizations.” Sunrise is a domestic vendor focused on inference GPUs (its product lines S1/S2/S3 target inference scenarios); its choice to land on the vLLM 0.24.0 plugin line that follows upstream indicates that the internet/cloud-side inference deployment path continues to grow more attractive to domestic chip vendors. DAMO XuanTie’s static graph fix and the incorporation of its PPU delivery line into 0.7.0 show that, as the most representative compute backend in the RISC-V context, it maintains a regular-position update cadence within FlagOS’s delivery matrix.

3.5 BAAI (Lead Organization): Two Governance Actions — Delivery Pipeline Version Unification and Packaging Policy (09-10)

Sources: FlagTree #1151, build-infra #812, release-info

  • The lead organization’s actions in this window focus on governance rather than features: unifying the version numbers of FlagTree’s 29 vendor delivery workflows (submitted by a community-side maintainer), and writing the packaging channel boundaries into a bilingual Chinese-English documentation policy.
  • The release manifest repository release-info has no content updates within the window (still only the initial README), indicating that the formal release manifest for 2.2 has not yet been finalized.

Interpretation: Taken together, the three pieces of information show that before 2.2 GA (scheduled for 09-28), the focus of preparation has shifted from “features and adaptation” to “delivery specifications and installation channels”: version numbers must align the delivery lines of over a dozen vendors, dependency sources must have a policy to rely on, and the release manifest must be able to clearly state all artifacts at once. This kind of work is invisible externally, but directly determines whether a reproducible delivery surface can be presented on GA day.

IV. Summary

In this window (09-10 10:18 ~ 09-11 10:18), GitHub saw 61 in-window commits across 13 repositories with pushes, keeping engineering activity at a high level; on the news side, component-level searches marked the ninth consecutive quiet window, with zero external coverage and all information coming from code repositories. Four main threads:

  1. FlagTree 0.7.0 enters delivery convergence (the most important change in this window): The mainline version number was bumped from 0.6.0 to 0.7.0, and the version input parameter for 29 vendor delivery workflows was switched to 0.7.0 in one pass, covering six NVIDIA triton lines (including TileIR and special forms), AMD, Ascend, Enflame, Iluvatar CoreX, MetaX, Moore Threads, Tsingmicro, Sunrise, Kunlunxin XPU, HCU, AIPU, Thrive, PPU, and more; the rc0/rc1 three-tier branches (triton 3.3/3.5/3.6) were already in place, and the official release tag has not yet been published. This means version convergence in the 2.2 RC period has reached its final step.
  2. Ascend 910C completes two-tier “base → app” rollout, with sglang elevated to a first-class application line: After the 910C runtime image build was pushed, the vllm application line opened on both CANN 8.5.0 and 9.0.0 910C tracks (covering four application entries for vLLM 0.20.2 and 0.24.0), with nine verify/template/dependency stabilization fixes added; at the same time, startup documentation and changelogs were generated for sglang0.5.18 across at least 10 chip lines, shifting the inference framework matrix from “full vllm, scattered sglang” to dual-line parity.
  3. External and non-member vendors continue to increase investment: Sunrise completed component-level backend rollout (advancing from runner environment to a vendor backend for vLLM 0.24.0), Kunlunxin XPU and Hygon DCU dual backends were merged into FlagTensor, and Tsingmicro added tsingmicro3.6 bidirectional CI/CD and aligned with LLVM 22 and Triton 3.6 — the standard path for new chip onboarding (environment first → plugin backend → delivery line integration) has been proven replicable.
  4. RC-period discipline repeatedly appears in engineering details: TLE NVIDIA’s layout optimization was merged and reverted the same day, FlagGems removed residual MetaX CI entries, installation subpackage integrity was fixed, and packaging channel policy was documented — actions during the freeze period are “fix correctness and definitions, do not add new features,” with same-day reverts and installation-surface fixes being the most direct evidence of this discipline.

Forecast: Four points to watch going forward — first, when the first app image tag for 910C enters registry records and appears in the “verified” column of the status matrix (this is the final marker of 910C delivery readiness); second, when FlagTree 0.7.0’s official release tag and build-infra’s flagtree pin follow up (the NVIDIA line is still pinned at 0.6.1, leaving a one-version mismatch); third, the rc1.postN increment cadence and community/release-info list actions before 2.2 GA (09-28); fourth, whether Sunrise’s onboarding path expands from vllm to the sglang line, and whether Kunlunxin will be included in the public member list.

Limitations note: All entries in this window come from GitHub commits, workflow files, and patch contents; the news side is the ninth consecutive quiet window, with no independently cross-verifiable third-party coverage, so judgments such as “version convergence” and “delivery readiness” are based on commit text and file changes, without relying on third-party paraphrases. All 13 Google News queries in Chinese and English returned zero hits, and HN hits were substring false matches, all recorded faithfully in the appendix.

Appendix: Complete Source List

Source Verification Result
GitHub org repos API (flagos-ai, 53 repos, sorted by pushed) 13 repos pushed within window: build-infra (09-11 10:06), FlagTree (09-11 10:05), FlagBLAS (09-11 10:14, no in-window commits on default branch, judged as branch activity), vllm-plugin-FL, FlagGems, FlagGems-vllm, FlagDNN, Torch-FL, flir, FlagFFT, FlagCX, FlagTensor, Megatron-LM-FL; no new repos (most recently created repo was 08-15)
GitHub commit search (org-wide, committer-date > 2026-09-10T02:18Z, single page of 60, full set) Verified committer time and repo attribution item by item: build-infra 24 / FlagGems 10 / FlagTree 8 / FlagTensor 5 / vllm-plugin-FL 3 / FlagDNN 3 / FlagGems-vllm 2 / Torch-FL 2 / flir 1 / FlagFFT 1 / FlagCX 1
GitHub per-repo commits recheck (Megatron-LM-FL, FlagBLAS, FlagGems-Experimental) Megatron-LM-FL #148 (09-10 10:47) falls within window, not captured due to search index lag, added retroactively; FlagBLAS default branch latest commit is 09-09 (outside window), in-window pushes came from branches; FlagGems-Experimental latest commit 09-10 09:11 (outside window)
GitHub branches API (FlagTree) 0.7.0-rc0-triton3.3/3.5/3.6 head times 08-11 / 08-27 / 08-31; 0.7.0-rc1-triton3.3/3.5/3.6 are 09-01 / 09-04 / 09-04 (rc1-triton3.6 head is Qingwei backend integration #1071)
GitHub commit details and patches #1151 totals 29 delivery workflow files, default version ‘0.6.0’ → ‘0.7.0’ (committer zhengyang@baai.ac.cn); #816 (273 lines, 4 910C vllm changelogs + status matrix); #831 (2896 lines, sglang0.5.18 launch documentation matrix); #1118 (354 lines, Qingwei build-and-test + delivery); FlagTensor backend merge (4225 lines / 4393 lines); vllm-plugin-FL #391 (sunrise, target is TANGRT 1.2.0); FlagGems-vllm #736 (Hygon op 325 lines); Torch-FL #270 (658 lines, includes DCU routing benchmark docs); FlagCX #576 (MUSA PAL)
GitHub tags / releases API No new releases in this window. Latest anchors: FlagGems v5.4.0-rc1.post1, FlagTree 0.6.0+triton3.x (Releases) / delivery line switched to 0.7.0, FlagCX v0.14.0-rc1.post1, FlagGems-vllm v0.2.0-rc1.post1, vllm-plugin-FL v0.3.0-rc1.post1, FlagBLAS v0.3.0-rc1.post1, FlagTensor v0.3.0-rc1.post1, FlagDNN v0.3.0-rc1.post1, FlagFFT v0.2.0-rc1.post1, Torch-FL v0.2.0-rc1.post1, FlagOS-Robo v0.1.0
raw.githubusercontent (README and configs.yaml for FlagTree / vllm-plugin-FL / build-infra / flir) FlagTree vendor table includes NVIDIA (incl. TileIR), AMD, Enflame, Iluvatar, Hygon, Moore Threads, DAMO, Huixi Intelligence, MetaX, Xiwang, Kunlunxin, DAMO XuanTie (T-Head), SpacemiT, Tsingmicro; vllm-plugin-FL vendor table includes Sunrise (Supported); build-infra configs.yaml NVIDIA line still pins flagtree==0.6.1, includes sunrise / tsingmicro / kunlun / hygon / mthreads / iluvatar / cambricon / metax / enflame keys; flir is the FlagTree IR intermediate layer (forked from triton-shared)
Google News RSS (13 query groups in Chinese and English, via proxy) Component-level queries all returned zero hits (ninth consecutive quiet window); member-unit term hits were reposts of JD Cloud’s 100,000-GPU cluster, stock price/lockup-release items, and gambling SEO articles, excluded from technical entries per established criteria
HN Algolia (FlagOS / FlagGems / FlagTree / FlagScale / BAAI) All were irrelevant items from substring false matches on flags/flagship/flocked, removed entirely
FlagOS official CSDN account (flagos.csdn.net) No new articles in window, latest remains 08-28’s GLM-5.3-Flash Day0 adaptation for 9 chips; 09-07 KubeCon co-located forum page and operator tuning topic page had no publish-time updates
BAAI Community (hub.baai.ac.cn) In-window hits were routine community content (embodied intelligence, AI governance, etc.), not directly related to the FlagOS tech stack
Tavily / web search Xiwang Xinke background verification (official site, QbitAI, TMTPost — three sources); FlagOS version cadence historical anchor verification (Zhongzhi FlagOS 1.6 / 1.5 official press releases)