你以为 API 账单只跟"用了多少 token"有关？错。在中国开发者的真实账单里，有一笔钱是请求已经失败、结果根本没拿到、但 token 照样被扣——它来自三个被 90% 人忽略的源头：重试风暴、超时幽灵、流式断流。这篇拆开这三笔隐形扣款，用刚抓取到的 DeepSeek-V4 真实定价（缓存命中输入只要 $0.0028/M，是未命中的 1/50）告诉你：把重试和超时工程做对，账单能直接砍掉一个数量级，而且零代码改功能。
打开任何一家模型厂商的 Usage 面板，你看到的都是"input tokens / output tokens / 合计美元"。但这个数字里藏着一类没有任何业务产出的 token——它们既没生成有效回复，也没服务到真实用户，纯粹是工程缺陷导致的"白烧"。
这就是我要讲的成本黑洞：请求可靠性工程的成本面。它和"换个便宜模型"是两件事——哪怕你已经在用最便宜的 DeepSeek-Flash，重试和超时没配好，照样能烧出 5~10 倍的冤枉钱。
下面是三笔没人盯的扣款。
几乎所有主流 SDK 默认都会自动重试。Anthropic 的 Python/TS SDK max_retries 默认是 2，OpenAI SDK 同样默认重试 2 次（指数退避 + jitter），触发条件是连接错误、408、409、429 和 5xx。
问题在于：重试 = 重新计算整个 prefill（输入 token 的预填充）。如果你的 prompt 没命中 prompt cache，那几千上万 token 的系统提示、文档、对话历史，每重试一次就重新计费一次。
这是绝大多数人没意识到的关键：重试的代价取决于是否命中缓存，而缓存命中的折扣大得离谱。 我刚抓取的 DeepSeek-V4 官方定价页（截至发稿 2026-06-27）给出了最直观的对照：
| 模型 | 输入(未命中) / 1M | 输入(缓存命中) / 1M | 命中是未命中的 |
|---|---|---|---|
| DeepSeek-V4-Flash | $0.14 | $0.0028 | 1/50 |
| DeepSeek-V4-Pro | $0.435 | $0.003625 | 1/120 |
| Claude Sonnet 4.x（公示价） | ~$3.00 | ~$0.30 | 1/10 |
| Claude Opus 4.x（公示价） | ~$15.00 | ~$1.50 | 1/10 |
| Claude Haiku 4.x（公示价） | ~$0.80 | ~$0.08 | 1/10 |
看懂这张表你就明白信息差了：DeepSeek 的缓存折扣（98%~99% off）比 Anthropic（90% off）狠一个数量级。 一次失败重试，如果打到缓存上，V4-Pro 的输入成本从 $0.435 直接塌到 $0.003625——重试 120 次才等于一次未命中。
而如果你的系统提示是固定的长文档（比如 RAG 的固定指令、产品手册、few-shot 示例），天然就该被缓存。重试一次几乎免费的前提，是你把这些"稳定前缀"放对了位置。
真实算笔账：假设一个后端服务日均 10 万次请求，平均输入 4000 token，失败率 5%（429+5xx+超时），SDK 默认重试 2 次才成功。用 Claude Sonnet 的未命中价算：
每日失败重试浪费的 prefill = 100000 × 5% × 平均1.5次重试 × 4000 token
≈ 3000万 token
未命中成本 = 30 × $3.00 = $90/天 = $2700/月
启用缓存命中 = 30 × $0.30 = $9/天 = $270/月 （省 $2430）
改打到 Flash 重试 = 30 × $0.14 = $4.2/天 = $126/月 （省 $2574）
一个月 2430 美元，纯粹烧在"把已经传过的 prompt 又传了一遍"上，业务零收益。 这不是估算游戏，是把缓存开关和重试策略拨对就能落地的现金。
第二笔更隐蔽。你给请求设了 timeout=30s，但模型平均 12 秒返回。看起来很安全？错。当请求在 25 秒时被你的客户端超时丢弃，服务端可能已经把 output token 生成了一大半——而这条计费照样记在你头上。
行业通行规则：流式或非流式响应里，所有已经生成的 output token 都会被计费，无论你是否中断、是否拿到完整结果。 你在客户端看到的"timeout / connection reset"，对计费系统来说是"已完成的生成"。
这笔钱在三种场景里特别容易失控：
这叫"幽灵请求"——它从没把结果交到你手里，却从你账上划走了钱。
第三笔是第二笔的 streaming 版本，但很多人单独踩坑。当你用 stream=True 流式接收时，客户端在接收中途断开（网络抖动、用户取消、负载均衡切断），服务端已经 flush 出去的 token 仍然计费。
更要命的是：很多 SDK 的 usage 统计依赖最后一个 usage 事件，而断流时这个事件根本到不了你的日志。 于是出现一个诡异现象——账单上的 token 比你日志里记录的多 10%~30%，因为那部分是"流到一半就断、连 usage 事件都没收到"的幽灵 token。你对着自己的日志找不到对应记录，只能怀疑厂商多扣钱。
把三笔扣款串起来，就是一条"失败也烧钱"的放大链路：
flowchart TD
A[请求发出] --> B{429 / 5xx / 超时?}
B -- 否 --> C[正常计费 1x ✅]
B -- 是 --> D[SDK 自动重试<br/>默认2次 指数退避]
D --> E{命中 prompt cache?}
E -- 否 --> F[全量重算 prefill<br/>输入token重新全额计费]
E -- 是 --> G[仅付缓存读取价<br/>V4-Pro低至1/120]
F --> H[成本放大N倍<br/>N≈重试次数]
G --> I[几乎免费重试]
H --> J{还有副作用?}
J -- 下单/发邮件/tool call --> K[无幂等键:<br/>超时但已成功→重复执行]
J -- 纯生成 --> L[纯token浪费]
K --> M[业务重复+二次扣费 💸]
L --> M
I --> N[止血]
M --> N
N --> O[断路器 + 幂等键 + 缓存兜底 + 降级重试]
C --> P[✅ 正常]
注意中间那个分支：如果你的失败请求带有副作用（下单、发邮件、调 tool），还叠加了"超时但其实成功了"的灾难——客户端以为失败去重试，结果同一个订单下了两次。这就是为什么幂等性不只是可靠性问题，更是成本问题。
下面每个开关都能立刻执行，按"投入产出比"从高到低排：
开关 1：把重试上限和退避设对，不是越多越好。
默认 2 次重试在大多数场景是对的，但指数退避必须带 jitter（随机抖动），否则 429 时所有请求同时重试，触发更严格的限流，雪崩式放大成本。把 max_retries 设到 5 以上通常只是让账单更贵，不会让成功率更高。
开关 2：让重试天然命中缓存。
把稳定的长前缀（系统提示、固定指令、few-shot、被检索文档）放在 prompt 最前面，启用 prompt caching。重试打到缓存上，DeepSeek-V4 的输入成本直接降到 1/50~1/120。 这是性价比最高的一个开关——一行 cache_control 配置，重试成本归零。
开关 3：失败重试降级到便宜模型。 与其用同一个贵模型重试，不如第一次失败后，重试打到 DeepSeek-V4-Flash（$0.14/$0.28）或 GLM-4.6（公示价约 $0.60/$2.18）。把"可能失败的兜底请求"放到最便宜的引擎，是天然的省钱结构。
开关 4：加幂等键（idempotency key）。 对所有带副作用的请求（支付、下单、发消息、tool call）传同一个 idempotency key。"超时但已成功"的请求再被重试时，服务端识别到同一 key 直接返回原结果，既避免重复执行，又避免重复扣费。
开关 5：断路器（circuit breaker）。 错误率超过阈值（比如连续失败率 >30%）时直接熔断，停止重试，等冷却。防止一个坏掉的下游把整个服务的预算烧穿——重试风暴是最容易让账单一夜爆表的原因。
开关 6：硬超时设得比 p99 大一点。
统计你请求的 p99 延迟，把 timeout 设在 p99 之上 20%~30%。设太短，正常长请求被当超时丢弃但照样扣钱；设太长，挂死请求占用并发。别用拍脑袋的 30s，用你自己的延迟分布。
开关 7：流式 usage 跟踪 + 中断对账。 流式请求一定要监听每个 chunk 累加 token，中断时主动落库。这样账单来时你能对得上"哪些是断流幽灵 token"，而不是对着日志比厂商少 20% 干瞪眼。
开关 8：设硬性消费上限（spend cap）。
在 Anthropic Console、OpenAI 后台设 spend cap，重试风暴触发时自动熔断账户，给账单装一道物理保险丝。这是最后一道防线，零成本但救命。
| 维度 | 大多数人以为的 | 真实情况（信息差） |
|---|---|---|
| 失败请求 | 没成功=没扣费 | prefill 照扣，output 已生成部分也照扣 |
| 重试代价 | 重试免费 | 未命中缓存时全量重算，成本 ×重试次数 |
| 缓存折扣 | 所有厂商一样 | DeepSeek 98~99% off，是 Anthropic 的 10 倍力度 |
| 流式中断 | 中断=没花钱 | 已 flush 的 token 照算，且 usage 事件常丢失 |
| 超时丢弃 | 丢弃=不付费 | 服务端已生成的 token 全部计费 |
| 幂等性 | 只是可靠性 | 直接决定是否被重复扣费 |
max_retries 是默认值还是有 jitter；给所有带副作用的请求补 idempotency-key。spend cap，给账单装保险丝。特别提醒（时效）：DeepSeek 官方已宣布，旧模型名 deepseek-chat（非思考）和 deepseek-reasoner（思考）将于 2026/07/24 15:59 UTC 弃用，分别对应迁移到 deepseek-v4-flash 的非思考/思考模式。还在用旧名字的生产环境，务必在 7 月 24 日前改完，否则线上直接报错——顺手把 V4-Flash 的缓存命中价（$0.0028/M）用起来。
一句话总结：换便宜模型是省小钱，把失败请求的计费链路修对才是省大钱——因为这部分成本你既没拿到结果，又付了全价，是账单上 ROI 最低的一块。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。