DeepSeek Pro 正式版上线，但其低调的 API 推出让关键主张仍待验证

DeepSeek Pro 于 8 月 13 日推出最终 API 版本，取代预览模型，但没有发布详细的上线公告或更新后的基准测试报告。

DeepSeek 官方模型页面现将生产版本标为 DeepSeek-V4-Pro-0813。这一变化将历时三个月的预览版转为可供已使用 deepseek-v4-pro 端点的开发者部署的正式版本，同时也造成了一个不同寻常的验证缺口：DeepSeek 在说明模型内部究竟发生了哪些变化之前，便先替换了 API 背后的模型。

这一缺口之所以重要，是因为预览版曾提出格外雄心勃勃的主张。DeepSeek 将其定位为可与 Anthropic、Google 和 OpenAI 领先系统竞争的开放权重模型。如今，最终版本需要在生产环境中证明这些主张；在那里，可靠性和工具使用能力比单一基准测试的峰值表现更重要。

DeepSeek Pro 在现有 API 名称背后完成更新

眼下的变化是模型修订，而非新增端点或独立的开发者产品。

DeepSeek 官方的模型规格将 deepseek-v4-pro 列为 API 标识符。同一页面现将通过该标识符提供服务的版本标为 DeepSeek-V4-Pro-0813。

这一版本标签为 8 月 13 日发布提供了最明确的官方证据。本文撰写时，DeepSeek 尚未在其公开更新日志中发布对应的 8 月 13 日条目。因此，这次发布看似是一次低调的生产环境上线，而非传统意义上的产品发布。

开发者无需替换基础 URL，也不必迁移至新命名的端点。现有集成可继续向 deepseek-v4-pro 发送请求。DeepSeek 可在这一稳定的模型名称背后，控制这些请求实际落到哪个带日期的版本上。

这一方式减少了迁移工作，但也让可复现性变得更复杂。同一模型标识符下的两次请求，在更新前后可能会抵达不同版本。团队需要借助带日期的快照、评估记录或模型指纹，来判断行为是否发生变化。

官方页面列出的 DeepSeek V4 Pro 上下文窗口为 100 万 token。上下文窗口是模型在一次请求中能够处理的输入和生成内容量。页面还列出了 384,000 token 的最大输出长度。

这些限制确实可观，但不应被误认为模型能够在整个窗口范围内可靠推理的保证。模型可以接受超长提示词，却可能遗漏深埋其中的关系。长上下文检索与长上下文推理仍是不同的工程问题。

DeepSeek V4 Pro 支持思考与非思考两种运行模式。思考模式让模型在返回答案前，将更多计算资源用于中间推理。API 也提供推理强度控制，以满足需要更深层处理的工作负载。

该模型支持工具调用、结构化 JSON 输出、前缀补全和中间填充补全。中间填充补全要求模型在现有代码或文本段落之间生成内容，而不是只从末尾继续扩展。

DeepSeek 还增加了对 OpenAI 风格和 Anthropic 风格接口的兼容性。这一选择面向既有的智能体框架，在这些框架中，更换模型可能只需修改配置。

兼容性并不等于行为等效。不同模型在工具选择习惯、参数格式、拒答模式，以及失败操作后的恢复能力上都有差异。即使是 API 兼容的替换，也仍需进行应用层测试。

最终版本发布前，DeepSeek 已于 7 月停用较旧的 deepseek-chat 和 deepseek-reasoner 名称。这些别名曾在过渡期间暂时将用户路由至 V4 Flash 模式。

这一停用让 V4 的产品划分更加明确。Flash 面向速度和更高吞吐量的工作负载；Pro 则瞄准高难度推理、编程、知识和智能体任务，在这些场景中，更大的模型足以证明更高延迟的合理性。

这种区分对于生产路由至关重要。团队可以将 Flash 用于分类、提取或简单工具调用，并将 Pro 留给规划、代码修改，或失败成本更高的研究任务。

8 月版本并不要求开发者重新设计这一路由策略，但确实要求他们重新运行评估。一次无声的模型替换可能整体提升质量，同时在狭窄却重要的工作流中引入回归。

为什么最终版本没有伴随完整发布活动

DeepSeek 似乎正将模型部署与公开披露分开进行，这能加快交付，但也削弱了外部审查。

DeepSeek 于 4 月 24 日将 V4 Pro 和 V4 Flash 作为预览模型推出。其预览公告称，两款模型在发布当天便可通过 API 使用。

4 月的发布确立了如今与 DeepSeek V4 相关联的架构和产品定位。DeepSeek 将 Pro 描述为一款拥有 1.6 万亿参数的混合专家模型，在推理期间激活其中 490 亿参数。

混合专家模型包含许多专门化的参数组，但每个 token 只激活网络的一部分。这种设计可在不为每次请求动用全部参数的情况下，提高整体容量。

DeepSeek 将 V4 Flash 描述为一款规模更小的模型，拥有 2840 亿总参数和 130 亿激活参数。两个版本均以 100 万 token 的上下文窗口发布。

该公司还以 MIT 许可证发布了模型权重。这使预览版能够被检查并部署在 DeepSeek 托管服务之外，尽管运行完整的 Pro 模型仍需要大量基础设施。

生产环境的过渡分阶段完成。DeepSeek 先在 7 月下旬更新了 V4 Flash，为该模型推出带日期的 0731 版本。公司称，Flash 更新改变了后训练过程，但保留了预览版的架构和规模。

DeepSeek 的官方更新日志明确表示，该更新仅适用于 Flash API。日志补充称，V4 Pro API 和消费者应用保持不变，最终的 Pro 版本将在后续发布。

新的 0813 模型标签似乎兑现了这一承诺。不过，更新日志没有立即说明，Pro 获得的是仅限于新的后训练，还是更深层的修改。

后训练决定预训练模型如何遵循指令、进行推理、使用工具并响应人类偏好。即便不改变底层参数数量，这一阶段的变化也能显著影响实际应用。

最终版本的发布时间也反映出向持续模型交付的更大转变。供应商越来越多地维持稳定的 API 别名，同时更新其背后的模型。这种模式更接近软件即服务部署，而非传统的模型发布。

持续交付让供应商能够快速修复问题，也可以在不强迫每位客户迁移端点的前提下改善智能体行为。

代价则是透明度下降。开发者需要知道行为何时变化，因为模型更新可能会使提示词、评分阈值和安全控制失效。简短的版本标签无法替代发布说明。

DeepSeek 的推出方式尤为重要，因为该公司将开放权重和技术披露作为关键差异化优势。其 4 月预览版包含模型卡、架构细节和基准测试结果。

目前来看，这次低调的最终发布提供的信息更少。DeepSeek 尚未明确说明，预览版与 0813 版本之间的训练数据、奖励流程、智能体框架或安全调优究竟发生了哪些变化。

这并不意味着模型没有实质性改进，而是意味着外部观察者尚无法将任何已观察到的提升归因于某项已有文档记录的技术变化。

腾讯云此前曾告知客户，最终的 V4 模型将遵循 DeepSeek 的官方供给。其部署通知预告了通过托管模型服务提供 V4 Pro 和 V4 Flash 的计划。

这也为稳定版本提供了另一项理由。云平台和企业客户需要一个生产版本标识，才能将模型视为可长期依赖的组件。

不过，“最终”并不意味着一成不变。托管 AI 产品在正式普及后仍会持续变化。更有用的区别在于，DeepSeek 现在似乎已准备好将 V4 Pro 作为生产模型支持，而非实验性预览版。

DeepSeek Pro 对封闭式智能体模型构成压力

主要竞争并不只是开放权重与封闭权重之争，而是 DeepSeek 能否在真实工作负载中匹敌封闭模型的智能体可靠性。

DeepSeek 将 V4 预览版定位为可与 Anthropic、Google 和 OpenAI 高端系统竞争的产品。其最强的主张集中在编程、推理、世界知识和智能体工作上。

智能体模型不只是回答提示词。它会规划多个步骤、调用外部工具、读取结果、修订方案，并持续执行直至完成任务。

这类工作负载会暴露普通聊天基准测试可能掩盖的弱点。模型可以给出一个出色的单次回答，却可能在十次工具调用后失败，因为一个格式错误的参数就会让整个序列偏离轨道。

DeepSeek 表示，V4 Pro 在智能体编程评估中达到了领先的开放模型表现。它还称，预览版在部分内部测试中超过了 Anthropic 的 Sonnet 4.5，并接近更高配置的 Opus。

这些比较仍属于公司主张。基准分数取决于测试框架、工具定义、推理预算、重试策略和运行环境。配置上的细微差异就可能显著改变智能体排行榜。

最终 API 的重要性在于，它将比较从公开图表带入客户环境。开发者现在可以将同一个稳定端点与已在处理其代码库和业务流程的模型进行测试比较。

DeepSeek 在这场竞争中具备多项结构性优势。其 API 遵循熟悉的请求格式；对于偏好私有部署的组织，其权重可供使用；其长上下文能力可容纳大型代码库、文档集或更长的智能体历史记录。

公开的V4 模型卡描述了一种混合注意力架构，旨在降低长上下文计算和内存使用。DeepSeek 将压缩稀疏注意力与高度压缩的注意力相结合。

稀疏注意力限制在处理时哪些较早的 token 会获得完整注意力。压缩则保留过去信息的更小表示。二者结合，旨在降低处理超长提示词的成本。

DeepSeek 报告称，在 100 万 token 上下文下，V4 Pro 所需的单 token 推理计算量仅为 V3.2 的 27%。它还称，使用的键值缓存仅为 V3.2 的 10%。

键值缓存会存储较早 token 的表示，使模型无需为每个新生成 token 重新计算它们。更小的缓存可以在长会话中提升吞吐量，并降低内存压力。

这些架构效率直接针对编程智能体面临的实际限制。仓库级任务可能涉及源文件、测试日志、依赖文档，以及一长串工具结果。

然而，在提示词中塞入更多材料，并不会自动带来更好的软件。模型必须识别正确的文件、保持约束、解读失败原因，并避免修改无关代码。

同样的原则也适用于知识工作。长上下文可以容纳会议记录、研究论文和项目资料。可靠的综合分析仍取决于检索、来源追踪，以及抵御相互矛盾指令的能力。

封闭式供应商仍是难以挑战的对象，因为它们控制着整个推理技术栈。它们可以协调模型训练、系统提示词、工具协议、记忆层和用户界面。

例如，Anthropic 的编程产品受益于模型与智能体框架之间的协同优化。Google 可以将 Gemini 模型与其搜索、workspace 和云基础设施结合。OpenAI 则可以围绕自身的 Responses API 和编程系统调优模型。

DeepSeek 正在谋求更具可移植性的定位。它希望 V4 模型能够通过广泛使用的协议和独立框架运行。这给开发者带来更多部署选择，但也让他们承担更多集成责任。

因此，只有当开发者无需重建周边应用就能替换模型时，最终版 DeepSeek Pro API 才会对封闭式供应商形成最大压力。当竞品的价值来自一套集成式智能体系统时，这种压力就会减弱。

决定性的比较不会是孤立地比较一个模型与另一个模型，而是比较同一智能体框架内的任务完成率、人工干预率、延迟和故障恢复能力。

DeepSeek 公布的数据无法证明什么

最终标签解决了发布状态问题，但并不能独立验证 DeepSeek 的性能或生产可靠性。

DeepSeek 在 4 月的技术资料中称，V4 模型使用了超过 32 万亿个 token 进行训练。公司描述了一个两阶段后训练流程，涉及专门化专家模型和后续整合。

第一阶段采用监督微调和强化学习，培养特定领域的行为能力。第二阶段使用 on-policy 蒸馏，将这些能力整合为统一模型。

这些细节有助于研究人员理解其预期机制，但并未披露训练语料的完整构成、评测污染控制措施，或 0813 构建版本中确切的后训练变更。

最大的未知数在于基准测试的迁移性。编程基准通常为智能体提供干净的代码仓库、明确的测试和受限任务。生产环境中的软件工作则包含不明确的需求、隐藏依赖和组织惯例。

长周期任务会放大微小错误。智能体可能在早期选择了错误的抽象，却产出内部一致的代码，并通过表面检查，同时违反业务需求。

工具调用支持同样需要压力测试。开发者应检验模型是否选择正确工具、生成有效参数、遵守模式，并在出错时作出恰当响应。

结构化输出是另一个常见故障点。模型通常或许能返回有效 JSON，但当提示词变长、工具返回意外数据，或推理占用大量输出预算时，就可能失败。

当智能体读取不可信内容时，安全性依然重要。提示词注入是指文档或网页中包含旨在让模型偏离用户真实目标的文本。

更长的上下文会扩大这一攻击面。智能体可能处理更多包含敌对或误导性指令的第三方资料、日志、邮件或代码仓库文件。

模型供应商可以通过训练和系统设计降低这种风险。应用开发者仍需要权限边界、工具白名单、参数验证，以及针对重要操作的确认步骤。

数据治理带来了另一个问题。一些组织在缺乏合同、区域和保留期保障的情况下，无法将专有代码或敏感记录发送到托管服务。

开放权重为这些组织提供了另一条部署路径。自行托管并不能消除治理工作，而是将基础设施安全、访问控制、日志记录和模型维护转移给运营方。

V4 Pro 的规模使这项责任变得十分重大。一个拥有 1.6 万亿参数的混合专家模型在每个 token 上只激活其中一部分，但完整模型仍需要分布式存储和专用推理基础设施。

因此，大多数小团队将通过托管 API 或受管服务商接触 DeepSeek V4 Pro。他们的体验将同样取决于容量、速率限制、排队情况和区域可用性，而不只是模型智能水平。

DeepSeek 为 Pro 和 Flash 列出了不同的并发限制。并发指客户或服务在既定条件下能够同时处理多少请求。

吞吐量较低的 Pro 部署仍然可以用于困难任务。不过，在支持大规模面向用户的智能体之前，它可能需要请求路由、缓存、后台任务和回退机制。

版本稳定性同样值得关注。DeepSeek 的稳定别名让采用更容易，但客户应尽可能记录服务返回的带日期模型版本。

团队还应维护一套源自自身失败案例的小型评测集。公开基准有助于发现能力，私有测试则能揭示更新是否破坏了人们实际使用的应用。

一套实用评测可以包含具有代表性的工具调用、困难的代码仓库变更、长文档问答、拒绝案例和对抗性指令。每项测试都应具有可观察的成功条件。

开发者应在完全相同的提示词和设置下比较最终版本与预览版。否则，变化的推理预算或框架可能会被误认为模型改进。

他们还应将质量与成本、延迟分开评估。一个能解决更多任务的模型，如果响应时间破坏了交互式工作流，仍可能并不适用。

人工干预率提供了一个有用的综合信号。它衡量用户必须纠正智能体、重复指令、修复工具参数或撤销变更的频率。

此次发布较为低调，使这些评测变得更为重要。由于缺乏详细说明，客户不能假定提示词行为、安全边界或工具偏好保持不变。

DeepSeek 可能会在 API 上线后公布更完整的技术解释。在此之前，“最终版”应被视为一个生产里程碑，而不是对预览阶段各项主张的独立证明。

V4 机制瞄准长上下文的经济性

DeepSeek 最重要的技术押注在于：压缩注意力能够让百万 token 智能体变得实用，而不只是理论上可行。

V4 架构结合了两条注意力路径。压缩稀疏注意力通过选择有限的相关 token 块来减少计算量。高度压缩的注意力则保留其余上下文更广泛但更小型的表示。

这种混合设计解决了纯稀疏系统的一个弱点。激进的选择可能丢弃后续变得重要的信息。压缩的全局路径能够保留信号，而无需对所有内容应用完整注意力。

DeepSeek 还使用了流形约束超连接，简称 mHC。这些连接在试图维持超大网络训练稳定性的同时，调节信息如何在各层之间流动。

公司使用 Muon 优化器训练模型，这是一种旨在稳定并加速大型神经网络学习的优化方法。这两项技术都涉及训练，而非 API 行为。

对用户而言，可见结果是其宣称能够以更低的推理开销处理一百万个 token。这一能力可能改变开发者构建智能体工作流的方式。

编程智能体可以在提出修改建议前检查更多代码仓库内容。法律助手可以分析更大规模的合同集合。研究智能体则可以在一次会话中保留更多源材料和中间发现。

这些例子仍需要谨慎的上下文设计。将所有可用文档发送给模型，可能引入无关证据、相互矛盾的版本和隐藏指令。

即便拥有百万 token 窗口，检索仍然有用。检索会挑选最有可能回答问题的材料，减少噪声，并使引用更容易审计。

开发者可以将检索与长上下文结合，而不是在两者之间二选一。检索可以选择高优先级证据，而更大的窗口则保留周边细节和智能体历史。

该架构也支撑了 DeepSeek 更广泛的战略。Flash 与 Pro 同属一个产品家族，但面向不同的计算预算。

Flash 可以处理高频、可预测的操作。Pro 可以在首次尝试失败，或任务超过既定复杂度阈值时作为升级模型使用。

这种路由模式反映了工程团队已经采用的做法：将快速模型与更深入的推理系统结合。它可以减少不必要的 Pro 调用，同时为困难案例保留一个选项。

一个生产级智能体可能先使用 Flash 进行分类和信息提取，再调用 Pro 进行规划、处理模糊的代码变更，或解决检索来源之间的冲突。

挑战在于判断何时值得升级。基于提示词长度的简单启发式规则并不足够，因为简短请求也可能需要深度推理。

团队可以使用置信度估计、测试失败、工具错误或任务类别作为路由信号。他们也可以让用户针对重要决策请求更深入的分析。

DeepSeek 的双思考模式提供了另一层路由。非思考模式优先直接生成；思考模式则在输出可见回复之前分配更多计算资源。

最高推理设置可以改善困难任务的结果，但会增加延迟和资源消耗。开发者需要针对任务设置阈值，而不是为每个请求启用最大投入。

这种机制会对竞争对手形成压力，因为它瞄准的是智能体的运行经济性，而不仅是对话质量。智能体往往会生成大量 token，并在反复工具调用中保留庞大历史。

内存效率能够决定供应商是否能以盈利方式服务这些工作负载，也能决定组织能否在不需要不切实际硬件条件的情况下自行托管开放模型。

不过，DeepSeek 公布的效率数据是将 V4 Pro 与其自身的 V3.2 架构进行比较。它们并不能直接证明相对所有竞品模型或推理系统的优势。

封闭式供应商披露的架构细节较少，使得同类比较变得困难。它们的生产技术栈可能使用模型报告中看不到的缓存、推测解码、量化和路由方法。

因此，最终版 V4 Pro 为开发者提供了一个可测试的 DeepSeek 机制实现。它的真正价值将体现在持续工作负载中，在那里上下文规模、准确性、延迟和干预成本彼此交织。

三个信号将决定此次发布是否重要

接下来的证据应来自有记录的模型变更、独立的智能体测试和生产采用情况，而不是又一份孤立的排行榜。

第一个信号是官方的 0813 发布说明或更新后的技术报告。DeepSeek 需要解释最终构建版本与 4 月预览版的区别。

一份有用的披露应说明后训练变更、支持的接口、安全调整和基准测试设置，也应澄清架构和参数数量是否保持不变。

如果 DeepSeek 提供这些细节，外界对其发布叙事的信心将会增强。若模型页面仍是唯一的官方记录，客户就只能通过测试来推断其行为表现。

第二个信号是标准化 Agent 测试框架中的独立评估。这些测试应在相同的工具、提示词、推理预算和重试规则下，将 V4 Pro 与闭源模型进行比较。

编程测试应涵盖代码仓库导航、实现、测试执行以及失败后的恢复。长上下文测试则应要求模型综合证据，而不只是检索某一句隐藏文本。

安全评估应让模型面对提示注入和相互冲突的工具指令。当不受信任的内容试图将其重定向时，生产级 Agent 必须仍能保持用户的目标不偏离。

若多项独立评估均显示出稳定提升，将支持 DeepSeek 的性能主张。若结果在不同测试框架之间出现显著波动，则说明集成质量仍是主导因素。

第三个信号是伴随可衡量成果的生产环境采用。仅有云端可用性，并不能证明团队愿意把重要工作交给该模型。

有价值的证据包括重复使用、稳定吞吐量、低人工干预率，以及在编程或文档密集型 Agent 中的成功部署。公开的事故报告也有助于建立对失败模式的认识。

开发者应关注主要 Agent 框架是否发布推荐的 DeepSeek 配置。特定提供商的提示词模板和工具设置，往往能反映出一个模型需要多少调优。

他们还应关注 Pro 与 Flash 之间的关系。DeepSeek 先更新了 Flash，并在最终确定 Pro 前为其提供了更广泛的 API 功能。

如果 Flash 能够可靠地处理大多数 Agent 任务，Pro 可能会成为专门应对复杂规划和知识工作的模型。这会削弱“每个严肃的 Agent 都需要最大模型”的观点。

如果 Pro 在长流程、对失败敏感的工作流上展现出明显优势，双模型策略就更具吸引力。它将为开发者在同一 API 产品线内提供一条实用的升级路径。

对于知识工作者而言，这次发布也提醒人们，模型能力本身并不会自动整理信息。即使拥有更大的上下文窗口，仍然需要结构化的 AI knowledge base，以保留来源、权限和当前版本。

DeepSeek pro API 现已成为一个可用于生产环境的选择，但其重要性仍取决于后续验证。该端点已经可用，版本发生了变化，其架构也提供了可信的效率论据。

仍然缺失的是对最终构建版本的书面说明，以及证明其 Agent 性能能在真实约束条件下保持稳定的独立证据。开发者应在替换已受信任的生产模型之前，先验证这些主张。

下一步很明确：让 DeepSeek V4 Pro 运行在你最具挑战性、可重复的工作流上，记录 0813 版本，并在完全相同的条件下比较完成质量、延迟和人工干预情况。