第 18 章 部署基础

学习目标

• 理解五种部署目标：云、边、端、混合、私有化的取舍；
• 掌握容器、镜像、Kubernetes、Helm、Operator 的部署体系；
• 理解 GPU 调度：MIG、共享 GPU、异构硬件；
• 理解 Serverless、边缘 K3s、移动端、浏览器端部署；
• 掌握模型格式：ONNX、TorchScript、SavedModel、GGUF、TensorRT Engine。

---

18.1 部署目标：云、边、端、混合、私有化

部署的本质是把「服务」放到离用户合适的位置。五种目标的取舍：

目标	延迟	隐私	成本	典型
云（Cloud）	中	低	弹性	大模型推理、训练
边（Edge）	低	中	中	网关/机房内的轻量推理
端（Device）	极低	高	摊到硬件	手机、车机、浏览器
混合（Hybrid）	分场景	分场景	分场景	端+云协同、边+云协同
私有化（On-prem）	本地	最高	高	金融、政企数据不出域

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart LR
    A[端侧
小模型/离线] -->|复杂任务| B[边侧
中模型/近线]
    B -->|更复杂| C[云端
大模型/旗舰]
    A -.隐私敏感.-> A
    C -.知识实时.-> B
    B -.轻量兜底.-> A

部署形态与第 4 章「规模」、第 13 章「压缩」强耦合：端侧只能放量化后的 1B-7B，云上才能跑 70B-671B。选部署目标前先回答三个问题：延迟要求多严、数据能不能出域、预算有多少。

18.2 容器、镜像、Kubernetes、Helm、Operator

容器是部署的最小单元：把模型服务、依赖、运行时打包成镜像，保证「构建一次、到处运行」。LLM 镜像的特殊性：大（权重打进镜像可达几十 GB，或用挂载卷动态拉取）、GPU 依赖（CUDA 版本、驱动兼容）。

Kubernetes（第 12 章讲过调度）是部署的控制平面。LLM 部署的三个 K8s 关注点：

1. GPU 资源：nvidia-device-plugin 暴露 GPU，limits.nvidia.com/gpu 申请；
2. 亲和性：推理副本尽量同节点（TP 需要 NVLink，第 11 章）、避免被调度到异构坏节点；
3. 稳定性：模型加载慢 → readiness 探针要等模型就绪；OOM/显存错误 → 自动重启策略。

Helm：把「一堆 K8s YAML」打包成可配置的 chart（values.yaml 控制副本数、模型、GPU 数）——LLM 服务部署模板化的事实工具。

Operator：把「部署一个模型服务」这种有状态、有生命周期的操作自动化（监控、滚动升级、回滚）。代表：KServe 的 InferenceService CRD、Kubeflow 的 Trainer、以及各种 LLM Operator。

18.3 GPU 调度、MIG、共享 GPU、异构硬件

GPU 是稀缺资源，调度要精细化：

• 整卡分配：一个 Pod 独占一张 GPU（最简单，最浪费——小模型也用整卡）；
• 共享 GPU（Time-Slicing / vGPU）：多 Pod 共享一张卡的时间片/显存分片（NVIDIA MPS、vGPU 方案），提高利用率但有隔离风险；
• MIG（Multi-Instance GPU）：A100/H100 把一张物理卡切成多个独立实例（显存、计算、带宽隔离）——比时间片共享更稳，适合「一张卡服务多个中小模型」；
• 异构硬件：A100/H100/L40 混布，按模型需求调度（70B 上 H100，7B 上 L40/4090）。

%%{init: {"themeVariables": {"primaryTextColor": "#000000", "textColor": "#000000", "labelColor": "#000000", "nodeTextColor": "#000000", "labelTextColor": "#000000", "scaleLabelColor": "#000000"}}}%%
flowchart TD
    A[GPU 资源] --> B{模型大小}
    B -->|小模型 7B| C[共享 GPU / MIG
一卡多模型]
    B -->|中模型 30B| D[整卡
单卡单实例]
    B -->|大模型 70B+| E[多卡
TP/PP 并行]
    C --> F[高利用率]
    D --> F
    E --> G[大模型专用节点]

调度策略的权衡：共享 GPU 省成本但隔离弱（一个租户跑满拖累别人）；MIG 折中；整卡最稳但利用率低。生产上「按模型大小分层 + 关键任务隔离」是常态。

18.4 Serverless、边缘 K3s、移动端、浏览器端

• Serverless（函数即服务）：按需启动、用后即停。对 LLM 的两难：模型加载慢（第 16 章预热问题）让冷启动成灾难；但「保活池」+ 小模型可以折中。结论：Serverless 适合小模型/低频/突发场景，不适合 70B 常驻服务；
• 边缘 K3s：轻量 K8s（K3s）跑到边缘网关/机房，管理边侧模型服务——混合部署的底座；
• 移动端：量化小模型（GGUF）直接跑在手机（MLC、llm.cpp、Ollama 移动版），离线、隐私、低延迟；受限于内存与算力，只适合 1B-7B；
• 浏览器端：WebLLM/WASM 在浏览器跑小模型，零安装、隐私好，但算力与内存限制最严。

18.5 模型格式：ONNX、TorchScript、SavedModel、GGUF、TensorRT

模型要部署，先要「格式化」——不同格式决定能在哪跑、多快：

格式	来源	特点	用在哪
ONNX	开放标准	跨框架可移植、图优化	通用部署、CPU/异构
TorchScript	PyTorch	PyTorch 序列化	PyTorch 生态
SavedModel	TensorFlow	TF 生态	TF 服务
GGUF	llama.cpp	量化 + 打包一体（第 13 章）	端侧/桌面/CPU
TensorRT Engine	NVIDIA	编译后引擎、性能极致	GPU 生产、延迟敏感

格式选型逻辑：GPU 极致性能用 TensorRT Engine；通用可移植用 ONNX；端侧/CPU 用 GGUF；PyTorch 快速原型用 TorchScript。LLM 的主流路径：训练产出权重 → 转成引擎所需格式 → 量化（第 13 章）→ 部署。格式转换本身就是一道压缩/优化工序（TensorRT 的 engine 构建就是编译优化）。

---

本章要点回顾

1. 部署目标五选一：云/边/端/混合/私有化，先问延迟、隐私、预算。
2. K8s 部署 LLM 三要点：GPU 资源、节点亲和性、模型就绪探针；Helm 模板化、Operator 自动化。
3. GPU 调度分层：整卡 / 共享 / MIG；异构按模型大小分卡。
4. Serverless 对小模型可行、对 70B 是灾难（加载慢）；端侧靠 GGUF 量化小模型。
5. 模型格式决定部署形态与性能：TensorRT Engine 极致、ONNX 可移植、GGUF 端侧。
6. 部署形态与规模、压缩强耦合：先定规模与压缩，再定部署目标。

习题

1. 你的产品要求首 token < 300ms、数据不出域、用户量波动大。设计部署架构（云/边/端如何分工）。
2. 7B 与 70B 模型在同一 K8s 集群如何做 GPU 调度？给出节点池与亲和性设计。
3. 为什么 Serverless 对 70B 不友好？冷启动 2 分钟在 Serverless 计费模型下意味着什么？
4. 端侧部署要跑 3B 模型，从格式、量化位宽、内存预算三个角度给出选型。

延伸阅读

• Kubernetes + NVIDIA GPU 文档（device-plugin、MIG）
• KServe / Seldon 部署文档
• Helm 文档
• llama.cpp / GGUF / Ollama 文档（端侧）
• ONNX Runtime / TensorRT 文档（格式与优化）

下一章预告

第 19 章模型版本与发布工程：模型注册表与制品管理、CI/CD/CT（持续集成/交付/训练）、环境隔离、配置与密钥管理、回滚审计合规。