随着大模型(LLM)在 Kubernetes 上的普及,推理服务的冷启动性能日益成为瓶颈。近日,开源项目 Hermes 通过实测展示了如何显著优化这一流程。在 Kubernetes 环境中,包含 PyTorch、CUDA 及 Python 依赖的 vLLM 等推理镜像体积常超过 10GB。在传统的 containerd 或 overlayfs 存储驱动下,节点必须完整下载并解压镜像后,Pod 才能启动,这导致在 Karpenter 等弹性扩容场景下,业务响应延迟高达 4 分 35 秒。Hermes 项目提出了一种无需修改业务 Dockerfile 或 CI/CD 流程的解决方案,其在平台侧定义 HermesPolicy,由 Controller 自动为匹配的镜像构建并缓存 SOCI(Seekable OCI)索引,节点侧 Daemon 组件随后利用这些索引实现镜像的延迟加载。基于 Amazon EKS 和 Karpenter 的实测数据显示,针对 763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2 这一约 10.8GB 的镜像,开启 Hermes 后,Pod 从调度到 Ready 的时间从原本的 4 分 35 秒骤降至 14 秒。这意味着镜像拉取与挂载阶段的耗时降低了约 95%。该项目目前定位为集群侧的通用优化能力,通过策略决定哪些镜像启用延迟加载,适用于各类 AI 推理场景。
事件分析
💡 核心观点:只有将镜像加载从全量下载阻塞转变为按需读取流式加载,才能真正释放云原生环境下 AI 算力的弹性潜力。
原文链接:V2EX 分享发现





