小红书CCD感知编排技术突破多核CPU向量搜索性能瓶颈

在数据库与数据工程领域的顶级会议ICDE 2026上，小红书引擎架构团队发表了一篇题为《CCD–Level and Load-Aware Thread Orchestration for In-Memory Vector ANNS on Multi-Core CPUs》的论文。该研究深入探讨了工业界向量检索服务中一个普遍存在的性能瓶颈：为何在现代多核CPU上，增加核心数量却无法带来线性的性能提升？

研究团队提出了一种创新的“CCD级负载感知线程编排”框架。该方案专门针对AMD EPYC等采用CCD（Core Complex Die）芯粒架构的服务器CPU，通过感知CPU缓存拓扑与实时业务负载，系统性地解决了内存向量近似最近邻搜索（ANNS）的性能扩展难题。在实际业务测试中，该框架使小红书搜索、推荐及广告系统的向量检索吞吐量最高提升3.7倍，P99.9长尾延迟降低30%至90%，同时显著降低了CPU缓存未命中率与总停顿时间。

论文链接：https://arxiv.org/abs/2605.10090

01、背景与核心挑战

1.1 向量检索的性能扩展困境

近似最近邻搜索（ANNS）是支撑现代搜索引擎、推荐系统与广告匹配的核心技术，其目标是从海量高维向量中快速找出与查询最相似的条目。目前，基于图索引的HNSW算法与基于倒排索引的IVF算法已成为工业界主流解决方案。

以小红书为例，其核心业务每日需处理数千万QPS的向量检索请求，背后涉及数千张规模从百万至百亿不等的向量索引表。为满足严格的低延迟要求，基于CPU内存的向量索引是线上服务的首选方案。

为应对业务增长，团队引入了核心数众多的AMD EPYC系列CPU。例如，第四代Genoa处理器单颗可集成12个CCD，共计96个物理核心。然而，实际部署结果却令人意外：在96核全开运行HNSW时，吞吐量仅达到理论峰值的82%；IVF在启用2至12个CCD时，加速比也仅在1.6到2.8倍之间，远未实现理想的线性扩展。

问题的根源在于，现有线程调度框架对CPU内部的CCD拓扑结构缺乏感知。线程被随机分配到不同CCD，导致大量的跨CCD缓存失效。新增的计算核心不仅未能提升性能，反而因缓存污染与内存带宽竞争，拖累了整体效率。

1.2 论文的核心贡献

本论文的贡献主要体现在三个方面，为业界提供了系统的解决方案。

首先，研究首次系统性地刻画并量化了工业级向量检索服务在CCD架构CPU上的负载特征，包括访问局部性分布、跨CCD流量倾斜原因及长尾延迟来源，为性能优化奠定了坚实的数据基础。

其次，提出了一套CCD感知的冷热自适应映射算法。该算法能根据实时流量，动态地将不同的向量索引表调度至合适的CCD上执行。其核心思想是“冷热配对”，避免多张高热度表集中于同一CCD内竞争资源，从而实现流量均衡与缓存高效利用。

最后，设计了一种拓扑感知的层级化任务窃取策略。该策略突破了“缓存亲和性与负载均衡难以兼得”的工程困局，通过建立“本地->同CCD->跨CCD”三级任务窃取优先级，在保证负载均衡的同时，将损害缓存性能的跨CCD任务迁移降至最低。

02、问题深度剖析

2.1 现有调度研究的局限性

在向量检索领域，研究长期聚焦于算法本身，如优化图结构或量化精度。HNSW和IVF的开源实现（如hnswlib和FAISS）已成为行业标准。在多核并行方面，业界通常依赖OpenMP等通用框架，或采用类似百度bthread的、基于全局任务窃取的自研线程池。

然而，无论是OpenMP还是bthread，其调度逻辑均未考虑CCD这一独特架构。每个CCD芯粒拥有独立的L3缓存，这与传统的NUMA架构存在本质区别。操作系统对CCD的感知与支持也非常有限。在CCD架构上运行向量检索，犹如用旧规则管理新交通网络，必然导致拥堵与低效。

2.2 跨CCD调度破坏缓存亲和性

CCD架构的性能关键在于其独立的L3缓存。假设同一张向量表（如存储热门商品特征的索引）的查询请求被随机分发至不同CCD的线程处理，那么每个CCD的L3缓存都需要独立加载该表数据，无法共享，造成巨大的内存访问冗余。

以HNSW查询为例，其过程类似于在图中进行随机游走，会反复访问某些关键“热点”节点。若这些查询分散于多个CCD，则每个CCD的缓存都需存储一份热点数据，不仅挤占宝贵缓存空间，还导致缓存频繁被驱逐，命中率大幅下降。线上数据分析证实，向量表访问遵循典型的“二八定律”，少数热表承载了绝大部分流量，这恰恰凸显了CCD感知调度策略的必要性。

2.3 热表同驻引发缓存污染

即便一张表仅在一个CCD上处理，问题仍未完全解决。若多张高流量“热表”被调度至同一CCD，它们将激烈争夺仅有的32MB L3缓存空间。不同表的数据量可能相差悬殊，从数万到上千万向量不等。当多张“大表”同驻时，其热点数据会相互驱逐，导致缓存实际效用远低于预期。

实测数据显示，在未优化的轮询调度策略下，L3缓存未命中率比优化后高出6%至30%。大量本应在高速缓存中完成的计算，被迫降级为慢速内存访问，CPU不得不空转等待数据，利用率自然难以提升。

2.4 全局任务窃取损害访问局部性

bthread等框架采用的全局任务窃取策略，初衷是最大化资源利用——让空闲CPU核心协助忙碌核心。但在CCD架构的向量检索场景下，它却成了“性能杀手”。

当一个CCD上的线程空闲时，它可能从另一个CCD的线程那里“窃取”任务执行。该任务所需数据并不在当前CCD的缓存中，从而引发完整的缓存失效与重新预热。线上监控显示，在未优化的bthread调度下，HNSW和IVF场景的跨CCD任务窃取率分别高达75%和80%。几乎每一次“互助”都伴随着一次性能惩罚。

图片

03、CCD感知自适应线程编排框架设计

针对上述三大核心问题，小红书团队设计了一套名为“CCD感知自适应线程编排框架”的解决方案。该框架作为独立中间层，嵌入于现有向量索引库与底层调度系统之间，对上层算法完全透明，无需修改核心代码即可直接替换。

图片

整个框架围绕三个核心模块构建：统一任务提交接口、冷热感知映射调度器以及拓扑感知层级化任务窃取机制。

3.1 统一任务提交接口

为兼容HNSW和IVF这两种并行模式不同的算法，框架设计了一个统一的抽象层，支持两种并行粒度：

一种是“表间并行”，适用于HNSW。每个查询作为独立任务，在单个核心上完整执行。同一张表的大量查询会被尽量调度至同一CCD内的多个核心并行处理。这样，该CCD的L3缓存便能有效沉淀该表的热点图数据，供后续查询复用。

另一种是“表内并行”，适用于IVF。单个查询被拆分为多个子任务（如扫描不同的聚类列表），在同一CCD内的多个核心上并行执行，最后汇总结果。此方式能显著降低单次查询延迟。

该设计使得替换现有系统中的调度逻辑极为简便，工程改造成本极低。

图片

3.2 冷热感知映射调度器

此调度器是框架的“决策大脑”，负责决定每张向量表应由哪个CCD服务，并能根据流量变化动态调整决策。

它首先在线估算每张表的内存访问压力。随后，采用“贪心双端扫描”算法进行智能分配：每次选取最“热”的表，将其分配给当前总负载最“轻”的CCD；同时，将最“冷”的一张表也配对该CCD。这种“冷热配对”策略旨在实现各CCD总体负载均衡，并避免多个“高热表”聚集争夺缓存资源。

图片

业务流量存在波动，表的“热度”也会变化。为此，框架采用双时间窗口机制：一个快速窗口（如10秒）捕捉短期波动，一个慢速窗口（如60秒）把握长期趋势。当检测到映射关系与实际流量偏差过大时，系统会在后台生成新调度方案，并通过版本隔离实现平滑切换，确保重映射期间服务无感知。

3.3 拓扑感知的层级化任务窃取

静态映射解决了大部分问题，但无法应对实时、细粒度的负载波动。框架通过一套感知硬件拓扑的任务窃取机制，实现动态负载均衡。

该机制建立了三个明确的优先级：

第一优先：本地执行。 线程优先处理自身本地队列的任务，无任何额外开销。

第二优先：CCD内部互助。 若本地无任务，线程会向同一CCD内的“邻居”线程请求任务。由于共享同一块L3缓存，窃取任务所需数据很可能已在缓存中，性能损失极小。

最后手段：跨CCD支援。 仅当同一CCD内所有线程均空闲，而其他CCD已严重过载时，才允许触发跨CCD任务窃取。此时，缓存失效的代价相对于核心闲置而言是可以接受的。

通过这三级策略，跨CCD任务窃取率从原先的75%-80%骤降至10%以下，在维持系统整体负载均衡的同时，最大程度保障了缓存亲和性。

图片

04、实验验证与性能评估

4.1 实验环境设置

为验证框架有效性，团队在真实硬件与业务数据上进行了全面测试。硬件采用多代AMD EPYC处理器，测试数据来自小红书线上真实的HNSW和IVF向量表，负载为实际业务流量。

实验设置了多个对照组，包括未优化的基线版本（V0）、仅做CCD绑定的版本（V1）以及完整的CCD感知框架（V2）。

4.2 吞吐量与扩展性提升

图片

实验结果显著。在96核CPU上，HNSW场景中，完整框架（V2）的饱和吞吐量突破10万QPS，而基线版本仅约7万QPS。更重要的是，随着启用CCD数量从4个增至12个，V2展现出近乎线性的扩展能力，成功打破了原有方案在82%利用率附近的瓶颈。

在IVF场景下，收益更为突出。由于IVF单次查询访问数据量更大，跨CCD缓存失效代价更高，因此优化后的吞吐量提升幅度超过HNSW。

4.3 延迟性能显著改善

图片

延迟优化，尤其是长尾延迟的降低，对用户体验至关重要。实验表明，在相同负载下，P50延迟降低30%-50%，而P99.9延迟更是降低60%-90%。此前，长尾延迟的主要成因正是偶发的高代价跨CCD任务窃取。新框架从根本上解决了这一问题。在长达1000秒的持续压力测试中，优化后的延迟曲线平滑稳定，而旧方案则不时出现高达数倍的延迟尖峰。

4.4 硬件指标深度分析

通过监控CPU性能计数器，可从硬件层面直接观测优化效果：L3缓存未命中率显著下降，意味着更多计算在高速缓存中完成；CPU停顿时间占比大幅减少，说明CPU“空等”内存数据的情况得到改善。这些硬件指标的变化，从底层印证了框架设计思路的正确性。

05、结论与未来展望

本研究系统性地剖析并解决了向量检索在CCD多核CPU上的性能扩展难题。所提出的框架通过冷热感知映射和拓扑感知任务窃取两大创新，巧妙平衡了缓存亲和性与负载均衡这一长期矛盾。最终，在不更换硬件、不重写核心算法的前提下，实现了最高3.7倍的吞吐量提升及高达90%的长尾延迟降低。

目前，该论文中的关键技术已于今年4月申请专利。

06、团队介绍

本项工作由小红书引擎架构团队完成。该团队长期专注于构建AI时代的搜索、推荐、广告一体化架构，深耕“存储-检索-计算”技术闭环，在大数据处理、索引检索、模型优化等领域拥有深厚积累。团队技术成果曾发表于WWW、ICDE、OSDI等顶级学术会议，并荣获CIKM 2024最佳应用研究论文奖，持续通过技术创新驱动小红书各项核心业务发展。

本论文主要作者包括黄宇辰、马百腾、孙一平、石旸、陈晓、钟晓诚等。