01 它是干嘛的
Triton 是开源的推理服务软件。它支持来自多种训练框架、多种格式的模型，把它们放在同一个服务里统一管理、统一调度，并对外提供统一的调用接口。它的价值在于「收敛」：把一个公司内部五花八门的模型服务，合并成一套标准基础设施。
02 为什么会有它
2018 年之前：每个模型配一套服务，运维同事快要崩溃
同一个公司里，不同团队用的训练框架往往不一样：有人用这个、有人用那个，导出格式也各不相同。结果就是每个模型上线都要单独写一套服务程序，接口风格五花八门，日志、监控、扩缩容各搞一套。
运维的噩梦由此而来：模型数量一多，机器上跑着十几个来历不明的服务，显存怎么分、并发怎么控、某个服务挂了影响谁，全靠人肉记忆。新模型上线要重新评审一遍，效率极低。
Triton 的做法是「定一个大家都能用的服务标准」：不管模型来自什么框架，都放进统一的模型仓库、由同一个服务加载与调度，对外只暴露一套接口。运维只需要维护这一套东西，团队也不必再为每个模型重复造轮子。
03 它怎么工作
Triton 把「模型仓库、加载调度、批处理、多框架执行」这几件事收进一个服务里：请求进来后先排队攒批，再由对应后端执行，最后把结果返回。
一次预测请求进入 Triton 之后的完整旅程
- 1① 扫描模型仓库并加载
Triton 启动时扫描指定目录，发现每个模型文件夹后按需加载，并支持同一模型的多个版本共存与切换。
- 2② 接收请求并路由到对应模型
服务对外暴露统一接口，请求里指明要调用哪个模型与版本，Triton 把它转交给正确的执行后端。
- 3③ 动态批处理
短期内到达的多个小请求被合并成一批一起送入显卡，用一次计算完成多次预测，显著提高显卡利用率。
- 4④ 多框架与多显卡执行
不同模型可分别用不同的推理后端执行，并可分布在多块显卡上并发生效，互不影响。
- 5⑤ 收集结果并返回
各请求的结果被拆回并返回给调用方，同时上报延迟、吞吐与队列长度等指标用于监控。
04 谁在用它
把全公司各团队的模型统一托管到同一套服务上，接口、监控与运维流程标准化。
同一个业务需要图像、文本、语音等多个模型时，用一套服务统一承载。
新版本与旧版本并存，按流量逐步切换，出问题可快速回退。
用动态批处理把零散请求攒成批，让同一块显卡服务更多请求，降低单位成本。
05 怎么用
偏向平台与运维角色：需要按约定组织模型目录，并用命令或配置启动服务。
- 01按规范组织模型仓库：每个模型一个目录，放置模型文件与描述其输入输出的配置。
- 02启动 Triton，指定模型仓库路径，观察日志确认模型被成功加载。
- 03调用就绪检查接口，确认模型状态为可用。
- 04用官方客户端或 HTTP 接口发起一次推理，核对输入输出是否符合预期。
- 05在生产环境开启动态批处理与指标监控，并根据负载调整实例与显卡分配。
# 1) 启动推理服务器，指定模型仓库目录
tritonserver --model-repository=/models
# 2) 查看某个模型是否已就绪
curl localhost:8000/v2/models/resnet50/ready
# 3) 发起一次推理请求（HTTP 接口，输入需按模型要求组织）
curl -X POST localhost:8000/v2/models/resnet50/infer \
-H "Content-Type: application/json" \
-d '{
"inputs": [{"name": "input", "shape": [1, 3, 224, 224], "datatype": "FP32", "data": []}]
}'避坑提示
- !模型的输入输出描述文件最容易写错，形状与数据类型对不上，服务会直接加载失败。
- !动态批处理能大幅省算力，但会增加一点等待时间，对延迟极敏感的接口要单独权衡。
- !同一块显卡上放太多模型会互相抢占显存，加载前先算清显存预算。
06 关键概念
- 推理服务器
- 专门负责加载模型并对外提供预测接口的服务程序。
- 模型仓库
- 按约定组织的目录结构，服务从这里发现并加载模型。
- 动态批处理
- 把几乎同时到达的多个小请求合并成一批一起计算，提高显卡利用率。
- 推理后端
- 真正执行模型计算的底层组件，不同训练框架对应不同的后端。