2026 ICDE精选：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 CPU缓存感知调度研究

向量检索领域的优化长期聚焦于算法层面，如图结构设计与量化技术。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 Hot-Hot同驻引发的缓存污染

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

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

2.4 全局任务窃取破坏访问局部性

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

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

图片

03、系统设计

针对上述三大症结，小红书团队设计了一套名为“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最佳应用研究论文奖，持续通过技术创新驱动小红书各项核心业务发展。

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