很多人第一次看训练报价单会愣住：明明是写代码调模型，怎么账单上全是一排排显卡。这篇不讲故事，按「算得慢、装不下、传不动」三条线拆开，告诉你GPU在训练的哪一步被吃掉，以及动手前该按什么顺序估卡数和租期。
第一次看训练报价单的人基本都会愣一下：不就是写代码调模型，怎么账单上全是显卡，还一排一排地算。这事儿不玄乎，钱主要花在三个地方——算得慢、装不下、传不动。把这三条线拆开，你就能大概判断自己的任务到底该租几张卡、租多久。
下面按「计算并发、显存占用、卡间通信」的顺序讲，最后给一套动手前估卡数的判断流程。需要先说明，本文不给任何具体数字，因为卡型、精度、模型规模一直在变，这些得去站内页面看当时的数值。
第一笔账：同样的乘法，CPU和GPU差在并发数
大模型训练的内核其实很朴素，就是海量的矩阵乘加。单看一次运算，加减乘除而已，一点也不高级。麻烦在于这种运算要同时发生几百万次、几千万次。GPU 有成千上万个计算核心，天生就适合这种「同构、批量、互不依赖」的活；CPU 核心少，更擅长调度、分支判断和串行逻辑。所以不是 GPU 比 CPU 聪明，是它更适合干这种重复量大的体力活。
这也是为什么别把 GPU 当成「更快的 CPU」。它快在吞吐，不卡在单线程延迟。判断一个任务值不值得上卡，先问一句：它能不能拆成一堆互不依赖的小计算？能拆，上卡才有意义；拆不开，上卡就是白花钱。
- 矩阵乘加、卷积、注意力里的批量运算，属于典型的可并行任务，适合 GPU
- 数据清洗、分词、格式转换这类串行或 IO 密集环节，GPU 帮不上多少忙
- 写训练脚本时，别把这些前置环节的耗时也算进卡时预算，否则估出来的租期会虚高
- 判断标准很简单：这段代码里有没有大段 for 循环按顺序处理数据，有就基本不适合上卡
第二笔账：装不下就得拆，拆了就得多买卡
显存是第二道坎，而且经常比算力先撞墙。训练时显存里同时压着四样东西：模型权重、梯度、优化器状态、中间激活值。很多人只按参数量估显存，结果实际一跑就 OOM。原因是优化器那部分往往比权重本身还大，激活值又会随着批大小和序列长度往上蹿。
实际用下来，最容易踩的坑是把 batch 调大之后只盯着显卡利用率看，忘了显存。上下文拉长、batch 调大，最先炸的通常是显存，不是算力。所以调参时要有个顺序：先确认显存余量，再谈吞吐。
- 先估单卡显存把模型规模、精度档位、批大小代进站内部署测算，看单卡还差多少。具体数字到 /models/deploy 核对自己那组参数，别用别人的结论套自己的模型。
- 再决定减批还是切分显存差得不多，优先减批大小或缩短序列长度；差得多，才考虑张量并行、流水并行这类切分方案，因为切分本身会带来通信开销。
- 留出余量按理想值卡着线买卡，跑起来很容易因为激活值波动崩掉。留多少余量取决于你的序列长度和批大小策略，这个没有统一答案，只能自己试跑确认。
这里有个常见误判：有人把推理侧的显存估算直接搬到训练上，结果差出一大截。训练要额外存梯度和优化器状态，推理只做前向，两者根本不是一套算法。只做推理或知识库问答的场景，别用训练这套逻辑估卡。
第三笔账：卡多了，卡之间也得说话
单卡放不下就得拆，拆法主要有三种：数据并行、张量并行、流水并行。每种切法都会引入卡间同步，梯度要汇总、层与层之间要传数据。通信带宽跟不上时，加卡的收益会明显打折，甚至出现卡越多越慢的怪现象。
麻烦在于，机器内互连和机器间互连是两回事。同一台机器里的卡走高速链路，跨机器就得看网络。千兆网络凑多机，往往卡在通信上而不是算力上。所以租卡之前先确认机型走的是哪条链路，别只看单卡型号。
| 现象 | 可能原因 | 先查什么 |
|---|---|---|
| 加卡后总耗时没降 | 通信成为瓶颈 | 卡间链路与并行策略是否匹配 |
| 单卡利用率长期偏低 | 数据加载或通信在等 | 输入流水线、批大小、同步频率 |
| 训练中途频繁报错 | 显存余量不足或切分不当 | 激活值占用、并行切分比例 |
| 多机比单机还慢 | 跨机带宽不够 | 机器间网络规格，而非机器内互连 |
排查顺序建议固定下来：先看单卡利用率是不是长期上不去，再看通信是否成为瓶颈，最后才考虑换更贵的卡。顺序反了，很容易花大钱买了个用不上的规格。租卡渠道和规格对照可以翻 /compute/gpus 与 /compute/platforms，看当时各家的机型与链路说明。
真要开练，按这个顺序估一遍
前面三笔账讲完，落到动手就是一套估算顺序。顺序错了，估出来的卡数和租期会差一个量级，预算自然也对不上。
- 定目标先分清是继续预训练、全参微调，还是只做轻量微调。三条路对卡数和时长的要求差一个量级，别拿微调的经验去估预训练。
- 算显存按权重、梯度、优化器、激活四块分别估，按实际精度档位留余量。具体数值到 /models/deploy 代入自己的参数核对。
- 算时间先用小规模试跑拿到每步耗时，再乘总步数换算成卡时。别凭感觉猜，试跑数据比任何经验公式都准。
- 估预算拿卡时去对照 /compute/training-cost 的计费口径，注意不同计费方式对短任务和长任务的影响不一样，具体数字以页面当时为准。
- 回头验证正式开跑前用最小配置跑通一轮，确认显存、通信、数据加载都没问题，再放大规模。
有一种情况这套流程不适用：只做推理部署或者知识库问答，根本用不上训练。这类需求该去看推理侧的显存与并发估算，训练这套估法套上去只会把预算估高。
下一步想知道自己那组模型参数到底要几张卡、租多久，直接去部署测算页代入参数看当时的数字，比在群里问别人靠谱。→常见问题
只是微调一个小模型，也必须用GPU吗？
多数情况下是。微调同样要做反向传播和参数更新，计算量比推理大得多，CPU跑起来时间会长到没法迭代。模型很小、数据量也小的时候，CPU能跑通但只适合验证流程，不适合反复调参。
卡越多训练一定越快吗？
不一定。加卡会带来同步开销，当通信成为瓶颈时，多出来的卡利用率很低。先确认单卡是否已经跑满，再判断是数据并行还是切分方式的问题，盲目堆卡经常只是多花钱。
训练和推理的显存算法一样吗？
不一样。推理主要压权重和KV缓存，训练还要额外存梯度、优化器状态和激活值，同等参数下训练吃显存明显更多。拿推理的显存数字去估训练，通常会严重低估。
