Serverless 推理成本分析：波动负载如何选型
用启动、活跃计算、空闲等待和缩到零条件拆解 Serverless 推理费用，并按波动负载的服务目标比较 RunPod、Modal 与 Replicate 的计费路径。
算力租赁的 Serverless 推理不能只比 GPU 单价；应把启动、活跃计算、请求后等待和缩到零前分别计价。波动负载的选型顺序，是先确认服务目标能否接受冷启动，再按各平台的真实计费段计算月成本，最后用账单逐项校验。下面按 RunPod、Modal 和 Replicate 的文档口径给出可填数的比较方法。
先统一成本口径
先记录每次请求的开始、输入结束、输出结束和下一次请求时间，再从自己的报价或账单抄录启动、活跃、空闲、资源请求及“其他费用”。这些时间用于识别计费段，不等于供应商一定会全部收费。
单一费率且各次用量相同时，可用下面的方法估算：
RATE = YOUR_VALUE
BILLABLE_VALUE = YOUR_VALUE
REQUESTS_PER_MONTH = YOUR_VALUE
OTHER_COST = YOUR_VALUE
RUN_COST = RATE × BILLABLE_VALUE
MONTHLY_TOTAL = RUN_COST × REQUESTS_PER_MONTH + OTHER_COST
COST_PER_REQUEST = MONTHLY_TOTAL / REQUESTS_PER_MONTH
按时间计费时，把 BILLABLE_VALUE 填为实际计费秒数；按输出指标计费时，填为对应的计费数量。如果不同请求使用不同费率或资源组合，直接汇总账单各行金额，不要强套统一公式。
RunPod Serverless：把启动和保底空闲算进去
RunPod 的 Serverless 定价说明规定，费用从 worker 启动持续到完全停止，按秒计费并向上取整。可计费时间包括容器初始化与模型加载、请求执行，以及请求完成后的 idle timeout。因此，模型加载慢或请求间隔较长时，只计算 token 生成时间会低估费用。
按照 RunPod 的 Serverless workers 概览，Active workers 持续运行，Flex workers 则按需求扩缩，在空闲时缩到零且不产生使用费用，但扩容会带来 cold start。两者对应不同的成本取舍：不能接受冷启动时，应把常驻 worker 的空闲时间作为基线成本；可以等待启动时，则要同时计算启动次数和归零前后的等待时间。
账户侧也要单独核对。RunPod 的 Billing overview把近期支出放在 Billing 页面的 Billing Explorer，并说明 network volume 在 Pod 停止后仍会继续累计存储费用。若方案还使用 Pod 或持久存储，应把这项列入 OTHER_COST；该页同时说明数据传输不收费。
Modal：保活窗口和资源请求要一起算
Modal 定价页说明，CPU、内存和 GPU 的包含用量按秒计量；应用加载、输入处理以及最后一次输入后的默认保活窗口都会计费，应用缩到零后则不再收费。对于 CPU 和内存，计费依据是请求量与实际用量中的较高者。
因此，不能只拿 GPU 使用时间比较。资源请求长期高于实际用量时，应按较高值估算；请求间隔很短时，还要检查这些请求是否落在同一保活窗口内。保活结束后缩到零的成本才停止，这项条件必须与冷启动容忍度一起判断。
Replicate：先确认模型属于哪种计费路径
根据 Replicate 计费文档，public model 只对处理请求的 active time 收费，setup 和 idle 免费；默认使用与其他客户共享的 hardware pool，请求会进入共享队列。请求出现空档时，实例可能先保持 idle，而不是立即关闭。
大多数 private models 使用 dedicated hardware，不需要共享队列，但 setup、idle 和 active 的全部在线时间都收费。Deployments 也按全部在线时间计费；fast-booting fine-tunes 是例外，只对 active time 收费。因此，独占硬件或队列条件属于服务要求，不能只比较 active 单价。
若模型归入 Official Models，还要采用另一套口径。Replicate 的 Official Models 文档说明，这些模型可按输出图像、视频秒数、输入和输出 token 等指标计价。此时应使用“指标费率 × 输出数量”，不能直接套用运行时长公式。
波动负载如何落到选择条件
做算力租赁选型时，先填写服务目标，再填写费用；不满足响应、队列或冷启动硬条件的候选应先排除。
- 在各 provider 自己的 pricing、billing、model 或 endpoint 页面确认模型类别、资源类型、计费单位、保活设置和缩零条件。
- 把适用的费用行加入
OTHER_COST或总成本：启动与模型加载、输入处理、空闲或保活、请求量与实际用量差异、存储，以及账单实际列出的其他项目。 - 分开记录低谷基线、高峰并发和请求间隔。平均值会掩盖短时突发，不能用它代替峰值条件。
- 先算满足服务目标的候选，再比较
MONTHLY_TOTAL和COST_PER_REQUEST；官方页面或报价没有写明的费率与条件，应向 provider 确认，不自行填入假设值。
上线前如何核对
完成估算后，用完整账期的账单逐行校验。优先排查四类遗漏：只算 active time、把 idle 一律视为免费、假设缩到零立即发生，以及把按输出指标计费的模型套入时长公式。
若公式结果与账单不一致，先用实际行项目金额替换估算值，再核对资源类型、保活窗口和账单中的其他项目。provider 当前文档没有说明的项目，应以书面报价或答复为准。
本文步骤依据正文所链接的官方文档整理，使用前应核对当前版本。