用于 ML 研究的 GPU · 无需 KYC 的加密货币支付
IteraGPU
方法 02 · 质量、测量与成本

哪个 GPU 在获得相同 ML 结果时成本最低?

首先要比较满足相同质量要求的结果,然后比较在您的日程内获得这些结果所需的预算。更高的吞吐量并不足够:语料库必须完整、输出必须可接受、导出必须完成。本资料提供一套推理协议、一张空白结果表和一个套餐计算;它不发布任何 GPU 性能排名。

01 /

定义什么算作被接受的结果

在测试之前先写下决策:“哪种配置能处理我的所有文档、满足我的最低质量要求、在截止日期前完成,并且投入的预算最低?”确定方案:这里是指离线处理的语料库。交互式应用还需要定义请求到达、并发量和可接受延迟;其排名不能仅凭这次试验推断。

将一整套通过您所有检查的完整输出称为已验证语料库。一个已创建的文件还不算被接受的结果。检查标识符、格式、覆盖率以及与您的用途相关的指标。在查看耗时之前,先写下阈值以及相对于参考值的容差。这样,两种配置在决策上可以是等价的,而不会产生逐位相同的结果。

数据集、质量目标和方案之间的这种区分也存在于 MLPerf Inference 的原则中。以下协议是我们可适配到您项目的工作方法;它既不是 MLPerf 的执行,也不是其认证。

技术来源: MLCommons — 方案、指标与质量目标

02 /

准备输入、参考和清单

您需要一份有权使用的语料库、参考答案或一套评估流程、推理代码,以及能够运行所选模型的环境。将用于调整配置的数据与最终比较的语料库分开。如果您在查看最终语料库之后调整阈值,请准备一次新的独立评估来支撑结论。

为每个输入分配一个稳定的标识符。保留语料库的指纹、处理顺序、模型与 tokenizer 的版本、代码和依赖项的版本。清单还应说明所用的 GPU、精度、量化、编译、注意力后端、padding 策略和最大长度。不同的截断会改变需要比较的工作量。

记录实际存在的驱动与后端。对于 AMD 变体,请在官方矩阵中核对系统、GPU、ROCm 与框架的组合。查阅过的文档或显卡名称并不能证明该环境已安装。如果两次试验之间的软件栈不同,结论应针对实际测试过的完整配置。

技术来源: AMD — ROCm 兼容性矩阵

03 /

示例:对同样的 1 000 条文本进行分类

以下是一个用您自己的数据构建的实验,不预设任何性能结果。您希望把 1 000 条文本分到项目的类别中。预留 600 条短文本、300 条中等长度和 100 条长文本;用所选的分词器定义边界,并保持各类别分布具有代表性。这种划分为协议示例,既不是提供的语料库,也不是通用的比例建议。

用相同的模型、相同的精度、相同的顺序和相同的 padding 规则,比较 1、4 和 8 的批次。第一轮的唯一变量是批次大小。第二轮可以改变精度或硬件,同时明确固定其他选择。按长度分组属于新的变体,必须声明,因为它改变了工作的组织方式。

对每一轮运行,导出 1 000 条预测及其标识符。校验必须准确找到所有预期标识符,无重复、无遗漏。保留错误的预测:它们用于质量计算。删除困难样本会人为抬高分数,并缩小实际处理的语料库。

首次测量前需填写的质量约定
检查项示例规则需写明的决定
覆盖1 000 个预期标识符各出现且仅出现一次任何缺失或重复都会使语料库失效
格式每条文本一个允许的类别;若导出数值,须为有限值模式与允许的类别
整体质量一个主要指标,例如 macro-F1相对于基准的最低阈值与容差
重要案例对项目关键类别或长度的检查预先确定的子组与标准
截止时间在截止时间前完成预测评估并取回文件结束日期、时间及时区
04 /

区分启动、预热与测量轮次

将必要的下载、安装、加载和编译与稳定后的处理分开记录。它们可以从某一轮次的计时中排除,但仍会占用一部分租用时间。为所有变体设定相同的预热规则:覆盖的输入、轮次数量以及重编译的处理方式。不要在看出哪个变体受益后再调整这条规则。

定义主阶段的时间边界。对于这个离线示例,请测量语料读取、分词、传输、推理以及预测结果在主机上的落地耗时。然后分别对评估和交付物写入计时,以构成完整的流程。仅限 GPU 计算的时长不能直接与这一处理时间相比较。

CUDA 操作是异步的:宿主计时器必须在开始前等待先前操作完成,在结束前等待被测工作完成。CUDA 事件适用于边界定义正确的 GPU 范围。对于单个操作,torch.utils.benchmark.Timer 可处理预热与同步。在各变体之间保持相同的测量边界。

技术来源: PyTorch 2.14 — CUDA 异步执行 · PyTorch — 用 torch.utils.benchmark 测量

05 /

重复并保留失败结果

为这次初步比较,每个变体安排五轮完整运行。轮换它们的顺序,例如 1–4–8、4–8–1、8–1–4,以免总是同一个变体排在前面。保持进程、缓存和预热策略不变。这五轮描述的是您的小规模系列;仅凭它们并不能证明长期稳定性。

原始表格中的一行代表一次尝试的运行,包括中断。它将变体与语料库同参数、时长和质量判定关联起来。expected_ids 和 observed_ids 字段记录条目数量;ids_match 确认两个集合是否相等,该检查在单独保存的预测文件中完成。corpus_accepted 包含该次运行的判定结果。请在 notes 中记录错误和输出路径。如果某项测量缺失,请将其单元格留空并说明原因。没有 GPU 并不等于零秒或零字节的测量值。

如果 batch 8 在长输入上超出内存,请保留失败的那一行以及已完成条目的数量。不要悄悄用更小的 batch 替换这次运行。恢复设置会成为另一个独立的变体;其耗时和尝试次数都计入总结。中断或格式错误绝不会因为速度快就成为经济上的成功。

一次完整运行的吞吐量 = 已处理条目数 ÷ 所声明范围的时长。质量判定仍是单独的一项检查。
06 /

如何解读时长而不对五次试验过度解读

请列出五次原始时长、其中位数、最小值和最大值,以及成功和失败的次数。中位数描述的是这些观测值的中心;它并不会消除那些意外事件。如果某次运行因已记录的外部原因被排除,请保留其记录,并对所有变体应用相同的排除规则。

不要把基于五次运行计算出的 p95 当作对慢速情况的稳健估计。要研究请求延迟,请采集一组合适的单次时间,并附上到达场景和并发度。五次语料库时长和 1000 次请求的延迟不是同一个总体。

如果观测到的离散程度与中位数之间的差距相当,那么这组数据还不足以区分各选项。请在统一协议下增加重复次数,或考察某个具体原因:加载、输入形状、编译、并发活动。避免只保留每张卡最好的一次运行。

07 /

更改精度后如何验证质量

要比较 FP32、BF16 或某种量化,请从相同的输入和相同的基准出发。评估格式、主要指标以及预先设定的子组。某个超出你容差的变体可能对另一个目标有价值;但事后降低阈值,并不会让它加入同等质量的比较。

请记录所使用的随机种子和确定性选项。即使种子相同,PyTorch 也不保证在不同版本、平台或 CPU 与 GPU 执行之间具有完全可复现性。因此请明确你希望复现的是什么:完全相同的输出、有界的数值偏差,还是可接受的业务质量。对于随机协议,请准备多个共用的种子,并分别保留其结果。

技术来源: PyTorch 2.14 — 可复现性的范围与局限

08 /

将内存作为可行性标准

某个选项必须先能在包含长输入的情况下跑完整个语料库,然后才能比较其成本。请记录每个设备的内存峰值以及计数器的统计范围。在 PyTorch 中,memory_allocated 跟踪张量,memory_reserved 跟踪分配器管理的内存:这两个值不能相加。它们对应的峰值可能出现在不同时刻。

内存文件夹中的 notebook 有助于区分估算与观测。其中的练习不能替代对你自己模型的测量:请加载你的环境,保留相关参数,并重新运行你的负载。某张卡标称的容量和按批计价的价格,并不能推导出吞吐量、互连性能或模型在多块 GPU 上的自动分配。

技术来源: PyTorch 2.14 — 内存计数器与分配器

09 /

用完整日历选择时长

所需时长并不只是 GPU kernel 耗时之和。请构建一个从租用实例上的准备到取回交付物为止的访问窗口:安装、检查、预热、对比、预留的重试、评估和导出。再加上你仍需保留该租用实例的等待时段。当任务相互重叠时,请按真实日历推算,而不是把它们的时长重复相加。

日程示例,不假设速度:您希望保留周一 9 点至周五 9 点的访问权限,处于同一时区且不涉及夏令时切换。该时间窗口覆盖 96 小时。它超出 3 天套餐的 72 小时,并落在 7 天套餐的 168 小时之内。这并不能证明您的任务会按时完成:其耗时仍需实测。

该计算器允许您填入总时间窗口,并显示 3 天、7 天和 30 天套餐。能覆盖日程的套餐即成为候选。如果任务周期超出所选时段,请修改计划,或明确为所需的额外时段单独核算费用;不要假设会自动延长。

需要填入计划的边界节点
阶段可观察的完成标志时长
准备环境已加载且最小测试通过需实测或规划
对比所有计划内的运行均有记录在案的状态需实测
评估与返工每项输出都有结论,每次失败都有决策需实测或规划
导出文件已取回、打开并在目标端校验需实测
预期团队的复核与可用性已纳入日程需规划
10 /

用我们的套餐计算已发生成本

一次租用的预算是单批套餐价格乘以批数。每个有效语料库的成本则用总金额除以在既定范围内实际验收通过的可用语料库数量。如果没有任何语料库通过验收,该比值无定义。而已发生的支出仍留在结算中。

以下价格来自我们的目录,版本日期为 2026 年 9 月 24 日。它们用于说明计算规则,并不表明哪种 GPU 能最快完成您的任务。一个 B200 批已包含两块卡:把它的价格再乘以二,就会把这些卡重复计算。因此,两批 RTX 4090 租用 7 天共计 220 USD;一批两块 B200 租用 7 天为 2 071 USD。

一次短时运行不会把套餐变成按小时计费。即使有一部分时段未被使用,计算器仍按套餐总额计算。对于更大范围的项目预算,请单独记录其他实际适用的支出及其依据。不要把某一方案实测到的成本与另一方案遗漏的项目混在一起。

已发生成本 = 单批套餐价格 × 批数。每个有效可用语料库的成本 = 已发生成本 ÷ 已验收的可用语料库数量(须严格为正)。
IteraGPU 各批次价格示例,以 USD 计——2026 年 9 月 24 日目录
批次配置3 天7 天30 天
1 × NVIDIA GeForce RTX 4090 24 GB47,14110,00390,00
2 × NVIDIA B200 SXM,每块 180 GB887,572 071,007 391,00

技术来源: IteraGPU — 目录套餐

11 /

统计有效交付物,而非重复测量次数

同一基准测试的五次重复用于观察离散程度。它们不会仅仅因为写出了五个文件就变成五个有效的生产语料库。请在任务开始前定义好预期交付物,每个通过验收的交付物只计一次。如果实际工作涉及多个语料库,每种配置都必须处理相同的语料库并采用相同的质量规则。

在计算器中,只要有效交付物尚未真正完成并通过验收,请将语料库数量留空。质量复选框用于确认您自己的检查;该工具不会读取您的预测或指标。请仅填写实际核实的数量。任务周期可以是规划假设,但容量预测不能替代已验收的结果。

最终结算会为每种可接受的配置汇总:质量结论、原始耗时、任务周期、已使用套餐以及已验收的交付物数量。快速方案可能对紧迫的截止日期有用,但未必最便宜。两种落在同一日程内的方案,可通过其已发生成本、失败情况或仍存在的不确定性来区分。

12 /

下载协议并保留可复用的证据

IteraGPU Lab v1 资料包汇集了本次对比和内存测量的支持材料。请先从 README 和质量协议入手,然后用您的运行数据补全原始表格。性能单元格在执行前保持空白;价格属于目录数据,与实测数据分开。

要用 7 天时间为两批 RTX 4090 计算费用,请把 calcul_forfaits.py 和 tarifs-forfaits.csv 放到同一个文件夹中,在该文件夹里打开终端,然后用 Python 3.10 或更高版本运行下面的命令。它会显示两块 GPU 的套餐价 220.00 USD。可选参数 --accepted-results 接收您实际完成并验证的不同有效语料整数数量。在这项结论尚不存在时请省略它:脚本此时只计算套餐价,不会凭空编造单个结果的成本。

请把清单、输入哈希、预测、判定和尝试记录表保存在一起。决策说明记下所选设置、覆盖的负载以及选择理由。您可以将其与 IteraGPU 账本中的租用记录对照,并在更换模型或版本时精确复现该实验问题。

这一离线协议本身并不能界定交互式服务、训练至收敛或其他数据集。对于这些用途,请先重新定义有效单位和检查项,再进行对比。所提供的文件用于准备和记录您的试验;本资料不包含目录中任何配置之间的实测对比,也不包含观测到的节省。

shell
python calcul_forfaits.py --gpu rtx-4090 --days 7 --lots 2
工具 / 套餐

计算你的训练活动预算

选择一个配置和你的组合数量。表格使用的是我们目录中的价格。然后填写你自己的时间安排假设;此处不预测任何计算时间。

共 1 块 GPU · 每块 GPU 24 GB · 每个批次的价格包含 1 块 GPU。

请包含租用前的准备工作、计算、评估、计划中的中断以及导出。时间窗口在套餐范围内并不保证处理成功。

一个语料库即你的协议所定义的完整工作批次。只计入已完成并验证的有效语料库;基准测试的重复不算作新的有效语料库。计算器不衡量质量。

NVIDIA GeForce RTX 4090 24GB 套餐 · 1 批 · USD
时长套餐总价已输入时间窗口USD / 已验证语料库
3 天 · 72 小时USD 47.14待填写需要满足质量和数量要求
7 天 · 168 小时USD 110.00待填写需要满足质量和数量要求
30 天 · 720 小时USD 390.00待填写需要满足质量和数量要求

每个语料库的成本 = 套餐总额 ÷ 已验证的完整语料库数量。套餐需整体支付;该比率不构成小时费率,也不属于按用量付费。

如果时间窗口超过 30 天,请设定新的日程或多个租赁时段,并核对其可用性。计算器不假设自动续期,也不假设容量持续可用。