Xing4_0 登陸 SGLang：中國電信下一代 MoE 的第六個 PR，以及首度公開的規模

2026 年 9 月 16 日，相隔兩小時，兩大主流開源推論服務堆疊不再對名稱各執一詞。vLLM 在上午提交了「[Model] Add Xing4_0 support」；sgl-project/sglang 隨即在 UTC 10:38 跟進「feat: add Xing4_0 model support」，而在三個名稱並行使用六週之後，兩個框架如今都稱其為Xing4_0。SGLang 的 pull request 帶來了先前任何一份都沒有的東西：尺寸。它將模型描述為Xing4.0-29B-A4B，一個「29B 參數的 MoE，約 4B 啟用參數」，並給出一條啟動指令，指明 checkpoint 路徑、262,144 token 上下文與 EAGLE 推測解碼。這是中國電信尚未發布的 MoE，正是 XingChen4 相關 pull request 自八月以來不斷繞著打轉的那一個，而它仍未發布：權重未公開，PR 所指的 checkpoint 路徑在專案外無人能解析，沒有任何廠商確認名稱或數字，本文亦無任何內容經過獨立查證。取自 pull request 的事實均標明出處；其餘則是歷史與推論。今天你真正能呼叫到的最接近模型是 DeepSeek V4 Flash。

這是一篇「目前已知」的整理報導，持續更新而非從頭重寫。內容涵蓋六週以來的 PR 軌跡、命名問題如何塵埃落定、9 月 16 日那兩個 pull request 究竟新增了什麼、設定檔如今實際洩漏出的架構細節，以及接下來該留意什麼。一句話總結：中國電信的下一個 MoE 已經真實到累積了六個推論服務整合、在 vLLM 中有一列表格標註為 TBA、在 SGLang 文件中有了一則標註「即將推出」的條目，還有一個明示的參數量——卻仍不夠真實到能在任何你觸及得到的地方跑起來。

訊號：六項整合、三個名稱、六週

這條線索的起點比這篇文章最初報導的版本更早，而它的提交紀錄仍是這次外洩中最能說明問題的產物。第一個 vLLM PR 是 #51237，於 2026 年 8 月 6 日開啟，標題為「[WIP][Model] Add upcoming XingChen4 model support」。它的三個提交本身就說明了整個故事。第一個提交標題為「Add TeleChat4 model support」。第二個提交在一個多小時後出現，標題為「chore: revert premature docs and test entry for telechat4」——文件與 registry 測試項目因過早而被撤回。第三個提交在 8 月 27 日，標題為「rename xingchen4」。一分鐘後，該 PR 未合併即被關閉，而在那之後十一分鐘，#54051以相同標題、相同分支（supported_telechat4）和單一 squash 提交開啟。在此期間被加上了一個 needs-rebase 標籤，所以這讀起來更像是清理後關閉再重開，而不是改變主意。這一切都是從 GitHub 帳號 zyp2014 提交的，每個提交的作者與簽署者都是 zhangyp26 <zhangyp26@chinatelecom.com.cn>。

那第二個 PR 正是這篇文章最初圍繞的重點，而它已經不再是開啟狀態。#54051 已於 2026 年 9 月 7 日由其作者本人關閉，未經合併。不過它的說明仍值得一提並引用，因為那正是歷經每一次改名與每一次重新開啟後依然留存下來的那句話：

• 模型權重尚未在 Hugging Face Hub 上公開。此 PR 是為了提早進行程式碼審查而開啟的。一旦權重釋出，我會在 tests/models/registry.py 中加入測試條目、更新 docs/models/supported_models.md，並將 PR 標記為準備好接受審查。

那句話就是整個故事的縮影：程式碼走在權重前面。下方的截圖是 #54051 頁面在 2026 年 8 月 27 日、也就是它開啟當天的樣貌——一份帶有日期戳記的快照，之所以保留，是因為其中顯示的 pull request 後來已經關閉。請把它讀作當時訊號的紀錄，而不是它現在的狀態。

接著，在9月16日，同樣的模式再次出現——一天內兩次。#57135，「[Model] 新增 Xing4_0 支援」，於當天早上由同一個帳號 zyp2014 開啟，單一提交如今由另一位中國電信工程師撰寫——xiongji <xiongj9@chinatelecom.cn>。共變更 11 個檔案，約 1,300 行新增，全篇採用新名稱，且相同位置有相同的但書：「模型權重尚未在 Hugging Face Hub 上公開。」

兩小時二十分鐘之後，另一個服務堆疊不再是落後一次重新命名的那一方。sgl-project/sglang #39793，標題為「feat: add Xing4_0 model support」，從一個名為 support_xing4_0 的分支開啟，而它唯一的提交帶有與 vLLM 那次重新命名相同的 xiongji 位址。十四個檔案、約 1,400 行新增，其中略多於一千行是單一模型檔案。這是六週內為這個模型提出的第六個整合，也是第一個以非草稿形式提交的：GitHub 將它列為已開啟、可供審查，並要求了十位審查者——而它的三次 CI 執行已全部亮紅燈。

在今天之前，SGLang 這一邊的運作方式與 vLLM 相同。#33982，〈feat(model): add TeleChat4 model support〉，由貢獻者 PaddyXj 於 2026 年 8 月 7 日提出，並在 8 月 31 日以未合併狀態關閉——就在同一天，#37228，〈feat: add XingChen4 model support〉，取而代之提出。那一件目前仍以草稿形式掛在 PaddyXj 名下保持開啟，位於名為support_xingchen4的分支上，已累積三個提交，最後一次更動是在 9 月 8 日。它的檢查清單是兩套框架中最有意思的部分：模型能在「本機、以內部權重」載入並生成——已勾選；工具呼叫——已勾選；推理剖析——已勾選；而公開 CI 則未勾選，因為它「受阻於權重發布」。有人手上握有一份檢查點，卻沒有人公開它。而且，不像 vLLM 每次重新提交都會先關閉前一版，SGLang 現在有兩個針對同一模型、以兩個不同名稱提出的 pull request 同時存活。

六週內的六次整合加起來所代表的，並不是同一項訊號的更強版本；而是另一項不同的訊號。六次整合會與一個正在反覆迭代的團隊相符。六次整合、三個名稱——TeleChat4、XingChen4、Xing4_0——則是一個團隊在公開場合針對模型最終將以哪個名稱發布反覆琢磨，而權重仍保持私密。那是未經證實的推斷，而這也是目前 PR 軌跡所顯示的最具關鍵影響的一件事。

這兩個九月的 PR 究竟新增了什麼

這個 vLLM pull request 是對八月工作的重新命名，而不是改寫。模型檔案現在是 vllm/model_executor/models/xing4_0.py，類別是 Xing4_0ForCausalLM，而 model_type xing4_0 對應到 DeepseekV3Config —— 也就是 XingChen4 版本所使用的同一個 Deep​Seek-V3 設定。它包含的內容：

• 在 vllm/model_executor/models/xing4_0.py 中的完整模型實作 — 類別 Xing4_0ForCausalLM，包含前向傳遞、mHC 適配器，以及張量平行的 load_weights() 實作。提交訊息指出同時支援 DSA 與非 DSA 變體，並重複使用共用的 mhc_pre / mhc_post 運算。

• 在 vllm/model_executor/models/registry.py 中註冊 Xing4_0ForCausalLM，讓 vLLM 能依名稱認得這個架構。

• 一個推理解析器（vllm/reasoning/xing4_0_reasoning_parser.py），「適用於具備推理能力的變體」，以及一個工具解析器（vllm/tool_parsers/xing4_0_tool_parser.py），用於自動工具呼叫。

• 在 vllm/config/speculative.py、vllm/transformers_utils/model_arch_config_convertor.py 與 vllm/transformers_utils/config.py 中註冊——並在提交訊息中說明已為推測解碼啟用與 DeepSeek-V3 相容的 MTP 頭。

• 兩份文件 — 真正新增的部分，以及對八月的直接逆轉。最初的提交包含一項文件與測試項目，但一小時後因被認為時機過早而遭還原；九月的 PR 重新納入文件，並標記為 documentation、new-model 與 tool-calling。

vLLM 文件條目是讀者第一次從中學到具體內容的地方。在 docs/models/supported_models.md，新的一列寫著 `Xing4_0ForCausalLM` | Xing4_0 | TBA——checkpoint 欄位字面上寫著 TBA，那不過是用不同字體寫出的同一句「尚未」。而在 docs/features/tool_calling.md中，在標題「Xing4_0 Models (xing4_0)」底下，該 PR 記錄了模型的工具呼叫格式：呼叫會以 <tool_call>...</tool_call> 區塊的形式發出，形式可以是 JSON（{"name": ..., "arguments": {...}}），或是使用 <param_key>...</param_key> 與 <param_value>...</param_value> 的標籤式形式。這是先前的 PR 未能達到的具體程度——模型對話格式的一項實作細節，被寫進某個主要框架的公開文件裡，而且是為了一個沒人能下載的 checkpoint。

SGLang 的 PR 更有意思，因為它附帶的是實作與設定，而不是註冊表項目與文件。它文件中的那一列是首次有框架把廠商名稱放進自家文件裡。在 docs/docs/supported-models/generative_models.mdx，新的一列列出了 Xing4_0，其中 checkpoint 欄位寫著 `Xing4_0` （即將推出）以及一段描述：「中國電信的 MoE 模型，採用 MLA 注意力與 mHC（流形約束超連接）殘差流；支援原生 MTP 推測解碼、工具呼叫與推理。」vLLM 的那一列寫著 TBA，且未指名任何廠商；SGLang 的則指名中國電信並表示即將推出。兩者都不是發布日期，而框架文件中的一列並不是產品。

這則報導先前的每個版本都缺少的數字，由這份 PR 說明補上了。「這個 PR 新增了對 Xing4.0-29B-A4B（290 億參數的 MoE，約 40 億啟用參數）的支援。」它也給出了一道啟動指令——--model-path XingChen-AGI/Xing4.0-29B-A4B --trust-remote-code --tp-size 2 --context-length 262144 --reasoning-parser xing4_0 --tool-call-parser xing4_0 --speculative-algorithm EAGLE——並聲明該配置已在張量平行度 2、262,144 個 token 的上下文，以及 EAGLE MTP 推測解碼下驗證過，還把一段推理回應與一次 get_weather 工具呼叫的逐字稿貼進說明作為證據。那項驗證背後的權重屬於作者本人：PR 所指名的儲存庫路徑無法公開讀取，而它指向的 Hugging Face 組織完全沒有列出任何公開模型。請把尺寸、上下文長度與逐字稿視為附帶於私有檢查點的 PR 自述主張，而非任何人都能重現的測量結果。這一切都僅根據該 pull request，且未經重現。

推理與工具解析器同時以兩個名稱出現，這件事之所以重要，原因和八月時一樣。推理解析器的存在，是為了從模型輸出中剝除思考標記——也就是模型在給出最終答案前所發出的內部思維鏈。專為此模型打造的解析器，意味著這個系列預期會有具備推理能力的變體，就如同 TeleChat3 推出了 Thinking 版本一樣。工具解析器，加上如今已有文件記載的呼叫格式，則意味著原生函式呼叫同樣在預期之中。這兩者都不是對最終產品的保證；但兩者都是 PR 中關於 China Telecom 目標所在的最強提示。

目前已知資訊，一目了然

下方的計分板，是 2026 年 8 月 27 日為本文所彙整的那一份，取材自當時的 vLLM PR。它被刻意保留在此，作為一份註明日期的快照，而非重新繪製，因為三週之後，它的每一行依然成立——尚未發布、權重未公開、DeepSeek 主幹、mHC 殘差、兩個解析器都涵蓋在內。改變的並不是卡上的任何數值，而是它周遭的一切：它引用的 vLLM PR 已於 9 月 7 日關閉，這項工作於 9 月 16 日以新名稱重新出現，SGLang 在數小時後跟進改名，第一個明確公布的參數數量也隨之到來。卡上沒有任何一點是錯的。它只是已經三週大了，而故事早已推進到它之後。最後一列的 FlagGems 數據原封不動地延續到新的 vLLM PR 中，仍為 PR 所報告，也仍未被重現。

PRs 所洩漏的架構

重新命名檔案並不會重新命名架構，而九月 vLLM PR 中的摘要文字，就是八月的文字以 Xing4_0 取代 XingChen4——逐子句完全相同。有兩句話承載了訊號：

• "Xing4_0 重用 Deep​Seek-V2/V3 主幹（MLA 注意力、MoE 區塊、可選的 DSA 索引器）。"

它以流形約束超連接（mHC）取代標準殘差連接：將殘差流擴展為 num_residual_streams 個並行流，並透過 Sinkhorn-Knopp 投影生成依賴輸入的雙隨機矩陣來混合這些並行流。

每個子句都對應到某個具體事物。MLA 是 Multi-head Latent Attention，這是 DeepSeek 在 V2 中提出的壓縮注意力機制，能讓 KV 快取保持精簡；MoE 是混合專家路由，能以很小的活躍佔用維持龐大的參數量。選配的 DSA 索引器是 V3.2 系列的 DeepSeek Sparse Attention 機制——一個輕量級評分模組，會挑選要關注的 top-k 符元，將注意力成本從隨上下文長度呈二次方降低到大致線性。而 mHC 那句話則是最大亮點：這個模型採用了 DeepSeek 自己在這一代才首度引入的殘差架構。

SGLang 的 PR 是第一個公開這種東西的形狀、而非描述它的。其設定檔 python/sglang/srt/configs/xing4_0.py 宣告了 40 個隱藏層、3,584 的隱藏大小，以及 131,072 個詞元的詞彙表；MLA 在 32 個頭上具有 512 的 KV LoRA 秩與 768 的查詢 LoRA 秩；以及一個稀疏 MoE，帶有 64 個路由專家加一個共享專家、top-4 路由、sigmoid 評分、2.0 的路由縮放因子，以及 noaux_tc 專家選擇。mHC 欄位也很明確：hc_mult 4、二十次 Sinkhorn-Knopp 迭代、h_res 鉗位在正負 30，以及 rope_theta 為 10,000，最大位置嵌入為 262,144。根據該 pull request，這些是尚未發布的整合中的預設值——設定檔是一份意圖聲明，不是模型卡，而 PR 描述中的 29B-A4B 數字在任何公開資料中都並非由它們推導而來。

有一個欄位的價值高於其餘所有欄位，因為這是這個模型明顯不再只是 DeepSeek 複製品的第一個地方。SGLang 設定會設定 hc_contract_for_draft，這會在最終 norm 之前把 mHC 串流合併回模型自身的 hidden size，並把那個收縮後的張量餵給 Eagle 草稿頭。DeepSeek V4 則是改餵入經 mHC 展平、維度為 n 倍 hidden_size 的張量。設定註解明確說明了這一點，而這正是那種唯有實作真正對照過真實 checkpoint 雕琢之後才會浮現的細節——也就是先前的 SGLang PR 檢查清單聲稱擁有、卻未公開的東西。

mHC 的數學正是這兩套堆疊在實作上分歧、但在假設上一致的地方。vLLM 的 PR 指出，它「與 vllm.model_executor.layers.mhc 中的共用運算子相符，因此不會引入私有核心」——該模組之所以存在，是因為 vLLM 已支援 DeepSeek V4 的 mHC，所以新增這個模型的邊際成本很小。SGLang 則是殊途同歸：其 mHC 模組使用註冊為 torch 自訂運算子的融合 TileLang 核心，而該 PR 擴充既有的 mhc_pre split-K 核心，使其在原本已處理的兩種大小之外，也能接受 hc_hidden_size 14,336。它也會為這個架構關閉 DeepGEMM 的 tf32_hc_prenorm_gemm 路徑，因為該路徑是 torch.compile 無法追蹤的原生 C 擴充；mHC 反而會改走 TileLang 核心。這兩個框架的實際優勢相同：如果你今天在 vLLM 或 SGLang 上服務 DeepSeek V4，那麼未來將用來服務中國電信下一代 MoE 的機制就已經安裝就緒。

mHC，位居一切核心的 DeepSeek 技巧

Manifold-constrained Hyper-Connections 值得深入剖析，因為它是這個模型最有趣的一點——而且它不是中國電信的發明，而是 DeepSeek 的。

這個故事的起點是 Hyper-Connections，由 Kimi 團隊在 2024 年提出。標準的 Transformer 每一層只維持一條殘差串流：輸入會加到該層的輸出上，讓梯度有一條乾淨的路徑，也讓網路能學習殘差修正。Hyper-Connections 則把這條單一串流替換成多條平行串流，並在每一層用可學習的矩陣加以混合，使模型中的資訊能有更豐富的傳遞路徑。問題在於穩定性：不受約束的混合矩陣會破壞恆等映射性質，而這正是殘差連接之所以可訓練的關鍵；到了兆級參數規模，訓練損失就會變得不穩定。

DeepSeek 的貢獻——以 mHC 論文形式於 2025 年 12 月發表，隨後用於 DeepSeek V4——是將混合矩陣約束為雙隨機矩陣：非負，且每一行與每一列的總和均為一，並在訓練期間透過 Sinkhorn-Knopp 投影強制執行。雙隨機矩陣的譜半徑恰好為一，因此訊號在穿過數百層時不會以指數方式被放大或衰減。這個界限正是讓訓練在大規模下保持穩定的關鍵，而且該投影成本夠低，DeepSeek 回報在四個殘差流下僅約 6.7% 的訓練額外負擔。於 2026 年 4 月 24 日發布的 DeepSeek V4 是這項技術的旗艦應用，據回報在數學推理任務上約有 15% 的增益，並額外支援 1M token 的上下文。

所以，這些 PR 說白了就是：中國電信的下一個模型採用了 DeepSeek 經驗證的骨幹，以及 DeepSeek 最新的殘差機制，而不是從零開始發明其中任何一項。這是個務實的選擇，也隱含著一個微妙的確認——在 DeepSeek 本身之後，第二個採用 mHC 的主要實驗室，相信這招已經可以投入生產。

這些 PR 尚未完成 mHC 的部分，而未結項目也坦承此事。在 vLLM 的各個 PR 中，作者指出檢查點偏差（bias_pre、bias_post、bias_res）與 h_res 鉗位目前已被合併或省略，而審閱者對公式等價性的確認是「主要的正確性問題」。另外還有一個自訂轉置運算，可讓張量在 TileLang 核心中保持 C-contiguous——它與其他所有東西一同被重新命名，從 _xingchen4_transpose_contiguous 改為 _xing4_0_transpose_contiguous——以及一項硬性限制：在 mHC 模式下，當 num_residual_streams 大於 1 時不支援管線平行化，但支援張量平行化。對草稿而言，這些都不令人意外，但它仍是八月時那個未完成的邊緣，而這本身就很有資訊量：六週的重新命名並未推進正確性問題，而最新 SGLang PR 上三次失敗的 CI 執行，則是同一個故事的不同色調。SGLang 設定確實解決的是串流數量。當 hc_mult 設為 4、隱藏大小為 3,584 時，核心修補程式中的 14,336 正好就是四條串流——而核心註解也明白寫出這一點。這篇文章最初發表時，那樣的解讀只是從一個單純數字推斷而來；如今它已寫在設定檔中。

加速角度：FlagGems，再次

另一條線索將這個模型與中國電信和北京智源人工智能研究院既有的關係連結起來，而這是唯一一條歷經每一次更名仍完整存續的線索。這項 vLLM PR 在 USE_FLAGOS 環境旗標後方啟用可選的 FlagOS/FlagGems 加速，預設為停用，並以熱路徑核心替換 MoE、注意力、softmax 與 top-k。根據 PR 作者在 H100 上針對高併發長提示工作負載（輸入 token 超過一萬、併發數 10）所做的基準測試，其宣稱的效益為：首次 token 時間最多降低 19.87%，每個輸出 token 時間最多降低 26.32%，其他工作負載則維持不變。這些數字由 PR 自行回報且未經重現，而且它們伴隨的是預設關閉的旗標。

值得記錄的是，這次更名所觸及的範圍有多麼小。九月的 vLLM PR 仍帶著相同的數據、同樣狹隘的範圍註記——該旗標僅存在於模型檔案內——以及同樣要安裝 flagtree 與 flag-gems 的指示。數字之所以沒有改變，是因為程式碼沒有改變；改變的只有標籤。SGLang 的 pull request 完全沒有 FlagGems 的痕跡——它們改走 TileLang 與 DeepGEMM 路線——這使得這件事變成關於誰擁有服務層最佳化的爭論，而不是關於模型本身。

這是一則延續性故事。截至 2026 年 4 月，TeleChat3-36B-Thinking 是第一個被獨立移植到 FlagOS 的大型模型，而 FlagOS 是 BAAI 的開源 AI 軟體堆疊。無論這款模型以什麼形式發布，延續這條脈絡——在其自家的 vLLM 整合中採用 FlagGems 核心——意味著該實驗室的國產堆疊策略延伸到了服務層，而不只是訓練。

命名問題，以及它所來自的家族

直到 9 月 16 日，命名問題還只是個附帶事項。如今它幾乎已成定局，而證據仍然全在分支名稱和殘留字串裡，而非正式聲明——但這兩個框架已從同一個方向收斂到相同答案。

• 提交訊息依序為：「新增 TeleChat4 模型支援」，然後是「chore：還原 telechat4 過早的文件與測試項目」，然後——三週後，且在 PR 被關閉前一分鐘——「重新命名 xingchen4」。一個唯一目的就是重新命名的提交。

• 這個 fork 開出了分支。前兩個 vLLM PR，#51237 和 #54051，是從 zyp2014:supported_telechat4 切出來的。第三個 #57135 則是 zyp2014:support_xing4_0。這個分支在重新命名模型的那次動作中一併被重新命名了——而 SGLang 這一側如今也分三步走過完全相同的路徑，從 support_telechat4 經過 support_xingchen4 到 support_xing4_0。

• #51237 的正文寫道，FlagGems 加速是「為 TeleChat4」而做，但同一段落卻把該模型稱為 XingChen4。這兩個名稱早在作者八月六日自己的摘要中就已互相打架。

• 雙方的逐檔案重新命名。在 vLLM 中，是將 xingchen4.py 改成 xing4_0.py，並將 XingChen4ForCausalLM 改成 Xing4_0ForCausalLM；在 SGLang 中，則是將 xingchen4.py 改成 xing4_0.py，並將 XingChen4Config 改成 Xing4_0Config，而且是在一個隨之更名的分支上進行。這兩個 PR 都沒有在其 diff 中任何地方留下舊名稱。

所以，有三個名稱在兩個框架之間輪番出現，而這個模式與單一模型在逐步接近其最終公開名稱的過程中不斷被改名相符。「Xing4_0」讀起來自然像是 Xingchen 4.0——該模型家族在中文裡的品牌名是星辰（Xingchen）——但這仍然是從字串推斷而來，並非任何公關稿明確表示的內容。也同樣有可能是，TeleChat4 和 XingChen4 是同一世代中的姊妹模型，而不是同一個模型掛兩個名字；不過，共用的 fork、共用的架構段落、共用的 FlagGems 數字、共用的未解決項目，以及如今共用的重新命名，讓這種說法更難成立。沒有人確認過這層關係，中國電信也未發表評論。改變的是，這次重新命名不再是某位貢獻者的選擇：兩個由不同人維護的獨立 serving 專案，都在彼此相隔一天內，把各自的整合重新標記為同一個第三名稱。

這個家族本身值得持續關注，因為它說明了這種務實作風。迄今為止，公開發佈的版本都以 TeleChat 為品牌：

• TeleChat-7B 和 TeleChat-12B，於 2024 年 1 月開源，附帶 1 兆 token 的語料庫。

• TeleChat2-115B（2024 年 9 月），號稱首個完全國產的兆參數開源模型，另有 35B、7B 和 3B 等同系列模型。

• TeleChat2-39B-A12B（2025年3月），該系列首個MoE。

• TeleChat3-105B-A4.7-Thinking（2025年12月），一個細粒度的 MoE 模型，總參數 105B、啟用參數 4.7B，以 15 兆 tokens 訓練，與密集模型 TeleChat3-36B 及後續的 TeleChat3-Coder-36B-Thinking 並列。

如果 29B-A4B 這個數字成立，這款模型在總參數量與活化參數上都將位在 TeleChat3-105B-A4.7-Thinking 之下——是體型更小、成本更低的同門兄弟，而非取而代之的旗艦。這是一種解讀，不是事實；兩份 PR 都沒有說明這款模型鎖定的是哪個層級。Xingchen 品牌是該公司投注 AI 心力之所在：Xingchen AGI Lab 於 2026 年 3 月在北京正式成立，建立在同一個模型家族之上，而 China Telecom 將其「三全」（全模態、全尺寸、全自主）體系描述為涵蓋從 1B 到 1T+ 參數的語意、語音、視覺與多模態模型。從 TeleChat 更名為 Xingchen，正是一個實驗室在希望模型家族掛上實驗室的品牌、而非產品線品牌時，會做的事。

我們還不知道的事

對這麼早期的模型來說，誠實清單仍然比已知清單長，不過本週已在兩處縮小：

• 沒有發布日期。六個整合中有五個是為了早期程式碼審查而開啟的草稿，正是因為權重尚未公開。第六個 SGLang #39793 是以審查而非草稿的形式開放——但它尚未合併，其三項 CI 執行全都失敗，而且需要一位審閱者核准。沒有公布的時程。

• 一個參數量，但僅是宣稱的數字。這篇文章先前每個版本都將 MoE 配置列為未公開。SGLang PR 在紙面上改變了這點：Xing4.0-29B-A4B，總計 29B，約 4B 啟用。這個數字來自一份 pull request，未附在任何公開檢查點上，未獲任何設定檔佐證，且該專案外無人重現過。把它視為所陳述的意圖，而非規格。

• 沒有基準測試數據，無論是廠商自行回報的還是其他來源，也沒有獨立評分。SGLang PR 中的驗證逐字稿顯示，該模型能回答一道推理提示，並發出格式正確的工具呼叫；但這些紀錄同樣沒有顯示它在這兩方面的表現究竟有多好。

• 沒有定價，也沒有確認的授權條款。先前每一版 TeleChat 發布都是 Apache-2.0，這點令人振奮，但這一版尚未說明授權條款。

• 沒有公開權重——這是經過確認的事實，而非假設。截至 2026 年 9 月 16 日，SGLang PR 所指名的 Hugging Face 路徑無法公開讀取，且其指向的組織未列出任何公開模型；該系列最新的公開項目是 1 月的 TeleChat3-Coder-36B-Thinking。vLLM 的支援模型表在 checkpoint 欄位標示 TBA，SGLang 的則標示「即將推出」，而兩個 SGLang PR 的公開 CI 都失敗。

• 中國電信沒有官方說法——沒有公告、沒有權重、沒有確認名稱或規模。請仔細注意這種不對稱：SGLang 文件中的那一列將該模型歸屬於中國電信，但那是 pull request 內貢獻者的描述，並非公司聲明，而最新的 PR 說明則完全省略了廠商名稱。有六個整合正在為這個模型開發，是迄今最強力的證據，顯示它確實存在，但整合會被關閉，代號也會改變；已經有兩個如此了。在實驗室親口證實之前，沒有任何事是確認的。

對這一切的正確解讀，並不是對這個模型抱持懷疑，而是對一項早期訊號的準確描繪。今天真正存在的，是真實的工程成品——共有六個，橫跨兩個框架——具有真實的架構，而且首次附上了明確表述的形態。目前尚未存在的，則是任何你能下載、呼叫或進行基準測試的東西。

現今你能運行最為接近的事物

這個模型無法在任何地方提供服務——不論是透過 API，還是在本機端，因為權重並未公開。當今讀者真正能呼叫、且與其共享架構血脈的最接近模型是 DeepSeek V4 Flash，它在 MLA 與 MoE 之上採用了相同的 mHC 殘差架構，而它正是這兩套框架中共用的 mHC 模組所依據的參考實作。OrcaRouter 上 deepseek/deepseek-v4-flash 的模型頁面列出了 100 萬個 token 的上下文、384K 的最大輸出，以及每百萬輸入 token 0.15 美元、每百萬輸出 token 0.29 美元的定價——與 DeepSeek 本身公布的數字相同，以 0% 加價直接轉嫁，因此供應商一調價，這裡當天就會生效。一組 API 金鑰即可涵蓋整個型錄，這使得將它與推論層級中其餘模型相互比較，成為一條路由規則，而非一次全新的整合。

這也是「當這個模型推出時，我該怎麼試用它」的實用解答。全新、未經證實的檢查點，正是自動容錯移轉發揮價值的地方：把一小部分流量導向它，保留一個經過驗證的模型作為備援，讓路由層來做決定，而不是把正式環境路徑賭在首日行為上。一個 29B MoE、約 4B 活躍參數（如果最終來的是這個），正是因為每個 token 只啟用其中極少部分，所以拿它來與前沿模型做路由競爭，成本很低。如果名稱從現在到正式發布之間又改了——而過去六週顯示這是有可能的——你要改寫的是路由規則，而不是整合。

常見問題

為什麼 vLLM 的 PR 被關閉了？

我們能看到關閉這件事，卻看不到原因。#54051 於 2026 年 9 月 7 日被其作者本人關閉，未被合併，而這項工作在九天後以新名稱 #57135 重新出現。較早的 vLLM PR #51237 在同一天以相同標題被關閉並重新提交，因此關閉再重新提交是這位作者的模式，而非麻煩的徵兆——但 PR 內文並未說明原因，我們也不會憑空編造一個。

Xing4_0 什麼時候會發布？

沒有日期。六項整合中有五項是為了早期程式碼審查而開啟的草稿，而作者自己的計畫是新增測試項目、更新文件，並且只有在權重釋出後才將這些 PR 標記為就緒。SGLang 較舊的檢查清單最清楚地說明了現況：「模型可載入並生成（在本機、使用內部權重）」已勾選，而公開 CI 則「因權重釋出而受阻」。較新的 SGLang PR 是以可供審查而非草稿的形式提交，這改變的是姿態而非狀態——它尚未合併、其 CI 是紅的，而文件列中寫著「即將推出」並不代表正式推出。

Xing4_0 和 XingChen4 是同一個模型嗎？

幾乎可以肯定是的，而這些 PR 讓查證變得容易：同樣的 fork 譜系、同樣的架構段落、同樣的 FlagGems 基準數據、同樣的待辦項目，以及兩個框架中逐檔案的重新命名——xingchen4.py 改為 xing4_0.py，包含 config 類別，且分支也重新命名以相符。這是同一項工作換上新名稱，而截至 9 月 16 日，vLLM 和 SGLang 都已採用那個名稱。沒有任何 PR 說明的是，已發布的檢查點將會帶有哪個名稱。

這是 Deep​Seek 模型嗎？

不是。它是中國電信的模型，來自星辰 AGI 實驗室。與 DeepSeek 的關聯是架構性的：它沿用了 DeepSeek-V2/V3 主幹，以及 DeepSeek 在 V4 中提出並推出的 mHC 殘差方案。採用他人的架構，並不等同於這兩個專案彼此相關。

接下來要看什麼

這些 PR 仍然提供了一份具體的檢查清單，而 9 月 16 日的那兩份 PR 又為它增加了兩個項目。第一，權重：每位作者都說過他們的工作要等 Hugging Face，因此公開儲存庫出現就是最關鍵的事件——而 SGLang PR 現在給了你確切要盯的路徑：XingChen-AGI/Xing4.0-29B-A4B，而它目前對任何人都無法解析。第二，PR 本身：vLLM 的那份需要確認 mHC 偏差公式、加入 registry 測試項目，並讓它的 CI 變綠；SGLang 的 #39793 需要修好它三個紅色執行，並讓十位被請求的審查者簽核，而較舊的 #37228 仍需要它的測試項目、它的 MTP 加速基準測試，以及一個不受阻的 CI。第三，也是本週新增的：SGLang 是否會為了 #39793 而關閉 #37228，就像 vLLM 一向在重新提交前關閉前身那樣。同一個未發布模型有兩個活躍整合，是沒有人會長期維持的狀態；而哪一個能存活下來，多少說明了這件事實際上有多接近。第四，數字：已發布的 checkpoint 是否符合 29B-A4B 形狀、64 專家 MoE，以及設定檔和 PR 描述現在所宣稱的 262,144 token 上下文。第五，第三個 vLLM PR 是否能比它兩個前身存活更久；那兩個前身在被關閉且未合併之前，分別撐了 21 天和 11 天。還要留意推理解析器是否在描述一個獨立的 Thinking 變體，就像 TeleChat3 所推出的一樣。

在那其中一件事發生之前，就把這個模型當作它實際的樣子來看待：一份來自一家嚴肅實驗室、規格完善的計畫，當場被發現正在準備其服務基礎設施——如今同時出現在兩大主要開源服務堆疊中，使用著兩者都已採用的名稱，以及一個只有它自己的 pull request 才表明的規模。光是架構就讓它值得追蹤：它是繼 DeepSeek 自身之後，mHC 的第二次重大採用，且出自一家上一代就已經是以國產晶片訓練的細粒度 MoE 的實驗室。當權重釋出時，它在 vLLM 或 SGLang 上能不能執行，將不再是問題。兩個堆疊都已用三種不同名稱，把程式碼寫了三遍。