打算自己训一个模型，最先卡住的问题往往不是代码，而是「这事要几台机器、跑多少天、大概烧多少钱」。网上的公式只讲参数量乘 token 数，没告诉你显存、通信、利用率这些会吃掉一半预算。这篇按可执行顺序，把算力规模估算拆成几步，每步告诉你去看哪个站内页面取当时的数字，最后给一份资源配比与降档方案对照。
打算自己训一个模型，最先卡住的往往不是代码，而是「这事要几台机器、跑多少天、大概烧多少钱」。网上的公式只讲参数量乘 token 数，没告诉你显存、通信、利用率这些会吃掉一半预算。这篇按可执行顺序，把算力规模估算拆成几步，每步告诉你去看哪个站内页面取当时的数字，最后给一份资源配比与降档方案对照。
先说清一个前提：估算的目的不是算出精确值，而是拿到一个量级，判断这件事你到底做不做得起。量级对了，后面采购、租卡、排期才有意义；量级错了，参数调得再细也是白搭。所以下面每一步都强调「先归类、再套数、最后用实测修正」。
先分清你训的是哪种「训练」
全量预训练、继续预训练、微调、LoRA 这四类任务，算力口径完全不是一回事。全量预训练要按参数量乘总 token 数去估；继续预训练数据量小一截但仍在动全部参数；微调只跑几千到几万条样本；LoRA 只训练少量附加参数，显存和卡时都能压到很低。不先归类就套公式，量级能差出几个数量级。
- 判断标准一：是否要更新全部参数。只改少量参数的走微调路线即可，别按预训练口径吓自己
- 判断标准二：数据量是几千条还是几十亿 token。数据量决定了总步数和总卡时
- 判断标准三：目标是不是「让模型会答某个业务问题」。如果是，多半不该走训练，先排除更轻的路线
- 不适用情况：想提升的其实是模型对私有知识的掌握，检索增强往往比训练更划算
路线怎么划分、每类对应什么资源量级，站内已经整理过对照，直接到 /training 里按任务类型看当时的说明，别凭印象归类。
估算只需要四个输入：参数、数据、时长、利用率
把估算收敛到四个输入：参数规模决定显存占用和单步开销；数据量与训练轮次决定总步数；目标训练时长决定你需要多少并行度；硬件利用率决定理论卡数要乘的折扣倍数。前三个是你自己定的，第四个最容易被忽略，也最容易让预算翻倍。
- 定参数量和数据量写下你准备训的参数量级和喂进去的总数据量，单位统一成 token 或样本数。这一步只求量级，不求精确
- 估总算力需求用「参数量 × 数据量」的常见经验口径先算出粗略总算力，得到一个量级数字
- 除以单卡有效吞吐用目标卡型在你自己代码上的实际吞吐去除，而不是厂商标称峰值。有效吞吐通常要打折扣
- 乘利用率折扣再乘上集群利用率，得到实际需要的卡数和卡时。利用率越低，要买的卡越多
折算系数、当时可租的卡型规格和对应的显存参数，到 /compute/sizing 与 /compute/gpus 核对当时的数字。这两个页面的数值会随时间变，凭记忆套用旧参数是最常见的翻车原因。
资源配比：显存、算卡、网络、存储谁先成为瓶颈
算完总量只是第一步，真正决定训练能不能跑起来的是配比。显存、卡间通信、数据读取、checkpoint 写盘，这四样里任何一样拖后腿，前面算出来的卡时都用不上。排查顺序建议从显存开始，因为它最常先撞墙。
| 瓶颈 | 先看什么 | 常见处理方向 |
|---|---|---|
| 单卡显存 | 参数加优化器状态放不放得下 | 先量化或分片，再考虑 offload，最后才是加卡 |
| 卡间通信 | 多卡并行时的带宽够不够 | 调整并行策略，别一味堆卡数 |
| 数据读取 | 训练时 GPU 是否在等数据 | 先把数据预处理和读取管道做顺 |
| 存储空间 | checkpoint 写盘留了多少余量 | 按最大 checkpoint 的倍数预留，别写到满 |
显存测算有现成的口径可以对照，到 /models/deploy 看当时的部署测算说明，再决定是分片、量化还是换卡。要提醒一句：小规模微调时网络和存储基本不是瓶颈，照搬大集群的配比反而是浪费，这种情况按单卡或双卡估即可。
把算力需求翻成钱：三条路各算一遍
有了总卡时，接下来就是选路径：短期按小时租卡、长期租用或签合同、直接买卡自建。三条路适合的场景不同，先把总卡时算出来，再分别套各自的单价口径，别只比单价不看总持有成本。
- 短期租卡：适合验证阶段和试错期，灵活但单位成本偏高
- 长期租用：适合已经确认规模和周期的项目，锁定单价换稳定供给
- 自建买卡：适合长期持续训练，但要算上机房、电力、运维和折旧
- 容易漏的成本：试错重跑、数据准备与清洗、存储与出网流量、训练失败后重来的那一轮
价格不要凭印象比。按 /compute/price-index、/compute/tco、/compute/rental 的顺序对齐口径，先看单价的实时追踪，再看总持有成本，最后看租赁方案，避免拿按小时价去和买卡价直接比。看的时候以页面当时的数字为准。
动手前的自查清单与降档方案
预算不够时不要硬上，先按顺序自查一遍，再逐条对照降档方案。自查的目的不是让你放弃，而是让你在小规模上先把流程跑通，避免大集群上烧掉第一轮预算才发现在数据处理阶段就有问题。
- 确认目标是否必须训练如果需求能被检索增强或提示工程解决，先排除训练这条路
- 小规模验证跑通用极小数据量跑完整流程，确认代码、数据管道、保存恢复都正常
- 确认单卡能否放下放不下就先解决显存，而不是直接加卡数
- 估算需要几张卡、跑多久按实测吞吐外推，而不是按理论峰值估
- 设预算上限和止损点提前写清楚花到多少、跑多久还没收敛就停下来换方案
| 降档手段 | 对效果的预期影响 | 什么情况下不适用 |
|---|---|---|
| 减小参数规模 | 容量下降，复杂任务上更明显 | 任务本身对模型容量要求高时不建议 |
| 减少数据量 | 覆盖度下降，容易过拟合 | 数据本身就是瓶颈时不建议 |
| 降低训练精度 | 多数情况影响有限，需实测确认 | 对数值稳定性敏感的任务要谨慎 |
| 缩短训练时长 | 可能欠拟合，指标未收敛 | 已经确认收敛曲线走平的情况例外 |
| 改用微调或检索增强 | 省算力，但改的是能力边界 | 需要模型内化新知识时效果有限 |
验收标准很简单：先用小规模跑通完整流程并记录实际吞吐，再按实测值外推总卡时和预算，而不是按理论峰值估。外推结果和站内页面上的卡型数据对不上的时候，以你自己的实测为准。想横向看不同算力方案和工具的口径，可以到 /tools 里按类别挑，避免只盯一家。
下一步先到站内算力测算页把参数量、数据量、目标时长填进去，拿到一个量级数字，再拿这个数字去价格追踪页对齐当时的租用口径，你就知道这事做不做得起了。→常见问题
不写公式，我怎么快速判断这事要不要上多卡？
先回答一个问题：单卡显存放不放得下。放不下才谈多卡，而且要同时看卡间通信是否跟得上。到 /models/deploy 按你的参数规模和精度做一次部署测算，能放下就单卡慢跑，放不下再往分片和集群上想。
租卡和自建，估算方式一样吗？
前四步完全一样，总卡时是不变的。区别在最后一步：租卡把卡时乘小时单价，自建要把硬件、机房、电费、运维摊到同一时间窗里。到 /compute/tco 用同一套卡时口径算一遍，才比得公平。
估出来的数字和实际差很多，通常是哪一步错了？
八成错在硬件利用率上。理论算力乘一个乐观系数，忽略了通信等待、数据加载和失败重跑，结果自然偏小。稳妥做法是先小规模实跑，记录真实吞吐，再按实测值外推整体预算。
