【AI闲谈】DeepSeek涨价，API策略如何调整？——模型路由实战指南

DeepSeek 涨价，API 策略如何调整？——模型路由实战指南

面向 2026 年 8 月 DeepSeek V4 全系列 API 调价：从账单重算、缓存工程、峰谷调度到生产级模型路由

2026 年 8 月 13 日，DeepSeek 在 V4-Pro 正式版上线的同时宣布调整 API 价格。新价格于北京时间 2026 年 8 月 17 日 0 时生效，覆盖当时官方文本 API 的两档主力模型 deepseek-v4-flash 与 deepseek-v4-pro，并首次把调用时间纳入计费：每日 9:00—12:00、14:00—18:00 为高峰时段，其余 17 小时为空闲时段，空闲价是高峰价的一半。

这不是 2025 年 DeepSeek V3 的那轮价格变化，也不能继续用已经退役的 deepseek-chat、deepseek-reasoner 来讨论。DeepSeek 的官方更新日志明确说明：V4 API 应使用 deepseek-v4-flash 或 deepseek-v4-pro，旧模型名已于 2026 年 7 月 24 日停止使用；本轮新价格则从 8 月 17 日开始生效。

更重要的是，这次变化不能用“统一涨了几倍”概括。模型、Token 类型与调用时段三个变量共同决定账单：同一个请求，在不同时间执行可能相差一倍；相同输入长度，缓存命中与未命中的单价可能相差数十倍；Agent 多走一次工具循环，增加的输出与新输入又会继续计费。

所以真正的问题不是“DeepSeek 还便宜吗”，而是：

在质量、延迟、可靠性和合规约束不下降的前提下，如何让每个请求使用恰当的模型、推理强度、上下文与执行时间？

本文会从准确的价格快照出发，建立可审计的成本模型，再实现一套可以灰度上线的模型路由。结论先给出来：先消灭无效 Token，再做峰谷调度；先建立评测集，再做模型分流。 如果连每类 Token 的消耗都没有测清楚，所谓“智能路由”只是在把成本和质量风险藏进另一个黑盒。

1. 先把事件说清楚：这次到底涨了什么

1.1 生效时间与模型范围

本轮调整的关键事实如下：

• 公告时间：2026 年 8 月 13 日；
• 生效时间：北京时间 2026 年 8 月 17 日 0 时，即 UTC 2026 年 8 月 16 日 16:00；
• 涉及模型：deepseek-v4-flash、deepseek-v4-pro；
• 高峰时段：北京时间每日 9:00—12:00、14:00—18:00，共 7 小时；
• 空闲时段：其余 17 小时；
• 计费关系：所有计费项的高峰价均为空闲价的 2 倍。

DeepSeek 官方把峰谷定价解释为更合理地调配资源，并鼓励用户按业务情况调整任务时间。Reuters 对公告的报道指出，不同模型、Token 类型和调用时段对应的涨幅约为 50%—1100%，但这个跨度本身也说明：只看一个最大涨幅没有决策意义。Reuters 报道

截至本文核对日 2026 年 8 月 27 日，美元价格快照如下，单位均为 美元/百万 Token：

其中，V4-Flash 的缓存未命中输入与输出新价格，以及 V4-Pro 对应价格，可由 InfoWorld 的价格整理交叉核对。价格会继续变化，生产配置应以 DeepSeek 官方价格页和自己的结算币种为最终依据，不要把本文表格永久硬编码在业务代码里。

1.2 “最高涨 1100%”为什么既正确又容易误导

逐项计算后，涨幅差异非常大：

“超过 1100%”指向的是 V4-Pro、高峰时段、缓存命中输入这一项，而不是所有请求的总成本。一个请求的实际成本还取决于缓存命中 Token、缓存未命中 Token、输出 Token 各占多少，以及请求发生在哪个时段。

但也不能因此轻描淡写。许多代码 Agent、固定长 System Prompt、RAG 模板与多轮会话高度依赖前缀缓存，Pro 缓存命中价恰恰是它们最敏感的项目。即使缓存仍然很便宜，相比旧账单的增量也可能非常显著。

1.3 本轮定价真正改变了三个工程变量

过去，团队通常把模型选择近似成一维问题：Flash 还是 Pro。现在至少变成三维：

此外还有一个常被漏掉的第四维：推理强度。V4-Flash 和 V4-Pro 都支持 low、high、max 三档思考强度；官方文档说明思考模式默认开启、默认强度为 high。更高强度可能提高复杂任务质量，也可能生成更多推理 Token、拉长端到端时延。它不是一个可以全局固定的开关，而应成为路由决策的一部分。DeepSeek 思考模式文档

2. 不要拿请求数估账：建立可复算的成本模型

2.1 单次调用的精确成本

对模型 (m)、时段 (b) 的一次调用，设：

• (T_h)：缓存命中的输入 Token；
• (T_m)：缓存未命中的输入 Token；
• (T_o)：输出 Token；
• (P_{m,b,h})、(P_{m,b,m})、(P_{m,b,o})：对应的百万 Token 单价。

则一次调用的直接费用为：

C

c

a

l

l

=

T

h

P

m

,

b

,

h

+

T

m

P

m

,

b

,

m

+

T

o

P

m

,

b

,

o

10

6

C_{call}=\\frac{T_hP_{m,b,h}+T_mP_{m,b,m}+T_oP_{m,b,o}}{10^6}

Ccall​=106Th​Pm,b,h​+Tm​Pm,b,m​+To​Pm,b,o​​

一个业务任务往往不止一次调用。Agent 可能进行多轮工具调用，格式校验失败会重试，低档模型失败后会升级到 Pro。因此，任务成本应写成：

C

t

a

s

k

=

∑

i

=

1

N

c

a

l

l

s

C

c

a

l

l

(

i

)

+

C

r

o

u

t

e

r

+

C

t

o

o

l

+

C

i

n

f

r

a

C_{task}=\\sum_{i=1}^{N_{calls}}C_{call}^{(i)}+C_{router}+C_{tool}+C_{infra}

Ctask​=i=1∑Ncalls​​Ccall(i)​+Crouter​+Ctool​+Cinfra​

其中 router 是路由分类器开销，tool 是搜索、数据库、沙箱等外部工具开销，infra 是网关、队列、日志与自托管推理等基础设施开销。只统计第一次模型调用，会系统性低估 Agent 的成本。

生产上更有价值的指标不是“每千次请求成本”，而是：

Cost per Successful Task

=

总模型与工具成本

通过质量门槛的任务数

\\text{Cost per Successful Task} =\\frac{\\text{总模型与工具成本}}{\\text{通过质量门槛的任务数}}

Cost per Successful Task=通过质量门槛的任务数总模型与工具成本​

如果便宜模型让一次通过率下降，导致重试和升级增多，它的 Token 单价低并不等于单位成功任务成本低。

2.2 一个可复算的账单示例

假设某客服与知识库混合业务每日 10 万个请求，平均每个请求包含：

• 缓存命中输入 2800 Token：固定 System Prompt、工具描述、稳定知识前缀；
• 缓存未命中输入 1200 Token：用户问题、动态检索结果、实时状态；
• 输出 600 Token。

全部使用 V4-Flash 时：

同样的 Token 结构若全部使用 V4-Pro：

这个例子揭示了两件事。第一，真实涨幅由工作负载结构决定，既不是统一的 50%，也不是统一的 1100%。第二，因为每个高峰单价都恰好是空闲价的两倍，如果某业务有比例 (\\rho) 的 Token 落在高峰，新价格的日均成本可简化为：

C

a

v

g

=

C

o

f

f

p

e

a

k

(

1

+

ρ

)

C_{avg}=C_{offpeak}(1+\\rho)

Cavg​=Coffpeak​(1+ρ)

当高峰流量占 40% 时，平均成本就是“全部空闲”的 1.4 倍。削减高峰流量占比与降低模型档位，是两个相互独立的优化旋钮。

2.3 缓存命中率必须按 Token 算，而不是按请求算

下面两种业务都可以宣称“50% 的请求命中缓存”，但经济意义完全不同：

• 业务 A：命中的请求只命中 200 Token，未命中部分有 8000 Token；
• 业务 B：每个请求的 6000 Token 固定前缀都命中，只有 1000 Token 动态内容未命中。

真正有意义的指标是：

R

c

a

c

h

e

=

T

h

T

h

+

T

m

R_{cache}=\\frac{T_h}{T_h+T_m}

Rcache​=Th​+Tm​Th​​

并且要同时记录绝对的 (T_h) 和 (T_m)。高命中率不能掩盖不断膨胀的上下文：当总输入从 8K 增长到 80K，即使命中率仍是 90%，未命中 Token 也增长了 10 倍。

2.4 思考、工具调用和重试的放大效应

传统聊天应用的调用链通常是“一问一答”；Agent 的调用链更像一个带反馈的循环：

请求 → 思考 → 工具调用 → 工具结果回填 → 再思考 → 再调用 → 最终回答

每轮工具结果都会成为后续输入，每轮思考与回答都会产生输出。假设一次正常任务需要 3 次模型调用，而 8% 的任务因为工具失败完整重试，那么请求数放大系数至少为：

A

r

e

t

r

y

=

3

×

(

1

+

8

%

)

=

3.24

A_{retry}=3\\times(1+8\\%)=3.24

Aretry​=3×(1+8%)=3.24

如果失败后不是从检查点恢复，而是把整个轨迹重新发给模型，Token 放大还会高于 3.24。因此，Agent 成本治理首先要限制最大步数、为工具设置幂等键、压缩工具结果、区分可重试与不可重试错误，而不是只盯着模型单价。

3. 涨价后的正确优化顺序

3.1 第一步：建立可归因的用量基线

在改路由前，先从 API 网关、DeepSeek 用量后台与业务日志导出至少 7—14 天数据，并按以下维度聚合：

• 业务场景、租户、接口、任务类型；
• 模型、思考开关与 reasoning_effort；
• 北京时间小时、高峰/空闲标签；
• 缓存命中输入、缓存未命中输入、输出 Token；
• 首次成功、重试、回退、人工接管；
• TTFT、端到端 P50/P95/P99 延迟；
• 质量结果：准确率、任务成功率、格式通过率、人工评分或业务转化。

然后用新价格对历史流量做重定价回放：保持同一批 Token 不变，只替换价格表。这样可以回答“如果什么都不做，下月账单是多少”。没有这个基线，后续任何“节省 40%”都缺少可信分母。

3.2 第二步：先消灭无效 Token

无效 Token 无论路由到哪一个模型都要付费，通常也是最容易拿到的收益：

• 删除多轮会话中重复的系统指令与工具定义；
• 将稳定前缀放在动态内容之前，提高前缀复用机会；
• 对检索结果做去重、重排和证据截断，不把 Top-50 原文全部塞入上下文；
• 对 HTML、日志和代码删除与任务无关的样板内容；
• 为不同任务设置独立的 max_tokens，不要全局给一个极大上限；
• 工具返回结构化摘要、游标或对象 ID，而不是完整数据库记录；
• 多轮会话采用滚动摘要，并保留关键事实与引用来源；
• 用户取消请求时向下游传播取消信号，避免后台继续生成；
• 为 Agent 设置最大步数、总 Token 预算和总金额预算。

这里有一个重要边界：上下文压缩不是越激进越好。 若压缩导致证据丢失、工具参数错误或回答需要重试，节省的输入成本可能换来更高的输出与回退成本。应在离线评测上绘制“上下文长度—质量—成本”曲线，而不是凭感觉截断。

3.3 第三步：把缓存当成数据布局问题

缓存命中依赖可复用前缀，因此 Prompt 的物理布局会影响账单。推荐顺序是：

[稳定系统指令]
[稳定工具定义]
[版本化业务规则]
[可复用的会话前缀]
[本轮动态检索结果]
[当前用户输入]

几条生产原则：

DeepSeek 的限速与隔离文档说明，user_id 同时参与内容安全、KV Cache 与调度隔离，且不得包含用户隐私信息。缓存工程必须服从租户隔离与数据治理，不能为了几分钱破坏安全边界。

3.4 第四步：只调度真正可延迟的任务

峰谷定价让时间成为明确的经济变量。适合移动到空闲时段的任务包括：

• 代码仓库索引、离线代码审查、依赖升级建议；
• 夜间报表、文档摘要、批量标签与数据清洗；
• 评测集回归、Prompt 实验、合成数据生成；
• 非紧急的研究 Agent、知识库增量处理。

不适合调度的任务包括在线客服、交互式编程、实时风控、生产告警分析。强行等待空闲时段会把 API 成本转化为用户流失和 SLA 违约。

调度器至少应支持：任务截止时间、优先级、预计 Token、租户预算、幂等键、最大重试次数和死信队列。临近 9:00 或 14:00 时，不要只看入队时间；长任务可能跨入高峰。实际计费归属应以平台规则和账单为准，并持续做预测成本与结算成本的差异监控。

3.5 第五步：最后才是模型与推理强度路由

路由的目标不应是“尽量走 Flash”，而应形式化为一个约束优化问题：

min

⁡

r

∈

R

E

[

C

(

r

,

x

)

]

\\min_{r\\in R}\\;\\mathbb{E}[C(r,x)]

r∈Rmin​E[C(r,x)]

同时满足：

Q

(

r

,

x

)

≥

Q

m

i

n

,

L

p

95

(

r

,

x

)

≤

L

S

L

O

,

A

(

r

)

≥

A

m

i

n

,

G

(

r

,

x

)

=

1

Q(r,x)\\ge Q_{min},\\quad L_{p95}(r,x)\\le L_{SLO},\\quad A(r)\\ge A_{min},\\quad G(r,x)=1

Q(r,x)≥Qmin​,Lp95​(r,x)≤LSLO​,A(r)≥Amin​,G(r,x)=1

其中 (C) 是任务成本，(Q) 是质量，(L) 是延迟，(A) 是可用性，(G) 表示合规与能力约束是否满足。只有在硬约束通过后，成本才进入比较。

4. 生产级路由不是关键词分流

4.1 先做硬门控，再做能力判断

一个可解释的路由链可以拆成五层：

请求
↓
能力/合规硬门控
↓
任务类型与复杂度估计
↓
模型 + 思考强度 + 执行时段选择
↓
结果校验
↓
成功返回 / 升级重试 / 人工接管

硬门控处理不能被统计模型覆盖的条件，例如：

• 是否需要特定工具、JSON Schema、视觉输入或超长上下文；
• 是否属于医疗、法律、金融、生产变更等高风险任务；
• 数据能否发送给该供应商或部署区域；
• 租户合同是否允许跨供应商；
• 延迟 SLO 是否允许增加一次路由调用。

通过硬门控后，才根据任务难度选择 Flash/Pro 与思考强度。高风险并不自动意味着 Pro 可以解决所有问题：它通常还需要检索证据、确定性校验、审计日志甚至人工复核。

4.2 四种路由器及其适用边界

规则路由

依据业务入口、任务类型、风险标签和长度区间分流。优点是零额外 Token、低延迟、易审计；缺点是无法识别隐含复杂度。它适合覆盖大量结构化流量，也是任何路由系统的第一层。

轻量分类器

用传统分类模型或小型语言模型预测任务类型、难度与失败风险。优点是成本低、可本地部署；缺点是需要标注数据，并会遇到分布漂移。训练标签不应是主观的“简单/困难”，而应来自不同模型在同一任务上的实际成功与成本。

LLM 路由器

让模型读取请求并输出路由决策，冷启动快、语义理解强，但会额外增加调用成本与延迟，也可能被用户内容提示注入。若路由调用本身用了昂贵模型，节省很容易被吞掉。路由输出必须使用受约束的结构化格式，并把用户输入作为数据而非指令处理。

级联与结果驱动路由

先用 Flash 生成，对可验证结果做检查，失败再升级到 Pro。它适合代码编译、JSON Schema、SQL 只读验证、数学可执行校验等任务；不适合开放式创作或难以自动判断正确性的领域。级联的关键指标是：

E

[

C

]

=

C

F

+

p

f

a

i

l

(

C

v

e

r

i

f

y

+

C

P

)

E[C]=C_F+p_{fail}(C_{verify}+C_P)

E[C]=CF​+pfail​(Cverify​+CP​)

只有当 Flash 失败率 (p_{fail}) 足够低，且校验可靠时，级联才比直接使用 Pro 更便宜。

4.3 “复杂度”应由可观测特征组成

不要只按 Prompt 长度判断。长文摘要可能是简单任务，短短一句竞赛题可能需要深度推理。更可靠的特征包括：

• 任务类型：抽取、分类、摘要、生成、规划、代码修改、开放问答；
• 约束数量与冲突程度；
• 是否需要多步工具调用；
• 输出是否可以确定性验证；
• 检索证据覆盖率与冲突率；
• 历史同类任务在 Flash 上的失败概率；
• 任务价值与错误代价；
• 剩余延迟和预算；
• 用户是否明确请求高质量模式。

可用一个校准后的失败概率模型 (p_F(x)) 代替模糊复杂度分数。当选择 Flash 的预期损失为：

L

F

=

C

F

+

p

F

(

x

)

⋅

(

C

f

a

l

l

b

a

c

k

+

C

e

r

r

o

r

)

L_F=C_F+p_F(x)\\cdot(C_{fallback}+C_{error})

LF​=CF​+pF​(x)⋅(Cfallback​+Cerror​)

而选择 Pro 的预期损失为：

L

P

=

C

P

+

p

P

(

x

)

⋅

C

e

r

r

o

r

L_P=C_P+p_P(x)\\cdot C_{error}

LP​=CP​+pP​(x)⋅Cerror​

只有 (L_F<L_P) 时才选择 Flash。高价值业务的 (C_{error}) 很大，因此阈值会自然趋于保守；内部批处理的错误可自动发现，阈值则可以更激进。这比全业务共享一个 complexity > 0.7 更符合真实经济学。

4.4 路由器必须允许“拒绝判断”

分类器最危险的错误是把复杂任务高置信地判为简单任务。为此应设置灰区：

• 低失败风险：Flash + thinking=disabled 或 low；
• 中等风险：Flash + high，必要时结果校验；
• 高风险：Pro + high/max；
• 置信度不足或分布外：保守路由、双跑或人工复核。

不要把“高置信度”理解为模型输出的一个自报数字。置信度需要在独立验证集上做校准，例如用可靠性图、Expected Calibration Error 或 Brier Score 检查“预测 10% 失败”的样本是否真的约有 10% 失败。

5. 一套可运行、可审计的 Python 实现

下面的示例分为价格引擎、确定性路由、API 调用和 usage 对账四部分。它不是完整网关，但刻意保留了生产系统最重要的边界：价格版本化、时区明确、决策有原因、思考强度可控、用服务端 usage 结算。

5.1 价格引擎：不要把高峰判断散落在业务代码里

from __future__ import annotations

from dataclasses import dataclass
from datetime import datetime
from decimal import Decimal
from enum import StrEnum
from zoneinfo import ZoneInfo

BEIJING = ZoneInfo("Asia/Shanghai")
MILLION = Decimal("1000000")

class Model(StrEnum):
FLASH = "deepseek-v4-flash"
PRO = "deepseek-v4-pro"

class Band(StrEnum):
OFF_PEAK = "off_peak"
PEAK = "peak"

@dataclass(frozen=True)
class TokenPrice:
cache_hit_input: Decimal
cache_miss_input: Decimal
output: Decimal

# USD / 1M tokens；快照版本必须随配置发布并可回滚。
PRICE_VERSION = "deepseek-v4-2026-08-17-usd"
PRICES: dict[tuple[Model, Band], TokenPrice] = {
(Model.FLASH, Band.OFF_PEAK): TokenPrice(Decimal("0.007"), Decimal("0.22"), Decimal("0.66")),
(Model.FLASH, Band.PEAK): TokenPrice(Decimal("0.014"), Decimal("0.44"), Decimal("1.32")),
(Model.PRO, Band.OFF_PEAK): TokenPrice(Decimal("0.022"), Decimal("0.66"), Decimal("1.98")),
(Model.PRO, Band.PEAK): TokenPrice(Decimal("0.044"), Decimal("1.32"), Decimal("3.96")),
}

def billing_band(at: datetime) –> Band:
"""按北京时间判断价格时段；要求传入带时区时间。"""
if at.tzinfo is None:
raise ValueError("at must be timezone-aware")
local = at.astimezone(BEIJING)
minute = local.hour * 60 + local.minute
is_peak = (9 * 60 <= minute < 12 * 60) or (14 * 60 <= minute < 18 * 60)
return Band.PEAK if is_peak else Band.OFF_PEAK

def estimate_cost_usd(*, model: Model, at: datetime,
cache_hit_tokens: int, cache_miss_tokens: int,
output_tokens: int) –> Decimal:
if min(cache_hit_tokens, cache_miss_tokens, output_tokens) < 0:
raise ValueError("token counts must be non-negative")
price = PRICES[(model, billing_band(at))]
raw = (
Decimal(cache_hit_tokens) * price.cache_hit_input
+ Decimal(cache_miss_tokens) * price.cache_miss_input
+ Decimal(output_tokens) * price.output
) / MILLION
return raw.quantize(Decimal("0.00000001"))

这里使用 Decimal 而不是二进制浮点数，避免大规模聚合中的舍入漂移。生产环境中，价格配置还应包含生效起止时间、币种、供应商、模型版本、来源 URL 和审批记录，并放在配置中心或数据库中，而不是等待重新发版。

5.2 路由策略：先表达约束，再选择便宜模型

from dataclasses import dataclass
from typing import Literal

Risk = Literal["low", "medium", "high"]
Effort = Literal["none", "low", "high", "max"]

@dataclass(frozen=True)
class RequestProfile:
task_type: str
risk: Risk
complexity: float
route_confidence: float
has_tools: bool
deterministic_verifier: bool
latency_budget_ms: int
deferable: bool
expected_output_tokens: int

@dataclass(frozen=True)
class Route:
model: Model
effort: Effort
verify_output: bool
defer_to_off_peak: bool
reason: str

def choose_route(profile: RequestProfile, at: datetime) –> Route:
if not 0.0 <= profile.complexity <= 1.0:
raise ValueError("complexity must be in [0, 1]")
if not 0.0 <= profile.route_confidence <= 1.0:
raise ValueError("route_confidence must be in [0, 1]")

should_defer = profile.deferable and billing_band(at) is Band.PEAK
if profile.risk == "high":
return Route(Model.PRO, "max", True, should_defer, "high_risk")
if profile.route_confidence < 0.80:
return Route(Model.PRO, "high", True, should_defer, "router_abstained")
if profile.has_tools and profile.complexity >= 0.55:
return Route(Model.PRO, "high", True, should_defer, "complex_tool_task")
if profile.complexity < 0.25:
return Route(Model.FLASH, "none", profile.deterministic_verifier,
should_defer, "low_complexity")
return Route(Model.FLASH, "high", profile.deterministic_verifier,
should_defer, "standard_task")

这里的 0.25、0.55、0.80 只是演示结构，不能直接当成“行业最佳阈值”。正确做法是在自己的评测集上搜索阈值，比较质量、单位成功任务成本、P95 延迟与 Pro 流量占比，然后选择 Pareto 前沿上的策略。

defer_to_off_peak=True 也不意味着当前线程原地等待。在线服务应把任务写入持久队列并返回任务 ID，由独立 Worker 在空闲时段消费。请求线程睡几个小时既不可靠，也会浪费连接和并发配额。

5.3 调用 DeepSeek V4，并记录可对账字段

import os
import time
from dataclasses import asdict
from datetime import datetime, timezone
from typing import Any
from openai import AsyncOpenAI

client = AsyncOpenAI(
api_key=os.environ["DEEPSEEK_API_KEY"],
base_url="https://api.deepseek.com",
timeout=120.0,
max_retries=0, # 在业务层区分错误类型并做有预算的重试
)

def _usage_value(usage: Any, name: str) –> int:
return int(getattr(usage, name, 0) or 0)

async def invoke_deepseek(*, messages: list[dict[str, str]],
profile: RequestProfile, request_id: str,
user_id: str) –> tuple[str, dict[str, Any]]:
started_at = datetime.now(timezone.utc)
route = choose_route(profile, started_at)
if route.defer_to_off_peak:
raise RuntimeError("enqueue this task for an off-peak worker")

thinking_enabled = route.effort != "none"
kwargs: dict[str, Any] = {
"model": route.model.value,
"messages": messages,
"stream": False,
"extra_body": {
"thinking": {"type": "enabled" if thinking_enabled else "disabled"},
"user_id": user_id,
},
}
if thinking_enabled:
kwargs["reasoning_effort"] = route.effort
else:
kwargs["temperature"] = 0.2

t0 = time.perf_counter()
response = await client.chat.completions.create(**kwargs)
latency_ms = int((time.perf_counter() – t0) * 1000)
content = response.choices[0].message.content or ""
usage = response.usage

hit = _usage_value(usage, "prompt_cache_hit_tokens")
miss = _usage_value(usage, "prompt_cache_miss_tokens")
output = _usage_value(usage, "completion_tokens")
estimated_cost = estimate_cost_usd(
model=route.model, at=started_at, cache_hit_tokens=hit,
cache_miss_tokens=miss, output_tokens=output,
)
audit = {
"request_id": request_id,
"price_version": PRICE_VERSION,
"route": asdict(route),
"started_at": started_at.isoformat(),
"billing_band": billing_band(started_at).value,
"cache_hit_tokens": hit,
"cache_miss_tokens": miss,
"output_tokens": output,
"estimated_cost_usd": str(estimated_cost),
"latency_ms": latency_ms,
"provider_request_id": getattr(response, "id", None),
}
return content, audit

几个细节值得强调：

5.4 结果校验与有预算的升级

以 JSON 任务为例，先让 Flash 执行，校验失败后最多升级一次：

import json
from jsonschema import ValidationError, validate

async def run_with_escalation(*, messages, profile, schema,
request_id, user_id):
audits = []
content, audit = await invoke_deepseek(
messages=messages, profile=profile,
request_id=request_id, user_id=user_id,
)
audits.append(audit)
try:
data = json.loads(content)
validate(instance=data, schema=schema)
return data, audits
except (json.JSONDecodeError, ValidationError):
if audit["route"]["model"] == Model.PRO.value:
raise

escalated = RequestProfile(**{
**profile.__dict__, "risk": "high", "route_confidence": 1.0
})
content, audit = await invoke_deepseek(
messages=messages, profile=escalated,
request_id=f"{request_id}:escalated", user_id=user_id,
)
audits.append(audit)
data = json.loads(content)
validate(instance=data, schema=schema)
return data, audits

结构校验通过只表示格式正确，不表示事实正确。对于 SQL，应在只读沙箱中做语法、权限与扫描范围检查；对于代码，应编译并运行测试；对于 RAG，应核对关键陈述是否被证据支持；对于生产变更，应走权限审批和人工确认。

6. 监控：从 Token 看板升级为单位经济看板

6.1 必须具备的指标

建议至少建立以下四组指标。

流量与路由：

• requests_total{task, model, effort, route_reason}；
• route_abstain_rate、flash_share、pro_share；
• escalation_rate{task, first_model}；
• peak_token_share，注意是 Token 占比而非请求占比。

Token 与成本：

• cache_hit_input_tokens、cache_miss_input_tokens、output_tokens；
• cache_hit_token_ratio；
• estimated_cost_usd{price_version}；
• billed_cost_usd 与 cost_reconciliation_error；
• cost_per_successful_task、cost_per_tenant、cost_per_feature。

质量：

• 任务成功率、一次通过率、格式通过率；
• 事实一致性、引用正确率、测试通过率；
• 用户重问率、人工接管率、投诉率；
• Flash/Pro 在同一评测集上的分层差异。

性能与可靠性：

• TTFT 与端到端 P50/P95/P99；
• 429、5xx、超时、取消、重试率；
• 队列等待时间、截止时间违约率；
• 路由器自身延迟与错误率。

DeepSeek 当前文档给出的账号并发上限是 Pro 500、Flash 2500，超限会返回 429；并发按账号而不是 API Key 计算。路由到 Flash 的比例增加不只改变 Token 单价，也可能改变队列与吞吐行为。因此容量规划要用并发、平均服务时间和突发流量共同估算，不能把“有多个 Key”当成扩容方案。官方限速说明

6.2 三类告警比“日账单超限”更早发现问题

日账单是滞后指标。Prompt 模板一次小改动就可能破坏缓存前缀；工具故障可能让 Agent 循环数翻倍；路由模型版本更新可能让 Pro 占比从 15% 漂到 40%。结构指标能在账单形成之前暴露这些问题。

6.3 预算控制要分层

生产系统应同时设置：

• 单次调用 max_tokens；
• 单任务最大调用次数、最大总 Token、最大金额；
• 单租户分钟/日/月预算；
• 单功能预算与整体项目预算；
• 软阈值降级和硬阈值熔断。

降级必须事先定义。例如预算达到 80% 时把低价值批任务移到空闲队列；达到 95% 时暂停合成数据任务；在线高价值请求继续服务。不要在达到阈值时粗暴关闭全部 AI 功能，也不要静默把高风险请求降到低质量模型。

7. 如何证明路由真的省钱，而不是牺牲了质量

7.1 构建贴近真实流量的评测集

从生产流量脱敏采样，并按任务类型、输入长度、语言、工具数量、风险等级、用户群和时间段分层。评测集要刻意保留长尾与失败样本，不能只放“看起来典型”的顺利请求。

每条样本至少应包含：

• 可接受答案或评分规则；
• 必须满足的硬约束；
• 可执行校验器；
• 错误严重度；
• Flash/Pro 在不同 effort 下的输出、用量、延迟；
• 是否发生工具失败、重试与升级。

对开放式任务，采用盲评、成对比较和清晰 rubric，避免评审知道模型名后产生品牌偏差。LLM-as-a-Judge 可以用于扩展评测，但要用人工样本校准，并检查位置偏差、长度偏差和自偏好。

7.2 离线搜索 Pareto 前沿

不要只比较平均准确率。对每套路由策略同时计算：

• 质量均值与低分位；
• 高风险子集的严重错误率；
• 单位成功任务成本；
• P95 延迟；
• Pro 流量占比；
• 升级与重试率。

如果策略 A 更便宜且在所有质量指标上不差于策略 B，B 被 A 支配，可以淘汰。最终候选应位于成本—质量—延迟的 Pareto 前沿。阈值不应由一篇博客给出，而应由这条曲线决定。

7.3 线上按“影子—灰度—扩大”推进

推荐发布流程：

实验的主指标可以是单位成功任务成本，护栏指标至少包括严重错误率、P95 延迟、人工接管率、投诉率和 429/5xx。对低频严重错误，仅看短期均值不够，应结合分层置信区间、人工复核与更长观察窗口。

7.4 评测要持续，因为模型与流量都在漂移

DeepSeek V4 的模型能力和接口在 2026 年持续更新：V4-Flash 正式版在 7 月 31 日更新，V4-Pro 正式版在 8 月 13 日上线，8 月 21 日又新增实验性视觉模型。即使模型 ID 不变，后端版本也可能更新。每次模型、Prompt、工具、检索库、价格或路由器变化，都应触发回归评测与小流量灰度。

8. 最常见的九个错误决策

错误一：按“最高涨幅”直接迁移

最大涨幅不等于你的账单涨幅。先用真实 Token 结构重算，再评估迁移收益。

错误二：只比较供应商价目表

真正要比较的是同一批业务任务上的质量、重试、工具调用、输出长度、缓存行为和延迟。一个单价更低但输出更长、失败更多的模型可能更贵。

错误三：把请求级缓存命中率当成 Token 级命中率

这会严重高估缓存价值。监控必须分离命中 Token 与未命中 Token。

错误四：用一次昂贵 LLM 调用为每次请求做路由

路由器本身可能比被路由的简单任务更贵、更慢。优先使用业务规则和轻量分类器，只有语义边界样本才调用 LLM 路由器。

错误五：把 Prompt 长度等同于难度

长度只是成本特征，不是充分的能力特征。路由应学习“该模型在这个任务上失败的概率”。

错误六：所有任务都打开 max 思考

更强思考适用于复杂任务，不是免费质量按钮。简单抽取、分类、改写通常不需要最大强度。思考模式下部分采样参数不会生效，也不能继续沿用旧客户端的参数假设。

错误七：失败后无限回退

供应商故障时，自动重试和跨模型回退可能形成流量放大。要使用指数退避、随机抖动、熔断器、全链路截止时间和每任务重试预算。

错误八：为了空闲价损害实时 SLA

只有可延迟任务才能调度。在线用户等待成本可能远高于 API 差价。

错误九：把自托管等同于“API 费用为零”

自托管要计算 GPU 折旧或租赁、低利用率、显存冗余、电力、网络、存储、推理引擎维护、模型升级、值班与容灾。正确比较是 API 的单位成功任务成本与自托管 TCO，而不是 Token 单价与 GPU 标价。

9. 一份可执行的 30 天调整计划

第 1—2 天：止血与核算

• 冻结当前 Prompt、模型和路由配置；
• 导出历史 usage，按模型、时段、Token 类型重定价；
• 校验生产中是否仍存在旧模型名；
• 给 Agent 增加最大步数、总 Token 和重试预算；
• 建立价格配置版本与账单告警。

第 3—7 天：无损优化

• 清理重复上下文和过长工具结果；
• 重排 Prompt，提升稳定前缀复用；
• 按任务设置输出上限；
• 将真正可延迟的批任务迁入空闲时段队列；
• 建立 Token 级缓存命中率与单位成功任务成本看板。

第 2 周：评测与候选路由

• 建立脱敏、分层的业务评测集；
• 跑完 Flash/Pro × none/low/high/max 的候选矩阵；
• 训练或校准失败概率分类器；
• 确定硬门控、灰区、升级条件与人工接管条件；
• 找到成本—质量—延迟 Pareto 前沿。

第 3 周：影子与小流量灰度

• 路由器影子运行，不影响用户；
• 对低风险可验证任务双跑；
• 上线 1% 流量，跨越完整峰谷周期；
• 检查路由错误、缓存变化、重试放大和对账误差；
• 完成故障演练：429、超时、供应商异常、队列积压。

第 4 周：扩大与固化

• 按 5%—20%—50% 逐级扩大；
• 对每个任务类型设置独立阈值；
• 把价格、模型能力、合规规则与路由策略解耦；
• 建立周度评测、月度成本复盘和模型更新回归机制；
• 把回滚、熔断和预算降级写入运行手册。

10. 结语：价格变化之后，真正值钱的是选择权

2026 年 8 月这轮 DeepSeek 调价的核心，不是简单地把 V3 时代的价格乘上一个倍数，而是把模型能力、缓存结构和执行时间同时变成了成本变量。对同步、短上下文、低缓存业务，实际影响可能接近某个中等涨幅；对高峰期运行、依赖 Pro 且高度缓存的 Agent，账单变化可能非常剧烈。二者都不能被一条新闻标题替代。

成熟的应对策略也不是“继续用”与“马上迁移”的二选一，而是按顺序完成四件事：

模型路由的价值不只是应对这一次涨价。它把模型从写死在业务代码里的单一依赖，变成一个有能力约束、价格版本、质量证据和回滚路径的运行时资源。下一次价格变化、模型升级或供应商故障发生时，团队不必再次仓促迁移，而可以基于数据调节策略。

真正的成本优化从来不是“使用最便宜的模型”，而是：

让满足质量与可靠性要求的每个任务，以可解释、可审计、可回滚的方式，使用总成本最低的执行路径。

参考资料

• DeepSeek API 更新日志
• DeepSeek 模型与价格
• DeepSeek 思考模式
• DeepSeek 限速与隔离
• Reuters：DeepSeek raises API pricing for its V4 models
• InfoWorld：DeepSeek raises some V4 prices by more than 10x