Kubernetes 上的生成式人工智能 (Chinese Edition)

第五章 模型 可观测性

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在第1章中，我们通过一个简单的编码示例，从零开始学习了如何在Kubernetes中部署LLM。 该全栈方案包含：用于优化模型执行的vLLM模型服务器，以及管理Kubernetes集成与部署生命周期的KServe模型服务器控制器。

第二章聚焦于LLM模型数据，探讨了当前管理同类模型规模的复杂性与可选方案。 我们正逐步接近完整的生产环境部署，其中LLM工作负载将实现全自动化管理，使其能与其他工作负载（即传统应用程序）并行运行，所有组件均由Kubernetes统一管控。

Kubernetes通过声明式API协调容器执行 ，借助控制器和协调循环以最终一致性方式实现工作负载的自我修复。 任何熟悉Kubernetes的人都知道，这种方法不能替代完善的可观测性和监控能力。 这些能力让你能在无法自动解决问题时快速响应。 这一原则同样适用于LLMs。 监控模型服务器至关重要，但鉴于LLMs的特性，其监控方式与传统应用程序并不等同。

与仅需少量端点的传统微服务相比，LLM在工作负载生成机制上存在显著差异——后者主要由请求数量和数据查询速度驱动。 即使相较于传统机器学习，LLMs也具有独特特性。

本章将阐述其差异性，阐明需重点监控的执行环节，并介绍相应的可用指标。

全书中我们通常将LLMs视为运维黑盒，聚焦部署、扩展和资源管理，无需理解其内部机制。 但在可观测性和生产监控领域，理解LLMs的请求处理流程至关重要。 我们监控的指标（如首次令牌生成时间、令牌吞吐量、KV缓存利用率）直接关联LLMs推理管道。

若您跳过了《理解LLM基础》中的基础知识章节，请在深入可观测性细节前重新学习该部分。 该章节涵盖令牌化、嵌入、预填充与解码阶段，以及计算密集型与内存密集型工作负载等概念。 这些基础知识将帮助您理解为何要监控特定指标，以及这些指标如何揭示生产环境性能状况。

本章后续内容将基于您对上述概念的基本认知，重点探讨基于Kubernetes的生产环境LLM部署中可观测性工具、技术及最佳实践。

可观测性架构与配置

本节探讨用于监控Kubernetes上LLM工作负载的可观测性工具与实践。 在监控LLM工作负载时，我们可以复用或调整现有的Kubernetes工具及成熟的工作负载可观测性实践。

工作负载的可观测性涉及多个维度：通过日志排查错误、收集指标进行时序分析、借助追踪关联执行步骤、以sidecar形式代理流量，甚至直接在容器内注入模块。 这些方法适用于应用程序工作负载，其中大部分同样适用于基于KServe和vLLM的LLM部署。

日志

Kubernetes定义了日志架构（ ），其中标准输出和标准错误均重定向至容器运行节点上的log-file.log文件。 这使得通过kubectl logs命令可轻松访问日志，但无法提供长期存储或索引功能（）。 您需要通过Grafana Loki等现有项目为集群补充此功能。

当以推理服务形式部署模型时（ ），KServe控制器会创建包含多个容器的部署： 包括用于加载模型的初始化容器storage-initializer、运行模型服务器的kserve-controller，以及根据部署模式（Knative或ModelMesh，详见"KServe"章节）添加的额外sidecar容器。

LLM 的内省和日志管理与应用工作负载类似。 为了解这些日志中包含哪些信息，我们将介绍典型的 vLLM 启动流程。

示例 5-1 ...