1. 从算力狂热到回报率拷问一个投资框架的诞生背景过去两年我身边做投资的朋友分成了两派。一派在2023年上半年冲进算力租赁赛道张口闭口就是“卡就是印钞机”另一派在2024年下半年开始焦虑因为发现很多AI项目的收入曲线和算力投入曲线完全对不上。我自己从2022年底开始系统性地跟踪AI基础设施投资踩过坑也吃过肉最大的体会是AI投资正在从“算力军备竞赛”切换到“回报率验证”阶段而市面上缺少一套能把技术参数翻译成财务语言的中间框架。这个框架要解决的核心问题很具体当一个AI项目摆在你面前它说要买多少张卡、建多大集群、用多高的精度训练你怎么判断这笔钱砸下去能不能收回来算力不是抽象概念它对应着具体的电费、折旧、运维人力和机会成本。我见过太多BP把“算力规模”当成核心竞争力来写但一问到“每PetaFLOP-day的产出是多少”“推理毛利率能不能覆盖折旧”就含糊其辞。这套框架适合三类人一是看AI赛道的投资人需要把技术叙事拆解成可验证的财务模型二是AI创业公司的技术负责人需要向董事会解释算力预算的合理性三是传统行业里负责数字化转型的管理者需要判断供应商报出的算力方案是否虚高。不管你是哪一类核心逻辑是一致的算力是成本项不是收入项只有能转化为可计费产出的算力才有投资价值。我把它拆成四个模块算力需求评估、算力成本结构、回报率测算、风险排查。每个模块都有具体的参数和计算路径不是拍脑袋的定性判断。下面我按实操顺序展开中间会穿插我实际做过的案例和踩过的坑。2. 算力需求评估从模型参数量到实际集群规模2.1 精度选择如何直接影响算力账单很多人一上来就问“训练一个大模型要多少算力”这个问题没法直接回答因为精度格式决定了算力需求的基数。我用一个具体例子来说明假设你要训练一个130亿参数的模型训练token量是2万亿不同精度下的显存占用和算力需求差异巨大。先看显存。模型参数本身占用的显存等于参数量乘以每个参数的字节数。FP32下每个参数4字节130亿参数就是52GBFP16下每个参数2字节就是26GBINT8下每个参数1字节就是13GB。但这只是权重训练时还有优化器状态、梯度、激活值。以Adam优化器为例FP32训练时优化器状态需要参数量乘以8字节一阶矩和二阶矩各4字节梯度需要参数量乘以4字节加起来每个参数额外12字节。所以130亿参数在FP32下光是权重优化器梯度就是130亿乘以16字节约208GB。这还没算激活值实际训练时激活值可能再占几十到上百GB。这就是为什么现在主流训练都用混合精度前向和反向传播用FP16或BF16优化器更新用FP32。这样权重和激活值用2字节优化器状态用4字节梯度用2字节每个参数约8字节130亿参数约104GB。如果再用上ZeRO零冗余优化器做分片把优化器状态和梯度切分到多张卡上单卡显存压力就能降到可接受范围。INT8在训练中很少用因为量化误差会严重影响收敛但在推理场景下INT8是主流。推理时不需要优化器状态和梯度只需要权重和激活值。INT8推理下130亿参数模型权重占13GB加上激活值和KV Cache一张24GB显存的卡就能跑起来。FP16推理则需要26GB权重至少两张24GB卡或者一张48GB卡。注意精度选择不是“越高越好”而是“够用就好”。FP64在AI训练中几乎用不到那是科学计算领域的。FP32适合小模型或者对数值稳定性要求极高的场景FP16/BF16是当前训练标配INT8/INT4是推理降本的关键手段。2.2 从参数量到算力需求的换算路径显存只是门槛真正决定训练时间的是浮点运算次数。业界有个经验公式训练算力需求约等于6乘以参数量乘以训练token数。这个6的来历是前向传播一次矩阵乘法是2倍参数量乘以token数乘加各算一次反向传播是前向的两倍所以总共约6倍。拿130亿参数、2万亿token来算6乘以130亿乘以2万亿等于1.56乘以10的24次方FLOPs。这个数字很大我们换算成更直观的单位。一张H100的FP16算力不算稀疏性大约是989 TFLOPS也就是每秒约10的15次方次浮点运算。1.56乘以10的24次方除以10的15次方得到1.56乘以10的9次方秒约等于18000天。一张卡要跑49年显然不现实。所以需要集群。如果用1000张H100理想情况下18天能跑完。但实际不可能达到100%利用率通信开销、数据加载、检查点保存都会吃掉时间。我实测下来大规模训练的有效算力利用率通常在30%到50%之间。按40%算1000张H100需要45天左右。这就是为什么大模型训练动辄几个月而且集群规模直接决定了你能在多短时间内迭代一次。这里有个关键参数叫MFU模型浮点运算利用率等于实际达到的FLOPs除以理论峰值FLOPs。MFU超过50%就算非常优秀了很多团队只能做到30%出头。MFU低的原因包括通信瓶颈尤其是跨节点All-Reduce、显存带宽限制、流水线气泡、数据预处理跟不上。评估一个团队的训练能力不要只看他们有多少卡要问他们的MFU是多少。2.3 推理场景的算力评估逻辑训练是一次性投入推理是持续性成本。推理的算力需求取决于三个变量请求量、每次请求的token数、模型大小。假设你有一个130亿参数的模型每天处理100万次请求每次请求平均输入500 token、输出200 token。推理的算力消耗主要来自两部分Prefill阶段处理输入和Decode阶段逐token生成输出。Prefill阶段的计算量约等于2乘以参数量乘以输入token数Decode阶段每生成一个token需要2乘以参数量次运算。所以每次请求的总FLOPs约等于2乘以130亿乘以500200等于1.82乘以10的13次方FLOPs。100万次请求就是1.82乘以10的19次方FLOPs。一张H100在INT8推理下的算力约2000 TOPS每秒万亿次操作考虑50%利用率每秒能处理10的15次方次操作。1.82乘以10的19次方除以10的15次方等于18200秒约5小时。也就是说一张H100理论上5小时能处理完100万次请求平均每天只需要0.2张卡。但实际要考虑峰值并发不能按平均值配置通常要留3到5倍余量。实操心得推理算力评估最容易犯的错误是只看平均值。我见过一个项目按日均请求量配了卡结果晚上流量高峰时排队严重用户体验崩了。正确做法是看P99峰值并发按峰值配置闲时用弹性伸缩降本。3. 算力成本结构把技术参数翻译成财务语言3.1 自建集群与租用算力的成本对比算力获取方式主要有三种自建集群、租用云算力、混合模式。每种方式的成本结构完全不同不能简单比单价。自建集群的成本包括硬件采购GPU服务器、网络设备、存储、机房改造供电、制冷、承重、电费、运维人力、软件授权、折旧。以1000张H100为例单张H100服务器含8卡市场价约300万人民币1000张卡约125台服务器硬件采购约3.75亿。机房改造按每千瓦1万元算1000张H100功耗约700千瓦加上制冷和网络总功耗约1000千瓦改造费用约1000万。电费按每度0.8元、每天满载20小时算每天电费约1.6万一年约584万。运维团队至少5人人均年薪50万一年250万。折旧按3年直线折旧每年约1.25亿。租用云算力的成本相对简单按卡时计费。H100的市场租用价格波动很大2023年高峰期每小时30到40元2024年回落到20到25元。按每小时25元算1000张卡租一年按每天20小时有效使用约1.8亿。表面看租用比自建贵但自建有大量隐性成本和资金占用。这里有个关键决策点如果你的算力利用率低于50%租用几乎总是更划算。因为自建集群闲置时也在折旧和耗电而租用可以随用随停。我帮一个团队算过账他们训练任务不连续平均利用率只有35%自建三年总成本约4.5亿租用同样算力三年约3.2亿租用省了1.3亿。但如果利用率能到70%以上自建在第二年就开始有成本优势。3.2 算力集群的架构选择与成本影响算力集群的架构直接影响通信效率和成本。当前主流架构有三种胖树架构、轨道优化架构、蜻蜓架构。胖树架构是最常见的核心交换机和汇聚交换机分层连接任意两个节点之间的通信跳数相同。优点是延迟可预测适合All-Reduce密集的训练任务。缺点是核心交换机端口数量限制了集群规模扩展成本高。一个支持1000张卡的胖树集群网络设备成本约占总硬件成本的15%到20%。轨道优化架构把同一轨道内的节点用高速链路连接跨轨道通信走上层交换机。这种架构适合混合并行策略因为同一轨道内的通信可以走高速链路。但轨道间通信可能成为瓶颈需要精心设计并行策略来减少跨轨道通信。蜻蜓架构用高维超立方体拓扑扩展性好但布线复杂对运维要求高。我见过一个团队用蜻蜓架构搭了2000卡集群结果因为光模块故障率偏高实际可用性只有85%训练任务经常中断。注意网络成本容易被低估。1000卡集群的网络设备交换机、光模块、线缆成本可能占到总硬件成本的20%到30%。而且网络故障是训练中断的首要原因选架构时要把可靠性和可维护性放在扩展性前面。3.3 电力与制冷被忽视的成本大头算力集群的电力成本包括两部分IT设备耗电和制冷耗电。PUE电能利用效率等于总耗电除以IT设备耗电。先进数据中心PUE可以做到1.1到1.2普通机房可能到1.5甚至更高。1000张H100的IT设备功耗约700千瓦如果PUE是1.2总功耗就是840千瓦。一年电费按0.8元每度算约588万。如果PUE是1.5总功耗1050千瓦一年电费735万多出147万。所以机房选址和制冷方案对长期成本影响很大。制冷方案主要有风冷和液冷。风冷改造成本低但散热效率有限适合功率密度较低的集群。液冷散热效率高支持更高功率密度但改造成本高。冷板式液冷每千瓦改造成本约5000到8000元浸没式液冷更高。对于1000卡以上的集群液冷通常是更优选择因为可以降低PUE到1.1左右长期电费节省能覆盖改造成本。我个人的经验是如果电价高于0.6元每度液冷的投资回收期通常在2年以内。如果电价低于0.4元风冷可能更经济。选址时优先考虑电价低、气候凉爽的地区比如西北和华北部分地区。4. 回报率测算从算力投入到可计费产出4.1 训练项目的回报率测算框架训练项目的回报率测算比推理复杂因为训练本身不直接产生收入它产出的是模型能力模型能力再通过推理服务变现。所以训练项目的回报率要分两步算先算模型能力提升带来的收入增量再算训练成本。假设你有一个基础模型当前在某个任务上的准确率是80%你计划用1000张H100训练一个月预期准确率提升到85%。这个5个百分点的提升能带来多少收入取决于你的商业模式。如果是API调用准确率提升可能带来调用量增长如果是垂直场景解决方案准确率提升可能带来客单价提升或客户留存率提升。我做过一个案例一个法律文书生成模型准确率从82%提升到88%后客户续费率从65%提升到80%客单价从每年10万提升到15万。假设有100个客户收入增量等于100乘以15万乘以80%减去10万乘以65%等于100乘以12万减去6.5万等于550万。训练成本按1000张H100一个月算租用成本约1000乘以25乘以24乘以30等于1800万。单看这个项目收入增量覆盖不了训练成本。但这里有个关键模型能力提升往往有复用性。同一个模型可以服务多个场景收入增量要按所有场景汇总。而且模型能力提升后推理成本可能下降比如可以用更小的模型达到同样效果这部分节省也要算进去。所以训练项目的回报率测算不能只看单个场景要看模型能力的整体价值。4.2 推理服务的单位经济模型推理服务的单位经济模型相对清晰每千token收入减去每千token成本。收入端取决于定价策略成本端包括算力折旧或租金、电费、网络带宽、运维分摊。以130亿参数模型、INT8推理为例。一张H100每小时能处理约200万token考虑50%利用率和批处理优化租用成本每小时25元每百万token算力成本约12.5元。加上电费、网络、运维分摊每百万token总成本约18元。如果定价是每百万token 30元毛利率40%。如果定价是每百万token 20元毛利率只有10%稍微有点波动就亏损。这里的关键变量是批处理大小。批处理越大GPU利用率越高单位token成本越低。但批处理太大会增加延迟影响用户体验。我实测下来对于交互式应用批处理大小在8到16之间比较平衡对于离线批量处理可以开到64甚至128。实操心得推理服务的毛利率对算力利用率极其敏感。利用率从50%提升到70%单位成本能降30%左右。所以推理服务要尽量把流量集中到少数几张卡上而不是分散到很多卡上。我见过一个团队为了“高可用”把流量分散到10张卡上结果每张卡利用率都不到20%毛利率惨不忍睹。4.3 算力投资回报率的核心公式与参数把上面这些串起来算力投资回报率的核心公式是ROI 推理收入 模型能力增量收入 - 算力总成本 - 其他运营成本/ 算力总成本其中算力总成本包括硬件折旧或租金、电费、制冷分摊、网络成本、运维人力、软件授权。其他运营成本包括数据标注、模型评估、市场推广、销售人力。每个参数都需要有依据不能拍脑袋。硬件折旧按3年直线折旧残值率5%到10%。电费按实际PUE和当地电价算。运维人力按集群规模配通常每1000卡配5到8人。数据标注成本按标注量和单价算模型评估成本按评估次数和每次成本算。我建议做一个敏感性分析表把关键参数上下浮动20%看ROI的变化范围。如果ROI在悲观情景下仍然为正这个投资就比较安全如果在乐观情景下才为正风险就很高。参数悲观情景基准情景乐观情景算力利用率30%50%70%每百万token收入20元30元40元电费元/度1.00.80.5硬件折旧年限2年3年4年ROI-15%25%60%这张表是我实际做项目时用的模板每次评估新项目都会填一遍。如果悲观情景下ROI为负就要慎重考虑如果基准情景下ROI低于20%说明这个项目抗风险能力弱。5. 常见问题与排查技巧实录5.1 算力需求评估中的典型误判误判一按理论峰值算算力需求忽略实际利用率。我见过一个BP写“1000张H100峰值算力989 PFLOPS训练130亿模型只需XX天”完全没考虑MFU。实际MFU可能只有30%训练时间是理论值的3倍多。评估时要问清楚MFU假设最好要求提供历史训练任务的MFU数据。误判二把显存需求当成算力需求。显存决定能不能跑起来算力决定跑多快。两个模型可能显存需求差不多但算力需求差几倍。评估时要分开算先算显存能不能装下再算算力需要多少卡时。误判三忽略推理的峰值并发。按日均请求量配卡晚上高峰时排队。正确做法是按P99峰值并发配卡闲时用弹性伸缩。弹性伸缩的响应时间也要考虑如果扩容需要5分钟那这5分钟内的请求要么排队要么丢弃。误判四低估网络和存储成本。算力集群不只是GPU网络设备和存储系统可能占总成本的30%以上。评估时要问清楚网络架构、存储方案、带宽需求。5.2 回报率测算中的常见陷阱陷阱一把收入增长全部归因于算力投入。收入增长可能来自市场推广、销售团队扩张、产品体验优化不全是算力的功劳。做回报率测算时要剥离其他因素的影响或者至少做归因分析。陷阱二忽略竞争导致的降价压力。AI推理服务的价格在过去一年下降了50%以上未来可能继续下降。测算时要考虑价格年降幅保守一点按每年降20%到30%算。陷阱三低估运维复杂度和人力成本。大规模集群的运维不是几个脚本就能搞定的需要专业的SRE团队、监控系统、故障排查流程。我见过一个团队自建了500卡集群结果因为运维跟不上实际可用性只有70%算力成本变相增加了40%。陷阱四把一次性收入当成持续性收入。有些AI项目是项目制交付收入是一次性的但算力成本是持续性的。这种项目的回报率测算要特别小心确保一次性收入能覆盖整个项目周期的算力成本。5.3 算力投资决策的检查清单每次评估算力投资项目我都会过一遍这个清单算力需求是否按实际MFU折算MFU假设是否有历史数据支撑显存需求是否算上了优化器状态、梯度、激活值是否用了混合精度和ZeRO推理算力是否按P99峰值并发配置弹性伸缩策略是否明确自建还是租用利用率是否超过50%资金成本是否算进去了网络架构是否匹配并行策略网络成本占比是否合理PUE是多少电价是多少制冷方案是否经济收入预测是否剥离了非算力因素是否考虑了价格年降运维人力是否配足可用性目标是否现实敏感性分析是否做了悲观情景下ROI是否为正这个清单我用了两年多帮我避开了至少三个坑。有一次一个项目看起来回报率很高过完清单发现他们按100%利用率算的实际历史利用率只有40%重算后ROI从35%降到8%果断放弃。5.4 算力集群架构选择的实操建议如果你决定自建集群架构选择有几个实操建议第一先确定并行策略再选架构。数据并行、流水线并行、张量并行的通信模式不同对网络的要求也不同。数据并行需要高带宽All-Reduce流水线并行需要低延迟点对点通信张量并行需要极高带宽和极低延迟。先确定主要用哪种并行策略再选匹配的网络架构。第二网络设备不要省钱。网络故障是训练中断的首要原因而且排查困难。我建议网络设备预算占总硬件预算的20%以上选择成熟稳定的品牌和型号。光模块要买原厂的兼容模块虽然便宜但故障率高。第三存储系统要分层。训练数据量大全部放高速存储成本太高。建议用分层存储热数据放NVMe SSD温数据放SATA SSD冷数据放HDD或对象存储。检查点保存要快否则训练中断后恢复时间长。第四预留扩展空间。机房供电、制冷、承重、网络端口都要预留扩展空间。我见过一个团队建了500卡集群想扩展到1000卡时发现机房供电不够改造花了半年错过了市场窗口。5.5 算力成本优化的几个实用技巧技巧一混合精度训练。FP16/BF16训练比FP32训练省一半显存和算力而且收敛性通常没问题。BF16比FP16更稳定推荐优先用BF16。技巧二梯度累积。显存不够时可以用小batch加梯度累积模拟大batch。梯度累积步数等于目标batch除以实际batch。这样不增加显存但训练时间会线性增加。技巧三检查点优化。检查点保存频率太高会拖慢训练太低则中断后损失大。建议根据训练稳定性和任务时长平衡通常每几小时保存一次。检查点可以用异步保存不阻塞训练。技巧四推理批处理。推理时尽量批处理提高GPU利用率。但批处理大小要平衡延迟和吞吐交互式应用批处理小一点离线应用批处理大一点。技巧五弹性伸缩。推理服务用弹性伸缩闲时缩容降本忙时扩容保体验。伸缩策略要基于实际流量模式不要拍脑袋设阈值。技巧六算力共享。如果多个团队共用集群可以用调度系统做算力共享提高整体利用率。但要做好隔离和优先级管理避免互相影响。6. 一个完整的算力投资评估案例6.1 项目背景与算力需求测算去年我参与评估了一个AI客服项目。项目计划训练一个70亿参数的垂直领域模型用于替代人工客服。训练数据是500万条历史客服对话训练token量约50亿。推理场景是每天处理20万次用户咨询每次咨询平均输入300 token、输出150 token。训练算力测算6乘以70亿乘以50亿等于2.1乘以10的21次方FLOPs。用100张H100训练理论时间等于2.1乘以10的21次方除以100乘以10的15次方等于2.1乘以10的4次方秒约5.8小时。按MFU 35%算实际约16.6小时。加上数据加载、检查点、评估按2天算。租用100张H100两天成本约100乘以25乘以24乘以2等于12万。推理算力测算每次请求FLOPs等于2乘以70亿乘以300150等于6.3乘以10的12次方。20万次请求等于1.26乘以10的19次方FLOPs。一张H100 INT8推理算力2000 TOPS按50%利用率算每秒10的15次方次操作。1.26乘以10的19次方除以10的15次方等于12600秒约3.5小时。考虑峰值并发是平均值的3倍需要约10张H100。租用10张H100一个月成本约10乘以25乘以24乘以30等于18万。6.2 成本结构与回报率测算训练成本12万推理成本每月18万。其他成本包括数据标注和清洗约5万模型评估约2万运维人力分摊约3万每月。首月总成本约40万后续每月约21万。收入端替代人工客服假设每个客服月薪6000元20万次咨询需要约20个客服月人力成本12万。AI客服定价按每次咨询0.5元算20万次收入10万。表面看AI客服收入10万低于人工成本12万但AI客服可以24小时服务且边际成本低。如果咨询量增长到30万次人工需要30个客服成本18万AI客服收入15万成本增加很少。算力投资回报率首月投入40万后续每月收入10万减去成本21万亏损11万。但随着咨询量增长和模型优化推理成本会下降。假设6个月后咨询量到50万次收入25万推理成本因批处理优化降到每月25万其他成本5万月利润负5万。再优化模型用更小的模型达到同样效果推理成本降到15万月利润5万。累计12个月总投入约40万加11个月乘以20万等于260万总收入约12个月平均15万等于180万净亏损80万。这个项目单看财务回报不理想但战略价值在于积累垂直领域模型能力可以复用到其他客服场景数据资产可以用于训练更多模型AI客服可以提升响应速度和一致性带来隐性收益。所以最终决策是先小规模试点用租用算力验证效果如果效果好再扩大。6.3 敏感性分析与决策建议对关键参数做敏感性分析参数悲观基准乐观咨询量月增长5%15%30%每次咨询定价0.3元0.5元0.8元推理成本月降幅5%10%20%12个月累计利润-180万-80万50万悲观情景下亏损180万基准情景亏损80万乐观情景盈利50万。这个项目风险较高建议先租用算力做3个月试点投入控制在50万以内。如果3个月内咨询量月增长超过20%且推理成本月降幅超过15%再考虑扩大投入。这个案例的教训是算力投资不能只看技术可行性要看商业可行性。技术上行得通的项目商业上可能亏钱。评估时要算清楚账不要被技术叙事带偏。7. 算力投资的未来变量与应对策略7.1 算力供给格局的变化趋势算力供给正在从紧缺走向结构性过剩。2023年一卡难求2024年很多算力租赁商开始降价促销。这个变化对投资决策的影响是自建集群的风险在上升租用算力的性价比在提升。因为如果算力供给持续增加租用价格会继续下降自建集群的折旧成本相对固定竞争力会下降。另一个变化是推理算力需求超过训练算力需求。随着大模型应用落地推理算力占比越来越高。推理算力对集群架构的要求和训练不同推理更看重低延迟和高吞吐对网络带宽要求相对低。这意味着现有训练集群可能不适合做推理需要单独建设推理集群。应对策略训练算力优先租用保持灵活性推理算力可以根据流量稳定性决定自建还是租用流量稳定且规模大时自建更经济。7.2 模型效率提升对算力需求的影响模型效率在快速提升。同样的任务2024年的模型可能比2023年的模型少用50%算力。MoE混合专家架构、稀疏注意力、量化推理等技术都在降低算力需求。这对算力投资的影响是算力需求预测要留出效率提升的余量不能按当前效率线性外推。我建议做算力规划时按每年效率提升20%到30%来折算。也就是说如果当前需要1000张卡一年后同样任务可能只需要700到800张卡。这个效率提升来自模型架构优化、推理框架优化、硬件升级等多个方面。应对策略算力投资要模块化、可扩展避免一次性大规模投入。先建小集群验证再根据实际需求逐步扩展。硬件选择上优先考虑通用性强的型号避免专用芯片锁定。7.3 算力投资的风险管理框架算力投资的主要风险包括技术路线变化导致硬件过时、算力价格下降导致自建集群贬值、模型效率提升导致算力需求下降、竞争加剧导致推理价格下降。风险管理框架包括第一控制自建集群规模。自建集群不超过总算力需求的50%其余用租用满足。这样既保证核心任务的算力供应又保持灵活性。第二硬件折旧年限不要超过3年。AI硬件迭代快3年后可能大幅贬值。折旧年限太长会导致账面利润虚高实际现金流紧张。第三收入预测要保守。推理价格年降幅按20%到30%算咨询量增长按10%到15%算。不要用乐观情景做决策。第四保持技术跟踪。关注模型效率、硬件性能、算力价格的变化每季度更新一次算力投资模型。第五设置止损线。如果实际利用率连续3个月低于30%或者推理毛利率连续3个月低于10%就要考虑调整策略。这套框架我用了两年多帮我在算力投资上避开了大坑也抓住了机会。最核心的体会是算力是手段不是目的能产生回报的算力才是好算力。不要被“算力规模”迷惑要盯着“算力回报率”。每次决策前把账算清楚把风险想全面比盲目跟风靠谱得多。最后分享一个小技巧做算力投资评估时找一个懂技术的人和一个懂财务的人一起看项目。技术的人看算力需求是否合理财务的人看回报率是否可行。两个人意见一致时再决策不一致时就要深挖原因。我见过太多项目是技术的人觉得可行、财务的人觉得亏钱最后发现是技术的人高估了利用率或者财务的人低估了收入增长。两边对齐了决策质量会高很多。