英伟达预计2028财年营收同比增70%黄仁勋却说实际需求远高于这个数字。看到这条新闻很多人第一反应是股价要涨但如果你正在做AI应用开发我觉得更值得留意的是一个藏在数字背后的信号AI算力仍然处在供应紧张的阶段而整个产业链真正短缺的不只是芯片本身而是从芯片到集群、从软件到运维一整套基础设施。单次跑通一个模型的时代正在过去接下来是算力资源管理能力决定项目上限的时代。这个判断听起来有点大但它会落到非常具体的日常决策里。比如新模型发布后要不要立刻切换云GPU配额不够时怎么办为什么同一个模型上线后越来越慢这些问题看起来是技术问题背后绕不开同一个变量算力供给。这里不打算把它当成股票新闻而是想从英伟达这条营收预测出发拆开算力需求的结构再落到技术人现在可以做的几件事。1. 一个预测数字为什么值得技术人认真拆解1.1 先分清“财年增长”和“自然年增长”媒体标题里的2028财年采用的是英伟达自己的财年口径和自然年不完全重合。很多讨论会把“2028财年”直接理解成2028自然年其实会有偏差。对技术人来说不需要把会计日历搞得太细但要意识到一点这个数字不是某个季度的短期业绩预告而是面向未来两三年的一条增长曲线。真正值得关注的是它的基数。当一家公司的营收已经处在很高的体量再预计同比增长70%意味着绝对增量非常可观。这背后隐含的是大量数据中心、云厂商和AI公司正在持续扩建算力。如果这个预期最终兑现未来两三年内GPU资源仍然会是核心基础设施而不是一个可以随意扩容的普通组件。1.2 70%不是一个“愿望”而是一个“产能计划”如果把营收预期理解成“英伟达觉得市场好”就低估了它的信息量。生产一张高端GPU需要先进制程产能、CoWoS封装、HBM显存、高速互联、散热和供电。这些环节都有各自的产能上限不是想扩就能立刻扩。所以公司给出的营收预期通常更像是一个在产能约束下排下来的交付计划。换句话说70%的增长可能只是它当前能供应出来的上限而不是真实需求的总和。黄仁勋说“实际需求远高于此”放在这个背景下是合理的。因为市场上愿意买GPU的客户可能比能拿到货的客户多得多实际需求被产能和订单周期限制了。这一点对普通开发者的影响是直接且长期的在供应受限的周期里热门GPU不会突然变得便宜云厂商的算力配额也会一直处于紧张状态。你可能不是直接采购芯片的人但最终会通过云账单、排队等待和实例缺货感受到这个约束。1.3 “实际需求远高于此”到底在说什么黄仁勋这句话表面上是说给资本市场听的但更实际的作用是告诉供应链和下游客户算力供给的紧张不是短期现象而是一个结构性阶段。这句话会让云厂商更积极地锁定产能也会让应用开发团队重新评估自己对GPU的依赖程度。如果你正在做一个AI产品我的建议是不要因为这条预测就把所有希望寄托在未来算力会变便宜上。相反更应该假设未来两三年内GPU仍是稀缺资源。在这个假设下做架构你会更看重单位算力产出而不是单纯堆模型规模。从工程经验看很多团队一开始在云上申请GPU很顺利到了业务增长期才开始被配额限制卡住。那时候再改架构成本远高于初期就做规划。所以这条预测离技术人并不远。2. 算力需求不是单指显卡而是三层系统2.1 第一层GPU芯片与显存大多数开发者接触算力是从一张GPU开始的。看型号、看显存、看峰值算力、看功耗然后决定能不能跑某个模型。显存大小决定了模型能不能完整放进去计算速度和显存带宽决定了每一步推理要等多久。但如果生产环境只有一张卡很多高并发业务根本撑不住。真实项目里只要模型超过一定规模或者用户请求并发升高计算就会自然落到多卡、多机集群上。这时候问题已经不再是单张卡性能够不够而是整条链路是否通畅。2.2 第二层集群、网络、散热与供电在集群层面影响最大的往往是网络和存储。多张卡之间的数据交换、参数同步、样本读取任何时候慢一步都会让GPU空转。很多团队买了四张卡一跑训练发现利用率只有50%问题不在GPU而在数据加载或网络带宽。数据中心还涉及散热和供电。高功率GPU一旦集中部署机柜功率、空调制冷、电力容量都会成为硬约束。这也是为什么即使芯片本身出货增加整个数据中心的建设周期仍然很长。对于使用云服务的团队这些约束会通过配额形式呈现出来比如某类实例有最大数量限制某些可用区缺货或者需要提前申请。看得见的GPU其实是冰山一角看不见的集群基础设施才是真正的稀缺层。2.3 第三层软件栈、模型生态与运维能力同一块GPU在不同软件配置下的产出可能差出好几倍。CUDA、cuDNN、TensorRT这些基础库以及PyTorch、vLLM、Sglang这类框架决定了显存怎么分配、算子怎么编排、请求怎么批处理。不会用推理优化的人用大卡跑小模型也可能跑不过一个量化加批处理的小卡集群。我经常看到两类团队一类比较懂底层能把一张卡的高性能压榨出来另一类只会在默认配置下启动模型一旦并发上来就加卡。在大规模算力面前软件优化不是锦上添花而是成本控制的核心手段。软件生态的价值会越来越像操作系统你可能不用每天都碰驱动但框架是否跟上新架构、推理运行时是否能自动算子融合会直接影响你的可用算力。这也是我在后文会反复强调的一点不要只盯硬件也要盯软件栈。2.4 为什么单看芯片会误判整个行业的节奏如果只看新闻里的新一代GPU会以为行业节奏就是“新卡一出老卡淘汰”。实际情况是算力市场是分层并存的。不同客户对性能、价格、功耗、生态成熟度要求不一样新卡负责最吃性能的预训练和高端推理上一代卡会继续服务成本敏感型业务。英伟达的营收增长对应的是整个数据中心基础设施的扩张。芯片是其中价值最高的一层但不是唯一一层。当一家云厂商扩建一个算力中心它采购的不只是GPU还有网络设备、存储、冷却和电力。这些环节都会消耗时间和资源也会制约可交付的算力总量。所以看到“预计增长70%”时不需要简单理解为“新一代显卡卖爆”。更接近事实的理解是整个AI基础设施进入了一个持续扩建期而扩建速度会受到多层因素的限制。对技术人来说这意味着算力仍然需要被当作一种需要规划的资源而不是像内存一样随时可加。3. 算力紧缺时技术人的选型逻辑必须换一套3.1 从“追新模型”转向“算力预算优先”过去两年AI圈有一个明显氛围新模型一发布大家就想立刻试用看看是不是更强。这个习惯在个人实验中没问题但在生产业务里必须多算一笔账。换模型意味着重新评测效果、重新压测性能、调整推理参数还可能带来显存和延迟变化。当算力紧缺且成本高企时更合理的方式是给项目设一个算力预算上限。在这个预算内选择能解决业务问题的最小模型。排行榜上的推理能力再强如果上线后单次调用成本超出产品承受力依然不是合适的方案。我建议用“单位算力产出”作为判断标准而不是只看“模型A是否强于模型B”。比如一个500亿参数模型在目标任务上只比70亿参数模型高出2个百分点但推理成本是后者的8倍那么在产品场景里70亿模型很可能是更理性的选择。3.2 训练、微调、推理三类负载的资源逻辑完全不同算力紧缺时最容易犯的错是让所有负载共享同一套资源策略。实际上训练、微调和推理的资源需求差异很大。训练任务通常是离线、长时间、整批占用的。它适合提前规划用包月或预留集群来跑追求持续稳定。微调任务介于两者之间时长可能从几小时到几天可以接受排队但需要知道完成时间。推理任务则是在线服务对延迟和吞吐有硬性要求需要预留资源并且在流量闲时释放。如果不去区分就会出现一种典型情况把推理服务部署在按小时计费的训练集群上结果闲时浪费钱高峰期又无法弹性扩容。或者把离线批处理请求混在在线推理里导致线上延迟抖动。把负载分类是资源管理的第一步。3.3 云服务、私有集群、混合部署不要只看单价选云还是自建不是简单地比较每卡时单价。云服务灵活可以按需弹性但长期高负载时累计成本会超过包年或自建。自建集群有很高的前期投入和运维复杂度需要机房、网络、电力和专业工程师如果没有稳定的长期业务贸然自建风险很大。更常见也更容易落地的是混合架构。线上推理用云上的预留实例保证稳定离线大批量任务用竞价实例或包年资源模型微调放在非高峰时段用同一批资源做潮汐调度。这样既控制成本也保留弹性。一个很实际的建议是先跑一个压力测试用真实的请求量去估算资源需求再拿着这个需求去对比不同采购方式。不要因为某家云的页面报价便宜就直接迁移页面报价和实际账单之间往往隔着流量费、存储费、备份费和各种附加项。3.4 一个可复用的算力决策框架负载-时延-成本如果上面的分析还不够具体可以试试一个简单框架。做任何算力选型之前先回答三个问题它是什么负载它允许的最坏时延是多少它一个月最高的算力成本预算是多少把这三个问题写在页面上再决定用哪类GPU、用多少卡、用云还是自建。这样做的好处是它把“选型”从拍脑袋变成了需求驱动。场景典型负载时延要求推荐资源策略通用实时聊天助手在线推理P95 1秒中小模型 推理优化框架 预留GPU离线内容审核批量推理分钟级量化模型 批处理 竞价实例或包时业务模型微调微调/增量训练小时级中规模GPU集群避开高峰时段大规模预训练长期训练天级大规模集群包年或预留关注网络这个表是通用建议不是标准答案。它想表达的核心判断是先定义负载类型和时延预算再去选资源顺序不能反。4. 从预测到落地四件事现在就可以做4.1 建立自己的性能基线和成本基线很多团队在项目上线前不知道怎么规划资源因为缺少基线数据。建议从第一次压测开始就把关键指标记录成表格。字段不用多但要有代表性。指标含义示例值平均输入长度单次请求输入Token数1200 tokens平均输出长度单次请求输出Token数300 tokensP95延迟95%请求在多少毫秒内完成780 msGPU利用率压测期间平均利用率62%显存峰值单个GPU最大显存占用18.6 GB单千Token成本每处理1000 Token的推理成本0.015 元表格里的数字只是示例你需要根据自己的环境填。有了基线后续做模型切换、推理优化或资源扩容时才能判断变化到底是变好还是变坏。没有基线任何一个“感觉更快了”都不可靠。建议先建立性能基线再做资源扩容。没有基线任何“感觉更快了”都缺乏依据。4.2 做一次负载的“需求拆解”而不是继续堆机器当服务变慢或成本升高第一反应往往是加卡。但更稳妥的做法是先做一次负载拆解。通过日志或APM工具把请求按业务类型、模型大小、输入规模、调用时段分类你会看到很多此前忽略的现象。比如可能有一类固定请求只是做关键词抽取却一直走大模型接口也可能有很多超长文档解析请求它们消耗的显存和算力远高于普通请求但出现频率不高却把显存峰值拉得很高。通过简单路由把这些请求接入小模型或专用流程往往能释放大量算力。这比升级硬件更快也更符合成本控制原则。我的建议是不要急着扩容先花半天时间把线上请求分类统计一遍。注意不要把所有请求都送到大模型。先根据业务场景做分流这是成本最高的杠杆。4.3 设计降级方案避免上游波动打穿服务GPU资源再充足也可能因为配额、故障、局部拥堵而变得不可用。线上服务应该把GPU视为一种外部依赖而不是本地资源。它随时可能被限流、排队或短时不可用。降级方案可以很轻当GPU推理超时先走缓存结果没有缓存时退回小模型或规则引擎仍然不行就把请求列入队列等到算力空闲时再处理。这样用户最多感觉慢一点而不是服务直接报错。另外要监控请求队列的长度和延迟。很多时候服务“挂掉”不是因为GPU坏了而是因为排队请求堆积把整个服务拖死。设置合理的超时和排队上限往往比增加GPU更有效。4.4 用异常排查顺序管理“越来越慢”的问题很多AI服务的性能问题会被归因成“算力不够”最后靠加卡解决。但真正的原因可能只是一个超时配置或一个数据加载问题。从工程经验看可以先按这个顺序排查基础设施层GPU利用率、显存、温度、网络吞吐、存储I/O是否异常。调度层请求并发、排队长度、批处理策略、超时设置。输入层请求的输入长度是否突然变大数据格式是否变化有没有异常调用。推理层模型的单次推理耗时、是否触发了动态shape编译、框架版本和算子实现。外部依赖embedding服务、向量库、数据库、模型下载等是否存在瓶颈。这个顺序的核心思路是先把“资源层”和“应用层”分开。大部分问题在调度和输入层真正需要加卡的场景只占一部分。5. 这轮增长真正改变的是什么5.1 从“能不能跑”到“能不能长期稳定地跑”前几年AI应用的验证逻辑是模型能跑通Demo就说明项目可行。但在算力价值不断走高的未来这个标准明显不够。能不能在业务高峰保持稳定延迟能不能把成本控制在可接受范围能不能在算力配额紧张时依然提供基本服务这些才是真正的分水岭。英伟达那条营收预测其实反映出整个行业仍在拼命扩建基础设施。基建会增长但需求也在增长。对应用开发者来说与其等待算力便宜不如提前把系统的稳定性、可观测性和降级能力做扎实。5.2 软件生态的价值会被重新定价算力紧缺时谁能在单位GPU上跑出更多有效请求谁就拥有更强的竞争力。这意味着推理优化、模型量化、批处理调度、算子融合、自动调优这些能力会越来越值钱。以前它们是性能优化可选内容未来可能是控制成本的必要手段。同时模型框架和部署平台的更新节奏非常重要。建议技术负责人定期关注自己依赖的推理框架是否适配最新GPU驱动是否支持新模型的量化方案。很多时候一次框架升级带来的性能提升比增加一张卡更可观。5.3 对普通开发者更早理解抽象层比学会某个框架更重要对于不直接从事底层优化的开发者这轮变化真正的影响是要求更早建立抽象思维。算力、模型、应用之间会形成类似硬件、操作系统、应用软件的层次关系。你不需要掌握每一层的所有细节但需要知道每一层都有成本、有边界、有瓶颈。当你理解了这层关系就明白为什么不能把大模型当作免费API来调用为什么要在业务架构里预留限流、降级和队列为什么要长期维护一套性能基线。这些能力不会因为某一次“新模型发布”而过时它们是应对算力不确定性的通用能力。从这个角度看英伟达的70%增长预测不是距离技术人很远的华尔街故事而是提醒我们重新审视自己的工作流是不是把所有关键环节都押在了一个随时可能变贵的资源上如果是那么现在就是开始做缓冲的最好时机。回到开头的问题一条英伟达营收预测和技术人到底有什么关系关系不在于股票涨跌而在于它让我们看到算力供需的真实状态。接下来两三年GPU大概率仍然是稀缺资源AI应用的成本结构也会长期受其影响。与其被这种外部变量牵着走不如现在就把算力当作一种需要预算、监控和优化的工程资源。如果只记一句话我会建议你从今天开始给自己正在跑的AI服务建立一张基线和成本表。不需要很复杂先记录输入长度、延迟、GPU利用率和单次成本。很多项目的问题都藏在这些数字里。 
长河君 · 2026/8/30 8:28:15 · 阅读 1.2k 英伟达预期营收增长70%，AI算力基础设施与技术选型启示
英伟达预计2028财年营收同比增70%黄仁勋却说实际需求远高于这个数字。看到这条新闻很多人第一反应是股价要涨但如果你正在做AI应用开发我觉得更值得留意的是一个藏在数字背后的信号AI算力仍然处在供应紧张的阶段而整个产业链真正短缺的不只是芯片本身而是从芯片到集群、从软件到运维一整套基础设施。单次跑通一个模型的时代正在过去接下来是算力资源管理能力决定项目上限的时代。这个判断听起来有点大但它会落到非常具体的日常决策里。比如新模型发布后要不要立刻切换云GPU配额不够时怎么办为什么同一个模型上线后越来越慢这些问题看起来是技术问题背后绕不开同一个变量算力供给。这里不打算把它当成股票新闻而是想从英伟达这条营收预测出发拆开算力需求的结构再落到技术人现在可以做的几件事。1. 一个预测数字为什么值得技术人认真拆解1.1 先分清“财年增长”和“自然年增长”媒体标题里的2028财年采用的是英伟达自己的财年口径和自然年不完全重合。很多讨论会把“2028财年”直接理解成2028自然年其实会有偏差。对技术人来说不需要把会计日历搞得太细但要意识到一点这个数字不是某个季度的短期业绩预告而是面向未来两三年的一条增长曲线。真正值得关注的是它的基数。当一家公司的营收已经处在很高的体量再预计同比增长70%意味着绝对增量非常可观。这背后隐含的是大量数据中心、云厂商和AI公司正在持续扩建算力。如果这个预期最终兑现未来两三年内GPU资源仍然会是核心基础设施而不是一个可以随意扩容的普通组件。1.2 70%不是一个“愿望”而是一个“产能计划”如果把营收预期理解成“英伟达觉得市场好”就低估了它的信息量。生产一张高端GPU需要先进制程产能、CoWoS封装、HBM显存、高速互联、散热和供电。这些环节都有各自的产能上限不是想扩就能立刻扩。所以公司给出的营收预期通常更像是一个在产能约束下排下来的交付计划。换句话说70%的增长可能只是它当前能供应出来的上限而不是真实需求的总和。黄仁勋说“实际需求远高于此”放在这个背景下是合理的。因为市场上愿意买GPU的客户可能比能拿到货的客户多得多实际需求被产能和订单周期限制了。这一点对普通开发者的影响是直接且长期的在供应受限的周期里热门GPU不会突然变得便宜云厂商的算力配额也会一直处于紧张状态。你可能不是直接采购芯片的人但最终会通过云账单、排队等待和实例缺货感受到这个约束。1.3 “实际需求远高于此”到底在说什么黄仁勋这句话表面上是说给资本市场听的但更实际的作用是告诉供应链和下游客户算力供给的紧张不是短期现象而是一个结构性阶段。这句话会让云厂商更积极地锁定产能也会让应用开发团队重新评估自己对GPU的依赖程度。如果你正在做一个AI产品我的建议是不要因为这条预测就把所有希望寄托在未来算力会变便宜上。相反更应该假设未来两三年内GPU仍是稀缺资源。在这个假设下做架构你会更看重单位算力产出而不是单纯堆模型规模。从工程经验看很多团队一开始在云上申请GPU很顺利到了业务增长期才开始被配额限制卡住。那时候再改架构成本远高于初期就做规划。所以这条预测离技术人并不远。2. 算力需求不是单指显卡而是三层系统2.1 第一层GPU芯片与显存大多数开发者接触算力是从一张GPU开始的。看型号、看显存、看峰值算力、看功耗然后决定能不能跑某个模型。显存大小决定了模型能不能完整放进去计算速度和显存带宽决定了每一步推理要等多久。但如果生产环境只有一张卡很多高并发业务根本撑不住。真实项目里只要模型超过一定规模或者用户请求并发升高计算就会自然落到多卡、多机集群上。这时候问题已经不再是单张卡性能够不够而是整条链路是否通畅。2.2 第二层集群、网络、散热与供电在集群层面影响最大的往往是网络和存储。多张卡之间的数据交换、参数同步、样本读取任何时候慢一步都会让GPU空转。很多团队买了四张卡一跑训练发现利用率只有50%问题不在GPU而在数据加载或网络带宽。数据中心还涉及散热和供电。高功率GPU一旦集中部署机柜功率、空调制冷、电力容量都会成为硬约束。这也是为什么即使芯片本身出货增加整个数据中心的建设周期仍然很长。对于使用云服务的团队这些约束会通过配额形式呈现出来比如某类实例有最大数量限制某些可用区缺货或者需要提前申请。看得见的GPU其实是冰山一角看不见的集群基础设施才是真正的稀缺层。2.3 第三层软件栈、模型生态与运维能力同一块GPU在不同软件配置下的产出可能差出好几倍。CUDA、cuDNN、TensorRT这些基础库以及PyTorch、vLLM、Sglang这类框架决定了显存怎么分配、算子怎么编排、请求怎么批处理。不会用推理优化的人用大卡跑小模型也可能跑不过一个量化加批处理的小卡集群。我经常看到两类团队一类比较懂底层能把一张卡的高性能压榨出来另一类只会在默认配置下启动模型一旦并发上来就加卡。在大规模算力面前软件优化不是锦上添花而是成本控制的核心手段。软件生态的价值会越来越像操作系统你可能不用每天都碰驱动但框架是否跟上新架构、推理运行时是否能自动算子融合会直接影响你的可用算力。这也是我在后文会反复强调的一点不要只盯硬件也要盯软件栈。2.4 为什么单看芯片会误判整个行业的节奏如果只看新闻里的新一代GPU会以为行业节奏就是“新卡一出老卡淘汰”。实际情况是算力市场是分层并存的。不同客户对性能、价格、功耗、生态成熟度要求不一样新卡负责最吃性能的预训练和高端推理上一代卡会继续服务成本敏感型业务。英伟达的营收增长对应的是整个数据中心基础设施的扩张。芯片是其中价值最高的一层但不是唯一一层。当一家云厂商扩建一个算力中心它采购的不只是GPU还有网络设备、存储、冷却和电力。这些环节都会消耗时间和资源也会制约可交付的算力总量。所以看到“预计增长70%”时不需要简单理解为“新一代显卡卖爆”。更接近事实的理解是整个AI基础设施进入了一个持续扩建期而扩建速度会受到多层因素的限制。对技术人来说这意味着算力仍然需要被当作一种需要规划的资源而不是像内存一样随时可加。3. 算力紧缺时技术人的选型逻辑必须换一套3.1 从“追新模型”转向“算力预算优先”过去两年AI圈有一个明显氛围新模型一发布大家就想立刻试用看看是不是更强。这个习惯在个人实验中没问题但在生产业务里必须多算一笔账。换模型意味着重新评测效果、重新压测性能、调整推理参数还可能带来显存和延迟变化。当算力紧缺且成本高企时更合理的方式是给项目设一个算力预算上限。在这个预算内选择能解决业务问题的最小模型。排行榜上的推理能力再强如果上线后单次调用成本超出产品承受力依然不是合适的方案。我建议用“单位算力产出”作为判断标准而不是只看“模型A是否强于模型B”。比如一个500亿参数模型在目标任务上只比70亿参数模型高出2个百分点但推理成本是后者的8倍那么在产品场景里70亿模型很可能是更理性的选择。3.2 训练、微调、推理三类负载的资源逻辑完全不同算力紧缺时最容易犯的错是让所有负载共享同一套资源策略。实际上训练、微调和推理的资源需求差异很大。训练任务通常是离线、长时间、整批占用的。它适合提前规划用包月或预留集群来跑追求持续稳定。微调任务介于两者之间时长可能从几小时到几天可以接受排队但需要知道完成时间。推理任务则是在线服务对延迟和吞吐有硬性要求需要预留资源并且在流量闲时释放。如果不去区分就会出现一种典型情况把推理服务部署在按小时计费的训练集群上结果闲时浪费钱高峰期又无法弹性扩容。或者把离线批处理请求混在在线推理里导致线上延迟抖动。把负载分类是资源管理的第一步。3.3 云服务、私有集群、混合部署不要只看单价选云还是自建不是简单地比较每卡时单价。云服务灵活可以按需弹性但长期高负载时累计成本会超过包年或自建。自建集群有很高的前期投入和运维复杂度需要机房、网络、电力和专业工程师如果没有稳定的长期业务贸然自建风险很大。更常见也更容易落地的是混合架构。线上推理用云上的预留实例保证稳定离线大批量任务用竞价实例或包年资源模型微调放在非高峰时段用同一批资源做潮汐调度。这样既控制成本也保留弹性。一个很实际的建议是先跑一个压力测试用真实的请求量去估算资源需求再拿着这个需求去对比不同采购方式。不要因为某家云的页面报价便宜就直接迁移页面报价和实际账单之间往往隔着流量费、存储费、备份费和各种附加项。3.4 一个可复用的算力决策框架负载-时延-成本如果上面的分析还不够具体可以试试一个简单框架。做任何算力选型之前先回答三个问题它是什么负载它允许的最坏时延是多少它一个月最高的算力成本预算是多少把这三个问题写在页面上再决定用哪类GPU、用多少卡、用云还是自建。这样做的好处是它把“选型”从拍脑袋变成了需求驱动。场景典型负载时延要求推荐资源策略通用实时聊天助手在线推理P95 1秒中小模型 推理优化框架 预留GPU离线内容审核批量推理分钟级量化模型 批处理 竞价实例或包时业务模型微调微调/增量训练小时级中规模GPU集群避开高峰时段大规模预训练长期训练天级大规模集群包年或预留关注网络这个表是通用建议不是标准答案。它想表达的核心判断是先定义负载类型和时延预算再去选资源顺序不能反。4. 从预测到落地四件事现在就可以做4.1 建立自己的性能基线和成本基线很多团队在项目上线前不知道怎么规划资源因为缺少基线数据。建议从第一次压测开始就把关键指标记录成表格。字段不用多但要有代表性。指标含义示例值平均输入长度单次请求输入Token数1200 tokens平均输出长度单次请求输出Token数300 tokensP95延迟95%请求在多少毫秒内完成780 msGPU利用率压测期间平均利用率62%显存峰值单个GPU最大显存占用18.6 GB单千Token成本每处理1000 Token的推理成本0.015 元表格里的数字只是示例你需要根据自己的环境填。有了基线后续做模型切换、推理优化或资源扩容时才能判断变化到底是变好还是变坏。没有基线任何一个“感觉更快了”都不可靠。建议先建立性能基线再做资源扩容。没有基线任何“感觉更快了”都缺乏依据。4.2 做一次负载的“需求拆解”而不是继续堆机器当服务变慢或成本升高第一反应往往是加卡。但更稳妥的做法是先做一次负载拆解。通过日志或APM工具把请求按业务类型、模型大小、输入规模、调用时段分类你会看到很多此前忽略的现象。比如可能有一类固定请求只是做关键词抽取却一直走大模型接口也可能有很多超长文档解析请求它们消耗的显存和算力远高于普通请求但出现频率不高却把显存峰值拉得很高。通过简单路由把这些请求接入小模型或专用流程往往能释放大量算力。这比升级硬件更快也更符合成本控制原则。我的建议是不要急着扩容先花半天时间把线上请求分类统计一遍。注意不要把所有请求都送到大模型。先根据业务场景做分流这是成本最高的杠杆。4.3 设计降级方案避免上游波动打穿服务GPU资源再充足也可能因为配额、故障、局部拥堵而变得不可用。线上服务应该把GPU视为一种外部依赖而不是本地资源。它随时可能被限流、排队或短时不可用。降级方案可以很轻当GPU推理超时先走缓存结果没有缓存时退回小模型或规则引擎仍然不行就把请求列入队列等到算力空闲时再处理。这样用户最多感觉慢一点而不是服务直接报错。另外要监控请求队列的长度和延迟。很多时候服务“挂掉”不是因为GPU坏了而是因为排队请求堆积把整个服务拖死。设置合理的超时和排队上限往往比增加GPU更有效。4.4 用异常排查顺序管理“越来越慢”的问题很多AI服务的性能问题会被归因成“算力不够”最后靠加卡解决。但真正的原因可能只是一个超时配置或一个数据加载问题。从工程经验看可以先按这个顺序排查基础设施层GPU利用率、显存、温度、网络吞吐、存储I/O是否异常。调度层请求并发、排队长度、批处理策略、超时设置。输入层请求的输入长度是否突然变大数据格式是否变化有没有异常调用。推理层模型的单次推理耗时、是否触发了动态shape编译、框架版本和算子实现。外部依赖embedding服务、向量库、数据库、模型下载等是否存在瓶颈。这个顺序的核心思路是先把“资源层”和“应用层”分开。大部分问题在调度和输入层真正需要加卡的场景只占一部分。5. 这轮增长真正改变的是什么5.1 从“能不能跑”到“能不能长期稳定地跑”前几年AI应用的验证逻辑是模型能跑通Demo就说明项目可行。但在算力价值不断走高的未来这个标准明显不够。能不能在业务高峰保持稳定延迟能不能把成本控制在可接受范围能不能在算力配额紧张时依然提供基本服务这些才是真正的分水岭。英伟达那条营收预测其实反映出整个行业仍在拼命扩建基础设施。基建会增长但需求也在增长。对应用开发者来说与其等待算力便宜不如提前把系统的稳定性、可观测性和降级能力做扎实。5.2 软件生态的价值会被重新定价算力紧缺时谁能在单位GPU上跑出更多有效请求谁就拥有更强的竞争力。这意味着推理优化、模型量化、批处理调度、算子融合、自动调优这些能力会越来越值钱。以前它们是性能优化可选内容未来可能是控制成本的必要手段。同时模型框架和部署平台的更新节奏非常重要。建议技术负责人定期关注自己依赖的推理框架是否适配最新GPU驱动是否支持新模型的量化方案。很多时候一次框架升级带来的性能提升比增加一张卡更可观。5.3 对普通开发者更早理解抽象层比学会某个框架更重要对于不直接从事底层优化的开发者这轮变化真正的影响是要求更早建立抽象思维。算力、模型、应用之间会形成类似硬件、操作系统、应用软件的层次关系。你不需要掌握每一层的所有细节但需要知道每一层都有成本、有边界、有瓶颈。当你理解了这层关系就明白为什么不能把大模型当作免费API来调用为什么要在业务架构里预留限流、降级和队列为什么要长期维护一套性能基线。这些能力不会因为某一次“新模型发布”而过时它们是应对算力不确定性的通用能力。从这个角度看英伟达的70%增长预测不是距离技术人很远的华尔街故事而是提醒我们重新审视自己的工作流是不是把所有关键环节都押在了一个随时可能变贵的资源上如果是那么现在就是开始做缓冲的最好时机。回到开头的问题一条英伟达营收预测和技术人到底有什么关系关系不在于股票涨跌而在于它让我们看到算力供需的真实状态。接下来两三年GPU大概率仍然是稀缺资源AI应用的成本结构也会长期受其影响。与其被这种外部变量牵着走不如现在就把算力当作一种需要预算、监控和优化的工程资源。如果只记一句话我会建议你从今天开始给自己正在跑的AI服务建立一张基线和成本表。不需要很复杂先记录输入长度、延迟、GPU利用率和单次成本。很多项目的问题都藏在这些数字里。