4.3 資源高效預(yù)填充與混合并行和微批次
預(yù)填充階段負(fù)責(zé)處理輸入提示以生成初始 KV 緩存，對(duì)首令牌時(shí)間（TTFT）和系統(tǒng)吞吐量有顯著影響。鑒于其通常是計(jì)算密集型特性，在預(yù)填充期間實(shí)現(xiàn)高 NPU 利用率至關(guān)重要。然而，該階段經(jīng)常面臨諸如異構(gòu)輸入序列長度導(dǎo)致的負(fù)載不平衡以及通信開銷等挑戰(zhàn)，特別是在像 MoE 模型這樣的復(fù)雜架構(gòu)中。為了解決這些問題并最大化 CloudMatrix384 上的效率，我們?cè)?CloudMatrix-Infer 中提出了三個(gè)關(guān)鍵優(yōu)化。首先，我們?yōu)?MLA 計(jì)算引入了一種_分階段混合并行方案，以克服傳統(tǒng)數(shù)據(jù)并行（DP）的固有低效性（§4.3.1）。其次，我們提出了一種基于微批次的預(yù)填充流水線，利用昇騰 910C NPU 的異構(gòu)計(jì)算和通信單元來最大化延遲重疊并減少爭用（§4.3.2）。最后，我們介紹了預(yù)填充和解碼階段之間的傳輸優(yōu)化，以最小化對(duì)解碼的干擾（§4.3.3）。
4.3.1. MLA 計(jì)算的混合并行
LLM 中的預(yù)填充是一個(gè)顯著的計(jì)算瓶頸。盡管 CloudMatrix384 提供了強(qiáng)大的計(jì)算能力和高帶寬互連，但我們觀察到，在昇騰 NPU 上，DeepSeek GPU 部署中最初使用的純數(shù)據(jù)并行（DP）（§3.5.1）導(dǎo)致次優(yōu)的負(fù)載平衡和資源利用率。這種低效率源于兩個(gè)主要原因：
序列長度傾斜（Sequence-Length Skew）： 在實(shí)踐中，傳入的請(qǐng)求通常具有不同的輸入序列長度。在典型的 32 路 DP 配置下，分配到較短序列的 NPU 更早完成工作，然后空閑等待那些處理批次中最長序列的 NPU，導(dǎo)致計(jì)算周期浪費(fèi)。
并發(fā)不足（Insufficient Concurrency）： 如果正在處理的請(qǐng)求數(shù)量少于 DP 度（例如，對(duì)于 DP32 少于 32 個(gè)請(qǐng)求），一些 DP 分片接收不到工作。延遲處理以累積滿 32 個(gè)請(qǐng)求的批次會(huì)增加 TTFT，而使用部分批次進(jìn)行則會(huì)利用不足 NPU 資源。
為了緩解這些低效率問題，我們?yōu)轭A(yù)填充階段的 MLA 計(jì)算引入了一種優(yōu)化的分階段混合并行策略，在圖 16a 和 16b 中與基本 DP 進(jìn)行了視覺對(duì)比。我們將 MLA 分解為三個(gè)階段，并對(duì)每個(gè)階段應(yīng)用不同的并行方案。
第一階段（包括處理層輸入和 down_proj 操作）和第三階段（包括 o_proj 操作）涉及的計(jì)算在并行化策略上本質(zhì)上不依賴于令牌在序列中的位置。對(duì)于這些階段，我們利用_序列并行（SP）結(jié)合序列打包（sequence packing），取代純 DP。該方法涉及將多個(gè)請(qǐng)求的提示序列連接起來，然后將打包的超序列的分段分布在 SP 等級(jí)上。因此，來自不同長度請(qǐng)求的令牌以近似均勻的方式分布在 NPU 芯片上，實(shí)現(xiàn)有效的負(fù)載平衡，不受單個(gè)請(qǐng)求長度影響。
第二階段，包括 q_wp_proj、kv_wp_proj 和核心 FlashAttention 機(jī)制，關(guān)鍵依賴于令牌位置進(jìn)行注意力計(jì)算。對(duì)于此階段，我們應(yīng)用張量并行（TP）以確保跨 NPU 芯片的計(jì)算負(fù)載均衡分配。在我們的預(yù)填充實(shí)現(xiàn)中，MLA 通常在沒有某些權(quán)重矩陣吸收的情況下執(zhí)行，以增強(qiáng)原始計(jì)算效率，允許將其有效地視為標(biāo)準(zhǔn)的 128 頭多頭注意力（MHA）操作。鑒于 MHA 計(jì)算對(duì)每個(gè)注意力頭是獨(dú)立的，我們通過將這些注意力頭均勻分布在 NPU 芯片上來應(yīng)用 TP。
跨階段在這些不同并行策略之間轉(zhuǎn)換需要數(shù)據(jù)重分布。我們?cè)陔A段 1 和 2 之間插入一個(gè) All-Gather，在階段 2 和 3 之間插入一個(gè) All-to-All，以在等級(jí)之間正確重新分片和分布激活數(shù)據(jù)。
圖 17 提供了使用四個(gè)不同長度輸入（輸入 0、輸入 1、輸入 2、輸入 3）在四個(gè) NPU 等級(jí)上處理的這種混合并行數(shù)據(jù)流的說明性示例。最初，在階段 1，來自這些輸入的令牌被打包并使用 SP 分布。每個(gè)等級(jí)處理打包序列的一個(gè)連續(xù)片段，確保所有等級(jí)接收大致相同數(shù)量的令牌，從而盡管原始查詢長度不同也能平衡負(fù)載。對(duì)于階段 2，在 All-Gather 之后，數(shù)據(jù)為 TP 重新分布。在這里，每個(gè)等級(jí)處理來自所有四個(gè)輸入的所有令牌的一個(gè)分片（例如，一個(gè)注意力頭子集）。圖中此階段的彩色塊表示每個(gè)等級(jí)現(xiàn)在處理每個(gè)輸入的一部分。最后，在通過 All-to-All 操作從 TP 階段收集結(jié)果之后，階段 3 執(zhí)行其計(jì)算，數(shù)據(jù)再次按照類似于階段 1 的 SP 組織。此示例突顯了混合方法如何在 MLA 計(jì)算過程中保持負(fù)載平衡。
與傳統(tǒng)的 DP 策略（圖 16a）相比，這種混合并行引入了這兩個(gè)額外的集合通信步驟。然而，它們的開銷被仔細(xì)管理。All-Gather 操作在維度縮減步驟（由 down_proj 隱含）之后執(zhí)行，因此操作在潛在更小的張量上。All-to-All 集合主要重新分布注意力機(jī)制的張量并行分片。由于這些分片已經(jīng)被 TP 度減小了大小，因此在此操作期間每個(gè)等級(jí)交換的數(shù)據(jù)遠(yuǎn)少于可能處理完整未分片張量的集合操作。在具有高帶寬 UB 平面的 CloudMatrix384 上，兩個(gè)算子的通信開銷相對(duì)較小。
4.3.2 基于微批次的預(yù)填充流水線
為了減輕專家并行引入的通信開銷，原始的 DeepSeek 部署采用了雙微批次流水線策略。如圖 18a 所示，此方法在 NVIDIA H800 GPU 上交疊兩個(gè)并發(fā)微批次的計(jì)算和通信。通過將一個(gè)微批次的計(jì)算與另一個(gè)微批次的通信開銷（即分發(fā)和組合）重疊，該方法提高了流水線效率并在預(yù)填充階段分?jǐn)偭搜舆t。
然而，由于架構(gòu)不匹配，將此策略直接移植到 CloudMatrix384 上的昇騰 910C NPU 效率低下。H800 上的流水線通常保留其部分流式多處理器（SM）用于通信任務(wù)，實(shí)現(xiàn)并發(fā)但減少了可用的計(jì)算資源。相比之下，昇騰 910C 提供了異構(gòu)計(jì)算結(jié)構(gòu)，包括用于矩陣操作的 AIC、用于輕量級(jí)計(jì)算的 AIV 以及用于數(shù)據(jù)移動(dòng)的 SDMA 引擎，支持更細(xì)粒度的、特定角色的任務(wù)分配。
為了充分利用這種異構(gòu)性，我們?yōu)?CloudMatrix384 引入了一種優(yōu)化的基于微批次的預(yù)填充流水線，如圖 18b 所示。我們的設(shè)計(jì)編排了跨 AIC、AIV 和 SDMA 子系統(tǒng)的工作負(fù)載分配，如下所示：
首先，我們將低強(qiáng)度的輔助計(jì)算卸載到 AIV，釋放 AIC 專注于計(jì)算密集型算子，如 ATTN 和 MLP。諸如分發(fā)前令牌重新排序和元數(shù)據(jù)生成（表示為 DispatchCompute）以及組合后專家輸出累積（表示為 CombineCompute）等任務(wù)被分配給 AIV。這些操作是輕量級(jí)且可向量化的，非常適合 AIV 執(zhí)行。如圖 18b 所示，當(dāng) AIC 為另一個(gè)微批次執(zhí)行核心計(jì)算時(shí)，AIV 可以為一個(gè)微批次處理 DispatchCompute，實(shí)現(xiàn)細(xì)粒度的算子級(jí)重疊。
其次，我們將高容量數(shù)據(jù)傳輸（例如用于 MoE 分發(fā)和組合的 All-to-All 通信）顯式路由到 SDMA 引擎。通過將這些內(nèi)存操作隔離到專用的傳輸流，我們防止了與 AIC 和 AIV 執(zhí)行的爭用。這種隔離確保計(jì)算密集型操作可以不受干擾地進(jìn)行，并且通信延遲被并發(fā)執(zhí)行的 AIC/AIV 任務(wù)所重疊。鑒于預(yù)填充工作負(fù)載由密集矩陣操作和通信主導(dǎo)，通過 SDMA 顯式引導(dǎo)數(shù)據(jù)流在保持峰值 NPU 吞吐量方面起著關(guān)鍵作用。
這種硬件感知的任務(wù)分配，即 AIC 用于主要計(jì)算，AIV 用于輔助向量任務(wù)，SDMA 用于通信，提高了并發(fā)性并最小化了執(zhí)行停滯。
此外，這種設(shè)計(jì)明顯不同于我們的解碼階段流水線（§4.2.3），由于不同的延遲和吞吐量要求，通信邏輯在那里與計(jì)算流更緊密地耦合。在預(yù)填充中，需要處理更長的序列和更大的微批次，使其對(duì)計(jì)算飽和和帶寬爭用更敏感。因此，通過專用執(zhí)行單元分離關(guān)注點(diǎn)并在算子級(jí)別重疊任務(wù)更符合 CloudMatrix384 的性能特征。
4.3.3 預(yù)填充與解碼之間的低干擾傳輸
在預(yù)填充-解碼解耦的服務(wù)架構(gòu)中，預(yù)填充階段負(fù)責(zé)生成第一個(gè)令牌和相應(yīng)的 KV 緩存，然后必須將其傳輸?shù)浇獯a階段以啟動(dòng)自回歸生成。為了防止延遲敏感的解碼性能被預(yù)填充活動(dòng)干擾，我們?cè)?CloudMatrix-Infer 中引入了三個(gè)系統(tǒng)級(jí)優(yōu)化：(1) 通過 RDMA 平面實(shí)現(xiàn) KV 緩存?zhèn)鬏數(shù)挠布?jí)隔離，(2) 異步調(diào)度以解耦預(yù)填充執(zhí)行與解碼調(diào)度，以及 (3) 模型感知的連接分組以均衡平衡預(yù)填充-解碼通信流量。
基于 RDMA 平面的 KV 緩存?zhèn)鬏敗?預(yù)填充階段完成后，完整的 KV 緩存被傳輸?shù)椒峙涞慕獯a節(jié)點(diǎn)。為了消除與解碼階段通信的潛在干擾，此 NPU 到 NPU 傳輸通過 RDMA 平面進(jìn)行，該平面在物理和邏輯上與用于帶寬密集型解碼操作（如令牌分發(fā)和專家輸出組合）的 UB 平面解耦。使用 RDMA 平面的專用路徑，我們將 KV 緩存的移動(dòng)與延遲關(guān)鍵的解碼流量隔離。此外，由于每個(gè)請(qǐng)求的 KV 緩存僅傳輸一次，RDMA 平面提供了足夠的帶寬而不會(huì)成為性能瓶頸。
異步預(yù)填充調(diào)度。 為了進(jìn)一步最小化兩個(gè)階段之間的干擾，我們將預(yù)填充調(diào)度和 KV 緩存?zhèn)鬏斝遁d到解碼調(diào)度器中的專用后臺(tái)線程。當(dāng)新的推理請(qǐng)求到達(dá)時(shí)，推理引擎立即將控制權(quán)交還給后臺(tái)線程，該線程異步執(zhí)行以下步驟：(i) 在目標(biāo)解碼節(jié)點(diǎn)上分配 KV 緩存緩沖區(qū)，(ii) 將預(yù)填充任務(wù)路由到低負(fù)載的預(yù)填充節(jié)點(diǎn)，以及 (iii) 在完成后觸發(fā)基于 RDMA 的緩存?zhèn)鬏?。此設(shè)計(jì)確保解碼線程永遠(yuǎn)不會(huì)被預(yù)填充計(jì)算或數(shù)據(jù)傳輸阻塞，從而實(shí)現(xiàn)連續(xù)的解碼調(diào)度和更高的響應(yīng)性。
負(fù)載均衡的預(yù)填充-解碼連接映射。 在 PD 解耦系統(tǒng)中，一個(gè)常見場景是為預(yù)填充和解碼階段使用不同的并行配置。例如，解碼階段可能采用張量并行（TP）和數(shù)據(jù)并行（DP）的組合，而預(yù)填充階段通常使用更大的 TP 度來加速長輸入序列的處理。使用具有單個(gè)潛在頭的 MLA 的 DeepSeek-R1 模型的一個(gè)關(guān)鍵特征是，TP 組（tp_rank）內(nèi)的所有等級(jí)持有相同的、完整的 KV 緩存副本。
雖然這種數(shù)據(jù)冗余提供了靈活性，但如果管理不當(dāng)，也會(huì)帶來創(chuàng)建網(wǎng)絡(luò)熱點(diǎn)的風(fēng)險(xiǎn)。如果一個(gè)解碼實(shí)例的所有等級(jí)都從同一個(gè)源預(yù)填充等級(jí)拉取 KV 緩存，那么該單一網(wǎng)絡(luò)鏈路將成為嚴(yán)重的瓶頸。為了防止這種情況，我們開發(fā)了一種確定性分組連接機(jī)制以確保均衡的傳輸負(fù)載。此映射方案計(jì)算如下：
令 prefill_tp_sizeprefill_tp_size 為預(yù)填充實(shí)例的 TP 大小。
令 decode_tp_sizedecode_tp_size 和 decode_dp_sizedecode_dp_size 分別為解碼實(shí)例的 TP 和 DP 大小。
令 decode_tp_rank_iddecode_tp_rank_id 和 decode_dp_rank_iddecode_dp_rank_id 為特定解碼進(jìn)程的 TP 和 DP 等級(jí) ID
首先，建立分組參數(shù)
和 .
和prefill_tp_rank_id = (group_id×decode_tp_size)+decode_tp_rank_id。此方案確保所有預(yù)填充-解碼鏈路之間均衡的連接拓?fù)?，避免通信熱點(diǎn)并維持高吞吐量。
總之，這三種技術(shù)實(shí)現(xiàn)了從預(yù)填充到解碼的無縫、低干擾切換，在解耦架構(gòu)下保持系統(tǒng)效率并確保大規(guī)模 LLM 的高性能服務(wù)。
4.4 UB 驅(qū)動(dòng)的分布式緩存與統(tǒng)一內(nèi)存訪問
在云環(huán)境中高效部署 LLM 關(guān)鍵依賴于高性能緩存策略。這些策略對(duì)于加速數(shù)據(jù)訪問至關(guān)重要，主要針對(duì)兩個(gè)關(guān)鍵場景：用于優(yōu)化上下文預(yù)填充的歷史 KV 緩存（上下文緩存），以及用于促進(jìn)快速模型部署和切換的模型。
參數(shù)（模型緩存）。這些緩存層的有效實(shí)施顯著減少了冗余計(jì)算，削減了模型加載延遲，并提高了整體系統(tǒng)性能。支持此類緩存功能需要一個(gè)高性能、大容量和低延遲的中間內(nèi)存層，戰(zhàn)略性地定位以彌合 NPU 高速內(nèi)存和較慢持久存儲(chǔ)服務(wù)（例如對(duì)象存儲(chǔ)服務(wù)（OBS））之間的性能差距。
本節(jié)詳細(xì)介紹了在 CloudMatrix384 上用于 LLM 服務(wù)的 UB 驅(qū)動(dòng)分布式緩存。我們首先描述解耦內(nèi)存池基礎(chǔ)（§4.4.1），它利用高帶寬 UB 平面構(gòu)建具有統(tǒng)一內(nèi)存訪問的解耦內(nèi)存池。然后我們介紹構(gòu)建在此池之上的兩個(gè)關(guān)鍵緩存服務(wù)：上下文緩存（§4.4.2）和模型緩存（§4.4.3），兩者都通過華為云的彈性內(nèi)存服務(wù)（EMS）[26] 提供。
4.4.1 解耦內(nèi)存池化
EMS 緩存服務(wù)的核心是一個(gè)邏輯上解耦的內(nèi)存池，由 CloudMatrix384 內(nèi)跨節(jié)點(diǎn)聚合的 CPU 連接 DRAM 組成。該池充當(dāng)歷史 KV 緩存和模型參數(shù)的統(tǒng)一高性能內(nèi)存基礎(chǔ)。該內(nèi)存池的一個(gè)顯著特征是其與 UB 網(wǎng)絡(luò)平面的深度集成，實(shí)現(xiàn)對(duì)分布式 DRAM 的高效、統(tǒng)一內(nèi)存訪問，并允許 NPU 快速檢索必要的數(shù)據(jù)，無論其物理位置如何，促進(jìn)了 §4.1 中提出的點(diǎn)對(duì)點(diǎn)服務(wù)架構(gòu)。該設(shè)計(jì)的有效性關(guān)鍵由以下 UB 的硬件能力驅(qū)動(dòng)：1) 高速點(diǎn)對(duì)點(diǎn)結(jié)構(gòu)： UB 網(wǎng)絡(luò)支持快速的節(jié)點(diǎn)間數(shù)據(jù)傳輸，允許任何 NPU 或 CPU 高效訪問其他節(jié)點(diǎn)上的 DRAM；2) UB 上的 DMA： 通過直接內(nèi)存訪問（DMA）實(shí)現(xiàn)零拷貝數(shù)據(jù)傳輸，繞過 CPU 仲裁并減少傳輸延遲；3) 低級(jí)內(nèi)存原語： UB 協(xié)議公開了用于遠(yuǎn)程內(nèi)存注冊(cè)和訪問的原語，允許軟件棧維護(hù)全局內(nèi)存視圖。
如圖 19 所示，此解耦內(nèi)存池由專用的三組件軟件架構(gòu)管理：
MP SDK： 嵌入在 AI 應(yīng)用程序的進(jìn)程中，它將上層緩存請(qǐng)求轉(zhuǎn)換為分布式內(nèi)存操作，暴露鍵值存儲(chǔ)風(fēng)格的 API，如 Put 和 Get；
MP 控制器（Controller）： 一個(gè)集中的控制平面，維護(hù)元數(shù)據(jù)（例如分布式哈希表（DHT）視圖、命名空間），協(xié)調(diào)操作并編排資源管理；
MP 服務(wù)（Server） ： 部署在DRAM-contributing 的節(jié)點(diǎn)上，管理本地內(nèi)存，處理分層（tiering）和恢復(fù)，并參與負(fù)載平衡。
這些軟件組件與 UB 平面的相互作用實(shí)現(xiàn)了幾個(gè)關(guān)鍵的操作機(jī)制和系統(tǒng)特性：
分布式數(shù)據(jù)索引和放置。 為了確定鍵值對(duì)在解耦內(nèi)存池中的放置位置并高效定位它，內(nèi)存池采用全局一致性哈希索引。該索引將輸入鍵映射到負(fù)責(zé)的 MP 服務(wù)器節(jié)點(diǎn)。一個(gè) DHT 視圖支撐此方案，其整體一致性和元數(shù)據(jù)由 MP 控制器管理。各個(gè) MP 服務(wù)器通過管理其本地?cái)?shù)據(jù)部分并響應(yīng)路由請(qǐng)求來參與 DHT。MP SDK 利用此機(jī)制將密鑰分發(fā)到特定節(jié)點(diǎn)和 DRAM 地址以進(jìn)行數(shù)據(jù)訪問。
高性能遠(yuǎn)程內(nèi)存訪問。 UB 平面支持并由軟件組件管理的一個(gè)關(guān)鍵功能是 NPU 對(duì)遠(yuǎn)程 DRAM 的直接、高性能訪問。這涉及在 MP 服務(wù)器實(shí)例和 MP SDK 客戶端初始化期間建立的內(nèi)存映射和注冊(cè)過程。協(xié)商控制消息以交換指定用于池的 DRAM 段的物理地址范圍，然后在 UB 結(jié)構(gòu)和 MP 控制器處注冊(cè)。此跨節(jié)點(diǎn)映射能力利用了 CloudMatrix384 超級(jí)節(jié)點(diǎn)對(duì)全局統(tǒng)一內(nèi)存尋址和路由的支持，允許 UB 交換機(jī)將 NPU SDMA 驅(qū)動(dòng)的訪問請(qǐng)求直接路由到目標(biāo) MP 服務(wù)器管理的 DRAM。
細(xì)粒度本地內(nèi)存管理。 為了有效管理其分配的 DRAM 段并應(yīng)對(duì)來自可變大小數(shù)據(jù)對(duì)象（如 KV 緩存塊或模型分片）的碎片，每個(gè) MP 服務(wù)器采用多粒度內(nèi)存分配系統(tǒng)。一個(gè)關(guān)鍵方面是使用大頁（huge pages）來減少內(nèi)存片分配頻率和相關(guān)管理開銷。對(duì)于數(shù)據(jù)分配，系統(tǒng)支持可變長度內(nèi)存分區(qū)，與固定大小分配器相比顯著提高了內(nèi)存利用率。此外，MP 服務(wù)器允許在其管理的 DRAM 內(nèi)不同粒度之間進(jìn)行動(dòng)態(tài)內(nèi)存流動(dòng)，基于工作負(fù)載相關(guān)的使用模式增強(qiáng)資源效率。
具有持久性和恢復(fù)功能的內(nèi)存分層。 為了管理存儲(chǔ)成本并確保數(shù)據(jù)持久性，解耦內(nèi)存池集成了一個(gè)基于 SSD 的分層，由 MP 服務(wù)器管理。該層利用云提供的彈性卷服務(wù)（EVS）SSD 來提供大容量、持久存儲(chǔ)?；?EVS 的分層的替代方案是使用云的可擴(kuò)展文件系統(tǒng)服務(wù)（SFS），但這會(huì)產(chǎn)生更高的成本。在此層次結(jié)構(gòu)中，分布式 DRAM 池充當(dāng)位于 EVS 層之上的快速緩存，實(shí)現(xiàn)對(duì)常用數(shù)據(jù)的低延遲訪問。持久性通過將所有數(shù)據(jù)寫入 EVS 來強(qiáng)制執(zhí)行。由于 EVS 卷容量有限，系統(tǒng)采用本地驅(qū)逐策略，例如最近最少使用（LRU），在需要時(shí)釋放空間。MP 服務(wù)器獨(dú)立管理 DRAM 駐留，使用其自己的 LRU 驅(qū)逐邏輯和 DRAM 層的容量閾值。從 DRAM 驅(qū)逐的數(shù)據(jù)仍然持久存儲(chǔ)在 EVS 中，除非后來被 EVS 自身的空間管理例程移除。這種分層結(jié)構(gòu)確保了容錯(cuò)能力：如果內(nèi)存中的數(shù)據(jù)丟失（例如由于節(jié)點(diǎn)故障），并且尚未被 EVS 自身驅(qū)逐，則可以從 EVS 層恢復(fù)。
重要的是，雖然通過擎天卡訪問 EVS 的每節(jié)點(diǎn)帶寬相對(duì)適中，通常低于 400 Gbps，但 CloudMatrix384 中的解耦內(nèi)存池聚合了所有 48 個(gè)節(jié)點(diǎn)的帶寬，產(chǎn)生高達(dá) 48×400 Gbps 的總 EVS 訪問帶寬。由于數(shù)據(jù)被劃分為細(xì)粒度塊并分布在節(jié)點(diǎn)間，NPU 可以通過高帶寬 UB 平面同時(shí)從多個(gè)節(jié)點(diǎn)獲取這些塊。這使得即使請(qǐng)求的數(shù)據(jù)駐留在 EVS 層，也能實(shí)現(xiàn)高聚合負(fù)載帶寬，通過系統(tǒng)范圍的并行有效地分?jǐn)偯抗?jié)點(diǎn) EVS 訪問的限制。
命名空間隔離。 為了支持多租戶和管理不同上下文緩存和模型緩存實(shí)例的數(shù)據(jù)，解耦內(nèi)存池提供 KV 命名空間隔離。這主要由 MP 控制器編排，它管理命名空間的創(chuàng)建、刪除和元數(shù)據(jù)。每個(gè) MP 服務(wù)器都知曉活動(dòng)命名空間，并確保數(shù)據(jù)操作被限制在指定的命名空間內(nèi)，在共享池內(nèi)提供邏輯數(shù)據(jù)隔離和容量使用限制。
總之，CloudMatrix384 的 UB 驅(qū)動(dòng)解耦內(nèi)存池為 LLM 推理提供了一個(gè)高吞吐量、可擴(kuò)展的內(nèi)存層。通過將硬件級(jí)點(diǎn)對(duì)點(diǎn)訪問與分布式內(nèi)存管理軟件相結(jié)合，系統(tǒng)支持對(duì) KV 緩存和模型參數(shù)的高效緩存，構(gòu)成了 EMS 的支柱。
4.4.2. 上下文緩存
LLM 推理的預(yù)填充階段負(fù)責(zé)處理輸入提示并生成初始 KV 緩存，是計(jì)算密集型的，特別是對(duì)于長序列。通過重用先前請(qǐng)求的歷史 KV 緩存可以獲得顯著的性能提升。這在涉及重復(fù)前綴的場景中特別有價(jià)值，例如多輪對(duì)話、少樣本提示（few-shot prompting）和重復(fù)的系統(tǒng)指令。在我們的架構(gòu)中，上下文緩存指的是用于存儲(chǔ)和高效檢索這些歷史 KV 緩存的專用機(jī)制。
上下文緩存由華為云上的服務(wù) EMS 實(shí)現(xiàn)。EMS 利用 UB 驅(qū)動(dòng)的解耦內(nèi)存池（§4.4.1）為歷史 KV 緩存創(chuàng)建一個(gè)共享的分布式存儲(chǔ)庫。這些緩存根據(jù)模型特性和 UB 傳輸效率組織成分頁塊（例如，每塊 128-512 個(gè)令牌）。服務(wù)集群中的所有 NPU 都可以通過 EMS API 訪問或貢獻(xiàn)于此緩存。
索引、去重和檢索。 EMS 向上層 LLM 服務(wù)框架提供專門的上下文緩存 SDK（即 API 層）用于存儲(chǔ)和檢索歷史 KV 緩存塊。在內(nèi)部，此 EMS SDK 利用 MP SDK（§4.4.1）的 API 與底層分布式 DRAM 和分層存儲(chǔ)交互。每個(gè) KV 緩存塊與一個(gè)唯一的哈希鍵相關(guān)聯(lián)，該哈希鍵源自其令牌序列，并輔以前綴哈希以實(shí)現(xiàn)內(nèi)容可尋址索引。這允許快速查找和去重：相同的 KV 塊存儲(chǔ)一次并在請(qǐng)求間重用。
分配給上下文緩存的解耦內(nèi)存池部分受容量限制。當(dāng)接近這些限制時(shí)，MP 服務(wù)器（§4.4.1）觸發(fā)將較冷的 KV 緩存塊從 DRAM 驅(qū)逐到 EVS 支持的 SSD 層。如果 SSD 容量也受限，則基于 LRU 類策略完全刪除數(shù)據(jù)。此驅(qū)逐過程確保在統(tǒng)一池內(nèi)上下文和模型緩存之間公平高效地共享資源。
與 PDC 解耦的交互。 EMS 與解耦的預(yù)填充和解碼流水線緊密集成：
預(yù)填充 - 重用和存儲(chǔ)： 收到新請(qǐng)求時(shí)，預(yù)填充引擎使用輸入前綴的哈希查詢 EMS 以識(shí)別可重用的 KV 緩存塊。如果找到，這些塊通過 UB 平面獲取并直接加載到 NPU 內(nèi)存中，繞過冗余計(jì)算。引擎然后處理剩余的后綴并生成相應(yīng)的 KV 緩存塊。這些新塊被異步存儲(chǔ)回 EMS，以便在未來的請(qǐng)求中重用，而不會(huì)阻塞正在進(jìn)行的計(jì)算。
解碼 - 選擇性緩存存儲(chǔ)： 解碼階段生成的 KV 緩存可用于非推理模型重用，但不適用于像 DeepSeek-R1 這樣的推理模型。這些推理模型發(fā)出中間推理令牌，后跟最終響應(yīng)令牌。中間令牌通常在后續(xù)輪次中不會(huì)被重新攝取，因此當(dāng)包含在后續(xù)提示中時(shí)，最終響應(yīng)令牌的位置會(huì)發(fā)生變化。這種位置變化由于位置敏感的注意力而破壞了緩存有效性。因此，解碼生成的緩存通常被排除在存儲(chǔ)之外。然而，如果系統(tǒng)采用容忍位置變化的近似 KV 重用技術(shù)，有選擇地存儲(chǔ)最終響應(yīng)令牌的緩存塊可以提供性能優(yōu)勢(shì)。
4.4.3. 模型緩存
現(xiàn)代 LLM 服務(wù)基礎(chǔ)設(shè)施必須高效支持大小、架構(gòu)和任務(wù)專業(yè)化各異的多樣化模型組合。這些基礎(chǔ)設(shè)施還必須適應(yīng)動(dòng)態(tài)模型切換以響應(yīng)波動(dòng)的服務(wù)需求和持續(xù)的模型更新。然而，從持久存儲(chǔ)（例如對(duì)象存儲(chǔ)服務(wù)（OBS））將具有數(shù)十億參數(shù)的 LLM 加載到 NPU 內(nèi)存會(huì)產(chǎn)生顯著的延遲。例如，從 OBS 加載具有 671B 參數(shù)的 DeepSeek-R1 模型（假設(shè)每個(gè)桶的標(biāo)準(zhǔn)訪問帶寬為 2.5 GB/s）需要超過五分鐘。此延遲嚴(yán)重限制了動(dòng)態(tài)模型切換的實(shí)用性，并損害了服務(wù)響應(yīng)性，特別是在模型更新或 A/B 測(cè)試期間。因此，快速緩存機(jī)制不僅對(duì)于減輕這些開銷至關(guān)重要，而且對(duì)于確保響應(yīng)迅速、敏捷的模型部署也必不可少。
為了應(yīng)對(duì)這些挑戰(zhàn)，我們納入了由 EMS 提供的模型緩存。其核心是，EMS 利用 UB 驅(qū)動(dòng)的解耦內(nèi)存池（§4.4.1）作為高性能分布式緩存基礎(chǔ)，支持跨系統(tǒng)的低延遲模型訪問。為了與上層服務(wù)框架集成，EMS 提供了模型緩存 SDK，公開用于從緩存中檢查、預(yù)取和加載模型的 API。具體來說，SDK 允許用戶查詢模型當(dāng)前是否緩存在 EMS 內(nèi)存池中，啟動(dòng)從持久存儲(chǔ)到 EMS 的模型塊異步預(yù)取，以及觸發(fā)模型塊加載到目標(biāo) NPU 內(nèi)存以進(jìn)行推理。當(dāng)模型已部分緩存時(shí)，預(yù)取充當(dāng)提示，將塊從較慢層（例如 SSD）提升到較快層（例如 DRAM），進(jìn)一步優(yōu)化訪問延遲。
緩存管理策略。 在內(nèi)部，EMS 將每個(gè)模型分解為內(nèi)存塊，并將它們作為鍵值條目存儲(chǔ)在解耦內(nèi)存池中。集中的元數(shù)據(jù)服務(wù)跟蹤從每個(gè)模型到其相應(yīng)塊集的映射，實(shí)現(xiàn)細(xì)粒度的分片模型加載和推理期間的高效檢索。EMS 通過跨準(zhǔn)入、驅(qū)逐和版本控制的協(xié)調(diào)策略管理緩存的模型塊。對(duì)于準(zhǔn)入和預(yù)取，EMS 基于應(yīng)用程序提示和觀察到的訪問模式將模型塊加載到 DRAM 或 SSD 層。驅(qū)逐由解耦內(nèi)存池的原生基于 LRU 的策略處理，由于模型塊的連貫訪問行為，該策略通常在模型級(jí)粒度運(yùn)行，即整個(gè)模型或大段一起被驅(qū)逐，避免碎片狀態(tài)。對(duì)于版本控制，EMS 通過維護(hù)版本感知標(biāo)識(shí)符并將每個(gè)模型與其相應(yīng)的塊集關(guān)聯(lián)，確保 NPU 始終執(zhí)行正確的模型版本。當(dāng)部署新版本時(shí)，服務(wù)框架顯式請(qǐng)求它，而陳舊版本通過自然緩存驅(qū)逐逐漸淘汰。
UB 驅(qū)動(dòng)解耦內(nèi)存池的模型緩存優(yōu)勢(shì)。 EMS 利用 UB 驅(qū)動(dòng)解耦內(nèi)存池為模型緩存實(shí)現(xiàn)兩個(gè)關(guān)鍵優(yōu)勢(shì)。首先，高帶寬、低延遲的 UB 平面促進(jìn)了從 EMS 內(nèi)存層（例如 DRAM 或 SSD）到 NPU 內(nèi)存的模型塊快速傳輸，大幅減少模型加載延遲。其次，EMS 使用統(tǒng)一的、集群范圍的內(nèi)存池，消除了數(shù)據(jù)冗余，允許多個(gè) NPU 實(shí)例共享單個(gè)緩存模型版本。此設(shè)計(jì)減少了對(duì)持久存儲(chǔ)帶寬的壓力以及緩存所需的累積 DRAM 和 SSD 占用空間，從而提高了可擴(kuò)展性和資源效率。
表 2 通過對(duì)具有 INT8 量化的 671B 參數(shù)模型的不同模型加載策略進(jìn)行性能比較來量化這些優(yōu)勢(shì)。當(dāng)不使用緩存時(shí)，所有 8 個(gè)同時(shí)從 OBS 加載同一模型的實(shí)例，由于共享的 2.5 GB/s OBS 帶寬上的嚴(yán)重爭用，每個(gè)實(shí)例的冷啟動(dòng)延遲約為 2,560 秒。本地 DRAM 緩存在此冷啟動(dòng)延遲上沒有改進(jìn)，因?yàn)槊總€(gè)節(jié)點(diǎn)仍然獨(dú)立地從 OBS 獲取完整模型。相比之下，EMS 通過內(nèi)存池啟用共享加載并跨實(shí)例重用模型塊，將冷啟動(dòng)延遲減少到僅 ~320 秒。
除了延遲之外，EMS 還提高了內(nèi)存效率。本地 DRAM 緩存導(dǎo)致 8 倍的 DRAM 開銷，其中 8 個(gè)實(shí)例中的每一個(gè)都存儲(chǔ)一個(gè)完整的模型副本。相比之下，EMS 僅需要 1 倍的 DRAM 占用空間來服務(wù)所有實(shí)例，同時(shí)保持相同的 ~5 秒熱啟動(dòng)延遲。在模型切換場景中，EMS 實(shí)現(xiàn)了 100% 的緩存命中率和平均 ~5 秒的切換延遲，顯著優(yōu)于本地 DRAM 緩存（后者僅產(chǎn)生 12.5% 的命中率和 ~281 秒的延遲）。這些結(jié)果突顯了 EMS 作為在大規(guī)模推理環(huán)境中最小化模型訪問延遲和內(nèi)存資源開銷的高效解決方案。
4.5 INT8 量化
為了在昇騰 910C 平臺(tái)上實(shí)現(xiàn) DeepSeek-V3/R1 等大規(guī)模 MoE 模型的高吞吐量、低延遲推理，我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了一種免訓(xùn)練的、分層的 INT8 量化方案，用于模型權(quán)重和激活。該方案旨在最大化計(jì)算效率并減少內(nèi)存占用，同時(shí)仔細(xì)管理潛在的精度損失。我們方法的核心組件詳述如下：
混合精度策略。 我們的量化方案采用混合精度策略，根據(jù)其對(duì)整體性能（例如計(jì)算負(fù)載、內(nèi)存訪問）的影響與對(duì)數(shù)值精度的敏感性之間的權(quán)衡，對(duì)模型中的不同算子進(jìn)行分類。關(guān)鍵執(zhí)行路徑中最計(jì)算密集的操作，如前饋網(wǎng)絡(luò)（FFN）和注意力機(jī)制中的大型矩陣乘法，被量化為 INT8 以利用最高吞吐量。相反，對(duì)量化誤差更敏感但構(gòu)成整體內(nèi)存訪問或計(jì)算負(fù)擔(dān)較小部分的子模塊或特定操作（例如某些歸一化層或關(guān)鍵門控機(jī)制）使用 BF16 或 FP32 保留更高精度。這種靈活的分區(qū)確保了整個(gè)模型可以在統(tǒng)一的硬件流水線中高效執(zhí)行，同時(shí)避免了關(guān)鍵、數(shù)值敏感路徑中的精度瓶頸。
自適應(yīng)縮放因子搜索。 有效的量化需要仔細(xì)對(duì)齊浮點(diǎn)值的動(dòng)態(tài)范圍到 INT8 整數(shù)的有限范圍。對(duì)于每個(gè)目標(biāo)為 INT8 量化的權(quán)重張量和激活張量，我們引入了一個(gè)輕量級(jí)的自適應(yīng)縮放因子搜索過程。此過程自動(dòng)確定最優(yōu)縮放因子 s?，以最小化量化誤差，有效對(duì)齊量化前后的值分布?？s放搜索被表述為一個(gè)優(yōu)化問題：
這里，WW 表示權(quán)重，XX 表示激活，Q(?)表示量化函數(shù)。該公式旨在找到權(quán)重的縮放因子 s（以及激活的 s?1），使得量化操作 Q(W?s)(s?1?X)Q(W?s)(s?1?X) 的輸出最接近原始浮點(diǎn)輸出 WX。這整個(gè)縮放確定過程在量化后校準(zhǔn)步驟中離線執(zhí)行，因此在推理期間不會(huì)產(chǎn)生額外的運(yùn)行時(shí)開銷。這個(gè)概念涉及在執(zhí)行量化乘法之前使用適當(dāng)?shù)目s放因子變換 X和 W。
離群值抑制和結(jié)構(gòu)轉(zhuǎn)換。 大型模型中的某些組件，特別是 MoE 架構(gòu)中的特定專家子網(wǎng)絡(luò)或門控結(jié)構(gòu)，可能表現(xiàn)出具有長尾或顯著離群值的激活或權(quán)重分布。這些離群值可能不成比例地影響量化范圍，導(dǎo)致大多數(shù)值精度的損失。為了緩解這種情況，我們采用了一種涉及結(jié)構(gòu)轉(zhuǎn)換的離群值抑制技術(shù)。在量化之前，引入簡單的線性變換（概念上類似于應(yīng)用學(xué)習(xí)的正交基旋轉(zhuǎn)或?qū)⒖s放因子吸收到前/后層中）。這些變換旨在將極值重新分配到更平衡和量化友好的范圍內(nèi)，而不改變層的底層數(shù)學(xué)函數(shù)。通過減少離群值的影響，此方法最大程度地降低了大量化誤差的風(fēng)險(xiǎn)，并抑制了通過網(wǎng)絡(luò)后續(xù)的錯(cuò)誤放大。
高效的 INT8 矩陣乘法內(nèi)核。 INT8 量化的性能優(yōu)勢(shì)關(guān)鍵依賴于高度優(yōu)化的執(zhí)行內(nèi)核。我們?yōu)榫仃嚦朔ɡ?em>混合粒度量化方案：激活（X）按每個(gè)令牌量化（動(dòng)態(tài)范圍按令牌確定），而權(quán)重（W）按每個(gè)通道量化（通常按輸出通道，每個(gè)通道靜態(tài)范圍）。此方法平衡了適應(yīng)快速變化的激活統(tǒng)計(jì)數(shù)據(jù)的需要與保持穩(wěn)定權(quán)重表示的需求。這種混合粒度，結(jié)合權(quán)重和激活的精心對(duì)齊的內(nèi)存布局，允許充分利用昇騰 NPU 上可用的專用整數(shù)矩陣乘法指令。與等效的 BF16 或 FP16 實(shí)現(xiàn)相比，這些優(yōu)化的 INT8 內(nèi)核在相同硬件上可以提供數(shù)倍的推理吞吐量提升，同時(shí)確保任何精度損失保持在應(yīng)用可接受的容忍范圍內(nèi)。
塊級(jí)裁剪和誤差補(bǔ)償。 為了進(jìn)一步優(yōu)化精度并處理大型權(quán)重張量內(nèi)的局部變化，我們實(shí)現(xiàn)了塊級(jí)裁剪和誤差補(bǔ)償。對(duì)權(quán)重進(jìn)行統(tǒng)計(jì)分析并劃分為較小的塊。對(duì)于每個(gè)塊，建立一個(gè)獨(dú)特的、可容忍的裁剪范圍。該范圍可以通過優(yōu)化裁剪的縮放因子 α 來確定（例如，
），該因子最小化該特定塊的量化誤差，例如通過求解：
這里， (W;α)表示使用裁剪因子 α量化塊內(nèi)的權(quán)重 W。同時(shí)，輕量級(jí)的誤差補(bǔ)償項(xiàng)被策略性地插入到推理計(jì)算圖中。這些項(xiàng)旨在抵消或部分糾正量化在不同模型點(diǎn)引入的系統(tǒng)性誤差，從而減輕量化噪聲對(duì)最終模型輸出的累積影響。該方法的一個(gè)顯著優(yōu)勢(shì)是它不需要修改原始模型訓(xùn)練過程，也不依賴于額外的微調(diào)階段，便于快速部署和迭代。
總之，這五種策略形成了一個(gè)健壯的分層 INT8 量化框架，使 DeepSeek-V3/R1 等海量模型能夠在昇騰硬件上實(shí)現(xiàn)高性能推理，仔細(xì)平衡計(jì)算效率與模型精度保持。
5. 評(píng)估
在本節(jié)中，我們對(duì)先前在 §4 中詳述的、部署在 CloudMatrix384 上的提議服務(wù)系統(tǒng) CloudMatrix-Infer 進(jìn)行全面性能評(píng)估。我們首先概述評(píng)估中使用的通用實(shí)驗(yàn)設(shè)置（§5.1）。隨后，我們分析性能和功效的幾個(gè)關(guān)鍵方面：包括整體系統(tǒng)性能（§5.2）；使用我們的 INT8 量化方案實(shí)現(xiàn)的推理精度（§5.3）；一項(xiàng)消融研究，調(diào)查所采用的不同優(yōu)化技術(shù)的具體貢獻(xiàn)（§5.4）；最后，考察關(guān)鍵底層算子的性能（§5.5）。
5.1 實(shí)驗(yàn)設(shè)置
我們的評(píng)估在華為云 ModelArts Lite（集群模式）服務(wù)提供的華為 CloudMatrix384 超級(jí)節(jié)點(diǎn)上進(jìn)行。具體來說，我們使用來自單個(gè) CloudMatrix384 的 256 個(gè)昇騰 910C NPU 及其關(guān)聯(lián)的主機(jī)鯤鵬 CPU 的配置。服務(wù)系統(tǒng)由華為和 SiliconFlow2 共同優(yōu)化的 LLM 推理引擎組成，部署了必要的華為 CANN 軟件包。華為云中的彈性內(nèi)存服務(wù)（EMS），如 §4.4 所述提供分布式緩存能力，已在分配的計(jì)算節(jié)點(diǎn)上預(yù)部署。整個(gè)部署遵循我們提出的具有 PDC 解耦的點(diǎn)對(duì)點(diǎn)服務(wù)架構(gòu)（§4.1），每個(gè)邏輯集群的具體配置如下：
解碼集群： 我們部署一個(gè)解碼實(shí)例，使用 160 個(gè)昇騰 910C NPU（跨越 20 個(gè)計(jì)算節(jié)點(diǎn)，產(chǎn)生 320 個(gè) NPU 芯片）。該實(shí)例對(duì)稀疏 MoE 層采用 320 路專家并行（EP320）。對(duì)于其他組件，如 MLA 和密集 FFN 層，在 NPU 芯片上使用 320 路數(shù)據(jù)并行（DP320）。在這 320 個(gè) EP 等級(jí)中，我們?cè)诿總€(gè)等級(jí)部署一個(gè)專家實(shí)例。專家配置包括 32 個(gè)共享專家副本、256 個(gè)不同的路由專家以及額外的 32 個(gè)冗余路由專家以促進(jìn)專家并行負(fù)載平衡（EPLB）。
預(yù)填充集群： 預(yù)填充集群包含 6 個(gè)預(yù)填充實(shí)例，每個(gè)實(shí)例分配 16 個(gè)昇騰 910C NPU（每個(gè)實(shí)例兩個(gè)計(jì)算節(jié)點(diǎn)，產(chǎn)生 32 個(gè) NPU 芯片）。預(yù)填充集群總共使用 96 個(gè) NPU。每個(gè)預(yù)填充實(shí)例對(duì)稀疏 MoE 層采用 32 路專家并行（EP32）。預(yù)填充實(shí)例內(nèi)的 MLA 組件使用 §4.3.1 詳述的混合并行策略。在每個(gè) 32 等級(jí)的預(yù)填充實(shí)例中，我們配置每個(gè)等級(jí) 10 個(gè)專家，包括 1 個(gè)共享專家、8 個(gè)路由選擇專家和 1 個(gè)冗余路由專家以實(shí)現(xiàn)有效的 EPLB。
緩存集群（EMS）： EMS 提供的分布式緩存通過利用構(gòu)成預(yù)填充和解碼集群的所有物理計(jì)算節(jié)點(diǎn)的主機(jī) CPU DRAM 實(shí)現(xiàn)。這些 32 個(gè)計(jì)算節(jié)點(diǎn)（20 個(gè)用于解碼集群 + 12 個(gè)用于預(yù)填充集群）上的鯤鵬 CPU 及其關(guān)聯(lián)的 DRAM 共同構(gòu)成了 UB 驅(qū)動(dòng)的解耦內(nèi)存池。
EMS 利用此池進(jìn)行模型緩存（§4.4.3）和上下文緩存（§4.4.2）。從所有 NPU 訪問此共享內(nèi)存池由 CloudMatrix384 的高速 UB 平面實(shí)現(xiàn)。
此實(shí)驗(yàn)配置作為后續(xù)章節(jié)精度和性能評(píng)估的基礎(chǔ)。評(píng)估的 DeepSeek-R1 模型是 671B 參數(shù)版本，已量化為 INT8（§4.5）以在昇騰 910C NPU 上執(zhí)行。
5.2 整體性能
在本節(jié)中，我們?cè)u(píng)估 CloudMatrix-Infer 相對(duì)于領(lǐng)先基線的整體性能，測(cè)量原始吞吐量和硬件效率（tokens/s/TFLOPS），包括預(yù)填充和解碼階段。我們將這些指標(biāo)與 DeepSeek 在 NVIDIA H800 GPU 上服務(wù) [12] 和 SGLang 在 NVIDIA H100 GPU 上 [53] 的公開性能數(shù)據(jù)進(jìn)行比較。我們的評(píng)估獨(dú)立評(píng)估預(yù)填充和解碼階段的性能，反映比較來源中報(bào)告的實(shí)驗(yàn)設(shè)置以便清晰分析。
預(yù)填充吞吐量。 我們首先檢查預(yù)填充吞吐量，這是高效處理輸入提示的關(guān)鍵因素。表 3 詳細(xì)列出了這些每加速器的比較。有效的 MoE 模型服務(wù)在預(yù)填充期間也顯著依賴于強(qiáng)大的 EPLB，正如 SGLang 的分析所強(qiáng)調(diào) [53]。DeepSeek (Profile) 數(shù)據(jù)具有高吞吐量（每個(gè) GPU 7,839 tokens/s），可能反映了接近理想專家負(fù)載平衡下的性能。為了提供與此類優(yōu)化場景可比較的分析基線，表 3 包括 SGLang 和 CloudMatrix-Infer 的完美 EPLB（Perfect EPLB）配置。這些結(jié)果代表了在完美負(fù)載分布跨專家的理想化假設(shè)下的預(yù)測(cè)性能。
在其默認(rèn)配置中，CloudMatrix-Infer 處理每個(gè) NPU 5,655 tokens/s?？紤]到每個(gè)昇騰 910C NPU 的計(jì)算能力為 1,504 TFLOPS (INT8)，這產(chǎn)生了 3.76 tokens/s/TFLOPS 的計(jì)算效率。這比 NVIDIA H100 上的 SGLang 默認(rèn)配置（3.18 tokens/s/TFLOPS）效率顯著更高，盡管后者的原始吞吐量略高。在測(cè)試的理想化“完美 EPLB”條件下，CloudMatrix-Infer 達(dá)到每個(gè) NPU 6,688 tokens/s，轉(zhuǎn)化為 4.45 tokens/s/TFLOPS 的效率，超過了 H100 上的 SGLang 理想效率（3.75 tokens/s/TFLOPS）和 H800 上的 DeepSeek profile（3.96 tokens/s/TFLOPS）。這些比較突顯了 CloudMatrix-Infer 的強(qiáng)大潛力，而我們的默認(rèn)結(jié)果和理想結(jié)果之間的差距凸顯了負(fù)載平衡算法進(jìn)一步改進(jìn)的機(jī)會(huì)。
解碼吞吐量。 接下來，我們分析自回歸解碼階段的性能，如表 4 詳述。我們?cè)u(píng)估目標(biāo)為低于 50 ms 的每輸出令牌時(shí)間（TPOT）SLO 的絕對(duì)解碼吞吐量（tokens/s），并評(píng)估按加速器計(jì)算能力歸一化的吞吐量（tokens/s/TFLOPS）作為計(jì)算效率的指標(biāo)。值得注意的是，SGLang (模擬 MTP) 和 CloudMatrix-Infer 配置都使用多令牌預(yù)測(cè)（MTP），假設(shè)單個(gè)推測(cè)令牌的有效接受率為 70%。
配置批次大小為每個(gè) NPU 96，KV 緩存長度為 4,096 令牌，CloudMatrix-Infer 實(shí)現(xiàn)了優(yōu)異的 TPOT 49.4 ms。在絕對(duì)系統(tǒng)吞吐量方面，CloudMatrix-Infer 在批次大小為 96 時(shí)產(chǎn)生每個(gè) NPU 1,943 tokens/s。這高于 DeepSeek (博客) H800 基線（每個(gè) GPU 1,850 tokens/s）。雖然在數(shù)值上低于 H800 上的 DeepSeek (Profile)（每個(gè) GPU 2,325 tokens/s）和 H100 上的 SGLang（每個(gè) GPU 2,172 tokens/s），但后兩個(gè)系統(tǒng)是使用更大的批次大小 128 進(jìn)行基準(zhǔn)測(cè)試的。每 TFLOPS 吞吐量指標(biāo)提供了對(duì)系統(tǒng)計(jì)算效率的進(jìn)一步洞察。CloudMatrix-Infer 實(shí)現(xiàn)了最高的計(jì)算效率（1.29 tokens/s/TFLOPS），高于 H100 上的 SGLang（1.10 tokens/s/TFLOPS）、H800 上的 DeepSeek (博客)（0.93 tokens/s/TFLOPS）和 H800 上的 DeepSeek (Profile)（1.17 tokens/s/TFLOPS）。這表明我們的服務(wù)解決方案在解碼期間有效利用了 CloudMatrix384 的可用計(jì)算能力。
我們還評(píng)估了 CloudMatrix-Infer 在不同 TPOT 服務(wù)級(jí)別目標(biāo)（SLO）和不同提示及輸出長度下的解碼吞吐量，如表 5 所示。結(jié)果顯示出明顯的趨勢(shì)：解碼吞吐量隨著組合提示和輸出長度的縮短而顯著增加。例如，當(dāng)提示和輸出長度各為 1,024 令牌時(shí)，解碼吞吐量達(dá)到每個(gè) NPU 2,733 tokens/s。當(dāng)提示長度增加到 2,048 令牌，輸出減少到 256 令牌時(shí)，此值降至每個(gè) NPU 2,360 tokens/s。這種改進(jìn)歸因于更短的總長度減少了每個(gè)請(qǐng)求所需的 KV 緩存空間，從而允許更大的批次大小。此外，隨著 TPOT SLO 變得更加嚴(yán)格，從 50 ms 到 15 ms，CloudMatrix-Infer 相應(yīng)地調(diào)整批次大小以滿足延遲目標(biāo)。在寬松的 50 ms SLO 下，CloudMatrix-Infer 支持批次大小 96 并實(shí)現(xiàn)每個(gè) NPU 1,943 tokens/s 的吞吐量，同時(shí)滿足延遲約束。當(dāng) SLO 收緊到 30 ms 和 15 ms 時(shí)，批次大小分別減少到 24 和 8，導(dǎo)致更低的吞吐量，分別為每個(gè) NPU 974 和 538 tokens/s。這些發(fā)現(xiàn)證明了 CloudMatrix-Infer 通過動(dòng)態(tài)調(diào)整批次大小以滿足不同延遲約束的能力，即使在嚴(yán)格的實(shí)時(shí)需求下也能保持高解碼吞吐量。
5.3 準(zhǔn)確性
為了全面評(píng)估量化為 INT8 并部署在 CloudMatrix384 上的 DeepSeek-R1 的推理精度（以下簡稱 DeepSeek-R1 (INT8)），我們基于廣泛使用的基準(zhǔn)測(cè)試進(jìn)行了廣泛測(cè)試。我們的評(píng)估重點(diǎn)是將 SilliconFlow 實(shí)現(xiàn)的 INT8 量化（§4.5）的精度與官方 DeepSeek-R1 API [10] 的結(jié)果及其技術(shù)報(bào)告 [13] 中發(fā)布的結(jié)果進(jìn)行比較。鑒于原始的 DeepSeek-R1 技術(shù)報(bào)告未完全公開每個(gè)基準(zhǔn)測(cè)試的所有測(cè)試參數(shù)，這可能導(dǎo)致直接復(fù)現(xiàn)存在差異，我們采用了針對(duì)實(shí)時(shí) DeepSeek-R1 API 的并行評(píng)估方法，以確保對(duì)實(shí)際性能進(jìn)行公平直接的比較。
我們的評(píng)估套件源自 DeepSeek-R1 技術(shù)報(bào)告和其他廣泛使用的基準(zhǔn)測(cè)試中的廣泛列表，包含 16 個(gè)不同的基準(zhǔn)測(cè)試，用于多方面的評(píng)估。排除的包括 AlpacaEval 2.0 [17] 和 Arena-Hard [36]，因?yàn)樗鼈円蕾?GPT-4 進(jìn)行評(píng)估（超出了我們當(dāng)前的設(shè)置），以及 CodeForces3，因?yàn)槿狈ΜF(xiàn)成的自動(dòng)化評(píng)估腳本。選定的基準(zhǔn)測(cè)試涵蓋了廣泛的能力：英語（MMLU [23], MMLU-Pro [9], DROP [16], IFEval [58], GPQA Diamond [50], SimpleQA [44]）、代碼生成（LiveCodeBench [31], HumanEval [7]）、數(shù)學(xué)（AIME 2024 [3], MATH-500 [24], CNMO 2024 [1], MGSM [51]）和中文（CLUEWSC [55], C-Eval [25], C-SimpleQA [22], C-MMLU [35]）。我們相信這個(gè)精選集為評(píng)估精度提供了堅(jiān)實(shí)的基礎(chǔ)。
為了評(píng)估的一致性，諸如 MMLU、DROP、MGSM、GPQA Diamond、HumanEval、MATH-500、SimpleQA 和 C-SimpleQA 等基準(zhǔn)測(cè)試的提示來源于 simple-evals 框架。其他，包括 CMMLU、C-Eval、LiveCodeBench、IFEval 和 CLUEWSC，使用 OpenCompass 框架?。遵循 DeepSeek-R1 技術(shù)報(bào)告中的方法，MMLU-Pro、C-Eval 和 CLUEWSC 在零樣本（zero-shot）設(shè)置下測(cè)試，而其他測(cè)試集遵循其原始協(xié)議。數(shù)學(xué)競賽基準(zhǔn)測(cè)試（AIME 2024 和 CNMO 2024）各經(jīng)過 32 次重復(fù)測(cè)試運(yùn)行以準(zhǔn)確估計(jì)其 pass@1 指標(biāo)。對(duì)于官方評(píng)估報(bào)告使用各種 GPT-4 版本的MATH-500、SimpleQA 和 C-SimpleQA 基準(zhǔn)測(cè)試，我們使用 Qwen2.5-72B-Instruct? 作為評(píng)分模型來評(píng)估 DeepSeek-R1 (INT8) 和 DeepSeek-R1 API 的輸出。雖然此選擇確保了本研究的內(nèi)部一致性，但在將我們的分?jǐn)?shù)與依賴基于 GPT-4 評(píng)分的 DeepSeek-R1 技術(shù)報(bào)告中的分?jǐn)?shù)比較時(shí)，可能會(huì)導(dǎo)致差異。關(guān)鍵生成參數(shù)包括溫度 0.6 和 top-p 0.95，與 DeepSeek-R1 技術(shù)報(bào)告 [13] 中指定的設(shè)置一致。
比較精度結(jié)果呈現(xiàn)在表 6 中?？傮w而言，我們?cè)跁N騰 910C 上的 DeepSeek-R1 (INT8) 實(shí)現(xiàn)展示了與官方 DeepSeek-R1 API 和原始技術(shù)論文中報(bào)告的指標(biāo)基本相當(dāng)?shù)男阅?。這表明為在昇騰 910C 上部署而應(yīng)用的 INT8 量化在廣泛的任務(wù)范圍內(nèi)有效保留了模型的能力。
5.4 消融研究
為了理解 CloudMatrix-Infer 中采用的關(guān)鍵優(yōu)化技術(shù)的個(gè)體貢獻(xiàn)和有效性，我們進(jìn)行了一系列消融研究。這些研究分離了我們的基于微批次的流水線策略（用于預(yù)填充和解碼階段）、多令牌預(yù)測(cè)（MTP）機(jī)制以及基于 EMS 的上下文緩存的影響。
5.4.1 基于微批次的流水線
此消融研究量化了基于微批次的流水線策略的性能影響，通過比較啟用和禁用這些微批次優(yōu)化時(shí)的系統(tǒng)性能。
解碼流水線。 我們首先評(píng)估了解碼階段的基于微批次流水線（先前在 §4.2.3 中詳述）。消融比較了系統(tǒng)在有和沒有此微批次優(yōu)化下的性能。
圖 20a 展示了不同批次大小下的解碼吞吐量。我們觀察到，啟用基于微批次的流水線將批次大小為 64、96 和 128 時(shí)的解碼吞吐量分別提高了 5.8%、9.4% 和 6.9%。盡管有益，但與為其他平臺(tái)報(bào)告的潛在改進(jìn)相比（例如 SGLang [53] 在 NVIDIA H100 集群上引用 35%），這種增益相對(duì)溫和。這種差異主要?dú)w因于 CloudMatrix384 上 MoE 分發(fā)和組合通信開銷固有的較低，這得益于其高性能 UB 平面（如第 5.5.1 節(jié)所述），而 NVIDIA GPU 集群通常使用 RDMA。在 UB 平面上較小的 MoE 通信停滯下，通過微批次隱藏通信的改進(jìn)上限自然對(duì) CloudMatrix384 更有限。
圖 20b 提供了批次大小為 96 時(shí)解碼執(zhí)行的每層延遲分解。它顯示，盡管像門控（Gating）、分發(fā)（Dispatch）和 MoE 這樣的階段的單個(gè)微批次執(zhí)行延遲由于每個(gè)流的計(jì)算資源減少（例如 AIC 從 24 減少到 16）而略有增加，但基于微批次的流水線顯著受益于整體性能。這是通過有效地為不同的微批次重疊注意力路徑（流 0）和 MoE 路徑（流 1）實(shí)現(xiàn)的，導(dǎo)致整體每層延遲減少約 10%，并相應(yīng)顯著提高了端到端解碼吞吐量。
預(yù)填充流水線。 接下來，我們檢查了提出的基于微批次的預(yù)填充流水線（在第 4.3.2 節(jié)詳述）的影響。圖 21a 顯示了在各種提示長度下啟用和未啟用此流水線時(shí)的預(yù)填充吞吐量。我們觀察到啟用基于微批次的流水線顯著提高了預(yù)填充吞吐量，在測(cè)試的配置中提高了 23% 到 31%。此外，預(yù)填充吞吐量隨著提示長度的增加而降低。這種趨勢(shì)發(fā)生是因?yàn)樽⒁饬τ?jì)算的每令牌執(zhí)行延遲隨提示長度增加。
圖 21b 提供了對(duì)應(yīng)請(qǐng)求執(zhí)行（4K 提示長度）的每層延遲分解。數(shù)據(jù)顯示，當(dāng)微批次流水線激活時(shí)，每層的整體執(zhí)行延遲減少了約 24%。這種顯著增益主要是通過將與通信相關(guān)的輕量級(jí)計(jì)算任務(wù)（例如 DispatchCompute、CombineCompute）卸載到 AIV，并指定 SDMA 引擎用于批量數(shù)據(jù)傳輸（例如用于 MoE 的 All-to-All）來實(shí)現(xiàn)的。該策略允許它們的執(zhí)行延遲與在 AIC 上執(zhí)行的核心計(jì)算（如 ATTN 和 FFN）有效重疊，從而提高了 NPU 利用率并減少了端到端預(yù)填充時(shí)間。
5.4.2 MTP
為了具體量化 MTP 機(jī)制在典型條件下的性能貢獻(xiàn)，我們進(jìn)行了一項(xiàng)有針對(duì)性的消融研究。此評(píng)估側(cè)重于 MTP 在每個(gè)解碼步驟生成單個(gè)推測(cè)令牌的場景，在 CloudMatrix384 上使用一致的輸入序列長度 4K 令牌。我們將啟用 MTP 的性能與在相同工作負(fù)載參數(shù)下的標(biāo)準(zhǔn)單令牌自回歸解碼（即禁用 MTP）基線進(jìn)行比較。
如圖 22a 所示，我們觀察到，與禁用 MTP 的基線相比，啟用帶有單個(gè)推測(cè)令牌的 MTP 在不同批次大小下將解碼吞吐量提高了 6% 到 49%。觀察到這種加速比在較小的批次大小下更為顯著。這種現(xiàn)象可能是因?yàn)樵谳^小的批次大小下，基線非 MTP 系統(tǒng)離其峰值效率更遠(yuǎn)（例如，由于固定每次迭代開銷分?jǐn)傒^少）。通過 MTP 接受的額外令牌（以 70% 的接受率）則提供了更大的相對(duì)吞吐量增益。隨著批次大小的增加，雖然 MTP 仍然能提供絕對(duì)收益，但其相對(duì)加速可能會(huì)減弱，因?yàn)榛€系統(tǒng)本身變得更加飽和，或者 MTP 自身的開銷變得更加突出。
然而，這種吞吐量提升伴隨著啟用 MTP 時(shí)每解碼層迭代執(zhí)行延遲的增加。如圖 22b 所示（批次大小 96），使用 MTP 使每層執(zhí)行延遲增加了約 44%（例如，從基線 874 us 增加到啟用 MTP 的 1,260 us）。這主要是因?yàn)槊總€(gè)啟用 MTP 的 LLM 解碼步驟從上一次迭代中處理每個(gè)請(qǐng)求的兩個(gè)輸入令牌：一個(gè)基礎(chǔ)令牌和一個(gè)推測(cè)令牌。這種更大的每迭代有效批次大小自然導(dǎo)致核心操作（如 Attention Core、Gating、Dispatch、MoE 和 Combine）的執(zhí)行時(shí)間更長。
盡管每次迭代延遲增加，但整體吞吐量提高了。以 70% 接受率成功驗(yàn)證推測(cè)令牌意味著，平均而言，每個(gè)啟用 MTP 的迭代產(chǎn)生 1.7 個(gè)令牌（1 個(gè)基礎(chǔ)令牌 + 0.7 個(gè)推測(cè)令牌）。這種每迭代令牌增益超過了約 44% 的更長迭代時(shí)間，確認(rèn)了我們的 MTP 實(shí)現(xiàn)在 CloudMatrix384 上用于 4K 序列長度工作負(fù)載的凈積極影響。
5.4.3 上下文緩存
在 §4.4 中引入的 EMS-上下文緩存機(jī)制通過存儲(chǔ)和重用先前請(qǐng)求的 KV 緩存塊來加速預(yù)填充階段。此消融研究定量評(píng)估了 EMS-上下文緩存在 CloudMatrix384 上的有效性，特別關(guān)注底層網(wǎng)絡(luò)結(jié)構(gòu)如何影響緩存訪問性能。具體來說，我們測(cè)量了輸入長度為 4K 令牌、批次大小包含每個(gè) NPU 16K 總令牌時(shí)的預(yù)填充吞吐量和首令牌時(shí)間（TTFT）。為了評(píng)估不同緩存命中率下的性能，我們調(diào)整了令牌重用率，該比率控制重用的歷史 KV 前綴的比例。本研究的一個(gè)核心目標(biāo)是比較 EMS 在兩種網(wǎng)絡(luò)配置下的性能：一種利用高帶寬 UB 互連，另一種回退到較慢的 VPC 網(wǎng)絡(luò)平面進(jìn)行緩存訪問。
圖 23 展示了作為令牌重用率函數(shù)的性能趨勢(shì)。如圖 23a 所示，兩種網(wǎng)絡(luò)配置下，吞吐量與重用率之間存在強(qiáng)正相關(guān)。對(duì)于帶 UB 的 EMS，將重用率從 12.5% 增加到 50% 導(dǎo)致預(yù)填充吞吐量增加了 1.42 倍。在 90% 重用率下，吞吐量比未使用 EMS 的基線提高了 2.28 倍。這種顯著提升發(fā)生是因?yàn)楦叩闹赜寐室馕吨斎胄蛄兄懈蟊壤?KV 緩存直接從 EMS 緩存加載而不是重新計(jì)算，顯著減少了預(yù)填充 NPU 上的計(jì)算負(fù)載。此外，在比較兩種網(wǎng)絡(luò)配置時(shí)，帶 UB 的 EMS 始終優(yōu)于帶 VPC 的 EMS。使用 UB 平面使預(yù)填充吞吐量提高了高達(dá) 1.52 倍。這種增益直接歸因于 UB 平面顯著更高的帶寬和更低的延遲，加速了從分布式 EMS 緩存到 NPU 的 KV 緩存塊加載。
同時(shí)，隨著令牌重用率的增加，TTFT 顯著降低，如圖 23b 所示。例如，使用帶 UB 的 EMS，50% 的令牌重用率相比無上下文緩存將 TTFT 減少了 861 ms（34%），而 90% 重用率導(dǎo)致 TTFT 減少了 1,505 ms（59%）。這種 TTFT 的顯著減少是繞過大量預(yù)填充計(jì)算（當(dāng)緩存命中時(shí)）的直接結(jié)果?？焖購?EMS 加載歷史 KV 緩存的能力，特別是通過高帶寬 UB 平面訪問并可能從解耦內(nèi)存池的 DRAM 層提供服務(wù)，直接轉(zhuǎn)化為更快的初始令牌生成。類似地，在所有重用率下，通過 UB 平面訪問 EMS 緩存比通過 VPC 平面產(chǎn)生始終更低的 TTFT，突顯了高性能互連對(duì)于延遲敏感緩存檢索的重要性。
5.5 算子性能
理解基本計(jì)算和通信算子的性能是診斷系統(tǒng)瓶頸和指導(dǎo)軟件優(yōu)化工作的關(guān)鍵。在本小節(jié)中，我們提出了與 LLM 服務(wù)相關(guān)的關(guān)鍵算子的微基準(zhǔn)分析，具體是 MoE通信原語、MLA 計(jì)算和通用矩陣乘法（GEMM）內(nèi)核。我們?cè)u(píng)估了它們?cè)?CloudMatrix384（每個(gè)昇騰 910C 芯片）上的性能，并與 NVIDIA H800 GPU 上的代表性性能進(jìn)行了比較。
5.5.1 通信算子
我們?cè)?CloudMatrix384 上使用 CANN 實(shí)現(xiàn)對(duì)關(guān)鍵的 MoE 通信算子（特別是分發(fā)（Dispatch）和組合（Combine））進(jìn)行了基準(zhǔn)測(cè)試。此實(shí)現(xiàn)詳述于我們?nèi)诤贤ㄐ潘阕拥脑O(shè)計(jì)中（§4.2.1）。性能與 DeepSeek 在 NVIDIA H800 GPU 上的 DeepEP 實(shí)現(xiàn) [56] 進(jìn)行了比較，如表 7 所示。該表展示了在不同 EP 度（#EP），從 8 到 256 個(gè)等級(jí)，每個(gè)等級(jí)批次為 128 的情況下，延遲和每等級(jí)實(shí)現(xiàn)的帶寬。
對(duì)于分發(fā)操作，CloudMatrix384（CM384）上的 CANN EP 實(shí)現(xiàn)在所有測(cè)試的 EP 度下始終顯示出比 H800 上的 DeepEP 更低的延遲。例如，在 EP 度 8 時(shí)，CM384 實(shí)現(xiàn) 116 us 的延遲，而 H800 記錄為 163 us。CM384 的這種延遲優(yōu)勢(shì)隨著 EP 度的增加而持續(xù)，在 EP256 時(shí) CM384 顯示 152 us，而 H800 為 194 us。在分發(fā)的每等級(jí)帶寬方面，CM384 在較小的 EP 度下表現(xiàn)出優(yōu)越的性能（例如，在 EP8 時(shí)為 71 GB/s 對(duì)比 46 GB/s）。然而，在大的 EP 度下，我們觀察到 CANN EP 在 CloudMatrix384 上的有效帶寬顯著下降。這種下降突顯了當(dāng)前 EP 實(shí)現(xiàn)中的可擴(kuò)展性瓶頸，我們將其留作未來優(yōu)化的途徑。
組合操作揭示了 CANN 在 CM384 上更顯著的性能優(yōu)勢(shì)。在所有 EP 規(guī)模下，CM384 上的延遲顯著降低。例如，在 EP8 時(shí)，CM384 的延遲為 118 us，而 H800 為 318 us。這種顯著的延遲減少一直保持到 EP256（CM384 為 149 us 對(duì)比 H800 360 us）。此外，CM384 上組合操作的每等級(jí)實(shí)現(xiàn)帶寬顯著高于 H800。在 EP8 時(shí)，CM384 提供 131 GB/s 每等級(jí)，幾乎是 H800 46 GB/s 的三倍。這種帶寬優(yōu)勢(shì)在所有測(cè)試的 EP 度上持續(xù)，CM384 在 EP256 時(shí)提供強(qiáng)勁的 103 GB/s 每等級(jí)，而 H800 提供 40 GB/s。
這些結(jié)果突顯了 CANN 集合通信庫以及 CloudMatrix384 的 UB 平面對(duì)于 MoE 特定通信模式的高效性。在 CloudMatrix384 上實(shí)現(xiàn)的持續(xù)較低延遲和較高每等級(jí)帶寬對(duì)于緩解大規(guī)模專家并行中固有的通信瓶頸至關(guān)重要。
5.5.2 MLA 算子
我們?cè)u(píng)估了在 CM384 上我們的 CANN MLA 實(shí)現(xiàn)的 TFLOPS 利用率和內(nèi)存帶寬利用率，與 NVIDIA H800 上的 DeepSeek 的 FlashMLA 在計(jì)算密集型和內(nèi)存密集型設(shè)置下進(jìn)行比較。
表 8 展示了當(dāng)工作負(fù)載主要是計(jì)算受限時(shí) MLA 算子的 TFLOPS 利用率。H800 上的 DeepSeek FlashMLA 實(shí)現(xiàn)了 660 TFLOPS (BF16/FP16)，報(bào)告硬件峰值為 989 TFLOPS，利用率為 66.7%。我們同樣在 BF16/FP16 下運(yùn)行的 CANN MLA 在 CloudMatrix384 上實(shí)現(xiàn)了 246 TFLOPS，NPU 配置的硬件峰值為 376 TFLOPS，產(chǎn)生了可比較的利用率 65.4%。這表明雖然由于硬件能力不同實(shí)現(xiàn)的絕對(duì) TFLOPS 不同，但在計(jì)算密集型場景下，利用可用計(jì)算能力進(jìn)行 MLA 的效率在兩個(gè)平臺(tái)上是相似的。
在內(nèi)存密集型設(shè)置下，有效利用可用內(nèi)存帶寬至關(guān)重要。表 9 展示了這一比較。H800 上的 DeepSeek FlashMLA 實(shí)現(xiàn)了令人印象深刻的 3,000 GB/s 內(nèi)存帶寬，占其 3,350 GB/s 硬件內(nèi)存帶寬的 89.6%。我們?cè)跁N騰 910C 芯片上實(shí)現(xiàn)的 CANN MLA 在所用 NPU 配置下實(shí)現(xiàn)了 1,346 GB/s，硬件內(nèi)存帶寬為 1,600 GB/s，產(chǎn)生了同樣高的利用率 84.1%。
5.5.3 GEMM 算子
通用矩陣乘法（GEMM）是幾乎所有深度學(xué)習(xí)模型的基本計(jì)算內(nèi)核。GEMM 操作的效率，特別是在 INT8 等較低精度下，對(duì)于實(shí)現(xiàn)高推理吞吐量至關(guān)重要。我們?cè)趩蝹€(gè)昇騰 910C 芯片（在 CloudMatrix384 系統(tǒng)內(nèi)）上對(duì) CANN 提供的 INT8 GEMM 內(nèi)核進(jìn)行了基準(zhǔn)測(cè)試。結(jié)果詳見表 10，展示了實(shí)現(xiàn)的 TFLOPS、相對(duì)于芯片峰值 INT8 硬件 TFLOPS 的計(jì)算利用率，以及這些操作期間的持續(xù)內(nèi)存帶寬。這些測(cè)試使用常見的 GEMM 分片維度（BM × BN = 128 × 152），操作涉及 INT8 輸入和 BF16 輸出。
表 10：在昇騰 910C 芯片（CloudMatrix384）上使用 INT8 輸入和 BF16 輸出的不同配置下的 INT8 GEMM 性能和實(shí)現(xiàn)的內(nèi)存帶寬。分片：BM × BN = 128 × 152。
如表 10 所示，昇騰 910C 芯片上的 CANN INT8 GEMM 內(nèi)核在不同矩陣形狀（M, N, K）和組數(shù)下，始終展示了高計(jì)算利用率，范圍從 77.4% 到 82.7%，基于芯片的 752 峰值 INT8 TFLOPS。例如，使用 4 組，維度 M=7168, N=4096, K=8192，內(nèi)核實(shí)現(xiàn)了 622 TFLOPS，對(duì)應(yīng) 82.7% 的利用率。這種高效率在不同配置下得以保持，表明昇騰 910C 芯片上 INT8 計(jì)算單元的穩(wěn)健性能。
該表還報(bào)告了這些 GEMM 操作期間實(shí)現(xiàn)的持續(xù)內(nèi)存帶寬，范圍從 195 GB/s 到 327 GB/s。這些值遠(yuǎn)低于昇騰 910C 芯片的峰值內(nèi)存帶寬（1,600 GB/s，如 MLA 算子分析 §5.5.2 所述）。結(jié)合高計(jì)算利用率數(shù)據(jù)，這一觀察強(qiáng)烈表明，對(duì)于測(cè)試的矩陣維度，這些 INT8 GEMM 操作主要是計(jì)算受限而非內(nèi)存帶寬受限。這種特性表明在 NPU 的內(nèi)部緩存層次結(jié)構(gòu)和寄存器中實(shí)現(xiàn)了高效的數(shù)據(jù)重用，允許計(jì)算單元在其峰值能力的高比例下運(yùn)行，而不會(huì)持續(xù)因來自內(nèi)存的數(shù)據(jù)傳輸而匱乏。
6. 未來方向討論
AI 模型的快速演進(jìn)及其普遍應(yīng)用繼續(xù)對(duì) AI 基礎(chǔ)設(shè)施提出日益嚴(yán)格的要求。雖然 CloudMatrix384 代表了擴(kuò)展緊密耦合 AI 計(jì)算的一個(gè)重要架構(gòu)里程碑，但需要進(jìn)一步演進(jìn)以滿足新興工作負(fù)載的需求。在本節(jié)中，我們討論了 CloudMatrix 架構(gòu)及其構(gòu)建的 LLM 服務(wù)系統(tǒng)的潛在未來方向，旨在進(jìn)一步增強(qiáng)可擴(kuò)展性、靈活性、效率和性能。
6.1 CloudMatrix 的未來演進(jìn)
CloudMatrix384 所體現(xiàn)的超級(jí)節(jié)點(diǎn)概念可以沿多個(gè)維度擴(kuò)展以適應(yīng)未來的 AI 工作負(fù)載。
6.1.1 統(tǒng)一 VPC 和 RDMA 平面
如 §3.2 所述，CloudMatrix384 目前為橫向擴(kuò)展（scale-out）和 VPC 流量使用獨(dú)立的網(wǎng)絡(luò)平面。然而，CloudMatrix 具有將橫向擴(kuò)展通信集成到 VPC 網(wǎng)絡(luò)中的潛力。在典型的 AI 訓(xùn)練和推理工作負(fù)載中，帶寬密集型通信階段（如張量、專家和序列并行（TP/EP/SP））主要包含在超級(jí)節(jié)點(diǎn)內(nèi)。相比之下，跨超級(jí)節(jié)點(diǎn)通信，主要源自數(shù)據(jù)和流水線并行（DP/PP），通常表現(xiàn)出低得多的帶寬需求。通過分層 DP 通信和通信隱藏技術(shù)，VPC 網(wǎng)絡(luò)可以充分滿足大多數(shù) AI 工作負(fù)載的跨超級(jí)節(jié)點(diǎn)通信需求。
基于此觀察，基于 VPC 平面的統(tǒng)一網(wǎng)絡(luò)架構(gòu)可以在可用區(qū)（AZ）規(guī)模上實(shí)現(xiàn)大規(guī)模 AI 集群的構(gòu)建。它容納了不同代的 AI 硬件，支持使用超級(jí)節(jié)點(diǎn)作為基本單元進(jìn)行靈活和模塊化擴(kuò)展，并通過數(shù)據(jù)中心網(wǎng)絡(luò)（DCN）技術(shù)實(shí)現(xiàn)跨區(qū)域的無縫互連。
6.1.2. 更大規(guī)模的超級(jí)節(jié)點(diǎn)
盡管 CloudMatrix384 提供了 384 個(gè) NPU 的龐大規(guī)模，但下一代 AI 模型和應(yīng)用場景預(yù)計(jì)將需要更大規(guī)模的超級(jí)節(jié)點(diǎn)。幾個(gè)關(guān)鍵因素推動(dòng)著向更大規(guī)模的趨勢(shì)：
擴(kuò)展以匹配模型演進(jìn)： 隨著 LLM 在參數(shù)規(guī)模和架構(gòu)復(fù)雜度上的持續(xù)擴(kuò)展，服務(wù)它們所需的基礎(chǔ)設(shè)施也必須相應(yīng)演進(jìn)。未來的模型預(yù)計(jì)將具有顯著更大的參數(shù)數(shù)量、更長的輸入序列以及越來越多的稀疏激活專家，特別是在 MoE 設(shè)計(jì)中。這些趨勢(shì)對(duì)每個(gè)推理會(huì)話中的計(jì)算、內(nèi)存和互連帶寬提出了更高的要求。此外，新興的架構(gòu)模式，例如用于專業(yè)推理的模塊化子網(wǎng)絡(luò)、檢索增強(qiáng)生成或混合稠密-稀疏計(jì)算，需要模型組件之間更緊密的耦合，導(dǎo)致模型內(nèi)通信和同步增加。高效支持這些工作負(fù)載需要將計(jì)算和內(nèi)存共置在單個(gè)緊密集成的超級(jí)節(jié)點(diǎn)內(nèi)，以最小化通信延遲并維持高吞吐量。因此，擴(kuò)展超級(jí)節(jié)點(diǎn)容量不僅對(duì)于滿足原始資源需求至關(guān)重要，而且對(duì)于維持下一代 LLM 所需的細(xì)粒度局部性和性能特征也至關(guān)重要。
-
提高資源分配效率： 擴(kuò)大超級(jí)節(jié)點(diǎn)規(guī)模也提高了現(xiàn)實(shí)世界異構(gòu)工作負(fù)載條件下系統(tǒng)范圍的資源利用率?；谡鎸?shí)的生產(chǎn)跟蹤，我們通過將每個(gè) AI 任務(wù)建模為一組緊密耦合塊（tightly-coupled blocks）來模擬未來的 NPU 請(qǐng)求模式，其中每個(gè)塊是必須在單個(gè)超級(jí)節(jié)點(diǎn)內(nèi)供應(yīng)的連續(xù) NPU 組，以滿足任務(wù)內(nèi)帶寬和延遲約束。如圖 24 所示，在廣泛的平均塊大小范圍內(nèi)，更大的超級(jí)節(jié)點(diǎn)始終實(shí)現(xiàn)更高的 NPU 分配率。例如，在平均塊大小 10.08 時(shí)，384-NPU 超級(jí)節(jié)點(diǎn)實(shí)現(xiàn)了超過 94% 的分配率，而 224-NPU 超級(jí)節(jié)點(diǎn)則降至 91% 以下。這種改進(jìn)源于減少的碎片和更好的統(tǒng)計(jì)復(fù)用——更大的資源池為非均勻作業(yè)大小提供了更大的放置靈活性。相反，對(duì)于固定大小的超級(jí)節(jié)點(diǎn)，增加塊大小會(huì)導(dǎo)致分配效率降低，因?yàn)榇虬щy。當(dāng)平均塊大小達(dá)到 11.28 時(shí)，224-NPU 超級(jí)節(jié)點(diǎn)的分配率降至 85% 以下。這些結(jié)果突顯了在現(xiàn)實(shí)工作負(fù)載分布下，擴(kuò)展超級(jí)節(jié)點(diǎn)規(guī)模顯著提高了系統(tǒng)吞吐量和效率。
圖 24. 不同超級(jí)節(jié)點(diǎn)規(guī)模和緊密耦合塊大小下的 NPU 分配率 幾乎恒定的分?jǐn)偩W(wǎng)絡(luò)成本： 擴(kuò)大超級(jí)節(jié)點(diǎn)的規(guī)模并不會(huì)導(dǎo)致更高的每 NPU 網(wǎng)絡(luò)成本。在相同的網(wǎng)絡(luò)架構(gòu)下，例如類似 2 層 Clos 的交換拓?fù)?，只要配置?shí)現(xiàn)交換機(jī)端口的完全利用，每 NPU 的網(wǎng)絡(luò)基礎(chǔ)設(shè)施分?jǐn)偝杀驹诓煌?jí)節(jié)點(diǎn)規(guī)模下幾乎保持不變。如表 11 所示，具有 192、288 或 384 個(gè) NPU 的配置都實(shí)現(xiàn)了 100% 的交換機(jī)利用率，且每節(jié)點(diǎn)分?jǐn)偨粨Q機(jī)成本相同。中間配置，如 256 或 352 個(gè) NPU，存在交換機(jī)未充分利用的問題，略微增加了每節(jié)點(diǎn)成本。這些結(jié)果表明，將超級(jí)節(jié)點(diǎn)規(guī)模擴(kuò)展到給定交換層的上限不會(huì)引入額外的成本開銷，從網(wǎng)絡(luò)角度來看是一種成本效益高的策略。
- 適應(yīng)增加的資源異構(gòu)性： 未來的 AI 工作負(fù)載將需要在同一執(zhí)行上下文中支持日益多樣化的硬件。除了 NPU 和 CPU，下一代超級(jí)節(jié)點(diǎn)可能會(huì)納入專用加速器，用于物理模擬、實(shí)時(shí)視頻處理、無損數(shù)據(jù)壓縮和密碼計(jì)算等任務(wù)。這些單元正在成為端到端 AI 流水線中必不可少的組成部分，特別是對(duì)于多模態(tài)或特定領(lǐng)域的應(yīng)用。為了有效利用，此類異構(gòu)資源必須共享相同的高帶寬、低延遲互連結(jié)構(gòu)，并在超級(jí)節(jié)點(diǎn)內(nèi)作為一流計(jì)算對(duì)等體可訪問。在大規(guī)模支持這種多樣性需要擴(kuò)展超級(jí)節(jié)點(diǎn)規(guī)模和更靈活的互連架構(gòu)，進(jìn)一步強(qiáng)化了朝著更大、更異構(gòu)的計(jì)算域發(fā)展的趨勢(shì)，以處理緊密耦合、跨功能的 AI 工作負(fù)載。
6.1.3. CPU 的物理解耦與池化
雖然當(dāng)前的 CloudMatrix384 超級(jí)節(jié)點(diǎn)已經(jīng)通過池化其計(jì)算節(jié)點(diǎn)（每個(gè)節(jié)點(diǎn)集成 4 個(gè)鯤鵬 CPU 和 8 個(gè)昇騰 NPU）中的 CPU 和 NPU 實(shí)現(xiàn)了某種程度的資源靈活性，但 CloudMatrix 架構(gòu)的一個(gè)關(guān)鍵未來方向涉及更根本的 CPU 和 NPU 資源的物理解耦，如圖 1 所示。這設(shè)想了一個(gè)由不同的、專用節(jié)點(diǎn)類型構(gòu)建的超級(jí)節(jié)點(diǎn)：密集集成 AI 加速器的以 NPU 為中心的節(jié)點(diǎn)，以及提供大量通用計(jì)算、內(nèi)存容量和 I/O 能力的以 CPU 為中心的節(jié)點(diǎn)。這些異構(gòu)節(jié)點(diǎn)類型將通過高帶寬、低延遲的 UB 網(wǎng)絡(luò)平面互連，實(shí)現(xiàn)在超級(jí)節(jié)點(diǎn)級(jí)別的細(xì)粒度、靈活和可擴(kuò)展的資源池化。
物理解耦的動(dòng)機(jī)源于傳統(tǒng) CPU-NPU 配對(duì)在固定節(jié)點(diǎn)配置中的僵化性，其中靜態(tài)的 NPU 與 CPU 比例限制了系統(tǒng)匹配工作負(fù)載需求的能力。例如，一些推理工作負(fù)載需要密集的 CPU 前/后處理或大型內(nèi)存支持的緩存，導(dǎo)致 CPU 瓶頸，而 NPU 閑置。相反，訓(xùn)練工作負(fù)載可能使 NPU 飽和，而 CPU 資源未充分利用。在這種情況下，緊密耦合的 CPU-NPU 配置導(dǎo)致硬件利用次優(yōu)和擴(kuò)展不靈活。
盡管 CloudMatrix384 的點(diǎn)對(duì)點(diǎn) UB 拓?fù)湟呀?jīng)將邏輯資源分配解耦，實(shí)現(xiàn)了跨超級(jí)節(jié)點(diǎn)的靈活 CPU-NPU 匹配，但將 CPU 和 NPU 資源物理分離為專用資源池釋放了進(jìn)一步的優(yōu)勢(shì)：
獨(dú)立和優(yōu)化的擴(kuò)展： 可以開發(fā)物理上獨(dú)立的以 NPU 為中心的節(jié)點(diǎn)（例如，具有用于基本管理的最小本地 CPU 但最大化 NPU 密度）和以 CPU 為中心的節(jié)點(diǎn)（例如，具有許多 CPU 核心、大容量 DRAM 和豐富 I/O 選項(xiàng)，作為超級(jí)節(jié)點(diǎn)主要的 CPU 和內(nèi)存資源池）。這使得超級(jí)節(jié)點(diǎn)的 NPU 計(jì)算能力和通用 CPU/內(nèi)存能力能夠獨(dú)立且更經(jīng)濟(jì)地?cái)U(kuò)展。數(shù)據(jù)中心運(yùn)營商然后可以組合具有高度可變的 NPU 與 CPU/內(nèi)存比例的超級(jí)節(jié)點(diǎn)，精確地針對(duì)主導(dǎo)工作負(fù)載（例如，用于訓(xùn)練的 NPU 密集型，用于數(shù)據(jù)密集型預(yù)處理或大規(guī)模 EMS 緩存的 CPU/內(nèi)存密集型）進(jìn)行定制。
增強(qiáng)的資源利用率和專業(yè)化： 專用節(jié)點(diǎn)設(shè)計(jì)允許針對(duì)主要資源類型進(jìn)行硬件優(yōu)化。NPU 節(jié)點(diǎn)可以專注于加速器的電源輸送和冷卻，而 CPU/內(nèi)存 節(jié)點(diǎn)可以優(yōu)化內(nèi)存密度、I/O 帶寬或特定 CPU 指令集。與一刀切的混合節(jié)點(diǎn)設(shè)計(jì)相比，這可以帶來更好的整體效率和每種資源類型的性能。
6.2 未來服務(wù)系統(tǒng)增強(qiáng)
隨著底層超級(jí)節(jié)點(diǎn)架構(gòu)的持續(xù)演進(jìn)，LLM 服務(wù)系統(tǒng)必須共同演進(jìn)以充分利用這些能力。一個(gè)關(guān)鍵方向是超越粗粒度解耦（例如預(yù)填充-解碼分離），轉(zhuǎn)向更細(xì)粒度的組件級(jí)解耦和智能的、自適應(yīng)的部署策略。這些方法旨在提高資源利用率、提升吞吐量，并支持日益異構(gòu)的工作負(fù)載和硬件配置。
6.2.1 組件級(jí)解耦
CloudMatrix384 中使用的具有預(yù)填充-解碼-緩存（PDC）解耦的點(diǎn)對(duì)點(diǎn)服務(wù)架構(gòu)已被證明在分離 LLM 推理的主要階段方面是有效的。然而，通過將模型執(zhí)行分解為更細(xì)粒度的組件（這些組件可以被獨(dú)立管理、部署和擴(kuò)展），可以實(shí)現(xiàn)進(jìn)一步的改進(jìn)。我們強(qiáng)調(diào)兩個(gè)新興方向：
解碼-注意力解耦與卸載： 雖然預(yù)填充實(shí)例是計(jì)算受限的，解碼實(shí)例通常是內(nèi)存受限的，但 Adrenaline 系統(tǒng) [37] 表明，通過將內(nèi)存密集型的注意力計(jì)算從解碼路徑中解耦并卸載到未充分利用的預(yù)填充實(shí)例，可以獲得額外的性能提升。這種方法提高了整體內(nèi)存帶寬利用率，并在解碼實(shí)例上支持更大的批次大小，從而提高計(jì)算效率。它依賴于低延遲同步、卸載任務(wù)的仔細(xì)共置以及 SLO 感知的卸載策略。結(jié)果是提高吞吐量而不影響延遲，例證了注意力解耦如何釋放現(xiàn)有服務(wù)部署中的潛在容量。
注意力和 MoE 解耦： 大規(guī)模 MoE 模型因稀疏專家激活和極端內(nèi)存需求而帶來獨(dú)特挑戰(zhàn)。MegaScale-Infer [59] 提議將注意力和專家組件解耦為獨(dú)立的執(zhí)行服務(wù)，實(shí)現(xiàn)不同的并行策略和硬件映射。處理每個(gè)令牌的注意力層部署在使用數(shù)據(jù)并行（DP）的內(nèi)存優(yōu)化節(jié)點(diǎn)上，而專家 FFN 則通過專家并行（EP）分布在專用資源池上。這種解耦執(zhí)行減少了爭用，提高了吞吐量，并允許獨(dú)立擴(kuò)展注意力和專家資源，這對(duì)于高效服務(wù)數(shù)萬億參數(shù)的 MoE 模型至關(guān)重要。
總之，這些解耦技術(shù)代表了一種將 LLM 視為松散耦合的微服務(wù)集合的轉(zhuǎn)變，每個(gè)微服務(wù)具有不同的性能特征。這種細(xì)粒度允許更好地映射到異構(gòu)硬件，并改善了超級(jí)節(jié)點(diǎn)上的負(fù)載平衡和可擴(kuò)展性。
6.2.2 混合與自適應(yīng)部署
一旦 LLM 推理被分解為組件，這些組件可以被視為細(xì)粒度的微服務(wù)，例如注意力執(zhí)行、FFN 計(jì)算、KV 緩存管理或 MoE 專家門控，服務(wù)系統(tǒng)就獲得了采用更復(fù)雜部署策略的顯著靈活性。這些混合和自適應(yīng)部署模型使系統(tǒng)能夠根據(jù)每個(gè)組件的獨(dú)特計(jì)算和內(nèi)存需求定制資源分配，提高整體利用率和可擴(kuò)展性。
硬件感知的微服務(wù)放置： 每個(gè)微服務(wù)可以根據(jù)其性能特征映射到最合適的硬件類型。例如，通常受內(nèi)存帶寬限制的注意力層應(yīng)優(yōu)先放置在具有高內(nèi)存吞吐量的 NPU 上；計(jì)算密集型的 FFN 模塊受益于在具有強(qiáng)大計(jì)算能力的 NPU 上分配；而輕量級(jí)或延遲容忍的操作，如 KV 緩存索引，可以卸載到池化的 CPU 或低成本通用加速器上。這種細(xì)粒度的匹配能夠更有效地利用異構(gòu)硬件，并在不影響性能的情況下降低成本。
混合微服務(wù)共置： 解耦的微服務(wù)也可以動(dòng)態(tài)共置以提高整個(gè)超級(jí)節(jié)點(diǎn)的資源利用率。例如，來自解碼階段的內(nèi)存受限的注意力操作可以卸載到內(nèi)存未充分利用的預(yù)填充實(shí)例 [37]。這種混合共置策略有助于緩解資源瓶頸，提高各階段間的利用率，并增加有效系統(tǒng)吞吐量，特別是在可變或突發(fā)工作負(fù)載下。
微服務(wù)的自適應(yīng)和獨(dú)立擴(kuò)展： 微服務(wù)解耦的一個(gè)關(guān)鍵優(yōu)勢(shì)是能夠根據(jù)實(shí)時(shí)工作負(fù)載特征獨(dú)立擴(kuò)展每個(gè)組件。例如，在處理長上下文輸入時(shí)，注意力微服務(wù)可能經(jīng)歷更高負(fù)載并相應(yīng)擴(kuò)展，而不需要額外的 FFN 或?qū)＜屹Y源。這種細(xì)粒度防止了系統(tǒng)性過度配置，并允許系統(tǒng)彈性適應(yīng)工作負(fù)載動(dòng)態(tài)。
為了充分利用這些能力，服務(wù)基礎(chǔ)設(shè)施必須包含一個(gè)復(fù)雜的編排層，能夠持續(xù)分析系統(tǒng)負(fù)載，預(yù)測(cè)性能瓶頸，并做出實(shí)時(shí)、SLO 感知的調(diào)度和擴(kuò)展決策。該編排器作為混合部署模型的控制平面，確保即使在工作負(fù)載和資源可用性波動(dòng)時(shí)也能滿足性能保證。
總之，由組件級(jí)解耦支持的混合和自適應(yīng)部署策略代表了 LLM 服務(wù)系統(tǒng)設(shè)計(jì)的一個(gè)有前景的前沿。它們?cè)试S更精確的資源利用，跨異構(gòu)硬件的無縫負(fù)載平衡，并能夠滿足日益復(fù)雜和多樣化的模型架構(gòu)帶來的未來需求。
7. 結(jié)論
在本文中，我們介紹了華為 CloudMatrix，一個(gè)體現(xiàn)華為先進(jìn) AI 基礎(chǔ)設(shè)施愿景的下一代 AI 數(shù)據(jù)中心架構(gòu)。我們特別強(qiáng)調(diào)了華為 CloudMatrix384，這是這一創(chuàng)新架構(gòu)理念的首個(gè)生產(chǎn)級(jí)實(shí)現(xiàn)。CloudMatrix384 是一個(gè)專為高效支持大規(guī)模 AI 工作負(fù)載而設(shè)計(jì)的 AI 超級(jí)節(jié)點(diǎn)，采用全點(diǎn)對(duì)點(diǎn)互連的硬件設(shè)計(jì)。它集成了 384 個(gè)昇騰 910C NPU 和 192 個(gè)鯤鵬 CPU，通過超高帶寬、低延遲的統(tǒng)一總線（UB）網(wǎng)絡(luò)互連。這種獨(dú)特的架構(gòu)促進(jìn)了動(dòng)態(tài)資源池化、簡化的內(nèi)存管理和卓越的節(jié)點(diǎn)間通信，有效解決了傳統(tǒng)數(shù)據(jù)中心架構(gòu)中常見的可擴(kuò)展性和效率挑戰(zhàn)。
利用 CloudMatrix384，我們提出了 CloudMatrix-Infer，一個(gè)全面的服務(wù)解決方案，其點(diǎn)對(duì)點(diǎn)服務(wù)架構(gòu)將推理工作流解耦為不同的預(yù)填充、解碼和緩存子系統(tǒng)。該架構(gòu)通過實(shí)現(xiàn)對(duì)所有 NPU 的共享解耦內(nèi)存池的統(tǒng)一訪問，顯著簡化了調(diào)度，增強(qiáng)了負(fù)載平衡并優(yōu)化了資源利用率。我們進(jìn)一步設(shè)計(jì)和實(shí)現(xiàn)了先進(jìn)的硬件感知技術(shù)，包括大規(guī)模專家并行（LEP）、優(yōu)化的通信和 MLA 算子、基于微批次的流水線和 INT8 量化。這些技術(shù)共同提升了 MoE 和 MLA 計(jì)算吞吐量，提高了緩存效率，并為整體推理性能帶來了顯著提升。
我們使用 DeepSeek-R1 模型進(jìn)行的廣泛評(píng)估表明，CloudMatrix-Infer 實(shí)現(xiàn)了卓越的吞吐量，在預(yù)填充階段達(dá)到每個(gè) NPU 6,688 tokens/s，在解碼期間達(dá)到每個(gè) NPU 1,943 tokens/s，同時(shí)持續(xù)保持低于 50 ms 的每輸出令牌延遲。這些結(jié)果對(duì)應(yīng)于預(yù)填充 4.45 tokens/s/TFLOPS 和解碼 1.29 tokens/s/TFLOPS 的計(jì)算效率，兩者都超過了在 NVIDIA H100 上的 SGLang 和在 H800 上的 DeepSeek 等領(lǐng)先框架的已發(fā)布效率。此外，CloudMatrix-Infer 有效管理了吞吐量-延遲權(quán)衡，即使在更嚴(yán)格的低于 15 ms TPOT 約束下也能維持 538 tokens/s 的吞吐量。INT8 量化策略在廣泛的基準(zhǔn)測(cè)試中進(jìn)一步保持了與 DeepSeek 官方 API 相當(dāng)?shù)木取?/p>
展望未來，有幾個(gè)令人興奮的方向可以進(jìn)一步增強(qiáng) CloudMatrix384。未來的工作包括集成和統(tǒng)一 VPC 和 RDMA 網(wǎng)絡(luò)平面以實(shí)現(xiàn)更簡化的互連，擴(kuò)展到更大的超級(jí)節(jié)點(diǎn)配置，以及追求 CPU 資源的更深層次解耦和池化。此外，更細(xì)粒度的組件級(jí)解耦和自適應(yīng)部署策略為實(shí)現(xiàn) AI 數(shù)據(jù)中心基礎(chǔ)設(shè)施的更大靈活性、效率和可擴(kuò)展性提供了有前景的途徑。
總之，我們的研究結(jié)果驗(yàn)證了華為 CloudMatrix 作為部署大規(guī)模 AI 工作負(fù)載的高效、可擴(kuò)展和性能優(yōu)化的平臺(tái)，為未來的 AI 數(shù)據(jù)中心基礎(chǔ)設(shè)施樹立了標(biāo)桿。
