设想一下，你正在为应用挑选一个 LLM。你花了大量精力研究哪个模型最适合你的场景，可能还会在沙箱里用 DigitalOcean 无服务器推理 先跑跑看，发现效果不错，然后就选了另一家供应商来把这个模型集成到你的应用里。结果一推到生产环境，模型的准确率、首 Token 延迟 (TTFT) 和吞吐量全都不如你预期。明明是同一个模型，到底哪里出问题了？
答案是：模型在不同平台上享受到的待遇是不一样的。一家平台可能会把最好的 GPU 押在一组模型上，而另一家则会把最好的硬件资源投给另一组完全不同的模型。即使平台上架了这个模型，它背后也未必有能让它扛住生产流量的资源配置。每一个 API 端点的背后，供应商都在做一系列基础设施决策：比如要保持多少个副本处于热启动状态、以什么精度来跑模型服务、分配到哪个 GPU 层级、以及如何排列请求队列的优先级。这些决策几乎从不会被写进文档，而且不同供应商之间、甚至同一供应商的不同模型之间，差异都非常显著。
这篇文章会讲清楚供应商到底控制了哪些变量、为什么模型的热度会左右这些决策，以及最重要的一点——在把某个模型和供应商的组合钉死在生产环境之前，如何自己动手去测。
文中的基准测试数据来自我们为验证这些模式而做的内部测试。供应商的名字被隐去了，但方法论描述得足够详细，你完全可以用同样的方式自己去复现一遍。
本文核心要点
- 无服务器推理供应商会针对每个模型做出大量未公开的基础设施决策，包括副本数量、量化精度、GPU 层级和批处理策略。所有这些都会直接影响到你感受到的延迟和一致性。
- 这些决策在很大程度上取决于市场对模型热度的感知。热门模型能一直保持热启动，而小众或低流量的模型则会触发更多的冷启动，并且得到的优化投入也更少。
- 同一个模型在不同的供应商那里可能表现得像是完全不同的产品。在我们的基准测试中，DeepSeek V4 Pro 在一家平台上的变异系数 (CV) 是 21%，而在另一家平台上却高达 710%，这意味着它的一致性差了 34 倍。
- 没有哪家供应商能通吃所有模型。哪些模型获得了更充分的资源保障，完全看平台，而唯一靠谱的发现方法就是自己动手去测。
供应商控制的关键变量
大多数开发者想当然地认为，只要一个模型被列在供应商的平台上了，它就是在以一种标准、对等的方式在提供服务。事实并非如此。供应商为每个模型做的一系列决策会叠加在一起，最终造就了你观察到的那种延迟和一致性表现。
副本数量与热池规模
无服务器推理的工作原理是动态分配 GPU 容量来处理进来的请求。对于那些流量稳定且量大的热门模型，平台有动力去保持多个在线副本（就是已经加载好模型、随时可以接手请求的 GPU 实例），让它们始终在后台待命。这样一来，当一个请求进来时，它就能被立刻路由到一个可用的副本上。
而那些不那么热门的模型，在非高峰时段可能连一个热副本都分不到。当一个请求打到一个冷模型上时，供应商就得现场给它分配一块 GPU，从存储里把模型权重加载出来，初始化服务运行时，然后再去处理请求。对于一个大型语言模型来说，这个过程根据模型大小、存储位置和基础设施的不同，短则 10 秒，长则 90 秒。这就是冷启动。
冷启动是我们后面要讨论的那种高波动延迟模式的主要推手。一个模型的 TTFT 中位数可能是 0.4 秒，因为绝大多数请求都打到了热副本上；但它的 95 分位延迟 (p95) 可能会超过 6 秒，因为差不多每二十个请求里就有一个会踩中冷启动。光看中位数是完全看不出这个问题的。
量化精度
同一组模型权重可以用不同的数值精度来提供服务。全精度服务（BF16 或 FP16）最吃内存，但它能原封不动地保留原始权重。FP8 和 INT8 大约能把内存占用砍掉一半，而且对于大多数任务来说，质量损失微乎其微。INT4 量化能进一步压榨内存，但在强推理的基准测试上，它可能会导致可测量的质量差异。
供应商会根据他们对每个模型的优化投入来挑选量化级别。热门模型往往能得到仔细的量化调优，选一个既能把单 GPU 吞吐量拉到最大，又不伤害输出质量的精度。而小众模型呢，可能上架时随便配了一个最容易搞的精度就完事了。
量化从两个方面影响性能。更低的精度意味着在单个 GPU 上能跑更多的副本（降低冷启动出现的频率），同时也能执行更快的矩阵运算（当副本处于热状态时，降低 TTFT）。但供应商几乎从来不会公开他们对某个特定模型到底用了哪种精度。
GPU 硬件分配
不是所有 GPU 生来平等的。H100、A100 和 AMD MI300X 之间的显存带宽和计算吞吐量有着实质性的差别。一个模型跑在 H100 NVL 上还是跑在 A100 80GB 上，对于完全相同的负载，TTFT 差个 2 到 3 倍都不稀奇。供应商可能会根据需求、可用库存，以及该模型流量体量背后的经济账，把不同的模型路由到不同层级的 GPU 上去。
推理引擎与内核优化
模型到底怎么被运行起来，其重要性不亚于跑在什么硬件上。vLLM、TensorRT-LLM、SGLang 以及各种定制内核，即使面对完全相同的模型权重，给出的吞吐量和延迟曲线也大相径庭。一些额外的技术，比如推测解码，它会用一个轻量级的小草稿模型来提前预测大模型接下来要吐出的好几个 Token，这能显著降低 TTFT，但需要显式地去投入配置。每个供应商都是独立地做这些选择的，这也就是为什么同一个模型在不同平台上的表现会一个天一个地。
请求队列优先级与批处理
当负载上来时，供应商会把多个请求合并成一批来处理，以此来提高 GPU 的利用率。那些流量稳定且可预测的热门模型，批处理效率就很高。请求以均匀的时间间隔抵达，队列很浅，批处理带来的额外开销就很小。而那些流量稀疏且突发的小众模型，批处理效果就很糟。一个打到冷门模型上的请求，很可能被迫排在热门模型的批处理队列后面，由此增加的延迟看起来和冷启动噪音毫无区别。
变量叠加后的累积效应
上述决策并不是孤立地在起作用。一个小众模型可能会以一个保守的精度跑在一层比较老的 GPU 上，没有开启推测解码，零热副本，批处理效率也很差。每一个因素单独都会增加一点延迟，而它们全叠在一起时，结果就是：一个模型在短暂的评估期里可能测试起来还行，但一上生产环境立马翻车。
这正是为什么选择供应商时，光看模型目录页远远不够。相比之下，DigitalOcean 的无服务器推理 采取的是另一种思路：它不会追求目录里塞进几百个模型，而是在每个支持的模型上都保证了一致的硬件配置和优化策略。你在 DigitalOcean 后台看到每个托管模型，不论是DeepSeek 、Kimi2.6和即将支持的Kimi 3，还是Qwen、GLM ，都是经过优化的。这种"少而精"的路线，本质上就是把供应商本该做好的脏活累活，提前做完。
模型热度如何影响这些决策
无服务器推理供应商的 GPU 利润空间都很薄。容量很贵，要给一个有 400 个模型的目录里的每一个都预先分配热副本，在经济上根本不现实。这个资源分配决策非常简单粗暴：他们会把重注砸在那些能产生持续、大流量的模型上，减少对那些大部分时间都闲置着的模型的投入。
模型目录的规模还会放大这个效应。当一家体量相对较小的供应商列出了 400 个模型时，其中只有一小部分背后有经过优化、热启动的服务基础设施在撑腰。剩下的模型虽然"可用"——意思是权重文件在那儿，能加载——但在低流量下用起来的体验，跟一个得到充分的资源倾斜的旗舰模型相比，完全是两码事。
最关键的是，每家供应商在押注时都是各押各的。一家可能在 DeepSeek V4 Pro 上投得盆满钵满，而另一家可能把同样的功夫花在了 Kimi K2.6 身上。光是看模型目录页，这俩看起来都一样：一个模型名字、一个每 Token 单价、一个 API 端点。但它们背后的基础设施决策，完全天差地别。一个模型在某个平台上"可用"，绝不等于这个平台为它做了深度优化。
内部测试的发现
我们是从 DigitalOcean 在 NYC1 的 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 秒。
| 供应商 | TTFT 中位数 | p95 TTFT | CV% |
|---|---|---|---|
| A | 0.39 秒 | 0.57 秒 | 21% |
| B | 0.55 秒 | 6.30 秒 | 541% |
| C | 0.73 秒 | 6.91 秒 | 710% |
一个开发者要是在一家供应商上评估了 DeepSeek V4 Pro，然后选了另一家去做生产部署，那他最终感受到的生产延迟将像是彻底坏了——明明除了路由之外什么都没变。
不存在通用的"最佳"供应商
Kimi K2.6 讲出了完全相反的故事。在一家供应商上，CV 高达 989%：TTFT 中位数 0.35 秒，p95 为 5.98 秒。在第二家供应商上，CV 为 1266%：中位数 0.43 秒，p95 虽然只有 1.70 秒，但极端离群值把标准差拉到了 5.4 秒。而在对这款模型投入最多的那家供应商上，CV 骤降到了 102%：中位数 0.25 秒，p95 为 1.08 秒——这比在其他两家平台上的表现大约一致了 10 倍。
| 供应商 | TTFT 中位数 | p95 TTFT | CV% |
|---|---|---|---|
| A | 0.35 秒 | 5.98 秒 | 989% |
| B | 0.25 秒 | 1.08 秒 | 102% |
| C | 0.43 秒 | 1.70 秒 | 1266% |
在我们的测试里，把 DeepSeek V4 Pro 跑得最好的那家供应商，就是跑这个模型的正确选择；而跑 Kimi K2.6，最正确的却是另一家供应商。这两个结论都得靠测试才能拿到，你光看模型目录页是绝对看不出来的。
目录越大，验证负担越重
一家相对小体量的供应商，要是列出了几百个模型，它是没可能对所有这些模型都平均投入的。基础设施的经济账就不允许。一个经过精心策划的模型目录暗示着背后有刻意的选择——平台只把那些它认为值得重点投入的放进来。而一个追求广撒网的庞大目录则暗示了完全相反的事实：好多模型被列出来，只是因为它们能被加载起来，而不是因为它们已经被充分优化过了。
数据也反映了这一点。对于 Kimi K2.6，追求广度的供应商 CV 基准值高达 989% 和 1266%，而一家走精选路线的供应商，CV 只有 102%——大概一致了 10 倍。对于 DeepSeek V4 Pro，一家投入了很多的供应商 CV 是 21%，而另一家没怎么投入的 CV 高达 710%。
跟精选型供应商打交道时，一个模型被列出来，是一个相当强的信号，说明它已经被刻意配置过了。而跟广度型供应商打交道时，一个模型被列出来，几乎不能告诉你关于它背后支持质量的任何信息。不论这个模型背后是有三个热副本，还是零个，模型目录页看起来都一模一样。
这并不是说广度型供应商总体上就更差。对于他们明确重注投入的模型，他们完全可以是最好的选择。但是，他们目录里模型支持质量的差异幅度要远高于其他平台，这意味着落在你肩上的验证负担也更重。你绝不能因为一个模型出现在有 400 个模型的目录里，就想当然地认为它已经经过了充分优化。你必须自己去查。
那些高 CV 的结果并非噪音。一个超过 100% 的 CV 值，意味着标准差超过了均值。在实践中，这表明存在一种双峰分布：有一簇快速的请求（打中了热副本），以及一条由极慢请求（触发了冷启动）组成的长尾。光看中位数是绝对发现不了这个问题的。如果你只发 10 个请求然后取个平均值来评估模型，你很可能从头到尾都没踩中过一次冷启动。
选型前的基准测试方法
一个好的基准测试至少需要几个小时才能跑完。以下是一套能让你在基于一个模型和供应商的组合做开发之前，得到所有你需要的信息的最小化方法论。
测什么：测首 Token 延迟 (TTFT)，而不是端到端延迟。TTFT 能把"模型是否处于热启动且就绪"这个状态单独隔离开来，不受生成长度的影响。它是反映基础设施投入程度最直接的信号。
测多少请求：至少 75 个。10 到 20 个请求只能让你看到中位数，但看不到那条长尾。冷启动之所以罕见，是因为一个 20 个请求的基准测试很可能完全碰不到它们。到了 75 个请求的量级，如果模型容易出现冷启动，你基本一定会撞上。
提示词一致性：要么使用能准确反映你真实应用场景的提示词，要么就在所有请求里都用一句固定的短提示词。这样能把提示词长度带来的方差从结果里排除掉，让跨供应商的对比保持干净。
时间节奏：每个请求之间隔几秒钟再发。这能避免因请求批处理而人为地美化结果。你想观察到的是模型在具有代表性的单次请求条件下的行为，而不是持续高吞吐下的表现。
计算什么：TTFT 中位数、p95 TTFT、标准差和 CV%。中位数和 p95 放一起，能告诉你常态体验和长尾延迟分别是多少。而 CV% 则是跨供应商比较一致性时最有用的那个单一信号。
用 CV% 阈值做一个快速判断指南：
- CV < 40%：平台对这个模型的投入很扎实，保持热启动并且经过了优化。
- CV 40-100%：有一些波动，对于容忍一定延迟的工作负载来说可以接受。
- CV > 100%：正在经历冷启动，需要评估 p95 值对你的应用场景到底能不能接受。
- CV > 300%：在这个供应商上，对于对延迟敏感的应用来说，就当它还没法上生产吧。可以考虑用专用端点。
时间点很重要：要在高峰和非高峰时段都跑基准测试（比如凌晨、周末）。当打到模型上的流量最低时，冷启动的行为也最糟糕。在工作时间跑的基准测试，可能会因为其他用户一直在帮着把模型维持在热启动状态，而给出人为美化的结果。
常见疑问与解答
这是不是意味着无服务器推理本身就不可靠？
并不是普遍如此。对于那些在特定供应商上有着稳定流量的成熟模型来说，无服务器推理是高度可靠的。可靠性的担忧只针对那些供应商没有进行相应投入的模型，不管这个模型在别家跑得多好。
我该如何彻底避开这个问题？
专用端点通过给你预留的 GPU 容量，彻底消除了冷启动的风险。但它的经济账只在你有持续、可预测的流量时才算得过来。专用容量的成本，不管用不用都是一样的，但延迟的可预测性是百分之百的。如果你已经确定了一个想要在生产中使用的模型，在那家对它优化最到位的供应商上开一个专用端点，是最稳妥的路径。
是不是模型目录最大的供应商，对模型优化最到位？
不是。目录的规模与平均支持深度是负相关的。一个列出 400 个模型的供应商，不可能对它们都平均投入。更小、更精选的目录通常反映了背后关于哪些模型值得重点投入的深思熟虑。目录大小只能告诉你广度，只有亲自去测才能告诉你深度。
我是不是应该把我所有的模型都放在同一家供应商上？
不一定。正如 DeepSeek V4 Pro 和 Kimi K2.6 展现出的那种反转关系，不同的供应商押注了不同的模型。如果你在生产中用到了多个模型，那么每个模型的最佳供应商可能各不相同。按模型粒度把请求路由到不同的供应商，虽然会增加一些架构上的复杂度，但对于那些供应商支持程度差异巨大的模型来说，在延迟和可靠性上的收益也是相当可观的。
结语
无服务器推理目录并不是一张所有模型都得到同等支持的平铺列表。它们是一个分层的系统，每家供应商都选择性地对某些模型进行投入，让它们享受热副本、精细的量化优化以及专门的工程关注，而其他模型则只能去分那些剩下来的、边边角角的容量。这些层级是隐性的、无文档记录的，而且每个平台都各不相同。
在实践中的后果就是，模型评估和供应商评估完全是两码事，是两件要分开决策的事。在任何一家供应商上，你用少量请求就能评估出模型的质量好坏。但在把一组"模型+供应商"的组合钉死在生产环境之前，你必须专门去测一致性，包括 p95 延迟，而不仅仅是中位数，要跑过足够多的请求来把冷启动的行为完全暴露出来。
当然，如果你不想每次选型都像排雷一样自己跑一圈基准测试，一个更省心的办法是选一个已经把这些脏活累活做在前面的平台。比如 DigitalOcean 的无服务器推理，它不会在基础设施层做差异化对待，你在测试环境看到的表现，就是生产环境的真实表现。这样，你可以把精力放在模型的回答质量上，而不是底层资源的稳定性上。
这件事做起来其实很快。本文中的基准测试跑了几个小时，就挖出了那些要在生产环境调试好几天才能发现的差异。所以，先把这些数据跑出来，再在其基础上去做开发。
相关链接
相关产品与选型
