我不准备逐字背诵任何规范清单直接按一个资深从业者的口吻把这篇关于云栖大会与算力规划的文章写透。下面就是正文。1. 云栖大会现场的几个直观信号今年云栖大会逛下来最强烈的感受是算力这个词已经从技术圈的黑话变成了企业决策层必须亲自过问的“基础设施账单”。前几年大家聊算力聊的是单卡性能、集群规模、跑分排名今年聊的是单位算力产出、推理成本、ROI以及“我到底该买卡、租云、还是直接调API”。先说一个现场细节。展馆里最拥挤的展台不是某家芯片厂商的旗舰卡发布而是一个做算力调度与成本优化的SaaS厂商——他们把同一种AI模型部署在不同算力资源上的每秒成本做成实时榜单旁边围满了拿着笔记本记录的企业CTO和财务负责人。这个场景本身就说明算力过剩与算力稀缺同时存在企业缺的不是算力本身而是对算力的度量能力和规划能力。另一个信号是边缘侧算力设备的密集出现。去年云栖大会还有大量展台在秀千卡万卡集群互联今年很多厂商把精力放到了单机2-4卡的边缘推理设备、自带NPU的工业控制器、以及车端和无人机端的轻量化算力模组上。这说明行业共识正在转向大模型效果到底行不行技术侧已经验证得差不多了接下来要解决的是怎么把算力部署到离业务最近的地方。对于企业决策者来说今年的大会其实只传递了三句话算力要算账算力要分层算力要嵌入业务流。2. 算力规划之前先搞懂算力的几种“度量衡”很多决策者一上来就盯着一串数字比较某显卡AI算力多少TOPS、某云厂商的算力实例每秒能跑多少次推理、某款加速卡的FP16算力是不是比另一款高两倍。这些数字有用但盲目对比之前得先搞懂它们分别度量的是什么。否则很容易被单一参数带偏。2.1 TOPS、TFLOPS、TOKEN/s分别代表什么TOPS全称是Tera Operations Per Second每秒万亿次操作通常用来描述INT8等整数精度的AI算力是边缘设备、自动驾驶芯片、端侧NPU最常用的指标。TFLOPS是每秒万亿次浮点运算分FP32、FP16、BF16、FP8等不同精度是GPU和数据中心加速卡的主流标称方式。TOKEN/s则是指每秒生成的token数量是应用层最直观的指标——一个模型到底跑得快不快最终还是要看这个数。这三者之间没有简单的换算关系。同一块芯片跑不同模型、不同精度、不同batch size实际吞吐差异可能高达3到5倍。所以最靠谱的做法是用你的真实业务模型、真实并发特征去跑一轮benchmark而不是直接拿厂商标称的峰值参数做比较。2.2 训练算力、推理算力、边缘算力要分开规划很多企业规划算力时犯的第一个错误是把训练、推理、边缘计算混在一个池子里讨论。实际上三类需求的特性完全不同。训练算力是“波峰型”的集中在模型调优、微调和版本迭代期任务密集但往往不是7×24小时满负荷推理算力是“稳态型”的业务上线后持续消耗对延迟和成本非常敏感通常是最先出现浪费或瓶颈的环节边缘算力则是“分布式”的部署在工厂产线、门店、车辆、无人机等物理现场核心约束不是算力峰值而是功耗、体积、环境温度和网络条件。一个我服务过的制造业客户最初把所有预算都砸在一台八卡训练服务器上结果训练每月只用十几天而产线的视觉质检推理还在用老旧的CPU方案检测速度跟不上产线节拍。后来把规划思路调整为“训练按需租云算力推理自建小规模GPU集群产线边缘部署专用推理卡”整体成本下降约40%检测时延从800毫秒压到了120毫秒。3. 自建算力、云上租用、API接入三类资源怎么选企业在算力规划时最纠结的问题就是自建还是上云还是干脆不碰底层算力直接调用大模型API。我的观点是这不是一道非此即彼的选择题而是一道根据业务形态动态配比的组合题。3.1 自建算力的适用边界自建算力的核心优势是可控数据不出域、资源独占、成本在足够利用率下可以摊得很薄。但它的劣势也极其明显——前期投入大、扩容周期长、硬件折旧快、运维成本容易被低估。适合自建算力的场景通常有三个特征一是算力利用率能够长期维持在50%以上二是数据合规或业务连续性要求不允许依赖外部资源三是推理负载相对平稳可以预测。3.2 云上算力的弹性价值云算力最大的价值是弹性这个认知大家都懂但实际使用中的误区是把云算力当自建算力用——买了包年包月的高配实例却只跑稀疏的训练任务或者没有配置自动伸缩策略导致高峰期资源不足、低谷期资源空转。我的实操建议是训练任务这类波峰型负载优先使用按量付费或竞价型实例配合任务调度系统在低谷期跑大规模批量训练推理服务这类稳态负载才适合使用预留实例并且一定要做好基于QPS每秒查询数的自动伸缩配置。3.3 API接入算力与本地算力的成本分界线现在很多AI应用团队倾向于直接接入大模型API省去算力规划和管理成本。这个思路在前中期非常正确但有一个问题需要被正视当业务流量达到一定量级后API的按token计费会成为一个不断膨胀的运营支出项。我做过一个粗略测算假设一个客服机器人平均每次会话消耗约2000个tokenAPI定价按输入输出混合估算大约每千token在0.01到0.02元区间不同模型差异很大单次会话成本就是0.02到0.04元。如果月会话量达到100万次仅推理费用就是2万到4万元。如果流量继续增长到千万次级别自建推理集群的单位成本优势就会体现出来——一张当前主流的中高端显卡在量化模型下单卡吞吐可以做到每秒数千甚至上万token按三年折旧摊算单位token成本往往比API低一个量级。但自建推理也意味着你要承担稳定性、并发调度、模型版本迭代等工程成本。所以我的建议不是“流量大了就一定要自建”而是设定一个分界线当API月度支出稳定超过自建方案TCO的60%到70%时就该认真启动自建推理的方案验证。3.4 算力分层中心训练、边缘推理、端侧轻量计算前面提到的制造业质检案例已经说明了分层的重要性。再展开一点完整的算力规划应该像一张地图中心算力负责训练和复杂推理边缘算力负责现场实时响应端侧算力负责传感器融合和轻量预处理。4. 从算力参数到现场实测一款显卡的真实算力评估今年大会上关于显卡AI算力TOPS排行的话题讨论度很高尤其是RTX Pro 5500这类工作站级显卡在专业应用和边缘推理设备里频繁被提及。很多决策者喜欢直接看排行榜但我建议把排行当作线索而不是结论。4.1 读懂厂商标称的TOPS含义以单张显卡为例厂商标称的AI算力TOPS通常是在特定精度如INT8稀疏性加速开启和特定模型结构下测得的理论峰值。这个数字体现的是硬件极限能力但在真实业务里模型结构、显存带宽、batch size、数据预处理方式都会直接影响实际吞吐理论峰值往往只能达到一半甚至更低。我自己的评估流程是四步第一步确定业务需要的精度FP16还是INT8第二步用真实业务模型跑一轮标准benchmark记录吞吐和延迟第三步小规模压测观察持续负载下的功耗和散热表现第四步测算单位推理成本算力硬件成本除以总推理次数。4.2 一个真实的评估案例去年我帮一个做工业视觉检测的团队评估设备选型。他们最初的方案是采购高性能游戏显卡理由是单卡TOPS高价格比专业卡便宜。实测后发现两个问题一是该卡在长时间满载推理时存在功耗墙性能会周期性下降约20%直接影响产线节拍二是游戏卡在7×24小时工业场景下的稳定性和驱动支持都不够一个月内出现了两次驱动崩溃。后来我们换成了散热设计更稳健的专业工作站卡虽然单卡TOPS标称低一些但持续推理吞吐反而更稳定整体TCO更优。这个案例说明算力规划看的是系统级的持续能力不是单卡级的峰值参数。4.3 边缘与嵌入式算力的特殊考量大疆这类公司在嵌入式AI算力上的开发申请之所以常被讨论是因为无人机、机器人、车载设备对算力有完全不同的约束——功耗不超过几十瓦、必须在特定温度范围内稳定工作、重量和体积严格受限。在这些场景里TOPS/W每瓦算力和TOPS/mm²每平方毫米算力比绝对TOPS更有决策价值。5. 我实操中踩过的算力规划坑这一节写给真正要落地算力规划的企业决策者和技术负责人。以下问题都是我在实际项目里踩过、或者亲眼见过的。5.1 只算峰值需求不算利用率最常见的坑按照业务最高峰时的并发量来采购自建算力结果高峰只占全年5%的时间剩下95%的时间算力都在空转。建议做法先按利用率规划基座资源覆盖60%到70%的典型负载高峰期的溢出需求全部交给云上弹性资源处理。成本模型里要同时包含硬件折旧、机房电费、运维人力和云资源弹性支出而不是只盯着采购单。5.2 忽略模型演进对算力需求的影响很多团队在做规划时基于当前模型尺寸估算推理成本但未来6到12个月模型可能会升级、上下文窗口可能会变长、业务可能增加多模态能力。这些变化都会显著推高单次推理的算力消耗。我在规划时通常会预留30%左右的算力冗余用来吸收模型升级和业务增长带来的增量。这个比例可以根据业务节奏调整但不要一点冗余都不留。5.3 低估数据搬移的成本算力规划最容易漏掉的是数据进出集群的带宽和时间成本。训练数据要传到算力所在的地方推理结果要送回业务侧海量数据在存储、网络、计算之间流转的花费有时候比算力本身更惊人。一个实际案例某团队把自建训练的GPU集群放在A地但业务数据主要在B地的对象存储里。每次训练任务光数据传输等待时间就占整个任务时长的近三分之一。后来把训练任务改到数据所在地的云上算力执行再定期把模型产物同步回来整体效率提升将近一倍。5.4 忽视单位算力产出的度量我见过一个团队在报告里详细列了买了多少张卡、集群峰值算力达到多少P但问起来“这些算力总共支撑了多少业务请求、创造了多少收入”管理层却说不出具体数字。算力规划的最终产出应该是业务指标不是硬件指标。所以从一开始就要建立一套映射关系算力消耗对应多少活跃用户请求、多少条质检记录、多少个生成任务。没有这层映射算力规划就只是花钱清单。6. 决策者可以把哪些信号带回自己的工作如果今年云栖大会只能记住三个信号我会建议企业决策者记住下面三个。第一算力正在从稀缺资源变成被精细运营的普通资源。前几年能抢到卡就是优势接下来的竞争在于谁的单位算力产出更高。建立算力成本与业务指标之间的量化关系是每个用AI做业务的企业都要补的功课。第二推理算力是未来大多数企业真正需要认真规划的算力类型。训练可以租、可以等、可以找人代工但推理是持续运行的业务成本它的效率直接决定AI应用的毛利空间。第三边缘侧不是小打小闹的补丁而是算力分布的重要一极。凡是要求实时响应、数据本地化、弱网甚至断网可用的场景都需要把算力放到现场去。规划时不要只看中心集群要把端、边、云当成一个整体来设计。7. 最后分享一点个人体会做算力规划这件事本质上是在跟不确定性和时间做博弈。没有人能精确预测未来三年的模型形态和业务规模所以好的规划不是做一次就一劳永逸而是要搭一个可以动态调整的框架——固定的部分尽量少弹性的部分尽量多每一笔大额算力支出都要有对应的业务假设和退出机制。我个人的习惯是每年做一次算力规划的复盘把实际利用率、单位成本和年初假设摆在一起对一遍差距超过20%的指标单独写原因。这个习惯帮我避免了好几次盲目扩容也让团队在下一次做决策时有依据可循。算力这件事不怕算得细就怕拍脑袋。