Hadoop 时代的一代人彻底学会了一个教训，以至于它成了一种本能：移动数据是昂贵的，所以要把计算移动到数据所在的地方。每一个 MapReduce 调度器、每一个 HDFS 块放置决策、每一个“数据本地化”（data locality）仪表盘的存在都是为了服务于这一原则。然后，在托管模型 API 的兴起和智能体（agent）热潮之间的某个时刻，我们悄然颠倒了这一原则——而且没有人重新评估这一决策的成本。
看看现代智能体循环（agent loop）实际上在做什么。它从向量数据库中检索一堆文档，从对象存储中提取代码库快照，从六个内部服务中收集工具执行结果，将所有这些内容拼接进一个上下文窗口，然后将整个负载发送到通常位于不同 VPC、不同区域、甚至不同云平台的模型端点。然后在下一轮对话中重复这一过程。周而复始。你的上下文具有质量，而你正在为每一次跳转支付运费。
这些数字绝非舍入误差。在运行高流量推理负载的组织中，出口流量（egress）费用已经占到云总支出的 10%–25%，而智能体从结构上放大了这个问题：一个智能体消耗的 Token 大约是单次对话的 4 倍，而多智能体系统则约为 15 倍。Token 数量是衡量数据传输量的一个不错指标。每一个 Token 都在某处被组装、序列化，并跨越网络边界进行传输，而这些都是要计费的——即使账单条目上从未写着“AI”字样。
无人估价的“反转”
“计算向数据靠拢”原则并非意识形态，而是算术题。在 2010 年代的 Hadoop 集群中，网络是最稀缺的资源，因此调度器会将每个 map 任务分派到已经持有数据块的节点上。跨交换机流量是你需要优化的故障模式。
托管 LLM API 以一种特殊的方式打破了这种算术平衡：计算变得不可协商。你无法在存储数据的节点上运行顶级模型。GPU 位于提供商放置它们的地方，而接口是一个 HTTPS 端点。因此，行业默认选择了唯一剩下的选项——将数据移动到计算端。由于最初的负载很小（一个提示词，几百个 Token），成本是隐形的。
智能体终结了小负载时代。单个智能体轮次通常携带数兆字节的数据：检索到的片段、文件内容、工具输出以及整个累积的对话历史记录，这些内容在每次迭代中都会被重新发送。对生产环境智能体账单的分析一致发现，重复发送的上下文——而非新输入或输出——是主要的成本项，通常占 Token 总支出的 60% 左右。同样的动态也在网络层上演。曾经是包含小消息的频繁交互协议（chatty protocol），现在变成了包含重负载的频繁交互协议，而“频繁交互且重负载”正是出口流量计费惩罚最严厉的流量模式。
数据重力（Data gravity）—— Dave McCrory 很久以前提出的观点，即大型数据集会吸引应用程序向其靠近——原本是关于供应商锁定（lock-in）的一个警告。对于推理负载而言，它已变成了一个字面意义上的成本函数：你的上下文来源距离模型端点越远，每一个智能体轮次的“重量”就越大。
单个智能体轮次中的计费边界
追踪生产环境中智能体的一个轮次并计算上下文跨越的边界会有所帮助。一个典型的企业级 RAG 加工具（RAG-plus-tools）循环如下所示：
向量数据库到编排器。 检索返回 20–50 个片段。如果你的向量数据库是另一个 VPC 或区域中的托管服务，这一跳转在他们那边计收出口流量费，而在你这边可能计收入口处理费。对象存储到编排器。 智能体读取文件——代码库快照、PDF、电子表格。S3 到同区域的 EC2 是免费的；S3 到另一个区域或另一个云平台的费用为每 GB 0.02–0.09 美元。内部服务到编排器。 工具调用扇出到各个微服务。在 AWS 上，每个跨可用区（AZ）的跳转双向各需 0.01 美元/GB，而高可用架构在设计上就是跨可用区的。编排器到模型端点。 组装好的上下文——对话中期通常达到 50,000–200,000 个 Token——被发送到推理提供商。跨云传输时，这将按互联网出口流量的全额费率计费，第一级定价约为 0.09 美元/GB。每轮重复。 一个包含 20 轮对话的智能体会话会重新跨越这些边界 20 次，且随着历史记录的累积，负载在每一轮都会增加。
你的模型提供商发票中不会出现这些跳转费用。Token 定价是可见的成本；而“运费”则散落在云账单中的“数据传输”项下，没有人会将其归因于 AI 项目。那些正确测量这些成本的团队往往会发现，每个智能体会话的实际成本明显高于 Token 计算出的预期——而这一差距几乎完全是由地理位置决定的。
延迟也以同样的方式叠加。每个边界都会增加往返时间，且智能体循环将这些跳转串行化：检索，然后读取，然后调用工具，最后推理。40 毫秒的跨区域检索延迟听起来微不足道，直到它被置于一个每会话运行 15 次的循环中，呈现在体验总延迟的用户面前。
当云原生提供商方案优于 API 时 超级云厂商早已预见到了这一点，这就是为什么会出现“模型向数据靠拢”（bring the model to your data）这类产品。Amazon Bedrock 通过 PrivateLink 连接在 AWS 内部运行推理，因此从 S3 和 DynamoDB 组装的上下文永远不会触及公共互联网。Vertex AI 在 Google Cloud 上通过 VPC Service Controls 实现了同等功能。Azure OpenAI 则为 Azure 资产提供类似服务。合规团队出于数据驻留和 HIPAA 的原因采用了这些方案，但物理层面的论据同样强而有力：同地域、私有网络内的推理能将原本负担最重的跳转（hop）变成成本最低的一环。
决策框架与其说是关于模型质量，不如说是关于你的“引力中心”在哪里：
如果你的上下文来源和流量绝大多数位于同一个云端 ，那么即使每 token 的溢价适中，云内推理通常也是正确的默认选择。你可以消除最粗数据路径上的互联网出站流量，降低每轮对话的延迟，并将敏感上下文保留在信任边界内。支付溢价是为了省去高昂的传输“运费”。如果你需要一个仅通过直接 API 提供的特定前沿模型 ，请量化传输成本，而不是忽视它。估算“每轮字节数 × 每会话轮数 × 每日会话数”，应用你的跨边界费率，并将其加到 token 成本中。有时答案可能仍然是“使用 API”，但现在这是一个明码标价的决策，而不是默认的选择。如果你的数据确实是多云分布的 ，引力模型建议拆分代理（agent），而不是拆分数据。在数据所在的每个云中运行检索和上下文组装，仅将组装并压缩后的上下文跨边界传输一次——而不是让云 A 中的编排器向云 B 中的数据源发起十二次琐碎的调用。 错误的答案是大多数团队目前拥有的“偶然架构”：数据在一个地方，编排器在第二个地方，向量数据库在第三个托管服务中，模型在第四个地方，每个部分都是由设置该部分的负责人独立选择的。
上下文组装应紧邻数据 更深层次的架构主张是关于“组装”发生在哪里，而不不仅仅是模型在哪里运行。大多数代理技术栈将上下文组装视为编排器的工作：循环将原始材料从各处拉取到自身，在本地构建 prompt，然后发送出去。这种设计使编排器成为了一个“引力反模式”——一个被放置在完全不考虑数据来源地、却又是最大数据汇聚点的位置。
将组装移动到数据端，流量特征就会发生变化。一个与向量数据库共存的检索服务可以在任何数据跨越边界之前，对 50 个候选分块进行重排序（rerank）、去重和修剪，精简为关键的 8 个分块——传输的是 KB 而非 MB。一个运行在代码托管商旁的仓库上下文服务，可以将代理的“显示相关文件”请求解析为精选切片，而不是快照。工具适配器可以在源头总结冗长的 API 响应。这些都体现了 Hadoop 调度器的核心理念：在字节所在地运行归约（reduction），只让精炼后的结果传输。
这也解释了为什么 Prompt 缓存（虽然很有用）并不能解决问题。缓存使得重新发送的前缀在提供商端变得大幅便宜——缓存命中的输入价格仅为一小部分，且首个 token 响应速度快 2 到 5 倍——但缓存存在于模型端点。你的字节仍然必须传输到那里。缓存是目的地的折扣，而不是运费的折扣，它对于在 prompt 产生之前发生的检索和工具调用跳转毫无帮助。
关于这一点还有一个带有研究色彩的论点：像 RAGO 这样的推理优化工作将检索和生成视为一个在共享硬件上共同调度的流水线，正是因为“获取上下文”和“运行模型”之间的边界是延迟和吞吐量的死穴。系统社区正趋于得出与经济学观点相同的答案——检索和推理需要成为邻居。
在引力审计你之前，先审计你的引力 实际的行动是进行一个下午的核算，而不是重构平台。画出地图：你的代理接触的每个上下文来源、每个来源所在的地域和云，以及所有数据流向的模型端点。在每个边缘（edge）标注“每轮字节数”——你的链路追踪（tracing）已经有了 token 计数，而 token 可以很好地转换为字节以满足此目的。然后乘以你的传输费率和会话量。
通常会有三个发现。首先，某个边缘占据了主导地位——通常是“编排器到模型”或“向量数据库到编排器”——将该单一边缘的两个端点部署在同一处就能获得大部分收益。其次，某些昂贵的边缘是因为被遗忘的原因而存在的；例如，由于 Terraform 模块中的默认设置，向量数据库最终落在了另一个地域。第三，延迟和成本问题原来是同一个问题，因此通过调整地理位置，可以同时改善用户体验和账单。
Hadoop 时代的工程师并不比我们聪明；他们只是当时所处的网络环境下，忽视局部性（locality）的成本高到无法视而不见。托管 API 让这些成本在过去几年变得不可见，而代理现在又让这些成本变得巨大。上下文是有质量的。权衡它，映射它的传输路径，并将计算——或者至少是组装——放在它原本所在的地方。引力不会消失；唯一的问题是，你的架构是顺应它，还是在一轮又一轮的对话中为其支付昂贵的对抗代价。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
