在构建 AI Agent 或强化学习训练平台时，最常见的默认动作是把计算层交给 Kubernetes。它擅长维护和扩展那些已知的、长期运行的稳定服务副本——镜像固定、行为可预测、副本数可控。可当真实的 AI 工作负载同时涌入时，画面立刻变了。

三个任务几乎同时到达同一套计算平台：一个运行自定义容器的机器人仿真、一个需要精确 CUDA/Python/模型服务组合的语音 Agent、一个客户直接提交的黑盒容器。它们没有任何共同点，都必须从零开始物化出完整的隔离环境。这才是当下 AI 基础设施每天要面对的常态。Kubernetes 从设计之初就不是为这种场景而生的。

我起初认为，只要把镜像提前拉到节点、把本地缓存和懒加载调到极致，Kubernetes 的启动开销就能被压到可接受范围。后来看到 Daytona 团队给出的 500 次环境启动基准数据后，这个假设被彻底推翻。他们给了 Kubernetes 几乎所有能想到的优势：镜像全部预拉取到节点，测量路径里完全没有下载开销，对比条件对 Kubernetes 最有利。

结果却很直接。Daytona 到首次可执行命令的中位时间：

• 1 个环境：1.05 秒
• 10 个环境：1.13 秒
• 100 个环境：1.10 秒

Kubernetes 对应中位时间：

• 1 个环境：4.17 秒
• 10 个环境：4.27 秒
• 100 个环境：4.37 秒

中位延迟始终保持大约 4 倍差距。哪怕工作集从 1 扩到 100，Kubernetes 的数字几乎没有改善，Daytona 也始终稳定在 1 秒出头。

更关键的是累积效应。500 次顺序启动的总时间：

• 1 个环境工作集：Daytona 16 分钟，Kubernetes 47 分钟
• 10 个环境工作集：Daytona 26 分钟，Kubernetes 48 分钟
• 100 个环境工作集：Daytona 31 分钟，Kubernetes 50 分钟

每一秒的差距在成百上千次启动后变成实实在在的空转算力和账单。任务启动得更晚，机器闲置得更久，基础设施成本被无形抬高。这还没把运维侧的持续调优算进去——镜像仓库镜像、自定义 AMI、本地缓存、懒加载……每多一层优化，系统就更专属于某一种工作负载形态，通用性被一点点牺牲掉。

可以把 Kubernetes 想象成一条高度优化的汽车总装线：同一车型、同一配置、源源不断。它极擅长这件事。可 AI 平台更像每天要临时搭建完全不同的实验台——有的要液压机械臂，有的要精密光学台，有的干脆是客户自带的神秘设备。你不可能用总装线去应付这些。沙箱更接近那种能在几秒内按图纸搭好、用完立刻拆走的模块化实验舱。

Daytona 的分布其实有更重的尾部：绝大多数启动很快，少数会稍慢。Kubernetes 整体更慢，但分布更紧，几乎都挤在 4-5 秒。如果你的核心诉求是“最坏情况绝对可预测”，Kubernetes 仍然有价值。可一旦场景变成“大量短生命周期、彼此完全不同的环境需要被快速拉起”，中位延迟和累积时间才是真正决定吞吐和成本的变量。

在强化学习训练、Agent 评估、或者任何需要成百上千个异构环境反复启动的流水线里，这个差距会被每一次 rollout 放大。沙箱在中位延迟上赢 4 倍，在总累积时间上大约赢 3 倍。Kubernetes 依然是维护和扩展稳定服务的正确工具，却不是按需物化多种短生命周期环境的合适原语。

如果你正在搭 AI Agent 基础设施，并且默认还在伸手拿 Kubernetes，不妨自己跑一遍同样的基准。数据摆在那里，选对原语比选对熟悉度更重要。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。