如果你正准备做一次LLM训练预算，很可能已经有过这样的体验：
GPU型号查过了，价格也算过了，看起来还能接受，但真正跑起来之后，账单却明显超出预期。
我们在做模型训练规划时，也遇到过几乎一模一样的问题。最初大家讨论最多的是“选哪种GPU更划算”，但当我们把账单逐项拆开后才发现，真正推高成本的，并不是GPU单价本身，而是显存策略、训练时长估算以及反复调参带来的隐性消耗。
所以这篇文章，我不打算直接告诉你“该买多少卡”，而是先带你把一件事想明白：
LLM训练的钱，究竟是在哪些地方被花掉的。
只要这一步想清楚，后面的优化就不会再是碰运气。
预算第一步：别急着算价格，先把结构搭好
在真实项目中，我们几乎不会一开始就给出一个“精确到美元”的训练报价。
更合理的做法，是先搭一个不容易失控的预算结构。
通常我会把训练成本拆成四块：
- GPU计算费用
- 模型检查点与数据存储
- 数据下载、同步与出网
- 调参、失败和重跑的缓冲空间
其中GPU费用当然是大头，但它本身并不是一个固定值，而是由两个变量共同决定：
你用了多少GPU，以及它们工作了多长时间。
而真正容易被低估的，往往是后面那一项。
显存不是只给模型用的，这一点很多人第一次都会算错
很多新手在第一次做预算时，会下意识地把“模型规模”和“显存需求”直接画等号。
但只要你真的跑过一次训练，就会发现：显存消耗远比想象中复杂。
在训练过程中，GPU显存主要会被四类内容占用：
- 模型参数本身
- 反向传播产生的梯度
- 优化器状态
- 与序列长度强相关的激活值
尤其是在全参数微调、使用Adam类优化器时，优化器状态往往是显存消耗中最容易被忽略的一块。
如果你没有做任何分片或并行，每张卡都会保存一整套状态，显存很快就会见底。
这也是为什么我们后来回头看做的方案时，会发现问题并不在GPU型号，而在于：
训练状态没有被合理拆分。
一个经验值，快速判断你的方案是否现实
为了让预算阶段更高效，我们通常会用一个简单但非常实用的经验估算：
在BF16或FP16全参数微调、使用Adam优化器的情况下，
每个参数大约需要16bytes显存。
用这个规则去看不同模型规模，结果往往一目了然。
| 模型规模 | 全参训练状态显存总量 | 8卡分片后单卡 | 16卡分片后单卡 |
|---|---|---|---|
| 7B | ≈104GiB | ≈13GiB | ≈6.5GiB |
| 13B | ≈194GiB | ≈24GiB | ≈12GiB |
| 70B | ≈1043GiB | ≈130GiB | ≈65GiB |
看到这里，你基本可以做出一个理性判断：
如果你打算在80GB级别显存上训练70B模型，全参数微调几乎不可能“靠单卡硬扛”，分片和并行并不是优化选项，而是前提条件。
真正决定账单高低的，是训练时间
在很多预算失控的案例里，显存其实只是第一道门槛。
真正拉开成本差距的，是训练时间的估算方式。
我们更推荐用“Token视角”来估算训练周期，而不是只盯着step数。
在实际项目中，一个更稳妥的流程通常是：
- 明确训练所需的总Token量
- 用目标配置跑一个小规模测试
- 实测每张GPU的Tokens/秒
有了这个吞吐数据，训练时间就可以非常直观地反推出来：
训练小时数 ≈ 总Token数 ÷（Tokens/秒/卡 × GPU数量 × 3600）
这个过程的价值在于：
你可以清楚地看到，究竟是数据规模、序列长度，还是并行效率在拉长训练时间，而不是在账单出来之后才开始猜原因。
为什么序列长度一变，预算就容易失控
这是我们被问得最多的问题之一。
当你把序列长度从2048提高到4096甚至8192时，变化的不只是计算量，而是一整套连锁反应：
- 激活显存显著增加
- 单卡batch被迫降低
- 梯度累积次数上升
- 单卡吞吐下降，训练时间拉长
最后你看到的结果就是：
GPU数量没少，单价没变，但训练时间明显延长，整体费用自然水涨船高。
所以在预算阶段，我一直坚持一个原则：
只要涉及长序列，一定要在目标配置下做实测。
成本优化的关键，往往不在“换哪家云”
在实际项目里，我们很少通过“单纯换云厂商”来解决预算问题。
真正有效的优化，更多发生在训练策略层面。
这些是我们在训练中最常用、也最稳定的做法。
先解决“跑不跑得动”的问题
当显存成为瓶颈时，优先考虑模型和训练状态的分片，而不是盲目升级显存规格。
很多时候，这一步就能决定你是用8卡跑，还是被迫扩展到16卡。
用梯度累积换取显存空间
当batch受限于显存时，梯度累积是最现实的折中方案。
它确实会让单次迭代变慢，但至少可以保证训练稳定推进。
重新评估是否真的需要全参数微调
在实际训练中，我们最终并没有选择70B全参微调。
原因很简单：在目标任务下，PEFT方案已经能够提供足够的效果提升，而成本却可控得多。
低精度优化器和QLoRA这类方案，最大的价值不是让训练更快，而是：
把原本无法承担的训练，拉回到一个理性的预算区间。
一个可直接复用的训练预算表示例
如果你希望把这些思路快速落地，下面这张预算表就是我们内部经常使用的参考模板。
| 项目 | 7B | 13B | 70B |
|---|---|---|---|
| 训练Token总量 | 1.5亿 | 5亿 | 100亿 |
| 序列长度 | 2048 | 4096 | 8192 |
| Tokens/秒/卡 | 120 | 900 | 1200 |
| GPU数量 | 1 | 8 | 16 |
| 训练小时数 | 347h | 19h | 145h |
| GPU费用压力 | 低 | 可控 | 高 |
| 缓冲建议 | 10% | 10% | 15–30% |
你会发现，真正决定成本的，从来不是模型名字本身，而是你如何组织训练过程。
FAQ：预算阶段最容易踩的几个坑
Q：是不是模型越大，训练就一定越值？
A：不一定。在很多业务场景中，7B或13B模型在数据质量和训练策略合理的情况下，性价比往往更高。
Q：为什么我算出来的预算和别人差很多？
A：最常见的原因是吞吐假设不同。实测Tokens/秒/卡，远比理论算力更可靠。
Q：GPU越多，训练一定越快吗？
A：不一定。并行策略不到位时，通信开销反而会拉低整体效率。
写在最后：清醒地算账，本身就是一种能力
如果你正准备开始一次LLM训练，我真心建议你先做好三件事：
- 把模型规模、Token量和序列长度明确写出来
- 用小规模实测拿到真实吞吐
- 给预算留出调参与失败的空间
如果你愿意，欢迎在评论区分享你的模型规模、训练计划，或者踩过的预算坑。
这些真实经验，往往比任何参数表都更有价值。
觉得这篇文章对你有帮助，也欢迎点赞、收藏、转发给正在算账的朋友。
真正把训练跑顺的人，通常不是最激进的那一批，而是最清醒的那一批。