小红书精读：Hybrid GPU-CPU Retrieval for Personalized Search at Ultra-Large Scale

GPU显存塞不下万亿库存，他们拆成两路

各位算法同学们，把全量库存塞进 GPU 显存这条路，Meta 自己承认走不通了。这篇把「个性化要深度、检索要广度」的矛盾拆成两条路并行跑，而且已经是线上系统。

📄 Hybrid GPU–CPU Retrieval for Personalized Search at Ultra-Large Scale

🔧 不换模型，换编排：两条路径各自选库存、各自发布版本、各自设 deadline，单条路能独立关掉回滚，候选最后在聚合层按 doc id 去重，再进共享排序器。

🧩 GPU 侧维护约十亿文档的池子，按「搜索价值」而不是热度筛，教程、本地指南这类低互动但高查询价值的内容会被保住；超过一年的内容只有不到 0.1% 进常青池。

⚙️ GPU 路径把两塔检索和 DeepFM 交互预排序联合训练，InfoNCE 加 Smooth L1 加 BCE 一起优化，候选离开 GPU 前就已打过交互分；CPU 路径用独立 embedding 索引加轻量个性化打分，库存约为 GPU 的二十倍。

📊 全系统 A/B 对比老的纯 CPU 配置，模型相关性打分和实质性互动都有提升，另给了保守的跨天依赖鲁棒 GSRR 区间。

📈 检索日志按来源归因显示，两条路径产出的候选在结构上确实不同，不是互相重复。

✅ 容量账算得硬：匹配的宽向量方案里，GPU 加速器年化成本约是 CPU 的 4 倍，把深度给 GPU、广度给 CPU 有经济依据。

总结：做十亿级以上检索或推荐的同学，这篇的价值在分工方式而不是模型结构。盯模型相关性打分和实质性互动，只看 ANN recall 会漏掉一半目标。落地坑在两套库存的版本对齐、去重接口和 GPU 池筛选策略——池子选错，深度再高也救不回来。

原文：AlphaXiv