文章摘要
近日有消息称DeepSeek或将涨价，推测是为调控流量、缓解服务器压力。第三方平台DeepSeek V4 Flash 0423版本定价低于官方，但实际使用成本因缓存命中率等因素而不同，官方API缓存处理能力更优。此外，第三方调用和官方服务在上下文窗口、模型性能表现等方面存在体验差异，未来AI编程产品竞争或聚焦Harness体系。

有第三方技术人士近日在社区发帖提及，DeepSeek或将迎来涨价。该人士表示，自己找到了通过租赁GPU复现DeepSeek当前定价的方式，并推测此次涨价并非因为运营亏损，而是针对过高的服务负载采取的流量调控手段——通过提价压低需求，缓解服务器过载压力。

不少开发者也印证了这一观点：V4 Flash版本的性价比优势过于突出，自7月底以来相关服务的调用量激增，服务器负载持续高位运行，所谓的峰谷定价根本不存在，全球各地的使用高峰完全重叠，全天都处于高负载状态。大模型领域的高智能、低成本与服务稳定性，目前仍是难以兼顾的三角难题。

对于第三方平台能够维持DeepSeek当前定价的消息，有业内人士评价，如果属实，将重新审视DeepSeek的基础设施团队实力——这支团队一直被认为是行业内的标杆存在。该发帖人士后续透露，这一复现方式并非来自其所在团队，而是与其合作的另一支团队完成的，目前OpenCode正推动通过OpenCode Go在海外地区提供低价的DeepSeek服务。

从第三方聚合平台的公开数据来看，DeepSeek V4 Flash 0423版本的定价存在明显差异：例如部分供应商的输入Token单价为每百万0.09美元，输出为每百万0.18美元，而DeepSeek官方的对应价格分别为0.14美元和0.28美元，第三方平台的价格仅为官方的64%左右，优惠幅度超过35%。其他多家第三方服务商的报价也均低于官方定价。

不过需要注意的是，第三方平台标注的V4-Flash多为FP4精度，而DeepSeek官方开放的模型仓库包含BF16、FP8等多种精度，官方API实际采用的精度和推理策略并未在价格页完整公开。由于DeepSeek已经公开V4-Flash权重，且许可证允许第三方使用、修改、再分发甚至商业销售，因此第三方厂商并非通过转卖官方API获利，而是直接下载权重后在自有GPU或加速器集群上运行模型，这与GPT、Claude等闭源模型完全不同——后者的第三方服务商仍需向官方购买Token才能转售。

不过，即便第三方平台的单Token标价更低，用户的实际支出未必比直接使用官方API更划算。有开发者通过真实的AI编程任务进行了对比测试：他选取包含百余代码仓库的代码库，分别通过OpenCode Go和DeepSeek官方API发起相同的代码调研任务，输入完全一致的Prompt。测试结果显示，在短任务中，OpenCode Go显示的消费金额平均为官方API的4倍；较长会话的差距甚至超过10倍，仅少数短任务的成本差距约为2倍。

该开发者日常主要使用Claude和OpenAI的订阅服务，每月单项支出约100美元。DeepSeek V4发布后，他开始通过官方API使用V4 Pro和部分V4 Flash处理小型代码调研、可观测性分析等需要快速结果的任务，先让模型搜索代码、读取文件、梳理问题，得到满意结果后再生成笔记，最终交给Claude或GPT完成正式开发。按照他的使用方式，即使进行大量工作，每月的DeepSeek API支出仍可控制在10美元以内。

有网友指出，OpenCode Go界面显示的“美元”消费额度，与用户实际支付的现金不能直接划等号。该服务本质是固定月费换取内部使用额度的订阅套餐，如果用户每月仅支付10美元，界面显示的数美元额度消耗并不代表额外支付了这笔费用。因此，将OpenCode显示的8美元额度消耗与DeepSeek API实际扣除的2美元直接比较，可能夸大了OpenCode Go的真实现金成本，但第三方平台定价更低仍是不少开发者的实际感受。

造成这一差异的核心原因在于缓存命中率。该开发者指出，DeepSeek官方API的缓存处理能力远优于OpenCode Go，会话时间越长，OpenCode Go的缓存未命中次数越多，最终的成本被放大的幅度也就越大。他总结道，对于短任务来说，OpenCode Go仍然便捷易用，但如果是超过5分钟的长会话，通过OpenCode Go调用DeepSeek的实际成本，反而会高于直接调用官方API。

该开发者还提到，使用GLM模型时可以通过专属设置提升缓存命中率，例如配置模型不重写之前的消息、不删除前几轮的推理内容，但OpenCode并未为DeepSeek开放类似的模型设置。对于Coding Agent来说，模型需要不断读取代码、调用工具、返回结果，并将大量积累的上下文带入下一轮推理，如果历史Prompt能够被缓存，后续请求中的大量重复上下文可以按照极低的缓存读取价格计费；一旦Prompt前缀变化导致缓存失效，数十万甚至更多的历史Token就需要重新按照普通输入价格处理，随着会话变长，这种差异会迅速放大。这也是为什么仅以“每百万Token多少钱”来衡量成本高低已经越来越不准确。

DeepSeek官方的缓存定价中，还有一项仅为0.0028美元每百万Token的缓存读取价格，如果能实现95%甚至99%的缓存命中率，输入Token的实际成本几乎可以忽略不计。有用户测试显示，DeepSeek确实能达到这一水平：有技术博主开展了为期3天、总计两万次的对比测试，覆盖DeepSeek、Kimi、智谱GLM、MiniMax以及通过第三方平台调用的OpenAI模型。测试方法为每隔40分钟向每个模型发送27条随机请求，并在1分钟到12小时后再次发送相同内容，记录缓存命中情况以排除系统负载波动的影响。

测试结果显示，DeepSeek的缓存命中率始终保持100%，即使间隔12小时也没有明显失效；MiniMax次之，非工作时段命中率约90%，工作时段降至约70%；Kimi和OpenAI表现居中；而智谱GLM的表现最弱，2分钟后命中率约80%，3分钟降至50%，5分钟仅剩25%，几乎没有超过15分钟的缓存存活。该博主推测，GLM表现较弱可能有两个原因：一是KV缓存更多依赖显存，缺乏向更低成本存储介质持久化的能力，导致缓存频繁淘汰；二是实际请求量过大，超过可缓存容量，加速旧缓存失效，但这两种解释目前都只是推测。

以第三方平台给出的统一缓存命中率口径计算，假设DeepSeek官方缓存命中率达到78.2%（实际水平更高），缓存价格仅为第三方的一成，其余价格相同，那么DeepSeek需要将Cache Hit和Cache Miss的价格全部提升约3倍才能与第三方平台基本持平；如果仅提高Cached Read价格而保持普通输入价不变，则需要提升约30倍才能持平。

这一优势源于DeepSeek的架构设计。其官方缓存文档披露了三种缓存前缀落盘机制：一是在每次请求的用户输入结束和模型输出结束位置自动生成缓存前缀；二是公共前缀检测，当系统发现多次请求存在共同前缀时，主动将这部分内容单独落盘，直接提升实际命中概率；三是针对超长输入输出，按照固定Token间隔主动生成缓存前缀单元，避免等待超长请求结束才能形成可复用缓存。不再使用的缓存通常会在数小时到数天后清除。

到了V4版本，官方采用Token-wise Compression + DeepSeek Sparse Attention（DSA）技术，进一步降低百万Token上下文的计算和内存成本，将100万Token上下文作为所有官方服务的标准配置。根据第三方团队的架构拆解，V4不仅共享Key/Value缓存，还会跨Token进一步压缩KV Cache，部分模式的压缩比可达128倍。在百万Token上下文场景下，估算的BF16 KV Cache约为9.62 GiB，而V3.2结构约为83.9 GiB，缩小约8.7倍；实际部署时使用FP4保存Indexer Cache、FP8保存Attention Cache，还能进一步将缓存占用压低约一半。

不过第三方调用和官方服务也存在体验差异。有开发者测试发现，通过OpenCode路由的DeepSeek V4 Flash上下文窗口仅约600k，超过阈值后会被压缩截断，而官网提供的是全量1M上下文，因此官方服务的能力更全面、性能更强。不少开发者对DeepSeek能力的评价存在分歧，或许也和这一因素有关。

V4-Flash-0731版本并未扩大基础模型规模，仅通过重新后训练和Agent适配实现了能力升级。这意味着DeepSeek在展示V4 Flash强大的Coding Agent能力时，实际上结合了两个关键因素：模型本身的后训练优化，以及DeepSeek自研的Harness框架。有开发者在实际使用中发现，同一款DeepSeek V4 Flash在不同的AI编程工具中表现差异明显：在官方适配的Codex环境中，其性能可以与主流模型基本持平，但在OpenCode环境中只能发挥约一半的真实水平。

这种差异主要体现在两个方面：一是对问题的整体理解能力，Codex环境下的DeepSeek V4 Flash对代码的读取和整体问题的宏观把握更好，不易陷入局部细节；而在OpenCode中，模型更容易纠结于局部细节，影响对整体任务的判断。二是长程任务的记忆连贯性，复杂软件开发任务包含大量关联问题，局部最优未必能带来全局最优，在OpenCode环境中，DeepSeek更容易在解决多个局部问题后偏离初始任务目标，甚至在任务末尾给出不合理的解决方案；而在Codex环境中，即使任务链条较长，模型仍能保持对初始目标的理解，不易偏离方向。

实际上，DeepSeek官方曾发布Codex接入文档，提供完整的models.json模型配置，帮助Codex更好地适配V4 Flash。这份配置暴露了不少Harness层面的适配细节：例如V4 Flash在Codex中被配置为支持并行工具调用、约104万Token上下文、95%的有效上下文窗口，还定义了apply_patch工具、Web Search等功能，甚至明确了长任务中的上下文压缩规则，即上下文过长时如何压缩历史内容并继续任务，而非从头开始。

这也让不少开发者将关注点从模型本身转向Harness体系。一个成熟的Harness涉及消息路由、记忆管理、长短期记忆优化与调用、工具调用等大量机制，这些能力往往来自长期的工程实践和反复优化，且相关SDK不会公开全部实现细节和技巧。因此，未来AI编程产品的竞争，可能不再仅仅局限于模型本身的智能水平，围绕模型构建的Harness体系，以及其中沉淀的消息路由、记忆管理和工具调用能力，或将成为比模型本身更深的竞争护城河。

有消息显示，过去48小时内DeepSeek的流量远超其他平台，来源涵盖多种客户端，并非仅来自OpenCode相关渠道。

以上内容不代表本平台立场，仅供读者参考