在Kubernetes上服务开源模型：五层工具与取舍

在Kubernetes上服务开源模型，靠的从来不是某一个工具。它更像一支完整的乐队：需要模型运行时、模型部署工具、集群管理，以及其他一些组件，才能让一切在GPU上协同工作。每一项工作该选哪个工具，取决于你要服务的是什么：是一个大模型，还是一堆小模型？在这份便于快速阅读的指南里，我会逐层介绍每一项工作、主要的开源工具，以及你应该考虑的取舍。如果你只需要一份推理服务器排名，我在《Top Kubernetes-Native Inference Servers Ranked (2026)》里已经讲过了。

Kubernetes服务栈的五层

大多数排名把所有工具放在一张清单里，但这样很难比较，因为它们做的是不同的工作：

• 运行时：把模型权重加载到GPU上，把请求变成输出。本指南涉及的工具：vLLM、SGLang、TGI。
• 服务平台：把运行时部署为Kubernetes资源，处理模型配置、发布和扩缩容规则。本指南涉及的工具：KServe、llm-d、NVIDIA Dynamo、KAITO、Ray Serve、SIE。
• 路由：把每个请求送到最适合回答它的Pod。本指南涉及的工具：Gateway API Inference Extension、vLLM Production Stack router。
• 自动扩缩容：随流量变化增减GPU Pod。本指南涉及的工具：KEDA、Knative、Horizontal Pod Autoscaler（HPA）。
• GPU配置：让GPU在集群里可见、可调度。本指南涉及的工具：NVIDIA device plugin、NVIDIA GPU Operator。

运行时：vLLM vs. SGLang vs. TGI

本指南里的每个平台最终都会调用一个运行时。对于开源大语言模型（LLM），有三个选项值得了解：

• vLLM：生成式LLM的默认选择，模型支持面广，提供兼容OpenAI的API。它的设计围绕“一个服务器一个模型”。小型的编码器模型用不太上它的LLM特性。处于活跃开发状态，被llm-d、KServe和KAITO采用。
• SGLang：适合请求共享长提示词前缀的场景（比如智能体、多轮对话）以及结构化输出。但多数Kubernetes运维方默认选vLLM，所以它在各平台上的支持程度不一。处于活跃开发状态，是Dynamo和SIE的后端。
• TGI：适合那些暂时还迁移不了的既有部署。目前只做小修小补，不再加新功能，自2025年12月起进入维护模式。

如果你还在跑TGI：Hugging Face现在只接受缺陷修复和文档更新，并建议后续转向vLLM、SGLang、llama.cpp或MLX。

运行时清单

• 想要最稳妥的默认项，选vLLM。
• 如果大量请求都以同一段很长的系统提示词开头，值得测一测SGLang。
• 生产环境里还有TGI在跑的，该安排迁移了。
• 嵌入或重排序模型在上LLM运行时之前，先测一测效果（《SIE vs. vLLM》说明了为什么结果常常出人意料）。

该用哪个服务平台管你的模型？

你需要的是给一个模型写个自定义资源定义（CRD），还是一整套面向多模型的平台？

• KServe：面向预测类和大模型两类工作负载的标准服务方案。代价是组件多、环节杂，小团队起步会比较吃力。Apache 2.0许可，CNCF孵化项目。
• llm-d：适合一个或少数几个大模型、高并发的场景。只做生成类任务；它的主要收益需要大模型和高速互联才能体现。Apache 2.0，CNCF沙箱项目。
• NVIDIA Dynamo：面向NVIDIA GPU上的多节点LLM服务。配置选项非常多，整体围绕NVIDIA硬件构建。Apache 2.0。
• KAITO：适合快速把一个Hugging Face模型变成可用端点，尤其在Azure上。只运行vLLM和Hugging Face模型。Apache 2.0，CNCF沙箱项目。
• Ray Serve（通过KubeRay）：适合用Python写的多步骤流水线。代价是Ray集群本身会带来一套运维工作。Apache 2.0。
• SIE：适合一个智能体背后的一群小模型共享少量GPU的场景。它不是为单个巨型模型设计的，从零扩容需要几分钟。Apache 2.0。

请求怎么找到对的Pod？

普通的Kubernetes Service会把请求均匀分到各个Pod上，但它并不知道哪个Pod已经缓存了提示词，也不知道哪个Pod的队列已经满了。

• Gateway API Inference Extension：引入一个InferencePool资源，网关通过它向端点选择器（EPP）询问每个请求该由哪个Pod处理。适合已经在用Envoy Gateway、kgateway、GKE Gateway或agentgateway的团队。自v1.6.0起，完整的端点选择器位于llm-d项目中。
• vLLM Production Stack router：一个通过Helm安装在vLLM Pod前面的路由器，提供服务发现、容错和监控面板。适合只运行vLLM、想要一套参考配置的集群。仅限vLLM。
• 内置路由器（llm-d、Dynamo、SIE gateway）：为特定平台优化的路由。适合已经选定某个平台的团队。代价是绑定该平台。

路由清单

• 只运行一个平台？先用它自带的路由器。
• 想混用网关或厂商？统一用InferencePool。

扩缩GPU Pod，又不想为空闲的GPU付费

GPU即使不处理请求也在花钱：

• HPA：基于CPU、内存或自定义指标扩缩容。默认不支持缩到零。适合流量稳定、始终留一个热Pod也划算的场景。
• KEDA：基于Prometheus指标（如队列深度或待处理请求）扩缩容。支持缩到零。适合GPU工作负载；KAITO和SIE使用它，KServe也支持它。
• Knative：基于每个Pod的并发请求数扩缩容。支持缩到零。适合KServe的无服务器模式和HTTP驱动的流量。

缩到零有一个隐藏成本：冷启动。SIE的自动扩缩容文档把整个过程拆解为：找GPU节点2-5分钟，启动容器20-40秒，加载模型10-120秒，总共3-7分钟。任何等待新GPU节点的平台都会面临类似的延迟。

自动扩缩容清单

• 凡是用户在等待的服务，至少保留一个热副本。
• 批处理任务和内部工具可以用缩到零。
• 设置与流量模式匹配的冷却时间（SIE默认缩容前等待15分钟）。

哪种技术栈最适合你的工作负载？

那么该部署哪种组合？如果你在构建……

• 一个高并发的大型聊天模型：运行时选vLLM，平台选llm-d或KServe，路由选LLMInferen