从 1,227 到 2,941 tok/s:快速上手 TensorRT-LLM 的完整指南

📅 2026/8/24 8:44:38
从 1,227 到 2,941 tok/s:快速上手 TensorRT-LLM 的完整指南
从 1,227 到 2,941 tok/s快速上手 TensorRT-LLM 的完整指南【免费下载链接】TensorRT-LLMTensorRT LLM provides users with an easy-to-use Python API to define Large Language Models (LLMs) and supports state-of-the-art optimizations to perform inference efficiently on NVIDIA GPUs. TensorRT LLM also contains components to create Python and C runtimes that orchestrate the inference execution in a performant way.项目地址: https://gitcode.com/GitHub_Trending/te/TensorRT-LLM单卡解码 Llama-70B 时瓶颈几乎从来不在算力而在显存带宽——每个 token 都要把 KV cache 从显存搬一遍GPU 反而在空转。NVIDIA 开源的推理引擎 TensorRT-LLM就是冲着这类瓶颈来的一个专门针对解码阶段重写的注意力内核实测能把同硬件下的输出吞吐推到原来的 2.4 倍。这篇文章带你把它的门道和最短跑通路径一次讲清。这张曲线图对比了 Llama-2 70B 开启 XQA 前后的表现横轴是吞吐纵轴是每个输出 token 的耗时。开启后曲线整体右移——在几乎不增加单用户延迟的前提下单位时间能处理的请求量明显变多。TensorRT-LLM 是什么给 NVIDIA GPU 上 LLM 推理榨带宽的开源引擎一句话定位TensorRT-LLM 是 NVIDIA 的开源推理优化引擎负责把 LLM 和视觉生成模型在 NVIDIA GPU 上跑得更快、更省。它的价值分三层一层是手写的 GPU 内核覆盖注意力、矩阵乘、MoE 这些高频算子一层是运行时调度与内存管理包括 KV cache 管理、CUDA Graph、重叠调度一层是 PyTorch 原生的模块化框架允许你直接改它的运行时或者加自己的模型。什么时候该选它三种情况多卡在线服务追求每卡吞吐和 TTFT 的平衡低延迟场景对单请求的首 token 时间有硬性要求推理 DeepSeek 这类 256 专家的 MoE 模型需要专门的路由与通信优化。亮点拆解三个反直觉的优化解码带宽瓶颈XQA 内核如何把 70B 吞吐翻倍问题解码阶段是典型的内存受限负载batch 一大注意力计算本身反而不再是重点瓶颈是 KV cache 的读写带宽。做法XQA 针对 GQA/MQA 结构用 Tensor Core 重写了注意力内核减少数据搬运和精度转换次数。收益官方博客给出的实测数据——H200 单卡跑 Llama-70B输入 128、输出 2048吞吐从 1,227 提升到 2,941 tok/s/GPU约 2.4 倍8 卡张量并行下也有 1.9 倍。更关键的是延迟预算没有变意味着同样的卡能接住更多并发用户。算更多反而更快MoE 的 DENSEGEMM 思路问题DeepSeek-V3 这类模型有 256 个专家每个 token 每层只路由 8 个。batch 小的时候每层只进来几十个 token传统 grouped GEMM 里每个专家分到的 token 太少内核启动、调度、数据重排的开销占比过高。做法DENSEGEMM 反着来——对全部专家做一次稠密 GEMM再用 per-token 掩码把没被选中的专家输出丢掉。收益在内存受限区间这些冗余计算的代价很小而稠密的矩阵形状让 Tensor Core 利用率明显上升。B200 上 TP8 的 MoE 模块基准里64~208 token 区间比原有 grouped GEMM 路径快最高 1.12 倍。算得更多反而更快这是理解低延迟 MoE 调优的钥匙。这张图展示 MoE 的路由机制token 先进路由器打分再分发给被选中的专家计算最后加权合并。理解它之后你就能明白为什么每层进来多少 token会成为选择优化路径grouped GEMM 还是稠密 GEMM的分界线。CPU 开销藏进 GPU 计算CUDA Graph 与重叠调度问题PyTorch 栈里CPU 端启动内核、检查停止条件、更新响应的 Python 开销在解码时容易拖住 GPU。做法CUDA Graph 把一段连续操作录成图、一次下发批大小对不上时就 padding 到最近的已录制尺寸重叠调度器则让 GPU 算第 n 步时CPU 同步准备第 n1 步把 CPU 延迟藏进 GPU 计算里。收益官方架构文档给出的数字CUDA Graph padding 在部分模型上带来最高 22% 的端到端吞吐提升两项优化都是运行时默认开启的不需要你写代码。这张图对比了 Blackwell 解码阶段的关键路径哪些环节被跳过、哪些计算被提前重叠直接决定了单步解码延迟的构成。三步跑通从容器到第一条推理结果最短路径就三件事拉容器、起服务、发请求。docker run --rm -it --ipc host --gpus all --ulimit memlock-1 \ -p 8000:8000 nvcr.io/nvidia/tensorrt-llm/release:1.0.0容器里依赖已打全起服务只要给一个模型名你会拿到一个 OpenAI 兼容的 8000 端口trtllm-serve TinyLlama/TinyLlama-1.1B-Chat-v1.0另开终端发个 chat 请求确认 JSON 里有 completion 和 token 统计就算跑通了curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:TinyLlama/TinyLlama-1.1B-Chat-v1.0,messages:[{role:user,content:Where is New York?}],max_tokens:32,temperature:0}想再快一点把模型名换成量化过的检查点如 nvidia/Qwen3-8B-FP8即可FP8 权重加 FP8 KV cache在 Hopper/Ada 卡上能放下 2~3 倍更大的 batch。本地源码可以从 git clone https://gitcode.com/GitHub_Trending/te/TensorRT-LLM 获取。延伸资料按需求挑一份读快速上手指南docs/source/quick-start-guide.md第一次跑通时对照它serve 与 LLM API 两条最短路径都有示例。架构总览docs/source/developer-guide/overview.md想搞懂 LLM 类、PyExecutor 和每步调度循环怎么转时看它。部署指南docs/source/deployment-guide/DeepSeek-R1、Llama 3.3 70B、Qwen3 等 12 份模型的预置部署配置照着抄就行。技术博客docs/source/blogs/tech_blog/27 篇内核级文章XQA、DENSEGEMM、Wide EP、稀疏注意力都在里面每篇都带实测数据。建议先用单卡跑通一个服务再逐篇过技术博客每篇的实测数字都可以直接对照自己的硬件复现。【免费下载链接】TensorRT-LLMTensorRT LLM provides users with an easy-to-use Python API to define Large Language Models (LLMs) and supports state-of-the-art optimizations to perform inference efficiently on NVIDIA GPUs. TensorRT LLM also contains components to create Python and C runtimes that orchestrate the inference execution in a performant way.项目地址: https://gitcode.com/GitHub_Trending/te/TensorRT-LLM创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考