算力不够时，先优化代码，再考虑加卡；因为多数情况下瓶颈不在算力总量，而在数据管道、通信、显存和算子效率。 你盯着 nvidia-smi，发现 GPU 利用率只有两成，风扇转得欢，卡却在摸鱼，这时候买新卡，只是多几张摸鱼的卡。
算力不够先加卡还是先优化代码？先定位瓶颈
先看GPU到底在忙什么
别急着下单,先跑几条命令。
nvidia-smi -l 1：看整体利用率、显存、功耗。nvidia-smi dmon -s u：按秒采样，观察利用率波动。dcgm-exporter：接入 Prometheus，看长期趋势。nsight systems：抓训练或推理时间线，定位空洞。torch.profiler：看算子耗时、CUDA kernel 占比。py-spy top：看 Python 进程哪个函数在卡。
GPU 利用率长期低于三成，加卡就是浪费，业内专家指出，训练任务中数据加载、CPU 预处理、通信同步经常成为隐性瓶颈。
三种典型瓶颈
- GPU 利用率低，CPU 很高：DataLoader 是短板。
num_workers太小、pin_memory=False、没有预取，都会让 GPU 等数据。 - GPU 利用率忽高忽低，显存没满：分布式通信在拖后腿，NCCL 配置、梯度同步、拓扑结构都可能有问题。
- 显存先爆，算力还有余：模型太大或中间激活太多，梯度检查点、ZeRO、FSDP 能救。
先分清是“算不动”还是“喂不饱”，喂不饱的卡，加得越多，浪费越大。
大模型训练算力不足怎么优化代码？从数据到通信逐层排查
数据管道
num_workers设为 GPU 数的 4 到 8 倍，观察是否改善。pin_memory=True，prefetch_factor=2或更高。- 用 WebDataset、DALI 替代 Python 原生加载。
- 把小文件合并成 TFRecord、WebDataset 分片，减少 IO 随机读。
计算精度
- 开启 AMP：
torch.cuda.amp.autocast
- BF16 比 FP16 更稳，适合大模型。
- FP8 在 H100 等新卡上可用，但要检查算子支持。
显存与并行
- 梯度检查点：
model.gradient_checkpointing_enable()，用计算换显存。 - ZeRO-2/ZeRO-3：分片优化器状态、梯度、参数。
- FSDP：适合 PyTorch 原生分布式。
- 张量并行：单层放不下时切开矩阵乘。
编译与算子
torch.compile：一行代码可能带来明显加速。- FlashAttention：长序列训练必备。
- 融合算子：LayerNorm、激活函数、矩阵乘融合。
- 自定义 CUDA kernel：最后手段，维护成本高。
这些优化做完,相当于凭空多出几张卡，而且不增加电费、机架和运维。
GPU加卡和代码优化哪个性价比高？算一笔账
加卡不是买白菜,一张卡背后是服务器、电源、散热、机架、交换机、电费、运维、软件授权，优化代码的成本主要是人力时间。
| 维度 | 优化代码 | 加卡 |
|---|---|---|
| 成本 | 人力、时间、测试 | 硬件、电费、机房、运维 |
| 收益 | 提升吞吐、降低显存 | 线性增加算力 |
| 风险 | 精度、稳定性 | 供应链、兼容性 |
| 周期 | 几天到几周 | 几天到几月 |
| 可逆性 | 高，可回滚 | 低，退换麻烦 |
行业共识认为,先做 profiling 再扩容，能避免相当一部分无效投资，如果优化能让吞吐提升三成，对 8 相当于省下 2 到 3 张卡的钱，中小团队尤其要算这笔账。
算力不足先加卡还是先优化代码价格对比
- 云 GPU 按小时或包月计费，适合短期峰值，优化代码后，可能不需要升级到更高配置。
- 本地买卡一次性投入大,但长期折旧后单卡成本低，前提是利用率要上去。
-
优化人力成本是一次性的,收益却持续存在。
- 如果业务增长快,云上弹性加卡加代码优化可以并行。
- 如果业务稳定且卡供应紧张,优先榨干现有硬件。
价格不是唯一指标,停机时间、交付周期、模型迭代速度都要算进去。
推理场景算力不够先加卡还是先优化代码？延迟和吞吐分开看
推理和训练不一样,训练看吞吐，推理既要看延迟，也要看吞吐。
延迟敏感
- 量化：INT8、FP8、AWQ、GPTQ。
- KV cache 优化：PagedAttention、连续批处理。
- 投机采样：小模型草稿，大模型验证。
- 算子融合：TensorRT-LLM 能自动做。
如果用户等不起,先优化代码，加卡不一定降低单次延迟，除非做张量并行。
吞吐敏感
- 动态批处理：Triton Inference Server、vLLM。
- 连续批处理：vLLM 的强项。
- 多卡张量并行：把大模型切开。
- 如果优化后 QPS 仍不足，加卡最直接。
推理场景的决策更依赖 SLA，延迟每降一点，用户体验就好一点，吞吐每升一点，单位成本就低一点，先看哪个指标卡住了业务。
北京AI公司算力扩容先加卡还是先优化代码？地域与供应链
北京机房资源紧张,电价和租金不低，卡供应受渠道影响，热门型号可能要等，这时候更要想清楚。
- 北京本地加卡：延迟低，数据合规方便，但扩容周期长、成本高。
- 云上加卡：按需开通，适合突发流量，但长期成本可能更高。
- 代码优化：不受地域限制，一次投入，多地复用。
- 如果业务必须在北京落地,优先优化代码，再根据合规要求决定本地还是云上。
上海、深圳、杭州的团队也类似，供应链和电价会变，优化代码的能力不会贬值。
什么情况下必须加卡
优化不是万能药,以下情况加卡更合理：
- 模型参数、数据量、并发数持续增长，优化已到天花板。
- 优化后 GPU 利用率已经较高，比如稳定在七成以上。
- 业务 SLA 硬约束，延迟或吞吐不能再等。
- 新模型架构对显存和算力需求跳变。
- 加卡前检查：PCIe/NVLink 拓扑、电源功率、散热、机架空间、驱动和 CUDA 版本。
加卡是买时间,优化是买效率，顺序错了，钱就白花。
实操决策流程
- 监控：用
nvidia-smi dmon、DCGM 连续记录 GPU 利用率、显存、功耗。 - Profiling：用
nsight systems、torch.profiler抓时间线，找空洞和热点。 - 优化：数据管道、混合精度、梯度检查点、分布式策略、算子融合。
- 复测：对比吞吐、延迟、显存、精度，确认收益。
- 决策：若优化后仍无法满足业务，优先云上按需加卡；若长期稳定，再考虑本地扩容。
每一步都要有数据支撑,拍脑袋加卡，容易变成沉没成本。
Q&A：算力不够先加卡还是先优化代码常见问题
优化代码会不会影响模型精度？
有可能,但可控，混合精度、量化、梯度检查点都可能引入数值差异，做法是保留基线，做小规模对比实验，监控 loss 曲线和评估指标，如果精度下降超过容忍范围，就回滚或调参，多数情况下，BF16 和 FP16 的精度损失很小。
加卡后GPU利用率还是低怎么办？
先查数据管道。num_workers 是否够，pin_memory 是否开，IO 是否成瓶颈，再查通信，NCCL 拓扑、网卡带宽、梯度同步频率，最后查 CPU，预处理、增强、后处理是否拖慢，加卡不会自动解决喂不饱的问题。
云GPU按小时计费，算力不够先加卡还是先优化代码价格怎么选？
短期峰值优先云上加卡,配合代码优化降低单位消耗，长期稳定负载先优化代码，再评估本地采购，云上按小时计费适合实验和突发，本地买卡适合持续高利用率，算总拥有成本时，把人力、电费、机房、运维都算进去，算力不够时，先优化代码，再按需加卡，这是多数团队的最优顺序。