JITServe vs 相关论文：跨篇综合 #

相关论文 #

本篇选取 8 篇相关工作，覆盖 SLO 感知调度、PD 分离架构、网络流调度、MoE prefill 优化、KV-cache 压缩、RL 训练传输和低延迟 kernel 执行，与 JITServe 在"serving 系统如何处理多样化 SLO"这一核心问题上形成多维对比。

DualPath (2602.21548) — 在 PD 分离推理架构中解决存储带宽单点瓶颈。DualPath 聚合 decode engine 空闲 SNIC 带宽加载 KV-Cache，配合 CNIC-centric 流量隔离和自适应调度，实现 agentic workload 下 1.87× 离线吞吐提升 [2602.21548]。与 JITServe 的关联：两者都面向 agentic workload 但处于不同栈层——DualPath 优化 I/O 数据通路（KV-Cache 如何搬运），JITServe 优化请求调度策略（哪些请求先获得 GPU 时间）。DualPath 的 DeepSeek 生产 trace 验证了 agentic workload 的 KV-Cache 命中率 98.7%、平均 157 轮，为 JITServe 的 compound 请求 pattern graph matching 提供了真实工作负载印证。

PPD (2603.13358) — 在 PD 分离架构下动态路由 multi-turn 请求的 append-prefill。PPD 观察到 append-prefill 仅造成 2% TPOT 劣化（vs full prefill 的 48%），用 offline-profiled scoring function 实现 per-request 路由决策，Turn 2+ TTFT 降低 48–73% [2603.13358]。与 JITServe 的关联：两者都处理"多轮请求的 SLO 最优路由"，但层次不同——PPD 决定请求在 P/D 节点之间的物理路由，JITServe 决定请求在 batch 内的优先级排序。PPD 的 scoring function $S = w_{\text{ttft}}\Delta_{\text{ttft}} - w_{\text{tpot}}\Delta_{\text{tpot}}$ 是一个简化版的 SLO trade-off 框架，JITServe 的 GMAX 将其扩展到三类 SLO 的统一优先级排序。

MFS (2603.17456) — 解决 disaggregated MoE serving 中三阶段通信的网络争用。MFS 通过反转经典 MLFQ 的 Reverse Multi-Level Queue 实现 Defer-and-Promote 策略，无需精确 laxity 即可近似 Least-Laxity-First 调度，TTFT SLO 达标率提升 1.2×–2.4× [2603.17456]。与 JITServe 的关联：MFS 和 JITServe 是当前 SLO-aware serving 调度的两个对偶方案——MFS 在网络层做 flow-level 调度（per-packet 优先级），JITServe 在请求层做 batch-level 调度（per-request 优先级）。两者面对同一个基本难题：SLO deadline 在系统推进过程中逐步具体化。MFS 用 MLU（Minimal Link Utilization）量化 flow 紧迫度，JITServe 用 margin goodput 量化请求价值——两者的 "just-in-time" 调度哲学完全一致。

TensorHub (2604.09107) — RL 训练中 trainer→rollout 的权重传输系统。TensorHub 提出 Reference-Oriented Storage，用 RDMA 直传消除数据所有权，pipeline replication 实现线性带宽扩展，6.7× standalone stall 减少 [2604.09107]。与 JITServe 的关联较间接：两者都服务于 agent/RL 工作负载的不同阶段——TensorHub 解决训练侧权重分发，JITServe 解决推理侧请求调度。JITServe 的 compound 请求模式（deep research / multi-agent）正是 TensorHub 所训练的 agent 模型在生产推理时产生的。

PrfaaS (2604.15039) — 将 PD 分离从单集群 RDMA 扩展到跨 DC Ethernet。PrfaaS 利用混合注意力压低 KV 吞吐到 ≈3 Gbps，配合长度阈值路由 $t$ + 双时间尺度调度，实现 +54% 吞吐 [2604.15039]。与 JITServe 的关联：PrfaaS 的长度阈值路由是 JITServe QRF 预测的一个极端简化——PrfaaS 用单一阈值 $t$ 做二元路由决策，JITServe 用 QRF 分位数做连续优先级排序。PrfaaS 的 Eq.7 双臂 balance 条件 $\Theta_{\text{prfaas}}/p = \Theta_{\text{pd-p}}/(1-p)$ 是吞吐优化目标；JITServe 的 GMAX 是 goodput 优化目标——两者在"throughput vs goodput"的目标函数选择上构成有意义的对比。

ZeRO-Prefill (2605.02960) — 通过反转 MoE 数据流方向（weight 聚集替代 activation 路由）消除 prefill serving 的三重冗余。ZeRO-Prefill 用 AsyncEP 的后台 D2D AllGather 替代每层同步 AllToAll，配合 frontend 饱和阈值 $T$ 保证 overlap，在 Qwen3-235B 上实现 1.35–1.37× 吞吐 [2605.02960]。与 JITServe 的关联：ZeRO-Prefill 面向 prefill-only 判别式工作负载（分类、审核），JITServe 面向混合在线工作负载（chat + agent + deep research）。两者在 "batch formation" 策略上有结构性对比——ZeRO-Prefill 的 frontend 用物理量 $T$ 保证每 GPU compute window 足够大，JITServe 的 GMAX 用 input-length 滑动窗口保证 batch 内长度同质。

TileRT (tilert-speed-scaling-law) — AOT 编译将模型展开为单个 Persistent Engine Kernel，以 tile 为调度粒度消除 inter-kernel idle。TileRT 解决近 BS=1 decode 下理论 ≈1000 tok/s 与实际几十 tok/s 的量级差距 [tilert-speed-scaling-law]。与 JITServe 的关联：TileRT 和 JITServe 分别在栈的两端优化延迟——TileRT 在 kernel/device 层压缩 per-token 执行时间，JITServe 在 scheduler 层压缩请求等待时间。JITServe Figure 8 揭示的 "batch 内长度异质导致 per-token 变慢（即使用 Flash Decoding）" 是 TileRT 的异构 worker 特化可能直接解决的问题。

KVServe (kvserve) — Service-aware KV-cache 压缩框架，以 vLLM external connector 形式实现。KVServe 通过三阶段模块化 pipeline + ε-greedy bandit 在线 controller 实现 up to 10x KV 压缩、9x PD 通信加速 [kvserve]。与 JITServe 的关联：两者都采用 "service-aware + 在线自适应" 的设计哲学——KVServe 根据实时带宽动态选择压缩策略（Theorem 1: $B < (1-1/cr) \cdot S$ 判据），JITServe 根据实时生成进度动态精化长度预测（QRF 每 50 token 重新调用）。KVServe 的 analytical model 给出 go/no-go 判据，JITServe 的 GMAX 给出可证明竞争比——两者的理论基础程度形成对比。

本篇 vs 相关论文的 delta #

JITServe 的核心 delta 是 Goodput-as-first-class-objective + imprecise-info-tolerant scheduling——在请求长度和依赖图均不精确的条件下，用"保守上界估计 + 在线精化 + GMAX 两步解耦调度"实现可证明竞争比的多类型 SLO 调度。

JITServe vs MFS — SLO 调度的对偶方案。JITServe 在请求-batch 层做 SLO-aware 调度 [2504.20068]，MFS 在网络-flow 层做 SLO-aware 调度 [2603.17456]。两者的 "just-in-time" 设计哲学高度一致但作用域互不重叠：JITServe 的 GMAX 决定哪些请求进入当前 batch，MFS 的 RMLQ 决定哪些 flow 获得当前链路带宽。MFS 的 Defer-and-Promote（P2D flow 初始低优先级、MLU 驱动 promote）与 JITServe 的 margin goodput（按 goodput/t_gen 排序后 top-p 过滤）在哲学上是同一个思想的不同投影：资源只在"刚好需要"时才分配给请求。MFS 通过 earliness→0 验证了 just-in-time 的实现效果 [2603.17456]，JITServe 通过 oracle gap 3–9% 验证了类似效果 [2504.20068]。关键差异：MFS 不需要预测请求长度（flow 大小在发送前已知），JITServe 必须处理长度不确定性——QRF 预测是 JITServe 的独有组件。但 MFS 也面对自己的不确定性——background traffic $\rho$ 只能保守估计 [2603.17456]。

JITServe vs PPD — 多轮请求管理的两个切面。PPD 解决的是多轮对话中 KV-Cache 重复传输的物理效率问题，JITServe 解决的是多轮/多阶段请求的 SLO 管理问题。PPD 的 scoring function $S = w_{\text{ttft}}\Delta_{\text{ttft}} - w_{\text{tpot}}\Delta_{\text{tpot}}$ [2603.13358] 考虑两个 SLO 维度的 trade-off，JITServe 的 GMAX 考虑三类 SLO 的统一优先级排序 [2504.20068]。PPD 的核心发现——append-prefill 仅造成 2% TPOT 劣化 [2603.13358]——为 JITServe 的 compound 请求处理提供了互补优化：如果 compound 请求的后续阶段被路由到 decode 节点本地执行（PPD 方式），JITServe 的 pattern graph 分配的 sub-deadline 可以更宽松，因为省去了 KV 传输延迟。两者在 PD 分离架构下可以叠加。

JITServe vs PrfaaS — 长度路由的复杂度光谱。PrfaaS 用长度阈值 $t$ 做二元路由（$L > t$ → PrfaaS 集群，$L \leq t$ → PD 集群），通过 Eq.7 的单调性唯一确定最优 $t^*$ [2604.15039]。JITServe 用 QRF 预测连续分位上界，每 50 token 精化 [2504.20068]。PrfaaS 的方案更简单、更可证明（Eq.7∩Eq.8 的 closed-form 解），但只优化吞吐（$\Lambda_{\max}$），不直接关心 per-request SLO。JITServe 的方案更复杂但覆盖三类 SLO 的 goodput 优化。PrfaaS 的 $t$ 作用于 prefix-match-aware 增量长度（非原始长度）[2604.15039]——这个细节与 JITServe 的 QRF 预测形成对比：QRF 预测的是完整 response 长度上界，而非增量长度。在 agentic workload 高 prefix 命中率下（DualPath 报告 98.7% [2602.21548]），两种 "长度" 的定义差异会显著影响路由决策。

JITServe vs ZeRO-Prefill — Batch formation 的两种约束。ZeRO-Prefill 的 frontend 用 $T = t_{\text{EP}} \times F_{\text{GPU}} \times \gamma$ 保证每 GPU 的 compute window 足以隐藏 weight AllGather [2605.02960]；JITServe 的 GMAX 用 input-length 滑动窗口保证 batch 内长度同质以提升 Flash Decoding 效率 [2504.20068]。两者的 batch formation 约束正交可组合：如果场景是 MoE 模型的 prefill-only serving，可以同时满足 ZeRO-Prefill 的饱和约束（FLOPs ≥ T）和 JITServe 的长度同质约束（滑动窗口分组）。ZeRO-Prefill 的 $T$ 是物理量、启动时一次标定 [2605.02960]；JITServe 的 GMAX 参数（$p$ 阈值、$\delta$ 抢占阈值）需要运行时调整——前者更 robust，后者更 adaptive。

JITServe 的独有增量：

1. 首个统一三类 SLO 的调度框架——latency-sensitive、deadline-sensitive、compound 请求在同一 GMAX 优先级公式中处理。DualPath/PPD/MFS/PrfaaS 各自只覆盖一到两类 SLO [2504.20068]。
2. 可证明竞争比的在线调度——$\approx 1/8.55$ 的常数竞争比在所有对照论文中独一无二。MFS 近似 LLF 但无形式化保证 [2603.17456]。PrfaaS 的 Eq.7 最优性限于稳态吞吐 [2604.15039]。
3. Imprecise-info-tolerant 的 QRF + pattern graph——用保守上界容忍预测不精确，每 50 token 精化逐步收紧。没有任何对照论文系统性处理"长度未知"的调度难题——MFS 的 flow 大小在发送前已知 [2603.17456]，PrfaaS 假设输入长度已知 [2604.15039]，PPD 假设 workload descriptor $\psi$ 可映射到最近网格点 [2603.13358]。
4. Pattern graph matching 为 compound 请求分配 sub-deadline——这是 multi-agent / deep research 场景下 E2E deadline management 的首个实用方案。DualPath 的 trace 证实了此类工作负载的存在性和规模（157 轮/trajectory）[2602.21548]，但 DualPath 不做 deadline 管理。

可攻击面 #

以下攻击针对 JITServe L2 论证链中的具体声明。

Attack 1: QRF "7ms + 不会低估"的声明在分布偏移下脆弱 (L2 §核心三问)

JITServe 声称 QRF 推理 7ms、比 BERT 快 7×，且提供不会低估的保守上界 [2504.20068]。但 QRF 的上界保证依赖训练集覆盖目标分布——对全新模型（如 Qwen3-MoE 首次上线）或全新应用（首次出现的 agent workflow），QRF 训练数据不存在，上界估计会退化为无信息先验。论文未量化冷启动期的精度退化。对比 KVServe 的 service-aware controller：KVServe 用 ε-greedy bandit 在线学习系统性残差 [kvserve]，至少有明确的收敛机制；JITServe 的 QRF 是离线训练的，论文未提供 re-training 频率或 online adaptation 机制。更严重的是，Figure 13 的 3–9% oracle gap 是在作者选定的 workload 上测得——这些 workload 的响应长度分布很可能被 QRF 训练集覆盖。在真实生产中，reasoning 模型（o1/R1 风格）的 "thinking" 阶段长度高度不可预测且可达数万 token，QRF 的分位回归在这种 heavy-tailed 分布上会系统性低估——此时 3–9% gap 可能放大到数十个百分点。

Attack 2: "SJF/EDF 竞争比可任意差"的理论结果对实践的指导意义有限 (L2 §Key Findings)

JITServe 在 Appendix D.1 构造对抗工作负载证明 SJF/EDF 的竞争比 OPT/SJF → ∞ [2504.20068]。但这些对抗构造需要精心设计的请求模式——一个高 goodput 长任务 + N 个紧 deadline 短任务。在真实生产工作负载中，请求到达模式不太可能精确匹配这些对抗序列。MFS 的实验表明，在真实 agent workload 下 EDF 的 SLO 达标率并非"任意差"，只是比 MFS 低 1.2×–2.4× [2603.17456]——这是有限的、可量化的差距，不是"发散到无穷"。JITServe 的 $\approx 1/8.55$ 竞争比虽然有界，但 1/8.55 ≈ 12% 意味着理论下界只保证 JITServe 在最差情况下达到 OPT 的 12%——这个保证在实践中几乎没有指导意义。论文实际性能远好于此（距 oracle 仅差 3–9%），说明竞争比是一个过度悲观的 worst-case bound，其学术价值大于工程价值。

Attack 3: Batch 内长度异质的硬件根因可能被新硬件消解 (L2 §Key Findings)

JITServe 声称 batch 内混合长输入和短输入会显著减慢 per-token 速度（Figure 8），这是 GMAX 强制长度同质分组的硬件原因 [2504.20068]。但该实验在 A100 上进行。H100/H200 的 TMA (Tensor Memory Accelerator) + dynamic shapes 可能大幅降低 ragged batch 的效率损失。TileRT 的 tile-level scheduling 直接在 kernel 内部处理异构工作负载 [tilert-speed-scaling-law]，如果 TileRT 或类似技术成为主流执行引擎，GMAX 的"长度同质"约束将失去硬件动机——变成一个解决已消失问题的方案。ZeRO-Prefill 在 H100/H200 上的评估表明，大 batch prefill 的 MFU 可达 29.8–36.2% [2605.02960]，暗示新硬件的计算利用率对长度异质的敏感度可能已降低。

Attack 4: Pattern graph 的 "500 graphs 足够" 假设在 truly novel workflow 下不可外推 (L2 §Deep Analysis)

JITServe 用 K-medoids 聚类 + Gaussian-kernel 相似匹配在 500 个历史图中找最相似的执行图，匹配准确率 > 80% [2504.20068]。但 deep research 和 multi-agent workflow 的图结构极度多样——DualPath 的 trace 显示 agent 平均 157 轮 [2602.21548]，每轮的 tool call 可选 branching factor 远大于 chatbot。对于 truly novel 的 workflow（首次出现的图结构），pattern graph matching 退化到"匀分 sub-deadline"——相当于 EDF 的简化版。论文没有评估 "匀分 sub-deadline" 的 goodput 损失，也没有评估 K-medoids 的更新策略在图空间快速演化时是否会 drift。PrfaaS 的方案在此维度上反而更鲁棒：长度阈值 $t$ 不依赖历史模式 [2604.15039]。

Attack 5: "非侵入中间件"声明掩盖了 SLO 参数的外部依赖 (L2 §Deep Analysis)

JITServe 声称只需几行 API 改动即可集成 vLLM [2504.20068]，但每个请求必须提供 deadline/target_tbt/target_ttft/waiting_time 四个 SLO 参数。在实际部署中，这些参数的设定极为困难：(a) 用户通常不知道自己的 SLO 偏好（Table 1 的用户调查是学术场景），(b) compound 请求的 E2EL deadline 需要了解 workflow 全局结构才能合理设定，(c) 不同 tenant 的 SLO 可能冲突。PPD 的 operator-level 权重 $(w_{\text{ttft}}, w_{\text{tpot}})$ 虽然也是外部输入，但只有两个参数且作用于系统级而非 per-request [2603.13358]。MFS 的 TTFT deadline 由 application 自然定义（agentic pipeline timeout）[2603.17456]。相比之下，JITServe 把四个参数的负担推给了 developer——这在生产中可能导致"参数设错不如不设"的境况。

Attack 6: 与 PD 分离架构的兼容性未验证 (L2 §Limitations)

JITServe 仅在 16×A100 + vLLM（non-disaggregated）上评估 [2504.20068]。但 2025-2026 年的 serving 趋势是 PD 分离（DualPath、PPD、PrfaaS 都基于此架构）。GMAX 的 frame 模型假设 batch size 在一个 $\Delta$ 内近似恒定——若换成 PD 分离的异步 prefill+decode pipeline，$\text{bw}_\Delta$ 的定义需要重写。DualPath 论证了 PD 分离在 agentic workload 下的 TTFT 显著受 I/O 限制 [2602.21548]——在此架构下，JITServe 的 request-level scheduling 可能被更下层的 I/O bottleneck 遮蔽。论文的 "Bottleneck Shift" 分析（L2 §7c）将瓶颈推到"SLO-estimation bound"，但这只在 non-disaggregated vLLM 上成立；PD 分离后可能回退到 "I/O bound" 或 "network contention bound"（MFS 的发现 [2603.17456]）。

生态位 #

范式定位：JITServe 标志着 LLM serving 调度从 Phase 1（吞吐优先：vLLM FCFS、continuous batching）和 Phase 2（延迟优化：chunked prefill、Sarathi-Serve）进入 Phase 3（goodput-as-objective：多类型 SLO + 信息不确定性容忍） [2504.20068]。这个范式转移的驱动力是 agent/deep research/multi-agent 工作负载的爆发——它们把 SLO 空间从一维（TBT）扩张到三维（TBT × E2EL × compound-E2EL）。JITServe 是首个在学术上正式定义并攻克这个三维调度问题的系统。

但 JITServe 的范式定位也暴露了两个结构性局限：(1) 与 PD 分离架构的正交性——JITServe 在 scheduler 层操作，而 DualPath [2602.21548]、PPD [2603.13358]、MFS [2603.17456]、PrfaaS [2604.15039] 都在 PD 分离这一更底层的架构维度上创新。JITServe 的中间件定位使它理论上可以叠加在 PD 分离之上，但论文缺乏验证；(2) SLO 参数的外部化——JITServe 不自己推断 SLO，所有分析假设 developer 提供参数。在 cloud-native 多租户场景下，SLO 推断和 fairness isolation 是更大的未解决问题。

与相邻方案的生态位对比：

生态位	方案	JITServe 相对优势	JITServe 相对劣势
SLO-aware 请求调度	Autellix / LTR	三类 SLO + 可证明竞争比 + QRF	未开源、实验规模较小 (16×A100)
SLO-aware 网络调度	MFS	与 MFS 正交可组合	MFS 不需要预测长度，更少假设
Multi-turn SLO 路由	PPD	覆盖 compound 请求（PPD 只做 Turn 2+ routing）	PPD 更轻量、更容易集成
跨 DC 资源调度	PrfaaS	Goodput 目标 vs 吞吐目标	PrfaaS 有 closed-form 最优解
Prefill throughput	ZeRO-Prefill	在线 SLO 感知 vs 离线批吞吐	ZeRO-Prefill 的物理量 $T$ 更鲁棒
I/O 路径优化	DualPath / KVServe	正交互补——调度层不碰 I/O	DualPath 有千 GPU 级生产验证
执行层加速	TileRT	正交互补——调度层不碰 kernel	TileRT 有生产部署
RL 训练传输	TensorHub	不同领域，共享 agent 场景	TensorHub 有千 GPU 级部署

采纳信号：

• 正面：(1) deadline/target_tbt 等 SLO API 与 OpenAI 风格一致，被采纳概率较高；(2) 中间件设计、集成门槛低（几行 API 改动）；(3) 3–9% 距 oracle 定义了该问题的上限，给后续论文建立了 benchmark；(4) 被 AdaServe / Autellix 后续论文列为对照组
• 障碍：(1) 未开源 QRF 训练 pipeline 和 pattern graph 数据——最大落地门槛；(2) 仅在 A100 + vLLM non-disaggregated 上验证，未覆盖 H100/H200 或 PD 分离架构；(3) 四个 per-request SLO 参数的设定负担；(4) 没有 multi-tenant fairness 和计费模型讨论

定位判断：JITServe 在混合工作负载（chat + agent + deep research）共享单一 GPU 集群的场景下价值最大——此时三类 SLO 共存且请求长度高度不确定，GMAX 的 goodput 优化直接转化为资源节省（28.5%–83.2%）[2504.20068]。但随着 serving 架构向 PD 分离 + 跨 DC 演进（DualPath、PrfaaS 方向），JITServe 必须证明其调度策略在新架构下仍然 load-bearing——否则将被更架构感知的方案（MFS + PPD + PrfaaS 的组合）替代。

未探索方向 #

方向 1: JITServe + MFS 联合调度——请求层与网络层的协同。JITServe 在请求层做 GMAX batch formation [2504.20068]，MFS 在网络层做 RMLQ flow scheduling [2603.17456]，两者在 PD 分离 MoE serving 中是正交互补的。当前两个系统独立运行——GMAX 选出 batch 后交给 vLLM 执行，MFS 在 NCCL/Mooncake 层拦截通信 flow 做优先级排序。联合优化的契机：GMAX 在选 batch 时如果考虑当前网络争用程度（MFS 可提供 MLU 信息），就可以避免在网络拥塞时选入过多长请求——因为长请求的 KV-Cache P2D 传输会进一步加剧争用。具体接口：MFS 的 centralized coordinator 向 JITServe scheduler 暴露 per-link MLU snapshot，JITServe 在 GMAX 滑动窗口评估中加入 "network-aware" 惩罚项。这可以将 TTFT SLO 达标率的改善从 MFS 的 1.2×–2.4× 和 JITServe 的 1.4×–6.3× 叠加为乘性收益。

方向 2: PD 分离架构下的 GMAX 重定义。JITServe 的 GMAX 假设 batch size 在一个 frame $\Delta$ 内恒定 [2504.20068]，这在 PD 分离下不成立——prefill 和 decode 在不同节点异步执行，batch size 是分别管理的。重定义路径：将 GMAX 拆分为 P-GMAX（prefill 端 batch formation，优化 TTFT goodput）和 D-GMAX（decode 端 batch management，优化 TBT goodput），两者通过 KV transfer queue 耦合。P-GMAX 可吸收 PrfaaS 的长度阈值路由思想（对跨 DC 请求用简化版 GMAX）[2604.15039]，D-GMAX 可吸收 PPD 的 append-prefill 干扰模型（Turn 2+ 请求在 D 节点本地执行时的 TPOT 影响）[2603.13358]。这本质上是将 JITServe 从 non-disaggregated 中间件升级为 PD-native 调度系统。

方向 3: QRF 的 online adaptation + KVServe 的 bandit 融合。JITServe 的 QRF 是离线训练的，对分布偏移缺乏适应性 [2504.20068]。KVServe 的 ε-greedy bandit 用 EWMA 在线学习 analytical model 的系统性残差 [kvserve]。融合方向：在 QRF 预测的基础上加一层 bandit 残差校正——bandit 观察 QRF 预测与实际长度的偏差 pattern，按 (模型版本, 应用类型, prompt 特征) 分桶学习系统性偏差。这将 JITServe 的冷启动问题从"需要完整 QRF 训练集"降级为"需要数百个在线样本的 bandit 收敛"——显著降低新模型/新应用的部署门槛。KVServe 的 profile library（按 accuracy × bandwidth 分桶）可以类比为 JITServe 的"预测精度 × 请求类型"分桶。

方向 4: Pattern graph matching 与 TensorHub 的 RL 训练联合优化。JITServe 的 pattern graph 在推理时匹配历史 agent workflow 图 [2504.20068]；TensorHub 在训练时为 agent 模型提供权重更新 [2604.09107]。联合方向：在 RL 训练的 rollout 阶段，每个 trajectory 自然产生新的 workflow 图——这些图可以实时注入 JITServe 的 pattern graph 库，使推理时的图匹配始终紧跟最新的模型行为模式。具体路径：TensorHub publish 新模型权重后，rollout engine 在新权重下生成 trajectories，trajectory 的 (工具调用序列, 阶段时长分布) 被压缩为 pattern graph 并同步到 JITServe 的 graph 库。这形成了"训练产生行为模式 → 推理利用行为模式"的闭环，消除了 JITServe 对历史数据的依赖。

方向 5: TileRT 的异构 worker + JITServe 的长度分组消除 ragged batch 问题。JITServe 强制 batch 内长度同质以避免 Flash Decoding 效率损失 [2504.20068]，但这以牺牲调度灵活性为代价。TileRT 的 tile-level scheduling + warp specialization 可以在 kernel 内部处理异构工作负载 [tilert-speed-scaling-law]——如果 TileRT 的 Engine Kernel 能高效处理 ragged batch，JITServe 的 GMAX 就可以移除滑动窗口约束，仅保留 top-p 过滤的 goodput 保证。这将简化 GMAX 为单步决策（去掉二步解耦中的第二步），同时放宽竞争比分析中 $p$ 引入的乘法损失。但需要验证：TileRT 在 ragged batch 下的 per-token 延迟是否确实优于 length-homogeneous batch 下的 Flash Decoding——如果 TileRT 的 warp specialization overhead 超过 ragged batch penalty，则融合无益。