并发和重试怎么让成本翻倍：估算时该按哪种口径填请求量

估算一笔模型调用成本时，多数人先盯单价。但真正让估算和账单对不上的，往往是请求量：账单按实际发生的请求次数收，而实际次数通常高于业务逻辑里「打算调用几次」。

先分清三个数：业务调用量、有效请求量、实际计费请求量

• 业务调用量：代码里一次业务动作打算发起多少次模型调用。
• 有效请求量：真正拿到模型返回结果的那部分请求。
• 实际计费请求量：实际发往供应商、被计入用量的请求条数。

理想情况下这三个数相等，一旦出现超时重发、限流重试，就会分叉。DeepSeek 的 API 参考在 total_tokens 字段上写明，它统计的是本次请求中 prompt 与 completion 的总 token 数——也就是说，每一次实际发出的请求各自计一次用量，重发的那一次不会和原请求合并成一次。

并发不改变单价，改变的是「发生了几次」

并发限制约束的是同时占用的连接数。DeepSeek 的 Rate Limit 文档写明：一笔请求从发出到模型响应结束，这段时间算作一个并发连接；并发数超过上限时会收到 HTTP 429 错误码；而且并发上限按账户级别计算，与使用哪个 API Key 无关。

这句话有两个推论，都对估算有用：

• 并发本身不改变单次调用的 token 单价，它约束的是同时有多少请求在跑。
• 一旦触到上限，后面的请求会被拒或排队等待。如果客户端的策略是在收到 429 之后重新发起请求，那次重发就是一笔新的实际请求。

Amazon Bedrock 关于提示缓存的文档在描述使用场景时也提到，一次 agent 运行会突发多笔调用（bursts of calls a single agent run generates）。这说明「业务上一次操作」与「实际发出的请求笔数」本来就不是一回事，与缓存机制无关，是调用形态决定的。

重试率这栏怎么填：实际计费量 = 业务调用量 × (1 + 重试率%)

估算台用的换算就是这个式子，对应页面上的「重试率 %」输入框。

要留意它的含义：这栏描述的不是你「打算重试几次」，而是把「实际发出的请求总数超出业务调用量的比例」折算成一个百分比。填法上：

• 如果调用链路上没有任何自动重发路径，可以按不产生重试增量来填。
• 如果客户端在超时、网络中断或收到 429 之后会重新发起请求，这些重发都要计入。
• 本站不取实时调用数据，也不提供行业经验值——这个数只能由你根据自己的调用链路和日志自填。

页面原话是「重试率按额外调用成本估算。」也就是把它当作额外调用处理：在当前单次成本之上乘一次增量。这是一项明确的估算假设，不是账单复刻。

按输入项走一遍

页面输入项包括：输入 token（in）／缓存 token（cache）／输出 token（out）／每月调用（runs）／输入价 / 1M（ir）／缓存价 / 1M（cr）／输出价 / 1M（orr）／重试率 %（retry）。

单次与每月算式为：one = ((in - cache)*ir + cache*cr + out*orr) / 1e6 * (1 + retry/100)；month = one * runs。按页面输入项代入公式，可得到单次与每月估算。

这里值得留意：第一，缓存 token 应包含在输入 token 内，所以算式里第一部分只算未命中的那部分输入；命中缓存的那部分输入按更低的缓存档计费，具体档位与规则以各供应商官方文档为准。第二，单次成本里已经按重试率计入重试增量。

三个可以自己做的复核动作

1. 把重试率调成不启用重试的情形，再算一次。两次月成本的差额，就是重试这一项在你的假设下贡献了多少——这个差值是算出来的，不是估出来的。
2. 把「每月调用」换成业务日志里的真实调用条数，而不是「设计上打算调用几次」。这一步通常比调单价更能改变结果。
3. 看清分项：输入、缓存、输出、重试分别展示，不把未知费用默认为零。没填的项不代表没有成本，只代表这次估算里没有计入。

还要接受一个边界：页面写着「浏览器本地运行 · 估算不是账单」，它不连任何厂商的计费接口。供应商价格、模型别名和缓存规则会变；购买前请回到官方价目页。本工具是独立的计算工作台，不代表任何模型供应商。结果仅用于估算，不构成报价、采购或财务建议。

估算的价值在于每个数字都能被指认出来：它来自哪个输入框、按什么算式、可以怎么复算。并发和重试之所以容易让成本翻倍，不是因为单价变了，而是因为请求笔数变了。价格与口径以各供应商最新官方文档为准。