DeepSeek 涨价30倍仍是最便宜，第三方平台价格更低

这轮讨论的起点不是官方公告，而是第三方平台 OpenCode 工程师 dax 的一则发帖。他讨论 DeepSeek 即将涨价，并推测涨价很可能不是因为 DeepSeek 亏钱，而更像一种流量调控手段——通过提价压低需求、缓解过载。这一推测属于个人判断，未获 DeepSeek 官方确认。

dax 同时表示，自己找到了即便租赁 GPU 也能复现 DeepSeek 当前价格的方法，但随后透露这并非其自己团队复现，而是与其合作的另一支团队做到的。OpenCode 目前正在推动通过 OpenCode Go 在中国以外的地区使用低价 DeepSeek。这些说法同样停留在 source_claim 层面。

真正值得追问的问题由此浮现：如果第三方真能把价格压到官方之下，用户的实际支出会更低吗？

按 OpenRouter 列出的 DeepSeek V4 Flash 0423 供应商数据，DeepInfra 的输入和输出价格分别为每百万 Token 0.09 美元和 0.18 美元，而 DeepSeek 官方对应价格为 0.14 美元和 0.28 美元。按标价计算，DeepInfra 约为官方的 64%，便宜约 36%。GMICloud、百度千帆等其他第三方平台的报价同样低于官方。

这种低价并非亏本转卖。DeepSeek 已公开 V4-Flash 权重，许可证允许第三方使用、修改、再分发甚至商业销售，因此第三方厂商可以直接下载权重，在自己的 GPU 或其他加速器集群上运行模型，自己生产 Token。这与闭源模型必须向原厂购买 Token 的路径完全不同。

但价格可比性存在一个前提缺口：DeepInfra 明确标注自己的 V4-Flash 为 FP4，而 DeepSeek 官方开放的模型仓库包含 BF16、FP8 等，官方 API 究竟采用什么精度和推理策略，并未在价格页中完整公开。也就是说，两个价格未必对应同一种服务。

OpenCode Go 的定位是面向开放模型的低成本 AI 编程订阅服务，首月 5 美元、之后每月 10 美元，可调用 DeepSeek V4 Pro、DeepSeek V4 Flash、GLM-5.2、Kimi K3、MiMo-V2.5、MiniMax M3、Qwen3.8 Max 等多款模型。官方给出的限制为每 5 小时最多 12 美元使用额度、每周 30 美元、每月 60 美元。

OpenCode 官方表示，对于大多数模型，希望通过批量采购和预留 GPU 容量等方式，让用户以 10 美元订阅获得最高约 6 倍的模型使用价值。正是这种“10 美元换 60 美元”的折扣结构，让不少用户形成了直觉：通过 Go 调用 DeepSeek 应该明显比直接买官方 API 划算。

这里需要区分两件事：界面显示的“美元”额度与用户实际支付的现金并不直接等同。Go 本质上是固定月费换取内部使用额度，界面消耗数美元并不代表用户又付了这笔钱。因此，把界面消耗与实际扣费直接比较，可能夸大其真实现金成本。

一名开发者用真实 AI Coding 任务做了验证：选取一个包含 100 多个代码仓库的代码库，同时打开两个终端，一个走 OpenCode Go，一个直连 DeepSeek 官方 API，输入相同 Prompt、执行相同调查任务。

按其公布的结果，多个短任务中 OpenCode Go 显示的消费金额平均约为官方 API 的 4 倍，部分较长会话差距超过 10 倍，少数任务约 2 倍。他给出的结论是：短任务中 OpenCode Go 可能依然方便，但更长会话、尤其是多轮交互累计模型运行时间超过约 5 分钟时，通过 OpenCode Go 使用 DeepSeek 的最终成本可能明显高于直接调用官方 API。

这组数据来自单一开发者的自测，样本与方法未公开，结论的普适性不确定，应视为 source_claim 而非行业结论。

该开发者认为主要差异出在缓存命中率：DeepSeek 官方 API 在缓存处理方面明显优于 OpenCode Go，会话持续越久，OpenCode Go 累积的缓存未命中越多，成本被放大的倍数也越高。

他还提到一个细节：使用 GLM 时可以通过模型专属设置提高缓存命中率，例如设置模型不要重写之前的消息、不要删除前几轮推理内容，但 OpenCode 并未为 DeepSeek 暴露类似设置。

在价格对比表中，DeepSeek 官方的 0.0028 美元缓存价是列表中的最低价格。若能实现 95%、99% 的缓存命中，官方这一价格几乎相当于白送输入 Token。对 Coding Agent 而言，模型需要不断读取代码、调用工具、返回结果，再把已积累的大量上下文带入下一轮推理；历史 Prompt 一旦被缓存，重复上下文按极低的 Cache Hit 价格计费，前缀变化导致缓存失效时，几十万甚至更多历史 Token 就要按普通输入价重算。会话越长，这种差异放大得越快。

知乎答主“苏迟但到”进行了一次两万次实验、持续 3 天的测试，覆盖 DeepSeek、Kimi、智谱 GLM、MiniMax 以及通过 OpenRouter 调用的 OpenAI 模型。方法是每隔 40 分钟向每个模型发送 27 条随机请求，并在 1 分钟至 720 分钟（最长 12 小时）后再次发送相同内容，记录缓存是否仍命中。

结果显示，DeepSeek 无论工作时间还是非工作时间，缓存命中率始终保持 100%，即使间隔达 12 小时仍无明显失效。MiniMax 排名第二，非工作时间命中率约 90%、工作时间降至约 70%；Kimi 和 OpenAI 表现居中；GLM 最弱，2 分钟后命中率约 80%、3 分钟降至 50%、5 分钟仅剩 25%，几乎没有观察到超过 15 分钟的缓存存活。

该答主对 GLM 表现较弱给出两种解释：一是 KV Cache 更多依赖显存，缺乏向更低成本存储介质持久化的能力，导致缓存频繁淘汰；二是实际请求量过大，超过可缓存容量，加速旧缓存失效。这两种解释目前都只是推测。

需要强调的是，这组数据来自个人测试，属于 source_claim；而 DeepSeek 官方缓存命中率优势能持续多久，文章本身也认为值得思考。

V4-Flash-0731 没有扩充基础模型规模，仍是原来的模型架构，主要变化来自重新后训练以及 Agent 适配。也就是说，DeepSeek 在展示 V4 Flash 的 Coding Agent 能力时，把模型后训练与自己的 Harness 绑定在了一起。

有开发者反复测试得出，经 OpenCode 路由的 DeepSeek V4 Flash 上下文窗口其实只有 600k 左右，超过后 OpenCode 会作某种压缩截断，而官网是全量 1M 上下文。该开发者认为，很多人对 DeepSeek 能力评价差异很大，可能也有这个原因。

同一款 V4 Flash 在不同工具中的表现差异也被归因于 Harness：该开发者体验是，V4 Flash 在 Codex 中可与 Fable 5 基本打平，放到 OpenCode 环境中只能发挥大约一半的真实水平。差异体现在两方面——对问题的全面理解能力，以及长程任务中的记忆连贯性。在 Codex 中模型对代码读取和整体问题把握更好，长链条任务中仍能保持对最初目标的理解；在 OpenCode 中则更容易陷入局部细节，甚至在任务末尾给出并不成立的解决方案。

这些体验来自个别开发者，缺乏系统性评测。但一个成熟的 Harness 背后涉及消息路由、记忆管理、长短期记忆的优化与调用、工具调用等大量机制，这些能力往往来自长期反复的工程试验，相关 SDK 也不会完整公开实现细节。因此，围绕模型建立的 Harness 体系，可能成为比模型本身更深的一层护城河。