自托管 LLM 每百万 Token 成本：可复现的 GPU 成本模型

自托管 LLM 每百万 Token 成本：可复现的 GPU 成本模型

计算自托管 LLM 每百万 Token 成本的可靠方法，是用完全负载的服务成本除以你的工作负载实际接收的 Token 数量，而不是除以 GPU 宣传的峰值吞吐量。

这一区别至关重要。GPU 的基准测试表现可能很好，但在生产环境中，如果它在付费时间内处于闲置状态、处理异常长的提示词、重试失败请求，或生成被你的产品拒绝的输出，其成本仍可能很高。本指南提供了一个可重复使用的自托管 LLM 每百万 Token 成本模型、一个工作表、一个完整示例，以及一种公平比较自管端点与托管 API 的方法。

更新于 2026 年 10 月 16 日。以下所有美元金额和吞吐量均为示例输入，并非供应商报价或性能声明。

自托管 LLM 每百万 Token 成本公式

如需从输出 Token 的角度计算，请使用：

cost per 1M accepted output tokens =
  fully loaded hourly serving cost
  / (active-window output tokens/second × 3,600 × paid-time utilization × success rate × acceptance rate)
  × 1,000,000

其中：

分母是关键。自托管 LLM 每百万 Token 成本应当是每个有用单位的成本，而不是每项 GPU 基准测试的成本。

避免重复计算规则

使用以下两种测量路径之一：

1. 测量活跃窗口吞吐量，然后乘以付费时间利用率。
2. 测量整个付费时间段内接收的 Token，然后将利用率设为 1，因为观测中已经包含闲置时间。

不要同时使用两者。对已经包含闲置时间的实际时钟吞吐量再应用利用率系数，会使每 Token LLM 推理成本看起来比实际更高。若在活跃窗口基准测试中省略利用率，则会使其看起来比实际更低。

可复制的每百万 Token GPU 成本工作表

针对每种模型、硬件拓扑、区域和工作负载形态，在电子表格中各建一行。不要将短对话基准测试与长上下文生产工作负载混在一起。

该工作表使自托管 LLM 每百万 Token 成本计算可审计：另一位运营人员应能够替换输入值、重新运行测量窗口并复现结果。

这是示例计算，并非任何 GPU 的价目表。用实测值替换这五个输入，即可得到你自己的每百万 Token GPU 成本。

完整示例：为什么利用率会改变结果

保持该假设端点的完全负载每小时成本 $4.07 和活跃窗口输出吞吐量 900 Token/秒不变。输入项的微小变化会显著改变单位成本。

要点并不是购买某一种特定加速器，而是：自托管 LLM 定价是一个运维与吞吐量模型。如果更高每小时成本的节点拥有足够的内存、批处理余量和需求，能够持续完成更多有用工作，那么它可能带来更低的每个已接受输出成本。一旦将闲置容量和重试纳入分母，较低的小时费率可能反而失去优势。

在基准测试前区分预填充与解码

LLM 服务并非单一同质的工作负载。推理包含上下文处理（预填充）阶段和生成（解码）阶段；NVIDIA 的 TensorRT-LLM 指南明确将二者视为独立阶段，并强调针对工作负载进行调优。在将任何醒目的每秒 Token 数字视为具有代表性之前，请先查阅 TensorRT-LLM 性能调优指南。

• 长提示词、检索上下文和大型附件会给预填充和 KV 缓存带来压力。
• 长回答、代码生成和智能体推理会给解码容量及每个输出 Token 的耗时带来压力。
• 高并发使调度器行为、批处理、缓存驻留和内存余量成为价格模型的一部分。

分别记录提示词和输出的分布。对于一个输入 20,000 个 Token、输出 300 个 Token 的检索密集型助手，仅考虑输出的经济性可能会忽略真正的瓶颈。对于一个输入 2,000 个 Token、输出 4,000 个 Token 的编程工作流，解码可能占据主导地位。

要进行严谨的自托管 LLM 每百万 Token 成本比较，至少应维护以下三种视图：

从生产遥测数据中测量分母

不要从硬件规格推断已接受吞吐量。服务栈应导出使计算可复现的输入数据。

例如，vLLM 为提示词 Token、生成 Token、请求完成、准入拒绝、排队时间、预填充时间、解码时间、KV 缓存使用量、首 Token 时间以及每输出 Token 延迟提供了 Prometheus 指标。这些数据足以构建测量记录，而不是根据基准测试猜测。vLLM 的指标参考列出了当前的指标名称及其含义。

为每次运行捕获以下记录：

measurement_window_start/end
model_id and weights_precision
serving_engine and version
gpu_sku, gpu_count, interconnect, region
input_tokens_p50/p95 and output_tokens_p50/p95
concurrency and request-rate distribution
prompt_tokens_total and generation_tokens_total
request_success_total and admission_rejections_total
time_to_first_token_p50/p95 and time_per_output_token_p50/p95
KV-cache usage and OOM/timeout counts
paid capacity hours and fully loaded hourly cost
acceptance-rule version and accepted-output count

硬件遥测很有用，但它是一种诊断手段，而不是单位成本的分母。NVIDIA 的 DCGM 性能分析文档指出，活动度是区间平均值，应与具有代表性的工作负载吞吐量相关联。使用DCGM 性能分析指标来调查究竟是计算、内存带宽还是互连行为限制了运行；不要用单一的 GPU 利用率百分比替代付费时间利用率。

构建完全加载的分子

GPU 租赁价格是一项输入，而不是答案。要公平地计算 LLM 服务成本，请纳入同一测量窗口所需的容量成本和运维成本。

对于试点项目，请报告两个指标：

仅 GPU 的每 100 万 Token 成本
全成本的每 100 万个已接受 Token 成本

两者之间的差距并非错误；它是自托管服务的运营成本。这使自托管 LLM 定价决策可供审计。

纳入重试和被拒绝的输出

生成的 Token 并不自动等同于有用的 Token。一次请求可能在超时、生成无效 JSON、工具调用失败、违反策略规则或未达到质量阈值之前，消耗预填充和部分解码容量。

使用产品团队可以复现的接受率调整：

已接受的输出 Token =
  生成的输出 Token
  × 执行成功率
  × 产品接受率

如果接受情况在请求级别进行衡量，请记录确切规则：评估器版本、采样集、模式验证器、人工审核协议或任务成功事件。未对规则进行版本控制就更改规则，会使成本趋势失去意义。

这也是原始的每 Token LLM 推理成本可能具有误导性的原因。某个配置即使将吞吐量提高 30%，但若降低了已接受任务的成功率，在产品层面的成本可能更高。

在相同单位下比较自托管与托管 API

自托管购买的是容量。托管 API 购买的是用量。只有当分子和分母一致时，两者才具有可比性。

当 API 基准以相同单位表示时，使用以下盈亏平衡吞吐量检查：

所需活跃窗口输出 Token/秒 =
  全成本每小时服务成本 × 1,000,000
  /（托管 API 每 100 万个已接受输出 Token 的成本 × 3,600 × 利用率 × 成功率 × 接受率）

在做出决定之前，请在两种路径中对齐以下控制项：

• 相同的模型，或经过明确评估且质量等效的模型。
• 相同的提示词和输出长度分布。
• 相同的延迟 SLO 和并发形态。
• 相同的重试、回退和接受规则。
• 对缓存命中、工具失败和已取消工作采用相同的处理方式。

如果直接 GPU 控制、自定义权重、硬性部署位置要求或专用内核栈是必需条件，即使成本高于托管基线，自托管仍可能是正确选择。如果流量低或呈突发性、模型经常变更，或者团队不希望运营推理基础设施，按用量计费的 API 可以承担利用率风险。

如需更广泛的采购比较，请参阅 Flatkey 的GPU 云与模型 API 指南和GPU 租赁价格指南。当不需要直接 GPU 控制时，托管路径是一个有用的基准：Flatkey 通过一个余额提供统一的模型和工具 API，因此团队可以将托管路径与其自托管计算进行比较，而无需维护单独的提供商密钥。使用相同的测试集和接受规则启动 Flatkey API 基线测试。

七步采购测试

将此自托管 LLM 每百万 Token 成本框架作为采购材料，而不只是工程基准。它应准确展示哪些工作负载、容量和质量假设改变了结果。

1. 定义单位：输入 Token、输出 Token、混合 Token、已接受响应或已接受任务。
2. 在贴近生产环境的流量下测量活跃窗口吞吐量，而非使用单个合成提示词。
3. 测量每个付费副本和热备用节点在付费时间内的利用率。
4. 将所有运营成本加入每小时分子。
5. 对成功和接受规则进行版本控制，然后计算已接受输出。
6. 通过托管 API 基线运行相同的工作负载。
7. 在预留容量之前，一并审查成本、p95 延迟、可靠性、质量和工程工作量。

自托管 LLM 成本模型中的常见错误

使用峰值基准吞吐量。峰值对于比较受控设置很有用，但它并不是生产工作负载组合的预期吞吐量。

将 GPU 利用率称为容量利用率。繁忙的 GPU 仍可能连接到一个相对于付费需求而言规模过大的端点。对于单位经济效益，请使用付费时间利用率；并使用硬件遥测来诊断原因。

重复应用利用率。请选择活跃窗口吞吐量加利用率，或者选择已经包含空闲时间的实际时钟吞吐量。

忽略提示 Token。即使产品主要按输出计费，长上下文也会增加预填充和 KV 缓存压力。

将每个生成的 Token 都视为被接受。重试、无效工具参数、模式失败和质量拒绝都是需要付费的工作。

仅将 GPU 账单与 API 标价进行比较。工程、支持、存储、网络、可观测性和预留容量应纳入同一计算。

如需了解完整决策流程（何时自托管能实现成本效益、GPU 内存选型、工具以及分步服务器设置），请参阅我们的自托管 LLM 指南。

常见问题

如何计算自托管 LLM 每百万 Token 的成本？

用完全加载的每小时服务成本除以每个付费小时内被接受的 Token 数，然后乘以 1,000,000。应使用实测的、符合生产环境特征的吞吐量、付费时间利用率、成功率和接受率，而不是理论 GPU 峰值。

GPU 每百万 Token 成本是否等同于 LLM 每 Token 推理成本？

GPU 每百万 Token 成本可以是仅涵盖 GPU 的基础设施指标。LLM 每 Token 推理成本应包含相关的运营成本分子以及明确定义的分母。对于产品决策而言，每个被接受的响应或任务的成本通常是更稳妥的配套指标。

我应该使用输出 Token 还是总 Token？

当提示和输出成本存在不同瓶颈时，应同时使用两者。对于生成式工作负载，输出 Token 易于比较；对于长上下文检索工作负载，总 Token 或加权 Token 能更好地反映实际情况。将自托管与 API 进行比较时，请保持单位一致。

自托管何时能节省成本？

当需求稳定、容量保持较高利用率、模型和部署稳定且直接控制能够带来价值时，自托管更有可能节省成本。当流量呈突发性、模型选择经常变化，或运营开销超过容量节省时，则不太可能节省成本。

结论

可靠的自托管 LLM 每百万 Token 成本计算方式，是用完全加载的付费容量除以被接受的吞吐量。分别测量预填充和解码，一次性计入空闲时间，对接受规则进行版本管理，并以相同单位比较托管基准方案。这样就能将 GPU 报价转化为可直接用于决策的成本模型。

技术参考资料

• vLLM 指标参考
• NVIDIA TensorRT-LLM 性能调优指南
• NVIDIA DCGM 性能分析文档