如果把过去十年服务器出货量和同一时期大模型训练算力的增长曲线放在一张图上，会看到两条斜率完全不同的线：一条是缓坡，一条接近垂直。更值得注意的不是"涨了"，而是"涨的加速度在变大"——2020 年之前，算力需求的增长主要跟随互联网用户数和数据量的线性扩张；2020 年之后，驱动力换成了模型参数量、上下文长度、推理链条长度这三个可以互相叠乘的变量。

这篇文章不谈宏大叙事，只从工程角度拆解一件事：算力需求到底是被什么推着走的，每一股力量贡献了多少量级，硬件侧的进步为什么追不上，以及在这种趋势下企业该怎样重新估算自己的算力预算。理解了这套增长逻辑，再去评估一张 GPU 卡、一台 AI 服务器、一个机柜到底能撑多久，判断会稳得多。

一、需求增长的四个独立来源

很多人把"算力需求增长"笼统归因于"模型变大了"，这个说法只对了一部分。实际上至少有四股力量在同时起作用，它们分属训练和推理两个阶段，彼此不重叠，叠加之后才形成今天这种复合增长率。

1. 训练侧：参数与数据同步放大

早期提升模型能力的主要办法是增加参数量，从亿级到百亿级再到千亿级。但当参数增长到一定程度后，业界发现单纯堆参数会遇到数据不足的问题，于是训练数据量（Token 数）也开始同步放大。按照业内普遍引用的经验比例，一个模型比较理想的训练 Token 数大约是参数量的 20 倍左右；而近两年的实践证明，把比例推到 100 倍甚至更高，模型效果还能继续提升。参数和 Token 同时乘以 10，训练算力就乘以 100，这就是"乘法效应"的第一层。

2. 推理侧：用户规模乘以单次请求的计算量

训练是一次性的资本开支，推理是持续性的运营开支。当模型从实验室走向产品，推理请求量会随用户数上升；与此同时，单次请求内部消耗的 Token 数也在上升——更长的系统提示词、更长的上下文、更详细的回答、以及"先思考再回答"的推理模式，都会让一次对话的实际计算量成倍增加。用户数乘以单请求计算量，构成了第二层乘法。

3. 多模态：单位内容的算力密度显著提高

纯文本的一个 Token 大约对应几个字节的信息量，而一张 1024×1024 的图片经过视觉编码器后往往会产生数百到上千个视觉 Token；一段 10 秒的 1080p 视频，按每秒若干帧切分后产生的 Token 数量可以达到数万级。视频生成模型的情况更极端：一次 5 秒视频的扩散采样需要在时间维度上反复迭代，其算力消耗常常是同等参数规模文本模型的几十倍到上百倍。内容形态从文字扩展到图像、语音、视频，单位内容承载的算力密度就上了一个台阶。

4. 后训练与强化学习：从"训一次"到"采样很多次"

为了让模型更符合人类偏好、更擅长推理和工具调用，后训练阶段的比重明显上升。监督微调相对便宜，但基于人类反馈的强化学习、以及可验证奖励的强化学习，需要在训练过程中反复生成大量样本再打分回传，采样成本可能是监督微调的数十倍。一个 70B 级别的模型做一轮完整的强化学习后训练，消耗的算力有时能接近甚至超过预训练本身的一部分。这部分开销在早期的算力预算里几乎不被考虑，现在已经成为不可忽略的一项。对交付周期敏感的项目，可以提前和天下数据确认机房的现货与排产情况。比单看参数更接近真实的落地成本。

二、用公式把增长量级算清楚

工程上估算训练算力有一个被广泛使用的近似公式：训练总浮点运算量 ≈ 6 × 参数量 × 训练 Token 数。系数 6 的来源是前向传播约 2 次乘加、反向传播约 4 次乘加（对参数和对激活值各一次）。这个公式忽略了注意力机制中与序列长度平方相关的开销，因此对长上下文训练会低估，但用来做量级判断已经足够。

把公式套进不同规模的模型，就能直观看到算力需求的跨度有多大。下表按公开资料常见的配置给出参考值，实际项目中会因序列长度、批次策略、并行方式和框架效率产生较大偏差，仅用于量级对比。

表中"单卡等效卡时"是按单卡有效算力约 4×10¹⁵ FLOP/s（对应 FP8 峰值算力的 40% 左右利用率）折算出来的。可以看到，从 7B 到 400B，算力需求跨了将近三个数量级；而如果再把"同规模模型训练多轮、多版本、多组超参"的实际情况算进去，真实消耗还要再乘 3 到 10 倍。这就是为什么一个看起来"只是把模型放大十倍"的决定，会让整个机房规划推倒重来。

三、推理为什么开始吃掉大部分算力

在 2023 年之前，业界的算力预算里训练占绝对多数。现在情况反过来了：对很多已经上线的产品而言，推理消耗的算力总量已经超过训练。原因不是推理单价贵，而是推理是 7×24 小时持续发生的。

1. 长上下文把显存带宽变成主要成本

自回归推理每生成一个 Token，都要把历史上下文的键值缓存（KV Cache）读一遍。上下文从 4K 扩展到 128K，KV Cache 的容量增加 32 倍，每一步解码需要搬运的数据量也同步增加。此时推理的瓶颈往往不在算力，而在显存带宽：一张卡的理论算力可能只发挥了两三成，剩下的时间都在等数据。为了让长上下文可用，业界采取分组查询注意力、分页式 KV 管理、KV 量化、前缀缓存复用等手段，本质上都是在减少"每一步要搬多少数据"。

2. 推理链让输出 Token 数成倍膨胀

具备"先思考后回答"能力的模型，会在给出最终答案前生成大量中间推理步骤。一个原本只需要输出 200 个 Token 的问题，加上推理过程后可能输出 2000 个 Token。输出侧的计算量与输出长度成正比，于是同样的用户请求量，算力消耗上升一个数量级。这类模型在数学、代码、复杂规划任务上收益明显，但成本模型必须重新计算。

3. Agent 架构把一次调用变成几十次调用

当模型被放进智能体框架，一次用户任务会被拆解成规划、检索、工具调用、结果校验、重试等多个步骤，每一步都是一次完整的模型调用，且上下文会不断累积。一个原本一次调用即可完成的任务，在 Agent 架构下可能产生 20 到 50 次调用，累计 Token 量放大十几倍。这解释了为什么"模型单价下降"和"企业推理账单上升"可以同时发生。

四、硬件进步为什么追不上需求

从公开数据看，单颗 AI 加速卡的浮点性能大约每两年提升一倍多一点，而模型训练算力的需求在 2020 至 2025 年间大约每 6 到 10 个月翻一倍。两条曲线之间的差距，就是持续存在的算力缺口。硬件侧至少有三个难以突破的约束。

1. 制程与封装的天花板

先进制程从 5nm 到 3nm，晶体管密度提升幅度远小于从前，漏电流和功耗密度问题却更严重。单芯片面积受光刻掩模尺寸限制，想继续提升性能只能往先进封装走——把计算 die 和多个高带宽内存堆栈放在同一块中介层上。封装产能、良率和成本成为新的瓶颈，这也是高端 GPU 长期供不应求的结构性原因。

2. 功耗与供电的硬约束

单卡功耗从 300W 级走到 700W 级，再到 1000W 以上，一个 8 卡整机的功耗可以达到 10kW 量级，一个 30 台机器的机柜就要 300kW。传统机柜配电是 6 至 12kW，差距在二三十倍。这意味着扩容不只是买卡，还要改配电、上液冷、加变电站容量。供电能力往往比芯片供应更早成为天花板。

3. 集群规模扩大带来的效率衰减

卡数越多，通信开销占比越高。千卡集群做一次全局梯度同步，通信量可以达到数百 GB，如果网络带宽不足或拓扑设计不合理，GPU 会有大量时间空转。业内常用"线性度"衡量扩展效率：8 卡时可能达到峰值的 85%，扩展到 512 卡可能只剩 60%，再到数千卡可能降到 40% 以下。也就是说，算力需求涨 100 倍，实际需要买的卡可能不止 100 倍，而是 150 到 200 倍。

五、这种增长对企业的实际影响

1. 成本结构从"设备采购"转向"持续运营"

传统 IT 采购是一次性买服务器、五年折旧。AI 算力则是"买卡 + 电费 + 机房改造 + 运维 + 模型迭代"的复合成本，其中电费在三年周期内可能接近甚至超过设备本身。在做预算时，把电费按 0.6 至 0.9 元/度、单卡平均功耗按额定值的 70%、年运行 8000 小时来估算，会得到比较接近现实的数字。

2. 采购策略从"一步到位"转向"分层配置"

面对快速迭代的硬件，一次性买满并不划算。更稳妥的做法是把算力分成三层：常驻层用自建或长租满足稳定负载，弹性层用按小时租赁应对峰值，试验层用少量最新卡做验证。这样既避免为峰值过度投资，也不至于在架构换代时被大量旧设备套牢。

3. 评估指标从"峰值算力"转向"有效算力"

同样标称 10 PFLOPS 的两套系统，在实际训练任务上的吞吐可能相差一倍以上，差异来自显存带宽、互联拓扑、存储吞吐、框架适配和调度策略。选型时更应关注"在目标模型上的实测吞吐"，而不是宣传页上的峰值数字。建议用自己的代表性模型跑一轮 1 到 2 小时的基准测试，记录每秒处理的 Token 数、GPU 利用率曲线和通信占比，这比任何参数表都可靠。

回到 AI 算力这件事，这类负载最终要落到具体的整机与机房里——天下数据可同时提供 GPU 整机租用与整机托管，GPU 节点与普通节点同机房交付；售前会给出机型对比清单与算力测算，交付前支持整机压测验收。对跨境业务有需求的团队，值得纳入首轮询价名单。

总结

AI 算力需求的持续增长，不是单一因素推动的结果，而是"参数 × 数据 × 上下文 × 推理链 × 调用次数"多个乘数共同作用的结果。训练侧的一次性投入在放大，推理侧的持续性开销增长更快，多模态把单位内容的信息密度推高，后训练与强化学习又增加了额外轮次。硬件虽然在进步，但受制于制程、封装、功耗和集群效率，单卡性能的提升速度始终落后于需求增速。

对企业的实践意义有三点：第一，估算算力时要用"乘数思维"，把训练轮次、推理并发、上下文长度、Agent 调用次数都算进去，避免按单次训练做预算导致严重低估；第二，评估硬件时看有效吞吐而非峰值参数，用真实模型实测；第三，采购上采用自建、长租、弹性租赁分层组合的方式，把不确定性留给弹性层。把这三点做到，算力投入的性价比会有明显改善。

需要针对自身模型规模与业务并发做算力测算，或了解 GPU 服务器与集群的具体配置方案，可通过天下数据（idcbest.com）官网获取方案与报价，结合实测数据再做决策。

本文链接：https://www.idcbest.com/cloundnews/11018852.html