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 等主流推理框架后验证。