为什么同一模型的无服务器推理一致性会有差异

• 无服务器推理服务商针对每个模型做出大量未公开的基础设施决策，包括副本数量、量化、GPU 档次和批处理策略。这些决策都会直接影响你实际体验到的延迟与稳定性。

• 这些决策在很大程度上取决于模型的人气高低。热门模型始终有热备副本待命，小众或流量偏低的模型则更频繁地遭遇冷启动，获得的优化投入也更少。

• 同一模型在不同提供商之间的表现可能像完全不同的产品。在我们的基准测试中，DeepSeek V4 Pro 在一个平台上的变异系数（CV）为 21%，在另一个平台上为 710%，这导致了一致性相差 34 倍。

• 不存在一种适用于所有模型的‘最佳’提供商。哪些模型得到良好支持因平台而异，唯一可靠的办法是进行测量。

大多数开发者认为，如果一个模型在提供商的平台上被列出，它就会以标准、等价的方式被提供服务。事实并非如此。提供商会为每个模型做出多个决策，这些决策共同作用，产生您所观察到的延迟和一致性。

副本数量和热池大小

无服务器推理通过动态分配 GPU 容量来处理传入请求。对于流量持续且高峰的热门模型，保持多个活跃副本（已加载模型并准备好服务的 GPU 实例）一直处于空闲状态是合理的。当请求到达时，会立即路由到一个可用的副本。

非热门模型在非高峰时期可能没有任何热副本。当有请求到达冷模型时，提供商必须分配 GPU，从存储加载模型权重，初始化服务运行时，然后处理请求。对于大型语言模型，此过程可能需要 10 到 90 秒，具体取决于模型大小、存储位置和基础设施。这就是冷启动。

冷启动是我们后文讨论的高方差延迟模式的主要驱动因素。一个模型可能具有 0.4 秒的中位 TTFT，因为大多数请求会命中热副本，但其 95 分位数（p95）可能超过 6 秒，这是因为大约每二十个请求中就会有一次触发冷启动。中位数测量无法揭示这一点。

量化

同一套模型权重可以按不同的数值精度对外提供服务。全精度服务（BF16 或 FP16）内存占用最大，但能完整保留原始权重。FP8 和 INT8 能把内存占用削减约一半，对大多数任务而言质量损失微乎其微。INT4 量化能进一步压缩内存，但在对推理能力要求较高的基准测试上可能出现可测量的质量差异。

服务商会根据在每个模型上投入的优化力度来选择量化级别。热门模型通常经过精心的量化调优，在保证输出质量的前提下，挑选能让单卡吞吐量最大化的精度。而小众模型可能就用接入时最省事的那种精度来部署了。

量化从两个方面影响性能。更低的精度意味着同一块 GPU 能容纳更多副本（从而降低冷启动频率），也让矩阵运算跑得更快（在副本已预热的情况下缩短 TTFT）。但服务商很少对外公布某个模型究竟用了哪种精度。

GPU 硬件分配

GPU 之间的性能并不对等。H100、A100 和 AMD MI300X 在显存带宽和算力吞吐上差异显著。同一个模型跑在 H100 NVL 上和跑在 A100 80GB 上，相同负载下的 TTFT 可能相差 2 到 3 倍。服务商会根据需求、可用库存，以及该模型流量规模对应的经济性，把不同模型调度到不同档位的 GPU 上。

推理引擎与内核优化

模型实际如何执行，与其运行在什么硬件上同样重要。针对同一份模型权重，vLLM、TensorRT-LLM、SGLang 和自研内核会带来明显不同的吞吐与延迟表现。投机解码这类附加技术借助一个小型草稿模型，抢在主模型之前预测多个 token，能显著降低 TTFT，但需要专门投入配置工作。各家服务商在这些选项上各自为政，这正是同一个模型在不同平台上表现可能天差地别的原因。

请求队列的优先级与批处理

高负载时，服务商会把多个请求打包成批处理，以提高 GPU 利用率。热门模型流量稳定、可预测，批处理起来效率很高：请求按固定间隔到达，队列始终不长，批处理带来的额外开销也微乎其微。小众模型流量稀疏、突发性强，批处理效果就差得多。请求一个冷门模型时，它可能要排在热门模型的批次后面，由此增加的延迟与冷启动噪音几乎无法区分。

叠加效应

这些决策并非彼此独立。一个小众模型可能同时碰上所有不利条件：以保守的精度运行、部署在较旧的 GPU 档位上、没有启用投机解码、没有预热好的副本，批处理效率也不佳。每一项都会单独增加延迟，而它们还会层层叠加。结果就是：这样一个模型在简短的评测中可能表现尚可——哪怕就是在同一个平台上测出来的——但一到生产环境就表现失常。

无服务器推理提供商在微薄的 GPU 利润空间中运营。容量成本高昂，为 400 模型目录中的每个模型预分配热副本在经济上不可行。分配决策很简单：他们在产生稳定、高流量的模型上进行深度投资，而在大部分时间闲置的模型上减少投资。

目录规模会放大这种效应。当一个相对较小的提供商列出 400 个模型时，只有其中的一小部分拥有经过优化的、温暖的服务基础设施。其余模型虽然权重存在且可加载，但在低流量情况下使用它们的体验可能与使用得到良好支持的旗舰模型大相径庭。

重要的是，每个提供商独立做出这些押注。一个提供商可能在 DeepSeek V4 Pro 上进行了深度投资，而另一个提供商则对 Kimi K2.6 做了同样的投资。目录页在模型名称、每 token 价格、API 端点方面看起来完全相同，但背后的基础设施决策完全不同。一个模型在平台上可用并不能说明该平台对其支持程度如何。

我们在 NYC1 的 DigitalOcean Droplet 上使用流式基准测试工具、固定提示词以及 temperature=0 进行这些测试，以便将比较集中在提供商行为而非提示词方差上。每个模型‑提供商组合至少执行了 75 次并发度为 1 的顺序请求，已丢弃预热请求，并且测试分布在几个小时内，以便我们能够观察到典型和低峰时段的行为。

如果在并发度为 1 的情况下跨提供商运行结构化基准测试，测量首 token 延迟（TTFT），你会看到差异。与其只比较中位数，不如使用变异系数（CV%），即标准差除以均值，作为一致性的主要信号。低 CV 表示延迟可预测；高 CV 表示模型有时很快有时非常慢，这是冷启动和队列波动的特征。

发现一：同一个模型在不同服务商上的表现会截然不同

DeepSeek V4 Pro 是一款使用广泛、编码与推理能力都很强的模型。在我们的测试中，DeepSeek V4 Pro 表现最佳的服务商 CV（变异系数）仅为 21%，意味着延迟紧凑且可预测：TTFT 中位数为 0.39 秒，p95 为 0.57 秒。第二家服务商的 CV 高达 541%：中位数 0.55 秒，p95 达 6.3 秒。第三家服务商的 CV 更是达到 710%：模型完全相同，中位数 0.73 秒，p95 却是 6.9 秒。

如果开发者在一家服务商上评估完 DeepSeek V4 Pro，随后换到另一家部署，就会发现生产环境的延迟完全乱了套——而除路由之外，其他一切都没变。

发现二：不存在普适的“最佳”服务商

Kimi K2.6 讲的则是另一个故事。在一家服务商上，CV 高达 989%：中位数 0.35 秒，p95 达 5.98 秒。第二家服务商的 CV 为 1266%：中位数 0.43 秒，p95 为 1.70 秒，但极端离群值把标准差推高到了 5.4 秒。而在支持得最好的那家服务商上，CV 骤降至 102%：中位数 0.25 秒，p95 为 1.08 秒——稳定性约为另外两家平台的 10 倍。

在我们的测试中，对 DeepSeek V4 Pro 支持最好的服务商，就是这款模型的正确选择；而 Kimi K2.6 的正确选择，却是另一家服务商。这两个结论都必须靠实测得出，光看服务商目录页面是看不出来的。

发现 3：广度优先提供商需要更彻底的验证

列出数百种模型的小型提供商无法在所有模型上平均投入。基础设施经济不允许如此。精选目录意味着对支持对象做出有意选择。广泛目录则意味着相反的情况。许多模型被列出仅是因为它们可以加载，而非因为它们已经经过优化。

数据印证了这一点。以 Kimi K2.6 为例，广度优先提供商的 CV 基准分别为 989% 和 1266%。精选提供商的 CV 为 102%，大约只有前者的十分之一（更一致）。对于 DeepSeek V4 Pro，一家提供商投入较大，CV 为 21%；另一家未投入，CV 为 710%。

使用精选提供商时，模型被列出表明它经过有意准备，这是一个相当可靠的信号。使用广度优先提供商时，模型被列出几乎无法说明其背后支持质量。无论模型拥有三个温暖副本还是零个，目录页面看起来完全相同。

这并不意味着广度优先提供商整体上更差。对他们明确投入的模型，他们往往是可选的最佳方案。但其目录中支持质量的差异更大，这也意味着你需要承担更高的验证负担。你不能仅因为模型出现在 400 模型目录中就假设它得到良好支持。你必须自行检查。

良好基准测试通常需要几个小时才能完成。下面是一种最小化方法，能够让你在构建之前了解模型与提供商组合所需要知道的一切。

测什么指标：首 token 时间，而非端到端延迟。TTFT 能单独反映模型是否已预热就绪，且不受生成长度影响。它是衡量基础设施支持程度最直接的信号。

发多少请求：至少 75 次。十到二十次只能看出中位数，看不出尾部。冷启动出现的概率本身不高，20 次的测试很可能完全错过；而 75 次测试下，只要模型容易冷启动，你几乎必然会碰上一次。

提示词保持一致：要么使用能准确反映你实际用例的提示词，要么在所有请求中统一使用一条固定的短提示词。这样能把提示词长度带来的波动从结果中剔除，让跨服务商的对比保持干净。

请求间隔：请求之间隔几秒发出，以免因为请求恰好被批量合并处理而得到虚好的成绩。你要观察的是模型在典型单请求条件下的表现，而不是持续吞吐能力。

算哪些指标：TTFT 中位数、p95 TTFT、标准差和 CV%。中位数与 p95 结合起来，能同时反映正常体验和长尾表现；而 CV% 是跨服务商比较一致性时最有用的单一指标。

CV% 阈值速查：

• CV < 40%：支持良好，服务商已对该模型做好预热和优化。
• CV 40-100%：存在一定波动，对延迟不敏感的工作负载可以接受。
• CV > 100%：说明正在发生冷启动，请评估 p95 对你的用例是否可接受。
• CV > 300%：对延迟敏感的应用来说，应视为在该服务商上不具备生产可用性，考虑改用专用端点。

测试时机很重要：高峰和非高峰时段（清晨、周末）各跑一次测试。模型流量最低谷时，冷启动表现最糟。在工作时间测出的结果可能虚好，因为其他用户的请求一直在让模型保持热身状态。

这是否意味着 Serverless 推理不可靠？

并非一概而论。对于流量稳定的成熟模型，特定服务商上的 Serverless 推理可以非常可靠。可靠性隐患只出现在服务商没有做这类投入的模型上，与该模型在其他平台支持得多好毫无关系。

怎样才能彻底避免这个问题？

专用端点通过为您的模型提供预留的 GPU 容量来消除冷启动风险。只有在流量持续且可预测的情况下，其经济性才成立。专用容量无论使用与否，成本相同，但延迟的可预测性是完整的。如果您已经确定想要在生产环境中使用的模型，那么在最能支持该模型的提供商上使用专用端点是最可靠的途径。

模型目录最大的提供商是否提供最佳支持？

不。目录大小与平均支持深度呈反比关系。列出 400 个模型的提供商不可能在所有模型上平均投入。更小、更精心策划的目录往往反映出对哪些模型提供良好支持的刻意选择。目录大小反映了广度，而只有测量才能揭示深度。

我应该为所有模型使用同一个提供商吗？

不一定。正如 DeepSeek V4 Pro / Kimi K2.6 的反转所示，不同提供商在不同模型上进行了投资。如果您在生产环境中使用多个模型，每个模型的最佳提供商可能不同。按模型将请求路由到不同提供商会增加架构复杂性，但对于提供商支持差异较大的模型，延迟和可靠性的收益可能非常显著。

无服务器推理目录并不是等效支持模型的平列表。它们是分层系统，每个提供商选择投资的模型将获得温备副本、优化量化和专门的工程关注，而其他模型则共享剩余的容量。这些层级是隐式的、未文档化的，并且在每个平台上都不同。

实际后果是，模型评估和提供商评估是两个独立的决策。您可以在任何提供商上仅用少量请求评估模型质量。但在将模型和提供商组合投入生产之前，您需要特别测试其一致性，包括 p95 延迟，而不仅仅是中位数，跨足够多的请求以暴露冷启动行为。

这是一个相对较短的实验。本文中的基准测试只需几小时即可运行，并揭示出若在生产环境中调试将需要几天时间的差异。在基于它们构建之前，请先运行这些数字。

• 无服务器推理的关键指标

• LLM 推理优化入门

• LLM 推理优化：从量化到投机解码