@PyTorch：生成式推荐系统将个性化重构为基于用户行为的序列建模，NVIDIA recsys-examples 提供端到端推理工作流

生成式推荐系统（GR）正在成为大规模个性化推荐的一种强大新方法。与将推荐拆分为孤立的检索、排序和预测阶段不同，GR 将推荐重新定义为对用户行为的序列建模。用户的交互、上下文信息、候选物品和操作被转化为高基数事件流中的 token，模型从中学习生成或预测下一个相关物品。

这种方法对现代推荐工作负载尤其具有吸引力——用户历史记录可能很长，物品目录不断变化，个性化质量依赖于对丰富序列行为的建模。但它也引入了一个服务化挑战：GR 模型需要在长历史记录、大 embedding 表和序列化模型架构的条件下实现低延迟推理。

NVIDIA Dynamo-Triton（https://developer.nvidia.com/dynamo-triton）（原 NVIDIA Triton Inference Server）现在支持通过 NVIDIA recsys-examples（https://github.com/NVIDIA/recsys-examples/tree/v26.06.01/examples/hstu/inference_aoti）仓库实现端到端的层级序列转导单元（HSTU）GR 推理工作流。该工作流结合了 HSTU（https://github.com/NVIDIA/recsys-examples/blob/main/examples/hstu/README.md）、PyTorch 即时编译（AOTI）（https://github.com/triton-inference-server/pytorch_backend#pytorch-20-models）、FlexKV 支持的 KV 缓存（https://github.com/taco-project/FlexKV）、原生 C++ 验证（https://github.com/NVIDIA/recsys-examples/blob/v26.06.02/examples/hstu/inference_aoti/README.md#exported-model-package）、NV Embedding Cache（https://github.com/NVIDIA/nv-embedding-cache）以及 Dynamo-Triton 部署（https://github.com/triton-inference-server）。

最终结果是一条兼具卓越延迟性能的 HSTU 排序模型服务化路径。在 NVIDIA RTX PRO 6000 Blackwell Workstation Edition（https://www.nvidia.com/en-us/products/workstations/professional-desktop-gpus/rtx-pro-6000/）GPU 上以动态 batch size 8 运行时，Dynamo-Triton 搭配 PyTorch AOTI 在 GPU KV 缓存命中率 100% 的条件下，相对于相同 AOTI 配置但不使用 KV 缓存的场景，三层 HSTU 模型最佳加速比达到 4.47 倍，八层模型达到 5.93 倍。

本文介绍如何使用 NVIDIA Dynamo-Triton、PyTorch AOTI 和 FlexKV 将 HSTU 生成式推荐模型从 PyTorch 开发环境迁移到生产推理环境。你将了解如何导出并提前编译模型、如何在 Python 和原生 C++ 中验证生成的部署产物，以及如何在不为单独运行时重写模型的情况下通过 Dynamo-Triton 提供服务。

本文还探讨了 GPU 支持的 KV 缓存如何减少重复计算，并展示了高达 5.93 倍延迟降低的基准测试结果，凸显了这一部署工作流的实际性能收益。

为什么选择 HSTU 做生成式推荐？https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#why_use_hstus_for_generative_recommendation

HSTU 是为在高基数、非平稳事件流上运行的 GR 工作负载而设计的。在传统推荐系统中，检索和排序通常由一系列专门的模型和特征管道构建。而 GR 将推荐建模为序列预测问题，使模型能够在统一的序列感知架构中同时推理用户上下文、物品历史、操作历史和候选物品。

在 NVIDIA HSTU 排序示例中，模型输入由类别型 token 构成。上下文 token 表示用户侧信息，物品 token 表示物品，可选的操作 token 表示用户与这些物品的交互。

图 1. 传统深度学习推荐模型（左）与生成式 HSTU 工作流（右）对比

HSTU 预处理路径检索 embedding，当存在操作 token 时将物品 embedding 与操作 embedding 交替排列，追加上下文信息，并应用位置编码。HSTU 模块处理序列，预测头生成多任务排序输出。

这种结构非常适合近期性、顺序性和重复交互模式重要的推荐场景。然而，这也意味着当每个请求都重复处理长历史序列时，推理成本可能很高。生产系统需要在保留 HSTU 建模优势的同时，减少服务化过程中的冗余计算。

为什么大型序列推荐系统的服务化具有挑战性？https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#why_is_serving_large_sequential_recommenders_challenging

服务化大型序列推荐模型与服务化一个小型稠密排序模型完全不同。服务化栈必须处理不规则的序列输入、大型类别型 embedding 状态、长历史记录，以及同一用户可能反复出现但只有少量新信息的请求模式。每次请求都为用户历史重新计算完整的键值（KV）状态会浪费计算资源并增加延迟。

这就是 KV 缓存变得重要的原因。KV 缓存存储了先前序列计算中可重用的键值数据，使模型能够避免重新计算已缓存的用户历史部分。对于推荐推理而言，当用户的长期历史基本稳定而新的候选物品或近期操作到达时，这种机制尤为有用。

图 2. HSTU 服务化示意

NVIDIA HSTU 推理工作流包含一个使用 GPU 内存和主机存储进行 KV 数据缓存的 KVCacheManager（https://github.com/NVIDIA/recsys-examples/tree/v26.06.01/corelib/recsys_kvcache_manager）。GPU 缓存组织为分页 KV 数据表，支持查找、分配、追加和淘汰操作。当 GPU 缓存空间受限时，较旧的用户可以按照 LRU 策略被淘汰。主机端存储提供了 KV 数据缓存的另一个层级，该工作流还包含一个基于 FlexKV 的 KV 缓存运行时后端。

HSTU 注意力内核可以消费来自分页缓存的 KV 数据，导出的推理路径包含缓存感知的自定义操作，用于查找、分配、注册、追加和卸载。这使得服务化路径能够在保留模型序列语义的同时减少冗余计算。

使用 PyTorch AOTI 实现原生推理 https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#pytorch_aoti_for_native_inference

PyTorch AOTI（即即时编译，Ahead-of-Time Inductor）工作流从 PyTorch 模型出发，使用 torch.export 和 PyTorch AOTI 进行导出。AOTI 将模型提前编译为可由原生 C++ 运行时加载的包。这降低了 Python 运行时开销，并为 Dynamo-Triton PyTorch AOTI 后端提供了一个部署友好的产物。

图 3. PyTorch AOTI 工作流

导出的模型包包含 AOTI 模型归档文件以及元数据和 embedding 表文件。在 NVIDIA 示例中，embedding 实现将 DynamicEmb 推理 embedding 表与 NV Embedding Cache（https://github.com/NVIDIA/nv-embedding-cache）相结合——仅将热门 embedding 保存在 GPU 内存中，同时将完整表保留在 CPU 内存中，从而降低 GPU 内存占用。导出路径将层元数据和 embedding 表数据与编译好的 .pt2 归档文件一起写入，使模型加载时无需多余的 embedding 表副本。

该工作流从多个维度验证相同的导出产物。Python 导出脚本生成包并回放张量。原生 C++ 可执行文件加载导出的模型并进行回放，以验证正确性和性能。Dynamo-Triton 部署使用相同的 AOTI 包和回放路径，这有助于保持开发验证与生产服务化的一致性。

Dynamo-Triton 部署路径 https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#dynamo-triton_deployment_path

Dynamo-Triton 为导出的 HSTU 模型提供生产服务化层。AOTI 部署使用 Dynamo-Triton PyTorch 后端（https://github.com/triton-inference-server/pytorch_backend#aot-inductor-support-beta）并配置 platform: "torch_aoti"。这使得 Dynamo-Triton 能够加载并服务提前编译好的 PyTorch 模型包。

完整工作流包含以下五个阶段：

• 构建所需的自定义算子和运行时库
• 使用 PyTorch AOTI 导出 HSTU 排序模型
• 启动基于 FlexKV 的 KV 缓存服务
• 使用原生 C++ 回放验证导出产物
• 使用 Dynamo-Triton 服务导出的 KV 缓存 AOTI 模型

这种方法之所以重要，是因为推荐系统服务化需要的不仅仅是快速的模型内核。Dynamo-Triton 提供模型仓库管理、请求处理、后端集成、监控指标和部署结构。AOTI 提供了更低开销的编译模型产物。NV Embedding Cache（https://github.com/NVIDIA/nv-embedding-cache）通过仅在 GPU 内存中保留 embedding 表的热门部分来降低 GPU 内存需求。FlexKV（https://github.com/taco-project/FlexKV/tree/main）通过缓存注意力块来减少长用户历史的重复计算。这些技术共同构成了一个面向真实生成式推荐推理场景的服务化栈。

图 4. HSTU 生成式推荐推理栈（含 Dynamo-Triton）

HSTU 服务化延迟基准测试 https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#benchmarking_hstu_serving_latency

本基准测试比较了不同 Dynamo-Triton 后端、模型规模、batch size 和 KV 缓存状态下 HSTU 的服务化延迟。

其目标是量化生产级 HSTU 服务化栈的性能收益。该测试将 Dynamo-Triton PyTorch AOTI 后端与 Python 后端进行对比，衡量 GPU KV 缓存带来的额外延迟降低，并评估这些收益在不同模型深度和 batch size 下的扩展性。最终，它向开发者展示了从基于无缓存 Python 的推理迁移到使用 Dynamo-Triton 的编译化、缓存感知 HSTU 部署后所能获得的性能表现。

recsys-examples（https://github.com/NVIDIA/recsys-examples/blob/v26.06.02/examples/hstu/inference_aoti/benchmark/README.md#benchmark-results）中的基准测试结果（https://github.com/NVIDIA/recsys-examples/blob/v26.06.02/examples/hstu/inference_aoti/benchmark/README.md#benchmark-results）使用 KuaiRand-1K 排序配置，在单 GPU 上运行。模型结构包含三层和八层 HSTU 变体，隐藏维度 512，四个注意力头，BF16 模型权重，BF16 KV 缓存，最大历史序列长度总计 8,192（4,096 个物品加操作对的历史流），最大候选序列长度 100，以及六个上下文特征。对齐前的有效序列长度为 8,298 个 token，导出时使用最大对齐序列长度 8,320。

基准测试协议报告每个逻辑请求的延迟。对于 Dynamo-Triton AOTI 基准测试，每次 Dynamo-Triton 调用包含一个逻辑 batch，每个逻辑请求的延迟计算方式为：端到端通过时间除以（Dynamo-Triton 调用次数 × 逻辑 batch size）。数据集加载、验证、重新分批、用户 ID 生成、服务器启动、预热以及预热后的休眠时间均不计入测量时间。

用于 Dynamo-Triton 后端对比和 batch size 结果的硬件为 NVIDIA RTX PRO 6000 Blackwell Workstation Edition GPU。

Dynamo-Triton 后端对比 https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#dynamo-triton_backend_comparison

在 Dynamo-Triton batch size 2 时，即使没有 KV 缓存命中，PyTorch AOTI 相比 Dynamo-Triton Python 后端也能降低延迟。在 20 GB GPU KV 缓存产生命中的情况下，延迟改善更加显著。

图 5. 三层和八层 HSTU 的 Dynamo-Triton 后端对比

这些结果展示了两方面的收益。第一，AOTI 相比 Python 后端降低了服务化开销。第二，KV 缓存命中通过重用已缓存的序列状态来减少模型计算量。缓存在更深的八层模型上收益尤为明显，因为避免重复计算的影响更大。

AOTI 与 KV 缓存的 Batch Size 扩展性 https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#batch-size_scaling_with_aoti_and_kv_cache

PyTorch AOTI 后端按 batch size 的测试结果表明，KV 缓存随着逻辑 batch size 的增大而变得更加有效。

图 6. 三层 HSTU，Dynamo-Triton batch size 扩展性

图 7. 八层 HSTU，Dynamo-Triton batch size 扩展性

在 batch size 8 时，三层 HSTU 模型在 GPU KV 缓存命中条件下达到每个逻辑请求 0.423 毫秒的延迟。八层 HSTU 模型达到 0.678 毫秒。对于长序列排序推理而言，这些都是出色的结果，证明了将编译化模型执行与缓存感知服务化相结合的价值。

加速 HSTU GR 推理的收益是什么？https://developer.nvidia.com/blog/deploying-an-hstu-generative-recommender-with-nvidia-dynamo-triton/#what_are_the_benefits_of_accelerating_hstu_gr_inference

推荐系统运行在严格的延迟预算之下。额外的排序延迟会影响页面加载时间、信息流响应速度和广告投放截止时间。与此同时，越来越注重序列感知和个性化的模型可能需要更多的推理计算，尤其是随着用户历史记录不断增长。

HSTU 服务化工作流结合了多种互补技术来应对这一挑战。HSTU 提供了生成式推荐架构，PyTorch AOTInductor 生成提前编译的部署产物，基于 FlexKV 的 KV 缓存实现了已计算注意力状态的重用，NVIDIA Dynamo-Triton 提供了生产级服务化环境。