最近在看 Kubernetes 上 AI 推理服务的冷启动问题，发现很多时候慢的不只是模型加载，容器镜像本身也很夸张。

比如 vLLM 这类镜像，里面有 PyTorch 、CUDA 、Python 依赖、系统库，动不动就是 10GB+。传统 containerd / overlayfs 路径下，节点要先完整下载并解压镜像，Pod 才能真正起来。对 Karpenter 这种弹性扩容场景来说，这部分时间会很明显。

我们做了一个小项目 Hermes：

https://github.com/cloudpilot-ai/hermes

想法是：不让业务团队改 Dockerfile 、不重建镜像、不改 CI/CD ，也不改原来的 image reference 。平台侧定义一个 HermesPolicy ，controller 在集群内自动为匹配到的镜像构建并缓存 SOCI index ，节点上的 daemon 再用这些 index 做 lazy loading 。

这次用 EKS + Karpenter 跑了一个简单对比，镜像是：

763104351884.dkr.ecr.us-east-1.amazonaws.com/vllm:0.9-gpu-py312-ec2

大概 10.8GB 。

普通节点上，从 Pod 调度到节点后，到容器 Running/Ready：

5m04s - 29s = 4m35s

开启 Hermes 的节点上，在 HermesPolicy 已经 Ready 、SOCI artifact 已经构建好的前提下：

44s - 30s = 14s

也就是这个场景里，镜像拉取/挂载到容器启动这段，从 4m35s 降到了 14s 。

需要强调一下：这个结果不包含首次 index 构建耗时，也不等于 vLLM first token latency 。Pod Ready 变快，只说明容器镜像这条路径被 lazy loading 优化了。后面还需要继续测 vLLM readiness 、first request TTFT 、warmup 后真实请求延迟。

Hermes 现在的定位更像一个集群侧能力：应用继续发原来的 OCI image ，平台通过策略决定哪些镜像需要被 lazy load 。类似：

apiVersion: hermes.cloudpilot.ai/v1alpha1
kind: HermesPolicy
metadata:
  name: prod-large-images
spec:
  paused: false
  imageSelectors:
    - imageRegex: ".*vllm.*"
  platforms:
    - linux/amd64

目前还比较早期，欢迎大家关注项目： https://github.com/cloudpilot-ai/hermes