Initial commit: obsidian to gitea
This commit is contained in:
128
period/daily/26/260119.md
Normal file
128
period/daily/26/260119.md
Normal 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 阈值联动。 |
|
||||
Reference in New Issue
Block a user