开源模型缩小与闭源差距，推动智能体时代

当业界各组织最初采用生成式 AI 时，大多数是通过托管 API 来使用它，但开放权重模型正在改变这一局面。Qwen 系列和 GLM-5 等模型发布在 Hugging Face 等模型仓库上，许多采用 Apache 2.0 许可，可直接加载到 vLLM 和 SGLang 等开源服务引擎中。

“对于越来越多的工作负载而言，这一差距已经小到模型不再是主要制约因素。”

2025 年闭源模型进一步拉开了领先优势，但幅度并不大。斯坦福 AI Index 2026 显示，截至 2026 年 3 月，在 Arena 排行榜上，最强闭源模型对最强开源模型的领先优势为 3.3%。对于越来越多的工作负载而言，这一差距已经小到模型不再是主要制约因素。

KubeCon + CloudNativeCon 将于 11 月 9 日至 12 日在盐湖城举行。立即注册！

部署一个下载好的模型是简单的部分；价值来自对它的改动：用自己的数据做微调，或针对自己的任务应用强化学习（RL），然后把改进后的版本重新投入服务。这个学习闭环正是大部分成本和基础设施复杂性所在。

设想一个平台团队构建的内部编码 agent，用于修复失败的 CI 构建，它运行在一个从 Hugging Face 拉取的开放权重模型上。当构建失败时，agent 将仓库克隆到沙箱中，读取日志，编写补丁，并运行测试。每一次尝试都会产生一条轨迹，即单次运行的记录，并带有清晰的奖励信号，因为测试要么通过，要么不通过。

这些轨迹喂入学习闭环。团队按计划在成功的修复上微调模型，或针对奖励运行 RL 任务，然后评估新的 checkpoint 并在现有端点后面上线。随着时间推移，模型学会了团队的代码库如何出问题以及如何被修复。这一个工作流结合了三种工作负载类型，而每一种都以不同方式给平台带来压力。

学习闭环难在哪里

• 三种工作负载，三个平台？

推理需要长时间运行的副本，随流量伸缩并快速启动。微调和 RL 任务则几乎相反：跨 GPU 成组调度（gang-scheduled）并运行至完成。Agent 需要快速启动的短生命周期执行环境。为每一类分别搭建独立基础设施的团队，最终会在一处闲置 GPU，在另一处排队等待任务，而每一次交接都会增加成本。

• 高密度下的不可信代码

Agent 执行的是模型几秒前写出的代码，而共享内核是一道薄薄的边界。示例中的 CI agent 大部分时间也都在等待模型响应或测试运行。为每个 agent 分配一个专用的、常开的 pod 会让隔离变得昂贵，因此团队往往用安全性换取密度。

• 分散的算力和缓慢的启动

团队逐步增加 GPU，跨区域部署，有时还使用他们本地已经拥有的硬件。一个训练任务可能适合放在已存在但位于集群之外的算力上，而当推理扩容时，每个新副本在服务第一个请求之前都必须加载数十 GB 的权重。

整个闭环一个控制平面

与其为每个阶段构建单独的平台，不如把学习闭环当作一个标准的云原生系统问题来处理。Kubernetes 已经在协调声明式状态并调度工作。现在的任务是把这些原语扩展到模型、agent 和加速器上，在共享控制平面上为这一模式提供三层。

模型层：将服务和调优作为声明式工作负载

模型层涵盖服务、微调和评估。有多个开源项目在此领域工作，包括 KServe、llm-d 和 Kubernetes AI Toolchain Operator（KAITO）。KAITO 将模型及其 GPU 需求表示为自定义资源，并协调该状态。模型更新变成对期望状态的变更，而不是某人必须运行的脚本。

在训练方面，Kueue 处理排队和成组调度，而 KubeRay 编排分布式任务。如果你不想自己拼装这些组件，微软于 2026 年 8 月开源的 TauGrid 将它们与 GPU 健康监控和可观测性打包成一次 Helm 安装。

模型流式加载有助于缓解冷启动。vLLM 支持的 Run:ai Model Streamer 直接从对象存储读取张量到 GPU 内存，而不是先暂存到本地磁盘，因此新副本能更快开始服务。

Agent 执行层：隔离而无需为闲置时间付费

Agent 执行层运行 agent 产生的代码，这里的项目处于不同层级。Kata Containers 和 gVisor 将工作负载与宿主内核隔离。来自 Kubernetes SIGs 的 agent-sandbox 将沙箱化的 agent 作为 Kubernetes 资源管理，而 Agent Substrate 在其之上构建，将许多 agent 打包到更少的工作节点上。Hyperlight 是微软于 2024 年捐赠的 CNCF Sandbox 项目，它在更细的粒度上工作，位于应用程序内部。

Kata 在轻量级 VM 中运行每个 pod，该 VM 有自己的 guest 内核，而 pod API 保持不变。工作负载通过其 runtime class 选择启用，部署的其他方面无需改变，这就是 agent-sandbox 能将 Kata 用作沙箱化 agent 后端的原因。Kata 支持多种虚拟机监视器，包括 Cloud Hypervisor，Agent Substrate 将其用于其 microVM 类别。

Agent Substrate 通过将大量有状态 agent 映射到较小的预热工作节点池、实时分配工作，并将闲置 agent 挂起到对象存储以便按需恢复，来解决密度问题。它默认使用 gVisor 隔离，并提供基于 Kata 和 Cloud Hypervisor 构建的可选 microVM 类别。Agent 保持隔离，而你不再为它们等待的时间付费。

Hyperlight 在应用程序中嵌入一个 micro-VM 管理器，在 VM 内运行 guest 代码，无需内核或操作系统。VM 在一到两毫秒内启动，并且可以快照和恢复 VM 内存。

计算层：将算力带入集群

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）