适用对象把 PyTorch、ONNX、TensorRT、LLM 或多模态模型部署到生产环境的工程团队。核心结论Triton 解决“如何稳定服务”TensorRT 解决“如何跑得更快”TensorRT-LLM 与 Dynamo 解决“大模型如何高吞吐、低尾延迟、可扩展地跑”。真正有效的优化不是单点开关而是围绕 SLA 的端到端闭环。第 0 层30 秒理解服务化框架可以理解为 AI 推理的智能工厂Triton Inference Server是调度系统统一 HTTP/gRPC 接口、模型版本、动态批处理、并发实例和监控指标。TensorRT是编译优化器把模型图编译成面向 NVIDIA GPU 的高效执行计划利用融合、精度选择、内核选择和动态形状 Profile。TensorRT-LLM是面向 LLM 的专用推理栈重点处理 KV Cache、Paged Attention、in-flight batching、投机解码、量化和多 GPU 通信。Dynamo是新一代分布式推理服务层更适合把 prefill、decode、KV Cache、路由和分布式扩展组合成大模型服务系统。简化公式线上收益 编译收益 × 调度收益 × 内存收益 × SLA 约束下的稳定性 端到端延迟 排队时间 批处理等待 数据搬运 推理执行 后处理 有效吞吐 成功请求数 / 时间窗口而不是峰值 benchmark 数字不要只问“TensorRT 能提速几倍”。生产环境真正该问在 p99 延迟、错误率、成本、回滚能力都满足要求时最大稳定吞吐是多少第 1 层基础概念为什么需要服务化框架训练框架擅长表达模型和训练过程但线上推理还需要解决这些问题问题典型表现服务化优化手段框架碎片化PyTorch、ONNX、TensorRT、Python 预处理各自部署Triton 多后端统一服务GPU 利用率低单请求推理、批量不足、CPU/GPU 同步频繁动态批处理、并发实例、异步客户端尾延迟高大小请求混跑长序列阻塞短序列优先级队列、请求分桶、prefill/decode 分离显存浪费KV Cache 碎片、固定大 shape、重复加载模型Paged KV Cache、动态 shape Profile、多实例规划运维困难模型升级不可控缺少指标模型仓库、版本策略、Prometheus metrics、灰度发布推理服务化栈从请求进来到结果返回优化链路通常是客户端并发 - 网关限流与路由 - Triton 调度、批处理、实例管理 - TensorRT / TensorRT-LLM 执行 - GPU 显存、Tensor Core、通信栈 - 指标观测、压测、回滚Triton 的核心能力先把 Triton 看成一条请求流水线客户端请求进入统一入口后Triton 负责凑批、排队、选择模型实例再分发给 TensorRT、ONNX Runtime、Python backend 等后端执行。Triton 的价值不是“替代 TensorRT”而是把不同模型和后端稳定地组织成服务支持 TensorRT、ONNX Runtime、PyTorch、Python backend 等多种后端。支持模型仓库与版本化部署。支持动态批处理、sequence batching、ensemble pipeline。支持 HTTP/gRPC 客户端、共享内存、Prometheus 指标。可以和 Model Analyzer、Perf Analyzer 组成调参闭环。基础配置示例name: resnet50_trt platform: tensorrt_plan max_batch_size: 32 input [ { name: input data_type: TYPE_FP32 dims: [ 3, 224, 224 ] } ] output [ { name: output data_type: TYPE_FP32 dims: [ 1000 ] } ] instance_group [ { count: 2 kind: KIND_GPU gpus: [ 0 ] } ] dynamic_batching { preferred_batch_size: [ 4, 8, 16, 32 ] max_queue_delay_microseconds: 50000 }关键点max_batch_size要和 TensorRT engine 的 batch 语义匹配。preferred_batch_size不是越大越好必须用 p95/p99 延迟约束验证。instance_group.count太大可能抢显存和上下文资源太小可能吞吐不足。TensorRT 的核心能力TensorRT 的优化发生在“构建 engine”阶段。输入模型、动态形状范围、精度策略和 workspace 约束共同决定最终 plan 文件的性能上限。TensorRT 把模型从通用计算图变成面向硬件的执行计划。主要优化包括图优化与层融合。kernel auto-tuning。FP32、TF32、FP16、BF16、INT8、FP8 等精度路径具体可用性取决于 GPU 架构和算子。动态形状 optimization profile。Plugin 扩展不支持或需要自定义优化的算子。TensorRT 10 之后 API 变化较大到 TensorRT 11.x 语境下应优先使用更现代的写法importtensorrtastrt loggertrt.Logger(trt.Logger.INFO)buildertrt.Builder(logger)networkbuilder.create_network(1int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))parsertrt.OnnxParser(network,logger)withopen(model.onnx,rb)asf:ifnotparser.parse(f.read()):foriinrange(parser.num_errors):print(parser.get_error(i))raiseRuntimeError(ONNX parse failed)configbuilder.create_builder_config()# TensorRT 10 推荐用 memory pool limit 替代旧式 max_workspace_size。config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE,4*1024*1024*1024)ifbuilder.platform_has_fast_fp16:config.set_flag(trt.BuilderFlag.FP16)profilebuilder.create_optimization_profile()profile.set_shape(input,min(1,3,224,224),opt(8,3,224,224),max(32,3,224,224),)config.add_optimization_profile(profile)serialized_enginebuilder.build_serialized_network(network,config)withopen(model.plan,wb)asf:f.write(serialized_engine)第 2 层15 分钟掌握工程配置动态批处理吞吐和延迟的第一处平衡动态批处理的收益来自把多个小请求拼成一个 GPU 更喜欢的大请求。但等待凑批会增加延迟。推荐起点dynamic_batching { preferred_batch_size: [ 4, 8, 16 ] max_queue_delay_microseconds: 20000 preserve_ordering: false }调参方法现象优先检查调整方向GPU 利用率低实际 batch 分布增加preferred_batch_size或队列等待p99 延迟高队列等待和长请求降低max_queue_delay_microseconds做请求分桶吞吐上不去实例数和客户端并发增加并发、异步请求、适当增加实例显存吃紧engine profile 和实例数减少实例或缩小 max shape实例数不是越多越好同一 GPU 上多个模型实例可以提升小模型吞吐但也会消耗显存、CUDA context 和调度资源。经验规则CV 小模型可以从count: 2或count: 4开始测。大 CNN、Transformer encoder先测count: 1与count: 2。LLM多数场景不要盲目用 Triton 多实例复制大模型应优先考虑 TensorRT-LLM 的 batching、KV Cache 和并行策略。动态形状Profile 要贴近真实流量TensorRT 动态 shape 的核心不是“允许任意 shape”而是给优化器明确范围profile.set_shape(tokens,min(1,128),opt(8,1024),max(16,4096),)常见错误max设置过大导致 engine 为极端情况保守优化。opt不代表真实主流输入线上常见 shape 性能差。一个 Profile 覆盖所有请求短请求和长请求互相拖累。更稳妥做法是按流量分桶profile_short: min(1,128), opt(8,512), max(16,1024) profile_medium: min(1,512), opt(4,2048), max(8,4096) profile_long: min(1,2048), opt(2,8192), max(4,16384)精度选择先 FP16/BF16再严肃评估 INT8/FP8精度不是单纯的性能开关而是精度、速度、显存、可维护性的组合选择。精度适用场景注意事项FP32 / TF32精度基线、敏感模型成本高常用于对照FP16CV、ASR、LLM 常见起点需要检查溢出、LayerNorm、Softmax 稳定性BF16LLM、训练迁移友好依赖硬件支持速度未必总优于 FP16INT8高吞吐、成本敏感需要 PTQ/QAT、校准集和回归测试FP8Hopper/Blackwell 等新硬件上的高性能路径工具链和模型支持要逐项验证INT4 / Weight-onlyLLM 权重量化重点看困惑度、长文本质量和特定任务退化实用顺序建立 FP32 或训练框架基线。转 FP16/BF16验证精度和 p99。对吞吐或成本敏感模型做 INT8/FP8/INT4 实验。用真实业务样本回归不只看公开 benchmark。第 3 层30 分钟技术深度LLM 服务真正的瓶颈在 KV Cache 和调度LLM 推理分两个阶段Prefill处理 prompt计算量大适合大 batch。Decode逐 token 生成访存和 KV Cache 管理更关键。优化方向因此不同阶段主要瓶颈优化方法Prefill算力、长 promptFlashAttention、FP8/FP16、prompt 分桶、大 batchDecodeKV Cache、访存、调度Paged KV Cache、in-flight batching、speculative decoding多用户混合长短请求干扰prefill/decode 分离、优先级调度、请求准入控制TensorRT-LLM 的核心价值就在这里它不是普通 TensorRT 的简单包装而是围绕 LLM 的生成式推理路径重做了调度和算子栈。Triton TensorRT-LLM 的部署思路典型组合Triton - TensorRT-LLM backend - engine files - tokenizer / postprocess - batching scheduler - KV Cache manager生产建议不要把所有请求塞进同一个队列至少按输入长度或预估输出长度分桶。对短请求给更严格的排队上限避免被长 prompt 拖住。配置最大输入长度、最大输出长度、最大并发请求防止显存被异常请求打满。对 streaming 输出单独测首 token 延迟 TTFT 和 token 间隔 ITL。关键指标TTFT: time to first token ITL: inter-token latency TPOT: time per output token TPS: tokens per second p99 latency: 尾部体验 KV cache hit / usage: 显存效率 request admission reject rate: 过载保护效果Dynamo面向分布式 LLM serving 的新层当模型变大、流量变复杂时单个 Triton 实例或单机 TensorRT-LLM 往往不够。Dynamo 的定位是把大模型推理拆成更可组合的分布式服务系统把 prefill 和 decode 作为不同资源池调度。更精细地管理 KV Cache 和请求路由。支持多节点、多 GPU 的扩展。更适合构建“高吞吐 低尾延迟 弹性扩缩”的 LLM 服务。如果只是部署一个中小 CV 模型用 Triton TensorRT 就够了。如果是 70B 级别 LLM、多租户、长上下文、streaming、大并发才值得认真评估 Dynamo 或同类分布式 serving 栈。Ensemble把预处理、模型、后处理放到服务图里Triton ensemble 可以把多个步骤组合成一个服务decode image - resize/normalize - TensorRT model - NMS/postprocess优点客户端更简单。多步骤指标更统一。可以减少重复网络往返。风险Python backend 后处理太慢会成为瓶颈。每一步数据拷贝都可能吃掉 TensorRT 的收益。出错定位要有 per-step metrics。经验高频路径上的预处理和后处理尽量做成 GPU 侧或 C 后端Python backend 适合快速集成但要压测后再上核心链路。第 4 层60 分钟前沿与系统化调优用 SLA 反推配置而不是凭经验写配置先定义 SLA图像分类 p99 80 ms throughput 3000 rps / GPU error rate 0.1% LLM Chat TTFT p95 800 ms ITL p95 40 ms decode TPS 尽可能高 过载时优雅拒绝而不是全局雪崩然后设计压测矩阵维度示例batch1、4、8、16、32queue delay0、5ms、20ms、50msinstance count1、2、4precisionFP16、BF16、INT8、FP8shape profileshort、medium、long并发1、8、32、128、512用 Perf Analyzer 测单模型用 Model Analyzer 搜配置再用真实网关压测复现业务流量。一个可执行的优化闭环1. 建立基线原始 PyTorch / ONNX Runtime / 未优化 Triton。 2. 转 TensorRT固定 shape FP16获得第一版 engine。 3. 加 Triton 动态批处理测吞吐、p50、p95、p99。 4. 加动态 shape profile覆盖真实输入分布。 5. 调实例数观察 GPU 利用率、显存、上下文切换。 6. 尝试 INT8 / FP8 / weight-only做业务回归。 7. 上灰度小流量验证指标和错误。 8. 固化监控延迟、吞吐、GPU、显存、队列、失败率。 9. 定期回看流量分布变了就重新编译或调度。诊断表看到现象后先查什么现象可能原因处理优先级GPU 利用率低客户端并发不足、batch 太小、CPU 预处理慢先看实际 batch 和 CPU 火焰图平均延迟低但 p99 高长短请求混跑、队列等待过大、过载分桶、优先级、准入控制TensorRT 提速不明显shape 不匹配、算子未融合、数据搬运占比高看 profile不只看总耗时显存突然打满max shape 过大、实例过多、KV Cache 无上限限制请求、减少实例、分页缓存INT8 精度掉太多校准集不代表线上、敏感层被量化增加校准集、混合精度、QATStreaming 首 token 慢prefill 排队或长 prompt 堵塞prefill 分桶、prefill/decode 解耦版本更新带来的实践变化截至 2026-06-22需要特别注意这些变化Triton最新公开 release 线已到 26.05 / 2.69.0核心仍是多后端服务、动态批处理、模型管理和指标体系。配置写法要以当前镜像文档为准。TensorRT11.x 已发布旧文章中的max_workspace_size、隐式 batch、部分弱类型 API 写法应更新新项目应优先使用 explicit batch、serialized network、memory pool limit、强类型/显式精度约束等现代接口。TensorRT-LLM1.x 系列成为 LLM 推理优化重点围绕 Paged KV Cache、in-flight batching、量化、speculative decoding 和多 GPU 扩展演进。Dynamo已经成为 NVIDIA 面向分布式 LLM serving 的重要新栈适合评估大规模 prefill/decode 分离和 KV Cache 路由。实战模板Triton 服务配置起点name: encoder_fp16 platform: tensorrt_plan max_batch_size: 16 input [ { name: input_ids data_type: TYPE_INT32 dims: [ -1 ] } ] output [ { name: embeddings data_type: TYPE_FP32 dims: [ 768 ] } ] instance_group [ { count: 2 kind: KIND_GPU gpus: [ 0 ] } ] dynamic_batching { preferred_batch_size: [ 4, 8, 16 ] max_queue_delay_microseconds: 20000 }压测命令思路perf_analyzer\-mencoder_fp16\-ulocalhost:8001\-igrpc\--concurrency-range1:128:8\--measurement-mode time_windows\--measurement-interval5000看结果时优先关注server queue 时间是否过高。compute input / infer / output 哪一段占主导。并发增加后 p99 是否突然劣化。GPU 利用率是否随吞吐增长。TensorRT 构建检查清单[ ] ONNX 已 simplify并保留必要动态轴 [ ] min/opt/max shape 来自真实流量 [ ] workspace memory pool 足够但不过度 [ ] FP16/BF16 精度已回归 [ ] INT8/FP8 有校准集和业务回归 [ ] engine 与目标 GPU 架构匹配 [ ] 记录构建日志、TensorRT 版本、CUDA 版本、driver 版本 [ ] engine 可回滚旧版本未立即删除常见误区误区 1更大的 batch 一定更好更大的 batch 通常提升吞吐但会增加排队等待、显存占用和尾延迟。线上优化应找 SLA 内的最大稳定 batch而不是 benchmark 峰值 batch。误区 2FP16 一定比 FP32 快多数 GPU 上 FP16 很有价值但如果瓶颈在 CPU 预处理、数据搬运、后处理或小算子调度FP16 的收益会被掩盖。误区 3INT8 只会损失 1% 精度INT8 精度损失取决于模型结构、校准集、任务指标和敏感层。分类 top-1 小幅下降不代表搜索、推荐、RAG rerank 或长文本生成质量也安全。误区 4Triton 配好就不需要应用层限流服务框架不能替代容量治理。线上必须有超时、重试预算、限流、熔断、准入控制和降级策略。最终建议如果你从零开始做生产部署推荐路径是中小模型ONNX - TensorRT FP16 - Triton 动态批处理 - Perf Analyzer 调参 - Prometheus 监控。LLM 单机或单节点TensorRT-LLM - Triton backend - 重点优化 TTFT、ITL、KV Cache 和 batching。大规模 LLM评估 Dynamo 或同类分布式 serving 栈把 prefill/decode、KV Cache、路由和多 GPU 扩展作为系统问题处理。所有场景用真实流量压测围绕 p95/p99、吞吐、错误率、成本和回滚能力做决策。服务化优化的本质不是“打开某个加速开关”而是让模型、硬件、调度、内存和业务 SLA 对齐。Triton 负责把服务组织好TensorRT 负责把单次执行压榨到位TensorRT-LLM 与 Dynamo 负责让大模型在复杂流量下仍然可控。把这几层串成闭环才是 2026 年推理服务化的核心能力。参考资料NVIDIA Triton Inference Server 文档与 Release NotesNVIDIA TensorRT 11.x 文档与 Release NotesNVIDIA TensorRT-LLM 文档NVIDIA Dynamo 文档Triton Perf Analyzer 与 Model Analyzer 文档