全栈方案优于点方案：在单一云上运行 AI 的基础设施论点

认为把更多 AI 堆栈放在同一云供应商上并不是因为他们在每个组件上都更好；也不只是因为发票会变少。更可能的是，将对延迟敏感的组件集中在一起可以消除关键工作流中的重广域网往返。

AI 应用与其数据服务之间网络往返会占用模型生成第一个 token 前响应时间预算的一部分。这是你在今天使用许多最佳方案时会遇到的最大问题之一。您可以选择一个供应商进行 GPU 计算，另一个供应商进行向量搜索。也许您想要使用不同的供应商进行对象存储，另一个供应商进行 LLM 推理。这些方案各自都可以表现出色。但您的生产工作负载将感受到它们的综合影响。

本文将使用 DigitalOcean 的 CPU Droplet 作为应用，使用托管的 PostgreSQL（带 pgvector）进行检索，并在私有连接上进行 GPU 推理。从创始人视角看，关键问题是该方案是否能满足产品对质量和响应时间的期望。

如果您的 AI 应用需要检索增强生成方案，查询可以依次经过嵌入函数、向量搜索、过滤、重排、提示词创建、LLM 调用和日志，然后返回结果。如果这些阶段跨越云提供商或地区，每个阶段都可能产生网络延迟。

最佳方案 AI 基础设施是理性的起点

团队很少构建分离式 AI系统，因为他们想避免不必要的复杂性。他们这么做是因为单个产品决策本身就有意义。也许您需要供应商随时可得的特定 GPU。您想要一个具备混合搜索、元数据过滤等功能的高级向量数据库。推理供应商可能提供一组出色的模型、快速冷启动或每个 token 更低的成本。对象存储可能已经存在于组织的主要云中。典型的点解决方案 RAG 架构可能会使用：

• 应用托管在组织当前的云上
• 使用其选定模型提供的 Embedding API
• Pinecone, Qdrant, Weaviate, 或另一个托管向量数据库
• 来自专用计算提供商的 GPU 容量
• 外部模型推理端点

用于追踪和评估数据的独立可观测性服务

每个决策在孤立情况下都可以说得通。负责嵌入的团队会选择在评估集上表现最佳的模型。负责数据库的团队会采用最佳的检索方案。机器学习团队会根据可用性和价格采购 GPU。首席财务官可能会关注每 1M token 的低广告价。

当这些局部优化被拼装成一个同步请求时，问题就会出现。用户查询系统时，他们不关心向量数据库检索数据的速度。他们关心的是从发出请求到获得有用答案所花费的时间。该指标包括连接建立、名称解析、网络传输、加密、排队、重试、检索、提示词传递、推理和流式传输。

因此，性能的真实单位不是组件，而是已完成的应用任务。在交互式 AI 中，许多组件必须在下一个开始之前完成。如果数据库未返回上下文，大模型不会使用它。重排模型不会对未返回的结果进行排名。推理端点在应用程序组装提示词并发出请求之前不会返回响应。并行性可以掩盖一些延迟，但无法消除关键路径上的依赖。

技术机制：网络往返进入关键路径

依赖操作序列中的最长路径称为关键路径。这就是作业能够完成的最短时间。如果操作 B 必须等到操作 A 完成后才能开始，那么它们的持续时间会相加。

考虑一个基本的 RAG 工作流：

1. 应用程序接收到问题。
2. 它将问题发送给嵌入模型。
3. 它将得到的向量发送给数据库。
4. 数据库检索相关段落。
5. 应用程序构建一个包含这些段落的提示词。
6. 它将提示词发送给推理端点。
7. 模型开始生成答案。

这些步骤中有几个是顺序的。在获得查询嵌入之前，我们不能将查询发送到向量数据库。在相关段落返回之前，我们不能构造提示词。在收到完整的提示词之前，模型不能开始使用这些段落。如果这些请求跨越云或地区边界，网络往返时间会被加到每个依赖上。如果这些服务在不同的云或地区运行，网络往返时间将成为每个依赖的一部分。

往返时间是指数据前往远程系统并收到响应所需的时间。它包括穿越物理链路和路由设备、提供商网络以及服务网关的传播。地理位置是影响因素的重要组成部分，但不是唯一因素。拥塞、路由策略、对等关系、丢包以及加密会影响你实际看到的时长。远程请求可能涉及以下步骤：

1. 如果地址未被缓存，需要进行域名系统（DNS）解析
2. 传输控制协议（TCP）连接建立
3. 传输层安全（TLS）协商以建立加密连接
4. 请求的传输
5. 服务端的排队和处理
6. 响应的序列化
7. 将响应传输给应用
8. 反序列化以及客户端处理

连接池可以在请求之间复用部分设置工作。与其为每个请求建立新连接，不如让连接池保持现有连接以备后续请求使用。现代协议还能进一步降低握手开销。

虽然这些优化有所帮助，但它们无法消除地理因素或服务之间的数据传输。即使复用连接，加密连接也必须在网络上传输请求和响应。TCP 规范和TLS 1.3 规范描述了这些底层机制。关键的架构经验很简单：远程依赖不仅仅是服务内部的计算时间。

组件基准测试为何可能误导应用性能

想象一个向量数据库报告称其索引在几毫秒内响应了查询。这个数字很可能准确反映了数据库内部的耗时。然而，它可能无法反映应用程序实际需要等待的时长。我们可以将客户端观测到的时长定义如下：

如果数据库仅报告其执行时间，那么其他所有环节都会被忽略。模型推理基准测试同样存在此问题。供应商可能在生成开始后只给出令牌吞吐量。这未考虑从远程服务检索数据、构建提示词、通过 API 网关处理、在推理队列中等待，或将大型提示词传输到端点所需的时间。

首 token 响应时间对交互式应用通常更有参考价值，因为它反映的是用户从发起请求到看到输出需要等多久。而且根据测量方式的不同，这个指标甚至可以排除请求到达推理服务之前的那些处理环节。因此，架构师需要区分以下几种延迟：

• 数据库执行时间：在数据库内部执行查询所花的时间
• 客户端观测到的检索延迟：从应用发出请求到收到结果的耗时
• 推理排队时间：请求在队列中等待模型执行的耗时
• 模型预填充时间：处理输入提示词所花的时间
• 首 token 响应时间：从请求开始到第一个生成 token 就绪前的耗时
• token 间延迟：相邻生成 token 之间的间隔
• 端到端延迟：从用户发起请求到拿到最终结果的总耗时

某个组件的性能提升了，端到端表现却可能几乎没变化。这正是为什么单靠“最快的 GPU”“最快的向量数据库”这类对比，不足以在顶尖单品和全栈 AI 基础设施之间做出抉择。

串行调用如何放大距离带来的代价

单次远程调用通常只会增加少量延迟，问题出在多次调用串行执行的场景。设想一个 AI 客服智能体，它需要：

1. 获取客户的账户数据。
2. 搜索产品知识库。
3. 检索适用的服务政策。
4. 携带合并后的上下文调用模型。

如果前三步操作都要跨远程边界且串行执行，网络延迟就会层层累加。这一关系可以表示为：

这只是个计算示例，并非基准测试结果。

假设你从自己的部署环境中采集了一组数据，发现远程调用比同地部署多花 40ms。如果某个工作流需要 4 次调用，就可以算出来：4 × 40 毫秒 = 160 毫秒。这里的 40 毫秒只是假设值，实际必须针对特定区域、云服务商、协议和工作负载去采集数据。这个计算只是为了说明调用次数为什么重要。

对于并行调用则不同。当有 4 次远程调用同时进行时，它们的延迟并不一定直接相加。通常，工作流会等待最长的请求完成。这意味着通过并行执行可以隐藏部分延迟。然而，许多 AI Agent 操作无法并行化。Agent 可能需要先得到一次工具调用结果，才能决定下一步调用哪个工具。它可能会先搜索、检查结果、细化查询、再次检索，然后生成最终答案。每一次决策都会产生新的顺序依赖。

更快的 GPU 为何无法解决慢速 AI 应用

升级 GPU 具有吸引力，因为带来的好处看起来很具体。更新的加速器可能提供更多内存、更高的计算吞吐量，或支持低精度执行。然而，优化某一阶段无法消除其他阶段所花费的时间。假设一个应用的预生成路径包含：

• 嵌入生成
• 远程向量检索
• 重新排序
• 提示词构造
• 推理排队
• 模型预填充

更快的 GPU 可能提升模型预填充和生成速度。它不会消除远程向量请求或传输检索到的段落所需时间。这一限制可以通过 Amdahl 定律 来理解，该定律描述了当系统中只有某一部分得到加速时可实现的最大整体提升。如果工作流的 30% 可以提速两倍，则理论上的整体加速可表示如下：

此计算纯属数学推导，并非针对特定产品的声明。其含义在于，工程师需要评估所提出的优化实际上能影响端到端时长的多少。如果检索和网络传输主导了关键路径，昂贵的 GPU 升级可能只会带来 modeste 用户可见改进。在这种情况下，数据布局或减少调用可能是更有效的干预手段。

DigitalOcean 工作示例：应用、检索与推理

以下自管理配置可作为基线。下一节将展示如何替换为托管的专用推理。

1. 在 CPU Droplet 上运行应用。
2. 在 GPU Droplet 上运行推理服务器。
3. 在带有 pgvector 的托管 PostgreSQL 中存储应用记录和嵌入。

将兼容的资源放置在同一地区和 VPC 中。

使用私有网络进行资源间通信。

Droplets 是 DigitalOcean 的 基于 Linux 的虚拟机。DigitalOcean 目前提供多种按需 GPU Droplet 配置。它提供了一个内置 Docker 和 vLLM 的推理优化镜像。vLLM 是一个开源推理引擎，可帮助您服务大型语言模型。您必须检查您想使用的地区有哪些硬件可用。您可以在 虚拟私有云网络 上创建 droplets 并管理数据库。将 VPC 视为数据中心地区内资源的私有网络。VPC 内部的流量不计入带宽使用量。此外，单个 VPC 不会跨越多个数据中心地区。

您可以使用 DigitalOcean 托管的 PostgreSQL 运行向量工作负载，使用 pgvector 和 pgvectorscale。向量存储和搜索在托管的 PostgreSQL 上受支持，但您必须在应用程序中生成嵌入或使用外部嵌入服务。

请求流程： 运行在 CPU 上的应用程序将生成查询嵌入并从 Postgres 私有端点拉取相关段落。它将生成提示词并将其发送到 GPU Droplets 私有地址上的 vLLM。响应将返回给应用程序。可选的重新排名应保持在本地，或在测量中明确包含其远程路径。

测量检索时间、推理调用的首个 token 时间、用户请求的首个 token 时间以及总响应时间。**." 推理时间将包括排队和模型计算，不应被标记为网络往返时间。

此架构无法保证低延迟。数据库配置、索引质量、提示词大小、模型选择、GPU 利用率和应用代码仍然重要。其优势更具针对性：延迟敏感的检索和推理组件可以放置在一起，而不必被不可避免的跨云路径分隔。

选择匹配您工作负载的 DigitalOcean 推理路径

下表列出了关键的部署和连接注意事项，包括私有访问、区域放置、安全以及为指导选择所需的性能检查。

为什么选择 DigitalOcean 而不是另一种单云堆栈？

其他云也可以实现同样的局部性原则。选择 DigitalOcean 的理由在于其部署选项与团队的运营模式相匹配。团队规模较小时，我们可以利用 Droplets、托管 Postgres 和托管推理端点。无需自行构建 Kubernetes 服务方案。这是一种架构选择，而并非说明 DigitalOcean 在所有情况下都更快或更便宜。

如果没有现成的平台团队，您可以使用 DigitalOcean 基准测试能够运行工作负载的最小配置。对于已经在 EKS 或 AKS 上取得成功的团队，迁移应当带来可衡量的收益。

Full-Stack Does Not Mean Using One Product for Everything

统一架构不需要把所有数据和工作负载放入单一数据库。PostgreSQL+pgvector 在应用的数据访问模式需要紧密集成的向量相似性搜索、关系记录、事务、连接和 SQL 过滤时，可以是一个引人注目的解决方案。当工作负载的规模或搜索需求更适合由专门的引擎处理时，这种方法可能不太合适。DigitalOcean 列出了几种向量搜索选项（包括 PostgreSQL、OpenSearch 和 Weaviate）。这些引擎满足不同的需求。架构目标不是统一。而是将通信最频繁且需要同步的服务并置。

例如，团队可以：

• 在推理服务附近运行对延迟敏感的在线索引
• 使用对象存储保存归档文档
• 在请求路径之外运行批量嵌入生成
• 在另一个数据库中存储向量，用于离线分析工作负载
• 仅复制交互式检索所需的数据子集

离线作业可以容忍距离，因为它们不会让用户等待响应。文档摄取、夜间索引、评估、备份复制和批量推理作业可以跨区域运行，而不会产生可见的交互延迟。应优先并置的服务是面向用户的关键路径上的服务。

点解决方案是更好的选择时

此表格说明了何时专用 AI 服务能够证明额外网络延迟和运营复杂性的合理性。

工作负载是异步的 批量推理、文档处理、训练和离线评估可能对每个请求的几十到几百毫秒不敏感。 吞吐量和总成本可能比交互延迟更重要。 请求量较低 使用率低的内部应用可能受益于完全托管的点解决方案。 运行专用 GPU 或复杂的本地基础设施可能会带来不必要的成本和运维工作。 地理或合同要求决定部署位置 数据驻留、客户合同、模型许可和区域可用性可能要求服务在不同环境中运行。 合规和合同要求可能优先于网络局部性。 独立提供商提升韧性 精心设计的多提供商策略可能保护关键应用免受区域或提供商范围故障的影响。 韧性需要经过测试的故障转移、复制的数据、兼容的 API 和明确的一致性规则。仅仅使用多个供应商并不会自动创造韧性。 组织具备强大的分布式系统运营能力 具备成熟的追踪、事件响应、可靠性工程和成本控制的团队可能有效地运行分解的堆栈。 当组织已经能够理解和管理跨提供商依赖时，整合带来的运营优势较小。