文章分析了在Kubernetes上大规模运行AI推理基础设施的挑战，包括GPU碎片化、推理接口不一致和批处理基础设施等痛点。为解决这些问题，文章提出了一种Kubernetes原生模式。该模式通过KAITO管理模型生命周期，liteLLM提供统一推理访问，并利用GPU Flex Nodes实现弹性GPU调度。此架构将AI工作负载标准化为Kubernetes原语，以提高可预测性和可扩展性。
译自：Building a Kubernetes-native pattern for AI infrastructure at scale
作者：Sachi Desai
当AI开发和运维团队首次在Kubernetes上采用大型模型时，通常的重点是让它们运行起来。最初，推理服务可能响应正确，延迟可接受，概念验证也变成了生产端点。这可能让人感觉最困难的部分已经过去了。
然而，随着采用的增长，操作开始发生变化。在“第0天”运行模型相对简单，但在跨区域、不可预测的流量模式和云提供商之间可靠地运行推理基础设施，才是“第1天”和“第2天”操作变得复杂的地方。
为了让这些基础设施挑战更具体，我们来看一个真实的用例：事件驱动的事件分类和根本原因分析（RCA）。这个场景结合了同时给AI平台带来压力的几个特性：延迟敏感性、不可预测的流量高峰以及对故障的低容忍度。
考虑一个生产环境，值班工程师收到服务降级的呼叫。系统聚合来自多个服务的日志，检查最近的配置更改和部署，并关联跨依赖项的指标。一个由大型语言模型（LLM）驱动的分析步骤评估收集到的信号，并生成一份结构化摘要，提出可能的根本原因。这份摘要随后发布到事件管理渠道供审查。
“在‘第0天’运行模型相对简单，但可靠地运行推理基础设施……才是‘第1天’和‘第2天’操作变得复杂的地方。”
乍一看，这个过程似乎很简单。但在实践中，该流程依赖于GPU支持的推理能力和跨环境一致的低延迟路由。核心挑战不是在理想条件下获得单个模型响应，而是在操作压力期间，确保这个多阶段、依赖模型的RCA工作流能够可靠且可预测地执行。
AI平台操作中的常见痛点
让我们来思考一下团队在规模化运营AI平台时面临的一些常见痛点。
1. 碎片化的GPU容量
GPU通常是增量添加的：来自不同区域和云的独立SKU被引入，通常与特定项目绑定。随着时间的推移，容量变得分散。
从Kubernetes的角度来看，你需要一个单一的调度域。你可能在一个集群或区域有闲置的GPU，而另一个集群或区域却已饱和。即使总容量充足，它也不是可互换的。在不同区域或云之间转移工作负载需要外部编排，并增加了操作复杂性。
2. 不一致的推理接口
团队以不同的方式暴露模型：自定义模型服务器、托管端点或轻量级HTTP封装器。每种方法都定义了自己的错误语义、扩缩容行为和指标。
对于多阶段流程，这会产生紧密耦合。应用程序代码必须针对每个模型处理不同的请求格式和重试逻辑。推理不再是平台原语，而变成了定制集成的集合。
3. 面向批处理的基础设施
GPU集群通常针对稳定状态的批处理工作负载进行优化。然而，事件驱动的推理是突发且对延迟敏感的。当基础设施根据可预测的需求进行规模设计时，高峰会导致排队或增加延迟。
推理应被视为具有弹性调度的、一流的声明式管理工作负载，而不是批处理基础设施上的覆盖层。
一个随你而扩展的Kubernetes原生模式
相反，我们可以将AI基础设施视为一个标准的云原生系统问题。我们不为模型和GPU引入单独的控制平面，而是将Kubernetes原语——声明式状态、协调、调度——扩展到推理工作负载。
云原生AI架构可以理解为运行在共享Kubernetes控制平面上的三个逻辑层：
- 模型层
- 推理访问层
- 计算层
模型层：声明式生命周期管理
模型层以声明方式处理生命周期管理，将模型视为一流的Kubernetes资源。一些开源项目解决了这个问题，包括KServe、Ray Serve和NVIDIA Dynamo。对于这种架构，我们使用CNCF沙箱项目Kubernetes AI工具链操作器（KAITO）。
KAITO将模型定义和GPU供应捆绑到一个自定义资源中。团队定义所需状态，包括模型类型、配置和GPU要求，KAITO的控制器会自动协调该状态。资源请求是明确的，为调度器提供了可预测地放置工作负载所需的信息。通过将集群作为事实的来源，KAITO消除了临时脚本，并降低了模型或节点池更新期间的操作风险。
推理访问层：使用liteLLM的统一网关
推理访问层集中了跨模型和提供商的路由、速率限制和可观测性。Kubernetes Gateway API推理扩展、Envoy AI网关和kgateway等项目都解决了这个问题。对于这种架构，我们使用liteLLM。
推理流量不再由多个应用程序直接调用不同的模型服务器，而是通过liteLLM，它提供了一个一致的API接口。在多阶段流程中，这减少了服务之间的耦合，并简化了故障处理。应用程序看到一个稳定的端点，而网关将请求路由到适当的模型版本，透明地处理重试并在需要时回退到备用计算节点。
计算层：使用Flex Nodes的弹性GPU调度
计算层解决了GPU碎片化和突发需求的问题。Karpenter、KubeFleet和Kubernetes集群自动扩缩器等项目对此采取了不同的方法。对于这种架构，我们使用GPU Flex Nodes。
Flex Nodes允许来自多个云或区域的GPU支持节点加入单个Kubernetes集群。调度随后在Kubernetes内部进行，使用模型层中声明性定义的资源要求。工作负载被放置在有可用容量的地方，而不是绑定到特定的云或集群。最终，这种方法提高了利用率，并消除了在碎片化环境中管理GPU的操作摩擦。
为什么这种模式适合事件驱动的AI
事件驱动型工作负载（例如事件分类）需要在不可预测的需求下实现快速扩容和可预测的路由。在这种架构中：
- Flex Nodes通过在额外的云或区域GPU容量之间分配GPU容量来吸收峰值
- LiteLLM提供稳定的API，将请求一致地路由到正确的模型
- KAITO确保模型以声明方式就绪并进行版本控制
当警报触发工作流时，数据分析和推理作为Kubernetes原生组件运行。请求通过liteLLM，并被调度到可用的GPU节点上，甚至在需要时跨云调度。系统保持可预测性，因为模型生命周期、路由和计算都在单个控制平面下运行。
展望未来
最终，AI工作负载不需要单独的操作范式。通过将模型生命周期、推理和GPU容量标准化为一流的Kubernetes原语，团队获得了声明式配置和弹性调度。
“最终，AI工作负载不需要单独的操作范式。”
借助云原生架构中的KAITO、liteLLM和GPU Flex Nodes，平台工程师可以为AI开发者提供一个可靠的基础。跨云容量成为可互换的资源，使工作负载能够弹性扩展并高效地进行故障转移。
展望未来，随着集群跨越多个区域和提供商，拓扑感知调度将变得越来越有价值。放置决策可以包含延迟、数据本地性和成本考量，并在集群中以声明方式表达，而不是嵌入在应用程序逻辑中。这使得扩容和故障转移更加智能，同时不偏离云原生、Kubernetes驱动的原则。
