DeepSeek V4.1-Flash 正式发布：模型路由、缓存与 API 价格变化怎么接？

先说结论

DeepSeek 已正式发布 V4.1-Flash，并把它同时放到官方 API 与 Hugging Face：这是一个 552B 参数的多模态 MoE 模型，采用 Causal Encoder–Decoder 结构，输入侧激活 8B、输出侧激活 16B，支持最长约 100 万 token 上下文。对开发者而言，真正需要关注的不是“552B 看起来多大”，而是模型 ID、路由变化、缓存成本和自托管门槛会一起改变。

官方公告称，V4.1-Flash 已在 API 上线，模型名为 deepseek-flash；旧的 deepseek-v4-flash 和 deepseek-v4-flash-vision-exp 会暂时路由到新模型。北京时间 2026 年 9 月 14 日 12:00 起，deepseek-v4-pro 请求也将路由到 V4.1-Flash，并按 Flash 价格计费，直到 V4.1-Pro 发布。

这次发布确认了什么

DeepSeek 官方资料和 Hugging Face 模型卡共同确认：

• V4.1-Flash 是原生多模态模型，模型卡提供权重、技术报告和 vLLM/SGLang 部署示例。
• 新结构把输入和输出的激活规模拆开，官方写明输入激活 8B、输出激活 16B。
• 官方称 KV Cache 相比上一代减少到 HBM 的四分之一、SSD 的八分之一；这属于厂商架构披露，不是 WayToClawEarn 独立测量。
• 官方 API 的新价格已于 2026 年 9 月 10 日 04:00 UTC 起生效，并保留峰谷时段定价；非高峰价格为高峰价格的 50%。具体账单仍应以 API 控制台和真实调用记录为准。

官方还称，多方测试结果显示 V4.1-Flash 在性能、成本、速度和总运行时间上领先 V4-Pro。这个表述仍是厂商引用的比较结论，本文不把它写成独立 benchmark 结论。

对现有应用会有什么影响

1. 模型别名需要重新核对

如果你的应用把 deepseek-v4-flash、deepseek-v4-flash-vision-exp 或 deepseek-v4-pro 写死在配置中，应该在 9 月 14 日路由切换前记录当前模型、价格、缓存命中、延迟和错误率。否则发生问题时，很难判断是模型升级、计费变化，还是业务代码本身变化。

2. 低激活参数不等于低总成本

8B/16B 激活和更小 KV Cache 可能有利于吞吐与显存规划，但自托管仍要面对总权重、并行策略、量化、带宽、上下文长度、并发和故障恢复。模型卡展示的是约 510 GB 仓库规模，不能把“激活参数少”直接翻译成“一张卡就能跑”或“必然更便宜”。

3. Agent 工作负载值得优先验证

官方强调缓存和长上下文，比较适合把验证重点放在检索增强、代码代理、长文档处理和多模态输入，而不是只跑几条聊天 prompt。建议固定同一批任务，分别记录首 token 延迟、总耗时、输入/输出 token、缓存命中、工具调用成功率、失败重试和实际账单。

一个可执行的迁移清单

1. 在 staging 中同时跑旧模型名与 deepseek-flash，保存 20–50 个真实业务任务的输入、输出和失败样本。
2. 在 9 月 14 日路由切换前锁定当前价格页、调用量和缓存策略，切换后按同一口径复测。
3. 把模型名、价格、上下文上限和供应商路由记录进配置与日志，不要埋在代码分支里。
4. 对带工具调用的任务增加人工复核和超时回退；不能因为模型便宜就扩大不可逆操作权限。
5. 自托管前先做显存、带宽、并发和恢复演练；没有这些实测，不写“省钱”结论。

证据边界

模型发布、API 上线、路由日期、价格机制和架构数字来自 DeepSeek 官方公告；权重、MIT 许可证、技术报告与部署文件来自官方 DeepSeek Hugging Face 仓库；AI Primer 对模型架构和公开资料做了独立整理。性能领先、成本下降和吞吐改善仍需按固定任务独立测试。

来源：DeepSeek 官方公告；Hugging Face 官方模型卡；AI Primer 独立技术整理。