FlagOS Daily Intelligence Report (2026-10-19)
Research window: 2026-10-16 06:00 ~ 2026-10-19 06:00 (Beijing time, approx. 72 hours; Monday morning report, window covers the weekend, counted from the cutoff of the previous daily report (10-16), including the full run of the “2026 AI Open Computing Conference & Zhongzhi FlagOS Technology Conference” on 10-17 to 10-18).
Sources: GitHub (full audit of 61 repos under org: flagos-ai, paginated verification of 147 commit searches, retrieval of 139 merged PRs and 239 open PRs, atomic verification of releases across 31 repos and tags across 8 repos, 100 org event-stream entries plus branch-level fallback), Google News RSS (24 groups of Chinese and English query terms, via proxy), HN Algolia (8 groups), the CSDN FlagOS column and BAAI Community, the conference official agenda page, and DOIT on-site coverage (see the appendix source list for details).
This Issue’s Index
- Today’s Focus: Full two-day coverage of the 2026 Open Computing Conference — the 2.2 main forum figures (21 vendors, 35 chips / 1454 operators / +27.6% cross-chip / 264 contributors) and the Quantum-AI Cloud launch; on the GitHub side, 16 repos with 147 commits and 139 merges, the new FlagCV skeleton landed, FlagQuantum 0.3.1 and FlagCX 0.15.0.dev0 released, and build-infra’s six-backend 22.04 builder finalized (10-16 ~ 10-19)
- I. Open Source Project Progress (GitHub Activity)
- 1.1 Organizational cadence: 16 repos pushed, 147 commits, 139 merges, 239 under review; FlagCV enters the commit surface for the first time (10-16 ~ 10-19)
- 1.2 New repo FlagCV: multi-backend image operator library skeleton aligned with the OpenCV interface merged (10-18 ~ 10-19)
- 1.3 build-infra: FlagCX six-backend 22.04 self-contained builder finalized; FlagTree per-backend builder and daily wheel matrix take shape (10-16 ~ 10-18)
- 1.4 FlagGems: thirty-plus NVIDIA operators from KernelGen batch-landed; wave of twenty-plus Kunlunxin optimizations; 216 test cases migrated to Protocol v6 (10-16 ~ 10-17)
- 1.5 FlagTree: SpaceMiT RISC-V backend adds smt_rvisa bare-metal eDSL, retiring the private TLE dialect (10-16)
- 1.6 Communication and Quantum: FlagCX v0.15.0.dev0 plus two Hygon UIL commits; FlagQuantum 0.3.0 / 0.3.1 dual releases (10-16 ~ 10-18)
- 1.7 Inference and training stack: GLM-5.3 / Qwen4 operators enter FlagGems-vllm; vllm-plugin-FL Ascend full decode graph; Torch-FL MPS and FlagCICD (10-16 ~ 10-19)
- 1.8 Operator libraries and review surface: FlagBLAS DAMO XuanTie PPU GEMM; FlagTensor 16-operator suite; 27 challenge submissions under review (10-16 ~ 10-18)
- II. News Coverage and Ecosystem
- 2.1 Main forum: the six sets of numbers and four-layer architecture of FlagOS 2.2 (10-18)
- 2.2 Quantum-AI Cloud launch: FlagOS Execution Stack underpins FlagQuantum (10-18)
- 2.3 Other conference segments and channel verification: sub-forum livestream pages online, per-session minutes not yet published (10-17 ~ 10-19)
- III. Member Company Deep Dive
- 3.1 Moore Threads: S5000 conference figures, MThreads operators and the MUSA line (10-16 ~ 10-19)
- 3.2 MetaX: MiniMax M3 and Kimi K3 optimization tiers on C550 under review, metax wheels enter the daily line (10-18 ~ 10-19)
- 3.3 Iluvatar / Enflame / Cambricon / Hygon / Tsingmicro / Xiwang / DAMO XuanTie: six-backend 22.04 and operator lines (10-16 ~ 10-18)
- IV. Summary and Trend Observations
Today’s Focus: The two-day conference concludes in full, with 2.2’s “scale metrics” and the engineering side’s “reproducible delivery surface” both delivered in sync (10-16 ~ 10-19)
Date: 2026-10-16 ~ 2026-10-19 Sources: DOIT main forum report · Conference agenda page · FlagCV · build-infra (see appendix for the full list)
- The conference (10-17 ~ 10-18) is the absolute main thread of this issue: In the 09:10 slot of the main forum, Lin Yonghua, Vice President and Chief Engineer of BAAI, gave a talk titled “FlagOS 2.2: From the Token Economy to Physical AI,” disclosing 2.2’s scale metrics in a concentrated manner for the first time—21 chip vendors and 35 chips, 9 major operator libraries with 1454 operators (+890 vs. the previous version), cross-chip operator performance +27.6% (covering 10 chips), and 264 code contributors (+55% quarter-over-quarter); it also released the FlagPrism cross-chip debugging tool and the FlagOS-Compressor unified quantization tool (see 2.1 for details).
- Quantum-AI Cloud released on 10-18: Jointly launched by BAAI and the Beijing Academy of Quantum Information Sciences, supported by the FlagOS Execution Stack for FlagQuantum, and connected to the “Jiuding” AI computing system and the “QUAFU” quantum computer to enable hybrid quantum-classical job scheduling—the GitHub-side release notes for FlagQuantum v0.3.0 (resumable Jiuding / Quafu tasks, ordered results for multiple Quafu circuits) corroborate the public messaging (see 2.2 / 1.6 for details).
- The engineering side advanced on three fronts in parallel during the same period: build-infra had 45 commits and 41 merges, unifying the nvidia / hygon / cambricon / metax / enflame / iluvatar six-backend builders of FlagCX into a self-contained 22.04 form, and changing the FlagTree builder and daily wheels to a matrix of “one backend per line in backends.yaml” (see 1.3 for details); FlagGems had 48 commits and 52 merges (a wave of KernelGen batch operator landings and Kunlunxin optimizations, see 1.4 for details); Torch-FL had 20 commits and 21 merges (native MPS operators and FlagCICD reporting, see 1.7 for details).
- The organization added a new “operator-domain expansion” signal: FlagCV, with its repo created on 10-14, landed its first commit late at night on 10-18 and merged PR #1 “Init project skeleton” at 01:38 on 10-19—its interface aligns with OpenCV, its multi-backend structure follows FlagDNN, and its kernels are written in Triton; it lands the skeleton first without operators (see 1.2 for details).
- Version side: FlagQuantum 0.3.0 (10-16 13:34) and 0.3.1 (10-16 19:20) were both released on the same day; FlagCX tagged v0.15.0.dev0 (10-18 10:36). No other components on the 2.2 list had official version changes within the window.
I. Open-Source Project Progress (GitHub Activity)
1.1 Organizational Cadence: 16 Repos Pushed, 147 Commits, 139 Merges, 239 Under Review; FlagCV Enters the Commit Surface for the First Time (10-16 ~ 10-19)
Date: 2026-10-16 ~ 2026-10-19 Source: org repository list · FlagGems · build-infra (full list in appendix)
- Repository surface: 16 of 61 repos had pushes within the window—docs, FlagTree, FlagCV, Torch-FL, Trident, build-infra, FlagFFT, FlagCX, FlagQuantum, FlagGems, FlagGems-Experimental, FlagDNN, FlagGems-vllm, vllm-plugin-FL, FlagBLAS, FlagTensor. Among these, pushes to FlagDNN / FlagFFT / Trident / docs landed on non-default branches (latest commits on default branches were 10-15 17:16 / 10-15 15:58 / 10-13 22:19 / 10-03 11:12 respectively), with no new additions to the mainline.
- Commits and merges: Commit search returned 147 hits across 12 repos—FlagGems 48, build-infra 45, Torch-FL 20, FlagQuantum 11, FlagGems-vllm 6, FlagTree / FlagGems-Experimental / FlagCX / FlagCV / FlagTensor 3 each, FlagBLAS / vllm-plugin-FL 1 each; 139 merged PRs across 11 repos (FlagGems 52, build-infra 41, Torch-FL 21, FlagGems-vllm 6, FlagTree 4, FlagQuantum 4, FlagCX 3, FlagGems-Experimental 3, vllm-plugin-FL 3, FlagCV 1, FlagBLAS 1).
- Review surface: 239 open PRs updated within the window across 23 repos, led by FlagGems 104, FlagGems-sglang 31, vllm-plugin-FL 27, Torch-FL 14, FlagTree 12, FlagGems-vllm 11; 27 of these carry the “FlagOS Competition-Track1” label, all targeting FlagGems-sglang (see 1.8).
- Assessment: The merge density over the three-day window (~46 per day) is higher than the normal level of 10-15 single-day (107 in 24 hours), but the structure is unchanged—FlagGems and build-infra together account for 63% of commits and 67% of merges, still driven by the dual engine of “operator library + build infrastructure”; the training side (Megatron-LM-FL / TransformerEngine-FL / FlagScale) saw zero pushes in the window, in a quiet period around the conference.
1.2 New Repo FlagCV: Multi-Backend Image Operator Library Skeleton Aligned with OpenCV Interfaces Merged (10-18 ~ 10-19)
Date: 2026-10-18 ~ 2026-10-19 Source: FlagCV · PR #1 · commit history
- Facts: FlagCV, created on 10-14, landed its first commit “Add project skeleton and bitwise_and operator” at 10-18 23:14, followed by “Restructure as an immediate-mode skeleton without operators” at 10-19 01:24, and merged PR #1 (author zhangjieBaai) at 10-19 01:38. The PR description states three design orientations: interfaces aligned with OpenCV (five headers under
include/flagcv/—core / imgproc / gpumat / handle / types—corresponding to opencv2’s core and imgproc), multi-backend structure following FlagDNN, and kernels written in Triton; this PR only lands the skeleton, with no operators. - Structure: Of the repo’s 81 paths,
backends/already lays out six backends at once—nvidia / thead / ascend / hygon / iluvatar / mthreads (each with CMakeLists, backend.cpp, compiler.py, and kernels/registry.json);src/is split into five blocks: core, imgproc, image, lowering, runtime;compiler/flagcv_codegenis the code generation entry point;docs/already has three documents: architecture, numerical-tolerance, operator-development. - Assessment: This is the first time the FlagOS operator map extends from “large models / scientific computing” to image processing—previously gaps of the FlagCV kind were shared between FlagDNN (deep learning operators) and vendors’ own CV libraries; now it stands as a separate repo with an OpenCV-compatible interface. The six backend directories being laid out at once rather than added one by one indicates the team intends to directly reuse the existing FlagDNN multi-backend paradigm; the
numerical-tolerancedocument appearing before the operators also matches FlagOS’s established rhythm on the KernelGen line of “establish acceptance criteria first, then land operators in batches.” The risk is that the match between image processing operators (interpolation, color space, morphology) and Triton’s expressiveness has not yet been validated, and the repo has no runnable operators yet, so no conclusions should be drawn about its coverage in the short term.
1.3 build-infra: FlagCX Six-Backend 22.04 Self-Contained Builders Finalized; FlagTree Per-Backend Builders and Daily Wheel Matrix Take Shape (10-16 ~ 10-18)
Date: 2026-10-16 ~ 2026-10-18 Source: build-infra #1369 · #1371 · #1372 · #1380 · #1389 · #1394 · #1398 · #1399 · #1403 · #1404 · #1407
- FlagCX line: Within 24 hours, one “22.04 self-contained builder” was landed for each of six backends—nvidia (#1372), hygon (#1380), cambricon 4.7.2 (#1389, with a companion pandas dependency fix #1391), metax (#1394), enflame (#1398), iluvatar (#1403); each builder uses ubuntu:22.04 as the glibc floor, pre-installs the vendor SDK into the image, builds the wheel on top of it, and leaves a trace in wheel-info (#1375 / #1395 / #1400). #1407 adds a dispatch-level
--no-bitcodeswitch: thev0.14.0tag predates FlagCX #668’sbindings/irMakefile, so re-releasing iluvatar’s0.14.0+corex4.4.0/corex4.5.0pins no longer produces device bitcode, avoiding setup.py throwing directly on non-nvidia adaptors. - FlagTree line: Builders are merged from “two workflows doing one thing” into a single matrix, with one line in
backends.yamlcarrying the Containerfile, image repo, runner label, disk budget, and acceptance assertions (#1369); daily wheels likewise become one line per backend, withplancomputing version and filename line by line (#1371), metax joins the daily line (#1377), iluvatar joins the target and daily lines (#1390 / #1393), sunrise consolidates builder and wheel into a single file and enables the daily line (#1399 / #1402), and the ascend backend pair becomes a two-stage builder (#1404 / #1405, where the build environment is the delivery environment, reading CANN and pinning AscendNPU-IR accordingly). #1397 explicitly removes FlagCX from iluvatar’s FlagTree wheel, drawing the boundary between the two artifacts. - Packaging line: Wheel upload moves from the runner’s local python to execution inside the uploader image (#1381 / #1382 / #1388); release-type workflows accept
pull/<N>as a ref (#1347), allowing PR branches to run the release chain first; FlagGems-sglang enters both the noarch deb/rpm and flaglibs wheel lines (#1387); bundle deep smoke tests switch to real-device device + compiler JIT/execution (#1365), and validation runs on the bundle’s glibc floor (22.04) (#1376). - Assessment: This batch is not scattered patching but a compression of “N backends × M artifact types” into “one matrix + one backends.yaml”—adding a backend goes from “writing another workflow” to “adding a line.” Unifying on 22.04 is the other side of the same logic: only by pinning the glibc floor of both build and delivery environments can cross-distro wheels be “one artifact installable in many places.” This directly corresponds to the “35 chips” mentioned in the main forum—the chip count must be supported by a reproducible delivery surface, otherwise scale is just a list.
1.4 FlagGems: Thirty-Plus NVIDIA Operators from KernelGen Landed in Batch; Kunlunxin Optimization Wave of Twenty-Plus; 216 Test Cases Migrated to Protocol v6 (10-16 ~ 10-17)
Date: 2026-10-16 ~ 2026-10-17 Source: FlagGems #6989 · #7215 · #7213 · #6985 · #7124 (full list in appendix)
- KernelGen (NVIDIA) batch operator landing: Around 10-16 14:06 ~ 14:50 and 16:11, thirty-plus “[KernelGen][Nvidia] Add operator with Triton kernel” PRs were merged in a burst, covering convolution and transposed-convolution kernels, FFT, small linear-algebra decompositions (Cholesky, eigenvalues, inverse, tensor-solve), RNN / LSTM / GRU cells, and sparse or aliasing copy operators (
coalesce,col_indices_copy,values_copy,diagflat,gradient,dense_dim,_dim_arange,_dimV); FlagGems-Experimental landed 3 more (dstackand a per-channel quantized-tensor factory). - Test criteria migration: #7215 migrates 216 operator test cases to the Protocol v6 three-part layout (
tests/test_<op>.py+benchmark/test_<op>.py+definitions/<op>.json), noting that of the 220 exact IDs in the source list, 216 were migrated, 3 were excluded after review (umbrella rows such astensor_split), and 1 was deferred (clonehas no existing implementation); it also adds version-gated Philox registration forphilox_normal_. - Kunlunxin optimization wave: Twenty-plus PRs concentrated on the XPU backend—
amax / mv / i0 / cauchy,euclidean_dist / normed_cumsum,batch_norm_backward / layer_norm_backward,masked_scatter / nonzero / addr / logit,foreach_copy / foreach_pow_list / foreach_tan,float_power_ / gather_backward / scatter_add_ / to_copy,tril_ / arange,le_scalar_ / one_hot / mhc_pre,index_select_backward; among these, #7213 rewritescumsum’s row scan as a prefix-sum matrix multiply, and #7144 / #7218 add int16 dtype support and precision fixes. - Other lines: MThreads adds the
moe_load_balance_lossoperator (#6985, with MUSA specializations: accumulatorsem="relaxed",tl.histogramper-program histogram replacing scalar atomics, single scratch allocation, plus a C++ wrapper and gtest); Ascend fixes the grid limits and tiled launch offsets ofadaptive_max_pool3d(#7124); Hygon’s open #7242 caps split-KV’sBLOCK_Mat 16 to stay within 64KB LDS. - Assessment: KernelGen output has entered the cleanup phase of “filling in against the ATen list”—most of this round’s additions are corner operators like
_dim_arange,values_copy,_has_same_storage_numel, indicating that mainline operator coverage is nearing completion and work has begun on boundary semantics such as aliasing/views/sparsity. The density of the twenty-plus Kunlunxin PRs deserves separate note: this is the most concentrated optimization investment by a single domestic backend within the three-day window.
1.5 FlagTree: SpaceMiT RISC-V Backend Adds smt_rvisa Raw-Kernel eDSL, Retires Private TLE Dialect (10-16)
Date: 2026-10-16 Source: FlagTree #1381 · #1394
- Facts: #1381 (author alex-spacemit) updates the SpaceMiT RISC-V (K3) backend, doing three things at once—adding
smt_rvisa, a raw-kernel eDSL where the author explicitly specifies SEW / VL / tiling / instruction selection rather than leaving it to the scheduler; kernels are lowered via a C++ builder API (no MLIR text generated), with an additional LLVM direct-output path that uses MLIR Python bindings to producellvm.funcdirectly and skipsspine-optentirely; the backend no longer keeps a private TLE dialect copy and instead consumes the commonthird_party/tle; it also fixes pointer / memory space lowering defects exposed by the raw path. - Companion changes: #1394 updates the Ascend CI py311 / py312 and ascend3.5 workflows; open #1395 ([SPEC][XPU] reuse core analysis and route TritonTypes.td) and #1396 (Ascend3.5 py312 delivery workflow) show that specification work continues on both the XPU and Ascend lines; #1387 skips the
tle.gpu.allocalias test on enflame. - Assessment: The RISC-V backend in FlagTree used to be “compiles and runs”; this issue marks the first appearance of a hand-written entry point targeting the vector unit—explicit control over SEW / VL means RVV vector length and tiling strategy can be written into the kernel rather than relying on automatic scheduling inference. Retiring the private TLE copy is a governance action: multiple backends sharing one TLE dialect prevents “one semantics per backend.” For RISC-V AI chips (the SpacemiT K3 line), this is a step from “can run models” toward “can squeeze performance.”
1.6 Communication and Quantum: FlagCX v0.15.0.dev0 and Two Hygon UIL PRs; FlagQuantum 0.3.0 / 0.3.1 Dual Releases (10-16 ~ 10-18)
Date: 2026-10-16 ~ 2026-10-18 Source: FlagCX v0.15.0.dev0 · FlagCX #643 · #668 · #663 · FlagQuantum v0.3.0 · v0.3.1
- FlagCX: Tagged v0.15.0.dev0 (development-line tag) at 10-18 10:36; three code-side merges—#643 enables the Hygon Device API and HIP backend for the unified IR, adding Hygon’s device channel on the UIL (unified interface layer); #668 makes device bitcode generated per adaptor rather than hardcoded to nvidia, a key change moving the heterogeneous communication library from “one vendor’s exclusive” to “multiple vendors’ homogeneous”; #663 converges CI to four cards and unifies platform configuration.
- FlagQuantum 0.3.0 (10-16 13:34): The 0.3 line moves to stable packages, providing stable-ABI wheels for Python 3.10–3.12 (Linux x86_64 / macOS arm64 / Windows amd64); Jiuding and Quafu tasks are resumable (opt-in receipts), with Quafu multi-circuit results order-preserving; the package ships with English and Chinese versions of the six FlagOS 2026 workshop lectures.
- FlagQuantum 0.3.1 (10-16 19:20): Adds the local research capability service merged after the 0.3.0 build—
flagquantum.servicesdiscovery and description of restricted capabilities, validation and estimation of typed requests, local CPU execution and structured evidence validation, including a two-qubit Pauli-sum ground-state VQE path and a versioned evidence package; the release notes also draw clear boundaries: it does not construct molecular Hamiltonians from chemical specifications, does not run on quantum hardware, and does not include an MCP server or agent runtime (the MCP adapter is a separate package). - Assessment: Both lines complete the “capability—product” alignment within the same window—FlagCX’s UIL-ization (Hygon channel + per-adaptor bitcode) is the finalizing move for multi-vendorization of the communication layer; FlagQuantum’s release notes state “what it can do / what it does not do” more clearly than most projects, and the Jiuding / Quafu task resumption capability in 0.3.0 is precisely the technical draft for the next day’s Liangzhi Cloud external release (see 2.2).
1.7 Inference and Training Stack: GLM-5.3 / Qwen4 Operators Enter FlagGems-vllm; vllm-plugin-FL Ascend Full-Decode Graph; Torch-FL MPS and FlagCICD (10-16 ~ 10-19)
Date: 2026-10-16 ~ 2026-10-19 Source: FlagGems-vllm #900 · #896 · vllm-plugin-FL #409 · #607 · Torch-FL #560 · #565 · #542
- FlagGems-vllm (6 merges): #900 adds GLM-5.3 Flash public operators for framework-side PR 454; #896 delivers three classes of Qwen4 operators—HC / PLE / sparse QSA—for plugin integration; #924 fixes thead’s W8A8 MoE integer accumulation and reuses GEMM2; #934 fixes MUSA’s vLLM baseline startup; #937 compresses the FP8 varlen precision matrix to 359 cases.
- vllm-plugin-FL: #409 enables generic full-decode graph mode for Ascend; #598 disables the failing NVLS initialization on H20; #593 adds eager reference implementations for operator profiles. Two open PRs target MetaX C550: #540 is a two-node TP16 MiniMax M3 BF16 optimization profile (opened 09-18, still updating on 10-18), and #607 is a four-node TP8 / PP4 Kimi K3 MXFP4/BF16 implementation (newly opened 10-19 01:58, running on the vLLM 0.28-compatible 0.4.0-dev branch).
- Torch-FL (20 commits / 21 merges): Three MPS PRs—native
mm/bmminto the MPSGraph gemm class (#560), nativesoftmaxand elementwiseneg/pow(#565), compiled MPSGraph plan caching and scheduling (#545); five Ascend PRs (PrivateUse1bitwise_*_.Scalar, SDPA fallback with dropout,cumsumvia aclnn,flipvia aclnn, bridging FlagTree 0.7.0’s autotuning parameter rename); three GCU PRs (nativersub, conv and layer_norm gated by operand device, Qwen-Image rotation table memoization); one Tsingmicro PR (metadata-only view operators routed to vendor slots); on the CI side, a new Kunlunxin P800 2.9 stable-branch line (#273), platform pytest report upload to FlagCICD (#542 / #577), MUSA runtime coverage merged into the shared integration list (#574), and the CUDA line switched to FlagGems-led default wheels (#530). - Assessment: Inference-side actions have shifted from “adapting to a chip” to “adapting to a model’s new structure”—GLM-5.3 Flash and Qwen4’s HC / PLE / QSA are all new architecture terms that appeared only in October, with operators landing before the models are public. On the training side, Torch-FL’s focus is on MPS (Apple platforms) and FlagCICD reporting: the former shows that FlagOS’s “multi-chip” now includes edge devices / workstations, and the latter is a governance action to centralize multi-platform pytest results.
1.8 Operator Libraries and Review Surface: FlagBLAS DAMO XuanTie PPU GEMM; FlagTensor 16-Operator Suite; 27 Competition PRs Under Review (10-16 ~ 10-18)
Date: 2026-10-16 ~ 2026-10-19 Source: FlagBLAS #148 · FlagTensor · FlagGems-sglang PR list
- FlagBLAS: #148 completes GEMM for the DAMO XuanTie Zhenwu PPU’s thead backend—four Triton kernels
sgemm / hgemm / bfgemm / dgemm, each with NN / TN / NT / TT layout variants;cgemm / zgemmare placeholders only and redirect toflag_blas.ops.level3(Zhenwu has no native complex GEMM). The PR also fixes the thead precision and performance suites that previously could not run (e.g., the compute type parameter ofcublasGemmEx) and scopes the change to the thead vendor only. - FlagTensor: Three commits unify non-NVIDIA vendors onto a fixed 16-operator test suite and update the platform guides accordingly (10-16 11:01 ~ 11:26)—i.e., changing “each backend tests its own” to “the same 16 operators, the same criteria.”
- Review surface: Of the 239 open PRs, 27 carry the “FlagOS Competition-Track1” label, all targeting FlagGems-sglang (which has 31 open PRs), adding Triton kernels for SGLang—wide-row softmax, MLA absorbed Q concatenation, DCP LSE merging, QKV-ZBA split-reorder, speculative sampling bonus token collection, etc. (kernel names in the appendix PR list); submitters are mostly competition team accounts.
- Review highlights (others): FlagGems #7246 Moore Threads
mmoptimization (+3501/-72); #7239 Ascendmmshape dispatch and Triton tiling; #7243 Ascendindex_putfalling back to native ATen to avoid an MLIR pass crash; #7203 fixes a GRU barrier deadlock in the DAMO XuanTie backend; FlagTree #1395 XPU spec reuse, #1396 Ascend py312 delivery flow. - Assessment: The three operator libraries are each doing the same thing at different layers—FlagBLAS fills in basic linear algebra for hardware backends, FlagTensor unifies acceptance criteria, and FlagGems absorbs the inflow of operators from the competition and KernelGen. The competition’s open-PR volume (27) shows community supply persists, but it is concentrated on the single sglang line, with narrower coverage than September’s first batch of 16.
II. News Coverage and Ecosystem
2.1 Main Forum: Six Sets of Numbers and a Four-Layer Architecture for FlagOS 2.2 (10-18)
Date: 2026-10-18 Source: DOIT, “Lin Yonghua: Zhongzhi FlagOS 2.2 Released, the Token Economy Is Moving Toward Physical AI” · Conference agenda page
- Scale figures: Covers 21 AI chip vendors and 35 chips; 9 major operator libraries totaling 1,454 operators (up 890 from the previous version); 27.6% cross-chip operator performance improvement (across 10 chips); 264 code contributors (+55% period-over-period). Community metrics also include: 730+ active contributors, 100+ member organizations, coverage of 30+ countries, and 55,800+ developers; from 2.1 to 2.2, merged PRs rose from 1,890 to 4,890, new issues from 420 to 1,423, and commits from 5,100 to 9,730. The report states that 2.2 was released on September 30; on the GitHub side, the 24 items on the 2.2 list were actually committed between 09-28 and 09-29 (see the 09-29 / 09-30 daily briefs). There is a two-day discrepancy between the public statement and the repository commit dates; the repository is authoritative.
- Compilation and tuning: FlagTree covers 20 vendor backends in a single repository, adding NVIDIA TileIR, AMD, DAMO XuanTie, SpacemiT, Huixi, and ARM64 CPU backends, with the main branch upgraded to Triton 3.6; FlagOSTune speeds up the search for operators such as matrix multiplication by up to 298x. End-to-end measurements: on NVIDIA, DSV4-flash throughput +12.63% and first-token latency −20.22%; on Moore Threads S5000, Qwen3.6-35B-A3B reaches 82.29%–89.83% of H100-equivalent throughput, exceeding the vendor’s native implementation by 4%–19%. Within the overall +27.6% cross-chip gain, Kunlunxin P800 speedup rose 191.2% and Ascend 910B rose 160.7%.
- Toolchain: Newly released FlagPrism (cross-chip debugging and performance analysis, able to localize numerical deviations to the statement level; already supports Ascend, Tianshu Zhixin, Moore Threads, NVIDIA, and Enflame); a unified plugin system changes the “N×M” combination into an “N+M” decoupling, covering inference (vLLM / SGLang), training (Megatron-LM / TransformerEngine), reinforcement learning (VeRL), and base frameworks (Torch-FL); FlagOS-Compressor provides unified cross-chip quantization for the first time — after W8A8 on a 397B MoE, size is reduced by 49.1% while GPQA-Diamond remains at 84.85%, validated on H20 and domestic PPUs; Day0 capability achieves adaptation of a new model to up to 12 chips within one day, with simultaneous distribution to HuggingFace, ModelScope, Tencent Cloud, Huanxin Community, and the National Supercomputing Internet.
- Token and model cases: DeepSeek V4.1 Flash inference performance on H100 improves 18%–20%, with total throughput of about 9,190 tok/s at 64-way concurrency; DAMO XuanTie 810E improves 77%–82% and achieves usable 16-way concurrency; FP4 index scoring speeds up 2.75x on average, and FP8 Dense GEMM 1.41x. GLM-5.3-Flash on Ascend 910B improves throughput 2.04x, reduces cold TTFT for long context by 8.1% and ITL at full load by 16.6%, reaching 99.7% of the official API’s performance with 19.4%–27.6% better cost-effectiveness.
- Embodied AI, edge, and internationalization: On the embodied side, VLM speeds up about 2.3x (MFU 33%), Tx2V about 1.9x (MFU 36%), Action about 2.0x (MFU 35%), and training MFU 33%–36%, versus 23% for Cosmos3-Nano and 30% for Cosmos3-Super; on the edge, MiniCPM5-2B runs on an Arm CPU using only the CPU, with prefill at 1,135 tokens/s and generation at 90 tokens/s; after coordination between FlagTree-CPU and SME2 / NEON I8MM, full-model Prefill improves a further 21%–25%, and on Mac M5 Pro, Xing4.0 29B-A4B improves 252.09% over native vLLM; internationally, the UN “Open Computing Working Group” was approved on 9-28, with 300+ global institutions registering within two weeks, and the first meeting planned to be held during the November APEC summit.
- Assessment: The value of these figures lies not in any single number but in breaking “scale” into four verifiable layers — chip count (35), operator count (1,454), performance gain (+27.6%, with a breakdown across 10 chips), and contributor count (264). Compared with the “how many chips are supported” framing of the 2.1 era, the 2.2 narrative has shifted to “whether shared optimizations on the same set of chips can accumulate”; the two new tools, FlagPrism and FlagOS-Compressor, are precisely the tooling expression of that statement.
2.2 Quantum-AI Cloud Launched: FlagOS Execution Stack Underpins FlagQuantum (10-18)
Date: 2026-10-18 Source: DOIT main forum report (Quantum-AI Cloud section) · Official agenda (Quantum-AI Cloud platform launch, 10:05–10:15) · FlagQuantum v0.3.0
- Facts: On the morning of 10-18, the Quantum-AI Integration sub-forum included a “Quantum-AI Cloud platform launch” session (agenda 10:05–10:15). According to the main forum report, Quantum-AI Cloud was jointly launched by the Beijing Academy of Artificial Intelligence (BAAI) and the Beijing Academy of Quantum Information Sciences (BAQIS), using the FlagOS Execution Stack to support the FlagQuantum quantum framework, interfacing with the “Jiuding” AI computing system and the “QUAFU” quantum computer to enable hybrid quantum-classical job scheduling.
- Code-side corroboration: The FlagQuantum v0.3.0 release notes (10-16) already state that “Jiuding and Quafu tasks are resumable (opt-in receipts)” and “Quafu multi-circuit results preserve order,” while v0.3.1 adds local research capability services and versioned evidence bundles — indicating that at the time of the Quantum-AI Cloud launch, the quantum-side task submission, receipt, and result-ordering pipeline already existed in the package, rather than only framework-level interfaces.
- Assessment: This is the first cloud-service-form product of FlagOS extending from “AI training and inference” to “quantum-classical hybrid.” A boundary worth noting: the v0.3.0 / 0.3.1 notes explicitly state that it does not run on quantum hardware and does not include an MCP server or agent runtime; hardware execution is handled on the Jiuding and QUAFU side — the division of labor is “FlagOS handles scheduling and the execution stack, the quantum institute handles hardware and cloud.” Follow-up points to watch are when Quantum-AI Cloud will open externally, and whether FlagQuantum’s multi-chip backends (Hygon / Moore Threads) will be incorporated into cloud scheduling.
2.3 Other Conference Sessions and Channel Verification: Sub-forum Livestream Pages Online, Session-by-Session Notes Not Yet Public (10-17 ~ 10-19)
Date: 2026-10-17 ~ 2026-10-19 Source: CSDN FlagOS Column · AI Systems sub-forum livestream page · Quantum-AI Integration sub-forum livestream page · AI Agent sub-forum livestream page
- Session structure: The conference consists of 1 main forum + 6 sub-forums + 1 full-day workshop. The sub-forums cover Open Computing AI Systems, In-Vehicle Intelligence, Quantum-AI Integration, Embodied Intelligence, AI Agents, and International AI Computing Cooperation; the 10-18 full-day workshop has five sessions (KernelGen operator generation, edge inference, Triton-TLE attention operators, quantum programming for quantum-AI integration, and FlagScale-Agent architecture). Agenda details were already covered in the 10-12 / 10-13 daily briefs and are not repeated here.
- Verifiable additions: The CSDN FlagOS Column launched livestream pages for the AI Systems, Quantum-AI Integration, and AI Agent sub-forums on 10-17 / 10-18 (marked “replaying”); as of the window cutoff, no session-by-session notes or talk transcripts were found, and main forum content still relies primarily on a single on-site DOIT report. No FlagOS-related entries were detected on the BAAI community (hub.baai.ac.cn) during the window.
- News search conclusions: 24 groups of Chinese and English queries via Google News RSS returned 34 hits; direct component-name searches (FlagOS / FlagGems / FlagScale / FlagTree / FlagPerf / FlagCX / KernelGen) still returned zero hits within the window, with the only substantive hit being the 10-18 main forum report (see 2.1); 8 HN Algolia queries returned no direct hits. The remaining hits were member-organization corporate releases and market pieces — Moore Threads Step 5 Preview Day-0 (10-15, covered in the previous issue), MetaX Xisuo X302 award at the Industrial Fair (republished across multiple sites since 10-12, already covered), Enflame’s “A-share listing” (verified to be a re-publication of old news from 09-11), “adapting a hundred-billion-parameter model in 7 days” (Dongfang Suanxin DF1000, not FlagOS-related), and Lanxin Computing’s RISC-V Bay Area Chip Expo piece (not FlagOS-related) — all of which were excluded.
III. Deep Dive on Member Units
3.1 Moore Threads: S5000 conference figures, MThreads operators, and the MUSA line (10-16 ~ 10-19)
Dates: 2026-10-16 ~ 2026-10-19 Sources: DOIT main forum report · FlagGems #6985 · #7246 · FlagGems-vllm #934 · build-infra #1399
- Conference figures: The main forum gave two sets of Moore Threads-related numbers — on S5000, Qwen3.6-35B-A3B reaches 82.29% ~ 89.83% of H100-equivalent throughput, 4% ~ 19% above the vendor’s native performance; in the end-to-end comparison, the DSV4-flash gain on NVIDIA (+12.63%) is presented alongside the domestic-side comparison, indicating that S5000 has been folded into the 2.2 performance benchmark set.
- Code side: FlagGems merged
moe_load_balance_loss(MUSA specialization, #6985); #7246 under review optimizesmm(+3501/-72, newly opened 10-19 00:06); FlagGems-vllm #934 fixes MUSA vLLM baseline startup, and #937 converges the FP8 varlen accuracy matrix; the sunrise builder in build-infra is unrelated to this item — Moore Threads itself corresponds to the mthreads wheel row in FlagTree (pre-existing). - Note: Moore Threads’ Step 5 Preview Day-0 on 10-15 (MTT S5000 + MUSA + SGLang-MUSA, hybrid sliding-window/CSA sparse attention, FP8 DeepGEMM, MTP3 speculative decoding) runs on its own MUSA software stack, not the FlagOS plugin chain; that event was covered in the previous issue and is not counted again as a FlagOS ecosystem item here.
3.2 MetaX: Two tiers of MiniMax M3 and Kimi K3 optimization on C550 under review; metax wheels enter the daily line (10-18 ~ 10-19)
Dates: 2026-10-18 ~ 2026-10-19 Sources: vllm-plugin-FL #540 · #607 · build-infra #1377 · #1394
- Model adaptation (under review): #540 is the MiniMax M3 BF16 optimization tier on two-node MetaX C550, TP16 (opened 09-18, still being updated 10-18 21:54, including sparse attention, small-batch Linear/MoE, and communication optimizations); #607 is the Kimi K3 MXFP4/BF16 implementation on four-node C550, TP8 / PP4 / DP1 (EP and SP disabled), running on the 0.4.0-dev branch compatible with vLLM 0.28, with model adaptation, TP/head packing, shape selection, and PP runtime orchestration all kept on the FL side (newly opened 10-19 01:58).
- Build side: build-infra puts metax into FlagTree’s daily wheel line (#1377), lands a self-contained 22.04 FlagCX builder for metax (#1394, including two fixes to the SDK version variable name and the deb unpack path), and records a metax wheel re-release at 10-18 09:21.
- Assessment: MetaX’s role within FlagOS has shifted from “a chip being adapted” to “a contributor of performance tiers” — both PRs under review are paired deployment recipes (node count, parallelism, quantization format, context) rather than single-operator patches; such PRs are costly to review, but once merged they become reusable reference configurations.
3.3 Iluvatar / Enflame / Cambricon / Hygon / Tsingmicro / Sunrise / DAMO XuanTie: Six-backend 22.04 and operator lines (10-16 ~ 10-18)
Dates: 2026-10-16 ~ 2026-10-18 Sources: build-infra #1380 · #1389 · #1398 · #1403 · FlagCX #643 · FlagBLAS #148 (full list in appendix)
- Iluvatar: FlagCX 22.04 builder and re-release of two corex pins at
v0.14.0(#1403 / #1407, 22.04-clean, without device bitcode); the iluvatar row in FlagTree moves from “a standalone workflow” into the matrix with daily wheels enabled (#1390 / #1393 / #1397); Torch-FL reroutes complex dtypes in the FlagGems factory on DCU (#548); FlagGems #7220’s conv2d weight caching and channels_last fusion optimization is under review. - Enflame: FlagCX 22.04 builder (#1398 / #1401, recording an enflame wheel re-release); on the FlagTree side, fixes the
tle.gpu.allocalias test erroneously running on enflame (#1387); FlagGems-vllm #900’s GLM-5.3 Flash public operators are shared across vendors, not enflame-specific. - Cambricon: FlagCX 4.7.2’s 22.04 builder (#1389, with a pandas patch to resolve the
torch_mluimport issue #1391), recording a 22.04-clean re-release of neuware 4.7.2 at 10-17 21:39 (#1392). - Hygon: FlagCX enables the Hygon Device API and the unified-IR HIP backend (#643), and lands the 22.04 builder and wheel re-release record (#1380 / #1383); FlagGems #7242 under review caps split-KV’s
BLOCK_Mat 16 to stay within 64KB LDS; Torch-FL’s DCU complex dtype rerouting is the same as #548. - Tsingmicro: Torch-FL routes metadata-only view operators to the vendor slot (#550), continuing the Tsingmicro backend’s “scaffold first, semantics later” path from the 2.2 cycle.
- Sunrise: FlagTree’s builder and wheel are consolidated into a single file (22.04 toolchain publishable and reusable, pybind11 pinned to 3.1.0), added to the shared builder matrix, and the daily wheel row is enabled (#1399 / #1402).
- DAMO XuanTie: FlagBLAS adds four-precision GEMM for Zhenwu PPU (including NN/TN/NT/TT variants, #148); FlagGems-vllm fixes W8A8 MoE integer accumulation and reuses GEMM2 (#924); FlagGems #7203 under review fixes a backend GRU barrier deadlock, and the thead accuracy suite in the #7209 series is running in sync.
- D-Robotics: No commits, PRs, or news activity detected in the window.
IV. Summary and Trend Observations
- Narrative and engineering aligned for the first time: The main forum framed 2.2 as “large-scale shared optimization” (21 vendors, 35 chips, 1,454 operators, +27.6%, 264 contributors), while the single heaviest item on the GitHub side in the same window happened to be build-infra’s six-backend 22.04 builder and per-backend daily wheel matrix—both answer the same question: the chip roster must be backed by a reproducible delivery surface. This is the most noteworthy correspondence of this issue.
- The operator domain is expanding, but the direction of expansion needs to be seen clearly: KernelGen landed thirty-plus NVIDIA operators over three days, mostly boundary operators such as
_dim_arange,values_copy, and_has_same_storage_numel, indicating that trunk coverage is nearing completion and work has moved into cleanup of alias and view semantics; meanwhile, incremental work on domestic backends remains concentrated on Kunlunxin (twenty-plus optimizations) and DAMO XuanTie (GEMM completion), and the coverage gap between backends has not narrowed. The establishment of the FlagCV repo is expansion in another direction—from LLMs and scientific computing toward OpenCV-style image processing, with six backend directories laid out at once, but the repo has no runnable operators yet, so it should not be overestimated in the short term. - The quantum line has taken on product form: The dual release of FlagQuantum 0.3.0 / 0.3.1 plus the external launch of Liangzhi Cloud write engineering capabilities such as “resumable Jiuding / QUAFU tasks” into the release notes, while explicitly stating that it does not run on hardware and contains no agent runtime. The division of labor is “FlagOS does the execution stack and scheduling, the quantum institute does hardware and cloud”—this explains the boundary better than the vague slogan of “quantum-intelligence integration.”
- On the RISC-V side, the action is deep in the compiler: SpaceMiT’s
smt_rvisalets authors explicitly control SEW / VL / instruction selection and retires the private TLE copy—such changes appear in no external messaging, yet they determine whether the RVV backend can move from “it runs” to “it can push performance.” - To watch: First, per-session notes from the conference’s sub-forums and workshops have not yet been published; beyond the main forum, technical and tactical content (unified IR, Token Factory, edge deployment) currently exists only as agenda framing. Second, when Liangzhi Cloud will open externally. Third, when FlagCV will land its first runnable operator. Fourth, the training side (Megatron-LM-FL / TransformerEngine-FL / FlagScale) had zero pushes over three days—whether this is normal silence around the conference or the starting point of the 2.3 cycle needs confirmation in the next issue.
Appendix: Source Verification Table
| Source | Verification method | Conclusion |
|---|---|---|
| GitHub | Full org repos (61 repos) | 16 repos pushed within the window; FlagDNN / FlagFFT / Trident / docs were branch pushes, with the latest commits on default branches all outside the window |
| GitHub | Commit search (paginated) | 147 commits, 12 repos; pulled in two pages (100 + 47), supplemented by 100 org event-stream entries and commits.atom fallback for four repos |
| GitHub | Merged PR search | 139 PRs, 11 repos (two pages: 100 + 39), using is:merged + merged:>= as ground truth |
| GitHub | Open PR search | 239 PRs, 23 repos (three pages: 100 + 100 + 39), of which 27 carry event labels |
| GitHub | Release / tag atom verification | 31 repos’ releases.atom + 8 repos’ tags.atom: FlagQuantum v0.3.0 / v0.3.1 and FlagCX v0.15.0.dev0 within the window; FlagOps v2.0.5 / v2.0.6 on 10-15 (just outside the window) |
| News | Google News RSS (24 groups, Chinese and English, via proxy) | 34 hits; 1 event substantively included (10-18 main forum), the rest being member-company pieces, republished old news, and non-FlagOS articles |
| News | HN Algolia (8 groups) | No direct hits |
| News | DOIT on-site reporting | Main forum content verified paragraph by paragraph (2.1 / 2.2 / 3.1); the report’s stated “September 30 release” is inconsistent with the repo landing dates (09-28 ~ 09-29), noted in the body text |
| Official channels | CSDN FlagOS column | Three new sub-forum livestream pages within the window (10-17 / 10-18); no new long-form articles |
| Official channels | BAAI community hub.baai.ac.cn | No FlagOS entries detected within the window |
| Historical comparison | 10-16 daily report (previous issue) | Deduplication check: previous issue cutoff was 10-16 06:00; Step 5 Preview Day-0, the MetaX challenge, and Iluvatar CoreX MiniCPM-V 4.7 were all already included and are not repeated in this issue |
Complete Source List
- [1] 1.1 Organization overview and FlagCV’s first landing — https://github.com/orgs/flagos-ai/repositories · https://api.github.com/orgs/flagos-ai/repos · https://github.com/flagos-ai/FlagCV
- [2] 1.2 FlagCV skeleton — https://github.com/flagos-ai/FlagCV/pull/1 · https://github.com/flagos-ai/FlagCV/commits/main · https://github.com/flagos-ai/FlagCV/blob/main/docs/architecture.md
- [3] 1.3 build-infra FlagTree matrix — https://github.com/flagos-ai/build-infra/pull/1369 · https://github.com/flagos-ai/build-infra/pull/1371 · https://github.com/flagos-ai/build-infra/pull/1377 · https://github.com/flagos-ai/build-infra/pull/1390 · https://github.com/flagos-ai/build-infra/pull/1393 · https://github.com/flagos-ai/build-infra/pull/1397 · https://github.com/flagos-ai/build-infra/pull/1399 · https://github.com/flagos-ai/build-infra/pull/1402 · https://github.com/flagos-ai/build-infra/pull/1404 · https://github.com/flagos-ai/build-infra/pull/1405 · https://github.com/flagos-ai/build-infra/pull/1406
- [4] 1.3 build-infra FlagCX builder — https://github.com/flagos-ai/build-infra/pull/1372 · https://github.com/flagos-ai/build-infra/pull/1380 · https://github.com/flagos-ai/build-infra/pull/1383 · https://github.com/flagos-ai/build-infra/pull/1389 · https://github.com/flagos-ai/build-infra/pull/1391 · https://github.com/flagos-ai/build-infra/pull/1392 · https://github.com/flagos-ai/build-infra/pull/1394 · https://github.com/flagos-ai/build-infra/pull/1396 · https://github.com/flagos-ai/build-infra/pull/1398 · https://github.com/flagos-ai/build-infra/pull/1401 · https://github.com/flagos-ai/build-infra/pull/1403 · https://github.com/flagos-ai/build-infra/pull/1407
- [5] 1.3 Packaging and bundles — https://github.com/flagos-ai/build-infra/pull/1347 · https://github.com/flagos-ai/build-infra/pull/1365 · https://github.com/flagos-ai/build-infra/pull/1376 · https://github.com/flagos-ai/build-infra/pull/1381 · https://github.com/flagos-ai/build-infra/pull/1382 · https://github.com/flagos-ai/build-infra/pull/1387 · https://github.com/flagos-ai/build-infra/pull/1388 · https://github.com/flagos-ai/build-infra/pull/1375 · https://github.com/flagos-ai/build-infra/pull/1395 · https://github.com/flagos-ai/build-infra/pull/1400
- [6] 1.4 FlagGems merge batch — https://github.com/flagos-ai/FlagGems/pull/6989 · https://github.com/flagos-ai/FlagGems/pull/6987 · https://github.com/flagos-ai/FlagGems/pull/6988 · https://github.com/flagos-ai/FlagGems/pull/7080 · https://github.com/flagos-ai/FlagGems/pull/7078 · https://github.com/flagos-ai/FlagGems/pull/7082 · https://github.com/flagos-ai/FlagGems/pull/7084 · https://github.com/flagos-ai/FlagGems/pull/7085 · https://github.com/flagos-ai/FlagGems/pull/7087 · https://github.com/flagos-ai/FlagGems/pull/7126 · https://github.com/flagos-ai/FlagGems/pull/7127 · https://github.com/flagos-ai/FlagGems/pull/7128 · https://github.com/flagos-ai/FlagGems/pull/7129 · https://github.com/flagos-ai/FlagGems/pull/7086 · https://github.com/flagos-ai/FlagGems/pull/7083 · https://github.com/flagos-ai/FlagGems/pull/7094 · https://github.com/flagos-ai/FlagGems/pull/7037 · https://github.com/flagos-ai/FlagGems/pull/7004 · https://github.com/flagos-ai/FlagGems/pull/6979 · https://github.com/flagos-ai/FlagGems/pull/6634 · https://github.com/flagos-ai/FlagGems/pull/6599 · https://github.com/flagos-ai/FlagGems/pull/6629 · https://github.com/flagos-ai/FlagGems/pull/6632 · https://github.com/flagos-ai/FlagGems/pull/7215
- [7] 1.4 FlagGems Kunlunxin optimization batch — https://github.com/flagos-ai/FlagGems/pull/7192 · https://github.com/flagos-ai/FlagGems/pull/7049 · https://github.com/flagos-ai/FlagGems/pull/6493 · https://github.com/flagos-ai/FlagGems/pull/7189 · https://github.com/flagos-ai/FlagGems/pull/6886 · https://github.com/flagos-ai/FlagGems/pull/7213 · https://github.com/flagos-ai/FlagGems/pull/7214 · https://github.com/flagos-ai/FlagGems/pull/6875 · https://github.com/flagos-ai/FlagGems/pull/7144 · https://github.com/flagos-ai/FlagGems/pull/7218 · https://github.com/flagos-ai/FlagGems/pull/7202 · https://github.com/flagos-ai/FlagGems/pull/7073 · https://github.com/flagos-ai/FlagGems/pull/6885 · https://github.com/flagos-ai/FlagGems/pull/6797 · https://github.com/flagos-ai/FlagGems/pull/7195 · https://github.com/flagos-ai/FlagGems/pull/6983 · https://github.com/flagos-ai/FlagGems/pull/7053 · https://github.com/flagos-ai/FlagGems/pull/6985 · https://github.com/flagos-ai/FlagGems/pull/7124
- [8] 1.5 FlagTree — https://github.com/flagos-ai/FlagTree/pull/1381 · https://github.com/flagos-ai/FlagTree/pull/1387 · https://github.com/flagos-ai/FlagTree/pull/1389 · https://github.com/flagos-ai/FlagTree/pull/1394 · https://github.com/flagos-ai/FlagTree/pull/1395 · https://github.com/flagos-ai/FlagTree/pull/1396
- [9] 1.6 FlagCX and FlagQuantum — https://github.com/flagos-ai/FlagCX/releases/tag/v0.15.0.dev0 · https://github.com/flagos-ai/FlagCX/pull/643 · https://github.com/flagos-ai/FlagCX/pull/663 · https://github.com/flagos-ai/FlagCX/pull/668 · https://github.com/flagos-ai/FlagQuantum/releases/tag/v0.3.0 · https://github.com/flagos-ai/FlagQuantum/releases/tag/v0.3.1 · https://github.com/flagos-ai/FlagQuantum/pull/629 · https://github.com/flagos-ai/FlagQuantum/pull/634
- [10] 1.7 Inference and training stack — https://github.com/flagos-ai/FlagGems-vllm/pull/900 · https://github.com/flagos-ai/FlagGems-vllm/pull/896 · https://github.com/flagos-ai/FlagGems-vllm/pull/924 · https://github.com/flagos-ai/FlagGems-vllm/pull/934 · https://github.com/flagos-ai/FlagGems-vllm/pull/937 · https://github.com/flagos-ai/vllm-plugin-FL/pull/409 · https://github.com/flagos-ai/vllm-plugin-FL/pull/593 · https://github.com/flagos-ai/vllm-plugin-FL/pull/598 · https://github.com/flagos-ai/vllm-plugin-FL/pull/540 · https://github.com/flagos-ai/vllm-plugin-FL/pull/607
- [11] 1.7 Torch-FL — https://github.com/flagos-ai/Torch-FL/pull/545 · https://github.com/flagos-ai/Torch-FL/pull/547 · https://github.com/flagos-ai/Torch-FL/pull/548 · https://github.com/flagos-ai/Torch-FL/pull/549 · https://github.com/flagos-ai/Torch-FL/pull/550 · https://github.com/flagos-ai/Torch-FL/pull/551 · https://github.com/flagos-ai/Torch-FL/pull/553 · https://github.com/flagos-ai/Torch-FL/pull/557 · https://github.com/flagos-ai/Torch-FL/pull/559 · https://github.com/flagos-ai/Torch-FL/pull/560 · https://github.com/flagos-ai/Torch-FL/pull/565 · https://github.com/flagos-ai/Torch-FL/pull/567 · https://github.com/flagos-ai/Torch-FL/pull/273 · https://github.com/flagos-ai/Torch-FL/pull/530 · https://github.com/flagos-ai/Torch-FL/pull/542 · https://github.com/flagos-ai/Torch-FL/pull/568 · https://github.com/flagos-ai/Torch-FL/pull/574 · https://github.com/flagos-ai/Torch-FL/pull/577 · https://github.com/flagos-ai/Torch-FL/pull/584 · https://github.com/flagos-ai/Torch-FL/pull/357
- [12] 1.8 Operator libraries and the open-PR surface — https://github.com/flagos-ai/FlagBLAS/pull/148 · https://github.com/flagos-ai/FlagTensor · https://github.com/flagos-ai/FlagGems-sglang/pulls · https://github.com/flagos-ai/FlagGems/pull/7246 · https://github.com/flagos-ai/FlagGems/pull/7239 · https://github.com/flagos-ai/FlagGems/pull/7243 · https://github.com/flagos-ai/FlagGems/pull/7203 · https://github.com/flagos-ai/FlagGems/pull/7220 · https://github.com/flagos-ai/FlagGems/pull/7242
- [13] 2.1 / 2.2 / 3.1 Conference main forum and Liangzhi Cloud — https://www.doit.com.cn/computing/860804040699973.html · https://www.bagevent.com/event/9263895
- [14] 2.3 Sub-forum livestream pages and column — https://flagos.csdn.net/ · https://flagos.csdn.net/6ad0972649ed150a32d7dd22.html · https://flagos.csdn.net/6ad09c47536f457592b0185d.html · https://flagos.csdn.net/6ad307be49ed150a32d847a1.html · https://hub.baai.ac.cn/
- [15] 2.3 Search and exclusion basis — https://finance.sina.com.cn/tech/roll/2026-10-16/doc-inivkncr7860303.shtml · https://www.eet-china.com/news/202610165757.html · https://hn.algolia.com/
- [16] Appendix verification baseline — https://github.com/flagos-ai · https://api.github.com/orgs/flagos-ai/repos · https://github.com/flagos-ai/FlagQuantum/releases · https://github.com/flagos-ai/FlagCX/tags