批量推理跑了一周，实时调用那套我先停了

作为一个没碰过批量推理的人，我试了一下 Together AI 的 Batch Inference。名字听着唬人，其实就是把一堆请求攒起来一次性丢过去，让它慢慢跑，跑完给你结果。跟实时调用是两个路子。

第一天，开通没什么门槛，注册、拿 API key，跟别的推理服务差不多。真正卡住我的是格式。批量推理不吃你随手拼的 JSON 数组，它要 JSONL，就是一行一条请求的那种文件。我第一版把整个列表塞成一个大 JSON，提交上去直接报错，也没告诉我是哪一行的问题，翻了半天文档才反应过来。改对之后提交，任务进队列，然后就是等。它不是同步返回的，提交完只能轮询状态，或者等它给你一个结果文件。第一天我就栽在这上面，盯着屏幕以为会像实时接口那样几秒钟吐字，结果什么都没有。

第三天，量上来了，才体会到它省在哪。逐条调用慢，慢的不全是模型推理本身。每条请求从服务发出去，要建连接、握手、鉴权、序列化、等响应、反序列化，这一串重复开销在量小的时候看不出来，量一大就很可观。批量把这一层摊薄了。我这边测下来，同样的活，批量跑完的时间比逐条轮着发要短，成本那栏也好看不少。

不过它也挑数据。有一批里混了几条格式不对的，整批结果就残缺，得回头把脏数据挑出来重跑。前两天翻到一篇讲跨供应商批处理的文章，里面有句话我记下来了。

可以在应用编排层把不同模型供应商的请求收进同一套批处理管道里并行执行，而不是让每一条请求各自为战。

我还没到那个复杂度，但思路是对的。批处理的收益，一大半来自前面的整理。

一周后，我把周期性的活都挪过来了，夜间跑的报表、历史数据回填，这些对延迟不敏感的，扔进去就不用管。实时接口只留着对话那类要即时响应的。

两种用法摆一起看。

	实时调用	批量推理
返回方式	同步，秒级	异步，提交后轮询
吞吐	受并发限制	攒批后明显更高
成本	单价高	单位成本低
适合	对话、交互	报表、回填、评测

适合的是手里有周期性、大批量、对延迟不敏感的推理任务，而且数据本身规整的团队。要做实时对话的、任务量小到不值得搭一套提交流程的，还有数据很脏又不想先清洗的，就别折腾了。我第一天那种随手丢个数组进去的用法，基本是白折腾。

往后看，我猜批量推理会从省钱的备选变成默认路径。实时推理留给交互，剩下的训练后数据生成、评测、报表这类活，会越来越多地走异步批处理。到那时候，会不会用批处理，可能比选哪个模型还影响账单。