AI芯片小批量为何算不快？流水气泡怎么填？

模型并不轻，单次推理却总跑不出预期吞吐，这种问题在小批量场景尤其常见。AI芯片面对在线推理、实时控制或多租户请求时，最难受的往往不是峰值算力不够，而是流水线永远没被真正填满。

小 batch 的第一层损失来自固定开销占比被放大。内核启动、DMA 编程、地址重定位、同步栏和结果回传这些步骤，无论批量大还是小都要做一遍。批量一缩，真正用于有效矩阵计算的时间占比迅速下降，看起来阵列很强，实际大量周期都在为下一口小任务做准备。

流水气泡则是第二个更伤持续吞吐的瓶颈。前端搬运、主阵列计算和后端回写若不能稳定重叠，任何一级稍微短一点或长一点，都会在相邻阶段之间留下空档。大 batch 时，这些空档能被长时间计算自然摊薄；小 batch 时，单个 tile 本来就短，任何一点不对齐都会变成肉眼可见的气泡。

很多实现把问题归咎于算子太碎，其实更常见的是分块粒度不对。tile 做得太大，小 batch 下只能开出很少并发实例，阵列边角浪费严重；tile 做得太小，启动和同步又把收益吃回去。真正有效的粒度，往往要同时让阵列、片上缓存和 DMA 队列都能并行驻留，而不是只对某一级资源看起来整齐。

对AI芯片在线场景来说，微批合并是把双刃剑。把邻近请求拼成更大的批量，确实能抬高利用率，但合并窗口一长，尾延迟立刻变坏；窗口太短，又拼不出足够大的批量。系统必须明确吞吐和时延谁是硬约束，再决定是优先多开并发流、做轻量微批，还是让单流尽可能吃满阵列。

双缓冲也需要围着小任务重排。很多离线训练中好用的预取深度，到了在线推理会因为任务太短而来不及启动；有些缓冲区刚装满，前一个任务就已经算完。更稳妥的办法，是缩小某些缓冲粒度并减少不必要的同步，让搬运尽早介入，而不是照搬大 batch 时的深流水模板。

定位小 batch 低效时，需要把启动时间、前后级重叠比例、阵列活跃占空比和尾块填充损失一并拆开。只要这些时间账摊平，就能判断到底是启动开销太大、tile 太粗，还是流水级之间根本没真正接起来。

运行时队列策略也会直接影响结果。若短请求和长请求混排在同一执行流里，后面的短任务很容易被前面的长任务拖住，外部看起来像芯片对小 batch 不友好，实际是排队策略先放大了气泡。若再叠加严格 SLA，请求为了守尾延迟还会被迫更早截断合批窗口，固定开销占比随之继续上升。跨请求预取若做不好，气泡还会沿队列继续传递，最终把局部短板放大成整段服务抖动，长短请求混部时尤甚。把请求按形状或预计时长做轻度分流，通常能先换回一截可观的利用率。

所以，小批量算不快，往往不是模型太碎，而是固定开销和流水气泡把阵列时间切得太散。把分块、预取和合并窗口围着真实时延目标重排，在线吞吐才会开始像样。