# 请求失败钱照扣：API账单里三笔没人盯的隐形扣款
你以为 API 账单只跟"用了多少 token"有关？错。在中国开发者的真实账单里，有一笔钱是**请求已经失败、结果根本没拿到、但 token 照样被扣**——它来自三个被 90% 人忽略的源头：重试风暴、超时幽灵、流式断流。这篇拆开这三笔隐形扣款，用刚抓取到的 DeepSeek-V4 真实定价（缓存命中输入只要 $0.0028/M，是未命中的 1/50）告诉你：**把重试和超时工程做对，账单能直接砍掉一个数量级，而且零代码改功能。**
---
## 一、信息差在哪：你看到的账单 vs 真实烧钱路径
打开任何一家模型厂商的 Usage 面板，你看到的都是"input tokens / output tokens / 合计美元"。但这个数字里藏着一类**没有任何业务产出的 token**——它们既没生成有效回复，也没服务到真实用户，纯粹是工程缺陷导致的"白烧"。
这就是我要讲的成本黑洞：**请求可靠性工程的成本面**。它和"换个便宜模型"是两件事——哪怕你已经在用最便宜的 DeepSeek-Flash，重试和超时没配好，照样能烧出 5~10 倍的冤枉钱。
下面是三笔没人盯的扣款。
---
## 二、第一笔：重试风暴——失败请求的 prefill 要重新算一遍
几乎所有主流 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"，对计费系统来说是"已完成的生成"。
这笔钱在三种场景里特别容易失控：
1. **前端聊天应用**：用户等不及，点关闭/刷新/Ctrl+C，半截回复的 token 已经烧了。
2. **批量任务**：设了统一的硬超时，长 prompt 的请求被批量误杀，但下游照样按生成量收费。
3. **Agent 循环**：一个 agent step 超时被上层 kill，但子请求的 output 已经计入。
这叫"幽灵请求"——**它从没把结果交到你手里，却从你账上划走了钱。**
---
## 四、第三笔：流式断流计费
第三笔是第二笔的 streaming 版本，但很多人单独踩坑。当你用 `stream=True` 流式接收时，**客户端在接收中途断开（网络抖动、用户取消、负载均衡切断），服务端已经 flush 出去的 token 仍然计费。**
更要命的是：**很多 SDK 的 usage 统计依赖最后一个 `usage` 事件，而断流时这个事件根本到不了你的日志。** 于是出现一个诡异现象——账单上的 token 比你日志里记录的多 10%~30%，因为那部分是"流到一半就断、连 usage 事件都没收到"的幽灵 token。你对着自己的日志找不到对应记录，只能怀疑厂商多扣钱。
---
## 五、整条失败计费链路长什么样
把三笔扣款串起来，就是一条"失败也烧钱"的放大链路：
```mermaid
flowchart TD
A[请求发出] --> B{429 / 5xx / 超时?}
B -- 否 --> C[正常计费 1x ✅]
B -- 是 --> D[SDK 自动重试
默认2次 指数退避]
D --> E{命中 prompt cache?}
E -- 否 --> F[全量重算 prefill
输入token重新全额计费]
E -- 是 --> G[仅付缓存读取价
V4-Pro低至1/120]
F --> H[成本放大N倍
N≈重试次数]
G --> I[几乎免费重试]
H --> J{还有副作用?}
J -- 下单/发邮件/tool call --> K[无幂等键:
超时但已成功→重复执行]
J -- 纯生成 --> L[纯token浪费]
K --> M[业务重复+二次扣费 💸]
L --> M
I --> N[止血]
M --> N
N --> O[断路器 + 幂等键 + 缓存兜底 + 降级重试]
C --> P[✅ 正常]
```
注意中间那个分支：**如果你的失败请求带有副作用（下单、发邮件、调 tool），还叠加了"超时但其实成功了"的灾难**——客户端以为失败去重试，结果同一个订单下了两次。这就是为什么幂等性不只是可靠性问题，更是成本问题。
---
## 六、止血开关清单（8 个，按优先级排）
下面每个开关都能立刻执行，按"投入产出比"从高到低排：
**开关 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 全部计费 |
| 幂等性 | 只是可靠性 | 直接决定是否被重复扣费 |
---
## 八、行动指南（接下来 72 小时做这些）
1. **马上做（10 分钟）**：翻一遍你调用模型的代码，确认 `max_retries` 是默认值还是有 jitter；给所有带副作用的请求补 `idempotency-key`。
2. **今天做（30 分钟）**：在 Anthropic / OpenAI 后台设一个比你月预算高 20% 的 `spend cap`，给账单装保险丝。
3. **本周做（2 小时）**：把固定的长 prompt 前缀做 prompt caching，统计重试率——如果重试率 >3%，这一步能立刻看到账单下降。
4. **月底前**：把失败兜底重试改到 DeepSeek-V4-Flash 或 GLM-4.6，按"贵模型干主活、便宜模型接重试"重排调用结构。
**特别提醒（时效）**：DeepSeek 官方已宣布，旧模型名 `deepseek-chat`（非思考）和 `deepseek-reasoner`（思考）将于 **2026/07/24 15:59 UTC 弃用**，分别对应迁移到 `deepseek-v4-flash` 的非思考/思考模式。还在用旧名字的生产环境，务必在 7 月 24 日前改完，否则线上直接报错——顺手把 V4-Flash 的缓存命中价（$0.0028/M）用起来。
---
## 九、不同预算的推荐方案
- **个人 / 侧项目（月预算 < $20）**：直接上 DeepSeek-V4-Flash + prompt caching，重试降到 1 次命中缓存。月用量百万级 token 基本几毛钱，几乎不可能因为重试翻车。
- **中型团队（月预算 $200~$2000）**：用 LiteLLM 或 OpenRouter 做统一网关，集中管理重试/退避/断路器策略，失败兜底打到 Flash/GLM。一次性把可靠性策略配在网关层，所有服务自动受益。
- **企业（月预算 > $5000）**：上全链路可观测（每个请求的 prefill/output/重试次数都打点）+ 幂等中间件 + 多可用区故障转移 + 硬性 spend cap。把"失败成本"变成一个能监控、能报警的指标，而不是账单上的盲盒。
**一句话总结**：换便宜模型是省小钱，把失败请求的计费链路修对才是省大钱——因为这部分成本你**既没拿到结果，又付了全价**，是账单上 ROI 最低的一块。
---
## 参考来源
- DeepSeek 官方定价页（V4-Flash/Pro、缓存命中价、模型迁移公告）：https://api-docs.deepseek.com/quick_start/pricing
- z.ai GLM 模型定价（GLM-5.x / 4.6 / 4.5 全系列）：https://docs.z.ai/guides/pricing
- Anthropic 速率限制与重试机制：https://docs.anthropic.com/en/api/rate-limits
- OpenAI Python SDK 重试与超时配置：https://github.com/openai/openai-python
- LiteLLM（统一网关 / 重试 / 断路器 / 降级）：https://docs.litellm.ai/docs/proxy/reliability
---
> 本文由「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 等场景全覆盖。
