Kubernetes + LLM 实战：如何用 Gateway API Inference Extension 优化你的大模型推理服务

Kubernetes + LLM 实战：如何用 Gateway API Inference Extension 优化你的大模型推理服务

最近在折腾生产环境的LLM服务时，我遇到了一个挺头疼的问题：当你有多个模型、多个版本，甚至还有一堆LoRA适配器在集群里跑的时候，传统的Kubernetes Service和Ingress那套东西，感觉就像是用一把锤子去拧螺丝——不是不能用，但总感觉别扭。流量来了，它只知道按路径或者轮询往Pod里扔，至于这个Pod是不是正在处理一个超长的推理会话、GPU内存还剩多少、哪个模型版本应该接多少流量，它一概不知。结果就是，有的GPU闲得发慌，有的却因为队列堆积导致响应慢如蜗牛，灰度发布更是得靠手动切流量，运维起来简直是一场噩梦。

直到我发现了Gateway API Inference Extension，才算是找到了那把趁手的“螺丝刀”。这玩意儿不是什么全新的网关，而是在大家熟悉的Gateway API标准之上，专门为AI推理场景“打”的一个补丁。它让网关变得“聪明”起来，能看懂你请求里要的是哪个模型，能根据后端Pod的实时负载（比如请求队列深度、GPU内存压力）来智能调度，还能像玩跷跷板一样平滑地调整不同模型版本的流量权重。对于需要在Kubernetes上自托管大模型，并且对服务的稳定性、资源利用率和迭代效率有要求的团队来说，这几乎是一个必选项。

这篇文章，我就结合自己最近在A100集群上折腾Llama 3.1和多个LoRA适配器的实战经验，带你从零开始，把Gateway API Inference Extension这套东西摸透、用起来。我们会聊清楚它的核心设计，然后手把手部署一套完整的、支持智能路由和灰度发布的LLM推理服务栈。无论你是负责模型服务的开发，还是维护集群的运维，相信都能从中找到可以直接复用的思路和代码。

1. 为什么传统Kubernetes网络方案在LLM面前“失灵”了？

在深入技术细节之前，我们得先搞清楚问题在哪。把大语言模型塞进Kubernetes，和部署一个普通的Web服务，面临的网络挑战截然不同。如果你只是简单地把LLM服务暴露成一个Service，很快就会发现几个棘手的痛点。

首先，LLM推理请求是“有状态”且长生命周期的。一个生成数百个token的对话请求，可能会在GPU上停留数秒甚至数十秒，占用着显存中的KV缓存。传统的负载均衡器（比如kube-proxy的iptables模式或者大多数Ingress Controller）在处理HTTP请求时，默认是无状态的。它们通常采用简单的轮询（Round Robin）或最少连接数（Least Connections）算法。但在LLM场景下，把一个新请求发给一个已经满载的Pod，和发给一个空闲的Pod，用户体验是天壤之别。我们需要的是能感知后端Pod实时推理状态的调度。

其次，路由粒度需要细化到“模型”级别。一个vLLM服务进程可以同时加载多个LoRA适配器，对外提供多个“逻辑模型”。客户端请求通过model参数（遵循OpenAI API格式）指定要使用哪个模型或适配器。传统的路由基于HTTP路径（如/v1/chat/completions），无法根据请求体里的model字段做决策。这就导致要么为每个模型单独部署一套服务（资源浪费），要么在应用层自己写复杂的路由逻辑（维护成本高）。

再者，发布与运维流程复杂。今天上线一个新版本的LoRA适配器，明天要灰度10%的流量过去看看效果。在没有专门工具的情况下，你得手动调整Deployment的副本数、改Service的Selector、或者写一堆复杂的脚本去调用模型的加载/卸载接口。整个过程不仅容易出错，而且无法做到秒级的流量切换和回滚。

注意：这里说的“状态”并非指需要持久化到磁盘的会话状态，而是指在单次推理请求持续期间，GPU内存等计算资源被占用的临时状态。智能路由需要避免向已处于高负载的实例分发新请求。

最后是资源利用率与成本。GPU很贵，尤其是A100、H100这样的卡。理想情况下，我们希望集群里每一块GPU的算力都被充分利用，同时又要保证关键交互式请求的低延迟。这需要一套能够根据服务优先级（Service Criticality） 进行调度的机制。例如，实时对话请求的优先级高于后台批量摘要任务，系统应该优先保障高优先级请求的资源。

面对这些问题，社区之前涌现过一些方案，比如在模型服务前加一个自定义的代理层，或者利用Service Mesh的细粒度流量管理。但它们要么不够标准化，绑定特定实现；要么太重，引入了不必要的复杂度。Gateway API Inference Extension的巧妙之处在于，它基于Kubernetes原生的Gateway API标准进行扩展，提供了一套专为推理优化的、声明式的API资源。你可以把它理解为给Kubernetes的网络层加上了“AI推理加速卡”。

2. Gateway API Inference Extension 核心架构拆解

这套扩展的核心思想很清晰：在标准的HTTP路由层之下，插入一个专为AI推理设计的智能调度层。它不取代你现有的网关（如Envoy Gateway, KGateway），而是增强它们。整个架构围绕几个关键资源展开，理解它们之间的关系是上手的关键。

2.1 核心概念：InferencePool 与 InferenceModel

整个系统的基石是两个自定义资源定义（CRD）：InferencePool 和 InferenceModel。你可以把它们类比为Kubernetes中原生的Service和更上层的抽象。

InferencePool：你的模型服务器资源池 InferencePool定义了一组专门用于AI推理的Pod集合。它通过selector（和Deployment的selector一样）找到这些Pod，并知道它们监听哪个端口（targetPortNumber）。但它的作用远不止于此。

# 一个典型的 InferencePool 示例
apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
  name: vllm-llama3-8b-instruct
spec:
  targetPortNumber: 8000 # 模型服务监听的端口
  selector:
    app: vllm-llama3-8b-instruct # 选择标签为 app=vllm-llama3-8b-instruct 的 Pod
  extensionRef:
    name: vllm-llama3-8b-instruct-epp # 关联的智能调度器（EPP）

最关键的是extensionRef字段，它指向一个EndPoint Picker (EPP)。正是这个EPP组件，让InferencePool超越了普通的Service，具备了根据实时指标（如GPU内存、请求队列长度）选择最佳Pod的能力。

InferenceModel：逻辑模型的路由规则 如果说InferencePool管的是“物理”服务器，那么InferenceModel管的就是“逻辑”模型。它定义了客户端请求中的model参数如何映射到后端的实际模型或适配器，并可以设置优先级和流量拆分策略。