【初阶·云原生】AI 应用容器化交付深度解析：模型打包、镜像化与云原生工作流

【初阶·云原生】AI 应用容器化交付深度解析：模型打包、镜像化与云原生工作流

专栏：《AI 工程与安全深度实战》· 第1轮·第1篇

前言

• 核心痛点：当 AI 模型从实验性原型走向生产环境时，企业面临一个根本性难题——如何像管理传统软件制品一样，对数十 GB 甚至 TB 级别的模型文件进行版本化、安全扫描、签名验证与可复现交付？传统 ML 工程师用 scp、S3 桶脚本拷贝、共享 NFS 挂载等方式分发模型的做法，在 Kubernetes 时代的集群规模化部署中已经完全不可行。
• 适配人群：适合 ML 工程师、AI 平台工程师、DevOps/SRE 工程师以及对云原生 AI 基础设施感兴趣的中高级开发者。要求读者具备 Docker 与 Kubernetes 的基本使用经验，了解 PyTorch/TensorFlow 等深度学习框架的基本概念。
• 收获能力：读完本文你将掌握：OCI 制品与容器镜像在模型打包中的完整原理、Docker Model Spec 与 CNCF ModelPack 标准的核心架构、AI 训练/推理容器的 Dockerfile 最佳实践（GPU 支持、多阶段构建、shm 与 NCCL 配置）、Harbor + Dragonfly 企业级模型注册中心与 P2P 分发体系的搭建方法，以及基于 Kubernetes Image Volumes 的模型部署落地实战能力。

技术背景与演进逻辑

传统 ML 模型交付的碎片化困境

在容器化理念深入软件工程的今天，AI/ML 领域的制品管理却长期停留在"手工作坊"阶段。回顾典型 AI 团队的模型交付流程：

数据科学家训练模型 → 导出 .pt / .safetensors / .h5 文件
↓
上传到 S3/MinIO 对象存储桶（手动命名：model_v2_final_fixed.pt）
↓
运维团队编写下载脚本（curl/wget + 环境变量拼路径）
↓
GPU 节点启动时拉取模型文件（串行下载，无缓存，无校验）
↓
推理引擎（vLLM/TGI/TensorRT-LLM）加载模型 → 启动服务

这套流程的致命缺陷在于：

容器化交付范式的必然性

容器技术的核心价值在于：将应用及其运行时依赖封装为不可变制品，在开发、测试、生产环境间实现一致性交付。

将这套范式迁移到 AI 模型交付中，意味着：

• 模型权重 + 推理引擎 → 解耦为独立制品，通过 OCI 标准注册中心统一管理
• 版本标签（sha256:abc…） → 替代 model_v2_final_fixed.pt，实现内容可寻址的不可变版本
• 签名与证明 → Cosign/Notation 对模型制品签名，SLSA 证明记录构建来源
• P2P 分发 → Dragonfly 将模型权重分片并借助节点间 P2P 传输，将集群就绪时间从 40 分钟压缩到 5 分钟以内

核心生态项目总览（截至 2026 年 6 月）

核心原理深度解析

OCI 制品：从容器镜像到模型权重的范式扩展

OCI 镜像的基本结构

OCI（Open Container Initiative）镜像由三个核心组件组成：

OCI 镜像结构：
├── 镜像清单（Image Manifest） — JSON 文档，引用 config 和 layers
│ ├── config（镜像配置） — JSON，含层排序和运行时参数
│ └── layers[]（文件系统层） — TAR 归档（通常 gzip 压缩），顺序叠加为 rootfs

一个典型的 OCI 镜像清单（Manifest）如下：

{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"config": {
"mediaType": "application/vnd.oci.image.config.v1+json",
"digest": "sha256:7b4721e214600044496305a20ca3902677e572127d4d976ed0e54da0137c243a",
"size": 477
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"digest": "sha256:189fdd1508372905e80cc3edcdb56cdc4fa216aebef6f332dd3cba6e300238ea",
"size": 1844697
}
]
}

manifest 的 sha256 摘要即镜像的全局唯一标识（image digest），实现了内容可寻址的不可变版本管理。

OCI 制品（Artifact）：超越镜像的通用分发格式

OCI 制品复用了镜像的 Manifest + Config + Layers 结构，但放宽了 Layers 的限制——layers 可以是任意媒体类型，不再局限于文件系统变更集的 tar 归档。制品的类型由 config.mediaType 标识。

以 Helm Chart 作为 OCI 制品为例：

{
"schemaVersion": 2,
"config": {
"mediaType": "application/vnd.cncf.helm.config.v1+json",
"digest": "sha256:8ec7c0f2f6860037c19b54c3cfbab48d9b4b21b485a93d87b64690fdb68c2111",
"size": 117
},
"layers": [
{
"mediaType": "application/vnd.cncf.helm.chart.content.v1.tar+gzip",
"digest": "sha256:1b251d38cfe948dfc0a5745b7af5ca574ecb61e52aed10b19039db39af6e1617",
"size": 2487
}
]
}

Docker Model Spec：LLM 的 OCI 原生打包格式

Docker 在 2025 年 6 月发布了 Docker Model Spec（v0.1），定义了将 LLM 打包为 OCI 制品的标准格式。

为什么不用标准 OCI 镜像来打包 LLM？

Docker 团队给出了四个关键理由：

Docker Model Spec 的媒体类型

模型配置 JSON 示例

{
"config": {
"format": "gguf",
"quantization": "IQ2_XXS/Q4_K_M",
"parameters": "3.88 B",
"architecture": "gemma3",
"size": "2.31 GiB"
},
"descriptor": {
"created": "2025-03-26T09:57:32.086694+01:00"
}
}

通过定义领域特定的配置 Schema，工具链可以仅获取小型 JSON（300-500 字节）就能了解模型的全部元数据，而无需下载数百 GB 的权重文件。

CNCF ModelPack：AI/ML 制品的标准化生态

CNCF ModelPack 是 2025 年 6 月被 CNCF TOC 接受为 Sandbox 项目的新兴标准。与 Docker Model Spec 聚焦 LLM/GGUF 不同，ModelPack 的目标更广泛——为所有 AI/ML 制品建立与 OCI 兼容的打包规范。

ModelPack 的媒体类型体系

application/vnd.cncf.model.manifest.v1+json — 模型清单
application/vnd.cncf.model.config.v1+json — 模型配置
application/vnd.cncf.model.weight.v1.raw — 模型权重（原始格式）
application/vnd.cncf.model.weight.config.v1.raw — 权重配置文件
application/vnd.cncf.model.weight.code.v1.raw — 关联代码
application/vnd.cncf.model.doc.v1.raw — 文档/README

modctl：ModelPack CLI 工具

modctl 是 ModelPack 生态的核心 CLI，对标 docker build 的工作流：

# 步骤 1：在模型目录生成 Modelfile
modctl modelfile generate .

# 步骤 2：自定义 Modelfile
cat <<EOF > Modelfile
NAME qwen2.5-0.5b
ARCH transformer
FAMILY qwen2
FORMAT safetensors
CONFIG config.json
CONFIG generation_config.json
MODEL *.safetensors
CODE *.py
EOF

# 步骤 3：登录 Harbor 注册中心
modctl login -u admin -p Harbor12345 harbor.registry.com

# 步骤 4：构建并推送 OCI 制品
modctl build -t harbor.registry.com/models/qwen2.5-0.5b:v1 -f Modelfile .
modctl push harbor.registry.com/models/qwen2.5-0.5b:v1

ModelPack 生成的 Manifest 结构

{
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"artifactType": "application/vnd.cncf.model.manifest.v1+json",
"config": {
"mediaType": "application/vnd.cncf.model.config.v1+json",
"digest": "sha256:d5815835051dd97d800a03f641ed8162877920e734d3d705b698912602b8c763",
"size": 301
},
"layers": [
{
"mediaType": "application/vnd.cncf.model.weight.v1.raw",
"digest": "sha256:3f907c1a03bf20f20355fe449e18ff3f9de2e49570ffb536f1a32f20c7179808",
"size": 4294967296
},
{
"mediaType": "application/vnd.cncf.model.weight.config.v1.raw",
"digest": "sha256:a5378e569c625f7643952fcab30c74f2a84ece52335c292e630f740ac4694146",
"size": 106
}
]
}

注意权重层的大小高达 4.29 GB——这正是模型制品与常规容器镜像的本质区别。单个层即可超越大多数微服务镜像的总体积。

ModelCar：过渡期的实用容器化模式

Red Hat 提出的 ModelCar 容器模式是一种务实方案：将模型文件放置在容器的 /models 目录下，打包为标准 OCI 镜像（而非 artifact）。由于不依赖 OCI Artifact 的特殊支持，ModelCar 在最广泛的环境中都能工作，包括尚未支持 OCI Artifact Mount 的老版本 Kubernetes 集群。

ModelCar 容器结构：
├── /models/
│ ├── model-00001-of-00005.safetensors (9.97 GB)
│ ├── model-00002-of-00005.safetensors (9.94 GB)
│ ├── …
│ └── config.json (704 B)
└── (无运行时组件——纯模型文件)

ModelCar 的优势：

• 享受容器注册中心的全部企业功能（签名、扫描、RBAC、复制）
• 生成 SBOM 和 AI-BOM，满足软件供应链安全合规要求
• KServe v0.11+ 和 OpenShift AI 2.14+ 原生支持从 ModelCar 容器直接加载模型
• 模型在节点上被缓存时，推理服务的启动速度显著优于 S3 拉取

ModelCar 的局限：

• 模型层与容器文件系统层混合，权重文件在 push/pull 时仍需经过（高熵数据无效的）压缩与解压缩
• 更新模型意味着重建整个容器镜像，无法独立管理模型层的版本
• 镜像体积受注册中心的实际限制（多数企业注册中支持 15-20 GB 的镜像尺寸）

Kubernetes Image Volumes：模型即卷的声明式交付

Kubernetes 1.31（Alpha）引入、1.33（Beta，默认启用）的 Image Volume 特性，允许 Pod 将 OCI 镜像/制品的层以只读卷方式挂载。对于 AI 模型交付，这意味着：

Kubernetes 1.33 Image Volume 部署模型流程：
OCI 注册中心（Harbor）
↓ kubectl apply -f pod.yaml
CRI-O/containerd 拉取 OCI 制品
↓ 模型层不压缩存储于本地
kubelet 将模型层以卷方式挂载到 Pod
↓ /models 目录直接可见模型文件
vLLM/TGI 推理引擎加载模型权重
↓
推理服务就绪

这个流程实现了模型（数据）与推理引擎（计算）的彻底解耦。同一节点上的多个推理 Pod 可以共享同一份模型卷，相比每个 Pod 各自打包模型文件的 ModelCar 模式，磁盘利用率显著提升。

核心模块/流程/机制详解

模块一：AI 训练容器的 Dockerfile 最佳实践

AI 训练任务对容器的要求与常规 Web 服务有本质差异：它们需要 GPU 设备访问、大规模共享内存（DataLoader 多进程）、高速 NCCL 多卡通信、以及特定的 CUDA/cuDNN 版本组合。

标准训练容器 Dockerfile

# 阶段 1：构建阶段（依赖安装、代码编译）
FROM pytorch/pytorch:2.5.1-cuda12.4-cudnn9-devel AS builder

# 设置 CUDA 架构（加速编译）
ENV TORCH_CUDA_ARCH_LIST="8.0;8.6;8.9;9.0"
ENV MAX_JOBS=4

# 安装 Python 依赖
COPY requirements.txt /tmp/requirements.txt
RUN pip install –no-cache-dir -r /tmp/requirements.txt

# 安装 FlashAttention-2（需从源码编译以匹配 CUDA 架构）
RUN pip install –no-cache-dir flash-attn –no-build-isolation

# 阶段 2：运行阶段（精简体积）
FROM pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime

# 从构建阶段复制已编译的 Python 包
COPY –from=builder /opt/conda/lib/python3.11/site-packages /opt/conda/lib/python3.11/site-packages

# 设置 NCCL 环境变量（生产环境建议 INFO 或 WARN 级别）
ENV NCCL_DEBUG=WARN \\n NCCL_IB_DISABLE=0 \\n NCCL_SOCKET_IFNAME=eth0 \\n NCCL_IB_GID_INDEX=3 \\n NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3 \\n NCCL_NET_GDR_LEVEL=2 \\n OMP_NUM_THREADS=1 \\n TOKENIZERS_PARALLELISM=false

# 设置工作目录
WORKDIR /workspace

# 复制训练代码
COPY src/ /workspace/src/
COPY configs/ /workspace/configs/

# 入口点
ENTRYPOINT ["torchrun", "–nproc_per_node=8", "–nnodes=1", "–rdzv_backend=c10d"]
CMD ["src/train.py", "–config", "configs/training.yaml"]

Kubernetes 训练 Job 配置

apiVersion: batch/v1
kind: Job
metadata:
name: llm–finetune–llama3–8b
spec:
parallelism: 1
completions: 1
backoffLimit: 2
ttlSecondsAfterFinished: 86400
template:
spec:
hostNetwork: true # NCCL 通信性能优化
dnsPolicy: ClusterFirstWithHostNet
restartPolicy: Never
containers:
– name: trainer
image: registry.example.com/ai/llama–finetune:v1.2.0
resources:
limits:
nvidia.com/gpu: 8
memory: 512Gi
cpu: 64
requests:
nvidia.com/gpu: 8
memory: 480Gi
cpu: 56
env:
– name: MASTER_ADDR
valueFrom:
fieldRef:
fieldPath: status.podIP
– name: WORLD_SIZE
value: "1"
– name: RANK
value: "0"
– name: WANDB_API_KEY
valueFrom:
secretKeyRef:
name: wandb–secret
key: api–key
volumeMounts:
– name: training–data
mountPath: /data
– name: checkpoints
mountPath: /checkpoints
– name: dshm
mountPath: /dev/shm
volumes:
– name: training–data
persistentVolumeClaim:
claimName: training–dataset–pvc
– name: checkpoints
persistentVolumeClaim:
claimName: model–checkpoints–pvc
– name: dshm
emptyDir:
medium: Memory
sizeLimit: 64Gi # DataLoader 多进程所需共享内存
nodeSelector:
accelerator: nvidia–a100–80gb

模块二：模型打包（三种模式对比）

模式 A：Docker Model Spec（推荐用于 GGUF/LLM 推理）

# 从 HuggingFace 直接拉取并转换为 OCI 制品格式
docker model pull huggingface.co/meta-llama/Meta-Llama-3-8B-Instruct

# 查看本地已缓存的模型
docker model list

# 推送到私有注册中心
docker model tag meta-llama/Meta-Llama-3-8B-Instruct \\n harbor.internal.com/models/llama3-8b-instruct:q4_k_m
docker model push harbor.internal.com/models/llama3-8b-instruct:q4_k_m

模式 B：ModelPack + modctl（推荐用于 safetensors/PyTorch 格式）

# 生成 Modelfile
modctl modelfile generate .

# 编辑 Modelfile 配置模型元数据
# 构建并推送
modctl build -t harbor.internal.com/models/llama3-8b:v1 -f Modelfile .
modctl push harbor.internal.com/models/llama3-8b:v1

# 验证制品签名
cosign verify –key cosign.pub harbor.internal.com/models/llama3-8b:v1

模式 C：ModelCar 容器（兼容性优先）

# ModelCar Dockerfile — 将模型直接打包为标准 OCI 镜像
FROM scratch
COPY model/ /models/
LABEL org.opencontainers.image.title="Llama-3-8B-Instruct-FP16"
LABEL org.opencontainers.image.version="1.0.0"
LABEL ai.model.family="llama3"
LABEL ai.model.parameters="8B"
LABEL ai.model.quantization="FP16"

# 构建和推送
docker build -t harbor.internal.com/models/llama3-8b-fp16:1.0.0 .
docker push harbor.internal.com/models/llama3-8b-fp16:1.0.0

# 签名
cosign sign –key cosign.key harbor.internal.com/models/llama3-8b-fp16:1.0.0

模块三：推理容器的封装与优化

推理引擎容器 Dockerfile（vLLM 示例）

FROM vllm/vllm-openai:v0.8.5

# 安装额外的推理优化库
RUN pip install –no-cache-dir \\n outlines==0.1.11 \\n lm-format-enforcer==0.10.7

# 设置推理引擎环境变量
ENV VLLM_ATTENTION_BACKEND=FLASH_ATTN \\n VLLM_USE_V1=1 \\n VLLM_CPU_OMP_THREADS_BOUND=0 \\n VLLM_WORKER_MULTIPROC_METHOD=spawn

# 创建非 root 用户运行引擎
RUN useradd -m -u 1000 vllm && \\n mkdir -p /home/vllm/.cache/huggingface && \\n chown -R vllm:vllm /home/vllm

USER vllm
WORKDIR /home/vllm

EXPOSE 8000
ENTRYPOINT ["python", "-m", "vllm.entrypoints.openai.api_server"]

Kubernetes Image Volume 挂载模型部署（K8s 1.33+）

apiVersion: v1
kind: Pod
metadata:
name: vllm–llama3–inference
labels:
app: vllm
model: llama3–8b
spec:
containers:
– name: vllm
image: vllm/vllm–openai:v0.8.5
command:
– "python3"
– "-m"
– "vllm.entrypoints.openai.api_server"
args:
– "–model"
– "/models"
– "–dtype"
– "float16"
– "–host"
– "0.0.0.0"
– "–port"
– "8000"
– "–max-model-len"
– "8192"
– "–gpu-memory-utilization"
– "0.90"
– "–enable-prefix-caching"
env:
– name: VLLM_ATTENTION_BACKEND
value: "FLASH_ATTN"
resources:
requests:
nvidia.com/gpu: 1
memory: "32Gi"
cpu: "8"
limits:
nvidia.com/gpu: 1
memory: "64Gi"
cpu: "16"
volumeMounts:
– name: model–volume
mountPath: /models
readOnly: true
ports:
– containerPort: 8000
protocol: TCP
name: http
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 15
timeoutSeconds: 10
failureThreshold: 3
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 10
timeoutSeconds: 5
volumes:
– name: model–volume
image:
reference: harbor.internal.com/models/llama3–8b–fp16:1.0.0
pullPolicy: IfNotPresent
—
apiVersion: v1
kind: Service
metadata:
name: vllm–llama3–service
spec:
selector:
app: vllm
model: llama3–8b
ports:
– port: 8000
targetPort: 8000
protocol: TCP
name: http
type: ClusterIP

模块四：Harbor + Dragonfly 企业级模型注册与分发体系

Harbor 作为 AI 模型注册中心

Harbor v2.12+ 原生支持 OCI 制品的管理，能为 AI 模型提供与容器镜像完全一致的企业级治理：

Harbor AI 模型管理能力：
├── 版本管理
│ ├── OCI 制品不可变 Tag + SHA256 Digest → 确定性推理环境
│ ├── 模型属性可视化展示（架构/参数量/量化方式/文件列表）
│ └── 标签保留策略：自动清理非发布版本，锁定活跃版本
├── 访问控制
│ ├── RBAC：算法工程师（PUSH）、推理服务（PULL）、管理员（Full）
│ └── 项目级隔离：训练模型、推理模型、实验模型分项目管理
├── 供应链安全
│ ├── Cosign/Notation 签名集成 → 部署前强制验签，防模型投毒
│ ├── 漏洞扫描（Trivy/Grype 集成）
│ └── 审计日志：所有制品操作（pull/push/delete）的完整记录
└── 多站点复制
├── 中心注册中心 → 边缘集群自动增量同步
└── 主备注册中心高可用

Dragonfly P2P 分发架构

在大规模 GPU 集群中拉取 TB 级模型文件，传统的一对多拉取模式造成中心带宽瓶颈。Dragonfly 通过 P2P 架构解决这个问题：

Dragonfly P2P 模型分发流程：

Harbor（模型源）
↓ 用户创建预热策略，Dragonfly Manager 触发预热
Scheduler（调度器）
↓ 基于带宽感知的调度算法，分配各节点的初始下载任务
Peer Node A ←→ Peer Node B ←→ Peer Node C ←→ Peer Node D
(拉取 layer_1) (拉取 layer_2) (拉取 layer_3) (拉取 layer_4)
↓ 各节点完成初始层下载后，相互 P2P 交换缺失的层
全节点持有完整模型
↓
推理服务启动时从本地磁盘加载（零网络延迟）

核心数据：500 节点 × 1TB 模型场景下，Dragonfly P2P 分发可达到每个节点 70%-80% 的下行带宽利用率，集群整体模型就绪时间从传统串行模式的 30-40 分钟压缩到 5 分钟以内。

Harbor + Dragonfly 预热配置

在 Harbor 中配置 Dragonfly P2P 预热策略：

操作路径：Harbor → 项目 → P2P Provider Policy → 创建策略
参数配置：
├── Provider: Dragonfly
├── 触发条件：制品推送（On Push）/ 手动触发
├── 过滤规则：按 Tag 正则匹配（如 release-*）
└── 预热范围：指定节点组 / 全部注册节点

当 Harbor 收到新的模型制品推送或定时预热任务触发时，Dragonfly 自动将模型分片分发到目标节点组的本地缓存，确保推理服务扩缩容时模型已在节点本地就绪。

模块五：NVIDIA GPU 容器运行时配置

安装 NVIDIA Container Toolkit（Ubuntu 22.04）

# 添加 NVIDIA 容器工具包仓库
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \\n sudo gpg –dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \\n sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \\n sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# 安装并配置
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure –runtime=docker
sudo systemctl restart docker

# 验证 GPU 在容器内可见
docker run –rm –gpus all nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

Docker Compose 中的 GPU 配置

version: "3.8"
services:
# 训练任务：使用全部 GPU
trainer:
image: pytorch/pytorch:2.5.1–cuda12.4–cudnn9–runtime
deploy:
resources:
reservations:
devices:
– driver: nvidia
count: all
capabilities: [gpu]
environment:
– NCCL_DEBUG=INFO
– NCCL_P2P_LEVEL=NVL
volumes:
– ./data:/data
– ./checkpoints:/checkpoints
shm_size: "32gb"

# 推理服务：使用指定 GPU
inference:
image: vllm/vllm–openai:v0.8.5
deploy:
resources:
reservations:
devices:
– driver: nvidia
device_ids: ["0"]
capabilities: [gpu]
ports:
– "8000:8000"
volumes:
– /models/llama3–8b:/models:ro

模块六：云原生 AI 开发工作流全景

将上述各模块串联起来，形成完整的"开发 → 构建 → 推送 → 部署"闭环：

云原生 AI 开发工作流：

[数据科学家] [ML 平台工程师]
│ │
↓ ↓
1. 开发阶段 2. 构建阶段
├── 实验 Notebook/JupyterLab ├── CI/CD 流水线触发
├── 训练脚本 & 模型配置 ├── modctl build 生成 OCI 制品
├── Git 提交代码 + 模型配置 ├── Cosign 对制品签名
│ ├── SBOM/AI-BOM 生成
│ └── Harbor 推送到注册中心
│ │
└────────────→ 汇合 ←────────────┘
↓
3. 管理与分发
├── Harbor 存储模型制品（版本化 + RBAC）
├── Trivy 安全扫描（CVE + 模型文件检查）
├── Harbor 签名验证准入
├── Dragonfly 预热模型到目标 GPU 节点
└── P2P 分发加速（节点间自动交换数据块）
│
↓
4. 部署阶段
├── ArgoCD 检测 Harbor 新 Tag → GitOps 同步
├── K8s Image Volume 挂载模型到推理 Pod
├── KServe InferenceService 管理推理生命周期
├── Prometheus + Grafana 监控 GPU 利用率和推理延迟
└── HPA/VPA 弹性扩缩容（基于 GPU 利用率/请求队列深度）

技术优缺点 & 适用场景

技术优势

现存局限

生产适用场景

禁忌场景

实战落地

场景一：端到端 LLM 模型容器化交付流水线

本节提供从 HuggingFace 下载模型 → ModelPack 打包 → Harbor 推送 → Docker 签名 → Dragonfly 预热 → K8s 部署的完整可执行脚本。

CI/CD 流水线（GitHub Actions 示例）

name: Model Packaging Pipeline
on:
push:
tags:
– "model/v*"

env:
HARBOR_REGISTRY: harbor.internal.com
HARBOR_PROJECT: ai–models
MODEL_NAME: llama3–8b–instruct
COSIGN_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}
COSIGN_PASSWORD: ${{ secrets.COSIGN_KEY_PASSWORD }}

jobs:
package-and-publish:
runs-on: ubuntu–24.04
steps:
– name: Checkout model files
uses: actions/checkout@v4
with:
lfs: true

– name: Install modctl
run: |
curl -sSL https://github.com/modelpack/modctl/releases/download/v0.7.0/modctl-linux-amd64 -o /usr/local/bin/modctl
chmod +x /usr/local/bin/modctl

– name: Install Cosign
uses: sigstore/cosign–installer@v3
with:
cosign-release: "v2.4.1"

– name: Login to Harbor
run: |
echo "${{ secrets.HARBOR_PASSWORD }}" | \\n modctl login -u "${{ secrets.HARBOR_USERNAME }}" –password-stdin $HARBOR_REGISTRY

– name: Build OCI Artifact
run: |
REF="${HARBOR_REGISTRY}/${HARBOR_PROJECT}/${MODEL_NAME}:${GITHUB_REF_NAME#model/}"
modctl build -t "$REF" -f Modelfile .
echo "MODEL_REF=$REF" >> $GITHUB_ENV

– name: Sign artifact with Cosign
run: |
cosign sign –key env://COSIGN_KEY –yes "$MODEL_REF"

– name: Push to Harbor
run: |
modctl push "$MODEL_REF"

– name: Trigger Dragonfly preheat
run: |
curl -X POST "https://$HARBOR_REGISTRY/api/v2.0/p2p/preheat/policies/${{ secrets.POLICY_ID }}" \\n -H "Authorization: Basic $(echo -n 'admin:${{ secrets.HARBOR_PASSWORD }}' | base64)" \\n -H "Content-Type: application/json" \\n -d "{"artifact_ref": "$MODEL_REF"}"

– name: Generate AI–BOM
run: |
pip install aibom-generator
aibom-generator –model-ref "$MODEL_REF" –output ai-bom.spdx.json

– name: Upload AI–BOM as artifact
uses: actions/upload–artifact@v4
with:
name: ai–bom
path: ai–bom.spdx.json

Kubernetes 推理部署（KServe InferenceService）

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: llama3–8b–instruct
namespace: ai–inference
annotations:
cosign.sigstore.dev/verify: "true"
sidecar.istio.io/inject: "true"
spec:
predictor:
minReplicas: 2
maxReplicas: 10
scaleTarget: 60 # 目标 GPU 利用率 %
scaleMetric: gpu
model:
modelFormat:
name: llama3
runtime: vllm
storage:
key: model–weights
path: /models
storageUri: oci://harbor.internal.com/ai–models/llama3–8b–instruct:1.0.0
resources:
requests:
nvidia.com/gpu: 1
memory: "32Gi"
cpu: "8"
limits:
nvidia.com/gpu: 1
memory: "64Gi"
cpu: "16"
containers:
– name: kserve–container
image: vllm/vllm–openai:v0.8.5
args:
– "–gpu-memory-utilization"
– "0.90"
– "–max-model-len"
– "8192"
– "–enable-prefix-caching"

场景二：分布式训练容器的资源优化配置

PyTorch FSDP + DeepSpeed 混合训练配置

apiVersion: kubeflow.org/v1
kind: PyTorchJob
metadata:
name: llama3–8b–fsdp–train
namespace: ai–training
spec:
pytorchReplicaSpecs:
Worker:
replicas: 4
restartPolicy: OnFailure
template:
spec:
hostNetwork: true
dnsPolicy: ClusterFirstWithHostNet
containers:
– name: pytorch
image: registry.internal.com/ai/llama–train:v2.1.0
command:
– torchrun
– ––nproc_per_node=8
– ––nnodes=4
– ––node_rank=$(RANK)
– ––master_addr=$(MASTER_ADDR)
– ––master_port=29500
– src/train_fsdp.py
env:
– name: NCCL_DEBUG
value: "INFO"
– name: NCCL_IB_DISABLE
value: "0"
– name: NCCL_NET_GDR_LEVEL
value: "2"
– name: NCCL_SOCKET_IFNAME
value: "eth0"
– name: NCCL_IB_GID_INDEX
value: "3"
– name: CUDA_DEVICE_MAX_CONNECTIONS
value: "1"
– name: PYTORCH_CUDA_ALLOC_CONF
value: "expandable_segments:True"
resources:
limits:
nvidia.com/gpu: 8
memory: 800Gi
cpu: 128
requests:
nvidia.com/gpu: 8
memory: 720Gi
cpu: 120
volumeMounts:
– name: dataset
mountPath: /data
– name: checkpoints
mountPath: /checkpoints
– name: dshm
mountPath: /dev/shm
securityContext:
capabilities:
add:
– IPC_LOCK # NCCL 需要锁定内存
– SYS_PTRACE
volumes:
– name: dataset
persistentVolumeClaim:
claimName: training–data–2tb
– name: checkpoints
persistentVolumeClaim:
claimName: checkpoints–5tb
– name: dshm
emptyDir:
medium: Memory
sizeLimit: 128Gi
nodeSelector:
node.kubernetes.io/instance-type: a2–highgpu–8g
topology.kubernetes.io/region: us–west1–a

生产避坑经验

全文总结

本文围绕 AI 应用容器化交付这一核心命题，系统性地拆解了从模型打包、镜像构建到注册分发、Kubernetes 部署的完整链路：

容器化交付正在重塑 AI 基础设施的底层范式——模型不再是被特殊对待的"大文件"，而是成为云原生生态中的一等公民制品。当你的模型可以像容器镜像一样被构建、签名、扫描、分发和回滚时，AI 的生产化落地才真正具备了软件工程的严谨性。

免责声明

本文聚焦 AI 云原生基础设施工程实践，所有技术内容仅供学习研究使用。文中涉及的容器安全（镜像扫描、签名验证、SBOM 生成）为防御性安全工程技术，旨在帮助企业构建安全的 AI 制品供应链。实际部署请结合自身业务场景进行充分测试与安全评估。

本期专栏更新说明

本文为《AI 工程与安全深度实战》订阅专栏持续迭代内容，专栏按初/中/高阶递进规划，长期更新 AI 云原生架构、GPU 算力工程、LLMOps 运维智能化、模型安全攻防、供应链安全、安全治理与合规实践，一次订阅，永久持续更新。

参考资料

• Docker Blog: Why Docker Chose OCI Artifacts for AI Model Packaging — Docker 官方博客，详解 Docker Model Spec 的设计决策
• CNCF Blog: How OCI Artifacts Will Drive Future AI Use Cases — CNCF 博客，Sascha Grunert 阐述 OCI Artifact 如何驱动 AI 用例
• CNCF Blog: The Weight of AI Models — Why Infrastructure Always Arrives Slowly — ModelPack 维护者撰写，完整介绍模型交付的云原生解决方案
• Red Hat Blog: Using Containers to Bring Software Engineering Rigor to AI Workloads — Red Hat 首席架构师 Ann Marie Fred，涵盖 ModelCar、MCP Server 容器化、Agent 容器化
• ModelPack Official Website — CNCF ModelPack 项目官网，规范文档与工具链
• modctl GitHub Repository — ModelPack CLI 工具源码与使用文档
• ORAS (OCI Registry As Storage) — CNCF Sandbox 项目，OCI 制品通用 CLI
• NVIDIA Container Toolkit Documentation — NVIDIA 官方文档，GPU 容器运行时配置指南
• Kubernetes Image Volumes (KEP) — Kubernetes 官方文档，OCI 镜像/制品卷挂载
• Harbor Official Documentation — CNCF Graduate 项目，企业级 OCI 注册中心
• Dragonfly Documentation — CNCF Incubating 项目，P2P 文件分发
• VMware Blog: Using Harbor as an AI Model Registry — Harbor 作为 AI 模型注册中心的实践指南
• Docker Model Runner Architecture — Docker Model Runner 设计架构