NVIDIA TensorRT-LLM 1.4.0rc0：支持 GLM-5.3-Flash，移除 KVCacheManagerV2 的 Python 实现

1. 模型支持与准备条件

2026年10月14日发布的此次预发布版本在 PyTorch 后端新增了 GLM-5.3-Flash。该模型支持文本、图像和视频输入，直接使用官方的 8 位浮点模型权重。

模型支持变更的部署指南建议，一体化服务使用 4 张 B200，将输入处理与输出分配给不同工作进程的分离式服务使用 8 张。操作系统为 Linux，CUDA 驱动需为 575 或更高版本。

纯文本服务可使用随附安装的 Transformers 库运行。图像和视频输入需要执行以下安装命令。

  pip install "transformers==5.17.0"

容器内还需安装 fla-core 和 einops。

视频解码还需额外安装 opencv-python-headless。

2. 速度数据需结合测试条件解读

多词元预测是预先提出多个后续词元的方法。模型支持 PR #19136 的部署指南给出了使用 TensorRT LLM 1.3.0rc29 和 4 张 B200 测得的结果。

测试使用 8 位 FP8 权重和 16 位 BF16 缓存，输入与输出长度均为 1,024 个词元。随机输入的种子为 0，选择概率最高的词元并忽略结束词元。先用并发请求数 2 倍的请求预热，再发送 5 倍的请求，测量 2 次。预测词元的接受率未被人为固定。

并发请求为 1 个时，将模型计算以及根据输入选择性工作的子网络——专家模块分别分配到 4 张卡上，预测 3 个词元，每用户每秒生成 389 个词元，每 GPU 为 92 个词元。同等条件下关闭预测后，平均每词元耗时 5.57 毫秒，每用户每秒生成 180 个词元，单用户生成速度相差约 2.2 倍。

并发请求为 256 个时，将用于计算应关注输入哪些部分的注意力任务请求分配给 4 个 GPU 进程，专家模块也分布在 4 张卡上。预测 1 个词元时，每 GPU 每秒生成 2,735 个词元，每个进程的批处理上限为 64。

每用户指标不包含首词元等待时间，而每 GPU 指标包含输入处理和首词元等待时间。这些结果仅适用于测试配置和并发请求范围，并不证明最大吞吐量。

数学题评估中，在推理模式下对 1,319 道题选择概率最高的词元，并采用 4,096 个词元的输出预算时，与 Hugging Face 实现的准确率差异在 0.08 个百分点以内。

3. 缓存管理仅保留一套实现

KV 缓存用于保存此前已处理词元的计算结果。PR #19154 移除了管理该缓存的 KVCacheManagerV2 的 Python 实现。仅保留此前已为默认选项的实现，减少了维护两套键计算、数据驱逐和统计逻辑一致性的负担。

供 Python 导入使用的包本身并未消失。保留的包通过绑定暴露 C++ 实现。后端选择环境变量和用于加速 Python 实现的构建选项也已移除，因此指定了这些选项的部署和构建流程需要修改。

4. 事件采集需区分变更时点

移除实现的 PR 也删除了即时输出缓存变化的 Python 流式路径。在该变更中，kv_cache_config.kv_events_config 会在启动时被拒绝，替代方式是通过 kv_cache_config.event_buffer_max_size 收集事件，再按迭代取出。

不过，最终发布清单还单独列出了 PR #19359 的 C++ 流式事件支持。不能仅凭移除实现的 PR，就断定此版本完全不支持流式事件。所提供的资料未说明现有配置与新路径的兼容关系。

5. 采用收益与迁移成本

缓存精度也需要权衡。8 位浮点缓存可将压缩键值表示的存储空间减半。但它会反复将选中的缓存行转换为计算精度，再分成小批次移入临时空间并调用注意力计算。这些额外操作可能在输入较大时增加首词元等待时间，并降低输入吞吐量。用于定位的索引和循环计算的状态精度保持不变。

若要复用模型前段的计算，需要定期保存中间状态的策略。

GLM-5.3-Flash 不支持保留多个候选并从中选择答案的束搜索。

此版本还存在一个已知问题：在 H100 上以将模型计算分配到 2 个 GPU 的张量并行度 2 配置执行流式和远程执行任务时，若在模型对象间复用进程通信工作进程池，初始化可能卡住。

已保存的官方发布说明仅涵盖到 1.3，因此需结合发布清单和各个 PR 阅读。

此版本的重点是扩大模型选择范围和简化实现，是否采用还需在确认现有缓存配置能否迁移后再作决定。