NVIDIA发布HSTU生成式推荐器端到端推理方案，KV缓存最高提速 5.93 倍
NVIDIA技术博客介绍，Dynamo-Triton现通过recsys-examples仓库支持HSTU生成式推荐模型的完整推理流程，在RTX PRO 6000 Blackwell上、batch size 8、GPU KV缓存 100% 命中时，三层与八层模型的延迟分别为 0.423 毫秒和 0.678 毫秒。
AI解读：生成式推荐把推荐从“检索、排序、预测”几段独立流程，改成对用户行为序列做建模：把交互、上下文、候选物品都当成token，让模型直接生成或打分下一个相关物品。NVIDIA这次做的事不是提出新模型，而是解决这类模型上线后“算得慢”的问题——用户历史越长、序列模型越深，每次请求重复计算的部分就越多。
给出的方案是组合拳：用PyTorch AOTI把模型提前编译成可直接被C++加载的包，用FlexKV缓存注意力计算中的KV状态，用NV Embedding Cache把热门embedding放GPU、全量表放CPU，最后通过Dynamo-Triton对外提供服务。
官方给出的数字是：batch size 8、GPU KV缓存 100% 命中时，三层HSTU每逻辑请求 0.423 毫秒，八层 0.678 毫秒；相对同样AOTI但不带KV缓存，最高提速 4.47 倍和 5.93 倍。
对真正要部署推荐模型的人，这套流程的价值在于“同一份导出产物，既能在Python里验证，也能用原生C++回放，还能直接交给Dynamo-Triton上线”，不用为了生产环境重写模型。限制也很明确：这是NVIDIA在KuaiRand-1K配置、单张RTX PRO 6000 Blackwell上跑出的基准，序列长度、候选数量和上下文特征都是固定参数，不能直接外推到别的数据集或硬件。
普通读者不需要立刻做什么。这条新闻影响的是推荐系统工程师和负责推理成本的人：KV缓存只在“用户历史前缀基本不变、只追加少量新token”的请求模式里省算力，历史变化频繁或缓存命中率低时，收益会收窄。想复现的话，入口是NVIDIA/recsys-examples仓库里的HSTU推理指南。
NVIDIA技术博客称，NVIDIA Dynamo-Triton（原Triton Inference Server）现已通过NVIDIA recsys-examples仓库，支持端到端的HSTU（Hierarchical Sequential Transduction Unit）生成式推荐器推理流程。
该流程组合了HSTU、PyTorch AOTI（Ahead-of-Time Inductor）编译、FlexKV支持的KV缓存、原生C++验证、NV embedding cache和Dynamo-Triton部署。
NVIDIA给出的基准数据为：在NVIDIA RTX PRO 6000 Blackwell Workstation Edition GPU上，动态batch size 8、GPU KV缓存命中率 100% 时，Dynamo-Triton搭配PyTorch AOTI相对“同样AOTI配置但无KV缓存”，三层HSTU模型最高提速 4.47 倍，八层模型最高提速 5.93 倍。
HSTU把推荐变成序列建模，代价是每次请求都要重算历史
NVIDIA介绍，生成式推荐（GR）系统不再把推荐拆成检索、排序、预测等孤立阶段，而是把它重构为对用户行为的序列建模：用户的交互、上下文、候选物品和动作都成为高基数事件流中的token，模型学习从这段序列中生成或打分下一个相关物品。
在NVIDIA的HSTU排序示例中，模型输入由分类token构建：上下文token表示用户侧信息，item token表示物品，可选的action token表示用户与这些物品的交互。HSTU预处理路径会取embedding，在存在action token时交错item与action embedding，追加上下文信息并施加位置编码；随后HSTU block处理序列，预测头产出多任务排序输出。
NVIDIA称这种结构适合“时效性、顺序和重复交互模式很重要”的推荐系统，但每次请求都重复处理长历史序列会让推理变得昂贵。因此生产系统需要在保留HSTU建模收益的同时，减少服务期的冗余计算。
- HSTU由NVIDIA提出，面向高基数、非平稳事件流的生成式推荐负载。
- 传统推荐系统通常由多个专用模型和特征流水线构成检索与排序，GR则把推荐建模为序列预测问题。
- 代价集中在推理：请求反复处理长历史序列，KV状态反复重算会拉高延迟。
KV缓存和AOTI各自解决什么
NVIDIA说明，KV缓存保存此前序列计算中可复用的键值数据，使模型不必重算用户历史中已被缓存的部分。这在“用户长期历史基本稳定、只有新候选物品或近期动作到来”的推荐请求模式下尤其有用。
NVIDIA的HSTU推理流程包含一个KVCacheManager，用GPU内存和主机存储分层存放KV数据缓存。GPU缓存被组织为分页式KV数据表，支持查找、分配、追加和淘汰；当GPU缓存空间紧张时，较老的用户可按LRU风格策略被淘汰。主机侧存储提供另一层缓存，流程中还包含一个由FlexKV支持的KV缓存运行时后端。
PyTorch AOTI路径则从PyTorch模型出发，用torch.export和PyTorch AOTI导出，提前编译成可供原生C++运行时加载的包，以减少Python运行时开销，并为Dynamo-Triton的PyTorch AOTI后端提供部署产物。导出包内含AOTI模型归档、元数据和embedding表文件；embedding实现结合了DynamicEmb推理embedding表与NV Embedding Cache——后者只把热门embedding留在GPU内存，整个表则保留在CPU内存，以降低GPU内存占用。
NVIDIA称，同一份导出产物会在多种方式下验证：Python导出脚本生成包并回放tensor；原生C++可执行文件加载并回放导出模型，用于正确性和性能验证；Dynamo-Triton部署使用同一AOTI包和回放路径，以使开发验证与生产服务保持一致。
- KV缓存能消费分页缓存中的KV数据，导出的推理路径包含面向查找、分配、接入、追加和卸载的缓存感知自定义算子。
- GPU缓存按LRU风格淘汰老用户，主机侧作第二层存储，FlexKV提供KV缓存运行时后端。
- AOTI导出包写入层元数据和embedding表数据，避免不必要的embedding表重复拷贝。
- Dynamo-Triton的AOTI部署使用platform: "torch_aoti" 的PyTorch后端。
五步工作流与基准配置
NVIDIA列出完整工作流的五个阶段：构建所需自定义算子与运行时库；用PyTorch AOTI导出HSTU排序模型；启动FlexKV支持的KV缓存服务；用原生C++回放验证导出产物；用Dynamo-Triton服务导出的KV缓存AOTI模型。
基准测试使用recsys-examples中的KuaiRand-1K排序配置，在单GPU上运行。模型结构包括三层和八层HSTU变体，隐藏层大小 512、4 个注意力头、BF16模型权重、BF16 KV缓存，历史序列最大总长度 8,192（4,096 个item加action对），候选序列最大长度 100，6 个上下文特征。对齐前的有效序列长度为 8,298 个token，导出时最大对齐序列长度为 8,320。
基准协议报告每逻辑请求的延迟。对Dynamo-Triton AOTI基准，每次Dynamo-Triton调用包含一个逻辑batch，每逻辑请求延迟由端到端通过时间除以Dynamo-Triton调用次数与逻辑batch大小的乘积得出。数据集加载、验证、重分批、用户ID生成、服务器启动、预热和预热后休眠不计入测量时间。
- 硬件为NVIDIA RTX PRO 6000 Blackwell Workstation Edition GPU。
- 该基准同时比较Dynamo-Triton的PyTorch AOTI后端与Python后端，并衡量GPU KV缓存带来的额外延迟下降。
- 延迟数字仅对应上述固定配置和单张GPU。
后端对比与batch size扩展结果
NVIDIA称，在Dynamo-Triton batch size 2时，即使没有KV缓存命中，PyTorch AOTI相比Dynamo-Triton Python后端也已改善延迟；在GPU KV缓存（20 GB）有命中的情况下，延迟改善显著更大。NVIDIA将收益区分为两部分：AOTI降低相对Python后端的服务开销；KV缓存命中通过复用缓存的序列状态减少模型计算。缓存收益在更深的八层模型上尤其明显。
按batch size的PyTorch AOTI后端结果显示，随着逻辑batch size增大，KV缓存越来越有效。在batch size 8时，三层HSTU模型在GPU KV缓存命中下达到每逻辑请求 0.423 毫秒，八层模型为 0.678 毫秒。
- batch size 8、GPU KV缓存命中下：三层HSTU每逻辑请求 0.423 毫秒，八层 0.678 毫秒。
- 相对同一AOTI配置但不带KV缓存，三层最高提速 4.47 倍，八层最高提速 5.93 倍。
- NVIDIA称缓存收益随序列变长和模型变深而增大，因为原本要在多个HSTU层中重复计算。
适用条件与复现入口
NVIDIA表示，该方案在“连续请求共享用户交互历史中一段不变前缀”时尤其有价值：模型可复用那部分序列的缓存KV状态，只计算新追加token所需的部分。潜在节省随序列长度和模型深度增加，因为否则重复计算会在多个HSTU层上叠加出显著延迟。
NVIDIA建议从NVIDIA/recsys-examples GitHub仓库复现和扩展该工作流。HSTU总览介绍GR模型结构，包括上下文token、item token、action token、embedding表、HSTU block和预测头；AOTI推理指南则涵盖构建所需镜像与库、准备KuaiRand-1K数据、训练checkpoint、导出KV缓存AOTI模型、用C++回放验证、打包Dynamo-Triton运行时镜像，以及通过Dynamo-Triton服务器回放请求。
- NVIDIA称推荐系统受严格延迟预算约束，额外排序延迟会影响页面加载、信息流响应和广告投放截止时间。
- 该博客由NVIDIA跨团队完成，致谢J、Runchu Zhao、Yulu Liu、Lin Hu、Zhuofan Li、Jacob Subag和Tomer Bar-On。