推荐系统（RecSys）是消费互联网行业中最普遍的机器学习问题之一，但在大规模训练和服务部署方面难度极高。大语言模型的兴起推动了一场从传统基于嵌入相似度目标向生成式目标的转变——新目标是在给定用户历史行为序列的条件下，预测大型目录中的下一个动作或物品。本文将介绍生成式推荐系统（GR）的架构转变、其在生产环境中带来的挑战，以及NVIDIA recsys-examples与nv-embedding-cache如何应对这些挑战。
生产环境中的核心挑战
用户历史是RecSys的主要数据类型，记录了用户与目录中物品的交互行为。与文本或图像等模态不同，用户历史涉及随时间频繁变化的类别特征与连续特征的混合。在行业规模下，这类数据每天可达到TB乃至PB量级。即便在最高端的硬件加速器上，如此体量的数据也无法装入GPU的高带宽显存（HBM），从而在训练和推理过程中引入大量瓶颈。
推荐系统中的长尾问题，描述的是目录中少数热门物品占据绝大多数交互的现象。由于目录中的物品数量可能远超用户数量，导致用户-物品交互数据极为稀疏。与某一物品发生交互的概率分布严重偏向热门物品，使得训练数据对代表用户真实偏好的大量小众物品几乎无法提供有效信号。
当新用户或新物品加入推荐平台时，由于缺乏交互历史，无法立即生成高质量的嵌入表示，只能从较少的特征集中推断，这会对推荐质量产生负面影响。尽管可以通过与相似物品及语义描述进行关联来部分缓解这一问题，但初期推荐质量差、影响用户体验的风险仍然存在。
在生产环境中，RecSys模型需要在严格的服务水平协议（SLA）下为数百万用户提供在线服务，延迟的细微增加都会影响用户体验。与可容忍自回归解码延迟的大语言模型不同，RecSys模型必须在几毫秒内完成对数千个候选物品的检索与排序。
生成式推荐系统的架构转变
与传统基于嵌入的推荐系统通过几何相似度建模用户-物品偏好不同，生成式推荐系统将推荐重新定义为类似大语言模型的序列建模问题，目标是对给定用户历史序列条件下下一个动作或物品的概率分布进行建模：P(next_item | user_history)。
这种向更同质化Transformer架构的转变，能够更好地利用规模化定律，有望在单一模型中统一检索与排序，并更自然地融入快速演进的大语言模型生态系统。
目前实现这一目标的两种主流方法是分层序列转导单元（HSTU）和语义ID。
HSTU：高效的生成式推荐架构
HSTU由Meta于2024年提出，是一种基础性生成式推荐模型架构，在生成式目标框架下重新定义了RecSys，并引入了若干关键创新，以在生产规模下实现高效训练和服务。
HSTU将输入数据表示为按时间戳排序的、物品与动作（点赞、点击等）交织而成的用户序列，同时摒弃了传统RecSys模型中常见的显式特征工程，转而通过对用户-物品交互的注意力机制学习序列表示。这种构建方式使用户历史类比于大语言模型中的下一个Token预测，在训练时可以同时从序列内部和跨批次获得有意义的学习信号。
与标准Transformer注意力不同，HSTU对注意力聚合机制进行了修改：用基于SiLU的加权替代softmax归一化，引入相对注意力偏置，并在输出投影前应用逐元素门控。这些改动在保留长序列中更强幅度信息的同时，也实现了更高效的核融合与更低延迟的推理。
语义ID：解决稀疏性与长尾问题
在大规模物品语料库上对稀疏用户-物品交互进行下一物品预测会带来诸多挑战：完整softmax计算的瓶颈、长尾物品训练信号弱，以及对语义相似物品的泛化能力差。
由谷歌提出的语义ID通过对物品嵌入进行层次聚类，生成一组较小的新词汇Token来缓解上述问题。TIGER、PLUM、OneRec v1/v2等架构以及众多现代生成式推荐架构都将语义ID作为可扩展自回归推荐的基础。
与传统RecSys不同，语义ID的自回归解码直接生成推荐结果，无需在嵌入空间中进行搜索，并通过输出logits自然提供排序。束搜索等搜索方法可在单次前向传播中生成多个语义ID，提升吞吐量，并允许选择聚类中的小众物品。
recsys-examples：生产级训练与推理栈
recsys-examples代码库是一系列示例的集合，旨在展示使用PyTorch在NVIDIA GPU上训练和部署生成式推荐系统的最佳实践。它包含HSTU和语义ID模型的优化实现，覆盖训练与推理全流程，并整合了三个模块化组件：用于嵌入层的DynamicEmb、为推荐系统定制的KV缓存与存储管理器，以及用于HSTU和语义ID束搜索解码的高效CUDA算子。
DynamicEmb：突破静态嵌入表局限
传统RecSys中的嵌入表假设词汇表是固定静态的。然而在生产环境中，新用户和新物品持续涌现，物品目录的长尾增长速度远超单个GPU显存的承载能力。过度预留静态表会在从未访问的行上浪费显存，而预留不足则会导致昂贵的数据拷贝，影响模型性能与质量。
DynamicEmb用GPU优化的带评分哈希表取代静态表，按需将任意特征ID映射到嵌入行。行仅在模型实际遇到对应ID时才分配，且哈希表横跨HBM和固定主机内存，可以远超单个GPU容量地增长。该实现基于HierarchicalKV哈希表设计的算法，准入控制与基于评分的淘汰机制的结合，使容量能够集中在对模型训练真正重要的ID上，从而在规模上使长尾问题变得可处理。
DynamicEmb作为TorchRec后端提供，表通过EmbeddingBagCollection和EmbeddingCollection接口在各进程间按行分片。融合CUDA核处理SUM、MEAN和序列池化模式下的查找与梯度规约。预取技术使频繁访问的嵌入常驻HBM，以实现高效访问。
HSTU训练与推理优化
recsys-examples为HSTU提供了生产级的训练与推理栈。物品、用户、动作和上下文嵌入表通过TorchRec管理，DynamicEmb为高基数表提供动态容量与缓存。对于稠密层，HSTU主干使用Megatron-Core，使单次训练运行能够同时利用数据、张量、序列和流水线并行。该库在整个栈上都具有模块化设计，各组件可与自定义架构即插即用。
训练期间，TorchRec/DynamicEmb与Megatron-Core无缝集成，协调嵌入和稠密模块的分片与并行。训练流水线融入了动态打乱以平衡各进程间的工作负载，将嵌入通信与预取和稠密计算重叠，并包含针对NVIDIA Ampere、Hopper和Blackwell GPU优化了融合算子和FBGEMM注意力核的HSTU层。这些优化共同将端到端模型FLOP利用率（MFU）从两个DGX H100节点上的7.65%提升至31.40%，展示了训练效率的显著提升。
推理方面，recsys-examples支持PyTorch AOTInductor在Torch C++运行时中执行模型，同时保持与NVIDIA Triton推理服务器的兼容性，以满足严格的低延迟要求。频繁访问的嵌入通过nv-embedding-cache保持在GPU附近，并通过支持FlexKV的定制KV缓存将缓存条目分布到多个内存层级来进一步减少计算量。
在Triton推理服务器上部署时，使用PyTorch AOTI后端且无KV缓存的推理相比Python后端实现了1.14倍至1.28倍的加速；使用PyTorch AOTI后端并启用KV缓存的推理在理想的全GPU缓存命中场景下实现了2.20倍至2.38倍的加速。
语义ID生成式推荐专用推理框架
基于语义ID的生成式推荐引入了一种与聊天式大语言模型推理截然不同的服务模式：用户上下文长、自回归解码短、在受约束的物品Token空间上使用大束宽。在实际语义ID工作负载中，一个请求可能包含数千个历史Token，仅解码2-3个语义ID Token，并使用128或256的束宽来提升推荐多样性。
现有大语言模型服务系统（如vLLM、SGLang、TensorRT LLM）主要针对分页KV缓存、动态批处理和长解码的多用户聊天式服务进行了优化，是强大的通用框架，但不能自然暴露语义ID生成式推荐所需的核心抽象：共享请求级上下文KV、短的每束解码KV、束路径追踪、动态束宽和物品约束生成。
为此，recsys-examples为基于Qwen的语义ID模型提供了一个生成式推荐专用推理框架示例，将KV缓存分离以隔离与束相关和无关的组件：长共享上下文放入ContextKV，短解码历史放入BeamKV，逻辑束祖先关系放入BeamPath，避免将每个束视为独立的长序列。运行时还包含生成式推荐原生的连续批处理、直接池视图CUDA图重放、物品约束topK，以及直接在生成式推荐KV布局上操作的专用gr-decode_atten后端。
在单块NVIDIA H100 80GB GPU上，使用Qwen3-1.7B、上下文长度1,000和5,000 Token、束宽256、3个输出Token的配置下，生成式推荐专用路径在离线和在线基准测试中均持续优于SGLang束搜索方案。
这使语义ID生成式推荐服务成为recsys-examples中HSTU和嵌入组件的天然补充：HSTU与DynamicEmb解决生产规模的训练和嵌入密集推理，而语义ID生成式推荐推理路径则针对具有长上下文、大束搜索和严格推荐系统延迟要求的自回归语义ID生成。
nv-embedding-cache：多层级嵌入缓存加速
nv-embedding-cache（NVE）是一款用于加速推荐系统推理中大规模嵌入表查找与操作的SDK，提供模块化组件，包括优化核、软件缓存原语和PyTorch兼容绑定，支持对超出单个GPU显存容量的嵌入表进行低延迟访问。
生产推荐系统的嵌入表体量通常超过单个GPU显存的容量，迫使推理系统将嵌入分级存储在多个内存层级中。此外，推荐系统的访问模式通常非常适合缓存。
NVE通过分层查找流程管理这一问题：HBM中的GPU缓存作为热层，DRAM中的CPU缓存作为温层，以及远端参数存储（通常基于Redis或RocksDB）。热键向GPU缓存的提升策略可定制，无锁的失效与提交协议允许查找与缓存修改在GPU上并发运行而不阻塞查找流。跨设备分片通过CUDA虚拟内存处理，使单个逻辑表可以跨越多个GPU或节点。
NVE提供NVEmbedding和NVEmbeddingBag作为torch.nn.Embedding和torch.nn.EmbeddingBag的直接替代，便于与PyTorch生态系统集成。这些模块暴露熟悉的参数，同时增加了特定于缓存的配置项。由于这些层的行为与标准nn.Module组件一致，可以以最少的图修改集成到现有推荐模型中。部署方面，NVE针对LibTorch稳定ABI注册了其查找算子，在C++运行时中提供AOTInductor支持。
recsys-examples的DynamicEmb表在NVE中受到支持，使训练与推理之间的过渡更加顺畅。在基于HSTU的MLPerf生成式推荐系统基准测试DLRM v3上，recsys-examples与NVE实现了在线服务器场景下每秒99,997次查询的推理吞吐量。
Q&A
Q1：生成式推荐系统与传统推荐系统有什么本质区别？
A：传统推荐系统基于嵌入相似度建模用户-物品偏好，通过几何空间中的距离判断相关性。生成式推荐系统则将推荐重新定义为序列建模问题，类似于大语言模型的下一个Token预测，目标是在给定用户历史序列的条件下预测下一个物品或动作的概率分布。这种转变使推荐系统能够更好地利用Transformer架构的规模化优势，有望在单一模型中统一检索与排序，并更自然地融入大语言模型生态。
Q2：HSTU架构解决了推荐系统的哪些核心问题？
A：HSTU主要解决了三个核心问题：一是去除对显式特征工程的依赖，改为通过注意力机制自动学习序列表示；二是通过将用户历史表示为按时间排序的物品与动作交织序列，在训练时同时从序列内和跨批次获取有效学习信号；三是通过修改注意力机制（用SiLU替代softmax、引入相对注意力偏置、添加逐元素门控），在保留长序列幅度信息的同时降低推理延迟，在两个DGX H100节点上将模型FLOP利用率从7.65%提升至31.40%。
Q3：DynamicEmb如何解决大规模推荐系统的嵌入表问题？
A：传统静态嵌入表无法应对生产环境中用户和物品持续增加的场景，要么浪费显存，要么导致频繁的昂贵数据拷贝。DynamicEmb使用GPU优化的带评分哈希表，仅在模型实际遇到对应ID时才动态分配嵌入行，并通过横跨GPU高带宽显存和主机内存的设计突破单GPU容量限制。其基于评分的淘汰机制确保显存集中用于对训练真正重要的ID，从而在规模上有效应对长尾问题，同时通过预取技术保持频繁访问嵌入常驻GPU显存。
