DigitalOcean Serverless Inference的多模型合成：成本、延迟及何时值得

• 成本：根据配置不同，范围为 13× 到 93×，我们所使用的配置为 35× 我们发布文章中的配置每次调用成本为 $0.1928，而单独使用 GLM-5.2 的成本为 $0.0055，大约是单个前沿模型的 26×。
• 延迟：中位数 216秒，观测到的最大值为 19分钟 大约是单次模型调用的 7.6×，且尾部延迟超过了 600秒客户端超时所能看到的范围。
• 分歧完全取决于任务：0% 对比 64% 在提供的证据决定答案的任务中，四个模型从不产生分歧；而在证据不足以决定答案的任务中，有 64% 的任务出现分歧。
• 合成的答案通常与裁判模型自身的答案一致：86% 当小组成员真诚地存在分歧时，最终答案有 6 次出现在裁判模型的单独立场上（共 7 次）。它在所有任务中有 5% 的时候与单个小组成员的答案不同。
• 发布配置是我们测试过的最不可重复的东西：82% 当同一问题被问三次时，其一致性低于单个模型（89%），并且在未确定的任务上表现更差（72%），这正是您会使用它的场景。
• 所有三个预设都运行双模型小组，而不是文档所暗示的递增小组规模，且它们中没有一个设置裁判。
• 小组会静默失败。 在四模型调用中有 23% 的时候小组成员掉线，在 quality 预设的调用中有 32% 的时候掉线，API 每次都返回一个普通完成。

这并不使合成变得无用。它使其变得狭窄。以下是证据。

在所有 18 个可比较的任务中，分歧率为 39%。GLM-5.2 对同一问题提问三次，与 它自身 的分歧为 16%。差距 — 23 个百分点 — 是由模型选择而非抽样方差导致的分歧。

因此，模型多样性是真实存在的。它并不是一种可以在不说明你所问的问题的情况下直接引用一个数字的属性。0% 与 64% 之间的差距并不微妙，完全取决于任务是否具有确定的答案。

我们通过艰难的方式学到了这一点。一次早期的不完整运行因客户端超时而丢失了大部分无法确定的任务，并报告了 17% 的分歧，相对于 17% 的噪声基线 — — 这本会支持相反的结论：即模型多样性没有贡献。相同的模型、相同的提示、相同的代码。只有任务组合不同。

这就是该工具变得棘手的地方。

将这些放在一起看。在大多数未确定的任务上存在真正的分歧。裁判能看到所有这些。返回的答案几乎总是与裁判模型独立给出的答案一致。将 Kimi-K2.6 加入由 GLM-5.2 评判的小组中，在十九个任务中有一个任务的最终答案偏离了 GLM 的独立答案。

我们应该提出的一个注意点是：未进入小组的not裁判也有 57% 的时间（4/7）与其自身的独立答案匹配，而三人小组的随机基准大约为 33%。因此，这部分可能是模型在趋同于可辩护的答案，而不是裁判更倾向于自己的推理。入组/未入组之间的差距为 29 个百分点（各 n=7）——方向性明显，但尚未定论。

角色级别的 token 数据暗示了为什么小组内部的争论比名称所暗示的要少。小组席位的工作量差异巨大。在相同的任务上，openai-gpt-5.6-sol 作为小组成员使用了 709 个输入 token 和 156 个输出 token，而 Kimi-K2.6 使用了 37,558 个输入 token 和 5,301 个输出 token。在一种配置中，GLM-5.2 作为小组成员读取了 964 个输入 token —— 仅略多于问题。一个四模型小组通常由一到两个模型进行分析，其余模型返回快速意见。

而且关键的是：任何分歧都不会到达您的应用。 API 返回一个普通的补全。面板输出不会被暴露。在事件回顾中，模型之间的分歧可以说是系统产生的最有用的东西，但您无法看到它。

询问相同配置对同一问题三次并比较答案。启动小组的一致性低于单模型——并且在未确定任务上差距会扩大，这正是您会部署它的地方。

这并不神秘。合成增加了三个随机阶段：小组采样、裁判选择和合成重写。移动部件越多，方差越大。一个注意点：四模型小组在75次调用中有17次丢失了小组成员，因此其表面的稳定性可能部分源于小组成员减少导致争论减少。

如果您因为需要可重复的输出而选择方法，根据此证据，小组是错误的工具。预设或单模型更稳定。若要查看跨提供商而非跨合成配置测量的单模型运行间一致性，请参阅我们的独立研究：无服务器推理一致性 —— 此处的基线默认仅为DO，因为该主题是单一DO功能。

相较于前沿单模型基准，启动配置的成本大约是 26×。价格是 2026-07-28 的快照，来源于 无服务器推理定价，包含缓存读取费率；网络搜索按请求计费，与 token 分开，没有基于 token 的估算会显示这一点。

按顺序测量，没有其他任务在进行：中位数为 216 秒，而单次高努力 GLM-5.2 调用在相同任务上为 28.5 秒 — — 7.6×。一次答案需要三分半钟。

尾部值得单独一段。我们的首次完整运行使用了 600 秒的客户端超时，且观察到的最长调用都刚好低于此值：592s、594s、599s。它们并不慢，而是被截断。将超时提高到 1,500 秒后，揭示了在 balanced 预设上的最大值为 19 分钟，以及在四模型低努力小组上的 17.5 分钟。测得的尾部长度仅取决于你允许调用运行的时间，而我们的测试曾隐藏了一个因子为二的值。

您不需要时序数据就能知道原因。合成调用必须等到最慢的小组模型完成后才能返回，然后评审读取每个小组输出，最后合成器写出答案。这相当于在小组上取 max()，随后是两个串行阶段。

预设的构成没有文档记录。我们是从响应中各角色的使用情况推导出来的。

由此得出三点，其中两点出人意料。

所有三个面板都恰好包含两个模型。 文档将quality描述为最大的面板配置。在我们的运行中，该档位改变的是模型档次，而非面板大小。

成本是单调递增的；工作量则不然。 balanced比quality多消耗63%的令牌数，但成本却低三分之一。高级档之所以昂贵，是因为评审团中有哪些模型，而不是因为它做了更多工作。

没有预设会设置评审模型。 在所有三种情况下，都是由你的顶级model进行评审。如果你想要不同的评审模型，请自己在工具对象上设置model。

有一个我们无法解释的异常现象。balanced预设与我们手工构建的发布配置使用相同的面板和相同的评审模型，但成本却高出67%，可复现性高出14个百分点，而且其评审模型读取了37,449个输入令牌，而后者仅为16,181个。有某种东西向该评审模型提供了超过两倍的证据。我们发现一次quality预设调用在一个无需查询的自包含问题上发起了14次网络搜索，因此检索是一个合理的候选原因——但原本可以证实该假设的分支没有产生可用数据，原因在于下文所述的搜索工具缺陷。这仍然是一个悬而未决的问题，而非一项确定的发现；一旦该缺陷被修复，这将是我们最先重新运行的项目。

• 面板成员在 75 次四模型调用中失败了 17 次（23%），在 25 次 quality 预设调用中失败了 8 次（32%）。每次都返回了正常完成。您的应用永远不会知道它所付费的面板实际上运行不足。
• 输出格式降级：每个单模型臂在 100% 的时间内返回了我们请求的预告片格式。合成臂在 balanced 预设调用中丢失了 13%，在低努力四模型调用中丢失了 9%，在四模型调用中丢失了 7%。合成器会用自己的语言重写最终答案。如果您依赖结构化输出或 JSON 模式，请进行测试。
• 我们尝试的调用中有 128 次彻底失败并被排除，大约占尝试的 15%。这个数字不是合成可靠性指标，也不是无服务器推理可靠性指标：这些失败几乎全部源于服务器端网页搜索工具中的一个单一错误，我们已经报告了该错误。未调用搜索的调用完成率我们没有收到投诉。该错误也是为什么预设部分中启用搜索的比较臂未返回任何可用数据的原因，如果您计划在今天的合成调用中启用搜索，这一点值得了解。

我们的发布文章报告称，GLM + Kimi 小组在质量方面优于前沿模型，成本大约只有其一半，这是在 100 项深度研究基准测试中测得的。两个结果都是正确的，原因在于任务形状。

在深度研究中，前沿单模型也会消耗非常大的 token 量，因此它与小组之间的成本比率被压缩，小组确实可以在价格上获胜。在有限决策任务中，单次调用大约为 1,492 个 token，而合成调用大约为 95,395 个 token。经济学完全倒转。

已发布的数字在其测量的工作负载上是真实的。本文测量的是不同的工作负载并得出了不同的结论，这是您所期望的。如果您正在评估该功能，问题不是哪个结果正确 — — 而是哪种工作负载与您的相似。

对于最后一行，算术简单到可以在心里计算：

worth it when:  P(single model is wrong) × cost of being wrong
                 >  (N − 1) × cost per call

一个每月决定十次、价值4万美元的供应商承诺，以数量级超越了该基准——每月2美元的额外推理成本相对于五位数的下行风险。而一个每天处理两百万请求的分类端点则不然，且差距甚远。

我们并未衡量答案质量。判断者的自我偏好基于每个分支的七个任务。难度标签是我们在运行前编写的，而非事后发现——尽管0%对64%的差异表明它们捕捉到了某些真实的东西。面板构成是根据使用元数据推断的，因为面板输出并未公开。一个提供商、一个价格快照、一个处于公开预览中的功能。排除了128次调用，几乎全部归因于网络搜索工具的错误，而非综合过程或平台。而且我们的主要发现在不完整运行和完整运行之间发生了显著变化。

公开面板输出，或至少一个分歧信号。 这是我们主要的诉求，上述数据就是论据：在大多数未确定任务上确实存在分歧，而调用方却得不到任何信息。

呈现部分面板故障 在响应中，而不是在三分之一个面板未运行时返回正常的完成结果。

记录预设构成，并调和quality描述与其双模型面板。

保留调用方的输出格式 贯穿综合步骤。

多模型综合是否让答案更准确？ 我们不知道，这项研究也无法告诉你答案。我们衡量的是成本、延迟、一致性和可复现性，而非质量。我们能说的是，在95%的任务中，综合答案与单个小组成员返回的答案完全相同——因此，无论存在何种准确性提升，都必须来自答案发生变化的5%的情况。

测试工具、25 个任务的语料库、配置集和分析脚本均可在 github.com/Jameshskelton/fusion_test 获取，同时还包括本文所依据的原始结果。根据第一个发现，最关键的变量是你自己的任务组合——因此，这个实验的有用版本是在你自己的工作负载上运行的版本，而不是在我们的工作负载上运行的版本。

模型综合文档：使用模型综合工具

无服务器推理文档：使用无服务器推理

定价：无服务器推理定价详情

已经在使用 OpenAI API，并想针对 DO 复现此实验？该端点与 Chat Completions 兼容：从 OpenAI API 迁移到 DigitalOcean 无服务器推理。