想象你是一家顶级餐厅的主厨，手艺精湛但动作慢——顾客点一道菜，你要从洗菜、切菜、烹饪到装盘一步步来。这时来了一位聪明的厨房总管，他不改变你的菜谱，而是重新规划后厨流程：把重的锅换成轻便的、把食材提前切好放进统一规格的收纳盒、哪个菜快好了就先上桌、空出来的灶台立刻接新订单。这位总管，就是 NVIDIA 的 TensorRT-LLM 推理引擎。它专门负责大语言模型（LLM）在 GPU 上“做菜”的加速，让原本慢吞吞的模型回应变得飞快，还能同时招呼更多顾客而不手忙脚乱。本文就用这座“餐厅厨房”的故事，带你搞懂 TensorRT-LLM 的核心招式，从量化压缩到动态批处理，再到显存分页管理。

岗位关联

对 AI 从业者而言，TensorRT-LLM 是让大模型产品落地的关键加速引擎。掌握它的优化原理与部署流程，意味着你不再只会“调 API”，而是能亲手把模型推理速度从“勉强能用”提到“生产级标准”——这是推理优化工程师和部署工程师的核心竞争力。

目录
  1. 可视化演示
  2. 技术概览
  3. 量化机制
  4. 动态批处理
  5. 显存管理
  6. 部署流程
  7. 性能对比
  8. 最佳实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示快速排序的分区过程，通过选择基准元素将数组分为两部分，递归排序左右子数组，支持逐步执行与自动播放。

本节配有交互动效（进入视口后自动加载，约 3KB）。

快速排序 - 分区操作 选择最后一个元素作为基准，将小于基准的元素移到左侧 T(n) = O(n log n) 分治法：选定基准后递归排序左右子数组

技术概览

想象一位天才主厨站在堆满食材的后厨里，他的菜谱（模型权重）独一无二，但每下一道菜都要重新翻菜谱、称调料、热锅，出餐慢得让顾客等到不耐烦。TensorRT-LLM 这个“厨房总管”一上任，没有改动任何菜谱，而是把整个烹饪流程变成了标准化的操作卡：锅铲怎么拿、火候怎么调、配菜怎么摆，全部提前编排好。GPU 不再需要临时思考“下一步做什么”，而是照着操作卡流水线执行，出菜速度自然快了数倍。

这个“操作卡”在技术世界里叫推理引擎。TensorRT-LLM 是 NVIDIA 开源的 LLM 推理引擎，它读取 PyTorch 训练好的模型，将其编译成 GPU 专属的高效执行计划。编译后的引擎针对 NVIDIA GPU 的算子库（如 cuBLAS、CUTLASS）做了深度融合与调优，就像厨房总管把“切菜+炒菜+装盘”合并成一步完成一样。使用 TensorRT-LLM 不需要重新训练模型，只需转换一次，后续直接调用引擎推理。

在推理过程中，大模型生成一段回答要分两步走：先把整段输入“读一遍”形成初步理解（称为 prefill 阶段），再一个字一个字地“边想边写”（称为 decode 阶段）。总耗时就是这两者的叠加：

TensorRT-LLM 的发力点正是这个公式里最肥的一块肉——decode 阶段。它通过量化、动态批处理和显存管理三招把“边想边写”的速度推到极致。接下来我们就逐一拆解这位厨房总管的三大绝活。

Ttotal=Tprefill+Tdecode×NT_{\text{total}} = T_{\text{prefill}} + T_{\text{decode}} \times N
总响应时间 = 首轮理解时间 + 每个 token 生成时间 × 生成的 token 数。N 越大，decode 阶段越占主导。
  1. 首轮理解阶段 T_prefill模型一次性读完用户输入的全部 token，计算每个 token 的注意力，这一步耗时与输入长度相关。
    TprefillT_{\text{prefill}}
  2. 逐字生成阶段 T_decode模型每步只生成一个 token，生成数量等于输出长度 N，每一步都要读取全部历史信息。
    Tdecode×NT_{\text{decode}} \times N
  3. 叠加求总耗时总时间等于理解阶段加上生成阶段，TensorRT-LLM 的优化主要压缩第二个阶段，因为 N 通常很大。
    Ttotal=Tprefill+Tdecode×NT_{\text{total}} = T_{\text{prefill}} + T_{\text{decode}} \times N

量化机制

厨房总管很快发现，主厨用的锅又大又沉，每炒一道菜都要费很大力气翻动。如果换成轻便的不粘锅，翻炒速度能快一倍，而菜的味道几乎不变——食材没变，只是锅变轻了。在推理引擎里，这个“换锅”操作就是量化：把模型默认的 FP16（16 位浮点数）权重和激活值，压缩成 INT8（8 位整数）或 FP8（8 位浮点数），让计算更快、占用显存更小。

量化不是简单地把数字砍掉几位，而是用“缩放”来保持数值范围。就像把一斤菜切成小块，每块都按原来的比例缩小，做菜时再按比例“复原味道”。INT8 量化的核心是算出一个缩放因子 s，把浮点数 x 映射到 [-127, 127] 的整数区间：

FP8 量化的思路完全相同，但它不是整数而是 8 位浮点数（E4M3 格式），最大表示值是 448，因此缩放因子写成：

回到厨房：把大铜锅换成轻便锅后，主厨做菜的速度明显提升，客人尝过之后也说味道几乎没差。量化之美正在于此——用 1% 不到的精度损失，换取接近 2 倍的显存节省和计算加速。不过要提醒的是，锅不能换得太离谱（比如强行换成 4 位整数），否则菜就真糊了。

xq=round(xs),s=max⁡∣x∣127x_q = \text{round}\left(\frac{x}{s}\right), \quad s = \frac{\max|x|}{127}
FP8 与 INT8 存储大小相同（都省一半显存），但 FP8 的动态范围更大，量化误差更小，是当前大模型部署的首选。
  1. 8 位浮点表示FP8 用 4 位指数 + 3 位尾数表示数字，比整数能覆盖更宽的范围。
    FP8 (E4M3)\text{FP8 (E4M3)}
  2. 最大表示值 448E4M3 的规格化最大值，作为缩放分母，防止数值溢出。
    448448
  3. 更小的量化误差由于 FP8 的指数位保留了量级信息，对分布不均的权重（如存在极端小值和大值）更友好。
    sfp8=max⁡∣x∣448s_{\text{fp8}} = \frac{\max|x|}{448}

动态批处理

厨房里最让总管头疼的是“等菜齐”问题。以前顾客的订单必须凑满一桌才开工，如果三份菜里有一份需要慢炖，另外两份炒好的菜也只能干等着，灶台白白空转。这就是静态批处理的痛：同一批请求必须一起开始、一起结束，最慢的那个拖着全队跑。

TensorRT-LLM 的 in-flight batching（动态批处理） 彻底改变了游戏规则：每份菜独立烹饪，哪个先熟就先出锅，空出的灶台立刻安排新订单。在技术层面，每个请求（对应一段对话）在 GPU 上的计算进度独立推进，完成的请求立刻释放算力和显存，不需要等待整批同步。这个调度策略让 GPU 始终处于“满负荷”状态，吞吐量随之飙升。

动态批处理的效果可以用吞吐量公式来衡量，即单位时间生成的 token 数量：

在实际评测中，同样的 GPU 和模型，改用动态批处理后吞吐量通常能提升 2~6 倍，尤其在请求长短不一的真实场景下效果惊人。厨房总管实现了“永不空灶”的理想状态：动态穿插、随时补位、充分利用每一寸火力和台面。美中不足的是，单个请求的最快响应时间可能不如独占 GPU 时短，但整体服务能力大幅提升，这才是生产环境真正关心的。

Throughput=NtokensTelapsed\text{Throughput} = \frac{N_{\text{tokens}}}{T_{\text{elapsed}}}
吞吐量 = 所有请求生成的 token 总数 ÷ 总耗时。动态批处理让分母不变而分子变大，所以吞吐显著提升。
  1. 生成的 token 总数 N_tokens所有请求在这一段时间内生成的文本片段数量之和，是产出量。
    NtokensN_{\text{tokens}}
  2. 总耗时 T_elapsed从第一批请求进入到最后一批完成的墙钟时间，是成本量。
    TelapsedT_{\text{elapsed}}
  3. 吞吐量比值单位时间产出的 token 数越多，GPU 利用率越高，服务能力越强。
    NtokensTelapsed\frac{N_{\text{tokens}}}{T_{\text{elapsed}}}

显存管理

厨房的储物柜总是拥挤不堪。以前每接一桌订单，后厨就给整桌人预留一整片操作台，不管顾客实际点了几个菜，那片台面都被占死。随着大模型的上下文越来越长，这种“整块预留”造成的浪费愈发严重。这段被预留的空间在技术里叫 KV Cache——模型为了加速推理，把每轮计算得到的注意力 Key 和 Value 矩阵缓存下来，下次生成时不用重算。

问题是，KV Cache 的大小随序列长度线性增长，而且每个请求的缓存长度不同。如果按最长请求预留，短请求剩余的缓存空间就成了“看得见用不着的碎片”——在显存里东一块西一块，新请求来了却凑不出一整块。这就像储物柜里到处是半空的小格子，新的大行李却放不进去。

TensorRT-LLM 采用的 PagedAttention（分页注意力） 参考了操作系统虚拟内存的思路：把 KV Cache 切成固定大小的“页”或 block，按需分配，每个请求只在确实需要时才申请新页，页面可以散落在不连续的位置，由一张页表（block table）记录映射关系。KV Cache 的理论占用可以精确计算：

有了 PagedAttention，显存碎片从 60% 以上降到了 10% 以内。长序列请求也能从容跑起来，因为每个页面都用在了刀刃上，不再有“占着茅坑不拉屎”的整块预留。厨房储物柜变成了统一规格的小收纳盒超市，谁需要几个格子就拿几个，取用灵活且绝不浪费——这就是分页管理的魔力。

MKV=2×L×H×S×Dh×B×bM_{KV} = 2 \times L \times H \times S \times D_h \times B \times b
KV Cache 总显存 = 2 × 层数 × 注意力头数 × 序列长度 × 每头维度 × 批大小 × 每个元素字节数。PagedAttention 通过按页分配消除了碎片浪费。
  1. 系数 2每层要存 Key 和 Value 两套矩阵，所以乘以 2。
    22
  2. 层数 L 与头数 HTransformer 的层数和多头注意力头数，模型越大这两个数越大。
    L×HL \times H
  3. 序列长度 S 与头维度 D_h缓存覆盖全部已生成 token，序列越长占用越大；每个头存储的向量维度。
    S×DhS \times D_h
  4. 批大小 B 与字节数 b同时处理的请求数越多，缓存的份数越多；FP16 下 b=2 字节，INT8 下 b=1 字节。
    B×bB \times b

部署流程

厨房总管的方案再好，也不能直接拉着主厨上灶。正式营业前必须有一段“试菜筹备期”：把菜谱翻译成标准操作卡、把食材预处理成半成品、按客流定好灶台数量，最后才能开门迎客。TensorRT-LLM 的部署同样是一条固定的四步流水线，每一步都有对应的工具。

第一步是模型转换：把 HuggingFace 格式的 PyTorch 模型（如 Llama、Qwen、Mistral）转成 TensorRT-LLM 能识别的格式。这就像把主厨手写的潦草菜谱重新誊写成印刷体。第二步是引擎构建：用 trtllm-build 命令把转换后的模型编译成 GPU 引擎，可在此阶段指定量化方式（INT8/FP8）、batch 大小等选项，编译产出的 .engine 文件就是那张“标准操作卡”。第三步是参数调优：根据 GPU 显存和服务需求设置 KV Cache 上限、最大序列长度、最大并发数。第四步是启动服务：用 Triton 推理服务器或 TensorRT-LLM 的 Python API 加载引擎对外提供请求服务。

部署完成后，显存规划是最容易翻车的一步。显存总预算必须精确平衡三个部分：

完整的部署流程就像开一家新餐厅的 SOP：菜谱誊写、备料预处理、灶台规划、开门迎客，环环相扣。走完这四步，大模型服务才算正式“开业”。

Mavail_kv=MVRAM−Mweight−MactivationM_{\text{avail\_kv}} = M_{\text{VRAM}} - M_{\text{weight}} - M_{\text{activation}}
可用于 KV Cache 的显存 = 显卡总显存 − 模型权重占用 − 激活值临时占用。算错了就会在推理中途出现显存溢出（OOM）。
  1. 显卡总显存 M_VRAM物理上限，例如 A100 是 80 GB、L40S 是 48 GB，一切分配都不能超过它。
    MVRAMM_{\text{VRAM}}
  2. 模型权重 M_weight模型参数占用的空间，量化后这里会明显缩小。
    MweightM_{\text{weight}}
  3. 激活值 M_activation前向计算中的临时张量，与 batch 大小和序列长度正相关。
    MactivationM_{\text{activation}}
  4. 剩余给 KV Cache减完前两项后，剩下的空间才分配给 KV Cache，多退少补。
    Mavail_kvM_{\text{avail\_kv}}

性能对比

开张营业后，怎么证明这位厨房总管真的值这个薪水？答案是“公平试吃测评”——让不同厨房在同一批顾客、同一批菜品上比速度、比吞吐。TensorRT-LLM 的评测不能只看感觉，要盯住几个硬指标：生成吞吐（每秒产出多少 token）、首 token 延迟（从请求发出到第一个字返回的时间）、以及 P95 端到端延迟（95% 的请求都在这个时间内完成）。

在英伟达的公开基准和社区实测中，用同一块 A100/H100 GPU 部署同一个 7B~70B 模型，TensorRT-LLM 相对 PyTorch 原生推理的吞吐提升通常在 2~5 倍；相比同样是高效推理框架的 vLLM，性能也互有胜负、普遍持平或略优。加速比的量化表达为：

选型建议也很直白：如果你的推理服务跑在 NVIDIA GPU 上、追求极致吞吐、愿意花几天时间部署调优，TensorRT-LLM 是当前最优选之一；如果团队更看重开发效率、需要多模态或高度定制化模型支持，vLLM 等其他框架也可以作为备选。厨房总管的考核成绩单证明：同样的灶台和主厨，效率提升不是一点点。

Speedup=ThroughputbaselineThroughputTensorRT-LLM\text{Speedup} = \frac{\text{Throughput}_{\text{baseline}}}{\text{Throughput}_{\text{TensorRT-LLM}}}
加速比 = 原生框架的吞吐量 ÷ TensorRT-LLM 的吞吐量。大于 1 说明更快，2 代表吞吐翻倍。
  1. 基线吞吐 Throughput_baseline用同样的模型和数据跑在 PyTorch 或 vLLM 上的吞吐值，作为对照组。
    Throughputbaseline\text{Throughput}_{\text{baseline}}
  2. 优化后吞吐TensorRT-LLM 引擎在同一批真实请求下的吞吐值。
    ThroughputTensorRT-LLM\text{Throughput}_{\text{TensorRT-LLM}}
  3. 加速比结果比值越大，优化效果越明显，同时也代表单位 token 的 GPU 成本越低。
    ThroughputbaselineThroughputTensorRT-LLM\frac{\text{Throughput}_{\text{baseline}}}{\text{Throughput}_{\text{TensorRT-LLM}}}

最佳实践

纸上谈兵终觉浅。厨房总管在无数次实战中总结了几条“后厨铁律”，照着做能避开大部分坑。第一条铁律是量化选择有讲究：显存紧张但精度要求高的场景优先选 FP8，它速度快、误差小；显存特别吃紧的再考虑 INT8；不要轻易用 INT4 这类激进量化，除非你能接受明显的质量回退。

第二条铁律是批处理配置要适配请求分布。真实线上服务的请求长度参差不齐，这正是动态批处理发挥优势的舞台。建议把 max_batch_size 和 KV Cache 上限调得略高于预估峰值，再配合 max_num_tokens 控制单批 token 总数，避免一次塞太多导致显存暴涨。第三条铁律是显存规划要留余量，建议预留 10% 的显存给模型加载和临时张量，KV Cache 只分配总显存的 60%~70%，宁可少分也不能在高峰期 OOM。

最后也是最关键的一条：基准测试先行。别凭感觉调参，用官方 benchmark 脚本和你的真实请求数据先跑一轮基线，找出瓶颈是算力不足还是显存不足，再针对性优化。还有一个小技巧：引擎构建时开启 --gemm_plugin auto 等常用开关，能进一步压低算子开销。厨房总管的经验浓缩成一句话：用数据说话，用测试驱动，在量化和显存之间找平衡。

AI 应用场景

智能客服大模型服务

阶段：模型推理与部署

解决的问题：传统客服机器人接入大模型后，高峰期大量用户并发请求导致 GPU 算力吃紧，响应慢、成本高。TensorRT-LLM 的动态批处理和 PagedAttention 让单个 GPU 能同时服务更多用户，吞吐提升 3 倍以上，显著摊薄单次推理成本。如果客服话术质量要求极高，通过 FP8 量化还能让显存占用减半，同一张卡跑更大的模型或更多并发。

具体案例：某金融公司的智能理财客服，原方案在 1 张 A100 上同时只能服务约 20 路对话，单条回答延迟 6 秒。改用 TensorRT-LLM 后，通过 FP8 量化 + in-flight batching，并发提升到 80 路，首 token 延迟压到 0.8 秒，GPU 利用率从 35% 提升到 85%。

代码生成 IDE 插件

阶段：低延迟推理链路

解决的问题：代码补全工具对首 token 延迟极度敏感——用户敲完一行代码，300 毫秒内没看到建议就会失去耐心。TensorRT-LLM 把模型编译成高度优化的 GPU 引擎，配合显存分页避免了长上下文下的碎片等待，让首 token 延迟稳定压在 200ms 以内。

具体案例：某团队给公司内部的代码补全插件接入 7B 参数的 CodeLlama 模型。使用 TensorRT-LLM 的 FP8 引擎后，模型从原来的 2 张 T4 卡压缩到 1 张，响应速度反而快了 2.4 倍，生成的补全建议几乎“秒出”。

企业私有化对话机器人

阶段：模型转换与引擎构建

解决的问题：企业要求数据不出内网，需要把 HuggingFace 上的开源大模型部署到私有 GPU 集群。TensorRT-LLM 的标准部署流程（转换 → 构建 → 调优 → 启动）提供了一条经过验证的落地路径，避免团队从零摸索显存分配和并发调优的坑。

具体案例：一家制造业企业将 Qwen2.5-14B 部署到内网 2 张 L40S 显卡上，用 trtllm-build 构建 FP8 引擎，通过 Triton 统一对外服务。上线后并发高峰时没有出现一次 OOM，P95 延迟稳定在 3 秒以内。

Python 演示

python46 行
class PagedCache:    """模拟 PagedAttention 的分块显存分配。"""    def __init__(self, block_size=16, num_blocks=8):        self.block_size = block_size          # 每个 block 能存的 token 数        self.num_blocks = num_blocks          # 显存中总 block 数        self.free_lists = list(range(num_blocks))  # 空闲 block 池        self.tables = {}                      # 每个请求的 block 表        self.gc_count = 0                     # 释放次数统计     def alloc(self, seq_id, need):        """为一个序列分配显存，按块数取整。"""        blocks = []        need_blocks = (need + self.block_size - 1) // self.block_size        if need_blocks > len(self.free_lists):            self.free_lists.extend(blocks)            raise MemoryError("显存不足，请减少并发或序列长度")        for _ in range(need_blocks):            blocks.append(self.free_lists.pop())        self.tables[seq_id] = blocks        return blocks     def free(self, seq_id):        """请求结束时释放所有 block。"""        if seq_id in self.tables:            self.free_lists.extend(self.tables.pop(seq_id))            self.gc_count += 1     def usage(self):        """当前显存使用率。"""        used = self.num_blocks - len(self.free_lists)        return used / self.num_blocks  def main():    cache = PagedCache(block_size=16, num_blocks=6)    cache.alloc("seq_1", 30)     # 需要 2 个块    cache.alloc("seq_2", 10)     # 需要 1 个块    print("显存使用率:", cache.usage())    cache.free("seq_1")          # 释放 seq_1 的块    cache.alloc("seq_3", 25)     # 新请求复用刚释放的块    print("释放回收次数:", cache.gc_count)    print("最终使用率:", cache.usage())  if __name__ == "__main__":    main()
目的：演示 PagedAttention 的分页显存管理核心逻辑——小块分配、按需释放、碎片复用。
  1. self.free_lists = list(range(num_blocks))用列表模拟空闲块池，初始时所有 block 都可用。
  2. need_blocks = (need + self.block_size - 1) // self.block_size向上取整计算需要几个块，对应“分页”策略。
  3. if need_blocks > len(self.free_lists)显存不足的检查，避免无限制分配导致 OOM。
  4. self.tables[seq_id] = blocks记录每个请求的页表，映射关系是 PagedAttention 的核心。
  5. self.gc_count += 1统计回收次数，方便观察动态分配的行为。

常见误区

误区用 INT8 或 FP8 量化后，模型回答质量肯定大幅下降，“半精度变 8 位，损失肯定严重”。

正解现代量化配合校准集和缩放因子，精度损失通常控制在 1% 以内，对大多数任务影响极小。就像轻便锅做菜味道几乎不变，关键在缩放因子算得准。FP8 用指数位保留数值量级，误差比 INT8 更小，是当前首选。真正让模型“变笨”的往往不是量化本身，而是没有校准、缩放因子计算不当或用了过激的 4 位量化。

为何常见：人们凭直觉认为“位数越少 = 信息越少 = 质量越差”，忽视了缩放因子和动态范围设计能有效补偿精度损失。

误区“动态批处理不就是多塞几个请求一起跑吗？把 max_batch_size 调大就行。”

正解in-flight batching 是一种调度策略，而不是简单的容量调整。它让每个请求在 GPU 上独立推进，先完成的先退出、新请求补位，解决了静态批处理中“慢请求拖累全队”的问题。调大 batch size 只是增加容量，若请求长短不一，静态模式下吞吐仍被最短板的请求限制。两者可以同时用，但概念完全不同。

为何常见：从字面看“批处理”容易联想到堆量，忽略了“动态调度”才是核心创新的关键。

误区“分页管理嘛，就是显存变小了装得多，增加了物理显存。”

正解PagedAttention 并不增加物理显存，它解决的是显存碎片化问题。传统预留在显存中形成大量无法合并利用的小空洞，分页分配把这些空洞用起来，相当于“把储物柜重新打散成统一小格”，可用空间利用率提升了，但柜子本身没有变大。

为何常见：因为“能跑更长的序列了”容易让人误以为显存变多了，实际是空间利用率提高了。

误区“这么高级的引擎只有数据中心旗舰卡才能用，普通卡装了也白装。”

正解TensorRT-LLM 支持 NVIDIA 较新的 RTX 和 Ada 架构消费级显卡，例如 RTX 3090/4090、L40S、T4 等都可用，只是不同 GPU 对 FP8 等特性的支持程度不同。如果 GPU 不支持 FP8，可以退一步用 INT8。部署前用 nvidia-smi 确认算力和显存，选择对应的量化精度即可。

为何常见：TensorRT-LLM 的官方基准大多基于 A100/H100，给人“高不可攀”的印象，忽略了它向下兼容的能力。

面试题

Q1. TensorRT-LLM 最准确的定义是什么？

单选题 · easy

  • A.模型训练加速框架
  • B.NVIDIA 开源推理引擎← 正确答案
  • C.数据标注标注工具
  • D.GPU 驱动的管理软件

答案：B。TensorRT-LLM 是 NVIDIA 专门针对大语言模型推理优化设计的开源引擎，它把 PyTorch 模型编译成 GPU 专属执行计划，类似厨房总管优化后厨流程。A 是训练方向，C、D 与推理引擎无关。

Q2. INT8 量化中，缩放因子 s 的作用是什么？

单选题 · easy

  • A.随机打乱权重数值
  • B.把浮点数压缩到整数区间← 正确答案
  • C.增加模型的网络层数
  • D.降低 GPU 的时钟频率

答案：B。s = max|x| / 127，将浮点权重按比例映射到 -127~127 的整数区间，推理时再反乘 s 复原，核心是“一个缩放系数 + 取整”两步，让轻便锅做出接近原来的味道。A/C/D 都不是量化的含义。

Q3. FP8 相比 INT8 的主要优势是什么？

单选题 · mid

  • A.显存占用直接减半
  • B.动态范围大、误差小← 正确答案
  • C.完全不需缩放因子
  • D.只支持训练不支持推理

答案：B。FP8 是 8 位浮点数（E4M3），指数位保留了数值量级，因此动态范围比 INT8 更大，量化误差更小，是当前大模型推理首选。两者存储大小相同，都省一半显存，所以 A 不是相对优势；C、D 明显错误。

Q4. in-flight batching 最核心的改进是什么？

单选题 · mid

  • A.强制所有请求同时结束
  • B.请求独立推进并动态补位← 正确答案
  • C.拒绝一切新进入的请求
  • D.把请求排队串行处理

答案：B。动态批处理给每个请求独立推进的能力，完成的请求立刻释放资源，新请求马上补进空位。静态批处理才要求同进同退（A），C、D 与批处理提升吞吐的目标背道而驰。

Q5. PagedAttention 解决的核心问题是？

单选题 · mid

  • A.CPU 与 GPU 之间带宽小
  • B.网络传输延迟过高
  • C.KV Cache 显存碎片浪费← 正确答案
  • D.磁盘 I/O 读写速度慢

答案：C。PagedAttention 把 KV Cache 切成固定大小的 block，按需分配、散落存放，消除了传统整块预留造成的碎片空洞，让显存利用率从 40% 提升到 90% 以上，同时支持更长序列。A/B/D 都与显存管理无关。

Q6. 大模型推理中的 KV Cache 保存的是什么？

单选题 · easy

  • A.历史 token 的 Key 和 Value 矩阵← 正确答案
  • B.训练数据集全部样本
  • C.模型权重全部参数
  • D.用户输入的原始文本

答案：A。KV Cache 缓存的是每层注意力计算得到的 Key 和 Value 矩阵，用来避免每一步生成时重算历史 token 的注意力，类似厨房提前切好的半成品食材。B/C/D 都不属于 KV Cache 的内容。

Q7. 下列哪些是 TensorRT-LLM 支持的量化类型？

多选题 · hard

  • A.INT8 对称量化← 正确答案
  • B.FP8 E4M3 浮点量化← 正确答案
  • C.INT4 低比特量化← 正确答案
  • D.完全不支持任何量化

答案：ABC。TensorRT-LLM 支持 INT8、FP8、INT4 等多种量化方案，核心是用缩放因子压缩精度并配合校准集保证质量。D 与事实完全相反，属于一眼排除项。

Q8. 部署 TensorRT-LLM 的正确操作顺序是？

单选题 · hard

  • A.启动服务→构建引擎→转换模型
  • B.转换模型→构建引擎→启动服务← 正确答案
  • C.直接运行 PyTorch 模型无需构建
  • D.顺序任意排列结果相同

答案：B。正确流程是先做模型转换（把 HuggingFace 模型转成 TensorRT-LLM 格式），再用 trtllm-build 构建 GPU 专属引擎，最后加载引擎启动服务。A 把顺序反了，C 等于不用 TensorRT-LLM，D 显然不对——引擎必须构建后才能启动。

Q9. 动态批处理相比静态批处理的优势有哪些？

多选题 · mid

  • A.先完成请求先释放资源← 正确答案
  • B.新请求可及时补位← 正确答案
  • C.整体吞吐显著提升← 正确答案
  • D.所有请求延迟完全一致

答案：ABC。动态批处理让请求独立推进、完成即退出、新请求补位，因此吞吐大幅提升；但由于动态调度，个别请求的延迟无法保证完全一致，D 不是它的优势。

Q10. KV Cache 显存占用与哪些因素直接相关？

多选题 · hard

  • A.模型层数 L 和注意力头数 H← 正确答案
  • B.序列长度 S 和批大小 B← 正确答案
  • C.每个元素的字节数 b← 正确答案
  • D.训练数据集的样本总量

答案：ABC。KV Cache 大小 = 2 × L × H × S × D_h × B × b，层数、头数、序列长度、批次、字节精度都是关键因子。训练集大小只是影响模型权重分布，与推理时的 KV Cache 无直接关系，D 错误。