把零散的商品摘要放进同一次请求

§ 先看每次请求里重复的部分

假设你有几十条商品介绍，需要把每条压缩成一句摘要。最直接的做法是：读取一条，发送一次请求，保存结果，再处理下一条。这个流程容易理解，但每次都要重复发送任务说明、建立请求并等待响应。单条任务越短，这些固定开销就越显眼。

合批的思路很简单：把几条独立任务放进同一次请求，让模型一次返回多条结果。它适合摘要、分类、信息提取等规则相同、输入较短的工作。重点不是把所有内容塞进去，而是减少不必要的重复。

合批是一次请求处理多条数据；并发是同时发送多个请求。并发可以缩短整批任务的等待时间，但通常不会减少请求数量，也不会消除重复的提示词。两者可以结合使用，不过刚开始时，先把一种方式做稳定更容易排查问题。

这里讨论的是在应用中组织多条输入，不是某个专用的异步批处理接口。通过 Vana API 使用熟悉的 OpenAI 兼容调用方式时，可以在一条消息中写入共享规则和多条待处理内容。不要因此假定存在额外的批量折扣或专门的批处理端点。

例如，先把三条商品介绍分别标为“商品甲”“商品乙”和“商品丙”，再写一份共同指令：每条生成一句摘要，不补充原文没有的信息，逐条返回编号和摘要。共享规则只写一次，每条输入的边界则要清楚。

不要只靠返回顺序对应结果。模型可能漏掉一项或调整顺序。有编号之后，程序才能发现缺失项，并只对这些项目重新发起请求。

第一次可以每批放五条，观察响应时间和结果完整性，再逐步调整。这个数量只是测试起点，不是固定建议。商品介绍长短不同、输出要求不同，合适的批次也会不同。

批次大小还受模型上下文和输出长度限制。输入放得下，不代表输出一定能完整返回。如果响应被截断，先缩小批次，或者减少每条摘要的长度要求。不要为了少发几次请求，让一次失败牵连大量数据。

合批可以减少重复的任务说明、网络往返和应用处理请求的次数。不过，每条商品介绍仍需要被读取，每条摘要仍需要被生成，因此总令牌数不会按请求数量等比例下降。编号和输出格式本身也会占用一些令牌。

Vana API 按实际令牌计费，没有月费。判断合批是否划算，应比较相同任务的实际令牌用量、总耗时和重试次数，而不只是看请求数。可以先创建一个 Vana API 账户，用少量样本记录合批前后的表现，再决定是否扩大使用。

一次请求失败，整批结果都可能暂时拿不到。应用应保留原始输入，记录已完成的编号，并只重试未通过检查的项目。如果返回结果会触发后续操作，还要防止重试造成重复写入。

合批也需要等待任务凑齐。后台整理商品资料通常能接受，正在等答案的用户则未必愿意。因此，可以同时设置数量上限和等待上限：数量够了就发送，等到期限也发送，不必每次都凑满。

选同一组样本，分别测试逐条发送和小批次发送，记录总耗时、令牌用量、缺失结果和重试情况。只有当质量保持稳定、整体开销确实降低时，合批才值得保留。一个容易检查、能够恢复的小批次，往往比一次装下全部任务更实用。