跳转到内容
Jason's Study

Triton Inference Server — NVIDIA 多框架推理服务化标杆

是什么

Triton Inference Server（下称 Triton-IS）是 NVIDIA 开源的一套把训练好的模型对外提供 HTTP / gRPC 推理服务的服务器。日常类比：像一家”模型快餐店”——后厨有十几口锅（TensorRT / TensorFlow / PyTorch / ONNX / OpenVINO / vLLM 等不同框架），前台只有一个柜台（统一 HTTP 接口）；点单进来店长会自动凑单（动态批处理），把一桌的菜一锅炒出来送上桌。

由 NVIDIA 在 2018 年发布，最早叫 TensorRT Inference Server (TRTIS)，2019 年改名为 Triton Inference Server，扩展为多框架。BSD-3 协议，约 8.5k stars，主语言 C++，配合 Python / Java client SDK。

重要消歧：与 OpenAI 的 Triton（一个写 GPU kernel 的 Python DSL，见 triton-2019）同名但完全无关。OpenAI Triton 是”写 kernel 的 DSL”；Triton-IS 是”对外暴露 endpoint 的 server”。两者经常被搜索结果搅在一起。

为什么重要

不理解 Triton-IS，下面这些事就没法解释：

  • 大型推理工厂为什么不写 FastAPI 套 PyTorch，而是用 Triton-IS——因为 dynamic batching、并发实例、多框架共存这些事自己写一遍要几个月
  • 为什么 K8s 上部署模型时 KServe / Seldon 默认推荐 Triton-IS 当运行时——它实现了 KServe v2 API 标准
  • 为什么同一个 server 能同时跑视觉的 TensorRT 引擎、文本的 ONNX 模型、还能挂一个 vLLM 后端跑 LLM——后端是插件式的
  • 为什么 Microsoft Bing、蔚来汽车、American Express 在生产里都用它——它是过去 7 年迭代出来的工业级工程基建

核心要点

模型仓库（model repository）

Triton-IS 启动时只指向一个目录，约定结构：

model_repository/
  resnet50/
    config.pbtxt
    1/
      model.plan       # TensorRT 引擎
  bert-classify/
    config.pbtxt
    2/
      model.onnx

每个模型一个文件夹，里面按版本号子目录放权重文件，config.pbtxt 用 protobuf 文本格式声明输入输出 shape、batch、framework 等。踩坑提醒：版本目录必须是纯数字。

动态批处理（dynamic batching）

多个独立 HTTP 请求到达后，server 在排队 N 微秒内尽量凑成一批，再一次性送 GPU。配置三把旋钮：

dynamic_batching {
  preferred_batch_size: [4, 8]
  max_queue_delay_microseconds: 5000
}

max_queue_delay 是用延迟换吞吐的旋钮——延迟上限多大，就能凑出多大的 batch。这是推理工程最重要的权衡之一。

并发模型执行（instance groups）

instance_group [{ count: 2, kind: KIND_GPU, gpus: [0] }]

在 GPU 0 上跑 2 份该模型实例，请求自动负载均衡。两份模型权重会各占一份显存——不是免费午餐。

Ensemble / BLS（多模型串成 pipeline）

ensemble_scheduling 把”分词 → 主模型 → 后处理”三个 step 串成 1 个对外 endpoint，请求只来一次，中间 tensor 在 server 内部传递。复杂逻辑用 BLS（Business Logic Scripting，Python 后端）写代码版的编排。

多种 backend 是插件

后端 = 一个动态库 .so。官方提供 TensorRT / ONNX Runtime / PyTorch / TF / OpenVINO / Python / DALI / vLLM / TensorRT-LLM 等十多种；自己也可以写 backend 接管推理流程。

实践案例

案例 1：起一个最简 server

Terminal window
docker run --gpus=1 --rm -p8000:8000 -p8001:8001 \
    -v $PWD/model_repository:/models \
    nvcr.io/nvidia/tritonserver:24.10-py3 \
    tritonserver --model-repository=/models

8000 是 HTTP，8001 是 gRPC，8002 是 Prometheus metrics。

案例 2：客户端调用

import tritonclient.http as httpclient
client = httpclient.InferenceServerClient(url="localhost:8000")
inputs = httpclient.InferInput("INPUT_0", [1, 3, 224, 224], "FP32")
inputs.set_data_from_numpy(image_np)
result = client.infer("resnet50", inputs=[inputs])

注意 input 的 dim layout 必须和 config.pbtxt 完全一致——常见 422 的根因就在这里。

案例 3：和 vLLM 后端搭一个 LLM endpoint

把 Llama 模型放进 model_repository/llama/1/，config.pbtxt 选 backend: "vllm"，server 启动时 vLLM backend 自动拉起，对外仍是统一的 Triton 接口。这种组合让你在同一个 server 里既能跑视觉模型，也能跑大语言模型。

踩过的坑

  • GPU 利用率上不去：忘开 dynamic_batching 或 instance count = 1，单请求把 GPU 闲死。打开 --log-verbose=1 看请求是否真的被合批
  • dim 写错直接 422：[-1, 224, 224, 3]（NHWC，TensorFlow）vs [3, 224, 224]（CHW，PyTorch / ONNX），写错请求被拒
  • 镜像选错：tritonserver:24.xx-py3 是完整版（几 GB），生产精简用 -min 镜像并按需加 backend
  • Ensemble 中间 tensor 走 CPU：默认两个 step 之间数据先回 CPU 再下 GPU，掉性能；需配置策略让其驻留 GPU
  • 多实例 OOM：count: 4 等于把模型权重在显存里复制 4 份；70B 模型这样很快炸卡
  • 不能训练：Triton-IS 只做推理。训练用 PyTorch / Megatron 等，训完导出再喂给它

适用 vs 不适用场景

适用：

  • 多模型 / 多框架共存的推理工厂，需要统一接口
  • K8s 大规模部署，配 KServe / Seldon 做自动扩缩
  • 需要请求级动态批处理把吞吐量打满
  • 同一个 server 既挂视觉模型又挂 LLM（vLLM backend 或 TensorRT-LLM backend）

不适用：

  • 纯单一 LLM、追求极致吞吐 → 直接用 vllm / sglang 更轻
  • Python 业务逻辑很厚（前后处理是核心） → bentoml / FastAPI 更顺手
  • 边缘 / 嵌入式 → ONNX Runtime / TFLite 直接进进程
  • 闭源云模型（GPT / Claude）→ 直接调它们的 API，Triton-IS 跑不了

历史小故事（可跳过）

  • 2018：NVIDIA 发布 TensorRT Inference Server (TRTIS)，目标是把 TensorRT 优化好的引擎对外暴露成 HTTP/gRPC
  • 2019-09：更名为 Triton Inference Server，加入多框架后端（TF / PyTorch / ONNX / Python）——单一 TensorRT 战线被拓宽
  • 2020：进入 KServe（前身 KFServing）默认推荐运行时；引入 Ensemble
  • 2022：加入 BLS（Business Logic Scripting），让 Python backend 能在 server 内部写调度
  • 2023：TensorRT-LLM Backend 发布，支持高性能 LLM 推理
  • 2024-2025：vLLM Backend 加入；与 NVIDIA NIM 微服务整合，成为 NIM 的默认运行底座

学到什么

  • 服务化 = 仓库结构 + 动态批 + 后端插件——三件事缺一就要自己写一遍
  • dynamic batching 是吞吐杠杆：max_queue_delay 这一个旋钮就在调”延迟上限 vs GPU 利用率”
  • 多框架后端比单框架运行时长寿：团队不会只用一种栈，统一接口 + 可插拔后端是工业级软件的常见骨架
  • 命名冲突要敏感：Triton-IS vs OpenAI Triton 是不同东西，搜资料一定要看上下文（kernel 还是 server）

延伸阅读

关联

  • vllm —— 单一 LLM 高吞吐引擎；可被 Triton-IS 当 backend 挂载
  • sglang —— 结构化 LLM 推理运行时；定位与 vLLM 接近
  • tensorrt-llm-2023 —— NVIDIA 官方 LLM 推理栈；Triton-IS 的”亲儿子”backend
  • triton-2019 —— 同名 OpenAI Triton（GPU kernel DSL），完全不同领域
  • nvidia-gpu-operator —— K8s 上自动装 GPU 软件栈，常与 Triton-IS 一起部署
  • bentoml —— Python-first 模型打包；定位互补，业务逻辑厚时更顺手
  • fastapi —— 自己写推理服务的轻量替代；适合小规模 / 高定制