这是大语言模型延迟-吞吐量基准测试系列的第三篇博文，旨在指导开发者如何通过估算总体拥有成本 (TCO) 来确定 LLM 推理的成本。
有关基准测试和参数的常用指标的背景知识，请参阅 LLM Inference Benchmarking：基本概念。请参阅 LLM Inference Benchmarking 指南：NVIDIA GenAI-Perf 和 NIM，了解如何在您的应用中使用 GenAI-Perf 和 NVIDIA NIM。
简介
大语言模型 (LLMs) 已成为现代软件产业不可或缺的一部分，其功能类似于构建许多应用的“操作系统”基础层。这些应用包括 AI 助手、客户支持代理、编码助手和“深度研究”助手。
正如 DeepSeek R1 模型系列所示，算法和模型效率方面的最新进展降低了训练和推理成本。随着效率的提高，LLM 应用有望变得更加经济实惠和普及，消耗更多的计算资源 (也称为 Jevons paradox) 。
在准备大规模部署生成式 AI 系统和应用时，企业必须解决的一个问题是，如何估算这些推理应用所需的基础设施以及总体拥有成本。在本文中，我们将通过详细指导和分步分析来解决此问题。
在本博文的其余部分，我们列出了要遵循的步骤：
- 完成性能基准测试。这将生成调整基础设施规模所需的数据。
- 分析基准数据。根据有关延迟和吞吐量的性能数据，我们可以估算模型实例的数量以及以可接受的服务质量为预期用户群提供服务所需的服务器数量。
- 构建 TCO 计算器。这有助于更轻松地探索不同的部署场景、权衡取舍及其成本影响。
性能基准测试
确定规模并估算 TCO 的前提条件是对每个部署单元 (例如 inference server) 的性能进行基准测试。此步骤的目标是测量系统在负载下可以产生的吞吐量和延迟。这些吞吐量和延迟指标，以及服务质量要求 (例如最大延迟) 和预期峰值需求 (例如最大并发用户数或每秒请求数) ，将有助于估算所需的硬件，例如调整部署规模。反过来，配置信息是估算给定解决方案的总体拥有成本 (TCO) 的先决条件。
NVIDIA GenAI-Perf 是一款以客户端 LLM 为中心的基准测试工具，可提供关键指标，例如首次令牌时间 (Time to First Token, TTFT) 、令牌间延迟 (Intertoken Latency, ITL) 、每秒令牌数 (Token Per Second, TPS) 、每秒请求数 (Requests Per Second, RPS) 等。有关这些指标及其衡量方式的基础说明，请参阅我们之前关于 LLM 性能基准测试的博文。
对于使用 NVIDIA NIM 微服务部署的 LLM，我们提供分步指南，以轻松衡量实例的性能。然而，GenAI-perf 是一款多功能工具，可以支持任何其他兼容 OpenAI 的 API，例如 vLLM 或 SGLang。GenAI-perf 还支持通过 NVIDIA Dynamo、NVIDIA Triton 推理服务器和 NVIDIA TensorRT-LLM 后端部署的 LLM。
分析基准数据
收集原始基准数据后，系统会对这些数据进行分析，以深入了解系统的各种性能特征。阅读我们的 LLM 推理基准测试指南，其中我们使用 GenAI-perf 收集 NIM 性能数据，并使用简单的 Python 脚本分析数据。
例如，GenAI-perf 提供的性能数据可用于建立 latency-throughput 权衡曲线，如图 1 所示。
此图中的每个点都对应一个“并发”级别，例如，在整个基准测试过程中，系统在任何给定时间内收到的并发请求数量。x 轴表示以毫秒 (ms) 为单位的 TTFT 延迟，而 y 轴表示每秒请求 (req/s) 的吞吐量。可以使用 GenAI-perf 数据构建类似的图形，使用 TTFT、ITL 或端到端请求延迟的延迟指标，而吞吐量指标可以是 RPS 或每秒 token 数 (TPS) 。
在大多数情况下，需做出以下tradeoff：
- 在低并发情况下，系统仅服务少量并发请求。延迟较低，但吞吐量也较低 (请参见图 2 中图的左上角) 。
- 在高并发下，系统可以使用批处理效果高效地服务更多请求，从而提高吞吐量。但是，这会以延迟增加为代价 (请参见图的右上角) 。
在评估 FP4、FP8 和 BF16 等部署格式时，推理速度、内存使用量和准确性之间的权衡可以在 Pareto 前端可视化。此曲线突出显示了在不影响其他指标的情况下无法改进的最佳配置，帮助开发者为其工作负载选择最高效的精度。
Pareto 前端由在给定延迟级别 (例如第一个 token 的时间) 实现最高吞吐量 (例如每秒请求数) 的部署配置组成。如果没有其他选项能够以相同或更低的延迟提供严格意义上的更高吞吐量，则部署选项为 Pareto-optimal。在视觉上，Pareto 前端由最接近图表左上角的一组点表示，其中吞吐量得到最大化，同时保持最小的延迟。
基础架构配置
为计算给定 LLM 应用所需的基础架构，我们需要确定以下限制条件：
- 延迟类型和最大值。这通常取决于应用程序的性质。例如，对于具有实时交互式响应的聊天应用程序，将第一个 token 的平均时间保持在 250 毫秒或以下，以确保响应速度。
- 计划峰值请求/秒。考虑系统预计要服务的并发请求数量。请注意，这与并发用户数量不同，因为并非所有用户都会同时收到活动请求。
根据此信息，排除性能图表中不合格的部分 (在本示例中，为 250 ms 行右侧的任何数据点) 。在满足延迟限制的其余数据点中，我们希望选择吞吐量最高的数据点，这是最经济的选项，如图 3 所示。
注意：此图表假设所有部署选项均采用相同数量的 GPU。若非如此，则应将每秒请求数指标归一化为每个 GPU 每秒请求数，以获得共同的比较依据。
阅读图表中的每秒可优化请求数。这是每个实例实现的吞吐量。还应记录每个实例使用的 GPU 数量。
接下来，我们计算所需的模型实例数量，如下所示：
- 模型实例的最小数量：计算方法是：将计划的峰值请求除以每个实例每秒可实现的最优请求。
构建 TCO 计算器
要估算所需的硬件和软件许可证数量以及相关成本，请按照以下步骤和假设示例进行操作
首先，收集并识别硬件和软件对应的成本信息。
| 硬件成本 | 示例值 |
| 1x 服务器成本 (initialServerCost) | 320000 美元 |
| 每台服务器的 GPU 数量 (GPUsPerServer) | 8 |
| 服务器折旧周期 (以年为单位) (depreciationPeriod) | 4 |
| 每年每台服务器的托管成本 (yearlyHostingCost) | 3000 美元 |
| 软件成本 | 示例值 |
| 每年的软件许可成本 (yearlySoftwareCost) | 4500 美元 |
接下来，按照以下步骤计算总成本：
- 服务器数量的计算方法是：每个实例的实例数乘以 GPU 数，然后除以每台服务器的 GPU 数。
- 服务器年度成本的计算方法是：初始服务器成本除以折旧期 (以年为单位) ，再加上每台服务器的年度软件许可和托管成本。
- 总成本的计算方式为所需服务器数量乘以每台服务器的年度成本。
总成本可以进一步细分为每服务卷的成本，例如每 1000 个提示的成本，或每百万个 token 的成本，这些都是行业中流行的成本指标。
- 假设正常运行时间为 100%，则每 1000 个提示所产生的成本是指每年的服务器成本除以服务器一年内可以处理的请求总数。这可以根据实际正常运行时间分数进行调整。
- 每 100 万个 token 的成本将输入和输出相结合。我们已经有了每 1000 个提示词 (或请求) 的成本。请注意，我们还有与这些提示相关的用例，即其输入和输出序列长度 (ISL 和 OSL) 。因此，我们可以计算每 100 万个组合 token 的成本，如下所示：
- 每 100 万个输入/输出 token 的成本使用输入和输出 token 之间的成本比率计算得出。由于输出 token 通常需要更多时间才能生成，因此大多数商用 LLM-as-a-service 提供商都有单独的输入和输出 token 成本。
| Token 类型 | 参考成本 |
| 100 万个输入令牌 (1M inputPrice) | 1 美元 |
| 100 万个输出令牌 (1M outputPrice) | 3 美元 |
每 1,000 个提示的参考成本：
最后：
总结
在本系列博客中，我们介绍了为 LLM 应用构建 TCO 计算器的完整流程。我们介绍了设置推理服务器、测量性能特征、估算所需的硬件基础设施，然后确定相关成本要素，以纳入总拥有成本（Total Cost of Ownership）方程。这种方法将帮助用户为构建和大规模部署 LLM 应用做好准备。
查看以下资源：
- 要详细了解 TCO 计算方法并实践实践，您可以按照自定进度学习“Sizing LLM Inference Systems”在线课程。
- 如需详细了解 FLOPS 平台架构对 TCO 的影响，请阅读博文 NVIDIA DGX 云推出即用型模板来对 AI 平台性能进行基准测试，以及一系列即用型模板和性能基准测试方法。
- 阅读《The IT Leader’s Guide to AI Inference and Performance》，了解如何降低每个token的成本并更大限度地利用AI模型。
