很多人算算力账时把训练和推理混在一张表里，结果预算对不上：训练是一次性重投入，推理是随用量线性爬升的长期账。这篇把两者的硬件偏好、成本结构、扩容方式和增长驱动力拆开讲，并给出去站内页面核数字的具体路径，帮你在做预算、选平台、谈租卡时不再拿错口径。
很多人算算力账时把训练和推理混在一张表里，结果预算怎么对都对不上。原因不复杂：训练是一次性重投入，推理是随用量线性爬升的长期账，两者的节奏根本不是一回事。把两条曲线画在同一张图上，看到的斜率就是错的。
这篇不讲概念定义，只讲怎么把这两种账拆开。硬件偏好哪里不一样、成本什么时候发生、扩容靠堆卡还是靠弹性、增长靠什么信号推动，然后给出一套可以马上动手的四步核查动作。中途要核数字，都去站内对应页面看当时的数，别信任何写死的结论。
先分清两种算力负载在干什么
训练是反复前向加反向、更新权重，追求整卡整集群长时间稳定跑；推理只做前向，追求低延迟高吞吐。这个差别决定了后面所有的成本结构：训练怕中断，推理怕排队。一个中断可能丢掉几天的进度，一个排队只是让用户多等两秒，但量大了就是实打实的钱。
- 训练看什么
- 总算力规模、卡间互联带宽、集群能不能连续几天不抖
- 推理看什么
- 显存容量够不够装权重加 KV 缓存、批次调度效率、单位 token 的处理成本
- 混用的后果
- 同一张卡两种活都能干，但性价比曲线不一样，照着训练的选型去买推理的卡，多半花冤枉钱
成本结构：一次性重投入 vs 按量长期爬坡
训练开销集中在几周到几个月的密集占用，还要加上数据准备、调试重跑和失败试错。具体量级去 训练成本测算页（/compute/training-cost） 和 训练专题（/training） 看当时的测算口径，别拿别人项目里听来的数字套自己。推理开销跟调用量强相关，单价低但持续发生，最容易被低估的是并发峰值时的冗余容量。
| 对比维度 | 训练算力 | 推理算力 |
|---|---|---|
| 开销节奏 | 集中爆发，项目周期内烧完 | 随调用量持续发生 |
| 主要风险 | 中断、重跑、调参试错 | 峰值排队、容量冗余浪费 |
| 低估点 | 数据准备和失败重跑的时间成本 | 为峰值预留的那部分闲置卡 |
| 省钱方向 | 缩短试错周期、减少无效重跑 | 量化、调度、缓存、合理限流 |
判断自己属于哪一类很简单：项目上线后还在持续烧钱的基本是推理账，只在版本迭代那几天烧钱的是训练账。两个都有的团队，就必须分栏记账，否则月底永远说不清钱去哪了。
硬件偏好不一样，别按训练的选型思路买推理的卡
训练偏好高带宽互联和大显存集群，卡间通信往往是瓶颈，所以你看到训练集群动不动就是整机整柜地配。推理更在意显存够不够装权重加 KV 缓存，以及并发下的调度效率，互联带宽的重要性要低一档。
- 推理可以用量化、张量并行、CPU offload 等手段压成本，训练对这些手段的容忍度低得多
- 训练选型先看互联和集群能力，推理选型先看单卡显存和调度软件成熟度
- 加速卡规格差异去 加速卡资料库（/compute/gpus） 对照，别只看算力峰值那一列
- 拿不准就问平台方：这批卡跑推理时的实际并发吞吐是多少，而不是理论峰值多少
一个常见的坑是拿着训练的报价单去谈推理。报价单上的配置、租期、带宽都是按训练场景设计的，直接套到推理上，要么买多了，要么在峰值时被排队拖垮。谈之前先明确自己买的是哪种负载。
扩容方式：训练做加法，推理做弹性
训练扩规模基本靠堆卡和多机并行，前期就要把集群和网络规划好，临时加卡往往因为互联拓扑对不上而白搭。推理可以先按平均并发配卡，再用排队、限流、缓存扛峰值，扩容的颗粒度和响应速度要求都不一样。
- 估平均并发拿过去一段时间的真实请求量除以高峰时段占比，得到一个基线。数据从自己的日志里来，不要拍脑袋
- 算平均并发需要几张卡带着模型和上下文长度去 容量测算页（/compute/sizing） 和 模型部署页（/models/deploy） 跑一遍，看它给的单卡吞吐参考值
- 单独估峰值把峰值并发和平均并发的差额列出来，这部分就是你为弹性付的钱，要么靠预留卡扛，要么靠排队和限流消化
- 验证上线后看真实排队时长和卡利用率，和估算对不上就回去改参数，别让估算停留在纸面
峰值冗余留多少，取决于你能接受多长的排队延迟，没有统一答案。做交互式产品的团队通常容忍度低，做批量离线任务的容忍度高得多，同一个模型在两种业务下的合理配置可能差好几倍。
各自靠什么增长，判断潜力看哪几个信号
训练算力的增长由模型规模、迭代频率和自研需求驱动。头部之外的需求相对集中且波动大，一家公司决定自研就突然要一大批卡，决定改用现成模型这批卡就闲置了，所以训练需求的可预测性差。
推理算力的增长由用户量、调用频次、上下文长度和智能体多轮调用驱动。这几项都是持续放大的变量，尤其是上下文变长和多轮调用，会让单次请求消耗的算力成倍上升，而用户量往往还在同时增长。
| 观察信号 | 去哪看 | 说明什么 |
|---|---|---|
| 租金走势 | 算力价格追踪（/compute/price-index） | 短期供需松紧，反映市场热度 |
| 真实用量结构 | 用量统计（/usage） | 推理和训练的占比变化，比听结论可靠 |
| 平台供给变化 | 算力平台对比（/compute/platforms） | 新平台入场或配置调整，会影响可选方案 |
需要提醒的是，这些信号只反映市场层面的趋势，不等于你所在细分场景的趋势。如果你做的是垂直行业的私有部署，市场租金下降未必能传导到你手上，还要看能不能用公有云资源。
什么情况下这套判断不适用
- 小团队跑开源小模型做内部工具，训练和推理的差别在预算里几乎可以忽略，重点反而是人力成本
- 直接用官方 API 时你只承担推理侧价格，训练成本已经被摊进单价，没必要单独建训练预算模型
- 周期性集中爆发且不可预测的业务，弹性推理的按量单价可能反而不如预留资源划算
- 训练和推理跑在同一批卡上、靠错峰调度的团队，分栏记账的意义会下降，重点变成调度效率
换句话说，这套框架的适用前提是有一定规模、两种负载并存、且真金白银在付算力费。规模不到这个门槛，硬套反而增加管理成本。
落地清单：四步把自己的账对上
- 分栏把过去三个月的算力支出按训练相关和在线服务相关分两栏，先看清楚比例
- 补齐训练隐性成本训练栏里补上数据准备、失败重跑和调参占用的时间成本，不要只算成功那次
- 推理算两遍推理栏按平均并发和峰值并发各算一遍，差额就是你要为弹性付的钱
- 带数字去比方案带着这三组数字去 算力平台对比（/compute/platforms） 和 租卡导购（/compute/gpu-rental） 比方案，别拿训练报价去谈推理
训练是押注，推理是收租：押注看准一次就够，收租要天天算清楚成本。下一步把你自己近期的算力账单按训练和推理分一次栏，然后去站内核对当时的价格与容量参考值，看看估算和真实账单差在哪，这个差额就是你最该优化的地方。→
常见问题
推理算力以后会不会比训练算力消耗更大？
从公开趋势看，在线服务一旦铺开，用量是持续累积的，而训练是间歇性的。但具体谁更大取决于业务形态：纯 API 转售的团队基本只有推理账，做基础模型自研的团队训练占比会高很多。别拿行业结论套自己，先按上面清单把自己的两栏数字分出来。
同一张卡既跑训练又跑推理行不行？
技术上可行，但排期和显存分配会互相打架，训练任务长时间占卡会让在线服务的容量变得不可控。常见做法是把推理和训练分池，或者训完之后把卡整体转成推理资源。要不要分池，看你对在线服务可用性的容忍度。
想估算推理成本，最该先搞清哪个量？
先搞清你的平均和峰值并发，以及单次请求的输入输出长度。这两组数字决定了显存占用和卡数，比单价更能左右总成本。可以用 /tools/token-price-calculator 和 /tools/model-cost-calculator 先跑一遍量级，再拿结果去 /inference 比对不同渠道的报价口径。
训练成本是不是只算卡时就行？
不是。卡时只是显性部分，数据清洗标注、实验失败重跑、环境调试和人工排障经常占掉相当比例。做预算时建议在卡时之外留一块试错预算，具体比例按团队经验定，然后到 /compute/tco 把买卡和租卡两条路各算一遍三年账。
推理算力增长对普通团队意味着什么？
意味着单价会继续波动，选型空间也更大。对用量稳定的团队，可以用预留或包年压单价；用量波动大的，优先保住弹性而不是最低单价。跟价的方法很简单，隔一段时间去 /price-watch 和 /compute/price-index 看一眼趋势，别签长约时才第一次比价。
