gahow/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: obsidian to gitea

Browse Source
This commit is contained in:
Gahow Wang
2026-05-07 15:04:41 +08:00
commit a57afa86b4
323 changed files with 42569 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
period/daily/25/250216.md Normal file
View File

@@ -0,0 +1,3 @@
# TBD
- [ ] xxx

7
period/daily/25/250217.md Normal file
View File

@@ -0,0 +1,7 @@
# TBD
- [ ] xxx
Deepseek 为什么 1:10 的 PD 配比？
如何评价硬件组合的优劣？
Simulator 不同硬件组合，不同负载，不同算子库下的性能测试

3
period/daily/25/250218.md Normal file
View File

@@ -0,0 +1,3 @@
# TBD
- [ ] xxx

4
period/daily/25/250504.md Normal file
View File

@@ -0,0 +1,4 @@
# TBD
- [x] 图片换成中文
- [x] 3.1 补充 通义

17
period/daily/25/250508.md Normal file
View File

@@ -0,0 +1,17 @@
# TBD
- [ ] 检查 policy 测试情况，get a table
- [x] 准备脱敏 trace
- [x] 提交毕设
- [x] 跑 5 天 trace 处理
可用日期：4.20-4.24, 4.28-4.29
预期处理时间 4.21-4.24 & 4.28 共 5 天工作日
处理时间：9-11，使用 9-12 处理得到 9-11
traceB 下 WA 可能比 LRU 好，也可能比 LRU 差，testcase depended，如何解决
llama2-13b 为 MHA，空间小，但是 WA 反而比 LRU 差

15
period/daily/25/250509.md Normal file
View File

@@ -0,0 +1,15 @@
# TBD
- [ ] PPT policy
- [ ] policy 测试结果画图
- [ ] policy 文字部分
- [x] 准备盲审毕设
- [ ] 开源 trace repo readme
---
traceB 下 WA 可能比 LRU 好，也可能比 LRU 差，testcase depended，如何解决
llama2-13b 为 MHA，空间小，但是 WA 反而比 LRU 差

8
period/daily/25/250512.md Normal file
View File

@@ -0,0 +1,8 @@
# TBD
- [ ] policy 测试结果画图
- [ ] policy 文字部分
- [x] 开源 trace repo readme
- [x] 添加最简单的 pseudocode

8
period/daily/25/250513.md Normal file
View File

@@ -0,0 +1,8 @@
# TBD
- [ ] 删除 fig25-27，重画 fig28-30
- [ ] 更新文字部分
- [ ] 给出 policy design 对应 charactering 的对应表格
- [ ] 给出 GDFS 到 WA 的演化

7
period/daily/25/250519.md Normal file
View File

@@ -0,0 +1,7 @@
# TBD
- [ ] Fig 16 移到 policy 部分，给出拟合的分布
- [x] Table 2，文字太多，添加 ref
- [ ] table 文字自动断行添加 hyphen
- [x] algo 格式调整
- [x] policy 测试图

5
period/daily/26/260116.md Normal file
View File

@@ -0,0 +1,5 @@
# TBD
INFO: Reminded 54 papers: [4, 5, 7, 33, 42, 47, 50, 59, 62, 65, 73, 84, 92, 100, 110, 121, 124, 160, 164, 165, 181, 187, 189, 202, 238, 260, 326, 358, 362, 380, 412, 454, 522, 532, 549, 610, 611, 643, 648, 657, 661, 675, 722, 736, 771, 818, 825, 827, 852, 1063, 1123, 1125, 1458, 1579]
INFO: Already leaded 14 papers: [3, 28, 70, 81, 379, 389, 422, 470, 485, 578, 738, 761, 876, 1163]
INFO: Already commented need check 2 papers: [12, 370]

128
period/daily/26/260119.md Normal file
View File

@@ -0,0 +1,128 @@
# TBD
- [x] 如果 vLLM 启动超时（配置失败），直接放弃，而不是继续 trace-replay
- [x] 分析一些 config (-dcp/-pcp) 跑不起来的原因
- [ ] 总结之前工作的 trick，为他们的场景解决了什么问题，从而实现了 0 -> 1, 1 -> 100
- [ ] 开一个 paper repo
# Notes
```
Assertion failed, tensor parallel size 4 must be greater than total num kv heads 4 when enable decode context parallel for GQA/MQA [type=assertion_error, input_value=ArgsKwargs((), {'model_co...timizationLevel.O2: 2>}), input_type=ArgsKwargs]
ERROR 01-19 10:00:22 [multiproc_executor.py:231] Worker proc VllmWorker-3 died unexpectedly, shutting down executor. 10:00:25 [21/1935]
(EngineCore_DP0 pid=3230802) Process EngineCore_DP0:
(EngineCore_DP0 pid=3230802) Traceback (most recent call last):
(EngineCore_DP0 pid=3230802) File "/usr/lib/python3.12/multiprocessing/process.py", line 314, in _bootstrap
(EngineCore_DP0 pid=3230802) self.run()
(EngineCore_DP0 pid=3230802) File "/usr/lib/python3.12/multiprocessing/process.py", line 108, in run (EngineCore_DP0 pid=3230802) self._target(*self._args, **self._kwargs)
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/engine/core.py", line 940, in run_engine_core
(EngineCore_DP0 pid=3230802) raise e
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/engine/core.py", line 927, in run_engine_core
(EngineCore_DP0 pid=3230802) engine_core = EngineCoreProc(*args, engine_index=dp_rank, **kwargs)
(EngineCore_DP0 pid=3230802) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/engine/core.py", line 692, in __init__
(EngineCore_DP0 pid=3230802) super().__init__(
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/engine/core.py", line 113, in __init__
(EngineCore_DP0 pid=3230802) num_gpu_blocks, num_cpu_blocks, kv_cache_config = self._initialize_kv_caches(
(EngineCore_DP0 pid=3230802) ^^^^^^^^^^^^^^^^^^^^^^^^^^^
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/engine/core.py", line 270, in _initialize_kv_caches
(EngineCore_DP0 pid=3230802) self.model_executor.initialize_from_config(kv_cache_configs)
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/executor/abstract.py", line 115, in initialize_from_config
(EngineCore_DP0 pid=3230802) self.collective_rpc("initialize_from_config", args=(kv_cache_configs,))
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/executor/multiproc_executor.py", line 359, in collective_rpc
(EngineCore_DP0 pid=3230802) return aggregate(get_response())
(EngineCore_DP0 pid=3230802) ^^^^^^^^^^^^^^
(EngineCore_DP0 pid=3230802) File "/mnt/debugger/wjh/auto-tuner/tuner/.venv/lib/python3.12/site-packages/vllm/v1/executor/multiproc_executor.py", line 342, in get_response
(EngineCore_DP0 pid=3230802) raise RuntimeError(
(EngineCore_DP0 pid=3230802) RuntimeError: Worker failed with error 'PCP requires attention impls' support, but the impl FlashAttentionImpl does not support PCP.', please check the
stack trace above for the root cause
```
## vLLM `serve` 性能相关 flags 总表（按类别聚合）
| 类别 | Flag（聚合） | 主要影响点（性能/资源） | AITuner 里如何当成 search space |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| **Precision / Quantization / Graph** | `--dtype` | 权重/激活精度直接决定吞吐与显存（FP16/BF16/FP32 等）。 ([vLLM][1]) | **强推荐**作为离散选择（auto/float16/bfloat16/float32…），与硬件/模型强相关。 |
| | `--quantization/-q`, `--allow-deprecated-quantization` | 量化方法决定算子实现、带宽/算力瓶颈与精度。 ([vLLM][1]) | **强推荐**离散选择；需与模型权重格式匹配（AWQ/GPTQ/…）。 |
| | `--enforce-eager/--no-enforce-eager` | True 会禁用 CUDA graph（更灵活但通常更慢）；False 允许混合以取最大性能。 ([vLLM][1]) | **强推荐**二值 knob（尤其影响稳定吞吐与尾延迟）。 |
| | `--compilation-config/-cc` | `torch.compile` + cudagraph capture 细粒度配置（mode、capture sizes、backend 等），影响吞吐/稳定性/启动开销。 ([vLLM][1]) | **推荐**作为结构化 knob（可先只调 `mode` 与 `cudagraph_capture_sizes`）。 |
| | `--optimization-level` | 用启动时间换性能（-O0…-O3，默认 O2）。 ([vLLM][1]) | **推荐**小离散空间（0/1/2/3），尤其对服务长期运行场景。 |
| **Model length / Attention behavior** | `--max-model-len` | 直接决定 KV cache 上限与显存占用；过大导致 OOM/吞吐下降。支持 `auto`。 ([vLLM][1]) | **强推荐**作为核心连续/离散 knob（可按 workload 分布设上界）。 |
| | `--disable-sliding-window` | 禁用滑窗（对支持滑窗的模型）会改变注意力范围/计算与显存。 ([vLLM][1]) | **可选**二值 knob（依模型/正确性要求）。 |
| | `--disable-cascade-attn` | 影响 v1 的 cascade attention 启用策略（通常用于数值问题规避；可能影响性能）。 ([vLLM][1]) | **可选**（一般不作为主要调参维度，除非你在做稳定性-性能权衡）。 |
| | `--attention-backend` | 强制 attention backend（默认自动选择）。 ([vLLM][1]) | **推荐**离散 knob（不同 GPU/驱动/shape 下差异很大）。 |
| **Parallelism topology** | `--tensor-parallel-size/-tp`, `--pipeline-parallel-size/-pp` | TP/PP 改变通信/并行度/显存分片方式，是吞吐与尾延迟的关键结构性 knob。 ([vLLM][1]) | **强推荐**核心离散空间（受 GPU 数与模型结构约束）。 |
| | `--data-parallel-size/-dp` | DP 复制模型以提升吞吐（服务侧并发/负载均衡关键）。 ([vLLM][1]) | **强推荐**（常与外部 LB、KV 策略联动）。 |
| | `--decode-context-parallel-size/-dcp`, `--prefill-context-parallel-size/-pcp` | 在不改变 world size 的前提下复用 TP GPUs 做 DCP/PCP；影响 KV 放置与 decode/prefill 并行。 ([vLLM][1]) | **推荐**离散空间（需满足 `tp_size` 可整除等约束）。 |
| | `--cp-kv-cache-interleave-size`, `--dcp-kv-cache-interleave-size` | 控制 DCP/PCP 下 KV cache 的交错存储粒度，影响访问局部性/通信/吞吐。 ([vLLM][1]) | **推荐**小离散空间（1 / block_size / 若干倍数），高度依赖 workload。 |
| **Distributed executor / deployment backend** | `--distributed-executor-backend` | `mp/ray/uni/external_launcher` 影响多进程/多机执行模式与开销。 ([vLLM][1]) | **通常固定**（由部署环境决定）；AITuner 可把它当“环境维度”。 |
| | 多机参数：`--nnodes/-n`, `--node-rank/-r`, `--master-addr`, `--master-port` | 多机 `mp` 模式的控制面配置。 ([vLLM][1]) | **不建议调优**（属于集群 wiring）。 |
| | DP 组网：`--data-parallel-rank/-dpn`, `--data-parallel-start-rank/-dpr`, `--data-parallel-size-local/-dpl`, `--data-parallel-address/-dpa`, `--data-parallel-rpc-port/-dpp`, `--data-parallel-backend/-dpb` | DP rank/本地副本/通信方式等，影响 LB/扩展方式与开销。 ([vLLM][1]) | **部分可调**：通常只把 `dp`、`dpb`、LB 模式作为空间；其余固定。 |
| | LB 模式：`--data-parallel-hybrid-lb/-dph`, `--data-parallel-external-lb/-dpe` | online serving 的 DP 负载均衡策略，影响吞吐与尾延迟。 ([vLLM][1]) | **推荐**二值空间（尤其多节点/多副本场景）。 |
| **MoE / Expert parallel & communication** | `--enable-expert-parallel/-ep` | MoE 层使用 EP 替代 TP（通信/算子形态变化大）。 ([vLLM][1]) | **强推荐**（MoE 模型的关键结构性 knob）。 |
| | `--all2all-backend` | MoE all2all 通信后端选择（吞吐/延迟差异显著）。 ([vLLM][1]) | **强推荐**离散空间（按硬件/网络栈筛选）。 |
| | `--enable-return-routed-experts` | 返回 routed experts（通常增加返回/处理开销）。 ([vLLM][1]) | **一般关闭**；若业务需要可做“开销开关”。 |
| **Dual-batch overlap / microbatching** | `--enable-dbo`, `--ubatch-size`, `--dbo-decode-token-threshold`, `--dbo-prefill-token-threshold` | DBO 与 microbatch 策略，直接影响流水化程度、吞吐、TTFT/TPOT tradeoff。 ([vLLM][1]) | **强推荐**：对“prefill-heavy vs decode-heavy” workload 很敏感。 |
| **KV cache sizing & residency** | `--block-size` | KV cache block 粒度影响碎片化、prefix cache/调度行为与吞吐。 ([vLLM][1]) | **强推荐**小离散空间（常见 8/16/32…）。 |
| | `--gpu-memory-utilization` | 预留给 KV cache 的显存比例，直接决定可容纳并发与最大上下文。 ([vLLM][1]) | **强推荐**连续空间（例如 0.80–0.98，需 OOM guard）。 |
| | `--kv-cache-memory-bytes` | 直接指定 KV cache bytes（比 utilization 更硬）。 ([vLLM][1]) | **可选**：当你想把 search space 显式化为 bytes。 |
| | `--num-gpu-blocks-override` | 手动覆盖 GPU blocks 数量（影响可用 KV 容量与并发）。 ([vLLM][1]) | **可选**：更“底层”，适合研究型调优。 |
| **KV cache dtype / scaling / fast-prefill** | `--kv-cache-dtype` | KV cache 精度（auto/fp8…）影响带宽与显存。 ([vLLM][1]) | **推荐**离散空间（尤其 FP8 KV 的吞吐潜力/数值风险）。 |
| | `--calculate-kv-scales` | 计算 KV scales（为 FP8 KV 等服务），会引入额外计算但可能换来更好带宽/容量。 ([vLLM][1]) | **可选**：与 KV dtype 强绑定的条件 knob。 |
| | `--kv-sharing-fast-prefill` | fast prefill 的 KV sharing 行为，影响 prefill 吞吐与缓存复用。 ([vLLM][1]) | **推荐**二值空间（对长 prompt/复用场景很关键）。 |
| **Prefix caching** | `--enable-prefix-caching`, `--prefix-caching-hash-algo` | prefix cache 命中可显著降低 prefill；hash 算法影响开销/碰撞/性能。 ([vLLM][1]) | **强推荐**（你的 trace-replayer + block-hash 场景尤其关键）。 |
| **KV / CPU swap / offloading** | `--swap-space` | CPU swap 空间（GiB）用于溢出，影响 OOM vs 延迟退化。 ([vLLM][1]) | **推荐**：作为“容量-延迟退化”权衡 knob。 |
| | `--kv-offloading-size`, `--kv-offloading-backend` | 启用 KV offloading 到 CPU（native 或 lmcache），显著改变延迟/吞吐曲线。 ([vLLM][1]) | **推荐**：作为条件结构 knob（offloading 开/关 + backend + size）。 |
| **Batching / scheduling capacity** | `--max-num-seqs` | 批内最大并发序列数，直接决定吞吐与每步调度开销。 ([vLLM][1]) | **强推荐**核心整数空间（与 KV 容量强耦合）。 |
| | `--max-num-batched-tokens` | 批内 tokens 上限（吞吐/延迟核心）。 ([vLLM][1]) | **强推荐**：通常需要和 TTFT/TPOT 的目标函数做权衡。 |
| | `--max-num-running-requests`, `--max-num-requests` | 运行中/总请求上限（背压策略），影响尾延迟与拒绝率。 ([vLLM][1]) | **推荐**：更偏服务质量控制；也会影响队列与 p95。 |
| **Chunked / partial prefill** | `--enable-chunked-prefill` | 启用 chunked prefill（改善交互性/TTFT，但影响吞吐与调度复杂度）。 ([vLLM][1]) | **强推荐**二值 knob（对长 prompt + 在线场景很关键）。 |
| | `--max-num-partial-prefills`, `--max-long-partial-prefills`, `--long-prefill-token-threshold` | partial prefill 的并发与阈值控制，影响 TTFT/吞吐/公平性。 ([vLLM][1]) | **推荐**：作为 chunked-prefill 开启后的条件整数空间。 |
| **Scheduler behavior knobs** | `--num-scheduler-steps` | 每次输出 token 的调度步数（可改变调度-算子重叠/吞吐）。 ([vLLM][1]) | **推荐**小整数空间。 |
| | `--scheduler-delay-factor` | scheduler 延迟因子（吞吐 vs 延迟）。 ([vLLM][1]) | **可选**连续小范围。 |
| | `--scheduler-cls` | 自定义 scheduler 类（强影响行为）。 ([vLLM][1]) | **通常固定**（更像“选择调度器实现”而非调参）。 |
| | `--enable-sleep-mode` | 空闲时 sleep（省电/降温；唤醒开销影响延迟）。 ([vLLM][1]) | **可选**（取决于业务是否追求极致 tail latency）。 |
| **Speculative decoding / return-size** | `--disable-logprobs-during-spec-decoding` | speculative decoding 时禁用 logprobs 以减少开销。 ([vLLM][1]) | **可选**（若业务不需要 logprobs，通常应打开该禁用）。 |
| | `--max-logprobs`, `--logprobs-mode` | logprobs 返回规模与内容模式会显著增加计算与输出体积；`-1` 可能 OOM。 ([vLLM][1]) | **推荐**作为“开销/功能”维度；对性能目标通常应限制。 |
| **Frontend / API process scaling** | `--api-server-count` | API 进程数；可缓解前端解析/IO/序列化瓶颈（多核机器常见收益）。 ([vLLM][1]) | **推荐**：作为与 CPU/IO 相关的整数空间。 |
| | `--disable-frontend-multiprocessing` | 禁用前端多进程可能降低并发处理能力。 ([vLLM][1]) | **一般不建议**作为优化 knob（多数场景保持多进程）。 |
| **Logging / observability overhead** | `--disable-log-stats`, `--disable-log-requests`, `--max-log-len` | 统计与请求日志会引入 CPU/IO 开销，尤其高 QPS。 ([vLLM][1]) | **建议**在性能基准时统一关闭或固定，避免噪声。 |
| | `--collect-detailed-traces`, `--otlp-traces-endpoint` | 详细 tracing 可能引入“昂贵或阻塞”操作并影响性能。 ([vLLM][1]) | **不要纳入自动 search**；应作为诊断模式开关。 |
| | `--kv-cache-metrics`, `--kv-cache-metrics-sample`, `--cudagraph-metrics`, `--enable-layerwise-nvtx-tracing`, `--enable-mfu-metrics` | 指标/trace 会带来额外开销（部分采样降低开销；NVTX 与 cudagraph 互斥）。 ([vLLM][1]) | **诊断开关**：建议 AITuner 固定关闭，仅在分析阶段开启。 |
| | `--profiler-config` | profiler 会显著影响性能（profiling 模式）。 ([vLLM][1]) | **不作为 search**；仅用于测量与归因。 |
| **Disaggregated / KV transfer** | `--tokens-only` | 仅启用 Tokens In<>Out endpoint（面向 Disaggregated Everything）。 ([vLLM][1]) | **环境/架构维度**（通常不与常规 serving 混在同一空间）。 |
| | `--speculative-config` | speculative decoding 配置（结构化），强影响吞吐/延迟。 ([vLLM][1]) | **推荐**：结构化 knob（但需要你定义可调子字段集合）。 |
| | `--kv-transfer-config` | KV 传输配置（结构化），用于分离式架构/跨实例 KV。 ([vLLM][1]) | **推荐（条件）**：只在 disaggregated/多实例 KV 场景调。 |
| | `--kv-events-config`, `--ec-transfer-config` | KV 事件发布与 EC cache transfer（结构化）。 ([vLLM][1]) | **条件 knob**：多节点/缓存协同架构才有意义。 |
| **Multimodal performance knobs（若跑 MM 模型）** | `--mm-processor-cache-gb`, `--mm-processor-cache-type`, `--mm-shm-cache-max-object-size-mb` | MM 预处理缓存大小/类型影响 CPU 开销与内存占用（并随进程数复制）。 ([vLLM][1]) | **推荐（条件）**：高复用图像/视频输入场景会明显受益。 |
| | `--mm-encoder-tp-mode`, `--mm-encoder-attn-backend` | MM encoder 的并行策略与 attention backend，直接影响 encoder 吞吐。 ([vLLM][1]) | **推荐（条件）**：作为离散选择。 |
| | `--limit-mm-per-prompt`, `--video-pruning-rate`, `--skip-mm-profiling` | 限制输入规模/视频剪枝会改变 token/encoder 负载；skip profiling 主要影响启动。 ([vLLM][1]) | **建议**：把 input 规模限制当作 workload/profile 约束；剪枝率可作为质量-性能权衡 knob。 |
| **LoRA performance knobs（若启用 LoRA）** | `--enable-lora`, `--max-loras`, `--max-lora-rank`, `--max-cpu-loras` | LoRA 会引入额外计算与管理开销；batch 内 LoRA 数/rank 直接影响吞吐。 ([vLLM][1]) | **推荐（条件）**：在 LoRA serving 场景纳入空间；否则固定关闭。 |
| | `--fully-sharded-loras` | 在高 seq_len / 高 rank / 大 TP 下可能更快。 ([vLLM][1]) | **推荐（条件）**二值 knob。 |
1. **结构层（Topology / Memory feasibility）**：`tp/pp/dp/dcp/pcp` + `max-model-len` + `gpu-memory-utilization` + `block-size`（先保证可行，不 OOM）。 ([vLLM][1])
2. **吞吐-延迟层（Batching / Scheduling / Overlap）**：`max-num-batched-tokens`, `max-num-seqs`, `chunked-prefill + partial-prefill family`, `enable-dbo + thresholds`。 ([vLLM][1])
3. **内核层（Kernel / Compile / Backend）**：`attention-backend`, `enforce-eager`, `compilation-config`,（MoE 时）`all2all-backend`。 ([vLLM][1])
| 类别 | Flag | 类型/取值形态 | 作用（与性能相关的核心机制） | 典型权衡 / 约束关系 |
| --------------------- | -------------------------------------- | ---------------- | ------------------------------------------------------------------- | ---------------------------------------------------- |
| Parallelism | `--tensor-parallel-size/-tp` | int | Tensor 并行度；决定 GEMM/Attention 的分片与跨卡通信形态，强影响吞吐、显存、p95。 | 需满足 `tp*pp` 不超过可用 GPU；通信带宽不足会拉低 TP 收益。 |
| Parallelism | `--pipeline-parallel-size/-pp` | int | Pipeline 并行度；通过层切分减少单卡显存压力，但引入流水气泡与跨 stage 同步。 | 可能降低单请求 latency（气泡/flush）；更适合大模型或显存受限。 |
| Parallelism | `--data-parallel-size/-dp` | int | Data 并行（模型副本数）；提升吞吐/并发能力，配合负载均衡影响尾延迟。 | 会复制权重占用更多 GPU；与请求路由、cache 复用策略耦合。 |
| Context Parallel | `--decode-context-parallel-size/-dcp` | int | Decode 阶段的 context parallel；复用 TP GPU 做 decode 并行（改变 KV 放置/通信）。 | 需要与 `tp`、KV cache 组织匹配（通常有整除/拓扑约束）。 |
| Context Parallel | `--prefill-context-parallel-size/-pcp` | int | Prefill 阶段的 context parallel；提升长 prompt prefill 吞吐或降低峰值显存。 | 与 `dcp` 类似受 `tp`/拓扑约束；prefill-heavy workload 更敏感。 |
| MoE / Expert Parallel | `--enable-expert-parallel/-ep` | bool | MoE 模型启用 Expert Parallel（用 EP 处理 experts 分布/路由），改变通信与算子结构。 | 仅 MoE 模型适用；常与 all2all 通信后端强耦合。 |
| MoE / Communication | `--all2all-backend` | enum | MoE all-to-all 通信后端选择，直接影响路由通信开销与吞吐。 | 取值依赖编译/环境（如 NCCL 等）；网络/拓扑决定最优。 |
| Overlap / Dual-batch | `--enable-dbo` | bool | 启用 Dual-batch overlap；通过将不同阶段/批次重叠执行提高利用率、吞吐。 | 可能牺牲 TTFT 或引入调度复杂度；与阈值/ubatch 强绑定。 |
| Overlap / Microbatch | `--ubatch-size` | int | microbatch（uBatch）大小；控制 DBO 下切分粒度与重叠机会，影响吞吐与调度开销。 | 太小调度开销大；太大重叠不足、可能增加峰值显存/延迟。 |
| Overlap / Threshold | `--dbo-decode-token-threshold` | int | Decode token 数阈值；达到阈值才触发/采用 DBO 的相关策略。 | 对 decode-heavy workload 敏感；阈值过低可能增加干扰，过高则收益不足。 |
| Overlap / Threshold | `--dbo-prefill-token-threshold` | int | Prefill token 数阈值；控制 prefill 场景下 DBO 的启用门槛。 | 对长 prompt 场景敏感；与 chunked-prefill 可能产生交互。 |
| KV Cache / Memory | `--block-size` | int（常见 8/16/32…） | KV cache 分块粒度；影响碎片、prefix 复用、调度/缓存命中与吞吐。 | 小 block 碎片少但管理开销增；大 block 管理轻但浪费显存、影响并发。 |
| Batching | `--max-num-seqs` | int | 单 step/批内最大并发序列数；直接决定并发与调度开销、吞吐上限。 | 受 KV 容量、`max-num-batched-tokens` 约束；过大可能恶化尾延迟。 |
| Batching | `--max-num-batched-tokens` | int | 单 step/批内 token 总上限；吞吐-延迟（TTFT/TPOT）核心 knob。 | 越大吞吐越高但 TTFT/p95 可能升；与 prefill/decode 负载结构强相关。 |
| Prefill Scheduling | `--enable-chunked-prefill` | bool | 启用 chunked prefill；将长 prefill 切块与 decode 交错，提高交互性/TTFT（常见），并改变调度行为。 | 可能降低纯吞吐或增加调度复杂度；与 `max-num-batched-tokens`、DBO 阈值联动。 |

0
period/daily/26/260129.md Normal file
View File

6
period/daily/26/260304.md Normal file
View File

@@ -0,0 +1,6 @@
1. 刘嘉敏
- 上海交大 IEEE CS 大三
- 实习，不确定在IPADS读研/博
- **大哥** 家豪
- **任务** 辅助 agentic AITuner 项目的 micro benchmark 测试
- **机器** H100-九章

26
period/daily/26/260306.md Normal file
View File

File diff suppressed because one or more lines are too long

1275
period/daily/26/260307.md Normal file
View File

File diff suppressed because it is too large Load Diff

2
period/daily/26/260309.md Normal file
View File

@@ -0,0 +1,2 @@
- [ ] 设计怎么画图，证明 engine / workload / hardware 的演化速度

7
period/daily/26/260310.md Normal file
View File

@@ -0,0 +1,7 @@
- [ ] 设计怎么画图，证明 engine / workload / hardware 的演化速度
- [ ] 证明 trace-replayer 比 synthesis 好
- [ ] 证明 one instance tuning can work in cluster

121
period/daily/26/260312.md Normal file
View File

@@ -0,0 +1,121 @@
# TODO
- [ ] 分析开启 EP 性能好坏的本质原因
- [ ] 分析内部频繁修改 cuda_graph_sizes，会对性能有什么影响，怎么对应到 engine 性能
workload prefill 强度的定义，考虑三个维度：
- 总 prefill tokens
- request input length 的分布（长度究竟怎么影响？）
- burst（QPS CV）
`export VLLM_DISABLE_COMPILE_CACHE=1`
`export VLLM_FLASHINFER_ALLREDUCE_FUSION_THRESHOLDS_MB='{"4":0}'`
总 prefill load 增大，但是从 TP1 -> TP2，不仅 TPS 增大，而且 latency 降低
| **window_id** | trace_type | time_scale | prefill_tokens_per_second | real_prefill_tokens_per_second | prefix_cache_hit_tokens_per_second | total_prefill_tokens | total_real_prefill_tokens | total_prefix_cache_hit_tokens | prefix_cache_hit_rate | config_id | tensor_parallel_size | max_num_seqs | max_num_batched_tokens | goodput | goodput_per_gpu | num_slo_pass | total_requests | num_errors | experiment_duration | mean_ttft | p95_ttft | started_at | finished_at | log_path | server_log_path | num_good_tokens | good_token_per_second | good_token_per_second_per_gpu |
| ------------- | ---------- | ---------- | ------------------------- | ------------------------------ | ---------------------------------- | -------------------- | ------------------------- | ----------------------------- | --------------------- | --------- | -------------------- | ------------ | ---------------------- | ----------------- | ----------------- | ------------ | -------------- | ---------- | ------------------- | ------------------ | ------------------ | ------------------ | ------------------ | ------------------------------------------------- | ------------------------------------------------------ | --------------- | --------------------- | ----------------------------- |
| **chat_w06** | chat | 1.0 | 12045.351666666700 | 6850.685 | 5194.666666666670 | 7227211 | 4110411 | 3116800 | 0.4312590292437840 | A | 1 | 32 | 8192 | 5.426623109964860 | 5.426623109964860 | 3258 | 3436 | 0 | 600.373369216919 | 0.735489982664932 | 2.7120952010154700 | 1773196637.8148000 | 1773197238.188170 | results/experiment_logs/chat_w06__config_A.jsonl | results/experiment_logs/chat_w06__config_A.server.log | 7119724 | 11858.82713166710 | 11858.82713166710 |
| **coder_w02** | coder | 1.0 | 31264.74 | 14433.46 | 16831.280000000000 | 18758844 | 8660076 | 10098768 | 0.5383470324717240 | B | 2 | 64 | 16384 | 5.418584987116260 | 2.709292493558130 | 3252 | 3264 | 1 | 600.1566843986510 | 0.6616424000997540 | 2.0865608930587800 | 1773206129.1402500 | 1773206729.2969400 | results/experiment_logs/coder_w02__config_B.jsonl | results/experiment_logs/coder_w02__config_B.server.log | 18745884 | 31234.98327571430 | 15617.49163785710 |
- EP off
```
gahow@Gahow-MBA configs % rg '"enable_expert_parallel": false'
qwen3-coder-plus/1m-0922-config-fix/h20_prefill.config
38: "enable_expert_parallel": false,
qwen3-coder-plus/1m-0922-config-fix/h20_decode.config
74: "enable_expert_parallel": false,
qwen3-plusp/256k-1106/h20_prefill.config
43: "enable_expert_parallel": false,
qwen3-235b-a22b/256k-0717/h20_prefill.config
43: "enable_expert_parallel": false,
qwen3-max/256k-0922-fp4/h20_prefill.config
43: "enable_expert_parallel": false,
qwen3-235b-a22b/256k-0723-think-cs/h20_prefill.config
44: "enable_expert_parallel": false,
```
- EP on
```
gahow@Gahow-MBA configs % rg '"enable_expert_parallel": true'
qwen3-max/256k-0922-fp4-pc-eplb/h20_decode.config
74: "enable_expert_parallel": true,
qwen3-235b-a22b/256k-0717/h20_decode.config
76: "enable_expert_parallel": true,
qwen3-1.16t-a86b/256k-0922-sq-re-nvfp4/l20c_decode.config
76: "enable_expert_parallel": true,
qwen3-1.16t-a86b/256k-0922-sq-re-nvfp4/l20c_prefill.config
44: "enable_expert_parallel": true,
qwen3-plusp/256k-1106/h20_decode.config
76: "enable_expert_parallel": true,
qwen3-235b-a22b/256k-0723-think-cs/h20_decode.config
77: "enable_expert_parallel": true,
```
- TP
```
gahow@Gahow-MBA configs % rg '"tensor_parallel_size"'
qwen3-max/256k-0922-fp4/h20_prefill.config
51: "tensor_parallel_size": 8,
qwen3-max/256k-0922-fp4-pc-eplb/h20_decode.config
84: "tensor_parallel_size": 8,
qwen3-1.16t-a86b/256k-0922-sq-re-nvfp4/l20c_decode.config
84: "tensor_parallel_size": 8,
qwen3-coder-plus/1m-0922-re-fp8/h20.config
14: "tensor_parallel_size": 4,
qwen3-1.16t-a86b/256k-0922-sq-re-nvfp4/l20c_prefill.config
96: "tensor_parallel_size": 8,
qwen3-coder-plus/1m-0922-config-fix/h20_prefill.config
43: "tensor_parallel_size": 4,
qwen3-coder-plus/1m-0922-config-fix/h20_decode.config
84: "tensor_parallel_size": 4,
qwen3-30b-a3b-with-gate-next-fp4/instruct-fp4/h20.config
28: "tensor_parallel_size": 1,
```
- DP
```
gahow@Gahow-MBA configs % rg '"data_parallel_size"'
qwen3-plusp/256k-1106/h20_decode.config
85: "data_parallel_size": 8,
qwen3-235b-a22b/256k-0717/h20_decode.config
85: "data_parallel_size": 8,
qwen3-235b-a22b/256k-0723-think-cs/h20_decode.config
86: "data_parallel_size": 8,
qwen3-max/256k-0922-fp4-pc-eplb/h20_decode.config
83: "data_parallel_size": 1,
qwen3-1.16t-a86b/256k-0922-sq-re-nvfp4/l20c_decode.config
83: "data_parallel_size": 1,
qwen3-coder-plus/1m-0922-config-fix/h20_decode.config
83: "data_parallel_size": 1,
```

4
period/daily/26/260317.md Normal file
View File

@@ -0,0 +1,4 @@
backup 计划 -> OSS：
ali/data/formatted_trace

10
period/daily/26/260320.md Normal file
View File

@@ -0,0 +1,10 @@
```bash
OLD="/dashscope/caches/application/wjh"
NEW="/home/admin/cpfs/wjh"
grep -rl "$OLD" .venv | xargs sed -i "s|$OLD|$NEW|g"
find .venv -name "*.pyc" -delete
python -c "import sys; print(sys.prefix)"
```

12
period/weekly/25/0217-0223.md Normal file
View File

@@ -0,0 +1,12 @@
# TBD
- [ ] 把 deepseek v3 跑起来。为什么 decode 需要 320 卡？如果多个 experts 在同一张卡会怎么样？8 卡下性能如何？expert parallelism 怎么 work 的？
- [x] 找到可以在 8 * A100 上跑的 V3 【DeepSeek-V3-AWQ】
- [ ] 修改 vLLM，分析 expert 如何激活、如何做 expert parallelism
- [ ] 测试推理性能
- [ ] 分析 experts 负载状况
- [ ] 新 trace 的统一格式化处理，分析对比与之前 1h trace 是否存在区别，是否有新特征
- [x] 给出统一的 trace 格式规范，写好 doc
- [x] 支持 streaming 处理，格式化数据
- [ ] 刷新之前的测试图
- [ ] 调研 TensorFlow 为什么被 PyTorch 干趴下了，做对了什么/做错了什么？

3
period/weekly/25/0224-0302.md Normal file
View File

@@ -0,0 +1,3 @@
- [ ] vLLM 分布式 KV cache 管理： https://github.com/vllm-project/aibrix
- [x] 准备 FAST'25 KV cache related paper sharing
- [x] 完成 traceA/B 的 24h format

7
period/weekly/25/0303-0309.md Normal file
View File

@@ -0,0 +1,7 @@
- [ ] 调研企业级私有化部署 DeepSeek 的机会
- [ ] llama.cpp 有什么问题？是不是只适合单机？
- [ ] ktransformer 相比 llama.cpp 为什么有优势？他们是不是只 focus 在单机？企业级部署不像个人使用，提供 global scheduler 后跟多个单机跑有什么问题？分布式并行跑有什么问题？
- [ ] M2 Ultra 这种 unified memory 芯片有提供低成本部署的机会吗？
- 机会点：计算很可能在往稀疏性发展，MoE 等。m 系列芯片这种内存大算力一般的芯片可能具有一定优势
- m 系列芯片互联带宽在 10～40Gb 之间（相比 450Gb+ 的 NVLink），会不会成为 bottleneck

16
period/weekly/25/0310-0316.md Normal file
View File

@@ -0,0 +1,16 @@
- [x] 提供一个构造 不同时间段 / 不同总时长 / 不同 QPS 的 vLLM 真实测试的 trace 构造器，需要保证：小 QPS 是大 QPS 的子集（避免平均长度不同）
- [x] trace 分析
- [x] QPS
- [x] 平均输入输出长度
- [x] 有上一轮对话的比例
- [x] 上下轮对话之间间隔时间的 mean/p90/p50/...
- [ ] 不同 workload 的 one-shot 比例
- [ ] s3-fifo 的不同 one-shot 比例与 S/M 比例的关系
- [ ] DistServe 的 simulator 做了什么？

4
period/weekly/25/0317-0323.md Normal file
View File

@@ -0,0 +1,4 @@
- [ ] Sarathi(https://arxiv.org/abs/2308.16369)
- [ ] HybridFlow(https://arxiv.org/pdf/2409.19256)

0
period/weekly/25/0331-0406.md Normal file
View File

1
period/weekly/25/0512-0518.md Normal file
View File

@@ -0,0 +1 @@
- [ ] 使用 trace 测试 MoE 的 activate pattern

6
period/weekly/25/0714-0720.md Normal file
View File

@@ -0,0 +1,6 @@
- [ ] review EuroSys paper <0/5>
- [ ] deep research for review the comments from reviewers and review papers
- [ ] run deep research to check the agent workflow overhead
- [ ] 整理 ali 的 infra arch