422 lines
16 KiB
Markdown
422 lines
16 KiB
Markdown
# Draft
|
||
|
||
挑战：
|
||
1. workload 的 benchmark 性能与线上的 gap，如何最小化这一 gap，从而让 offline benchmark 数据能够在指导线上的资源配置时最小化误差
|
||
2. 使用 AI tuner 时如何让 LLM 有一条清晰的优化目标，而不是随意的 propose config 也无法判断优劣
|
||
3. 如何尽量减少 evolve 时需要的 GPU 卡时，减少资源需求，避免 AI tuner 成本甚至大于人力成本
|
||
|
||
|
||
我们的机制：
|
||
1. workload 的抽象定义，需要能够用于解释说明为什么不同 workload 下不同 setup 的表现不同
|
||
2. 自动化的异构硬件资源池内的 config/model 调整方案
|
||
|
||
|
||
|
||
|
||
# 11. Related Work (结构建议：按“范式”而非按领域罗列)
|
||
|
||
**11.1 Inference autotuning**
|
||
|
||
- Black-box optimization for serving configs
|
||
|
||
- Model-based fast search (operation-level / database-driven)
|
||
**TODO:** insert concrete citations and differences
|
||
|
||
|
||
**11.2 Agentic tuning for training/storage/PFS**
|
||
|
||
- StorageXTuner / ASAP / STELLAR line
|
||
|
||
- Position: our novelty is inference-specific feasibility + verifiable loop + drift reuse
|
||
|
||
|
||
**11.3 Systems optimization methodology**
|
||
|
||
- measurement-driven tuning, adaptive control, safe exploration
|
||
|
||
|
||
|
||
|
||
---
|
||
# GPT
|
||
|
||
## 一、把问题抽象成“论文级别”的 Research Problem
|
||
|
||
在顶会视角里，这个问题不是“压测不准”，而是：
|
||
|
||
> 在**高度异构硬件 + 多模型混部 + 动态调度**的 LLM 推理集群中，
|
||
> 怎样在满足多级 SLO（P95/P99 延迟）的前提下，**系统化地完成容量规划与资源编排**，同时让 offline benchmark 与 online 行为之间的误差可控？
|
||
|
||
可以总结出 **3–4 个核心挑战（Challenges）**，每个挑战都要能撑得起一个小机制：
|
||
|
||
### Challenge 1：Workload 维度极高，传统 trace / benchmark 已经不够用了
|
||
|
||
* 传统 web/microservice workload：请求大小 / CPU 时间分布 + 到达过程，维度很低。
|
||
* LLM workload 至少包括：
|
||
|
||
* prefill_tokens、decode_tokens 的长尾分布（甚至多峰）；
|
||
* sampling 参数（temperature, top_p, tools）对计算路径和 latency 的影响；
|
||
* multi-turn conversation / tool-call 带来的 stateful pattern；
|
||
* dynamic batching + KV cache 使得同一请求在不同系统状态下 cost 差异巨大。
|
||
* 离线压测往往用 **“单点分布 + 恒定并发”**，无法覆盖真实的高维空间。
|
||
|
||
**论文话术**：
|
||
LLM inference workload is inherently *high-dimensional* and *stateful*, breaking the assumptions behind existing capacity planning and benchmarking techniques for web and microservice workloads.
|
||
|
||
---
|
||
|
||
### Challenge 2：Multi-stage Pipeline & Scheduler 行为导致强状态依赖
|
||
|
||
* LLM 推理天然是 **两阶段**甚至多阶段：
|
||
|
||
* prefill（矩阵大、吞吐友好）；
|
||
* decode（矩阵小、step-by-step，容易被 tail 拖垮）。
|
||
* dynamic batching / speculative decoding / MoE 激活 / KV cache 驱逐等行为，使得：
|
||
|
||
* 单个请求的 latency 并不是其“独立 cost”，而是**队列状态 + 当前 batch 其他请求的函数**。
|
||
* offline 单请求 / 小批量 benchmark 很难反映真实 scheduler 行为。
|
||
|
||
**论文话术**：
|
||
LLM inference systems are *queueing systems with complex stateful schedulers*. Per-request cost is a function of *system state* (batch composition, cache state, competing models), invalidating the independence assumptions used in prior capacity planning models.
|
||
|
||
---
|
||
|
||
### Challenge 3：模型和硬件双重异构，性能曲线高度非线性
|
||
|
||
* **模型异构**：
|
||
|
||
* dense vs MoE vs MLA，FP16 vs FP8/FP4，不同架构（Qwen, LLaMA, DeepSeek, GPT…）；
|
||
* 不同层数 / hidden size / experts 数，导致 compute / memory / bandwidth 比例完全不同。
|
||
* **硬件异构**：
|
||
|
||
* A100 vs H100 vs L40S vs 4090 vs 国内卡，SM 数、HBM 带宽、NVLink 拓扑各不相同；
|
||
* 部分硬件支持特定指令 / kernel（比如 FP8/FP4、特定 GEMM kernel）。
|
||
* 传统 “QPS = f(硬件 FLOPS)” 一类的简单模型完全失效。
|
||
|
||
**论文话术**：
|
||
Model and hardware heterogeneity yields highly non-linear and non-monotonic performance surfaces, making extrapolation from a small set of microbenchmarks fundamentally unreliable.
|
||
|
||
---
|
||
|
||
### Challenge 4：多目标 & 反馈回路：SLO、成本、干扰、稳定性
|
||
|
||
* 目标不再是“单纯最大吞吐”，而是：
|
||
|
||
* SLO（不同租户/业务线、P95/P99）；
|
||
* 成本（GPU 小时 / 能耗）；
|
||
* 干扰与隔离（hot model vs cold model，RL / search 等长 query 对其他服务的拖累）。
|
||
* 容量规划的结果会反过来改变系统行为：
|
||
|
||
* 调整 batch 大小 / 并发 / 混部方案，会改变 latency 和 cost；
|
||
* 不同模型在同一节点上的 placement 会产生“不可线性叠加”的干扰。
|
||
|
||
**论文话术**：
|
||
The system must solve a multi-objective optimization problem under closed-loop feedback: capacity decisions alter scheduler behavior and interference patterns, shifting the workload characteristics themselves.
|
||
|
||
---
|
||
|
||
### Challenge 5：强非平稳（non-stationary），offline 结果迅速“过期”
|
||
|
||
* 模型会迭代，kernel 会升级，量化策略会变；
|
||
* 业务 pattern 也会变（比如长上下文应用越来越多，工具调用变多等）。
|
||
* 一个月前测出来的 “最优配置” 可能已经不再优。
|
||
|
||
**论文话术**：
|
||
LLM workloads and serving stacks are *non-stationary*: model upgrades, kernel changes, and evolving user patterns quickly invalidate static benchmark-based capacity plans.
|
||
|
||
---
|
||
|
||
## 二、如果当成 SOSP/OSDI 论文，storyline 可以这样讲
|
||
|
||
一个典型的“系统 + 测量 + 机制”型 paper，可以这样结构化：
|
||
|
||
### 1. Introduction（讲痛点 + 一组 killer numbers）
|
||
|
||
* 现实背景：某大规模 LLM 服务平台（xx 个模型、yy 种 GPU、每天 zz 亿 tokens）。
|
||
* 观测：当前行业普遍用 synthetic benchmark 做容量规划，导致：
|
||
|
||
* 为满足 tail latency SLO，**平均 over-provision 30–60% GPU**；
|
||
* 但在复杂高峰场景下，仍然会出现 SLO violation。
|
||
* 提出论文目标：
|
||
|
||
> 我们要构建一个 **trace-driven、heterogeneity-aware、online-calibrated** 的容量规划与资源编排系统，将 offline benchmark 与 online 行为闭环起来。
|
||
|
||
最后给出 contributions bullet list，比如：
|
||
|
||
1. 第一个系统性测量 LLM inference offline benchmark vs online gap 的工作；
|
||
2. 一个 token-centric 的 workload 抽象与 trace 压缩方法；
|
||
3. 一个 heterogeneity-aware 的性能模型和容量规划器；
|
||
4. 一个在线校准 + shadow serving 的闭环控制框架；
|
||
5. 真实大规模部署，xx 模型 yy 集群上，节省 zz% GPU 成本且保持 SLO。
|
||
|
||
---
|
||
|
||
### 2. Background & Motivation / Measurement Study
|
||
|
||
* 简要介绍现有 LLM serving stack（例如 vLLM / TensorRT-LLM / internal stack）：
|
||
|
||
* pipeline：prefill / decode，dynamic batching，KV cache；
|
||
* typical scheduler 行为。
|
||
* Measurement 部分：
|
||
|
||
* 对某些典型模型 M1…Mn，在 A100/H100/4090 等上，用行业常见压测方法（fixed prompt, fixed concurrency）测试；
|
||
* 然后对比真实生产 trace 的表现：
|
||
|
||
* latency 分布差异；
|
||
* GPU 利用率差异；
|
||
* per-token cost 的状态依赖（batch size / cache hit 等）。
|
||
* 这一节的目标是“打破读者的直觉”，让他们相信：
|
||
**传统 benchmark + naive 容量规划是 fundamentally flawed**。
|
||
|
||
---
|
||
|
||
### 3. System Overview：整体 architecture
|
||
|
||
画一个系统图，把你的方案抽象成 4 个逻辑组件：
|
||
|
||
1. **Trace Collector & Profiler**
|
||
从线上采集 token-level trace，构建 token-centric workload profile。
|
||
|
||
2. **Trace Synthesizer & Replayer**
|
||
|
||
* 将高维 trace 压缩成少量 profile；
|
||
* 支持生成 synthetic workload、重放真实 trace。
|
||
|
||
3. **Performance Model & Capacity Planner**
|
||
|
||
* 解析模型 + 校准点；
|
||
* 异构硬件 / 多模型资源分配。
|
||
|
||
4. **Online Calibrator & Shadow Serving**
|
||
|
||
* 线上 metric 对比预测，更新模型；
|
||
* 利用 shadow 流量验证新配置。
|
||
|
||
---
|
||
|
||
### 4. 关键“创新机制”可以怎么讲？
|
||
|
||
下面是可以写进论文、又不只是“工程 best practice”的那种机制：
|
||
|
||
---
|
||
|
||
#### 机制 1：Token-centric Workload Abstraction（令牌中心工作负载抽象）
|
||
|
||
**痛点对应**：Challenge 1（高维 workload）
|
||
|
||
**思路**：
|
||
|
||
* 提出一个“token-centric”的 trace 表示，把请求抽象为：
|
||
|
||
* prefill_token_trace：每个时刻注入多少 prefill tokens；
|
||
* decode_token_trace：每个时刻系统需要生成多少 decode tokens；
|
||
* 结合 arrival process，把原本复杂的请求行为用“token 流量（token flow）”来建模。
|
||
|
||
**创新点可以讲**：
|
||
|
||
* 提出一种**多粒度 trace 表示**：
|
||
|
||
* conversation-level；
|
||
* request-level；
|
||
* token-bucket-level；
|
||
* 并设计压缩算法，将实际数十亿条请求压缩成少量 profile，同时保持对系统行为（batching、队列长度）的预测 精度。
|
||
|
||
**论文卖点**：
|
||
从“request-centric”转向“token-centric”的 workload 抽象，显著提高了仿真的表达力和压缩率，是 LLM 特定的新的 workload 模型。
|
||
|
||
---
|
||
|
||
#### 机制 2：State-aware Performance Model（状态感知性能模型）
|
||
|
||
**痛点对应**：Challenge 2 & 3（scheduler 状态依赖 + 异构）
|
||
|
||
**思路**：
|
||
|
||
* 不用“全黑盒 curve fitting”，也不用纯理论 queueing，而是：
|
||
|
||
* 把模型的 cost 分解成几个 operator 类别（prefill matmul / decode matmul / MoE gating / KV read/write）；
|
||
* 用少量 microbench 估计每类 operator 在不同硬件上的 throughput；
|
||
* 再通过**scheduler 的状态特征**（batch_size、cache_hit_rate、active_experts）组合出 per-request cost。
|
||
|
||
**更系统一点说**：
|
||
|
||
$$
|
||
T_\text{req} \approx f(L_\text{prefill}, L_\text{decode}, B_\text{prefill}, B_\text{decode}, \text{cache\_stats}, \text{experts\_activated}, \text{hw\_features})
|
||
$$
|
||
|
||
把 `f` 做成：
|
||
|
||
* 一个参数化公式 + 少量校准项；
|
||
* 或者一个小模型（比如 GBDT/MLP），输入是上述 feature，输出是 per-request latency / tokens/s。
|
||
|
||
**论文卖点**：
|
||
|
||
* 这是一个**state-aware、operator-aware、hardware-aware** 的统一模型；
|
||
* 能在很少的测量点下，对未测配置做 reasonably accurate 的预测；
|
||
* 能清楚解释“为什么这个 config 在 H100 上更好，但在 4090 上反而更差”。
|
||
|
||
---
|
||
|
||
#### 机制 3：Heterogeneity-aware Capacity Planning（异构感知的容量规划）
|
||
|
||
**痛点对应**：Challenge 3 & 4
|
||
|
||
**思路**：
|
||
|
||
* 把每个 (model, hw, config) 抽象成一条“性能曲线”：
|
||
|
||
* 在不同 traffic level 下的 {tokens/s, P95 latency}；
|
||
* 再把多模型、多硬件的组合，看成一个优化问题：
|
||
|
||
> 在预算 B（或目标 tokens/s）下，选择每种硬件上的实例数和每个模型的 config，使
|
||
>
|
||
> * 所有 (model, traffic_class) 的 SLO 满足；
|
||
> * 总成本最低 / 利用率最高。
|
||
|
||
可以引入的技术点：
|
||
|
||
* 把性能曲线离散化成 piecewise-linear segments，用 MILP / ILP 近似求解；
|
||
* 或者用 heuristic（greedy、local search），但要有理论或实验解释“好在哪”。
|
||
|
||
**论文卖点**：
|
||
|
||
* 这是一个针对 LLM inference 特化的 “multi-model, multi-hardware capacity planning” formulation；
|
||
* 支持把不同模型视作**token 流**而非“QPS”，更符合 LLM 的真实代价。
|
||
|
||
---
|
||
|
||
#### 机制 4：Online Calibration with Safety Guardrails（带安全边界的在线校准）
|
||
|
||
**痛点对应**：Challenge 5（non-stationary）
|
||
|
||
**思路**：
|
||
|
||
* 运行时持续收集：
|
||
|
||
* per (model, hw, config) 的 measured latency / tokens/s；
|
||
* 维护一个“预测 vs 实测”的误差估计，比如：
|
||
|
||
* 每个组合一个信心水平和 bias term；
|
||
* 用类似 bandit / Bayesian update 的方式更新模型：
|
||
|
||
* 如果长期 under-predict（预测太乐观） → 自动增加安全裕度；
|
||
* 如果长期 over-predict → 可以安全收紧资源。
|
||
|
||
**创新点可以讲**：
|
||
|
||
* 不是简单手工加 20% buffer，而是**自动学习每个组合的安全系数**；
|
||
* 对高风险配置引入更严格的 conservative bound，对老练稳定配置更激进。
|
||
|
||
**论文卖点**：
|
||
|
||
* 提出一个 **confidence-aware capacity planner**，在线适配 non-stationary 的 LLM 堆栈；
|
||
* 实验中展现：在保证 SLO violation rate 不上升的前提下，把平均 GPU over-provision 从 X% 降到 Y%。
|
||
|
||
---
|
||
|
||
#### 机制 5：Shadow Serving + Semantic-equivalent Replay（影子服务 + 语义等价回放）
|
||
|
||
（如果你愿意把“功能正确性 + 性能”一起讲）
|
||
|
||
**痛点**：新模型 / 新 config 不仅要看性能，还要保证语义/答案质量不退化。
|
||
|
||
**思路**：
|
||
|
||
* shadow 集群接收真实流量；
|
||
* 对于采样类任务（开放对话），做 semantic diff（embedding / reward model）；
|
||
* 把“性能 / 质量 / 资源 cost”放在一起，形成三维 tradeoff。
|
||
|
||
这块可以是 optional，但如果你做了，会让论文更“完整”——从系统工程到用户体验。
|
||
|
||
---
|
||
|
||
## 三、论文的“创新性定位”可以怎么说？
|
||
|
||
顶会 reviewer 会问：**这和现有的 LLM serving, autoscaling, capacity planning 工作有什么根本不同？**
|
||
|
||
你可以把创新性定位在三层：
|
||
|
||
1. **问题定义层**：
|
||
|
||
* 从“QPS-capacity for microservices” 迁移到 “token-centric, stateful LLM inference capacity planning”；
|
||
* 首次系统性刻画 offline benchmark vs real-world LLM workload 的巨大 gap。
|
||
|
||
2. **建模与抽象层**：
|
||
|
||
* token-centric workload 模型；
|
||
* state-aware performance model；
|
||
* heterogeneity-aware capacity planning formulation。
|
||
|
||
3. **系统与实践层**：
|
||
|
||
* 在真实大规模集群落地（xx GPUs, yy models）；
|
||
* 提供可观测的数据点（数十亿请求 trace）、open-source 工具（如果能开源更好）。
|
||
|
||
---
|
||
|
||
## 四、如果你要落到具体 paper skeleton，可以是这样（中英文混合大纲）
|
||
|
||
1. **Introduction**
|
||
|
||
* 背景：LLM inference at scale
|
||
* 痛点 & measurement teaser
|
||
* Our approach & contributions
|
||
|
||
2. **Background & Motivation**
|
||
|
||
* LLM serving pipeline & scheduler
|
||
* Workload characteristics
|
||
* Why existing capacity planning breaks
|
||
|
||
3. **Measurement: The Gap between Offline Benchmarks and Production**
|
||
|
||
* Methodology (trace collection, baseline benchmarks)
|
||
* Key findings（2–3 条最重要的 gap）
|
||
* Design implications（为后面机制买伏笔）
|
||
|
||
4. **Token-centric Workload Abstraction**
|
||
|
||
* Trace model（conversation/request/token 三级）
|
||
* Compression & profile generation
|
||
* Accuracy vs size tradeoff
|
||
|
||
5. **State-aware Performance Modeling**
|
||
|
||
* Operator-level decomposition
|
||
* Hardware heterogeneity encoding
|
||
* Online calibration mechanism
|
||
|
||
6. **Heterogeneity-aware Capacity Planning**
|
||
|
||
* Optimization formulation
|
||
* Solving strategy（MILP / heuristic）
|
||
* Integration with workload forecaster
|
||
|
||
7. **Online Calibration and Shadow Serving**
|
||
|
||
* Confidence-aware model update
|
||
* Shadow evaluation pipeline
|
||
* Safety guardrails
|
||
|
||
8. **Implementation**
|
||
|
||
* Integration with existing LLM serving stack (vLLM/…)
|
||
* Engineering details（overhead, compatibility）
|
||
|
||
9. **Evaluation**
|
||
|
||
* Micro-bench: modeling accuracy, calibration speed
|
||
* Cluster-level: GPU savings, SLO satisfaction, robustness
|
||
* Ablation: no calibration / no heterogeneity / no token-centric
|
||
|
||
10. **Related Work & Discussion**
|
||
|
||
11. **Conclusion**
|
||
|
||
---
|
||
|
||
如果你愿意，下一步我们可以更具体地“代写”两块：
|
||
|
||
* **Measurement 部分**：一起设计 3–4 个关键 finding（包括可能的图，比如“offline latency vs online latency”的散点图、“token-centric profile 压缩比 vs 误差”的图）；
|
||
* **Design 部分**：把你已经有的 auto-tuner / vLLM 实验管线映射到上面的几个机制中，形成真正可落地的“系统 + 机制”叙事。
|