作者：卢建晖 - 微软高级云技术布道师
排版：Alan Wang

当企业将生成式 AI 从 Demo 阶段推进到真实业务负载时，最棘手的问题往往已经不再是“模型能否回答一个 Prompt”，而是整个系统能否长期稳定、可预测、安全且具备成本效益地运行。尤其是在各大模型提供商不断调整 Token 定价、上下文窗口计费、批处理折扣以及模型分层策略的背景下，这一点变得尤为重要。

这正是 AI Runway 发挥价值的地方。它将模型部署能力转化为 Kubernetes 原生的平台能力。AI Runway 不再要求每个应用绑定特定的推理运行时，而是允许团队通过统一的 ModelDeployment 资源描述模型服务意图，由平台在底层自动选择或委派合适的推理引擎与提供商。

对于已经采用 Kubernetes、AKS 或云原生平台工程实践的团队来说，AI Runway 提供了一条切实可行的路径，帮助企业从“调用外部模型 API”迈向“运营企业级推理平台”。

为什么我们需要一个自托管推理平台？

许多团队已经在知识助手、代码生成、内容创作、客户支持、文档处理以及 Agent 工作流中验证了大语言模型（LLM）的价值。但一旦使用规模增长，几个平台层面的问题会很快出现。

Token 成本会变成一个工程问题

在概念验证阶段，Token 使用通常看起来只是预算中的一小部分。但在生产环境中，它会变成一个架构层面的关注点。一次 RAG 请求可能会包含系统 Prompt、用户输入、检索到的上下文、工具输出以及最终答案。一个 Agent 工作流可能会多次调用模型，用于规划、路由、摘要、验证和生成。一个被数百名员工使用的内部 Copilot，可能会产生超出原始项目团队预期规模的 Token 消耗。

外部模型 API 的成本同样会受到模型版本、输入/输出 Token 比例、上下文长度、缓存策略、批处理以及供应商定价策略的影响。当模型供应商调整价格时，没有替代路径的企业就只能被动接受价格变化。

自托管推理并不意味着替换所有外部模型。它意味着为高频、可预测、本地化或对隐私敏感的工作负载创建一个可控的平台层。

应用场景	自托管推理的优势
高频内部问答	可通过小模型或量化模型承载海量请求
文档摘要与信息提取	任务模式固定，适配专用本地模型
Agent 中间步骤	规划、分类、改写类任务无需调用顶级闭源大模型
边缘或私有网络工作负载	数据需严格保留在可控内网边界内
成本敏感型应用	借助 CPU/GPU 资源池、请求批处理、模型分层策略，降低单位调用成本

数据边界与合规要求会变得更加明确

许多企业愿意使用云托管模型，但它们同样需要对数据分类、访问边界、日志记录和审计拥有清晰的控制能力。一个自托管推理平台能够让敏感文档、内部知识库、客户交互以及业务上下文保留在受治理的网络和运营模型之内。

团队不应该被锁定在单一推理引擎上

推理引擎正在快速演进。vLLM、SGLang、TensorRT-LLM 和 llama.cpp 分别适用于不同需求。有些针对高吞吐 GPU 服务进行了优化。有些更适合结构化服务或 NVIDIA GPU 加速。还有一些让 GGUF 量化模型能够在 CPU 或轻量级 GPU 环境中高效运行。一个平台不应该强迫所有团队使用同一种运行时。它应该提供统一入口，并在底层吸收不同运行时之间的差异。

生产级 AI 需要模型运维，而不仅仅是 Endpoint

生产工作负载需要部署生命周期管理、状态监控、日志、指标、扩缩容、调试、渐进式发布、资源配额以及安全入口等能力。一个自托管推理平台应该避免让每个团队都手工编写特定运行时的 YAML，而是应当将这些能力作为共享的平台基础能力提供。

什么是 AI Runway？

AI Runway 是一个 Kubernetes 原生的平台，用于部署和管理大语言模型。它的核心理念是通过一个统一的 Kubernetes CRD —— ModelDeployment 来描述模型部署意图。随后，AI Runway Controller 会基于不同 Provider 的能力，选择或委派给对应的 Provider 专属 Controller。

该项目这样描述自己：

在 Kubernetes 上部署和管理大语言模型 —— 无需编写 YAML。

AI Runway 支持 Web UI、REST API、Headlamp 插件，以及通过 kubectl 直接管理 CRD。UI 是可选且可替换的；平台的核心能力存在于 Controller、CRD 以及 Provider 抽象层中。

关键能力

能力	价值
统一的 ModelDeployment CRD	使用一个 API 统一管理模型、引擎、资源、扩缩容和网关配置
多 Provider 支持	支持 KAITO、NVIDIA Dynamo、KubeRay、llm‑d 以及 Provider shim
多推理引擎支持	支持 vLLM、SGLang、TensorRT‑LLM 和 llama.cpp
自动选择 Provider 与引擎	根据 CPU/GPU 需求、服务模式以及 Provider 能力自动匹配
Web UI 与 Headlamp 插件	简化模型发现、部署与监控
Hugging Face 集成	支持模型目录浏览与部署
可观测性	展示部署状态、日志以及 Prometheus 指标
Gateway API 集成	通过网关实现统一的 OpenAI 兼容路由
成本与容量建议	帮助进行 GPU 适配、定价与容量决策

多引擎支持是关键差异化能力

AI Runway 不只是另一个模型部署工具。它最重要的价值在于，将应用开发者与推理运行时决策解耦。应用可以调用 OpenAI 兼容 Endpoint 或统一网关，而由平台决定应该使用哪个引擎和 Provider 来服务特定模型。

引擎	典型使用场景	资源目标
vLLM	高吞吐量通用 LLM 服务	GPU
SGLang	复杂推理工作流与结构化服务	GPU
TensorRT‑LLM	NVIDIA GPU 上的高性能优化推理	GPU
llama.cpp	GGUF 量化模型与轻量级推理	CPU / GPU

对于团队而言，这是一个非常重要的能力：AI Runway 不再强迫所有团队使用相同运行时，而是构建了一个统一的平台，让不同工作负载可以选择不同引擎，同时保持一致的开发者体验。

AI Runway 架构概览

下面的 Mermaid 图展示了 AI Runway 平台层级的简化视图。

有三个设计要点尤为重要：

1. 统一控制平面：用户提交 ModelDeployment 资源，而不是为每一种运行时手工编写 YAML。

2. Out-of-tree Provider：KAITO、Dynamo、KubeRay 和 llm-d 通过 Provider shim 与 Controller 声明各自能力。

3. 可替换的运行时层：同一个平台既可以服务基于 CPU 的 llama.cpp 模型，也可以运行基于 GPU 的 vLLM 或 TensorRT-LLM 工作负载。

方案一：使用 AI Runway、KAITO 与 CPU 的本地 Kubernetes

本地 Kubernetes 非常适合学习、演示、开发验证以及小模型原型实验。目标并不是获得最大吞吐量。目标是验证 AI Runway + KAITO + llama.cpp 能够在无需 GPU 的情况下，提供 OpenAI 兼容的模型服务。

何时使用这种模式

场景	说明
本地开发者实验	使用 kind、minikube、k3d 或 Docker Desktop Kubernetes
平台演示	展示 ModelDeployment、Provider 以及 OpenAI 兼容 API 的工作流程
仅 CPU 验证	无需 GPU 或云资源
SLM / GGUF 测试	使用 llama.cpp 提供量化模型服务

对于本地 CPU 推理，建议至少分配 4 vCPU 和 12 GiB 内存。即使是小模型，也需要内存用于运行时启动、模型加载、KV Cache 以及上下文窗口。

本地架构

本地 KAITO + CPU 模式对于学习和推广非常有价值：

• 开发者无需 GPU 即可学习 ModelDeployment 抽象。

• 应用无需了解后端究竟是 LocalAI、llama.cpp 还是 KAITO Workspace。

• 仅 CPU 环境仍然可以运行轻量级和量化模型。

• 团队可以在迁移到 AKS 或生产集群之前，在本地验证模型、Prompt 与 API 行为。

示例指南：https://gist.github.com/kinfey/28b2338845cc63139aee2ea462a3c466

方案二：在 Azure 上结合 AKS、AI Runway、KAITO 与 CPU

在完成本地验证之后，下一步通常是构建一个云托管推理平台。AKS 提供托管 Kubernetes 控制平面、节点池、网络、身份认证、监控以及 Azure 生态集成。它是 AI Runway 在生产或预生产环境中的天然基础平台。

下面的示例使用仅 CPU 的 AKS + KAITO + Qwen3-0.6B GGUF，在无需 GPU 节点的情况下构建一个云托管推理服务。

Azure 架构

AKS 生产环境建议

领域	建议
安全入口	不要直接暴露明文 HTTP 80；应增加 TLS、API Key、OAuth2 Proxy、WAF 或内部 LoadBalancer
模型治理	固定模型版本、镜像版本以及 GGUF 文件名
成本治理	轻量级任务使用 CPU，大模型高吞吐任务使用 GPU
可观测性	集成 Azure Monitor、Prometheus、日志以及请求级指标
配额规划	部署前检查区域 vCPU/GPU 配额
缓存	使用 PVC 或模型缓存卷以减少重复下载
GitOps	通过 GitOps 管理 ModelDeployment、Provider 与 Ingress
访问控制	使用 Namespace、RBAC 与 NetworkPolicy 进行团队隔离

示例指南：https://gist.github.com/kinfey/d439a545d8c93e15d8a2854b65f03d4d

如何在工程组织内部推广 AI Runway

在介绍 AI Runway 时，我会避免以“我们正在构建自己的模型平台”作为开场。一个更有效的叙事方式是：

1. 从成本可预测性切入：高频工作负载不应该全部依赖最昂贵的外部模型层级。

2. 强调技术选择自由：团队可以使用不同模型与推理引擎，同时保持统一的平台入口。

3. 突出 Kubernetes 原生运维能力：现有的 AKS、RBAC、监控、GitOps、网络与安全实践都可以复用。

4. 通过 CPU Demo 降低门槛：本地 KAITO + CPU 可以让开发者在无需 GPU 的情况下理解完整工作流。

5. 将 Azure 作为生产落地区域：AKS 能够将同样的抽象能力扩展到云环境，并进一步演进到 GPU、网关、监控以及多租户治理场景。
   

这一路径避免了一开始就陷入 GPU 采购、复杂调度或完整平台治理的问题。应当从小规模开始，先验证抽象能力，随后再随着平台成熟逐步引入更高性能的推理引擎与更完善的治理能力。

结语

随着 AI 应用进入生产环境，企业需要的不再只是一个能够回答 Prompt 的模型。它们需要的是一个可控、可观测、可扩展并且可持续演进的推理平台。AI Runway 将这一问题重新带回 Kubernetes 平台工程领域：使用 ModelDeployment 标准化模型部署，使用 Provider 屏蔽运行时差异，并通过多种推理引擎匹配不同的成本与性能目标。

从本地 Kubernetes 上的 KAITO + CPU Demo，到 AKS 上基于 Qwen3-0.6B 的 CPU 推理服务，AI Runway 提供了一条清晰的落地路径：从低门槛环境开始，再逐步演进到多模型、多引擎、多 Provider、统一网关以及企业级治理的推理平台。

在一个 Token 定价频繁变化、模型生态快速演进的时代，自托管推理平台并不是为了拒绝外部模型。它真正的意义在于，让工程团队能够对成本、架构以及技术选型拥有更强的控制力。

参考资料

• AI Runway GitHub

• AI Runway Architecture

• AI Runway Providers

• AI Runway CRD Reference

• KAITO

• LocalAI

• AKS Application Routing

• Qwen3-0.6B GGUF