多卡 GPU 整机实测：122B MoE 模型首字 287ms、310/310 零错误

为什么要做这组测试

私有化部署里最常被问到的一个问题是："离开云端，我的推理性能会掉到什么程度？"

这个问题没法用参数表回答，只能用同一套真实推理链路的实测数据回答。我们在自研的液冷多卡 GPU 整机上做了一组完整压测：122B 参数 MoE 模型（激活参数 10B）、Int4 量化、32K 运行上下文，覆盖并发扫描、持续压力和输出质量三个维度。

关于硬件配置需要先说明一点：这套整机的 GPU 卡型是可替换的。多卡 PCIe 架构本身就是为选配设计的——同一套液冷机箱与散热方案，可以按客户预算和场景装配不同代际、不同显存规格的加速卡。因此本文给出的是这套架构在特定一次配置下的实测基线，不是某一款卡的性能标称。换卡即换基线，方法不变。

并发扫描：找到生产工作点

并发	输出吞吐	请求吞吐	首字延迟 (TTFT)	端到端	定位
1	35.5 tok/s	0.31 req/s	243 ms	3.13s	交互
2	48.3 tok/s	0.42 req/s	255 ms	4.98s	交互
4	65.8 tok/s	0.58 req/s	296 ms	6.60s	甜点区
6	131 tok/s	1.20 req/s	292 ms	4.10s	最优
8	164 tok/s	1.44 req/s	287 ms	4.85s	生产
16	92.9 tok/s	0.82 req/s	7,183 ms	13.66s	排队
32	122.8 tok/s	1.08 req/s	9,823 ms	17.48s	仅批处理

这张表最有价值的不是峰值，而是拐点在哪。

从 c=1 到 c=8，输出吞吐涨了 4.6 倍，而首字延迟几乎纹丝不动（243ms → 287ms）——这段区间里，增加并发几乎是免费的。c=8 是这套配置的生产工作点：164 tok/s 输出、287ms 首字、峰值输出可达 248 tok/s。

越过 c=8 之后行为突变：c=16 的首字延迟直接跳到 7.2 秒，是 c=8 的 25 倍。原因不是算力不够，而是 KV 缓存容量成了硬上限——满 32K 上下文下大约只能同时驻留 5 条序列，再多就进队列。这也是为什么我们把并发闸设在拐点之前而不是之后：一个 287ms 首字的系统和一个 7.2 秒首字的系统，对用户是两个产品。

持续压力：331 秒不间断

单点采样容易好看，持续压力才说明问题。我们用 200 条请求（1024 token 输入 / 512 token 输出）做了一轮不间断压测：

持续吞吐 0.60 req/s、输出 149 tok/s
首字延迟中位数 457 ms
全程 331 秒，成功率 200/200

并发扫描与压力测试合计 310 次请求，错误率 0%。

按这个持续吞吐折算：0.60 req/s ×（1024 + 512）token ≈ 922 tok/s。若按 7×24 连续满负荷运行，单机月处理量约 24 亿 token（输入+输出口径）；仅计输出侧约 3.9 亿 token/月。这是一个上限参考值——实际业务不会 24 小时跑满，但它给出了单机容量的量级。

质量测试：快不等于对

吞吐数字如果以输出质量为代价，就没有意义。五项质量测试全部通过：

测试项	结果	说明
长上下文（8K 输入）	PASS	摘要正确，无退化
思维链推理	PASS	答案正确，推理轨迹完整
6 路并发质量	PASS	6/6 数学题正确，延迟 0.54–0.59s
长文生成（16K）	PASS	8,023 token / 308s，正常收尾
复读循环检测	PASS	1–100 计数无循环，干净结束

最后一项值得单独说：复读循环是量化模型在长生成下的典型失效模式，也是最容易被 benchmark 忽略的一项。我们把它列为必测项，因为它一旦发生，用户看到的是一段永远停不下来的胡言乱语——那比慢得多更伤信任。

架构与瓶颈：把限制说清楚

项	值
模型架构	MoE，256 专家，8+1 激活
参数量	122B 总参数 / 10B 激活
量化	Int4（moe_wna16）
原生上下文	262,144 token（256K）
运行上下文	32,768 token（32K）
显存占用	68.5 GB（多卡合计）
推理引擎	SGLang，张量并行 TP=4

这套配置的限制同样清晰，我们一并列出：KV 缓存是硬上限，满 32K 上下文下并发约 5 条；MoE 架构导致 prefill/decode 无法重叠调度；纯 PCIe 拓扑（无 P2P 互联）下 CUDA Graph 为分段模式。这些都是架构层面的确定性约束，不是调参能绕过的——把它们写清楚，客户才能判断自己的场景合不合适。

这套整机解决的问题

我们同时提供两条私有化路线，它们不是替代关系而是阶梯：

单机 DGX Spark：Grace Blackwell 统一内存架构，整机功耗与一台高端工作站相当，可直接放进办公室机柜，适合数据主权优先、无专业机房的客户；
液冷多卡整机：本文测试的这套，通过多卡 PCIe 扩展承载更大模型与更高并发，GPU 卡型按需选配，适合规模化推理与满血模型部署。

两条路线跑的是同一套软件栈——同样的 RAG 引擎、同样的多租户隔离、同样的 API 网关。客户从入门配置成长到规模化时，不需要更换平台，也不需要重做集成。

常见问题

Q: 换成不同型号的 GPU，这些数字还成立吗？ A: 不成立，也不该成立。这套整机是按选配设计的，卡型、显存规格、代际都可以变，性能基线随之变化。本文给出的是测试方法与拐点分析框架——并发扫描找工作点、持续压测验稳定性、质量测试防退化。换配置后我们会用同一套方法重新出基线。

Q: 为什么并发闸设在 c=8 而不是更高？ A: 因为 c=16 的首字延迟是 c=8 的 25 倍。对话式产品里，首字延迟直接决定体感，把并发推过拐点换来的吞吐提升，代价是用户面前多等 7 秒。我们选择在拐点之前设闸。

Q: 月处理 24 亿 token 是实测还是推算？ A: 推算。它由实测的持续吞吐（0.60 req/s，1024 输入 / 512 输出）按 7×24 连续满负荷折算得出，口径为输入+输出合计。实际业务负载不会全天满跑，这个数字用于评估单机容量量级，不代表承诺产能。

关于 HTZL.AI

HTZL.AI 是四川慧途智联科技有限公司旗下的企业级私有 AI 品牌，专注于"数据不出企业、模型不进云端"的私有化部署路径，是 NVIDIA Inception 会员企业。本文所有数据均来自我们自有硬件上的实测记录。