这篇文章说明怎样识别这类任务，以及在排队型算力上怎样保证中断后不丢进度。
01 先区分实时和批量
有人在等的，比如对话和即时搜索，必须走即时资源。后台批量的，比如当天处理完即可的数据清洗，适合排队型算力。
只有后者适合放到排队档。
02 排队档为什么便宜
SpareHive 首页提到，供给来自中国的空闲消费级 GPU，那里的电价明显低于美国和欧洲。该站的说法是，这个电价差是它能压低价格的原因，并且是待私测验证的假设，不是已经实现的利润。
排队档便宜，代价是机器可能被中断，需要能恢复。
03 任务要能断点续跑
把批量任务拆成小批次，每批的输入和输出都落盘。中断后，只重跑没有完成的批次。
没有这一层，中断一次就可能白跑很久，省下的钱会被浪费掉。
04 按批次记录成本
每批记录开始时间、结束时间、处理的 token 数和实际花费，算出每百万 token 的成本。用这个数字和 API 的平均价格对比，判断排队档是否真的划算，而不是只看标价。
05 不适合排队的任务
线上对话、需要即时反馈的客服、有时限的交付，都不能排队。把这些任务放进排队档，省下的钱不值得你承担的延误。
如果你的批量任务需要稳定的算力，可以在 SpareHive 提交需求，由平台人工匹配，但要先问清楚对方的可用时段和中断规则。