Files
aituner/docs/simulator-claim-map-20260716.md

76 lines
9.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Simulator-for-config-tuning related-work claim map
日期2026-07-16。目的为「Frontier/Vidur-class simulator 能否低成本解决 config tuning」这条主线建立 related-work 边界。Vidur 与 LLMServingSim 的条目基于原文PDF 全文核读SimAI 基于论文页与摘要口径。每项按 Context / Claim / Assumption / Mechanism / Evidence / Boundary / 与本 project 的关系提取。
## VidurMLSys 2024arXiv:2405.05465
| 维度 | 内容 |
|---|---|
| Context | MSR India。首个面向 LLM inference 的大规模模拟器。Motivation 与我们一致config search 复杂度 O(\|M\|·\|T\|),且 optimal config 是 (model, trace) 的函数——Fig 1b 显示跨 trace misconfiguration 代价最高 2×。 |
| Claim | (a) request-level 预测误差 <9%static trace P95 normalized execution latency 误差 3.33%4 模型 × 3 tracedynamic trace **85% capacity** 负载下误差 <5%。(b) Vidur-Search 用约 1 小时 96-core CPU$9.93/h LLaMA2-70B 找到最优 config对比 deployment-based exploration 估算 42K GPU-hours $218K。(c) what-if 全量探索 $125 模拟成本 vs 估算 $1.14M 真机成本 |
| Assumption | operator runtime 可由单 GPU profiling + 小型 ML 估计器random forest插值prefill attention 可用等效单序列 sqrt(Σp_i²) 近似decode attention runtime 只依赖总 KV 读量而非 per-request context 分布LLM 架构同质小算子集合跨模型共享)。 |
| Mechanism | 声明式 model spec 算子三分类token-level / sequence-level / communication)→ GPU CUPTI profiling RF runtime estimator event-driven simulator + 三层 hierarchical scheduler支持 vLLM/Orca+/Sarathi-Serve/FasterTransformer/LightLLM 策略)→ Vidur-Search 对每个 config 二分搜索 max QPS判据 P99 scheduling delay <5s目标 QPS/dollar |
| Evidence | LLaMA2-7B/70BInternLM-20BQwen-72B denseAzure A100/H100 4-GPU pairwise-NVLink 节点Chat-1M / Arxiv-4K / BWB-4K trace总长截断到 4096 tokens |
| Boundary | **作者明示**接近 capacity point 时小误差会因排队失控放大 fidelity 评测停在 85% capacity。**结构性** MoE FP8/量化 prefix-cache reuse多轮对话按独立请求处理)、 speculative decoding列为 future work)、PP 仅同步长上下文未覆盖4K 截断)。metric 口径为 normalized execution latencystatic 排除 scheduling delay)。**最关键**sim 选出的 config 在真机 ground-truth surface 上的 selection regret 从未被验证42K GPU-h/$218K 是反事实估算分母是穷举式 exploration 而非 strong sequential tuner |
| 与本 project 的关系 | Frontier Vidur-class代码直接使用 vidur backend+ 我们的 FP8/MoE/EP/decode-profile patches我们的所有实验恰好工作在 Vidur 声明误差爆炸并回避的 regimecapacity point + SLO gate补的正是它缺的 selection-regret ground truth我们的 zero-shot 失败2530% regret与其 <9% 不矛盾——不同 metric不同 load regime不同 stack alignment论文必须主动写明这一点 Fig 1b workload-conditioned 结论与我们 P4 sign-flipP6 churn 互为独立佐证 支持 retune 频率 / amortization 论证C3)。 |
## LLMServingSimIISWC 2024arXiv:2408.05499
| 维度 | 内容 |
|---|---|
| Context | KAISTscale-out LLM serving HW/SW co-simulation面向 NPU/PIM/异构加速器设计探索基于 ASTRA-sim |
| Claim | 对真实 multi-GPU vLLM serving 平均误差 14.7% 趋势一致」; mNPUsim/GeneSys/NeuPIMs 34.7491×摘要口径 91.5×)。 |
| Assumption | iteration-level 模拟 + decoder-block 冗余复用编译一个 block 复制展开attention/ attention 分离可在可行时间内保持足够精度硬件行为可由可插拔 accelerator compiler+simulator 栈表达GeneSys 原型)。 |
| Mechanism | iterationscheduleriteration-level batchingKV pagingoperator mapping)→ per-device 硬件模拟 graph converterChakra)→ ASTRA-sim 网络级模拟 循环 |
| Evidence | multi-GPU vLLM 真机对照变量为 LLM 架构并行方案NPU 数量异构度报告平均误差与趋势一致性 |
| Boundary | 定位是硬件/系统设计空间探索不是 engine-knob config tuningvalidation 口径是 trend-following SLO-gated capacity selection-regret14.7% 平均误差大于典型 config capacity margin我们 12-cell 面上 top-2 差距 0.76%故该精度不足以支撑近邻 config 选择 |
| 与本 project 的关系 | 说明模拟保 trend是社区通行 validation 标准;「trend selection这一缺口对它同样成立不构成直接 baseline但在 related work 中界定我们评测口径selection regret at capacity point的必要性 |
## SimAINSDI 2025Alibabaaliyun/SimAI
| 维度 | 内容 |
|---|---|
| Context | 大规模 LLM **training** 的架构设计与参数调优模拟生产背景Alibaba Cloud)。 |
| Claim | 各测试场景平均 98.1% 与真实结果对齐 host 设计与参数设置提供生产可用 guidance |
| Assumption | training 过程可由 framework + kernel computation + collective communication 的选择性高保真集成复现 |
| Mechanism | 高保真集成三层栈 + 多线程加速 + lock-free global context sharing |
| Evidence | 与生产 training 场景对齐论文口径未逐一核读实验细节)。 |
| Boundary | training-onlytraining iteration 均匀batch 组成静态——恰是 Vidur 指出 inference 所缺的性质因此 98.1% 不可外推到 serving capacity point |
| 与本 project 的关系 | simulator 指导 infra 决策的工业先例与动机背书不与 serving config tuning claim 竞争引用价值在 motivation不在 evaluation 对照 |
## Frontier本 project 被测对象,非 related work
内部 Vidur-class 实现vidur backend+ project FP8/MoE tuning-keyQwen MoE serving planTP/EP-aware cache keycritical-lanedecode/true-mixed profile 补丁我们全部 fidelity 结论限定于该实现与已声明的 patch `simulator-fidelity.md`
## Consensus / disagreement / uncovered regime
**Consensus三方一致或与我们互证**
1. operator/iteration profile + 调度复合的模拟器在中低负载下能达到 515% latency 误差模拟成本比真机低数个数量级
2. optimal config (model, workload) 的函数misconfiguration 代价可达 ~2×Vidur Fig 1b我们 P4 pattern sign-flip P6 engine-churn 独立复证)。
**Disagreement** 无直接冲突数字我们的 zero-shot 失败与 Vidur <9% 处于不同 metric/regime论文需主动解释防止被误读为矛盾或重复
**Uncovered regime本 project 的空间):**
1. **capacity-point + SLO-gated selection regret 无人用真机 ground-truth surface 验证。** Vidur 自认该 regime 误差爆炸并把评测停在 85% loadLLMServingSim 只验 trend config tuning 的决策恰好发生在 capacity point
2. MoEFP8prefix reusespeculative decodingEP topology长上下文均在已发表 fidelity envelope 之外
3. **alignment/profiling 成本从不与真机 tuning 成本同表比较。** Vidur $218K 对比用穷举做分母正确分母是 strong sequential tuner我们实测 0.270.45 H20h/task`runs/tuning-cost/metrics.json`)。
4. envelope 失效的低成本检测workload/runtime/topology 变化后何时还能信 simulator无人提出
## 对本 project claim 的直接影响
- **C1 定位句**不是Vidur 错了」,而是Vidur-class claim 停在 sub-capacity load prediction fidelity把它外推到 SLO-gated capacity selection 是社区的隐含用法我们证明该外推在 zero-shot 下失败2530% regret并给出恢复 ranking 所需的最小真机证据层级」。
- **C2**Vidur 没有 minimum-real-evidence 的概念要么全模拟要么全真机per-TP calibration / 同栈 profile + KV capacity + patches 的证据层级是新贡献面
- **C3**省钱叙事必须从数量级修正为仅在 amortization 下成立」,分母换成 strong tuner 实测值Vidur Fig 1b + 我们 P6 churn 共同支撑 retune 频率前提
## 待 triage 的相邻工作(未读原文,暂不写 claim
APEXarXiv:2411.17651并行执行计划模拟)、LLMServingSim 2.0arXiv:2602.23036异构+分离式)、CharonarXiv:2605.17164training+inference 统一)、inference-fleet-simarXiv:2603.16054排队论容量规划)、AgentServeSimarXiv:2606.09613多轮 agent serving)。若审稿风险评估需要按本表格式各补一行
## Sources
- Vidur: <https://arxiv.org/abs/2405.05465>全文核读版本mlsys24 PDF
- LLMServingSim: <https://arxiv.org/pdf/2408.05499>
- SimAI: <https://www.usenix.org/conference/nsdi25/presentation/wang-xizheng-simai><https://github.com/aliyun/SimAI>