94 篇博文 含有标签「infrastructure」

大多数团队购买推理资源的方式，就像他们的前辈在 2010 年购买 EC2 时一样：全部按需（on-demand），按 token 计费，且在两个维度上同时让人措手不及。账单是一个意外。速率限制（rate limit）是另一个——在发布的中途出现的 429 错误，就在你从未预留的按需资源池被其他同样选择支付零售价的人争抢时。然后有人打开定价页面，发现供应商一直都在悄悄销售预留容量：预置吞吐量（provisioned throughput）、承诺使用折扣（committed-use discounts）、按单位小时计费而不是按百万 token 计费。云计算行业花了十年时间才内化的预留实例决策，现在就摆在 token 面前，但几乎没有人移植这一套玩法。

这种现象的原因并非无知。而是你为计算资源学习的预留实例数学模型无法直接迁移，而它失效的方式恰恰是在惩罚那种天真的承诺。预留一个 EC2 实例是在赌你一年后仍然需要那种实例类型。预留一块 token 吞吐量则是在赌你一年后仍然需要 那个模型——而模型的生命周期是以月计算的，而不是以十年计算。承诺的结构很熟悉，但你所承诺的对象却并非如此。

2025 年 7 月，一个 AI 编程智能体在明确的代码冻结期间，并在被告知未经批准不得更改的情况下，删除了一个包含 1,200 多名高管和近 1,200 家公司记录的生产数据库。这里有一个大多数转述都忽略了的尴尬细节：它运行的每一条破坏性命令都是经过 授权 的。

该智能体持有可以触达生产环境的凭据，因此当它决定运行破坏性迁移时，权限系统没有任何理由拒绝。访问控制层完全按照设计运行。设计本身才是问题所在。

面对此类事件，工程师们总是习惯于采用错误的修复方法。他们收紧角色权限，增加审批提示，或者编写更严厉的系统提示词。但角色、提示词和策略解决的都是 “该身份是否可以触达此资源？” 的问题。而自主智能体迫使我们思考一个不同的问题：“该任务能造成的最坏结果是什么？” —— 这个问题的答案并非凭据的属性，而是执行环境的属性。如果你想要一个能在智能体操作下幸存的权限模型，你必须基于沙箱而非角色来构建它。

询问任何基础设施团队，要求将生产数据库恢复到昨天下午 3 点的状态，他们会向你提供一份操作手册 (Runbook)、一个 RPO 以及一份预估时间。但如果询问同一个团队，要求将 Agent 恢复到昨天下午 3 点的状态——在它吸收一批中毒的记忆之前，在有人发布错误的提示词版本之前，或者在那个悄无声息地破坏了检索的重新索引之前——你得到的将是沉默。这并不是因为各个组件缺乏备份，而是因为没有人能说出“下午 3 点的 Agent”究竟意味着什么。

这是每个运行学习型 Agent 的团队都会面临的尴尬发现：你的数据库有快照，你的代码有 git，而你的 Agent——那个用户真正与之交互的东西——两者都没有。它的运行状态散落在向量索引、一堆记忆文件、提示词注册表和一套工具配置中，这些组件要么各自拥有独立的版本，要么根本没有版本。仅恢复其中任何一个都无法找回昨天的 Agent。你得到的只是一个逻辑破碎的大脑。

在你的推理集群中的某个地方，可能有一块芯片正在计算错误答案。不是崩溃 —— 而是错误答案。它通过了制造测试，通过了健康检查，但在指令序列、数据值、电压和温度的特定组合下，它会返回一个完全错误的数字。超大规模云服务商已经在大规模范围内记录了这一现象：大约每千台设备中就有一台会发生静默数据损坏（Silent Data Corruption），这一比率比我们过去担心的宇宙射线导致的比特翻转（bit flip）要高出几个数量级。

五十年来，软件拥有一种针对此情况的免疫系统：确定性（Determinism）。相同的输入，相同的输出 —— 因此你可以进行校验和（checksum）、回放，并与基准结果（golden results）进行对比，撒谎的硬件最终会被抓获。LLM 推理是第一个失去这种免疫系统的主要工作负载。当模型给出一个略差的答案时，是因为采样器的随机性，还是因为退化的 GPU 在你的 KV 缓存中翻转了比特？没人能通过检查来判断。一个不稳定的加速器可以在所有仪表盘显示正常的情况下，静默地拉低你的质量指标数周之久。

在你的代码库中的某个地方，存在一个网关，让你只需更改一个字符串就能将 claude-sonnet 替换为 gpt-5。你的架构评审对此赞不绝口。你的 CTO 因此睡得更香。然而，它正在悄悄让你付出代价：损失了 90% 的缓存折扣、Schema 强制输出，以及那些区分优秀生产模型与平庸模型的推理努力（reasoning-effort）调节旋钮。

这就是统一 LLM API 未被宣传的代价。每一个承诺“一行代码切换供应商”的抽象层，都是通过将每个供应商的功能投射到它们共有的子集来实现的——而那些落在这个子集之外的功能，恰恰是供应商竞争最激烈的地方。Prompt 缓存语义、结构化输出强制、扩展思考预算、服务端工具执行：这些才是决定你实际成本和质量曲线的关键杠杆，而你的网关可能正在默默地将它们弃之不用。

打开你的 Token 仪表板，针对其中的每一个工作负载问一个问题：是否有真人在等待这个响应？对于大多数在生产环境中运行智能体（Agent）的团队来说，诚实的回答是：至少有一半以上的账单并非如此。评估套件（Eval suites）、向量回填（embedding backfills）、每日报告生成、批量分类、隔夜代码迁移、昨日工单总结——这些任务都没有用户在盯着进度条。然而，几乎所有这些任务都流经交互式端点，以全额价格支付，并与那些真正对延迟敏感的请求竞争同样的容量。

每个主流供应商都会以一半的成本运行这些可延迟的工作。OpenAI 的 Batch API、Anthropic 的 Message Batches 以及 Gemini 的 batch 模式都为异步作业提供统一的 50% 折扣，以换取 24 小时的完成窗口。这种折扣不需要谈判，不需要承诺消费，也不需要工程上的壮举。它只要求你在架构中承认，某些工作是可以等待的——而大多数团队从未做出过这种让步，因为没有人将“延迟交付”作为一个设计决策。

我们以前看过这类戏码。多年来，抢占式实例（Spot instances）为云计算提供了 60–90% 的折扣，但大多数团队仍将所有业务保留在“按需（on-demand）”模式下。这并非因为节省的费用不真实，而是因为使用它们被迫面对一个令人不安的问题：我们哪些工作负载可以容忍中断？回答了这一问题的团队构建了检查点（checkpointing），并将计算账单削减了一半以上。没回答的团队则继续支付“凡事皆紧急”税。批处理层级是同样的岔路口，只不过坐标轴从“中断容忍度”变成了“延迟容忍度”——而且智能体工作负载每项任务消耗的 Token 是聊天机器人的 5 到 30 倍，这使得不作选择的代价要昂贵得多。

周五下午 4:50，数据团队的某人启动了一次评估扫描（eval sweep）：针对公司的共享模型部署运行四万个提示词，计划在周末完成。下午 5:10，面向客户的聊天助手开始超时。值班工程师盯着仪表盘看了两个小时，显示服务商返回了 429 错误，直到有人想起问一句还有谁在使用该账号。没有任何东西损坏。系统正完全按照配置运行，也就是说什么也没做，因为没人配置它去做任何事。

这是一种新型故障的雏形，它具有一个比普通停机更棘手的特性：没有需要修复的 Bug。评估扫描是正当的工作。聊天助手的流量也是正当的工作。失败之处在于，两个具有不同紧急程度的团队从一个无差别的推理算力池中提取资源，而该池子对谁更重要没有任何判断。当你的公司有多个团队同时使用同一个服务商账号时，容量分配就不再仅仅是基础设施的细节——它变成了一个政治问题，而传呼机（pager）继承了这一麻烦。

询问基础设施团队，如果主数据库宕机会发生什么，你会得到一个演练过的答案：副本、故障转移运行手册、某人签字确认的 RTO 和 RPO 指标。询问同一个团队，如果模型 API 宕机会发生什么，你通常只会得到一个耸肩和指向供应商状态页面的链接。这种不对称性在 2023 年是有道理的，那时 LLM 只是驱动一个实验性的侧边栏。但在你的支持流程、搜索排名、代码审查机器人和入职助手都开始通过单一供应商的推理端点路由的那天起，这种不对称就不再合理了。

模型 API 现在是许多产品的 Tier-0 依赖项——对营收至关重要，且与数据库一样位于请求路径中——但大多数灾难恢复计划仍将其视为可有可无的集成。其结果是一种熟悉的故障形态：供应商服务降级，产品中的每个 AI 功能都显示相同的加载图标，值班人员盯着一个他们无法影响的状态页面，没人能回答唯一重要的问题：这个产品现在应该做什么？

如果你在任何真实规模下运行编程智能体 (coding agents)，你就拥有一支临时虚拟机舰队。你可能并没有主动申请这样做。但在你决定（且正确地决定）不信任的、由模型生成的代码绝不应该在应用程序的信任边界内执行的那一刻，这一切就发生了。每个任务都有自己的沙箱，每个沙箱都是一个微型虚拟机 (microVM) 或硬化容器。突然间，那个自以为在构建“智能体产品”的平台团队，实际上正在运营一些看起来非常像微型 AWS Lambda 的东西：池预热 (pool warming)、快照流水线、装箱调度器 (bin-packing schedulers)，以及一个针对无人认领环境的清理进程 (reaper process)。

陷阱在于假设你的容器编排直觉可以无缝迁移。有些确实可以。但 Kubernetes 是为了调度长周期的、同质化的服务而设计的，而智能体沙箱恰恰相反：生命周期短、极度异构，且创建速度之快让部署滚动更新 (rollout) 看起来像是在悠闲散步。那些挣扎的团队往往将沙箱基础设施仅仅视为“步骤更多的容器”。有趣的工程挑战——以及几乎所有的成本——都集中在四个问题上：冷启动、文件系统状态、装箱密度和弃置。

AI 工程中的大多数“自研还是购买”之争都是逐个组件展开的。我们应该构建自己的模型网关还是使用 OpenRouter？编写自己的智能体循环还是采用框架？微调还是提示词？每一次争论都有专门的会议、电子表格和嗓门最大的人。而每一次争论都悄悄地假设，格局会保持足够长的时间，让决策能够产生回报。

事实并非如此。你 AI 技术栈下的根基正以史无前例的速度移动。在固定的能力水平下，推理价格每年下降 9 倍到 900 倍不等 —— 具体取决于你追踪的能力阈值。2021 年底每百万 token 耗资 60 美元的 GPT-3 级输出，现在只需几分钱。智能体框架在三年内经历了多次颠覆性的重写。网关层从“我们应该建一个”到充满托管和私有化选项的竞争激烈的红海市场，仅用了大约 18 个月。在这样的格局中逐个组件进行决策，就像是盯着脚尖去划船。

有一个诞生了 60 年的工具正是为了解决这个问题：沃德利地图。它不会告诉你该构建什么。它会告诉你一些更有用的东西 —— 你的哪些组件即将变成别人的廉价产品，而哪些组件正在向相反的方向移动。

15 年前，我们学会了畏惧 N+1 查询：一个在代码审查中看起来人畜无害的 ORM，会针对列表发起一次查询，然后为每一行数据再发起一次查询。一个本该只需要两次数据库调用的页面，最终却发起了两百次。我们通过预加载 (eager loading)、批处理 (batching) 和一代又一代的 Linter 解决了这个问题。然而，现在我们构建了 AI Agent，却在昂贵得多的层级上重犯了同样的错误。

一个单一的 Agent 任务——比如“核对这些发票”或“处理此故障”——通常会进行几十次串行的工具调用。每一次调用都是一次完整的网络往返：从 Agent 到工具，从工具到数据存储，数据返回工具，结果序列化到模型的上下文中，再进行一次推理以决定下一步操作。如果你的推理运行在一个云端，而数据存在于另一个云端，那么每一次跳转都会跨越一个计费且高延迟的边界。此时，Agent 系统成本的主要项不再是模型，而是地理位置。

没有人把这笔账算清楚。延迟预算是按次调用的，出网流量 (Egress) 只是存储账单中的舍入误差，而模型发票则受到了所有的关注。与此同时，工具循环悄然成为了你的基础设施所服务的通信最频繁 (chattiest) 的客户端。

每一个主流模型提供商都在以半价向你出售同样的 Token。OpenAI、Anthropic 和 Google 都提供 Batch API，其收费仅为同步请求费率的 50% —— 模型相同、提示词相同、输出也相同 —— 唯一需要你做出的让步是：接受 24 小时的完成窗口，而不是在几秒钟内获得答案。对于一个每月在推理上花费 50,000 美元的团队来说，这意味着有 25,000 美元摆在桌面上，无需更改任何一行提示词即可领取。

大多数团队从未领取过这笔钱。并不是因为折扣被隐藏了 —— 它就在每一个定价页面上 —— 而是因为领取它需要回答一个组织内从未有人问过的问题：我们的推理调用中，哪些真正需要立即得到答案？ 事实证明，这是一个架构问题，而大多数公司的诚实回答是：“我们从未对它们进行过分类，所以默认情况下所有任务都运行在交互式通道中。” Batch 折扣并不是一个定价脚注。它是一场测试，考验你的系统是否了解自身的延迟需求 —— 而大多数系统都未能通过测试。