DeepSeek開源周過後，國產晶片廠在焦慮中狂歡

作者｜冬梅、Tina

採訪嘉賓｜摩爾線程技術團隊、清程極智技術團隊

DeepSeek 上週一口氣開源了五個開源庫，這些專案看似技術名詞堆砌，但實際上都是在解決 AI 計算中的關鍵問題，尤其是針對英偉達 GPU 的最佳化。

英偉達的 CUDA 生態是其最大的護城河，幾乎所有 AI 開發者都依賴 CUDA 來最佳化 GPU 計算。然而，CUDA 的最佳化是通用的，不一定適合所有場景，尤其是國產晶片和特定 AI 任務的需求。

DeepSeek 的五個開源專案，從計算效率、通訊最佳化、矩陣計算、任務排程到負載平衡，覆蓋了 AI 計算中的多個關鍵環節。那這些對於開發者和國產晶片廠有什麼意義？

1 DeepSeek 放出的開源大招，相當於在 CUDA 上架起一座橋

2 月 24 日，DeepSeek 釋出了顯示卡的“加速器”FlashMLA，這是一個專門最佳化 GPU 計算效率的工具，特別適合處理不同長度的資料（比如長短不一的文字）。

它能讓 GPU 在處理 AI 任務時更“聰明”，動態分配算力，避免資源浪費。比如翻譯一段長文字和一段短文字時，它能根據任務需求調整算力，讓速度更快、成本更低。

英偉達的 CUDA 生態雖然強大，但它的最佳化是通用的，不一定適合所有場景。FlashMLA 透過針對性地最佳化 GPU 計算效率，相當於在 CUDA 的基礎上“開了一條快車道”，讓國產晶片和開發者能更高效地利用英偉達 GPU。

2 月 25 日，DeepSeek 亮相了大模型訓練的“通訊管家”DeepEP，這是一個專門用於提升大模型訓練效率的通訊庫，特別適合 MoE（混合專家）模型。

當多個 AI 模型協同工作時，DeepEP 能高效協調它們之間的通訊，減少延遲和資源消耗。它還支援低精度計算（如 FP8），進一步節省算力。

大模型訓練需要高效的通訊和資源排程，而 CUDA 在這方面的最佳化有限。DeepEP 透過最佳化通訊和低精度計算，讓國產晶片和開發者能更高效地訓練大模型。

2 月 26 日，我們迎來了矩陣計算的“省電小能手”DeepGEMM。眾所周知，矩陣乘法是 AI 計算的基石，這款最佳化矩陣乘法的工具透過低精度計算（FP8）提升速度，再用 CUDA 技術修正誤差，既快又準。DeepGEMM 的先進性在於，其程式碼只有 300 行，安裝簡單，適合快速部署。

2 月 27 日，DeepSeek 開源了兩個工具和一個數據集：DualPipe、EPLB 以及來自訓練和推理框架的分析資料，梁文鋒本人也參與了兩個專案的開發。

DualPipe 可以算得上是流水線並行的“排程大師”，當多個任務步驟速度不一致時，它能雙向排程，減少空閒時間，讓任務更流暢地完成。

2 月 28 日，DeepSeek 開源了 GPU 負載的“平衡大師”EPLB，當某些 AI 模型任務過重時，它會複製任務到空閒顯示卡，避免“忙的忙死，閒的閒死”。

可以說，DeepSeek 透過這一系列開源專案，證明了他們有能力深入剖解英偉達 CUDA 並對其進行調優，他們針對具體問題給出的解決方案讓國產晶片廠和 AI 開發者能夠更高效地利用 GPU 資源。

2 暫時繞不過 CUDA，但也有其他解決方案

相比於此次開源周帶來的震撼，國產晶片廠早在 DeepSeek R1 釋出後已經進行過一場酣暢淋漓的狂歡。

DeepSeek R1 釋出幾天後，似乎所有國產晶片廠商都陸續官宣已完成 DeepSeek 適配，算力晶片廠商華為昇騰、沐曦、天數智芯、摩爾線程、海光資訊、壁仞科技、燧原科技、崑崙芯等相繼宣佈適配或上架 DeepSeek 模型服務，有些廠商部署的是蒸餾版模型，而華為昇騰、寒武紀、摩爾線程以及崑崙芯都在公開場合表示其完成滿血版 DeepSeek 模型的適配。

那麼，滿血版和蒸餾版模型之間的區別是什麼？

滿血版模型與蒸餾版模型從模型結構上就是不同的，滿血版是包含了 256 個專家的 MoE 混合專家模型，目前流行的蒸餾版一般都是稠密模型，基礎模型一般是 Llama 或 Qwen。

滿血版模型通常需要更強的硬體支援比如更多視訊記憶體和更復雜的推理方案，比如 prefill 和 decode 分離、推理叢集排程等。相比之下，蒸餾版模型透過知識蒸餾技術將大模型的能力遷移到較小的模型上，降低了對硬體的要求，但同時也犧牲了一定的效能。

適配滿血版模型的關鍵技術包括混合精度計算、多機互聯、以及對 MoE（混合專家系統）的支援。MoE 模型涉及多個專家，每次推理只啟用部分引數，與傳統的 Transformer 模型部署有很大不同，這裡面可最佳化空間很大。

除了上述關鍵技術外，許多國產 AI 晶片廠商在部署滿血版模型時還有一個硬傷——無法原生支援 FP8 資料型別。

DeepSeek 模型採用了 FP8 混合精度訓練，英偉達從 H100 開始，AMD MI325X 都原生支援 FP8。那是否意味著，不原生支援 FP8 就無法適配滿血版模型？

在採訪中有業內人士表示：“原生支援 FP8 資料型別確實能夠更好的支援滿血版 DeepSeek 大模型，但不支援 FP8 的晶片也有解決方案，它們可以透過運算元最佳化、引數量化等技術手段來彌補這一差距。例如，透過使用 FP16 或 INT8 進行推理，但這樣會增加儲存需求或降低精度。

國產晶片 / 伺服器如果要適配滿血版 DeepSeek 模型，簡單來說就是要大容量視訊記憶體、多機互聯、混合精度和軟體相容。

首先，DeepSeek 引數量高達 671B，FP16 的精度下，單純的引數量就高達 1.3T，而低精度量化雖然可以降低視訊記憶體要求，但也帶來了模型精度損失。

其次，需要具備強大的多機互聯能力，以最佳化推理時伺服器的通訊效率，因為不降低精度的滿血版模型往往需要數臺多卡伺服器協同執行。此外，如果要最大化發揮 DeepSeek 模型技術優勢，尤其是要參考 DeepSeek 模型架構如何進行基礎模型訓練，因此晶片對 FP8 的原生支援是必不可少的，單純的推理場景 FP8 支援也有重大價值。晶片 / 伺服器還需要支援 MoE 訓練 / 推理軟體。

以摩爾線程為例，目前摩爾線程已經率先支援包括 FP8 在內的混合精度模型訓練。摩爾線程全功能 GPU，原生支援 FP8 資料精度，支援 MTLink 高速互聯技術，可以為 DeepSeek 滿血版推理以及類 DeepSeek 架構模型訓練提供優質的國產算力。

DeepSeek 的火爆為國產晶片注入了一劑強心劑。國產晶片可以跑通 DeepSeek，是不是證明我們已經可以繞過 CUDA 架構解決相容性問題？答案是：我們正在接近這個目標，但尚未完全實現。

在摩爾線程看來，DeepSeek 繞過 CUDA 是誤讀，其技術實現仍深度依賴 NVIDIA 生態的核心元件（PTX）。即使框架層試圖抽象化 CUDA API，只要底層執行在 NVIDIA GPU 上，就不可避免與 CUDA 工具鏈和硬體驅動繫結。這種依賴關係反映了當前 AI 算力領域“NVIDIA 主導，開源生態依附”的現實格局。DeepSeek 的實踐更多是在 CUDA 生態內最佳化，而非真正“繞過”它。

CUDA 生態壁壘的核心在於硬體與軟體的深度耦合，以及由此形成的強大生態繫結效應。英偉達的 GPU 架構透過 CUDA 進行了深度最佳化，能夠充分發揮硬體的平行計算能力。同時，CUDA 生態涵蓋了從程式語言、API 到最佳化庫的完整工具鏈，並與主流深度學習框架深度整合，形成了強大的開發者社群和應用生態。

摩爾線程表示：“如果希望在全球市場上挑戰英偉達的 CUDA 生態，國產 GPU 廠商需要從多個方面尋找突破口。一是構建自主可控的軟體生態是關鍵，其次，相容與創新並行的策略也至關重要。此外，抓住新技術的機遇也是一個重要方向，比如 DeepSeek 的爆火，它的核心突破在於演算法最佳化和計算效率的提升，這種低算力需求模型對國產晶片的發展是一個重要機遇。再有，透過開源和合作，吸引開發者參與，加速技術迭代，以及硬體層面的最佳化也非常重要。”

不得不承認的事實是，DeepSeek 等企業的技術迭代短期內難以完全脫離 CUDA 生態。但長期來看，隨著國產替代的推進、演算法最佳化能力的提升，以及行業對供應鏈安全的重視，將逐步降低單一依賴風險。這一過程需要時間和技術積累，但已是不可逆的趨勢。未來的算力底座更可能呈現“多元共存”的形態，而非某一廠商的絕對主導。

3 國產晶片廠，在焦慮中狂歡

多年來，在全球 AI 算力市場，英偉達的 CUDA 生態牢牢把持著一切，包括其他廠商只能眼巴巴看著英偉達市值一再創新高，那個愛穿皮夾克的創始人黃仁勳“躺在印鈔機上數錢”。但現在，DeepSeek 就像一條“鯰魚”，給國產晶片廠商帶來了“翻身”的希望。

DeepSeek 在技術上的突破，如 GRPO、MLA、FP8 訓練等，共同構建了其深而寬的技術護城河。

以 FP8 為例，大模型不斷演進，低精度計算成為 GPU 硬體的發展趨勢。從最初的 FP32，到目前主流的 FP16、BF16，再到如今備受關注的 FP8，低精度計算不僅能顯著提升計算速度和能效，還能減少記憶體佔用，非常符合大模型時代對 GPU 硬體的要求。

採用 FP8 訓練已逐漸成為大模型訓練的一個重要研究方向。相較於主流的 FP16 和 BF16，FP8 在大模型訓練和推理中展現出顯著優勢：首先，FP8 格式在相同硬體加速平臺上的峰值效能顯著超越 FP16 和 BF16，理論估計可提供兩倍的效能提升。其次，得益於架構設計上的特殊最佳化，FP8 在實現 2 倍計算效能的同時，功耗更低。此外，FP8 的數值位數比 FP16 和 BF16 更少，這使得在一些記憶體佔用較大的操作中，可以有效降低記憶體佔用消耗。同時，傳輸資料量減半，從而顯著降低通訊開銷。

摩爾線程 AI 技術專家觀察到 ，DeepSeek 團隊在實踐中，儘量剋制地去使用 FP8，僅在模型的 MLP 部分使用了 FP8 GEMM。

不過在使用時對啟用和權重做了細緻的設計。考慮到啟用和權重的數值分佈區別，對其分別採用了 1×128 和 128×128 大小的 block-wise 量化，在儘可能保證訓練精度的情況下利用到 FP8 帶來的計算和傳輸優勢，這樣的設計得以讓其 671B 的模型也能夠保持穩定訓練。

多層感知機（MLP）：MLP 是一種前饋人工神經網路模型，它由多個層次的節點（神經元）組成，每個節點都與其下一層的所有節點相連。 在大語言模型中，MLP 通常用於處理和轉換資料，是模型中重要的組成部分。MLP 在大模型中，往往是計算量非常大的模組。

此外，算力資源和人才儲備也是 DeepSeek 成功的關鍵因素。DeepSeek 透過分散式計算框架，將訓練成本大幅降低，實現了算力的民主化。這些因素共同構成了 DeepSeek 的核心競爭力，使其在 AI 領域具有難以複製的優勢。

遍地是機遇

DeepSeek 的成功，也證明了國產晶片即使“底子”差一點，也能透過軟體最佳化“彎道超車”。

摩爾線程表示，DeepSeek 的核心突破在於演算法最佳化和計算效率的提升，這種低算力需求模型對國產晶片的發展是一個重要機遇。

首先，DeepSeek 的成功表明，透過模型壓縮、稀疏計算、混合精度訓練等技術手段降低算力需求，可以在一定程度上彌補硬體效能的不足，為國內晶片提供了軟硬體協同設計的新思路，證明了在硬體效能短期內難以趕超的情況下，透過軟體層面的創新仍可提升整體計算效能。

其次，DeepSeek 在混合精度訓練方面的成功，展示了低精度計算在 AI 訓練中的潛力。國內晶片廠商可以借鑑這種模式，最佳化晶片的計算單元，支援更靈活的精度配置。

與此同時，DeepSeek 的開源模式為國產晶片廠商提供了與軟體開發者合作的機會。透過與 DeepSeek 等開源模型的合作，國內晶片廠商可以更好地理解 AI 應用的需求，進行針對性最佳化，國產模型 + 國產晶片可以形成完整的 AI 閉環，加速國產 AI 生態發展程序。

另外，DeepSeek 大幅降低 AI 成本，讓 AI 更加普及，反過來又會提升對算力規模的需求。整體來看，國產晶片透過聚焦能效比、本地化服務和政策紅利，有望在邊緣和端側市場、行業 AI 等場景實現突圍。

競爭加劇也是必然

DeepSeek 的出現，帶來的當然不僅僅是遍地機遇，它也一定將會加速國產 AI 晶片領域的競爭。這種競爭不僅體現在技術突破和產品效能上，還體現在生態構建、市場落地和成本控制等多個維度。

DeepSeek 對競爭的影響主要是幾個方面：

加速技術迭代：DeepSeek 等 AI 技術的應用場景和需求不斷擴充套件，倒逼 AI 晶片企業在算力、能效比、相容性等方面快速迭代，技術落後的企業將面臨更大的淘汰壓力。
推動生態合作：DeepSeek 的普及可能會促使 AI 晶片企業更加註重生態建設，包括與演算法公司、雲服務商、終端廠商的深度合作，形成更緊密的產業鏈協同。
重新定義賽點：DeepSeek 的出現可能會將競爭推向一個新的高度，企業不僅需要在硬體效能上領先，還需要在軟體棧、開發工具、應用場景支援等方面具備綜合競爭力。

值得注意的是，這種競爭並非一味打價格戰，瘋狂內卷，未來算力競爭的核心在於價效比，而價效比的本質是“場景定義算力”。國產 GPU 廠商需擺脫單純引數對標的思維，轉而圍繞客戶真實需求定義晶片規格。

4 ⼤模型算⼒的未來趨勢

那麼未來，大模型算力的發展趨勢將是怎樣的？

清程極智判斷，未來⼤模型的算⼒趨勢將是：推理側算力需求大幅增長、算力需求多樣化，而企業側追求算力成本最最佳化。

隨著 DeepSeek 等開源大模型的推出，越來越多的企業開始嘗試將大模型與自身業務場景結合，推動了大模型推理側算力需求的顯著增長。此外，大模型的發展呈現出模型規模擴大、演算法和模型結構複雜化的趨勢。例如，DeepSeek 採用的 MoE（混合專家）架構，進一步增加了推理環節的計算需求。

算力需求的增長必然帶來企業成本的上升，因此，如何節省算力、壓縮成本成為企業關注的重點。清程極智表示，企業更傾向於採用價效比最高的軟硬體一體化解決方案，以滿足自身業務場景的需求。

清程極智還指出，未來算力需求將呈現多樣化趨勢，無論是小規模還是大規模算力需求都將並存。特別是中小企業的快速發展，大量小規模算力的大模型部署和微調需求將越來越多。

宣告：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

今日好文推薦

騰訊元寶連夜修改使用者協議！“霸王”條款衝上熱榜，你的內容到底誰說了算？

“抄襲”程式碼，到底是 CTO 的鍋還是創始人的鍋？！這事兒已經撕3天了

分散式系統程式設計已停滯？！