DeepSeek V4.1 Flash 上线，V4 Pro 为何没下线？模型选型与成本对比

2026 年 9 月 10 日，DeepSeek 发布 V4.1 Flash，并宣布了一项引起开发者关注的服务调整计划：原有 V4 Pro 将逐步退出 API 服务，其模型名称对应的请求计划转由 V4.1 Flash 处理。按照当时的官方解释，新模型已经在性能、速度和成本等多个维度取得提升，因此继续维持两个不同定价的模型版本，似乎不再具有足够的必要性。
但事情并没有完全按照最初的公告发展。DeepSeek 随后在官方更新日志中明确表示，由于用户需求，V4 Pro 在 9 月 14 日之后继续提供 API 调用服务，计费方式维持原状。截至 2026 年 10 月 8 日，官方价格页面仍然同时列出 deepseek-flash 和 deepseek-v4-pro 两个模型。

这次调整值得分析的地方，并不只是 DeepSeek 改变了原有服务计划。更有意思的是，当一款价格更低的新模型已经在多项基准测试中超过原有旗舰模型时，为什么仍然有开发者希望保留旧版本？对于正在建设 AI 应用、Coding Agent 或者自动化工作流的团队，这涉及模型版本稳定性、推理效果和整体使用成本之间的取舍。

一、从 V4 Pro 正式发布到 V4.1 Flash 上线，DeepSeek 经历了哪些调整？

DeepSeek V4 系列最早于 2026 年 4 月 24 日推出预览版本。当时官方将模型划分为 Pro 和 Flash 两个方向，其中 Pro 定位于复杂推理、知识处理与 Agent 任务，Flash 则通过较小的计算规模降低推理成本。两个版本均支持百万 Token 上下文，并通过 API 开放调用。

这一阶段的产品划分比较清晰。Pro 承担复杂任务，Flash 处理对价格与响应效率更敏感的工作。开发者可以根据任务特点选择模型，并不需要在所有功能中统一使用旗舰版本。

7 月 31 日，DeepSeek 更新 V4 Flash 正式版 API，重点提高 Agent 相关任务的表现。根据官方更新日志，该版本在 Terminal-Bench 2.1 中取得 82.7 分，DeepSWE 达到 54.4 分，NL2Repo 达到 54.2 分。相比早期预览版本，新一轮后训练明显加强了模型处理代码和工具调用任务的能力。

8 月 13 日，V4 Pro 正式版上线。此次更新面向 Agent 应用进行了专项优化，并扩展对 OpenAI Responses API 的支持。官方还针对 Codex 等编程工具进行了适配，同时为思考模式提供 low、high 和 max 三级推理强度设置。

同月 17 日起，DeepSeek 正式实施新的峰谷计费机制，高峰和空闲时段采用不同价格。该机制意味着开发者除了选择模型，还可以通过调整任务执行时间控制费用。

真正改变模型竞争关系的是 9 月 10 日发布的 DeepSeek V4.1 Flash。

与旧版 Flash 相比，V4.1 Flash 采用了新的非对称 Causal-Encoder-Decoder 架构，并在预训练和强化学习后训练阶段进行调整。官方宣布，新版本在一系列 Agent 基准测试中超过 V4 Pro，同时降低了推理所需的计算与缓存资源。

基于这些测试结果，DeepSeek 在 9 月 10 日的发布说明中提出，计划从 9 月 14 日 12 时起，将访问 V4 Pro 的请求路由到 V4.1 Flash，并按照 Flash 价格计费，直至未来 V4.1 Pro 上线。

然而，官方后续更新日志修改了这一安排，明确继续保留 V4 Pro 的独立 API 服务。这意味着截至本文撰写时，开发者依然能够通过 deepseek-v4-pro 访问 V4 Pro-0813 版本，而不是默认被重定向到 Flash。

需要注意，9 月 10 日原始发布文章和更新日志中的服务安排存在差异。判断当前可用模型，应以更新后的官方模型列表与价格页面为准，而不能只引用发布当天的公告。

这次变化反映出一个现实情况：模型技术升级可以降低新版本的使用成本，但已经部署到业务系统中的旧模型，并不一定能够立即退出生产环境。

二、V4 Pro 与 V4.1 Flash 有什么不同？参数规模不是唯一指标

V4.1 Flash 最值得关注的变化，是它并没有简单延续过去通过缩小模型规模降低成本的思路。

按照 DeepSeek 官方技术资料，V4.1 Flash 是一款总参数量为 552B 的混合专家模型，也就是 Mixture-of-Experts（MoE）架构。它采用新的 Causal-Encoder-Decoder 设计，将输入处理和输出生成阶段区分开来：输入阶段激活约 8B 参数，输出阶段激活约 16B 参数。

这里的 552B 表示模型总参数规模，而 8B 和 16B 代表不同计算阶段所激活的参数规模。不能将总参数量直接等同于每个 Token 实际执行的计算量。

传统稠密模型通常需要调用大量固定参数完成前向计算，而 MoE 通过路由机制选择部分专家参与处理。V4.1 Flash 在此基础上进一步采用非对称设计，让输入处理与自回归生成分别使用更适合的计算配置。

对于 API 应用，这一设计具有明确的工程意义。大量 Agent 请求往往包含较长的上下文输入，但单轮输出未必同样长。输入和输出采用不同的激活规模，有机会提高计算资源的利用效率。

官方还披露，V4.1 Flash 显著压缩了 KV Cache 的存储需求。相比上一代模型，新架构的高带宽显存需求降低至原来的四分之一，SSD 存储需求降低至八分之一。

KV Cache 用于保存 Transformer 推理过程中已经计算的 Key 和 Value 状态，避免每次生成新 Token 时重复处理全部历史信息。对于多轮对话和长上下文 Agent，缓存占用会直接影响 GPU 显存、存储系统和请求并发能力。

因此，缓存压缩的价值不仅是节省空间，还可能提高同等硬件条件下的服务容量。需要强调的是，显存需求降低四分之三，并不意味着单次 API 费用一定降低相同比例。模型服务价格还受到硬件成本、吞吐调度和供应商定价策略的影响。

从 API 能力来看，两个模型的差异可以整理为下表。

表格

数据来源：DeepSeek 官方《模型与价格》页面，2026 年 10 月核查。表中的并发限制是官方服务参数，并非模型在任意环境下都能达到的吞吐能力。

一个值得注意的细节是，V4.1 Flash 支持原生视觉理解，而当前 V4 Pro 官方 API 不支持图像理解。这使得 Flash 不再只是一个低成本文本模型，在需要分析截图、图表或者视觉信息的 Agent 应用中，它反而具有更直接的功能优势。

不过，功能覆盖范围更广，不等于能够直接替代所有已有工作流。尤其是在复杂代码修改、长程推理和高度依赖固定输出格式的任务中，具体模型的行为稳定性仍需要单独验证。

官方基准测试反映了什么？
DeepSeek 在 9 月 10 日更新日志中公布了 V4.1 Flash 的多项评测结果，包括 GPQA Diamond 90.9、Codeforces Rating 3471、Terminal-Bench 2.1 达到 90.6、DeepSWE v1.1 达到 74.2，以及 Automation-Bench 达到 54.8。

这些数据说明，Flash 的能力提升并不只体现在一般知识问答中，也覆盖代码操作与 Agent 任务。

可以参考两个版本公开的部分测试数据：

表格

其中，V4 Pro 的数据来自 8 月 13 日官方更新日志，V4.1 Flash 来自 9 月 10 日更新日志。需要特别注意，Flash 的 DeepSWE 指标标注为 v1.1，NL2Repo 也使用了不同的版本名称，因此不能将表中所有差值直接解释为严格同条件的性能提升。

另外，Agent 类评测还受到执行框架、工具权限、推理强度和测试配置影响。不同版本的分数能够说明模型发展的方向，但不能替代开发者在自身项目中的回归测试。

从这些公开结果来看，V4.1 Flash 已经具备相当强的复杂任务处理能力。对于多数新建应用，将它列为优先测试对象是合理的，但这并不足以证明旧版本在全部生产任务中都没有价值。

三、Flash 明显更便宜，为什么还有开发者选择 V4 Pro？

如果只考虑官方 Token 价格，V4.1 Flash 的优势非常明确。根据 2026 年 10 月官方定价，Flash 在空闲时段的普通输入价格为每百万 Token 1 元，输出为 4 元；V4 Pro 对应价格分别为 4.5 元和 13.5 元。

在输入输出规模完全相同的情况下，Flash 的理论调用成本明显低于 Pro。

然而，实际应用不会只运行一次固定请求。模型往往需要读取工具结果、修改文件、执行测试，并根据返回信息继续处理任务。尤其是在 Coding Agent 中，一次用户任务可能包含十几次甚至更多模型请求，最终成本取决于整个任务的完成过程。

这里可以引入一个比 Token 单价更重要的指标：单位成功任务成本。

假设某个代码修复 Agent 需要完成 100 个任务，开发者分别使用 Flash 和 Pro 进行测试。Flash 每次完整尝试的平均模型调用费用为 0.8 元，首次成功率为 70%；Pro 每次尝试的平均费用为 2.5 元，首次成功率为 90%。

如果暂时忽略重试过程中的上下文变化，以每次尝试独立且成功率不变为前提，Flash 的理论成功任务成本约为 1.14 元，Pro 约为 2.78 元。

这个假设案例中，虽然 Pro 的首次成功率更高，但 Flash 仍有明显成本优势。如果任务只关注成本，而且允许自动重试，Flash 可能是更适合的选择。

但当一次失败会造成较长的执行时间、外部工具费用或者人工介入时，情况可能发生改变。例如在复杂代码部署流程中，模型修改失败后需要重新构建项目，或者执行耗时较长的测试套件。此时单纯计算 Token 支出，容易低估失败所带来的整体成本。

因此，评估模型经济性时，应当把平均请求费用、成功率、执行时间和必要的人工复核成本放在同一个任务口径下。

上述数字仅用于解释计算方法，不代表 DeepSeek 两个模型的实测成功率或平均任务费用。

另一个不可忽略的因素是输出一致性。

很多企业应用会对模型输出做结构化解析，例如要求返回固定字段的 JSON，或者根据工具调用结果执行下一步操作。即使两个模型均支持 JSON Output 和 Tool Calls，它们在面对同一提示词时，也不一定生成完全相同的结构与内容。

如果一个系统已经围绕 V4 Pro 建立了稳定的提示词与校验机制，更换 Flash 之后就需要重新确认字段完整性、工具调用参数和异常处理行为。对于没有严格时间压力的新项目，完成一次迁移测试并不困难；但对于运行中的关键业务，未经验证的模型替换可能造成额外风险。

这也是保留 Pro 服务具有工程价值的原因。旧模型不必在全部指标上领先，只要仍然有业务依赖它，就可能存在继续提供服务的必要性。

当然，这不意味着 V4 Pro 一定比 Flash 更稳定。目前没有足够公开数据证明 Pro 在所有复杂任务上的成功率高于 V4.1 Flash。按照 DeepSeek 发布时的官方说法，Flash 在多项测试中已经超过 Pro。因此，新项目应当通过实际任务评测决定模型选择，而不是按照 Pro 与 Flash 的命名推断能力高低。

四、DeepSeek API 费用如何计算？缓存命中和峰谷价格影响有多大

DeepSeek 在 2026 年 8 月引入峰谷计费，9 月又进一步下调 Flash 价格，使模型费用呈现出明显的时间差异。

截至 2026 年 10 月 8 日，官方公布的人民币价格如下，单位均为元 / 百万 Token。

表格

高峰时段为北京时间周一至周五 9:00—12:00、14:00—18:00，不包含中国法定节假日。其他时间以及周末和法定节假日属于空闲时段。

实际扣费应以官方账户账单为准，第三方 API 服务的价格也不一定与官方完全相同。

场景一：长文档分析任务
假设一个企业知识库应用每次需要处理 100,000 个输入 Token，最终生成 10,000 个输出 Token。为了便于计算，这里假设输入全部未命中缓存，且每次请求均在相同价格时段内完成。

采用 V4.1 Flash：
空闲时段输入费用为 0.1 元，输出费用为 0.04 元，单次合计 0.14 元。高峰时段对应费用为 0.28 元。

采用 V4 Pro：
空闲时段输入费用为 0.45 元，输出费用为 0.135 元，单次合计 0.585 元。高峰时段为 1.17 元。

表格

在输入输出 Token 数量相同的条件下，Flash 成本大约是 Pro 的 23.9%。

需要注意，这个计算没有考虑不同模型可能产生不同长度的推理内容，也没有包含因重试导致的额外调用。对于思考模式，内部推理产生的输出 Token 也应按照官方实际计费规则计入。

场景二：缓存命中后的费用变化
Agent 应用通常具有较高的上下文重复率。比如一个编程助手在连续修改代码时，会多次发送相同的系统提示词、项目结构和部分历史记录。

假设一次 Flash 请求包含 100,000 个输入 Token，其中 80,000 个命中缓存，20,000 个未命中缓存，另外产生 10,000 个输出 Token。

在空闲时段：
缓存命中部分费用为 0.0016 元，普通输入费用为 0.02 元，输出费用为 0.04 元，单次合计 0.0616 元。

如果全部输入都未命中缓存，相同输出下的费用为 0.14 元。

这说明在该假设条件下，缓存复用可显著降低费用。不过，具体命中率取决于输入结构与服务端缓存策略，不能直接假设每次调用都能达到 80%。

还需要区分 KV Cache 资源压缩与 API 缓存计费。前者主要是模型服务架构层面的存储优化，后者则决定用户请求中重复上下文按照什么价格扣费。两者存在联系，但并不是同一个概念。

场景三：将非实时任务安排在空闲时段
对于需要即时返回结果的在线问答，开发者很难自主安排用户请求时间。但数据清洗、批量报告生成、定期代码扫描等任务通常没有严格的秒级响应要求。

以每天处理 10,000 个文档任务为例，如果采用前述全部未命中缓存的 Flash 请求，全部在高峰时段执行，理论 Token 费用为 2,800 元；全部放到空闲时段则为 1,400 元。

对于具备任务队列的应用，可以将非实时任务安排在空闲时段执行，从而在不更换模型的情况下减少调用费用。

但峰谷调度也有适用范围。如果用户要求立即生成内容，或者任务存在严格的执行截止时间，延迟处理可能影响产品体验。成本优化应当服务于应用需求，而不是为了降低 API 单价牺牲核心功能。

五、如何让不同任务自动选择不同模型？

当一个 AI 应用同时存在简单文本处理、代码开发和复杂 Agent 任务时，为全部请求固定指定同一个模型，通常不是最灵活的架构。

比较合理的方式，是在业务系统和模型服务之间建立独立的模型选择层。任务进入系统后，先根据任务类型、复杂程度及输出要求选择候选模型，再发送 API 请求。调用结果通过统一的校验流程检查，如果失败，再根据错误性质决定是否重试或切换模型。

这个过程通常被称为模型路由（Model Routing）。

模型路由不一定需要额外部署复杂的机器学习分类器。对于任务类型明确的应用，使用预设规则就足以构建初步方案。例如，常规文本分类与格式整理可以优先尝试 Flash，依赖历史提示词表现的关键任务暂时保持 Pro，包含图像输入的任务则应选择具备视觉理解能力的模型。

后续如果通过业务评测确认 Flash 能够稳定完成更多任务，可以逐步调整路由比例，而不是一次性替换全部调用。

DeepSeek 官方 API 兼容 OpenAI SDK，开发者可以通过统一客户端实现基础接入。下面是一段简化的 Python 示例，用于演示按任务类型选择模型，不包含完整的生产级故障恢复机制。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com"
)

MODEL_CONFIG = {
    "text_processing": "deepseek-flash",
    "code_analysis": "deepseek-flash",
    "legacy_workflow": "deepseek-v4-pro"
}

def call_model(task_type, prompt):
    model = MODEL_CONFIG.get(
        task_type,
        "deepseek-flash"
    )

    response = client.chat.completions.create(
        model=model,
        messages=[
            {
                "role": "user",
                "content": prompt
            }
        ]
    )

    return response.choices[0].message.content

这里将 legacy_workflow 暂时绑定 V4 Pro，并不是判断 Pro 在此类任务上一定更强，而是模拟实际系统中已经验证过的旧工作流。是否迁移到 Flash，应由后续回归测试决定。

需要强调的是，自动回退并不是在请求失败时无条件更换模型。如果错误来自认证失败、参数不合法或者账户余额不足，切换模型未必能够解决问题。对于涉及工具操作的 Agent，还要防止请求重试造成重复执行，例如多次创建文件或重复提交交易。

在生产系统中，回退策略通常需要根据错误类型、任务状态和可重试性进行区分。对于已经完成部分外部动作的任务，应当先检查执行结果，再决定下一步操作。

当开发者需要同时调用 DeepSeek、Kimi、Qwen 和 GLM 等国产模型时，模型路由还会涉及不同供应商的 API 配置与版本管理。虽然不少国产模型提供 OpenAI 兼容接口，但模型名称、参数支持范围和工具调用机制并不完全一致。

这种场景下，可以将星链 API 等国产模型 API 中转站作为统一接入方案。通过集中管理模型调用入口，应用能够减少在不同业务模块中重复维护接口配置的工作量，同时保留按任务选择模型的空间。实际使用前，仍需确认所需模型版本已经上架，以及对应的推理模式、工具调用和计费方式是否符合业务要求。

统一接入层不能代替模型评测。即使不同模型可以通过类似的请求格式调用，也不意味着它们能够对同一个复杂任务给出一致结果。模型选择仍然需要建立在实际数据与工程测试上。

模型升级应该采用什么验证标准？
对于已有 V4 Pro 应用的团队，是否切换到 V4.1 Flash，可以通过小规模灰度测试判断。

测试时应尽量保持提示词、输入数据、工具环境与任务目标一致，同时固定可控的推理参数。模型输出需要经过相同的质量校验，并记录任务是否完成、调用 Token 数量和端到端执行时间。

如果涉及代码生成，可以使用单元测试和集成测试判断结果；对于结构化信息提取，可以比较字段正确率和遗漏情况；对于 Agent 工作流，则需要记录完整任务成功率，而不只是模型单轮回答质量。

在模型成本比较中，还应统计 P95 响应时间、失败重试比例及人工处理成本。只有这些数据能够反映完整业务流程中的投入产出情况。

对于希望通过统一接口管理多款国产模型的团队，星链 API 可以作为接入层的备选方案。但模型路由规则、业务验证和异常恢复仍然需要结合应用要求设计，不能仅靠更换 API 地址完成全部工作。

六、DeepSeek 保留 V4 Pro，对开发者意味着什么？

从 4 月推出 V4 系列，到 8 月 V4 Pro 正式发布，再到 9 月 V4.1 Flash 上线，DeepSeek 的产品变化呈现出一个趋势：模型性能提升正在越来越多地依赖架构创新与推理系统优化，而不是单纯扩大参数规模。

V4.1 Flash 采用 552B MoE 与非对称 Causal-Encoder-Decoder 结构，通过减少输入阶段的激活参数和压缩 KV Cache，降低了推理系统的资源需求。官方公开的部分评测显示，它已经在代码和 Agent 任务中取得较强表现，并能够以更低的 Token 价格提供服务。

这使 Flash 具备成为大量新应用默认模型的条件。尤其是需要处理高并发请求、长上下文和视觉输入的业务，Flash 的功能覆盖与成本优势值得优先测试。

但 V4 Pro 仍然具有现实的工程价值。已经在生产环境中验证过的模型行为、提示词配置与执行流程，不应该因为新的基准测试结果就被直接放弃。DeepSeek 最终继续提供 Pro API，也为开发者保留了渐进迁移与独立验证的空间。

在今后的模型选型过程中，开发者可以将 Token 价格视为基础成本，再结合任务成功率、延迟和系统维护成本判断实际收益。对于需要长期运行的 Agent 系统，保持模型接入层的灵活性，往往比持续追逐最新版本更具有工程价值。

DeepSeek V4.1 Flash 的发布证明，更低的推理成本不一定意味着更弱的任务能力；而 V4 Pro 的继续保留则说明，模型服务的价值不能只通过公开排行榜衡量。真正合理的模型选择，应当建立在可复现的业务测试和完整任务成本之上。

当模型版本持续迭代，企业需要解决的也不再只是如何调用某一款模型，而是如何在能力升级、成本变化和业务稳定性之间建立持续有效的管理机制。

了解更多：https://xinglianapi.com