8. 企业生产实践

Docker 部署

NVIDIA 提供官方 NGC 镜像，是生产部署的首选：

docker run --gpus all --rm -p 8000:8000 -p 8001:8001 -p 8002:8002 \
  -v $(pwd)/model_repository:/models:ro \
  nvcr.io/nvidia/tritonserver:26.09-py3 \
  tritonserver --model-repository=/models

端口说明：

• 8000：HTTP/REST。
• 8001：gRPC。
• 8002：Metrics（Prometheus）。

对于 LLM 场景，通常使用带 backend 的专用镜像：

• nvcr.io/nvidia/tritonserver:26.07-trtllm-python-py3：含 TensorRT-LLM backend。
• nvcr.io/nvidia/tritonserver:26.07-vllm-python-py3：含 vLLM backend。

注意（2026）：从 26.08 起，NGC 不再随月度发布提供 TensorRT-LLM backend 容器镜像；TRT-LLM 用户需要自行基于 tensorrtllm_backend 仓库构建，或评估 NVIDIA Dynamo。另外 26.09 起镜像基于 CUDA 13.4.1，并初步支持 Rubin GPU 架构，老驱动（R555 及更早）不在前向兼容范围内，升级前需核对驱动版本。

安全（2026）：NVIDIA 2026 年 8 月安全公告修复了多个高危漏洞（含 CVE-2026-47627 路径穿越，CVSS 9.8，影响 26.05 及更早版本），生产环境务必升级到 26.06 以上，且不要把 Triton 的 HTTP/gRPC 端口直接暴露到不可信网络。

Kubernetes / KServe 集成

KServe 把 Triton 作为 runtime 之一，通过 InferenceService 直接部署：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: my-model
spec:
  predictor:
    triton:
      storageUri: s3://my-bucket/model-repository
      runtime: kserve-tritonserver
      env:
        - name: OMP_NUM_THREADS
          value: "1"

生产建议：

• 使用 KServe 的 storageUri 把模型仓库放在 S3 / GCS，Triton 启动时自动拉取。
• 配置 HPA 基于 GPU 利用率或自定义 metrics（如 queue size）自动扩缩。
• 为 Triton 容器配置 resources.limits.nvidia.com/gpu。
• 使用 readinessProbe 与 livenessProbe 检查 /v2/health/ready。
• KServe 还提供了面向 LLM 的 LLMInferenceService CRD（可对接 vLLM / Triton 等 runtime）；纯传统模型继续用 InferenceService + Triton runtime 即可。
• 注意 Knative scale-to-zero 对 LLM 会带来明显的冷启动延迟，LLM 服务通常禁用 scale-to-zero，改用电厂式常驻副本 + 基于 KV cache / decode 吞吐信号的扩缩容。

TensorRT-LLM Backend 配置要点

TensorRT-LLM backend 的 model repository 通常包含：

tensorrt_llm/
├── config.pbtxt
└── 1/
    └── config.json          # 构建期生成的引擎配置

关键 config.pbtxt 参数：

backend: "tensorrtllm"
max_batch_size: 64
input [
  { name: "input_ids" data_type: TYPE_INT32 dims: [-1] }
]
output [
  { name: "output_ids" data_type: TYPE_INT32 dims: [-1] }
]
parameters: {
  key: "max_beam_width"
  value: { string_value: "1" }
}
parameters: {
  key: "max_tokens_in_paged_kv_cache"
  value: { string_value: "8192" }
}

注意事项：

• 引擎文件需要在相同 GPU 架构上构建。
• TensorRT-LLM backend 内部已经实现了 In-flight Batching，因此 Triton 层通常不需要再开 dynamic batching。
• 通过 parameters 控制 KV cache 大小、beam width、end id 等。
• Disaggregated serving：TensorRT-LLM backend 支持分离部署 context（prefill）与 generation（decode）worker，通过 kv_cache_transfer_lib（如 NIXL、UCX）传输 KV cache，由 orchestrator 统一调度；这是单机内做 prefill/decode 分离的方式。跨节点、大规模分离部署应改用 NVIDIA Dynamo。
• 容器现状（2026）：26.08 起 NGC 不再提供 TRT-LLM backend 容器；同时 backend 中纯 Python 的 gpt runtime 已被废弃（只剩 C++ backend），TensorRT-LLM 自身也在向 PyTorch 执行后端收敛。新项目建议评估 Dynamo 或 vLLM backend 路线。

vLLM Backend 配置要点

vLLM backend 把 vLLM 的 LLMEngine 封装为 Triton backend：

backend: "vllm"
max_batch_size: 64
input [
  { name: "text_input" data_type: TYPE_STRING dims: [-1] }
]
output [
  { name: "text_output" data_type: TYPE_STRING dims: [-1] }
]
parameters: {
  key: "model"
  value: { string_value: "meta-llama/Meta-Llama-3-8B-Instruct" }
}
parameters: {
  key: "gpu_memory_utilization"
  value: { string_value: "0.9" }
}

vLLM backend 与 TensorRT-LLM backend 的关键区别：

维度	TensorRT-LLM backend	vLLM backend
构建方式	需要提前 build engine	直接加载 HuggingFace checkpoint
性能	NVIDIA GPU 上通常更优	通用场景高吞吐
灵活性	受支持的模型/算子约束	更高，支持新模型更快
适用场景	性能敏感、模型固定的生产环境	快速上线、模型迭代频繁

多模型并发与资源隔离

在一张 GPU 上同时部署多个模型时，需要注意：

• 显存预算：LLM 模型会占用大量显存，给其他模型预留空间。
• Instance Group：为每个模型设置合理的实例数，避免互相抢占。
• Rate Limiter：限制每个模型占用的资源配额，防止一个模型把 GPU 占满。
• MPS（Multi-Process Service）：在 A100/H100 上可以通过 MPS 提高多模型并发效率。

模型热更新

Triton 支持两种热更新模式：

1. Poll 模式：

   tritonserver --model-repository=/models --model-control-mode=poll --repository-poll-secs=30

   Triton 每 30 秒扫描一次仓库，自动加载新模型、卸载删除的模型、更新修改的版本。

2. Explicit 模式：

   tritonserver --model-repository=/models --model-control-mode=explicit

   通过 HTTP/gRPC API 显式加载/卸载：

   curl -X POST http://localhost:8000/v2/repository/models/my_model/load
   curl -X POST http://localhost:8000/v2/repository/models/my_model/unload

生产推荐 explicit 模式，避免 poll 带来的意外变更。

A/B 测试与金丝雀

Triton 通过版本控制支持简单的 A/B 测试：

my_model/
├── config.pbtxt
├── 1/          # 旧版本
└── 2/          # 新版本

• 默认流量到最新版本（2）。
• 通过 /v2/models/my_model/versions/1/infer 保留旧版本入口。

更复杂的金丝雀需要在 Triton 前置一个网关（如 Nginx、Envoy、KServe Transformer）按权重分发流量。

监控与告警

Prometheus 抓取

scrape_configs:
  - job_name: triton
    static_configs:
      - targets: ["triton:8002"]

关键告警规则

指标	告警条件
nv_inference_queue_duration_us > 100ms	batch 没凑够或实例不足
nv_gpu_memory_used_bytes / nv_gpu_memory_total_bytes > 0.9	显存不足
nv_inference_compute_infer P99 > SLA	推理延迟超标
nv_inference_count 突降	流量异常或模型失败
rate(nv_inference_exec_count[5m]) == 0	某个模型无请求，可能配置错误

Grafana Dashboard

NVIDIA 提供官方 Triton Grafana dashboard 模板，可直接导入。

常见踩坑

1. 输入 shape 不匹配：

   • 客户端发送的 shape 必须与 config.pbtxt 一致，包括 batch 维度。
   • 使用 -1 表示可变维度时，仍需保证同一个 batch 内 shape 兼容。

2. Backend 共享库缺失：

   • 启动时报 unable to load backend，通常是镜像未包含对应 backend。
   • LLM 场景务必使用 trtllm 或 vllm 专用镜像。

3. 显存 OOM：

   • LLM 的 KV cache 会随 batch size 与序列长度增长，需要预留足够余量。
   • 通过 gpu_memory_utilization（vLLM）或 max_tokens_in_paged_kv_cache（TRT-LLM）控制。

4. Dynamic Batching 与 LLM backend 冲突：

   • vLLM / TensorRT-LLM backend 内部已经有 continuous/in-flight batching。
   • 在 Triton 层再开 dynamic batching 可能导致 batch 被错误拆分，通常建议 max_batch_size: 0 或关闭 dynamic batching。

5. 模型版本未更新：

   • 新模型放入 2/ 目录后，Triton 不会自动切换，除非启用 poll 或调用 load API。

6. Python backend 依赖冲突：

   • Python backend 运行在独立子进程中，依赖通过 parameters: { key: "EXECUTION_ENV_PATH" value: { string_value: "/path/to/env.tar.gz" } } 指定。

本章小结

生产部署 Triton 的核心是：选对镜像、写好 config.pbtxt、合理配置 instance group 与调度策略、做好监控与热更新。对于 LLM 场景，特别要注意 LLM backend 内部已经有 batching，不要在 Triton 层重复启用 dynamic batching，同时要严格控制显存预算。

参考来源

• Triton NGC Container
• Triton User Guide — Deploying on Kubernetes
• Triton TensorRT-LLM Backend
• TensorRT-LLM Disaggregated Serving
• Triton vLLM Backend
• KServe Triton Runtime
• KServe LLMInferenceService 入门
• NVIDIA Dynamo-Triton 官方主页
• Triton Metrics