GPU繁忙可能掩盖Kubernetes上AI推理缓慢的问题
内容提要
文章讨论AI推理服务在Kubernetes上的可观测性与运维：需测量首token时间、每token时间、可靠性、成本与答案质量，并在上线前用代表性负载建立基线；GPU利用率高不代表服务健康，应关联模型、Kubernetes、网络、存储等各层指标排查瓶颈；自动扩缩需合适指标与GPU容量；提示词和响应属敏感数据，须规范采集与访问；上线决策应由平台、数据科学、安全与业务方共同基于证据做出。
延伸解读
GPU利用率高不等于推理服务健康
文章指出，GPU利用率达到100%可能只是“误导性的胜利”。它无法说明首token时间、生成速度或答案质量是否达标。团队应关联模型服务、Kubernetes、网络、存储等各层指标，结合受影响请求和时间窗口排查瓶颈，而不是仅凭GPU繁忙判断服务正常。
上线前用代表性负载建立基线
文章建议在客户依赖前，用代表性提示词长度、上下文长度、输出量和流量水平进行性能剖析，记录token吞吐、延迟和服务级指标。基线可作为生产环境行为变化的参照，帮助区分推理需求上升与资源争用，并更有效地规划容量。
自动扩缩需要合适指标与GPU容量
Kubernetes的Horizontal Pod Autoscaler可使用自定义或外部指标，团队不必因CPU利用率不适合推理而替换它。但需提供并测试指标管道、扩缩边界和可用加速器容量。扩缩策略无法让额外GPU容量瞬间出现，因此容量规划仍需提前考虑。
提示词是敏感数据，可观测性需兼顾安全
文章提醒，提示词、响应和检索文档可能出现在日志与追踪中。团队应明确采集什么、存储何处、保留多久、谁可访问。提示词属于数据，敏感内容即使为排障采集也需保护。安全控制与事件响应仍需团队自行设计和测试，不能仅依赖可观测性工具。
Q&A
为什么GPU利用率100%不能说明AI推理服务运行良好？
GPU利用率高只表示GPU在忙，但无法反映服务是否快速、准确或可靠地响应用户。例如，首token可能很快但后续生成很慢，或者响应很快但答案错误。因此，必须结合首token时间、每token时间、可靠性、答案质量等指标综合评估。
在Kubernetes上部署AI推理服务前，应该测量哪些关键指标？
对于对话服务，建议测量首token时间、每输出token时间、可靠性、容量、资源效率、成本和答案质量。具体指标组合取决于期望的用户体验，并需在代表性负载下建立基线。
如何为AI推理服务建立性能基线？
在上线前，用代表性的提示词和上下文长度、输出量及流量水平对服务进行性能分析，记录token吞吐量、延迟和服务级别指标。该基线可作为生产环境行为变化的参照，帮助区分需求增长与资源争用。
Kubernetes的Horizontal Pod Autoscaler能用于AI推理服务的自动扩缩吗？
可以，HPA支持自定义或外部指标，因此不必因为CPU利用率不适合作为推理触发指标而替换它。但团队需要提供并测试指标管道、扩缩边界以及可用的加速器容量，且扩缩策略无法瞬间变出更多GPU。
AI推理服务的可观测性数据中，提示词和响应内容应如何处理？
提示词、响应和检索文档可能出现在日志和追踪中，属于敏感数据。团队应明确收集哪些信息、存储位置、保留时长和访问权限，并像保护其他敏感数据一样保护提示词内容。
AI推理服务上线决策应该由谁参与？依据什么？
上线决策不能由单个人做出，需要平台管理员、机器学习与数据科学团队、安全团队以及相关业务负责人共同参与。决策应基于证据，包括代表性负载测试、故障案例、容量、质量、成本和恢复能力等，确保服务能满足约定的用户和业务目标。
