GLM-5.2 · PAI CAPACITY REPORT · 2026-07-23

TP8 与 TP16：谁能服务更多用户？

答案取决于“用户”的定义。KV Cache 决定同一时刻能装下多少正在计算的 token；GPU 计算吞吐决定每分钟能完成多少请求。TP16 更能装，TP8 三副本通常更能并行处理短请求。

中短上下文 / 公共在线流量
优先 TP8 多副本：三套队列、24 张 GPU、低故障耦合。
超长上下文 / 200k～1M
使用 RDMA TP16：单实例 1M 窗口、更大的共享 KV 池。

一、实机容量基线

TP8 副本数3每个副本 8 GPU
TP8 单请求上限224k每副本 KV 池 224,320
TP16 副本数1两节点、16 GPU
TP16 单请求上限1MKV 池 1,252,288

二、部署结构不是“8 卡对 16 卡”这么简单

TP8：三份完整模型

每个副本独立保存一整份模型，拥有独立调度队列。

副本 A8 GPU · 224k
副本 B8 GPU · 224k
副本 C8 GPU · 224k
总 GPU：24；模型权重重复保存 3 次。

RDMA TP16：一份模型切到两台机器

16 张卡共同完成每个请求，只保存一整份模型权重。

MasterTP rank 0～7
⇄
RDMA
WorkerTP rank 8～15
总 GPU：16；模型权重只保存 1 次。

三、为什么 TP16 卡更少，KV 反而更大？

GLM-5.2-FP8 权重约 753GB。TP8 的三份副本重复占用大量显存；TP16 只保存一份权重，并明确使用 FP8 KV Cache。

TP8 三副本 · 24×H200

三份模型权重 ≈ 2,259GB
剩余空间

3,384GB 总显存 − 2,259GB 权重 ≈ 1,125GB

TP16 单实例 · 16×H200

一份权重 ≈ 753GB
更多剩余空间

2,256GB 总显存 − 753GB 权重 ≈ 1,503GB

再叠加 --kv-cache-dtype fp8_e4m3，TP16 每个 KV 元素通常只需 FP16/BF16 的一半字节数。因此它能驻留更多上下文，并不意味着它的计算吞吐也同比增加。

四、“33 个用户”和“62 个用户”到底是什么意思？

它们不是平台注册用户数，也不是整天只能服务的人数。
它们表示：假设每个正在推理的请求都占用 20k KV tokens，理论上同一时刻最多能放进多少个活跃请求。请求完成后，工作 KV 会释放或成为可淘汰缓存，容量随即可以服务下一批用户。
每个活跃请求TP8 三副本：KV 驻留上限TP16：KV 驻留上限说明
20k约 33 个约 62 个只是显存 admission ceiling
50k约 12 个约 25 个未计算延迟与 GPU 饱和
100k约 6 个约 12 个TP8 仍可能拥有更高总 tokens/s
200k约 3 个约 6 个TP8 接近单请求极限
500k不支持约 2 个只能走 TP16
1M不支持约 1 个接近 TP16 极限

五、KV 驻留容量计算器

20k

只计算理论 KV 容量，不代表满足延迟 SLA 的用户数。

TP8 三副本33个同时在途请求
RDMA TP1662个同时在途请求

六、TP8 真正的价值

TP8 三副本擅长

  • 三套独立队列：三批请求真正并行计算。
  • 24 张 GPU 总算力：短请求总 tokens/s 可能更高。
  • 较低通信开销：避免跨节点 TP16 每层 RDMA collective。
  • 故障隔离：一个副本故障，另外两个仍可服务。
  • 流量隔离：一个慢请求只拖累一个副本。
  • 易扩缩容：Router 可增加、摘除或滚动更新副本。

TP16 单实例擅长

  • 完整 1M 上下文：支持超长 Claude Code 会话。
  • 共享大 KV 池：没有三个副本之间的显存碎片。
  • 权重只存一份：更多显存可用于 KV Cache。
  • FP8 KV：进一步提升 token 容量。
  • 长请求 admission：500k～1M 请求只有它能接。

七、最终流量策略

普通请求（≤200k）→ TP8 多副本池　｜　超长请求（>200k）→ RDMA TP16 长上下文池

如果要回答“在 TTFT < 10 秒、P95 < 60 秒的条件下能服务多少用户”，必须分别压测并发 1/2/4/8/16/32，记录 TTFT、Prefill tokens/s、Decode tokens/s、总吞吐、P95/P99 与错误率。仅凭 KV 池无法得到这个答案。