集群慢不一定是卡不够：三种慢，只有一种值得花钱
集群慢不一定是卡不够 —— 「慢」有三种，只有一种值得花钱。显存接近 0 是显卡压根没参与计算（配置问题，加卡一分钱作用没有）；只有第一轮慢是预热，属正常开销；并发上去了单请求反而更慢，说明撞的是通信墙（加卡会更糟）。只有「单请求慢且显存占用正常、并发仍有边际收益」这一种，加卡才是正解。
硬件选型容量规划显存张量并行排错这条适用于
- 集群环境（多卡/多机）
- 需要区分「算力不够」与「配置/运行时接缝」
版本指纹
本机实测经验框架；并发 16 一行为 4 机单实例张量并行结论
具体做法
表一：三种「慢」，只有一行该掏钱
| 现象 | 真实原因 | 该不该花钱 |
|---|---|---|
| 单请求慢，但显存占用正常 | 计算量真的超过卡的算力 | 可以考虑加卡 |
| 单请求慢，显存占用接近 0 | 显卡压根没参与计算，全在 CPU 跑 | 加卡一分钱作用都没有 |
| 第一轮明显慢，后面就正常 | 预热 / 首批编译，属正常开销 | 加卡毫无意义 |
| 并发上去了，单请求反而更慢 | 通信开销量超过算力收益 | 加卡会更糟 |
表二：冷启动复测（temperature=0, max_tokens=400, 同一 prompt, 连续 6 次）
| run1 | 9.48 s | 42.18 tok/s |
|---|---|---|
| run2 | 9.39 s | 42.58 tok/s |
| run3 | 9.38 s | 42.62 tok/s |
| run4 | 9.41 s | 42.51 tok/s |
| run5 | 9.42 s | 42.45 tok/s |
| run6 | 9.38 s | 42.66 tok/s |
| 首次 9.48 s / 稳态 9.40 s = 1.01x | -> | 没有冷启动惩罚 |
表三：并发曲线（max_tokens=256, temperature=0）
| 并发 | 系统吞吐 | 加速比 | 单请求等待 |
|---|---|---|---|
| 1 | 41.20 tok/s | 1.00x | 6.21 s |
| 2 | 65.26 tok/s | 1.58x | 7.67 s |
| 4 | 103.29 tok/s | 2.51x | 9.52 s |
| 8 | 148.95 tok/s | 3.62x | 13.13 s |
| 16 | 148.22 tok/s | 3.60x | 20.24 s |
判断顺序：先看显存 -> 再看是否只有第一轮慢 -> 最后看并发边际收益
加卡最大的代价不是钱，是它让你停止思考了。
失效边界
三条判据里最容易误判的是第二条（显存接近 0 的那种慢）：它长得特别像「卡不行」，但根本不是。你去看显存几乎没被占用，你去看 GPU 利用率可能是满的（因为别的东西在用），你去看日志它写着「加载成功」—— 所有仪表盘都在告诉你一切正常，但计算根本没上卡。这种慢花钱买不到，因为它缺的不是算力，是配置和运行时的接缝。适用边界：表一的分类是，不同框架、不同硬件下判据会变化。另外「并发 16 零收益」这一行是 4 台机器跑单实例张量并行的结论，换流水线并行或多实例部署不成立。
三条判据里最容易误判的是第二条（显存接近 0 的那种慢）：它长得特别像「卡不行」，但根本不是。你去看显存几乎没被占用，你去看 GPU 利用率可能是满的（因为别的东西在用），你去看日志它写着「加载成功」—— 所有仪表盘都在告诉你一切正常，但计算根本没上卡。这种慢花钱买不到，因为它缺的不是算力，是配置和运行时的接缝。适用边界：表一的分类是，不同框架、不同硬件下判据会变化。另外「并发 16 零收益」这一行是 4 台机器跑单实例张量并行的结论，换流水线并行或多实例部署不成立。