TensorRT 构建大型推理引擎时需要评估大量 tactic，Timing Cache 能显著减少重复测量，但它也把历史环境的选择证据带进了新构建。若缓存文件只用“模型名.cache”命名，团队很难判断其中数据来自哪种 GPU、TensorRT、CUDA、精度、workspace 限制和插件组合。一旦构建结果出现回归，缓存命中会让问题难以复现。
可控做法是把 Timing Cache 当成有版本的构建制品，而不是临时文件。每份缓存要有内容摘要和来源清单，构建流水线先判断兼容域，再决定复用、合并或重新采样。构建耗时下降只是过程指标，生成引擎还必须完成输出正确性、动态形状、显存峰值、冷启动和目标负载时延验证。
先定义缓存兼容域
至少记录 GPU 计算能力与设备身份、TensorRT/CUDA/驱动版本、构建标志、精度、动态形状 Profile、workspace 或内存池限制、自定义插件摘要和模型摘要。任何会改变候选实现或计时环境的项目都应进入键值。不要凭文件能加载就认定结果适用于当前构建。
缓存来源必须能够追踪
流水线为每次采样保存构建日志、缓存 SHA-256、执行节点、时间和测试负载，并把缓存放入只读制品库。开发机产生的未知缓存不能直接进入发布构建。合并缓存前保留各输入摘要与顺序，使后续能够定位某项计时记录来自何处。
冷缓存与热缓存都要构建
发布候选至少执行一次不加载缓存的对照构建，再执行受控缓存构建，比较引擎层选择、构建警告、制品摘要和性能。若二者选择不同，需要解释差异而不是只接受更快的一个。对于关键模型，可按 GPU 节点池维护独立缓存，避免异构环境互相污染。
插件和形状变化触发失效
自定义插件重新编译、精度约束改变、Profile 边界调整或模型图重写后，应根据影响范围生成新的缓存命名空间。简单追加旧缓存可能保留已经不具代表性的计时。流水线要把失效规则写成机器检查，而不是依赖构建人员记忆。
验收对象仍然是完整引擎
对相同输入比较输出容差，覆盖每个 Profile 的最小、典型和最大形状，测量冷启动、稳态、尾延迟、显存与并发。缓存异常时应能切回无缓存构建，并保留旧引擎作为业务回退。不能把 tactic 选择推导为对所有服务器的性能承诺。
可执行的验收动作
- 为 GPU、TensorRT、模型、Profile、精度和插件生成兼容键。
- 保存缓存摘要、构建日志、节点身份和采样时间。
- 对比冷缓存与热缓存构建的选择、输出和性能。
- 为模型图、插件与形状变化建立自动失效规则。
- 验证禁用缓存重建和旧引擎业务回退路径。
当前能力如何确认
TensorRT 文档说明 timing cache 可复用层实现的性能测量结果，以减少后续构建耗时。
缓存兼容与构建结果受 TensorRT 版本、目标设备、构建配置和可用 tactic 约束，最终引擎仍需独立验证。
文中机制与配置边界依据NVIDIA TensorRT 文档的当前版本核对；官方说明用于确定候选条件，实际部署仍需结合完整料号、服务器支持清单、软件组合与现场测试。
从验证结论进入交付
中科新远是 NVIDIA Networking Elite 合作伙伴。中科新远可结合 GPU 节点池与推理流水线协助梳理构建制品、版本矩阵和回归记录，并把服务器与网络依赖纳入发布门禁。具体合作范围和项目交付内容以当前有效资质、官方目录及书面确认结果为准。
Timing Cache 可以在不同型号 GPU 之间直接共享吗？
不能只根据文件可加载来决定。计时结果与目标设备和构建约束有关，应按官方兼容条件和内部兼容键隔离，并在每类目标硬件上验证生成引擎。
WeChat
Profile