推理的并发模型是怎么选的？每一步都讲透

大模型推理有个反直觉的现象：同一台机器，调度方式不同，吞吐量能差出数倍。餐厅是现成的类比——一张桌子只坐一位客人，翻台率低；合理拼桌，同样面积接待更多食客。推理的并发模型研究的正是怎么「拼桌」：让有限的算力尽可能同时服务更多请求，又不让任何一位客人等太久。

先带走一个判断：并发选型的核心矛盾是吞吐与时延的拉锯。吞吐优先的方案让整体产出最大化，时延优先的方案让每个请求最快得到响应，两者不可能同时到顶，选型就是把这条线画在业务最需要的位置。

并发问题的实质

生成式推理的特别之处在于：一次请求要算很多步，每步生成一个片段，算力在步与步之间存在空隙。并发模型的本质是填空——在 A 请求等待的空隙里塞进 B、C 请求的计算。进来的东西是排队请求，发生的事是调度器决定谁和谁一起算、每步怎么切换，出去的是各自的结果流。空隙填得越满，算力利用率越高，但排队结构也越复杂，这是所有并发设计的出发点。还有一个实务提醒：并发参数变更要小步走，每次只动一个参数并观察一个完整周期，多个参数一起调，效果归因会很困难。

批处理与流式怎么折中

批处理把多个请求凑成一组同时计算，吞吐高，但组里最慢的请求会拖住整批，时延波动大。流式则是每生成一段就立即推送，用户体验好——豆包、Kimi 这类对话产品的打字机效果就来自流式输出。工程上的折中是动态组批：请求到达后只等一个极短的凑批窗口，凑满即走，不等满员；窗口大小直接在吞吐与时延之间做取舍，参数以压测数据为准，不做拍脑袋设定。

三种走法在吞吐与时延上的位置不同，摆在一起看得更清。

组批窗口过大还会放大超时问题，超时参数与重试怎么配合，见服务端的超时是怎么处理的？内部门道在这。

队列与排队时延

有并发就有排队。排队时延是请求从到达算起、到真正开始计算的时间，它是用户感知「变慢了」的主要成分之一。观察排队时延要看分布而非均值：多数请求几乎不排队的系统，也可能存在少数请求排长队，长尾恰恰是投诉的来源，把分位数曲线放进容量评审，比单看平均等待靠谱得多。队列设计有两个关键点：优先级，比如付费流量与内部任务分队列，避免互相拖累；长度上限，队列排太长时与其让用户无限等，不如快速返回「稍后再试」，把选择权交回客户端。限流正是控制队列入口的闸门，分层做法见限流的配置分几层？全局与按用户。

选型时的三个观察点

• 请求长度分布：长短请求混跑时，动态组批明显优于静态凑批，按业务分布选策略。
• 时延敏感度：交互式对话对首字时延敏感，离线批任务只看总产出，敏感度不同选型不同。
• 硬件特性：不同推理卡的批量增益差异明显，选型结论要落在实测数据上，不跨硬件套用。

边缘侧硬件的并发增益更特殊，小设备上组批可能得不偿失，见边缘设备的算力约束是怎么应对的？；整机交付形态下并发档位出厂已标定，见一体机里面的配置是什么？从原理到落地。

并发选型速查表

• 核心矛盾：吞吐与时延此消彼长，按业务画线
• 主流折中：动态组批 + 短凑批窗口
• 队列两件套：分优先级、设长度上限
• 验收方式：真实流量画像压测，不跨硬件套结论

聊聊推理并发的常见疑问

• 并发数调得越高越好吗？：超过硬件甜点后时延急剧恶化，吞吐反而下滑，找到拐点就停手。
• 流式输出会降低吞吐吗？：会带来少量开销，但换来感知时延大幅下降，交互场景几乎都值得。
• 为什么别人的压测数据我复现不了？：并发结果强依赖请求长度分布与硬件，脱离这两者谈数字没有意义。