小模型推理别只看吞吐，先把超时的请求扣掉
美团技术团队近期公开了一篇 SLM 推理工程文章，摘要把问题落在延迟约束下的有效吞吐，并说明面向搜推场景的小参数语言模型。这个切口很实在。在线服务不会因为设备很忙就认定系统表现良好，请求迟到以后，再漂亮的吞吐数字也救不回这次用户体验。基于公开摘要可见，文章讨论的是工程落地，而不是单靠增大模型来解决问题。
吞吐数字先问怎么算的
我会先问压测报告有没有把超时请求算成成功。一个请求已经越过业务截止时间，模型随后完成生成，服务端计数器仍可能增加一次完成量。设备利用率上去了，调用方却已经走了降级逻辑。把这种完成量直接当作可交付能力，容量规划就会偏乐观。更合适的口径是，在约定延迟内满足质量要求的请求究竟有多少。
搜推链路尤其容易遇到这个矛盾。模型只是链路中的一环，前面可能有召回，后面还要排序、拼装和网络传输。不能把整个接口的延迟预算都交给推理服务。实际接入时，我会先明确入口到出口的预算，再给模型分配其中一部分，并记录排队与计算各花了多久，否则定位时很容易把排队误判成模型变慢。
批次变大，也可能只是队伍变长
合并请求通常能改善计算资源的使用效率，但等待凑批同样需要时间。这是通用工程取舍，不代表公开摘要已经给出了某种具体实现。低峰流量下，固定等待可能白白消耗预算；流量突增时，过长的等待队列又会让请求在开始计算前就失去价值。只看平均延迟，很难发现这两种情况。
压测应该贴近请求分布，而不只是连续灌入形状相同的输入。输入长短、生成长度和突发流量都会影响队列。可以先固定一组可重放请求，分别观察稳定负载与短时突发时的尾部延迟，统计超时和主动拒绝。若某次优化只是把失败请求留在队列里更久，图表会更平滑，用户并没有得到好处。
先留住一个能关掉模型的入口
对小团队来说，我更愿意先把推理变成一个可替换的依赖。调用方应有明确超时，服务端在截止时间已过时停止无用工作，降级路径也要经过演练。重试不能无限叠加，否则一次拥塞会变成更多推理任务，反过来挤压正常请求。是否取消任务、是否允许重试，应按业务语义决定。
上线时可以让少量真实请求走新路径，并和原有方案对照。对照项除了接口延迟，还应包括业务可接受的输出质量以及单个有效请求的资源消耗。摘要没有披露可直接照搬的具体配置，因此没必要编一个推荐批次大小。拿自己的流量做一轮可重复实验，比照着别人的硬件利用率设置参数更可靠。
小模型值得关注，但它不是给失控队列兜底的工具。如果我负责接入，会先做出一份能区分按时完成、迟到和降级的报表，再讨论扩大并发。这样优化得到的容量才是业务能用上的容量，而不是监控面板上看起来热闹的数字。
本文由本站基于公开热点摘要整理和原创分析生成。来源：SLM 生成式高并发推理引擎：延迟约束下的有效吞吐优化。本文为缺失任务的补写，保留实际发布时刻。
