2026/8/29 4:34:46
FEATURED · 精选文章 
最近做 AI 应用的同学应该都有一种共同的体感想买的卡买不到买得到的卡越来越贵云上租卡也开始排队。如果你所在的公司还在做大模型训练或推理大概率还经历过卡在资源审批、算力预算超支、模型迟迟不能上线的情况。这些现象背后不只是一个厂商的产能节奏问题而是一条完整的供应链被同时拉满。英伟达最近给出的判断是AI 算力供给短缺至少会延续到 2028 财年末并且这轮短缺不是单一环节的紧张而是晶圆、HBM、电力三大约束同时出现。这个消息放在新闻里可能只是标题但对做技术的人来说它直接影响我们接下来几年的技术选型、成本预算、架构设计和职业方向。这篇文章不只是帮你解读“为什么缺卡”更想从开发者的视角把三件事讲清楚第一这轮算力短缺的产业逻辑到底是什么第二算力紧张会怎样影响我们的日常开发与技术决策第三在资源受限的前提下我们可以通过哪些工程手段把单位算力用得更高效。文章最后会给出一个可以在本地 GPU 上跑通的完整示例以及一组常见问题排查清单方便你结合自己的环境直接实践。1. 这篇文章真正要解决的问题很多技术文章会把“算力短缺”写成宏观新闻告诉你“英伟达又说了什么”然后就没有然后了。但这类信息对开发者的价值不在于记住一个结论而在于理解它会怎样传导到我们的工作里。算力短缺首先影响的是成本。当供给不足时云上 GPU 实例的租赁价格会波动自建机房的采购周期会变长训练一次模型的单位成本会上升。其次影响的是技术选型。你会发现过去可以随意用 70B 甚至更大参数模型做实验现在必须认真计算显存、推理时延和 batch 大小甚至会考虑用开源小模型替代闭源大模型。再者影响的是交付方式。团队可能从“先做大规模训练再优化”变成“先跑通小规模实验再扩展”整个研发节奏都会发生变化。这篇文章适合这几类读者正在做大模型应用开发、但资源有限的算法工程师。需要把模型部署到生产环境、对推理成本和延迟敏感的后端工程师。负责 AI 基础设施选型、预算评估和容量规划的架构师或技术负责人。想理解 AI 产业最近几年真实约束条件的开发者避免被各种营销话术带偏。读完之后你能获得一条相对完整的判断链从“为什么缺”到“缺多久”再到“我该怎么办”而不是停留在“英伟达很赚钱”的表面认知。2. 算力短缺的底层逻辑晶圆、HBM 与电力英伟达把瓶颈归结为三大件晶圆、HBM 和电力。这三者不是三个独立的问题而是一条相互耦合的供应链任何一环卡住整条算力供给都会停滞。2.1 晶圆先进制程不可能快速扩容AI 加速芯片依赖先进制程而先进制程的产能扩张周期非常长。一座晶圆厂从动工到量产往往要以年为单位计算产线的良率爬坡、设备调试、客户验证也都是时间成本。芯片设计公司可以快速调整产品规划但物理制造端不可能在一年内凭空多出一倍的产能。这意味着即使英伟达能设计出更强的 GPU也需要等待晶圆代工厂的产能释放。只要全球对先进制程的需求持续增加晶圆就会成为长期瓶颈。2.2 HBM高性能显存的产能更难跟上HBMHigh Bandwidth Memory高带宽内存是当前高端 AI 加速卡的核心部件之一。AI 模型在训练和推理时需要在短时间内读取大量权重和中间结果显存带宽直接决定了计算效率。没有足够的 HBMGPU 的计算单元再快也发挥不出来。但 HBM 的制造和封装难度远高于普通 DRAM。它需要把多层 DRAM 堆叠起来再通过先进封装与计算芯片集成整个工艺链的良率和产能都受限制。过去几年市场忽略了对 HBM 的投资导致现在 GPU 出货量受制于 HBM 供给。这是为什么“算力紧缺”问题会传导到存储芯片上。2.3 电力数据中心不是有卡就能跑很多人会忽略最后一个约束电力。GPU 本身功率很高一台 8 卡的 AI 服务器满载时功耗可以达到数千瓦这还没算散热和制冷的成本。一个大型 AI 数据中心电力需求往往高于一座中小型城市的基础设施承载能力。更关键的是电力扩容不像插卡那样简单。变压器、变电站、备用发电机、冷却系统、机房承重每一项都要提前规划审批和建设周期很长。所以你会发现即便芯片造出来了、HBM 也到位了仍然可能出现“有卡没电”的状态。这也是英伟达把电力列为与晶圆、HBM 并列的核心瓶颈的原因。2.4 三个瓶颈叠加后的判断晶圆决定芯片能不能造出来HBM 决定芯片能发挥多少性能电力决定芯片能不能持续运行。三者缺一不可任何一个环节延期都会让整个“算力交付周期”拉长。因此英伟达给出“至少延续到 2028 财年末”的判断本质上不是对未来需求的预测而是对供给端扩张节奏的诚实表态。从开发者的角度看这个判断意味着两件事一是未来几年内大规模训练和高性能推理资源会持续紧张价格会有波动但很难大幅下降二是小规模训练、单卡推理、边缘端部署反而更容易获得资源。我们要做的是适应这种“资源分层”的现实而不是等待某个时刻突然变宽松。3. 算力、Token、数据、模型、场景先搞懂这些概念再谈优化谈论“算力短缺”前我们需要把一组高频但容易被混淆的概念理清楚。因为 AI 项目里的算力需求本质上是这五个因素共同作用的结果。3.1 算力算力可以通俗地理解为“硬件每秒能完成多少次计算”。它通常用 FLOPS每秒浮点运算次数或 TOPS每秒万亿次操作来衡量。但算力并不等于“能力”它只是硬件上限。一个任务到底用多少算力取决于模型大小、数据规模、并发请求数和性能要求。算力也有不同类型训练算力关注吞吐和精度推理算力更关注延迟和成本。3.2 Token在大模型场景里Token 是文本被切分后的最小单位。它可以是一个词、一个子词或一个字符。模型处理文本时并不是逐字阅读而是按 Token 进行处理。生成一段回答本质上就是预测一串 Token。Token 数量直接决定计算消耗所以业界常说“Token 就是用算力的货币”。理解 Token 有助于做成本估算。当你部署一个模型时每次用户请求消耗的 Token 数 输入 Token 数 输出 Token 数。同样的模型输出越长消耗的算力越多。这也是为什么很多推理优化手段都会从“减少 Token 生成数量”入手比如限制最大输出长度、做缓存、用更短的提示词。3.3 数据数据是模型训练和微调的燃料。高质量、多样化的数据可以让模型在相同参数量下表现更好。反过来如果数据质量差哪怕你给了模型再多算力也只是在垃圾数据上浪费资源。数据规模不是越大越好清洗、去重、标注的质量往往更关键。对于开发者来说在算力紧张时最划算的做法是先优化数据而不是盲目扩大模型或训练轮数。3.4 模型模型指的是神经网络的结构和参数。参数越多模型理论上能表达的模式越复杂但每次前向和反向传播所需的算力也会显著上升。实际部署时不是参数越大越好因为还要考虑推理延迟、显存占用和成本。很多团队在算力有限的情况下会选择从开源社区下载一个成熟的小模型再针对业务数据做微调效果可能比直接用庞大的闭源模型更好。3.5 场景场景决定了延迟和成本预算。在线客服对话要求首字延迟要低适合部署小模型或蒸馏模型离线批量分析不要求实时响应可以用更大的模型跑更长的时间视频生成、语音合成这类任务对显存和带宽的要求又远高于文本任务。理解场景就是理解“算力需求的上限”。同样一个模型在不同场景下对算力的消耗可以是数量级的差异。这五个因素之间的关系可以用一句话概括模型和数据决定“一次计算要多少算力”Token 和场景决定“一段时间内要计算多少次”而算力是整个系统的天花板。做工程优化时其实就是在这五个变量之间找平衡。4. 算力短缺对开发者的实际影响如果你只是用别人的 API 做应用算力短缺的影响可能不明显。但如果你要自己做训练、微调、私有化部署影响就是直接的。4.1 成本压力从“算力自由”到“算力预算”过去很多团队把 GPU 当“免费试玩的玩具”随便跑实验。算力短缺后云厂商的 GPU 实例价格会更敏感自建机房的设备采购周期也会拉长。你需要学会给每个实验估算成本这个任务跑一次要多少小时、要多少张卡、每小时的单价是多少、是否值得跑。很多公司已经开始在内部推行“算力预算审批”制度本质上就是要让技术团队把算力当钱来花。4.2 训练与调试节奏变慢资源紧张意味着排队。一次大模型微调可能需要等待资源失败后重新排队的时间成本也会增加。这会逼着团队优化实验策略先在小规模数据上快速验证确认方法有效后再放大尽量复用训练结果而不是每次从头训练用更小模型做消融实验最后再用大模型跑正式版本。4.3 部署方案更依赖推理优化如果你的产品需要高并发推理算力不足会直接推高成本。为了让单位算力支撑更多请求你不得不在模型量化、批处理、缓存、模型剪枝、知识蒸馏上花时间。这里的变化是以前优化推理可能只是“加分项”现在变成了“必须项”。4.4 技术选型从“追新”转向“用好手头资源”过去我们习惯等新卡、上新模型。算力紧缺让“新卡”变得更加不可控手头已有的 GPU、已有的模型反而成了最可靠的资产。开发团队更多要考虑的是现有资源上能不能跑得更满能不能用更便宜的方式达到同样的业务效果开源模型和闭源 API 哪个更划算这些决策在短缺背景下显得尤为重要。5. 算力紧张期的技术选型逻辑算力短缺不是让我们什么都不做而是要求我们在“做什么”和“不做什么”之间做更聪明的权衡。5.1 硬件层面优先“够用”而不是“追新”选 GPU 时不要只看“最强的卡”而要看“当前任务的显存和算力需求”。显存大小决定了能否装载模型算力大小决定了推理速度价格决定了能否长期运行。如果你只需要跑 7B 级别的开源模型那么单张 24GB 显存的 GPU 可能比一张 80GB 显存的旗舰卡更划算如果要做大规模训练就需要考虑多卡互联和带宽而不仅仅是单卡性能。在没有确定硬件方案前建议先在云上按小时租用目标型号 GPU用小批量数据跑通验证流程记录实际的吞吐、显存占用和推理延迟再决定是长期租用还是采购。这样可以避免买错硬件。5.2 模型层面开源模型 量化 微调开源模型在算力紧张时期的价值会被放大。你可以下载一个参数规模适中的开源模型在私有数据上做轻量微调然后进行量化部署。这样既控制了模型知识产权风险也避免了每次调用 API 都产生高昂的 Token 费用。量化是这里的关键技巧。所谓量化就是把模型权重从高精度浮点数比如 FP16压缩到低精度比如 INT8 或 4bit以减少显存占用和计算量。代价是精度可能略微下降但在很多任务上这种下降可以忽略不计。可以说量化是在算力短缺时代适配已有 GPU 最重要的一步。5.3 部署层面推理框架选择与并发设计生产环境部署大模型时直接影响吞吐量的有三点模型加载方式、批处理策略、生成阶段的缓存设计。目前社区已经有不少成熟的推理框架专门为高吞吐大模型推理做了优化包括连续批处理、PagedAttention 等机制。选用这些框架往往比自己在原生 PyTorch 上硬调要高效得多。另一方面要在业务层面设计缓存相同输入可以被复用相似问题可以做语义缓存定时任务尽量集中到低峰期执行。这些优化看起来朴素但对降低算力消耗非常直接。6. 算力受限环境下的完整示例在单张 GPU 上跑通大模型推理下面我们用最小可行方案演示如何在算力有限的前提下跑通一个开源大模型的推理任务并做基本的量化与缓存优化。整个过程可以在单张消费级 GPU 或云上按小时租用的实例中完成。6.1 环境检查先把环境准备好确认 GPU 驱动和 PyTorch 都能正常识别显卡。# 查看 GPU 状态 nvidia-smi # 检查 PyTorch 能否使用 GPU python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU only)如果第一条命令能正常显示 GPU 型号和显存说明驱动没问题。如果第二条命令输出False说明 PyTorch 没有检测到 CUDA大概率是安装的 PyTorch 版本是 CPU 版或者 CUDA 版本与驱动不匹配。6.2 用 4bit 量化加载开源模型为了避免显存不足这里使用 4bit 量化加载模型。这样可以让本来需要大显存的模型在较小显存上运行。注意这个功能需要bitsandbytes库支持安装方式可以在官方文档中确认这里不指定具体版本避免误导。在项目目录下新建一个 Python 脚本quantized_inference.py# 文件路径quantized_inference.py from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 这里的模型 ID 需要替换为你实际使用的开源模型例如本地路径或 Hugging Face 上的模型名 model_id your-open-model-id print(Loading tokenizer...) tokenizer AutoTokenizer.from_pretrained(model_id) print(Loading model with 4bit quantization...) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto, load_in_4bitTrue, ) prompt 用一句话解释AI算力为什么会短缺。 inputs tokenizer(prompt, return_tensorspt).to(cuda) print(Generating...) outputs model.generate( **inputs, max_new_tokens128, do_sampleFalse, ) response tokenizer.decode(outputs[0], skip_special_tokensTrue) print(Response:, response)关键点device_mapauto让模型自动分配到可用的 GPU 和 CPU 内存上。load_in_4bitTrue使用 4bit 量化加载显著降低显存占用。max_new_tokens128控制生成长度避免无意义的算力消耗。运行方式python quantized_inference.py如果显存仍然不足可以继续调小max_new_tokens或者换一个参数更小的模型。6.3 用 FastAPI 封装一个带缓存的推理服务真实项目中模型推理通常以服务的方式暴露给业务调用。这里用一个最小化的 FastAPI 服务示例展示如何把推理接口封装起来并加入一个简单的内存缓存避免重复计算相同输入。新建app.py# 文件路径app.py from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForCausalLM app FastAPI() model_id your-open-model-id tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto, load_in_4bitTrue, ) # 简单的内存缓存 cache {} class GenerateRequest(BaseModel): text: str max_new_tokens: int 128 app.post(/generate) def generate(req: GenerateRequest): if req.text in cache: return {output: cache[req.text], cached: True} inputs tokenizer(req.text, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokensreq.max_new_tokens, do_sampleFalse, ) response tokenizer.decode(outputs[0], skip_special_tokensTrue) cache[req.text] response return {output: response, cached: False} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)这是一份极简示例真实项目中还需要考虑缓存淘汰策略避免内存无限增长。并发请求控制防止多请求同时打满显存。请求超时和错误处理。模型预热避免第一个请求过慢。运行服务pip install fastapi uvicorn python app.py另开一个终端测试curl -X POST http://127.0.0.1:8000/generate \ -H Content-Type: application/json \ -d {text: AI算力短缺是什么, max_new_tokens: 64}第一次请求会走模型生成第二次相同文本会命中缓存直接返回结果。通过这种方式可以在不增加 GPU 的情况下提升服务吞吐。6.4 显存管理相关环境变量在使用 PyTorch 跑大模型时还可以开启显存碎片优化减少因显存碎片化导致的 OOM 问题。在启动脚本前设置export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True如果模型体积很大也可以把 Hugging Face 模型缓存目录设置到容量更大的磁盘上export HF_HOME/data/hf_home这些环境变量不改变模型效果但能减少一些工程层面的麻烦。7. 运行结果与效果验证前面示例的预期结果分三层环境检查阶段nvidia-smi能看到 GPU 型号、驱动版本、显存总量和当前占用。PyTorch 检测到 GPU 时会输出True和 GPU 名称。量化推理脚本运行后终端会依次输出加载 tokenizer、加载模型和生成结果的日志最终打印出一段通顺的中文回答。如果显存不足会看到类似OutOfMemoryError的报错。FastAPI 服务启动后能通过curl返回 JSON 格式的output字段第二次请求相同文本时cached字段会变成True响应速度明显加快。判断成功与否的核心指标有三个模型是否成功加载没有报CUDA out of memory。是否返回了可读回答生成文本没有明显乱码或中断。缓存是否生效相同输入第二次请求更快且标记为cached。如果失败优先看两个位置第一是启动时的完整错误日志第二是nvidia-smi里的显存占用曲线。大概率问题出在显存不足或依赖库版本不匹配而不是代码逻辑本身。8. 常见问题与排查思路问题现象可能原因排查方式解决方案驱动安装后nvidia-smi无输出驱动未正确加载或与内核版本不兼容查看系统日志和驱动安装日志按官方驱动安装指南重新安装注意内核版本匹配PyTorch 检测不到 GPU输出False安装的是 CPU 版 PyTorch或 CUDA 版本与驱动不匹配运行python -c import torch; print(torch.version.cuda)安装匹配当前驱动版本的 PyTorch加载模型时报CUDA out of memory模型参数量 推理缓存超过显存容量用nvidia-smi观察显存占用开启 4bit 量化、降低max_new_tokens、换更小模型报错No module named bitsandbytes缺少量化依赖库检查 Python 环境中的已安装包安装bitsandbytes并确认 GPU 驱动满足其兼容性要求推理速度非常慢模型可能跑在 CPU 上或并发设计不合理确认nvidia-smi中 GPU 利用率是否升高检查device_map是否正确避免线程争抢服务启动后外部无法访问防火墙或安全组未放行端口检查本机端口监听和安全组规则在合法授权范围内开放对应端口或改用内网访问上面这些问题几乎都是环境问题不是算法问题。一方面要养成查看日志的习惯另一方面要尽量把依赖版本固定下来用环境管理工具或容器打包减少“本地能跑、服务器不能跑”的情况。9. 算力紧缺时期的工程最佳实践9.1 把算力当作预算来管理每个训练任务、每个推理服务都应该有明确的 GPU 预算。哪怕是内部实验也要记录任务名称、使用卡数、运行时长和显存峰值。这些数据积累起来后你可以清楚地知道哪些任务在浪费资源哪些任务值得继续优化。推荐在团队里建立一个简单的算力登记表格或自动化看板。9.2 优先优化数据而不是盲目调参在算力有限的情况下调参的时间成本和算力成本都很高。更高效的方式是先检查数据质量重复样本是否很多标注是否一致负样本是否充足数据问题往往比模型结构问题更容易暴露修正数据的投入产出比通常高于盲目做超参搜索。9.3 共享模型缓存与预加载团队内多个人使用同一个开源模型时不要在每台机器上重复下载。把模型文件放到一个共享存储目录并设置HF_HOME指向该目录可以节省大量带宽和磁盘空间。服务部署前也建议做模型预加载避免上线后第一个请求因为加载模型而超时。9.4 设计降级方案生产环境的推理服务需要有一份“降级路书”当 GPU 资源紧张时是切换更小模型、减少最大输出长度还是把部分流量切到 API 服务当 GPU 实例故障时有没有备用方案提前设计好这些策略比 CPU 被打满时再临时救火要可靠得多。9.5 重视安全与合规边界在算力资源上跑什么数据、用什么模型需要符合公司制度和相关法规。模型下载、部署、API 调用都要关注数据出境、敏感信息保护、最小权限等问题。在自己负责的职责范围内工作涉及生产环境变更时先做备份和回滚方案这些底线在任何时期都不能放松。9.6 用成本可视化驱动决策当算力紧张时管理者最想知道的不是“你在做什么”而是“做完要花多少钱”。所以建议定期统计每个业务的 Token 消耗量、GPU 小时数、每万次请求的推理成本。这些数据一方面能帮你优化资源分配另一方面也能在申请预算时提供更有说服力的依据。10. 总结与后续学习方向这篇文章把“英伟达AI 算力供给短缺至少延续至 2028 财年末”这个信息拆解到了开发者能理解、能行动的层面。我们梳理了晶圆、HBM、电力三大约束如何影响算力供应链解释了算力、Token、数据、模型、场景这几个核心概念也给出了在算力受限环境下做技术选型的基本逻辑。最关键的是通过一个可运行的本地 GPU 示例演示了量化推理、缓存服务和显存管理的具体做法。接下来你可以做三件事第一用nvidia-smi检查一下手头机器的 GPU 资源确认驱动和 PyTorch 是否匹配第二选一个开源模型在本地或云上用小显存环境跑通量化推理感受一下模型加载、显存占用和推理延迟的真实数据第三结合自己业务场景设计一个包含缓存和降级策略的推理服务把文章里的思路落到代码里。算力短缺是宏观趋势但技术人的竞争力从不会只取决于硬件数量。在同样有限的资源下谁能更快跑通实验、更稳地部署服务、更省地把模型用起来谁就更有主动权。与其焦虑新卡什么时候到货不如先把手里已有的算力用到极致。
AI算力供给短缺至2028，开发者如何应对？
最近做 AI 应用的同学应该都有一种共同的体感想买的卡买不到买得到的卡越来越贵云上租卡也开始排队。如果你所在的公司还在做大模型训练或推理大概率还经历过卡在资源审批、算力预算超支、模型迟迟不能上线的情况。这些现象背后不只是一个厂商的产能节奏问题而是一条完整的供应链被同时拉满。英伟达最近给出的判断是AI 算力供给短缺至少会延续到 2028 财年末并且这轮短缺不是单一环节的紧张而是晶圆、HBM、电力三大约束同时出现。这个消息放在新闻里可能只是标题但对做技术的人来说它直接影响我们接下来几年的技术选型、成本预算、架构设计和职业方向。这篇文章不只是帮你解读“为什么缺卡”更想从开发者的视角把三件事讲清楚第一这轮算力短缺的产业逻辑到底是什么第二算力紧张会怎样影响我们的日常开发与技术决策第三在资源受限的前提下我们可以通过哪些工程手段把单位算力用得更高效。文章最后会给出一个可以在本地 GPU 上跑通的完整示例以及一组常见问题排查清单方便你结合自己的环境直接实践。1. 这篇文章真正要解决的问题很多技术文章会把“算力短缺”写成宏观新闻告诉你“英伟达又说了什么”然后就没有然后了。但这类信息对开发者的价值不在于记住一个结论而在于理解它会怎样传导到我们的工作里。算力短缺首先影响的是成本。当供给不足时云上 GPU 实例的租赁价格会波动自建机房的采购周期会变长训练一次模型的单位成本会上升。其次影响的是技术选型。你会发现过去可以随意用 70B 甚至更大参数模型做实验现在必须认真计算显存、推理时延和 batch 大小甚至会考虑用开源小模型替代闭源大模型。再者影响的是交付方式。团队可能从“先做大规模训练再优化”变成“先跑通小规模实验再扩展”整个研发节奏都会发生变化。这篇文章适合这几类读者正在做大模型应用开发、但资源有限的算法工程师。需要把模型部署到生产环境、对推理成本和延迟敏感的后端工程师。负责 AI 基础设施选型、预算评估和容量规划的架构师或技术负责人。想理解 AI 产业最近几年真实约束条件的开发者避免被各种营销话术带偏。读完之后你能获得一条相对完整的判断链从“为什么缺”到“缺多久”再到“我该怎么办”而不是停留在“英伟达很赚钱”的表面认知。2. 算力短缺的底层逻辑晶圆、HBM 与电力英伟达把瓶颈归结为三大件晶圆、HBM 和电力。这三者不是三个独立的问题而是一条相互耦合的供应链任何一环卡住整条算力供给都会停滞。2.1 晶圆先进制程不可能快速扩容AI 加速芯片依赖先进制程而先进制程的产能扩张周期非常长。一座晶圆厂从动工到量产往往要以年为单位计算产线的良率爬坡、设备调试、客户验证也都是时间成本。芯片设计公司可以快速调整产品规划但物理制造端不可能在一年内凭空多出一倍的产能。这意味着即使英伟达能设计出更强的 GPU也需要等待晶圆代工厂的产能释放。只要全球对先进制程的需求持续增加晶圆就会成为长期瓶颈。2.2 HBM高性能显存的产能更难跟上HBMHigh Bandwidth Memory高带宽内存是当前高端 AI 加速卡的核心部件之一。AI 模型在训练和推理时需要在短时间内读取大量权重和中间结果显存带宽直接决定了计算效率。没有足够的 HBMGPU 的计算单元再快也发挥不出来。但 HBM 的制造和封装难度远高于普通 DRAM。它需要把多层 DRAM 堆叠起来再通过先进封装与计算芯片集成整个工艺链的良率和产能都受限制。过去几年市场忽略了对 HBM 的投资导致现在 GPU 出货量受制于 HBM 供给。这是为什么“算力紧缺”问题会传导到存储芯片上。2.3 电力数据中心不是有卡就能跑很多人会忽略最后一个约束电力。GPU 本身功率很高一台 8 卡的 AI 服务器满载时功耗可以达到数千瓦这还没算散热和制冷的成本。一个大型 AI 数据中心电力需求往往高于一座中小型城市的基础设施承载能力。更关键的是电力扩容不像插卡那样简单。变压器、变电站、备用发电机、冷却系统、机房承重每一项都要提前规划审批和建设周期很长。所以你会发现即便芯片造出来了、HBM 也到位了仍然可能出现“有卡没电”的状态。这也是英伟达把电力列为与晶圆、HBM 并列的核心瓶颈的原因。2.4 三个瓶颈叠加后的判断晶圆决定芯片能不能造出来HBM 决定芯片能发挥多少性能电力决定芯片能不能持续运行。三者缺一不可任何一个环节延期都会让整个“算力交付周期”拉长。因此英伟达给出“至少延续到 2028 财年末”的判断本质上不是对未来需求的预测而是对供给端扩张节奏的诚实表态。从开发者的角度看这个判断意味着两件事一是未来几年内大规模训练和高性能推理资源会持续紧张价格会有波动但很难大幅下降二是小规模训练、单卡推理、边缘端部署反而更容易获得资源。我们要做的是适应这种“资源分层”的现实而不是等待某个时刻突然变宽松。3. 算力、Token、数据、模型、场景先搞懂这些概念再谈优化谈论“算力短缺”前我们需要把一组高频但容易被混淆的概念理清楚。因为 AI 项目里的算力需求本质上是这五个因素共同作用的结果。3.1 算力算力可以通俗地理解为“硬件每秒能完成多少次计算”。它通常用 FLOPS每秒浮点运算次数或 TOPS每秒万亿次操作来衡量。但算力并不等于“能力”它只是硬件上限。一个任务到底用多少算力取决于模型大小、数据规模、并发请求数和性能要求。算力也有不同类型训练算力关注吞吐和精度推理算力更关注延迟和成本。3.2 Token在大模型场景里Token 是文本被切分后的最小单位。它可以是一个词、一个子词或一个字符。模型处理文本时并不是逐字阅读而是按 Token 进行处理。生成一段回答本质上就是预测一串 Token。Token 数量直接决定计算消耗所以业界常说“Token 就是用算力的货币”。理解 Token 有助于做成本估算。当你部署一个模型时每次用户请求消耗的 Token 数 输入 Token 数 输出 Token 数。同样的模型输出越长消耗的算力越多。这也是为什么很多推理优化手段都会从“减少 Token 生成数量”入手比如限制最大输出长度、做缓存、用更短的提示词。3.3 数据数据是模型训练和微调的燃料。高质量、多样化的数据可以让模型在相同参数量下表现更好。反过来如果数据质量差哪怕你给了模型再多算力也只是在垃圾数据上浪费资源。数据规模不是越大越好清洗、去重、标注的质量往往更关键。对于开发者来说在算力紧张时最划算的做法是先优化数据而不是盲目扩大模型或训练轮数。3.4 模型模型指的是神经网络的结构和参数。参数越多模型理论上能表达的模式越复杂但每次前向和反向传播所需的算力也会显著上升。实际部署时不是参数越大越好因为还要考虑推理延迟、显存占用和成本。很多团队在算力有限的情况下会选择从开源社区下载一个成熟的小模型再针对业务数据做微调效果可能比直接用庞大的闭源模型更好。3.5 场景场景决定了延迟和成本预算。在线客服对话要求首字延迟要低适合部署小模型或蒸馏模型离线批量分析不要求实时响应可以用更大的模型跑更长的时间视频生成、语音合成这类任务对显存和带宽的要求又远高于文本任务。理解场景就是理解“算力需求的上限”。同样一个模型在不同场景下对算力的消耗可以是数量级的差异。这五个因素之间的关系可以用一句话概括模型和数据决定“一次计算要多少算力”Token 和场景决定“一段时间内要计算多少次”而算力是整个系统的天花板。做工程优化时其实就是在这五个变量之间找平衡。4. 算力短缺对开发者的实际影响如果你只是用别人的 API 做应用算力短缺的影响可能不明显。但如果你要自己做训练、微调、私有化部署影响就是直接的。4.1 成本压力从“算力自由”到“算力预算”过去很多团队把 GPU 当“免费试玩的玩具”随便跑实验。算力短缺后云厂商的 GPU 实例价格会更敏感自建机房的设备采购周期也会拉长。你需要学会给每个实验估算成本这个任务跑一次要多少小时、要多少张卡、每小时的单价是多少、是否值得跑。很多公司已经开始在内部推行“算力预算审批”制度本质上就是要让技术团队把算力当钱来花。4.2 训练与调试节奏变慢资源紧张意味着排队。一次大模型微调可能需要等待资源失败后重新排队的时间成本也会增加。这会逼着团队优化实验策略先在小规模数据上快速验证确认方法有效后再放大尽量复用训练结果而不是每次从头训练用更小模型做消融实验最后再用大模型跑正式版本。4.3 部署方案更依赖推理优化如果你的产品需要高并发推理算力不足会直接推高成本。为了让单位算力支撑更多请求你不得不在模型量化、批处理、缓存、模型剪枝、知识蒸馏上花时间。这里的变化是以前优化推理可能只是“加分项”现在变成了“必须项”。4.4 技术选型从“追新”转向“用好手头资源”过去我们习惯等新卡、上新模型。算力紧缺让“新卡”变得更加不可控手头已有的 GPU、已有的模型反而成了最可靠的资产。开发团队更多要考虑的是现有资源上能不能跑得更满能不能用更便宜的方式达到同样的业务效果开源模型和闭源 API 哪个更划算这些决策在短缺背景下显得尤为重要。5. 算力紧张期的技术选型逻辑算力短缺不是让我们什么都不做而是要求我们在“做什么”和“不做什么”之间做更聪明的权衡。5.1 硬件层面优先“够用”而不是“追新”选 GPU 时不要只看“最强的卡”而要看“当前任务的显存和算力需求”。显存大小决定了能否装载模型算力大小决定了推理速度价格决定了能否长期运行。如果你只需要跑 7B 级别的开源模型那么单张 24GB 显存的 GPU 可能比一张 80GB 显存的旗舰卡更划算如果要做大规模训练就需要考虑多卡互联和带宽而不仅仅是单卡性能。在没有确定硬件方案前建议先在云上按小时租用目标型号 GPU用小批量数据跑通验证流程记录实际的吞吐、显存占用和推理延迟再决定是长期租用还是采购。这样可以避免买错硬件。5.2 模型层面开源模型 量化 微调开源模型在算力紧张时期的价值会被放大。你可以下载一个参数规模适中的开源模型在私有数据上做轻量微调然后进行量化部署。这样既控制了模型知识产权风险也避免了每次调用 API 都产生高昂的 Token 费用。量化是这里的关键技巧。所谓量化就是把模型权重从高精度浮点数比如 FP16压缩到低精度比如 INT8 或 4bit以减少显存占用和计算量。代价是精度可能略微下降但在很多任务上这种下降可以忽略不计。可以说量化是在算力短缺时代适配已有 GPU 最重要的一步。5.3 部署层面推理框架选择与并发设计生产环境部署大模型时直接影响吞吐量的有三点模型加载方式、批处理策略、生成阶段的缓存设计。目前社区已经有不少成熟的推理框架专门为高吞吐大模型推理做了优化包括连续批处理、PagedAttention 等机制。选用这些框架往往比自己在原生 PyTorch 上硬调要高效得多。另一方面要在业务层面设计缓存相同输入可以被复用相似问题可以做语义缓存定时任务尽量集中到低峰期执行。这些优化看起来朴素但对降低算力消耗非常直接。6. 算力受限环境下的完整示例在单张 GPU 上跑通大模型推理下面我们用最小可行方案演示如何在算力有限的前提下跑通一个开源大模型的推理任务并做基本的量化与缓存优化。整个过程可以在单张消费级 GPU 或云上按小时租用的实例中完成。6.1 环境检查先把环境准备好确认 GPU 驱动和 PyTorch 都能正常识别显卡。# 查看 GPU 状态 nvidia-smi # 检查 PyTorch 能否使用 GPU python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count()); print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU only)如果第一条命令能正常显示 GPU 型号和显存说明驱动没问题。如果第二条命令输出False说明 PyTorch 没有检测到 CUDA大概率是安装的 PyTorch 版本是 CPU 版或者 CUDA 版本与驱动不匹配。6.2 用 4bit 量化加载开源模型为了避免显存不足这里使用 4bit 量化加载模型。这样可以让本来需要大显存的模型在较小显存上运行。注意这个功能需要bitsandbytes库支持安装方式可以在官方文档中确认这里不指定具体版本避免误导。在项目目录下新建一个 Python 脚本quantized_inference.py# 文件路径quantized_inference.py from transformers import AutoTokenizer, AutoModelForCausalLM import torch # 这里的模型 ID 需要替换为你实际使用的开源模型例如本地路径或 Hugging Face 上的模型名 model_id your-open-model-id print(Loading tokenizer...) tokenizer AutoTokenizer.from_pretrained(model_id) print(Loading model with 4bit quantization...) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto, load_in_4bitTrue, ) prompt 用一句话解释AI算力为什么会短缺。 inputs tokenizer(prompt, return_tensorspt).to(cuda) print(Generating...) outputs model.generate( **inputs, max_new_tokens128, do_sampleFalse, ) response tokenizer.decode(outputs[0], skip_special_tokensTrue) print(Response:, response)关键点device_mapauto让模型自动分配到可用的 GPU 和 CPU 内存上。load_in_4bitTrue使用 4bit 量化加载显著降低显存占用。max_new_tokens128控制生成长度避免无意义的算力消耗。运行方式python quantized_inference.py如果显存仍然不足可以继续调小max_new_tokens或者换一个参数更小的模型。6.3 用 FastAPI 封装一个带缓存的推理服务真实项目中模型推理通常以服务的方式暴露给业务调用。这里用一个最小化的 FastAPI 服务示例展示如何把推理接口封装起来并加入一个简单的内存缓存避免重复计算相同输入。新建app.py# 文件路径app.py from fastapi import FastAPI from pydantic import BaseModel import torch from transformers import AutoTokenizer, AutoModelForCausalLM app FastAPI() model_id your-open-model-id tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto, load_in_4bitTrue, ) # 简单的内存缓存 cache {} class GenerateRequest(BaseModel): text: str max_new_tokens: int 128 app.post(/generate) def generate(req: GenerateRequest): if req.text in cache: return {output: cache[req.text], cached: True} inputs tokenizer(req.text, return_tensorspt).to(cuda) outputs model.generate( **inputs, max_new_tokensreq.max_new_tokens, do_sampleFalse, ) response tokenizer.decode(outputs[0], skip_special_tokensTrue) cache[req.text] response return {output: response, cached: False} if __name__ __main__: import uvicorn uvicorn.run(app, host0.0.0.0, port8000)这是一份极简示例真实项目中还需要考虑缓存淘汰策略避免内存无限增长。并发请求控制防止多请求同时打满显存。请求超时和错误处理。模型预热避免第一个请求过慢。运行服务pip install fastapi uvicorn python app.py另开一个终端测试curl -X POST http://127.0.0.1:8000/generate \ -H Content-Type: application/json \ -d {text: AI算力短缺是什么, max_new_tokens: 64}第一次请求会走模型生成第二次相同文本会命中缓存直接返回结果。通过这种方式可以在不增加 GPU 的情况下提升服务吞吐。6.4 显存管理相关环境变量在使用 PyTorch 跑大模型时还可以开启显存碎片优化减少因显存碎片化导致的 OOM 问题。在启动脚本前设置export PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True如果模型体积很大也可以把 Hugging Face 模型缓存目录设置到容量更大的磁盘上export HF_HOME/data/hf_home这些环境变量不改变模型效果但能减少一些工程层面的麻烦。7. 运行结果与效果验证前面示例的预期结果分三层环境检查阶段nvidia-smi能看到 GPU 型号、驱动版本、显存总量和当前占用。PyTorch 检测到 GPU 时会输出True和 GPU 名称。量化推理脚本运行后终端会依次输出加载 tokenizer、加载模型和生成结果的日志最终打印出一段通顺的中文回答。如果显存不足会看到类似OutOfMemoryError的报错。FastAPI 服务启动后能通过curl返回 JSON 格式的output字段第二次请求相同文本时cached字段会变成True响应速度明显加快。判断成功与否的核心指标有三个模型是否成功加载没有报CUDA out of memory。是否返回了可读回答生成文本没有明显乱码或中断。缓存是否生效相同输入第二次请求更快且标记为cached。如果失败优先看两个位置第一是启动时的完整错误日志第二是nvidia-smi里的显存占用曲线。大概率问题出在显存不足或依赖库版本不匹配而不是代码逻辑本身。8. 常见问题与排查思路问题现象可能原因排查方式解决方案驱动安装后nvidia-smi无输出驱动未正确加载或与内核版本不兼容查看系统日志和驱动安装日志按官方驱动安装指南重新安装注意内核版本匹配PyTorch 检测不到 GPU输出False安装的是 CPU 版 PyTorch或 CUDA 版本与驱动不匹配运行python -c import torch; print(torch.version.cuda)安装匹配当前驱动版本的 PyTorch加载模型时报CUDA out of memory模型参数量 推理缓存超过显存容量用nvidia-smi观察显存占用开启 4bit 量化、降低max_new_tokens、换更小模型报错No module named bitsandbytes缺少量化依赖库检查 Python 环境中的已安装包安装bitsandbytes并确认 GPU 驱动满足其兼容性要求推理速度非常慢模型可能跑在 CPU 上或并发设计不合理确认nvidia-smi中 GPU 利用率是否升高检查device_map是否正确避免线程争抢服务启动后外部无法访问防火墙或安全组未放行端口检查本机端口监听和安全组规则在合法授权范围内开放对应端口或改用内网访问上面这些问题几乎都是环境问题不是算法问题。一方面要养成查看日志的习惯另一方面要尽量把依赖版本固定下来用环境管理工具或容器打包减少“本地能跑、服务器不能跑”的情况。9. 算力紧缺时期的工程最佳实践9.1 把算力当作预算来管理每个训练任务、每个推理服务都应该有明确的 GPU 预算。哪怕是内部实验也要记录任务名称、使用卡数、运行时长和显存峰值。这些数据积累起来后你可以清楚地知道哪些任务在浪费资源哪些任务值得继续优化。推荐在团队里建立一个简单的算力登记表格或自动化看板。9.2 优先优化数据而不是盲目调参在算力有限的情况下调参的时间成本和算力成本都很高。更高效的方式是先检查数据质量重复样本是否很多标注是否一致负样本是否充足数据问题往往比模型结构问题更容易暴露修正数据的投入产出比通常高于盲目做超参搜索。9.3 共享模型缓存与预加载团队内多个人使用同一个开源模型时不要在每台机器上重复下载。把模型文件放到一个共享存储目录并设置HF_HOME指向该目录可以节省大量带宽和磁盘空间。服务部署前也建议做模型预加载避免上线后第一个请求因为加载模型而超时。9.4 设计降级方案生产环境的推理服务需要有一份“降级路书”当 GPU 资源紧张时是切换更小模型、减少最大输出长度还是把部分流量切到 API 服务当 GPU 实例故障时有没有备用方案提前设计好这些策略比 CPU 被打满时再临时救火要可靠得多。9.5 重视安全与合规边界在算力资源上跑什么数据、用什么模型需要符合公司制度和相关法规。模型下载、部署、API 调用都要关注数据出境、敏感信息保护、最小权限等问题。在自己负责的职责范围内工作涉及生产环境变更时先做备份和回滚方案这些底线在任何时期都不能放松。9.6 用成本可视化驱动决策当算力紧张时管理者最想知道的不是“你在做什么”而是“做完要花多少钱”。所以建议定期统计每个业务的 Token 消耗量、GPU 小时数、每万次请求的推理成本。这些数据一方面能帮你优化资源分配另一方面也能在申请预算时提供更有说服力的依据。10. 总结与后续学习方向这篇文章把“英伟达AI 算力供给短缺至少延续至 2028 财年末”这个信息拆解到了开发者能理解、能行动的层面。我们梳理了晶圆、HBM、电力三大约束如何影响算力供应链解释了算力、Token、数据、模型、场景这几个核心概念也给出了在算力受限环境下做技术选型的基本逻辑。最关键的是通过一个可运行的本地 GPU 示例演示了量化推理、缓存服务和显存管理的具体做法。接下来你可以做三件事第一用nvidia-smi检查一下手头机器的 GPU 资源确认驱动和 PyTorch 是否匹配第二选一个开源模型在本地或云上用小显存环境跑通量化推理感受一下模型加载、显存占用和推理延迟的真实数据第三结合自己业务场景设计一个包含缓存和降级策略的推理服务把文章里的思路落到代码里。算力短缺是宏观趋势但技术人的竞争力从不会只取决于硬件数量。在同样有限的资源下谁能更快跑通实验、更稳地部署服务、更省地把模型用起来谁就更有主动权。与其焦虑新卡什么时候到货不如先把手里已有的算力用到极致。 
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
