DeepSeek 把 Pro 路由给 Flash，省钱不等于能直接上线

9 月 14 日中午 12 点，DeepSeek API 里还写着 deepseek-v4-pro 的请求，会被路由到 V4.1 Flash，并按 Flash 的价格计费。这个改动不是建议，是已经写进官方发布说明的服务行为。官方公告说得很直接，V4 Pro 的过渡会持续到 V4.1 Pro 上线之前。

如果你的 Agent 还在用 Pro，这件事最容易让人松一口气。模型不用改，单价还会下来，棒棒的，周一照常上线。

但线上系统最怕这种看起来不需要动作的变化。

deepseek-v4-pro 这个名字还在，背后接的模型却变了。一个能把代码改完、检索跑顺、文档读完的 Agent，不是只靠模型名活着。它还靠工具调用格式、长上下文里的缓存命中、推理强度、图像输入、超时重试和你们自己的验收阈值。路由替换把默认值换掉了，问题并不会因为 SDK 没报错就自动消失。

我更愿意把这次更新看成一次已经开始的迁移窗口。不是纠结要不要升级，而是赶在它自动生效前，弄清楚什么可以放心交给 Flash，什么必须继续盯着。

本文没有做独立性能实测。下面的判断只依据 DeepSeek 的官方发布、API 更新和模型卡，重点是给正在跑 Agent 的团队整理一份最小验收顺序，不把官方跑分写成你我环境里的结论。

省下来的钱，落在哪一段链路

V4.1 Flash 的卖点很好懂。DeepSeek 把它做成了输入和输出不对称的架构，官方给出的口径是输入激活 8B、输出激活 16B，同时提供原生视觉能力。更抓人的是缓存，官方称新模型的 KV Cache 对 HBM 的需求降到上一代的四分之一，对 SSD 的需求降到八分之一。官方模型页还特别点出了 Agent 场景，缓存命中经常是账单的大头。

好家伙，这听上去像终于可以把长上下文放心塞进 Agent 了。

先别急着把预算表涂绿。

每百万 token 的价格变低，和一次任务最终更便宜，是两回事。Agent 的总成本大致由输入、缓存命中、输出、工具轮数和失败后的重跑共同决定。Flash 让其中几项有了更好的起点，可它也可能走出不同的工具路径。只要工具调用或重试次数增加，单价下降就未必能完全覆盖工作量变化。

所以，别只记录模型响应的 token。把一次业务任务作为账本单位更靠谱。拿一个真实的任务 ID，记下它的输入规模、缓存命中、输出规模、工具调用次数、总耗时、是否重试，以及最终有没有通过你们本来的验收。这样到了 14 日以后，才看得见省的是哪一笔，而不是只看见控制台上那个好看的单价。

官方仍保留峰谷定价，闲时价格是高峰时段的一半。价格页值得和这套任务账本一起看。适合异步的批处理、离线检索和夜间评测，可以排到便宜的时段。需要即时交付的交互式 Agent，就别为了折扣把用户请求排成候机队列。成本优化得先尊重任务本身。

看模型单价之前，先把一次任务跑成可比较的账本。

旧模型名没有报错，不代表迁移结束

DeepSeek 已把 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 这两个旧 ID 临时路由到 V4.1 Flash。新接入建议直接用 deepseek-flash。这是一种兼容安排，不是一份永久承诺。更新日志里也写清楚了旧 Flash 与 Vision Exp 已下线。

这类别名很善意，能避免凌晨被一串 404 叫醒。它也容易让版本治理失踪。你以为配置没有动，实际上测试集、缓存分布、模型能力和输出习惯都在动。等某个业务问题冒出来，排查时连到底跑的是谁都说不清，那就有点子牛逼了，只不过是反方向的。

在配置里显式写新 ID，不是为了好看，是为了让日志、灰度和回滚都能说人话。配置可以很朴素，关键是别把别名当作版本策略。

# 新任务显式选用当前模型
model = "deepseek-flash"

# 记录真正执行的模型、时间与验收结果
run_tags = ["model-id", "route-date", "golden-set"]

如果你们已经通过 OpenAI 兼容接口、Responses API 或其他封装接入，迁移前还应确认那层封装有没有把模型 ID、图像消息、工具 schema 或推理强度偷偷写死。DeepSeek 过去的 V4 系列已经支持 Responses API 和针对 Codex 的接入说明，这里是官方集成文档。接口兼容只能证明请求发得出去，不能证明完整工作流还按原来的方式完成。

真正要验的，是四个会让生产变脸的地方

第一关是结果，不是排行榜。挑一组你们已经确认过结果的任务，最好覆盖代码修改、检索汇总、结构化输出和长文档问答。每类任务留住输入、期望约束和验收方式。不要只问回答像不像，更要看补丁能不能过测试、JSON 能不能被下游解析、检索引用有没有跑偏。

第二关是工具。模型换了以后，工具调用的次数、参数填充习惯和遇到失败时的继续尝试方式都可能改变。对会写入数据库、创建工单、发送通知的动作，仍然把批准、幂等键和回滚留在系统侧。别把新模型更强这件事，误解成可以把权限门拆掉。

第三关是上下文。V4.1 Flash 支持原生视觉理解，也继续面向长上下文与缓存优化。图片、扫描件、图表和长对话一起送进 Agent 时，输入 token 的构成和缓存命中会和纯文本不一样。用一份包含真实图片或图表的回归样本，核对字段抽取、引用定位和总成本。没有这类业务，就不要为了尝鲜突然把视觉输入加进主流程。

第四关是失败路径。拿一个工具超时、一个无效 JSON、一个权限不足和一个上下文过长的样本，看看 Agent 会不会重复调用、有没有把错误抛给正确的观察点、能不能安全停下。模型的高分通常发生在定义清楚的任务上，真正磨人的地方反而是这些失败分支。厉害了的演示视频不负责替线上兜底。

模型、工具、上下文与失败路径，少一项都不算完成迁移。

这四关不需要做成大工程。一组稳定的 golden set，加一份按任务计的成本日志，再加一个可以切回旧策略的开关，已经能挡住多数盲区。重点是把它们放在 14 日之前跑一遍，并在路由切换后的第一天再跑一遍。前一次看风险，后一次看真实行为有没有偏离。

Pro 被换成 Flash，团队该怎么选

如果你们以前用 Pro 是因为它更适合某类高难任务，现在不能只靠旧印象决定。官方认为 V4.1 Flash 在性能、费用、速度和总用时上已超过 V4 Pro，所以才安排了这次切换。这个结论可以作为你优先测试 Flash 的理由，不能替代你自己的业务验收。

一个很实用的分流是，把确定性要求高的核心任务先放进小流量灰度，观察完成率、人工接管率和单任务成本。通过后再扩。对结果容错高、能重试、可以人工复核的任务，先吃到 Flash 的价格和吞吐红利没有问题。对高价值写入、长链路工具协作和异常代价很高的任务，继续保留更严格的人工门和回滚阈值。

DeepSeek 这次最值得注意的，不是又多了一张跑分表，而是模型选择正在从开发者的配置项，变成服务端会主动替你完成的路由行为。以后碰到类似更新，团队要问的不是「要不要改一行 model」，而是「这次替换会碰到哪些任务、哪些权限、哪几笔钱」。

把这个问题问清楚，模型变快才真的能变成系统变稳。

你们现在线上 Agent 最难验的，是模型输出、工具调用，还是长上下文成本？