大家好，這裡是最佳夥伴，我是大飛。
9月30日，國慶日前一天，DeepSeek一次性更新了六個程式碼庫：Ldeepj、Deep、Tirecos、FlashM和DeepSelect，所有這些程式碼庫都增加了對華為Ascend的支援。乍一看，這似乎是一個普通的開源專案提交。然而，在中美算力競爭的背景下，這更像是一個訊號。
華為與DeepSeek的共生關係
10月21日，SemiAnalysis發表了一篇題為「華為與DeepSeek之間的共生關係」的長文，他們的評估很直接：任何一方都無法獨自完成這件事。
簡而言之，雖然華為擁有盤古，但它缺乏前沿實驗室來證明其晶片可以訓練模型並進行推理；同時，DeepSeek擁有模型，但卻買不起所需的運算能力。一個缺乏證據，一個缺乏卡片。華為提供硬體和原生軟體棧，而DeepSeek提供工作負載和內部工程技術，使該硬體真正服務於其模型。
9月30日發布的儲存庫是此次交流的成果，交流介面則著重於內核程式語言。文章還提供了一個時間表，表明到2028年，甚至最早到2027年，DeepSeek很可能主要在華為的硬體和軟體堆疊上運行。技術已經成熟，但另一個推動因素是來自內部和外部的壓力，需要建立一個完全在地化的生態系統。
今天，我們就來談談這個話題。
昇騰950晶片架構與內部測繪
首先，我們來看看晶片。文章開頭提到了一個容易被忽略的細節：Ascend 950和950DT已經出現了許多變體，包括不同的核心數、HBM堆疊高度和快取大小。有些變體可能只是為了虛擬化或純粹為了測試目的。為什麼會有這麼多產品層級？由於晶片缺陷和性能參數未能達到標準，只有一部分晶片和HBM堆疊符合目標規格。因此，華為的做法是將運算能力和記憶體能力分開，將它們分成多個SKU，並將較弱的記憶體與較弱的運算能力配對。NVIDIA的分級邏輯不同，因為它主要關注計算組件的分級。這其實並不是一種新做法。在910B時代，有910B1、B2、B3和B4等變體。
這次基準測試使用的是Ascend 950 Pro 9579，它有28個C核心單元和128GB的HBM。接下來是一系列非常有趣的測試。
第一種是追逐指示物。每次從讀取16KB整數載入開始，延遲在18個執行緒區塊內保持穩定在134奈秒左右。當區塊數增加到56時，時間上升到182奈秒；當區塊數增加到64時，時間直接躍升到391奈秒。這一躍升表明，在超過56個向量核心後，任務進入第二波執行階段。
接下來，他們分別在每個核心和向量核心上執行標量指標追蹤探測，記錄在遍歷128MB鏈時相同位址的載入延遲。每個網格的顏色代表該位址處兩個核心之間的延遲分佈差異。結果自動聚集成兩組，剛好對應兩顆骰子。
接下來，他們讓一個核心運行記憶體流量或暫存器任務，同時測量另一個向量核心的指標追蹤速度減慢了多少。由此可見，他們能夠推斷出哪些子系統共享資源，從而形成像024和135這樣的分區。透過啟動立方體和向量核心，還可以確定每個子系統中有一個立方體和兩個向量。
當然，圖中所述的物理佈局只是一個示意圖。簡而言之，這種測試方法利用時序來繪製晶片的內部結構，而無需製造商提供的架構圖。
該晶片還隱藏著一個CPU；根據MIDR編號判斷，每個950都配備了數量不等的LX816 AC64ELFU核心。這些核心很可能與709000S9010中的核心相同，因為指令集顯示了SVE、BF16、i8和mMM特性。
此SoC配置了7個ASPU，其中6個可見，5個實際上正在運作。他們的目的不僅是控制設備；它們還可以處理一些CPU運算子。例如，對於KV元數據，ASPU可用於裝置到主機傳輸開銷占主導地位且運算本身非常短的任務。具體來說，對於DSA（即DeepSeek注意力調度），有一個很小的調度步驟，它會讀取當前序列長度並將索引工作委託給加速器核心。然後，立方體和向量核心計算int8指數得分。選擇前2048個指數。在vLLM實作中，規劃、索引、選擇和聚合步驟都在ASPU上運作。
文章也將此與在主機CPU上運行進行了比較，得出結論：ASPU的運算能力有限，只適合開銷較大的短任務，或者資料源自NPU並由NPU處理的任務。
效能實測：算力利用率與頻寬表現
接下來是效能。950PR定位於高密度推理。與性能更強大的同系列產品950DT相比，它的記憶體頻寬較低，核心數也較少。測試使用了Ascend原生的torch.matmul，最終選擇了ACL矩陣實現，而不是DeepSeek優化的核心。
他們從多個開源模型中選取了1,055個GEMM形狀。結果顯示，華為的最佳核心達到了理論性能上限的99.7%。這個數字值得注意。DeepSeek使用DeepGEMM實現了超過99%的利用率，DeepGEMM長期以來一直是行業標竿。現在我們看到這是唯一的出路，華為自己的工程師也實現了這一點。
優勢主要體現在運算密集型任務。對於低於Ascend Roofline拐點的形狀，中位數表現比率為41.5%，而H100為46.8%。然而，有一個細節需要說明：一些NVIDIA測試結果受到功率限制，並未達到最大SM時脈頻率。在700W的限制下，平均功耗在690W到698W之間，取樣SM時脈頻率在1335 MHz到1470 MHz之間，峰值頻率為1830 MHz。華為的功耗約為599W至600W，頻率為1500至1550 MHz，參考頻率為1650 MHz。因此，這種比較並非在完全相同的條件下進行的。
MXU獨特的設計可能是其高利用率的原因之一；它將矩陣運算元放入專用的L0A和L0B緩衝區，並將累加器放入L0C，從而允許資料移動、計算和結果處理重疊。它還將擴展的L0C與更靈活的平鋪和重用策略相結合。
然而，就絕對性能而言，950PR仍然落後，大致介於NVIDIA的A100和AMD的MI300X之間。
頻寬方面的結果更有意思。當每個緩衝區的訊息大小較小時，950 PR的有效頻寬和利用率超過H100。隨著訊息數量的增加，利用率與H100相匹配，儘管曲線有所下降；這是因為Ascend在這裡切換了複製方法，轉向了基於向量核心的張量內核，啟動開銷更高，因此隨著複製量略微增加，所需時間也會延長。當複製量變得非常大時，這種開銷就變得可以忽略不計，頻寬需求又會上升。
文章特別指出，高FLOPS使用率和高頻寬利用率並不一定能轉換為高MFU或MBU。使用FSDP時，您仍然需要處理集體通訊、保存檢查點和行動數據；這些任務很難完美地同時完成。它也重申，先前終端基準測試中的「單晶片」其實是一個社會建構的概念。多個晶片可以組合成一個更大的晶片；真正重要的是每瓦性能，或根據總擁有成本(TCO)計算出的性能。然而，對於電力相對便宜的中國來說，這個變數的權重有所不同。他們計劃在以後的文章中計算Ascend設備的基於總擁有成本(TCO)的性能。
軟體堆疊與編譯器調度
文章中有一句話我認為是整篇文章的核心：硬體提高了上限，但只有軟體才能讓你達到這個上限。華為的硬體可能落後五年多——這是與A100相比——但它的軟體卻處於領先地位。
從軟體方面來看，在DeepSeek更新的六個支援Ascend的儲存庫中，截至撰寫本文時，只有Triton真正可用。原因很實際：華為的CANN 9.2.0尚未發布，而DeepSeek需要此版本以及C++ 20編譯器。CANN 9.2.0 B2不提供此功能，HDK要到10月15日才會發布。其中一些程式碼庫在DeepSeek於2025年啟動開源週時僅支援Nvidia顯示卡。從測試結果來看，華為已經能夠很好地運作技術維運工具。
所謂的共生並不關注操作者本身，而是關注如何使應用程式的各個部分以及支援它們的工作更有效率且更易於重複使用。這種工程影響是雙向的；華為的架構已經改變了DeepSeek組織資料的方式。早期的FlashAttention KV快取將量化值及其縮放因子放置在不同的區域中。這在Nvidia上沒問題，但在Ascend上，檢索令牌需要分別傳輸值和縮放因子，從而導致額外的請求。新的實作方式將它們放在一起，減少了記憶體傳輸引擎發起的請求數量。晶片的儲存結構反過來又決定了軟體的快取格式。
接下來是Triton，Ascend 910後端並沒有單獨存放在華為的倉庫中，而是已經合併到了Triton的主倉庫中。它為Ascend的執行模型添加了原生編譯、調度同步和運行時整合。這相當於說，以前你必須自己費力地使用CANN來編寫Ascend內核，而現在Triton降低了這個門檻。但是，開發人員仍然需要考慮硬體；例如，選擇哪種計算方法，資料塊有多大，以及將資料放在哪裡——這些仍然需要由人來決定。
編譯器負責Cube核心、Vector核心和資料傳輸之間的大量協調工作。文章將其與Triton進行了比較，結果表明，在某些情況下，它可以與Triton相媲美，甚至超越Triton，最佳實現方式會根據規模而變化。但是請注意，這是一個沒有快取預熱的簡單基準測試，因此不要過度解讀它。
在後端，有一種稱為自動調度（AutoSchedule）的功能，它依靠資料依賴性和估計的執行時間來規劃哪些操作可以重疊，同時決定在片上記憶體限制內使用多少緩衝區，從而允許後續資料在當前資料區塊仍處理時開始載入。如果預設調度不合適，開發人員可以手動幹預。在950 Pro上，自動排程功能對於小規模作業尤其有用，可將單一操作員的執行時間減少高達40%。
編譯器也會透過插入必要的等待來處理同步，以確保運算子擁有所需的數據，同時刪除因其他依賴關係而變得不必要的冗餘等待。它還會檢查條件分支，確保不會僅僅因為程式碼中寫了某個操作就假定該操作已經完成，因為該分支可能從未執行過。以前由程式設計師負責的這部分工作，現在由編譯器負責處理。
通訊協同與專家調度
在通訊方面，華為和英偉達一樣，已經實現了大規模垂直擴展人工智慧系統的商業化，擴展節點叢集以連接多個機架上的加速器，從910上的CloudMesh 384到950叢集支援的水平擴展。在9月30日的發表會上，華為也公佈了EP16在950個DT超級節點上分發和收集的基準測試結果。
這裡有一個對比，突顯了工程成熟度：華為的發行版涉及三個順序執行的操作符，而PyTorch使用單一融合調用；此外，華為的POST階段包括測量中的接收完成和專家擴展工作，這不屬於GP300的結果，因此這兩個數字不能直接比較。
DeepAscent與DeepSpeed v2.5一致，共享相同的Python API，但底層實作已被Ascend HCL取代。這裡有個小插曲：2025年7月，華為生態系統團隊提議將DeepAscent移至DeepSpeed組織下。後來被DeepSpeed的一位維修者拒絕了，因此目前的專案是在DeepSpeed自己的組織下發布的。
底層將Cube和Vector的執行路徑分開，從而為重疊通訊和計算創造了機會。但重疊並非沒有代價；專家計算本身可能需要向量單元移動數據，而通訊會爭奪共享的記憶體頻寬。那麼，在不降低平行運算速度的前提下，可以隱藏多少通訊開銷呢？這就是一種平衡。
資源平衡問題並非DeepSeek獨有。華為Ascend C方案明確限制了向量單元的使用，為通訊工作流程留出了空間。因此，通訊應該透過專用CU還是Vector單元進行，取決於重疊的內容。
然而，僅僅擁有速度更快的個體操作員是不夠的；它們的資源需求必須能夠相互補充。DeepSeek的文檔指出，合併操作和通訊之間存在HBM資源爭用，華為計劃透過韌體改進來緩解這一問題。這就是協同設計在實踐中的樣子：模型暴露瓶頸，實現相應調整，平台調整優先順序以解決剩餘的未解決問題。
文章引用了DeepSeek五月投資者會議的記錄，並強調該記錄尚未得到核實。梁峰表示，中國和美國晶片及軟體生態系統之間的差距最終會消失，但目前存在兩個明顯的硬體劣勢：首先，需要四張華為加速卡才能達到一張英偉達加速卡的性能；其次，華為的硬體上市時間比競爭對手慢了大約兩年。四個月後，生態系差距縮小了。同一份記錄中提到T-Head幫助華為建構其生態系統。
DeepSeek-V4.1與推測性解碼實踐
然後是DeepSeek-V4.1與Flash共生關係的另一半：DeepSeek為華為提供了權重，使華為能夠在發布當天發布優化版本；V4和V4.1都是這樣產生的。
由於Ascend累加器的設計，注意力計算被迫採用不同的實現方式：L0C緩衝區無法就地重新縮放累加器輸出；相反，它必須將縮放後的結果傳回L0C，這需要進行單位矩陣乘法，成本非常高。DeepSeek的解決方案是將持續更新的輸出累加器保留在向量UB中，僅在需要重新縮放和累積時才將部分核心從L0C中轉移出來。相較之下，H100將累加器保存在暫存器中，而Blackwell支援在張量記憶體和暫存器之間進行載入/存儲，因此它們不受此限制。同一個注意力機制在三個晶片上需要三種不同的實作方式。
華為也發布了一份關於在32顆Ascend 910B晶片上部署DeepSeek-V4.1-Flash的效能報告，涵蓋了特定營運商及其主機進程。他們分析了V4 Pro類似的架構；許多組件都是相同的，例如使用ASPU或將某些層分佈在不同的流中。
執行順序如下：首先，40個目標模型層；然後是目標模型的LM頭部；接著是三個草稿模組；然後是草稿模型的LM頭部；最後，在Stream 19上運行五輪採樣操作，同時草稿模型在Stream 173上運行。來自V4Pro軌跡的V2MC融合內核（融合了計算和通訊）此次以V3的形式再次出現，這也是為什麼每步需要43次專家調度的原因。
然而，ASPU只發起了四項HCCL行動。這四個運算分別是目標模型和草稿模型詞彙表頭的HCOMGather和HCOMOutV。首先，收集隱藏狀態來執行LM頭的GEMM，然後草稿區塊的交換只需要執行一次。目標是為選秀位置產生基本邏輯值；後續的MoV頭使用採樣和嵌入反饋來建立令牌依賴關係，而無需為每個提案重新運行Transformer。每個步驟結束時的工作流程從MoE和注意力轉移到一系列小的頭部投影和採樣。
如前文所述，推測性解碼是無損的。它首先預測選秀結果，然後透過一次完整的正向傳球進行驗證。因此，重量裝載成本得以攤提。從解碼步驟圖中可以直接看出，與驗證步驟相比，草稿代幣產生速度快得多。
V4.1 Flash還有另一個身份：它是DeepSeek的首款採用InRAM的型號，儘管它的上市時間晚於阿里巴巴的Qwen和美團的基於LLaMA的型號。由於InRAM輸入是Token ID，因此可以一步完成資料檢索，並與第0層計算重疊。這意味著，與留在HBM中相比，卸載到DRAM不會導致效能下降，但卸載到PCIe 4.0 SSD會導致效能下降。
從穩態視窗的內核持續時間來看，流19佔據了該視窗的88.8%，但僅佔設備總時間的72.6%，因為它與其他流重疊。圖表中MixA和AI Vector Core部分的這些大塊區域，既有調度，也有合併，還有量化。透過MixA、Mix、AIC和AI Vector Core分別公開CE和向量路徑，每個事件都攜帶一個任務類型，因此時間追蹤按類型分類；這裡有一個陷阱：混合類型的活動工作實際上發生在單一實體單元之外。因此，儘管名稱是「混合的」，但你不能將此時間視為純粹的立方體或純粹的向量利用。
文章也進行了一階計算，假設UB吞吐量翻倍，而其他硬體保持不變，導致尾部效能提高1.32倍。此計算保持了所測量的流量重疊程度，並假設空閒時間保持不變。這是基於工作負載構成進行的推斷，而不是對新晶片的預測。畢竟，頻寬、依賴關係和調度都會影響最終結果。
營運商融合仍然是一個機會；其潛力在於生產者和消費者之間反覆出現的邊界，以及量化佔據了向量任務的很大一部分，而向量任務還必須處理融合通訊。
生態差距與未來思考
最後，還有生態系統差距，我認為這對國內從業者來說最值得注意。
這篇文章說得很有道理：這種合作對DeepSeek來說可能非常有效，但可能無法讓每個人都輕鬆使用Ascend。對於DeepSeek來說，編寫自己的編譯器、維護核心和調試特定供應商的行為與模型研究和產品開發爭奪資源。雖然文章暗示這可能是暫時的，但對其他人來說，問題在於一旦硬體配置與DeepSeek的配置不同，就會出現問題。
大多數優化都是圍繞超級節點構建的。截至VLM 0.2602 C1版本，在X86主機上使用Ascend仍然存在許多問題。例如，X86主機不支援DeepSeek-VLM使用的manfabric-hybrid依賴項中硬編碼的ARM頭文件，導致DeepSeek-VLM凍結；它並非開箱即用，因此非ARM CPU會跳過CPU綁定，並且沒有NPU和X86 CI/CD，需要手動修補某些配方。所以你看，Ascend和DeepSeek的組合在它們自己的超級節點上運作良好，但在這種配置之外，技術債就會暴露出來。
文章最後指出，華為已經為一群基礎業者提供了高效率的解決方案。DeepSeek引進了針對特定工作負載的工程設計，將平台功能擴展到這些運算子之外；同時，華為的架構和原生軟體堆疊正在影響這些實作方式的建構。
編譯器和核心工作的價值不僅體現在今天的效能上，還體現在它為下一代產品和下一次部署節省了多少工程工作量上。從更宏觀的角度來看，真正的機會在於為中國人工智慧產業的工程能力創造倍增效應。其他運行深度偽造服務的運營商可以直接重複使用這些核心和部署實踐，而其他研究機構可以基於這些共享的編譯器功能來建立新的模型。如果這些用戶將他們的修復和優化成果貢獻回社區，回報將會倍增成長，就像有人在每個團隊組成之初就幫他們完成最困難的部分一樣。
最後，它提到了類似戴爾的「晶片大戰」引發的關於晶片出口限制的擔憂。從目前這組軟體結果和對950PR的實證測試來看，隨著工程技術不斷融入華為的技術，生態系統差距正在縮小。文章中的原文是：「黃仁勳的惡夢正在變成現實。」我不想把話說得這麼戲劇化，但還有另一個問題更值得關注。
如果這種協同效應只適用於深度偽造技術和華為，那麼它真的能成為國內運算生態系統的基礎，還是只是一條客製化的私有線路？由於程式碼是開源的，答案取決於有多少團隊實際使用它並將他們的修改貢獻出來。
感謝收看，我們下次再見。