这次我们来看一个不太一样的题目英伟达官方对 AI 算力供给给出了一个判断——短缺至少延续到 2028 财年末而且卡点不只是 GPU 芯片本身晶圆、HBM、电力三条线同时吃紧。如果你正在选型 GPU 服务器、规划本地推理集群、估算训练任务成本或者只是好奇“为什么显卡这么贵还买不到”这篇文章可以帮你建立一张完整的影响链路图。先从最核心的问题说起算力缺口到底卡在哪个环节。围绕“AI 算力供给短缺”本文会覆盖英伟达给出该判断的背景依据、晶圆产能为什么是上限、HBM 为何成为比 GPU 还紧的瓶颈、电力如何反向限制算力规模、对开发者和企业的实际影响、以及观察算力市场冷暖的几个关键指标。全文不预测股价只拆技术要素和工程影响。1. 核心信息速览先给一张信息速览表把这次“AI 算力供给短缺”事件的关键要素整理清楚。信息维度内容事件主体英伟达NVIDIA核心判断AI 算力供给短缺至少延续至 2028 财年末短缺环节晶圆产能、HBM 内存、电力供给直接影响GPU 交付周期拉长、算力成本上升、数据中心建设周期变长涉及技术栈先进制程晶圆、CoWoS 封装、HBM 高带宽内存、液冷与数据中心供电受影响场景大模型训练、推理服务、私有化部署、智算中心建设对应读者GPU 选型者、算法工程师、运维/Infra 工程师、企业技术决策者核心观察指标GPU 交付周期、HBM 合约价、数据中心 PUE 与并网周期从这张表可以看出英伟达这次说的“短缺”不是单指芯片卖得好而是整个供应链条的产能上限被拉满。所以后文不再讨论“会不会缺”重点讨论“缺在哪个环节、怎么影响部署决策”。2. 适用场景与影响边界先说清楚这个话题不是让你立刻去囤卡而是帮助你判断未来两到三年的基础设施方向。以下场景会受到最直接影响。2.1 受影响最大的三类群体第一类是做大模型训练和微调的团队。训练任务对 GPU 数量和显存容量极其敏感如果交付周期从几周拉长到几个月实验节奏、模型迭代计划都要重排。第二类是提供推理 API 或私有化部署的服务方。推理服务需要长期稳定的算力供给GPU 短缺意味着扩容成本上升直接反映到 API 定价或项目交付成本。第三类是自建智算中心或行业云平台的 Infra 团队。他们要提前锁定设备、电力和机房资源供应链紧张时规划周期要比以往更长。2.2 影响边界这不等于“所有 GPU 都买不到”。不同型号、不同渠道、不同采购体量缺货程度差异很大。企业级旗舰型号和 HBM 容量大的型号最紧张消费级显卡的受控程度相对小一些。另外云端租用 GPU 的短期成本可能上涨但长期看云厂商的大规模集采反而可能提供更稳定的算力供给。所以对中小团队来说“自购硬件 vs 租用云算力”的决策权重正在发生变化。2.3 合规与安全边界算力基础设施属于强监管领域。建设数据中心、采购高端 GPU、对外提供算力服务都涉及合规审批、数据安全、内容安全等要求。无论是自建还是租用都要确认供应商资质、合同条款、数据流向和出口管制要求不碰灰色渠道。3. 为什么是“至少到 2028 财年末”英伟达给出这个时间点本质上是在说供需平衡的拐点不在眼前而在几年之后。要理解这个判断得看算力供给的三条约束线。3.1 需求侧AI 算力需求还在指数增长大模型参数规模继续扩大多模态模型、AI Agent、视频生成、具身智能等新场景不断出现。每一轮新模型发布都会带来一轮推理算力需求的跃升。训练阶段的算力消耗是脉冲式的推理阶段则是持续稳定的。当模型真正进入应用阶段推理算力需求往往超过训练算力。这里有一个常见的估算公式总算力需求 训练算力需求 推理算力需求 训练算力 ≈ 模型参数量 × 训练 token 数 × 常数 推理算力 ≈ 日均请求量 × 单次推理耗时 × 单卡并发系数需求侧的高速增长不是线性爬坡而是阶梯式跳跃。每次有新的能力解锁比如长上下文、视频生成、实时语音交互都会让算力基线抬高一个台阶。3.2 供给侧产能爬坡是物理约束芯片供给不像软件更新可以一夜之间完成。从设计、流片、晶圆制造、封装测试到终端交付整个链条通常以季度为单位计算。先进制程的晶圆厂产能扩充需要建设新产线而一条先进工艺产线的建设周期往往需要两到三年。HBM 的产能扩充同样需要新的产线和设备。电力供给则受制于电网建设、发电装机、变电站扩容周期同样以年为单位。所以英伟达说“至少到 2028 财年末”对应的是这条物理供应链的扩容周期而非单纯的市场供需调节。4. 卡点一晶圆产能与先进封装4.1 晶圆产能为什么是上限GPU 的核心计算单元需要在先进制程晶圆上制造。先进制程的难度不仅在于设计更在于良率爬坡。晶圆产能的一个关键指标是月产能WSPMWafer Starts Per Month。芯片面积越大一片晶圆能切出的可用芯片数越少。旗舰级 GPU 的芯片面积通常很大这意味着同样一片晶圆AI 芯片的产出数量远小于消费级芯片。晶圆产能约束可以简化为单颗 GPU 成本 晶圆成本 / 单片晶圆可用芯片数 封装测试成本 HBM 成本当 GPU 芯片面积增大时可用芯片数下降成本上升。当 AI GPU 需求暴增晶圆厂必须把产能优先分配给高利润的 AI 芯片自然挤压其他产品的产能空间。4.2 CoWoS 先进封装成为独立瓶颈即使晶圆制造产能足够还有一道关卡先进封装。以 CoWoS 为代表的 2.5D/3D 封装技术把 GPU 计算芯片和 HBM 内存堆叠封装在一起实现高带宽互联。这个封装工艺的产能扩张比晶圆制造更慢因为它涉及硅中介层、微凸点、临时键合/解键合等复杂工序。英伟达 AI GPU 出货量受制于 CoWoS 产能是过去两年行业反复提到的瓶颈。晶圆造出来的 GPU die 和 HBM 裸片只有在完成先进封装后才是完整的加速卡。封装产能不够芯片只能停在半成品状态。4.3 对部署决策的影响晶圆和封装双约束带来一个结果高规格 GPU 的交货周期显著长于中低规格产品。具体表现为旗舰训练卡的交付周期可能长达数季。服务器整机交付需要与 GPU 供应节奏匹配。二手市场和租赁市场的价格波动加剧。对于 Infra 团队这要求做预算和规划时多留 buffer不能按“下单即交付”的节奏设计上线时间。5. 卡点二HBM 高带宽内存5.1 HBM 为什么比 GPU 芯片更紧张HBMHigh Bandwidth Memory是 AI 加速卡的关键组件。大模型训练时权重、梯度、优化器状态都要在显存中交换显存带宽直接决定训练效率。HBM 通过 TSV硅通孔将多层 DRAM 垂直堆叠并用先进封装与 GPU 互联带宽远超传统 GDDR。HBM 的产能约束来自几个方面DRAM 晶圆的产能分配有限。HBM 的堆叠良率低于普通 DRAM。先进封装产能与 HBM 产能互相挤占。HBM 的扩产周期长且需要英伟达等客户提前锁量。一个直观的理解方式每颗 AI 加速卡要搭配若干颗 HBM 堆叠体HBM 的总供给量直接限制了 GPU 总出货量。如果你关注过“内存短缺”的报道就会发现 HBM 已经比 GPU 本身更紧缺——GPU 产能可以靠晶圆厂扩产解决HBM 则同时受制于 DRAM 晶圆、堆叠工艺、封装测试三条线。5.2 HBM 对显存配置的影响HBM 容量和带宽直接决定你能跑什么规模的模型。以推理场景为例模型规模显存需求估算典型配置7B 参数模型约 16-20 GB单卡 24GB 可推理70B 参数模型约 140-160 GB多卡并行或 8 卡集群数百 B 参数模型数百 GB 以上多节点集群实际显存占用还受量化精度、上下文长度、批处理大小影响。HBM 紧缺会抬高大显存 GPU 的价格带动小显存卡和量化方案的采用率上升。5.3 开发者的应对方向HBM 短缺会倒逼软件栈优化量化推理FP16 降为 INT8 / INT4用更少显存跑更大模型。上下文优化KV Cache 压缩、稀疏注意力。混合推理部分层走 GPU部分层走 CPU 卸载。内存复用多租户共享显存提高利用率。这些方向的共同点是在大模型效果损失可控的前提下降低对单一卡大显存的依赖。6. 卡点三电力供给6.1 电力是数据中心扩张的天花板AI 算力消耗的电力远超传统云计算。GPU 服务器功率密度高单机柜功耗可能达到 30kW、60kW 甚至 100kW 以上。一个大型智算中心的电力需求往往以百兆瓦甚至吉瓦计。电力短缺的表现形式是有地、有机房、有 GPU但电网容量不够。数据中心从立项到通电涉及电力接入方案、变电站建设、绿电指标审批等多个环节周期可能长达数年。这意味着就算 GPU 产能恢复电力仍然会压制算力供给。6.2 PUE 与算力成本PUEPower Usage Effectiveness是衡量数据中心能效的核心指标PUE 数据中心总能耗 / IT 设备能耗PUE 越接近 1说明越少电力浪费在散热、供电转换等非计算环节。AI 数据中心普遍追求 PUE 1.1-1.3 的水平。液冷技术可以显著降低散热能耗但液冷本身也依赖冷却液、换热设备和机房改造。高密度 GPU 机柜的挑战不只是“耗电”还有“散热密度”。风冷在 20kW 以上密度时已经力不从心液冷成为刚需。这又牵扯到机房基础设施改造和运维能力变化。6.3 电力短缺的工程应对从工程角度看电力约束下可以做这几件事提高机柜功率密度减少单平方米建筑面积的无效开销。采用液冷方案降低 PUE省出更多有效算力功率。错峰调度把非实时任务安排在电力低谷时段。就近部署把算力中心建设在电力富余区域。对于开发者也有一层含义你的任务是否能在功耗受限的时段运行、能否做成可中断恢复的批量任务会直接影响算力成本。7. 算力短缺背景下的 GPU 选型思路7.1 不要只看峰值算力峰值算力TFLOPS是纸面性能实际部署要看显存容量与带宽。互联带宽NVLink / InfiniBand / RoCE。软件生态适配度。功耗与散热要求。交付周期与成本。一张大显存卡可能比两张小显存卡更划算。一张能跑动整个模型、避免多卡通信开销的卡往往比追求极端算力更重要。7.2 训练 vs 推理的选型差异训练场景追求高算力和高互联带宽通常需要多卡集群推理场景追求吞吐和时延更看重显存带宽和批量推理效率。推理场景还可以使用量化推理牺牲部分精度换取吞吐量。7.3 云租用 vs 自建的决策框架在当前短缺环境下自建硬件的最大风险是“买了卡配套的电力和机房没到位”。云租用的优势是弹性扩缩和确定性成本劣势是长期成本可能更高。比较合适的判断方式是建立一个总成本模型总成本 硬件采购成本 机房与电力成本 运维人力成本 利用率系数把 GPU 利用率写进公式里。如果自建 GPU 平均利用率只有 20%而云上按需付费的利用率几乎 100%那云租用的实际成本效率可能更高。在电力、机房、运维都齐备的前提下自建才值得优先考虑。8. 如何观察算力市场的冷暖指标这里给出一套不用依赖内部消息的公开观察方法适合在技术规划和预算汇报中引用。观察维度具体指标数据解读GPU 交付周期厂商渠道报价中的到货时间交付周期拉长说明供给紧张HBM 合约价内存厂商季度财报中的 HBM 指引价格上涨或产能满载说明紧缺云 GPU 价格主流云厂商的 GPU 实例价格波动价格上调说明供需紧张电力申请周期智算中心项目的并网等待时间等待时间越长说明电力约束越明显英伟达财报指引数据中心业务收入与毛利率增速持续高位对应需求强劲库存周转服务器 ODM 厂商库存数据库存下降说明 GPU 被快速消化这些指标可以从公开渠道持续跟踪芯片厂商财报、云厂商定价页、第三方市场报告、智算中心招标公告。9. 短缺环境下的工程应对与部署建议9.1 规划阶段做算力规划时把“短缺”作为默认前提而不是异常情况。具体做法提前 6-12 个月锁定硬件资源。将 GPU 型号和数量做成可替换方案避免绑定单一型号。对能耗、机房空间、网络带宽做同步规划不能只看卡本身。在预算中预留电力扩容和液冷改造费用。9.2 部署阶段下面是一段 GPU 资源监控脚本示例用来持续观察显存利用率、功耗和温度。调度策略需要根据实际集群环境调整。# 每 10 秒采集一次 GPU 状态并追加到日志 watch -n 10 nvidia-smi --query-gpuindex,temperature.gpu,utilization.gpu,memory.used,power.draw \ --formatcsv,noheader gpu_usage.log# 基础版 GPU 利用率采集示例实际监控可接入 Prometheus/Grafana import subprocess import time import csv from datetime import datetime def collect_gpu_info(): output subprocess.check_output( [nvidia-smi, --query-gpuindex,memory.used,memory.total,utilization.gpu,power.draw,temperature.gpu, --formatcsv,noheader,nounits] ).decode() rows [] for line in output.strip().split(\n): index, mem_used, mem_total, gpu_util, power, temp [x.strip() for x in line.split(,)] rows.append({ time: datetime.now().isoformat(), gpu_index: index, memory_used_mb: mem_used, memory_total_mb: mem_total, gpu_utilization: gpu_util, power_w: power, temperature_c: temp }) return rows if __name__ __main__: # 实际使用时按需开启持续采集 with open(gpu_metrics.csv, a, newline) as f: writer csv.DictWriter(f, fieldnames[time, gpu_index, memory_used_mb, memory_total_mb, gpu_utilization, power_w, temperature_c]) if f.tell() 0: writer.writeheader() writer.writerow(collect_gpu_info()[0])这个示例适合在测试环境先验证确认采集频率和字段满足需求后再接入正式监控平台。9.3 任务调度层面算力紧缺时要提升任务调度效率大任务拆成可断点续跑的小任务。非实时任务调度到电力低谷时段。空闲 GPU 自动休眠或切换到低功耗模式。使用容器化部署配合 K8s 动态调度 GPU 资源。以下是一个 Kubernetes 分配 GPU 资源的最小示例apiVersion: v1 kind: Pod metadata: name: gpu-test-pod spec: restartPolicy: Never containers: - name: gpu-container image: nvidia/cuda:12.2.0-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1实际使用时需要提前部署 NVIDIA Device Plugin并确认集群的 GPU 调度策略。这个示例的目的是让你理解 GPU 如何以资源形式被调度而不是直接可用。9.4 推理优化方向面对算力不足优先做推理侧优化见效最快使用 vLLM、SGLang 等推理框架提高吞吐。对模型做 INT8 / INT4 量化降低显存占用。开启 Continuous Batching提高 GPU 利用率。多模型共享 GPU通过显存隔离实现多租户。对长上下文场景做 KV Cache 压缩。这些优化不会损失明显效果但能显著提高资源利用效率。10. 常见问题与排查方法问题现象可能原因排查方式解决方案GPU 采购迟迟不交付供应链紧张交期拉长咨询渠道实际交期并保留书面记录提前锁单、扩展备选渠道、考虑云资源过渡下单后发现机房电力不够电力容量评估不足核对机柜功率和电网接入容量优先选低功耗型号、改用液冷、申请电力扩容GPU 利用率长期偏低任务调度不合理或推理框架未优化用 nvidia-smi 观察利用率调整调度策略、使用高性能推理框架、批量任务合并显存不足导致 OOM模型过大或并发过高检查进程内存占用降低 batch size、量化模型、增加显存或启用内存卸载服务器功耗过高散热方案跟不上检查温度和降频情况改造液冷、调整机房气流组织、限制功耗上限API 推理延迟波动大多租户互相干扰拆分实例或加限流部署独立实例、设置排队策略、启用自动扩缩排查时要注意不同 GPU 型号的功耗、显存、散热基线不同先了解硬件的规格手册再结合日志和指标定位问题不要先改代码再查硬件。11. 最佳实践与工程建议11.1 从“买卡思维”转向“算力运营思维”算力短缺时期单张 GPU 的成本和获取难度都在上升关键是让每一块 GPU 尽量满载运行。建议建立 GPU 资源池而不是为单个项目独立采购。设定 GPU 利用率基线比如训练任务不低于 60%推理服务不低于 30%。为不同任务设定优先级保证高优任务获得资源。预留一部分弹性资源池应对突发流量或模型迭代。11.2 模型与硬件解耦尽量让模型可以灵活适配不同品牌和型号的 GPU。不要因为某个库只支持单一厂商就绑定硬件。开放的模型格式如 Safetensors、GGUF和跨平台推理框架如 ONNX Runtime、TensorRT、vLLM能有效降低硬件迁移成本。11.3 数据和模型资产安全算力资源紧张时团队可能会把数据送到第三方算力平台。这带来几个必须确认的问题数据是否涉及敏感信息、训练脚本是否会外传模型权重、合同是否明确禁止数据二次使用、训练完成后算力平台是否删除副本。任何时候安全合规都不能因为赶进度而妥协。12. 总结与下一步英伟达关于“AI 算力供给短缺至少延续至 2028 财年末”的判断核心提醒是算力不只是芯片问题而是晶圆、HBM、电力三条供应链的共振约束。对开发者来说短期内能改变的不是上游产能而是自己的规划方式、模型部署策略和资源调度效率。建议你优先做三件事第一盘点现有 GPU 资源的真实利用率找到空闲浪费的时段第二对主力模型做一次量化评估确认能否在降低显存消耗的同时保住效果第三重新算一遍“云租用 vs 自建”的总成本账把电力、机房、运维、利用率全部算进去。把这个话题放到更长远看AI 基础设施会从“能买到卡”转向“能运营好算力”谁能在有限算力里榨出更多有效计算谁就掌握了下一阶段的技术主动权。建议收藏备用后续如果供应链指标出现变化可以按第 8 节的观察表重新校准自己的规划。