SLM 生成式高并发推理引擎：延迟约束下的有效吞吐优化

搜索和推荐场景中想要使用语言模型提高在线效果，往往面临着在线极低延迟的约束，现有通用大模型推理引擎并非在这一延迟约束下设计，因此本文从「具有确定 decode 次数上界的请求」这一工作负载出发，重新设计在线执行路径：以静态 DAG 组织完整业务请求，结合 AOTInductor 编译、Packed Prefill、请求内 K/V 共享及选择性 FP8，系统性压缩调度与计算开销。在平均端到端时延低于 20ms 的约束下，Prefill-only 有效 MFU 达到 67%，吞吐较 SGLang 提升 10 倍，为 SLM 在搜推场景的大规模落地提供了一套高性能、可复用的工程实践。

摘要

搜推场景下业界逐渐使用 SLM（Small Language Model，小参数量语言模型 0.5~1B），用于意图理解，相关性判断，生成式推荐等任务，这些模型保留 Decoder-only Transformer 和 Next-Token Prediction 的基本结构，但在线执行形态与开放式文本生成存在明显差异：

- Prefill-Only 模式：仅执行一次 prefill，根据每条序列最后一个有效 Token 位置的 logits 得到类别或分值，或基于 prefill 产出的 Embedding 接入 MLP 模块做分类任务；

- Beam Search 模式：执行一次 prefill 和固定次数 decode，在固定 beam 宽度下返回少量候选序列。两类请求的输入规模、运行状态和最大迭代次数均具有可预先确定的上界。

本文将这类控制流结构、状态容量和执行资源能够在部署前界定，输出 decode 的次数具有固定上界的请求，统称为有界生成负载；其中 Prefill-Only 可以看作为 decode 次数为 0 的特殊情况；

在项目早期，我们通过 Triton Inference Server 的 Python Backend 适配业务协议，并使用 SGLang 完成模型执行。该方案能够快速复用 tokenizer、生成调度和状态管理能力，支持业务快速实验拿到效果。但随着 SLM 在搜索场景的持续应用，越来越多的场景取得显著收益，推全成本也在显著增加，业界现有方案已经不足以支持更大规模的落地 SLM，我们随即基于模型负载的独特性，提出专为有界生成负载设计的推理系统。

我们构建了一套以静态有向无环图（Directed Acyclic Graph，DAG）为在线执行抽象的推理框架，将完整业务请求作为 DAG 执行、端到端测量和容量规划的共同边界，并以节点作为模型编译边界。模型计算节点使用 PyTorch AOTInductor 生成的 AOTI 产物，文本处理和数据转换由框架自定义节点完成，Runtime 负责节点调度、资源管理和并发执行。针对有界生成负载，系统进一步将 Packed Prefill、请求内 shared-prefix K/V 布局、固定 Beam Search 编译和选择性 FP8 矩阵计算等自定义实现嵌入 AOTInductor 编译流程。

性能结论表明，约 0.6B 的 Prefill-Only 模型在每个请求包含 15 条样本时达到约 100 request QPS，即约 1,500 sample/s；约 0.5B 的短 prompt 和长 prompt Beam Search 模型在 beam width 约为 100、decode 4 次时，分别达到约 300 和 120 request QPS。三类负载的平均端到端时延均低于 20 ms，P99 约为 70 ms，Prefill-Only 负载下混合精度有效 MFU 为 67%，约为 SGLang 10 倍，短 prompt beam search 有效 MFU 41%，约为 SGLang 6 倍。

目前，该框架已经在美团搜索意图分流、搜索相关性判断、生成式召回等应用 SLM 的场景取得实验显著性，能支撑业务在推理成本可控的情况下全量推送。

01 有界生成负载的特征与设计约束

本文关注搜索推荐场景下一类在线执行过程受到业务约束的 SLM 负载：模型仍采用 Decoder-only Transformer，但一次请求涉及的模型阶段和最大迭代次数固定，搜索宽度和状态容量也具有可在部署前确定的上界。实际输入长度、batch 大小和搜索候选仍能随请求变化，但这些动态性均发生在预先配置的容量范围内。

“执行结构固定、动态 shape 可控”是后续系统设计的基础。这些约束来自具体业务的在线执行方式，与模型参数量或模型结构没有必然关系；同一个语言模型用于开放式文本生成时，也可能不满足这里的有界条件。

1.1 两类在线执行形式

Prefill-Only 模型只执行一次 Transformer prefill，不进入自回归 decode。模型在每条序列最后一个有效 Token 位置计算 Next-Token Logits，再根据目标标签对应 Token 的 logits，通过 softmax、Top-K 或固定映射得到业务输出。该路径仍使用语言模型的 Next-Token Prediction Head，但在线执行只包含一次批量前向过程。Prefill 结束后即可返回结果，不需要跨阶段维护该请求的 K/V 状态。

Beam Search 模型在 prompt prefill 后继续执行固定次数 decode。首步 logits 用于初始化候选，后续每一步从各 beam 的 Token 分布中选择局部候选，与历史累计分数合并，再保留固定数量的候选序列。对于一个具体部署配置，beam 宽度和最大生成 Token 数均为固定值。Beam Search 中的候选、累计分数和 parent index 仍由模型输出决定，但状态容量、更新次数和算子组合可以提前确定。

1.2 输入与状态边界

本文覆盖的请求平均输入长度均在 500 Token 以内，输出则是分类分值或少量生成 Token。部分 Prefill-Only 请求包含多条输入样本；有界 Beam Search 的 beam 宽度和最大生成步数由部署配置确定，本文覆盖的配置不超过 400 beam 和 5 个生成 Token。两类请求的实际输入和候选内容会变化，但处理规模和状态容量都具有明确上界。

对于同一 batch 内的变长输入，统一 padding 会使短序列承担与最长序列相同的线性层、MLP 和 attention 计算。系统因此保留每条序列的有效长度，并在后续 Prefill 计算中只处理有效 Token。

Prefill-Only 请求在一次前向后结束，不需要跨阶段保存 K/V。有界 Beam Search 只在少量 decode step 之间维护状态，同一请求内的 beam 共用一份 prompt K/V，并分别保存较短的 suffix K/V。输入长度、beam 宽度和生成步数均有上界，因此所需状态可以在加载阶段完成容量规划和内存预分配。

跨请求 prefix cache 的收益取决于公共 Token 前缀的长度和命中率。当前模板较早进入业务 Query、候选文本等请求特有内容，不同请求间可复用的公共前缀很短，实际命中率也很低；同时，平均输入长度不足 500 Token，缓存管理能够摊薄的计算有限。因此，系统不维护跨请求 Prefix Cache，只利用同一 Beam Search 请求内部确定存在的 prompt K/V 共享。

1.3 在线工作负载分析

由于 GPU 推理本质上是基于 Cuda Stream 的串行计算，因此推理服务的耗时可以抽象为排队论中的 G/G/1 模型。排队等待时间的经典工具是 Kingman 近似公式(G/G/1 排队）： ， 线上统计 QPS 是每秒处理的请求数，因此衡量推理性能的时间窗口就是 1000ms， 则可以对公式进行如下解释:

- 可以表征 GPU 的拥挤程度，表示在 1000ms 内执行计算的时间占比。

- 请求到达间隔的变异系数，可以表征的是在 1000ms 内请求到达 GPU 的概率分布，通常自然流量遵循泊松分布，但由于序列过长而需要分批处理时则会偏离泊松分布，请求在 1000ms 内的分布出现聚集现象但 GPU 处理能力有限，造成排队。

- 服务时间变异系数， 表征的是对于推理服务处理的耗时分布情况， 如果序列长度，batch size 等分布不均，则会使得单次请求处理时间分布也呈现出方差过大的现象。

- 表征单次 forward 的平均耗时，表示单次请求占用 GPU 卡的平均时间，可以表示为请求处理的周转速度。

推理耗时可以分为四部分，CPU 入口等待时间、CPU 处理时间、GPU 入口等待时间、GPU 处理时间。 CPU 通常并发处理能力远强于 GPU，因此 GPU 成为资源瓶颈。 越大， GPU 入口等待时间就会延长，当超过上游超时后，排队中的请求被 GPU 顺序执行则是一种浪费，大量请求的丢弃又会导致 GPU 在 1000ms 内的处理时间不足，也就是 偏低。于是呈现出一种 GPU 利用率很低但耗时却很高的现象。

在搜推场景下，由于序列分批导致请求到达间隔严重偏离泊松分布，服务时间通常是稳定的（序列长度和 batchsize 基本固定），单次推理的平均耗时一般在 20ms 以下。 传统的 SGLang/vLLM 框架并不是在这样的假设下设计，调度策略难以处理严重偏离泊松分布的请求到达负载，而其为了 prefill 长度任意变化，decode 次数无上界等场景设计的各种优化策略，在搜推的 SLM 场景均是负向优化。

我们利用 在搜推场景下较小的优势，移除 SGLang 为无界生成负载定制的各种优化手段，重新为有界生成负载（Prefill-Only & Beam Search）设计 GPU 计算路径，以达到减少 的目的，通过移除 Python 对 request 和 Token 的调度开销压缩 CPU 等待与处理时间，从而达到减少 GPU 空泡的目的，进一步通过 cpp 精细化的 Multi-Stream 调度能力，增加 GPU 跨请求并行计算的能力，以缓解无法调和的 。

1.4 负载特征与系统设计

上述业务约束将系统问题收束为：如何高效处理边界已知的一批输入。编译、执行和容量控制均围绕这一目标组织。

02 基于静态 DAG 的分层编译执行架构

整体上，本文实现的是一套以静态 DAG 组织完整请求流程、以独立节点封装具体计算的分层编译执行架构。离线构建链使用 Python 表达模型语义、选择算子实现，并将完整 GPU 计算编译为可直接加载的 AOTI 节点产物；在线执行链使用 C++ 完成协议处理、DAG 调度、资源管理和数据转换，不再解释或即时构建模型计算。

在线执行链进一步分为服务、DAG Runtime 和节点三个层次。服务层负责 RPC 协议、请求准入和生命周期；DAG Runtime 根据静态拓扑调度节点，并管理跨节点 Tensor、设备同步、请求上下文和并发；节点负责具体计算，其中 CPU 节点承载文本处理和结果编码，GPU 节点加载 AOTI 编译产物。Runtime 只依赖节点的输入输出、设备和执行接口，attention、Beam Search 和精度策略都封装在节点内部。

离线构建：Torch 模型与算子语义

-> lowering 与 AOTInductor

-> AOTI 模型节点产物

C++ 节点实现与配置

-> CPU 自定义节点与资源

在线执行：RPC 服务

-> DAG Runtime

-> CPU 预处理节点

-> AOTI 模型节点

-> CPU 结果节点

-> RPC 返回

两类模型在这套架构中对应两张不同的 DAG：

这种分层首先使系统可以按完整业务请求执行：Prefill-Only 的多条样本一次进入模型节点，Beam Search 的各个 decode step 在生成节点内部完成。其次，静态拓扑和有界 shape 使 buffer、stream 和执行实例能够在加载阶段规划，请求热路径只处理有效数据。最后，模型计算被封装在节点内部，算子、精度和硬件实现可以独立替换，而服务协议和 DAG 调度机制保持稳定。

2.1 完整业务请求的执行边界

项目早期通过 Triton Inference Server 的 Python Backend 适配业务协议，并使用 SGLang 完成模型执行。这套方案能够快速复用 tokenizer、生成调度和状态管理能力，适合模型验证和早期上线。但在当时的接入方式中，批量输入会被拆分为多条独立生成请求，分别完成文本处理、状态创建和模型调度，返回后再恢复原有顺序和业务结构；Beam Search 模型的各个 decode step 也继续经过通用生成控制路径。

通用生成系统通常按照独立请求组织调度，并在运行时处理请求的加入、退出和解码长度变化。这种粒度适合开放式生成；对于当前只执行一次 prefill 或少量 decode 的负载，请求拆分、对象创建、进程通信、逐步控制和结果重组却都要在约 20 ms 的端到端时延预算内完成，较长生成任务中能够被模型计算摊薄的固定开销在这里更加显著。

因此我们重新选择执行单位：完整业务请求成为 DAG 调度、端到端测量和线上容量规划的共同边界。Prefill-Only 请求内部可以包含多条样本，但这些样本作为一个 batch 进入模型节点，不再拆成独立生成任务；Beam Search 请求则从 prompt prefill 到最终候选返回只经历一次 DAG 调度。模型编译仍以节点为边界，不与请求调度耦合。

项目早期的执行路径可以概括为：

批量业务输入

-> 拆分为逐样本生成请求

-> tokenizer / 请求状态创建

-> 通用生成 Runtime

-> 逐 decode step 控制

-> 结果重组

当前执行路径则为：

业务请求

-> 协议适配与请求准入

-> DAG Runtime

-> 文本处理与 packed tokenizer

-> prefill / 生成 AOTI 节点

-> 结果编码

-> RPC 输出

Prefill-Only 中的多条序列由模型节点一次处理，Beam Search 的逐步控制则收进生成节点。在线请求不再反复跨越 Pyt