输入模式与 Workload Spec
trace-driven vs generative 两条主线——给 perf model 喂什么样的 workload 才能跑出可信结果
核心要点:
- workload 输入决定 perf model 上限——真实 API 服务 RPS 与朴素合成 workload 差一个数量级(BurstGPT 0.21 vs MAF 1.64)
- 公开 LLM trace 6 大候选:Azure 2023/2024、BurstGPT(10.31M / 213 天)、Mooncake(含 KV hash)、ShareGPT、LMSYS-Chat-1M、AlpaServe
- Poisson 到达对 LLM 服务严重失真——真实到达 CV ≈ 1.41,需 Gamma($\alpha\approx 0.5$)或 Weibull
- 长度分布:输入 Pareto + log-normal 混合,输出 Exponential(ServeGen NSDI 2026 实测)
- Trace 时效性 1 年:Azure 2023 Context-Heavy 占 45.8%,2024 飙至 91.6%,老 trace 系统性低估长 prompt
- Hybrid(参数 fitting → resampling)是当前最佳实践,ServeGen 避免 50% under-provisioning
名词定义
| 名词 | 定义 |
|---|---|
| Workload spec | 驱动 perf model 的请求侧规范(到达 + 长度 + 会话结构 + 路由) |
| Trace-driven | 直接回放真实生产 trace 的时间戳序列 |
| Generative | 用统计模型(分布 + 参数)合成请求序列 |
| Hybrid | Trace 拟合参数 + generative 重采样 |
| CV | 变异系数 $\sigma/\mu$,衡量分布离散程度,Poisson 的 CV = 1 |
| Index of Dispersion | 方差 / 均值,衡量计数过程突发性,Poisson = 1 |
| KS 检验 | Kolmogorov-Smirnov 检验,衡量两分布差异 |
| Prefix 命中率 | 多轮对话 / 系统 prompt 复用时 KV cache 可重用比例 |
| Context-Heavy 请求 | 输入 token >> 输出 token 的请求,RAG / agent 典型 |
本篇范围
workload 输入是 perf model 的入口——给定 compute / memory / interconnect 资源模型,要喂什么样的请求序列才能跑出可信结果。本篇讲两条路径(trace-driven vs generative)各自怎么做、何时选哪个、混合策略如何参数化。
不包含:
- continuous batching 状态机 / 三层指标计算 — 见 05-Scheduler-as-workload
- 系统调度算法本身 — 见 3.8 推理侧 — 调度优化 与 interconnect/09-推理服务化通信/
为什么 workload 输入决定结果可信度
workload 选错,perf model 跑得再准也是错的。两个证据:
证据 1 — RPS 数量级差异:BurstGPT 论文实测,真实 Azure OpenAI API 服务平均 0.21 RPS,而经典 MAF(Microsoft Azure Function)合成 workload 给出 1.64 RPS——朴素合成 workload 系统性高估了一个数量级的负载。perf model 用 MAF 类合成跑出来的结果,对真实部署完全不可用。
证据 2 — 一年时效性崩塌:Azure LLM Trace 2023 版与 2024 版字段相同,但Context-Heavy 请求占比从 45.8% 飙到 91.6%(Autopoiesis 2025 报告)。用 2023 trace 评估 2024 系统,会系统性低估长 prompt 的影响——RAG / agent 兴起改变了请求分布。
结论:workload 输入不是"次要细节",是 perf model 可信度的根。决定 trace-driven / generative / hybrid 之前,先回答三个问题:目标场景的真实 RPS、长度分布、时段模式分别是什么?
Trace-Driven 路径:6 个公开 trace 全景
直接回放真实生产 trace 是保真度最高的输入方式。业界公开可用的 6 大候选:
| Trace | 来源 | 规模 | 字段 | 时段 | 特色 |
|---|---|---|---|---|---|
| Azure 2023 | Microsoft Azure | 单日 | TIMESTAMP / ContextTokens / GeneratedTokens | 2023-11-11 | Splitwise / DistServe / Vidur 基准 |
| Azure 2024 | Microsoft Azure | 10 天 | 同上 | 2024-05-10 至 19 | Context-Heavy 91.6% |
| BurstGPT | Azure OpenAI 区域服务 | 10.31M traces / 213 天(verbatim) | Timestamp / SessionID / Elapsed / Model / Req / Resp / Total / Type | 2023 | 唯一同时含 SessionID 与多模型(GPT-3.5 / GPT-4) |
| Mooncake | Moonshot 生产 | FAST 2025 公开 | timestamp / input_length / output_length / hash_ids | 2024 | 唯一含 KV cache block hash 信息,prefix 命中可仿 |
| ShareGPT | 社区抓取 | 52K-90K 对话 | 原始对话文本(human/gpt) | 2023 | 无时序,只用作长度采样 |
| LMSYS-Chat-1M | LMSYS chatbot arena | 100 万条 / 25 模型 | 对话 + moderation 标注 | 2023 | HuggingFace 需登录审批 |
@tbl-ipm-w-traces 公开 LLM workload trace 全景
详细字段、采集方式、引用 URL 见 sub_1 cache(docs/knowledge/08-推理性能建模/.cache/iforge-research/06-workload/_sub_1_traces.md)。
Trace 回放的时间缩放问题
直接按原 timestamp 回放只能复现采集时段的 QPS。两种缩放手法:
- 比例压缩(时间轴 × 0.5):RPS 翻倍,但请求间间隔分布保留——适合在已知 trace 形状下扫描 QPS
- 比例拉伸(时间轴 × 2):RPS 减半,会丢失短时突发——bursty 行为在拉伸后被平滑,P99 严重低估
实操经验:只在 ±2× 范围内做时间缩放,超出后到达过程的统计性质失真,需改用 generative 拟合参数。
Trace 时效性的硬约束
Azure 2023 → 2024 一年 Context-Heavy 从 45.8% 升到 91.6%,意味着:
- trace 半衰期可能短到几个月,尤其在 LLM 应用快速演化期(agent / long-context / reasoning 涌现)
- 用旧 trace 评估新部署,会系统性偏向某种 workload 形态
- 缓解:周期性更新 trace + hybrid 拟合参数滚动,见后文 Hybrid 策略
Generative 路径:合成 workload 的统计建模
没有 trace 或要外推未来场景时,用统计模型合成。按四个维度建模:
到达过程:Poisson 不够用
经典 perf model 默认 Poisson 到达,但真实 LLM 服务 CV 普遍 > 1(Poisson 的 CV = 1)。BurstGPT 实测到达并发量服从 Gamma 分布,$\alpha \approx 0.5$ 对应 $\text{CV} \approx 1.41$,属强突发。
ServeGen(NSDI 2026)用 KS 检验对比多种分布,结论:
- 平稳低负载 / reasoning 类:Poisson 可接受
- API 服务 / 多模型混合:Gamma 或 Weibull,参数随规模而异
长度分布:输入与输出不同
ServeGen 实测的最佳拟合:
- 输入长度:Pareto + log-normal 混合,单一 log-normal 捕不到极端重尾
- 输出长度:Exponential(意外地 memoryless),CASTILLO 2025 进一步证实固定参数下输出长度仍有数百 token 量级方差
长度分布的重尾程度量化(Output 维度,arxiv 2604.00499 verbatim):
| 分位指标 | 值 |
|---|---|
| P99 / P50 | 10.77 |
| P90 / P50 | 4.62 |
| 最长 10% 占总输出比例 | 35.7% |
@tbl-ipm-w-length-tail LLM 推理输出长度的重尾程度
对建模的关键:用均值 / 方差描述长度分布不够,必须保留完整分布或至少 P50 / P90 / P99 三档,否则 P99 延迟预测会失真。
会话结构:多轮与 prefix 复用
单轮独立请求假设在对话 / agent 场景严重失真。多轮维度包括:
- 轮数分布:几何分布近似,但轮间时间有极长尾(用户思考期)
- Prefix 复用:多轮共享系统 prompt + 前文 → KV cache 命中
- 会话终止概率:与历史轮数关联,非独立
Prefix 命中率实测(本节最重要的可建模量):
| 场景 | 命中率 |
|---|---|
| 单轮 API | 趋近 0% |
| SGLang 生产 | 52-74%(verbatim) |
| Mooncake 生产 | ~50% |
| 多轮对话 / Agent | > 80% |
@tbl-ipm-w-prefix-hit Prefix cache 命中率典型范围
具体的 prefix cache 算法见 9.9 Cache-aware 调度,本节只关心命中率作为 workload 输入参数。
保真度量化:KS 检验与 per-client 分解
合成是否"足够代表生产"用 KS 检验量化:
$$\begin{equation} D_{KS} = \sup_{x} |F_{\text{trace}}(x) - F_{\text{synth}}(x)| \label{eq:ipm-w-ks} \end{equation}$$ServeGen 的核心方法:per-client 分解 + 分层 MLE fit + KS 选型——不直接拟合聚合分布,而是先按客户端切分,每个客户端独立拟合,再聚合。理由:聚合分布会平滑掉个体特异性。论文报告这样做避免了 50% under-provisioning——直接用聚合参数会低估真实负载。
真实 Workload 的关键特征
把 trace 与 generative 两路输入对齐到五个 perf model 必须 capture 的特征:
突发性(Burstiness)
- BurstGPT:Gamma $\alpha \approx 0.5$,$\text{CV} \approx 1.41$
- API 服务非周期突发,对话服务日模式周期高峰
- Index of Dispersion 1.5-3 量级是 LLM serving 典型值,Poisson 的 1.0 严重低估
重尾长度
- 输入 Pareto + log-normal,输出 Exponential
- coding 中位 13 token,conversation 中位 129 token(Splitwise 实测)——业务类型决定数量级差异
- 离线 batch vs 在线 interactive 的根本差异在长度方差:batch 可以宽松对齐,interactive 必须按 P99 配资源
模型混合
ServeGen 生产环境含 12 种模型(Language / Multimodal / Reasoning),各类型输入输出分布差异显著:Reasoning 模型输出约为 Language 模型 4×。perf model 在多模型部署评估时必须分别建。
时间相关性
- 日峰谷比可达 3×
- 工作日 vs 周末差异明显
- 同一服务内小时均值:输入长度差 1.63×、输出 1.46×(ServeGen 实测)
时段模型是排队论闭式的关键扩展——稳态 M/M/c 假设到达率恒定,真实必须分时段建。
Prefix 复用
$$\begin{equation} b \cdot s_{\text{effective}} \le \rho_{\text{frag}} \cdot \frac{M_{\text{HBM}} - M_{\text{weight}}}{2 \cdot L \cdot n_{kv} \cdot d_h \cdot \text{dtype}_{\text{bytes}}} \cdot \frac{1}{1 - p_{\text{prefix-hit}}} \label{eq:ipm-w-cap-with-prefix} \end{equation}$$其中 $p_{\text{prefix-hit}}$ 是 prefix 命中率——命中部分不占新空间。多轮场景下 $p_{\text{prefix-hit}} > 0.5$,有效容量翻倍,perf model 不算这个会严重低估可服务并发。
Trade-off 与 Hybrid 策略
Trace vs Generative 对比
| 维度 | Trace-driven | Generative |
|---|---|---|
| 保真度 | 高(真实分布) | 取决于参数估计 |
| 外推性 | 低(只能模拟历史) | 高(参数可扫描) |
| QPS 控制 | 固定(±2× 内可缩放) | 任意 |
| 时效性 | 1 年内 | 不直接受影响 |
| 适用 | 已上线硬件 + SLO 评估 | 未流片硬件 + DSE 扫描 |
@tbl-ipm-w-trace-vs-gen Trace-driven 与 Generative 路径对比
Hybrid 策略三种
业界最佳实践都是 hybrid,不是纯 trace 也不是纯 generative:
- H1 — 参数拟合 → 重采样:用 trace 估计分布参数,然后 generative 重采样。Vidur / ServeGen 均采用——到达时序拟合 Gamma,长度分布从 trace 直接采样或拟合 Pareto+log-normal
- H2 — Warmup-then-synthesize:用历史 trace 起步,跑过 warmup 后切换到 generative 续接,适合需要超时长仿真但 trace 不够长
- H3 — 跨硬件外推:workload 形状不变,算子时长按目标硬件 roofline 换算(LIFE 框架支撑)。这是评估未上线硬件的唯一可行路径
决策树
目标硬件未上线
├─ 必须 generative + H3 跨硬件外推
│
目标硬件已上线
├─ 需要 SLO / P99 评估 → trace-driven 或 H1
├─ 需要 DSE 扫描 → generative 或 H1
└─ trace 超过 1 年旧 → H1(拟合后重采样滚动更新)
主流 perf model 工具的 workload 输入格式
两个层级各有自己的格式约定:
推理调度层(Vidur / Splitwise-sim / DistServe)
workload 单元 = "推理请求"($\text{prompt\_len}, \text{output\_len}$):
| 工具 | Trace 格式 | Generative 支持 |
|---|---|---|
| Vidur | 3 列 CSV:arrived_at, num_prefill_tokens, num_decode_tokens | 到达(Poisson/Gamma/Static/Trace)× 长度(Fixed/Uniform/Zipf/Trace)正交组合 |
| Splitwise-sim | 7 列 CSV,generate_trace.py 重采样或参数化 | exponential / truncnorm 等到达分布 |
| DistServe | 真实数据集 tokenize 后 marshal binary | 到达 Poisson / Gamma / Uniform |
@tbl-ipm-w-scheduling-formats 推理调度层工具的 workload 输入格式
通信仿真层(ASTRA-sim / SimAI)
workload 单元 = 算子 / 层级操作,关注通信类型 + 消息大小:
| 工具 | 格式 | 字段 | 生成方式 |
|---|---|---|---|
| ASTRA-sim | Chakra protobuf .et | Node(type / duration_micros / comm_type / comm_size / 依赖边) | gen_chakra_traces.py 或 chakra_converter 从 PyTorch kineto 转 |
| SimAI | 纯文本 .txt | 每行一层 fwd/bwd/dp 三阶段(compute_us + comm_type + comm_bytes × 3) | AICB 从模型并行配置解析 |
@tbl-ipm-w-comm-sim-formats 通信仿真层工具的 workload 输入格式
关键区分:Vidur 的 Azure trace 用于到达间隔,token 长度另取 ShareGPT 等 CSV——不要把"用 Azure trace"误解为"完整 workload 都从 Azure 来"。SimAI 推理与训练同格式,推理只用 fwd 段。
升降档判据(workload 视角)
何时该升档(更精细的 workload 输入)、何时该降档(更简的输入):
- 回答"哪种并行配置相对更快":静态长度 + Poisson 到达够用,升档无收益
- 回答"P99 延迟达标吗":必须重尾长度分布 + 实际到达过程,Poisson 严重低估
- 回答"多轮 / RAG 场景部署多少卡":必须含 prefix 命中率与会话结构,单轮假设会高估容量需求
- 回答"未上线硬件能跑多快":必须 H3 跨硬件外推 + generative,trace-driven 物理上不可用
- 回答"明年 workload 怎么变":必须建时段 / 业务演化模型,trace 时效性失效
G5 落地视角(workload 输入)
G5(SystemC AT)本身不需要请求级 workload,它是 kernel / step 级标定提供方。但 G5 标定的代表性配置选择由 workload 决定:
- 如果目标部署主要是 Context-Heavy(长 input 短 output),G5 应该标定长 prefill kernel + 短 decode step
- 如果是 conversation(中等 input、长 output),G5 应该标定均匀 batch GEMV step
- 标定配置选错会让 L3 仿真器消费到不代表真实 workload 的 step 时长
实操:在跑 G5 标定前,先用 trace 或 generative 模型决定 batch × prefill_len × decode_step 的代表性扫描网格,而不是均匀网格。
Takeaway
| 知识点 | 核心结论 |
|---|---|
| Workload 决定可信度 | 朴素合成与真实差一个数量级(0.21 vs 1.64 RPS) |
| 公开 trace 选择 | BurstGPT 最大 / Mooncake 唯一含 KV hash / Azure 最常用 / Vidur 与 Splitwise 默认 |
| Poisson 不够用 | 真实 CV ≈ 1.41,用 Gamma($\alpha \approx 0.5$)或 Weibull |
| 长度分布 | 输入 Pareto + log-normal、输出 Exponential,必须保留 P50 / P90 / P99 |
| Trace 时效性 | 1 年可崩(Context-Heavy 45.8% → 91.6%),周期性更新或 hybrid |
| Hybrid 是标准 | 参数 fitting → 重采样,ServeGen 避免 50% under-provisioning |
| Prefix 命中率 | 单轮 ≈ 0%、SGLang 52-74%、Mooncake ~50%、多轮 > 80%,必须进容量墙公式 |
| 工具格式 | Vidur 3 列 CSV / Splitwise 7 列 / ASTRA-sim Chakra / SimAI .txt |
| G5 标定与 workload 联动 | 标定网格按 workload 代表性配置选,不是均匀扫描 |
开放问题
- Speculative decoding / prefix sharing 进不进 workload spec:这些系统特性改变"有效输入长度"——speculative 让 decode 多 token 一步,prefix sharing 缩短实际 prefill。当前业界做法不统一(有的进 workload,有的进 perf model 内部逻辑),需要建模约定见 11 投机解码篇待写
- LLM-based workload synthesis 的成熟度:TraceLLM(2025)证明用 LLM 生成微服务调用链可行,但 LLM 推理 workload 的 LLM 合成尚无同行评审论文
- 跨变量相关性丢失:ServeGen 等 per-variable 拟合方法丢失长度与到达时间的相关性,生产观察的"长 prompt 集中在晚高峰"无法表达
- 多模型混部的请求路由 trace:目前无公开数据集含"请求选哪个模型"的决策记录,多模型 perf model 缺这一维度
参考资料
延伸阅读
- 8.1 总览 — 全章精度阶梯与升降档判据
- 8.5 Scheduler-as-workload — workload 输入如何进入三层指标计算链
- 3.8 推理侧 — 调度优化 — Continuous batching / chunked prefill 算法侧
- 9.1 推理服务化通信总览 — PD 分离 / cache-aware 路由系统设计