做AI模型部署这件事，最大的错觉就是：模型训练好了就万事大吉。真正上线的那一刻，才是噩梦开始——同样的环境训练机跑得飞快，生产机一加载就OOM；延迟好不容易达标了，一问吞吐量又拉胯；好不容易本地跑通，运维一个kubectl apply把Pod调度过去，GPU设备却看不见。这几年我在生产环境里推过不下十套模型上线，最稳的一套组合拳就是：TensorRT做单机加速，Docker固化运行环境，K8s管整个集群的调度和生命周期。这篇文章就把这条工具链从零到落地串联起来讲清楚，适合正在做AI服务化、推理性能优化或者容器化改造的团队参考，也适合刚接手K8s部署的工程师照着复现。
核心思想很简单：模型部署不是“训练结束之后随便找个进程跑一下”，而是需要当成一套服务端系统工程来设计。TensorRT负责把训练产物压榨出硬件的极限性能，Docker把引擎和运行环境打包成不可变交付物，K8s负责让这些交付物在集群里规模化运行、自动恢复、按需伸缩。三层各干各的，边界清楚，任何一个环节出了问题都能快速定位。
1. 为什么是“Docker+K8s+TensorRT”这套组合拳
1.1 部署链路中的三大痛点
先说说没有这套工具链之前，团队踩过的典型坑。
第一是性能浪费。当时团队直接用PyTorch的TorchServe加载TorchScript模型跑推理，单卡A100上处理一张1080p图片的pipeline延迟在30毫秒左右，这个数字单看还行，但线上要支撑每秒几百路并发，资源成本立刻翻了几倍。模型推理的优化空间极大，PyTorch原生推理引擎会把很多计算图中间节点原样执行，而TensorRT会做层融合、算子替换、精度校准，同一个模型优化后延迟能降到10毫秒以内。
第二是环境一致性。训练机上的CUDA 11.8、cuDNN 8.6、PyTorch源码编译版，在生产机上稍微差一个patch，运行时可能直接报算子不存在或者精度漂移。最典型的一次是某成员本地用cuDNN 8.4验证通过，生产机的镜像却锁了8.2，模型输出直接变成NaN，排查了两天才定位到是库版本不同导致的反卷积数值异常。
第三是扩缩容能力。单机部署的模型服务，高峰期CPU和显存被打满只能干等着，等扩容脚本跑完高峰期也过了。而K8s作为容器编排调度平台，天然支持声明式部署、水平伸缩、健康检查和服务发现，模型服务是典型的无状态工作负载，放进去非常合适。
1.2 工具链的分工与选型逻辑
这三个组件不是各干各的，而是互补的。TensorRT解决的是“单张卡上跑多快”的问题，Docker解决的是“换台机器还能不能跑”的问题，K8s解决的是“整个集群怎么管、流量怎么分配、坏了怎么办”的问题。
可以打个比方：TensorRT像一辆改装过的赛车发动机，动力强但很“挑食”；Docker是给这台发动机定制了一个标准货柜，不管搬到哪里，只要货柜在就能正常启动；K8s就是那个港口调度系统，负责把货柜调度到空闲泊位、坏了自动吊走、流量大的时候多吊几个过来。
为什么不直接跳过Docker用K8s？因为K8s里的Pod镜像是运行的最小单元，没有Docker生成的标准镜像，调度系统无从下手。为什么不只用TensorRT做个高性能服务器？因为单机方案再快，也逃不过机器宕机、流量突增、版本回滚这些运维问题。
1.3 总体架构设计
我团队现在落地的标准流程是这样的：
- 训练完成后，把模型权重导出为ONNX格式；
- 用TensorRT的trtexec或Python API将ONNX转换成Engine文件；
- 将Engine文件、推理服务代码、依赖库打包进Docker镜像；
- 将镜像推送到私有镜像仓库；
- 在K8s集群中创建Deployment、Service、Ingress等资源；
- 通过K8s的调度能力把Pod调度到带有GPU标签的节点上。
这套流程从开发到上线，一条完整的自动化管道已经跑通了。每一个阶段都有明确的产物和检查点：ONNX文件有算子和输入shape的检查、Engine文件有精度对比报告、镜像有冒烟测试、K8s部署有健康检查。下面按顺序展开讲每个环节的关键细节。
2. TensorRT加速：从pt模型到可交付的Engine文件
2.1 模型转换全流程
很多人以为直接用PyTorch装一个TensorRT插件就能吃满加速效果，实际上完整转换链路的坑全在中间层。标准做法是先走ONNX。
把PyTorch模型转成ONNX，代码不复杂，但有几个参数必须盯紧。导出时必须设置opset_version，我一般用13或更高版本，否则很多动态算子会报不支持。input_names和output_names最好手动指定，这样后续解析动态shape时不容易糊涂。
import torch import torchvision.models as models model = models.resnet50(pretrained=True).eval().cuda() dummy_input = torch.randn(1, 3, 224, 224).cuda() torch.onnx.export( model, dummy_input, "resnet50.onnx", input_names=["input"], output_names=["output"], opset_version=13, do_constant_folding=True, dynamic_axes={"input": {0: "batch", 2: "height", 3: "width"}, "output": {0: "batch"}} )导出之后别急着转TensorRT，先用onnx-simplifier清理一下计算图。很多框架导出时会有大量冗余的reshape、transpose，这些算子TensorRT支持得不完美，经常导致转换失败，简化之后会好很多。我用python -m onnxsim resnet50.onnx resnet50_sim.onnx这行命令跑过很多模型，成功率高了不少。
然后进入关键一步：用trtexec转换Engine文件。trtexec是TensorRT自带的命令行工具，排查问题非常方便，尤其是看日志里每个算子的选择。一个基础转换命令长这样：
trtexec \ --onnx=resnet50_sim.onnx \ --saveEngine=resnet50.engine \ --workspace=4096 \ --fp16 \ --minShapes=input:1x3x224x224 \ --optShapes=input:8x3x224x224 \ --maxShapes=input:16x3x224x224这个命令包含几个重点参数：--workspace控制TensorRT构建时可用的显存上限，设太小会导致部分大网络构建失败；--fp16开启半精度，性能能翻倍但需要注意精度损失；--minShapes/optShapes/maxShapes是动态shape上下界，后面细讲。构建完成后会打印出每层的时间和总耗时，用这个日志来做性能验收非常直观。
2.2 精度与版本兼容性避坑
关于TensorRT版本，最近在技术社区看到很多人在问“TensorRT 10.x是否支持GTX1070”，这是个非常典型的老卡兼容性问题。GTX1070是Pascal架构，计算能力6.1，TensorRT 10.x官方支持的最低计算能力通常是7.0以上，所以严格来说Pascal卡并不是官方支持的目标。实测下来，10.x版本在新驱动下能跑，但因为核心优化已不再为旧架构做适配，收益不会像同时期的消费级卡那么明显，而且有些新算子会直接fallback到参考实现，速度反而变慢。
更务实的做法是：老卡停留在TensorRT 8.x系列，配合CUDA 11.x，Pascal架构反而能获得比较接近性能下限的稳定表现。新卡（Ampere、Ada、Hopper等）可以放心上10.x，新架构的重优化算子在吞吐量、显存管理方面收益非常可观。选版本前先确认GPU架构，这是做部署的第一条铁律。
精度方面，FP16是默认选择，INT8则慎用。INT8需要校准集来量化模型，如果校准集跟线上真实数据分布差太多，精度会有明显劣化。我踩过一次坑：用几百张老图片做校准，线上换了新采集的图片，模型分类精度掉了两三个点。后来改成在线抽1000条请求的真实流量作为校准集，问题解决了。所以校准集不是随便找一批数据填进去，而是必须贴近线上分布。
| 精度模式 | 典型加速比 | 精度损失 | 适用场景 |
|---|---|---|---|
| FP32 | 1x | 无 | 精度敏感的金融、医疗模型 |
| FP16 | 1.5~3x | 极小 | 绝大多数CV、NLP推理 |
| INT8 | 3~5x | 需校准 | 对延迟极度敏感的高并发场景 |
2.3 动态shape处理
生产环境里模型的输入尺寸经常不固定，比如目标检测模型要处理不同分辨率的图片。TensorRT的Engine必须显式定义shape范围，这个范围就是通过dynamic_axes和minShapes/optShapes/maxShapes来共同约束的。
我的经验是：optShapes设置成线上最常见的shape，这样TensorRT会针对这个最优shape做算子融合和内存布局优化，性能比随便设一个中间值要好不少。minShapes和maxShapes之间跨度不能太大，否则构建引擎会变慢，显存占用也会变高，而且某些算子（比如部分ROI pooling、NMS）对动态范围特别敏感，范围拉太宽容易导致构建失败或精度劣化。
如果不想用trtexec转动态Engine，也可以用TensorRT的Python API来构建，代码可控性更高。大致流程是：用Builder创建INetworkDefinition，然后创建OptimizationProfile，设置setDimensions的min/opt/max，最后按此profile构建Engine。用Python API的好处是调试方便，可以在构建前做很多自定义网络检查，适合做自动化pipeline里的构建服务。
3. Docker容器化：让Engine可移植、可运行
3.1 镜像设计与分层
TensorRT构建出的Engine文件和推理服务代码打包进Docker镜像是整个部署链路里最“无聊”但最容易出错的一步。很多团队在这一步犯的最大错误是：直接用CPU版的Python基础镜像，然后硬塞一个CUDA依赖，结果镜像跑到GPU节点上依然找不到CUDA运行库。
正确做法是直接用NVIDIA官方的NGC镜像作为基础层。NVIDIA提供了已经装好TensorRT、CUDA和cuDNN的镜像，比如nvcr.io/nvidia/tensorrt:23.10-py3。基于这个镜像，你可以直接拷贝Engine文件和推理代码进去，不用从零装CUDA库。这是最稳的容器环境基线，我实测过，跑起来后nvidia-smi能正常显示，深度学习模型推理也能正确读写GPU显存。
另外，尽量做多阶段构建。Builder阶段装编译器、转换工具链等开发依赖，Run阶段只保留运行时库和Engine文件，这样镜像体积能小一半以上。Dockerfile大致长这样：
FROM nvcr.io/nvidia/tensorrt:23.10-py3 AS builder COPY torch_model.py /build/ RUN python /build/export_onnx.py && \ trtexec --onnx=/build/model.onnx --saveEngine=/build/model.engine --fp16 FROM nvcr.io/nvidia/tensorrt:23.10-py3 COPY --from=builder /build/model.engine /models/model.engine COPY app/ /app/ WORKDIR /app CMD ["python", "inference_server.py"]这样Builder只负责构建Engine，Run阶段直接复用同一个镜像基础层，但不会带入编译工具链，安全性也更好。
3.2 GPU透传配置
镜像里光有CUDA库还不够，Docker容器要能访问GPU，主机侧必须装好nvidia-container-toolkit。这个装不好，Pod起来后执行nvidia-smi会直接报“could not select device driver”。装的过程大致如下：
distribution=$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker装完之后做一次验证，这个验证步骤别跳过：
docker run --rm --gpus all nvidia/cuda:11.8-base nvidia-smi如果这里能正常打印GPU信息，说明GPU透传链路没问题。如果有报错，先查主机驱动和CUDA版本是否匹配。很多运维同事习惯看“docker info”，其实最关键的是nvidia-container-toolkit的日志位置，在/var/log/nvidia-container-toolkit.log，排错比看docker日志更直接。
3.3 Docker Compose编排与网络问题排查
如果还没上K8s，先用Docker Compose做单机多容器编排也够用。比如模型推理服务、Redis、Prometheus exporter这几个容器要一起跑，一个docker-compose.yml就能搞定依赖顺序和网络组网。
比较常见的网络故障是容器网络不通。新手排查顺序我总结过：
- 先看宿主机防火墙是否放行了容器网段；
- 再看容器内
/etc/hosts和DNS配置； - 然后用
docker exec进入容器，ping外部主机测试连通，接着docker network inspect bridge看网关是否正常； - 最后检查iptables规则，Docker启动时会改写iptables，如果宿主机有自建防火墙策略，很容易把容器流量误拦。
最稳的办法是减少桥接折腾，直接使用host网络模式，但生产场景不推荐，因为Host模式会让容器之间端口冲突变得非常难排查。建议固定用bridge + compose里显式声明depends_on，配合健康检查去解决依赖问题。
4. Kubernetes调度：把推理服务规模化
4.1 核心对象设计
Docker镜像打包完成后就进入K8s阶段，这也是从单机走向集群的分水岭。先说最核心的两个对象：Deployment和Service。
Deployment管理副本数和滚动更新，我用它来控制推理服务的实例数量。一个标准的GPU推理Deployment长这样：
apiVersion: apps/v1 kind: Deployment metadata: name: tensorrt-infer namespace: ai labels: app: tensorrt-infer spec: replicas: 3 selector: matchLabels: app: tensorrt-infer template: metadata: labels: app: tensorrt-infer spec: containers: - name: infer image: registry.infra.local/ai/tensorrt-infer:1.4.0 imagePullPolicy: IfNotPresent resources: limits: nvidia.com/gpu: 1 ports: - containerPort: 8080 readinessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10Service用于把多个Pod统一暴露成一个虚拟IP。很多中小团队没有Ingress Controller，直接用NodePort或者externalIPs对外暴露。关于externalIPs，它本质上是手动指定一个宿主机IP，把该IP上的某个端口直接转给Service。比如Kubernetes里可以这样配置：
apiVersion: v1 kind: Service metadata: name: tensorrt-infer-svc spec: selector: app: tensorrt-infer ports: - name: http port: 80 targetPort: 8080 externalIPs: - 192.168.1.100这样只需要确保该IP被路由到这个集群的某个节点，外部访问http://192.168.1.100/api就能直达Pod。用externalIPs有个需要注意的点：这个IP必须是当前节点已配置的本机IP或可以被节点接收的IP，否则流量接不住。网络平面比较复杂的场景，还是建议上NodePort或者LoadBalancer。
4.2 GPU资源调度
K8s本身并不会自动识别GPU资源，必须部署一个NVIDIA device plugin插件。这个插件的全称是nvidia-device-plugin，它向Kubelet上报GPU数量和健康状态，这样调度器才能在Pod的resources.limits里识别nvidia.com/gpu: 1。
部署方式很简单，直接跑官方给的DaemonSet YAML就行。跑完后用kubectl get nodes -o json | jq '.status.allocatable'查看节点上的GPU资源是否已经被感知。
这里有一个常见误区：很多新手在Pod里不写resources，或者只在limits里写GPU而在requests里不写，结果Pod可能被调度到没有GPU的节点上。正确做法是在limits和requests里都要写上nvidia.com/gpu，因为调度器看的是requests。另外，如果需要在同一个GPU上跑多个推理实例，可以开启时间切片功能，但显存隔离有限，不建议生产环境无脑开。
4.3 高可用与Operator实践
关于高可用，如果你要管理的是三台master节点，用KubeKey或直接基于kubeadm搭一套HA集群是标准做法：三台master前挂Keepalived虚拟IP，etcd节点与master一一对应或独立部署。这样一台master宕机后，虚拟IP自动漂移，API Server仍能正常提供服务。
但在单集群高可用之上，真正的生产级演进是引入Operator模式。Operator本质上是把运维知识固化成代码，调度器用它来自动管理复杂应用生命周期。对模型推理服务来说，用Operator做滚动升级有一个天然优势：可以让模型版本灰度升级，避免Deployment默认的“先全量replace，再check”机制带来的服务闪断。我们用Operator做过线上A/B Test，由套壳的controller监听自定义CRD里的suspend: true标记，把新旧版本Pod同时保留一段时间，再逐步切流，这个效果比简单kubectl apply一个Deployment再手动改selector要优雅得多。
5. 实操过程中的坑与排查对照表
这套工具链跑久了，会积累很多碎片化的报错经验。我整理了一张高频问题的速查表，按“报错现象、根因、解决方案”三条来给，方便团队直接照着排查：
| 报错现象 | 根因 | 解决方案 |
|---|---|---|
| Docker Desktop启动失败，提示“virtualization support not detected” | BIOS中未开启虚拟化功能 | 重启进BIOS，开启Intel VT-x或AMD SVM |
| Docker API连接失败，报错“npipe:////./pipe/dockerdesktop” | Docker Desktop服务没起来，或Windows Docker引擎异常 | 先检查服务状态，再重启Docker Desktop，确认Hyper-V/WSL2内核 |
容器内运行nvidia-smi报“could not select device driver” | NVIDIA容器工具链未安装或未配置runtime | 重装nvidia-container-toolkit，并执行sudo nvidia-ctk runtime configure --runtime=docker |
| TensorRT构建报错“invalid bounding box shape” | 模型输出shape与预设dynamic range不匹配 | 检查ONNX输出的shape定义，调整maxShapes范围 |
| TensorRT在GTX1070上报出部分算子不支持 | 老架构不在当前TensorRT支持列表 | 降到TensorRT 8.x或换新架构卡 |
| K8s Pod调度失败，事件显示“0/1 nodes are available” | 节点GPU资源不足或未正确上报 | 查看kubectl describe node的Allocatable，确认GPU资源是否已注册 |
| Pod能起来但CPU/GPU利用率低 | 成员把requests和limits设置过大，导致负载均衡走错节点 | 调整resources配置，保持requests与真实用量匹配 |
| 镜像太大，拉取非常慢 | 基础镜像混入了编译工具链 | 用多阶段构建，run阶段仅保留运行时库 |
| Service通过externalIPs访问不通 | 宿主机的socket绑定、iptables NAT规则或防火墙未放行 | 检查节点上netstat和iptables -t nat -L，确认DNAT规则存在 |
| 模型推理精度漂移 | 半精度或量化配置问题，或校准集与线上分布不一致 | 改成FP32对比一次，或更换校准集重新量化 |
除了这些，再分享一个容易被忽略的细节：引擎文件和容器版本绑定的问题。TensorRT构建出的Engine文件强烈依赖构建时的GPU和CUDA版本，把Engine文件从构建机拷贝到另一台不同型号的GPU上，很可能无法加载；即使能加载，性能也未必达标。所以我现在的做法是：在每个GPU节点上各自用同一份镜像构建Engine缓存，而不是直接拷贝engine文件。这样虽然第一次启动会多花两分钟，但彻底避免了跨机器兼容性问题。
6. 我的经验总结
做这套工具链，有几个原则是我一直坚持的。第一，不要在生产容器里临时做模型转换，把所有Build过程放在CI或专门的构建阶段完成，产出的Engine才是可控交付物。第二，低版本驱动要锁死，凡是涉及CUDA、cuDNN和TensorRT的环境变量，一定要打版本标签，不许用latest，否则哪台机器跑挂都不知道哪个组件变了。第三，监控必须前置，上线第一天就把Prometheus + Grafana接好，不仅监控GPU利用率，还要监控模型推理的请求延迟分位数和每个Pod的显存用量，这样出问题第一时间能定位是服务层、调度层还是硬件层的问题。
如果你团队还停留在“模型文件发给运维，运维自己找机器跑”的阶段，我真的建议先把Docker和nvidia-container-toolkit这条链路跑通，再去碰K8s。等Docker环境百分百稳定了，再上K8s做集群管理，你会发现很多调度问题都变得可控得多。这套工具链不能帮你解决模型效果不好这种问题，但至少能让你辛辛苦苦调出来的模型，在生产环境里跑得快、跑得稳、坏了自己能恢复。
