设想一下你正在为应用挑选一个 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 TTFTCV%A0.39 秒0.57 秒21%B0.55 秒6.30 秒541%C0.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 TTFTCV%A0.35 秒5.98 秒989%B0.25 秒1.08 秒102%C0.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 的无服务器推理它不会在基础设施层做差异化对待你在测试环境看到的表现就是生产环境的真实表现。这样你可以把精力放在模型的回答质量上而不是底层资源的稳定性上。这件事做起来其实很快。本文中的基准测试跑了几个小时就挖出了那些要在生产环境调试好几天才能发现的差异。所以先把这些数据跑出来再在其基础上去做开发。相关链接无服务器推理的关键指标如何为你的 AI 推理业务场景选择合适的大语言模型如何借助推理路由实现多模型 API 成本直降40%
设想一下你正在为应用挑选一个 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 TTFTCV%A0.39 秒0.57 秒21%B0.55 秒6.30 秒541%C0.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 TTFTCV%A0.35 秒5.98 秒989%B0.25 秒1.08 秒102%C0.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 的无服务器推理它不会在基础设施层做差异化对待你在测试环境看到的表现就是生产环境的真实表现。这样你可以把精力放在模型的回答质量上而不是底层资源的稳定性上。这件事做起来其实很快。本文中的基准测试跑了几个小时就挖出了那些要在生产环境调试好几天才能发现的差异。所以先把这些数据跑出来再在其基础上去做开发。相关链接无服务器推理的关键指标如何为你的 AI 推理业务场景选择合适的大语言模型如何借助推理路由实现多模型 API 成本直降40%
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
