## AI 模型部署：从训练完成到生产可用的工程化全链路
### 一、模型训练完成不等于可以上线：部署的工程鸿沟
有个推荐算法团队花了三个月训出一个点击率预估模型，离线 AUC 做到 0.82。可一上线，推荐效果反而变差了。排查下来发现：训练时的特征工程用的是全量数据，线上推理却有部分特征要实时计算，延迟从预期的 10ms 飙到 200ms；模型文件 2GB，加载超过 30 秒，滚动更新时服务直接中断；GPU 显存不够触发 OOM，推理服务反复重启。
这压根不是算法问题，而是工程问题。从训练完成到生产可用，中间横着一条很宽的工程鸿沟：模型格式转换、推理引擎选型、资源调度、版本管理、灰度发布、回滚策略，哪一环卡住都上不了线。
模型部署要解决的核心问题是：怎么把一个静态的模型文件，变成一个低延迟、高可用、还能持续迭代的在线推理服务。
### 二、模型部署的架构分层与推理引擎选型
```
graph TB
subgraph "模型部署架构"
subgraph "模型层"
Training["训练产出
PyTorch / TensorFlow"]
Convert["模型转换
ONNX / TensorRT"]
Registry["模型仓库
版本管理"]
end
```
```
subgraph "推理层"
Engine["推理引擎
vLLM / Triton / ONNX Runtime"]
Batching["动态批处理
请求合并"]
Quantization["模型量化
FP16 / INT8 / INT4"]
end
```
```
subgraph "服务层"
API["推理 API
REST / gRPC"]
Router["流量路由
灰度 / A/B"]
Health["健康检查
就绪探针"]
end
end
```
```
Training --> Convert
Convert --> Registry
Registry --> Engine
Engine --> Batching
Engine --> Quantization
Batching --> API
Quantization --> API
API --> Router
API --> Health
```
#### 模型格式转换：跨框架的桥梁
PyTorch、TensorFlow 这些训练框架产出的格式各不相同，推理引擎却需要统一的输入。ONNX（Open Neural Network Exchange）是目前最通用的中间格式：几乎所有训练框架都能导出 ONNX，几乎所有推理引擎都能加载 ONNX。
典型转换路径是：PyTorch → ONNX → TensorRT（针对 NVIDIA GPU 优化）。TensorRT 会对 ONNX 模型做层融合、精度校准和内核自动调优，在 NVIDIA GPU 上通常能拿到 2-5 倍的推理加速。
#### 推理引擎选型
引擎| 适用场景| 优势| 劣势
---|---|---|---
vLLM| LLM 文本生成| PagedAttention、高吞吐| 仅支持 GPU
Triton Inference Server| 多模型、多框架| 动态批处理、多模型并行| 配置复杂
ONNX Runtime| 通用推理| 跨平台、CPU/GPU 均支持| LLM 优化不足
TensorRT| NVIDIA GPU 极致性能| 层融合、精度优化| 仅 NVIDIA GPU
做大模型推理，vLLM 眼下的首选。它的 PagedAttention 机制解决了 KV Cache 的显存碎片问题，吞吐量能提升 2-4 倍。
#### 模型量化：精度与性能的权衡
量化是压低推理成本最直接的一招。权重从 FP32 降到 FP16，显存占用减半，推理速度提升 30%-50%；再降到 INT8，显存又减半，速度再涨 50%。代价是精度损失，所以必须在校准数据集上评估掉点是否可接受。
### 三、基于 vLLM + Kubernetes 的 LLM 部署实现
#### 3.1 vLLM 推理服务部署
```
# vLLM Deployment 配置
apiVersion: apps/v1
kind: Deployment
metadata:
name: llm-inference
namespace: ai-serving
spec:
replicas: 2
strategy:
# 滚动更新策略：先启动新 Pod，再终止旧 Pod
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: llm-inference
template:
metadata:
labels:
app: llm-inference
version: v2
spec:
# GPU 节点调度
nodeSelector:
gpu-type: "a100"
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- --model
- /models/chat-v4
- --tensor-parallel-size
- "2" # 2 卡并行
- --gpu-memory-utilization
- "0.90" # GPU 显存利用率上限
- --max-model-len
- "8192" # 最大序列长度
- --dtype
- float16 # FP16 推理
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: "2"
requests:
nvidia.com/gpu: "2"
memory: "32Gi"
cpu: "8"
# 就绪探针：模型加载完成后才接收流量
readinessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 60
periodSeconds: 10
failureThreshold: 3
# 存活探针：推理服务卡死时自动重启
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 120
periodSeconds: 30
failureThreshold: 5
volumeMounts:
- name: model-storage
mountPath: /models
volumes:
- name: model-storage
persistentVolumeClaim:
claimName: model-pvc
```
#### 3.2 模型版本管理与灰度发布
```
@Service
public class ModelVersionService {
```
```
private final ModelRegistryClient registryClient;
private final KubernetesClient k8sClient;
```
```
/**
* 灰度发布新模型版本
* @param modelName 模型名称
* @param newVersion 新版本号
* @param canaryPercent 灰度流量比例（0-100）
*/
public void canaryDeploy(String modelName, String newVersion,
int canaryPercent) {
// 1. 验证新版本模型已注册
ModelVersion version = registryClient.getVersion(modelName, newVersion);
if (version == null) {
throw new ModelVersionNotFoundException(
"模型版本不存在: " + modelName + ":" + newVersion
);
}
```
```
// 2. 验证新版本通过基准测试
if (!version.isBenchmarkPassed()) {
throw new ModelBenchmarkFailedException(
"模型未通过基准测试: " + newVersion
);
}
```
```
// 3. 创建灰度 Deployment（新版本）
String canaryDeploymentName = modelName + "-canary";
createDeployment(canaryDeploymentName, modelName, newVersion);
```
```
// 4. 配置 Istio VirtualService 流量分配
configureCanaryRouting(modelName, canaryPercent);
```
```
// 5. 等待灰度验证
// 实际项目中通过监控指标自动判断是否继续放量
}
```
```
/**
* 全量发布：灰度验证通过后，将全部流量切换到新版本
*/
public void promoteCanary(String modelName) {
// 1. 将流量比例调整为 100%
configureCanaryRouting(modelName, 100);
```
```
// 2. 等待流量切换完成
sleep(30_000);
```
```
// 3. 更新主 Deployment 的镜像版本
updateMainDeployment(modelName);
```
```
// 4. 删除灰度 Deployment
deleteDeployment(modelName + "-canary");
```
```
// 5. 恢复路由规则
resetRouting(modelName);
}
```
```
/**
* 回滚：灰度验证失败，将流量切回旧版本
*/
public void rollbackCanary(String modelName) {
// 1. 将流量比例调整为 0%
configureCanaryRouting(modelName, 0);
```
```
// 2. 删除灰度 Deployment
deleteDeployment(modelName + "-canary");
```
```
// 3. 恢复路由规则
resetRouting(modelName);
}
```
```
private void configureCanaryRouting(String modelName, int canaryPercent) {
// 通过 Istio VirtualService 配置流量分配
// 实际实现中调用 Istio API
}
```
```
private void createDeployment(String name, String model, String version) {
// 创建 Kubernetes Deployment
}
```
```
private void updateMainDeployment(String modelName) {
// 更新主 Deployment 的版本
}
```
```
private void deleteDeployment(String name) {
k8sClient.apps().deployments()
.inNamespace("ai-serving")
.withName(name)
.delete();
}
```
```
private void resetRouting(String modelName) {
// 恢复默认路由规则
}
```
```
private void sleep(long millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
```
#### 3.3 模型预热与加载优化
```
@Component
public class ModelWarmUpRunner implements ApplicationRunner {
```
```
private final RestTemplate restTemplate;
private final MeterRegistry meterRegistry;
```
```
@Override
public void run(ApplicationArguments args) {
// 服务启动后，发送预热请求触发模型加载
String warmUpPrompt = "Hello, this is a warm-up request.";
```
```
Timer.Sample sample = Timer.start(meterRegistry);
try {
restTemplate.postForObject(
"
new WarmUpRequest(warmUpPrompt, 10),
String.class
);
sample.stop(meterRegistry.timer("model.warmup.duration"));
} catch (Exception e) {
// 预热失败不影响启动，但记录指标
sample.stop(meterRegistry.timer("model.warmup.duration",
"error", "true"));
}
}
}
```
### 四、模型部署的工程代价与选型边界
**GPU 资源的稀缺性：** GPU 是 AI 部署最昂贵的资源。一张 A100 的月租约 2-3 万元，而大多数推理服务的 GPU 利用率不足 40%。优化 GPU 利用率是降低部署成本的核心。动态批处理、模型量化、请求排队，都是围绕这一目标展开的。
**模型加载时间：** 大语言模型的参数量动辄数十 GB，从磁盘加载到 GPU 显存需要 10-60 秒。在 Kubernetes 滚动更新场景下，新 Pod 的就绪探针必须等模型加载完成后才通过，否则流量会被路由到未就绪的 Pod。`initialDelaySeconds` 的设置需要根据模型大小精确估算。
**量化精度的不可预测性：** INT8 量化在某些模型上精度损失可忽略，在另一些模型上可能导致输出质量显著下降。量化前必须在代表性数据集上做精度评估，不能想当然。对于对话类模型，建议至少做 100 条 Prompt 的对比测试。
**适用边界：**
* 日推理量 < 1 万次：直接调用云厂商的模型 API（如 OpenAI、通义千问），无需自建推理服务 * 日推理量 1 万 - 100 万次：自建推理服务 + GPU 服务器，成本可控 * 日推理量 > 100 万次：需要 GPU 集群 + 动态调度 + 模型量化，工程复杂度显著上升
### 五、总结
AI 模型部署的核心矛盾，是模型推理的资源密集性与生产服务的成本敏感性之间的冲突。GPU 是最昂贵的计算资源，每一分利用率都值得优化。模型量化、动态批处理、PagedAttention，这些技术的共同目标都是在有限的 GPU 资源下，最大化推理吞吐。
部署架构的分层设计——模型层、推理层、服务层——将模型格式、推理引擎、API 服务三个关注点解耦。模型层负责版本管理和格式转换，推理层负责性能优化和资源调度，服务层负责流量路由和灰度发布。每一层可以独立演进，不会因为推理引擎的变更影响 API 层。
灰度发布是模型迭代的必要保障。模型效果的评估不能只看离线指标，必须在线上真实流量中验证。通过 Istio 的流量分配能力，将 5%-10% 的流量导向新版本，观察推理质量和系统指标，确认无异常后再全量切换。
落地路线建议：先从云厂商 API 起步，验证业务可行性；然后自建推理服务，使用 vLLM 或 Triton；再引入模型量化和动态批处理，优化成本；最终建立模型版本管理和灰度发布体系，支撑模型的高频迭代。每一步的投入都应基于推理量和成本数据驱动。
评论0