Beyond Per-Token Pricing: A Concurrency-Aware Methodology for LLM Infrastructure Cost Estimation

发表时间: 2026-06 · arXiv:2606.11690 (Independent Researcher)

文章标题：超越按Token计费：一种面向并发的LLM基础设施成本估算方法论
作者：Chitral Patil
机构：独立研究员

A1 主要贡献

本文的核心论点在于，当前公开的几乎所有大型语言模型（LLM）成本计算器都将GPU利用率视为一个固定的输入参数，这导致了巨大的估算误差。研究表明，在完全相同的H100硬件上，仅因服务请求率（λ）这一个变量的变化，每百万输出Token的有效成本就可在\$0.21到\$15.25之间波动。这一成本差异，即“未充分利用惩罚”，在低到中等企业负载（1-10 rps）下为2.5至24倍，在接近闲置（λ=1 rps）时高达36.3倍。然而，没有任何开源计算器或主流学术研究将这个由运营商控制的关键变量——请求到达率λ——作为成本模型的核心参数。

核心问题与研究目标：
现有成本估算方法的根本缺陷是假设GPU处于完全或接近完全利用的状态。实际上，生产环境中的GPU利用率是由请求到达率、延迟服务等级目标（SLO）、模型架构和部署配置（如张量并行度）等因素动态决定的。例如，一个在10 rps下服务的GPU，其利用率和每Token成本与在200 rps下服务的同一个GPU截然不同。尽管业界已定性观察到这一点，但缺乏系统的量化分析和可复用的框架。本文旨在填补这一空白，通过衡量该误差的大小，形式化一个更准确的成本模型，并发布一个开源工具来解决此问题。

创新贡献：
本文做出了四点主要贡献：
1. 实证量化成本差异：通过在H100 GPU上进行的42次系统性vLLM基准测试（覆盖3种模型、2种精度、7个请求到达率水平），本文实证证明，仅因请求到达率λ的变化，在完全相同的硬件上，每百万Token的有效成本差异可高达36.3倍。
2. 形式化并发感知成本公式：提出了一个将有效成本Ceff建模为硬件（H）、模型架构（M）、量化（Q）、请求到达率（λ）和服务等级目标（L）的函数Ceff = f(H, M, Q, λ, L)。该公式将λ视为面向运营商成本归因的实证扫描轴，而非系统调度框架中的优化变量。
3. 修正盈亏平衡分析：证明了现有忽略利用率动态的盈亏平衡分析会产生误导性的交叉点，并提供了经过利用率调整的、更准确的交叉曲线。
4. 发布开源工具 vllm-cost-meter：发布了一款开源的实时成本估算工具。该工具能直接接入一个运行中的vLLM服务器，根据运营商自身的实际流量而非供应商的基准数据，实时报告真实的美元/百万Token成本。据我们所知，这是首个能根据实时负载计算调整后成本的开源工具。

A2 相关工作

2.1 基于Token量的成本模型

主流模型的局限性：大多数LLM成本估算工具和学术分析采用基于Token量的模型：C = Θmax T × PGPU，其中T是Token数量，Θmax是理论最大吞吐量，PGPU是GPU小时价格。Pan等人【1, A cost-benefit analysis of onpremise large language model deployment: Breaking even with commercial LLM services. 2025. arXiv preprint arXiv:2509.18101】提出的盈亏平衡框架假设每月160个运营小时内完全利用，其计算器只接受模型、GPU选择和数量作为输入，完全忽略了利用率、并发或工作负载参数。SLaM框架【2, Scaling down to scale up: A costbenefit analysis of replacing OpenAI’s LLM with open source SLMs in production. 2024. IEEE ISPASS】则假设在单个T4 GPU上有80%的利用率，并直接与GPT-4 API价格进行每Token成本比较。

公开计算器现状：对超过15个公开计算器（如Helicone, LiteLLM, YourGPT, http://llm-prices.com, http://Mem0.ai, DocsBot等）的调查证实，超过90%的工具仅接受模型名称和Token数量作为输入。LLM Inference TCO Calculator【12, LLM Inference TCO Calculator v2.4. 2025. https://acnicessc.github.io/llmcalc/】是现有功能最全面的网页工具，它接受并发用户、部署形态和延迟因子等输入；然而，其吞吐量值是基于启发式预设而非实证测量，并且明确声明不进行排队论建模 。

2.2 系统级成本优化

系统优化研究的视角：一些系统论文将并发和部署形态作为优化变量。Vidur【3, VIDUR: A large-scale simulation framework for LLM inference. 2024. MLSys】通过搜索张量并行、流水线并行、GPU SKU和调度策略来优化每美元的QPS，同时满足延迟SLO约束，并证明使用错误工作负载的优化配置会导致高达2倍的成本开销。Mélange【4, Mélange: Cost efficient large language model serving by exploiting GPU heterogeneity. 2024. arXiv preprint arXiv:2404.14527】将GPU分配问题形式化为跨异构GPU类型的成本感知箱装填整数线性规划问题，实现了高达77%的成本降低。SageServe【5, SageServe: Optimizing LLM serving on cloud data centers with forecast aware auto-scaling. 2025. arXiv preprint arXiv:2502.14617】通过基于ARIMA的容量预测和差异化SLA来处理日间流量模式；Llumnix【33, Llumnix: Dynamic scheduling for large language model serving. 2024. OSDI】则通过跨副本运行时重新调度在途请求来补充这一点，以控制尾部延迟和利用率。这些工作建立在由Orca【30, Orca: A distributed serving system for transformer-based generative models. 2022. OSDI】、Splitwise【25, Splitwise: Efficient generative LLM inference using phase splitting. 2024. ISCA】、DistServe【26, DistServe: Disaggregating prefill and decoding for goodput-optimized large language model serving. 2024. OSDI】和SarathiServe【27, Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve. 2024. OSDI】等工作建立的连续批处理基础上，从调度器/引擎侧解决吞吐量与延迟的权衡问题：通过在GPU间解耦prefill和decode、将KV缓存解耦到专用池（Mooncake【31, Mooncake: A KVCache-centric disaggregated architecture for LLM serving. 2024. arXiv preprint arXiv:2407.00079】）或分块prefill，它们在给定SLO下提升了可达到的Θmax。这些工作与本文的贡献是互补的：它们在固定的操作点上优化引擎的性能上限，而本文提出的Ceff = f(H, M, Q, λ, L)则描述了每Token成本在低于该上限的整个λ轴上如何变化。§5.9提供了跨硬件和TP扩展的实测证据，补充了Vidur的模拟成本开销预测和Mélange的分配目标前提。

基准测试与行业工具：BentoML的llm-optimizer【13, llm-optimizer: Benchmark and optimize LLM inference across frameworks. 2025. https://github.com/bentoml/llm-optimizer】支持并发扫描和帕累托前沿可视化，但不输出每Token成本 。SemiAnalysis InferenceX（前身为InferenceMAX）【14, InferenceX (formerly InferenceMAX): Open-source continuous inference benchmarking. 2025. https://github.com/SemiAnalysisAI/InferenceX】提供每日跨硬件基准测试和市场聚合级别的成本归因，但侧重于硬件供应商的参考配置，而非同一GPU上的负载/成本经济学；vllm-cost-meter则是测量运营商自己服务器在自己流量下的成本。这些是互补的，而非竞争关系。来自vLLM项目的GuideLLM 【15, GuideLLM: Evaluate LLM deployments for real-world inference. 2025. https://github.com/vllm-project/guidellm】能自动进行并发扫描，但只输出延迟和吞吐量指标，不进行成本计算。NVIDIA的TCO方法论 【10, LLM inference benchmarking: How much does your LLM inference cost? 2025. NVIDIA Developer Blog. https://developer.nvidia.com/blog/llm-inference-benchmarking-how-much-does-your-llm-inference-cost/】概述了一个清晰的基准测试和规模规划工作流，但没有发布独立的开源计算器。这些工具的贡献在于寻找更便宜的配置或测量性能，而不是为从业者提供一个将服务负载与美元成本联系起来的成本估算方法论 。

2.3 推理经济学

相关理论与实证研究：Erdil【6, Inference economics of language models. 2025. arXiv preprint arXiv:2506.04645】为LLM推理经济学建立了一个理论上的屋顶线模型，生成了串行速度与每Token成本的帕累托前沿，并明确建模了张量并行如何通过牺牲利用率来换取速度。WiNGPT (Zhuang等人)【7, Beyond benchmarks: The economics of AI inference. 2025. arXiv preprint arXiv:2510.26136】是与本文最接近的先前实证工作：他们在使用vLLM的A800 GPU上，将并发从8提升到48，展示了2.6倍的成本降低，并阐述了三个实证原则——边际成本递减、规模收益递减以及一个最佳成本效益区——这些都与本文报告的Ceff(λ)曲线在性质上一致。然而，他们的扫描从并发为8开始（此时已部分批处理，错过了λ<5时陡峭的冷启动区域，而这正是驱动我们主要发现的成本差异所在），只覆盖了单一硬件家族上的医疗领域模型，并且没有发布代码或数据。本文则推广到三种架构类别、两种硬件家族（H100 NVL, A100 PCIe），提供了一个参数化的五变量成本函数，并发布了一个可操作的开源测量工具。LLM服务中的并发请求调度也曾通过分析性成本模型进行研究【8, Faster LLM inference using DBMSinspired preemption and cache replacement policies (INFERMAX). 2024. arXiv preprint arXiv:2411.07447】，但其重点是调度器级别的prefill/decode成本，而非每次部署的运营成本测量。

2.4 研究空白声明

现有工作的四大阵营与本文的定位：先前的工作可以清晰地分为四个阵营，但没有一个能为从业者提供闭环的解决方案。基于Token量的计算器和盈亏平衡分析【1, 2】将利用率视为用户提供的输入。系统优化框架【3, 4, 5】能找到更便宜的配置，但不为给定部署输出美元/百万Token的成本。基准测试工具和行业仪表盘【13, 15, 14, 10】测量吞吐量或发布市场聚合的TCO，但并不检测运营商自己的服务器。先前的工作已经从理论上对推理成本进行了建模【6】，在狭窄领域内凭经验观察了服务负载与成本的行为【7】，在SLO约束下对引擎进行了基准测试但没有输出每Token成本【13, 15】，并提出了美元/百万Token作为基准测试指标。但没有先前的工作将这四者结合起来：一个跨架构和硬件家族校准的参数化成本函数、一个能读取运营商自身Prometheus指标的实时服务器检测工具，以及开放的数据和工具。本文做到了这一切。

A3 并发感知的成本框架

3.1 问题形式化

成本函数定义：我们将每百万Token的有效成本Ceff定义为一个包含四个扫描变量和一个隐式变量的函数：

公式1
公式1

分号将我们实证扫描的四个轴（H, M, Q, λ）与延迟SLO参数L分开。在本文报告的扫描中，L是隐式持有的（所有配置都是在没有SLO截止的情况下测量的，L将作为对测量分布的准入控制过滤器）。将L作为主动扫描维度是未来的工作；§6.9讨论了其范围影响。

其中：
* H = 硬件规格（GPU类型、数量、内存、互连）
* M = 模型架构（参数数量、密集 vs. MoE、注意力头）
* Q = 量化精度（FP16, FP8, INT8, INT4）
* λ = 提供的请求到达率（请求数/秒；平均和峰值）。引擎中驻留的在途请求数量是一个由利特尔法则（Little's Law）决定的涌现量（对于平均驻留时间W，N ≈ λ · W），而不是本研究中直接扫描的变量。
* L = 延迟SLO（目标TTFT，单位毫秒）

服务负载 vs. 在途并发：在本文中，我们使用λ表示运营商控制的服务请求率（到达服务器的请求数/秒），而不是推理引擎的在途批处理大小。这两个量是相关但不同的：在途并发是GPU在任何瞬间实际批处理的数量，它由λ和每个请求的驻留时间W通过利特尔法则共同决定。本方法论是“并发感知”的，因为它将运营商的服务负载操作点作为成本的一个一级输入——而不是假设固定的GPU利用率——并报告了实现的在途批处理（以及因此的Ceff）如何响应。

保持不变的变量：原则上还有五个参数可以进入公式(1)，但在这里保持不变，以隔离λ的影响。(i) 推理引擎：使用vLLM的默认设置，包括连续批处理和PagedAttention【9, Efficient memory management for large language model serving with PagedAttention by W. Kwon, et al. in SOSP, 2023】；跨引擎的基准测试【3, 14】报告称，引擎的选择会改变Θmax，但不会改变U(λ, L)的形状。(ii) 定价模式：PGPU是Azure的按需标价；预留和竞价实例会使Ceff乘以一个大致恒定的标量（0.3–0.7×），不会改变服务负载与成本的动态关系。(iii) 输入:输出Token比例：统一为512:256，取自ShareGPT衍生分布的中位数，该分布用于服务工作负载【4】；可变的比例会影响prefill与decode的平衡，但不会影响未充分利用的惩罚。(iv) 并行策略：张量并行度（密集模型TP=1，Mixtral TP=2）被视为H的一部分。(v) 请求到达分布：速率为λ的泊松分布。生产环境的LLM轨迹遵循变异系数超过1的Gamma或Weibull到达间隔分布【34, 35】，因此泊松分布（CV=1）是一个规律性假设。我们的补充性Gamma探测（§5.7）发现在C4配置上CV=2时成本影响可以忽略不计，但仅限于一个配置；突发性的真实世界工作负载可能会放大而非减小这里报告的惩罚。因此，我们将这些保持不变因素下的Ceff解释为生产运营商会观察到的成本离散度的保守下界。

3.2 利用率函数

核心洞察：核心洞察是GPU利用率U不是一个可以假设的独立参数（如先前工作），而是由H, M, Q, λ和L相互作用决定的因变量：

公式2
公式2

在低服务负载下，GPU计算单元未被充分利用——GPU等待内存传输，无法填满其执行流水线。随着服务负载增加，实现的在途并发提高了利用率，但由于排队和批处理竞争，延迟也会增加。延迟SLO L作为一个约束，限制了可实现的利用率。

有效成本公式：有效成本则变为：

公式3
公式3

这与基于Token量的模型有根本不同，后者假设：

公式4
公式4

未充分利用惩罚：比率Ceff/Cnaive = Θmax/Θachieved = 1/U捕捉了未充分利用的惩罚——即朴素估算低估真实成本的乘数因子。

3.3 依赖于架构的成本行为

假设：我们假设——并在第5节中通过实验证明——利用率函数U(λ, L)的形状在密集型和混合专家（MoE）架构之间存在系统性差异。密集型模型由于每个Token都会激活所有参数，其扩展行为与实现的在途批处理大小更具可预测性。而MoE模型每个Token只激活一部分参数，导致了不同的内存访问模式和批处理效率特性。这意味着，在一个架构上校准的单一成本公式，即使在相同的硬件上，也会对另一个架构产生不正确的估算。因此，模型架构必须是任何成本估算框架中的一个一级变量。

3.4 交叉点分析

盈亏平衡点定义：给定经利用率调整的成本Ceff，我们将自托管与API的交叉点定义为服务到达率阈值λ*，在该阈值下：

公式5
公式5

这个交叉点会根据所有五个输入变量而变化。先前的工作报告的是单个盈亏平衡点（例如，“当每月Token量超过5000万时，自托管更便宜”），但实际的交叉点是(λ, L, H)空间中的一个曲面，而不是一个单点。

A4 实验环境

A4 实验结果

所有结果均基于42个基准测试配置，GPU成本遵循§4中定义的惯例：单GPU模型按\$6.98/小时计，双GPU的Mixtral按\$13.96/小时计。

A7 补充细节

6.1 为什么现有计算器会失败

根本性错误：我们调查的超过15个计算器都犯了同一个错误：它们将GPU利用率视为用户需要猜测的输入参数（或者默认假设为100%）。利用率不是一个输入，而是请求到达率、模型架构、量化和SLO之间相互作用的输出。一个要求用户输入利用率的计算器，实际上是要求用户去解决他们本想通过计算器避免的问题。这就是为什么主要误差是一个数量级而不是例如2倍的原因：这类工具的整个因果方向都搞反了。

6.2 实际影响

超出计算器范畴的应用：除了计算器本身，请求负载轴在自托管推理的实际预算编制中也基本被忽略：容量规划和基础设施审查将GPU小时费率和每Token费率视为固定输入，而将经验上对实际成本影响最大的变量——请求负载——完全排除在成本模型之外。通过将其恢复为一级输入，本框架能够支持三个实际决策：1. 给定目标工作负载概况，自托管的实际成本是多少？ 2. 在何种流量水平下，自托管比特定的API层级更便宜？ 3. 对于混合策略，自托管和API服务流量之间的路由边界应设在哪里？

惩罚作为配置信号：这种惩罚也是一个配置信号，而不仅仅是计算器错误。本文中最大的乘数出现在请求负载极低（特别是λ=1 rps）的情况下，在这种情况下，有成本意识的运营商不会让一个专用加速器闲置：对于一个深陷成本悬崖的部署，结构性的补救措施是改变配置——整合租户、根据请求负载扩展副本、合并请求，或在交叉点以下回退到无服务器端点——而不仅仅是读取一个更准确的数字。本框架支持这两种解读：一个准确的Ceff(λ)是告诉运营商他们配置过度的诊断工具，而请求负载轴是自动扩展和整合所作用的维度。这也解释了为什么§6.7中分钟级别的离散度是固定部署的瞬态现象，而不是预算项目：一旦机群规模本身具有弹性，瞬时λ下的每Token成本就是一种归因，而不是月度费率。

对成本感知路由系统的贡献：贡献（3）直接关系到成本感知的路由系统。一个在自托管推理和API回退之间动态切换的路由控制器需要一个准确的实时成本模型——这正是本框架所提供的。

6.3 非对称Token定价的优势

自托管的结构性优势：现有分析一直忽视了自托管的一个结构性优势：商业API提供商采用非对称的Token定价，输出Token的收费远高于输入Token。GPT-5.5的输入收费为\$5.00/M，输出为\$30.00/M【19】；Claude Sonnet 4.6输入为\$3.00/M，输出为\$15.00/M【20】；Gemini 3.1 Pro输入为\$2.00/M，输出为\$12.00/M【21】。输出Token的定价高出5-6倍，因为生成是计算密集型且是序列化的——每个Token都需要一次完整的前向传播。自托管模型无论处理输入（并行prefill）还是输出（序列化decode），其GPU基础设施成本是相同的。这种非对称性有一个具体的含义：对于生成密集型的工作负载，有效的API成本远高于聚合的每Token定价。相比之下，自托管没有单独的输入和输出Token收费——尽管输入/输出混合仍然通过prefill/decode平衡影响每输出Token的实际成本（§5.7），因此一个同类比较会将API按其非对称的每Token费率定价，而自托管部署则按其在相同工作负载形状下测量的Ceff定价。

示例说明：作为一个粗略的估算（非实测基准），一个具有100个输入Token和500个输出Token（即5/6的Token是输出）的代码生成管道，在GPT-5.5的标价下，其聚合成本约为(100×\$5+500×\$30)/600 ≈ \$25.80/MTok——远高于通常引用的\$5.00/M输入费率。同样数量的Token在自托管的Qwen3-30B-A3B FP8上服务则没有这样的输出Token溢价：其\$0.209/MTok的饱和成本（在512:256形状下测量）对输入和输出Token按相同的GPU时间费率计费，尽管实际数字仍随工作负载形状变化（§5.7）。这种非对称定价效应恰恰放大了自托管在那些企业最可能考虑基础设施投资的工作负载——代码生成、长文写作、代理工具使用——上的优势。

框架扩展：我们当前的框架对聚合的Token吞吐量进行建模；一个自然的扩展是分离输入和输出Token的经济学，并将非对称定价结构纳入交叉点分析。

6.4 无服务器 vs. 专用部署的谬误

一个常见的误解：基础设施决策者经常问：“为什么不直接使用每百万Token \$X的无服务器API？”表面上看，这是一个直接的成本比较。但事实并非如此。发布的无服务器每Token价格并未附加任何生产服务等级目标。商业提供商并未发布关于首Token时间或Token间延迟在p99尾部的可强制执行的每请求保证；尽力而为的可用性是实际的合同。一个必须满足生产SLO（例如，TTFT p99 ≤ 300 ms, TPOT p99 ≤ 50 ms）的专用自托管部署，其运营成本完全处于不同的范畴，因为为了吸收到达率变化而不违反尾部延迟而预留的容量，正是驱动Ceff偏离Csat的原因。

具体例子：在我们的六阶段实时工作负载（1-50 rps）下，一个在2xH100上的Mixtral-8x7B FP16部署，其分钟级有效成本的最佳值是\$8.23/MTok（表7，“最佳”列，在50 rps饱和分钟观察到）——这仍然是理论饱和成本（Csat=\$0.87）的大约9.5倍，因为平均窗口覆盖了整个到达率的遍历，包括空闲的子区间。一个为了保持TTFT p99余量而固定在饱和点以下的运营商，其成本将严格高于这个数字。而可比模型级别的商业API价格通常报价在每百万输出Token \$12–\$15（§5.6的较低参考层级）。这两个数字是不可比的：一个反映了没有延迟SLA的尽力而为的无状态端点，另一个反映了已承诺p99延迟合同的专用部署。仅根据表面的每Token价格在两者之间做选择是一个范畴错误，类似于在不承认可用性和抢占差异的情况下比较云实例的竞价和预留实例定价。

框架的作用：本文提出的框架使这种不匹配变得可见。一个有生产SLO的组织应该在其SLO允许的到达率下计算Ceff（表4为一个固定SLA示例演示了这一点），然后与无服务器定价进行比较，同时明确承认无服务器路径放弃了对尾部延迟的控制。我们的配套工具vllm-cost-meter，正是因此在其API比较功能前设置了一个--accept-slo-mismatch标志：只有当用户有意识地接受无服务器不提供SLA对应物时，这种比较才有意义。

6.5 如何在操作中使用此框架

三步工作流：该框架旨在让单个基础设施所有者通过一个三步工作流来实际操作。

  1. 第一步 — 部署您选择的配置：选择与您的部署约束相匹配的模型、量化和硬件。本文发布的基准语料库（六个H100配置C1-C6，加上A100跨硬件和敏感性扫描；§7.1）提供了一个起始参考，但不能替代在您自己的硬件上用您自己的工作负载形状进行测量。
  2. 第二步 — 在您自己的工作负载和SLO下进行负载测试：使用您真实的提示长度和输出长度分布、预期的到达模式以及您声明的TTFT/TPOT/E2EL SLO，运行一次扫描（例如，使用vllm bench serve, inference-perf, LLMPerf, 或 GenAI-Perf【22, 23, 24】）。记录在保持SLO的情况下所能达到的最高到达率λ；这是您部署的“有效吞吐量”（goodput），不同于本文报告的原始饱和吞吐量Θmax。
  3. 第三步 — 将观察到的有效吞吐量输入计算器：将SLO下的有效吞吐量代入Ceff公式（公式3），以获得您部署在实际操作合同下的有效成本。将这个数字——而不是Csat，也不是无SLO基准测试的原始Θmax——与任何替代定价进行比较。

工作流的颠覆性：这个工作流颠覆了通常的采购顺序。运营商不是先选择一个价格点然后发现其延迟后果，而是先声明SLO，然后推导出成本。vllm-cost-meter工具直接支持第三步：它通过实时抓取vLLM的Prometheus端点，根据用户声明的SLO预算实时显示观察到的有效吞DASH吞吐量，并随着到达率的变化持续计算Ceff。

6.6 开源工具

vllm-cost-meter：vllm-cost-meter是针对第2节中批评的所有计算器的一个并发感知替代品。

为何是“仪表”而非“计算器”：这是一个深思熟虑的设计选择，而不是缺少功能。计算器要求用户提供模型在其硬件上的真实最大吞吐量——这正是本文认为几乎从未能正确获取、且在实践中被猜测或从供应商基准中复制的、需要经过SLO感知和仔细测量的量。而仪表则颠覆了这种依赖关系：通过抓取运行中服务器自身的Prometheus指标，它从观察到的流量中推导出操作点的吞吐量，因此那个难以获取的分母是被测量的，而不是被假设的。因此，我们发布的是一个读取地面实况的仪器，而不是一个传播猜测的表单。这里描述的六个配置的预计算曲线可作为这些精确部署的有限查找表；我们有意不将它们外推成一个通用计算器，因为一个用未经测量的模型预设值填充的计算器会重现本文旨在纠正的同样基于启发式预设、忽略利用率的错误（参见§2中基于预设的工具）。一个由社区贡献的、由仪表输出（真实观察，从不是预设）填充的社区计算器是一个自然的未来方向。

今日发布的三个部分：
* 基准测试运行器：一个命令即可在选定的到达率网格上对vLLM进行扫描，并输出结构化的CSV文件。
* 成本估算器：给定一个目标λ，通过插值经验曲线，生成一个经利用率调整的美元/MTok成本，以及与用户提供的任何API价格的交叉点。
* 实时仪表盘：抓取vLLM的/metrics Prometheus端点，并随着到达率的变化实时绘制Ceff。

预计算曲线：本文42次运行的预计算曲线随仓库一同发布；运行这些基准测试配置之一的从业者可以在不到一分钟内获得修正后的成本估算，无需运行任何基准测试，而未经测量的部署则需要§6.5中描述的在硬件上进行的扫描。

6.7 实时验证

验证方法：为了在受控基准测试之外验证该框架，我们在相同的H100 NVL硬件上部署了vllm-cost-meter，并与运行所有六个基准配置（C1-C6）的vLLM推理服务器一起运行。该工具是一个客观的实时仪器：在每个时间点，它抓取vLLM的Prometheus /metrics端点，根据观察到的每秒生成Token数和声明的硬件成本计算实时Ceff，并展示瞬时的请求负载/成本关系。一个六阶段的企业工作负载模拟将请求率从1 rps提升到50 rps再降回，模拟了生产部署在一天中可能经历的全部到达率范围。

验证结果：表7总结了结果。在一小时的真实流量中，同一个部署在其最便宜和最昂贵的分钟之间经历了653倍的成本波动——我们将其作为分钟窗口离散度的例证，而非可复现的验证数据（根据下文的警告）。这是一个极端的比率：它对比的是空闲谷底的瞬时分钟与峰值负载的分钟，而不是时间加权平均值。Mixtral FP16在空闲谷底时（当只有少量Token计入整个GPU小时成本时）成本峰值达到每百万Token \$5,379，而在50 rps时降至\$8.23。按小时平均计算，有效成本主要由高λ的分钟决定；653倍这个数字最好被理解为分钟窗口成本归因在接近空闲时的压力测试产物——一个接近奇异的比率，随着窗口延长而下降——而不是一个月的计费乘数。我们引用它以具体说明分钟级别的离散度；底层的每分钟Prometheus数据点并未检入公共语料库（表7记录了聚合的“最佳/最差”列），因此653倍应被视为一个方向性信号，而非可复现的数据点。任何不附带λ的成本数字——即使是平均值——其无意义的程度都远超大多数从业者的想象。

结论：实时验证证明了两件事。首先，并发感知框架产生了可操作的实时估算：同一个部署随着λ的变化描绘出一条可识别的Ceff曲线，其形状与基准扫描预测的相符。其次，未充分利用的惩罚不仅仅是离线基准测试的理论产物——只要λ低于引擎饱和的到达率，它就会在实时操作中立即显现。该工具展示的曲线与运营商通过在自己的工作负载上重新运行基准扫描所描绘的曲线相同；该工具使其在无需单独测量步骤的情况下变得可见。我们所声称的验证是一致性验证：实时的、源自Prometheus的Ceff在相同的操作点上描绘了与在相同硬件上进行的离线基准扫描相同的请求负载曲线——这证实了仪表报告的成本结构是运营商否则必须通过重新运行扫描来重建的。

6.8 范围与未来工作

范围限定：我们有意将主要扫描范围限定在单个H100 NVL节点上的合成定长工作负载——并辅以在A100 80GB PCIe上的针对性验证扫描（§5.9）——以保证可复现性并避免暴露专有的生产数据。主要的基准扫描在禁用前缀缓存和推测解码的情况下运行，从而建立了一个保守的性能下限和成本上限；我们的敏感性探测（§5.7）部分放宽了这些假设，允许了真实的前缀缓存命中并改变了到达过程和I/O形状。启用前缀缓存、推测解码和特定工作负载优化的生产部署将实现更低的有效成本，使得本文报告的绝对成本成为上限而非典型情况的估算。

未来工作：几个扩展方向是自然的：使用可变长度的对话轨迹（例如ShareGPT, LMSYS-Chat-1M【29】）进行验证，将SLO约束作为一级优化目标而非观察输出，对日间流量模式和自动伸缩经济学进行建模，以及扩展到其他硬件代（B200, MI300X）和推理引擎（SGLang, TensorRT-LLM）。该框架的结构设计旨在容纳这些扩展，尽管每个扩展都需要自己的实证验证来确认在新条件下U(λ, L)的形状。

6.9 局限性

多方面局限：我们的基准测试使用合成的定长工作负载，输入为512个Token，输出为256个Token；具有可变长度对话分布的生产工作负载将表现出不同的利用率曲线。我们测试了三种模型架构（密集型、超稀疏MoE、稀疏MoE）；其他架构（如状态空间模型、编码器-解码器）可能表现出不同的成本行为。主要的vLLM数据是在H100 NVL上进行的；我们增加了在A100 80GB PCIe上的跨硬件验证扫描（§5.9）以排除单一硬件的混淆因素，并且负载驱动的价差在那里也得到了再现，但更旧的硬件（V100）或更新的代（B200, MI300X）会进一步改变曲线，这留作未来工作。主要数据使用单一引擎（vLLM）；引擎选择保留了质的悬崖形状但改变了其幅度——同样的Llama 3.1 8B FP16配置在vLLM上价差为24.4倍，而在SGLang上为12.0倍（表6），因为较低的Θmax压缩了空闲到饱和的比率——因此绝对乘数应被理解为引擎相关的。我们改变了提供的请求率，同时将延迟作为输出观察，而不是将其作为SLO输入进行约束，将SLO约束的优化留给未来工作。我们没有对多租户GPU共享进行建模，这可以提高为多个客户服务的提供商的利用率。GPU定价频繁变化；该框架的价值在于方法论，而不是具体的美元金额。

A5 结论

本文的核心发现是17.5–36.3倍的成本差异。在完全相同的H100硬件上，固定模型、精度和GPU分配，仅改变请求到达率，每Token的有效成本在单个配置内就能波动17.5至36.3倍；在所有六个配置和整个负载范围内，成本从每百万输出Token \$0.21到\$15.25不等。这种差异并非极端情况，而是成本方程中的主导项，但却被我们调查的每一个生产成本计算器所忽视。

三个实际启示：
1. 基础设施规划：如果基础设施计划基于按Token计费的计算器，其结果可能存在超过一个数量级的误差——并且总是朝着让自托管看起来比实际更便宜的方向。
2. 架构选择：在我们测试的三种架构上，激活参数数量和内存访问模式，而非总参数数量，似乎是驱动饱和状态经济性的关键。例如，Qwen3-30B-A3B FP8在饱和时的每Token成本比Llama 3.1 8B FP8更低，这颠覆了基于模型大小的直觉。这一发现在A100上的复制实验中也得以证实。
3. 量化策略：FP8并非主要针对密集模型的优化。在我们的测试中，两种MoE架构从FP8中获得的收益比密集模型高出2.2-2.4倍（峰值吞吐量提升+69%至+74% vs. +31%），这一结构性信号应在更广泛的验证后，改变量化策略的优先级。

工具发布：本文发布了vllm-cost-meter工具。它能抓取一个运行中的vLLM服务器的Prometheus端点，并实时展示真实的成本曲线。如果今天对“一百万个Token要花多少钱？”的答案是一个单一数字，那么在下一次基础设施审查之前，请用一条曲线来取代它。

表7：实时验证：在H100 NVL上进行六阶段工作负载模拟（1-50 rps）期间观察到的有效成本（\$/MTok）。共32,401个请求，100%成功。
表7：实时验证：在H100 NVL上进行六阶段工作负载模拟（1-50 rps）期间观察到的有效成本（\$/MTok）。共32,401个请求，100%成功。

A6 附录

7.1 数据和工件可用性

开源发布：配套的vllm-cost-meter工具和原始的每次运行CSV数据文件已在MIT许可下发布于 https://github.com/pChitral/vllm-cost-meter。这包括140次运行的核心语料库——42 次H100 vLLM主要扫描、42次H100 SGLang配套扫描，以及56次A100 80GB PCIe跨硬件扫描——连同I/O形状、前缀缓存和突发性敏感性扫描（§5.7）以及测量稳定性活动（§5.8）的数据。§5中所有的饱和点、Ceff价差、未充分利用惩罚和稳定性CV都可以直接从这些CSV文件中重新推导；§5.7中的可变长度和真实前缀命中探测在文本中进行了总结。在最终版（camera-ready）时将创建一个带版本标签的Zenodo DOI。该仓库旨在作为一个社区基础，将λ轴扫描扩展到更多的硬件、模型架构和SLO约束的场景中。

方法细节中的引用汇总