NVIDIA 詳解 Helix 並行：百萬 token 即時推理，併發提升 32 倍

如果你試過給大模型塞進去一整套法律卷宗、幾個月的聊天記錄或者幾百萬行的程式碼庫，就會發現一個很現實的問題：模型回答起來慢得像在擠牙膏。

在生成每一個新字時，GPU 不僅要重新掃一遍幾百萬 token 的歷史記憶（KV cache），還得從視訊記憶體裡讀取巨大的前饋網路（FFN）權重。這兩項都在瘋狂吃 DRAM 頻寬，常規的張量並行（TP）在長上下文面前根本玩不轉，尤其是遇到 Llama 的 GQA 甚至 DeepSeek 的 MLA 時，多張顯示卡還會被迫複製同一份歷史記憶，視訊記憶體頻寬直接被擠爆。

NVIDIA 團隊公開了一項針對自家 Blackwell 架構量身定製的全新推理並行策略：Helix Parallelism（螺旋並行）。它專門解決幾百萬 token 級超長上下文的即時生成瓶頸。

把注意力與 FFN 拆開跑

Helix 的思路像它的名字一樣，借鑑了 DNA 雙螺旋結構。它沒有用一套固定的並行方案跑通一整個 Transformer 層，而是把注意力階段和 FFN 階段解耦開來。

在注意力階段，系統採用 KV 並行（KVP），把幾百萬 token 的記憶順著序列長度切碎，分給不同顯示卡。張量並行被限制在 KV 頭數以內，徹底杜絕了多張卡重複存放同一段歷史記憶的浪費。

算完區域性的注意力後，顯示卡之間只用一次 All-to-All 交換結果。這筆通訊開銷只和批處理大小以及隱藏維度有關，哪怕上下文拉到幾百萬 token，通訊量也不會膨脹。緊接著，系統用細粒度的流水線（HOP-B）讓下一個請求的計算和當前請求的通訊重疊進行，直接把通訊耗時藏了起來。

到了 FFN 階段，剛才那組顯示卡無縫重組成張量並行模式。如果是類似 DeepSeek 這種 MoE 混合專家模型，則切分成張量並行加專家並行（TP x EP）。從頭到尾，同一批 GPU 沒有一秒鐘在乾等。

為了防止寫入新記憶時視訊記憶體受熱不均，Helix 還搞了類似分發機制的輪詢更新：比如前 16 個 token 存第一張卡，後面 16 個存第二張卡，讓視訊記憶體負載始終均勻。

模擬成績：併發直接飆升 32 倍

根據 NVIDIA 基於 Blackwell 架構（特別是 NVLink 72 互連和 FP4 計算）的詳盡模擬測試，Helix 在 100 萬 token 上下文的 DeepSeek-R1（671B 引數）推理中拿出了驚人的表現。

在固定延遲預算下，Helix 能承受的併發使用者數最多提升了 32 倍，換算下來也就是單卡吞吐量拉高了 32 倍。

如果是在低併發、純粹追求打字機速度的互動場景下，單字生成延遲（TTL）也能降低最多 1.5 倍。

為什麼重要

我們認為，Helix 是大模型長上下文落地的關鍵解藥之一。

現在的長文本大模型看起來很美，但商用最大的阻礙就是貴和慢。使用者塞一本百科全書進去，往往要等很久才能擠出幾個字，而且雲廠商為了保延遲只能大幅壓低併發，算力成本高到令人肉痛。如果 Helix 隨 Blackwell 系統落地，企業搭建能讀整套案卷的 AI 律師、能吃完整程式碼庫的 Copilot，成本會斷崖式下降。

更值得玩味的是它的軟硬體繫結。Helix 極其依賴極高頻寬的 GPU 互聯，它頻繁的 All-to-All 通訊和動態重組，本質上就是給 Blackwell NVL72 這種大域互聯定製的。這看起來是 NVIDIA 又一次用底層系統架構給競品設立高牆：別人就算做出了單卡算力相近的晶片，只要卡間互聯頻寬跟不上，依然跑不動這種超長上下文的高併發流水線。

不過，目前公佈的資料來自數千種配置的系統級模擬，並非真實叢集的大規模實測資料。在真實業務複雜的動態請求下，動態重組會不會引入意料之外的排程開銷，還有待官方把它合併進 TensorRT-LLM 等主流推理框架後驗證。