HEXGEN-FLOW: Optimizing LLM Inference Request Scheduling for Agentic Text-to-SQL #

You Peng, Youhe Jiang, Wenqi Jiang, Chen Wang, Binhang Yuan (HKUST / ETH Zurich / Tsinghua) | 2025-05 | https://arxiv.org/abs/2505.05286 Category: framework | Tags: request-scheduling, agentic, SLO-aware, heterogeneous-GPU, text-to-sql Read: 2026-04-18 GitHub: https://github.com/Relaxed-System-Lab/Hexgen-Flow

Core Contribution #

一个专门针对多阶段 agentic Text-to-SQL 工作流的两层调度器 HexGen-Flow——顶层做"异构 GPU + 工作负载平衡"的任务派发，底层在每个模型实例内做"基于剩余 SLO 预算"的紧急度优先队列——把已有 vLLM/VTC/QLM 在独立请求上的调度范式升级到"带阶段依赖 + 端到端 SLO"的 agentic workflow 调度。

Summary #

动机：CHESS 这类 Agentic Text-to-SQL 系统把一个用户查询拆成 schema linking → SQL candidate generation → self-correction (多轮) → evaluation 四个阶段，单个端到端 query 平均触发约 19–21 次 LLM 调用（方差 12–16，反映不同查询复杂度差异巨大）。工业环境里 GPU 天然是异构的（A100 / A6000 / L40 混用），而 vLLM/TGI/TensorRT-LLM 都把每个 LLM 请求看作独立任务，用 FCFS + round-robin + continuous batching 调度，既不懂"阶段之间的前后依赖"，也不懂"把重活给强卡、轻活给弱卡"，更不懂"这个请求距离端到端 SLO 还有多少预算"。

方法：HexGen-Flow 设计了一个层次化调度器。全局协调器用一个加权打分函数 Score(q,m) = (1-α)·β/t_queue - α·t_comp 选择模型实例，用 α 调节"把任务给最快的卡 vs. 平衡负载"之间的权衡，并用轻量 CPU 端仿真器每 100s 重调一次 α*。本地优先队列动态给每个 LLM 请求分配 SLO 预算 t_SLO_{i,j} = (T_SLO_i - τ_elapsed) · t̄_comp_{i,j} / Σ t̄_comp_{i,k}，然后按紧急度 U_{i,j} = t_comp - (t_SLO_{i,j} - τ_queuing) 排序，让 SLO 快要违约的请求抢占执行。上游阶段超时的"债务"会自动传播到下游，导致后续请求获得更紧的预算和更高的紧急度。

结果：在 CHESS + Llama3.1-70B + BIRD-bench 基准上，跨 3 种部署（Hetero-1、Hetero-2、Homo）和 3 条 trace，相比 vLLM/VTC/QLM，HexGen-Flow 把 P95 tail latency 降低 1.42~1.56×，吞吐提升 1.49~1.81×。消融实验显示 WB（workload-balanced dispatch）和 PQ（priority queue）各贡献约 10-48% P95 降低；α-tuning 的仿真开销只有 115-158s，可在生产环境周期性调整。在 Qwen3-30B + MAC-SQL + Spider 上泛化验证依然有 34-38% P95 改进。

Key Findings #

• 阶段依赖感知是 agentic serving 的一阶优化——仅把"端到端 SLO 按阶段成本比例切分预算"这一步就能带来 10.5-48% 的 P95 改进。
• 异构 GPU 下，纯 round-robin 反而伤害性能：case study 显示 WB 把 57.5% 的 Stage-2 重请求路由到 A100（RR 只有 18.1%），把轻量 Stage-1 更多推给 L40，实现计算/硬件对齐。
• α 的最优值随硬件+负载漂移：Hetero-1 最优 α∈[0.1, 0.2]，Hetero-2 最优 α∈[0.3, 0.4]，说明"task suitability vs. load balancing"的平衡点不是静态的，必须在线 auto-tune。
• 轻量 CPU 仿真器足以做参数调优：115-158s 仿真即可扫完 α∈{0, 0.1, ..., 1.0} 网格，远小于工作负载漂移的 hour 级时间尺度。
• Urgency 优先队列会做"看似违反 FCFS"的决策：case study 里队列第 6 号请求虽然在 22s 之后才到，但紧急度 26.9 远高于 1 号（14.5），于是被调度器优先执行，正是这种"不公平"反而拉高 SLO attainment。
• 通用性：换 agentic 框架（CHESS→MAC-SQL）和模型（Llama3.1-70B→Qwen3-30B）依然保持 34-38% P95 改进，暗示这套调度范式不仅限于 Text-to-SQL。

Key Figures #

Figure 1: Agentic Text-to-SQL 工作流 #

What it shows: 一次 Text-to-SQL 查询如何被拆成 schema linking → candidate generation → self-correction → evaluation 四个阶段，阶段之间有明确的前后依赖和并行分支。

Why it matters: 是本文 motivation 的核心图——把"1 个用户查询 ≈ 20 次带依赖的 LLM 调用"直观化，解释了为什么独立请求调度器注定失败。

Detailed description: Schema linking 先做 entity-to-column 映射；generation 阶段并行发起多个 prompt 生成候选 SQL；self-correction 在数据库上执行候选、出错则迭代修正（最多 10 轮），这是长尾延迟的主要来源；evaluation 生成单元测试并评分选最优 SQL 返回用户。

Figure 2: HexGen-Flow 系统架构 #

What it shows: 顶部是全局协调器（global coordinator）负责 workload-balanced dispatch，底部是多个异构 GPU 上的模型实例，每个实例维护一个本地优先队列。不同颜色代表来自不同阶段的请求。

Why it matters: 展示了 HexGen-Flow 的核心创新——two-level scheduling 的解耦：全局做"空间分配"（哪个 instance 执行），本地做"时间排序"（什么时候执行）。

Detailed description: 左侧是 Text-to-SQL 多租户请求流入；coordinator 为每个请求查询所有 instance 的 score，将其派发到得分最高的 instance；每个 instance 维持自己的 priority queue，按 urgency 动态重排。coordinator 还跟踪每个 query 的 stage-completion 状态，保证依赖正确、完成即触发后续 stage 并回传剩余预算。

Figure 3: SLO Budget 动态重分配 #

What it shows: 当 q_{i,1} 的实际执行时间超出预算 10ms 时，这个"债务"通过 τ_elapsed 的更新回传，导致后续的 q_{i,2} 获得更紧的 SLO 预算。

Why it matters: 这张图是理解"为什么上游超时会让下游更紧急"的关键——它说明 HexGen-Flow 的 urgency metric 本身是一个闭环控制器，能自动吸收估计误差。

Detailed description: 横轴是时间；竖轴展示三个阶段的 SLO 预算分配。q_{i,1} 原本被分配 40ms，实际耗时 50ms；剩余时间 = T_SLO - τ_elapsed 变小，按 t̄_comp 比例重分配后，q_{i,2} 的预算从原计划缩短，其 urgency 相应升高。

Figure 4: End-to-End SLO 达成率对比 #

What it shows: 跨 3 条 trace × 2 种异构配置 × 2 种请求速率，HexGen-Flow vs. vLLM/VTC/QLM 的 95% SLO attainment 所需 SLO scale。

Why it matters: 主实验结果——HexGen-Flow 始终用更小的 SLO scale 达到 95% attainment，差距最大达 56.2%（P95 latency 维度）。

Detailed description: x 轴为 SLO scale（exclusive 执行时间的倍数），y 轴为 SLO attainment %。所有子图中 HexGen-Flow 曲线始终最左（需要最小的 SLO scale 即能跨过 95% 线），vLLM 最差（需要 5.4x），HexGen-Flow 仅需 3.5x（Trace 1, Hetero-1, 0.5 QPS）。

Figure 9: 消融实验（WB vs. PQ） #

What it shows: 三种组合的 SLO attainment 对比——RR+PQ、WB+FCFS、WB+PQ（完整版）。

Why it matters: 证明两个组件都必要且正交：WB 单独贡献 10.5-34.8% P95 降低，PQ 单独贡献最高 48%，组合后达到最优。

Detailed description: 跨 6 种 (trace × hetero) 组合，完整 WB+PQ 始终优于单项。某些场景下 PQ 比 WB 更关键（workload 偏向 latency-sensitive），另一些场景下 WB 更关键（硬件异构性大）。

Figure 10: α-tuning 效果 #

What it shows: 不同 α 值对 95% SLO attainment 所需 SLO scale 的影响，跨 3 条 trace × 2 种硬件。

Why it matters: 直接证明"α 必须 adaptive"——Hetero-1 最优 α≈0.1-0.2，Hetero-2 最优 α≈0.3-0.4，静态设置一定次优。

Detailed description: 每条曲线呈"U 型"——α=0 时纯粹看队列长度会忽略硬件速度差异，α 过大时又会过度集中到强卡造成队列堆积，中间存在最优点且随硬件/负载变化。

Key Tables #

Table 2: WB 对任务分布的影响（Trace 3, Hetero-2, 0.5 QPS） #

Stage	Dispatcher	I1 (A100)	I2 (A100)	I3 (A6000)	I4 (L40)
1 (schema linking)	RR	20.8%	23.1%	19.9%	26.8%
1	WB	0.9%	0.5%	6.1%	32.3%
2 (candidate generation)	RR	10.3%	7.8%	10.6%	9.6%
2	WB	27.9%	29.6%	16.5%	3.1%
3 (self-correction)	RR	26.5%	23.0%	25.5%	21.7%
3	WB	47.9%	46.6%	71.5%	8.3%
4 (evaluation)	RR	42.3%	46.0%	44.1%	41.8%
4	WB	23.3%	23.3%	5.8%	56.3%

Takeaway: WB 显著改变任务分布——stage 2（重计算）集中到 A100，stage 1（轻计算）集中到 L40。RR 把 43.9% 的 stage 1 请求送上 A100，严重浪费算力。

Table 3: 本地队列快照 #

Request ID	1	2	3	4	5	6	7
Arrive-at (s)	22.4	46.3	52.3	62.4	62.8	64.4	65.0
Urgency	14.5	13.2	19.0	13.1	19.0	26.9	21.9

Takeaway: FCFS 会先执行 Request 1（最早到），但 PQ 选择 Request 6（紧急度最高=26.9，虽到达最晚）。这种"违反直觉"的调度正是 SLO 达成率提升的关键。

Table 4: α-tuning 仿真开销 #

Setup	Trace 1	Trace 2	Trace 3
Hetero-1, 0.5 QPS	124.6s	122.3s	142.2s
Hetero-1, 1.0 QPS	133.3s	137.8s	149.7s
Hetero-2, 0.5 QPS	124.7s	141.3s	158.0s
Hetero-2, 1.0 QPS	115.6s	133.4s	154.2s

Takeaway: CPU 仿真扫完 α∈{0, 0.1, ..., 1.0} 网格耗时 115-158s，远小于工作负载漂移的小时级时间尺度，可生产级周期性 tuning。

Limitations #

• 估计误差敏感：整个调度依赖 L̂_out 输出长度预测和 t_prefill / t_decode 建模；论文用 Zheng et al. 2023 的方法，但没系统分析预测 MAPE 超过多少时调度开始失效。
• 没覆盖 prefix caching / disagg P-D：现代框架普遍走 PD 分离 + prefix cache，HexGen-Flow 的 cost model 似乎假设单实例 end-to-end 推理，未讨论 KV cache 跨实例迁移的成本。
• 抢占开销未量化：PQ 允许高 urgency 任务"preempt less critical ones"，但 vLLM 抢占涉及 KV cache swap/evict，这部分开销在实验中被 hidden，论文未单独 profile。
• α-tuning 假设 workload stationarity in 100s windows：突发流量（例如日切峰值）或 workload distribution shift 时，仿真 trace 过时可能导致错误 α*。
• 只和弱基线比较：vLLM 是 round-robin 派发 + FCFS，QLM 是针对非 agentic 的 SLO 调度器。没有与 Llumnix、DistServe 等更现代的多实例调度器直接对比。
• 多租户公平性有争议：紧急度优先会给"已严重拖延的查询"更多资源，从 fairness 角度可能不符合 VTC 的"公平 token 配额"范式；论文没讨论恶意用户能否通过设置宽松 SLO 反向利用调度器。

Infrastructure Impact #

• Algorithm: 为 agentic inference-time scaling（如 Best-of-N sampling、iterative refinement）提供了系统侧支撑——算法层可以更放心地堆更多阶段，调度器能保证端到端延迟。
• Kernel: N/A — HexGen-Flow 完全基于 vLLM 做上层调度，不修改 CUDA kernel 或 attention 实现。
• Framework: 直接启示——vLLM / SGLang 未来需要暴露 "workflow DAG" API 让上层注入 stage 依赖，而不只是独立 request。Llumnix-like 的动态 migration 可以和 HexGen-Flow 的 WB 组合。
• LLM: N/A for model design；但对 Long-CoT / multi-step reasoning 模型的部署有启示——思考链越长，阶段调度越重要。
• Agent: 这是 agentic LLM serving 领域的里程碑——第一次把 "workflow-aware scheduling" 工程化。对 AutoGen、LangGraph、CrewAI 这类多步 agent 框架的产线部署是关键原型。
• Code: 开源于 https://github.com/Relaxed-System-Lab/Hexgen-Flow，实现基于 vLLM，可作为 agentic serving 调度器的参考实现。

---

Deep Analysis (framework) #

Phase 2 Review: 时代定位 + 约束推导 + 核心壁垒 #

时代定位：2024-2025 年 LLM serving 的主战场已经从单 request 吞吐（vLLM/Orca 解决）转向"agentic 多步推理 + 异构集群"。PagedAttention、continuous batching 这类 "low-hanging fruits" 已被 vLLM/SGLang 采摘殆尽；HexGen-Flow 代表了调度研究进入"工作流感知 (workflow-aware)"的深水区——不再只做单 request 级优化，而是把整条推理流水线当作调度单位。这与同期的 DistServe（PD 解耦）、Llumnix（动态迁移）、Mooncake（Conductor-Prefill-Decode 分离架构）形成同一波浪潮：调度的"颗粒度"从 token 上升到 workflow。

核心技术壁垒：整个方法能 work 的关键不是两级调度的高层思想（这个 idea 并不新），而是"SLO 预算沿工作流反向传播 + 实时重分配"这个闭环——Equation 5 的预算再计算让上游误差不再被简单丢弃，而是折算成下游的 urgency。没有这一环，PQ 在估计误差累积下会崩溃。论文 Table 3 的 case study 暗示 urgency 值会在数秒内动态漂移数个单位，这种动态性是让 PQ 胜过 FCFS 28-48% 的根因。

设计绑定批判：HexGen-Flow 强制绑定三个前提：(1) 工作流是静态已知 DAG（Schema linking → Candidate → Self-correct → Evaluate），不能动态生成 stage；(2) t_comp 可以通过离线建模预测（依赖 input_len + predicted_output_len）；(3) 每个 model instance 是独立推理单元，不跨实例共享 KV cache。若任何一条不成立——例如 agent 运行时决定要不要做更多 self-correction 轮数——当前 cost model 和 SLO 预算分配就无法成立。

1. System Scope #

• 主要目标：在异构 GPU 集群上 serve 多租户 agentic Text-to-SQL 请求，优化端到端 SLO attainment 和 throughput。
• 分布式规模：单集群，文中测试 4 个 model instances × 4 GPUs/instance = 16 GPUs 级别；理论上可扩展。
• 在线 / 离线：Online latency-sensitive，P95 tail 为核心指标。
• 目标工作负载：Agentic multi-stage LLM workflow，每个 end-to-end query 触发 ~20 次 LLM 调用，阶段之间有依赖。不限于 Text-to-SQL（MAC-SQL 泛化实验证明）。

2. Architecture & Data Flow #

Figure 2: 系统架构（重复插入以便 section 对应） #

解读: 两级调度清晰体现——global coordinator 做空间路由（哪个 instance），local priority queue 做时间排序（什么时候）。每个 LLM 请求进入 coordinator 后被加上 metadata（所属 query、stage index、剩余 SLO），然后评分派发，最后在 instance 端按 urgency 重排。

2a. End-to-End Data Flow #

[User Query] → [Global Coordinator] → [Priority Queue @ Instance m] → [vLLM Engine] → [Stage Output]
                    ↓                       ↓                              ↓
               Stage DAG tracking   Urgency re-ranking            Standard continuous batching
               Workload scoring     SLO budget tracking

Stage	Input → Output	Location	Latency	Data format
Query ingestion	NL query → metadata	CPU (coordinator)	<1ms	workflow DAG
Stage dispatch	LLM request → instance m	CPU	<1ms	request + SLO meta
Local queue wait	queued request → next-to-execute	CPU (instance)	variable	priority heap
LLM inference	prompt → completion	GPU	100ms-10s	tokens
Stage completion callback	result → coordinator	CPU	<1ms	stage update
Budget rebalance	elapsed → new SLO budgets	CPU	<1ms	updated t_SLO_{i,j+1}

2b. Data Movement Hotspots #

1. Stage-completion callback: 每个 LLM 调用结束时，coordinator 必须更新 τ_elapsed 并触发下游 stage 派发。频率 = 每个 query 约 20 次，是 control-plane 通信热点。
2. Queue urgency re-evaluation: 每个 instance 在准备下一个 batch 时必须重新扫描整个 local queue 计算 urgency（因为 τ_queuing 在增长）。若队列很长（数百请求）会成为 CPU 开销瓶颈。
3. α-tuning trace collection: 100s 窗口收集所有请求的 arrival/duration trace 用于仿真，数据量中等，离线处理不阻塞 serving。

3. Design Space & Constraint Analysis #

3a-3b. Alternatives & Why Rejected

替代方案	为何不可？
纯 FCFS + Round-robin（vLLM baseline）	不懂阶段依赖，轻重活随机派；异构下 43.9% stage-1 被送到 A100（算力浪费）。
VTC（公平 token 配额）	把 query 当 user，但 token-count fairness 不等于 SLO fairness。不同 query 需要的总 token 差 2-3×。
QLM（SLO group 调度）	为独立请求设计，不追踪阶段依赖，上游超时债务无法传到下游。
纯 shortest-job-first	无法保证 SLO，长 query 饿死。
静态 α（固定权重）	Figure 10 证明最优 α 随硬件和负载漂移，静态设置一定次优。
学习型调度器（如 LTR[54]）	需要大量训练数据；冷启动 + 分布漂移下难稳定。HexGen-Flow 选用启发式 + 仿真 auto-tune 更鲁棒。

3c. Assumption Audit

• 假设 1: 输出长度可预测。依赖 Zheng et al. 2023 的 length prediction。在 Text-to-SQL 里尚可（SQL 有结构先验），但在开放式生成上预测误差会灾难性增加。
• 假设 2: workflow DAG 是静态的。CHESS 的 self-correction 轮数虽可变（0-10），但 DAG 结构固定。若 agent 动态决定新增新 tool call，当前预算分配失效。
• 假设 3: 100s 窗口内 workload stationary。Bursty traffic（如日切流量、故障重试风暴）会让仿真 trace 与未来不匹配。
• 假设 4: prefill + decode 时间可独立建模。实际上 continuous batching 里 prefill 和 decode 会互相干扰（chunked prefill 就是为此），论文未讨论这种干扰对 t_comp 预测的影响。

3d. 核心技术壁垒（呼应 Phase 2）

Equation 5 的 SLO 预算动态重分配 + Equation 7 的 urgency 定义，这两条公式闭环让误差自我修正。论文自己都承认："any unexpected execution cost will be reflected in the per-request SLO budget t_SLO_{i,j+1} of the subsequent inference request"——这是整个设计的精髓。工程上难复现的是如何让 coordinator 的状态更新 atomic 且低延迟（<1ms），否则 instance 在 coordinator 还没更新时取到过期 budget 会导致决策错乱。

3e. Design Binding

• 绑定 vLLM 作为底层引擎（continuous batching + paged attention 假设）。
• 绑定静态 workflow DAG。
• 绑定 "single instance = single model replica, TP=8"——没讨论 PD 解耦或 EP 的场景。
• 绑定 CPU-based coordinator（单点瓶颈，未讨论大规模下的 partitioning）。

4. Key Innovations #

Innovation	Mechanism	Benefit	Cost/Tradeoff
Workload-Balanced Dispatch (WB)	Score = (1-α)·β/t_queue - α·t_comp，选择最高分 instance	10.5-34.8% P95 降低；异构 GPU 利用率均衡	依赖准确 t_comp 估计；协调器单点
Adaptive Priority Queue (PQ)	Urgency = t_comp - (t_SLO - τ_queuing)；max-urgency 优先	最多 48% P95 降低	队列重排 CPU 开销；抢占导致 KV cache 扰动
SLO Budget Propagation	Eq. 5 按 t̄_comp 比例分配，完成即重算	上游误差自动修正，避免下游雪崩	需要每个 stage 的 avg 执行时间模型
α-auto-tuning	100s 窗口 t-test 检测退化 → CPU 仿真重搜 α*	14% SLO attainment 提升（Trace 3, Hetero-2）	115-158s 仿真开销，假设 workload stationarity

5. Scheduling & Resource Management #

• Batch formation: 复用 vLLM 的 continuous batching，不改引擎层；只在"哪个请求进下一个 batch"上加 priority 排序。
• Memory: 继承 vLLM 的 PagedAttention；未引入新的 KV cache 机制。
• GPU 利用率: 通过 WB 的 dispatch score 让算力匹配负载——stage 3（self-correction 重计算）高比例进 A100，stage 1（schema linking 轻）进 L40。
• 多租户: 支持多用户 + 每用户独立 SLO（Figure 8 双租户实验），urgency metric 天然适配。
• SLO-aware: 端到端 SLO 显式建模，逐 stage 分配预算。

6. Target Scenarios & Workload Characterization #

Scenario	工作负载特征	SLO	现有系统问题
Enterprise Text-to-SQL	每 query ~20 LLM 调用，4 阶段，长尾 self-correction	P95 E2E < N×exclusive time	FCFS 让上游延迟传播到下游无法补救
多 agent 工作流	阶段数量可变，可并行分支	端到端 SLO	独立 request 调度无法追踪 DAG
Analytics over DB	query 到达率 0.5-1.0 QPS，复杂度分布不均（14% simple / 72% moderate / 14% hard）	SLO scale ~3-7×	VTC/QLM 不懂阶段依赖

主要瓶颈: scheduling-bound——论文反复强调 vLLM 在计算上并不饱和，问题在于请求排队和派发策略低效，导致 SLO scale 被拉大 1.4-1.8×。

7. Performance Evaluation #

7a. Metrics #

Metric	Definition	更好方向
SLO attainment	% queries 在 SLO_scale × exclusive_time 内完成	更高
P95 tail latency	95% query 的完成时间	更低
Throughput	query/s	更高

7b. Before-After Comparison #

Figure 4: 主实验（SLO attainment） #



解读: 跨 3 trace × 2 hetero × 2 QPS，HexGen-Flow 始终在更小 SLO scale 下达到 95%，证明 agentic workflow 下的调度收益是跨场景一致的。

Optimization	Metric	Baseline	HexGen-Flow	Improvement	Condition
vs. vLLM P95	SLO scale for 95%	5.4×	3.5×	-35%	Trace 1, Hetero-1, 0.5 QPS
vs. vLLM throughput	query/s	1.0 (rel)	1.49-1.81	+49-81%	all traces
vs. VTC P95	SLO scale	7.9×	5.2×	-34%	Trace 2, Hetero-2, 0.5 QPS
vs. QLM P95	SLO scale	7.8×	6.1×	-22%	Trace 3, Hetero-2, 1.0 QPS
Homo P95	SLO scale	7.2×	5.9×	-18%	Trace 3, Homo, 1.0 QPS

7c. Bottleneck Shift #

Before HexGen-Flow: scheduling-bound (aggregate queue delay dominates E2E)
After WB only: partially shifted to local queue ordering (long queues inside A100)
After WB + PQ: queue ordering improved; residual bottleneck = t_comp estimation error
After α-tune: error amortized across window; now bounded by workflow DAG critical path

剩余瓶颈：critical path（self-correction 的 sequential 轮数）+ estimation noise。想进一步优化需要：speculative 执行 stage、更准的 output length predictor、PD 解耦减少 stage 内延迟抖动。

7d. Baselines & Fairness #

• Baselines: vLLM (FCFS+RR)、VTC (公平 token)、QLM (SLO-oriented)、RR+PQ (ablation)、WB+FCFS (ablation)。
• Fairness: 同模型 (Llama3.1-70B)、同 TP=8、同 vLLM 引擎、同 CHESS workflow。只改调度策略。
• 硬件: Hetero-1 (A100 + A6000)、Hetero-2 (A100 + L40 + A6000)、Homo (纯 A100)。
• Missing baselines: Llumnix、DistServe、Mooncake——这些更现代系统没比较，是论文明显短板。

8. API & Usability #

• 无详细 API spec；代码开源 (GitHub: Relaxed-System-Lab/Hexgen-Flow)。
• 模型格式走 vLLM（HF 兼容）。
• 部署需要用户提供工作流 DAG 定义（schema linking / generation / correction / evaluation），即 CHESS / MAC-SQL / 自定义 workflow。
• 主要可调参数：α (auto-tuned)、β (静态试出)、SLO per query。

9. Infrastructure Impact Matrix #

Layer	影响
Algorithm	支撑 inference-time scaling (best-of-N, self-correction) 的工程落地
Kernel	N/A
LLM	所有开源模型，依赖 vLLM 兼容
Agent	为 LangGraph/AutoGen/CrewAI 类 agent 框架提供生产级 serving 参考实现
Ops	α-tuning 的 trace 收集需要 logging/monitoring 基础设施

10. Comparison Matrix #

Feature	HexGen-Flow	vLLM	VTC	QLM	Llumnix	DistServe
Continuous batching	✓ (via vLLM)	✓	✓	✓	✓	✓
Paged attention	✓ (via vLLM)	✓	✓	✓	✓	✓
Multi-stage DAG awareness	✓	✗	✗	✗	partial	✗
Workflow SLO budget propagation	✓	✗	✗	partial	✗	✗
Heterogeneous GPU dispatch	✓	round-robin	✗	✗	✓	✗
Priority/urgency queue	✓	FCFS	fairness	SLO-group	priority	priority
PD disaggregation	✗	✗	✗	✗	✗	✓
Instance migration	✗	✗	✗	✗	✓	partial

HexGen-Flow 的独特点：DAG-aware scheduling；未来与 Llumnix/DistServe 正交可组合。

11. Adoption, Maturity & Ecosystem Influence #

• 开源: github.com/Relaxed-System-Lab/Hexgen-Flow（HKUST Relaxed-System-Lab）
• 成熟度: 研究原型，尚未证据显示被 vLLM/SGLang 等主流引擎内嵌。
• 生态定位: 是 HexGen 系列（HexGen 2024、HexGen-2 2025）的延伸——前两者解决"异构 GPU 上的 LLM 推理部署 / P-D 解耦"，HexGen-Flow 解决"异构 GPU 上的 agentic workflow 调度"。这个作者组 (Binhang Yuan) 是 heterogeneous LLM serving 方向的核心团队。
• 潜在采纳者: 企业内部 Text-to-SQL 产品（Databricks、Snowflake 的 NL→SQL）、LangGraph-backed 产线 agent 服务。
• 理论影响: 首次把 "SLO 预算沿 workflow DAG 传播" 系统化；这个 primitive 可以被任何 agentic serving 框架借鉴。

Open Questions #

• 如果 workflow DAG 不是静态的（agent 运行时动态扩展），SLO 预算分配怎么重新定义？
• 与 Llumnix 的动态 migration 正交组合能否同时享受两者收益？
• 当 instance 数量 scale 到 100+ 时，coordinator 的单点设计如何 shard 或 replicate？
• 抢占带来的 KV cache eviction / swap 在 real workload 下开销多大？是否会反噬 P95？