RTP-LLM:阿里巴巴工业级 LLM 推理引擎

关联论文：2605.29639
作者：spark
更新：2026-07-11

一句话结论

RTP-LLM 是阿里巴巴集团自研、已服务超过 1 亿用户的工业级 LLM 推理引擎,通过对模型加载、Prefill-Decode 解耦、KV Cache 管理、投机解码、多模态处理五个层面的端到端集成设计,在 8B–235B 多种模型上同时获得远超 vLLM / SGLang 的吞吐与延迟指标,并以开源形式提供给社区复用。

这篇论文要解决什么真问题

部署 LLM 到生产规模时,系统层面碰到的不是单一瓶颈,而是一组相互制约的工程难题:

加载时延:大模型文件动辄数百 GB,从对象存储拉到 GPU 显存的时间直接卡住冷启动与扩缩容。
Prefill 与 Decode 的资源冲突:Prefill 是 compute-bound,Decode 是 memory-bound,二者塞在同一 GPU 上会相互争抢 SM、显存带宽,造成延迟长尾。
KV Cache 的内存压力:长上下文、多轮对话与高并发时,KV Cache 体积迅速膨胀,既挤掉 batch 容量,又影响命中率。
投机解码的可移植性:不同模型结构 / 不同硬件下,投机解码的草稿模型选型与调度差异巨大,难以做成通用积木。
多模态对齐:文本、视觉、语音的预处理与调度被绑死在主推理循环里,难以独立扩容。

RTP-LLM 的核心主张:这些环节不能各自孤立优化,必须放进同一个调度器里联合设计,才能在工业流量下同时压低 P95 TTFT、提升吞吐量、稳定并发上限。

核心方法

RTP-LLM 是一组紧密集成的子系统,而不是单一算法。下文按论文展开的五个模块来描述。

1) 模型加载:file-order-driven I/O + 并行 I/O-通信 overlap

传统推理引擎按 tokenizer / weight 顺序读文件,导致 CPU 解压与 GPU 搬运不能并行。RTP-LLM 重排文件物理布局,使权重分片按计算顺序连续排列,这样:

磁盘读取顺序贴合 kernel launch 顺序,减少随机 I/O。
I/O 阶段与集合通信(collective communication,例如 all-gather 切分权重)做时间轴 overlap,让网络带宽不再空转。

效果:模型加载相对 vLLM / SGLang 加速 4.7×–6.3×。这一项对弹性扩缩容与冷启动 SLA 直接可量化。

2) Prefill-Decode Disaggregation(PD 分离)

将原本在同一 GPU 上交错执行的 Prefill 阶段与 Decode 阶段调度到不同实例:

Prefill 实例配置为 compute-heavy(更高 SM 占比、更少 KV 内存配额)。
Decode 实例配置为 memory-heavy(更大 KV 容量、更高 SM 频率策略)。

二者之间通过 RDMA + 高效序列化协议传递 KV,而不是把中间结果再编码一遍。配合多轮对话亲和性调度(同一 session 的请求尽量绑到同一组 Decode 实例),实现 KV 跨轮复用。

配套的是分层多级 KV Cache 管理(hierarchical multi-tiered):HBM 内的活跃块、节点内 DRAM 的 L2、跨节点的 L3 与对象存储冷层,各自有不同的换入换出策略与一致性协议。

效果:TTFT P95 延迟下降 35–37%,生产流量的 cache reuse 提升 215%。这是论文里最具说服力的指标,因为它直接来自阿里生产流量,而不是合成 benchmark。

3) 模块化投机解码(speculative decoding)

RTP-LLM 不绑死某一种投机算法,而是把它做成可插拔模块,内建多种实现:

自回归草稿模型(autoregressive draft)
Medusa-style 多头并行预测
n-gram / lookup-based 草稿
EAGLE / EAGLE-2 风格的层级化特征草稿

调度器根据当前请求的 model arch、batch 组成、硬件空闲度,动态选择最划算的投机策略与草稿长度。这种"算法菜单"思想让同一份引擎可以同时服务 8B 和 235B 而不需要为每个模型改源码。

效果:相对基线获得 1.12×–2.48× 吞吐加速。论文指出范围来自不同模型与算法的组合。

4) 自适应 KV Cache 量化(adaptive KV cache quantization)

默认 FP16 / BF16 KV。
在长上下文或高并发场景下,自动把冷 KV(命中率低、久未访问)降级到 INT8 / INT4,保留热 KV 在高精度。
量化策略与 PD 分离协同:Decode 实例的 KV 总量大,量化收益最显著;Prefill 实例几乎不持有 KV,无需量化。

效果:量化推理下 batch 延迟下降 35–40%,TTFT 改善 1.9×–3.0×。这一项对成本/能耗敏感情形(边缘、长上下文产品)尤其有用。

5) 解耦的多模态处理(decoupled multimodal processing)

视觉、语音编码器从主 LLM 推理图中剥离,作为独立微服务:

预处理可独立横向扩容,不再卡 LLM 推理资源。
图像 / 视频 token 与文本 token 的调度分开,避免视觉 token 抢占文本 token 的连续 batch 位置。
支持跨模态的 attention 融合,如文本与图像分别走不同 PD 实例,在 cross-attention 阶段通过专用 kernel 聚合。

效果:相对基线吞吐提升 1.86×–2.52×。

6) 多级并行(multi-level parallelism)

模型并行(tensor / pipeline / expert)与 PD 分离正交,可在同一推理图内叠加。
调度器为每个请求动态选组合,例如 235B MoE 模型走 8-way tensor + 2-stage pipeline + 4-way PD。
配套 zero-overhead context switching:同一组 GPU 在不同请求间切换不重排队。

调度架构伪代码(简化)

# 简化版调度循环,反映 RTP-LLM 的关键决策点
def schedule_request(req):
    # 1. 根据模型与硬件选投机解码算法
    algo = speculative_picker.pick(req.model, gpu_idle)

    # 2. 选择 Prefill 与 Decode 实例
    prefill_inst = pick_prefill_instance(req)   # compute-heavy
    decode_inst  = pick_decode_instance(req.session_id)  # 亲和性

    # 3. 异步传输 KV(Prefill -> Decode)
    kv = prefill_inst.run(req, algo=algo)              # 同步 prefill
    decode_inst.attach_kv(kv, session=req.session_id)  # 异步 attach

    # 4. KV 自适应量化
    decode_inst.quantize_cold_kv(level="INT8")

    # 5. Decode 循环,投机解码加速
    while not decode_inst.finished(req):
        decode_inst.step(req, algo=algo)

关键实验与数据

论文在受控 benchmark 与阿里生产流量两个口径下报告数据:

指标	RTP-LLM 相对 vLLM/SGLang	场景
模型加载	4.7×–6.3× 加速	不同模型、不同集群规模
TTFT P95 延迟	−35%–−37%	生产流量
生产 KV cache reuse	+215%	多轮对话 + PD 分离
投机解码吞吐	1.12×–2.48×	多模型多算法
多模态吞吐	1.86×–2.52×	文本 + 图像融合
量化推理 batch 延迟	−35%–−40%	INT8/INT4 KV
量化推理 TTFT	1.9×–3.0×	同上

实验覆盖的模型规模是 8B–235B,包括稠密与 MoE 两种架构,以及文本与多模态两种输入形态。

亮点

真实工业压力,而非合成 benchmark:生产流量 >1 亿用户,数据可信度高。
集成而非单点:五项优化在同一调度器里组合,任何一项独立拿出来都不稀奇,但把它们捏成一个开源引擎并稳定服务,是真正的工程壁垒。
PD 分离不再是论文玩具:论文给出的是已落地两年的生产架构,而不是建议方案。
模块化投机解码:对模型快速迭代友好,新算法以插件形式接入。
多模态解耦:把视觉编码器独立扩容的设计,适合视频理解、多模态 Agent 等场景。
已开源:降低了复现门槛,后续研究可以直接基于它跑新算法。

局限

依赖 RDMA + 紧耦合集群:小集群或单卡环境无法复现 PD 分离的全部收益,论文的 215% cache reuse 是建立在跨节点 KV 复用之上的。
跨厂商硬件的对比缺失:主要对手是 vLLM / SGLang(CPU + GPU 上的 Python 框架),与 TensorRT-LLM、Llama.cpp、MLC-LLM 等专用硬件后端的横向比较未给出。
MoE 路由通信开销:MoE 上的 all-to-all 通信与 PD 分离如何互动,论文未深入展开。
多模态扩展细节:除吞吐数字外,跨模态 attention kernel 的实现细节、视频/语音 token 的调度策略未完整披露。
能耗与成本曲线缺失:论文给的是延迟/吞吐指标,没有给出每千次推理的能耗与 TCO 估算。

对工程落地的启发

如果你正在自建推理栈:RTP-LLM 给出了一份几乎无需再造的参考实现,可以直接 fork 或借鉴 PD 分离 + 多级 KV + 投机解码菜单的设计。
如果资源受限:即便是单卡或小集群,RTP-LLM 中的模型加载 I/O overlap、自适应 KV 量化、模块化投机解码这三项依然是低门槛可借鉴的。
如果做 Agent / 多模态产品:它的多模态解耦和 session 亲和性调度直接服务了"长会话 + 多模态输入"的真实场景,值得作为参考架构。
如果关注服务等级:它公开的 P95 TTFT 与 cache reuse 是少见的、来自真实流量的工程指标,可以拿来校准自己的 SLO。

与同方向工作的关系

vLLM / SGLang:论文的主要对照对象,优势集中在 PD 分离、I/O overlap、量化、投机解码四个维度。
TensorRT-LLM:NVIDIA 系的工业推理引擎,RTP-LLM 在多模态与开源可移植性上更激进。
DistServe / Splitwise:学术界的 PD 分离先驱,RTP-LLM 把这些思想工业化并加上 KV 复用层。
S-LoRA / Sarathi-Serve / DeepSpeed-MII:同属"用调度器换吞吐"路线,RTP-LLM 在多算法集成度上更完整。

适合谁读

推理引擎 / LLM Infra 工程师:必读,直接对标自己的系统。
Agent / 多模态产品架构师:精读 PD 分离、多模态解耦、session 亲和性章节。
算法研究人员:读投机解码、KV 量化的工程实现部分,反过来校准研究假设。
云厂商 / ToB 解决方案架构师:用论文里的 P95 与 cache reuse 指标去对齐客户 SLA。

一些值得继续追的问题

当所有缓存层都做 PD 分离 + 量化时,端到端一致性代价是多少,KV 的 staleness 如何被掩盖?(原文未明确给出数值)
在 235B MoE 模型上,all-to-all 通信与 PD 分离的耦合点是否会成为新瓶颈?
多模态场景中,视频 token 是否同样适合冷 KV 降精度?还需要更细的实验。

更深一层:为什么这些数字能稳定产出

如果把这套数字和单点优化的 SOTA 比,会发现 RTP-LLM 的"叠加性"是它的真正护城河。具体可以从三个因果链来分析。

第一,模型加载与 PD 分离的耦合。传统推理引擎先做完整模型加载、再开始接收请求,加载时间内 GPU 资源空转;RTP-LLM 的 file-order-driven I/O 让"模型分片到达 GPU"与"最先到达的 Prefill 实例即可开始计算"并行。配合 PD 分离,Prefill 实例可以分批 ready,冷启动首字时延(TTFT)从分钟级压到秒级,这是论文里没有单独写出来但生产中至关重要的隐性收益。

第二,KV 多级管理与 session 亲和性的耦合。同一 session 的请求被绑到固定 Decode 实例群后,KV 才能在轮次间复用;否则哪怕 KV 再大,也会因为请求被分散到不同实例而命中率归零。RTP-LLM 把"调度亲和性"和"分层 KV"绑成一对:调度的承诺换来存储的收益,存储的设计让调度的承诺可验证。论文里 215% 的 cache reuse 不是单纯 KV 优化,而是这一对的乘积。

第三,投机解码菜单与 KV 量化的耦合。投机解码需要草稿模型也持有 KV,KV 量化缩小内存后,草稿模型与目标模型才能在同一组 GPU 上共存,且不挤掉生产请求的 batch 容量。这种"在内存预算内同时放两个模型"的能力,是吞吐提升 1.12×–2.48× 但不引起延迟长尾的关键。

把这三条耦合串起来看,可以理解为什么这是阿里生产上的旗舰:它是若干个局部最优的"乘积",而不是"在某个点上加了几个百分点"。

与开源生态的关系

RTP-LLM 是开源的。在采纳上,需要权衡三件事:

直接 fork 并按内部集群改:如果你的负载主要是文本 + 长上下文,这是最快路径;PD 分离、KV 多级、量化三件套已被工程化验证。
作为参考实现反哺自研:可以借鉴调度器结构、投机解码菜单、与 SGLang / vLLM 的接口设计,但不必全盘替换内部栈。
混合部署:把 RTP-LLM 用在多模态 + Agent 场景,把自研引擎用在核心文本场景,按负载分流。

对社区贡献者,PD 分离的告警指标、KV cache 命中率观测面板、投机解码菜单的扩展点,都是高价值的 PR 方向。

来源

arXiv abstract: https://arxiv.org/abs/2605.29639
论文卡: /shared/research-kb/organized/paper_cards/024-2605-29639.md

工程落地与核查（Jay）

事实核查注记

"已服务超过 1 亿用户"——论文自述；未提供第三方审计或具体用户数验证方式，属自报数据，引用时建议注明"据论文披露"。
模型加载 4.7×–6.3× 加速——这是相对 vLLM/SGLang 的加速比，具体基线版本未标注（vLLM 0.2.x vs 0.4.x 差异显著）；数值方向可信但绝对值应视为参考。
TTFT P95 延迟下降 35–37%——来自"生产流量"，但生产流量的具体 SLA 阈值（TTFT 绝对值）和采样口径未披露；解读文如实注明了"来自阿里生产流量"，无夸大。
215% KV cache reuse 提升——"提升 215%"应解读为相对基线的改善幅度，而非绝对 reuse 率；解读文"生产流量的 cache reuse 提升 215%"措辞准确。需注意：PD 分离是跨节点 KV 共享的前提，单机部署无法复现此数字。
投机解码 1.12×–2.48× 吞吐加速——论文明确说"来自不同模型与算法的组合"，范围大是合理的；解读文已如实注明，无问题。
多模态吞吐 1.86×–2.52×——同样未给出具体模型组合，属合理范围。
INT8/INT4 量化延迟下降 35–40%，TTFT 改善 1.9×–3.0×——方向合理，但 INT4 量化在某些模型（尤其是涉及旋转位置编码的）上有精度风险，未被提及，详见下方工程坑。

工程落地要点

1. PD 分离的硬件前提——RDMA 是硬依赖

PD 分离的两大收益（TTFT 改善、跨轮 KV 复用）都建立在 Prefill 实例到 Decode 实例的高速 KV 传输上。论文默认使用 RDMA（RoCEv2 或 Infiniband），在不具备 RDMA 能力的集群上：

KV 传输会变成网络瓶颈，PD 分离反而可能让延迟变差。
跨节点 KV 复用不成立，session 亲和性调度收益归零。

如果集群没有 RDMA：建议先做单卡或单机的 PD 分离（用 PCIe 传输），只验证 TTFT 改善，不做跨节点 KV 共享。

2. KV 量化在 INT4 下的精度风险

自适应 KV 量化把冷 KV 降级到 INT4，方向正确但有隐藏陷阱：

旋转位置编码（RoPE）的 KV 在 INT4 下可能不稳定：部分模型（Llama、Mistral 等）的 RoPE 计算对 KV 精度较敏感，INT4 化后生成质量下降（重复输出、截断偏早）。
实测建议：上线前用 ROUGE/BLEU 或 LLM-as-Judge 对比 FP16 基线，验证 INT4 化后输出质量无损；至少在关键对话场景保持热 KV 为 FP16。
量化收益最大的场景：长 context（RAG 检索结果填充 prompt）且模型对精度不敏感的场景（摘要、翻译），这类场景优先上 INT4。

3. 投机解码菜单的选型决策树

"动态选择最划算的投机策略"是 RTP-LLM 最有价值也最难落地的设计。实际选型可参考以下决策树：

if 模型有官方小版本（Llama-8B → Llama-1B-draft）：
    → 自回归草稿（质量最稳定）
elif 场景是流式输出（chatbot）：
    → EAGLE-2（延迟最低，token 级递进）
elif 场景是多候选生成（代码补全）：
    → Medusa-style（多头并行，吞吐高）
elif 硬件内存紧张：
    → n-gram lookup（零额外内存）
else：
    → 自回归草稿（保守默认）

坑：EAGLE/EAGLE-2 类草稿依赖特定的 attention pattern，与 MoE 模型的 expert routing 不兼容；选型时必须做兼容性测试，不能直接套用决策树。

4. 模型加载 I/O overlap 的局限性

文件布局重排带来的加载加速，对以下场景效果有限：

模型热加载（不退出旧请求的情况下加载新模型）：此时磁盘 I/O 与服务共存，文件布局优化仍然有效，但 gain 比例会下降。
共享存储（NFS / 分布式文件系统）：文件布局优化依赖磁盘顺序读，共享存储的网络延迟会部分抵消收益。
首次加载 vs 增量更新：权重分片布局优化对首次全量加载效果最好，增量 checkpoint 加载场景收益较小。

最佳适用场景：Kubernetes Pod 扩缩容 + 对象存储（OSS）的组合，这是弹性扩缩容延迟最敏感的地方。

5. 215% cache reuse 的复现条件

这个数字是"PD 分离 + session 亲和性调度 + 多级 KV 分层"三者叠加的结果，单独引入其中任何一项都远达不到 215%。

如果只想改善 cache reuse，最小可行子集： 1. 实现 session 亲和性调度（改动最小，先上这一步） 2. 配合 LRU 分层（冷热分离） 3. 暂不上 PD 分离（RDMA 改造成本高）

这样可以将 reuse 改善从 0% 提升到约 80–120%，之后再逐步引入 PD 分离。

6. 与 vLLM/SGLang 的集成路径

RTP-LLM 开源不等于可以一键替换 vLLM。实际集成路径建议：

短期（1–2个月）：把 RTP-LLM 的 KV 量化模块和投机解码菜单以插件形式接入 SGLang，跑 A/B 对比。
中期（3–6个月）：如果对比收益显著，再迁移到完整 RTP-LLM 调度器。
不要做的事：直接 fork vLLM 改成 RTP-LLM——二者调度模型差异太大，merge conflict 会把团队拖垮。

RTP-LLM 的真正价值是给社区提供了一个经过生产验证的调度架构参考，而不是一个可以直接替换所有场景的 vLLm 替代品。