TensorRT-LLM
TensorRT-LLM 是 NVIDIA 的 LLM 推理栈。在本 wiki 的论文语料中，它主要扮演三种角色：工业级 serving 基线、NVIDIA GPU 专用优化的代表，以及需要额外适配才能接入新 kernel、通信或内存机制的 runtime。
是什么
TensorRT-LLM 把模型执行、量化、GPU kernel、并行和 serving runtime 放在同一套 NVIDIA 软件栈中。论文常把它与 vLLM、SGLang 并列，但三者的可改造边界不同：TensorRT-LLM 往往有较强的现成 kernel 和 Tensor Parallel 路径，外部研究原型则更常直接修改 vLLM/SGLang 的 scheduler、KV manager 或算子入口。
这里的页面不是产品手册，也不试图列出 TensorRT-LLM 的全部版本功能。下面只综合引用本页的论文实际测到或明确说明的行为；不同版本、模型、GPU 和配置之间不能互相代替。
关键观察 / 隐含假设
-
它是强基线，但“强”取决于目标指标。 SuperInfer-MLSys26 在 GH200 上观察到 TensorRT-LLM 的 TBT 表现较强，高请求率下 TTFT 则因 lazy preempt 退化。BatchGen-OSDI26 在 16×H20、8K 输入/2K 输出的离线 MoE 批推理中比它快 10%，但 BatchGen 优化的是整批完成时间，不是交互式 TTFT/TPOT。
- 隐含假设：比较双方采用接近的模型、精度、并行度、batch 和 SLO 口径。把 batch inference 的 BCT 结果直接解释为在线 serving 胜负是不成立的。
-
原生精度支持会改变比较含义。 ADAngel-OSDI26 在 Orin 上用 W4A8 任意精度映射，相对 TensorRT-LLM 的 W8A8/W4A16 路径取得更低 TTFT 或更高 decode 吞吐。这个结果说明固定 precision portfolio 会留下优化空间，也说明两方并非始终是等精度比较，不能据此推出同等模型质量下的纯 runtime 加速。
-
kernel 很快不代表长上下文数据已就绪。 Strata-OSDI26 把 GPU、CPU 和 SSD 中的分层 KV cache 重新布局，并按“何时可用”调度请求；在其长上下文配置中相对 TensorRT-LLM-HiCache 吞吐最高提高 3.75 倍。差距主要来自碎片传输、布局转换和 I/O bubble，而不是简单替换一个 Attention kernel。
- 隐含假设：工作负载确实有 prefix/context reuse，并使用论文测试的 H200/H20、缓存层级和延迟口径。无复用或 decode 主导时，收益会明显缩小。
-
低延迟 TP 不会自动开启通信重叠。 TokenWeave-MLSys26 把 TensorRT-LLM、vLLM 和 SGLang 都列为默认不对小 batch 做 compute–communication overlap 的 serving 引擎，因为拆分 GEMM 的成本可能高于隐藏的 AllReduce。它在 8×H100 上通过 smart splitting 与 AllReduce–RMSNorm 融合展示另一设计点；这支持“小 batch 需要专门 overlap 机制”，不等于测得所有 TensorRT-LLM 版本都具有同样的 9%–23% 通信占比。
-
外部优化需要明确的接入面。 FlashInfer-Bench-MLSys26 的
apply()依赖调用经过 FlashInfer；论文把 TensorRT-LLM 列为未来适配目标，而非已验证的零侵入集成。fabric-lib-MLSys26 同样把它列为 RDMA P2P 的潜在 serving 集成栈，但实验细节主要来自内部 engine，不能把 fabric-lib 的全部结果自动归给 TensorRT-LLM。- 隐含假设：系统愿意暴露 operator、KV layout、memory allocator 和 scheduling hook。越一体化的 runtime，现成性能可能越好，深度替换的工程成本也越高。
在设计空间中的位置
作为基线
TensorRT-LLM 适合回答“针对 NVIDIA GPU 充分优化的现成推理栈能做到什么”。一个公平实验至少应写明：版本、GPU、模型、dtype/量化、TP/PP/EP、KV dtype、batch、CUDA Graph、chunked prefill、prefix cache，以及测的是 TTFT、TBT/TPOT、throughput 还是 BCT。
作为集成平台
论文中的新机制大致分三类：
- 算子级：任意精度 GEMM、通信—归一化融合，可以通过 plugin 或新 kernel 接口接入，但要验证 shape coverage 与数值一致性；
- 内存级：block-first KV、GPU/CPU/SSD 层级缓存、主动 rotation，会改变 allocator、block table 和 Attention layout，通常不是简单替换函数；
- 调度/通信级：sequence coroutine、P2P KV/权重传输、SLO-aware preemption，会改变 request state 和控制面，需要 runtime 原生配合。
越靠后，论文只说“可集成”而没有给代码和端到端结果时，就越应该把它视为未来工作，而不是已经实现的兼容能力。
证据边界
- ADAngel-OSDI26 的 TensorRT-LLM 基线精度与 ADAngel 不完全一致；headline speedup 同时包含表示宽度和 kernel/runtime 差异。
- BatchGen-OSDI26 只在一项 16×H20 离线配置中直接报告对 TensorRT-LLM 的 10% BCT 优势；大规模主对比主要是调优后的 SGLang groups。
- Strata-OSDI26 比较的是 TensorRT-LLM 0.17 HiCache，并且不同系统 page size 不同；最高 3.75 倍不能外推到普通短上下文 serving。
- SuperInfer-MLSys26 的结论来自 GH200、统一 5 秒 TTFT/100 ms TBT SLO 和特定 trace；其 block-first layout、RotaSched 与 DuplexKV 未在 TensorRT-LLM 内实现。
- TokenWeave-MLSys26 的端到端实现基于 vLLM V1，不是 TensorRT-LLM；对 TensorRT-LLM 的描述用于解释行业默认策略。
- FlashInfer-Bench-MLSys26 和 fabric-lib-MLSys26 都把 TensorRT-LLM 作为重要集成对象，但没有完成同等深度的公开端到端适配验证。
研究判断
TensorRT-LLM 在论文中最有价值的作用，不是充当一个固定数字，而是迫使新系统面对成熟 NVIDIA 路径。若新工作只在自建轻量 runtime 中领先，却没有解释 TensorRT-LLM 的 precision、fusion、parallelism 和 memory policy，结论通常不完整。
反过来，TensorRT-LLM 的强 kernel 也不能替代跨层设计。OSDI/MLSys 2026 的证据反复表明，长上下文缓存、batch completion、主动 KV rotation、低 bit 映射和 P2P 通信都可能把瓶颈移出单个 kernel。更可信的比较应分别报告“现成配置能做什么”“为了接入新机制改了什么”“收益来自哪一层”。
引用本实体的论文
- ADAngel-OSDI26 — 任意精度 mpGEMM 对照；需注意 baseline 精度不完全相同。
- BatchGen-OSDI26 — 离线 MoE batch inference 对照；一项 16×H20 配置 BCT 快 10%。
- Strata-OSDI26 — 长上下文分层 KV cache 对照；最高吞吐差距来自布局、I/O 与调度协同。
- SuperInfer-MLSys26 — GH200 SLO baseline；TBT 强，高负载 TTFT 受 lazy preempt 影响。
- TokenWeave-MLSys26 — 将其列为默认不开小 batch TP overlap 的 production engine 代表。
- FlashInfer-Bench-MLSys26 — FlashInfer
apply()尚需 TensorRT-LLM 专门适配。 - fabric-lib-MLSys26 — RDMA P2P 的候选 serving 集成栈，公开端到端适配证据有限。