gahow/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
obsidian/projects/auto-tuner/outline.md

16 KiB
Raw Permalink Blame History

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 实验管线映射到上面的几个机制中，形成真正可落地的“系统 + 机制”叙事。