为什么数据局部性比原始GPU速度对RAG更重要

下图展示了 RAG 管道的每个步骤如何增加总响应时间，以及哪些步骤实际上可以通过更快的 GPU 得到加速。

如果该步骤在 GPU 上运行，GPU 升级可以缩短查询嵌入时间。它还可以加速重新排序、提示处理和文本生成（前提是这些步骤同样在 GPU 上执行）。它无法做到的是消除访问位于其他地方的数据库的成本。对远程数据库的单次请求可能包括：

查询地址（DNS）

打开连接（TCP）

建立安全通道（TLS）

网络本身的传输

在提供商之间的路由

在数据库排队等待

执行实际查询

打包结果

将数据发送回去

复用连接可以省去重复的地址查找和连接建立。但它本身无法缩短距离。它也无法缓解网络拥塞、路由变化或跨供应商带来的额外开销。

一个简单的 RAG 演示可能只需一次搜索调用和一次模型调用。实际生产应用通常更复杂。设想一个系统，它会：

1. 将用户的问题转换为向量嵌入。
2. 在向量索引中进行搜索。
3. 根据租户、日期、权限或产品过滤结果。
4. 提取完整的文档块。
5. 从独立表格获取元数据。
6. 重新排序候选结果。
7. 构建最终的提示词。
8. 将该提示词发送给模型。
9. 运行模型。
10. 如果第一批证据不足，则返回获取更多信息。

Agent 风格的 RAG 工作流可以多次重复步骤 1 到 10。模型可能先查询一个来源，查看返回结果，重新表述问题，调用另一个工具，收集更多证据，然后才给出最终答案。

每一步远程操作都会增加一些等待时间。当这些等待时间的总和超过 GPU 所承担的工作量时，更快的 GPU 就不会带来明显提升。

位置比 GPU 速度更重要，但你不能仅凭这一点就下结论。你必须进行测量。GPU 速度的营销数字或普通的网络速度测试都无法提供有用的信息。你需要测量实际的检索调用，并从实际运行模型的机器上计时。

正确的测试会在保持其他一切不变（数据库设置、GPU、数据、查询、应用本身）的前提下移动数据库的位置。至少，公平的测试应保持以下内容固定：

DigitalOcean 托管的 PostgreSQL 已经自带 pgvector，使得 PostgreSQL 能够存储和搜索几种类型的嵌入：

• vector - 标准、全尺寸嵌入
• halfvec - 半精度嵌入，占用空间更小
• sparsevec - 大部分为零的嵌入

它不仅支持精确搜索，还支持两种更快的近似搜索方法 HNSW 和 IVFFlat。DigitalOcean 还支持 pgvectorscale，这是一个附加组件，包含一种称为 StreamingDiskANN 的技术，用于处理内存无法容纳的向量集合。您可以在以下文档中了解更多内容：DigitalOcean Managed PostgreSQL 向量搜索文档。

为了正确测试位置，请保持数据库引擎、数据、索引、查询和 GPU 设置不变，仅更改数据库的位置。这样，位置就是您实际测量的唯一因素。您希望至少比较三种设置：

同一数据中心：GPU Droplet 和 PostgreSQL 数据库位于同一 DigitalOcean 数据中心。

不同地区：相同的 GPU 设置会与一个完全相同的 PostgreSQL 数据库通信，但位于不同地区。其他一切（引擎、套餐、数据、嵌入、索引、查询）保持不变。

一个竞争平台： 我们在这里使用了 Modal，调用了一个单独的托管 PostgreSQL 数据库。

在进行竞争平台比较时，你还应该控制计算和数据库的物理位置。Modal 关于区域选择的官方文档 让开发者可以选择容器运行的位置，并建议将对延迟敏感的计算放置在数据库附近，因为跨区域会带来真实且可测量的延迟。

仅仅选择一个快速的推理平台并不能解决位置问题。你仍然需要将数据库放置在计算附近。否则，由物理距离、网络路由以及在不同提供商之间切换带来的延迟可能会抵消你在其他地方获得的任何速度提升。

以随机顺序运行测试

随机化或交错你的三种设置。向同一数据中心设置发送一个查询，接下来发送到不同区域设置，然后发送到竞争平台，并保持循环。

这可以防止时间偏差影响你的结果。如果你在早上运行同一数据中心测试，几小时后运行不同区域测试，数据库负载或网络流量的变化可能会导致数字偏移。你最终可能会把这种差异归咎于位置，而实际上它仅仅是因为在不同时间进行测试所致。

分别报告热连接和冷连接

持续运行的应用通常会保持一组打开的连接，并且主要使用热连接。在无服务器设置中常见的、会缩放到零的应用则需要更频繁地打开新连接。

如果将热连接和冷连接的结果平均在一起，得到的数字无法准确描述任一情况。应分别报告它们。

把一次跨区数据库调用的网络惩罚视为固定成本。记作 N。一个简单的 RAG 流水线如果只进行一次远程数据库调用，只需支付一次 N。而一种类似代理的流水线——先检索，再检查元数据，然后再次搜索——会为每一次顺序调用各支付一次 N，因为每次调用必须完成后才能启动下一次。如果它连续进行 k 次这样的调用，总的惩罚是 N × k，而不是仅 N。

相比之下，升级 GPU 只会在一次步骤上提速一次，不管你的流水线调用数据库多少次。因此，流水线进行的顺序远程调用越多，网络惩罚就会被放大得越多，而 GPU 的贡献则保持不变。

这只是论点的形状，而不是你自己数字的替代品。这实际上是否对你的应用有影响，取决于你自己的 N 和 k。唯一的办法是在你自己的流水线上运行上面描述的测试，使用你自己的地区和调用模式，然后看结果如何。

数据库请求无法以比携带它的信号在两台机器之间的物理距离上传播更快的速度传播。光在光纤电缆中的传播速度略慢于在开放空气中的速度。而在真实网络中，数据不会沿直线传播。途中，它通常会经过：

• 交换机
• 路由器
• 防火墙
• 网关
• 云服务提供商之间的边界
• 有时会经过拥堵的网络段

这设定了延迟的下限，无论怎样的软件调优都无法绕过。

带宽和延迟是两回事。带宽是指每秒能传输的数据量。延迟是指数据从一个地方到另一个地方所需的时间。一个带宽充足的连接在数据开始流动后可以快速传输大量数据，但这并不意味着第一个字节会到得更早。

DigitalOcean GPU Droplets 在专用网络上最高支持 25 Gbps，在公共网络上最高支持 10 Gbps。这些数据说明了能传输多少数据，而不是说明一个请求到达另一地区的数据库并返回需要多长时间。

向量数据库的请求通常更关注延迟而非带宽。查询嵌入向量通常只有几千字节，返回的结果也不大。传输这么少量的数据不需要太多带宽。真正导致变慢的是往返过程本身（请求到达和答案返回所花费的等待时间），加上在数据库排队的时间，以及搜索本身所需的时间。

尾部延迟会使情况更糟。中位响应时间可能看起来不错，但最慢的 5% 或 1% 请求会花费更长时间，原因可能是网络拥塞、路由变化、数据库积压、新连接打开，或其他工作负载争夺相同资源。这直接影响用户等待答案第一部分的时间。模型只有在所需数据实际到达后才能开始构建响应。因此，首个有用输出的时间比单纯的 GPU 性能更能诚实地衡量真实世界的速度。它涵盖了用户实际等待的每一步，从获取证据、构建提示到 GPU 队列、提示处理以及首位输出。

GPU 基准测试衡量诸如提示处理速度、首次输出时间和生成速度等指标。但用户感知的是整个流水线，而不仅仅是 GPU 所占的那部分。如果数据存放在远处，网络和数据库延迟可能会吞噬，甚至超过你通过使用更快芯片所节省的时间。

两个服务可以在地图上共享一个大致位置，但仍可能运行在不同的云、不同的数据中心、不同的区域或不同的网络。流量仍可能跨越提供商边界，或在公共互联网上传输。真正的目标是将应用、搜索层和模型放在同一个数据中心内，如果可能的话使用私有连接。

DigitalOcean 允许你选择 GPU Droplet 运行的数据中心。运行 pgvector 的托管 PostgreSQL 集群可以位于同样的更广泛的设置中。

这样做会带来以下几点好处：

• 请求的传输距离更短。
• 云提供商之间没有不必要的跳转。
• 减少对外部网络噪声的暴露。
• 数据库访问和网络安全往往更简单。
• 可能降低数据传输成本。
• 端到端监控系统更易于管理。

要明确的是，这并不会让数据库表现得像本地 GPU 内存。托管的 PostgreSQL 仍然是一个在别处运行的独立服务。重点只是尽量让平台允许的范围内把这一不可避免的远程步骤放得尽可能近。

团队应通过直接在运行模型的机器上测量检索时间来确认这一点。仅仅看数据库本身执行查询所需的时间是不够的。这样会遗漏往返 PostgreSQL 所花费的时间。

下面的图表将您的应用实际测得的时间与 PostgreSQL 自报的时间进行比较。两者之间的差距表明了数据库外部增加的延迟，诸如打开连接、网络往返、排队等待、打包结果、将结果发送回来以及在您的应用中处理结果等因素所导致的。

调整 HNSW 索引可能会削减数据库自身所需的 6 毫秒中的一部分。但这种调整无法弥补其余 69 毫秒中的大部分。在假设数据库本身是问题之前，应先检查事物的物理位置、流量如何路由、连接如何池化、结果如何打包和大小，以及您的应用如何协调所有这些步骤。

更快的 GPU 能让您训练更大的模型、使用更多上下文、运行更大的批次，并且每秒能完成更多工作，包括更快的提示处理和更快的生成。但假设 GPU 升级会以相同的比例提升整个流水线是错误的，因为 GPU 只参与请求过程中发生的部分操作。检索、元数据查找和网络传输都发生在 GPU 看到提示之前，而这些步骤仅仅因为 GPU 变快并不会变得更快。

以下是比较的轮廓，不假设知道您的具体数字。RAG 流水线的总响应时间被划分为几个步骤：检索、重排序、提示构建、GPU 上的提示处理以及生成，除此之外还有中间的一些网络开销。GPU 升级只会加速实际上在 GPU 上运行的步骤，主要是提示处理和生成。其他所有步骤（包括检索所需的时间）无论新 GPU 有多快，都将保持不变。

如果检索仅占总时间的很小一部分，GPU 升级在您的指标中会表现得很明显。如果检索占总时间的很大一部分，这是因为您的数据库与模型相距较远，GPU 升级可以加速它所触及的步骤，但由于它无法触及的步骤仍然占据了大部分时间，因此总响应时间几乎不会改变。

想要知道自己处于哪种情况，唯一的办法是逐步拆解自己的流水线，测量时间到底花在了哪里，再决定修复什么。

使用此表格来判断何时应关注数据位置，何时其他因素（如生成速度、成本、检索质量或可靠性）更值得你关注。

对于部署在 DigitalOcean 上的 RAG 应用，合理的起点是把 GPU Droplet 和带 pgvector 的托管版 PostgreSQL 放在同一个区域。尽量使用持久化的数据库连接，能用内网通信就用内网，并在运行模型的机器上测量端到端耗时。在此基础上，对比以下四种可行的改进：

1. 调优向量索引和 SQL 查询。
2. 减少重复的检索和元数据调用。
3. 把检索和模型移到同一个区域。
4. 升级 GPU。

根据实测结果，把精力投入到真正最耗时的那个环节上。

其他平台同样受物理规律约束。Modal 允许开发者把计算资源固定在特定区域，并建议将延迟敏感的任务放在靠近数据库的位置运行。这确实是解决位置问题的实际手段，但也恰恰印证了本文的观点：推理平台再快，也不会自动解决数据放在哪里的问题。

RAG 的响应时间取决于请求经过的整条链路，而不只是 GPU。只顾比较 GPU 性能、却不过问数据库部署在哪里的团队，往往是在优化看得见的部分，而不是真正拖慢速度的部分。更快的 GPU 只能加速 GPU 上的计算；把数据挪得更近，才能省掉 GPU 开工之前白白流逝的时间。在需要反复执行搜索、检索、元数据查询、重排序调用和工具调用的系统里，这些零星节省的时间会迅速累积成可观的收益。

这些改善会体现在多个方面：用户看到首条响应的速度、最慢请求的耗时、系统同时能处理的请求数、基础设施账单，以及 GPU 的实际利用率。这并不是说位置永远比算力更重要，而是说在断定“换一块更快的 GPU 就能解决问题”之前，必须先测量整条链路。

如果应用统计到的检索耗时远高于数据库自报的耗时，答案就已经很清楚了。先把数据挪近、砍掉不必要的远程调用、把检索稳定下来，然后再考虑为新 GPU 花钱。

对大多数生产环境的 RAG 系统来说，想让答案来得更快，最快的办法不是换更快的 GPU，而是缩短到数据的距离。

• 面向向量搜索的托管版 PostgreSQL：介绍 PostgreSQL 向量搜索、过滤以及 pgvector 索引。
• PostgreSQL 向量搜索最佳实践：涵盖精确搜索、HNSW、IVFFlat、过滤、重排序及查询调优的指导。
• 使用 pgvectorscale 和混合搜索处理高级向量工作负载：介绍 StreamingDiskANN 与统计二值量化（Statistical Binary Quantization）的文档，适用于大规模、基于磁盘的向量搜索。
• 托管版 PostgreSQL 向量功能指南：介绍如何在托管的 PostgreSQL 集群上启用 pgvector。
• pgvector：Postgres 开源向量相似度搜索：项目官方文档，涵盖 vector、halfvec、sparsevec 类型、搜索方法及索引配置。
• 区域可用性：说明哪些 DigitalOcean 产品在哪些数据中心可用。
• Droplet 功能特性：GPU Droplet 规格参数，包括网络带宽限制。
• 虚拟私有云文档：介绍 DigitalOcean 各类资源之间私有组网的文档。
• Modal：区域选择：介绍如何将计算固定在特定区域以降低跨区域延迟的文档。