80GB H100实测：35B模型对话仅需3B算力

在AI基础设施的讨论中，一个常见的误区是把"模型能否装进显存"和"模型能否流畅对话"画上等号。一位开发者在80GB显存的H100上部署35B参数模型的实际经历，揭示了这两个问题之间的巨大鸿沟。

显存充足不等于对话流畅

这位开发者使用了一台配备80GB显存的H100 GPU，硬件成本约为500万日元（约3.5万美元）。按照直觉，这样的配置应该能够轻松运行大型模型并进行流畅对话。

然而现实是，他最终只能有效地运行一个3B参数的模型——而且这还不包括语音功能。整个模型有35B参数，但在每次生成token时，只有相当于3B的权重被实际使用。

问题的核心在于：对话的流畅度取决于响应延迟。如果提问和回答之间等待时间过长，即使回答再聪明，对话也会显得不自然。大模型每个token需要大量计算，直接影响响应速度。

能否装进显存，与是否适合对话，是两个完全不同的问题。

为什么大模型每个 token 的计算量如此巨大？

自回归语言模型生成一个 token，需要对整个模型做一次前向传播。以稠密（Dense）架构为例，一个 35B 参数的模型，每生成一个 token，就要把全部 35B 权重与激活值参与矩阵乘运算。计算量大致与「参数量 × 输入 token 数」成正比，而显存占用则主要由「参数量 × 权重精度字节数」决定。

这种差别意味着：显存只决定模型能否被「放下」，而计算量决定每个 token 要等多久。一个 35B 模型以 FP16 存储约占 70GB 显存，勉强能塞进 80GB H100，但每 token 需要约 70 亿次以上的乘加运算，在单卡上延迟可能高达数百毫秒甚至秒级，这正是对话变得卡顿的根源。相比之下，量化权重和 KV Cache 管理同样影响延迟，但都无法改变「稠密模型每 token 必须激活全部参数」这一根本约束。

小模型为何无法胜任对话任务

为了降低计算成本、提升响应速度，开发者尝试了更小的模型。但他构建的是一个对话路由分类器，需要根据用户的单次话语判断"请求类型"。

小模型在理解上下文连续性方面表现不佳。例如"这次加上--watch跑同样的东西"这句话，依赖于之前的操作上下文。仅看文本本身将其作为独立的新请求处理，很容易丢失意图。

在分类任务中，模型间的差异在"前一个操作的延续"这类话语上尤其明显。单纯缩小模型规模，无法同时保持理想的响应速度和意图理解能力。

MoE架构的关键优势

保持整体模型规模较大、同时减少每个词的计算量——MoE（混合专家）架构提供了解决思路。

MoE通过多个专家网络中选择最优专家来处理输入，只选择性激活必要的子网络。开发者采用了Qwen3.6-35B-A3B模型：整体拥有35B权重，但处理每个词时只使用3B权重。

该模型的计算成本与普通4B、8B模型相当，在自己的网关（vLLM）上运行。

实测数据对比

在判断用户话语请求类型的任务中：

• Qwen3.6-35B-A3B：准确率92.6%，判断时间306ms
• 普通qwen3:8b和qwen3.5:4b：准确率约82%

在"前一操作延续"类话语上差距更为显著：35B-A3B准确率86.3%，而4B和8B模型仅70.4%。

对话中短话语往往依赖前文语境，准确理解这类话语成为选择该模型的关键理由。

不过这些数据仅反映文本判断结果，不包含语音识别（STT）和语音合成（TTS）。如需语音对话，还需额外计算时间和GPU显存，具体增幅难以量化。

MoE 中的「A3B」到底是什么意思？

Qwen3.6-35B-A3B 这类命名中，「35B」指模型总参数量，「A3B」中的 A 代表 Activated（激活），即每次前向传播时实际参与计算的参数量约为 3B。MoE 层通常由若干「专家」前馈网络和一个路由网络组成，路由网络根据当前 token 决定把它分配给哪几个专家（一般 top-k，k 常取 2 或 4）。

这样做的结果是：总参数可以做得很大以增强表达能力，但单 token 的计算量只与激活参数成正比，因此吞吐和延迟表现接近一个 3B 稠密模型。代价是显存仍需容纳全部专家权重，且路由、负载均衡、专家并行会带来额外工程复杂度，这也是为什么 MoE 模型往往更适合显存充裕但算力受延迟约束的场景。

对话路由分类器为何对上下文如此敏感？

路由分类器本质上是一个意图判别任务：它要在用户只说半句话、甚至只补一句「同样的东西再来一遍」时，判断该调用哪个工具或走哪条流程。这类话语的语义几乎完全依赖前几轮的对话历史，一旦模型把当前句子当成孤立输入，就会把「延续」误判为「新请求」。

参数更小的模型之所以在这类任务上掉得多，是因为它们对长上下文中的指代、省略、省略主语等现象建模能力较弱。而研究者通常用「延续性话语准确率」单独评估这一能力，因为它能暴露出平均准确率掩盖掉的边界情况。在实际对话系统中，这类误判往往比一次答错更影响体验，因为它可能导致重复执行或错误调用工具。

对话系统选型的多维考量

开发者此前曾撰文讨论"单张GPU可承载四个AI虚拟形象"的720p30实时推流方案。即便在那时，GPU也不是瓶颈。

讨论LLM时，如果只看GPU显存，会忽略很多关键因素：

• 模型能否装进80GB？
• 每个token需要多少计算量？
• 接收文本到返回响应的延迟是多少？
• 如果通过语音交互，还需叠加STT和TTS的时间和显存开销

即使使用相同的GPU，多种因素共同决定系统是否真正可用于对话。

这位开发者的结论是：GPU容量和对话响应性必须从不同角度考量。即使总模型达到35B，如果每个token的计算量相当于3B模型，它仍然是可行的候选方案。单纯切换到更小的模型，不足以维持结果的准确性。

选择GPU时，应关注"每个token做多少计算"，而非仅看显存大小。