训练大模型需要多少GPU

准备训一个模型，第一句往往就是「要多少张卡」。但这个问题没有单一答案，它取决于你训的是哪一档、用什么并行方式、能不能容忍通信开销吃掉一半效率。这篇不给你一个万能数字，而是给一条估算链路：先定位模型档位，再算单卡放不放得下，再决定张量并行、流水并行还是数据并行，最后落到租卡还是集群。照着走一遍，你自己能得出团队该买几张。

准备训一个模型，团队开会第一句话往往就是「要多少张卡」。但这个问题本身没有单一答案，它取决于你训的是哪一档、用什么并行方式、能不能容忍通信开销把效率吃掉一半。硬套别人的配置单，最常见的结果是卡买了、跑得比预期慢，或者卡不够、改架构改到怀疑人生。

这篇不给你一个万能数字，而是给一条估算链路：先定位模型档位，再算单卡放不放得下，再决定张量并行、流水并行还是数据并行，最后落到租卡还是上集群。照着走一遍，你自己能得出团队该买几张。下面每一节都给判断标准和排查顺序，不是概念科普。

先把三个问题问清楚，再谈卡数

三件事没定之前，任何卡数建议都是耍流氓。第一个是训练形态：从零预训练、继续预训练、还是只做微调，这三者对卡数和互联带宽的要求差一个量级，不要混在同一张预算表里算，否则你会把微调的小账套到预训练的大头上。

第二个是验收标准：目标是出一版可用效果，还是要出论文级的多组对照。后者每个对照组都要独立跑一遍，算力冗余得按组数翻倍留。第三个是墙钟时间：同样总算力，卡多则单次迭代快但通信开销上升，卡少则单次慢但线性度通常更好。你愿意等多久，直接决定卡数上限。

• 训练形态先写死：从零、继续预训练、微调，一次只选一个写进方案。
• 验收标准写清楚：最低可用效果线是什么，要不要留对照实验的算力。
• 墙钟时间给一个可接受区间，不要写「越快越好」，那等于没有约束。
• 三问回答完再开预算会，否则讨论会飘在别人的配置单上。

按模型档位粗分：小、中、大三类各自的卡数形态

与其一上来抠参数量，不如先按「能不能塞进一台机器」把档位分开。小档的特征是单机多卡就能放下模型加优化器状态，重点变成能不能把卡开满、别让数据加载拖后腿。这个档位常见误区是卡买了但利用率上不去，钱花在闲置上。

中档是单机放不下、但多机又不划算的区间，典型做法是机内张量并行切分、跨机只做数据并行，通信主要压在机内高速互联上。大档必须多机，张量并行、流水并行、数据并行要同时上，节点一多，互联拓扑和通信库配置就成了成败关键，卡数反而不是最难的部分。

每个档位当前的参数量边界会随硬件和框架变化，别记死数。站内训练算力页给了实测算例和分档参考，去 /compute/training-cost 对一遍再定档，比自己拍脑袋稳。

显存账怎么算：权重之外的三块大头

显存账是卡数估算的地基，但它不是「参数量乘个系数」这么简单。第一块是权重本身，按参数量乘每参数字节数估；用混合精度、分片优化器或量化感知训练，倍数完全不一样。第二块是梯度，通常和权重同量级。

第三块是优化器状态，Adam 类优化器常常是三者里最大的一块，很多人第一次做显存预算就在这里翻车，按权重乘个二就以为够了。第四块是激活值，随批次大小、序列长度和是否重计算线性变化，长上下文训练时它经常超过权重占用。四块相加，才是真实显存需求。

1. 算权重与梯度按参数量乘每参数字节数得到权重，梯度按同量级估，写进显存表第一行。
2. 单独算优化器状态不要并入权重一起估，按优化器类型单独列一行，这通常是最容易被低估的一块。
3. 按最长序列估激活用你计划的最长序列长度和批次大小估算激活，如果开了重计算要按额外时间成本折算。
4. 除以单卡可用显存总和除以单卡实际可用显存，别用标称显存，留出碎片和临时缓冲空间。
5. 回站内核对规格单卡显存规格去 /compute/gpus 查对比，别信商家页面上的宣传口径。

并行策略怎么选：从最省事的往最复杂的排

并行策略不是越高级越好，是从最省事的往下排，够用就停。数据并行最好调，优先把单机内的卡铺满数据并行，只有单个模型副本放不下时才升级。张量并行解决单层放不下，代价是每层都要通信一次，尽量限制在同一台机器内部，跨机会很吃亏。

流水并行解决层数放不下，会引入气泡，微批次划分和流水段数必须一起调，单独调一个参数多半没效果。序列并行或上下文并行只在超长上下文时才值得引入，短上下文场景用它是纯浪费，还增加调试成本。

• 先试数据并行，单副本能放下就别上更复杂的东西。
• 放不下再加机内张量并行，尽量别跨机切。
• 还放不下再加流水并行，同步调微批次和流水段数。
• 只有上下文真的超长时才考虑序列并行，否则跳过。
• 每一步都在小规模上量一次实际吞吐再扩，不要直接上目标规模。

并行策略的选择顺序是：够用就停，不是越复杂越专业。

互联与效率：卡数翻倍不等于速度翻倍

机内互联和跨机互联是两种东西，跨机带宽往往只有机内的零头。张量并行跨机，通信开销会直接把收益吃掉，这时候加卡不如换拓扑。扩卡前先测线性度：用当前规模跑一段固定步数，翻倍卡数再跑一遍，看每步耗时降了多少，降不到预期就说明通信或数据加载成了瓶颈。

数据加载、检查点写入、日志采样这些环节在多机下会同步放大，单机时看不出来，多机时就变成拖时间的元凶。什么时候不该扩：单卡已经满载但每步耗时不再下降，或者扩卡后单步时间只降一点点，这时候加钱的边际收益已经很低，不如先优化通信和 IO。

别忘了存储、检查点与失败重试

很多人算完卡数就直接开跑，结果卡在存储上。检查点体积和模型规模同量级，训练中会周期性写入，存储带宽不够会直接卡住所有卡，所有 GPU 一起等 IO。这个坑在单机小规模时几乎遇不到，多机一上就暴露。

多机训练节点越多，单点故障概率越高，必须提前定好从最近检查点恢复的流程、保留几个版本、恢复时优化器状态和随机种子是否一并加载。这块没做全，等于每次掉线都从头再来。规划卡数时把检查点开销算进去，否则你估的吞吐是虚的。

• 检查点写入带宽单独留预算，不要和训练数据 IO 抢同一条链路。
• 保留最近若干个检查点版本，别只留最新一个，损坏时没得退。
• 恢复流程要演练，包括优化器状态和随机种子的完整加载。
• 节点越多越要提前定故障切换策略，别等出事了现场想。

租卡还是上集群：按持续时长分界

卡数定了，下一个问题是这些卡从哪来。短期实验、对照实验、验证数据配比这类用几天到几周的，优先按量租卡，用多少付多少，随时换机型做对照。长期连续训练且算力需求稳定，再考虑签合同或自建，否则闲置成本会超过单价差。

判断分界线看两件事：预计连续占用的时长，以及中途要不要频繁换卡型做对照。前者决定自建摊薄是否成立，后者决定灵活性值多少钱。租卡前的验货与交付核查，走 /compute/availability 和 /compute/providers 两道，别只看报价单上的单价。

按量租卡

适合短期实验和对照，灵活但单价不一定低，注意隐性开销。

签约或自建

适合需求稳定且持续占用久，前期投入大、闲置是主要风险。

验货核查

交付前确认卡型、显存、互联和可用时长，别只比价格。

落地清单：从估算到开跑的执行顺序

把上面几节串成一条执行顺序，团队照着走就不会乱。核心原则是：每一步都先小规模验证再放大，不要等全部卡到位才第一次跑通流程。规模越大，前期没验证的假设越贵。

1. 写死约束把训练目标与可接受墙钟时间写进方案，作为唯一约束，后续所有估算围着它转。
2. 估单副本最小卡数按权重、梯度、优化器状态、激活四块显存账，估出单个模型副本的最小可行卡数。
3. 小规模跑通全流程先用少量卡跑通训练、检查点、恢复全流程，量出每步耗时和线性度。
4. 按线性度扩卡根据实测线性度决定扩到几卡，同步确认存储和检查点策略能跟上。
5. 端到端演练再开跑正式开跑前用一小段数据做完整演练，包括一次中断恢复演练。

这套链路不能保证你一次买对卡，但能保证每个数字都有来源、每个假设都被验证过。如果中途发现某项估算偏差大，回到对应小节重算即可，而不是推翻整个方案。