大模型 API 性能选型避坑指南：除了每秒 Token 数，项目上线更看重哪些指标？

当团队在评估无服务器大语言模型（LLM）推理模型和供应商时，对比往往会简化为一个单一的数字：每秒生成 Token 的中位数（median tokens per second）。这是一个很容易发布也很容易排名的数字，对于某些工作负载来说，它确实是正需要优化的核心指标。但这只是众多测量维度中的一个，如果单独来看，它只能描述工作负载进入生产环境后“性能”所包含的狭窄侧面。

原因在于，不同的工作负载会遇到不同的瓶颈。夜间的批量摘要任务依赖于持续的吞吐量，因此每秒 Token 的中位数是一个合理的衡量标准。然而，一个面向用户的聊天界面则受限于第一个 Token 出现的速度有多快以及这种体验有多稳定，而不是稳定状态下的生成速率。处理真实流量的生产环境服务则受限于其最坏的请求情况、错误率以及每个完整答案的成本，而这些都无法通过中位数吞吐量数据来体现。如果优化了错误的指标，你可能会交付一个基准测试非常漂亮但在实际运行中表现糟糕的产品。

本文涵盖了对生产环境无服务器推理真正至关重要的指标、每个指标所衡量的核心内容，以及哪些工作负载应该关注这些指标。其目的是帮助你选择与你的应用场景相匹配的衡量维度。

核心要点

• 在对多个供应商的众多模型进行基准测试后发现，并不存在单一的“最快”供应商，排名会随着模型的不同而改变。许多供应商的排名会根据模型而对调，有些供应商在运行 Llama 3.3 70B 时快 3 倍，但在运行 Gemma 4 时却慢 5 倍。任何宣称“供应商 X 最快”的言论，在没有指明模型和工作负载的情况下都是不完整的。

• 可用性是大多数基准测试都会忽略的指标，但它却是决定性的。一些供应商会将模型锁定在专用端点后，或者运行特定模型时不稳定且伴有漫长的冷启动。如果一个模型在能用时很快，但在需要时却无法可靠地提供服务，那么它就毫无价值。

• 首个 Token 的稳定性比首个 Token 的速度更重要。对于大多数生产环境应用来说，在整个模型目录中保持紧凑的“首个 Token 延迟”（典型和最坏情况控制在几百毫秒以内），远比在相同工作负载上看到请求从不到一秒飙升到 24 秒要好得多。用户感受到的是最坏的情况，而不是中位数。

• 每个有用答案的成本可能是最重要的指标，而它主要由模型选择决定，而非供应商的价目表。为任务挑选合适的模型才是更大的成本杠杆。

吞吐量（每秒 Token 数）

吞吐量是模型启动后，在稳定状态下发射 Token 的速率，这也是大多数公开基准测试最常主导的指标。对于某些工作负载，选择这个指标是正确的。一个在夜间重写商品目录的批量任务、一个大批量生成嵌入（Embeddings）或摘要的流水线，或者任何没有人类在等待的离线流程，都会受到持续每秒 Token 数的限制，通过这个数字来为供应商排名能为你指明正确的方向。

吞吐量通常是在一次处理一个请求的单流吞吐量下测量的，但这并不是生产环境运行的方式。真实的服务会同时发出许多请求，因此真正重要的数字是并发情况下的总吞吐量，以及随着负载上升，单次请求的速度是否能优雅地平稳降级。吞吐量还会与模型架构产生相互作用。由于混合专家（MoE）模型的生成速度远快于同等或更大规模的稠密模型，因此吞吐量与其说是供应商的问题，不如说是模型选择的问题。

首个 Token 延迟及其稳定性

对于任何交互式应用，首个 Token 延迟（TTFT）是用户能直观感受到的指标。在流式聊天界面中，TTFT 是指按下回车键与响应开始出现之间的间隔。如果一个模型的首个 Token 能够快速且可预测地到达，并且不需要在用户看到前几个生成的 Token 之前就完成整个响应，那么即便其吞吐量平平，依然能让用户感到即时响应。而在两者中，可预测性是更难做到的那一半。如果首个 Token 通常需要 0.2 秒，但偶尔需要 8 秒，那么即使中位数看起来非常优秀，体验上也会感觉像挂了一样。因此，应该将 TTFT 测量为一个区间（中位数对比第 95 百分位数），因为两者之间的差距正是中位数所掩盖掉的那部分体验。

在使用固定提示词和 temperature=0、对每个模型进行 25 次或更多次试验（舍弃前三次预热请求）来测量交互式聊天工作负载的 TTFT 时，中位数与最坏情况之间的区间是最能说明问题的数字。通过在纽约 NYC1 的 DigitalOcean Droplet 云服务器 上进行基准测试，DigitalOcean 展示了在 gpt-oss-120b（0.29 到 0.35 秒）以及 Kimi 推理模型（最坏情况下低于 0.7 秒）上紧凑的中位数到最坏情况的价差。在 DigitalOcean 更广泛的主流阵容中，这一规律依然成立，典型和最坏情况下的首个 Token 时间彼此相差在几百毫秒以内，全部低于 0.4 秒。

尾部延迟（p95 / p99）

如果说上一节探讨的是响应是否能及时开始，那么尾部延迟探讨的就是整个请求是否在预算时间内完成。它是你最慢的那部分请求的端到端时间（即第 95 和第 99 百分位数），也是编写服务级别目标（SLO）、HTTP 超时限制和容量规划时所依据的数字。在生产环境的流量规模下，尾部延迟并不是边缘情况，而是每分钟请求中可以预见的一定比例。因此，一个中位数极佳但尾部延迟过高的供应商，会在流量上升 medical 瞬间悄无声息地撑爆你的延迟预算。

中位数与尾部延迟之间巨大的鸿沟，往往是服务器链路吃紧的明确信号。在规划预算时应针对 p95 或 p99 进行，并将中位数与尾部延迟之间的宽泛差距视为一种可靠性警告，而不是可以忽略的四舍五入误差。

可靠性与可用性

如果请求失败、什么都没返回，或者模型根本无法调用，那么速度就毫无意义。可用性是指你是否能够在无服务器架构上直接调用你想要的模型，而无需额外配置专用的基础设施。

可靠性则是第二个维度，即在模型可以调用的情况下，请求是否能成功执行。请务必对你打算部署的具体模型进行基准测试，因为成熟模型在成熟平台上通常很稳健，但最新和最分众（niche）的模型往往经常会出现可用性和可靠性问题。

每一个有用结果的成本

在考虑不同的模型类型时，正确的成本指标并不是价格表上每百万 Token 多少美元。而是在你的工作负载实际产生的 Token 数量下，获得一个有用的、完整的答案所需的成本，而主导这一成本的因素是模型选择和路由能力，尤其是标准模型与推理模型（Reasoning models）之间的区别。推理模型在给出答案之前会产生很长一段内部“思考”过程，而这些思考 Token 是作为输出计费的，因此一个看起来只有几百个 Token 的答案，在账单上可能会体现为几千个 Token。

通过测量单个完整聊天答案的成本，可以总结出两个规律。在同一个模型内，各个供应商的价格相差在几个百分点以内（一个完整的 gpt-oss-120b 答案成本为 0.00017 到 0.00019 美元，而一个推理模型答案的成本为 1.5 到 1.7 美分）。而在跨模型对比时，波动幅度大约有 230 倍，从最小模型的 0.00006 美元到推理模型的大约 1.5 美分。供应商的选择对答案成本的影响在百分比级别，而模型的选择对成本的影响则是数量级级别的，因此核心的成本杠杆在于让模型与任务相匹配。随之而来的架构便是按任务进行路由：将默认请求发送给快速且廉价的主流模型，只有在真正需要解决复杂问题时才升级到推理模型，并将供应商的选择作为次要决策。能够自动管理这种路由的工具是 DigitalOcean 推理路由。

冷启动与突发流量表现

无服务器架构引入了一个专用部署所没有的指标：冷启动。当一个端点一直处于空闲状态，或者需要扩容以应对突发流量时，第一批请求会承担配置基础设施的延迟惩罚。对于有波峰波谷的流量来说，这第一批请求恰恰就是你的用户发送的请求。

该指标量化了从冷启动和突发情况下首个 Token 的时间。如果你的流量具有突发性，请确认该平台是否提供保温（keep-warm）或预置容量，并显式地对这种过渡状态进行测试，而不是盲目假设其能保持热路径下的数据。

输出保真度

一个请求可以返回 HTTP 200，但它依然可能是无用的。输出保真度是一个用来衡量响应是否真正正确、完整以及达到预期质量的指标。这是任何延迟和吞吐量图表都无法体现的。这有时可能包含无声的截断。在某些情况下，如果给推理模型分配了一个普通的、只够容纳标准答案大小的 Token 预算，它可能会把整个预算都花在“思考”上，最终返回一个空答案——这是一个没有任何可用内容但却“成功”的请求。另一个问题可能是量化（Quantization）。一些供应商提供模型的低精度变体（如 FP8、FP4），这会在不改变 API 的情况下改变输出质量，而且这一点并不总是会被公开。

该指标旨在确认输出对你的任务是否有效，而不仅仅是调用是否返回了 200。对于推理模型来说，这意味着需要预算足够的 Token 来让它真正得出答案。对于任何模型来说，这意味着要清楚你被分配的服务精度并对质量进行抽检。

业务适配度

最后一个指标是最难量化、但最有可能决定集成成本的指标，即该平台与你构建应用的方式适配得如何。大多数供应商都提供兼容 OpenAI 的 API，这使得切换供应商只需要修改一个基础 URL 即可，但兼容性不仅仅局限于端点的形状。你发送的参数是否真正被尊重同样重要。关闭模型推理模式的请求可能会被一家供应商采纳，而在其他供应商那里则被悄悄忽略。追踪服务器准确报告的 Token 使用情况以便进行计费和监控、可靠的流式传输、地域和数据驻留选项，以及允许你的使用场景的服务条款也同样重要。一个兼容的端点并不等同于一个兼容的平台，因此请务必确认你的应用程序所依赖的具体行为。

为你的工作负载选择合适的指标

上述指标并不是一个需要一次性全部优化的排行榜。它们是一个菜单，供你根据应用程序的具体功能进行挑选。工作负载决定了哪些数字是具有决定意义的，哪些数字只是噪音。

单流吞吐量的中位数是大多数对比中最常见的数字，它对上述工作负载中的某一种具有决定性意义，而对其他工作负载来说则是次要的。它是一个真正有用的指标。但它并不是唯一的指标，而且对于大多数生产环境部署来说，它并不是最重要的那一个。

常见问题

无服务器推理中最重要的指标是什么？

没有单一最重要的指标。正确的指标取决于工作负载。交互式聊天应用依赖于首个 Token 时间的稳定性和可靠性。批量流水线关心并发下的持续吞吐量和每个结果的成本，而 RAG 系统对长提示词上的 Prefill 延迟最敏感。每秒 Token 的中位数是一个有用的起点，但对于大多数生产部署来说，它不是决定性的数字。

为什么我应该看 p95 延迟而不是中位数？

中位数描述的是典型请求，而 p95 描述的是你运气最差的用户一天中会遇到多次的体验。在有意义的流量规模下，5% 的请求就意味着成千上万个请求。一个供应商可能在 p50 时看起来非常优秀，但在 p95 时却到了无法交付的地步。

推理模型在无服务器推理上的运行成本是否更高？

是的，而且比其价目表上标出的价格要高得多。推理模型在给出可见答案之前会生成思考 Token，而这些 Token 是作为输出计费的。在此基准测试中，推理模型在每次聊天请求上的成本大约是小型 Instruct 模型的 230 倍，即使它们的每 Token 价格相差并没有那么大。请始终对比每个完整答案的成本，而不是每百万 Token 的成本。

为什么不同供应商对同一模型的基准测试结果会有如此大的差异？

供应商运行着不同的硬件、批处理策略和量化级别，且精度并不总是公开的。资源池的配置同样重要，因为一个供应商可能在其主打模型上速度极快，而同一平台上的分众模型运行起来却慢得多。供应商之间的排名会完全根据你测试的模型而对调，因此请针对你计划服务的具体模型进行基准测试。

我需要多少次试验才能获得值得信赖的基准测试结果？

在每个模型和场景组合下至少使用 25 次可测量的试验，首先舍弃几次预热请求，并使用固定提示词将 temperature 固定为 0，以便运行具有可比性。这样的样本大小足以报告一个稳定的 p50 和一个具有指示意义的 p95。同时，还要收集跨多个时间窗口的试验数据。

结论

无服务器推理性能并不是一个单一的数字，而最常见的数字——每秒 Token 的中位数，仅仅回答了批量吞吐量这一个问题。决定生产环境部署的通常是其他指标。它们包括模型是否能可靠地提供服务、首个 Token 延迟在真实流量下是否能保持紧凑、在第 95 百分位数下的尾部表现如何，以及在计入思考 Token 和真实提示词大小后，一个完整的答案实际需要花费多少钱。

在此基准测试中，DigitalOcean 在这些维度上的表现最为强劲。在整个模型目录中保持几百毫秒的首个 Token 区间，并不是供应商事后可以补齐的。它是从外部看去配置完善、保持温态的服务池所具备的特征，正如宽泛的尾部延迟和被锁定的模型是配置薄弱的服务池所具备的特征一样。在承诺选择某家供应商之前，请用你自己的工作负载流式传输几百个请求并读取百分位数，因为相比于价目表或头条基准测试，这种测量更能揭示一个端点背后的基础设施实力。