英伟达预计 2028 财年销售额达 6730 亿美元，这是近期硬件和 AI 基础设施圈子里被频繁讨论的一条行业预测。很多开发者看到这类数字时，第一反应是股价或市场热度，但作为做技术架构、模型训练平台或数据中心资源规划的人，更应该把它换算成另一个问题：如果这个预测成真，说明全球 AI 算力需求会继续快速增长，那么企业自己的 GPU 集群到底应该按什么逻辑规划，才算既满足业务要求，又不会在利用率、成本和扩容节奏上失控。
这篇文章从工程视角来解读这条预测。不会去分析财务模型，也不做投资参考，而是把“英伟达 2028 财年销售额”当作一个行业需求信号，解释算力需求估算、GPU 集群选型、TCO 评估、容量监控和常见排错路径。适合正在建设 AI 训练平台、做高性能计算资源规划、或者第一次采购 GPU 集群的开发和运维工程师。看完之后，你可以用同样的方法，从自己的训练任务规模推算出大概需要多少卡，并知道上线后该盯哪些指标。
1. 英伟达的 2028 财年预测，工程师应该关注什么
1.1 这是一条需求信号，不是简单的财报数字
先还原这条信息的本质。英伟达预计 2028 财年销售额达到 6730 亿美元，这属于公司面向中长期市场空间的指引或预测，并不代表这一财年已经实现该收入，也不意味着所有销售都来自 GPU。预测是否能兑现，取决于模型训练和推理需求、全球数据中心的部署速度、芯片产能、上游供应链以及下游客户资本开支节奏等多种因素。
从技术决策者的角度看，这条预测更大的价值在于需求方向。如果未来几年 AI 算力市场继续保持扩张，企业面临的不是“要不要用 GPU”的问题，而是“用多少、用什么型号、怎么分摊成本、怎么保证利用率”。预测数字会变化，但算力规划的方法不会变。
工程上要避免两种极端反应。一种是完全不看行业信号，等业务提需求时才临时采购，导致集群交付周期过长；另一种是看到 6730 亿美元这类大数字，直接按最大规模扩容，结果大量 GPU 闲置，成本失控。正确的做法是把行业预测当作背景，用自己的任务负载做估算。
1.2 从销售额预测反推算力规模的方法
虽然我们无法拿到英伟达内部的产品组合和定价，但可以从公开逻辑构建一个量级估算模型。这个过程本身对做资源规划有参考价值。
假设计算：
- 英伟达数据中心业务在总营收中的占比，按近年公开趋势可能在 70% 到 80% 区间；
- 单张 GPU 的平均售价，这里只做量级演示，不代入真实价格；
- 销售额中除了 GPU，还包括网络设备、软件、服务等。
那么年出货量的粗略公式为：
年 GPU 出货量 ≈ 年销售额 × 数据中心占比 ÷ 单卡均价如果假设数据中心占比为 80%，单卡均价为 3 万美元，则：
6730 亿美元 × 80% ÷ 3 万美元 ≈ 1794 万张这个数字只能说明量级。真实销售组合里有训练卡、推理卡、消费级产品，还有 DGX 整机、网络、软件订阅等收入，不能直接等同于一年卖出近两千万张 GPU。这里要强调，整个推算过程不是精确预测，而是帮助理解行业规模背后的算力含义。
对于企业内部规划，同样不能只看“要买多少张卡”。一张 GPU 的算力只有在配套的网络、存储、调度、模型并行策略都合理时，才能转化为有效训练吞吐。
1.3 预测不确定性的工程应对
越是面对长期预测，越要保留弹性。2028 财年还有几年时间，市场格局、芯片型号、业务形态都会变化。工程侧的合理应对不是等预测确定后再行动，而是把算力规划拆成可以增量调整的模块：
- 当前需求用当前明确版本满足，不追求一步到位；
- 扩容路径在采购时提前设计，包括机房电力、机柜尺寸、散热方案；
- 成本模型按 3 到 5 年运行周期计算，而不是只看首次采购；
- 每年重新评估一次模型规模和推理并发，修正后续机型的采购计划。
这样即使英伟达的销售额预测最终与实际情况有偏差，企业自己的规划也不会因为依赖单一预测值而失控。
2. 从模型规模反推 GPU 需求，算力规划的第一步
2.1 训练和推理是两种不同的算力需求
算力规划不能只谈“大模型需要很多卡”。训练和推理的算力特征完全不同：
训练阶段，算力消耗取决于模型参数量、训练数据量、并行策略和训练时长。训练任务通常持续数天到数周，资源占用高且稳定。
推理阶段，算力消耗取决于并发请求数、单次请求的输入输出长度、模型规模和是否使用量化。推理任务对延迟更敏感，流量有明显峰谷。
生产环境中，一个成熟的算力平台通常会划分训练池和推理池。训练池注重长时间高负载稳定运行，推理池需要弹性伸缩和低延迟调度。做估算时，要先把两类需求分开。
2.2 用 FLOPs 估算训练所需 GPU 数量
训练大模型时，训练一个 token、一个参数大约需要 6 次浮点运算量，这个数字来自前向传播和反向传播的基本计算结构。虽然实际中因为激活重计算、通信、日志保存等原因会有所变化，但用它做量级估算是可接受的。
下面用一段 Python 脚本演示估算逻辑。这段代码用于说明思路，实际使用时要替换成自己模型的参数量、训练 token 数和目标训练天数。
def estimate_training_gpu_days( model_param_billions: float, tokens_billions: float, gpu_flops: float, utilization: float, efficiency_factor: float = 6.0, ) -> float: """ 估算训练所需 GPU 天数。 参数说明： model_param_billions: 模型参数量，单位 B，例如 70B 就传 70 tokens_billions: 训练数据量，单位 B，例如 2000B 就传 2000 gpu_flops: 单张 GPU 的稠密算力，单位 TFLOPs utilization: 实际利用率，建议取 0.3 到 0.6 efficiency_factor: 每个 token 每个参数需要的 FLOPs，常见估算取 6 """ total_flops = ( model_param_billions * 1e9 * tokens_billions * 1e9 * efficiency_factor ) available_flops = gpu_flops * 1e12 * utilization gpu_seconds = total_flops / available_flops gpu_days = gpu_seconds / 86400 return gpu_days # 示例：训练 70B 模型，使用 2000B token，单卡算力约 1000 TFLOPs gpu_days = estimate_training_gpu_days( model_param_billions=70, tokens_billions=2000, gpu_flops=1000, utilization=0.5, ) print(f"单卡训练需求约 {gpu_days:.0f} 天") print(f"如果目标 30 天完成，约需要 {gpu_days / 30:.0f} 张 GPU")运行这段代码，输出大致为：
单卡训练需求约 19444 天 如果目标 30 天完成，约需要 648 张 GPU这里的数字是量级参考，不等于真实训练耗时。影响实际卡数的因素还包括混合精度策略、张量并行大小、流水线并行阶段数、通信拓扑和 checkpoint 写入开销。真实项目里，648 张 GPU 是一个理论下限，工程实现通常要在此基础上增加 20% 到 50% 的冗余。
2.3 推理阶段的估算逻辑
推理估算可以用另一种思路：先估算单张 GPU 每秒能处理多少个请求，再根据在线业务峰值 QPS 倒推卡数。
def estimate_inference_gpu_count( qps: float, latency_budget_ms: float, concurrency_per_gpu: float, ) -> float: """ qps: 业务峰值每秒请求数 latency_budget_ms: 单次请求延迟预算，单位毫秒 concurrency_per_gpu: 单张 GPU 上能并行处理的请求数， 与显存、batch size、模型大小相关 """ max_qps_per_gpu = concurrency_per_gpu / (latency_budget_ms / 1000.0) return qps / max_qps_per_gpu # 假设峰值 1000 QPS，单次请求预算 200ms，单卡可并行处理 8 个请求 gpu_count = estimate_inference_gpu_count( qps=1000, latency_budget_ms=200, concurrency_per_gpu=8, ) print(f"推理池约需要 {gpu_count:.0f} 张 GPU")这个脚本缺少显存约束。实际规划中，只要显存放不下模型，再高的并发理论也无法实现。显存决定了 batch size 上限，单卡能并行处理的请求数会受显存限制。因此推理估算通常先验证模型加激活值是否放得进显存，再验证算力是否满足延迟要求。
推理场景的高峰倍数也很关键。不要拿平均 QPS 做规划，要预留 2 到 5 倍的峰值冗余，具体倍数取决于业务形态。对延迟敏感的业务，宁可多预留，也不能等超时时再扩容。
3. 算力池的三个关键维度：GPU、网络、存储
3.1 GPU 选型不能只看单卡算力
很多团队选型时只对比单卡 TFLOPs 和显存大小，忽略了训练任务在整卡集群中的扩展性。GPU 选型要考虑四个维度：
第一是算力密度。单卡算力决定同样规模任务的卡数上限，算力越高，需要的卡数越少，但机柜功耗也会上升。
第二是显存容量。显存决定能否在单卡上放下模型层、优化器状态和激活值。显存不足会导致无法启动训练，或者必须引入更复杂的并行策略。
第三是互联带宽。多卡训练中，梯度同步和 tensor parallel 通信非常频繁。如果卡间互联带宽不足，再高的单卡算力也会闲置。
第四是代际兼容性。同一个训练任务可能要跑几年，新采购的 GPU 如果与现有驱动、CUDA 环境和调度平台不兼容，会显著增加迁移成本。
以下表格整理了选型时常用评估项，具体数值要根据实际产品规格更新。
| 评估维度 | 核心问题 | 对资源规划的影响 |
|---|---|---|
| 单卡算力 | 每张卡能提供多少 FLOPS | 决定同等规模任务所需的卡数 |
| 显存容量 | 最大模型能否放得下 | 决定并行策略和 batch size 上限 |
| 卡间互联 | AllReduce 通信效率如何 | 决定万卡规模能否线性扩展 |
| 功耗与散热 | 机柜能部署几张卡 | 决定机房改造成本 |
| 软件生态 | CUDA、驱动、框架兼容性 | 决定迁移工作量 |
生产环境中，采购前要做一次小规模负载测试，不能只看规格表。把典型训练任务在候选 GPU 上跑三天，记录真实吞吐、稳定性、通信占比和掉卡情况。
3.2 网络是万卡集群最容易忽略的瓶颈
单机 8 卡训练时，NVLink 或同等的机内互联通常够用。但到了几十卡以上，机间通信就决定了整个集群的扩展系数。大规模训练中，all-reduce 通信量会随卡数增加而上升，网络拓扑如果设计不合理，GPU 会长时间等待梯度数据，利用率大幅下降。
网络规划要关注三个层次：
- 机内互联：决定单节点内多卡通信效率；
- 机间网络：决定跨节点梯度同步带宽；
- 管理层网络：用于日志、监控、容器镜像分发，不应与训练流量争抢带宽。
实际项目中，训练流量和存储流量最好分网或使用不同优先级队列。不然高并发的 checkpoint 写入会挤占梯度同步带宽，训练吞吐立刻下降。
3.3 存储决定数据加载和断点恢复速度
存储常被当成“买一块大硬盘”来规划，这是错误的。训练集群的存储有三个关键路径：
数据集读取。每次训练迭代都需要读取一批样本。如果数据集存储吞吐不足，GPU 算完当前 batch 后必须等待数据，利用率就会降低。
checkpoint 写入。大模型训练每几小时或每个 epoch 会保存一次权重。checkpoint 文件可能达到几百 GB，写入速度慢会导致训练等待，写入失败则可能导致训练中断后重新开始。
日志和临时文件。训练日志、性能追踪、临时文件如果写入同一套存储，会与核心训练任务争抢 IO。
推荐做法是至少区分热数据存储和冷数据存储。热数据用高吞吐并行文件系统或对象存储加速层，冷数据用容量型存储保存历史数据集和归档 checkpoint。存储性能目标要按训练迭代数据量和 checkpoint 大小反推。
4. 从采购到运营，6730 亿预测背后的 TCO 控制
4.1 硬件采购成本只是 TCO 的一部分
很多团队做预算时只算“每张卡多少钱”，然后乘以卡数。但 GPU 集群的 TCO 至少要包含以下部分。
| 成本项 | 说明 | 常见低估点 |
|---|---|---|
| 硬件采购 | GPU、CPU、内存、硬盘、网络设备 | 只算 GPU，忽略配套服务器成本 |
| 机房改造 | 电力、散热、机柜、布线 | 单机柜功率密度超出原设计 |
| 软件许可 | 调度平台、监控、操作系统支持 | 开源软件也要算维护人力 |
| 电费 | 满载功耗和实际负载相关 | 只看理论功耗，忽略空调和供电损耗 |
| 维护人力 | 系统、网络、平台、算法协作成本 | 一万卡集群需要专职 SRE 团队 |
| 折旧与换代 | 3 到 5 年后的淘汰和升级 | 没有预留更新换代资金池 |
以电费为例，假设单卡功耗 700W，部署 648 张卡，裸 GPU 功耗约 454kW，再加上服务器其他部件和机房制冷，总电力成本会明显高于硬件功耗本身。TCO 评估如果只看采购价，上线后很容易被电费和维护成本压垮。
4.2 一个最小 TCO 估算模板
TCO 估算不需要复杂的财务模型，用一个电子表格或 Python 脚本就能完成。下面是一个简化版 Python 示例，主要演示成本结构。
def estimate_three_year_tco( gpu_count: int, gpu_unit_price: float, gpu_power_watt: float, electricity_price_per_kwh: float, server_overhead_ratio: float = 1.8, electricity_duty_cycle: float = 0.7, years: int = 3, ): hardware_cost = gpu_count * gpu_unit_price total_power_kw = ( gpu_count * gpu_power_watt / 1000 * server_overhead_ratio ) yearly_electricity_cost = ( total_power_kw * electricity_duty_cycle * 24 * 365 * electricity_price_per_kwh ) operation_cost = yearly_electricity_cost * years # 机柜、网络、存储按 GPU 采购价的 30% 做量级估算 infrastructure_cost = hardware_cost * 0.3 total_cost = hardware_cost + infrastructure_cost + operation_cost return total_cost total = estimate_three_year_tco( gpu_count=648, gpu_unit_price=25000, gpu_power_watt=700, electricity_price_per_kwh=0.6, ) print(f"三年 TCO 约 {total / 10000:.0f} 万元")这段代码里的参数全部是示例，真实价格要以采购合同为准。重点是成本结构意识：当 GPU 数量从几十张扩大到几百张时，电费和基础设施成本会从“可以忽略”变成“必须按月核算”。
4.3 多代际混合与折旧策略
英伟达的销售额预测覆盖到 2028 财年，这也意味着未来几年会出现多代产品混用的情况。新 GPU 性能更强，但旧 GPU 也不是立刻退役，而是可以承担推理、开发测试、中小模型训练等压力较低的任务。
推荐策略是建立多代际算力池：
- 新卡投入大规模训练，承载核心业务；
- 上一代卡转入推理和微调任务；
- 再老一些的卡用于 CI、开发调试、低优先级批处理。
混合池调度时要注意算子兼容性。所有任务调度前应声明所需 GPU 型号或最低显存规格，调度器按标签分配，避免任务跑到不支持某类算子的卡上。
5. 容量上线后，利用率为什么会低于预期
5.1 现象：GPU 显示 100%，训练吞吐却上不去
这是训练平台最常见的故障。第一反应通常是加卡，但真正原因往往是瓶颈在网络、存储或数据加载。
排查链路从最外层开始：
首先检查硬件状态，使用nvidia-smi查看 GPU 利用率、显存、温度。
nvidia-smi如果 GPU 利用率接近 100%，但训练 loss 下降速度明显低于预期，需要进一步看计算是否在等待通信。可以用nvidia-smi dmon看更细粒度的指标。
nvidia-smi dmon -s pcumt然后再检查网络通信。大规模训练中，梯度同步时间过长会导致计算单元空转。可以用网卡工具查看实际吞吐是否接近预期带宽。
存储也是高发瓶颈。当数据集文件太小、数量太多，并且存储系统对小文件 IO 处理能力弱时，数据加载会拖慢每个 iteration。
5.2 常见瓶颈与数据采集点
| 现象 | 常见原因 | 检查方式 | 处理建议 |
|---|---|---|---|
| GPU 利用率高但吞吐低 | 混合精度计算单元空转 | 查看 kernel 分析工具日志 | 检查算子是否落到了低精度 kernel |
| 单卡利用率波动明显 | 数据加载抖动 | 观察 DataLoader 耗时 | 增大 num_workers、开启预取 |
| 多卡扩展后速度不线性 | 网络通信占比较高 | 查看通信时间占比 | 优化 tensor parallel 规模或拓扑 |
| 训练中断后恢复很慢 | checkpoint 存储并发写入慢 | 统计 checkpoint 写入耗时 | 使用高吞吐存储并做分片写入 |
这些排查项在万卡集群上必须有自动化采集和告警。不能等用户报告“训练很慢”再查，而是要在平台侧将 GPU 利用率、通信占比、数据加载耗时、网络吞吐全部打点。
5.3 队列、调度与弹性扩容
集群容量规划不只是“有多少张卡”，还包括“排队任务怎么管理”。高峰期所有 GPU 满载时，新任务只能排队。没有队列管理，用户会重复提交任务，导致资源碎片化。
调度策略建议：
- 训练任务按优先级和预估时长排队；
- 推理任务使用独立弹性池；
- 显存不足的任务自动回退到更小 batch 配置，而不是直接失败；
- 单用户可占用的最大卡数要有上限，避免一个任务占满整个集群。
弹性扩容要提前和云资源打通。本地集群处理日常稳定负载，突发需求通过云端 GPU 实例临时扩容。这种混合方案对控制 TCO 很有帮助，但前提是网络链路和镜像分发要提前测试。
6. 算力规划最佳实践与工程清单
6.1 六条可落地的工程建议
给正在做算力规划的团队六条建议。
第一，用“算力天”而不是“卡数”做预算指标。卡数只是资源规模，算力天能同时表达任务时长。预算口径统一后，训练和推理任务才能对比成本。
第二，所有算力估算都要给冗余。理论 FLOPs 和实际训练吞吐之间通常有 20% 到 40% 的差距，规划时要把利用率假设放在 0.4 到 0.6，而不是 0.9。
第三，采购前做小规模验证。先在 8 卡或 16 卡环境跑目标模型，得到真实吞吐，再线性外推到大规模集群。同时观察小规模下通信占比，如果已经偏高，更大规模会更明显。
第四，把存储和网络写入预算。GPU 采购只是第一步，配套改造成本要一起核算，避免“卡到货了，电不够，网不通”。
第五，监控要从第一天开始建设。初始集群规模小的时候就要采集利用率、排队时间、存储吞吐、通信占比。等集群变大后再补，历史数据会缺失，问题排查会很难。
第六，预留退出和降级路径。GPU 更新换代很快，采购时就要考虑旧卡迁移到推理或开发环境的方案，不要把所有业务绑死在一代硬件上。
6.2 算力规划上线前检查清单
| 检查项 | 建议标准 | 完成标准 |
|---|---|---|
| 训练需求估算 | 模型参数量、token 数、目标训练天数 | 输出 GPU 天数区间 |
| 推理需求估算 | QPS、延迟预算、显存约束 | 输出推理池卡数区间 |
| 网络带宽验证 | 机间通信类型、带宽要求 | 完成小规模压测 |
| 存储吞吐验证 | 数据集读取和 checkpoint 写入 | 记录实际写入耗时 |
| 监控体系 | GPU、网络、存储、队列指标 | 关键指标可出图可告警 |
| 容量预案 | 排队策略、云端扩容路径 | 完成一次扩容演练 |
| TCO 核算 | 3 年硬件电力维护总成本 | 输出成本对比表 |
这张清单可以在每次新增集群或扩容前执行。不是所有项目都需要全部完成，但至少训练需求估算、监控体系和 TCO 核算这三项不能省略。
6.3 下一步扩展方向
如果对这条路线继续深入，可以从两个方向扩展。
一个是调度与资源池化。研究 Kubernetes 与 GPU 调度器的配合，理解 binpack 与 spread 策略对集群利用率的影响，加入优先级、抢占、弹性伸缩能力。
另一个是训练性能分析。学习如何从 profiling 数据中识别通信瓶颈、低效算子和显存碎片，把规划阶段遗留的 20% 冗余逐步压缩回来。
英伟达的 2028 财年销售预测是一个远期的行业参考，它告诉你算力需求大概率还在增长，但不会替你决定该买多少卡。真正可靠的预算，来自你自己的模型规模、请求流量、成本结构和运行验证。从小规模开始，建立估算方法，拿到真实数据后再扩大投资，这才是面对千亿级行业预测时最稳妥的工程姿态。
)
