最近在看 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