北京车展这几天，智能驾驶和视觉算法相关讨论很多。
落到工程环境里，一个视觉推理服务通常会拆成几类容器：
- CUDA / cuDNN runtime
- PyTorch / TensorRT 推理环境
- ROS2 数据回放
- 视频处理服务
- Prometheus 指标采集
- K8s 基础组件
这类环境第一次部署时，常见问题不是代码异常，而是：
docker compose pull
卡住，或者 K8s 里直接 ImagePullBackOff。
服务拆解
假设有一个简化版视觉推理环境：
services:
ros-bag-runner:
image: docker.1ms.run/osrf/ros:humble-desktop
infer-worker:
image: docker.1ms.run/pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime
cuda-check:
image: nvcr.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04
metrics:
image: quay.1ms.run/prometheus/prometheus:v2.54.1
这里至少涉及 Docker Hub、NVIDIA、Quay 三类来源。如果后面上 K8s，还会涉及 K8s 基础组件。
预检命令
我会先把镜像阶段单独拉出来验证：
docker pull docker.1ms.run/osrf/ros:humble-desktop
docker pull docker.1ms.run/pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime
docker pull nvcr.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04
docker pull quay.1ms.run/prometheus/prometheus:v2.54.1
再执行：
docker compose pull
docker compose up -d
这样可以先确认“镜像能不能拉下来”，再看 GPU 驱动、模型路径、推理参数。
K8s 节点处理
如果推理服务跑在 K8s 里，新节点要提前预拉：
crictl pull k8s.1ms.run/pause:3.9
crictl pull k8s.1ms.run/coredns/coredns:v1.10.1
crictl pull nvcr.1ms.run/nvidia/cuda:12.4.1-runtime-ubuntu22.04
crictl pull quay.1ms.run/prometheus/prometheus:v2.54.1
节点镜像阶段稳定后，再处理：
- GPU device plugin
- runtimeClass
- nodeSelector / taint
- 模型文件挂载
- Prometheus scrape 配置
毫秒镜像的作用
毫秒镜像（1ms.run）在这里不是业务框架，而是基础设施入口。
它把 Docker Hub、NVIDIA、Quay、K8s 这些分散镜像来源统一成可访问前缀，减少视觉算法环境复现时的不确定性。
对推理服务来说，这一步的价值很明确：容器环境稳定后，后面的延迟、吞吐、显存和模型问题才有排查意义。
检查清单
上线前建议检查：
- 镜像版本固定，不用全量
latest。 - Docker Hub、NVIDIA、Quay、K8s 分源预拉。
- compose 中写入固定镜像前缀。
- K8s 新节点提前
crictl pull。 - GPU 容器先跑
nvidia-smi。 - 容器正常后再测推理接口和视频流。
视觉算法部署不是只把模型文件丢上去。镜像源、GPU runtime、K8s 节点和监控组件先稳定，推理服务才有继续优化的基础。
