平台与治理

前面的文章覆盖了 AI Infra 的大部分层次：硬件与互联、系统运行时、训练与推理引擎、数据与知识。但一个现代 AI 系统要真正投入生产并长期稳定运行，还缺最后一层：平台编排、可观测性与治理。

这层之所以重要，是因为 AI workload 和传统 Web 服务有着本质不同：它是高状态的（KV cache 不能随意丢弃）、高成本的（每次请求都直接消耗 GPU 时间和显存）、延迟敏感的（用户无法容忍数秒等待），而且行为难以预测（同样的 prompt 可能产生截然不同的输出和耗时）#CNCF-llm-d-2026 #OpenTelemetry-2026。

这些特性决定了：你不能只是把模型塞进容器然后交给 Kubernetes，而需要一整套面向 AI workload 的平台能力。

根据 CNCF 的调查，82% 的容器用户已在生产环境使用 Kubernetes，而越来越多的 AI 团队也开始把训练任务、推理服务和 agent 工作流部署在 K8s 上 #CNCF-Kubernetes-AI-2026。

但标准 K8s 并不是为 AI workload 设计的。传统 K8s 擅长管理无状态服务：一个请求进来，处理完就结束，pod 之间不共享状态。而 AI serving 是高度 stateful 的：KV cache 需要在请求之间保持，模型权重需要被稳定加载，推理节点的状态直接影响路由决策。

这催生了一批 K8s 之上的 AI 平台项目，其中 llm-d 是最有代表性的之一。

llm-d 被 CNCF 接纳为 Sandbox 项目，标志着云原生社区明确意识到：AI serving 需要新的平台抽象 #CNCF-llm-d-2026。

llm-d 的核心设计围绕三个 AI serving 特有的问题展开：

• Prefill/Decode Disaggregation：把 prompt 处理和 token 生成拆成独立的 pod 池，各自独立扩缩容。因为 prefill 更吃算力，decode 更吃显存带宽，混在一起会导致资源利用率低下。
• Inference-Aware Routing：传统负载均衡只看 CPU/内存利用率，但 AI serving 需要考虑 KV cache locality、队列深度、模型加载状态等因素。llm-d 引入了 prefix-cache-aware routing，把请求路由到已经缓存了相关前缀的节点上。
• Hierarchical KV Cache Offloading：当 GPU 显存不够时，把 KV cache 按热度分层卸载到 CPU DRAM 甚至 NVMe 存储，以成本和延迟的权衡换取更大的上下文容量。

传统系统监控关注 CPU、内存、错误率和 QPS。但 AI 系统需要观测的对象完全不同：

• Token 用量：输入输出 token 数直接决定成本和延迟。
• 模型调用链：一个用户请求可能触发多个模型调用、工具调用和检索操作，需要完整的分布式追踪。
• 输出质量：响应是否忠实于检索内容？是否存在幻觉？毒性如何？
• 成本波动：不同请求的成本差异巨大，需要精细的成本归因和预算控制。

OpenTelemetry 在 2026 年推动了 GenAI semantic conventions，标准化了如何记录模型名、token 计数、工具调用、finish reason 等信息 #OpenTelemetry-2026。这让 AI 观测从“每个团队自己造轮子”走向了“跨工具、跨厂商的统一标准”。

如果把 AI Infra 的六层地图拉通来看，平台与治理层处于最顶端，但它不是“装饰层”，而是决定整个系统能否从实验走向生产的决定性因素。

• 硬件和运行时层回答了“能不能算”；
• 训练和推理引擎层回答了“模型能不能工作”；
• 数据和知识层回答了“模型有没有足够的信息”；
• 平台与治理层回答了“系统能不能长期、稳定、可控地服务真实用户”。

一个训练得再好的模型，如果缺乏监控、没有成本约束、无法处理故障、不能隔离多租户，就无法真正投入生产。平台层的使命，就是让 AI 系统从“能跑”进化到“敢跑”。

到这篇为止，这个系列已经覆盖了 AI Infra 的六个层次：

AI Infra 不是一份工具清单，而是一套围绕 AI workload 特性重构出来的生产系统。当基础设施开始真正“理解”模型状态、token 生成过程、显存约束和多模态流水线时，我们才可以说：AI Infra 作为一个独立工程领域，已经真正成立。