从Ollama到vLLM：在Kubernetes上部署生产级AI Agent

本地跑通的AI Agent固然令人兴奋，但它有个致命短板：只服务一个人、一台机器。一旦合上笔记本，或者多个用户同时访问，整套系统立刻崩溃。如何把一个本地Agent推上生产环境？这篇文章基于一则实战演示，拆解从 Ollama 切换到 vLLM、并部署到 OpenShift（Kubernetes）集群的完整路径。

本地Agent的起点与局限

演示中的Agent已经具备相当完整的能力：挂载了三个工具——计算器、网页搜索器，以及一个连接 GitHub MCP 的工具。推理由开源权重模型 Qwen3 负责，通过 Ollama 在本地提供服务。整套系统免费跑在笔记本上，没有任何消息数据离开本机。

这个架构对个人开发、调试、演示都足够好。问题在于它天然是单机、单用户的。本地推理服务器（如 Ollama）面向的是单人交互场景，并非为高并发而设计。当需要让团队共享、或者让多个Agent同时调用同一个模型时，这套方案就撑不住了。

so it's living on a cluster instead of on my laptop.

关键的洞察是：上生产时，Agent本身的代码几乎不需要改动。真正改变的是模型跑在哪里、以及模型如何被提供服务。整个迁移只动两件事——推理服务层和部署载体。

第一步：用vLLM替换Ollama做推理服务

迁移的第一块是模型本身。Ollama 适合本地单机推理，而生产环境需要一个能扛住真实并发流量的推理服务器，vLLM 正是为此而生。

vLLM 的核心价值在于高效处理针对同一模型的大量并发请求。当多个用户或多个Agent同时命中这个模型时，vLLM 能够稳定支撑。底层还是同一个模型（Qwen3），但它所承担的工作性质已经不同——从服务一个人，变成服务一个集群的流量。

Let's take a look.

在 Red Hat OpenShift AI 中，可以通过 AI Hub 部署自有模型。演示中直接通过 URI 从 Hugging Face 拉取模型，但也支持从多种存储位置托管模型。选好硬件和运行时后即可完成部署。部署完成后，你会得到三样东西：

内部链接：供集群内部其他服务调用模型
外部链接：从集群外部访问模型
API Key：用于验证发往该模型的请求

这里有一个值得强调的点：虽然Agent代码不变，但配置里确实有一处必须改。在 .env 文件中，原先指向本地 localhost 上的 Ollama，现在改为指向集群内运行的 vLLM 服务；同时新增 API Key（因为模型现在公开托管在线上），并把 model ID 微调为 vLLM 期望的格式。这个配置文件，基本就是笔记本版本和集群版本之间的全部差异。

值得一提的是，这套架构对模型来源是无所谓的。无论你选择自托管开源模型，还是直接调用 Claude、GPT，Agent 都不在乎推理从哪来，只要有一个可对话的 endpoint 即可。演示选择自托管，只是因为它是一个更有展示价值的用例。

vLLM 之所以能高效处理并发，核心在于其 PagedAttention 机制。传统推理框架在处理每个请求时，需要为 KV Cache（注意力机制的中间状态）预先分配一整块连续显存，这导致大量显存碎片化浪费，并发数上不去。vLLM 借鉴操作系统虚拟内存的分页思想，将 KV Cache 切割成固定大小的块，按需动态分配，显存利用率可提升数倍。在此基础上，vLLM 还支持 Continuous Batching（连续批处理）：不同于传统静态批处理需要等一批请求凑齐才统一推理，Continuous Batching 允许新请求随时插入正在执行的批次，极大降低了排队延迟。这两项技术结合，使 vLLM 在相同硬件上的吞吐量通常比 Ollama 高出一个数量级，这也是它成为生产级推理服务事实标准的原因。

第二步：把Agent容器化并部署到集群

第二块是把Agent本身搬上集群。流程相对标准化：

从 OpenShift 控制台获取登录命令，粘贴到终端完成认证
启动 Podman（也可以用 Docker）
构建容器镜像
把镜像推送到 Quay 镜像仓库
部署

The second piece is getting the agent itself

演示中把这些步骤都封装成了 make 命令来自动化，完整命令可在配套仓库中查看。大约一分钟后，模型 endpoint 和 Agent 就并排运行在同一个集群里。Pod 被调度、启动——那个一分钟前还跑在笔记本上的Agent，现在已经作为一个 Pod 存活在 OpenShift 上。

OpenShift 是 Red Hat 基于 Kubernetes 构建的企业级容器平台，两者的关系类似于 RHEL 与 Linux 内核——Kubernetes 是开源底座，OpenShift 在其上增加了开发者工作流、内置镜像仓库、CI/CD 流水线、更严格的安全策略（如默认禁止以 root 运行容器）等企业特性。演示中使用的 Quay 是 Red Hat 提供的容器镜像仓库服务，功能上类似 Docker Hub 或 GitHub Container Registry，但提供了更细粒度的访问控制和镜像安全扫描能力。Podman 则是 Red Hat 主导的无守护进程（daemonless）容器运行时，命令行与 Docker 高度兼容，区别在于它不需要一个常驻的后台服务进程，每个容器直接作为用户进程运行，权限隔离更彻底。对于已熟悉 Docker 的开发者，切换到 Podman 的学习成本几乎为零。

验证：工具调用在集群里照常工作

部署完成后，就可以用那些依赖自定义工具的问题来验证Agent。演示里测试了网页搜索和数学计算，然后让它去 GitHub 检索一个 issue，再通过 GitHub MCP 创建一个新 issue。

We'll ask a web search and a math question.

Agent 能够通过同一个 MCP 工具完成读写操作，并且是从它在集群里运行的位置发起调用。聊天日志现在通过 Red Hat OpenShift AI 查看，而非本地终端。从模型、Agent 到 Playground，全链路都部署在集群内，模型通过 vLLM（而非 Ollama）提供服务。

「部署成功」不等于「生产就绪」

这是整篇演示最清醒的部分：deployed 和 production ready 是两头完全不同的野兽。

当前这个 Pod 存在一系列生产环境不可接受的问题：

它能读取自己容器里的任意文件，并几乎可以向任何地方发起外呼
对它的行为没有真正的可观测性，看不清它在做什么
几乎没有任何有意义的资源限制
没有多团队安全共享的概念
Agent 没有被分配权限，也没有对其行为做任何 scoping

换句话说，跑起来只是第一步。权限隔离、资源配额、可观测性、行为约束——这些才是把一个Agent真正送进生产的硬骨头，而它们各自都值得单独深入。

文中提到的生产就绪挑战，在 Kubernetes/OpenShift 体系内有对应的成熟解决方向：权限隔离通常通过 RBAC（基于角色的访问控制）和 ServiceAccount 实现，为 Agent Pod 分配最小必要权限；资源限制通过在 Pod 的 manifest 中设置 resources.requests 和 resources.limits 来约束 CPU 与内存用量，防止单个 Agent 耗尽集群资源；可观测性则依赖 OpenTelemetry 等标准协议将 Agent 的工具调用链路、延迟、错误率等数据导出到 Prometheus/Grafana 或专用的 LLM 可观测性平台（如 Langfuse、Phoenix）。对于 AI Agent 而言，可观测性尤为棘手——模型的推理过程本身是黑盒，工具调用序列又具有不确定性，传统 APM 工具难以直接适用，这也是当前 AI 工程领域最活跃的基础设施建设方向之一。

小结

这次迁移给出的核心经验非常实用：把本地Agent推向生产，重点不在于重写Agent逻辑，而在于更换推理服务层（Ollama → vLLM）和部署载体（笔记本 → Kubernetes/OpenShift）。真正需要改动的代码极少，几乎只是一个配置文件。但部署成功之后，安全与治理才是真正的工作重心所在。