今天聊的是用Triton部署PyTorch模型时，怎么通过几个实操步骤把性能提上去——这是我之前做线上项目踩过坑后总结的实用经验，哪怕刚入门的开发者也能跟着落地。
一、为什么Triton部署PyTorch模型要做性能调优？
先讲最实际的应用场景：假设你用PyTorch训练了一个商品分类模型，要部署到线上给用户用，要是直接把模型文件丢给Triton啥都不调，性能大概率还不如你自己写个Flask服务跑的快。我之前做电商项目时，刚开始裸部署Triton，每秒只能处理80条分类请求，用户刷商品要等五六百毫秒，明显卡；后来调优后，每秒能处理320条请求，延迟降到120ms，用户体验直接上来了。 再说说Triton的优缺点：优点是不用自己写请求合并、模型版本管理、资源调度这些杂事，支持多框架，能自动扩缩；缺点是如果PyTorch模型没适配、配置错了，就会浪费GPU/CPU资源，跑的慢还出问题。 最后提注意事项：调优不是瞎试，要结合模型特点和服务器硬件，不能拿别人的配置直接套，得自己测了才准。
二、具体调优实操步骤
2.1 先把PyTorch模型转成Triton能识别的格式
Triton本身不认PyTorch的.pth原生权重文件，得转成中间格式，最常用的是torchscript，兼容性好还不怎么掉性能。这里给完整示例，技术栈统一用PyTorch 2.1、Triton Inference Server 2.35：
# 导入PyTorch核心模块
import torch
import torchvision.models as models
# 加载预训练的ResNet50模型（实际项目换自己训练的模型路径就行）
model = models.resnet50(pretrained=True)
# 关键！必须设为推理模式，关掉dropout、batch norm的训练逻辑，不然性能差还不准
model.eval()
# 构造和实际输入匹配的示例输入：这里是单张图片，3通道，224x224尺寸
dummy_input = torch.randn(1, 3, 224, 224)
# 用trace方式转换为torchscript，适合静态结构的模型（大多数CV模型都用这个）
traced_model = torch.jit.trace(model, dummy_input)
# 按Triton要求的目录结构保存，后续config里要对应路径，比如/resnet50/1/model.pt
traced_model.save("resnet50_pt.pt")
这里要注意：要是你用的是动态输入的模型（比如NLP的变长文本），可以换用torch.jit.script，trace适合固定结构，script适合有控制流的动态结构。
2.2 调好Triton的核心配置文件
转好模型后，必须写config.pbtxt配置文件，Triton靠这个知道模型的各种参数，这是调优的核心。给完整示例，每个字段都加了注释：
# 模型名，和目录名对应
name: "resnet50"
# 用PyTorch的官方后端，别填错，不然模型加载失败
platform: "pytorch_libtorch"
# 单次最大批处理数，根据GPU显存调：16G GPU设32，8G设16，太小GPU利用率低，太大爆显存
max_batch_size: 8
# 输入定义，要和模型的输入名、尺寸匹配（看模型转换时的dummy_input）
input [
{
name: "input__0"
data_type: TYPE_FP32
dims: [3, 224, 224]
}
]
# 输出定义，同理匹配模型输出
output [
{
name: "output__0"
data_type: TYPE_FP32
dims: [1000]
}
]
# 实例组：这里用1个GPU实例，要是多GPU可以设多个count
instance_group [
{
count: 1
kind: KIND_GPU
gpus: [0]
}
]
# 关键！开启动态批处理，Triton会自动把多个小请求凑成一批，发挥GPU并行能力
dynamic_batching {
# 偏好的批大小，对应max_batch_size的一半左右，别设太大
preferred_batch_size: [4, 8]
# 凑批的最大等待时间，单位微秒，1000微秒=1毫秒，太长用户等的久，太短凑不成批
max_queue_delay_microseconds: 1000
}
这里解释下动态批处理的作用：单个小请求跑GPU，GPU的利用率只有30%都不到，凑成8个一起跑，利用率能到80%以上，吞吐量直接翻几倍，延迟也不会飙升太多（单个请求的等待时间从10ms变15ms，总处理请求数翻3倍）。
2.3 启动Triton时的硬件适配
启动命令要选对，不然用不到GPU性能，给Docker启动示例（主流部署方式）：
# 用官方Triton镜像，--gpus all才能用GPU，映射模型仓库，暴露8000(HTTP)、8001(gRPC)、8002(Metrics)端口
docker run --gpus all -p 8000:8000 -p 8001:8001 -p 8002:8002 \
# 把本地模型目录映射到容器内的/models，要换成你自己的模型路径
-v /本地/模型/目录:/models \
nvcr.io/nvidia/tritonserver:2.35-py3 \
# 指定模型仓库，设日志级别为info，方便看加载情况
tritonserver --model-repository=/models --log-info=1
注意：要是服务器没GPU，把--gpus all去掉，Triton会用CPU，性能会差，但是能跑。
2.4 用工具找最优参数，排查瓶颈
Triton自带perf_analyzer工具，不用自己写脚本测性能，直接用它找最优的并发数和批大小。示例命令：
# 测试resnet50模型的性能，并发数从1到8逐步测试，batch size=8，用随机输入模拟实际请求
perf_analyzer -m resnet50 --concurrency-range 1:8:1 -b 8 --input-data random --shape input__0:1,3,224,224
执行后会输出结果，比如看到并发数到4的时候，每秒能处理310个请求，延迟100ms，并发数到8的时候，每秒还是310，延迟涨到210，那最优并发数就是4，别调太高，不然资源浪费还延迟高。
三、实际项目的调优前后细节
我之前的电商商品分类模型，刚部署时TPS（每秒请求数）只有82，平均延迟590ms，用户反馈“点分类要等很久”。调优后，TPS到327，平均延迟118ms，提升非常明显，核心就是做了这几点：把模型转成torchscript，配置了动态批处理，max_batch_size设成8，用GPU跑，最后用perf_analyzer把并发数调到4。
这里补充动态批处理的注意点：如果模型是动态输入（比如NLP的变长文本），要在config的input里设dims: [-1]，告诉Triton输入维度是可变的，不然会报错。
四、调优的关键坑点和注意事项
- 模型转换必须设eval模式：我之前踩过坑，忘了设eval，模型里的dropout还在生效，推理时随机失活，导致分类准确率掉了5%，还跑的慢，后来改了才好；
- max_batch_size别设太大：要是16G的GPU设成64，直接爆显存，模型加载失败，得根据GPU显存和模型大小算；
- 动态批处理的等待时间别乱调：我之前设过10000微秒（10毫秒），结果用户请求要等10秒才处理，直接崩了，后来改回1000；
- 能转TensorRT更好：要是要极致性能，把torchscript转成TensorRT的plan文件，性能能再提20%-50%，示例代码：
import torch2trt
traced_model = torch.jit.load("resnet50_pt.pt")
dummy_input = torch.randn(1,3,224,224).cuda()
# 转成FP16的TensorRT模型，速度更快，精度损失很小
trt_model = torch2trt.torch2trt(traced_model, [dummy_input], fp16_mode=True)
trt_model.save("resnet50_trt.plan")
转完后把config的platform改成tensorrt就行。
五、总结
Triton部署PyTorch模型的性能调优，本质是让模型、请求、硬件三者匹配，不用复杂的算法，按步骤转模型、写对配置、用工具测，就能拿到不错的性能。适合电商、视频分类、客服机器人这些高并发的线上场景，只要避开我踩过的坑，入门级开发者也能快速搞定。
评论
围绕“Triton部署PyTorch模型时的性能调优经验分享”参与讨论