Containerization

容器化是一种软件打包方式：将应用及其运行所需的一切内容（包括运行时、库、系统包和配置）打包到一个镜像中，并作为称为容器的隔离进程运行。每个容器都有自己的文件系统、进程树和网络接口，但同一主机上的所有容器共享主机的操作系统内核，因此比虚拟机轻量得多。在机器学习（ML）中，容器化可消除不同项目之间的依赖冲突，例如 Python、CUDA 或 PyTorch 版本不同造成的冲突；它还能确保在工作站上训练的模型无需修改，就能在服务器、集群或边缘计算设备上运行。

容器的工作原理#

Linux 容器主要依赖两项内核功能构建。命名空间控制进程可见的内容，为其提供独立的进程 ID、网络栈、挂载点和用户；cgroups（控制组）则通过限制 CPU、内存和 I/O，控制进程可使用的资源。这一理念源自 1979 年的 chroot 和 2000 年的 FreeBSD jail；cgroups 于 2008 年进入 Linux 内核；Docker 则于 2013 年推动容器走向主流。成立于 2015 年的开放容器倡议（OCI）标准化了镜像和运行时格式，因此使用一种工具构建的镜像可以在另一种工具下运行。

容器运行时负责执行实际操作。containerd 和 CRI-O 等高级运行时会拉取镜像并管理容器生命周期；runc 等低级 OCI 运行时则会创建命名空间和 cgroups，并启动进程。由于 Linux 容器需要 Linux 内核，macOS 和 Windows 会在一个小型 Linux 虚拟机中运行容器。

镜像、层与注册表#

镜像由一系列只读层和一份指定运行命令的配置组成。启动时，运行时通常使用 OverlayFS 将各层合并为一个文件系统，并为该容器添加一个很薄的可写层，因此多个容器可以共享磁盘上的同一份镜像。Docker Hub、GitHub Container Registry 以及各云服务提供商的注册表会按 latest 等标签和内容摘要存储镜像；内容摘要是 SHA-256 哈希，始终对应相同的字节。构建时会重用未更改的层，因此 Dockerfile 通常会先安装依赖，再复制经常修改的代码：

ML 工作流中的容器化#

在 MLOps流水线中，容器可以将项目从实验阶段带入生产环境。NVIDIA NGC Catalog等框架镜像会固定 CUDA、cuDNN 和框架版本，因此分布式训练任务的每个节点都运行相同的软件；主机只提供 GPU驱动程序，NVIDIA Container Toolkit 会将其暴露给容器。持续集成测试会在与后续发布相同的镜像中运行；用于模型服务的推理服务器以镜像形式运行，由 Kubernetes根据流量进行复制和扩缩容；NVIDIA Jetson开发板等边缘 AI设备则通过拉取新的镜像标签来更新模型。

Ultralytics Platform面向企业工作区的本地部署集成会在需要时安装 Docker，并运行一个与主机 ARM64、CPU 或 NVIDIA GPU 硬件相匹配的官方 Ultralytics 镜像工作容器。工作容器以只读方式挂载数据集文件夹，因此源图像会保留在该计算机上，而训练指标和每次YOLO26运行的最佳检查点则会发送到 Platform。

容器与虚拟机#

虚拟机在虚拟机监控程序上运行完整的客户操作系统，并拥有自己的内核；因此，每个虚拟机都包含数 GB 大小的操作系统镜像，启动方式也像一台独立计算机。容器则是共享主机内核上的普通进程，启动速度与其应用一样快，只会增加自身文件。共享内核也意味着，内核漏洞可能影响主机上的所有容器，因此两者经常组合使用：公有云会在虚拟机中运行客户容器；对于不可信代码，例如 AI 智能体在智能体沙箱中编写并运行的代码，沙箱运行时会增加第二道隔离边界。Google 的 gVisor 使用自己的用户空间内核拦截容器的系统调用。Kata Containers 会在轻量级虚拟机中运行每个容器；AWS 则构建了 Firecracker 微型虚拟机，以同样的方式隔离 AWS Lambda 函数。