一句话定义：微批（Micro-batching）是一种在线推理调度策略：系统不会把每个请求单独送进模型，而是把极短时间窗口（通常是毫秒级）内到达的若干请求暂存成一小批，合并成一次计算，算完再拆开分别返回给各自的用户。
为什么这样做：GPU 很像一部电梯。一次只载一个人，确实到得快，但电梯的启动、运行、停靠成本一样都省不掉，一天下来运不了多少人；如果电梯门多开几毫秒，等三五个人一起走，总运力就能翻好几倍。GPU 也是同理：一次前向计算里，权重从显存读一遍、内核（kernel）启动一次，这些固定开销不会因为批大小为 1 就消失。把 8 个请求拼成一批，耗时不一定是 8 倍，往往只多一点点。于是单位时间处理的 token 变多，摊到每个 token 上的成本就降下来了，这就是吞吐提升的来源。
代价也很明确：延迟。请求进来后要先在队列里等一个窗口；凑不够人时还要等超时；批次里长短不一的请求得对齐（padding），短请求陪长请求一起算完。用户能感知到的就是“首字之前那一下停顿”变长了，首 token 延迟（TTFT，Time To First AI 词典：Token">Token）上升，还会出现长尾：一批里最慢的那个决定整批的完成时间。业界的应对办法是动态批处理（continuous batching）：不等整批做完，谁先算完谁先走，空出的位置立刻补进新请求，把“等”压缩到最小。
跟相邻概念的区别：微批容易和离线批处理（batch inference）混为一谈，其实定位完全不同。
| 单请求直通 | 微批 | 离线大批量 | |
|---|---|---|---|
| 攒批窗口 | 无 | 毫秒级 | 分钟级甚至更久 |
| 主要目标 | 最低单请求延迟 | 吞吐与延迟折中 | 最大吞吐、最低单位成本 |
| 典型场景 | 实时对话 | 在线 API 服务 | 数据标注、批量摘要 |
另外，流式输出（streaming）解决的是“结果怎么一点点吐给用户”，属于返回方式；量化（quantization）、蒸馏（distillation）解决的是“模型本身怎么变小”，属于模型压缩。它们和微批不是同一层面的东西。
对从业者的意义：批大小上限和最大等待时间，是在线推理服务里最值得反复调的两个参数。延迟敏感的产品（语音、实时补全）窗口要压到很小；后台任务可以放大。监控上不能只看平均延迟，要盯 TTFT 和 TPOT 的分位数。
对普通人的意义：你感到的“AI 想了半秒才开口”，有一部分就来自这里；而批量接口通常更便宜，也是同一笔账——你用等待换了成本。具体规则各家不同，以官方页面为准。