我一直觉得算力对AI团队来说就像柴米油盐对后厨平时不觉得它多金贵可哪一天断档了整条产线立刻瘫掉。前阵子帮人整理一个代号叫“墨子”的算力集群的资源规划又把这件事从头到尾捋了一遍。从一张显卡的浮点峰值到大模型训练的显存账本再到多机多卡之间的通信瓶颈最后落到“有限算力怎么分配”这个决策问题——说到底所有环节都在追问同一件事算力的基石到底是什么我们又是靠什么把它一块一块垒起来的。这篇文章想写给两类人一是准备自己搭算力集群、但又不太清楚该怎么选型和规划的人二是已经在用云资源或公司内部集群却总被分配不到卡、或者“卡很多但训练还是很慢”这类问题困住的朋友。我会把精度、硬件、集群架构、资源配置建模这些话题串起来讲尽量用大家能直接抄作业的方式把“算力”这层窗户纸捅破。1. 算力基石的本质一台机器、一个集群还是一套账本先说结论算力的基石从来不是某块具体显卡而是一整套“把计算力兑现成模型能力”的账本。你手里有1000张A100如果你的显存规划不合理、数据加载跟不上、网络又是千兆以太网那这1000张卡能跑出的有效算力可能只有峰值的20%。所以“算力基石”这个说法拆开看其实包含三块算得够快单位时间内能完成的浮点运算次数也就是卡片的峰值算力。装得够多显存容量、内存容量、存储容量。装不下模型算力再高也没用。传得够快显存带宽、节点间的网络带宽。数据传不动多卡就跟单卡没区别。这三块缺一不可。很多人只盯着第一块买卡时看TFLOPS觉得数字越大越好结果实际用下来发现瓶颈全在第二块和第三块。先给大家一个直观的算账过程。假设我们要训练一个70B参数的大语言模型训练数据量是1万亿token。按照大模型训练里常用的估算公式算力需求大概是计算量FLOPs≈ 6 × 模型参数量 × 训练token数代入数字6 × 70 × 10^9 × 1 × 10^12 4.2 × 10^23 FLOPs。这是什么概念一张NVIDIA A100FP16 Tensor Core的峰值算力大约是312 TFLOPS也就是每秒3.12 × 10^14次浮点运算。理想状态下跑完这个训练任务需要4.2 × 10^23 ÷ 3.12 × 10^14 ≈ 1.35 × 10^9秒换算成小时大约是37.4万小时。也就是说单张A100要把这个模型练完得不吃不喝跑37万多小时。但现实里GPU利用率不可能100%一般集群能做到40%的MFUModel FLOPs Utilization模型算力利用率就算很优秀了。所以实际单卡要跑的时间得再除以0.4也就是约93万小时。如果是一个1000张A100的集群并行训练下总时长大约是93万小时 ÷ 1000 ≈ 930小时约等于39天。也就是说就算你手里有1000张A100训练一个70B模型一个多月才算正常水平。算力这个东西一旦放到大模型场景里瞬间就从“科幻数字”变成了“账单数字”。这也是为什么我坚持说算力规划本质是资源账本的规划不是硬件采购的规划。2. 精度选择是第一道分水岭FP64、FP32、FP16、INT8分别服务谁“墨子”集群最开始做硬件选型的时候团队里就吵过一轮要不要上支持FP64的加速卡有人觉得FP64是“完整算力”不买就是阉割。这个理解放在AI训练场景里其实是个巨大的误区。先看下面这张表把几种常见精度摆在一起。精度位宽动态范围主要用途算力特点FP6464位极大科学计算、物理模拟、数值分析精度最高但AI芯片上速度最慢FP3232位较大传统深度学习训练、通用计算通用性最强的基准精度FP1616位较小AI训练中的半精度运算配合Tensor Core吞吐量高但易数值溢出BF1616位与FP32基本一致大模型训练首选混合精度格式范围大精度略低最实用INT88位极小推理阶段的量化加速吞吐量大适合已训练好的模型FP64在AI训练里基本用不上。大模型训练的困难在于要在超大参数空间里做梯度下降而不是追求小数点后十几位的精确数值。所以现代AI加速卡的FP64算力普遍被刻意压低核心算力都给了FP16、BF16和INT8。如果买卡时为了“FP64更完整”多花一倍预算那这笔钱大概率是白花了。那FP16和BF16选哪个这是新手最容易踩的坑。FP16的尾数位比较多精度稍好但指数的动态范围只有5位遇到稍微大一点的梯度值就容易变成无穷大。BF16虽然尾数位更少精度差一些但动态范围和FP32几乎一样梯度很难爆炸或归零。大模型训练早就不是单纯的“精度越高越好”而是“合理的精度足够的计算吞吐”。现在的Transfomer训练基本默认BF16就是这个原因。INT8则是推理阶段的重头戏。模型训练完需要部署上线时我们会把权重从FP16或FP32量化到INT8让单次运算的位宽变窄从而在同样的硬件上获得更高的吞吐。像我们常用的“W8A8”量化就是权重和激活都用INT8配合Tensor Core能跑出比FP16推理更高的速度。代价是精度损失但经验是大部分模型在INT8下掉点可以控制在可接受范围内尤其是在已经量化校准过的情况下。有个特别容易混淆的点不同精度下的“算力”数值差异巨大。以RTX 3090为例FP32是35.6 TFLOPS左右FP16 Tensor Core算力大约71 TFLOPS稠密矩阵INT8能到140 TOPS以上。很多人看到INT8算力高就觉得训练也该全程INT8——千万别这么干。梯度更新需要足够的动态范围直接INT8训练大概率收敛不了或者发散。训练和推理的精度策略是两套逻辑不能混着用。3. 把硬件算力看透RTX 3090、专业加速卡之间的真实差距“墨子”集群里既有消费级的RTX 3090也有A100后来还添了H100。有人问为什么不全部上顶配这就得算一笔账了。先看几个典型型号的纸面参数型号显存显存带宽FP32算力功耗定位RTX 309024GB GDDR6X936GB/s35.6 TFLOPS350W消费级性价比高RTX A600048GB GDDR6768GB/s38.7 TFLOPS300W工作站专业卡A100 80GB80GB HBM2e2TB/s19.5 TFLOPSFP32400W数据中心训练卡H100 80GB80GB HBM33.35TB/s67 TFLOPSFP32700W旗舰训练卡注意看A100的FP32算力只有19.5 TFLOPS比RTX 3090的35.6还低。但为什么没人拿RTX 3090替代A100差异在三个地方显存容量3090只有24GB装一个70B模型光权重就需要140GBBF16更别提优化器状态了。显存不够整卡就算力再高也白搭。显存带宽A100的2TB/s带宽是3090的两倍多。Transformer训练极其吃显存带宽尤其是Attention机制里的矩阵运算带宽不够时GPU有一半时间在等数据算力根本跑不满。多卡互联A100支持NVLink和NVSwitch卡间通信带宽高达600GB/s而4090/3090之间只能走PCIe带宽只有32GB/s左右连NVLink的零头都不到。大规模并行训练里卡间通信是压死性能的最后一根稻草。这也是为什么“个人电脑共享算力出租”这类玩法听起来很美落地却很难持久。家用电脑的显卡再强拆到多台机器上就是分布式集群而分布式集群的难点恰恰是节点间通信。千兆以太网跑大模型梯度同步一次可能要等几十秒训练进度基本停滞。如果你只是做单机推理或微调小模型那普通显卡完全够用但要做严肃的大模型预训练通信用不了InfiniBand/RoCE级别的设备算力再堆也是废铁。至于RTX Pro 5500这类专业卡它的优势不在浮点峰值而是驱动稳定性、ECC显存和更长的质保周期适合长时间开机跑渲染或科学计算的场景。对AI训练而言它的性价比通常不如同价位的数据中心卡这点选型时要单独评估不能只看宣传页上的TFLOPS。4. 算力集群的骨架网络、存储与调度缺一个都不行一个能稳定产出模型能力的算力集群至少包含五层计算层、存储层、网络层、调度层、监控层。我在“墨子”集群里最深的感受就是计算层是最不缺的部分真正决定上限的是网络和调度。先看网络层。多卡训练的核心操作叫AllReduce——每一张卡算完梯度后要把所有卡的梯度求平均再更新模型。这意味着每一轮迭代都要做一次全集群的梯度同步。如果集群有32张卡每张卡传1GB梯度交换数据就是几十GB的量级。用千兆以太网一次同步可能耗时几分钟用InfiniBand 200Gbps可能就是几秒。所以大模型集群的标准配置是InfiniBand或RoCERDMA over Converged Ethernet配合NCCL的RDMA通信库来跑。没有高速网络多卡扩展的效率会出现严重退化4卡可能只有3卡的实际收益8卡可能只有4卡再多反而变慢。再看存储层。训练数据要喂给GPU模型checkpoint要定期落盘。大模型一次checkpoint动辄上百GB如果存储系统的写入带宽不够保存一次可能卡断整个训练流程。我们在“墨子”上用Lustre并行文件系统数据加载走独立的数据节点避免和checkpoint写入抢带宽。如果你的项目还在起步阶段至少也要保证GPU节点本地有NVMe SSD缓存不能直接从机械硬盘读数据否则GPU算力再高也会被数据加载拖成“等待IO”。调度层同样关键。集群一旦有了几十上百张卡手动分配资源就是灾难。我们用的是Slurm加Kubernetes两套并存长时训练任务走Slurm的队列在线推理服务走K8s弹性的Pod调度。调度层明确规定了“谁有权限用卡、能用几张、跑多久”不然就会出现某人占着8张卡跑实验、真正的重要任务反而排队等卡的情况。最后是监控层。GPU温度、显存占用、功耗、PCIe链路速率、NCCL通信耗时这些指标必须可视化。我们接Prometheus加Grafana每5分钟记录一次集群状态。没有监控的算力集群等于盲开你根本不知道哪张卡已经降频了哪个节点网络拥塞了等训练崩了才去查浪费的都是真金白银。5. 算力约束下的大模型资源配置建模从公式到落地热搜词里有一句很专业的表述“算力约束下提升大语言模型能力的资源配置建模”。说白了就是在有限的算力预算下怎么决定模型的参数量、训练数据量、并行策略和精度方案让模型能力尽量强。这个话题值得单独说因为它是从“有什么资源”到“做什么模型”的决策桥梁。大模型的规模定律告诉我们在固定计算预算C的情况下存在一个最优的模型参数量N和训练数据量D。经典的计算公式是计算量 C ≈ 6 × N × D给定CN和D的乘积基本固定。问题变成同样一批卡你愿意把更多算力花在“增大模型参数”上还是“多看几遍数据”上Chinchilla定律给出的经验结论是参数量和训练token数大致要等比例增长大约每1B参数配20B token。也就是说70B模型对应1.4T token训练数据接近我们前面举例的量级。如果你有60B token的数据却训练一个70B模型参数偏多、数据不足效果反而可能不如直接上小模型。再来看显存约束。训练一个大模型时显存到底被谁吃掉了可以列一个简化版账本模型权重参数 × 精度字节梯度参数 × 精度字节优化器状态AdamW优化器通常要为每个参数保存FP32权重副本、一阶动量、二阶动量也就是参数 × 4字节 × 3激活值前向传播中临时保存的中间结果和序列长度、batch size成正比以70B参数、BF16训练为例模型权重70B × 2字节 140GB梯度70B × 2字节 140GB优化器状态70B × 12字节 840GB激活值随配置变化动辄几十GB总数往低了算也要1120GB显存。这就是为什么一张卡根本放不下必须用张量并行、流水线并行和数据并行还要靠ZeROZero Redundancy Optimizer把优化器状态切分到多张卡上。如果你在规划一个集群不能只看总算力还得验证“显存总容量能不能塞下这套模型并行策略”。我见过太多“理论算力够实际一跑就OOM”的项目根因都在这一步。建模落到实际操作可以写一个非常朴素的资源估算脚本。伪逻辑如下def estimate_train_resources(param_size_b, tokens_b, precision_bytes2, mfu0.4): flops 6 * param_size_b * 1e9 * tokens_b * 1e9 # 假设单卡可用算力 single_card_fp16 312e12 # A100 total_gpu_seconds flops / (single_card_fp16 * mfu) gpu_hours total_gpu_seconds / 3600 # 显存粗估权重梯度优化器状态激活 weight_gb param_size_b * precision_bytes grad_gb param_size_b * precision_bytes opt_gb param_size_b * 12 activation_gb 40 # 经验值按模型和batch调整 total_gb weight_gb grad_gb opt_gb activation_gb return gpu_hours, total_gb这个脚本不是让你拿来直接部署而是提醒你任何集群规划的第一步都得先把“算力需求”和“显存需求”同时算清楚。先有数学上的可行性再谈硬件和框架。约束建模的目标函数可以很粗暴地定义成“在预算内最小化模型loss”也可以更实际地定义成“在交付时间Deadline内选择能跑通的、参数最大的模型”。我个人的经验是与其追求理论最优不如做三层决策——先定参数量和数据量再定并行策略最后定训练框架和超参数。每一步都用可量化的公式去校验别拍脑袋。6. 我踩过的几个算力规划大坑最后分享几个真实踩过的坑希望能帮大家少走弯路。第一个坑是只看算力不看显存带宽。最开始我选卡时盯着TFLOPS后来发现很多模型根本跑不满峰值瓶颈在显存带宽。带宽不足时GPU计算单元全程在等数据和堵车没什么两样。所以买卡或租卡时显存带宽这个指标至少要和算力同等重要。第二个坑是忽略了CPU和内存。GPU节点标配CPU核心数量要够内存要够否则数据预处理阶段就会成为瓶颈。特别是做数据加载增强时CPU那边一卡GPU就空转。我们有一次训练效率奇低排查到最后发现是数据加载进程只给了4个核心导致每个step之间停顿好几秒。第三个坑是没有提前做多卡通信验证。拿4张卡跑一个简单的AllReduce测试看带宽能不能逼近理论值。很多时候租来的云主机的“内网”其实只是千兆共享带宽跑通信测试直接露馅。要测准就用NCCL自带的all_reduce_perf工具跑一遍心里才有底。第四个坑是忽略电源和散热。个人机器攒多卡尤其如此。电源额定功率不够高负载时整机重启机箱散热不行GPU温度超过85度会自动降频有效算力直接掉两成。别觉得这是小问题算力规划里“物理环境”和“软件环境”一样重要。第五个坑是版本对齐。CUDA、cuDNN、PyTorch、NCCL、驱动之间是有一套兼容矩阵的。团队协作时如果有人背着自己装的驱动跑了一个版本另一套环境又跑另一个版本最后排查起来非常痛苦。建议统一用容器封装环境比如Docker加NVIDIA Container Toolkit保证每张卡的环境一致。“墨子”这个项目给我最大的收获是算力规划的每一步最终都要落到可量化、可验证的账本上。精度账、显存账、带宽账、时间账账账要算清。资源永远不够用但把账算明白了你就知道该把宝贵的资源投在哪里。最后再分享一个习惯每次做资源配置改动之前先写一个最小规模的验证任务用1%的数据量跑通全流程再放大到完整规模。这个小习惯替我挡下了不知道多少次因为配置错误导致的整周算力浪费。