DeepSeek V4.1 Flash 发布并最高降价 60%？更低成本智能体考验归因体系？这一大模型从单纯追求参数规模转向能力、速度与部署成本同步优化的关键拐点已经到来，DeepSeek 于 2026 年 9 月 10 日正式发布 DeepSeek V4.1 Flash，推出 552B 参数的 MoE 模型、全新的 Causal-Encoder-Decoder 非对称结构与原生多模态视觉理解能力，并同步下调 API 价格，最高降幅达到 60%。DeepSeek V4.1 Flash 发布并最高降价 60% 不只是一次模型版本升级，也不只是一次价格调整：它把视觉理解、长上下文、工具调用、缓存成本和模型路由放进了同一套开发者基础设施。当旧模型下线、部分旧模型名称被暂时路由至 V4.1 Flash，甚至 V4 Pro 请求也将按照计划转由新模型处理时，企业面对的已经不是“要不要试用一个新模型”，而是如何重新评估任务来源、调用成本、失败重试和业务结果。对开发者、产品经理与增长数据团队而言，真正需要回答的问题是：在更低价格刺激更多 Agent 运行之后，怎样才能看清每一次调用来自哪里、经过了哪些工具、消耗了多少资源，以及最终是否完成了真实业务任务。

DeepSeek V4.1 Flash 发布了什么

新架构与模型规模

DeepSeek 官方将 V4.1 Flash 定义为全新模型结构系列中尺寸最小的模型。根据 IT 之家 9 月 10 日报道，该模型总参数量为 552B，采用 MoE，也就是混合专家结构；输入侧激活 8B 参数，输出侧激活 16B 参数。DeepSeek 选择了与传统对称计算不同的设计，让模型在读取上下文和生成结果时使用不同规模的计算资源。

这种结构的核心不在于“552B”这个总参数数字本身，而在于每次请求实际激活多少参数。对于 Agent 来说，输入和输出承担的任务并不相同。模型可能需要读取长篇代码、历史对话、工具说明、网页内容和文件资料，但最后只需要输出一段代码、一个判断结果，或者下一步工具调用指令。如果所有输入和输出都采用同等规模的计算路径，就会在大量上下文读取环节产生较高成本。

V4.1 Flash 的非对称结构试图把这两个过程拆开处理。输入阶段激活 8B 参数，输出阶段激活 16B 参数，在保留较大模型容量的同时，减少每次请求的实际计算负担。DeepSeek 表示，这一设计能够让模型具备更高的能力上限、更快的推理速度和更大的吞吐量，同时为后续扩展至更大参数模型提供基础。

预训练与强化学习后训练

架构变化之外，DeepSeek 还表示 V4.1 Flash 采用了新的预训练方式，并进行了更大规模的强化学习后训练。官方公布的说法是，新模型在基准测试中超越了包括 DeepSeek V4 Pro 在内的多款旗舰模型。

用户材料中列出了部分测试结果：在 GPQA Diamond 科学问答测试中，V4.1 Flash 得分 90.9；Codeforces 竞赛编程评级为 3471；MathArena Apex 得分 65.6；Terminal-Bench 2.1 得分 90.6；CyberGym 得分 88.1。作为对照，材料同时给出了 V4 Pro 在 Terminal-Bench 2.1 和 CyberGym 上的部分成绩，分别为 87.9 和 83.3。

这些数字能够说明模型在特定测试集合中的表现，但不能直接等同于所有真实业务中的效果。基准测试更适合衡量某类问题上的能力上限，而企业真正关心的通常还包括响应时间、工具调用成功率、上下文保持、文件处理稳定性、失败重试成本和任务最终完成率。对于 Agent 应用而言，一个模型即使在单轮测试中得分很高，如果在连续执行十几个工具调用时频繁丢失状态，仍然可能带来较高的实际使用成本。

因此，DeepSeek V4.1 Flash 发布并最高降价 60% 后，开发者不能只看榜单成绩。新模型是否适合某个业务，还要观察它在真实任务中能否稳定完成从理解、规划、调用工具到验证结果的完整链路。

KV Cache 为什么重要

从参数规模转向上下文成本

V4.1 Flash 的另一项重点变化，是大幅减少 KV Cache 的占用。KV Cache 可以理解为模型在处理上下文时保存的一部分中间计算结果。对于连续对话和 Agent 工作流而言，模型经常需要反复读取相同的系统提示词、历史消息、工具定义、代码片段或文件内容。如果每轮都从头处理，计算和存储成本会不断增加；如果能够复用缓存，就可以减少重复工作。

DeepSeek 表示，与上一代模型相比，V4.1 Flash 对 HBM 的需求减少到四分之一，对 SSD 的需求减少到八分之一。官方还称，相对于初代模型，其 KV Cache 已经缩小 437 倍。

这些变化对于 Agent 任务尤其重要。一个长期运行的 Agent 可能持续浏览网页、执行代码、读取日志、修改文件并接收新的用户指令。每一次工具调用都可能把新的结果追加到上下文中，模型需要在越来越长的历史中保持任务目标。如果上下文缓存过大，就会增加显存、存储和调度压力；如果缓存复用不充分，重复读取又会直接推高调用成本。

缓存命中与重复上下文

V4.1 Flash 的 API 价格调整也与 KV Cache 直接相关。新价格于北京时间 2026 年 9 月 10 日 12:00 生效，继续采用峰谷定价。按照材料披露的价格，闲时缓存命中输入为每百万 Token 0.02 元，缓存未命中输入为 1 元，输出为 4 元；高峰时段价格为闲时的两倍。

与此前 V4 Flash 同一时段的价格相比，缓存命中输入降价 60%，缓存未命中输入降价约 33.3%，输出降价约 11.1%。从比例来看，降幅最大的并不是输出，而是重复上下文被缓存命中后的输入部分。

这意味着，受益最明显的可能不是一次性问答，而是需要连续读取大量上下文的任务。例如：

• Agent 多轮修改同一份代码，需要重复读取项目结构和系统规则。
• 文档分析任务需要反复引用同一批 PDF、表格和历史材料。
• 浏览器 Agent 在多个步骤中持续保留网页状态和工具说明。
• 企业自动化流程需要让多个子任务共享前置上下文。
• 多轮客服或运营任务需要持续记住用户偏好和已完成操作。

对于只生成一次短文本的任务，缓存命中带来的节省可能不明显；对于长时间运行、重复读取上下文的 Agent，缓存成本则会成为整体账单的重要组成部分。

一个简单的用量示例

以材料中给出的示例为基础，如果一次任务消耗 100 万缓存命中输入 Token、10 万缓存未命中输入 Token和 1 万输出 Token，那么在闲时价格下，调整前费用约为 0.245 元，调整后约为 0.16 元，下降约 34.7%。

这个计算只能作为单次用量示例，不能直接代表所有任务的实际账单。真实费用还取决于几个变量：

• 模型思考模式和思考强度。
• 工具调用次数。
• 每轮请求携带的历史上下文长度。
• 缓存命中率。
• 失败重试次数。
• 高峰时段和闲时段的调用比例。
• 多 Agent 协作过程中重复传递的任务信息。

这也是为什么单看“每百万 Token 多少钱”并不足以评估 Agent 成本。企业更需要记录每个任务的完整调用链，才能知道费用究竟来自模型输出、重复上下文、工具重试，还是流程设计本身。

API 迁移带来哪些变化

新模型名称与兼容路由

DeepSeek V4.1 Flash 已同步上线 DeepSeek API。开发者可以将模型名称设置为 deepseek-flash，调用最新的 V4.1 Flash 模型。

与此同时，旧版本 V4 Flash 与 V4 Flash Vision Exp 已下线。为了保持一定的兼容性，原有的 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 模型名会暂时被路由到 V4.1 Flash。这种兼容路由可以降低开发者立即修改代码的压力，但也带来新的版本管理要求。

如果应用仍然使用旧模型名称，服务端实际返回的可能已经是 V4.1 Flash。开发者需要检查：

• 实际响应中的模型标识。
• 输入和输出 Token 的统计方式。
• 图像输入是否被自动启用。
• 思考模式的默认状态。
• 工具调用协议是否发生变化。
• 旧版本提示词是否仍然适用。
• 业务侧的成本报表是否正确映射到新模型。

如果只看客户端配置，而不记录服务端实际路由结果，后续成本分析和性能对比就可能出现偏差。

V4 Pro 的有序下线

DeepSeek 还宣布，计划有序下线 V4 Pro。北京时间 2026 年 9 月 14 日 12:00 之后，在未来 V4.1 Pro 上线之前，访问 deepseek-v4-pro 的请求将全部路由到 V4.1 Flash，并按照 V4.1 Flash 的价格计费。

这意味着使用 V4 Pro 的团队需要提前检查生产系统。模型路由发生变化后，应用可能出现三类情况：

第一，模型名称没有改变，但底层能力和响应特征发生变化。依赖固定输出格式、固定思考长度或固定工具调用顺序的应用，需要重新验证。

第二，费用结构发生变化。虽然新模型单价更低，但如果 V4.1 Flash 的默认思考模式、上下文处理或工具调用行为导致请求长度增加，最终账单不一定按照简单的单价比例下降。

第三，业务效果需要重新对照。模型从 V4 Pro 路由到 V4.1 Flash 后，企业应重新比较任务完成率、人工接管率、异常重试率和端到端耗时，而不仅是比较模型返回速度。

模型路由变化对生产应用来说，本质上是一场运行环境变更。即使接口格式保持兼容，也应当像处理基础设施升级一样，提前完成灰度测试、结果校验和回滚准备。

原生多模态如何改变 Agent

图片、截图与文件进入同一入口

V4.1 Flash 原生支持多模态视觉理解。此前 DeepSeek 通过 V4 Flash Vision Exp 提供实验性质的视觉能力；此次发布后，文字与图片处理被合并到同一个主力 API 模型中，旧版视觉实验模型也被下线。

按照材料中的接口说明，开发者可以让模型描述图片、识别截图文字和分析图表。图片可以通过公开链接传入，也可以编码后直接提交，还可以先通过 Files API 上传再引用。

对真实业务中的 Agent 来说，统一模型入口有明显价值。很多任务并不是纯文本任务：

• 客服需要同时阅读用户文字和产品截图。
• 运维 Agent 需要分析错误日志与监控图表。
• 电商 Agent 需要理解商品图片、尺寸表和用户要求。
• 代码 Agent 需要同时查看代码、界面截图和设计稿。
• 财务分析 Agent 需要读取表格、图表与文字说明。
• 内容审核 Agent 需要将图片内容和文本上下文放在一起判断。

过去，开发者可能需要在文字模型和视觉模型之间自行切换，再将结果重新拼接。V4.1 Flash 把这些输入统一到主力模型后，可以减少路由层的复杂度，但也让单个任务的输入类型更加多样，运行监控必须同时记录文本、图片、文件和工具调用的关系。

长上下文与视觉输入的组合

材料显示，V4.1 Flash 支持 100 万 Token 上下文和最大 384K 输出，并支持 JSON Output、工具调用和 Responses API。对于企业应用来说，长上下文并不意味着应该把所有数据一次性塞进请求。

长上下文会带来几个实际风险：

• 输入内容增加后，模型响应时间可能变长。
• 图片和文件会增加请求体积及处理成本。
• 无关历史信息可能干扰当前任务。
• 长链路中的错误会被后续步骤持续放大。
• 缓存策略如果设计不当，可能出现命中率低和重复计费。
• 过长的输出会增加下游解析和存储压力。

因此，开发者需要把上下文管理当作独立的工程模块，而不是简单提高上下文上限。任务摘要、信息分层、文件按需读取、历史压缩和状态检查点，都应当配合模型调用一起设计。

Harness 与连续工作能力

模型不再独立于运行环境

与 V4.1 Flash 同步更新的还有 DeepSeek Harness v0.1.5。材料显示，V4.1 Flash 针对 Harness 的标准模式、程序化工具调用模式和极简模式进行了专项训练与优化。

这说明 DeepSeek 的优化重点不只在模型本身，也开始覆盖模型实际工作的运行环境。一个 Agent 能否稳定完成任务，不仅取决于模型能否理解指令，还取决于工具如何提供、结果如何返回、错误如何处理以及下一步状态如何保存。

在典型 Agent 循环中，系统需要不断重复以下过程：

1. 模型读取当前目标和历史状态。
2. 模型决定下一步动作。
3. 运行框架调用外部工具。
4. 工具返回结果或错误。
5. 模型根据结果继续规划。
6. 系统判断任务是否完成。

任何一个步骤出现状态错位，都可能导致任务停滞。比如工具已经执行成功，但结果没有正确写回模型上下文；或者工具返回了错误，但运行框架误判为成功；又或者模型重新读取旧状态，重复执行已经完成的操作。

保留 KV Cache 更新系统提示词

新版 Harness 支持在保留已有 KV Cache 的情况下更新系统提示词。对于需要调整工作规则的长任务，这一能力可以减少重复处理此前上下文的需要，也与 V4.1 Flash 的缓存成本优化形成呼应。

不过，保留缓存并不等于可以随意改变任务规则。系统提示词变化可能影响模型对历史内容的解释，尤其是在以下场景中：

• 任务权限发生变化。
• 工具列表发生变化。
• 用户要求改变输出格式。
• 子 Agent 的职责重新分配。
• 安全规则和审核要求临时升级。

工程团队需要记录每次提示词更新的时间、版本、原因和生效范围，并确认旧状态是否仍然适合新的规则。否则，缓存复用可能节省计算成本，却增加状态一致性风险。

文件处理与多 Agent 协作

新版 Harness 支持通过 Web 界面上传图片、PDF 等文件，并由模型通过文件工具按需读取。工作区文件树可以浏览和预览 Markdown、HTML、PDF、代码和图片。材料还提到，父 Agent 与子 Agent 支持双向通信，主 Agent 可以为子 Agent 选择模型和推理强度；实验性 Agent Teams 功能则允许主 Agent 创建多个成员，通过共享任务列表进行分配和跟踪。

这些变化意味着一个用户任务可能不再由一个模型完成，而是由多个不同角色的 Agent 协同完成。主 Agent 负责规划，子 Agent 负责检索、分析、编程或验证，最后由主 Agent 汇总结果。

多 Agent 协作带来更高效率，也带来更复杂的测量问题。系统至少需要知道：

• 哪个 Agent 创建了任务。
• 哪个 Agent 调用了哪个工具。
• 子任务何时开始和结束。
• 子任务是否失败后重试。
• 主 Agent 是否采用了子 Agent 的结果。
• 最终结果由哪些输入和步骤构成。
• 哪些 Token 消耗来自主 Agent，哪些来自子 Agent。

如果只统计总 Token 或最终响应，就无法判断一个工作流到底是高效完成，还是因为重复调用和错误重试产生了大量浪费。

模型降价之后，归因为什么更难

更低价格会带来更多调用

DeepSeek V4.1 Flash 发布并最高降价 60% 后，最直接的变化是更多开发者可以承担模型调用成本。过去因为价格较高而被限制的功能，可能会被放进更多产品中：

• 文档批量处理。
• 图片和截图理解。
• 自动生成营销内容。
• 多轮客服和售后处理。
• 网站信息采集与比较。
• 多 Agent 协作。
• 自动化测试和代码检查。
• 长时间运行的个人助理。

调用量上升本身不是问题，真正的挑战在于数据解释。一个用户点击了广告，随后启动了 Agent，Agent 又调用多个外部服务，最后完成一次注册或购买。传统统计系统可能只看到一个激活事件，却无法知道这个激活是由哪一个广告触点、哪一次智能体任务或哪一个分享关系促成的。

自动化请求与真实用户请求混在一起

当模型价格下降后，自动化脚本也更容易使用多模态能力。恶意脚本可以通过视觉模型识别页面、模拟用户操作、批量填写表单并生成看似自然的行为。真实用户、企业自有 Agent 和异常自动化流量可能同时访问同一套接口。

这时，单一的 IP 地址、单一设备字段或单次点击日志都不足以判断请求是否可信。企业需要结合更完整的上下文：

• 请求来自哪个应用或服务。
• 是否存在用户授权。
• 任务是否有明确的业务目标。
• 工具调用路径是否符合预期。
• 调用频率和时间间隔是否异常。
• 是否出现大规模相同任务模板。
• 最终行为是否形成真实业务结果。
• 安装、注册和留存是否与来源匹配。

这类判断不能只在结果页完成，而需要贯穿触点、调用、工具执行和业务转化全过程。

把模型调用纳入全渠道测量

对于同时运行广告、社交分享、Web 页面、应用市场和 Agent 入口的企业，模型调用已经成为用户路径中的新节点。传统渠道统计可以回答“用户来自哪个渠道”，但面对 Agent 工作流，还需要继续回答：

• 哪个入口触发了任务。
• Agent 是否代替用户完成了中间步骤。
• 用户何时重新接管任务。
• 哪个端最终完成了注册或支付。
• 任务中断发生在哪个环节。
• 模型调用和最终转化之间间隔多久。
• 失败重试是否被错误计入新的转化。

在实际工程中，企业可以通过统一的任务 ID 和来源标识，把外部触点、应用启动、模型请求、工具调用和业务事件连接起来。Open+ 的全渠道统计与渠道监测体系适合用于汇总不同分发入口和渠道事件，但模型调用、Agent 权限和业务语义仍需要由企业自身的服务端日志与授权系统共同提供。

跨端接续与场景还原

Agent 不会永远停留在云端

DeepSeek V4.1 Flash 可以处理文件、图片、工具和多轮任务，但很多业务最终仍需要回到用户设备上完成。用户可能需要在手机上确认支付，在应用内查看完整结果，或者在桌面端继续编辑 Agent 生成的文件。

这就产生了一个常见路径：

1. 用户从社交平台、网页或广告看到某项内容。
2. 用户点击链接，启动一个 Agent 任务。
3. Agent 读取图片、文件或网页内容。
4. Agent 生成方案、草稿或待确认结果。
5. 用户需要打开原生应用完成最终操作。
6. 如果应用未安装，用户先进入应用商店下载。
7. 安装完成后，应用需要恢复原来的任务状态。

如果第 7 步只打开默认首页，前面的模型调用和用户上下文就会被切断。对于用户来说，他必须重新上传文件、重新描述需求、重新寻找页面；对于企业来说，原始来源和任务关系也难以继续追踪。

延迟深度链接的作用边界

在这种场景中，Open+ 深度链接与场景还原能力可以作为跨端接续的一种工程路径：外部触点先保存任务所需的业务参数，用户安装应用后，再在首次启动时恢复对应页面或任务上下文。

需要明确的是，深度链接不能替代模型自身的状态管理，也不能绕过用户授权。它更适合解决“用户从一个入口进入另一个应用后，如何继续原来的业务场景”这一问题。对于包含文件、图片和敏感信息的任务，企业还需要：

• 只传递必要的短标识，不在链接中暴露原始隐私内容。
• 将完整任务状态保存在受控服务端。
• 设置参数有效期和一次性消费机制。
• 在应用启动后重新验证用户身份和操作权限。
• 对来自不同渠道的参数进行签名校验。
• 在用户确认前，不自动执行高风险动作。

这样才能把模型调用、用户接管和应用内操作连接起来，同时保持安全边界。

API 迁移与上线检查

开发者需要先做什么

对于正在使用 DeepSeek 旧模型的团队，V4.1 Flash 的发布涉及模型名称、价格、路由、输入类型和运行环境多项变化。上线前至少需要完成以下检查：

• 核对生产环境实际使用的模型名称和服务端返回名称。
• 检查旧模型名称被路由到新模型后的输出格式。
• 验证图片、PDF 和截图输入是否符合接口要求。
• 比较思考模式关闭、低强度和高强度时的任务效果。
• 记录缓存命中率和未命中率。
• 统计每个任务的工具调用和失败重试次数。
• 在高峰与闲时分别测试响应速度和价格。
• 针对 V4 Pro 路由变化进行回归测试。
• 为模型异常、接口变化和输出格式变化准备降级方案。

不能只做模型替换

如果一个 Agent 应用只是把模型名称改成 deepseek-flash，却不改变监控和账单结构，那么它仍然很难知道新模型是否真的带来成本下降。

更完整的测试应当包含任务级指标：

• 首次成功率。
• 任务完成率。
• 平均工具调用次数。
• 失败重试率。
• 人工接管率。
• 每个完成任务的平均成本。
• 从任务启动到业务结果的总时长。
• 通过模型调用产生的最终注册、购买或其他业务事件。

只有把这些指标与来源渠道、用户身份和任务 ID 关联起来，团队才有可能判断降价究竟带来了真实效率，还是仅仅带来了更多没有结果的调用。

常见问题（FAQ）

DeepSeek V4.1 Flash 最高降价 60% 是所有费用都下降 60% 吗？

不是。材料显示，最高 60% 的降幅主要对应缓存命中输入价格；缓存未命中输入和输出价格的降幅不同，高峰时段价格也高于闲时。实际成本还取决于上下文长度、缓存命中率、思考强度、工具调用次数和失败重试。

为什么 KV Cache 会影响 Agent 成本？

Agent 会反复读取历史对话、工具说明、代码和文件内容，缓存可以减少重复计算。V4.1 Flash 表示降低 HBM 和 SSD 需求，并下调缓存命中输入价格，因此连续读取大量上下文的任务可能获得更明显的成本收益。

旧的 DeepSeek 模型还能继续调用吗？

部分旧模型名称会暂时路由至 V4.1 Flash，但这不代表底层仍然运行旧模型。材料显示，V4 Pro 请求计划在 2026 年 9 月 14 日 12:00 后路由至 V4.1 Flash，开发者应提前检查输出、价格、性能和工具调用行为。

V4.1 Flash 为什么适合多模态 Agent？

它原生支持视觉理解，可以处理图片、截图和图表，并与工具调用、长上下文和文件处理结合。这样，Agent 不必在文字模型和视觉模型之间频繁切换，但开发者仍需管理输入大小、权限和任务状态。

使用低价模型后，企业还需要做归因吗？

需要。价格下降可能带来更多模型调用，但调用量不等于有效业务结果。企业仍需记录任务来源、模型请求、工具调用、应用启动和最终转化，才能区分有效任务、失败重试和异常自动化流量。