英伟达刚刚在财报电话会上给出了一张相当重要的时间表：AI 算力的供给短缺不会在明年结束，至少会延续到 2028 财年末。这比很多人此前猜测的“2026 年供需平衡”要长得多。给出的理由也很直接——瓶颈已经不只是 GPU 芯片本身，而是晶圆、HBM 和电力三个环节同时在卡脖子。
这篇不是测评某个开源项目，而是把英伟达这次表态背后的技术逻辑拆开讲清楚。我会先梳理核心信息，再分别说明晶圆、HBM、电力为什么是当前最紧的三道约束，最后落到开发者视角：算力短缺持续的情况下，模型训练、推理成本、硬件选型和部署策略应该怎么调整。如果你正在做 AI 应用、大模型微调、私有化部署，或者准备买卡、租云 GPU，这篇建议完整看完。
1. 核心信息速览
| 信息项 | 说明 |
|---|---|
| 核心判断 | AI 算力供给短缺至少延续至 2028 财年末 |
| 主要瓶颈 | 晶圆制造产能、HBM 高带宽内存、数据中心电力供应 |
| 受影响环节 | GPU 生产、服务器交付、云厂商扩容、大模型训练与推理成本 |
| 直接后果 | 高端 GPU 供不应求、算力租赁价格上涨、模型训练排期拉长 |
| 受影响群体 | 云厂商、大模型创业公司、企业私有化部署团队、个人开发者 |
| 替代思路 | 模型量化、小参数模型、推理优化、混合云调度、国产算力适配 |
| 开发者关注点 | 显存规划、推理成本估算、API 选型、本地部署可行性 |
需要先说明一个时间口径：英伟达的财年与自然年不同。2028 财年末大约对应 2028 年 1 月底，也就是说，从现在的视角看，供需紧张至少还会持续数年。这是一个偏保守还是偏激进的判断，行业内还有争议，但英伟达作为供给端的核心玩家，它的排产和交付预期本身就说明了问题。
2. 算力短缺的三个底层原因
英伟达说短缺要到 2028 财年末，不是单指 GPU 芯片不够，而是整个算力产业链的三层约束同时达到上限。拆开看，每一层都有独立的物理瓶颈。
2.1 晶圆：制造产能是物理瓶颈
GPU 的第一道约束是晶圆制造。英伟达的旗舰芯片主要由台积电代工，采用先进制程。先进制程的产能扩张周期非常长，一座晶圆厂从动工到量产通常需要两到三年，而设备采购、工艺验证、良率爬坡都需要时间。即使台积电已经在全球多个地点扩建先进制程产能，短期内的月产能增幅仍然有限。
这里需要理解一个事实：AI 芯片消耗的晶圆面积远大于传统芯片。以当前主流的加速卡为例，其 die 尺寸通常在 800 平方毫米以上，一块 12 英寸晶圆只能切出很少的可用芯片。相比之下，CPU 或手机 SoC 的 die 面积小得多，同样的晶圆能切出更多颗。所以 AI 算力需求爆发时，晶圆产能的消耗速度远超传统半导体。
晶圆环节还有一个隐藏约束——先进封装。现代 AI 芯片普遍采用 chiplet 设计，需要将多颗 die 和 HBM 堆叠封装在一起，中间的 CoWoS 等先进封装产能同样紧张。英伟达此前被报道的交付延迟，很多时候瓶颈不在晶圆制造，而在封装环节。晶圆、封装、测试是一条完整的产能链，任何一环卡住都会影响最终的 GPU 出货量。
2.2 HBM：封装环节比晶圆更紧
HBM（高带宽内存）是 AI 加速卡里最关键的存储组件。训练大模型时，模型参数、激活值、梯度都需要高速存取，传统 GDDR 显存的带宽已经无法满足需求。英伟达从 A100 开始大规模采用 HBM，H100、H200 以及 Blackwell 系列对 HBM 的依赖更重。
HBM 的产能瓶颈来自多个层面：
- 制造工艺复杂，需要堆叠多层 DRAM die，良率控制难度高。
- 产能投资周期长，HBM 产线的建设速度跟不上 GPU 需求的增速。
- 主要供应商集中在少数几家存储厂商，扩产节奏相对保守。
一个更值得注意的趋势是，英伟达新一代产品的 HBM 容量和带宽还在继续提升。这意味着即使 GPU 芯片供应不变，HBM 的供需缺口也会随着单卡 HBM 容量的增加而扩大。这也是为什么英伟达在财报会上把 HBM 列为与晶圆并列的核心瓶颈。
对开发者来说，HBM 紧缺带来的直接影响是：大显存显卡的交付周期变长、价格坚挺甚至上涨。如果你计划购买 48GB 或 80GB 显存的加速卡做本地推理，可能需要等待更长时间，或者接受更高的租赁价格。
2.3 电力：数据中心从“芯片问题”变成“能源问题”
前两个瓶颈属于制造端，电力则是数据中心运营端的硬约束。
GPU 服务器的功率密度远超传统服务器。一片 H100 的 TDP 达到 700W，一台 8 卡 GPU 服务器的功率通常在 10kW 以上，加上散热、制冷和配套基础设施，机柜总功耗更夸张。大规模 AI 数据中心的单体功耗已经接近甚至超过一些中小城市的用电规模。
问题在于，电网扩容的速度远慢于 GPU 部署的速度。建设一座大型数据中心，电力接入和审批流程往往需要数年。即便拿到了电力指标，变压器、变电站、输电线路的施工周期也会限制上架速度。
这也是为什么英伟达把电力列为算力短缺的三大原因之一。芯片造得出来、服务器组装得起来，但如果没有足够的电力让它们运行，算力依然是纸面数字。过去大家关注的是 GPU 会不会缺货，现在还要关注地区电网能不能负荷。
3. 算力短缺对 AI 开发者的实际影响
英伟达的表态看起来是宏观产业新闻，但对做实际项目的开发者来说，影响并不遥远。
3.1 大模型训练卡位更紧张
如果你所在团队计划从头预训练一个大模型，需要提前考虑训练集群的可用性。算力短缺意味着：
- 云厂商的 GPU 实例可能长期处于高负载状态，申请大规模训练集群需要排队。
- 训练中途如果遇到节点故障，补货周期可能比预期更长，影响项目排期。
- 训练成本上升，实验迭代次数受限，试错空间变小。
对于只做微调或推理的团队，影响相对小一些，因为单卡或少量卡就能满足需求。但如果是百卡、千卡规模的训练任务，供给紧张带来的排期问题会非常实际。
3.2 推理成本不太可能快速下降
很多人期待 AI 应用落地后推理成本会像云计算一样快速下降，但从目前的情况看，这个预期需要调整。只要 GPU 供不应求，云厂商就没有动力大幅降价。相反，高端算力的价格可能继续维持高位。
推理成本的构成主要有两部分：硬件成本和能源成本。硬件端，HBM 紧缺导致大显存显卡价格坚挺；能源端，电力紧缺推高了数据中心的运营成本。两个因素叠加，推理成本短期内很难出现显著下降。
对开发者的启示是：不要把产品的成本模型建立在“算力价格每年降 50%”的假设上。做商业化应用时，应该更早考虑推理优化和成本控制。
3.3 模型迭代节奏会改变
算力短缺还会影响模型迭代的节奏。过去训练一次模型失败了可以马上重来，现在可能要为每次训练预留更长的时间。这意味着：
- 实验设计要更谨慎，避免低效的盲目试错。
- 小规模实验和消融分析变得更重要，不能动不动就跑全量训练。
- 模型架构的选择会更倾向于参数高效方案，而不是一味追求大参数。
对于使用开源模型的团队，一个比较务实的策略是：基于现有成熟模型做微调，减少从头训练的频率，把有限的算力用在推理和产品迭代上。
4. 算力单位与显卡规格理解
讨论算力短缺时，经常涉及 TOPS、TFLOPS、HBM 带宽这些概念。这里一并理清，方便后续做技术选型时直接对照。
4.1 TOPS、TFLOPS 与 HBM 带宽
| 指标 | 含义 | 关注场景 |
|---|---|---|
| TOPS | 每秒万亿次整数运算，常用于 AI 加速器算力宣传 | 边缘设备、NPU、端侧推理 |
| TFLOPS | 每秒万亿次浮点运算，分 FP32、FP16、BF16、FP8 等精度 | GPU 训练与推理性能对比 |
| HBM 带宽 | 高带宽内存在单位时间内可传输的数据量 | 大模型推理、长上下文场景 |
| 显存容量 | 显存中可同时存放的数据量 | 模型能否加载、batch size 上限 |
大模型推理时，HBM 带宽往往比峰值计算量更重要。因为 transformer 解码阶段的瓶颈在于权重读取速度，GPU 每生成一个 token 都要把全部权重从 HBM 读一遍。模型越大，权重量越大，对 HBM 带宽的需求就越高。这也是英伟达每一代产品都大幅提升 HBM 带宽的原因。
4.2 英伟达产品线的算力等级划分
对于普通开发者，可以从英伟达的产品线大致理解算力分层：
| 产品定位 | 示例 | 适用场景 | 显存特征 |
|---|---|---|---|
| 边缘端 | Jetson 系列 | 嵌入式 AI、机器人、边缘推理 | 小容量、低功耗 |
| 消费级 | GeForce RTX 系列 | 本地开发、小模型推理、图像生成 | 8GB-32GB，性价比高 |
| 专业工作站 | RTX PRO / 专业卡 | 工作站渲染、科学计算、本地微调 | 中高容量，稳定性好 |
| 数据中心 | A100 / H100 / B200 | 大模型训练、大规模推理 | 大容量 HBM，带宽高 |
如果你只是做 AI 应用开发或小规模模型推理，消费级显卡足够起步。如果是生产环境的大模型训练，数据中心级产品才是目标，但它的供应和成本都会受到本次算力短缺的影响。
4.3 消费级显卡在 AI 场景的定位
消费级显卡（RTX 系列）受供应链影响相对小，因为它的显存容量和配置与数据中心产品不同，通常不共享 HBM 产能。对于个人开发者来说，这反而是比较现实的入门选择。
不过消费级显卡有几个限制需要注意：
- 显存容量有限，无法加载超大模型。
- 驱动对数据中心场景有功能限制，例如虚拟化、集群通信等。
- 长期 7x24 满载运行的稳定性不如专业卡。
5. 开发者如何应对：本地部署与云端算力
算力短缺持续的情况下，本地部署和云端算力的选择逻辑会发生变化。两者不是二选一，而是可以根据任务类型动态组合。
5.1 本地部署场景
本地部署适合以下几类需求：
- 数据敏感，不能上传到云端。
- 需要高频推理，长期成本高于硬件购入成本。
- 开发调试阶段，需要快速迭代。
从硬件角度看，本地部署需要关注显存容量和带宽。以 70B 参数模型为例，即使使用 4-bit 量化，加载模型也需要约 40GB 显存，至少需要 48GB 显存的设备。如果只是运行 7B 或 14B 的模型，24GB 显存的消费级显卡通常可以覆盖。
本地部署的现实问题是：高端显卡本身也受供应链影响。HBM 紧缺会间接推高显存价格，大显存显卡的性价比可能不如以前。所以本地部署建议优先考虑推理优化，而不是盲目追求大模型。
5.2 云端 API 场景
云端 API 的优势是灵活、免运维、可按量付费，但算力短缺期间它的成本波动会比较大。如果你选择了云端 API，建议做好几件事：
- 对请求量和成本做预算监控，避免异常调用导致费用飙升。
- 合理设置超时和重试，避免无效请求浪费算力。
- 评估多家服务商的 API 定价，不要长期绑定单一供应商。
5.3 混合调度场景
更稳妥的方案是混合调度：常规任务走本地或按量付费的低优先级实例，突增流量走高优先级 API。这种模式下，即使某一边的算力资源紧张，整体服务也不会中断。
混合调度的关键是把任务做可拆分的抽象，例如定义一个统一的推理请求接口，底层可以切换本地 GPU、远程 API 或队列任务。这样算力价格波动时，只需调整调度策略，不需要改业务代码。
6. 算力供给约束下的工程实践
算力短缺的核心矛盾是供给跟不上需求，但这不意味着开发者只能被动等待。通过工程手段提高算力利用效率，是当前最现实的选择。
6.1 批次与异步推理
对推理服务来说，最直接的优化是批量处理。GPU 的算力在批量推理时利用率更高，单个请求的响应可能变慢，但整体吞吐会大幅提升。具体到工程实现：
# 推理服务批量调度伪代码 import queue import threading request_queue = queue.Queue() def batch_worker(model, batch_size=8): while True: items = [] # 收集 batch_size 个请求，或等待超时 while len(items) < batch_size: try: item = request_queue.get(timeout=0.05) items.append(item) except queue.Empty: break if not items: continue # 一次性推理 results = model.infer([item["text"] for item in items]) for item, result in zip(items, results): item["callback"](result) # 启动后台批量推理线程 # threading.Thread(target=batch_worker, args=(model,), daemon=True).start()这种方式适合聊天机器人、内容审核、文档解析等请求量大的场景。需要说明的是，这不是某个具体框架的代码，而是一种通用的服务端设计思路，实际使用时需要结合你的推理框架做适配。
6.2 量化与模型压缩
同样一张显卡，能运行什么规模的模型，取决于量化程度。以下是常见的量化思路：
- 训练后量化（PTQ）：把 FP16 权重转为 INT8 或 INT4，显存占用大幅下降。
- 量化感知训练（QAT）：训练时考虑量化误差，精度损失更小，但训练成本更高。
- AWQ、GPTQ 等算法：针对大模型推理专门优化的权重量化方法。
量化并不是万能的。极度量化后会带来精度损失，推理速度也可能因为反量化操作而变慢。更稳妥的做法是先用小规模验证集评估量化后的效果，再决定是否在生产环境启用。
6.3 弹性调度与成本控制
当你同时使用多个算力来源时，需要一套成本控制机制。几个比较实用的实践：
- 为每个任务设置算力上限，超过后自动降级到低成本模式。
- 为不同任务设置优先级，保证核心业务优先获得算力。
- 定期清理无效任务和僵尸进程，避免算力被白白占用。
在服务器上用nvidia-smi观察 GPU 利用率时，注意区分“计算利用率”和“显存利用率”。两者都不等于真实性能。更准确的性能判断需要结合训练或推理框架自身的指标，例如每秒处理 token 数、每秒推理次数等。
7. 算力短缺下的硬件选型建议
如果近期有采购 GPU 或云资源的计划，下面几条建议可以作为参考。
7.1 显存容量优先，其次是计算卡型号
大模型推理场景，显存容量决定了你能运行什么规模的模型。在预算有限的情况下，优先保证显存容量，再考虑计算速度。举例来说，24GB 显存的设备可以流畅运行 7B 到 14B 的量化模型，48GB 显存可以覆盖更大规模的模型。
7.2 不要盲目追求最新旗舰
每一代新 GPU 发布时，老一代产品会因为供应充足而出现性价比优势。如果任务不是非要最新的 FP8 或更大显存，上一代产品可能更划算。尤其是在当前新卡供应紧张、价格溢价明显的阶段，老卡的性价比值得重新评估。
7.3 考虑国产算力的适配
算力国产化是当前不少企业和机构在推进的方向。虽然生态成熟度、软件栈和性能表现仍在完善，但对于有政策要求或供应安全需求的场景，国产加速卡已经是不可忽视的选项。
在选型时，需要关注的不只是芯片本身的算力，还包括：
- 软件生态是否支持主流 AI 框架。
- 是否有成熟的推理引擎和量化工具。
- 是否有稳定的技术支持和文档。
- 与存量代码的迁移成本有多高。
7.4 云上优先使用抢占式实例
如果训练任务可以中断恢复，抢占式实例是降低成本的有效手段。它本质上是用“可中断”换取更低价格。适合的场景包括：
- 周期性执行的离线批量任务。
- 可断点续训的模型训练。
- 非实时性要求低的推理任务。
8. 常见问题与应对思路
| 问题 | 可能原因 | 应对思路 |
|---|---|---|
| GPU 租赁价格持续上涨 | 高端算力供不应求 | 改用批处理、量化模型、抢占式实例 |
| 申请训练集群排队时间变长 | 云厂商 GPU 库存不足 | 提前预定时段，拆分训练任务 |
| 本地推理时显存不足 | 模型太大或 batch 过大 | 量化模型、减少 batch、使用 CPU offload |
| API 调用费用超出预期 | 未做预算监控，异常请求过多 | 设置调用上限、增加缓存、监控请求量 |
| 新采购的 GPU 交期很长 | 供应链整体紧张 | 评估二手或上一代产品，或云上替代 |
| 国产加速卡运行报错 | 框架适配不完整 | 查看框架支持列表，使用对应版本驱动 |
这里需要强调一个思路：遇到算力问题，不要第一个想到“加钱买更多 GPU”，而是先想“现有 GPU 是否用满了”。很多团队的大模型推理服务，GPU 利用率只有 10% 到 30%。先做性能分析和优化，往往比增加硬件投入效果更明显。
9. 合规与安全边界
算力紧张可能让一些团队产生“绕过限制使用算力”的想法，这里需要明确几条底线：
- 从正规渠道采购云服务或硬件，不要使用来源不明的算力服务。
- 本地部署和私有化部署时，确保软件授权合法，不传播破解工具。
- 涉及用户数据、隐私数据的推理任务，必须满足数据安全与隐私保护要求。
- 涉及人脸、肖像、声音等敏感数据的 AI 应用，必须获得当事人明确授权，遵守相关法规。
算力资源是工具，怎么用由使用者决定。在成本和效率之外，合规是必须守住的底线。
10. 写在最后：算力短缺周期里的技术选择
英伟达给出“缺到 2028 财年末”的判断，本质上是在告诉整个行业：不要等算力便宜了再动手，要在现有算力约束下优化自己的方案。
对普通开发者来说，最值得做的事情是：
- 建立一套完整的推理成本评估方法，不要只看 API 单价，要算最终的端到端成本。
- 掌握量化、批处理、异步推理这些基础优化手段，它们比任何框架技巧都更接近算力效率的本质。
- 在硬件选型上保持灵活，不绑定单一厂商或单一产品线。
- 关注模型小型化和小模型路线。在算力不足的时候，7B 模型加正确的 RAG 方案，可能比硬跑 70B 模型更实用。
算力短缺是一件坏事，但也逼着行业把之前粗放的算力使用方式好好改一改。等真正供需平衡的那天到来，提前做好优化的团队会发现自己已经跑在前面了。
建议收藏备用。如果你正在规划一个新的 AI 项目，先把上面的成本模型和部署策略过一遍，再决定是买卡、租云还是调 API。
