framework Survey

32 papers

Framework Category Survey #

§1 现状快照 #

2025–2026 年 LLM 基础设施框架正经历从 "高吞吐 batch serving"到"agentic workload 全生命周期编排" 的范式转变。DeepSeek 的 DualPipe + PD 分离架构、vLLM/SGLang 的连续 batching 生态、以及 ByteDance veRL 的 RLHF 训练框架构成当前主流。新兴的 agentic serving 系统（ThunderAgent、Helium、Halo）、超低延迟 persistent kernel 引擎（TileRT/TokenSpeed）、和跨 DC PD 分离（PrfaaS/DualPath）正在快速扩展框架的覆盖边界。这一代框架的核心矛盾已从"怎么喂饱 GPU"转向"如何在动态多阶段工作负载下同时满足 SLO、吞吐和资源效率"。

§2 Taxonomy #

维度定义 #

维度	取值	定义
Stage	training / serving / hybrid	主要服务的推理/训练阶段
Workload Pattern	batch / interactive / agentic / RL-rollout	面向的工作负载形态
Architectural Layer	scheduling / execution / communication / end-to-end	干预的系统层次

论文分布矩阵 #

	Scheduling	Execution/Runtime	Communication	End-to-End
Serving-Interactive	DynaServe [2504.09285], JITServe [2504.20068], PPD [2603.13358], Justitia [ref:2510.17015]	TileRT [tile-ai-tilert], TokenSpeed [tokenspeed], Fleet [ref:2604.15379]	MFS [2603.17456], KVServe [kvserve]	vLLM Semantic Router [vllm-project-semantic-router]
Serving-Agentic	HexGen-Flow [ref:2505.05286], KVFlow [ref:2507.07400], Helium [ref:2603.16104], Halo [ref:2509.02121], Concur [ref:2601.22705]	ThunderAgent [ref:2602.13692], TokenDance [ref:2604.03143], Pancake [ref:2602.21477]	DualPath [2602.21548], PrfaaS [2604.15039]	Sutradhara [ref:2601.12967], Scepsy [ref:2604.15186], GLM [ref:2511.01633]
Serving-MoE	DynaServe [2504.09285], MoE-LB [ref:moe-lb-interai25]	ZeRO-Prefill [2605.02960]	MFS [2603.17456]	—
Training-RL	FlexRLHF [2312.11819], HybridFlow/veRL [2409.19256]	TensorHub [2604.09107]	—	—
Training-LLM	—	DeepSeek-V3/DualPipe [2412.19437]	—	—
Config/Auto-tune	AIConfigurator [ref:2601.06288]	Saguaro/SSD [ref:2603.03251]	—	—

§3 主线与分支 #

主线 A: PD 分离与 KV-Cache 生态 #

Leading: DualPath, PrfaaS, DynaServe, PPD, KVServe

PD (prefill-decode) 分离已从"单集群 RDMA"演进到跨 DC Ethernet。DualPath 用 dual-path loading + CNIC-centric flow isolation 聚合所有 SNIC 带宽 [2602.21548]；PrfaaS 将 hybrid attention 降低的 KV 吞吐用跨 DC 架构变现 [2604.15039]；DynaServe 用 micro-request 统一 colocation 和 disaggregation [2504.09285]；PPD 按干扰差异动态路由 Turn 2+ 请求 [2603.13358]；KVServe 用 service-aware 压缩解决带宽瓶颈 [kvserve]。

主线 B: Agentic Workflow Serving #

Leading: ThunderAgent, Helium, Halo, HexGen-Flow, KVFlow, Concur

Agentic workload（多轮、短追加、长上下文、DAG 依赖）正驱动框架从"请求级调度"转向"程序级编排"。ThunderAgent 引入 agentic program 作为一等调度单元 [ref:2602.13692]；Helium 用 Templated Radix Tree 做 plan-level 优化 [ref:2603.16104]；Halo 借数据库 query optimizer 思路做 batch DAG 整合 [ref:2509.02121]；KVFlow 用 workflow-aware STE 替代 LRU [ref:2507.07400]；Concur 用 AIMD 控制避免 KV thrashing [ref:2601.22705]。

主线 C: 超低延迟推理引擎 #

Leading: TileRT, TokenSpeed, Fleet

近 BS=1 decode 下 kernel 间 idle 占主导。TileRT 将整个模型 AOT 编译为单个 persistent Engine Kernel，tile-level 调度实现 compute-IO-comm 持续重叠，GLM-5 达 500 tok/s [tile-ai-tilert]。TokenSpeed 用 C++ FSM + Placement 编译器 + Blackwell MLA 内核在 Kimi K2.5 上超越 TRT-LLM [tokenspeed]。Fleet 为 AMD MI350 多 die 设计 hierarchical megakernel [ref:2604.15379]。

主线 D: RL 训练框架 #

Leading: HybridFlow/veRL, FlexRLHF, TensorHub, DeepSeek-V3

HybridFlow 用 hybrid single/multi-controller + 3D-HybridEngine 实现 1.53–20.57× 加速 [2409.19256]；FlexRLHF 的 Disaggregated 策略达 11× [2312.11819]；TensorHub 用 Reference-Oriented Storage 消除权重传输瓶颈 [2604.09107]；DeepSeek-V3 的 DualPipe 实现跨节点 all-to-all 完全隐藏 [2412.19437]。

分支: SLO-Aware 调度 #

JITServe 的 GMAX 算法提供 1/8.55 常数竞争比 [2504.20068]；MFS 用 RMLQ 做 MoE 三阶段通信隔离 [2603.17456]；Justitia 用 KV token-time 做公平调度 [ref:2510.17015]。

分支: MoE 执行优化 #

ZeRO-Prefill 反转 EP 数据流方向，用 AsyncEP 替代 AllToAll [2605.02960]；MoE-LB 用 ILP 做联合复制/分配 [ref:moe-lb-interai25]。

§4 跨论文对比表 #

系统	Stage	核心指标	Baseline 对比	硬件	代码开源	可复现性
DualPath [2602.21548]	Serving	1.87× offline JCT, 1.96× online APS	vs Basic (same infra)	H800+IB+3FS	未公开	不可
PPD [2603.13358]	Serving	Turn2+ TTFT −48–73%	vs vLLM PD	4×H100	未公开	部分
MFS [2603.17456]	Serving	SLO attainment 1.2–2.4×	vs FS/SJF/EDF/Karuna	32 GPU testbed	未公开	不可
TensorHub [2604.09107]	Training	6.7× stall reduction (standalone)	vs NCCL/UCX	1024 GPU Hopper	未公开	不可
PrfaaS [2604.15039]	Serving	+54% 吞吐, −64% P90 TTFT	vs 同构 PD	32H200+64H20	未公开	不可
ZeRO-Prefill [2605.02960]	Serving	1.35–1.37× throughput	vs DP×EP/TP/PP	8×A100/H100/H200	开源 (vLLM)	复现
TileRT [tile-ai-tilert]	Serving	600 tok/s (DSV3.2)	vs 传统框架 ~几十 tok/s	8×B200	部分	部分
TokenSpeed [tokenspeed]	Serving	Pareto 优于 TRT-LLM ~9–11%	vs TRT-LLM	B200	开源 (MIT)	部分
KVServe [kvserve]	Serving	up to 10× KV 压缩, 8.5× 延迟	vs 无压缩	A100	开源 (Apache)	复现
DynaServe [2504.09285]	Serving	1.15–3.07× serving capacity	vs coloc./disagg.	A100	未公开	部分
JITServe [2504.20068]	Serving	1.4–6.3× goodput	vs Sarathi/vLLM/Autellix	16×A100	未公开	部分
HexGen-Flow [ref:2505.05286]	Serving	P95 latency 1.42–1.56× lower	vs vLLM/VTC/QLM	未报告	开源	复现
KVFlow [ref:2507.07400]	Serving	1.83–2.19× speedup	vs SGLang+HiCache	A100	未公开	部分
Halo [ref:2509.02121]	Serving	>400× vs vLLM, 1.03–3.6× vs agent	vs vLLM/agent baselines	未报告	部分	部分
Justitia [ref:2510.17015]	Serving	57.5% JCT reduction	vs VTC/Parrot	Llama 7B/13B	未公开	不可
GLM [ref:2511.01633]	Serving	15.1× throughput, +38% accuracy	vs Graph-CoT baseline	未报告	未公开	不可
AIConfigurator [ref:2601.06288]	Serving	TPOT MAPE 6–12%, search 170K× faster	vs GPU benchmarking	多种	未公开	不可
Sutradhara [ref:2601.12967]	Serving	FTR −15% median	vs vanilla vLLM	A100	未公开	不可
Concur [ref:2601.22705]	Serving	4.09× throughput	vs SGLang	A100	未公开	不可
ThunderAgent [ref:2602.13692]	Serving	1.48–3.58× serving throughput	vs vLLM+K8s/Autellix	未报告	开源	复现
Pancake [ref:2602.21477]	Serving	E2E throughput 4.29× avg	vs baseline memory ops	未报告	未公开	不可
Saguaro/SSD [ref:2603.03251]	Serving	~30% faster than best SD	vs standard speculative	A100	开源 (MIT)	复现
Helium [ref:2603.16104]	Serving	1.56× vs KVFlow	vs KVFlow/vLLM	未报告	开源	复现
TokenDance [ref:2604.03143]	Serving	2.7× concurrent agents	vs baseline	未报告	未公开	不可
Scepsy [ref:2604.15186]	Serving	2.4× throughput	vs K8s autoscaler	16 GPU	开源	复现
Fleet [ref:2604.15379]	Kernel/Serving	1.3–1.56× decode speedup	vs vLLM on MI350	MI350X	未公开	不可
MoE-LB [ref:moe-lb-interai25]	Serving	12.5% MoE latency reduction	vs prior heuristics	未报告	未公开	不可
FlexRLHF [2312.11819]	Training	11× throughput	vs DeepSpeed-Chat	128×A100	未公开	不可
HybridFlow/veRL [2409.19256]	Training	1.53–20.57× throughput	vs DSChat/OpenRLHF/NeMo	16–64×A100	开源	复现
DeepSeek-V3 [2412.19437]	Training	bubble −60%+, $5.576M total	vs 1F1B	2048×H800	部分	不可
Semantic Router [vllm-project-semantic-router]	Routing	4.2K stars, 20+ signal types	vs simple routers	—	开源	复现
TileRT blog [tilert-speed-scaling-law]	Serving	~10× gap 弥合（理论）	vs traditional frameworks	8×H200	部分	部分

§5 Strength-Weakness Matrix #

系统	Strength	Weakness	Best-for
DualPath	聚合所有 SNIC 带宽，近线性扩展至 1152 GPU	深度绑定 DeepSeek 内部栈，需双网隔离	DeepSeek 级 agentic RL rollout
PPD	零运行时路由开销，稳定性恢复不可用配置	仅 vLLM prototype，offline profiling 需一次性成本	多轮对话 PD serving
DynaServe	统一 colocation/disaggregation，SLO-aware	只支持两路分割，需 RDMA	动态不平衡在线服务
JITServe	可证明竞争比，支持 compound SLO	QRF 冷启动风险，未开源	混合 SLO 多应用部署
TileRT/TokenSpeed	BS=1 极致低延迟，生产验证	不支持 batching，硬件绑定	Agent/TTS/real-time 场景
ZeRO-Prefill	消除 MoE EP 通信瓶颈，1 GPU 即可部署 235B	仅 prefill-only，绑定 NVLink	大规模判别式推理
HybridFlow/veRL	算法灵活 (PPO/ReMax/Safe-RLHF)，zero-redundancy resharding	仅同构 A100，auto-mapping 搜索慢	RLHF 研究和生产训练
TensorHub	消除 trainer stall，线性扩展 pipeline replication	未开源，绑定 Mooncake RDMA	大规模 RL weight distribution
ThunderAgent	程序级调度，lifecycle-aware eviction	架构复杂度高	Agentic batch rollout
Helium	DB-style plan optimization，Templated Radix Tree	需要模板化 workflow	结构化 agent 流水线
KVServe	模块化压缩 + service-aware controller，zero-fork vLLM	不支持 MLA，依赖 nvCOMP	跨 DC 低带宽 PD serving
DeepSeek-V3 DualPipe	all-to-all 完全隐藏，$5.576M 训 671B	2× 参数内存，硬件高度耦合	超大 MoE 预训练

§6 核心 Trade-off 轴 #

轴 1: 延迟 vs 吞吐 #

DynaServe [2504.09285] 的 micro-request 精确量化了此 trade-off: colocation 追求吞吐但 P99 TBT > 300ms，disaggregation 满足 SLO 但 MFU 低至 0.2%。DynaServe 的 Pareto 推进方式是在任意 token 边界动态分割请求。TileRT [tile-ai-tilert] 在 BS=1 走另一极端——彻底放弃 batching 换取 600 tok/s 单请求延迟。

轴 2: 通信隐藏 vs 内存开销 #

DeepSeek-V3 DualPipe [2412.19437] 以 2× 参数内存换取 60%+ bubble 减少和 all-to-all 完全隐藏。DualPath [2602.21548] 以 80GB/node DRAM buffer 换取 storage I/O 瓶颈消除。ZeRO-Prefill [2605.02960] 以每 GPU 保留当前层全部 expert weights 换取消除 AllToAll。三者都遵循"以空间换时间隐藏"范式。

轴 3: 灵活性 vs 性能 #

HybridFlow [2409.19256] 的 hybrid paradigm (single-controller 编排 + multi-controller 计算) vs FlexRLHF [2312.11819] 的静态 placement ratio；TokenSpeed [tokenspeed] 的 Placement 编译器 vs TileRT [tile-ai-tilert] 的 AOT 静态编译。更灵活的系统更容易适配新模型/算法但性能上限稍低。

轴 4: 开源生态 vs 内部优化 #

DeepSeek (DualPath/DualPipe), ByteDance (TensorHub), Moonshot (PrfaaS) 都是内部系统，展示最佳数字但不可复现。vLLM 生态 (KVServe, ZeRO-Prefill, HexGen-Flow) 和 veRL 提供完整复现路径但性能通常落后闭源系统 10–30%。

§7 冲突与调和 #

冲突 1: PPD 声称 append-prefill 干扰仅 2%，DualPath/PrfaaS 依赖 PD 分离的前提是干扰不可接受 #

PPD [2603.13358] 测量 append-prefill 仅造成 2% TPOT 劣化（vs full prefill 的 48%），从而论证 Turn 2+ 可以安全 co-locate。而 DualPath [2602.21548] 和 PrfaaS [2604.15039] 则假设 prefill 必须物理分离到不同节点。

矛盾根源: 规模和模型不同。PPD 在 Llama-3.1-8B + 4×H100 上测量 batch=200 的 append-prefill 干扰；DualPath 在 DeepSeek-660B + 千卡集群上面对 98.7% KV 命中率的 cache-compute ratio = 22 GB/PFLOP。小模型上 append-prefill 确实低干扰，但 MoE 超大模型的 I/O 密集 prefill 干扰模式完全不同——此时瓶颈不是计算干扰而是 storage I/O 带宽。两者在各自实验范围内都正确。

冲突 2: JITServe 声称 SJF/EDF 竞争比可任意差，但 DynaServe 的 local scheduler 仍用 FCFS #

JITServe [2504.20068] 在 Appendix D 严格证明 SJF 和 EDF 对 goodput 无常数竞争比。但 DynaServe [2504.09285] 的 local scheduler 默认用 FCFS。

矛盾根源: 优化目标不同。JITServe 优化 SLO-aware goodput（per-request 级别），DynaServe 优化 serving capacity（系统级别，P99 TBT < 100ms 约束下的最大 QPS）。DynaServe 的 local scheduler 是 SLO-aware batch composition（不是简单 FCFS），其"FCFS"只描述请求入队顺序，实际 batch 组合由 profile table 动态决定。

冲突 3: ZeRO-Prefill 声称 EP AllToAll 是"零价值通信"应消除，但 DeepSeek-V3 和 MFS 的整个设计基于优化 AllToAll #

ZeRO-Prefill [2605.02960] 论证传统 EP 的 AllToAll 是 prefill 瓶颈，用 AsyncEP（按 weight 聚集）完全消除。DeepSeek-V3 [2412.19437] 的 DualPipe 和 MFS [2603.17456] 的 RMLQ 则花大量精力优化和调度 AllToAll。

矛盾根源: Workload 差异。ZeRO-Prefill 仅面向 prefill-only（大 batch、长 compute window），此时 weight AllGather 可被完全隐藏。DeepSeek-V3 的 DualPipe 面向训练（forward+backward 双向），MFS 面向 online serving（低延迟约束）。在 decode 或训练时，per-token compute window 太短无法隐藏 weight AllGather——AllToAll 仍是更优选择。ZeRO-Prefill 自己也承认对 decode 不适用。

§8 Gaps #

基于 taxonomy 的维度组合分析，以下空白点在技术上可解但目前无人做：

Agentic Training (Stage=training × Workload=agentic): 现有 RL 框架 (veRL/FlexRLHF) 不理解 agent workflow 的 DAG 结构。JITServe 的 pattern-graph matching 和 Helium 的 TRT 可以反向引入训练调度。

Cross-DC RL Rollout (Communication × Training): TensorHub [2604.09107] 展示了跨 DC 权重传输，PrfaaS [2604.15039] 展示了跨 DC KV 传输，但没有系统同时解决跨 DC RL rollout 的 weight push + experience pull + KV reuse。

SLO-Aware MoE Prefill Scheduling (Scheduling × MoE × Serving-Interactive): ZeRO-Prefill [2605.02960] 面向 throughput-only prefill，MFS [2603.17456] 面向 SLO-aware 但不改变 MoE 执行策略。将 AsyncEP 与 SLO-aware RMLQ 结合——在 SLO 约束下动态选择 AllToAll vs weight streaming——尚无人尝试。

Multi-Agent Memory + Serving Co-design: Pancake [ref:2602.21477] 解决 agent 记忆索引，TokenDance [ref:2604.03143] 解决 agent KV 共享，但两者未整合。将 vector memory 与 KV cache 统一管理（共享 HBM 预算、统一 eviction 策略）是未探索的组合。

Persistent Kernel + Batching: TileRT/TokenSpeed [tile-ai-tilert] 局限于 BS=1。将 persistent Engine Kernel 扩展到 dynamic batching（在 kernel 内部 batch 大小可变）理论上可行但需要重写 tile scheduler。

AMD MI350 上的 Agentic Serving Framework: Fleet [ref:2604.15379] 提供了 chiplet-aware kernel，但上层缺乏完整的 agentic serving framework（scheduler、KV management、workflow orchestration）。

§9 Practical Recommendation #

场景	推荐系统	原因
DeepSeek 级 MoE 推理 (百卡 RDMA 集群)	DualPath [2602.21548] 的思路 + SGLang EP	DualPath 的 dual-path loading 和 CNIC-centric design 是当前最优，但需要自研。替代方案用 SGLang + Mooncake distributed KV
多轮对话低延迟 serving (几十卡)	PPD [2603.13358] 路由策略 + vLLM PD	Turn 2+ append-prefill 干扰极低，可安全 co-locate 于 decode 节点，减少 75% 网络传输
Agentic batch inference (offline RL rollout)	ThunderAgent [ref:2602.13692] 或 Concur [ref:2601.22705] + SGLang	ThunderAgent 的 program-aware 调度避免 KV thrashing，Concur 的 AIMD admission control 在高并发下更稳健
单请求超低延迟 (AI 编程/TTS/agent 链)	TileRT [tile-ai-tilert] (GLM-5) 或 TokenSpeed [tokenspeed] (Kimi K2.5)	BS=1 tile-level 调度消除所有 kernel 间 idle，600 tok/s 是当前最快
MoE prefill-only 判别式推理	ZeRO-Prefill [2605.02960]	AsyncEP 消除 AllToAll、支持单卡部署 235B，vLLM v0.11 单 flag 启用
RLHF/GRPO 训练 (研究团队)	veRL (HybridFlow) [2409.19256]	开源、算法灵活、auto-mapping、EuroSys 验证
跨 DC 异构推理 (H200 prefill + H20 decode)	PrfaaS [2604.15039] 思路	hybrid attention 模型的 KV 吞吐降 4–13×，跨 DC Ethernet 可行
结构化 multi-agent workflow	Helium [ref:2603.16104] + KVFlow [ref:2507.07400]	Helium 做 plan-level 优化，KVFlow 做 cache 优化，两者互补
混合 SLO 生产集群	JITServe [2504.20068] 中间件 + vLLM	GMAX 提供可证明 goodput 保证，仅需几行 API 修改
跨框架配置优化	AIConfigurator [ref:2601.06288] 思路	不跑 GPU 即可预测 TPOT 并搜索最优并行配置

§10 参考 #

ID	Title	Date	Venue/Status
2602.21548	DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference	2026-02	arXiv
2603.13358	Not All Prefills Are Equal: PPD Disaggregation for Multi-turn LLM Serving	2025-03	arXiv
2603.17456	MFS: Multi-stage Flow Scheduling for LLM Serving	2026-03	arXiv
2604.09107	TensorHub: Scalable and Elastic Weight Transfer for LLM RL Training	2026-04	arXiv
2604.15039	PrfaaS: KVCache of Next-Generation Models Could Go Cross-Datacenter	2026-04	arXiv
2605.02960	ZeRO-Prefill: Zero Redundancy Overheads in MoE Prefill Serving	2026-05	arXiv
tilert-speed-scaling-law	Speed as the Next Scaling Law (TileRT blog)	2026-05	Blog
kvserve	KVServe: Service-aware KV-cache Compression	2026-05	GitHub
tile-ai-tilert	TileRT: Tile-Based Runtime for Ultra-Low-Latency LLM Inference	2026-05	GitHub
tokenspeed	TokenSpeed: Speed-of-Light LLM Inference Engine	2026-05	GitHub
vllm-project-semantic-router	vLLM Semantic Router	2026-05	GitHub
2312.11819	FlexRLHF: Adaptive Placement and Parallelism for RLHF Training	2023-12	arXiv
2409.19256	HybridFlow (veRL): A Flexible and Efficient RLHF Framework	2024-09	EuroSys'25
2412.19437	DeepSeek-V3 Technical Report	2024-12	arXiv
2504.09285	DynaServe: Unified and Elastic Execution for LLM Serving	2025-04	arXiv
2504.20068	JITServe: SLO-aware LLM Serving with Imprecise Request Information	2025-04	arXiv
2505.05286	HEXGEN-FLOW: Optimizing Scheduling for Agentic Text-to-SQL	2025-05	arXiv
2507.07400	KVFlow: Efficient Prefix Caching for Multi-Agent Workflows	2025-07	arXiv
2509.02121	Halo: Batch Query Processing for Agentic Workflows	2025-09	arXiv
2510.17015	Justitia: Fair and Efficient Scheduling for LLM Applications	2025-10	arXiv
2511.01633	GLM: Graph Chain-of-Thought with Efficient LLM Serving	2025-11	PVLDB'26
2601.06288	AIConfigurator: Lightning-Fast Configuration Optimization	2026-01	arXiv
2601.12967	Sutradhara: Orchestrator-Engine Co-design for Agentic Inference	2026-01	arXiv
2601.22705	Concur: Proactive Agent-Level Admission Control	2026-01	arXiv
2602.13692	ThunderAgent: Program-Aware Agentic Inference System	2026-02	arXiv
2602.21477	Pancake: Hierarchical Memory System for Multi-Agent Serving	2026-02	arXiv
2603.03251	Saguaro: Speculative Speculative Decoding	2026-03	arXiv
2603.16104	Helium: Efficient LLM Serving for Agentic Workflows	2026-03	arXiv
2604.03143	TokenDance: Scaling Multi-Agent via Collective KV Cache Sharing	2026-04	arXiv
2604.15186	Scepsy: Serving Agentic Workflows Using Aggregate LLM Pipelines	2026-04	arXiv
2604.15379	Fleet: Hierarchical Task-based Megakernels on Multi-Die GPUs	2026-04	arXiv
moe-lb-interai25	Latency-Optimal Load Balancing for Distributed MoE Inference	2025	InterAI'25 Workshop