TensorRT-LLM 1.4 候选版调整 KV 缓存默认配置

TensorRT-LLM 1.4.0 候选版本需要分阶段升级

NVIDIA 于 UTC 时间 10 月 22 日发布了开源 TensorRT-LLM“v1.4.0rc1”候选版本。发行说明涵盖了模型支持、服务 API、KV 缓存管理、解码路径和特定于硬件的优化。对于需要其中一项更改的团队来说，候选版本是一个有用的集成目标，但它与经过广泛验证的生产版本不同。发布说明本身标记了已知问题。其中之一涉及通过分离式服务和 A100 上默认的 Python KV 缓存收发器取消流请求；另一种说法是，JSON 模式服务示例可以使用 Qwen3 模型返回无界输出。这些警告应该成为任何评估计划的一部分，而不是隐藏在功能列表后面。

缓存默认值是兼容性更改

发布说明将两个 API 更改标记为破坏性变更：KV 缓存管理器 V2 和 Python KV 缓存收发器成为默认值，并且删除了未使用的“LlmRequest”字段。因此，从早期版本升级的服务可能会改变行为，即使它自己的配置文件没有改变。使用预填充和解码分离、取消或外部缓存连接器的团队应明确测试这些路径。 NVIDIA 为 KV 缓存管理器 V2 添加了 Mooncake 连接器，另为传输后端增加了 KV 缓存借用 API，并开放原生 KV 事件流与路由负载信息。对于需要在工作节点之间放置工作和移动状态的操作员来说，这些原语非常有用，但发布页面并没有证明每个拓扑都有吞吐量增益。

具体的取消问题说明了隐藏状态转换的风险。客户端可以在收到足够的输出后关闭流；服务器仍然具有缓存状态并传输工作以进行协调。如果收发器在取消后发生故障，则后续生成的请求可能会受到影响。受控负载测试应将正常完成与有意的客户端断开连接混合起来，检查错误率和缓存清理，并在计划部署的相同硬件和服务模式上重复。简单的单请求延迟基准测试会错过这种故障模式。据报道，该问题是在 A100 上观察到的，因此不应说它在所有 GPU 上都普遍存在。

模型和精度支持扩展

该版本增加了对 DeepSeek-V4.1-Flash 和 NVFP4 GLM-5.3-Flash 检查点的支持，以及 Qwen3.8-Flash-Next NVFP4 的实验性 Modeling V2 目标。它还提到了 LiLiCorr 的 DFlash 草稿检查点，并更改了 Hopper 上 Nemotron-H NVFP4 的回退行为。每个条目都是特定模型格式和执行路径的兼容性声明。这并不是说模型输出或性能在不同精度下是相同的。在替换已知良好的部署之前，团队应验证检查点的许可证、分词器、聊天模板、数值容差和代表性输出质量。量化可以减少内存或提高吞吐量，同时改变边缘情况行为，特别是在长或结构化输出中。

NVIDIA 还列出了 NVFP4 冷页压缩中的 RoPE 精度选项、逐渐填充的主机缓存层以及缓存 V2 池的重新平衡参数。这些旋钮暴露了繁忙的服务集群面临的资源权衡：GPU 内存、主机内存、传输时间和响应延迟。有用的测量报告所有四个，以及相同提示长度分布下的 p50 和尾部延迟。发行说明提到了许多硬件路径，包括 Rubin 支持、Blackwell CuTe DSL 工作和注意力变体。在预期的机器上完成测试之前，它们应被视为特定于体系结构的开发。有关某个 GPU 系列的标题不应复制到另一个 GPU 系列的预算中。

结构化输出和确定性需要自己的测试

Qwen3 的 JSON 模式示例警告对于期望有界机器可读响应的代理系统非常重要。如果客户端可以无限期地等待或在不知​​情的情况下接受截断的对象，则模式功能在操作上没有用处。该版本还添加了确定性 FP32 GVR V2 top-K 解码，并在某些批量采样路径中尊重每个请求种子。确定性行为的范围仅限于这些指定的路径，而不是每次分布式运行都会逐字节再现的一揽子承诺。团队应设置响应上限，验证解析的输出，记录模型和解码设置，并在生产中使用的确切批处理计划下比较重复运行。

10 月 25 日读者如何判断

如果当前堆栈稳定并且不需要任何新模型或缓存功能，则候选版本可以保留为评估目标。如果所需的检查点或连接器需要，则在隔离的服务上进行升级，并收集前后配置文件，包括取消、预填充/解码传输、结构化输出、质量和资源使用。为配置和缓存行为保留经过测试的降级路径。这是来自已发布的变更和问题列表的编辑建议，而不是声称候选人在任何地方都不安全。 10 月 25 日的摘要呈现了 10 月 22 日的原始版本，其局限性完好无损；并不暗示 1.4.0 最终版本可用。