做AI模型部署这件事最大的错觉就是模型训练好了就万事大吉。真正上线的那一刻才是噩梦开始——同样的环境训练机跑得飞快生产机一加载就OOM延迟好不容易达标了一问吞吐量又拉胯好不容易本地跑通运维一个kubectl apply把Pod调度过去GPU设备却看不见。这几年我在生产环境里推过不下十套模型上线最稳的一套组合拳就是TensorRT做单机加速Docker固化运行环境K8s管整个集群的调度和生命周期。这篇文章就把这条工具链从零到落地串联起来讲清楚适合正在做AI服务化、推理性能优化或者容器化改造的团队参考也适合刚接手K8s部署的工程师照着复现。核心思想很简单模型部署不是“训练结束之后随便找个进程跑一下”而是需要当成一套服务端系统工程来设计。TensorRT负责把训练产物压榨出硬件的极限性能Docker把引擎和运行环境打包成不可变交付物K8s负责让这些交付物在集群里规模化运行、自动恢复、按需伸缩。三层各干各的边界清楚任何一个环节出了问题都能快速定位。1. 为什么是“DockerK8sTensorRT”这套组合拳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(pretrainedTrue).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_version13, do_constant_foldingTrue, 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 \ --onnxresnet50_sim.onnx \ --saveEngineresnet50.engine \ --workspace4096 \ --fp16 \ --minShapesinput:1x3x224x224 \ --optShapesinput:8x3x224x224 \ --maxShapesinput:16x3x224x224这个命令包含几个重点参数--workspace控制TensorRT构建时可用的显存上限设太小会导致部分大网络构建失败--fp16开启半精度性能能翻倍但需要注意精度损失--minShapes/optShapes/maxShapes是动态shape上下界后面细讲。构建完成后会打印出每层的时间和总耗时用这个日志来做性能验收非常直观。2.2 精度与版本兼容性避坑关于TensorRT版本最近在技术社区看到很多人在问“TensorRT 10.x是否支持GTX1070”这是个非常典型的老卡兼容性问题。GTX1070是Pascal架构计算能力6.1TensorRT 10.x官方支持的最低计算能力通常是7.0以上所以严格来说Pascal卡并不是官方支持的目标。实测下来10.x版本在新驱动下能跑但因为核心优化已不再为旧架构做适配收益不会像同时期的消费级卡那么明显而且有些新算子会直接fallback到参考实现速度反而变慢。更务实的做法是老卡停留在TensorRT 8.x系列配合CUDA 11.xPascal架构反而能获得比较接近性能下限的稳定表现。新卡Ampere、Ada、Hopper等可以放心上10.x新架构的重优化算子在吞吐量、显存管理方面收益非常可观。选版本前先确认GPU架构这是做部署的第一条铁律。精度方面FP16是默认选择INT8则慎用。INT8需要校准集来量化模型如果校准集跟线上真实数据分布差太多精度会有明显劣化。我踩过一次坑用几百张老图片做校准线上换了新采集的图片模型分类精度掉了两三个点。后来改成在线抽1000条请求的真实流量作为校准集问题解决了。所以校准集不是随便找一批数据填进去而是必须贴近线上分布。精度模式典型加速比精度损失适用场景FP321x无精度敏感的金融、医疗模型FP161.5~3x极小绝大多数CV、NLP推理INT83~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 --frombuilder /build/model.engine /models/model.engine COPY app/ /app/ WORKDIR /app CMD [python, inference_server.py]这样Builder只负责构建EngineRun阶段直接复用同一个镜像基础层但不会带入编译工具链安全性也更好。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 --runtimedocker 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虚拟IPetcd节点与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 SVMDocker 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 --runtimedockerTensorRT构建报错“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做集群管理你会发现很多调度问题都变得可控得多。这套工具链不能帮你解决模型效果不好这种问题但至少能让你辛辛苦苦调出来的模型在生产环境里跑得快、跑得稳、坏了自己能恢复。