你在搜索框里敲下几个字，背后可能有模型同时判断意图、评估结果是否相关，还要补出候选内容。每一步都不能慢：模型即使更聪明，只要让页面多等一会儿，就很难进入实时链路。美团这项实践解决的正是这个问题——让约0.5至1B参数的小语言模型（SLM，Small Language Model）在高并发搜索和推荐中，既守住毫秒级时延，又尽量多干活。
它的关键不是把通用大模型引擎再调快一点，而是先承认搜推任务与聊天不同：许多请求只做一次判断，或者只生成固定几个 Token——模型处理文本时使用的基本单位。既然工作量有明确上界，系统就可以提前编排执行路径，少做大量临场调度。
本文数字、架构与落地结论均来自美团技术文章，尚无独立信源交叉验证。尤其是与 SGLang 的对比，原文没有披露完整软硬件和调优配置，不能直接外推到其他环境。
先问清楚：模型到底要做多少事
语言模型推理通常分两段。Prefill 会一次读完输入并建立中间状态；Decode 再逐个生成后续 Token。开放式聊天不知道何时结束，系统必须随时处理请求加入、退出和长度变化。但搜推中的一些小模型任务简单得多。
第一类是 Prefill-Only。模型读完输入后直接给出类别或分数，不生成新文本。意图识别和相关性判断就可能采用这种形式。第二类是固定步数的 Beam Search——模型同时保留若干条候选生成路径，再从中筛选结果。美团把这两类任务统称为“有界生成负载”：执行阶段、搜索宽度、状态容量和最多生成几步，都能在部署前划出边界。Prefill-Only 可以看成 Decode 次数为零的特例。
材料覆盖的请求平均输入长度均不超过500 Token；Beam Search 配置不超过400条候选路径和5个生成 Token。这些限制与模型大小没有必然关系。同一个模型一旦用于开放式长文本生成，就未必仍是有界负载。
把临场指挥改成预先排练
美团用静态 DAG——有向无环图，也就是一张提前确定先后依赖关系的流程图——组织完整业务请求。文本处理、模型计算和结果转换各自成为节点。离线阶段用 AOTInductor 提前编译模型计算；在线阶段则由 C++ Runtime 按固定拓扑调度，不再通过 Python 临时解释和组织每一步。
这像把一份固定套餐提前排好后厨工序。通用引擎要面对顾客随时加菜、减菜，因此需要复杂的动态调度；这里的菜品和最大份量已经确定，更适合预留工作台和容器。系统可以在加载时规划内存、计算流和执行实例，请求到来后只处理有效数据。
执行边界也随之改变。早期方案通过 Triton Inference Server 的 Python Backend 适配协议，再用 SGLang 执行模型。一份包含多条样本的业务请求会被拆开，分别建状态、调度、执行，最后再恢复顺序。对长文本生成而言，这些固定开销容易被计算时间摊薄；对总预算约20毫秒的短任务而言，它们反而很显眼。新框架把完整业务请求作为一次 DAG 执行：15条样本可以一起进入模型节点，固定几步的 Beam Search 也只经历一次外层调度。
批得更满，也不能让请求排太久
批处理能让加速器一次处理更多输入，通常会提高吞吐；但请求为了凑批次而等待，也会拉高延迟。美团的思路是压缩每次执行的固定成本，并利用任务边界稳定这一点，让批次里的有效计算更密集。
Packed Prefill 只处理各条序列中的有效 Token，避免短输入陪最长输入一起计算填充部分。Beam Search 中，同一请求的多条候选路径共享 prompt 的 K/V——模型读完输入后留下的中间结果——各自只保存较短的后缀状态。系统没有维护跨请求的 Prefix Cache，因为材料称不同请求可复用的公共前缀短、命中率低，而平均输入也不足500 Token。
框架还采用选择性 FP8，即让部分矩阵计算使用8位浮点数，以降低计算和存储开销；同时把固定 Beam Search、Packed Prefill 和请求内 K/V 共享嵌入提前编译流程。不过原文没有拆分各项优化的单独贡献，因此不能把总体提升归功于其中某一种技术。
数字说明了什么
据美团披露，约0.6B参数的 Prefill-Only 模型在每个请求包含15条样本时，达到约100 request QPS——每秒处理约100个请求，折合约1,500条样本。约0.5B参数的 Beam Search 模型在候选宽度约100、固定 Decode 4次时，短 prompt 达到约300 request QPS，长 prompt 约120 request QPS。
三类负载的平均端到端时延都低于20毫秒，P99约70毫秒。P99指99%的请求能在该时间内完成。两组数字并不冲突，但也提醒我们：“延迟红线”究竟约束平均值还是尾部请求，原文没有给出同一个严格门槛。
Prefill-Only 的混合精度有效 MFU 为67%，约为 SGLang 的10倍；短 prompt Beam Search 为41%，约为 SGLang 的6倍。MFU可以理解为模型实际用上了多少理论计算能力。这里比较的主要是有效 MFU，不能简单改写成所有场景下纯吞吐都提升6倍或10倍。
为什么值得关注
这套方案展示了一种很实用的工程取舍：不要为“什么请求都能处理”支付全部成本，而要根据业务边界删掉不需要的灵活性。模型越小、任务越短，协议转换、对象创建和逐步调度等外围开销就越难忽略。此时，先界定负载，再重新选择执行单位，可能比继续优化单个算子更重要。
据美团披露，该框架已用于搜索意图分流、搜索相关性判断和生成式召回等场景。它延续了实时搜索的一条老路线：Amazon Science 曾报道，研究人员没有把较慢的 BERT 类模型直接塞进商品搜索链路，而是用它训练约7,500万参数的小模型，在保持与旧生产模型相近延迟的同时，将离线相关性指标最多提高23%，之后再做大规模线上 A/B 测试。共同点很清楚：实时系统最终选择的，往往不是能力最强的模型，而是在既定时间预算内完成最多有效工作的模型。
局限与未知
- 全部性能与落地结论来自美团单一信源；SGLang 的版本、硬件、精度、批量大小、并发设置和调优方式均未披露，对照结果无法独立复现。
- 原文称业务取得“实验显著性”并可支持全量推送，但未给出显著性检验方法、部署规模、成本和具体业务指标。
- 现有结果针对输入较短、生成步数固定的有界负载，不能证明同一设计适合开放式长文本生成。