Marico's space

说起来，最近 AI（人工智能）模型的托管和部署已经成为 DevOps 领域最热门的话题之一。我之前做过一段时间的云原生基础设施相关工作，对 Kubernetes（简称 K8s）在生产环境中的应用还算熟悉。今天要聊的这两家平台——Replicate 和 Modal——算是目前 AI 模型托管领域比较有意思的存在。一个走的是「傻瓜式」路线，用 Cog 把模型打包成标准化容器；另一个则是代码优先，把 Python 函数直接变成可弹性伸缩的服务。虽然定位不同，但有意思的是，两家都把赌注押在了 Kubernetes 1.34 这个相对较新的版本上。趁着有空，我仔细扒了扒它们的架构设计，分享一些我的理解和思考。

Replicate 的 K8s 1.34 架构

Replicate 的核心工作流绕着 Cog 这个工具转。简单来说，Cog 的作用就是把 AI 模型打包成标准化的 Docker（多纳）容器，顺带把依赖版本和模型权重都给固定住。当用户在 Replicate 上部署一个模型时，控制平面会为每个模型版本创建一个 K8s Deployment，跑的正是这个 Cog 容器。

这里 K8s 1.34 的 动态资源分配（DRA） 功能就派上大用场了。跟老式的设备插件方案比起来，DRA 允许 Replicate 请求fractional（分数级）的 GPU 资源——也就是说，可以把一个 GPU 分成好几份，让多个小型的推理任务跑在同一个物理 GPU 上，还能根据实际负载动态调整分配比例。对于那些调用量不算大的模型来说，这简直是省钱的利器。

另外 K8s 1.34 的调度器延迟优化也是实打实的改进。我查了些资料，相比老版本，pod 启动时间能缩短将近 30%，这对推理请求的响应速度影响挺明显。模型权重的存储方面，Replicate 采用的是容器镜像缓存（通过节点本地的镜像仓库）和持久化卷的组合方案，K8s 1.34 的 CSI（即容器存储接口）驱动改进让挂载延迟也降了不少。流量高峰怎么办？Replicate 用的是带自定义指标的 HPA（水平 Pod 自动扩缩容）v2 版本，以请求队列深度作为扩缩容依据，再配合 K8s 1.34 的优先级抢占机制，把低优先级的批量训练任务让位给高优先级的推理 Pod。

Modal 的 K8s 1.34 架构

Modal 的思路就不一样了，它是典型的代码优先：开发者只需要给 Python 函数加个装饰器 @stub.function(gpu="A100")，GPU 资源就自动帮你搞定。底层实现上，每个 Modal 函数都对应一个 K8s Deployment，Pod 里跑的是用 gVisor 沙箱化的容器——配合 K8s 1.34 增强的 seccomp 和 SELinux 配置文件，隔离性相当靠谱。

Modal 的自定义调度器跟 K8s 1.34 的调度器框架做了深度集成，专门针对 GPU 拓扑做优化。它用 K8s 1.34 的拓扑管理器（Topology Manager）把 GPU 和靠近的 CPU 核心、内存对齐，减少 NUMA（Non-Uniform Memory Access，非均匀内存访问）带来的延迟。这对推理 workloads（工作负载）的性能影响挺大，毕竟内存访问路径短了，延迟自然就低了。

另外 Modal 也很依赖 K8s 1.34 默认启用的 cgroups v2 来做租户间的严格资源隔离，避免「吵闹的邻居」问题——毕竟是个多租户环境，谁也不希望别人的负载影响到自己的推理延迟。扩缩容这块，Modal 用 K8s 1.34 的自定义指标 API，把函数调用队列深度和 GPU 利用率喂给自动扩缩容器，而且还支持缩容到零——没有请求的时候就不跑 Pod，省钱是认真的。临时容器（Ephemeral Containers）功能在 K8s 1.34 稳定化之后，也让 Modal 的工程师能在不中断推理 Pod 的情况下调试生产环境问题，这个能力相当实用。

两家都离不开的 K8s 1.34 特性

虽然定位不同，但 Replicate 和 Modal 在底层技术上还是有不少交集的，这些 K8s 1.34 的特性是它们实现可靠、低成本 AI 托管的基础：

• 动态资源分配（DRA）： 细粒度的 GPU 共享、分数级 GPU 请求，以及在同一个节点上混合运行推理和训练任务的能力。
• cgroups v2： 更好的资源隔离、支持层级化的内存限制，以及改进的 I/O 节流，对推理 Pod 特别有用。
• 调度器框架改进： 调度延迟降低、GPU 节点评分更优，以及支持自定义调度插件。
• 自定义指标 API： 与自动扩缩容器集成，基于推理相关指标（延迟、队列深度、GPU 利用率）进行扩缩容。
• 临时容器： 在不终止工作负载的情况下对运行中的 Pod 进行实时调试，对排查生产环境推理问题至关重要。

架构上的关键差异

虽然都用 K8s 1.34 做地基，但往上走的架构设计就体现出两家的产品定位差异了：

• 模型中心 vs. 函数中心： Replicate 把每个模型版本当作独立的 K8s Deployment 来管理，Modal 则把单个 Python 函数映射到 Deployment。这导致 Replicate 更适合预训练模型的托管，Modal 更适合需要自定义前后处理逻辑的推理场景。
• 容器化方案： Replicate 要求使用 Cog 做容器化，强制标准化的模型打包流程。Modal 用自己的容器构建器，配合 Python SDK，使用上更灵活，允许自定义依赖。
• 扩缩容逻辑： Replicate 根据发到模型端点的 HTTP 请求量来扩缩容，Modal 则根据函数调用队列深度和 GPU 利用率来调整，对任意 Python 工作负载都能支持。

挑战与权衡

当然，用 K8s 1.34 也不是没有代价的。升级过程中的兼容性问题就够喝一壶的：NVIDIA GPU 驱动必须升级到 525 以上才能支持 DRA，containerd 等容器运行时也要做相应验证。冷启动延迟也是个老大难问题——虽然两家都用 Pod 预热和 K8s 1.34 更快的镜像拉取来优化，但大模型权重加载本身就要好几秒，冷启动时间还是不太好压下去。成本管理方面，主要靠 K8s 1.34 的资源配额和限制范围来防止 Pod 疯狂创建，再配合节点自动扩缩容来匹配实际需求。

结语

看完这两家的架构设计，我的感受是：K8s 在 AI 基础设施领域的存在感是越来越强了。以前大家可能觉得 K8s 太重，不适合这种需要快速弹性伸缩的 Serverless（无服务器）场景，但现在随着 K8s 1.34 在 GPU 管理、调度优化和扩缩容支持上的持续改进，它的适用范围明显在扩大。Replicate 和 Modal 虽然抽象层次不同，但都在用 K8s 1.34 的核心能力来解决 AI 模型托管的实际问题——延迟、成本、可靠性。后续随着 K8s 进一步引入 GPU 分区、Serverless 集成这类特性，估计这种「用 K8s 托 AI」的方案会越来越成熟。