Triton Inference Server：NVIDIA 的推理"瑞士军刀"——LLM 只是它的一种负载

LLM 推理服务系列 · 第 3 篇

vLLM 和 TGI 是"纯 LLM"推理引擎------设计目标单一：高效服务 Transformer 模型。Triton Inference Server 不一样------它是 NVIDIA 2018 年发布的通用推理服务器。LLM 只是它的一个后端，它还能服务图像分类、语音识别、推荐模型、树模型、甚至你写的 Python 函数。

这篇文章拆 Triton------不是因为它做 LLM 比 vLLM 强，而是因为生产环境里你往往不止服务一种模型。Triton 的价值在于"一个平台统一所有推理"。

Triton 的核心设计：Backend 抽象

Triton 不关心模型是什么------它只关心"我给你输入，你给我输出"。不同的模型用不同的 Backend 加载：

scss 复制代码

Triton Server
     │
     ├── PyTorch Backend      → 加载 .pt 模型
     ├── TensorRT Backend     → 加载 .plan (TensorRT 编译后的优化引擎)
     ├── ONNX Runtime Backend → 加载 .onnx 模型
     ├── TensorFlow Backend   → 加载 SavedModel
     ├── vLLM Backend         → 加载 LLM（复用 vLLM 的 PagedAttention）
     ├── Python Backend       → 运行任意 Python 代码 (DAG pipeline)
     ├── XGBoost Backend      → 加载 .model 树模型
     └── FIL Backend          → 加载 LightGBM, XGBoost, RandomForest（树模型专精）

这意味着：同一个 Triton 实例可以同时跑------LLM（推理聊天） + BERT（分类用户意图） + ResNet（审核上传图片） + XGBoost（风控打分）。对于生产环境------不用为每个模型部署一个独立的推理服务------运维成本大幅降低。

模型仓库：声明式模型管理

Triton 用文件目录约定来管理模型：

arduino 复制代码

model_repository/
├── llama-8b/
│   ├── config.pbtxt          ← Triton 的模型配置（核心）
│   └── 1/                     ← 版本 1
│       └── model.safetensors  ← HuggingFace 格式的模型文件
│
├── bert-classifier/
│   ├── config.pbtxt
│   └── 1/
│       └── model.onnx         ← ONNX 格式
│
└── fraud-detector/
    ├── config.pbtxt
    ├── 1/
    │   └── model.xgb          ← XGBoost 模型
    └── 2/                     ← 版本 2（新版本上线）
        └── model.xgb

config.pbtxt 是核心------声明模型的最大 Batch Size、输入输出 Tensor 的 Name/Shape/Datatype、动态 Batching 策略、GPU 实例数：

protobuf 复制代码

# LLM 模型的 config.pbtxt
name: "llama-8b"
backend: "vllm"
max_batch_size: 32

instance_group [
  {
    count: 1           # 每个 GPU 启动 1 个实例
    kind: KIND_GPU
    gpus: [0, 1]       # 使用 GPU 0 和 1（张量并行）
  }
]

model_transaction_policy {
  decoupled: true      # LLM 的流式生成需要这个
}

parameters {
  key: "gpt_model_path"
  value: { string_value: "/models/llama-8b/1/" }
}

声明式的好处：改配置不需要改代码。 扩 GPU、调整批处理大小、AB 测试新旧版本------全部改 config.pbtxt 后重启即可。

Dynamic Batching：不需要等"满一批"

Triton 的 Dynamic Batching 策略比 vLLM/ TGI 更灵活------因为它是框架无关的抽象：

python 复制代码

策略一：Default（默认）
  等一个 batch 满了（或超时）→ 一起 Forward

策略二：Inflight Batcher（LLM 专用）
  跟 vLLM 的 Continuous Batching 等效
  请求到达立即加入 batch，完成立即退出

策略三：Sequence Batcher（序列模型专用）
  处理有状态序列（如流式语音识别）
  维护每个序列的内部状态

Inflight Batcher 是 Triton 22.09 版本引入的新特性------专门为 LLM 设计的，底层逻辑跟 vLLM/TGI 的 Continuous Batching 基本一致。结合 vLLM Backend------Triton 现在做 LLM 推理的性能跟裸 vLLM 几乎相同。

Model Ensemble：把多个模型串成 Pipeline

真实生产场景里，LLM 调用往往不是"单一模型"------是多个模型串行协作：

csharp 复制代码

用户输入："帮我查一下这个订单的状态"
     │
     ▼
  [BERT: 意图识别]  →  "query_order"  (JSON 分类结果)
     │
     ▼
  [Python Code: 查询数据库]
     │
     ▼
  [LLM: 基于订单数据生成回复]  →  "您的订单已于 7月28日发货，预计..."

Triton 的 Model Ensemble 让你把这个流程声明为 DAG：

protobuf 复制代码

# ensemble/config.pbtxt
name: "order_query_pipeline"
platform: "ensemble"
max_batch_size: 0

ensemble_scheduling {
  step [
    {
      model_name: "bert-intent-classifier"
      model_version: 1
      input_map { key: "text" value: "user_query" }
      output_map { key: "intent" value: "classified_intent" }
    },
    {
      model_name: "llm-response-generator"
      model_version: 1
      input_map { 
        key: "prompt" value: "classified_intent"
      }
      output_map { key: "response" value: "final_response" }
    }
  ]
}

所有请求按 DAG 路径自动路由------中间步骤的 Tensor 在 GPU 显存中零拷贝传递。客户端只看到一次请求一次响应，不需要知道中间有多少个模型。

跟 vLLM/TGI 比，Triton 真正不同的点

维度	vLLM / TGI	Triton
定位	LLM 专用推理	通用模型推理平台
模型类型	Transformer 文本生成	任何模型（LLM/CV/NLP/Tab/树模型）
后端	自研 CUDA Kernel	可插拔 Backend 架构
Pipeline	需要外部编排	内置 Model Ensemble
量化支持	AWQ/GPTQ	TensorRT-LLM（量化 + Kernel 编译优化）
部署复杂度	pip install + 一行启动	需要配置文件 + 模型仓库目录
LLM 纯推理性能	极致	跟 vLLM Backend 持平

关键结论：纯 LLM 推理选 vLLM 或 TGI。生产环境需要同时服务多种模型 + Pipeline 编排------Triton 是一站式方案。

TensorRT-LLM：Triton 的"核武器"

Triton 有一个特殊 Backend 叫 TensorRT-LLM------NVIDIA 的 LLM 专用推理库。它把模型编译成高度优化的 CUDA 图：

yaml 复制代码

HuggingFace 模型 (PyTorch)
        │
        ▼
  TensorRT-LLM 编译
   - Kernel Fusion: 把多个小操作（LayerNorm + Attention + Residual）融合为一个大 Kernel
   - Graph Optimization: 消除中间 Tensor 的内存分配
   - FP8 / INT4 量化
   - 针对特定 GPU 架构（H100/A100）的指令级优化
        │
        ▼
  .engine 文件（GPU 优化好的计算图）
        │
        ▼
  Triton Server + TensorRT-LLM Backend → 推理延迟比 vLLM 通常再低 20-30%

代价：编译过程慢（一次 30-60 分钟），模型更新频繁的话不划算。适合：模型稳定、对延迟极度敏感的场景。

一句话总结

Triton Inference Server 是 NVIDIA 的通用的推理服务框架------它不跟 vLLM/TGI 在"LLM 推理性能"上竞争，而是在"一个平台统一服务所有模型"这个维度上碾压。Backend 抽象让它可以加载 PyTorch/TensorRT/ONNX/Python/树模型------Model Ensemble 让你声明式地把多个模型串成 DAG------Dynamic Batching 跟 vLLM 的 Continuous Batching 等效。如果你只跑 LLM，用 vLLM。如果你跑 LLM + 多个辅助模型，用 Triton。

下一篇：KServe------Kubernetes 原生的模型推理平台。当你把模型推理平台化、多租户化，你需要的不止是"一个服务进程"------你需要自动扩缩容、金丝雀发布、可观测性------KServe 把 Triton/vLLM/TGI 打包进了 Kubernetes。