我是 Lena。过去两周我把一个 agent workflow 接到 DeepSeek V4 上跑，看看会发生什么。不是跑一组 quick benchmark。就是……把东西跑起来，盯着 token 计数器，跟踪钱到底花到了哪里。
价格看上去几乎好得不像真的。一部分确实是。但有一部分并不是它表面看起来那样——倒不是数字写错了，而是数字只讲了故事的一半。这就是我注意到的东西。
DeepSeek V4 API 表面上提供了什么
DeepSeek 在 2026 年 4 月 24 日 ship 了 V4 的 preview 版本。两个 model，都是 MoE 架构，都是 1M-token 的 context window ，最大输出可达 384K。
V4 Pro：1.6 万亿总参、每 token 激活 49 亿。模型 ID 是 deepseek-v4-pro。定位是复杂推理、coding、agentic 任务。目前有一波 75% 的促销折扣，持续到 2026 年 5 月 31 日——促销期内，cache-miss 的输入价是 $0.435 / M token ，输出 $0.87 / M token。促销结束后，这两个价分别跳到 $1.74 和 $3.48。
V4 Flash：2840 亿总参、激活 130 亿。模型 ID 是 deepseek-v4-flash。为速度和成本效率设计。定价 $0.14/M 输入 和 $0.28/M 输出 ——不需要折扣，这就是标准价。
两个 model 都支持 thinking 和 non-thinking 模式、tool calls、JSON 输出，以及 OpenAI 兼容的 API 格式。老的 deepseek-chat 和 deepseek-reasoner 别名计划在 2026 年 7 月 24 日下线。
上生产之前必须验证的事
我把官方定价页翻了好几遍。有一件容易漏掉的事：cache-hit 的输入价在 2026 年 4 月 26 日被砍到了发布价的 1/10 。在 V4 Flash 上，cached input 是 $0.0028/M——比 cache-miss 便宜了 98%。V4 Pro 在促销期内，cached input 是 $0.003625/M。
……这是一个挺大的、不该被忽略的数字。
但有一件事我反复回到上面来想：cache hit 不是有保证的。DeepSeek 自己的文档把 caching 描述成 best-effort。你可以把 prompt 的结构调整得对命中率友好——稳定的 system prompt 放最前、变动内容放最后——但你不能假设一个 hit rate。你必须实测。
Benchmark 数字也很硬。V4 Pro 在 SWE-bench Verified 上拿到 80.6%，跟最强的闭源 model 之间差距只有 0.2 分。V4 Flash 在 SWE-bench 上比 Pro 落后大约 1.6 分，每 token 成本却便宜了大约 12 倍。根据 NVIDIA 关于 V4 的技术博客，hybrid attention 架构（CSA + HCA）把 inference FLOP 降到了 V3.2 在 1M context 时所需的 27%，KV cache 降到了 10%。这是真的架构层面的进步，不是 marketing 数字。
但我仍然不太确定 benchmark 能告诉你多少：当一个 agent 因为前五次都返回了 malformed JSON、于是把同一个 tool call 跑了第六次的时候，会发生什么？
为什么对 agent 来说，便宜的 token 重要
数学很简单。当输入 token 是 $0.14 / M 的时候，你能跑得起更多 experiment。更多 iteration。更多候选解。更多 evaluation pass。
具体到 agent workflow，这件事改变了三件事：
每一块钱能跑的次数变多了。 一个 coding agent，调用 1,000 次 API，system prompt 2,000 token、user message 200 token、response 300 token，假设 system prompt 命中 cache，在 V4 Flash 上的总价大约是 $117.60 。同样这个量，跑在 $15/$75 的 input/output model 上，会要 $20,000 以上。这个差距不微妙。
实验的入门成本变低了。 如果你在搭一个 agent pipeline，需要测试你的 tool definitions 行不行、prompt 结构在边界 case 下扛不扛得住、evaluation harness 抓没抓到正确的 failure——便宜的 token 意味着你真的可以去 iterate，而不是靠猜。
Cache 经济学奖励好的工程能力。 那些把 prompt 做得整齐的团队——稳定的 prefix、一致的 few-shot example、变动内容放最后——会被不成比例地奖励。正如 Hugging Face 团队在他们的 V4 分析里指出的，hybrid attention 加上激进的 cache 定价，让 long-context 的 agent loop 第一次在规模上变得真正可行。
我反复在想这件事：成本上的优势不只是花得更少。是它让你买得起 debugging 的开销。
便宜的推理消除不掉的隐藏成本
这是我坐了挺久的那一段。
便宜的 token 减掉的是账单里的一行。但 agent 的成本不是被 token 价格主导的。它是被事情出错时会发生什么 主导的——而事情经常出错。
失败的 tool call
DeepSeek 自己的文档明确警告：model 可能生成无效的 JSON、可能 hallucinate 出你 function schema 里没定义的参数。你必须在执行任何 function 之前 validate 参数。这不是 DeepSeek 独有的问题——每一个 model 都会这样。但在 agent 规模下，5% 的 tool call 失败率不是说你的成本浪费了 5%。它意味着你 5% 的调用会触发 retry、error handling、重新 prompt，以及可能的下游级联失败。
……这部分成本不在定价页上。
重试和反复 debugging
一个失败步骤要重试三次的 agent，比第一次就成功的 agent 多烧 4 倍的 token。便宜的输入 token 有帮助，但它没有修复底层那个问题——model 没有按你要求的去做。如果你的 retry 逻辑就是把同一个 prompt 再发一次，你就是在为同一个错误反复付钱。
观察 V4 Flash 处理多步任务时，我注意到这个 pattern。它快、它便宜，在直来直去的步骤上，它真的好。但在那些需要精确结构化输出、或者复杂 tool orchestration 的步骤上，它的失败率比 V4 Pro 明显高一截。一旦把 retry 算进去，Flash 和 Pro 之间 12 倍的成本差就开始压缩。
Evaluation 的开销
这一点几乎没人在预算里留出位置：你仍然需要评估 agent 的输出对不对。如果你用第二次 model call 去验证第一次的输出，你的有效成本就翻倍。如果你拿一个更贵的 model 当 judge，token 的价格优势会被部分蒸发掉。
V4 的发布公告把 Flash 定位成在 "simple agent tasks" 上和 Pro 表现相当。这个限定词很重要。在更复杂的 agentic coding——SWE-bench Pro，那种测更难的多步场景——V4 Pro 拿了 55.4%，对面闭源领先者是 64.3%。这个 gap 意味着更多失败尝试、更多人工 review、更多 evaluation 循环。
延迟和稳定性
DeepSeek 的 API 主要 host 在中国境内。在高峰时段，latency spike 是真的。对于同步的 agent workflow，每一步都依赖上一步的那种，每三次调用里有一次延迟跳到 5 秒，加起来就很恐怖——不在 token 成本里，而在团队等待的 wall-clock 时间里。
我现在还不太确定怎么 quantify 这件事。但它感觉不可忽略。
Reasoning token 的盲区
还有一件事。V4 支持 thinking mode：model 在产出可见 response 之前会生成内部 reasoning token。这些 reasoning token 是要计费的。一个开了 thinking mode 的复杂多步 agent 任务，可能在产出 200 token 的回答之前，先生成 2,000–3,000 个 reasoning token。你按"看得见的输出 token"算的有效成本，可能比 output rate 显示的高 10 倍。
我自己也是在开始监控 response 里那个 completion_tokens_details 字段之后，才意识到这一点。你看到的和你付钱的，差距可能挺大。
DeepSeek V4 API 适合的场景
观察了一段时间以后，pattern 变得清楚了：
高频、对 cache 友好的工作负载。 如果你的 agent 在数千次调用里复用同一个稳定的 system prompt，context caching 可以把 V4 Flash 的有效输入价压到 $0.01/M 以下。Repository 分析、batch 代码 review、文档处理——这些都是天然契合。
实验和原型阶段。 当你还在搞清楚一个 agent 架构到底跑不跑得通的时候，$0.14/M 和 $5/M 之间的差，是 "让我来测一下" 和 "让我先想想测试值不值" 之间的差。
带 retry 预算的非关键 pipeline。 如果你的 workflow 能容忍偶发失败、并且你在里面写了 retry 逻辑，V4 Flash 给了你足够的余量去吸收这些 retry，而不会把预算烧穿。
任务定义清晰的 coding agent。 V4 Pro 的 Codeforces 评分 3,206、LiveCodeBench 拿到 93.5%，是 open-weight model 里最高的。对于竞赛风格的题、和边界清楚的 coding 任务，质量价格比很难被打败。
便宜的推理什么时候会误导团队
……这是我反复回到的那一段。
当你把"便宜的 token 价"误认成"便宜的总成本"。 如果你的 agent workflow 有 15% 失败率、而每个失败都会触发两次 retry 加一次人工 review，你"每次成功完成"的有效成本可能是原始 token 价的 3–5 倍。定价页不会告诉你这件事。只有你的日志会。
当你因为"便宜到可以直接跑"就跳过了 evaluation。 便宜的推理会制造出一种虚假的安全感。我见过这个 pattern：token 便宜到团队懒得去测输出究竟对不对了。代价不在 API 账单里——它在下游因此做出的坏决定里。
当你把促销价当成 baseline 假设。 V4 Pro 的 75% 折扣到 2026 年 5 月 31 日截止。之后，输出价从 $0.87/M 跳到 $3.48/M。如果你按打折价在搭生产基础设施，你需要一个"折扣结束之后怎么办"的方案。
当延迟比成本更重要。 那些需要次秒级响应的交互式 agent workflow，可能会发现 DeepSeek 不稳定的延迟——尤其从亚洲以外访问——比定价页暗示的更难绕开。Fireworks、DeepInfra 这种第三方 provider 用自己的基础设施提供 V4，延迟可能更可控，但他们会加一笔 markup，把成本差距收窄。
我可能这部分想多了。但我宁可现在就把它标出来，也不想之后才反应过来。
FAQ
应该用哪个 model ID——deepseek-chat还是deepseek-v4-flash？
直接用 deepseek-v4-flash 或 deepseek-v4-pro。老的 alias（deepseek-chat、deepseek-reasoner）目前会路由到 V4 Flash，但计划在 2026 年 7 月 24 日下线。
V4 Pro 的 75% 折扣是永久的吗？
不是。官方定价页写明它延长到 2026 年 5 月 31 日 15:59 UTC。之后恢复 list price，除非 DeepSeek 再发一次延期公告。
怎么把 cache 命中率拉到最高？
把稳定的内容——system prompt、tool definitions、few-shot examples——放在 message 数组的开头。变动内容放最后。在每一次 API response 里盯住 prompt_cache_hit_tokens，去测真实的 hit rate，而不是去假设。
做 agent 应该从 V4 Flash 开始还是 V4 Pro 开始？
从 Flash 开始。它便宜 12 倍，并且在大多数 benchmark 上和 Pro 只差几个百分点。只有当你自己的 evaluation 显示某一类任务上 Flash 的质量不够，再升到 Pro。
能自己 host V4 吗？
两个 model 都按 MIT license 发布，权重在 Hugging Face 上拿得到。V4 Flash 2840 亿参，多 GPU 配置下可行。V4 Pro 1.6 万亿参，需要相当规模的集群——大多数团队会用 API 来跑 Pro。
Previous Posts:
- 如果你正在把 token 成本和真实 agent 行为对照，这一篇直接接得上：Why Prompt Caching Reduces Cost — But Doesn't Create Agent Memory
- 想更深入看 agent 失败为什么会在 token 价之外复利累积？读这篇：Why Context Engineering Still Hits a Ceiling in Long-Running Agent Workflows
- 好奇 agent 基础设施会怎么改变 inference 价之外的总运营成本？看：Claude Managed Agents and the Real Cost of Long-Horizon Agent Runtime
- 如果你具体在评估 coding agent 用便宜推理的可行性，这篇配着读很顺：Claude Code Running Slow? The Real Bottleneck Usually Isn't the Model
- 想要一个更宏观的架构视角，看清究竟什么让 agent 能在时间维度上被复用：Agent Skills vs GEP Assets: The Difference Between Execution and Capability Reuse
