亞馬遜AIGC全家桶來襲，巨頭AI大亂戰(zhàn)都有什么殺手锏
此前，亞馬遜云科技發(fā)布多款AIGC產(chǎn)品，其中包括AI大模型服務Amazon Bedrock、人工智能計算實例Amazon EC2 Trn1n和Amazon EC2 Inf2、自研“泰坦”（Titan）AI大模型、軟件
部署超大規(guī)模 MoE 這件事，國產(chǎn)芯片的推理性能，已經(jīng)再創(chuàng)新高了 —— 不僅是“英偉達含量為 0”這么簡單，更是性能全面超越英偉達 Hopper 架構！
而做到這一點的，正是華為昇騰；具體而言，共包含兩個產(chǎn)品：
CloudMatrix 384 超節(jié)點
：部署 DeepSeek V3 / R1，在 50ms 時延約束下單卡 Decode 吞吐突破 1920 Tokens/s
Atlas 800I A2 推理服務器
：部署 DeepSeek V3 / R1，在 100ms 時延約束下單卡吞吐達到 808 Tokens/s，可支持靈活的分布式部署
之所以能夠這般，是因為華為昇騰所采取的“以數(shù)學補物理”—— 這種通過數(shù)學理論、工具、算法和建模等方式，來彌補硬件和工藝的局限性，實現(xiàn)最大化發(fā)揮芯片和系統(tǒng)能力效果。
華為昇騰還不只是“官宣”一下而已，后面更會是全面開源。
不僅已經(jīng)將昇騰在超大規(guī)模 MoE 模型推理部署的技術報告分享了出來，在一個月時間內，還會把實現(xiàn)這些核心技術的相關代碼也都會陸續(xù)開源出來。
那么接下來，我們就來深入了解一下華為昇騰背后的技術實力。
在華為昇騰上推理 DeepSeek在深挖華為昇騰背后技術創(chuàng)新之前，我們且需了解一下為什么要這么做。
從 2017 年 Google 提出的 Transformer 架構，到 2025 年 DeepSeek V3 / R1 的爆紅，大語言模型的重心正在從訓練開發(fā)轉向推理應用落地。
推理能力不僅是大模型能力的“試金石”，各大企業(yè)已從“拼模型參數(shù)”轉向“拼推理效率”：
誰能讓大模型在實際應用中跑得更快、更穩(wěn)、更省資源，誰就能在商業(yè)化浪潮中搶占先機。
然而，以 6710 億參數(shù)的 DeepSeek V3 為例，這類超大規(guī)模 MoE 模型雖然強大，卻給硬件帶來三大“成長煩惱”：
內存壓力山大：一個模型包含 257 個專家，每個專家“體重” 2.5G，普通 64GB 內存的 AI 硬件根本“扛不動”，必須依賴集群協(xié)作。
通信開銷爆炸：專家分布在不同芯片上，數(shù)據(jù)傳輸耗時甚至超過計算時間，就像團隊成員頻繁開會溝通，效率大打折扣。
架構創(chuàng)新的“甜蜜負擔”：例如“多頭隱式注意力機制（MLA）”雖然壓縮了數(shù)據(jù)空間，卻導致中間變量激增，對芯片的計算能力提出更高要求。
面對這些挑戰(zhàn)，華為團隊從算子、模型和框架三方面入手，基于昇騰硬件特性，開發(fā)了一整套面向集群的大規(guī)模專家并行解決方案。
在硬件部署上，華為團隊根據(jù)不同硬件配置 ——CloudMatrix 384 超節(jié)點和 Atlas 800I A2 推理服務器，針對性地采取了不同的部署優(yōu)化策略。為解耦 Prefill 和 Decode 階段的時延約束，昇騰采用 PD 分離部署方式。
在框架側，昇騰基于 vLLM 框架，適配 DP 和 EP 等多種并行策略，通過 Prefill 調度分桶、靈衢互聯(lián)與分層傳輸?shù)燃夹g來降低調度開銷，優(yōu)化請求下發(fā)、調度策略等環(huán)節(jié)，提升系統(tǒng)性能。
在模型方面，昇騰采用 A8W8C16 量化策略，其中 A8W8 使用 INT8，C16 使用 BF16，并針對不同機型進行差異化部署。
針對 CloudMatrix 384 超節(jié)點，其強大的組網(wǎng)能力大幅降低了通信耗時，釋放了昇騰芯片的算力。
團隊采用大規(guī)模 EP 并行部署，Prefill 使用 16 卡，Decode 使用 144 卡，其中 128 卡部署路由專家，16 卡部署共享專家，MLA 部分采用 DP 部署。
盡管存在時延約束、帶寬搶占、調度開銷、負載不均等因素影響，最終在 50ms 時延下，單卡 decode 吞吐達到 1920 Token / s。
針對機群規(guī)模較小但部署更加靈活的 Atlas 800I A2 服務器，華為團隊采用多節(jié)點互聯(lián)的方式進行部署。
作為示例，華為團隊使用 2 機 16 卡進行 Prefill，4 機 32 卡進行 Decode，每卡部署 8 個路由專家和 1 個共享專家，MLA 部分采用 DP 并行，并針對性地使用在真實負載下性能更優(yōu)的 AllGather / ReduceScatter 的通信方案。
通過各種策略優(yōu)化，在 100ms 時延下，單卡吞吐達到 808 Tokens / s。
還有更多優(yōu)化技術在推理框架優(yōu)化方面，針對高并發(fā)場景下單點 API Server 這一性能瓶頸，華為團隊設計了 API Server 橫向擴展方案，采用水平擴展技術提升框架的請求響應能力，顯著降低用戶請求延遲并提高整體服務吞吐量（QPS）。
針對 MoE 模型中的負載不均問題，基于動態(tài)調整專家部署與縮小通信域、熱專家冗余部署、實時調度與動態(tài)監(jiān)控機制等核心技術，降低顯存占用的同時實現(xiàn)動態(tài)負載均衡。
在投機推理技術的工程化應用中，如何將其從小批量低時延場景擴展至高吞吐量場景，是行業(yè)面臨的共性難題。
華為團隊基于昇騰芯片高計算帶寬比的硬件特性，提出 FusionSpec 投機推理引擎，針對性優(yōu)化多 Token 預測（MTP）場景下的推理性能：
流程重構
：將投機模型后置於主體模型，直接復用主體模型的輸出結果與控制參數(shù)，大幅減少框架耗時，完美適配參數(shù)-數(shù)據(jù)分離（PD 分離）的分布式部署架構；
輕量步間優(yōu)化
：對投機推理場景中的框架和算子優(yōu)化實現(xiàn)了輕量步間準備，適配多核并行的全異步框架。
在通信優(yōu)化方面，華為昇騰也有三大妙招。
首先，針對主流張量并行（TP）方案中 AllReduce 通信的固有缺陷（通信次數(shù)多、數(shù)據(jù)量大、冗余計算顯著），華為團隊推出 FlashComm 通信方案，通過集合通信邏輯重構與算子位置編排，實現(xiàn)低比特、低維度數(shù)據(jù)通信，在降低通信時延的同時消除冗余計算，最終實現(xiàn) 25% 通信量的降低和 10% 推理性能的提升。
其次，在 FlashComm 基礎上，團隊進一步提出層內并行轉換方案，針對 Prefill 階段的 MLA 層，通過張量并行（TP）與數(shù)據(jù)并行（DP）的靈活轉換，消除節(jié)點內卡間求和操作，并利用網(wǎng)絡低維特性與量化技術壓縮通信數(shù)據(jù)量，顯著降低跨卡通信時延，為大模型分布式推理提供更高效的通信支撐。
第三，通信方面的優(yōu)化還有一個并發(fā)機制的深度挖掘，包括：
計算通信并發(fā)
：通過 Gate 函數(shù)計算與 AllGather 通信的解耦，結合共享專家的數(shù)據(jù)并行（DP）策略，利用昇騰多流機制實現(xiàn)計算與通信的并發(fā)執(zhí)行，最大化硬件利用率；
通信通信并發(fā)
：針對 DeepSeek 模型的量化場景，將激活值與 scale 的傳輸任務并行處理，在不增加帶寬壓力的前提下掩蓋小數(shù)據(jù)量通信的啟動開銷；
通信和權重預并發(fā)
：利用通信階段 HBM 帶寬低占用特性，提前將后續(xù)算子權重預取至緩存，降低計算階段的數(shù)據(jù)搬運開銷，實測 MLA 層計算性能提升 10%。
最后，就是在算子方面的優(yōu)化了。華為團隊通過以數(shù)學補物理，發(fā)展了一系列的優(yōu)化技術。
針對 MLA 算子中間變量膨脹與計算量激增的挑戰(zhàn)，團隊開展硬件親和性優(yōu)化：
算法重構：提出 AMLA 算法，通過二進制編碼與存內計算，將乘性計算轉換為加性等價形式，直接在全局內存完成輸出更新，減少數(shù)據(jù)搬運耗時；
緩存策略：通過 L1 / L2 緩存精細化管理與 K-buffer 流水排布，提升緩存命中率與計算效率，實現(xiàn)張量計算與向量計算的相互掩蓋；
前序算子融合：在 Prefill 與 Decode 階段分別采用雙流并發(fā)與算子融合技術，結合權重預取、分塊策略及定制指令集優(yōu)化，構建端到端高效計算鏈路。
MoE 算子方面的優(yōu)化則包括：
通算融合算子：針對 EP 部署模式下 MoE 專家的跨卡調度難題，設計 MoeDistributeDispatch / Combine 算子，通過 Token 粒度的流水排布與內存語義通信技術，將通信與計算并行化，減少卡間同步開銷；
SMTurbo-CPP 技術：針對小數(shù)據(jù)量通信效率問題，通過讀寫混合、聚合流水等硬件并發(fā)技術，提升 AllToAll (v) 算子的吞吐能力，降低 Dispatch / Combine 場景時延；
細粒度分級流水算法：基于 Atlas 800I A2 組網(wǎng)特性，實現(xiàn)節(jié)點內 / 節(jié)點間的集合通信并發(fā)執(zhí)行，大幅提升集群環(huán)境下的帶寬利用率。
性能創(chuàng)新高在 Decode 性能測試方面，Atlas 800I A2 所采用的方式是：
序列長度為 2K 輸入 + 2K 輸出和 1K 輸入 + 2K 輸出兩種情況
在使能 MTP 進行推理加速的情況下，由于不同測試數(shù)據(jù)集和業(yè)務場景的 MTP 接受率不同，性能測試結果會有比較大的偏差。因此在計算時延和吞吐的時候默認按照 70% 接受率來折算。
TPOT（Decode 平均每 Token 時延）不超過 100ms。
具體表現(xiàn)如下所示：
在 Prefill 上的測試方法是，單 batch 輸入序列長度為 2K / 1K，通過拼 batch 的方式拼成一共 16K 序列。對于序列長度是 2K，共 8 batch 拼成一共 16K 序列的場景，端到端耗時為 631ms，卡均吞吐為 1622 Tokens / s。
具體表現(xiàn)如下圖所示：
在 2025 年 4 月，硅基流動聯(lián)合華為云基于 CloudMatrix 384 超節(jié)點昇騰云服務和高性能推理框架 SiliconLLM，用大規(guī)模專家并行最佳實踐正式上線 DeepSeek-R1。
該服務在保證單用戶 20 TPS (等效 50ms 時延約束) 水平前提下，單卡 Decode 吞吐突破 1920 Tokens / s，可比肩 H100 部署性能。
而也正如我們剛才提到的，昇騰在超大規(guī)模 MoE 模型推理部署的技術報告分享了出來了，想要更深入了解的小伙伴，可以在文末鏈接中自取哦。
One More Thing就在本周，華為昇騰還將舉辦一個技術披露周！
大家可以關注https://gitcode.com/ascend-tribe/ascend-inference-cluster/ 中每天的上新。
具體詳情放下面嘍，小伙伴們可以蹲一波了~
完整技術報告：
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/Overview/%E5%8D%8E%E4%B8%BA%E6%98%87%E8%85%BE%E6%9C%8D%E5%8A%A1%E5%99%A8_DeepSeek_V3_R1_%E6%8E%A8%E7%90%86%E9%83%A8%E7%BD%B2%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5.pdf
技術博客：
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/Overview/ascend-inference-cluster-overview.md
本文來自微信公眾號：量子位（ID：QbitAI），作者：金磊，原標題《華為 + DeepSeek，推理性能創(chuàng)新高！技術報告也公布出來了》
本文鏈接：http://www.tebozhan.com/showinfo-45-13053-0.html華為 + DeepSeek 推理性能創(chuàng)新高，技術報告公布
聲明：本網(wǎng)頁內容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號