第三方平台 OpenCode 工程师 dax 近日发帖讨论了

Dax 的猜测与很多网友感受一致。“这波主要还是 V4 Flash 整体性价比过于爆炸了,导致 0731 以来东大西大两边都在猛蹬,服务器给蹬冒烟了,什么峰谷定价,不存在的好吧,你这边的谷刚好就是那边的峰,24 小时全是高峰。所以大模型领域,高智、低价和服务的稳定性目前来讲还是个不可能三角。”有网友在知乎上说道。
对于 OpenCode 可以维持
随后,dax 透露这并不是他们自己团队复现的,而是与其正在合作的另一支团队做到的。OpenCode 目前正在推动通过 OpenCode Go 在中国以外的地区使用低价
第三方 Token 更便宜,但花的钱仍比官方多
OpenRouter 目前列出的

价格对比表,来源:OpenRouter
不过需要注意的是,DeepInfra 当前明确标注自己的 V4-Flash 为 FP4,而
这与闭源的 GPT、Claude 完全不同。第三方要卖 Claude,本质上通常仍然要向 Anthropic、AWS Bedrock 或 Google Vertex 购买 Claude Token。但第三方卖
但把价格与官方打平甚至更低后,用户花的钱会更少吗?
以 OpenCode Go 为例,其定位为面向开放模型的低成本 AI 编程订阅服务,首月价格 5 美元,之后为每月 10 美元,目前可以调用
正是“10 美元换 60 美元”让不少用户形成了一个直觉:既然 OpenCode Go 购买模型资源的实际折扣如此高,那么通过 Go 调用
但事实并非如此。
一名开发者用真实 AI Coding 任务做了一次验证。他选取了一个包含 100 多个代码仓库的代码库,希望模型调查并理解其中某一特定领域的系统知识,然后同时打开两个终端,一个使用 OpenCode Go,一个直接连接
按照其公布的测试结果,在多个短任务中,OpenCode Go 显示的消费金额平均约为官方
这名开发者表示,他日常开发主要使用 Claude 和 OpenAI 订阅服务,每项月支出约 100 美元。
不过有网友指出,OpenCode Go 界面里的“美元”与用户钱包里的美元,并不能直接画等号。其认为,Go 本质上是一个固定月费换取内部使用额度的订阅套餐,如果用户每月实际只支付 10 美元,那么界面显示消耗了数美元模型额度,并不意味着用户真的又支付了这笔钱。因此,将 OpenCode 显示的 8 美元额度消耗与
DeepSeek 的低价护城河
“主要差异似乎出在缓存命中率上。”该开发者表示,“
最终他得出结论:对于短任务来说,OpenCode Go 可能依然很方便。但如果是更长的会话,尤其是多轮交互累计的模型运行时间超过大约 5 分钟,那么通过 OpenCode Go 使用
该开发者还提到了一个细节:使用 GLM 时,他可以通过模型专属设置提高缓存命中率,这类设置有点类似于配置 temperature 或其他请求参数。具体来说,可以设置模型不要重写之前的消息,也不要删除前几轮中的推理内容。但是,OpenCode 并没有为
对于 Coding Agent,模型需要不断读取代码、调用工具、返回结果,然后将已经积累的大量上下文再次带入下一轮推理。如果历史 Prompt 能够被缓存,后续请求中的大量重复上下文就可以按照极低的 Cache Hit 价格计费;一旦 Prompt 前缀发生变化导致缓存失效,几十万甚至更多历史 Token 就可能重新按照普通输入价格处理。随着会话越来越长,这种差异会迅速放大。
这也是为什么现在单以“每百万 Token 多少钱”来衡量成本高低,正在变得越来越不准确。
在上面价格对比表中,真正值得注意的是
知乎答主“苏迟但到”,进行了一次两万次实验、持续 3 天的测试,覆盖
结果显示,
该答主认为,GLM 表现较弱可能有两种原因:一是 KV Cache 更多依赖显存,缺乏向更低成本存储介质持久化的能力,导致缓存频繁淘汰;二是实际请求量过大,超过可缓存容量,从而加速旧缓存失效。不过,这两种解释目前都只是推测。
那么,我们以 OpenRouter 给出的统一口径下的缓存命中率来计算,假设

来源:OpenRouter
这种优势得益于
最新官方缓存文档披露了其三种缓存前缀落盘机制。第一种是在每次请求的用户输入结束位置和模型输出结束位置自动生成缓存前缀;第二种是公共前缀检测(Common Prefix Detection),如果系统发现多次请求存在共同前缀,会主动把这部分公共前缀单独落盘;第三种是针对超长输入和输出,按照固定 Token 间隔主动生成缓存前缀单元,避免必须等到一个超长请求结束后才能形成可复用缓存。其中,“公共前缀检测”方式可以直接提高实际命中概率。而不再使用的缓存一般会在数小时到数天后清除。
到了 V4,官方采用“Token-wise Compression +
根据 vLLM 团队对 V4 架构的拆解,V4 不仅共享 Key/Value,还会跨 Token 进一步压缩 KV Cache,其中一种模式大约压缩 4 倍,另一种可达到约 128 倍。在百万 Token 上下文下,其估算的 BF16 KV Cache 约为 9.62 GiB,而 V3.2 结构约为 83.9 GiB,缩小大约 8.7 倍;实际部署时又使用 FP4 保存 Indexer Cache、FP8 保存 Attention Cache,还能再把 Cache 占用压低大约一半。
但这个优势能持续多久,或许也是一个值得思考的问题。
今天,dax 发帖子称,过去 48 小时里,

不过,第三方和官方在质量上也会有差异。
有开发者反复测试得出,经 OpenCode 路由的
Harness 或比智力更重要
V4-Flash-0731 没有扩充基础模型规模,仍然是原来的模型架构,主要变化来自重新后训练以及 Agent 适配。也就是说,
该开发者在实际使用中发现,同一款
这种差异主要体现在两个方面。首先是对问题的全面理解能力。在 Codex 中,DeepSeek V4 Flash 对代码的读取以及对整体问题的宏观把握明显更好,不容易出现只关注局部问题、忽略整个系统的情况。相比之下,在 OpenCode 中运行时,模型更容易陷入局部细节,影响对整体任务的判断。
第二个差异则出现在长程任务中的记忆连贯性。复杂的软件开发任务通常包含大量彼此关联的问题,局部最优解并不一定意味着全局最优。一个局部问题得到解决后,可能引发更多全局问题,最终使 Agent 不断在不同方案之间循环,甚至在任务末尾给出实际上并不成立的解决方案。开发者表示,这类问题在 OpenCode 中的 DeepSeek 上仍然较为常见。
但在 Codex 中,DeepSeek V4 Flash 却很少出现类似情况。即使任务执行链条已经很长,模型仍然能够保持对最初目标的理解,不容易因为连续解决大量局部问题而偏离整个任务方向,可以说是“走得再远,也不会忘记为什么出发”。
实际上,DeepSeek 官方此前有发布一份 Codex 接入文档,直接提供了一整套 models.json 模型配置,让 Codex 知道应该怎样“驾驭”V4 Flash。
这份配置实暴露出了一些 Harness 层面的适配信息。例如 V4 Flash 在 Codex 里被配置为支持并行工具调用、约 104 万 Token 上下文、95% 的有效上下文窗口,并定义了自由形式的 apply_patch 工具、Web Search 等,文档甚至明确了涉及长任务中的 compaction 行为,也就是上下文过长之后如何压缩历史、怎样在压缩后继续任务而不是从头开始等。
这也让该开发者把关注点从模型本身进一步转向 Harness。一个成熟的 Harness 背后涉及消息路由、记忆管理、长短期记忆的优化与调用、工具调用等大量机制,这些能力往往来自长期、反复的工程试验和优化,而且相关 SDK 并不会完整公开所有实现细节和技巧。
因此,在其看来,未来 AI Coding 产品之间的竞争可能不再只是模型智力高低。围绕模型建立起来的 Harness 体系,以及其中沉淀的消息路由、记忆管理和工具调用能力,可能成为比模型本身更深的一层护城河。
参考链接:
https://openrouter.ai/deepseek/deepseek-v4-flash-20260423?utm_source=chatgpt.com#providers
https://www.reddit.com/r/DeepSeek/comments/1uyvmp4/the_opencode_go_is_cheaper_than_deepseek_api/
https://x.com/caolei1/status/2085348596996526486/photo/4
https://zhuanlan.zhihu.com/p/2035737726952194774
https://api-docs.deepseek.com/zh-cn/guides/kv_cache/?utm_source=chatgpt.com
https://github.com/vllm-project/vllm-project.github.io/blob/main/_posts/2026-04-24-deepseek-v4.md?utm_source=chatgpt.com
https://x.com/ivanalog_com/status/2085147881569177834

