核心要点
容器共享宿主内核、秒级启动且镜像分层缓存，比 VM 轻——是 ML 打包依赖的主流选择
Docker 把 CUDA、Python 依赖与代码固化成同一镜像，消除「本地能跑、线上不行」
K8s 负责编排：HPA 多副本扩缩容、NVIDIA device plugin 调度 GPU、滚动/金丝雀更新
镜像 tag 应对应模型+代码版本并入 CI/CD，切忌用 latest 导致不可追溯
简要回答
虚拟化（VM）：Hypervisor 隔离完整 OS，强隔离、较重，适合多租户硬隔离；
容器（Container）：共享宿主机内核，轻量、秒级启动，镜像分层缓存——ML 主流选择
标准回答
虚拟化（VM）：Hypervisor 隔离完整 OS，强隔离、较重，适合多租户硬隔离。
容器（Container）：共享宿主机内核，轻量、秒级启动，镜像分层缓存——ML 主流选择。
对 MLOps 的支持：
| 能力 | 说明 |
|---|---|
| 环境一致 | 开发/CI/生产同一镜像，消除「本地能跑」 |
| 可移植 | 云/本地/边缘同一 artifact |
| 版本化 | 镜像 tag 对应模型+代码版本 |
| 编排 | K8s Deployment/HPA 自动扩缩容 |
| GPU | NVIDIA device plugin 调度 GPU 容器 |
| 微服务 | 预处理、推理、后处理拆分解耦 |
典型流程：
- Dockerfile pin CUDA + Python 依赖
- CI 构建镜像 push registry
- K8s manifest/Helm 部署；KServe/BentoML 封装推理
- 金丝雀更新 image tag
注意：镜像体积（多阶段构建）、GPU 驱动与 CUDA 版本匹配、有状态训练需挂载 PVC。详见 MLOps 入门、部署实践。
常见误区
⚠️ 常见踩坑
把容器当成虚拟机用（每容器塞 systemd）；镜像不设 tag 用 latest；忽视 GPU 资源 request/limit。
追问
追问 1：训练用容器有何坑？
镜像内 CUDA/cuDNN 版本要与宿主驱动兼容，否则 GPU 不可用；训练数据与 checkpoint 是有状态的，需挂载 PVC/对象存储而非写进容器层；大数据集的 I/O 易成瓶颈，需 prefetch；多 GPU 分布式还要配好 NCCL 与网络。
追问 2：Serverless 容器适合 ML 吗？
适合轻量、低频、可接受冷启动的推理（小模型、CPU 推理）。不适合需要常驻 GPU、加载大模型权重（冷启动慢）或长时训练的场景——那些更适合常驻 GPU 实例或 K8s。可混合：主流量用常驻服务，长尾/突发用 serverless 兜底。
追问 3：VM 何时仍需要？
强合规隔离、不同客户硬隔离、特殊驱动（部分裸金属 GPU 性能更优）。容器跑在 VM 上是常见多层隔离。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。
📰 AI 资讯
🛠️ AI 工具