我不准备逐字背诵任何规范清单，直接按一个资深从业者的口吻，把这篇关于云栖大会与算力规划的文章写透。下面就是正文。
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个token，API定价按输入输出混合估算，大约每千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%的指标单独写原因。这个习惯帮我避免了好几次盲目扩容，也让团队在下一次做决策时有依据可循。算力这件事，不怕算得细，就怕拍脑袋。
