智能体经济学
目的
为什么一个 token 单价仅为十分之一的模型，反而会让智能体每完成一项任务的成本更高？
如果一个团队像为聊天服务定价那样为智能体定价，只将 token 数量乘以供应商的费率，就会对账单感到意外。智能体购买的并不是 token，而是已完成的任务；每项已完成的任务都承担了使一个结果通过验证所需的每一轮交互、重新发送的上下文、沙箱运行的每一秒、测试运行、重试和人工审核的成本，还要加上所有未能通过验证的尝试的成本。更便宜但失败更频繁的模型会成倍放大所有这些成本项；对于时间主要花在测试和工具等待上的轨迹，更快的模型几乎无法缩短其耗时；而没有预留预算的委派树则可能花掉任何回滚都无法追回的资金。因此，经济性决定了调用哪个模型、缓存什么、购买多少推理计算、何时升级处理、保留多少容量，以及一项任务是否值得交给智能体；每个决策都以每项通过验收的任务所需的成本和时间来衡量。执行跨度决定了需要付费的轮次数，状态决定了每一轮需要重新发送多少上下文，而权限决定了每个结果必须通过多少验证和审批，因此，一项通过验收的任务的价格，就是消除这三类风险敞口所需的价格。
学习目标
- 根据整条轨迹的成本和验收通过率，计算每项通过验收的任务的成本，并解释为什么每 token 单价会产生误导。
- 估算前缀缓存命中、上下文压缩，以及推理或重试预算如何改变多轮轨迹的美元成本。
- 根据轨迹记录诊断其关键路径，并判断何时更快的推理（包括推测解码）能够带来收益。
- 设计由验证器把关的模型级联，并计算其预期成本、尾部延迟和错误验收的代价。
- 利用利特尔定律和供应商的速率限制，为轨迹配置所需容量，并找出专用模型服务与按 token 计费的 API 之间的盈亏平衡点。
- 设计分层预算预留机制和支出速率限制，约束整棵委派树的资金支出。
- 按每项通过验收的任务的成本，为固定工作流、有界智能体循环和多个智能体分别定价，评估一项任务适合采用哪种方式。
每项通过验收的任务的成本
当验收通过率低于一半时，失败尝试的成本会超过 token 价格折扣带来的任何节省。
一个平台团队将其缺陷修复智能体背后的前沿模型替换为 token 成本仅为原来十分之一的模型。接下来的一个月，修复缺陷的账单反而上涨了。模型服务日志无法解释这一现象，因为这些日志统计的是 token，而 token 从来就不是智能体真正购买的东西。聊天服务按调用计费，因此其成本是 token 数量乘以单价。智能体执行的是一条轨迹，而组织付费购买的是结果通过了验证的轨迹。轨迹有效吞吐量（微效与宏效）已经只统计用于通过验证的轨迹的资源，而 多层评估契约 定义了验证所产生的通过验收的任务。本节为每项通过验收的任务定价，并说明这一价格实际上购买了系统中的哪些部分。
图 1 的左侧面板分解了一个示例任务的成本。模型 token 的费用分为重新发送的输入和生成的输出两部分，合计不到总账单的一半。其余费用用于支付运行智能体命令的沙箱、智能体调用的工具、验证其结果的测试，以及失败尝试所触发的人工审核费用的一部分。对于包含 \(K\) 轮交互的轨迹，一次尝试的整条轨迹成本为
\[C_{\text{attempt}} = \sum_{k=1}^K \left( C_{\text{in}, k} + C_{\text{out}, k} + C_{\text{tools}, k} + C_{\text{sandbox}, k} \right) + C_{\text{verify}} + C_{\text{human}} \tag{1}\]
其中，\(C_{\text{in}, k}\) 是第 \(k\) 轮发送的上下文（系统提示词、工具定义、截至当前的交互记录以及最新的工具结果）的费用，\(C_{\text{out}, k}\) 是模型生成的 token 的费用，包括推理 token 和工具调用参数，\(C_{\text{tools}, k}\) 涵盖外部服务收取的费用，\(C_{\text{sandbox}, k}\) 涵盖执行智能体命令的隔离环境的费用，\(C_{\text{verify}}\) 涵盖用于判定结果是否被接受的测试和检查的费用，\(C_{\text{human}}\) 涵盖运行时将问题升级至人工处理时的审核费用。公式 1 的输入项随每一轮交互增长，因为模型在调用之间不保留任何信息，每一轮都会重新发送更长的上下文（加速器服务延迟）。正是这种增长，使下一节将缓存作为首要优化手段。
一次尝试并不等于一个被接受的任务。图 1 的右侧面板说明了原因。如果一个八步任务的每一步都以概率 \(p\) 独立成功，那么整个任务成功的概率为 \(p^8\)，而每次失败尝试在被丢弃前，其全部费用都已支付。“轨迹有效吞吐量与被接受的任务”（原则 22）指出了集群因此必须最小化的量，即每个被接受任务的有效成本。如果集群进行了 \(N\) 次尝试，其中 \(N_{\text{acc}}\) 次被接受，则
\[C_{\text{eff}} = \frac{\sum_{i=1}^N C_{\text{attempt}, i}}{N_{\text{acc}}} = C_{\text{succ}} + \frac{1 - \alpha}{\alpha} C_{\text{fail}} \tag{2}\]
其中，\(\alpha = N_{\text{acc}}/N\) 为接受率，\(C_{\text{succ}}\) 为通过验收的尝试的平均成本，\(C_{\text{fail}}\) 为失败后被放弃的尝试的平均成本。几率比 \((1 - \alpha)/\alpha\) 表示每个被接受任务所承担的失败尝试次数。它在接近 \(\alpha = 1\) 时很小，并随着 \(\alpha\) 的下降而无限增大，这对应于页边图左侧的陡峭部分。
Definition 0.1: 整条轨迹成本
整条轨迹成本 是所有尝试中模型 token、工具、沙箱、验证和人工审核的总支出，除以结果被接受的尝试次数，即 \(C_{\text{eff}} = C_{\text{succ}} + \frac{1 - \alpha}{\alpha} C_{\text{fail}}\)。
- 重要性：它是模型选择、缓存、路由和容量决策必须降低的量，而且即使 token 价格下降，它也可能上升。
- 区别：按 token 定价对模型输出计费，无论任务是否成功；整条轨迹成本则将每次失败尝试和每项非模型费用都计入被接受任务的成本。
- 常见误区：根据供应商的价目表为智能体编制预算，这既忽略了非模型费用项，也忽略了对失败尝试起乘数作用的几率比 \(\frac{1 - \alpha}{\alpha}\)。
粗略估算 0.1: 自动化缺陷修复中的 token 价格谬误
| 参数 | 前沿模型 | 低成本模型 |
|---|---|---|
| 每 106 个 token 的输入 / 输出价格 | $3 / $15 | $0.30 / $1.20 |
| 每次尝试的轮数 | 4 | 7 |
| 每轮的输入 / 输出 token 数 | 16,000 / 800 | 28,000 / 1,200 |
| 验收率 \(\alpha\) | 0.75 | 0.25 |
| 每轮的沙箱和工具成本 | $0.03 | $0.03 |
| 每次尝试的验证成本 | $0.05 | $0.05 |
| 每次失败尝试的人工分诊成本 | $10 | $10 |
计算：仅计 token 成本，前沿模型每次尝试的成本为 $0.240，低成本模型为 $0.069，后者看起来便宜 3.5×。低成本模型需要更多轮次，而每轮都要支付沙箱费用，因此计入托管和验证后，两者每次尝试的成本分别为 $0.410 和 $0.329，差距仅为 20%。除以验收率（公式 2，结合 \(C_{\text{fail}} = C_{\text{succ}}\)）后，前沿模型每次获验收修复的成本为 $0.55，低成本模型为 $1.32；后者每成功一次会伴随 3 次失败尝试，而前者为 0.33 次。当每次失败尝试还需支付 $10 的工程师分诊成本时，这两个数值变为 $3.88 和 $31.32。
系统洞见：不计分诊成本时，低成本模型每次获验收修复的成本高出 2.4×；计入分诊成本时，则高出 8.1×。token 价格折扣确实存在，但由此节省的费用被更多轮次、沙箱运行时间和失败尝试成倍消耗了。
结果报告也遵循同样的核算逻辑。仅以成功率评估智能体，会掩盖成功所付出的成本；仅以成本评估智能体，则会掩盖它未能完成的任务。只有在同一组运行中，同时报告验收率及其置信区间（统计评估的严谨性）和每个获验收任务的成本，结果才是完整的。这样，各种设计就可以放在成本—准确率平面上比较；如果一种设计比另一种设计既便宜又准确，它就支配后者。仓库级问题基准 (Jimenez 等 2024年) 使这一点具体可见，因为每个已解决的问题都有可验证的测试结果和可量化的账单。设计之间的比较应在相同预算下进行（潜在能力解耦），因为获准花费更多的设计，仅凭金钱就能买到成功。在本章中，\(C_{\text{eff}}\) 的倒数，即每美元获验收的任务数，是评判每一种调节手段的指标。
对完整轨迹的核算还揭示了应优先从哪里着手。在大多数智能体轨迹中，最大的 token 成本项并非模型写出的内容，而是运行时在每一轮重新发送给模型的内容。
缓存与推理预算
到第三十轮时，编码智能体发送给模型的上下文已包含数万个 token，其中几乎所有内容都已在第二十九轮发送过。默认情况下，这种重复内容按全价计费，但这笔费用是可以避免的。加速器服务延迟 统计了轨迹重复发送的 token（equation），并介绍了前缀缓存，它可复用服务已经处理过的提示词前缀所对应的注意力状态。上下文工程通过组织上下文，使前缀保持稳定（编排下一次调用），而 跨轮次前缀缓存 展示了模型服务系统如何共享该状态。二者都建立在同一事实之上：注意力状态是精确 token 前缀的函数（原则 5）。本节以美元核算由此产生的成本，随后核算运行时在每次调用中控制的另一项预算：购买多少推理计算，以及多少次尝试。
缓存命中的价值
支持提示词缓存的供应商，对从缓存前缀读取的输入 token 按正常输入价格的一部分计费，只有前缀之后的 token 才按全价计费。对于只追加内容的对话记录，第 \(k\) 轮是在第 \(k-1\) 轮的基础上扩展的，因此在理想复用条件下，每轮只有新增内容需要按全价付费。现在，可以对 加速器服务延迟 中按 token 数统计的同一条轨迹进行成本核算。
粗略估算 0.2: 有缓存与无缓存时三十轮轨迹的成本计算
计算：这条轨迹总共发送 892,500 个输入词元，按全价计费的成本为 $2.68。在仅追加的上下文中，只有首次提示和每轮追加的词元按全价计费，共计 51,500 个词元，其余均为缓存读取，因此输入成本降至 $0.41。无论是否使用缓存，输出成本均为 $0.09。不使用缓存时，轨迹成本为 $2.77；使用缓存时为 $0.50。
系统洞见：前缀缓存使同一条轨迹的成本降低 5.6×，且无需改变模型或答案。但它也很脆弱。系统提示开头的时间戳、重新排序的工具列表，或对早期消息的修改，都会使每一轮重新变成按全价计费的读取。
编排下一次调用 中的布局规则旨在保护这部分成本节省；智能体运行框架的仪表盘应将缓存命中率与每个验收通过任务的成本并列展示。为使估算如实反映情况，还需考虑两项限定条件。一些提供商对将前缀写入缓存收取额外费用，并在数分钟无活动后使缓存前缀过期，因此，一条因长时间等待工具或审批（审批关卡）而暂停的轨迹，恢复时可能面对冷缓存。对于同一决策，从服务侧来看，即是否在等待期间让注意力状态保持驻留，相关讨论见 保留、驱逐、重计算或卸载。
压缩的代价
压缩（上下文压缩）在上下文过长时缩减其长度，通常用摘要替换旧的交互轮次。对于使用缓存的轨迹，压缩有一项容易忽略的成本。摘要是新文本，因此压缩后的下一轮会按全价读取整个上下文，而生成摘要本身也需要一次模型调用。在笔记本中的轨迹里，假设运行时在第 16 轮进行压缩，此时上下文包含 30,500 个词元，将其缩减为 12,000 个词元，摘要调用生成 1,500 个词元。不进行压缩时，剩余 15 轮的输入成本为 $0.245。进行压缩后，这些轮次的输入成本为 $0.190，加上生成摘要的 $0.036，总计 $0.226。压缩只有在大约再运行 11 轮之后，才能抵消其缓存未命中和摘要调用的成本。
由此可得两个结论。在长轨迹的早期进行压缩可以节省成本，而临近结束时进行压缩则会增加成本，因此，按固定计划进行压缩的运行时至少应将预计剩余轮数与盈亏平衡点进行比较。更多时候，这一决策根本不取决于金钱。上下文窗口的限制，以及上下文逐渐充满过时内容时对决策质量的影响（上下文失效），构成了进行压缩的理由；以美元计的成本核算只是说明获得这种质量需要付出多少成本。
推理与重试预算
运行时设定的另一项单次调用预算，是购买多少思考量。调用接口提供推理词元预算（调用契约）；推理词元按价格较高的输出词元计费，并且串行生成，因此，更大的预算会提高每次使用该预算的调用的价格和延迟。三种计算分配轴 已经讨论了何时增加思考能够增强决策的证据支持。这里的经济问题更为具体。对于具有封闭验证器的任务，运行时可以通过一次昂贵的调用获得更好的答案，也可以通过较便宜的调用进行多次尝试；这两种方案的每个验收通过任务的成本不同。
如果运行时信任验证器，重试便可在首次获得验收通过的结果时停止。若低成本配置的每次尝试以 \(p\) 的概率成功，成本为 \(c\)，且各次尝试相互独立，那么，无论允许多少次重试，顺序重试的每个验收通过任务的期望成本均为 \(c/p\)，因为每次获准的重试都只在前一次失败时才会执行。重试上限 \(k\) 改变的是覆盖率 \(1 - (1-p)^k\)，而非每个验收通过任务的成本。并行运行 \(k\) 次尝试则是花钱缩短延迟，每个任务的成本为 \(kc\)，每个验收通过任务的成本为 \(kc/(1-(1-p)^k)\)。Pass@\(k\) 作为选择上限（候选选择），是这两种情况下的覆盖率项。
以一个低成本配置为例，其成功概率为 0.30，每次尝试的成本为 $0.10；另一个更强的配置（采用更大的模型或更高的推理预算）的成功概率为 0.70，每次尝试的成本为 $0.40。在最多尝试 5 次的限制下，对低成本配置进行顺序重试可覆盖 83% 的任务，平均尝试次数为 2.8，每个获接受任务的成本为 $0.33。更强的配置仅尝试一次，每个获接受任务的成本为 $0.57。并行采样 5 次低成本尝试速度最快，成本也最高，为 $0.60。低成本配置在成本方面占优，但在延迟和覆盖率方面处于劣势；更强的配置在延迟方面占优；只有满足截止期限所带来的收益足以抵偿额外成本时，并行方案才有采用的理由。
这一比较能否在实践中成立，取决于两个条件。验证器必须值得信赖，因为如果验证器有时会接受错误答案，重试就会转化为错误接受（原则 3）。各次尝试的失败还必须相互独立，而实际情况很少如此。同一模型在同一任务上的各次尝试具有共同的盲点，因此覆盖率会在远低于 \(1 - (1-p)^k\) 的水平趋于平稳，而 pass@\(k\) 与多次运行的可靠性（潜在能力解耦）之间的差距，就是这种相关性的量化表现。随后，搜索停止准则 中针对每个任务的停止规则会限制无望完成的任务所能消耗的预算。
缓存降低了每轮的成本，而推理和重试预算决定了能够购买多少轮交互和多少次尝试。两者都无法说明任务需要多长时间。一条轨迹即使成本低廉，也可能因耗时过长而失去实用价值；时间也有自己的账目。
关键路径延迟
沙箱中的测试执行占据了实际耗时的大部分，限制了加快推理所能带来的收益。
一个编程智能体修复失败测试需要 420 秒，其中模型花费 84 秒生成 token。平台团队将其迁移到一个 token 生成速度快 4× 的服务层级。下一次运行耗时 357 秒，投入巨大却只带来 15% 的改善，因为其余 336 秒用于容器启动、测试执行、文件同步和软件包下载，而这些环节都没有加快。轨迹时长核算 中的时长恒等式已经将每一轮的时间拆分为模型、工具、等待和运行时时间，并用阿姆达尔定律限定了加速模型所能带来的收益。本节将这一界限转化为诊断依据。追踪记录识别关键路径，运行时缩短关键路径上的环节，而只有当模型位于关键路径上时，才值得投入资金加速推理。
图 2 中的轮次耗时 4.25 秒，其中模型的两个阶段，即读取上下文和生成输出，耗时 1.5 秒，占 35.3%。无论模型加速多少，这一轮次的加速比都不可能超过 1.55×。模型加速 2× 可带来 1.21×。通过预热沙箱池、缓存构建结果和测试选择，使工具和等待环节加速 2.5×，可带来 1.63×，其收益甚至超过模型瞬时完成所能带来的收益。因此，应当投资哪一侧取决于测量，而非观点；测量的依据就是追踪记录。
从追踪记录中识别关键路径
一条轨迹的追踪记录（分布式轨迹追踪）将每次模型调用、工具调用、沙箱操作和等待记录为一个跨度，包含开始时间、持续时间和父跨度。实际轨迹会分支、重试并并行运行工具，因此这些跨度构成一个有向无环图，其中边 \((u, v)\) 表示 \(v\) 必须等到 \(u\) 完成后才能开始。这就是 协同拓扑 中的任务图，只是粒度细化到了单次调用；与该任务图一样，轨迹的耗时等于其最长路径的长度，
\[T_{\text{critical}} = \max_{\pi \in \Pi} \sum_{v \in \pi} t(v) \tag{3}\]
其中，\(\Pi\) 是从源节点到汇节点的路径集合，\(t(v)\) 是跨度 \(v\) 的持续时间。不在关键路径上的跨度具有松弛时间，缩短它不会改变用户感知到的任何结果。关键跨度在制约其耗时的因素以及缩短其耗时的方法上各不相同，表 1 对此作了汇总。
| 跨度 | 决定其持续时间的因素 | 缩短其持续时间的方法 |
|---|---|---|
| 模型：读取输入 | 上下文长度、前缀缓存未命中、排队 | 保持缓存稳定的布局、更小的上下文、更少的排队 |
| 模型：生成输出 | 输出 token 和推理 token | 更短的输出、更小的推理预算、推测解码 |
| 沙箱和工具 | 构建规模、测试套件规模、冷启动 | 预热池、快照、构建缓存、测试选择、并行工具调用 |
| 网络和服务 | 往返次数、载荷大小、服务提供方限流 | 响应缓存、预取、速率限制余量 |
| 运行时 | 解析、验证、日志记录、快照生成 | 流式解析器、增量快照 |
示例跟踪记录 展示了一条三轮修复轨迹的示例跟踪记录，其中包含智能体运行框架所采集的各类耗时。
| 执行片段 | 耗时（秒） |
|---|---|
| 运行时初始化 | 0.12 |
| 沙箱创建 | 14.80 |
| 第 1 轮，读取上下文 | 1.20 |
| 第 1 轮，生成 | 8.40 |
| 工具：仓库状态 | 0.08 |
| 第 2 轮，读取上下文 | 1.85 |
| 第 2 轮，生成 | 11.20 |
| 工具：运行测试套件 | 245.60 |
| 第 3 轮，读取上下文 | 2.10 |
| 第 3 轮，生成 | 4.50 |
| 沙箱快照导出 | 22.55 |
| 所有模型执行片段 | 29.25 |
| 轨迹 | 312.40 |
六个模型执行片段的总耗时占整条轨迹耗时的 9.4%。测试运行占 78.6%，创建和导出沙箱另占 12%。即使模型能瞬间完成执行，这条轨迹的加速幅度也至多为 1.10×。团队读过这份跟踪记录后，会着手优化测试选择和沙箱快照，而非推理。
压缩关键路径
一旦跟踪记录明确了 公式 3 的关键路径，就可以采用三种技术，在不改变模型所见内容的前提下缩短这条路径。第一种是并行运行独立的工具调用。当模型在一轮中请求多项读取操作，且调用接口允许这样做时（调用契约），运行时可以并发执行这些操作，这一轮只需等待最慢的操作，即 \(T_{\text{tools}} = \max_i T_{\text{tool}, i}\)，而非等待所有操作耗时之和。
第二种是在模型仍在生成时就开始工作。工具调用通过流式响应到达，在调用完整到达之前，工具名称和前面部分的参数就已确定，因此运行时可以在调用的其余内容仍在流式传输时，从预热池中获取沙箱，或读取目标文件。这些工作属于推测执行，如果完整调用未通过验证，就必须丢弃其结果；只有不产生副作用的准备工作才能安全地这样执行。
第三种是提前结束工具运行。测试套件会流式输出结果，而第一个失败的断言往往就足以支持模型作出下一步决策。如果运行时在失败出现时立即转发失败信息，并停止剩余测试，就能在发生失败的执行路径上将长达一分钟的运行缩短至几秒钟，代价是获得的观测不够完整。
推测解码何时值得采用
当跟踪记录确实显示生成位于关键路径上时，例如生成较长的补丁和计划时，为更快的生成付出成本就变得值得，而推测解码是实现这一目标的标准方法。一个小型草稿模型提出若干 token，目标模型在一次前向计算中检查所有这些 token，并保留与自身判断一致的前缀（自回归生成）。由于单个生成流受限于内存带宽，而非算术运算能力（原理 1），检查多个 token 所花的时间与生成一个 token 大致相同；同时，一套接受规则使输出分布与目标模型的输出分布完全一致 (Leviathan 等 2023年; C. Chen 等 2023年)。为什么输出的成本高于输入 推导了第一个事实，解码循环机制 则推导了第二个事实背后的接受规则。智能体工程师需要考虑的只是这项技术何时值得采用。
如果草稿模型每轮提出 \(\gamma\) 个 token，每个草稿 token 的成本是目标模型单步成本的 \(r\)，且目标模型每轮平均接受 \(\bar{\alpha}\) 个草稿 token，那么每轮可推进 \(\bar{\alpha} + 1\) 个 token，所用时间相当于目标模型执行 \(\gamma r + 1\) 步的时间，因此加速比为
\[S_{\text{spec}} = \frac{\bar{\alpha} + 1}{\gamma r + 1} \tag{4}\]
且只有当 \(\bar{\alpha} > \gamma r\) 时，这项技术才值得采用。接受率取决于输出的可预测程度。结构化输出和代码框架具有较高的可预测性，草稿模型在大多数 token 上都与目标模型一致。开放式规划和高温度采样的可预测性则较低，草稿模型的工作因而被浪费。不同智能体工作负载下的推测解码 针对智能体工作负载中的示例接受率，对 公式 4 进行了评估。
| 智能体工作负载 | 输出可预测性 | 每轮接受的词元数（\(\gamma =\) 5） | 加速比 \(S_{\text{spec}}\) |
|---|---|---|---|
| 结构化输出（JSON、YAML） | 极高 | 4.4 | 3.86× |
| 代码编辑与脚手架生成 | 高 | 3.6 | 3.29× |
| 错误堆栈诊断 | 中等 | 2.5 | 2.50× |
| 算法规划 | 低 | 1.4 | 1.71× |
| 开放式、高温度生成 | 极低 | 0.6 | 1.14× |
表格之外的两个条件决定是否启用推测解码。第一个是关键路径。若将速度提升 3.29× 的生成器用于模型耗时占比不足十分之一的轨迹，其总耗时仅会改变几个百分点，因此应将推测解码用于执行跟踪显示位于关键路径上、对延迟至关重要的调用，而非所有调用。第二个是负载。推测解码通过增加计算量来缩短单条流的耗时，只有当服务系统具有空闲计算资源时，这种额外计算才无需付出机会成本。在大批量处理负载下，计算资源不再空闲，草稿模型还会占用原本可用于存放其他轨迹注意力状态的内存，因此推测解码可能降低整个集群的吞吐量。服务系统因此会在队列较短且请求对延迟敏感时启用推测解码，在批次已满时将其禁用。同样的规则适用于本节中的每一种加速手段：只有作用于关键路径，且其消耗的资源仍有余量时，才能带来收益。
Checkpoint 0.1: 每个被接受任务的成本与耗时
在将调用路由至不同模型之前，先检查截至目前的成本核算：
关键路径分析说明了更快的调用何时才有意义。对于大量不在关键路径上的调用，以及大量根本不需要最强模型的调用，更大的节省来自一开始就避免发起昂贵的调用。
模型级联与路由
由验证器把关的级联系统使用小模型解决大多数任务，并将预期成本降低一个数量级。
将每次调用都发送给最强模型的智能体，会为 JSON 格式化、从堆栈跟踪中提取文件路径以及日志摘要支付前沿模型的价格。将每次调用都发送给小模型的智能体，虽然能节省这些调用的费用，却会在需要规划或诊断的调用上失败，而每次失败都要付出一次完整尝试的成本。轨迹中的大多数轮次所需能力远低于最强模型的能力，只有少数轮次需要充分发挥其能力。模型级联 利用了这种差异。它先尝试较便宜的模型，只有在检查表明结果不够好时才升级到更强的模型 (L. Chen 等 2023年)。检查是保障级联系统安全的关键，而 过程验证 中的验证器就是运行时执行检查所需的工具。
层级与路由
生产环境中的运行时通常有三类被调用对象，汇总见 表 2。确定性代码和小模型负责处理歧义较少的转换。中等规模的通用模型负责常规工具使用和局部编辑。前沿模型负责规划、跨多个文件的诊断，以及较低层级失败后的恢复。
| 层级 | 典型被调用对象 | 典型智能体角色 | 决定是否升级的关卡 |
|---|---|---|---|
| 1：确定性工具与小型模型 | 解析器、正则表达式、小型语言模型 | 参数提取、模式修复、日志分诊、命令过滤 | 模式与语法检查 |
| 2：中型通用模型 | 经过指令微调的中等规模模型 | 单文件编辑、常规工具调用、摘要生成 | 类型检查、构建、快速单元测试 |
| 3：前沿模型 | 当前可用的能力最强的模型 | 规划、跨文件诊断、从较低层级的失败中恢复 | 完整回归测试套件、必要时的审批 |
运行时可以通过两种方式选择层级。静态路由根据任务描述或调用特征，在每次调用发起前对其进行分类，并将其发送到某一层级。它几乎不增加延迟，其失败方式也可预测。一个看似简单的请求（“修复锁测试中失败的断言”）可能需要跨多个文件追踪竞态，而根据请求本身作出判断的路由器会将其发送给一个不断循环直至预算耗尽的模型。升级路由先尝试成本最低且可能胜任的层级，只有当该层级的输出未通过检查时才向上升级。它需要承担失败尝试的成本，换来的是基于输出证据作出决策，而不是猜测输入的难度。
学习型路由器介于两者之间。运行框架自身的日志（分布式轨迹追踪）记录了哪个层级的输出在哪类调用上通过了验证，这恰好就是路由器所需的带标签数据；用这些数据训练的分类器可以预测低成本层级是否可能通过验证。路由器错误的代价并不对称。错误地路由到较低层级，会产生一次低成本尝试失败的费用，再加上升级的费用。错误地路由到较高层级，则会产生层级之间的价差。其阈值应根据这两种代价设定，其预测结果仍须经过升级关卡，因此，路由器判断错误会增加费用，但不会损害正确性。
级联的期望成本与延迟
在 图 3 中，每个任务都进入第 1 层。其候选输出暂存在运行时的待处理提案缓冲区中，并接受模式与语法关卡的检查。如果通过，任务便退出。否则，运行时携带验证器的诊断信息升级到第 2 层，只有那些也未通过第 2 层构建与测试关卡的任务才会进入第 3 层。设 \(C_j\) 为第 \(j\) 层一次调用的成本，且 \(C_1 \ll C_2 \ll C_3\)，并设 \(P(\text{fail}_1)\) 和 \(P(\text{fail}_1, \text{fail}_2)\) 分别为任务在第 1 层失败以及在两个较低层级均失败的概率。每个任务的期望成本为
\[E[C_{\text{cascade}}] = C_1 + P(\text{fail}_1) \cdot C_2 + P(\text{fail}_1, \text{fail}_2) \cdot C_3 \tag{5}\]
当满足以下条件时，级联的成本低于将所有任务都发送到第 3 层的成本：
\[C_1 + P(\text{fail}_1) \cdot C_2 < \Big(1 - P(\text{fail}_1, \text{fail}_2)\Big) \cdot C_3 \tag{6}\]
公式 6 的右侧表示低层级解决任务时所避免的前沿模型调用成本。由于前沿模型调用的成本通常比小模型调用高一到两个数量级，即使低层级仅解决一小部分任务，该不等式也成立。
对于升级处理的任务，延迟则朝相反方向变化。设各层级的延迟为 \(T_j\)，门控延迟为 \(T_{V,j}\)，则到达最高层级的任务需要承担沿途每个层级的延迟，
\[T_{\text{worst}} = T_1 + T_{V,1} + T_2 + T_{V,2} + T_3 \tag{7}\]
而期望延迟为
\[E[T_{\text{cascade}}] = T_1 + T_{V,1} + P(\text{fail}_1) \cdot \Big(T_2 + T_{V,2}\Big) + P(\text{fail}_1, \text{fail}_2) \cdot T_3 \tag{8}\]
因此，级联通常会降低平均延迟，但总会增大尾部延迟，其上界为 公式 7。
粗略估算 0.3: 三级级联中的成本与延迟
数学分析：有 0.12 的任务到达第 3 层。根据 公式 5，每个任务的期望成本为 $0.0084，比仅使用前沿模型时的成本低 86%，后者为 $0.0600；每日支出从 $6,000 降至 $840。根据 公式 8，平均延迟为 1.32 秒，比前沿模型快 3.4×，后者的延迟为 4.5 秒。逐层升级并经过所有层的任务耗时 6 秒，比直接调用前沿模型长 33%。
系统启示：级联方案平均而言成本更低、速度更快，但尾部延迟更高。这种权衡是否可以接受，取决于升级处理的任务是否位于受截止时间约束的关键路径上。
错误接受的代价与升级处理规范
公式 5 假设验证关卡绝不会接受错误输出。但实际上会。只检查语法的验证关卡会放行一个能够通过解析却删除了授权检查的补丁，级联流程便在第 2 层停止，而工作区中的一个不变量已遭破坏。如果 \(\alpha_{\text{FA}}\) 是验证关卡接受错误输出的概率，\(C_{\text{recovery}}\) 是后续发现并撤销该输出的成本，则有效成本为
\[C_{\text{eff}} = E[C_{\text{cascade}}] + \alpha_{\text{FA}} \cdot C_{\text{recovery}} \tag{9}\]
由于恢复可能涉及回滚（轨迹 Saga 模式）或人工审查，\(\alpha_{\text{FA}}\) 即使在 公式 9 中很小，也可能抵消级联方案节省的成本。因此，验证关卡必须检查真正重要的属性；对于代码，这意味着运行测试，而不只是进行静态检查。根据验证不对称性（原则 3），学习型评判器可以对候选结果排序，或决定尝试哪一层，但允许输出被最终采纳的验证关卡必须采用错误已知且很少的检查机制。
第二种失败是系统自身造成的。如果运行时在升级处理时，将失败的尝试、其堆栈跟踪和原始提示追加到下一层的上下文中，就会为重新发送冗长的错误答案付出成本，并诱使更强的模型在该错误答案的基础上继续构建。升级处理时应传递任务和验证器的诊断信息，而非失败的输出，如下述调度器所示。
def dispatch_with_escalation(task, tiers, sandbox):
feedback = []
for tier in tiers:
# the prompt carries the task and the last verifier diagnostic only
prompt = build_prompt(task, verifier_feedback=feedback)
candidate = tier.generate(prompt, max_tokens=tier.token_limit)
# the candidate stays pending until an external check accepts it
result = sandbox.run_verifier(candidate)
if result.passed:
sandbox.commit(candidate)
return StepResult(status="ACCEPTED", tier=tier.name, output=candidate)
# drop the failed output; keep a short, deterministic diagnostic
feedback = [f"tier {tier.name} failed: {result.diagnostic}"]
return StepResult(status="ESCALATION_EXHAUSTED", tier=None, output=None)升级本身也需要停止规则。从层级 \(j\) 升级到层级 \(j+1\) 的成本为 \(\Delta C_{j \to j+1}\)，并使验收通过的概率提高 \(\Delta P_{j \to j+1}\)。如果 \(V_{\text{task}}\) 表示一项通过验收的任务的价值，那么只有在以下条件成立时，升级才合算：
\[\Delta C_{j \to j+1} < \Delta P_{j \to j+1} \cdot V_{\text{task}} \tag{10}\]
否则，运行时应停止，并报告有界失败。公式 10 是级联机制中对应于 搜索停止准则 中停止规则的版本，它能防止低成本任务因不断升级而变成高成本任务。
级联和缓存降低了轨迹中每次调用的成本。集群还必须具备执行这些调用的资源，而智能体集群所需的容量与请求服务系统所需的容量不同。
轨迹容量
一个团队沿用为聊天服务规划容量的方法，根据模型调用速率及其服务时间来确定智能体平台的容量，却发现平台既存在资源不足，又存在资源闲置。调用因提供商的速率限制而排队，预留的专用节点却有一半容量闲置；持续占用沙箱和缓存上下文二十分钟的轨迹又挤占了新轨迹所需的资源。占用资源的单位是轨迹，而非调用（原则 23）。本节以轨迹为单位规划容量，然后确定容量应从何处获取。
轨迹并发
一次模型调用持续数秒。一条轨迹持续数分钟，其中大部分时间都在等待工具，而在这整段时间内，它始终占用一个沙箱、运行时中的一个槽位，以及通常缓存在服务节点上的注意力状态。容量的解析表达式 曾将利特尔定律应用于驻留在单个服务节点上的轨迹；该定律给出了整个集群中正在执行的轨迹数量，
\[L_{\text{traj}} = \lambda_{\text{traj}} \cdot \mathbb{E}[T_{\text{traj}}] \tag{11}\]
其中，\(\lambda_{\text{traj}}\) 是轨迹启动速率，\(\mathbb{E}[T_{\text{traj}}]\) 是轨迹的平均生命周期。如果根据调用速率和调用时长，而非 公式 11 来确定沙箱、运行时工作进程和缓存内存的容量，就会低估并发量，低估倍数等于轨迹生命周期与调用时长之比，即相差两到三个数量级。轨迹在等待期间占用哪些资源，是一项设计选择。保留、驱逐、重计算或卸载 决定了在等待工具期间，其注意力状态是保持驻留、被逐出后重新计算，还是被卸载；轨迹排队 则推导了工具等待如何增加并发量。
轨迹发起调用的方式会带来两个后果。当一条轨迹扇出多个工具调用，或协调器启动子智能体时，调用会以相关的突发形式到达，而调用的服务时间则从生成几个词元到数千个词元所需的时间不等。排队延迟会随着这种变异性增大而增长，并在利用率接近饱和时急剧上升；针对单个队列的 Kingman 近似（轨迹排队）可以量化这两种影响。当到达过程具有突发性（\(c_a^2 =\) 2），且生成长度满足 \(c_s^2 =\) 4 时，变异性因子 \((c_a^2 + c_s^2)/2\) 为 3；利用率为百分之 70 的服务资源池会使一次调用的平均等待时间约为平均服务时间的 7 倍，而利用率为百分之 90 的资源池则会使其等待约 27 倍。因此，容量配置应使系统运行在利用率曲线拐点以下。尾部延迟还会沿着轨迹累积，这是 取消级联 中扇出慢任务现象的串行对应情形。对于一条包含 30 次串行调用的轨迹，若每次调用以 0.01 的概率遭遇第 99 百分位延迟，则该轨迹至少遭遇一次此类延迟的概率为 0.26，因此，即使集群容量足以实现良好的平均延迟，仍会经常出现执行缓慢的轨迹 (Dean 和 Barroso 2013年)。
提供商速率限制
对于调用托管模型的团队而言，首先遇到的容量限制通常不是硬件，而是提供商的配额，以每分钟词元数和每分钟请求数表示。配额限制的是轨迹的运行速率，而非可同时处于活动状态的轨迹数量。每条轨迹都需要固定数量的词元才能完成，因此，在稳态下，无论轨迹的生命周期多长，词元需求速率都等于轨迹启动速率乘以每条轨迹的词元数。假设轨迹以每分钟 1 条的速率启动，每条轨迹发起 60 次调用，每次调用包含 30,000 个输入词元，即每条轨迹共 1,800,000 个词元。在每分钟 2,000,000 个词元的限制下，这一需求占用配额的百分之 90，集群最多可持续支持每分钟 1.11 条轨迹。若生命周期为 20 分钟，根据利特尔定律，正在执行的轨迹共有 20 条，每条轨迹每分钟约发起 3 次调用。
如此接近配额上限运行，与服务器接近饱和运行的后果相同。受到限流的调用会在退避后重试，轨迹的生命周期随之延长，占用沙箱和缓存的时间也更长，并导致其完成时间超出截止期限。可以从三个方面着手。前缀缓存可以降低费用，但它是否也能降低配额用量，取决于提供商如何统计缓存词元；容量规划必须核实这一点，而不能自行假定。简短、可靠的轨迹会减少每个通过验收的任务所消耗的词元数，从而在固定配额下提高通过验收的任务速率，其作用与提高配额同样直接。提供折扣、在数小时内返回结果的批处理端点，适用于离线评估运行、轨迹评分和数据筛选等单次调用任务，但不适用于每一轮都必须等待上一轮完成的多轮循环。
优先级通道
交互式轨迹中，用户会等待结果；批处理轨迹则包括夜间问题分流或评估运行等任务。两者共享相同的模型和配额，却有着截然不同的截止时间。如果将它们混放在同一个先到先服务的队列中，一波耗时较长的批量生成任务就会延迟排在其后的所有短交互式调用。运行时将两者分配到优先级不同的通道，并为交互式通道设置准入控制、预留容量余量。在模型服务系统中，即使调度器无法预知一次生成会持续多久，仍可将超过一个令牌时间片的调用降级到优先级较低的队列，从而使短调用始终无需排在长调用之后等待（原则 23）。随后，批处理任务会利用交互式任务留下的空闲容量，而这对于本节最后讨论的决策——是否拥有这些容量——尤为重要。
排队动态
由于智能体平台无法将加速器调度与智能体行为的随机性分离，确定集群规模需要采用能够刻画极端变异性的排队论模型。标准的入门级系统分析通常依赖 \(M/M/1\) 或 \(M/M/k\) 模型，这些模型假设到达过程为泊松过程（到达间隔服从指数分布），且服务时长具有无记忆性、服从指数分布。在生产环境中的智能体集群里，这两项假设均已被证实不成立。
自主智能体产生的模型调用，其到达过程在结构上具有突发性。当编排器启动并行验证子智能体，或智能体执行多步骤规划循环时，请求会以高度相关的批次到达模型服务层，而非形成互不相关的泊松流。到达间隔的变异系数平方定义为 \(C_a^2 = \sigma_a^2 / (\mathbb{E}[T_a])^2\)，通常大于 1（\(C_a^2 > 1\)）。
与此同时，模型服务时间的分布与指数分布相去甚远。智能体集群处理的是双峰混合工作负载：一类是轻量、低延迟的分类探测、JSON 模式验证和单令牌工具路由决策，耗时为数十毫秒（\(S \ll 100\text{ ms}\)）；另一类则是计算量大、包含数千令牌的思维链生成和复杂代码合成，持续数秒（\(S > 10\text{ s}\)）。这种双峰分布的离散性使服务时间的变异系数平方显著大于 1（\(C_s^2 = \sigma_s^2 / (\mathbb{E}[S])^2 \gg 1\)）。
为了估计具有任意到达分布和服务时间分布的队列中的期望等待时间，而不立即诉诸周期精确的离散事件仿真，系统工程师采用针对 \(G/G/1\) 队列的 Kingman 重载近似（公式 12）：
\[W_q \approx \left( \frac{C_a^2 + C_s^2}{2} \right) \left( \frac{\rho}{1 - \rho} \right) \frac{1}{\mu} \tag{12}\]
其中，\(\rho = \lambda / \mu\) 表示服务器利用率，\(\mu = 1 / \mathbb{E}[S]\) 为平均服务速率。Kingman 公式将平均排队等待时间 \(W_q\) 分解为三个明确的乘法因子：
- 变异性因子 \(\frac{C_a^2 + C_s^2}{2}\)： 该项根据到达过程和服务过程的综合离散程度，直接按比例放大延迟。在理想化的 \(M/M/1\) 系统中，若 \(C_a^2 = C_s^2 = 1\)，该因子等于 1。在智能体集群中，相关的突发请求和双峰生成长度使 \(C_a = 1.8\) 和 \(C_s = 2.4\)，变异性因子达到 \(\frac{1.8^2 + 2.4^2}{2} = \frac{3.24 + 5.76}{2} = 4.5\)。在硬件吞吐量和平均到达率保持相同的情况下，仅工作负载的方差就会使系统的平均排队延迟放大 \(4.5\times\)。
- 利用率因子 \(\frac{\rho}{1 - \rho}\)： 当服务器利用率接近饱和时，这一双曲形式的惩罚项决定了非线性的渐近行为。当 \(\rho\) 从 \(0.70\) 上升至 \(0.90\) 时，乘数从 \(2.33\) 跃升至 \(9.00\)，增至近四倍。
- 基础服务时间尺度 \(\frac{1}{\mu}\)： 底层模型未经加权的平均处理时长。
正如 Jeffrey Dean 和 Luiz André Barroso 在《数据中心即计算机》中所阐述的，决定用户感知到的分布式系统性能的是尾部延迟，而非平均延迟。在包含 \(N\) 次串行模型调用的智能体轨迹中，完成整个轨迹且不遭遇第 99 百分位排队延迟的概率按 \((1 - 0.01)^N\) 衰减。
在运行 \(k\) 个并行加速器实例的企业集群中，单服务器 \(G/G/1\) 模型转变为聚合的多服务器 \(G/G/k\) 系统。根据 Allen-Cunneen 近似，多服务器队列的等待时间与 Erlang-C 等待概率 \(P_{\text{wait}}(M/M/k)\) 成正比（公式 13）：
\[W_q(G/G/k) \approx \left( \frac{C_a^2 + C_s^2}{2} \right) \frac{P_{\text{wait}}(M/M/k)}{k\mu(1 - \rho)} \tag{13}\]
虽然将 \(k\) 个加速器汇集到统一的服务集群中能够带来统计复用收益，相较于彼此隔离的单服务器孤岛降低平均等待时间，但这也会加剧多轮轨迹中的尾延迟放大效应。如果一个智能体工作流需要 \(N = 30\) 次顺序模型调用才能完成端到端任务，且运行时以较高的硬件利用率 \(\rho = 0.85\) 运行，那么该轨迹在至少一个关键路径轮次中遭遇极端尾延迟（\(P_{99}\)）的概率为：
\[P(\text{Tail Incident}) = 1 - (1 - 0.01)^{30} = 1 - 0.7397 \approx 0.26\]
所有已执行的智能体轨迹中，超过四分之一会遭遇极端尾延迟。由于智能体轨迹在各个顺序轮次之间同步执行，第 7 轮中的一次尾延迟会直接传导至总完成时间，常常导致宿主编排器违反其全局服务水平目标（SLO）。
粗略估算 0.4: 重尾流量下的队列容量规划
工程负责人提议配置 \(k = 4\) 个工作节点，使其以 \(\rho = \frac{\lambda}{k \mu} = \frac{160}{4 \times 50} = 0.80\) 的平均利用率运行。请使用 Allen-Cunneen 近似计算该配置下的期望排队等待时间 \(W_q\)，并将其与配置 \(k = 5\) 个工作节点（\(\rho = 0.64\)）的备选方案进行比较。
步骤 1：计算变异性缩放因子。 \[\frac{C_a^2 + C_s^2}{2} = \frac{1.4^2 + 2.2^2}{2} = \frac{1.96 + 4.84}{2} = \frac{6.80}{2} = 3.40\]
步骤 2：计算 \(k = 4\) 在 \(\rho = 0.80\) 下的 Erlang-C 等待概率。 对于 \(M/M/4\) 队列，其提供负载为 \(A = k\rho = 3.2\text{ Erlangs}\)： \[P_{\text{wait}}(M/M/4) = \frac{\frac{A^4}{4!(1 - \rho)}}{\sum_{n=0}^{3} \frac{A^n}{n!} + \frac{A^4}{4!(1 - \rho)}} \approx 0.554\]
步骤 3：计算 \(W_q\)，对应配置为 \(k = 4\)。 \[W_q \approx 3.40 \times \frac{0.554}{4 \times 50 \times (1 - 0.80)} = 3.40 \times \frac{0.554}{200 \times 0.20} = 3.40 \times \frac{0.554}{40} = 3.40 \times 0.01385\text{ s} \approx 47.1\text{ ms}\] 在配置 \(k = 4\) 个工作节点时，平均排队等待时间（\(47.1\text{ ms}\)）超过请求本身的平均执行时间（\(20\text{ ms}\)），超出幅度大于 \(2.3\times\)。
步骤 4：评估超额配置至 \(k = 5\)、运行于 \(\rho = 0.64\) 的集群。 对于 \(M/M/5\)，在 \(A = 3.2\text{ Erlangs}\) 条件下，等待概率急剧下降至 \(P_{\text{wait}}(M/M/5) \approx 0.237\)。 \[W_q \approx 3.40 \times \frac{0.237}{5 \times 50 \times (1 - 0.64)} = 3.40 \times \frac{0.237}{250 \times 0.36} = 3.40 \times \frac{0.237}{90} = 3.40 \times 0.00263\text{ s} \approx 8.95\text{ ms}\]
要点： 仅增加一个加速器节点的容量（硬件扩容幅度为 \(25\%\)），就能将平均排队等待时间从 \(47.1\text{ ms}\) 降至 \(8.95\text{ ms}\)，延迟降幅超过 \(80\%\)。在重尾智能体服务环境中，必须在利用率曲线拐点以下（\(\rho \le 0.70\)）运行，才能吸收变异性并保护多轮轨迹的关键路径。
面向智能体工作负载的多级反馈队列调度
当智能体服务集群通过不加区分的先来先服务（FCFS）队列调度所有请求时，就会遭遇经典的队头阻塞问题。一次需要生成 4,096 个输出 token 的大型多步骤代码生成调用，会连续数秒占用加速器的连续批处理槽位。如果交互式用户或对延迟要求严格的监督智能体在这个大型任务之后提交一个 10-token 的路由查询，这个短查询就会因排在耗时较长的解码阶段之后而被延迟。这种性能退化违背了计算系统的核心调度目标：在事先不知道确切执行时长的情况下，通过优先处理短任务（最短作业优先）来最小化平均响应时间。
由于主机运行时无法在推理前预测自回归生成的确切 token 长度，因此无法实现纯粹的最短处理时间（SPT）调度。集群必须转而采用自适应的多级反馈队列（MLFQ）调度策略，并针对 token 生成的内存与计算机制进行适配（图 4）。
如 图 4 的系统示意图所详述，该架构分为左侧的活跃优先级调度器和右侧的物理内存层次结构。在调度平面中，所有新到达的智能体任务都进入 \(Q_0\)，初始获得不可抢占的 token 配额 \(\Delta_0 = 64\text{ tokens}\)。简短的语义分类器探测和工具分派决策会在该配额内完成，并以亚毫秒级的排队延迟离开系统。需要较长时间思考的任务会耗尽 \(\Delta_0\)，随后降级至 \(Q_1\)（\(\Delta_1 = 512\text{ tokens}\)，轮转调度）；而长时程的代码生成和代码仓库重构任务则会降级至 \(Q_2\)（\(\Delta_2 \ge 4{,}096\text{ tokens}\)，FCFS 批处理）。向上的优先级提升弧线通过实际调度机制防止后台任务饥饿：它将 \(Q_1\) 和 \(Q_2\) 中的所有待处理请求以原子方式移回 \(Q_0\)，这一操作每 \(T_{\text{boost}} = 60\text{ seconds}\) 执行一次。
与此同时，图 4 的右侧面板展示了调度器如何在各个物理硬件层级上与 PagedAttention 内存管理机制对接。当 \(Q_1\) 或 \(Q_2\) 请求在被抢占时让出其连续批处理槽位，加速器 HBM 中的键值缓存块会受到宽限期 \(\tau_{\text{grace}}\) 的保护，以防止颠簸。在持续的内存压力下，内存管理器会启用 PCIe Gen5 DMA 通道，将非活跃页面迁移到主机 DDR5 RAM（\(64\text{ GB/s}\) 双向传输）。如果空闲时间超过经济驱逐的盈亏平衡阈值（\(T^* \approx 70\text{ ms}\)），页面就会转存到本地 NVMe 存储（\(7\text{ GB/s}\)），从而确保对延迟要求严格的 \(Q_0\) 调用具有较高的 HBM 驻留率，同时保留计算成本高昂的预填充状态。
面向智能体的 MLFQ 将加速器容量划分为不同的优先级层级，以管理抢占、批次组装和内存占用：
- 优先级队列 0（\(Q_0\)，交互与探测）： 所有新到达的模型调用均进入 \(Q_0\)。该层级被分配最高调度优先级和具有严格上限的词元生成时间片（例如，\(\Delta_0 = 64\text{ tokens}\)）。\(Q_0\) 中的调用包括交互式用户查询、快速语义分类器探测、工具调用路由决策和安全护栏检查。如果调用在 \(\Delta_0\) 个词元以内完成生成（输出一个
EOS词元或工具分派序列），便立即退出系统，从而实现极短的排队等待时间和接近零的尾延迟。 - 优先级队列 1（\(Q_1\)，多轮推理）： 如果调用耗尽其 \(Q_0\) 词元时间片后仍未终止，调度器便在词元边界抢占其前向传播，将任务降级至 \(Q_1\)，并对其执行状态进行上下文切换。\(Q_1\) 采用更大的时间片（例如，\(\Delta_1 = 512\text{ tokens}\)）和中等调度优先级。该层级承载常规智能体思考轮次、标准代码编辑和多句推理步骤。
- 优先级队列 2（\(Q_2\)，长程批处理轨迹）： 超过 \(\Delta_1\) 个词元的任务会被降级至 \(Q_2\)，即优先级最低的后台队列。\(Q_2\) 采用大额度词元时间片（\(\Delta_2 \ge 4,096\text{ tokens}\)），或不受限制的运行至完成机制。该层级处理异步后台任务：大规模全仓库重构、合成测试套件生成、离线嵌入流水线和非紧急验证。\(Q_2\) 中的调用被明确设定为可抢占；如果 \(Q_0\) 或 \(Q_1\) 的到达量激增，正在执行的 \(Q_2\) 请求便让出其连续批处理槽位。各层级的运行参数汇总于 多级反馈队列优先级层级配置。
| 队列层级 | 优先级 | 词元时间片（\(\Delta\)） | 目标工作负载 | 抢占策略 |
|---|---|---|---|---|
| \(Q_0\) | 最高 | 64 个词元 | 交互式 UI、安全护栏、工具调用路由探测 | 时间片内不可抢占 |
| \(Q_1\) | 中等 | 512 个词元 | 标准推理循环、单文件代码生成 | 可被 \(Q_0\) 抢占 |
| \(Q_2\) | 最低 | 4,096+ 个词元 | 仓库重构、测试生成、批量评估 | 可被 \(Q_0\)/\(Q_1\) 抢占；可换出至主机内存 |
为保持架构稳定性，智能体 MLFQ 必须解决两个关键系统挑战：饥饿和 KV 缓存内存抖动。
如果 \(Q_0\) 和 \(Q_1\) 中的高优先级交互流量使集群饱和，\(Q_2\) 中长时间运行的批处理轨迹就会无限期饥饿。为确保任务持续推进这一不变量，调度器实施周期性优先级提升。每隔固定时间 \(T_{\text{boost}}\)（例如，每 60 秒），所有优先级层级中尚未获得服务的任务都会被移回 \(Q_0\)，重置其已消耗的时间片计数器，确保后台轨迹定期取得进展（多级反馈队列调度规则）。
集群调度器依据确定性的转换规则，将智能体推理作业划分为具有不同优先级的执行层级：
- 入口分配： 所有传入调用均进入最高优先级队列 \(Q_0\)，并获得 \(\Delta_0 = 64\) 个词元的初始时间片。
- 时间片耗尽降级： 如果执行线程耗尽分配的时间片后仍未完成，也未发出 I/O 等待，则向下层降级： \[Q_k \xrightarrow{\text{exhausts } \Delta_k} Q_{k+1}\] 具体转换为从 \(Q_0 \to Q_1\)（\(\Delta_1 = 512\text{ tokens}\)）以及 \(Q_1 \to Q_2\)（\(\Delta_2 \ge 4{,}096\text{ tokens}\)）进行转换。
- 完成退出： 在其时间片 \(\Delta_k\) 内完成解码或为工具执行而让出执行权的调用，会立即退出调度队列并返回结果。
- 周期性优先级提升： 为消除 \(Q_2\) 中的长程饥饿，每隔 \(T_{\text{boost}}\) 秒，\(Q_1\) 和 \(Q_2\) 中的所有活动任务都会以原子方式提升回 \(Q_0\)，并重置时间片。
- 分层内存保留： 被抢占的 \(Q_1\) 任务在宽限时间 \(\tau_{\text{grace}}\) 内保留其物理 HBM 分配；若内存压力持续，则通过 PagedAttention 将 \(Q_2\) 块迁移至主机内存。
第二个挑战涉及抢占期间的物理内存管理。当一个 \(Q_2\) 作业被抢占，以释放张量核心来应对新到达的 \(Q_0\) 突发流量时，将其累积的 4,000 个词元的 KV 缓存逐出至主机 CPU RAM 会消耗宝贵的互连带宽。如果被抢占的任务在几毫秒后重新获准执行，将这些物理页换回 HBM 会造成严重的 PCIe/NVLink 抖动。MLFQ 调度器通过分层逐出阈值缓解这一问题：被抢占的 \(Q_1\) 任务在宽限时间 \(\tau_{\text{grace}}\) 内以挂起状态保留其物理 HBM 页分配。只有当内存压力持续且 \(Q_0\) 耗尽空闲 HBM 页框池时，PagedAttention 内存管理器才会触发向主机 DDR5 内存的异步页面迁移。经典队列调度规则与自适应队列调度规则之间的权衡比较见 智能体推理的集群调度规则比较分析。
| 调度规则 | 平均等待时间（\(W_q\)） | 尾延迟（\(P_{99}\)） | 饥饿风险 | 抢占开销 | 内存效率（KV 缓存） |
|---|---|---|---|---|---|
| 先到先服务（FCFS） | 高 | 严重（队首阻塞） | 无 | 零 | 低（内存被固定占用导致停滞） |
| 最短处理时间（SPT） | 最优 | 短作业低；长作业高 | 大型任务的风险严重 | 零（需要预知信息） | 高（作业快速完成并释放资源） |
| 多级反馈队列（MLFQ） | 接近最优 | \(Q_0/Q_1\) 中低；\(Q_2\) 上有界 | 通过 \(T_{\text{boost}}\) 限定 | 低至中等（时间片边界） | 高（分层内存迁移） |
专用容量与按词元计费的 API
团队可以按词元为模型调用付费，也可以预留专用服务容量并自行运行模型。按词元计费将所有成本转化为可变成本，并将排队、限流和多租户干扰交由提供商处理。专用容量无论繁忙还是空闲，每小时成本都相同；作为回报，它消除了配额限制，使尾延迟保持稳定，并允许根据工作负载调整推测执行和缓存策略等服务选项。哪种方式更便宜，取决于专用容量的繁忙程度。
设 \(C_{\text{node}}\) 为专用节点的每小时成本，包括硬件摊销或租赁、电力和运维成本，并设该节点在该工作负载的轨迹上能够持续达到每秒 \(R_{\text{out}}\) 个输出词元。如果该工作负载每生成一个输出词元就发送 \(\kappa\) 个输入词元，而 API 对每个词元的收费分别为 \(P_{\text{in}}\) 和 \(P_{\text{out}}\)，则按 API 价格计算，一个满负荷节点一小时完成的工作将花费
\[V_{\text{node}} = 3600 \cdot R_{\text{out}} \cdot \left( P_{\text{out}} + \kappa \cdot P_{\text{in}} \right) \tag{14}\]
若节点处于繁忙状态的时间比例为 \(\rho\)，则其完成的工作按 API 价格计费为 \(\rho V_{\text{node}}\)，因此，当 \(\rho\) 超过盈亏平衡利用率，即 \(C_{\text{node}}\) 除以 公式 14 时，专用容量更便宜，
\[\rho^* = \frac{C_{\text{node}}}{3600 \cdot R_{\text{out}} \cdot \left( P_{\text{out}} + \kappa \cdot P_{\text{in}} \right)} \tag{15}\]
输入项需要谨慎处理。智能体工作负载的 \(\kappa\) 很大，因为每一轮都会重新发送上下文；而 API 的缓存输入折扣会降低实际的 \(P_{\text{in}}\)，这会提高 \(\rho^*\)，使采用专用容量更难证明其经济合理性。比较时应使用该工作负载实际支付的缓存输入价格，而非标价。
粗略估算 0.5: 专用模型服务容量的盈亏平衡点
计算：按 API 价格计算，每个输出 token 及其对应输入的成本折合为每百万输出 token $30，因此，一个始终满负荷运行的节点每小时完成的工作按 API 价格计值为 $129.60，根据 公式 15，盈亏平衡利用率为 0.22。在预计利用率下，一个节点每小时完成价值 $67.39 的工作，成本为 $28，每小时节省 $39.39，相当于 API 账单的 58%。
系统洞见：token 密集型智能体工作负载在较低利用率下就能达到盈亏平衡，但这一结论仅在采用输入 token 标价时成立。对于相同的工作量，缓存输入折扣会降低 API 账单，因此，在预留容量之前，必须按折扣价格重新计算盈亏平衡点。
如 混合资源配置 所示，大多数集群最终会同时采用这两种方式。专用资源池按基础负载确定规模，并使其利用率保持在利用率曲线的拐点以下；交互式轨迹优先使用该资源池，批处理轨迹填补其空闲时段，超出其容量的突发负载则溢出到按 token 计费的 API。
| 资源配置层级 | 容量来源 | 规模配置依据 | 成本模型 | 工作负载 |
|---|---|---|---|---|
| 专用资源池 | 预留的模型服务节点 | 基础负载，保持在拐点以下 | 每小时固定费用 | 交互式通道优先；批处理轨迹填补空闲时间 |
| 按 token 计费的 API | 托管模型端点 | 超出基础负载的突发负载 | 按 token 计费 | 溢出负载，以及集群未托管的模型 |
Checkpoint 0.2: 轨迹所需的容量
在治理支出之前，先检查容量模型：
容量限制了集群花钱的速度，却不限制其支出总额。陷入循环的轨迹，或不断委派任务的子智能体树，会耗尽分配给它们的所有容量，因此，运行时需要直接限制金额。
支出治理
预算与上限 中的运行框架预算能够阻止单条轨迹陷入失控循环（失控循环及终止它的预算）。任务委派则会引入单轨迹预算无法察觉的失效情形。一个协调器还剩两美元，却启动了两个子智能体。每个子智能体都读取共享余额，看到有两美元可用，随后发起一次成本接近两美元的调用。两次检查都通过，两次调用都执行，合计支出接近父智能体剩余金额的两倍。沙箱写入可以回滚，但花在 token 和工具费用上的钱无法追回，因此，在智能体消耗的资源中，支出是任何恢复机制都无法挽回的那一种。不变量闭合（原则 不变闭包原则）直接适用于此处。不能依赖模型自行计量支出，也不能依赖它察觉何时应该停止，因此，支出上限必须由运行时在每次分派前执行的检查来保障。本节将 预算与上限 中的美元预算扩展到多个智能体从同一笔额度中并发支出的情形，并增加对支出速率的限制。
支出不变量
设 \(C(t)\) 为某个任务截至步骤 \(t\) 的累计支出。每项计费操作都会增加一个正金额，因此 \(C(t)\) 只会增加。运行时还知道已经承诺但尚未支付的金额。一个正在执行的模型调用，其成本至多为最大输出 token 数乘以输出价格，再加上输入成本；工具调用则有已知费用。设 \(R(t)\) 为这些预留金额之和。运行时维持以下不变量
\[C(t) + R(t) \le B_{\text{task}} \tag{16}\]
在每一步都满足任务预算 \(B_{\text{task}}\) 的约束。在派发操作之前，系统会预留该操作在最坏情况下的成本；如果预留会违反该不等式，系统便不派发操作，而是返回一个带类型的预算超限观测，即 控制操作 中的控制动作。操作完成后，预留金额会被实际成本替代，差额则被释放。使用调用的最大输出字段（调用契约）确定预留金额，即使调用运行至其上限，也能保证该界限成立。
分层预算预留
只有一个智能体时，公式 16 是一个计数器。当存在协调器和子智能体（委派的权衡）时，多个智能体会同时支出，共享余额便会引发本节开头所述的竞态。单调委派（原则 21）提供了消除这一竞态的规则。分配给子智能体的任何预算，在子智能体返还之前，都必须从父智能体的可用预算中扣留。衰减能力委派 将这一规则应用于权限。这里，它成为一种预算预留账本机制，图 5 展示了一次委派过程中的账本变化。
委派树中的每个节点 \(k\) 都维护一个账本 \(\mathcal{L}_k = \langle B_k, E_k, R_k, F_k \rangle\)，记录其预算 \(B_k\)、已结算支出 \(E_k\)、预留金额 \(R_k\) 和可用余额 \(F_k\)，并满足
\[B_k = E_k + R_k + F_k, \quad E_k, R_k, F_k \ge 0 \tag{17}\]
已结算支出只增不减。预留资金用于覆盖正在执行的调用和子智能体的预算，不能再次承诺用于其他支出。只有可用资金才能为新操作提供资金。预算账本状态转换 给出了四种状态转换，每一种都保持 公式 17 成立。
| 事务 | 前置条件 | 父智能体账本 | 子智能体账本 |
|---|---|---|---|
| 创建子智能体 | \(\Delta B \le F_P\) | \(R_P \leftarrow R_P + \Delta B\), \(F_P \leftarrow F_P - \Delta B\) | \(B_C = F_C = \Delta B\), \(E_C = R_C = 0\) |
| 派发调用 | \(c_{\text{est}} \le F_C\) | 不变 | \(R_C \leftarrow R_C + c_{\text{est}}\), \(F_C \leftarrow F_C - c_{\text{est}}\) |
| 结算调用 | 实际成本 \(c\) 已知 | 不变 | \(E_C \leftarrow E_C + c\), \(R_C \leftarrow R_C - c_{\text{est}}\), \(F_C \leftarrow F_C + (c_{\text{est}} - c)\) |
| 子智能体结束 | 子智能体已停止，无论原因为何 | \(E_P \leftarrow E_P + E_C\), \(R_P \leftarrow R_P - B_C\), \(F_P \leftarrow F_P + (B_C - E_C)\) | 已关闭 |
子智能体只能查看自己的账本，不能动用父智能体的可用余额；孙级智能体的资金同样来自其父智能体的可用余额。由于每笔预留金额都在支出之前扣除，且每个子智能体的支出都受其预留金额约束，因此，无论委派树有多深、并发程度有多高，任何创建子智能体和调用的序列都不可能使总支出超过根预算。陷入循环的子智能体会耗尽自己的预留金额并停止，而其兄弟智能体和父智能体不受影响。账本还回答了运维人员针对每个集群都会提出的问题：是谁花了这些钱。为每个租户或每张工单设置一个根任务后，只需读取根账本即可完成成本归因。
粗略估算 0.6: 子智能体失败过程中的预算账本
计算：规划阶段结算 $0.042，剩余可用资金为 $4.958。委派任务预留 $3.70，剩余 $1.258 可供协调器自身的调用使用。当两个子智能体均停止时，它们的支出结算到根账本中，未使用的预留资金 $0.82 和 $1.65 则返还至根账本的可用余额。最终，根账本已支出 $1.272，无预留资金，可用资金为 $3.728。
系统洞见：无论陷入循环的子智能体做了什么，其支出都不可能超过预留额度，而协调器仍保有足够资金尝试另一种方法。这一上界由账本保证，而非由子智能体的行为保证。
账本核算不变量
智能体委派树中的每个节点 \(k\) 都维护一个独立且隔离的账本上下文，由以下四元组定义：
\[\mathcal{L}_k = \langle B_k, E_k, R_k, F_k \rangle\]
这些字段的语义分别对应资金的不同物理状态和财务状态：
- 分配预算（\(B_k\)）： 直属父节点授予节点 \(k\) 的资金总额上限。该值在节点 \(k\) 的整个生命周期内保持不变。
- 已结算支出（\(E_k\)）： 因已完成的推理过程、已最终确认的工具执行以及已完成的子进程而永久扣除、不可收回的资金。已结算支出单调递增。
- 托管预留资金（\(R_k\)）： 为运行中的子智能体或待完成的异步工具调用专门预留的资金。托管资金不能再用于新的操作。
- 可用资金（\(F_k\)）： 尚未承诺用途、尚未预留，可立即用于发起新操作的余额。
这些变量受严格的守恒不变量约束：
\[B_k = E_k + R_k + F_k, \quad \text{where } E_k \ge 0, \; R_k \ge 0, \; F_k \ge 0\]
多速率熔断器
虽然静态累计支出上限 \(B_{\text{task}}\) 能保证智能体不会超出绝对财务预算，但静态上限是一种过于粗粒度、因而存在危险的控制机制。如果一个自主智能体具有 \(\$50.00\) ceiling enters a pathological code generation loop that burns \(\$10.00\) 每分钟的支出速率，静态上限会允许系统失控运行整整五分钟，在停止之前生成数百个无用文件，并使执行沙箱陷入频繁抖动。
工具熔断器 中的工具熔断器已经允许运行时在无需模型配合的情况下切断发生故障的依赖。这里，同样的三状态熔断器监测的是不同信号，即资金消耗速率和认知效用衰减，而非套接字超时和错误比例。
熔断器类比 在电网中，当电流消耗（\(I = \frac{dQ}{dt}\)）危险地激增时，断路器会跳闸，以防止火灾。在智能体系统中，当资金消耗速率（\(\frac{dC}{dt}\)）超出安全范围边界时，熔断器会触发。
智能体熔断器充当包裹在模型调度流水线外部的动态监督器。它持续在三种运行状态之间转换：
- 闭合（正常）： 正常调度操作。产生的成本和状态变化量被记录到滚动滑动窗口中。
- 断开（已触发）： 熔断器检测到不变量被违反。后续所有推理请求、工具调度和子智能体初始化均立即失败（
fail-fast）。当前轨迹被暂停，运行时启动自动回滚或升级至人工操作员处理。 - 半开（金丝雀探测）： 在冷却间隔结束或恢复环境检查点后，运行时允许执行一次有明确资源上限的“金丝雀”探测（例如一次低成本的反思过程或一个确定性单元测试），以验证智能体是否已恢复连贯性。如果探测失败，熔断器立即恢复至
OPEN。支配这一控制循环的状态转换和运行不变量在 熔断器状态机 中进行了形式化描述。
| 当前状态 | 转换触发因素 / 条件 | 目标状态 | 不变量守卫与操作语义 | 系统恢复操作 |
|---|---|---|---|---|
| CLOSED（正常） | 速率突增（\(\bar{\nu}_W > \nu_{\max}\)）、效用衰减（\(\Delta \mathcal{U} < \epsilon\)）或不变量违反 | OPEN | 立即触发快速失败陷阱；停止推理和工具调度 | 暂停轨迹，取消待处理的子任务，记录告警 |
| OPEN（已触发） | 冷却窗口结束（\(\Delta t > \tau_{\text{cool}}\)）或检查点回滚完成 | HALF-OPEN | 允许执行隔离的单步金丝雀评估探测 | 发起有界内省或隔离的单元测试 |
| HALF-OPEN（金丝雀） | 金丝雀探测失败或再次触发不变量违反 | OPEN | 强制执行指数冷却退避（\(\tau_{\text{cool}} \leftarrow 2 \tau_{\text{cool}}\)） | 升级至人工操作员处理或终止轨迹 |
| HALF-OPEN（金丝雀） | 金丝雀探测成功且状态验证通过 | CLOSED | 重置连续失败计数器并解除托管冻结 | 恢复正常的多轮模型调度流水线 |
为提供全面的纵深防御，宿主运行时实现了三种不同且相互正交的熔断触发机制。
支出速率限制
支出速率熔断器监控支出相对于时间的瞬时一阶导数：\(\nu(t) = \frac{dC}{dt}\)。在离散运行时中，该值通过时长为 \(W\) 的回溯滑动窗口计算（例如，60 秒）：
\[\bar{\nu}_W(t) = \frac{C(t) - C(t - W)}{W}\]
如果 \(\bar{\nu}_W(t)\) 超过获准的资金消耗速率阈值 \(\nu_{\max}\)（例如，\(\$2.00 / \text{minute}\)），熔断器会立即触发并转入 OPEN。速率突增通常意味着智能体已通过大规模扇出生成大量未经协同的子智能体、进入了针对外部 API 的未限流轮询循环，或触发了自回归循环，以冗余的上下文窗口使本地 GPU 预填充引擎达到饱和。
轨迹累计上限
累计熔断器强制执行硬边界条件 \(C(t) + R(t) \ge B_{\text{task}}\)。速率熔断器根据速率触发，而累计熔断器则约束总量。它充当最终的故障保护机制，防范那些速率较低却高度持久、执行数小时仍进展甚微的智能体轨迹。触发后，运行时会保留当前沙箱状态，转储诊断性执行跟踪，并将智能体转入静止状态，等待人工授权扩增预算。
边际认知效用衰减
自主系统中最隐蔽且破坏性最大的失效模式是认知循环：智能体的支出速率始终远低于限制，并且只消耗了总预算的一小部分，但它已不再朝着任务完成取得可衡量的进展。智能体生成代码、运行单元测试、观察到断言错误、修改无关的注释或变量名、再次运行测试，并无限重复这一循环。
为检测这种异常，运行时会评估轨迹的边际认知效用。令 \(\mathcal{S}_t\) 表示环境在第 \(t\) 轮的可观测状态（例如，源代码目录树、编译器诊断向量和测试执行结果）。我们定义进展度量 \(\mathcal{M}(\mathcal{S}_t) \in [0, 1]\)，用于衡量与目标不变量的客观接近程度：
\[\mathcal{M}(\mathcal{S}_t) = w_1 \cdot \text{PassRatio}(\mathcal{S}_t) + w_2 \cdot (1 - \text{LintErrors}(\mathcal{S}_t)) + w_3 \cdot \text{DiffConvergence}(\mathcal{S}_t)\]
其中，\(w_1, w_2, w_3\) 表示归一化的领域权重。跨越 \(K\) 轮评估窗口的边际效用定义为：
\[\Delta \mathcal{M}_K(t) = \mathcal{M}(\mathcal{S}_t) - \mathcal{M}(\mathcal{S}_{t - K})\]
如果运行时观察到，在连续 \(K\) 轮中，累计支出显著增加（\(\sum_{j=t-K+1}^t c_j > \theta_C\)），而边际进展度量仍停滞不前或有所下降：
\[\Delta \mathcal{M}_K(t) \le \epsilon_{\text{progress}}\]
认知衰减熔断器便会触发并转入 OPEN。运行时会停止循环，诊断判定模型已耗尽其针对当前环境状态的推理能力，继续执行只会消耗资金，而不会提高达成目标的概率。三种熔断器所监控的指标、数学触发条件及其缓解的失效模式汇总于 多速率熔断器触发条件与失效模式缓解措施。
| 熔断器 | 监控指标 | 数学触发条件 | 缓解的主要失效模式 |
|---|---|---|---|
| 速率限制器 | 资金消耗速率 \(\frac{dC}{dt}\) | \(\frac{C(t) - C(t - W)}{W} > \nu_{\max}\) | 并发子任务扇出激增；未限流的 API 轮询循环 |
| 累计上限 | 总风险敞口 | \(C(t) + R(t) \ge B_{\text{task}}\) | 长时间运行导致的渐进式耗尽；未经授权的项目预算超支 |
| 认知衰减 | 边际效用 \(\frac{\Delta \mathcal{M}}{\Delta C}\) | \(\Delta \mathcal{M}_K \le \epsilon\) 且 \(\Delta C_K > \theta_C\) | 无效的重试循环；表面性的代码调整；循环推理陷阱 |
一旦通过单调账本、分层托管和多速率熔断器在数学上为支出设定了上界，系统工程师就可以安全地将自主智能体部署到生产环境中。然而，强制执行支出上界仅解决了集群运行中的负面风险——防止经济灾难。正向的设计挑战依然存在：对于一项已知延迟、预算和准确率约束的具体生产任务，架构师应如何确定，是采用确定性的编译器脚本、一次带结构化输出的模型调用、由专用模型组成的顺序链，还是完全动态的多智能体系统来解决？下一节将讨论如何综合这些运行变量，形成一套有原则依据的选择准则。
为架构选择定价
拥有可用智能体的团队，很容易想让它处理所有任务。架构决策矩阵：工作流与模型导向循环 给出了判断任务是否需要模型主导循环的方法。有了每项验收通过任务的成本、关键路径延迟和支出风险，现在就可以为这一决策定价，而价格往往决定了选择。以智能体方式完成任务，成本最高、可预测性最低；只有在更低成本的方法无法奏效时，才值得为其付费。
架构谱系的定价
架构谱系的定价 将四种设计置于一个谱系中，架构决策矩阵：工作流与模型导向循环 中的四个问题用于从中选择：确定性代码、固定工作流中的单次模型调用、有界智能体循环，以及共同处理一项任务的多个智能体。延迟和成本列给出的是数量级，而非测量值。每向右迈进一步，都会获得更多灵活性，同时付出成本、延迟、方差以及运行时必须提供的闭环保障方面的代价。
| 维度 | 确定性代码 | 单次模型调用 | 有界智能体循环 | 多个智能体 |
|---|---|---|---|---|
| 控制流 | 固定在代码中 | 固定流水线，包含一个模型步骤 | 在轮次上限内由模型主导 | 具有类型化交接的任务图 |
| 延迟 | 微秒至毫秒 | 数百毫秒至数秒 | 数秒至数分钟 | 数分钟至数小时 |
| 每项任务成本 | 可忽略不计 | 每次调用固定，\(10^{-5}\) 至 \(10^{-3}\) 美元 | 各轮成本之和，\(10^{-2}\) 至 \(10^{-1}\) 美元 | 数美元至数十美元 |
| 携带的状态 | 程序变量和表 | 请求之外无其他状态 | 上下文、工作区、轨迹记录 | 分区的上下文和工作区 |
| 故障恢复 | 异常处理和重试 | 重新解析、备用模型 | 根据反馈重试、回滚、补偿 | 协调器重新规划、升级至人工处理 |
| 验证依据 | 单元测试和类型 | 模式检查 | 沙箱中的测试和检查 | 每次提交的不变量关卡、端到端测试、人工审查 |
图 6 展示了架构自主性谱系中这些维度之间的权衡。
四个问题的定价
时域、状态和权限分别决定了任务必须为哪些闭环保障付费。
架构决策矩阵：工作流与模型导向循环 中的四个问题，根据任务在 H·S·A 三个维度上的风险暴露（H·S·A 暴露面），以及运行时能够为其收集的闭环证据（闭合证据等级），确定任务的位置。每一项都有其代价，本章现在可以明确说明这些代价。
时域的代价体现在时间和优势比上。每一轮都会增加关键路径耗时，并重新发送上下文；截止时间只有一两秒的任务，无法承受每轮都耗时数秒的循环。更长的时域还会使每一步的失败风险累积，因此，自然执行长度为多轮的任务，需要较高的单步成功率或经过验证的中间里程碑，才能使 \((1-\alpha)/\alpha\) 保持较小。
状态的代价体现在上下文上。无需携带状态的输入到输出转换，只需单次调用即可完成；将其包装成循环，只会增加上下文重传和失效模式，而不会增加价值。必须观察并修改工作区的任务，每一轮都要为 节 2 带来的上下文增长付费，具体代价由缓存布局和压缩策略决定。
权限的代价体现在审批和错误成本上。其影响仅限于可丢弃沙箱（\(A_1\)）内的任务，可以作为有界循环运行。影响可补偿（\(A_2\)）的任务也可以如此，但前提是每个超时操作在重试前都已完成结算（原则 9），并且需要为补偿机制付费。具有不可逆影响（\(A_3\)）的任务，每次执行此类操作都要付出审批关卡（审批关卡）的代价，其 \(C_{\text{human}}\) 项也不再只是偶尔出现。
闭环证据的代价体现在验证上，而这一问题最常决定最终选择。如果存在快速、可信的检查手段，例如测试套件或编译器，低成本模型就可以依据检查结果迭代；检查每筛选一次尝试，每项验收通过任务的成本就会下降。如果不存在这样的检查手段，增加轮次和智能体数量也无法使结果收敛到正确答案；它们只会增加成本，结果仍需人工审查。这类任务适合采用单次调用加人工审查的方式，其成本主要由 \(C_{\text{human}}\) 决定。
循环何时值得采用
最常需要进行的比较，是单次调用强模型与围绕较低成本模型构建有界循环之间的比较。对于最多执行 \(K\) 轮、依据验证器进行验证的循环，若在此前各轮均失败的条件下，第 \(r_k\) 所表示的条件成功概率对应于第 \(k\) 轮，则产出验收通过结果的概率为
\[p_{\text{loop}}(K) = 1 - \prod_{k=1}^K (1 - r_k) \tag{18}\]
其期望成本等于每轮成本乘以实际执行轮数的期望值。当未解决的任务转交人工处理、成本为 \(C_{\text{human}}\) 时，每种设计的单张工单成本都等于其计算成本加上 \((1 - p) C_{\text{human}}\)，而人工成本项通常决定最终选择。
粗略估算 0.7: 依赖升级的三种设计方案成本测算
数学计算：根据 公式 18，该循环的成功概率为 0.82，平均执行 1.71 轮，计算成本为 $0.014，每个工单耗时约 12.3 秒。加上失败后的人工处理成本，使用重写器时单个工单的成本为 $23.80，使用单次调用时为 $11.24，使用循环时为 $6.41，对应的每月成本分别为 $238,010、$112,450 和 $64,082。
系统洞见：循环的成本比单次调用低 43%，比重写器低 73%，尽管其计算成本仅比单次调用低几美分。它的优势在于测试套件。能够看到构建失败并再次尝试的廉价模型，可以将低成本的尝试转化为通过验收的修复。如果没有这种检查，循环就没有可用于迭代的反馈依据。
多个智能体将同样的逻辑进一步延伸。只有在总预算相同的情况下，多智能体设计在每项通过验收任务的成本、耗时或验收率上优于单个智能体，同时在其余指标上不落后，才有采用的价值（原则 20）；而无论是否做到这一点，它都必须承担协同开销（原则 19）。只有当通过验收的任务所带来的收益超过新增轮次、验证、协同和治理的成本时，才应提高自主程度，而本章的核算方法正是判断这一点的依据。
服务经济性综合分析
集群管理员若分别优化模型服务、工具执行和调度策略，最终必然会发现，局部效率的提升会叠加为整个集群层面的灾难性低效。通过定制的 flash-attention 或推测验证来加速自回归解码内核，可使受 GPU 性能限制的解码延迟降低 \(2.5\times\)，然而整个轨迹的实际耗时降幅却不足 \(6\%\)，如果智能体运行时在关键路径上有 \(82\%\) 的时间因同步容器镜像重建和外部沙箱 RPC 而停滞。同样，部署激进的模型级联，将查询路由到参数量不足十亿的模型，虽然能大幅降低名义上的词元推理费用，但如果廉价模型较低的指令遵循能力引发反复的语法重试和轨迹回滚，那么每项通过验收任务的累计成本就会急剧上升。
自主智能体集群的经济可行性并非底层神经网络权重或推理内核的固有属性，而是支配其调用的闭环控制系统的涌现属性。 要使系统的经济回报最大化，就需要将完整轨迹的成本核算、关键路径延迟分解、推测加速、分层模型路由和基于排队论的集群资源配置，整合到一个能够自我平衡的统一运行时中。当这些子系统彼此孤立地运行时，就会产生适配失衡：调度器用长上下文轨迹挤满 GPU 显存，使交互式查询得不到所需资源；与此同时，路由级联将复杂推理任务分派给能力有限的模型，这些模型在失败之前会消耗不成比例的工具和验证预算。
多层级经济控制循环
为避免这些失效模式，生产环境中的智能体平台必须将其控制流组织为一个包含五个流水线阶段的闭环反馈引擎（图 7）。每个阶段都强制执行一项形式化的系统契约，将无特权用户的意图转化为经过验证的外部状态修改，同时主动尽量减少资源消耗。
沿着 图 7 的端到端流水线追踪可见，传入请求在向外部环境提交变更之前，需要经过五道相互协同的系统屏障。在第 1 阶段（工作负载分析器与资金托管），入口路由器解析提示词语义，确立 SLA 截止时间，并配置初始托管资金额度（\(B_{\text{task}}\)）。在第 2 阶段（MLFQ 集群调度器），请求进入优先队列 \(Q_0\)，同时遵循满足 Kingman 安全条件的集群利用率目标（\(\rho \le 0.70\)），通过 token 配额（\(\Delta_0=64, \Delta_1=512, \Delta_2\ge 4{,}096\)）将交互式探测与批处理轨迹隔离，并通过周期性提升优先级（\(T_{\text{boost}} = 60\text{ s}\)）防止饥饿。
在第 3 阶段（分层路由级联），执行轮次尝试在成本最低的可行层级完成求解：\(60\%\) 的语法性轮次在 SLM 层正常终止（\(C_1 = \$0.0004\)), \(28\%\) resolve at the mid-tier generalist (\(C_2 = \$0.0024\)），仅有 \(12\%\) 升级至前沿模型，使每轮预期成本达到 \(E[C] = \$0.0084\). In Stage 4 (Speculative Decoding Engine), heavy frontier invocations are accelerated directly on GPU tensor cores using an aligned draft model that speculatively generates \(\gamma = 3..5\) tokens per forward pass (\(\alpha_{\text{accept}} = 0.75\)), collapsing critical-path decode latency. Finally, in Stage 5 (Hierarchical Ledger & Verifier), the model holds zero ambient authority and every proposed action executes in an isolated sandbox; only when deterministic mechanical verifiers certify correctness does the transaction commit, returning unexpended escrow to the tenant. The entire pipeline is enclosed by a global feedback bus that continuously optimizes cluster Goodput per Dollar (\(\text{GP}_{\$}\)），并根据实时缺陷率动态调整路由阈值和队列时间片。
该引擎的第一阶段是工作负载分析器。当任务请求到达平台入口时，分析器会检查提示词载荷、用户指定的截止时间、请求租户的历史轨迹特征以及工具能力需求。分析器并不将所有请求视为同质的 token 序列，而是将传入流量划分为不同的执行类型：短时且有界的交互式查询、多轮确定性工作流，以及无界的探索性智能体轨迹。通过提取结构不变量，例如查询是否需要执行任意代码，或仅需提取结构化数据，分析器计算出一个初始资源预留向量，其中包含内存边界、工具速率限制以及初始托管资金。
第二阶段是多级反馈队列（MLFQ）集群调度器。当长时间运行的随机性智能体轨迹与单轮交互式请求共享物理计算队列时，会产生灾难性的队首阻塞，而该调度器可防止这一问题。传入任务进入最高优先级队列（\(Q_0\)），该队列立即分配一个较小的计算时间片，以优化首 token 延迟（TTFT）并快速完成初始规划。如果任务耗尽时间片后仍未终止或进入外部等待状态，调度器会将其降级到优先级较低、吞吐量较高的批处理队列（\(Q_1, Q_2\)）。这种分离确保长时间运行的轨迹在针对高密度连续批处理和高吞吐量配置的集群上运行，而对延迟敏感的用户轮次则在负载未饱和的低延迟节点上运行。
第三阶段是分层路由级联，它将 L. Chen 等 (2023年) 在 FrugalGPT 中确立的原则付诸实施。当已调度的智能体轮次需要神经网络推理时，运行时不会默认使用能力最强的前沿模型，而是将上下文发送至轻量级小语言模型（SLM），该模型被配置为生成中间推理草稿、经模式验证的工具调用或候选验证检查。SLM 的输出会经过一个无特权输出验证器。如果 SLM 生成的工具模式无效、在关键 token 上表现出较低的 logit 置信度，或表明无法解析提示词的依赖图，级联机制就会将该调用升级至中间层模型或前沿推理模型。通过在最低层级完成绝大多数语法格式化、工具路由和状态摘要步骤，级联机制将昂贵的前沿模型容量保留给复杂规划和错误恢复。
第四阶段是推测解码引擎，直接嵌入物理推理集群。当升级后的任务必须在大规模目标模型（\(M_{\text{target}}\)）上运行时，运行时系统会将目标模型与一个对齐的草稿模型（\(M_{\text{draft}}\)）配对。草稿模型沿 Amdahl 关键路径推测性地生成 \(\gamma\) 个候选词元。目标模型在一次并行前向传播（GEMM）中评估这 \(\gamma\) 个词元，接受与自身概率分布相符的前缀，并在首次拒绝时回退到自身的分布。由于推测解码保证在数学上等价于直接从 \(M_{\text{target}}\) 采样，运行时系统能够大幅加速自回归生成，而不会引入随机漂移或降低任务成功率。
第五阶段是分层预算账本与不变量托管。每一次下游执行——无论是推测性前向传播、SLM 路由检查、容器化编译器运行，还是外部 SaaS API 调用——都必须依据严格单调的预算账本获得授权。当子智能体被创建以执行子问题时，父智能体会拆分自身托管的资源，为子智能体分配更小且不可续增的额度。如果子智能体进入反复重试的循环，或未能在分配的预算内推动状态进展，账本就会触发硬性熔断。智能体修改后的状态会被托管；只有当外部确定性测试套件通过时，运行时系统才会将该变更提交到权威生产存储。这五个阶段的契约、机制、优化目标和失效模式汇总于 集群经济性控制循环的机制与接口。
| 控制循环阶段 | 输入契约 | 主要机制 | 优化目标 | 缓解的失效模式 |
|---|---|---|---|---|
| 1. 工作负载剖析器 | 原始任务与历史元数据 | 上下文与依赖关系静态分析 | SLA 分类；托管额度确定 | 资源过度配置；沙箱资源饥饿 |
| 2. MLFQ 调度器 | 剖析器分类与轮次时间片 | 动态时间片降级 | P99 交互式 TTFT；集群吞吐量 | 队头阻塞；KV 缓存耗尽 |
| 3. 路由级联 | 经验证的上下文与意图层级 | 分阶段能力升级（SLM \(\to\) 前沿模型） | 每个中间步骤的成本（\(C_{\text{turn}}\)） | 前沿模型过度使用 |
| 4. 推测解码 | 活跃词元流与草稿模型 | 对 \(\gamma\) 个草稿词元进行并行验证 | 词元间解码延迟（\(T_{\text{decode}}\)） | 内存带宽限制下的计算资源利用不足 |
| 5. 分层账本 | 已分配的托管额度与执行差异 | 单调记账与熔断器 | 任务财务误差有界 | 失控的无限循环；预算耗尽 |
每美元有效吞吐量：统一目标
优化智能体集群需要一种能够连接硬件效率与企业效用的指标。传统机器学习基础设施指标——如每秒词元数、FLOP 效率或 GPU 利用率——在智能体系统中会产生实质性的误导。一个让不受约束的智能体陷入无限循环的集群，可以达到 \(98\%\) 的模型 FLOPs 利用率（MFU），每秒生成数万个词元，却不产生任何功能价值。反之，纯粹基于每百万词元原始成本的基础设施指标，会鼓励选择廉价但能力退化、无法解决用户任务的模型。
在集群规模下，节 1 中以验收通过的任务为目标的指标表现为每美元有效吞吐量（\(\text{GP}_{\$}\)), the number of verified, defect-free tasks completed per unit of total economic expenditure. It is the reciprocal of \(C_{\text{effective}}\)。微效与宏效 中的轨迹有效吞吐量衡量用于最终通过验收的任务的资源占比，而每美元有效吞吐量衡量每美元能够换来多少个通过验收的任务：
\[\text{GP}_{\$} = \frac{N_{\text{acceptable}}}{\sum_{i=1}^M C_{\text{task}}^{(i)}}\]
在这一表达式中，\(M\) 表示集群接纳的任务总数，\(C_{\text{task}}^{(i)}\) 表示任务 \(i\) 的完整轨迹综合成本。如我们的任务成本核算框架所述，\(C_{\text{task}}\) 涵盖整个尝试生命周期中消耗的所有资源：
\[C_{\text{task}} = \sum_{k=1}^K \left( C_{\text{prefill}}^{(k)} + C_{\text{decode}}^{(k)} + C_{\text{tool}}^{(k)} + C_{\text{sandbox}}^{(k)} \right) + C_{\text{verify}} + C_{\text{human}}\]
分子 \(N_{\text{acceptable}}\) 表示在没有预算外人工干预的情况下满足所有功能不变量的任务数量：
\[N_{\text{acceptable}} = \sum_{i=1}^M \mathbf{1}\left( \text{Verified}(i) \land \neg \text{Defect}(i) \right)\]
这里，\(\text{Verified}(i)\) 是一个二元指示变量，表示任务的最终输出是否成功通过外部确定性验证框架（例如单元测试套件、集成代码检查工具或模式检查器）。\(\neg \text{Defect}(i)\) 项确保排除误接受的情况，即通过语法测试却引入潜在回归问题或安全漏洞的解决方案。
Definition 0.2: 每美元有效吞吐量
粗略估算 0.8: 集群每美元有效吞吐量的评估
1. 硬件与提供商定价依据：
- 前沿模型（\(M_{\text{target}}\)）：\(\$10.00\) per \(10^6\) prefill tokens; \(\$30.00\)，每 \(10^6\) 个解码 token。
- 小语言模型（\(M_{\text{draft}}\) / 级联第 1 层）：\(\$0.20\) per \(10^6\) prefill tokens; \(\$0.60\)，每 \(10^6\) 个解码 token。
- 临时执行沙箱：\(\$0.06\) per CPU-hour (\(\$1.67 \times 10^{-5}\)，每秒）。
- 确定性验证套件：每次执行 \(\$0.02\)。
- 人工升级处理分诊：每次缺陷修复 \(\$15.00\)。
2. 基线：朴素单体架构
- 轨迹动态：每个任务均在 \(M_{\text{target}}\) 上运行。平均每条轨迹需要 \(K = 6\) 轮。
- 每轮：\(4{,}000\) 个预填充 token、\(500\) 个解码 token、\(45\) 秒沙箱执行。
- 任务准确率：首次通过率为 \(p = 0.65\)。其余 \(35\%\) 未通过验证，直接丢弃，不进行人工修复（\(N_{\text{acceptable}} = 650\)）。
- 每轮 token 成本：\((4{,}000 \times 10^{-5}) + (500 \times 3 \times 10^{-5}) = \$0.040 + \$0.015 = \$0.055\)。
- 每轮沙箱成本：\(45 \times (1.67 \times 10^{-5}) = \$0.00075\)。
- 轨迹成本（\(6\) 轮）：\(6 \times (\$0.055 + \$0.00075) = \$0.3345\)。
- 验证成本：\(\$0.02\). Total cost per task: \(\$0.3545\)。
- 集群总成本：\(1{,}000 \times \$0.3545 = \$354.50\)。
- 基线有效吞吐量： \[\text{GP}_{\$}^{\text{naive}} = \frac{650 \text{ tasks}}{\$354.50} \approx \mathbf{1.83 \text{ accepted tasks / dollar}}\]
3. 综合架构：
工作负载剖析与级联：所有轮次中的 \(60\%\)（文件搜索、语法检查、git 暂存）完全由 \(M_{\text{draft}}\) 处理。仅有 \(40\%\) 的轮次升级至 \(M_{\text{target}}\)，以完成复杂的算法合成。
推测解码：应用于所有 \(M_{\text{target}}\) 调用，草稿模型为 \(M_{\text{draft}}\)（\(\gamma = 4\)，平均接受率为 \(\alpha = 0.75\)）。解码的实际耗时缩短 \(2.1\times\)，从而减少生成期间的沙箱占用时间。
每轮 token 成本（级联第 1 层——SLM，占轮次的 60%）： \[(4{,}000 \times 2 \times 10^{-7}) + (500 \times 6 \times 10^{-7}) = \$0.0008 + \$0.0003 = \$0.0011\]
每轮 token 成本（级联第 2 层——前沿模型 + 推测解码草稿模型，占轮次的 40%）： 前沿模型成本仍为 \(\$0.055\). Draft generation overhead adds \(500 \times \gamma \times (6 \times 10^{-7}) \approx \$0.0012\)。每轮 token 总成本：\(\$0.0562\)。
平均每轮 token 成本：\((0.60 \times \$0.0011) + (0.40 \times \$0.0562) = \$0.00066 + \$0.02248 = \$0.02314\)。
每轮沙箱成本：延迟降低使沙箱驻留时间从 \(45\text{s}\) 降至 \(28\text{s}\)： \[28 \times (1.67 \times 10^{-5}) = \$0.00047\]
任务成功与重试：分层预算机制允许困难任务最多执行 \(K = 8\) 轮。首次通过率升至 \(p = 0.82\)。对于其余 \(180\) 个任务，\(100\) 通过自动升级重试得到解决（增加 \(3\) 轮第 2 层执行），而 \(80\) 明确失败并被标记为需人工审核（被拒绝的批次省略 \(C_{\text{human}}\)，或完成修复：假设 \(N_{\text{acceptable}} = 820 + 75 = 895\)）。
1,000 个任务的有效平均轮数：\(6.8\) 轮。
轨迹执行成本：\(6.8 \times (\$0.02314 + \$0.00047) = \$0.1605\)。
验证成本：\(\$0.02\). Average cost per task: \(\$0.1805\)。
集群总成本：\(1{,}000 \times \$0.1805 = \$180.50\)。
综合架构有效吞吐量： \[\text{GP}_{\$}^{\text{synth}} = \frac{895 \text{ tasks}}{\$180.50} \approx \mathbf{4.96 \text{ accepted tasks / dollar}}\]
综合构建的系统实现了每美元有效吞吐量提升 \(2.71\times\)，同时将集群支出削减 \(49.1\%\)，并将任务产出提高 \(37.7\%\)。
最大化每美元有效吞吐量揭示了服务经济性的根本权衡：当且仅当边际支出能使任务被接受的概率实现超线性增长时，增加单个任务的支出才具有经济合理性。相反，降低任务成功率的成本削减策略，即使仅使成功率略微下降，也常常导致每美元有效吞吐量骤降，因为工具基础设施、预填充词元和验证的固定成本都浪费在了无法挽回的失败上。
集群的经济运行包络
将智能体集群从单个独立实例扩展到更大规模，会引入由排队论和共享资源争用所支配的显著非线性效应。为了维持经济上的可持续性并满足服务级别协议（SLA），基础设施架构师必须定义系统的经济运行包络。这一包络表示一个多维参数空间，其边界由到达率（\(\lambda\)）、并发度（\(N\)）、任务复杂度（\(K\)）和预算上限（\(B\)）共同限定；集群在该空间内能够稳定运行。
Neil J. Gunther 的通用可扩展性定律对并发度为 \(N\) 时的系统容量进行建模： \[C(N) = \frac{N}{1 + \sigma(N - 1) + \kappa N(N - 1)}\] 其中，\(\sigma\) 衡量串行化瓶颈处的争用，\(\kappa\) 衡量串扰或一致性延迟。
在对集群扩展进行建模时，简单的线性容量假设并不成立。我们采用 Neil J. Gunther 的通用可扩展性定律（USL）来刻画智能体服务集群的有效容量 \(C(N)\)，该集群承受的并发轨迹负载为 \(N\)。在智能体系统中，争用参数 \(\sigma\) 刻画了对共享物理资源的排队等待：GPU 工作节点上的高带宽内存（HBM）、容器虚拟机监控器内并发容器实例化数量的限制，以及外部工具 API 提供方的速率限制。一致性参数 \(\kappa\) 则刻画了协同和串扰引起的性能倒退效应：共享预算账本中的分布式锁争用、集群节点间的上下文缓存失效，以及并行状态提交期间的数据库串行化。
如果运维人员将并发度 \(N\) 推至 USL 曲线峰值（\(N_{\max} = \lfloor \sqrt{(1 - \sigma)/\kappa} \rfloor\)）之外，系统就会进入性能倒退并崩溃的运行区间。队列开始积压，预填充激活值从 GPU SRAM 溢出到主机系统 DRAM，沙箱初始化时间的尾部延迟被极度放大。由于智能体轨迹受顺序依赖链约束，第 \(k\) 轮的延迟突增会拖延第 \(k+1\) 轮至第 \(K\) 轮。如果延迟超过客户端超时阈值，整条轨迹就会中止，使 \(N_{\text{acceptable}}\) 降为零，而已发生成本中的 \(100\%\) 仍然需要承担。
为了强制系统严格运行在稳定包络内，综合构建的运行时实现了三项硬性边界不变量：
首先，动态准入边界根据当前集群的队列深度调节任务准入。调度器使用我们在容量配置框架中建立的 \(M/G/k\) 排队模型，当 \(Q_0\) 中的预计等待时间可能导致交互式会话违反 P95 TTFT SLA 时，拒绝接纳或丢弃低优先级的后台轨迹：
\[W_{Q_0}(\lambda) + \mathbb{E}[T_{\text{prefill}}] \le \text{SLA}_{\text{interactive}}\]
其次，单调升级上限限制模型级联的深度和资金消耗速率。除非预期信息增益超过成本增量，否则禁止智能体调用更高层级的推理模型。形式化地说，如果从模型层级 \(j\) 升级到层级 \(j+1\) 会产生增量成本 \(\Delta C_{j \to j+1}\)，则当且仅当满足以下条件时才允许升级：
\[\Delta C_{j \to j+1} < \left( \mathbb{P}_{j+1}(\text{Success}) - \mathbb{P}_j(\text{Success}) \right) \cdot V_{\text{task}}\]
其中，\(V_{\text{task}}\) 表示成功完成任务的经济价值。如果不满足这一条件，运行时就会终止轨迹，报告一次成本有界的失败，而非继续为成功概率很低的恢复尝试消耗资金。
第三，阿姆达尔效率门控决定对推测解码和加速的投入。运行时持续测量关键路径的实际耗时中，自回归解码所占的比例（\(\alpha_{\text{decode}}\)）与工具及沙箱执行所占的比例（\(\alpha_{\text{env}} = 1 - \alpha_{\text{decode}}\)）。如果性能剖析发现 \(\alpha_{\text{decode}} < 0.20\)，运行时就会针对该任务类型禁用推测草稿生成。当环境延迟主导关键路径时，将 GPU 内存带宽和计算核心用于推测草稿验证，只能带来微乎其微的端到端加速，却会浪费原本可用于支持更大批量并行请求的内存容量。
通过持续依据实测运行边界，平衡准入速率、模型档位、解码加速和预算台账，综合形成的架构确保集群实现最高的单位美元有效吞吐量。
然而，将这些架构原则转化为生产系统充满风险。当系统设计者从理论表述转向实际实现时，往往会陷入直觉上合理却会造成灾难性后果的运行陷阱。驳斥这些常见的系统误解，并明确指出基础模型部署中有关物理约束的具体谬误，是掌握服务经济学所必需的最后一步。
谬误与陷阱
设计和运行生产级智能体系统，需要跨越微基准测试中的推理延迟与宏观经济层面的集群稳定性之间危机四伏的鸿沟。硬件加速器、网络互连结构和基础模型 API 呈现出非线性的成本曲面，使天真的运行假设付出沉重代价。当系统工程师将非确定性的智能体轨迹等同于传统的无状态远程过程调用（RPC）时，由此形成的架构会遭遇灾难性的财务失控、严重的吞吐量崩溃，以及工程投入的浪费。以下谬误与陷阱揭示了智能体服务基础设施中出现的具体物理与经济失效模式。
谬误： 严格按照 API 的每 token 价格评估模型成本，就能找出最经济的模型。
基础模型提供商公布以每百万 token 的美元费用计价的标价，由此形成了一种直观却危险的启发式判断：换用更便宜的模型就能直接降低运营支出。这种微观价格指标在结构上具有误导性，因为它将原始 token 的输入与生成，同完成自主任务所需的随机状态空间遍历割裂开来。在智能体运行时中，总财务支出并不由 token 单价决定，而是由整条轨迹的成本方程决定：
\[C_{\text{effective}} = \frac{\mathbb{E}[C_{\text{task}}] + (1 - p_{\text{success}}) C_{\text{human}}}{p_{\text{success}}}\]
其中，\(\mathbb{E}[C_{\text{task}}] = \sum_{k=1}^K C_{\text{turn}, k} + C_{\text{tool}} + C_{\text{runtime}} + C_{\text{verify}}\)涵盖了 \(K\) 个顺序轨迹步骤中的累计预填充与解码费用、沙箱环境执行费用、工具调用开销，以及确定性验证运行的费用。参数 \(p_{\text{success}}\) 表示生成的轨迹在不违反环境不变量的情况下，通过全部基于真实标准的验收测试的实测概率；\(C_{\text{human}}\) 表示失败或损坏的状态必须由工程师检查并修复时产生的事后排查成本。
当一个无特权预测器的潜在能力较低时，轨迹动态会沿三个相互依赖的维度恶化。首先，模型会生成格式错误的工具调用、无效的模式定义和幻觉文件路径，触发反复的自我纠正循环，从而大幅增加轨迹长度 \(K\)。由于每个对话步骤都会将此前的工具输出追加到工作上下文中，输入 token 的预填充量呈二次增长：
\[\text{Total Tokens} \approx \sum_{k=1}^K (S_{\text{prompt}} + k \cdot \Delta S)\]
其中，\(S_{\text{prompt}}\) 是基础系统提示词，\(\Delta S\) 是每轮累积的上下文增量。一个名义上便宜、却需要 \(K=12\) 轮才能完成任务的模型，其处理的 token 总量远高于一个能在 \(K=2\) 轮内正确规划的先进前沿模型。
其次，较弱的模型会执行多余且具有破坏性的工具操作。每增加一轮，都会产生外部沙箱计算成本、数据库读写单元费用和网络出站流量费用，这些费用往往远超推理 API 的收费。第三，也是最关键的一点，较低的推理能力会降低最终通过率 \(p_{\text{success}}\)。由于下游业务流程无法容忍未经验证的幻觉，未被自动化沙箱拦截的失败会流入人工审核队列。如果人工工程排查成本为 \(\$60.00\) per hour (\(\$1.00\) 每分钟），而审核一个有缺陷的补丁需要五分钟（\(C_{\text{human}} = \$5.00\)), a failure rate of \(30\%\) adds an amortized overhead of \(\$2.14\) 每次任务尝试——这会完全淹没 token 折扣带来的不足一美分的节省。
架构层面的防御要求将遥测重点从单位 token 消耗转向每次通过验收的任务完成所对应的有效成本（\(C_{\text{effective}}\)）。生产服务运行框架必须配备端到端核算台账，跟踪完整的轨迹生命周期，将 token 使用量、沙箱运行小时数、工具 API 费用和验证开销，与任务验证测试套件的通过或失败结果关联起来。优化目标必须围绕每美元已验证产出的帕累托前沿来定义，只有当较便宜模型的实测单次通过成功概率 \(p_{\text{success}}\) 达到运行阈值时，才将任务路由给这些模型。
陷阱： 当工具等待时间主导关键路径时，仍优化词元生成速度。
当交互式智能体响应迟缓时，系统工程师往往将优化工作集中在推理服务上：调优自回归解码内核、实现推测解码，或将权重从 16 位浮点数（FP16）迁移至 4 位整数量化（INT4）。尽管这些措施提高了生成吞吐量，却往往无法使端到端任务的实际耗时得到可感知的改善。
这种工程投入的错配源于忽视了支配智能体轨迹的顺序依赖关系。关键路径延迟 \(T_{\text{trajectory}}\) 可划分到三个互不重叠的执行域中：
\[T_{\text{trajectory}} = \sum_{k=1}^K \left( T_{\text{model}, k} + T_{\text{tool}, k} + T_{\text{runtime}, k} \right)\]
其中，\(T_{\text{model}, k}\) 是第 \(k\) 轮的预填充与自回归解码总时长，\(T_{\text{tool}, k}\) 表示外部 API 或环境交互延迟，\(T_{\text{runtime}, k}\) 则涵盖主机端开销，包括 IPC 序列化、沙箱容器隔离屏障和上下文重建。根据阿姆达尔定律，通过加速推理组件所能实现的理论加速比 \(S_{\text{task}}\)，严格受限于模型所占的执行时间比例：
\[S_{\text{task}} = \frac{1}{(1 - f_{\text{model}}) + \frac{f_{\text{model}}}{s_{\text{model}}}}, \quad \text{where } f_{\text{model}} = \frac{\sum_{k=1}^K T_{\text{model}, k}}{T_{\text{trajectory}}}\]
在 示例跟踪记录 的跟踪记录中，模型占实际耗时的 9.4%，因此，速度达到原来 4× 的模型只能使轨迹执行加速至 1.08×，而即使模型瞬时完成，也只能达到 1.10×。仅测试运行就占用了 78.6% 的时间。解决办法是在投入优化之前先查看跟踪记录：预热沙箱池、构建缓存、测试选择和并行工具调用，才能缩短实际位于关键路径上的耗时。
在自主软件工程、数据分析或多服务编排智能体中，\(f_{\text{model}}\) 通常很小。以执行测试套件的软件工程智能体为例：前沿模型可能在 \(1.5\text{ s}\)（\(T_{\text{model}} = 1.5\text{ s}\)）内生成一条 bash 命令，但执行该命令需要启动隔离容器、编译抽象语法树、拉取软件包依赖，并运行耗时为 \(45\text{ s}\)（\(T_{\text{tool}} = 45\text{ s}\)）的测试套件，随后还需花费 \(1.0\text{ s}\) 进行运行时日志截断和沙箱同步（\(T_{\text{runtime}} = 1.0\text{ s}\)）。在这种情况下，\(f_{\text{model}} \approx 0.031\)（模型约占关键路径的 \(3.1\%\)）。将推理解码速度提高到原来的四倍，即从 \(30\text{ tokens/s}\) 提升至 \(120\text{ tokens/s}\)（\(s_{\text{model}} = 4.0\)），会将生成时间从 \(1.5\text{ s}\) 缩短至 \(0.375\text{ s}\)，得到的端到端任务加速比为：
\[S_{\text{task}} = \frac{1}{(1 - 0.031) + \frac{0.031}{4.0}} = \frac{1}{0.969 + 0.00775} \approx 1.024\]
这项工程干预付出了显著增加架构复杂性的代价，却只实现了难以察觉的 \(2.4\%\) 总体延迟降幅。
正确的系统缓解措施要求在着手优化之前，对关键路径进行严格的分布式跟踪。通过在智能体循环的各次迭代之间传播分布式跟踪上下文头，工程师可以定位真正的结构性瓶颈：容器冷启动初始化、阻塞式网络 I/O、同步数据库轮询，以及冗余的环境状态清理。缓解措施必须集中在 \(f\) 最高的环节：利用写时复制（CoW）内存派生机制预热容器沙箱池，通过异步运行时并行执行独立的工具调用，缓存确定性的工具输出，以及流式传输执行日志，以便在工具完成之前启动推测性预填充。
谬误： 推测解码在所有服务负载下都能减少模型资源用量。
推测解码利用轻量级草稿模型 \(M_{\text{draft}}\) 预测包含 \(\gamma\) 个候选词元的序列，随后由主目标模型 \(M_{\text{target}}\) 在一次经过修改的前向传播中并行验证这些词元。由于验证过程将 \(\gamma\) 次受内存带宽限制的顺序向量—矩阵乘法（GEMV）转化为一次受计算能力限制的矩阵—矩阵乘法（GEMM），推测解码能够显著降低独立的单批次推理请求的逐词元解码延迟。这种延迟降低常常误导系统架构师，使其认为推测解码在任何条件下都能节省硬件计算资源，因此应在所有服务层级中全局启用。
这一失效机制源于一种根本性的物理权衡：推测解码以浮点运算量（FLOPs）换取实际运行延迟的降低。对于每个生成长度为 \(\alpha \le \gamma + 1\) 的已接受序列的验证步骤，服务系统所付出的计算量包括：执行 \(\gamma\) 次经过 \(M_{\text{draft}}\) 的前向传播，再执行一次经过 \(M_{\text{target}}\)、覆盖 \(\gamma + 1\) 个词元的前向传播。由于推测接受率严格小于 1（\(\beta < 1.0\)），被拒绝的草稿词元意味着相应计算被丢弃。推测解码每生成一个经过验证的词元所消耗的总 FLOPs 严格高于标准自回归解码：
\[\text{FLOPs}_{\text{speculative}} = \frac{\gamma \cdot \text{FLOPs}(M_{\text{draft}}) + (\gamma + 1) \cdot \text{FLOPs}_{\text{attn+proj}}(M_{\text{target}}) + \text{FLOPs}_{\text{FFN}}(M_{\text{target}})}{\mathbb{E}[\alpha]}\]
在批大小极小（\(B \approx 1\)）的低并发服务负载下，GPU 显存总线是实际运行中的制约性瓶颈。此时，硬件在 Roofline 模型中处于明显受内存带宽限制的区域，算术强度远低于加速器张量核心的饱和阈值。在这些条件下，基于缓存权重执行的额外 FLOPs 实际上是“免费”的，因为它们被 \(M_{\text{target}}\) 的内存读取延迟所掩盖，从而在不损害吞吐量的情况下缩短实际运行时间。
然而，在为数百条并发轨迹提供服务的生产智能体集群中，推理集群在较大的聚合批大小（\(B \gg 1\)）下处于高度饱和状态。在这一运行点，批处理使内存带宽达到饱和，将引擎推入计算受限区域，此时张量核心的算术运算利用率接近物理容量上限。在这种状态下，算术运算周期不再是免费的。\(M_{\text{draft}}\) 执行的冗余 FLOPs，以及对被丢弃草稿分支的验证，会直接与并发请求争夺执行流水线、功能单元和 SRAM 寄存器文件。此外，将 \(M_{\text{draft}}\) 部署在同一设备上会消耗关键的高带宽内存（HBM），挤占原本可分配给 PagedAttention 物理 KV 缓存池的容量。由此造成的 KV 缓存页框缩减迫使调度器抢占活跃序列，或人为限制最大批大小，直接降低集群整体吞吐量（\(tokens/second\)），并增加调度池中的排队延迟 \(W\)。
架构层面的防御措施要求采用负载感知的动态推测解码启停控制。运行时必须持续监控加速器计算利用率、活跃批大小和调度队列深度。只有对在关键路径上执行、对延迟敏感且未进行批处理的任务，才应动态启用推测解码；一旦服务集群进入计算受限的饱和状态，需要最大化全局聚合的每美元有效吞吐量，就应自动停用推测解码。
陷阱： 允许子智能体在没有分层预算预留的情况下派生子工作进程。
复杂的智能体框架经常实现动态任务分解，允许父智能体实例化专门的子智能体，以执行辅助子程序、开展并行网络搜索，或排查代码编译失败。一种普遍且后果灾难性的实现反模式，是让子工作进程默认拥有对父智能体所用组织级 API 凭据或全局支出额度的访问权限。当子智能体拥有不受计量约束、默认即可使用的计算资源分配权限时，递归委派就会造成一种无边界的分布式资源耗尽漏洞。
这一失效机制源于非特权模型规划的非确定性与循环故障恢复轨迹的结合。如果子智能体遇到含义不明确的工具故障或无法解决的环境状态，其内部提示循环可能会判定，将问题分解为多个并行子任务是最优恢复策略。如果每个子智能体又能在没有结构性约束的情况下派生更多工作进程，系统就会产生失控的异步进程级联：
\[N_{\text{active}}(d) = \prod_{i=0}^d b_i\]
其中，\(b_i\) 是在递归深度 \(d\) 处派生工作进程的分支因子。如果上游工具 API 出现暂时性中断或语义模式变更，所有活跃工作进程都会同时遇到相同错误。集群将该故障解释为需要进一步分解的问题，继而引发补救工作进程数量的递归爆炸，每个进程都会将冗长的错误跟踪信息读入自己的工作上下文。
由于 token 摄入成本会在所有活跃分支上累积，不受约束的子智能体级联会在几分钟内耗尽价值数千美元的商业 API 额度，或使本地部署的 GPU 集群的 KV 缓存资源枯竭。此外，以不受计量约束的并发方式运行的子工作进程会对内部沙箱造成分布式拒绝服务（DDoS）状况，使容器守护进程的套接字队列饱和、耗尽临时网络端口，并导致数据库连接池耗尽。父进程事后发送的取消请求需要经过异步队列，往往在子工作进程已经执行了大量冗余且产生费用的推理调用链之后才到达。
架构层面的缓解措施要求严格实现遵循最小权限原则的分层预算预留账本。在这一架构中，子智能体的创建由事务性的额度托管系统进行管控（表 3）：
| 预算账本不变量 | 架构强制执行机制 | 所防止的系统故障 |
|---|---|---|
| 无隐式权限 | 子工作进程仅获得短期有效、通过密码学机制限定权限范围的会话令牌，其中包含严格的 token 数量上限和金额上限。 | 防止工作进程使用组织全局密钥或父级资源池账户产生费用。 |
| 严格的预算守恒 | 剩余配额为 \(B_{\text{parent}}\) 的父进程在创建子进程 \(k\) 时，必须托管一部分预算 \(B_{\text{child}} \le B_{\text{parent}} - B_{\text{reserved}}\)，并相应扣减自身账本余额。 | 消除财务支出的无限扩张；整个集群的支出树受到根用户配额的严格约束：\(\sum B_{\text{leaves}} \le B_{\text{root}}\)。 |
| 单调且不自动补充的限额 | 子级账本余额只能减少；补充预算必须向父级监督进程发出显式的阻塞式 RPC 请求。 | 阻止失控循环；当子进程耗尽其微额预算时，会被强制暂停并置于运行时托管状态。 |
| 消耗速率熔断器 | 宿主监督进程在滑动窗口内评估瞬时消耗速率 \(dC/dt\)。 | 当 token 消耗速率超出安全运行参数时，触发确定性关闭，在额度耗尽之前隔离存在缺陷的递归。 |
在这一机制下，当子工作进程耗尽分配给它的托管预算时，运行时监督进程会拦截越界行为，终止推测执行分支，回收未使用的 KV 缓存块，并强制父进程以确定性方式处理失败，而非创建不受约束的补救工作进程。
掌握模型服务的物理边界和经济边界，就能破除将智能体集群构建为无状态、解耦的软件模块的幻觉。完整轨迹成本核算、关键路径上的阿姆达尔定律限制、动态推测解码阈值与分层托管治理之间的相互作用表明，可信赖性和经济可行性是整个运行时监督系统的涌现属性。将这些经济不变量整合为统一的系统方法，为可持续的集群运行奠定了基础。
总结
智能体的价值以其完成的任务计酬，而非以其输出的 token 计酬；集群中的每项设计决策都要根据每个通过验收的任务所需的成本和时间来评判。这一成本涵盖每一轮交互、每一次重新发送的上下文、沙箱运行的每一秒、每一次测试运行，以及每一次失败尝试；其中，几率比 \((1-\alpha)/\alpha\) 将失败尝试的成本计入成功尝试。长轨迹中最大的 token 成本项是重新发送的上下文，因此，采用稳定布局的前缀缓存是首要优化手段；只有剩余执行跨度足够长时，上下文压缩才有收益；推理预算和重试预算则取决于可信的验证器能否让低成本尝试在首次成功时停止。耗时取决于执行跟踪中的关键路径，而工具和沙箱往往占据其中的大部分时间，因此，更快的推理和推测解码只有用于该路径上的调用，且服务容量尚有余量时，才会带来收益。由验证器把关的级联可以避免在不需要前沿模型的调用上使用它，前提是验证关卡检查了真正重要的内容。容量通过利特尔定律以轨迹为单位进行配置；对于托管模型，容量还受提供商配额约束。当利用率超过盈亏平衡点时，专用容量才具备经济优势，而缓存带来的费用折扣会抬高这一利用率门槛。金钱是唯一无法通过恢复操作挽回的资源，因此，预算预留限制了任何子树能够支出的总额，支出速率限制则约束了支出的速度；同一套核算方法也决定了某项任务是否值得使用智能体。
要点回顾: 以通过验收的任务计价，而非以 token 计价
- 失败尝试决定价格：每个通过验收的任务的成本，都将每一次失败尝试和每一项模型以外的成本计入成功任务，因此，即使模型的 token 价格便宜得多，每个完成任务的成本仍可能高出数倍。
- 重新发送的上下文是最大的 token 成本项：在长轨迹中，采用仅追加布局的前缀缓存可以将费用降至原来的几分之一；提示词开头只要有一个频繁变化的字段，就会丧失这一收益；只有剩余执行跨度足够长时，上下文压缩才有收益。
- 执行跟踪决定时间花在哪里：更快的推理，包括推测解码，只能按模型在关键路径中所占的比例缩短轨迹耗时，而工具和沙箱往往占据该路径的大部分时间。
- 低成本模型需要可信的验证关卡：只有外部检查能够拦截错误输出时，级联和重试才会降低成本；薄弱的验证关卡会将节省的成本转化为错误验收和恢复工作。
- 轨迹占用容量和资金：根据轨迹生命周期配置并发量，根据每条轨迹的 token 数量配置配额，并在每个子进程支出之前预留其预算，因为已经花掉的钱永远无法回滚。
本章为三项原则赋予了定量形式。轨迹有效吞吐量与通过验收的任务（原则 22）具体化为完整轨迹成本方程及其几率比，并以此评判从缓存、级联到专用容量的每一种优化手段。基于轨迹生命周期的容量配置与考虑尾部延迟的调度（原则 23）具体化为利特尔定律下的轨迹并发量、提供商配额限制轨迹处理速率这一观察，以及串行调用中尾部延迟的累积。单调委派（原则 21）具体化为任何并发子进程都无法透支的预留账本；这一点之所以重要，是因为沙箱写入可以回滚，而花掉的一美元无法回滚。