1000 token/s 的 GPU 集群被 1000 用户并发访问，如何分析性能瓶颈？

第一步：先算账，建立量级直觉

1000 tok/s 是集群的总吞吐上限。如果 1000 个用户真的同时在生成，理论上人均只有约 1 token/s——这远低于可用体验（通常希望每用户 20–50 tok/s）。所以第一结论是：这是容量严重不足导致的排队，光调参数救不回来，需要先判断“是真满载，还是配置没用满”。要区分两种情况：吞吐确实被硬件顶到天花板，还是 batch 没打满、调度不佳导致有效吞吐远低于硬件极限。

第二步：理解吞吐与延迟的权衡

LLM 推理里吞吐和单请求延迟是一对矛盾：增大 batch 能提高总吞吐（GPU 利用率更高），但会拉长单个请求的延迟。分析瓶颈先要明确目标是保吞吐还是保延迟，再看当前在曲线的哪个位置。

第三步：分阶段看 prefill 与 decode

• Prefill（处理输入 prompt）：一次性算完整个输入，是算力（compute）密集型，长 prompt 会吃满算力；
• Decode（逐 token 生成）：每步只生成一个 token，是显存带宽密集型，且要反复读写 KV Cache。

判断瓶颈在哪个阶段，决定了优化方向：prompt 很长就先优化 prefill，长输出就重点优化 decode。

第四步：定位真正的瓶颈点

逐项排查：

1. batch 是否打满：有没有用连续批处理（continuous batching）？传统静态 batch 要等一批全部结束才换下一批，GPU 大量空转；连续批处理能在每步动态加入/移除请求，把利用率拉满。没用上它，吞吐就远没榨干；
2. KV Cache 显存：每个并发请求都要为它的上下文常驻一份 KV Cache，显存往往才是真正的并发上限——不是算力不够，而是显存装不下更多并发序列。看显存占用是否逼近上限、有没有因显存碎片浪费；
3. 显存带宽 vs 算力谁先到顶：用 profiler 看 decode 阶段是带宽打满还是算力打满，对症下药；
4. 排队时延：观测请求在队列里等了多久，排队占端到端延迟的比例，确认瓶颈是排队还是计算。

第五步：优化手段

• vLLM / 连续批处理 + PagedAttention：把 KV Cache 像操作系统分页一样管理，大幅减少显存碎片、提升并发数和吞吐，是性价比最高的一招；
• 量化：INT8 / FP8 / 权重量化降低显存占用和带宽压力，腾出空间装更多并发、提速 decode；
• 扩容 / 多副本：1000 并发对 1000 tok/s 本质是容量不够，水平扩展副本、加卡是根本解；
• 投机解码（speculative decoding）：用小模型起草、大模型校验，降低单请求延迟、提高有效吞吐；
• 限流与优先级、按 SLA 分级：既然总吞吐有限，就主动管理——对请求限流、设优先级队列，把吞吐优先分给付费 / 关键请求，普通请求降级或排队，保证关键体验不崩。

结论

先用“算账”确认这是容量与排队问题，再从 batch 利用率、KV Cache 显存、prefill/decode、带宽 vs 算力逐层定位真正瓶颈；优化上以 vLLM 连续批处理 + 量化压榨单卡吞吐为先，配合扩容根治容量，再用限流分级把有限资源用在刀刃上。