按截止时间计价的 AI 推理
开发者提交可延迟的 AI 批处理任务和截止时间，服务等待低价算力并在期限内交付结果。
离线评测、商品分类、历史数据回填这类任务，常常不需要几秒钟返回结果。开发者创建任务时填写最低可接受的模型能力、预算上限、输入规模和最晚交付时间，再上传数据或接入对象存储。提交成功后，页面先给出最高可能花费、预计完成区间与可取消条件。
调度层不在收到任务时立刻购买昂贵的即时算力。它持续比较多家模型供应商的闲置容量、批处理价格和排队情况，把任务拆成可独立完成的小批次。低价资源出现时自动投递，某个供应商中断则从最近检查点转给另一家，避免整批重跑。
开发者获得统一格式的输出、每个批次实际使用的模型和费用明细。若临近截止时间仍未完成，系统会按照预先同意的升级规则提高预算，或提前通知任务可能无法按时交付，而不是悄悄换成质量更低的模型。
首版专注无状态的文本批处理与评测任务，提供 API、对象存储输入和检查点恢复。它不适合客服对话或实时代理；它服务的是愿意把等待时间换成成本下降的工程团队。
为什么是现在
8月17日，一条 X 帖直接提议用更慢的最佳模型换取极低价格。截至8月20日，该帖发布后累计为点赞 101 / 转发 5 / 浏览 21489，使离线任务的速度与成本取舍进入公开讨论。S1
目标用户
目标用户是已有稳定离线任务的 AI 工程团队。典型时刻是夜间评测、历史数据回填或批量分类上线前。任务结果要在次日或发布节点前拿到，却不值得持续占用即时推理额度。团队愿意等待，也能明确允许的模型范围。此时预算上限、交付期限和失败恢复，比单次响应速度更重要。
最小切入点
首版接入两家已有批处理接口，不自建推理集群。任务拆成带稳定编号的 JSONL 小批次，状态存入关系数据库。输入和结果通过客户对象存储交换，避免长期托管原始数据。调度器维护价格表、剩余时间和已完成分片。失败后只重投未确认完成的编号，并用幂等键防止重复入账。模型能力不做抽象评分，先由客户指定可接受模型清单。临近截止时间时，只按预先批准的预算阶梯升级。
以小博大
第一批用户可从开源评测框架和数据处理流水线中获得。做一个命令行工具与 GitHub Action，让夜间回归评测直接提交截止时间。公开展示同一批任务在即时接口、原生批处理和调度服务中的实际账单。案例应保留模型、输入规模和等待时长，方便工程团队复算。由此切入已有离线任务，比教育用户创造新工作流更直接。
竞品与缝隙
- Gemini Flex 与 Gemini BatchGoogle
- Gemini Flex 已把低优先级容量做成正式服务层。它面向后台任务，目标延迟为 1–15 分钟，价格为标准层的 50%。容量紧张时可能返回错误，重试和超时由客户端处理。系统也不会自动升级到标准层。S2 Gemini Batch 则面向非紧急的大批量任务，目标在 24 小时内完成。S2 这两种方式已经覆盖“便宜一些、允许等待”的核心诉求。缝隙在于它们都围绕单一供应商运行，也没有让用户填写任意截止时间。产品若能统一管理跨供应商分片、检查点和预算升级，才会形成独立价值。否则它只是给现有接口再包一层队列。
- OpenAI Batch API 与 Amazon Bedrock Batch InferenceGoogle
- OpenAI Batch API 已提供异步批量请求，并以固定完成周期交付。S3 Amazon Bedrock Batch Inference 支持从 S3 读取 JSONL，再把结果写回 S3。它还提供停止任务、状态查询和完成通知。S4 对已经锁定模型或云平台的团队，这些原生能力更短、更容易采购。它们的不足是任务通常先绑定供应商和模型，用户仍要自行比较价格、处理失败批次，并统一不同输出格式。按截止时间计价的服务可以承担这层调度工作。不过跨平台重投会引入输出差异、数据权限和重复计费问题。只有费用明细与恢复行为足够透明，团队才会放弃原生批处理。
怎么赚钱
按实际推理费用加收固定比例的调度服务费。取消任务只收已发生的模型费用与少量任务费。团队版按月收费，增加预算审批、审计导出和私有存储接入。
反方视角
跨供应商模型很难用一个能力等级准确替代。相同提示在不同模型上可能改变标签分布，导致回填数据前后不一致。客户必须先提供验收集，否则调度器无法证明低价路线仍满足质量要求。任务迁移还涉及对象存储权限、数据驻留和供应商条款。检查点不严谨会造成重复请求与重复收费。截止时间承诺又要求预留昂贵容量，会吞掉低价调度的利润。若多数客户直接使用原生批处理，额外平台费也很难成立。