DeepSeek V4 Preview：Pro、Flash、1M 上下文、API 与开源权重怎么选

截至 2026 年 5 月 8 日，DeepSeek V4 Preview 已经不是传闻。DeepSeek 4 月 24 日的官方发布页明确写出 V4 Preview 已正式上线并开源，官方 API 也给出了 deepseek-v4-pro 和 deepseek-v4-flash 两个模型 ID。中文读者真正要解决的不是“有没有 V4”，而是先走官方 API、网页/App、Hugging Face 权重、第三方 Provider，还是本地自托管。

第一轮测试可以按一个简单规则拆开：高吞吐、低延迟、能用测试集验收的任务，先测 Flash；代码、Agent、多跳推理、长文综合、人工返工成本高的任务，先测 Pro。不要把 deepseek-v4-preview 写进 model 字段，也不要把 1M 上下文当成自动可靠的召回能力。

官方到底发布了什么

DeepSeek 官方发布说明的价值在于锁定事实边界：发布时间是 2026 年 4 月 24 日，标题是 DeepSeek V4 Preview Release，发布说明写明 V4 Preview 已 officially live 并 open-sourced，同时列出 DeepSeek-V4-Pro 与 DeepSeek-V4-Flash。两者都支持思考与非思考模式，官方 API 也使用明确的 V4 模型 ID。

Pro 与 Flash 的差异不是“一个高级、一个低级”这么粗。DeepSeek-V4-Pro 是 1.6T 总参数、49B 激活参数的 MoE 模型；DeepSeek-V4-Flash 是 284B 总参数、13B 激活参数。这个参数差异应该转成测试策略：Flash 用来跑可量化、可快速淘汰的量产任务，Pro 用来跑失败代价高、人工复核贵、上下文跨度大的任务。

真正容易踩坑的是把“1M 上下文”“开源”“低成本”“性能接近顶级模型”压成同一个采用理由。实现时必须把官方事实、市场解读、Provider 合同和本地部署风险拆开：官方事实来自 DeepSeek 与 Hugging Face，Provider 价格只证明 Provider 自己的路线，本地部署则是基础设施能力问题。

如果团队已经有旧的 DeepSeek 配置，先不要直接全量替换。更稳的做法是拉出一组固定样本：短输入、长输入、工具调用、JSON 输出、失败样本、人工高返工样本各一批；同一批样本同时跑 Flash、Pro 和现有生产模型。只有当 Flash 或 Pro 在质量、延迟、失败率和人工返工上都过线时，才把那一类工作负载迁过去。

Pro 与 Flash 应该怎么先测

Flash 适合先接入可以被自动验收的流程，例如分类、抽取、结构化输出、批量摘要、文档筛选、客服初分流和可复核的低风险生成。它的优势不是“永远够用”，而是当错误能被 schema、测试集、复核队列或二次验证挡住时，更低的成本与延迟可以让你跑更多样本。

Pro 应该先进入失败更贵的分支，例如代码 Agent、多文件 Debug、架构取舍、长上下文综合、跨章节事实冲突、工具调用链路和需要强推理稳定性的工作。Pro 的 token 价格可能更高，但如果它减少重试、返工和人工审稿，实际 accepted-output cost 反而可能更低。

API ID、旧别名与迁移

新代码应该直接使用 deepseek-v4-pro 或 deepseek-v4-flash。官方发布页说明 deepseek-chat 和 deepseek-reasoner 目前是兼容别名，分别指向 V4-Flash 的非思考和思考模式，并计划在 2026-07-24 15:59 UTC 后不可访问。它们可以帮助旧服务过渡，但不适合作为新生产配置的长期名字。

如果使用 OpenAI-compatible 客户端，DeepSeek 官方 quick start 与价格页给出的 base URL 是 https://api.deepseek.com。这只证明 DeepSeek 官方 API 的入口，不证明任何第三方 Provider 的路径、价格或模型新鲜度。生产配置里要把模型 ID、base URL、路线来源、价格检查日期和回滚策略写清楚。

hljs ts复制
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com",
});

const response = await client.chat.completions.create({
  model: "deepseek-v4-flash",
  messages: [{ role: "user", content: "Summarize the document and cite evidence lines." }],
  stream: true,
  max_tokens: 4096,
});

价格与折扣只能按日期引用

DeepSeek 官方价表是引用托管 API 成本的主来源。截至 2026 年 5 月 8 日，deepseek-v4-flash 行显示 cache hit input 为每 1M tokens 0.0028 美元、cache miss input 为 0.14 美元、output 为 0.28 美元。deepseek-v4-pro 当前折扣行显示 cache hit input 0.003625 美元、cache miss input 0.435 美元、output 0.87 美元；原价行是 0.0145、1.74、3.48 美元，并且官方说明 75% 折扣延长到 2026-05-31 15:59 UTC。

这些数字必须写上检查日期，因为它们是易变事实。第三方 Provider 可能有不同加价、折扣、余额、地区路由、日志、限额和支持策略。Provider 的报价或接入说明能证明“这个 Provider 现在这么卖”，不能反推 DeepSeek 官方价表，也不能证明官方 API 的 SLA 或支持边界。

1M 上下文怎么验收

1M 上下文首先是输入能力，不等于长文任务已经完成。真正需要验收的是远端事实召回、跨段推理、冲突处理、延迟、输出上限、重试率、accepted-output cost 和路线稳定性。一个模型能接受长输入，仍然可能在中段事实、结尾事实或多处证据合并上失败。

开源权重、Provider 与本地部署

DeepSeek 的 Hugging Face verified collection 包含 Pro、Pro-Base、Flash、Flash-Base，模型卡记录了 Preview 系列、MoE 参数、1M 上下文、思考模式与 MIT license。它能证明开源权重可用，但不能证明你的本地部署会拥有官方 API 的吞吐、延迟、上下文长度或工具行为。

本地部署的核心不是“免费替代官方 API”，而是把运行时责任转移给你自己：GPU、显存、KV cache、推理框架、批处理、监控、升级、评测和安全边界都要自己承担。Provider 路线也是另一份合同；它可能更方便，但必须重新检查价格、限额、日志、fallback、地区和支持。

如果要把 Hugging Face 权重放进内部评测，先从较短上下文开始，不要一上来就把 1M 当目标。先验证 32K、128K、256K 的召回和显存曲线，再决定是否值得扩大窗口。这样能把“模型支持长上下文”和“你的部署能稳定服务长上下文”分开，避免把基础设施失败误判成模型失败。

什么时候看 GPT 对比页

如果决策仍然是“DeepSeek V4 现在怎么用、先测 Pro 还是 Flash、1M 怎么验收”，就保持 DeepSeek-only 路线。如果问题变成 OpenAI 与 DeepSeek 的替换、并行或采购选择，就应该打开 sibling 对比路线：GPT-5.5 vs DeepSeek-V4。不要把跨厂商选择硬塞进 DeepSeek V4 Preview 的官方状态判断。

上线前检查表

• 把候选模型写成 deepseek-v4-flash 或 deepseek-v4-pro。
• 记录路线来源：官方 API、Provider、Hugging Face 权重或本地部署。
• 用同一 prompt set 对测 Flash 与 Pro。
• 如果 1M 上下文是切换理由，必须加入远端召回和跨段推理测试。
• 统计 accepted-output cost，而不是只看 token 单价。
• 对流式、工具调用、JSON 输出和 thinking mode 做实际集成测试。
• 给 deepseek-chat 与 deepseek-reasoner 的旧服务加别名退休检查。
• 发布任何价格、折扣、Provider、限额或可用性说法前重新核对当前来源。

上线评测包最好分三层保存。第一层是稳定回归集，用来发现模型更新或 Provider 路由变化；第二层是长上下文集，用来观察远端事实召回、延迟和输出截断；第三层是高失败成本集，用来决定是否把任务从 Flash 升级到 Pro。每次 DeepSeek 调整 Preview、价格或别名时，至少重跑第一层和高风险分支。

迁移时不要只看平均分。把样本分成“Flash 可留”“必须升 Pro”“暂不迁移”三类，并记录原因：事实漏召回、工具参数错、JSON 不稳定、长输出截断、延迟超 SLA、人工修复过长、Provider 限额不可控。这样团队不会因为一次漂亮 demo 就把所有流量推给新模型，也不会因为某个困难样本失败就放弃 Flash 的成本优势。

对旧别名的处理也要进入发布计划。保留 deepseek-chat 或 deepseek-reasoner 的服务需要列出 owner、调用量、替换 ID、灰度比例、回滚方式和最终删除日期。若某个旧服务必须暂时保留兼容别名，就要在 2026-07-24 15:59 UTC 前完成二次检查，而不是等到别名不可访问后再定位故障。

验收数据表至少保留六列：模型、路线、输入长度、通过率、p95 延迟、人工修复分钟数。价格列也要拆成官方价表日期和实际 Provider 账单日期，因为两者不一定同步。只有当通过率、延迟、人工修复和账单都在同一张表里，Flash 与 Pro 的选择才不会变成单纯的参数或单价争论。

如果这些数据暂时拿不到，就先保持小流量灰度，不要把 Preview 当成默认生产基线；缺少证据的路线只适合继续评测，不适合对外承诺稳定迁移，也不适合替代既有可靠模型或核心生产链路。

FAQ

DeepSeek V4 Preview 是官方的吗？

是。DeepSeek 2026 年 4 月 24 日官方发布页说明 V4 Preview 已正式上线并开源，API 文档也列出 V4 模型 ID。发布时保留 Preview 限定，因为价格、别名和模型行为都可能继续变化。

正确的 API model ID 是什么？

新代码使用 deepseek-v4-pro 或 deepseek-v4-flash。不要使用 deepseek-v4-preview。deepseek-chat 和 deepseek-reasoner 只是兼容别名，并有 2026-07-24 15:59 UTC 后不可访问的退休安排。

先测 Flash 还是 Pro？

高量、低延迟、低成本且能客观验收的任务先测 Flash。复杂推理、代码、Agent、长文综合、失败返工成本高的任务先测 Pro。最好保留同一评测集，让简单分支留在 Flash，困难分支升 Pro。

1M 上下文是不是可以直接放进生产？

不是。官方与模型卡能支持 1M 上下文能力，但生产还要验证召回、延迟、成本、384K 最大输出、Provider 限制和 Preview 期间的稳定性。

DeepSeek V4 权重是开放的吗？

DeepSeek verified Hugging Face collection 包含 Pro、Pro-Base、Flash、Flash-Base，模型卡列出 MIT license。这证明权重可用，不证明本地部署已经具备官方 API 的运行时表现。

OpenRouter 或其他 Provider 算官方 API 吗？

不算。它们是 Provider 合同。价格、路由、fallback、日志、限额、支持和模型新鲜度都要单独检查。官方 DeepSeek 事实以 DeepSeek 文档为准。

本地可以跑 1M 上下文吗？

可以评估，但这是基础设施问题。先从较短上下文阶梯开始，记录显存、延迟、召回和成本，再决定是否扩大到 1M。