小模型推理别只看吞吐，先把超时的请求扣掉
内容提要
文章讨论小参数语言模型在搜推场景的推理优化，核心是在延迟约束下追求有效吞吐，而非单纯追求吞吐数字。压测应将超时请求计为失败，明确端到端延迟预算并区分排队与计算耗时；合批需权衡等待成本，压测应贴近真实请求分布并关注尾部延迟。工程上应设置调用超时、及时停止过期任务、限制重试并演练降级，通过小流量对照验证质量与资源消耗。
延伸解读
吞吐数字的统计口径决定容量判断
文章指出，若压测把超时请求仍计为完成，吞吐数字会虚高。在线服务中，请求一旦越过业务截止时间，即使模型随后生成完毕，调用方可能已走降级，这次完成对用户体验没有价值。因此容量规划应基于约定延迟内满足质量要求的有效请求数，而非服务端完成计数。否则设备利用率看似提升，实际可交付能力却被高估，导致扩容决策偏乐观。
合批的等待成本容易被平均延迟掩盖
合并请求能改善计算资源效率，但凑批本身消耗时间。低峰时固定等待可能白白花掉延迟预算，突增时过长队列又让请求在计算前就失去价值。只看平均延迟很难发现这两种情况。压测应使用可重放的真实请求分布，分别观察稳定负载与短时突发下的尾部延迟，并统计超时和主动拒绝。若优化只是让失败请求在队列里待更久，图表平滑了，用户并未受益。
降级入口和重试边界要先于扩容讨论
文章建议先把推理做成可替换依赖：调用方设明确超时，服务端在截止时间已过后停止无用工作，降级路径经过演练。重试不能无限叠加，否则一次拥塞会放大成更多推理任务，挤压正常请求。是否取消任务、是否允许重试应按业务语义决定。上线时让少量真实请求走新路径并与原方案对照，除接口延迟外，还要看业务可接受的输出质量和单个有效请求的资源消耗。
Q&A
小模型推理优化中，为什么不能只看吞吐量？
因为在线服务中，请求迟到后即使吞吐数字再高也无法挽回用户体验。压测时若将超时请求计为成功，会导致容量规划偏乐观。更合适的口径是在约定延迟内满足质量要求的有效吞吐。
在搜推场景下，如何合理分配端到端延迟预算？
不能把整个接口的延迟预算都交给推理服务。应先明确入口到出口的总预算，再给模型分配其中一部分，并记录排队与计算各花了多久，避免把排队误判为模型变慢。
合批（batching）优化可能带来哪些问题？
合批能改善计算资源使用效率，但等待凑批需要时间。低峰时固定等待会浪费预算；流量突增时过长等待队列会让请求在计算前就失去价值。只看平均延迟难以发现这些问题。
压测小模型推理服务时应该注意什么？
压测应贴近真实请求分布，而非连续灌入相同输入。需考虑输入长短、生成长度和突发流量对队列的影响。可固定一组可重放请求，分别观察稳定负载与短时突发时的尾部延迟，统计超时和主动拒绝。
工程上如何设置超时、重试和降级来保障推理服务稳定性？
调用方应有明确超时，服务端在截止时间已过时停止无用工作，降级路径要经过演练。重试不能无限叠加，否则一次拥塞会变成更多推理任务，挤压正常请求。是否取消任务、是否允许重试应按业务语义决定。
上线新的推理优化方案时，如何验证效果？
可以让少量真实请求走新路径，并与原有方案对照。对照项除接口延迟外，还应包括业务可接受的输出质量以及单个有效请求的资源消耗。用自身流量做可重复实验比照搬他人配置更可靠。
