DeepSeek H200 测试挑战“便宜 80 倍”的说法
在 The Call Center Doctors 租用四块 Nvidia H200 GPU 检验该模型“便宜 80 倍”的说法后，DeepSeek 面临了一场实际成本测试。
这家咨询公司尝试为其编程智能体部署 DeepSeek V4.1 Flash，以替代通过 Claude Code 使用 Claude Opus 5.5。其原始测试发现，低廉的模型权重并不等于低成本的可用系统。
这项 DeepSeek H200 测试揭示了 token 定价与完成实际软件工作成本之间的差距。租用服务器能快速处理合成工作负载，但当团队回放真实的编程流量时，其经济性随之恶化。
按常规按需租赁价格计算，这台服务器的成本约为将同一工作负载发送至 DeepSeek 自有 API 的两倍。该咨询公司还得出结论：在按已完成的代码变更而非 token 价格衡量后，其现有 Claude Code 订阅仍具竞争力。
这些发现源自一家公司的工作负载、配置和内部测量数据，并非两款模型的通用基准。测试期间，DeepSeek 从未获得编写生产代码的权限，这限制了对已完成工作的直接比较。
不过，这项实验仍具意义，因为它使用的是已部署编程智能体的流量，而非孤立的基准测试。它测量了重复上下文、并发、延迟、运维工作，以及自主代码执行周围的安全边界。
核心反转很简单：DeepSeek 的低 API 费率依然颇具吸引力，但在高端 GPU 上自托管同一模型，对这一特定工作负载而言反而带来了更差的经济性。
这一结果促使买家在更换供应商前先定义“更便宜”的含义。较低的输出 token 单价或许重要，但它并不能说明吞吐量、可靠性、工程投入或成功交付。
DeepSeek H200 测试用工作负载测试取代了价格说法
这家咨询公司测试的是一套完整的推理系统，而不只是标注在一百万 token 旁边的数字。
The Call Center Doctors 为其他企业构建和运营呼叫中心环境，同时也使用编程智能体维护支撑这些工作的软件。
9 月 27 日，该公司租用了一台配备四块 Nvidia H200 加速器的服务器。它下载了 DeepSeek V4.1 Flash，并将该模型配置为通常连接 Claude Code 的智能体后端。
测试针对开放权重模型的两项常见说法。第一项认为，更低的 token 费率会直接转化为更低的运营成本。第二项则认为，企业可通过租用 GPU 并自行部署模型，避开服务商的利润空间。
DeepSeek 为买家调查这些说法提供了理由。其模型发布公告称，V4.1 Flash 是一款混合专家模型，旨在实现更快的推理和更高的吞吐量。
混合专家模型会针对每个 token 只激活网络的一部分。相比为每个请求运行所有参数，这种设计可以减少计算量。
DeepSeek 表示，其架构在处理输入和输出时激活的参数更少。它还表示，该模型的键值缓存所需高带宽内存少于上一代。
键值缓存存储先前 token 的中间注意力数据。复用这些数据，相比将整个序列作为新输入处理，能更低成本地处理重复上下文。
因此，该咨询公司选择了适合内存密集型推理的硬件。根据 Nvidia 的 H200 规格，每块 H200 配备 141GB 高带宽内存。
经过数次配置调整后，四块 GPU 的总容量足以加载并运行该模型。然而，服务经历五次启动后才稳定下来。
每次重启都需要再次加载模型。其中一项优化消耗了意外的内存，一次运行发生卡死，之后的配置则在更高并发下失败。
第五次尝试最终稳定下来，但并发上限较低，且大部分可用内存都已被占用。这一运维过程也成为经济性结果的一部分。
托管 API 会隐藏模型下载、内存分配、推理服务软件、容量规划和启动失败等问题。租用机器则将每一项任务暴露给客户。
稳定后，服务器在孤立的一分钟测试中表现良好。它处理缓存输入尤其迅速，并能在整台机器上每秒生成数千个 token。
这一结果最初支持了自托管的论点。四块 H200 具备可观的原始吞吐量，DeepSeek 面向缓存的设计也如预期般发挥作用。
问题出现在团队不再逐项测试单一 token 类别之后。其编程智能体并未发送由新输入、缓存输入和输出均衡构成的序列。
它们反复提供长对话、工具结果、文件上下文和此前的推理。每个请求的大部分文本都是模型已经见过的内容。
这一工作负载使测试脱离了理论输出速度。机器几乎必须将所有时间用于处理生成下一条回答前所需的上下文。
因此，这并非一场传统的模型竞赛，而是一次测试：具有吸引力的推理费率，是否能经受住智能体系统真实流量的考验。
为什么智能体上下文耗尽了四块 H200
编程智能体在阅读历史内容上的计算开销，往往远高于写出下一个有用 token。
该咨询公司 9 月的日志包含 3885 亿个读取 token 和 3.93 亿个写入 token。其中，3742 亿个输入 token 为缓存重读。
这意味着，超过 96% 的记录输入是此前上下文的重复。每生成一个输出 token，智能体大约提供 41.6 个新输入 token 和 1,042 个缓存 token。
平均每个请求会重读约 19.6 万个 token。这一模式很重要，因为缓存输入单个 token 的成本虽低，却并非完全不消耗计算资源。
租用服务器处理每个缓存 token 的速度快于处理每个新 token。然而，智能体提供的缓存 token 数量如此之多，以至于这些微小成本累积为主导工作负载。
该公司测得，每个缓存 token 大约占用 1.9 微秒的服务器时间。一个新输入 token 约需 60 微秒，而一个输出 token 约需 189 微秒。
将这些测量结果应用于生产流量构成后，得出的综合上限接近每秒 213 个输出 token。这是所有智能体共享四块 GPU 时的总结果。
据该咨询公司称，该公式与实时测试的误差在 3% 以内。这种一致性增强了工作负载模型的可信度，尽管尚未有独立第三方复现这一结果。
该公司估计，在这一流量结构下，这台机器每天可处理约 200 亿个 token。其 9 月最繁忙的一天则达到 510 亿个 token。
容量因此成为第二项限制。即使常规租赁经济性有利，一台服务器也无法承载记录到的峰值。
孤立测试与混合测试之间的反差，解释了为何标题式吞吐量可能具有误导性。仅测量输出时，这台机器每秒可生成超过 5,000 个 token。
真实智能体不能仅靠输出运行。它们必须持续提供指令、代码、文件、日志、工具响应和此前消息。
长时间运行的智能体会放大这种失衡，因为对话会不断增长。每次后续调用都可能包含大部分相同历史，加上少量新信息。
缓存折扣会降低这些重复 token 的费用，但不会消除内存带宽、调度延迟，或占用服务器带来的机会成本。
这种差异也令模型之间的比较更复杂。能力更强的模型或许能以更少尝试、更短提示词或更少审查完成任务。
如果使用相似的上下文并取得相当结果，成本更低的模型仍可能胜出；如果它需要更多重试、更长解释或另一模型的验证，则可能落败。
DeepSeek H200 测试并未完全回答质量问题，因为 DeepSeek 主要充当只读审阅者。它确实表明，仅凭输出 token 费率无法回答这一问题。
真正重要的指标取决于工作类型。批量摘要系统可能优先考虑总吞吐量，而交互式智能体还需要低延迟和可靠的工具调用。
编程工作更关心已完成的变更、审查时间、回归问题、安全性和开发者等待时间。token 效率只是影响结果的一个因素。
该咨询公司的日志为其他买家提供了一项有用警示。在选择硬件前，团队必须分析新输入、缓存上下文与生成输出之间的比例。
没有这一比例，基准测试就可能只优化工作负载中占比最小的部分。一项快速生成测试，对于大部分时间都在阅读的智能体或许说明不了什么。
DeepSeek 自托管输给了 DeepSeek API
最清晰的结果并非 DeepSeek 对阵 Claude，而是租用的 DeepSeek 基础设施对阵 DeepSeek 的托管服务。
按常规按需服务器费率计算，每日成本约为通过 DeepSeek API 处理相同流量成本的 2 至 2.4 倍。这一计算假设服务器持续满负荷利用。
实验中使用的竞价租赁价格低得多。在这一临时费率下，服务器只有在满负荷运行时才接近与 DeepSeek 托管服务持平。
竞价容量带来可用性方面的权衡。当需求变化时，服务商可收回这些容量，因此很难将其视为可靠的生产基础设施。
实验结束后几乎立刻就发生了这种情况。服务商在最终测试结束数分钟内收回了这台机器。
按需替代方案避免了中断风险，但削弱了经济性。它还会在模型加载、重启、等待流量或未达到最大利用率时持续收费。
DeepSeek 的托管 API 则将这些空闲时段分摊给众多客户。服务商可以批量处理请求、共享硬件资源，并以更大规模运营自己的推理服务栈。
其 API 价目表也区分缓存输入、新输入和输出。非高峰流量的费率低于工作日高峰流量。
这一安排为买家提供了另一种优化途径。灵活的批处理工作负载可以避开高峰期，而无需专用机器。
租用服务器没有相应的需求调整机制。无论智能体是否产出有用工作，其按小时计费都会持续进行。
这一比较并不能证明自托管始终不具经济性。企业可能拥有已折旧的硬件、协商到更低的容量价格，或能让多种工作负载维持稳定利用率。
大型部署还可能在内核、量化、路由和批处理调度方面进行优化，超出短期实验所实现的水平。DeepSeek 本身也邀请计划进行超大规模部署的企业讨论更多选项。
即使托管推理更便宜，隐私需求仍可能使本地运行变得合理。受监管的工作负载可能需要足以抵消直接计算成本的数据控制措施。
可预测的容量同样重要。需求持续的公司可能更倾向于控制自己的基础设施，尤其是在外部 API 存在限额或可用性风险时。
不过，这些优势需要稳定的机器、经验丰富的操作人员、监控、故障切换和安全控制。开源权重本身不会自动带来这些条件。
测试还揭示了专业能力成本。工程师必须先诊断内存消耗、启动失败、并发限制和服务行为，才能运行真正有用的工作负载。
这些人力成本并未计入简单的机器对比中。若将其纳入，短期自托管实验的结果会更不利。
这正是考虑部署 DeepSeek 自托管方案的企业应吸取的主要教训。相关的比较应是一个完整服务与另一个完整服务之间的比较。
模型权重只是其中一个组成部分。硬件租赁、闲置容量、编排、可观测性、事件响应、电力、存储和员工时间共同构成完整系统。
DeepSeek API 同样受益于与可下载模型相同的架构效率。它还受益于 DeepSeek 能够面向众多客户运营的基础设施。
自托管必须克服这两项优势。当 API 提供商拥有更高的资源利用率和更成熟的服务经验时，仅仅避免 API 加价并不够。
对于这一工作负载，自托管并未克服这些优势。开源权重方案带来了控制权，但 DeepSeek 云服务提供了成本更低的 DeepSeek 使用体验。
“便宜 80 倍”的说法比较了不同的购买模式
这一醒目的对比之所以站不住脚，是因为它将公开 API 费率与高频使用的订阅访问方式并列比较。
“便宜 80 倍”的说法是在特定假设下比较 token 费率。它并不能自动反映每位 Claude Code 用户的实际支出。
这家咨询公司通过订阅而非 Anthropic 按量计费的 API 使用 Claude。Anthropic 确认，符合条件的套餐为 Claude Code 提供订阅访问，但须遵守共享使用限制。
订阅和 API 面向不同的购买模式。订阅在既定限制内打包提供访问，而 API 则按实际计量的使用量收费。
该咨询公司表示，其订阅使用量相当于相对于公开 API 费率获得了大幅折扣。这一差异消化了理论上 80 倍差距中的大部分。
根据 9 月流量，该公司计算认为，DeepSeek API 的成本可能从略低于其 Claude 订阅，到高于其 Claude 订阅不等。使用量在高峰和非高峰费率之间所处的位置取决于时段。
报道结果还估计，若按 Claude 的公开 API 费率计费，账单将高得多。但这并不是该公司实际购买的产品。
当比较将每种产品都简化为名义 token 费率时，很容易忽视这种区别。同一模型可以通过订阅、企业合同、云平台或直接 API 销售。
每个渠道都有不同的限制与经济激励。订阅可能更适合稳定的个人使用，而 API 则提供可编程的规模化能力和细致的使用量核算。
企业合同可以加入协商后的容量、服务承诺或控制措施。自托管则以基础设施和运营责任取代供应商的服务利润空间。
没有任何单一费率能够涵盖这四种安排。买方应比较自己实际能够购买和运营的路径。
该咨询公司还计算了每项合并代码变更的成本。在测量期间，其 Claude 代理完成了 5,610 项已合并变更，其中 5 项后来被回滚。
该公司估计，DeepSeek 会需要额外的 token、重试，以及基于 Claude 的检查。在这些假设下，每项被接受的变更通过 DeepSeek 完成的成本会更高。
这一估算应谨慎看待。DeepSeek 并未执行相同的可写入任务，因此该研究无法观察其实际成功率或总 token 使用量。
如果更好的提示词、服务软件或代理设计改善 DeepSeek 的输出，这些假设可能过于严苛。如果审查发现更多缺陷，它们也可能过于乐观。
尽管如此，每项被接受变更的成本仍比每个输出 token 的成本更有参考价值。它将推理支出与能够通过审查的软件联系起来。
最佳衡量单位取决于工作流。客服团队可能衡量已解决的案例，而研究人员可能衡量经验证的发现。
当模型需要完成相近的工作才能达到这些结果时，低 token 费率依然具有价值。当能力、延迟或审查负担存在差异时，它的决定性就会降低。
因此，“80 倍”这一数字描述的是一种狭窄的比较，而非普遍适用的节省。Call Center Doctors 并未推翻 DeepSeek 公布的费率。
相反，它表明，当产品、工作负载和结果质量不同时，费率表算术可能失效。
安全问题阻止 DeepSeek 编写生产代码
这项实验最严重的限制，也是最重要的运营警告是：DeepSeek 从未完成预定的编码任务。
该公司原计划让 DeepSeek 用于编写代码的代理。但审查人员随后发现，生成的代码可能有途径逃离预期的沙箱。
沙箱是一种隔离执行环境，用于限制不受信任代码能够访问的资源。它应防止代理接触敏感文件、凭据、网络或管理权限。
其中一项被报告的弱点涉及共享临时目录中的设置文件。该公司认为，对其中内容进行操纵，可能使生成的代码以提升后的权限运行。
因此，这家咨询公司让构建代理保持离线。DeepSeek 仅通过 48 至 64 个只读审查代理运行。
这些审查代理检查了 2,377 个代码文件夹，并生成了 32 份漏洞报告。这一活动展现了有用的吞吐量，但并未测试自主实现能力。
该安全问题并未被描述为 DeepSeek 模型权重的缺陷。它涉及的是该咨询公司周边代理环境和执行控制措施。
这一区别很重要。任何能够生成命令的模型，都可能暴露隔离不充分的工具链中的弱点。
当代理获得文件系统和 shell 访问权限时，Claude、DeepSeek 或其他模型都可能产生不安全的操作。安全边界必须假定模型输出不可信。
因此，这项测试混合了两个不同问题。其一是 DeepSeek 推理的经济性。其二是该公司的代理沙箱是否已准备好支持可写入自动化。
只有第一个问题获得了直接的工作负载测量。第二个问题使原定的正面对比编码试验停止。
这无法有力证明 Claude 在同一实验中生成了更好的代码。Claude 在 9 月完成的工作属于历史生产数据，而 DeepSeek 的工作则是受限测试。
这也阻碍了对 DeepSeek 每项合并变更成本的公平测量。该模型从未获得生成变更并接受审查和部署的机会。
该公司援引公开编码基准来论证 Opus 具有能力优势。基准可以提供背景信息，但无法替代完全相同的内部任务集。
严谨的后续研究应为两种模型提供相同的代码仓库、工具、安全限制、提示词和验收测试。审查人员应始终不知道模型身份。
研究应记录成功变更、回归问题、重试次数、延迟、token 使用量、人工审查时间和安全违规情况。只有这样，才能直接比较总体交付成本。
尽管存在这一限制，取消部署仍带来一条实际教训：当执行层无法安全地向模型开放其预定工具时，基础设施成本几乎没有意义。
代理系统会扩大攻击面，因为它们将概率性的模型输出连接到确定性的操作。一条不安全路径的重要性，可能超过数千个廉价 token。
因此，企业应先测试隔离能力，再计算自主工作带来的节省。只读分析和可写入代理处于截然不同的风险类别。
安全也会影响经济性。更强的隔离可能需要一次性环境、受限凭据、网络控制、日志记录和审批检查点。
这些控制会消耗工程时间并增加延迟。它们还可能降低并发能力，或要求独立的基础设施。
推理费率最低的模型未必带来最低的安全交付成本。相关系统包括信任其输出所需的每一项控制措施。
DeepSeek H200 测试对 AI 买方意味着什么
下一轮比较应聚焦于被接受的工作、持续利用率和安全执行，而非单一 token 价格。
首先要关注的信号，是一次受控的可写入重跑测试。DeepSeek 需要使用此前与 Claude 相同的工具、代码仓库、提示词和验收标准。
如果它能以有限审查完成可比的变更，这家咨询公司的负面结论就会被削弱。如果重试和修正仍然很多，基于结果的成本论证就会更有力。
第二个信号是持续数周的利用率。当一台自托管服务器在全天的大部分时间里，实际需求都接近其容量时，它会更具吸引力。
Call Center Doctors 测得的峰值超过了一台机器的容量。但波动的流量仍可能让这些高价机器在峰值之外出现闲置期。
更长时间的测试应按小时报告利用率、队列深度、首 token 延迟、中断情况，以及用于加载或恢复的时间占比。
它还应区分缓存输入、新输入和输出。这些类别与内存带宽和批处理的交互方式不同。
第三个信号是 DeepSeek V4.1-Pro。DeepSeek 表示，其当前 Flash 架构将扩展至更大的模型，但尚未给出明确发布日期。
更强的模型若能以更少重试完成更多任务，可能改变经济性。它也可能需要更多内存，或带来更低的吞吐量。
买方应同时关注能力与服务要求。基准提升并不保证生产成本更低。
DeepSeek 当前取得的成果依然重要。其官方费率让高容量实验变得可及，而可下载的权重提供了部署灵活性。
这项测试并未抹去这些优势。它只是缩小了这些优势能够转化为节省的适用条件。
对于间歇性或不确定的需求，DeepSeek 托管 API 似乎比租用专用四 GPU 服务器更合理。它保留了较低 token 费率，同时不将基础设施运营转移给客户。
对于敏感数据、可预测的持续需求或专门优化，自托管仍值得评估。商业案例必须纳入人员、可靠性、安全和未使用容量。
Claude Code 提供的是不同的方案。它在订阅限制下打包提供模型访问、编码界面和由提供商运营的基础设施。
对于重度个人使用，这种打包方式可能优于基于 token 的比较。当组织需要可编程容量或集中控制时，它也可能变得限制重重。
因此，压力落在采购团队和工程领导者身上。他们必须停止将“API”“订阅”和“自托管”视为可互换的购买单位。
他们应从生产轨迹而非供应商示例开始。最有用的轨迹记录上下文长度、缓存命中、输出、延迟、失败情况和被接受的结果。
随后，团队可以通过竞争系统重放具有代表性的工作负载。测试应纳入成功演示之后真正重要的运营条件。
这些条件包括并发量、流量波动、重启、排队、模型更新、监控和恢复机制。安全测试必须在智能体获得写入权限之前完成。
结果指标应与组织目标相匹配。对于编程智能体，指标包括已合并的变更、缺陷、回滚、审查时间和完成耗时。
对于支持智能体，有效指标包括已解决的案例、升级处理、客户满意度和政策违规。对于研究智能体，经过验证的发现比生成的页面更重要。
DeepSeek H200 测试的价值在于，它向这一标准迈进了一步。它以真实的上下文分布和真实的基础设施，取代了抽象的速率比较。
它的局限性同样具有启示意义。较短的运行时间、单一组织、尚未完成的安全工作，以及不对等的生产环境访问权限，都使其无法得出具有普遍性的结论。
更恰当的结论应当更为有限：针对这一智能体工作负载，四张租用的 H200 并未击败 DeepSeek 的 API，而该 API 相较订阅服务也未展现出明显的 80 倍优势。
这已足以质疑过于简单化的说法，但还不足以否定 DeepSeek、开放权重模型或自托管推理。
在调整 AI 技术栈之前，应收集一周具有代表性的流量数据，并计算每个被接受结果的成本。随后，在启用安全控制措施的情况下重复进行比较。
应关注模型是否完成了同样的工作，而不是它最便宜的 token 看起来是否令人印象深刻。下一次 DeepSeek H200 测试应回答这个更困难的问题。
