手头有一万条文本要处理，是立刻调通义千问的实时接口一条条跑，还是交给批量通道慢慢处理？先把判断标准放前面：用户在等，用实时；用户不等，用批量。接口形态的差别本质上只有一个字——急不急，但由此延伸出的价格、时限、错误处理全都不同。
实时接口：一问一答马上回
实时接口为「人在等」设计：请求发出，结果秒级返回，对话式产品、在线客服、智能助手的每一次点击都走这条路。它的价值是响应速度，代价是单位消耗高——为了随叫随到，服务方要常年保留足量算力待命，这份待命成本摊进了每一次调用的单价里。
批量接口：攒一批再统一跑
批量接口为「结果不急」设计：你把成千上万条任务提交上去，服务在空闲时段统一调度，几小时内甚至隔天给出结果，单价通常明显更低。离线翻译库、历史资料摘要、夜间跑评测集，都是典型用户。它的代价是时效失控感——任务何时完成不完全由你决定，急件千万别往这里塞。
批量的低价还有一层来源值得知道：削峰填谷。服务方把大量不急的任务挪到深夜等空闲时段执行，把白天宝贵的算力留给实时请求，资源的利用率提高了，省下的钱让利给愿意等的人。这不是低人一等的通道，而是资源调度的智慧，理解了这一点，就更懂得给它派对任务。
差异维度：时效与价格
- 响应时间：实时按秒计，批量按小时甚至按天计。
- 单位消耗：批量普遍更便宜，量大时差距可观。
- 失败处理：实时当场报错当场重试，批量通常整批跑完再看清单。
- 使用姿势：实时适合交互链路，批量适合队列与定时任务。
时效、单价、失败处理之外，把典型任务也放进来。
| 维度 | 实时接口 | 批量接口 |
|---|---|---|
| 响应时间 | 秒级返回，为「人在等」设计 | 几小时甚至隔天，为「结果不急」设计 |
| 单位消耗 | 高，常年留足算力待命的成本摊进单价 | 明显更低，靠削峰填谷把任务挪到空闲时段 |
| 失败处理 | 当场报错当场重试 | 整批跑完再看清单 |
| 典型任务 | 对话式产品、在线客服、智能助手的每次点击 | 离线翻译库、历史资料摘要、夜间跑评测集 |
| 派活边界 | 急件、格式还没验证过的任务，先在这条跑通 | 三连问全过才放心走，有截止时间要先算延误代价 |
判断一个任务走哪条通道，可以用三连问收口：结果晚到半天，业务受影响吗？任务格式经过小样本验证吗？失败条目有补跑安排吗？三问全过，放心走批量；任何一问含糊，先走实时把效果跑通，再谈省消耗的事。顺序反过来的人，大多在返工里把省下的钱赔回去了。
顺带纠正一个相关误解：有人因为批量单价低就认为「攒着一起跑永远划算」，其实任务有截止时间时，批量延误的隐性代价可能吃掉全部价差，这类误区的更多变体在「上下文加倍速度就减半」错在哪所在的系列里逐条拆过。
选型速查
- 界面上的按钮、聊天的回复：实时接口。
- 夜里跑、明早看：批量接口。
- 不确定急不急：先实时验证效果，再批量放大。
放进整体架构看
一个成熟应用往往两者并用：用户交互层全部实时，数据加工层全部批量，互不越界。与实时链路强相关的上下文策略见单轮长问和多轮短问差在哪；批量任务若要一次给全结果或分段交付，参考一次性回答和分步回答有什么区别；当应用需要按任务特点挑选模型时，分发逻辑见模型路由和多模型聚合有什么区别；批量任务跑长上下文时的性能表现，上下文窗口和检索窗口有什么区别补充了窗口层面的背景。
一句口诀带走：急件走实时，慢活走批量，用对通道等于直接降消耗。
通道选择每季度复盘一次，用量结构变了，答案也会跟着变；把复盘结论写进团队的接入手册，新人不必重新踩坑。Kimi 等多数主流产品同时提供两种通道，先用小批量试水再放量，切换成本低，值得各试一遍。
聊聊批量接口和实时接口的常见疑问
- 批量任务能插队吗？：多数服务不支持插队，急件应改走实时通道。
- 批量结果质量会打折扣吗？：同一模型同一参数，结果口径一致，差别只在交付时间。
- 小批量值得用批量通道吗？：几十条以内省得有限，权衡提交管理的麻烦再决定。
