面经策

如果一个 GPU 集群的 LLM 处理能力为 1000tokenss，那 1000 个用户同时并发访问，响应给每个用户的性能只有 1 tokens 吗？怎么分析性能瓶颈 ​

  • 标签：后端、场景题、大模型

🏛 业务架构师 ​

这是典型的容量估算题，先纠正题设再给分析方法：

第一步·概念纠偏：1000 tokens/s 是集群吞吐上限。1000 并发用户不会每人只分到 1 token/s——因为不是所有用户同时在"生成中"。真实场景中用户有阅读、打字间隔，请求到达是错峰的；且系统有排队机制，用户体验取决于 P50/P95 延迟而非平均分摊。

第二步·两个关键指标：

  • 吞吐（tokens/s）：决定总产能。按 1000 并发、每人平均每 10 秒发起一次生成、每次输出 200 token 算，实际需求 = 1000/10×200 = 20000 tokens/s——集群 1000 tokens/s 就严重不足，要排队；
  • 首 token 延迟（TTFT）与出字速度：决定体感。排队导致 TTFT 飙到几十秒，用户直接流失。

第三步·瓶颈定位（按排查顺序）：GPU 利用率与显存（KV Cache 占满会导致吞吐骤降）→ 批处理策略（continuous batching 是否开启）→ 模型规模与量化 → 预填充与解码的算力争抢。

第四步·扩容与降本的组合：扩容 GPU 副本、换小模型/量化版本、路由分层（简单任务走便宜通道）、缓存高频问答、对高峰限流+排队。

业务视角：容量规划要回答"多少预算买多少并发、SLA 承诺到哪"——技术上把吞吐-延迟曲线压测出来，业务上把用户可容忍等待和峰值系数定清楚，两边对齐才做承诺，避免"上线即崩"或"过度采购"。

🏗 系统架构师 ​

这题考的是吞吐与延迟的容量账，我先把模型说清楚再算账：

先纠偏：LLM 推理有两个性能阶段——prefill（处理输入）算吞吐，decode（生成 token）通常按流式延迟体验。集群吞吐 1000 tokens/s 指的是系统总生成吞吐。1000 并发用户均分的话，每用户确实只有 ~1 token/s 的生成速度——但这是资源调度策略的结果，不是物理定律。

正确的分析框架：

  • 吞吐 vs 延迟的分配：可以 100 人各 10 token/s（交互可接受），而不是 1000 人各 1 token/s（体验崩坏）——用排队/准入控制：超过容量的请求进队列或直接限流（返回"繁忙稍后重试"），保在服用户的体验；
  • 并发 ≠ 同时生成：请求有思考/阅读时间，真实稳态并发生成数远小于在线用户数；引入会话级令牌桶限流；
  • 提升分母：Continuous Batching 动态组批（GPU 利用率大幅提升）、张量并行切大模型、PD 分离（prefill 与 decode 分离部署，各自扩容）、更小模型/量化（int8/int4 吞吐翻倍）、Speculative Decoding；
  • KV Cache 是关键资源：1000 并发 × 长上下文的 KV Cache 会先于算力打爆显存——上下文长度控制与 PagedAttention 决定并发上限。

结论：先算稳态吞吐需求（QPS × 平均输出 token）对照集群能力，缺口靠限流保护 + 扩容/优化解决，绝不裸奔让 1000 人均分。

💻 全栈开发专家 ​

这是吞吐与延迟的经典问题。1000 tokens/s 是集群总吞吐，1000 并发时「平均每用户」确实是 1 token/s——但只在「串行处理」假设下成立，实际要分层分析：

1. 关键指标拆解：

  • TTFT（首 token 时间）：排队+prefill 决定；
  • TPOT（每输出 token 间隔）：由「分到单个请求的算力」决定；
  • 总吞吐 1000 tokens/s ÷ 1000 并发 = 1 token/s/用户，意味着一句话 100 token 要等 100 秒——不可接受。

2. 为什么实际没那么惨：Continuous Batching。现代推理引擎（vLLM/TensorRT-LLM）做连续批处理：不同请求的 token 拼在同一 batch 迭代里，GPU 并行度拉满，总吞吐随并发上升（直到显存/算力饱和），不是简单均分。1000 并发下真正的问题是 KV cache 显存耗尽 → 排队 → TTFT 恶化。

3. 排查瓶颈的动作：

bash
nvidia-smi dmon -s um        # GPU 利用率、显存带宽
vllm serve ... --max-num-seqs 256   # 并发上限与 batch
# 看 metrics: vllm:num_requests_waiting、token_generation_time
  • GPU 计算型瓶颈（SM 利用率>90%）：量化（FP8/AWQ）或扩实例；
  • 显存型瓶颈（KV cache 满载）：限制上下文长度、--gpu-memory-utilization 调优、开 prefix caching；
  • 排队型：加实例+负载均衡，长文本和短文本分流。

4. 业务侧解法：入口限流+排队产品化、请求分级（VIP 优先）、输入压缩降 prefill 压力。这道题的考点是「吞吐和单用户延迟是两个指标，中间隔着批处理调度」。