gahow/obsidian
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
obsidian/period/daily/26/260119.md

38 KiB
Raw Permalink Blame History

TBD

  • 如果 vLLM 启动超时（配置失败），直接放弃，而不是继续 trace-replay

  • 分析一些 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 阈值联动。