成本、容量与可靠性

质量达到要求之后，服务还必须在费用、配额和时间约束内运行。本文以完整任务为计量单位，从成本账走到配额瓶颈与平均在途量，再把重试放进总期限。模型内部 KV 与算子开销见推理资源篇，这里关注服务调度与失败处理。

成本按完整执行链计算

Token 是常见计费量，但不是唯一成本来源。模型请求可能区分普通输入、缓存写入、缓存读取和输出；工具、检索、存储、执行容器、网络及自托管算力也会产生费用。不同供应商与产品有不同口径，不能把“输出固定比输入贵五倍”作为通用规则。

任务成本 = 所有模型请求费用之和 + 工具与运行费用 + 相关存储/检索等费用

假设某服务的教学价格为输入每百万 token 2 个货币单位、输出 10 个单位。一次请求输入 20,000、输出 2000，模型费用是 0.04+0.02=0.06；再加工具费用 0.01，总量为 0.07。一个任务需要三次同样规模的调用，才是 0.21；额外失败尝试也要按实际产生的费用加入。⁠这些数字仅用于演算，不是当前产品报价。

缓存收益可以用不含真实定价的模型核算：前缀长度 L，普通输入单价 u，写入单价 w，读取单价 r，复用 N 次且其余请求都命中，比较 N×L×u 与 L×w+(N−1)×L×r。TTL 内调用太少或前缀经常变化时，写入溢价可能收不回来；机制与条件见 上下文工程。

换便宜模型也要算整个任务。若单次费用减半，但失败导致三次额外尝试，未必更省。报告每项成功分摊的总成本，并记录未成功任务耗费，而不是只比较一次请求的报价。

拆解延迟与吞吐

端到端时间包含排队、网络、输入处理、推理/生成、工具和应用验证等阶段。串行依赖相加，并行分支按关键路径计算；“延迟主要由输出长度决定”只适合部分工作负载。

流式让结果逐步交付，通常改善等待感知，并可配合连接保活；它不会自动提高模型生成速度、解除输出上限或保证所有代理与网络都不超时。需要分别设置连接、读取空闲、单次调用和任务总期限；接收部分文本后断流，也不能把半截结构化结果标为完成。

缓存、缩短输入、批量、并行和更少探索都可能改善某些阶段，但要根据 trace 找瓶颈。若工具查询花 20 秒，削掉 100 个输出 token 对整体影响可能很小；若排队占大头，单独降低前端超时只会制造更多失败重试。

配额、准入与有界排队

配额可能同时限制请求数、输入 token、输出 token和加速增长速度；具体维度按服务文档与账户配置确认。Claude Rate limits 只限制请求并发，不能保证 token 配额不超；只限制平均 RPM，也不能消除瞬间突发。

假设允许 100 请求/分钟、200,000 输入 token/分钟、50,000 输出 token/分钟，每个请求平均输入 10,000、输出 1000，则三个维度给出的平均上限分别为 100、20、50 请求/分钟，最紧约束是 20 请求/分钟⁠。

若平均服务时间为 30 秒，在稳定、无积压的简化条件下，20 请求/分钟对应平均在途请求数约 10。这个 Little 定律算例是平均容量账，不是生产并发设为 10 就一定安全：长度波动、尾延迟、突发和外部共享配额还需余量与动态控制。

from fractions import Fraction

rpm = 100
input_tpm, output_tpm = 200_000, 50_000
input_per_request, output_per_request = 10_000, 1_000
rate = min(Fraction(rpm), Fraction(input_tpm, input_per_request),
           Fraction(output_tpm, output_per_request))
mean_inflight = rate / 60 * 30
assert rate == 20
assert mean_inflight == 10
assert 3 * 3 == 9  # 两层各最多 3 次尝试的最坏放大
print("平均请求/分钟:", rate, "平均在途:", mean_inflight)

队列需要长度与等待期限，超出后按业务延期、降级或拒绝。在线交互与可延后的离线任务可分开调度，避免长批处理耗尽交互资源。过载时持续接收并让所有请求更慢，常比早期拒绝更难恢复；容量管理应依据真实资源而非单一请求计数。Google SRE：Handling Overload

重试需要期限与幂等边界

错误类别比数字口诀更有用

不能把它压成“只有 429/5xx 才能重试”或“所有 5xx 都应重试”。408、409 等是否适合重试取决于协议和操作；供应商错误与 SDK 默认策略也应分别核查。Claude Errors

将退避放进同一个任务期限

常见退避上界为 min(cap, base×2^attempt)，在区间内引入 jitter，避免多个客户端同时醒来。服务返回 Retry-After 时按它的语义安排，并受任务剩余期限约束；如果等完后已经没有完成一次尝试的时间，就不应继续启动。

例如任务剩余 8 秒，服务要求至少等待 6 秒，而下次操作需要预留 5 秒，这轮重试不符合预算。把“每次请求 timeout=10 秒”设置好，也不代表任务只会等 10 秒；重试、退避、排队和工具阶段都会占用总时长。

调用方重试三次、SDK 内部每次又最多尝试三次，最坏就是九次底层请求。要明确由哪一层管理重试，统计真实尝试数，必要时设置整个服务的重试预算；过载时重试放大会让本已不足的容量更紧张。Google SRE：Addressing Cascading Failures

人工确认不替代幂等

用户确认过“创建一条订单”，只授权了一次业务意图，不保证网络重试不会创建两条。幂等键必须对应同一个业务操作，并由实际服务保存和核验；对同一键发送不同参数也应按服务语义处理，不能只在模型 prompt 里写“不要重复”。

请求超时不能证明服务没执行。若动作已完成但响应未到，应先查询或重放已有结果，取消等待也不自动撤销动作。这条边界在 Agent 循环 中用完整时序展开。

先耗尽的是请求数还是 token？

先把不同单位的配额都换成请求速率，再取最小值，才能找到当前瓶颈。Little 定律中的 L 是平均在途请求数；它不是推荐的硬并发上限，也不能单靠这条公式保证排队尾延迟。

$$r\le \min \left(R,\frac{I_{\max }}{\bar{I}},\frac{O_{\max }}{\bar{O}}\right),L=\frac{r}{60}\bar{W}$$

降级、批量与运行验证

降级仍需满足任务的最低要求

切换模型前核验上下文长度、结构化输出、工具格式、输入模态与权限边界。不能把只支持文本的后备模型静默接到图像任务，也不能因为备用服务支持范围不同，就删除关键约束后伪装成同等结果。

可选择返回已有可信部分、延后离线完成、使用兼容后备或明确报告暂不可用。缓存旧结果时标注适用时间与版本，并检查用户访问范围。恢复服务后，应防止积压任务同时重放形成新一轮突发。

批量提交按条目管理生命周期

非实时任务可以使用批量接口，但价格折扣、完成时限、大小限制和缓存交互是服务特定规则。批次结束不等于所有条目成功；按每项 ID 区分成功、失败、过期与取消，并只重试应重试的条目。Claude Batch processing

批量/并行结果可能乱序，保存请求映射，按 ID 对应输出。重新提交失败项时保留原任务与新尝试的关联，避免重复写入已成功结果；模型批处理本身也不保证下游业务操作恰好执行一次。

验证目标是可控的完整服务

建立包含短请求、长输入、长工具等待、限流、断流、结果未知和后备切换的运行样例。记录成功率、p50/p95 延迟、队列长度、实际尝试数、配额使用和每项成功成本。

每层只重试两次，会放大多少？

“重试两次”容易被误读成总共两次调用，这里统一使用包含首次调用的尝试上限。底层 SDK 与外层工作流都重试时，要按乘积核算最坏请求量，并共享截止时间和重试预算。

$$N_{\mathrm{backend}}\le A_{\mathrm{outer}}{A}_{\mathrm{inner}},t_{\mathrm{wait}}+t_{\mathrm{attempt}}\le t_{\mathrm{remaining}}$$

继续阅读：发布验收、灰度与恢复。