1 算力效率与成本要回答什么
训练模型时，团队很容易先问“需要多少张 GPU”。真正影响方案的却是：为了在截止时间前得到满足质量要求的模型，需要消耗多少资源，其中多少资源确实推动了训练，又有多少消耗在等待、重复和闲置上。算力效率把资源投入与有效工作联系起来，成本则把这些投入换算成可比较的支出。买到更高的峰值能力，不能直接保证实验更快完成，更不能保证每个合格模型更便宜。
本课以公开的 CIFAR-10 图像分类任务为主线。它包含 10 个类别，官方提供 50000 张训练图像与 10000 张测试图像。我们从训练部分固定划出 45000 张用于训练、5000 张用于验证，保留测试集到方案确定后使用。比较资源方案时，模型结构、图像增强规则、随机种子集合和质量门槛都要记录。否则某次训练虽然更便宜，却可能只是少训练了几个轮次，或用了更容易的验证样本。
质量门槛不能只有总准确率。可以记录各类别 precision、recall 与宏平均 F1，检查某个类别是否被整体成绩掩盖。precision 关注预测为某类的样本有多少正确，recall 关注真实属于该类的样本找回多少，F1 综合这 2 项。若任务改为公开流失预测表格，可用合同期限、历史月费、服务类型等预测时已知特征，同时报告 AUC 和指定阈值下的召回率。费用结算后才出现的流失原因不能作为输入，那会造成数据泄漏，让虚假的高质量污染成本比较。
我们把“有效”限定为：在一致的数据规则下，为达到既定质量门槛所必需、能够解释的训练或评估工作。合理的验证、检查点保存和故障恢复都可能是必要开销；它们不直接产生训练浮点运算，却保护结果的可信度。相反，路径错误导致重复下载、资源未释放、相同失败参数被反复提交，都应独立计入浪费。不要把所有非计算时间都删除，也不要把所有已付费时间都称为有效训练。
因此本课同时回答 3 个问题：资源有没有被分配出去，分配后的资源有没有推进任务，推进的任务有没有得到合格结果。它们分别对应资源管理、运行效率和实验价值。任何单项指标都不足以替代其余指标。以下数字均为教学用测算，目的是展示口径与推理方法，不代表特定硬件的实测性能或市场报价。
2 MFU、利用率与单位成本
“GPU 利用率很高”常常只说明监测窗口内设备持续有工作，并不说明完成了多少有用的模型运算。监控系统显示的忙碌比例、显存已用比例、资源分配比例，是 3 种不同指标。显存装满可能只是缓存了大批张量；资源已分配可能只是进程在等数据；设备持续忙碌也可能在做额外复制。汇报数字时必须同时写出对象、采样窗口和分母，避免把相似名称当成同一件事。
MFU 是模型浮点运算利用率，入门时可理解为“模型所需的理论运算吞吐，占设备理论峰值吞吐的比例”。近似写为：MFU＝每步模型理论浮点运算量÷每步耗时÷所用设备的合计理论峰值。假设每步模型理论运算量为 12 TFLOP，每步用时 0.2 秒，匹配当前数值精度的合计峰值为 200 TFLOP/s，估算 MFU 为 30%。这里的 TFLOP 表示运算量，TFLOP/s 表示每秒运算能力，不能互换。
这个计算有严格边界。模型运算量来自估算，是否计入前向、反向等部分必须说明；峰值要匹配实际使用的精度和硬件模式。不能拿某种低精度的宣传峰值去除另一种精度下的训练吞吐。也不能把训练之外的所有硬件工作自动算成模型贡献。对于表格模型和很小的短文本分类器，运算量估计可能不稳定，CPU 方案也可能更合适，此时直接比较质量约束下的耗时与费用更有解释力。
本课再使用 2 个较容易测量的比例。分配率＝观察窗口内已分配设备时÷窗口内可供分配设备时；有效训练时间占比＝任务中有效训练的设备时÷任务已分配设备时。设备时把设备数量与持续时间相乘，例如 2 张 GPU 持续 3 小时就是 6 GPU·小时。它不能表示运算量，也不能跨不同型号直接解释为相同能力，但能帮助核对资源占用与费用。
单位成本需要明确产出。每处理 1000 个样本的成本适合观察运行吞吐，却不能独立评价训练方案，因为模型可能需要更多轮次才能收敛。每个达到约定验证门槛的模型成本更接近实验目标，但必须计入失败实验。若项目花费 600 元，只得到 3 个符合门槛的候选模型，阶段平均成本是 200 元，不能只汇报其中最便宜的成功运行。另需报告得到首个合格模型的总历时，因为排队会影响交付。
不要把这些比例机械相乘来预测质量。设备忙碌、模型运算与模型有效性没有固定换算关系。提高 MFU 有时能缩短训练，有时调整批量后却需要更多轮次；提高分配率有时只是让更多失败实验同时运行。比较应采用同一质量标准，并把运行指标、项目成本与交付时间放在同一张记录表里。
3 排队、装箱与闲置
任务提交到完成，可以依次经历排队、准备、训练、验证、保存和释放资源。排队通常不占用该任务的 GPU，但仍消耗交付时间；准备阶段如果已经锁住 GPU，就会消耗设备时。训练阶段也可能间歇等待图像读取，验证和保存则可能形成周期性停顿。区分这些阶段后，团队才能判断应该减少等待、改善数据供给，还是调整资源请求。只看总耗时，往往会把不同问题混成“卡太慢”。
装箱是把不同任务安排到有限设备和节点上的过程。这里先把节点理解为装有若干 GPU 的服务器。假设有 2 台节点，每台 4 张 GPU；已经运行的任务在每台上各占 1 张，集群共有 6 张空闲 GPU。若新任务必须在同一节点取得 4 张，就仍然无法启动。空闲总量足够，位置却不满足要求，这就是资源碎片。是否允许跨节点运行，应由程序支持能力与通信成本决定，不能只靠调度器强行拼接。
资源碎片也不只有 GPU 数量。图像训练可能同时需要较大内存和快速本地数据盘；短文本分类可能 GPU 用量较少，却受 CPU 分词处理限制。某台服务器即使 GPU 空闲，CPU 或内存已经耗尽，也不能承接新任务。相反，给很小的表格流失模型独占大容量 GPU，会产生另一种浪费：资源要求被满足了，任务却无法使用这份能力。请求表应同时描述必要资源，避免只填 GPU 张数。
闲置可分为未分配的空闲和已分配但没有推进任务的等待。前者可能来自低需求、资源碎片或为紧急任务保留容量；后者可能来自数据读取、评估、人工调试或程序卡住。容量预留有业务价值，应单列预算与使用规则。把它混入训练效率，会使治理人员误删必要的余量；把所有空闲都解释为预留，又会掩盖长期未使用的资源。
调度需要在短任务周转、长任务连续运行和截止时间之间取舍。可以让资源需求明确的短实验填入空档，也可以限制交互式调试的占用时长。若允许暂停任务，应先确认检查点能可靠恢复，并统计暂停带来的重复工作。入门阶段无需设计复杂调度算法，先确保任务有负责人、资源上限、预期时长和退出条件，就能解决不少长期占用问题。
这个动画把“提交了任务”拆成可测量的阶段。观察时特别注意：排队结束不是有效训练的起点，进程退出也不总是资源释放的时刻。只有把调度事件、程序日志与费用记录对齐，才能解释同样 1 次训练为什么在不同安排下消耗不同的设备时。
4 动手：核算一次任务的有效算力比
现在为 CIFAR-10 任务建立最小核算表。固定前述数据划分，用训练集计算任何需要学习的预处理统计量，只在验证集选择学习率与停止时机。记录模型配置、批量大小、数值精度、训练轮次、硬件型号和数据版本。测试集暂不参与调参。先约定验证宏平均 F1 至少达到 0.80，且各类别召回率不低于 0.65；这些是练习门槛，真实项目应按错误代价确定。
准备 1 次占用 2 张相同 GPU 的教学运行。提交后排队 0.5 小时，获得资源后又运行 2 小时。已分配阶段包含：环境与数据准备 0.25 小时、有效训练 1.25 小时、验证与保存 0.25 小时，以及训练结束后未释放的 0.25 小时。此处各阶段均占用 2 张 GPU，且互不重叠，所以已分配设备时为 2×2＝4 GPU·小时，有效训练设备时为 2×1.25＝2.5 GPU·小时。
把本次练习的“有效算力比”明确定义为有效训练设备时占已分配设备时的比例，可得 2.5÷4＝62.5%。这是时间口径的代理指标，不能称为 MFU，也不表示 62.5% 的峰值运算被利用。若训练阶段的设备经常等待数据，这个粗粒度定义仍会高估实际运算贡献，需要再结合逐步耗时或吞吐观察。定义写清楚，比给比例起一个响亮名称更重要。
若示例 GPU 单价为每 GPU·小时 8 元，GPU 费用为 32 元。再加 CPU、内存和存储等归属本任务的费用 6 元，本次总费用为 38 元。排队的 0.5 小时在这套按任务占用计费的假设下不产生该任务 GPU 费用，但端到端历时为 2.5 小时。若团队自有或包期租用整个集群，空闲容量依然有成本，不能因为任务账单未列出，就把它从项目成本中消失。
随后按证据找改进点。把准备工作前移到申请 GPU 之前，可减少已分配等待；退出时自动释放资源，可消除最后的遗留占用。假设这 2 项总计节省 0.5 小时且训练结果不变，新的 GPU 设备时为 3，GPU 费用为 24 元，有效训练时间占比约为 83.3%。其余费用是否仍为 6 元需要重新核对，不能把阶段缩短直接当成所有费用等比例下降。
实际操作可用任务开始结束时间、资源分配释放事件和训练日志完成，不必先建设大型平台。日志至少保存各阶段时间、已处理样本数、验证指标和退出原因。如果 2 张 GPU 在不同时间加入或退出，应按各时间段分别累计设备时；如果任务有自动重试，则把重试全部关联到同一实验编号。最终输出原始记录、计算公式与质量结果，使别人能够复算这个比例。
验收时还要看重复实验是否稳定。若改动数据加载后某次 F1 更高，不应立即把差异全部归因于调度；随机初始化和样本顺序也会带来波动。对重要决策可使用预先约定的 3 个随机种子，报告指标范围与费用范围。若某次运行未达到门槛，应保留其费用并说明原因，不能从统计中删掉后只比较成功样本。
5 峰值能力与平均效率取舍
峰值能力回答“理想条件下最多能做多少运算”，平均效率回答“在指定观察期里实际推进了多少工作”。某种设备峰值更高，若任务太小、输入供应不足或软件配置不合适，训练时间可能改善有限。另一种设备峰值较低，却可能以更低费用完成相同质量任务。合理选择要从真实任务测量出发，不能用峰值之比直接推算训练加速比。
假设方案甲使用 1 张 GPU，合格训练用时 4 小时，单价每小时 8 元，GPU 费用为 32 元；方案乙使用 2 张同型 GPU，用时 2.5 小时，费用为 40 元。乙把训练时间缩短 1.5 小时，却多消耗 1 GPU·小时。如果截止时间只剩 3 小时，乙可能值得；如果截止时间宽松，甲可能更经济。还需加上排队、准备和评估，确认乙能否真的在截止前交付。
增加设备后，数据划分、梯度更新对应的批量和学习率设置都可能影响训练轨迹。本课不展开这些内部机制，只要求比较者核对：是否仍需相同训练轮次，是否达到相同质量门槛，是否出现新的失败。某方案每秒处理更多图像，但收敛需要更久，就不能把吞吐提升直接写成模型成本下降。可以同时记录样本吞吐与达到门槛的总时间，以便区分这 2 种结果。
滑块展示的是明确假设下的预算敏感性：固定有效训练工作量时，时间占比提高，会减少完成该工作量所需的已分配设备时。它不预测某张卡的实际速度，也不代表调度改动必然保持训练质量。观察时先改有效占比，再改变单价与排队时间，辨别哪些参数改变费用、哪些参数改变历时，以及哪些因素需要重新测量才能下结论。
平均效率也有边界。把所有资源长期排满，可能让紧急实验等待过久；保留适度余量，虽然降低分配率，却能保障截止时间。成本方案应说明余量服务于什么任务、允许等待多久，以及超过阈值后怎样处理。若没有明确需求，长期空闲应触发复核；若存在真实的时限要求，不能仅为报表中的高占用而取消余量。
6 常见坑：只买卡不治理调度
常见的第 1 个坑是看到排队就加 GPU。队列变长可能来自总容量不足，也可能来自任务集中要求同一节点、用户过量申请，或已完成的交互环境没有释放。应先对齐“等待中的请求”与“当前空闲资源的位置和类型”。如果大量单卡任务分散占据多卡节点，再增加相同节点可能暂时缓解排队，却保留了导致碎片的安排方式。
第 2 个坑是把显存占用当成产出。训练进程可能预留了显存，但正在等待 CPU 图像解码；短文本任务也可能卡在分词与磁盘读取。可先检查训练步耗时是否周期性拉长、输入准备时间是否同步上升，再做小规模对照，例如提前准备相同批次的数据。不要凭某个瞬时图表就修改整个系统，也不要为了增加设备忙碌比例而重复计算无关工作。
第 3 个坑是为提高吞吐破坏评估规则。公开流失数据可能类别不平衡，若随机抽取的验证集恰好漏掉少数类，准确率看起来很好，实际召回率却不可用。应在划分时关注类别比例；如果同一客户有多条记录，还要避免客户跨集合出现。短文本分类中相同或近似重复文本也可能泄漏到验证集。高效率只能建立在可信评估上，否则节省的是得到错误结论的时间。
第 4 个坑是把历史最好成绩当成长期保证。输入图像拍摄条件、文本来源或用户群发生变化，会形成分布偏移。即使硬件吞吐不变，模型也可能需要重新训练或增加数据治理工作。预算中应保留重新验证的费用，记录数据时间范围和来源；不能用过去某次合格运行的成本，直接承诺未来所有数据上的交付成本。
第 5 个坑是用单个优化掩盖整体账本。压缩检查点频率可能提高表面训练占比，却在故障时损失更多进度；抢占任务可能提高资源分配率，却引发重试和超时。任何改动都应记录节省的设备时、新增的恢复成本和质量影响。先用少量可恢复任务验证，再扩大范围；当质量或截止时间恶化时，按预先约定的条件回退。
7 案例：碎片化导致大量空闲 GPU
某教学团队共有 4 台训练节点，每台 4 张相同 GPU，总计 16 张。它们同时承接 CIFAR-10 图像实验、公开短文本分类实验和表格流失预测。某个时刻，每台节点都运行着 1 个单卡文本任务，共占用 4 张 GPU，其余 12 张空闲。与此同时，2 个各需同节点 4 张 GPU 的图像任务排队。仪表盘显示大量空闲，学生却不断反馈训练启动不了。
此时分配率只有 25%，但不能据此断言另外 75% 可以立刻服务排队任务。4 台节点各剩 3 张，没有任何节点符合 4 张的请求。如果 2 个任务都必须满足该约束，当前可启动数量就是 0。这个现场表明资源总量统计与可调度容量不同。要解释问题，需要查看节点级分布、任务资源请求以及请求是否真的必要。
团队先核对图像训练是否确实需要 4 张卡。若只是沿用旧模板，应在相同质量约束下测试更小请求；若确实需要，则调整后续任务的放置。对于已经运行的文本任务，不应未经评估直接杀掉重排。可以等其自然结束，或只对支持检查点恢复的任务实施计划迁移，并将迁移成本计入方案。
随后把新提交的单卡任务优先放入已经有单卡负载且仍有容量的节点，让部分节点保持完整可用。理想化的稳定状态可以是 1 台节点承接 4 个单卡任务，另外 2 台各运行 1 个4卡图像任务，剩余 1 台提供余量。此时使用 12 张 GPU，分配率为 75%。这只是资源布局示意，实际还需确认 CPU、内存、数据读取与任务隔离条件都满足，不能保证所有任务速度不受影响。
为了判断改进是否有效，团队按连续 7 天记录提交到启动的等待时间中位数与第 95 百分位数，并记录每个合格图像模型的总费用、训练完成率和各类别召回率。第 95 百分位数可理解为按等待时间排序后，约 95% 的任务不超过的值，它能提示少量任务是否等待特别久。只比较平均等待时间，可能漏掉资源请求较大的任务长期排队。
验收标准应提前写明：在相近任务数量与类型下，4卡任务等待下降，单卡任务的等待没有超过约定阈值，质量门槛保持满足，恢复浪费没有明显上升。即使分配率从 25% 上升到 75%，也不能声称训练加速了 3 倍；变化首先表示更多任务能够同时运行。若任务需求本来就很少，布局优化也不会凭空创造有价值的工作。
8 把效率指标写进成本方案
成本方案应先定义交付物，再列资源。对于图像分类，交付物可以是通过固定验证门槛的候选模型、确定后的测试结果，以及能够复现的配置记录。对于流失预测，交付物可能要求在固定召回率下达到最低 precision，并报告 AUC；因为漏掉流失客户与误报客户的代价不同，不能只写“准确率较高”。质量门槛变化后，预算和性能测量都要重新评估。
资源账本至少分成任务直接占用与共享容量成本。前者包括训练、验证、准备、恢复所消耗的设备时，以及可归属的 CPU、存储等费用；后者包括包期容量的空闲部分和必要余量。共享部分可以按约定规则分摊，也可作为平台预算单列，但要避免重复收费或完全遗漏。硬件购置还应结合使用周期核算，不能只把购置价除以某次运行时间。
指标表应同时包含质量、时间、资源和费用。质量列写宏平均 F1、各类别召回率或任务适用的 AUC；时间列写排队、运行和端到端历时；资源列写设备时、分配率、有效训练时间占比，必要时加有明确估算方法的 MFU；费用列写本次运行与阶段累计成本。每项都要指定来源和观察窗口，例如单次运行、每日汇总或连续 7 天，而不是把不同时间范围拼在一起。
还需规定行动条件。若连续多次出现资源已分配却长时间没有训练步进，先检查输入、程序状态与退出清理；若空闲很多且大任务排队，检查碎片和资源约束；若单位合格模型成本上升，检查失败率、数据变化与质量门槛是否改变。阈值应基于任务的正常范围制定，不能要求所有模型达到同一个 MFU 或同一个训练时间占比。
最后，把不确定性写入预算。可分别估计正常运行、出现若干失败重试、需求集中到达时的费用与完成时间，注明哪些数值来自测量，哪些来自假设。承诺应落在已经验证的范围内，并明确重新评估的触发条件。这样成本方案既能解释当前选择，也能在任务数量、数据规模或截止时间变化时继续使用。
9 从算力效率与成本走向性能建模（H49）
到这里，我们已经能够区分峰值能力、资源分配、训练推进和合格产出，也能沿着任务时间线解释费用。下一步的问题是：在尚未投入大量资源前，能否估计数据量翻倍、增加 GPU 或提高并发后，耗时会怎样变化？这就进入性能建模（H49）。本课先保留测量证据，不把某次训练的比例扩展成对所有任务都成立的定律。
准备交接时，至少保留基准配置、各阶段耗时、处理样本数、设备数量和完整质量结果。还可选择少量有代表性的配置作对照，例如相同模型分别使用 1 张与 2 张 GPU，并记录端到端时间和设备时。若改变批量或数据增强，就单独标记，避免把多个因素的共同变化归因于硬件数量。公开数据集只是实验载体，可复算的记录才是可迁移的资产。
性能建模会进一步讨论工作量与吞吐、固定开销与可缩短部分之间的关系。现在只需掌握一个判断：某个阶段不随 GPU 增加而缩短时，它会限制总体收益。例如数据准备仍需 15 分钟，即使训练本身更快，端到端耗时也不会按相同比例下降。排队还受到其他任务到达情况影响，因此单次空闲集群上的测试不足以承诺繁忙时段的交付时间。
把问题带到 H49 时，应使用可以被测量推翻的说法，例如“固定质量门槛下，增加设备是否能让总历时低于 3 小时，同时把费用控制在 50 元以内”。这比“设备越多越快”更适合做决策。接下来的建模负责连接规模与表现，本课的成本口径、质量约束和异常记录则保证模型讨论的是有意义的工作。
放进方案里
本项目以公开 CIFAR-10 图像分类为基准，使用 45000 张训练图像、5000 张验证图像和官方 10000 张测试图像。验证集用于选择配置，测试集在配置确定后评估。验收要求验证宏平均 F1 不低于 0.80，各类别召回率不低于 0.65，同时保留数据版本、模型配置与随机种子。门槛属于项目约定，调整门槛须同步复核预算，禁止通过重复查看测试成绩选择资源方案。
核算范围覆盖提交、排队、准备、训练、验证、保存和资源释放。已分配设备时按实际设备数量与占用时间累计，失败和重试关联到原实验。有效算力比采用有效训练设备时除以已分配设备时的时间口径，并与 MFU 区分。直接费用包括 GPU、CPU、存储等任务用量；包期容量的空闲与预留费用单独列入平台账本，避免遗漏和重复分摊。
基准运行使用 2 张同型 GPU，分配 2 小时，有效训练 1.25 小时，对应 4 GPU·小时与 62.5% 的有效训练时间占比。按每 GPU·小时 8 元估算，GPU 费用为 32 元；其他归属费用暂估 6 元，总计 38 元，等待 0.5 小时另计入交付历时。以上为预算假设，正式执行后以资源事件和费用明细替换。
优化优先处理准备阶段占卡、完成后未释放和节点资源碎片。调度调整先在支持恢复的任务中试行，连续观察 7 天的等待中位数、第 95 百分位数、合格模型成本与完成率。只有质量门槛持续满足，且等待与费用符合约定，才扩大应用；出现质量下降或恢复浪费上升则回退。资源规模改变前补做对照测量，并把证据交给 H49 的性能建模。
验收附件须按实验编号关联资源释放事件、训练步日志和账单，核对失败重试是否全部入账。比较优化前后成本时，固定随机种子集合与质量门槛，报告累计费用除以合格模型数；若合格数为 0，则记录全部支出并判定未通过。硬件型号、精度或全局批量改变后，原成本结论须重新验证。
10 小结：下一步性能建模（H49）
算力效率必须说清分子、分母和观察窗口，成本比较必须绑定质量与交付时间。MFU 描述模型运算相对理论峰值的吞吐，分配率描述容量占用，有效训练时间占比描述任务时间构成，它们不能相互替代。资源碎片说明空闲总量足够，也可能无法启动特定任务。
进入 H49 前，尝试解释这 3 个现象：为什么设备忙碌却没有更快得到合格模型；为什么增加 GPU 缩短了训练却增加了费用；为什么空闲 GPU 很多，大任务仍在排队。能够用质量记录、阶段时间和资源布局支持解释，就已经具备继续做性能建模的基础。