RAG 落地后，瓶颈从 GPU 挪到哪
RAG 落地后，瓶颈从 GPU 挪到哪
生成不慢，检索慢
一篇 2024 年的 arXiv 论文（Accelerating Retrieval-Augmented Generation）把 RAG 流水线从头到尾 profiling 了一遍：在一个 50 GB 向量库、生成模型跑在 H100 上的配置里，精确最近邻检索（ENNS）能占掉端到端推理时间的 97%。也就是说，瓶颈根本不在 GPU。
为什么卡在 CPU 侧
向量库太大，塞不进单卡 HBM，只能放在 CPU 主存或磁盘。检索是典型的内存带宽受限任务：每次查询都要扫一遍 embedding 做点积。论文在 Intel Xeon 4416+（8 通道 DDR5-4000）上测，CPU 根本喂不满 DRAM 带宽。GPU 算力虽强，但为这种任务配多卡太贵，且利用率极低。
用近似检索（ANNS）能快点，但论文指出：为保住准确率，ANNS 得返回更多文档给模型，反而把生成侧成本拉高，端到端可能更慢。高质量检索和低成本之间，本质是内存带宽的较量。
主机内存成了主战场
越来越多方案把向量库放在大容量、高带宽的 CPU 内存甚至 CXL 内存扩展上。这意味着 RAG 服务的成本与延迟，越来越取决于 DDR5 RDIMM 的容量和通道带宽，而不是 GPU 张数。
检索侧一旦内存出错，召回的文档就可能错，生成质量跟着掉。HeroTEST 提供模块级 DDR5 RDIMM 宽温测试与可信分级，用真实工况验证模块可靠性，帮 RAG 服务守住检索这条底线。内存选型想稳妥，欢迎找我们。