AI 圈最近几年年年都在谈“算力焦虑”但2025年的焦虑和往年明显不同。往年大家担心的是“交付慢一点”今年英伟达方面传递出的公开判断是AI 算力供给短缺至少延续至 2028 财年末而且瓶颈不是某一个环节而是晶圆、HBM、电力三个环节同时收紧。对研发团队来说这件事的真实影响不在于“显卡又要等多久”而在于技术决策的底层假设变了。以前我们做模型选型、确定训练频率、设计推理服务时默认“算力可以按需买到”现在这个假设不成立了你需要把产能约束、供应波动、成本曲线全部放进技术方案里。这篇文章想重点拆三件事。第一算力短缺到底缺在哪一层为什么说 2028 财年之前不会缓解。第二HBM、晶圆、电力、token 这些词几乎天天出现在热榜上但在工程上到底意味着什么。第三面对算力紧缺研发团队应该怎样调整技术选型和成本模型我会给出可以实际运行的估算脚本和排查清单。如果你正在做 AI 应用开发或者正为团队做算力规划这篇文章建议收藏。1. 这篇文章真正要解决的问题先说一个明确判断算力短缺不是“买不到卡”那么简单它正在改变 AI 研发的工程节奏。很多人会把算力短缺理解为供应链新闻觉得这是云厂商和大规模数据中心才需要关心的事。但从近两年的实际行业状态看算力资源的紧张已经渗透到相当基层的开发环节租用 GPU 实例需要排队热门机型价格波动明显模型的训练和微调频次被压缩小团队的推理服务成本占比越来越高。这篇文章适合三类读者。第一类AI 应用开发者。你关心的不是怎么造 GPU而是每次调用大模型 API 的成本以及模型推理服务的响应延迟。算力短缺会直接影响 token 的价格和服务的可扩展性。第二类算法工程师和技术经理。你手里有大模型训练、微调或行业模型部署的需求需要估算训练一次要多少钱、买多少卡、跑多久。算力短缺意味着混合精度、量化、模型并行这些技术必须从“可选项”变成“必选项”。第三类基础设施和平台工程师。你负责 GPU 集群的运维、调度或算力中心的规划。你需要理解晶圆、HBM、电力三个约束在物理上如何限制单集群规模并据此设计容量和预算。读完这篇文章你至少能带走三样东西一个能用来估算 GPU 显存需求和训练成本的工具脚本一套做算力规划时的判断框架覆盖自建、租用、混合部署三种路径一组实际部署中容易踩的坑和排查方法。2. 核心概念算力、HBM、晶圆、电力、token2.1 算力到底是什么日常说的“算力”在工程上通常指两个不同的东西。第一个是硬件理论算力也就是 GPU 每秒能完成的浮点运算次数常用 TFLOPS每秒万亿次浮点运算或 PFLOPS 来衡量。这个数据很好查每一代 GPU 的规格表上都有。第二个是有效算力即实际训练中 GPU 真正用于计算的时间比例术语上常用 MFUModel FLOPs Utilization模型算力利用率表示。两块相同型号的显卡在不同框架、数据加载和并行策略下有效算力可能是 35% 和 65% 的差别。这个差别在算力短缺的背景下直接决定了你“抢到”的卡到底用出了多少价值。所以后面给出的脚本重点不是算芯片的理论峰值而是估算真实训练场景中的资源需求。2.2 HBMGPU 身边的高速工作台HBM 全称 High Bandwidth Memory即高带宽内存。它是紧贴着 GPU 计算核心放置的一种特殊内存特点是带宽极高、容量小于普通内存但远大于处理器缓存。用一个比喻来解释GPU 是一个需要不断吞吐中间结果的超级流水线工人HBM 就是他手边的工作台。模型参数、中间激活值、梯度都要先放到工作台上计算单元才能快速取用。工作台太小模型放不下工作台太慢计算核心就得频繁等待数据搬运。在大模型训练中单个 GPU 能承载多大的模型直接由 HBM 的容量和带宽决定。这也是为什么 HBM 会成为当前 AI 算力供给中最紧张的环节。HBM 的产能扩张受制于先进封装工艺和良率爬坡比普通存储芯片的扩产节奏慢得多短期内很难快速放量。2.3 晶圆一切算力的物理起点再往上游看GPU 芯片是在晶圆上制造出来的。晶圆是半导体制造的基板晶圆尺寸越大、制程越先进单颗芯片的成本优势和性能优势越明显。AI 加速芯片普遍采用先进制程而先进制程晶圆厂的建设周期非常长。新建产线从动工到满产中间要经历设备安装、良率爬坡、客户验证等多个阶段不是搭一条流水线就能立刻出片。更关键的是GPU 芯片不只是英伟达一家在扩产下游服务器、网络设备、高算力场景产品都在争夺同一批先进制程产能。这意味着晶圆短缺的影响是全局性的逻辑芯片、存储芯片、网络芯片都会受影响而不是某一家厂商单独面临的问题。2.4 电力最容易被低估的硬约束晶圆和 HBM 是“造不出来”的约束电力则是“运不转”的约束。一颗高功率 GPU 在满载运行时功耗在数百瓦级别一台 8 卡训练服务器整机功耗动辄数千瓦。当几十台上百台服务器进入同一个机房对数据中心的供电容量和散热能力都是严峻考验。从行业趋势看AI 数据中心的机柜功率密度正在从过去的 3-5KW 向数十甚至上百 KW 演进。但电网接入、变压器扩容、备用电源、液冷改造都不可能一夜之间完成。所以在不少地区即使芯片到位、服务器到位数据中心能否在合适时间提供足够电力也完全是另一个独立变量。这就是为什么越来越多的人把“电力”和“芯片”并列把它当作 2028 年之前 AI 算力供给的核心约束之一。2.5 token把算力成本翻译成业务成本训练一个模型要消耗多少算力普通人很难直观感受。但如果按 token 计费调用 API算力短缺对业务的影响就非常清晰了。token 是模型处理文本或代码的基本单位可以简单理解成“语义切片”。模型输入和输出都会被切分成 token推理平台按 token 计费。token 单价比算力供给更敏感因为 GPU 越紧张提供 API 的平台就要负担更高的采购成本最终会反映到价格变动或免费额度政策上。这也是为什么现在很多团队特别关注“免费 token”“免费大模型 API 额度”这类信息。合理的判断是用官方开发者平台提供的免费 API 做原型验证是高效的但生产环境必须建立自己的成本模型不能依赖短期免费额度。3. 算力短缺的底层逻辑需求、供给与库存先看需求端。大模型训练和推理本身就在持续吃算力但更重要的是应用形态正在变化。早几年的 AI 产品主要做离线批处理一次计算可以慢慢跑。但 AI Agent 普及之后一个任务往往需要模型多次推理、多轮调用在线推理的调用量呈指数上升。同一个模型从“单次请求”变成“多步 Agent 流程”算力消耗可能放大数倍到数十倍。这意味着算力需求增长曲线不仅没有放缓反而变得更陡。再叠加多模态模型参数量持续扩大、端上 AI 应用开始加速普及整个算力需求盘子处在高速膨胀的状态。再看供给端。三个瓶颈相互叠加先进制程晶圆产能扩产慢HBM 被几家主流 AI 加速卡厂商集中采购供需缺口大电力又受限于数据中心建设和电网改造节奏。三个环节里任何一个没有跟上最终落到客户手上的 GPU 交付量都会受影响。从英伟达的公开表态看AI 算力供给短缺至少延续至 2028 财年末。按英伟达财年口径推算这个时间点大致覆盖到日历上的 2027 年到 2028 年初。也就是说这种紧供给状态还会持续数年不是一两个季度就能缓解的。这个判断落到研发团队身上最直接影响有两个。第一算力成本在未来几年不会大幅下降至少不会像摩尔定律时代那样一年降一半。所有 AI 技术选型和成本模型都应该把“算力持续昂贵”作为基准假设。第二不能把“等芯片降价再做大规模训练”当作计划。更稳妥的策略是现在就优化训练效率、推理吞吐和资源利用率用工程手段对冲硬件供给紧张。4. 企业应对策略先选型再规划4.1 三种算力获取方式自建、租用、混合部署是一个老话题但在算力紧缺背景下评估口径要变。自建集群的优势是资源可控、长期成本稳定适合有持续稳定训练需求的团队。风险是前期投入大、建设周期长如果需求波动明显容易造成闲置浪费。云上租用优势是弹性好、不占用现金流适合快速验证和需求波动大的场景。风险是热门机型可能排队总体单价也比自建更贵长期大规模训练的成本会很高。混合部署是目前更主流的选择核心训练任务用自有集群兜底峰值流量和短时验证走云上弹性资源。代价是运维复杂度明显上升需要统一的调度和成本核算体系。获取方式优势风险适合场景自建集群资源可控、长期成本稳定前期投入大、闲置浪费长期稳定训练需求云上租用弹性好、不占现金流单价贵、热门机型排队快速验证、波动需求混合部署兼顾弹性与成本调度运维复杂度高明显峰谷负载、核心训练兜底4.2 模型层的硬件友好优化算力短缺意味着同样的 GPU 资源要跑更多的任务。模型层有四个方向值得优先投入。量化。把模型权重从 fp16/bf16 降到 int8 或 fp8可以在不明显损失精度的情况下减少显存占用、提升吞吐。当前主流推理框架基本都支持量化部署训练阶段也可以逐步尝试低精度技术。蒸馏。用一个参数量小得多的学生模型去学习大模型的输出把大模型能力压缩到小模型里。推理成本可以大幅下降代价是需要额外的蒸馏训练成本和时间。MoE混合专家。把模型拆成多个专家模块每次推理只激活一部分专家而不是让全部参数参与计算。这种架构能有效提高算力利用率很多新一代大模型已经在采用。混合精度训练。使用 fp16/bf16 做前向和反向计算同时保留 fp32 的模型副本用于优化器更新。实践已经证明这是大模型训练的主流方案显存占用和训练速度都能得到明显改善。5. 完整示例显存估算、成本对比与 GPU 监控这一节不再讲概念直接给出三个可运行的实用脚本和一个 PyTorch 训练配置示例。5.1 估算大模型训练显存需求在决定是否使用某个模型进行分布式训练之前先用脚本估算一下单卡显存是否放得下。这个脚本是粗略估算用于选型和容量规划实际值会受并行策略、激活重计算等因素影响。# 文件路径memory_estimator.py def estimate_training_memory( model_params: int, weight_bytes: int 2, optimizer_bytes: int 8, grad_bytes: int 2, batch_size: int 1, seq_len: int 2048, hidden_size: int 4096, num_layers: int 32, activation_bytes: int 2, ): # 权重内存参数量 * 每个参数的字节数 weight_mem model_params * weight_bytes # 优化器状态内存常见 Adam 优化器每个参数约 8 字节 optimizer_mem model_params * optimizer_bytes # 梯度内存通常与权重精度一致 grad_mem model_params * grad_bytes # 激活内存粗略估算实际受并行策略影响极大 # 这里按 Transformer 结构粗略估算k 为经验常数 k 8 activation_mem batch_size * seq_len * hidden_size * num_layers * activation_bytes * k total_bytes weight_mem optimizer_mem grad_mem activation_mem total_gb total_bytes / (1024 ** 3) print( 训练显存粗略估算 ) print(f模型参数规模: {model_params / 1e9:.2f}B) print(f权重显存: {weight_mem / (1024 ** 3):.2f} GB) print(f优化器显存: {optimizer_mem / (1024 ** 3):.2f} GB) print(f梯度显存: {grad_mem / (1024 ** 3):.2f} GB) print(f激活显存(粗略): {activation_mem / (1024 ** 3):.2f} GB) print(f预估总显存: {total_gb:.2f} GB) return total_gb # 示例70B 模型、bf16 权重训练 estimate_training_memory( model_params70e9, weight_bytes2, optimizer_bytes8, grad_bytes2, batch_size1, seq_len2048, hidden_size8192, num_layers80, )运行方式python memory_estimator.py这个脚本能帮你快速判断一张 80GB 的卡到底能不能跑单个 batch 的训练。如果能跑通那就可以进入下一步并行方案设计如果显存明显不够就需要考虑模型并行、梯度累积、激活重计算或降低 batch size。5.2 对比自建与云租用成本算力紧缺背景下自建和云租用不能只看“单卡价格”要看三年综合成本。# 文件路径cost_compare.py def compare_cost( cloud_price_per_gpu_hour: float, # 云上单卡小时价格单位元 gpu_count: int, # 需要多少卡 daily_hours: float, # 每天运行小时数 days_per_year: int, # 每年运行天数 years: int, # 对比周期 self_hardware_cost: float, # 自建硬件总成本单位万元 self_ops_cost_per_year: float, # 自建每年运维、机房、人力成本单位万元 self_utilization: float 0.7, # 自建资源平均利用率 ): cloud_hours gpu_count * daily_hours * days_per_year * years cloud_total cloud_hours * cloud_price_per_gpu_hour / 10000 # 转为万元 self_total self_hardware_cost self_ops_cost_per_year * years # 考虑利用率后自建的“有效算力成本”应该折算 self_effective_total self_total / self_utilization print( 三年成本对比单位万元 ) print(f云上租用总成本: {cloud_total:.2f}) print(f自建硬件 运维成本: {self_total:.2f}) print(f自建按利用率折算后成本: {self_effective_total:.2f}) if cloud_total self_effective_total: print(结论当前负载下云上租用更经济) else: print(结论如果业务长期稳定自建成本更可控) # 示例参数 compare_cost( cloud_price_per_gpu_hour25, # 单卡小时价 25 元 gpu_count8, # 8 卡一台整机 daily_hours12, # 每天跑 12 小时 days_per_year300, years3, self_hardware_cost150, # 硬件 150 万 self_ops_cost_per_year20, # 运维 20 万/年 self_utilization0.7, )python cost_compare.py这个脚本核心逻辑是把“利用率”计入成本。自建集群如果长期利用率只有 30%每卡每小时的真实成本反而可能比云上更贵因为硬件折旧和运维成本被闲置浪费摊薄了。5.3 GPU 监控与日志采集算力紧缺环境下GPU 利用率是必须盯住的运维指标。以下命令可以查看每一张卡的实时状态nvidia-smi --query-gpuindex,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw --formatcsv,noheader如果需要持续采集并保留历史可以用下面的脚本#!/bin/bash # 文件路径gpu_monitor.sh LOG_DIR./gpu_logs mkdir -p $LOG_DIR while true; do timestamp$(date %Y-%m-%d %H:%M:%S) echo [$timestamp] nvidia-smi --query-gpuindex,utilization.gpu,memory.used,memory.total,temperature.gpu,power.draw \ --formatcsv,noheader echo --- sleep 60 done | tee $LOG_DIR/gpu_monitor_$(date %Y%m%d).logchmod x gpu_monitor.sh ./gpu_monitor.sh采集日志后建议再配合 Grafana Prometheus 之类的监控体系做可视化。长期看GPU 利用率、显存占用量、温度、功耗四个指标是容量规划和成本核算的原始数据来源。5.4 PyTorch 混合精度训练配置混合精度已经是当前 GPU 训练的事实标准。下面是一个 PyTorch 训练循环片段使用torch.compile加混合精度。# 文件路径train_bf16_example.py import torch import torch.nn as nn from torch.utils.data import DataLoader, TensorDataset # 假设你已经定义了自己的模型 class SimpleModel(nn.Module): def __init__(self): super().__init__() self.fc nn.Linear(128, 10) def forward(self, x): return self.fc(x) model SimpleModel() model model.cuda() # 有 H100/A100 等硬件时使用 bf16 更稳定 # 如果 PyTorch 版本支持 torch.compile可以试试 try: model torch.compile(model) except Exception: print(当前环境不支持 torch.compile继续使用普通模式) optimizer torch.optim.AdamW(model.parameters(), lr1e-4) criterion nn.CrossEntropyLoss() # 构造一个极小的训练集用于演示 x torch.randn(64, 128) y torch.randint(0, 10, (64,)) dataset TensorDataset(x, y) dataloader DataLoader(dataset, batch_size16) # 混合精度使用 bf16 自动混合精度 scaler torch.amp.GradScaler(cuda) model.train() for epoch in range(1): for batch_x, batch_y in dataloader: batch_x batch_x.cuda() batch_y batch_y.cuda() optimizer.zero_grad() # 前向在 bf16 精度下执行 with torch.autocast(device_typecuda, dtypetorch.bfloat16): outputs model(batch_x) loss criterion(outputs, batch_y) # 反向传播 scaler.scale(loss).backward() scaler.step(optimizer) scaler.update() print(floss: {loss.item():.4f})需要提醒的是混合精度训练中如果出现 NaN 或 loss 不下降优先检查数据是否有异常值、学习率是否过大、硬件是否支持对应精度。使用 bf16 需要较新的 GPU 和驱动支持使用旧卡时请改用 fp16 并保留 fp32 模型副本。6. 运行结果与效果验证以 5.1 节的显存估算脚本为例运行后你会看到类似这样的输出 训练显存粗略估算 模型参数规模: 70.00B 权重显存: 130.38 GB 优化器显存: 521.50 GB 梯度显存: 130.38 GB 激活显存(粗略): 68.72 GB 预估总显存: 850.98 GB看到这个结果再配合“单卡 80GB”这个现实就能立刻理解为什么 70B 级模型的训练极少有人用单卡直接塞下都需要依赖张量并行、流水线并行或多节点训练。这个脚本的价值不在于精确——精确值要等真实启动训练之后用nvidia-smi观察才能拿到而在于“事前判断”。验证正确性的方法也很简单把脚本估算的权重显存加优化器显存与真实训练中nvidia-smi观察到的显存占用做对比误差通常在 10%-30% 之间。如果真实值明显高于估算值说明激活重计算没有开启或者 batch size 设置偏大。7. 常见问题与排查思路在 GPU 训练和推理链路中下面几个问题出现概率最高这里列成表格方便直接对照排查。问题现象可能原因排查方式解决方案训练时显存溢出OOM模型权重、优化器或激活占满显存使用 5.1 节的脚本估算查看 nvidia-smi 内存占用降低 batch size、开启激活重计算、使用模型并行GPU 利用率长期低于 50%数据加载有瓶颈CPU 预处理太慢使用nvidia-smi查看利用率检查数据加载线程数开启 DataLoader 多进程、改用 tfrecord 或缓存机制容器里跑不了 GPU 程序容器缺少 GPU 运行时参数nvidia-smi在容器内执行是否正常启动容器时使用--gpus all参数并安装 NVIDIA Container Toolkit驱动与 CUDA 版本不匹配驱动版本过旧或过新执行nvidia-smi查看驱动版本使用官方 LTS 驱动版本按官方兼容矩阵选 CUDA 版本训练结果出现 NaN学习率过大数据有异常混合精度未正确设置检查 loss 曲线检查输入数据范围降低学习率、开启梯度裁剪、检查自动混合精度配置推理延迟明显增高显存带宽被打满推理并发设置不合理观察服务端日志查看 GPU 利用率与显存读写使用动态 batching、优化模型结构、考虑量化8. 最佳实践与工程建议算力短缺时代GPU 集群的治理核心不再是“买多少卡”而是“每一块卡用出了多少价值”。下面几条建议来自很多实际项目踩坑之后的共同经验。8.1 容量规划三步法第一步确定负载曲线。统计过去 3-6 个月训练任务、推理请求的峰谷分布计算出真实的算力需求曲线而不是拿一个“峰值配卡”的数字。第二步折算有效算力。把硬件理论算力乘上一个合理的 MFU 系数再用于容量计算。训练集群按 0.4-0.6 估算推理服务按 0.3-0.5 估算都会比直接用峰值更贴近现实。第三步加上冗余和缓冲。考虑到 HBM 缺货和供应链波动建议在“当前最紧需求”基础上保留 20%-30% 的扩容空间同时做好“需求紧急时可以快速租用云资源”的预案。8.2 监控与成本治理建立基于 GPU 利用率、显存、温度、功耗的完整监控体系把每次训练任务消耗的 GPU 小时数和费用自动记录到成本账单里。这是目前很多团队最容易忽视的一环。没有成本账单就没有优化方向。有了账单之后你会发现模型的参数量、训练轮次、推理 batch size 这些看似普通的技术参数实际上就是成本参数。8.3 供应链与多云策略不要把鸡蛋放在一个篮子里。即使你决定自建集群也建议保留至少一家云厂商的 GPU 资源作为弹性池。主要原因是全球 AI 算力供给紧张单一供应链的交货时间、价格、售后服务都存在不确定性。混合部署虽然有运维成本但在产能不确定的环境里这是风险最低的策略。8.4 驱动与基础环境管理GPU 服务器环境管理是老问题但在算力稀缺年代出一次环境事故就浪费一次宝贵的算力窗口代价更大。几个提醒生产环境优先选择官方 LTS 驱动版本不要追最新。驱动和 CUDA 版本要记录在集群配置管理里避免不同节点版本不一致。容器化部署时提前把 NVIDIA Container Toolkit 配好避免每次启动都卡在 GPU 权限上。如果使用 Ubuntu Server 等系统安装驱动时注意先屏蔽系统自带的 nouveau 开源驱动否则重启后可能进不了图形界面或报错。下面是在 Ubuntu 系统上以常见 LTS 版本为例安装官方驱动的一种通用思路具体版本号请以英伟达官网识别结果为准# 1. 删除可能冲突的旧驱动 sudo apt remove --purge nvidia-* # 2. 更新内核与基础工具 sudo apt update sudo apt install build-essential # 3. 屏蔽 nouveau echo blacklist nouveau | sudo tee /etc/modprobe.d/blacklist-nouveau.conf echo options nouveau modeset0 | sudo tee -a /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u # 4. 重启后到英伟达官网下载对应驱动 runfile并执行 # 具体安装流程以官方文档为准 # sudo sh NVIDIA-Linux-x86_64-xxx.run这一步的重点不是“抄命令”而是强调版本识别和内核匹配。驱动装错最容易出现在“最新”和“兼容”之间的选择上生产环境请克制。8.5 自由与责任边界容器、GPU 调度、多租户共享意味着一个团队用的账号可能有集群共享权限。实际操作中需要注意权限隔离和资源配额避免一个用户的训练任务把整机显存占满影响其他业务。在共享 GPU 集群上建议先为每个团队或项目设置最大 GPU 数和最长运行时间再通过调度系统管理优先级。这不是限制开发者的自由而是在资源稀缺时保证核心任务的稳定性。9. 总结与后续学习方向回到文章开头的判断英伟达已经明确表达AI 算力供给短缺至少延续至 2028 财年末。这意味着未来几年算力稀缺是常态价格波动是常态供应链不确定性也是常态。对研发团队真正有价值的变化不是继续等待“算力降价”而是把工程效率做到极致。写一个成本估算脚本把模型训练显存提前算清楚把 GPU 利用率监控起来让每张卡的使用率变成可量化的指标把自建、租用、混合部署的成本模型放在一起比较把混合精度、量化、蒸馏这些模型层优化落实到位。这些事单看都不难但整体做好之后团队在算力短缺环境里的容错空间会明显变大。后续值得继续深入的方向包括模型并行与分布式训练的进一步调优推理系统的动态 batching 与 KV Cache 优化以及围绕 GPU 集群的 FinOps 成本治理体系。最后想说的是算力短缺会倒逼技术团队更理性地使用计算资源。过去那些粗放的“堆卡跑训练”的方式会逐渐让位于精细化的资源治理。谁能用同样的算力产出更多业务价值谁就更能在这一轮周期里站住脚。