核心要点

  • 吞吐核心是 continuous batching + PagedAttention 管理 KV Cache，让 GPU 在变长请求下保持高利用率

  • 显存与成本：用量化（INT8/FP8/INT4）压模型与 KV Cache，配合张量并行切大模型上多卡

  • 弹性与稳定：多副本 + 基于 GPU 利用率/队列长度的自动扩缩 + 排队与限流，过载时降级而非雪崩

  • 明确 SLO 并分别优化：TTFT（首字延迟，受 prefill 影响）与 TPOT（每 token 延迟，受 decode/batch 影响），加多级缓存削峰

标准回答

需求与 SLO

在有限 GPU 下扛高并发推理，目标是高吞吐 + 满足延迟 SLO。两个核心 SLO：TTFT（首字延迟）和 TPOT（每 token 输出延迟），二者与吞吐相互制约。

整体架构

接入层做鉴权、限流与排队；调度层把请求送入推理引擎（如 vLLM）做 continuous batching；引擎用 PagedAttention 分页管理 KV Cache 提升显存利用；大模型用张量并行跨多卡，整体多副本部署在自动扩缩组后。

关键模块

批处理：continuous batching 动态拼批，避免静态 batch 的等待与浪费；KV Cache：缓存历史 token 的 K/V，decode 阶段复用，PagedAttention 减少碎片；量化：INT8/FP8/INT4 压权重与 KV Cache，降显存提吞吐；缓存：高频/相同请求走语义缓存或前缀缓存直接命中。

评估

压测看吞吐（tokens/s）、TTFT、TPOT、P99 延迟随并发的变化曲线，确定单副本承载与扩缩阈值。

上线与监控

按 GPU 利用率与队列长度自动扩缩；过载时排队 + 限流 + 降级（切小模型或拒绝），避免雪崩；监控延迟分位、显存、batch 利用率与 OOM。

常见误区

⚠️ 常见踩坑

用传统静态 batching 攒满再算，导致变长 LLM 请求大量等待与 GPU 空转——应上 continuous batching；以及只盯平均延迟忽略 TTFT/TPOT 区分与 P99，无法定位是 prefill 还是 decode 瓶颈。

追问

追问 1：continuous batching 相比静态 batching 好在哪？

静态批处理要等齐一批、按最长序列对齐，短请求被长请求拖住，GPU 利用率低。continuous batching（连续/迭代级批处理）以 token 迭代为粒度动态进出请求：一条生成完就立刻让新请求补位，无需等整批结束。在变长、随机到达的 LLM 负载下，GPU 利用率和吞吐显著提升，是 vLLM 等引擎的核心机制。

追问 2：TTFT 和 TPOT 分别受什么影响，如何优化？

TTFT 主要由 prefill（处理输入 prompt）和排队等待决定：缩短靠前缀缓存复用、控制输入长度、prefill-decode 分离与优先调度。TPOT 由 decode 阶段每步生成成本决定：靠 KV Cache 复用、量化降显存带宽压力、合理 batch、推测解码（speculative decoding）加速。两者需分别压测和优化，不能只看一个。

追问 3：流量突增时如何防止服务雪崩？

多层防护：接入层限流 + 请求排队设上限，超限快速拒绝或降级；基于队列长度/GPU 利用率自动扩容副本，但扩容有冷启动延迟，故先靠排队和限流兜底；过载时降级到更小模型或截断输出；语义/前缀缓存吸收重复请求。配合熔断与优雅拒绝，保住已接入请求的 SLO。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。

📚 知识库

📖 术语表

🛠️ AI 工具

  • vLLM

    高吞吐 LLM 推理引擎，77,418+ stars。采用 PagedAttention 显存优化技术，吞吐量比 HuggingFace Transformers 高 24 倍，是生产环境部署大模型推理的首选方案，支持 OpenAI 兼容 API

🎯 相关面试题