寒武紀所稱的「Day 0」適配，核心是一項軟體整合與可部署性成果，而不只是模型權重一發布就能被讀取。該公司表示，DeepSeek-V4.1-Flash 在 checkpoint 發布當日，便可透過開源推理框架 vLLM 在寒武紀加速器上運行；底層結合 NeuWare 執行階段、Torch-MLU-Ops 與最佳化的 BangC 核心。13

對叢集營運者來說，權重可取得並不等於能立即上線。要把大型模型真正納入服務，還必須有可用的加速器執行階段、框架算子、分散式執行能力，以及針對運算瓶頸的高效率實作。

三層軟體整合：從執行階段到核心

寒武紀公布的適配路徑可概括為三層：

• NeuWare：為寒武紀 MLU 加速器提供軟體執行階段。
• Torch-MLU-Ops：提供面向 MLU 的算子支援；相關報導指出，其用於支援模型中的 Engram 與 Compressor 結構。9
• BangC 核心：直接針對 MLU 架構處理效能關鍵運算。寒武紀將 BangC 定位為可撰寫高效能 MLU 程式的異質平行程式語言。18

這種分層做法的意義在於：vLLM 的服務流程能使用加速器專屬後端，而不必變成客戶需自行維護的私有、一次性服務程式。寒武紀也表示，其 vLLM 最佳化涵蓋混合／低位元精度推理、平行化最佳化、大規模專家平行，以及 Prefill 與 Decode 分離部署。18

為何 DeepSeek-V4.1-Flash 是棘手的服務目標？

DeepSeek-V4.1-Flash 是一款原生支援文字與影像的多模態混合專家模型（MoE），具有 5,520 億個骨幹參數，另有 1,960 億個 Engram 記憶參數，支援最長 100 萬 token 的上下文。58

實務上，總參數量與每個 token 實際啟用的參數量必須分開看待。DeepSeek 表示，模型在處理提示詞的 Prefill 階段，每個 token 約啟用 80 億參數；在輸出生成的 Decode 階段，則約啟用 160 億參數。8 這種不對稱設計，對輸入量很大的工作負載可能降低運算量；不過真實服務成本仍取決於權重精度、批次大小、通訊、記憶體容量及實際請求組合。

40 層 Causal Encoder–Decoder 架構

模型採用 40 層的因果式編碼器—解碼器（Causal Encoder–Decoder，CED）架構：前 20 層為因果編碼器，後 20 層為解碼器。解碼器的全域 KV 狀態並非由每一層自行獨立產生，而是從編碼器最終隱藏狀態投影而來。58

這正是其記憶體設計的關鍵。長上下文推理常受限於 KV 快取，也就是模型在持續生成時，為回看先前 token 所保留的狀態。

每個 token 890 bytes：KV 快取壓縮的意義

DeepSeek 指出，透過 Compressed Sparse Attention 2（CSA2）的跨層 KV 快取重用，加上 FP4 KV 快取，可將常駐於高頻寬記憶體（HBM）的全域 KV 快取降至 每個 token 890 bytes，約為 DeepSeek-V4-Flash 對應數值的 四分之一。78

其技術資料亦稱，藉由 SWA Bounded Replay，儲存在 SSD 或主機記憶體中的持久化 KV 快取可降至 V4-Flash 的約 八分之一。7

對服務營運者而言，這代表長上下文與多模態請求的資源瓶頸可能有所轉移：單一請求保留的 KV 狀態減少，便可能為更多並行工作階段釋出記憶體空間。不過，這些數字是 DeepSeek 公布的模型設計數據，並不是對寒武紀叢集所做的獨立端到端基準測試；不能據此推論所有部署都會有特定的吞吐量、延遲、準確率、可用性或成本表現。

服務端最佳化如何配合？

寒武紀的公開軟體資料列出多項與大型 MoE 模型 vLLM 服務有關的技術。18

• 混合精度與低位元推理：可降低權重、活化值的儲存需求與記憶體資料傳輸量。
• 平行化最佳化與大規模專家平行：讓模型計算與路由至不同專家的工作可分攤到多個加速器。
• 通訊與運算重疊：在集體通訊或專家路由資料傳輸期間，盡可能讓裝置持續執行運算。
• Prefill／Decode 分離部署：將提示詞處理與逐 token 生成拆分，分別配置與調校資源。

這些技術彼此互補。Prefill 往往偏重提示詞處理與頻寬，Decode 則是反覆生成、對延遲更敏感；MoE 路由還會增加跨裝置協調的成本。目標是提升並發時的資源利用率與服務可預期性，而非只追求單一理論 FLOPS 數字。

目前公開材料未提供 DeepSeek-V4.1-Flash 在寒武紀硬體上的可重現吞吐量、延遲、模型品質、叢集拓撲或服務可用性測量。因此，「可供生產部署」較適合理解為已有可用、受支援的部署路徑；在做容量規畫或 SLA 承諾前，營運團隊仍應依自身模型版本、精度、上下文長度、批次與叢集配置完成驗證。

加入 PyTorch Foundation 代表什麼？

PyTorch Foundation 在 2026 年 9 月 8 日宣布，寒武紀加入為白金會員。49 Foundation 另指出，寒武紀曾與 vLLM 社群合作，為包括 DeepSeek-V4 與 GLM-5 在內的開源模型提供 Day 0 支援。57

其重要性在於生態系對齊。當加速器支援可透過 PyTorch、vLLM 等廣泛使用的公開框架與服務層取得，而不是要求使用者維護另一套廠商專屬堆疊，其實用價值會更高。會員資格本身不保證每個模型或功能都已上游支援，但它強化了寒武紀對 PyTorch 與 vLLM 相容性的既定方向。

其他模型家族的支援範圍

寒武紀軟體資料列出 DeepSeek V3／V3.1、Qwen2.5、Qwen3、Qwen3-Next、GLM-4.5、Qwen3-VL、Flux、Wan 2.1／2.2 與 Hunyuan-Video 等模型相關工作。18

但該資料混合了訓練支援與較廣泛的軟體最佳化，不能據此認定每一個家族都具備與 DeepSeek-V4.1-Flash 相同的 Day 0、正式 vLLM 推理支援狀態。較精確的結論是：寒武紀已在多個中國模型家族建立軟體支援足跡；至於每次發布可用的推理功能、精度、多模態覆蓋與 Day 0 狀態，仍須逐一確認。

為什麼發布當天可用很重要？

對叢集營運者來說，同日相容可縮短「模型發布」到「在既有基礎設施受控評估」之間的時間。公開的 vLLM 路徑，也讓團隊可基於熟悉的服務介面進行容量規畫、流量路由、可觀測性、量化評估與整合測試，而非從私有分支重新建立流程。

DeepSeek-V4.1-Flash 的案例尤其值得注意，因為其公布的快取壓縮直接瞄準長上下文服務的兩大壓力點：活躍工作階段對 HBM 的需求，以及快取重用所需的 SSD 或主機記憶體容量。78

整體來看，一項 Day 0 宣告並不能證明所有場景下的生產效能；真正重要的是，若執行階段、框架算子、核心、分散式執行與服務工具能形成可重複的支援鏈，模型加速器的適配便能更接近模型發布時間。隨著未來開源模型變得更大、更稀疏且更多模態，這套能力將比單次移植更具價值。

寒武紀所稱的「Day 0」適配，核心是一項軟體整合與可部署性成果，而不只是模型權重一發布就能被讀取。該公司表示，DeepSeek-V4.1-Flash 在 checkpoint 發布當日，便可透過開源推理框架 vLLM 在寒武紀加速器上運行；底層結合 NeuWare 執行階段、Torch-MLU-Ops 與最佳化的 BangC 核心。13

對叢集營運者來說，權重可取得並不等於能立即上線。要把大型模型真正納入服務，還必須有可用的加速器執行階段、框架算子、分散式執行能力，以及針對運算瓶頸的高效率實作。

三層軟體整合：從執行階段到核心

寒武紀公布的適配路徑可概括為三層：

• NeuWare：為寒武紀 MLU 加速器提供軟體執行階段。
• Torch-MLU-Ops：提供面向 MLU 的算子支援；相關報導指出，其用於支援模型中的 Engram 與 Compressor 結構。9
• BangC 核心：直接針對 MLU 架構處理效能關鍵運算。寒武紀將 BangC 定位為可撰寫高效能 MLU 程式的異質平行程式語言。18

這種分層做法的意義在於：vLLM 的服務流程能使用加速器專屬後端，而不必變成客戶需自行維護的私有、一次性服務程式。寒武紀也表示，其 vLLM 最佳化涵蓋混合／低位元精度推理、平行化最佳化、大規模專家平行，以及 Prefill 與 Decode 分離部署。18

為何 DeepSeek-V4.1-Flash 是棘手的服務目標？

DeepSeek-V4.1-Flash 是一款原生支援文字與影像的多模態混合專家模型（MoE），具有 5,520 億個骨幹參數，另有 1,960 億個 Engram 記憶參數，支援最長 100 萬 token 的上下文。58

實務上，總參數量與每個 token 實際啟用的參數量必須分開看待。DeepSeek 表示，模型在處理提示詞的 Prefill 階段，每個 token 約啟用 80 億參數；在輸出生成的 Decode 階段，則約啟用 160 億參數。8 這種不對稱設計，對輸入量很大的工作負載可能降低運算量；不過真實服務成本仍取決於權重精度、批次大小、通訊、記憶體容量及實際請求組合。

40 層 Causal Encoder–Decoder 架構

模型採用 40 層的因果式編碼器—解碼器（Causal Encoder–Decoder，CED）架構：前 20 層為因果編碼器，後 20 層為解碼器。解碼器的全域 KV 狀態並非由每一層自行獨立產生，而是從編碼器最終隱藏狀態投影而來。58

這正是其記憶體設計的關鍵。長上下文推理常受限於 KV 快取，也就是模型在持續生成時，為回看先前 token 所保留的狀態。

每個 token 890 bytes：KV 快取壓縮的意義

DeepSeek 指出，透過 Compressed Sparse Attention 2（CSA2）的跨層 KV 快取重用，加上 FP4 KV 快取，可將常駐於高頻寬記憶體（HBM）的全域 KV 快取降至 每個 token 890 bytes，約為 DeepSeek-V4-Flash 對應數值的 四分之一。78

其技術資料亦稱，藉由 SWA Bounded Replay，儲存在 SSD 或主機記憶體中的持久化 KV 快取可降至 V4-Flash 的約 八分之一。7

對服務營運者而言，這代表長上下文與多模態請求的資源瓶頸可能有所轉移：單一請求保留的 KV 狀態減少，便可能為更多並行工作階段釋出記憶體空間。不過，這些數字是 DeepSeek 公布的模型設計數據，並不是對寒武紀叢集所做的獨立端到端基準測試；不能據此推論所有部署都會有特定的吞吐量、延遲、準確率、可用性或成本表現。

服務端最佳化如何配合？

寒武紀的公開軟體資料列出多項與大型 MoE 模型 vLLM 服務有關的技術。18

• 混合精度與低位元推理：可降低權重、活化值的儲存需求與記憶體資料傳輸量。
• 平行化最佳化與大規模專家平行：讓模型計算與路由至不同專家的工作可分攤到多個加速器。
• 通訊與運算重疊：在集體通訊或專家路由資料傳輸期間，盡可能讓裝置持續執行運算。
• Prefill／Decode 分離部署：將提示詞處理與逐 token 生成拆分，分別配置與調校資源。

這些技術彼此互補。Prefill 往往偏重提示詞處理與頻寬，Decode 則是反覆生成、對延遲更敏感；MoE 路由還會增加跨裝置協調的成本。目標是提升並發時的資源利用率與服務可預期性，而非只追求單一理論 FLOPS 數字。

目前公開材料未提供 DeepSeek-V4.1-Flash 在寒武紀硬體上的可重現吞吐量、延遲、模型品質、叢集拓撲或服務可用性測量。因此，「可供生產部署」較適合理解為已有可用、受支援的部署路徑；在做容量規畫或 SLA 承諾前，營運團隊仍應依自身模型版本、精度、上下文長度、批次與叢集配置完成驗證。

加入 PyTorch Foundation 代表什麼？

PyTorch Foundation 在 2026 年 9 月 8 日宣布，寒武紀加入為白金會員。49 Foundation 另指出，寒武紀曾與 vLLM 社群合作，為包括 DeepSeek-V4 與 GLM-5 在內的開源模型提供 Day 0 支援。57

其重要性在於生態系對齊。當加速器支援可透過 PyTorch、vLLM 等廣泛使用的公開框架與服務層取得，而不是要求使用者維護另一套廠商專屬堆疊，其實用價值會更高。會員資格本身不保證每個模型或功能都已上游支援，但它強化了寒武紀對 PyTorch 與 vLLM 相容性的既定方向。

其他模型家族的支援範圍

寒武紀軟體資料列出 DeepSeek V3／V3.1、Qwen2.5、Qwen3、Qwen3-Next、GLM-4.5、Qwen3-VL、Flux、Wan 2.1／2.2 與 Hunyuan-Video 等模型相關工作。18

但該資料混合了訓練支援與較廣泛的軟體最佳化，不能據此認定每一個家族都具備與 DeepSeek-V4.1-Flash 相同的 Day 0、正式 vLLM 推理支援狀態。較精確的結論是：寒武紀已在多個中國模型家族建立軟體支援足跡；至於每次發布可用的推理功能、精度、多模態覆蓋與 Day 0 狀態，仍須逐一確認。

為什麼發布當天可用很重要？

對叢集營運者來說，同日相容可縮短「模型發布」到「在既有基礎設施受控評估」之間的時間。公開的 vLLM 路徑，也讓團隊可基於熟悉的服務介面進行容量規畫、流量路由、可觀測性、量化評估與整合測試，而非從私有分支重新建立流程。

DeepSeek-V4.1-Flash 的案例尤其值得注意，因為其公布的快取壓縮直接瞄準長上下文服務的兩大壓力點：活躍工作階段對 HBM 的需求，以及快取重用所需的 SSD 或主機記憶體容量。78

整體來看，一項 Day 0 宣告並不能證明所有場景下的生產效能；真正重要的是，若執行階段、框架算子、核心、分散式執行與服務工具能形成可重複的支援鏈，模型加速器的適配便能更接近模型發布時間。隨著未來開源模型變得更大、更稀疏且更多模態，這套能力將比單次移植更具價值。