
过去几个月AI 算力短缺这件事已经从技术圈内部话题变成几乎所有人都能聊两句的行业新闻。真正让我警觉的是身边越来越多技术负责人开始把“能不能拿到算力”而不是“该用哪套模型”当作第一优先级。他们不是不理解模型而是发现从提出需求到真正跑上训练任务中间隔着的往往不是代码框架而是交付周期。这几天“英伟达称 AI 算力供给短缺至少延续至 2028 财年末”的讨论又刷了一圈。晶圆、HBM、电力三个词被反复放在一起说。很多人第一反应是“又要涨价了”或者“还能缺这么久”。但我的判断是这不是一个单纯的时间预测它真正传递的信号是——算力短缺已经从单一芯片问题演变成了覆盖制造、封装、内存、能源全链条的供应链问题最终会落到每一家企业的算力规划上。谁能在未来几年稳定拿到算力取决于你从什么时候开始规划而不是从什么时候开始抢。1. 先别急着把“2028 财年末”当作预言理解它的口径更重要看到这个时间点第一件事不是焦虑而是搞清楚公司是怎么算时间的。1.1 “至少延续至 2028 财年末”到底是什么意思英伟达的财年不是自然年。按公司习惯口径2028 财年大致覆盖 2027 年年初到 2028 年年初。所以这句话用更直白的方式说就是“按当前的供需趋势判断算力紧张的局面还会维持好几年。”但要注意这是一个基于当前订单、产能建设周期和需求增长预期的判断属于公司层面的供给评估不是写死的物理规律。如果需求增速放缓、产能按期交付、能效技术取得突破或者经济周期发生调整时间点都可能变化。所以理性一点看待它更像是一个“对供给侧投资节奏的提醒”而不是一个精确到财年的预言。过去很多人低估了算力短缺的持续时间原因是习惯用芯片行业的摩尔定律思维来想问题觉得新一代 GPU 发布后性能翻倍供给压力自然化解。但这次的问题是光有新的 GPU 设计不够还要有足够的晶圆产能来制造有足够的 HBM 来配套有足够的电力来让它跑起来。三代技术叠加任何一个环节落后都会被放大成整体瓶颈。1.2 为什么这个时间点会让产业链紧张芯片迭代周期大约一到两年但一座晶圆厂从动工到量产往往要三到五年。HBM 的扩产也需要新增厂房、设备和测试能力。电力设施更慢电网扩容、变电站建设、储能配套涉及审批、施工、并网时间单位通常是年甚至更久。也就是说芯片设计端可以一年翻一次代制造端却是按五年维度规划的。这种“产品快、供应链慢”的错位是“短缺持续到 2028 财年”这种说法真正成立的底层原因。对普通用户来说这意味着不用指望某个新显卡发布后算力价格马上回落对企业来说这意味着采购窗口要前置规划周期要从季度拉长到年度甚至更长。2. 晶圆、HBM、电力三种约束同时出现才是真正的麻烦很多行业短缺是单点问题比如某一种原料缺货找到替代就能缓解。这次不一样的是最上游的制造、最核心的配套芯片、最底层的能源基建三类约束同时卡在那。2.1 晶圆制造产能没有快速伸缩的弹性晶圆是半导体的地基。先进制程的产能建设周期长、投入大而且不能像软件服务一样临时扩容。即便新增产能已经规划设备交付、工艺调试、良率爬坡都需要时间。另一个容易被忽略的点是AI 芯片消耗的晶圆面积远大于普通消费级芯片。同样一片晶圆能切出的 AI 芯片数量明显更少。GPU 本身尺寸大、晶体管密度高、制造难度大对先进制程产能的占用本来就重。当 AI 训练和推理需求同时增长时制造端感受到的压力会比终端用户看到的更早、更猛烈。理解了这一点就能明白为什么“新一代产品发布”和“供给压力缓解”之间有一大段延迟。新产品同样需要晶圆产能如果总产能没跟上发布新品并不能解决短缺只是把有限产能优先分配给毛利率更高的产品。2.2 HBMGPU 的“内存伴侣”已经成为独立瓶颈GPU 算力再强数据喂不进去也是白搭。HBM 就是专门为这类高带宽场景设计的存储方案它和 GPU 封装在一起直接影响训练和推理能跑多快、跑多大模型。HBM 的瓶颈不在 GPU 设计能力而在存储制造、测试和封装环节。HBM 需要多层 DRAM 堆叠生产难度大、良率爬坡慢。加上 HBM 不是标准内存颗粒需要与 GPU 协同设计供应商认证周期很长。从实际情况看HBM 产能常常被讲成“决定下一代 GPU 出货量能到多少”的关键变量。这里有一个容易忽视的传导关系如果 HBM 供应不足即使晶圆环节能生产足够多的 GPU 核心最终整卡出货量依然会被压住。换句话说GPU 短缺不能只靠多建晶圆厂解决还要同步解决存储和先进封装的产能。这也是为什么业内会把晶圆、HBM 并列提出来而不是只说“芯片不够”。2.3 电力算力竞赛的终点是能源配额绝大多数人在讨论 AI 算力时最先想到的是 GPU 型号、显存大小、集群规模很少第一时间把电力当作核心变量。但实际落地时电力往往是比芯片更难解决的约束。一个高密度 AI 机柜的功率需求非常可观和传统机柜完全不在一个量级。你要部署大规模 GPU 集群不是买几十张卡插进机房就行而是要看机房电力配额够不够、供电架构能不能支撑、散热是否跟得上、电力成本是否符合预算。很多存量机房即便有空置空间电力容量也未必支持新上 AI 设备。更关键的是电力设施的建设周期比半导体产能还要长。电网连接、变压器扩容、储能配套、绿电采购每一环都涉及工程和审批。所以你会看到算力中心选址越来越关注的不再只是网络带宽而是当地电力供给、电价水平、消纳能力和气候条件。电力从幕后走到台前成为算力供给的一个硬约束这不是夸张而是已经发生的工程现实。注意对普通开发者来说短期感知最强的可能是“排队变久、配额变小、价格变贵”真正到了数据中心层面卡住你的往往不是下单晚而是电和房子。3. 算力短缺如何传导到你的日常开发和技术决策大家最关心的是大环境缺算力跟我有什么关系核心关系是它会改变你拿到资源的方式、等待时间、成本结构以及技术选型的优先级。3.1 从“按需采购”变成“提前排队”过去做 AI 项目常见路径是先申请几张卡跑实验效果好了再扩充。在算力相对充裕时这没问题。但算力紧缺时这种做法会频繁碰壁——你临时要卡资源池里没有你申请小规模配额平台优先保障生产任务你追新模型厂商优先供货给大客户。这是一个很现实的转变算力从“随用随取”变成“计划分配”。企业内部会开始要求你提前报需求、说明用途、预估用量、给出周期。开发者也必须接受今天想跑一个想法很可能要排队到几天甚至几周之后。这听起来不优雅但算力紧张周期里就是这样的规则。3.2 算力报价里开始包含“可预期性”的成本当供给短缺时价格不只是变高还会变得更不稳定。同样的训练任务在不同时段竞价、在不同区域发起成本可能差很多。对团队来说比绝对价格更重要的是“可预期性”。引入一个参考框架如果你只是跑少量推理或小规模微调按时付费可能是划算的因为灵活。但如果你要训练一个固定迭代周期的模型更建议锁定一段时间的资源或预留配额因为你能大概知道成本上限。否则一次跑失败重来或者排队时间超出预期隐形成本会高得吓人。3.3 “免费 token”和“总量短缺”并不矛盾有段时间大家发现部分云平台或开发者计划还在发放免费 token就疑惑既然算力短缺为什么还有免费资源其实总量短缺不意味着所有资源都被占满平台完全可以在低峰时段、特定任务类型、部分区域释放一些额度用来吸引开发者试用、培育生态。这更像一种运营策略把边缘时段和过剩资源利用起来为后续付费转化创造入口。所以不必把“免费 token”和“短缺”对立起来。短缺是总量层面的免费额度是局部、低优先级、有时段限制的。理解这一点有助于合理安排你的真实任务免费资源适合试错、验证思路不适合跑长期稳定生产任务。3.4 软件优化被重新重视算力贵了以后第一反应是“买更多卡”但更理性的选择是“先把已有算力用得更狠”。这一步正在带动周边技术重新被关注分布式训练框架的优化效率推理引擎的量化手段混合精度训练和模型压缩任务调度与优先级管理冷热数据分层和缓存策略。这些过去看起来很“偏工程”的事在算力受限时反而成为性价比最高的投入。给团队的建议是不要把成本压力全部转嫁给采购先看看现有流程里有多少算力被浪费掉了。4. 这三类受影响的人感受和应对方式完全不同“算力短缺”作为一个宏观话题落到不同角色身上体感差别很大。把人群分清楚才能避免用一套通用建议解决所有问题。4.1 企业技术负责人预算结构比模型选型更重要如果你是技术总监、CTO 或项目负责人最需要转变的是预算结构。以前你只需要“估计今年要花多少钱买卡”现在必须回答几个问题未来 12 个月的稳定算力需求是多少高峰期如何应对是排队还是临时扩容哪些任务必须自建哪些适合上公有云预算有没有弹性能否接受算力价格上涨团队有没有备用方案比如切换到其他供应商或硬件。算力紧缺阶段企业之间竞争的不只是模型效果更是“谁能更早锁定资源”。这要求负责人提前建立算力台账把资源需求和使用情况纳入项目评估而不是等项目启动后才开始找算力。同时要注意避免“堆越多越好”的惯性。先弄清楚项目瓶颈是算力、数据、工程链路还是模型设计。很多团队发现在数据清洗和特征工程上多花两周比多买几十张卡更有效。算力只是手段不是目的。4.2 算法工程师和开发者把“省算力”变成默认习惯对开发者来说不用每天盯供应链新闻但要有意识地调整工作方式先做小规模验证再决定是否跑全量优先使用已有的预训练模型和开源权重减少从零训练在数据层面先做裁剪和采样不要一上来全量喂入训练任务尽量串行复用资源避免并行抢占保存好每次实验的配置和中间结果避免重复运行。我见过不少团队在算力受限后反而效率提升原因是大家开始认真对待实验设计想清楚要验证什么、哪些因素要控制、跑出来结果怎么办。算力紧张会倒逼工程师减少“拍脑袋式”的试错这本身是一件好事。4.3 电力与基础设施从业者算力需求带来了新的机会从这次讨论的热词变化里能看到智慧电力、储能、电力负荷预测、电力交易、电力巡检这些方向被频繁提起算力建设正在成为电力领域的新需求来源。数据中心选址、电网扩容、绿电采购、储能配套都需要电力行业的工程师和数据团队参与。比如一组 GPU 集群运行起来后电力负荷如何预测、储能如何调度、故障如何巡检这些都不是空泛概念而是实际存在的工程问题。对关注职业方向的人来说这提示了一个交叉点既懂算力基础设施又懂电力系统和能耗优化的复合能力在未来几年会越来越值钱。算力短缺不只是芯片行业的新闻它正在把能源产业的开发需求带到更多人面前。5. 给普通团队的一套“算力规划”落地框架面对“至少几年内都不宽裕”的算力环境最实用的动作不是焦虑而是做一份算力规划。下面这套框架是我在多个项目里验证过的基本思路不一定适合所有团队但路径可以复用。5.1 阶段一用最小资源验证核心链路技术选型阶段不要直接申请大规模资源。先用一张消费级卡、云端小实例或免费额度跑通数据加载、模型加载、训练循环、结果保存这一整套链路。关键不是跑出多好的效果而是确认流程没有断点。这一步能帮你筛掉大量隐藏问题代码依赖是不是完整、数据格式有没有问题、模型能否正常加载、输出目录是否有权限。如果这些小问题没有提前暴露等资源申请下来再排查浪费时间也浪费钱。5.2 阶段二估算“稳定算力”而不是“峰值算力”很多团队做资源规划时恨不得按最高并发和最大数据量来配置结果预算爆炸。更合理的方式是先估算稳定算力日常持续运行需要多少卡时、训练任务多久跑一轮、推理峰值出现在哪个时段。表格里列一个基本模板规划项要回答的问题参考做法稳定训练量每周实际要跑多少小时按历史任务平均估算别按理想状态峰值需求是否一定要在峰值时间跑能错峰的任务排在低峰时段数据流动数据存储和读取是否拖慢训练检查数据管线先解决 IO 瓶颈模型体积是否可以用量化或蒸馏压缩同等效果下优先选小模型失败成本任务跑失败后重跑代价多大增加检查点保存避免从头再来确定稳定算力之后再考虑超配多少作为缓冲。一般不建议一上来拉满留出 20% 到 30% 的弹性空间就够了。5.3 阶段三建立至少两条备份路径算力越紧张越不能把所有资源寄托在单一供应商上。备份路径不一定是要自建机房可以是一个多云账号、一组备用硬件、一份可切换的推理服务或者一套已经验证过的开源模型权重。更实际的做法是把你的训练脚本和依赖写成可复用的配置。确保将来换一套环境或换一批资源时能快速重建而不是一个人手动配置半天。这看起来基础但到了资源紧张时能快速切换环境本身就是竞争力。5.4 阶段四定期复盘动态调整算力环境不是一成不变的。每隔一两个月把实际用量和预估对比一次看看哪些任务吃掉了大部分资源、哪些集群长期闲置、哪些任务高峰期排队最久。复盘不是找谁背锅而是优化下一轮规划。复盘时重点看三个指标资源利用率买了或租用的 GPU 有多少时间在真正跑任务排队时长从提交任务到开始执行平均花了多久成本有效性单位有效实验结果对应的算力成本而不是单位 GPU 价格。只要持续迭代这套规划算力紧张对你的影响会从“经常卡住”变成“偶尔等待”。提醒先跑通再优化最后才是规模化。这个顺序不要反过来。很多人一上来就搭大集群结果三个月后发现一半资源在空转成本压力全变成了团队内耗。6. 算力周期的本质是“看芯片”转向“看资源”最后回到更底层的问题上来。为什么“英伟达算力短缺”会让这么多人产生持续焦虑因为它揭示了一个过去被忽略的事实AI 产业的增长约束已经从芯片本身扩展到制造、存储、能源甚至地理空间。6.1 芯片迭代快供应链迭代慢过去几年AI 领域有一个隐含假设只要模型做出来算力总会在下一代硬件里得到解决。但现实是半导体供应链的物理周期摆在那里。晶圆厂、封装产线、HBM 产能、电力基础设施哪个都不能像软件版本一样快速发布会。你可以在芯片设计上做到一年一代但整个产业链协同跑起来之后实际能出货的规模会受制于最慢的那个环节。所以衡量 AI 算力未来的关键不再是“某家公司发布了什么新芯片”而是“整个供应链体系什么时候能把产能真正放出来”。这个视角转换很关键它决定了你是当一个“看发布会做判断”的人还是当一个“按供应链周期做规划”的人。6.2 未来几年值得长期关注的方向顺着这个思路有几类能力会比单纯追新硬件更有长期价值算力调度与资源管理把有限 GPU 用得更好分布式训练与推理优化降低单任务资源占用模型压缩与量化用小模型逼近大模型效果低碳与能效优化响应电力约束和成本压力多云与异构算力接入避免被单一供给困住。这些方向不会因为某一天“算力不缺了”而失去价值。恰恰相反算力从稀缺到富余的过渡期恰恰是最需要这些能力的阶段。6.3 别陷在时间点里重点是想清楚自己的排队位置“至少延续至 2028 财年末”这句话真正值得关心的不是具体日期而是两个问题你的需求处在供应链优先级里的哪一层你有没有为更长的等待周期做好准备如果只是一个偶尔做实验的开发者正常用云资源或免费额度即可不必因为新闻就恐慌性囤卡。如果你是技术负责人需要尽早把算力规划纳入项目周期并和财务、采购、基础设施团队对齐。如果你在电力或基础设施行业可以关注算力带来的电力需求、储能和负荷管理问题这是未来几年确定性很高的需求方向。算力供给的紧平衡未来几年很可能是一种常态。这种环境下谁能更早算清楚自己的需求、更合理设计资源结构、更灵活地切换路径谁就能跑得更稳。与其问“算力什么时候不缺”不如问自己“下一次需要大量算力时我已经排到哪一步了”