如何在 Kubernetes 上诊断和修复 AI 推理延迟
内容提要
Kubernetes 集群看似健康，但 LLM 应用在高峰时仍严重延迟。瓶颈不在模型，而在路由、排队、预填充和解码四个阶段：负载均衡按连接分配、自动扩缩容因冷启动滞后、GPU 碎片化、入口超时与缓冲破坏流式输出。建议按 token 吞吐规划容量，用队列深度扩缩容，监控首 token 延迟，并明确平台与应用团队的责任归属。
延伸解读
延迟问题的根源不在模型
文章指出，LLM 推理延迟通常不是模型本身的问题，而是基础设施层面的路由、排队、预填充和解码四个阶段。Kubernetes 的默认负载均衡、自动扩缩容和入口配置都是为短请求设计的，无法适应 LLM 请求的长时、高成本和 GPU 内存密集特性。因此，当集群看似健康时，用户仍可能经历长时间等待。
按 token 吞吐规划容量
文章强调，传统的请求每秒（RPS）指标对 LLM 无意义，因为每个请求的 token 数差异巨大。应使用 token 吞吐量（区分提示和完成）来规划容量，并基于队列深度而非 CPU 或 GPU 利用率进行自动扩缩容。同时，由于冷启动可能长达数分钟，必须保留额外副本并设置最小副本数，避免缩容到零。
监控首 token 延迟和队列深度
用户感知的延迟主要取决于首 token 延迟（TTFT），而非总生成时间。文章建议监控 TTFT 和队列深度的 p95/p99 分位数，而非平均值。此外，需检查入口控制器的读超时和响应缓冲设置，避免长生成被中断或流式输出被破坏。这些指标应放在同一仪表板上，供平台和应用团队共同查看。
明确平台与应用的职责边界
延迟问题常因平台、应用和 MLOps 团队职责不清而长期存在。文章建议明确划分：平台团队负责容量、调度、路由、扩缩容和放置；应用团队负责模型配置、上下文长度、批处理参数和重试行为。双方应就关键指标达成一致，并共同处理性能问题，避免问题在团队间隙中无人负责。
Q&A
为什么 Kubernetes 集群显示健康，但 LLM 应用在高峰时仍然严重延迟？
因为 Kubernetes 的标准监控指标（如 CPU、Pod 状态）无法反映 LLM 推理的真实瓶颈。LLM 请求的延迟主要来自路由、排队、预填充和解码四个阶段，这些阶段的问题不会体现在集群健康指标上。例如，负载均衡按连接分配导致请求分布不均，自动扩缩容因冷启动滞后，GPU 碎片化导致资源无法利用，入口超时和缓冲破坏流式输出。因此，集群看似健康，但用户体验到的延迟可能高达数秒。
LLM 推理延迟通常发生在哪些阶段？
LLM 推理延迟主要发生在四个阶段：1）路由：负载均衡器按连接分配请求，导致热点和缓存未命中；2）排队：自动扩缩容因冷启动（拉取镜像、加载权重）而滞后，且扩缩容信号（如 CPU）不准确；3）预填充：GPU 分配粒度粗，导致碎片化，且预填充计算密集，影响首 token 延迟；4）解码：入口控制器默认超时和响应缓冲会中断长生成或破坏流式输出。
如何为 LLM 推理服务配置 Kubernetes 自动扩缩容？
应使用基于队列深度的扩缩容，而不是 CPU 或 GPU 利用率。vLLM 暴露了等待请求数等 Prometheus 指标，可用 KEDA 等工具根据这些指标扩缩容。配置示例：设置最小副本数为 2（避免冷启动），冷却时间约 600 秒（避免频繁缩容）。同时，由于冷启动耗时数分钟，反应式扩缩容总是滞后，因此需保持额外冗余容量，并避免缩容到零（除非是批处理任务）。
Kubernetes 中 GPU 资源分配有哪些问题？如何解决？
Kubernetes 默认以整卡为单位分配 GPU，导致资源浪费和碎片化。例如，一个需要多卡的模型可能因 GPU 分散在不同节点而无法调度。解决方案包括：1）时间片共享：简单但无内存隔离，适合开发；2）MIG：硬件隔离但切片固定；3）动态资源分配（DRA）：将加速器请求纳入核心 API，实现更细粒度调度。此外，应给 GPU 节点打污点，防止非推理负载占用。
如何优化 LLM 推理的入口配置以避免流式输出中断？
许多入口控制器默认有 60 秒读超时和响应缓冲，这会中断长生成或破坏流式输出。应调整入口配置：增加读超时（如超过最长生成时间），并禁用响应缓冲，确保 token 实时流式传输。同时，调整 Pod 的 terminationGracePeriodSeconds 并添加 preStop 钩子，避免部署时切断进行中的流。
监控 LLM 推理服务时，除了常规指标外还应关注哪些？
除了延迟、流量、错误和饱和度，还应监控：1）Token 消耗率（区分提示和完成），作为容量规划单位；2）每租户和查询类型的成本；3）输出质量（如幻觉率、护栏漂移）；4）模型归因（记录检查点和提示版本）。此外，应关注首 token 延迟（TTFT）和 token 间延迟的 p95/p99，而非平均值。
平台团队和应用团队在 LLM 推理延迟问题上应如何划分责任？
平台团队负责实现目标延迟的能力：容量、调度、路由、扩缩容、放置。应用团队负责模型配置和调用方式：上下文长度、批处理参数、提示大小、重试行为。双方应共同商定关键指标（如 TTFT、token 间延迟、错误率、队列时间），并共享同一仪表板。当指标下滑时，双方共同排查，基于同一数据对话。
如何规划 LLM 推理服务的容量？
容量规划应以 token 吞吐量（每秒 token 数）为单位，并区分提示 token 和完成 token，因为两者对系统压力不同。使用最差真实提示和最差并发进行负载测试，并据此规划。GPU 资源应提前预留，保持基线容量并允许突发。使用 Kueue 等工具进行多租户 GPU 配额管理，防止单个团队耗尽资源。
