Files

Gahow Wang a57afa86b4 Initial commit: obsidian to gitea

2026-05-07 15:04:41 +08:00

25 KiB

Raw Blame History

AITuner Trace A | 10 min https://nas.gahow.org/webdav/ai_tuner_logs/dash_prod/ai_tuner_260307-152305.jsonl

2026-03-08 06:28:06 [INFO] run_trace_replayer summary: success=True best_goodput_qps_per_gpu=0.798171666969416 selected_time_scale=0.4678486930206418
2026-03-08 06:28:18 [INFO] Agent loop finished. Total runs=5, LLM calls=6
2026-03-08 06:28:18 [INFO] Original vs best production config diff:
2026-03-08 06:28:18 [INFO]   engine_args.block_size: 64 -> 32
2026-03-08 06:28:18 [INFO]   engine_args.enable_expert_parallel: False -> True
2026-03-08 06:28:18 [INFO]   engine_args.max_num_batched_tokens: 8192 -> 32768
2026-03-08 06:28:18 [INFO]   engine_args.tensor_parallel_size: 4 -> 2
2026-03-08 06:28:18 [INFO]   envs.VLLM_MOE_USE_DEEPEP: '0' -> '1'
2026-03-08 06:28:18 [INFO] Baseline vs best production config diff:
2026-03-08 06:28:18 [INFO]   engine_args.block_size: 64 -> 32
2026-03-08 06:28:18 [INFO]   engine_args.enable_expert_parallel: False -> True
2026-03-08 06:28:18 [INFO]   engine_args.max_num_batched_tokens: 8192 -> 32768
2026-03-08 06:28:18 [INFO]   engine_args.tensor_parallel_size: 4 -> 2
2026-03-08 06:28:18 [INFO]   envs.VLLM_MOE_USE_DEEPEP: '0' -> '1'
2026-03-08 06:28:18 [INFO] Persisted best production config to /usr/local/lib/python3.12/dist-packages/vllmgen/configs/qwen3-235b-a22b/256k-0717/h20.config
2026-03-08 06:29:02 [INFO] AI tuner JSONL log: runs/ai_tuner_logs/ai_tuner_260307-152305.jsonl

(codex-tuner) wjh@ds-dda11ac6-1-847f4dd4c5-vg6mr:~/auto-tuner/tuner$ cat micro_trace_replayer/comm_tp4_noep_traceA_10min.jsonl.summary.json
{
  "duration_ms": "600078.484",
  "e2e_mean_ms": "429.185",
  "e2e_p90_ms": "1163.643",
  "e2e_p95_ms": "1557.812",
  "e2e_p99_ms": "2594.410",
  "output_tokens_total": "2048",
  "requests_success": "2048",
  "requests_total": "2048",
  "throughput_rps": "3.413",
  "throughput_tps": "3.413",
  "tpot_mean_ms": "0.000",
  "ttft_mean_ms": "0.000"
}
(codex-tuner) wjh@ds-dda11ac6-1-847f4dd4c5-vg6mr:~/auto-tuner/tuner$ cat micro_trace_replayer/ali_tp4_noep_traceA_10min.jsonl.summary.json
{
  "duration_ms": "600082.137",
  "e2e_mean_ms": "523.779",
  "e2e_p90_ms": "1478.267",
  "e2e_p95_ms": "2008.634",
  "e2e_p99_ms": "3050.164",
  "output_tokens_total": "2048",
  "requests_success": "2048",
  "requests_total": "2048",
  "throughput_rps": "3.413",
  "throughput_tps": "3.413",
  "tpot_mean_ms": "0.000",
  "ttft_mean_ms": "0.000"
}

现存的问题

阿里的生产环境上测试的链路是 API -> Gateway -> Chat Serving (CPU machine for encoding) -> Model Serving (vLLM) 此时存在一个问题，AITuner 不再能直接获取到 vLLM 引擎上的各种性能相关的指标（kvcache hit ratio / kvcache usage / queuing ratio / avg running / avg queuing）

"VLLM_ATTENTION_BACKEND": "FLASH_ATTN_VLLM_V1" -> "FLASH_ATTN" link

内部存在更多不存在清楚文档定义的中间状态值，tuning 系统对此难以感知，缺少每个 knob 清晰的可取值范围与对应的含义

现状总结

git log --oneline -- util/vllmgen/configs/qwen3-235b-a22b/256k-0717/h20_prefill.config

一个模型（Qwen3-235B-A22B）的 prefill 版本在 25.11.18 - 26.01.08 有 10 次 commit

补充

所有修改 configs 的 commit：

git log --oneline -- util/vllmgen/configs

从 25.07.31 (vllmgen 的首次提交) ～ 26.02.03 这段时间（大约 6 个月）总共有 92 次 commit（平均每 2 天一次 commit）

configs commit 总结

ecc7b539136cd34d29bf4cdb215ae298c019be76 initial commit: common.config

36faa64b969b633187645b29fa997b177d120f37 添加 util/vllmgen/configs/qwen3-235b-a22b-h20-4.config

929e6bc9c9ac17fdd087ed74c9dadc41c2812d43 添加 util/vllmgen/configs/qwen3-235b-a22b/128k-0426-hf-fp4/h20.config、util/vllmgen/configs/qwen3-30b-a3b/128k-0425-fp4/h20.config

cb65b0c128c07725817278f2ddb020ddd2df0722 util/vllmgen/configs/qwen3-30b-a3b/128k-0425-fp4/h20.config，加长 max_seq_len

22d382a13baf68e278dd1c616b379d59f34dcdbe util/vllmgen/configs/qwen3-30b-a3b/128k-0425-fp4/h20.config，更新 use vllm v1

==09b005191f10e2b93c3159c6d0d0d6735287269b== util/vllmgen/configs/qwen3-30b-a3b/128k-0425-fp4/h20.config 添加：

"compilation_config": {
	"use_inductor": false,
	"custom_ops": [
		"all"
	]
},

9007270573a7a6c3a8d88bcc45261751fd2379f3 添加 util/vllmgen/configs/draft-models/qwen3-235b-a22b/0723-thinking-eagle-0821/h20.config

7f392d7e608974fc56f9fd6913d6be3f52ff8ec9 更新 util/vllmgen/configs/qwen3-235b-a22b/256k-0723-thinking-fp4/h20.config 和 util/vllmgen/configs/qwen3-30b-a3b/128k-0425-fp4/h20.config 的 max_num_batched_tokens 添加 util/vllmgen/configs/qwen3-vl-30b-a3b/128k-0717-fp4/h20.config

4e90f0582cd7f86312e5ae01c9cd7d59132723fd util/vllmgen/configs/qwen3-vl-30b-a3b/128k-0717-fp4/h20.config 中 enable_prefix_caching 开启

4535fd0e39f8a181c73a7669eaa379feae26fe57 添加 util/vllmgen/configs/qwen3-vl-235b-a22b/256k-thinking-0920-fp4/h20.config

60296b817616aaeec919fc9dc68b11dc9f9e9124 删除 VLLM_ENABLE_TORCH_COMPILE

39a9bb43feb6e6b22f7ed8cefe6442d973bf6057 typo

781fee1a1a9ba86228684c1f2a1e0f9726ab3e2b 支持 qwen-coder/max/next

b1c5efe09ef9df162d442fc7b71932d41f3a426b change meta

a3389997e420de0b9c45342be6f806ff9179e193 use PIECEWISE compilation_config for cudagraph_mode

dc0761d070e9068f64e3c33926fe3bc0c7d62f7b remove unused TP size

dc83943aa9f3b2d4c90dde3c6f2fe49458877ba1 bug fix set VLLM_USE_UPSTREAM_FA3=0

216194960c290d64914ffad88338587069889e6c 删除 PIECEWISE

b75c0cf11dedcf4ee0396ec939e1e0e80267593f typo

a09d8da72fc9ca837862b61850cdb324223cfd76 typo

34b32eb885ecb07296d7a2bbe58d5e0ee028d30c 添加：

"VLLM_USE_FLASHINFER_SAMPLER": "0"
"VLLM_ENABLE_TORCH_COMPILE": "1"

adba559382c4ab60738a0b2783e27acc801d2ab7 设置 "VLLM_FLASH_ATTN_USE_UPSTREAM": "0"

517bc31caaf26c6f1cd119a5283f2e5b2cb141c7 使用

"compilation_config": {
	"cudagraph_mode": "PIECEWISE",
	"use_inductor": false,
	"custom_ops": [
		"all"
	]
}

4259a99557467b48cbae606c0092bf0b75ab3f84 meta

e1d1b64420426406afcfe3a36d10172b6473ead8 修改 gpu memory util 避免 kvs swap 的 OOM

13294741780ff79bbab8a54e98286e07a1ba4b0e meta

5b2f35fe49033711c9cfcbd2afe7036905f462a6 "VLLM_VL_VISION_NUM_GRID_PER_SIDE": "27"

ea95b933221ba192d9e0a2a06e6c84bee4a32544 "VLLM_VL_VISION_NUM_GRID_PER_SIDE": "27"

4994e414d8ee812feebe23eed473abcf5166f246

"VLLM_FLASH_ATTN_FP8_ATTENTION": "1",
"VLLM_ENABLE_TORCH_COMPILE": "1"

985ffa6156c37f8a299870722f51bdfec9fba2f4 添加 5090 support util/vllmgen/configs/qwen3-30b-code-switch/v2/5090.config

ae600ea07735cbe03b1b862054133d805f85ed5e 支持 PD 分离：util/vllmgen/configs/qwen3-235b-a22b/256k-0717/h20_prefill.config

98038e62d8f3f7b94079cc287bdf10e4f4c64267 支持一系列 qwen-vl

2f5a20b76049a33d79bbe2a4ab8abd8ae84581c7 typo fix

cc3484b98cfeccc8c9d6426c4f1238545832cc14 删除 "VLLM_VL_VISION_NUM_GRID_PER_SIDE": "27"

d71559b5f3fd6084bc738c4dc22af0566cf133eb meta

3ec865d4b2db0cd98b537124d5ca791e458cba93 支持一系列闭源 qwen-vl 模型

31a07b6eceb0bda01dcd0db4da0e4d390251facb no bladnn gdn by default

896de6b72d079bf4d9c568667189c3d711e9ebde meta

213d89408b1c45d6ae5ed6593268dc41d07eb12e use VLLM_FLASH_ATTN_FP8_ATTENTION

de918bd2d52e30cba3cff640af3f1e73fdb841da add qwen3-vl-235b-a22b pd

7835de1c4fffb8f2c5ad1a8af3501d1dfcc60728 support qwen-vl-max dashgen on L20X and A800

b3d465adb53e993bc4bfc069ad869232fb36823d make draft model support PD decoupling

dcc0ab7fc9ed21c0763086f1ae1428633f53ba8e fix rope scaling 的位置

==f66a954d5e68c829f7d841ed9aa020ec45d11436== 修改 gpu_memory_utilization, max_num_batched_tokens, cuda_graph_sizes (P 和 D 不同）, cudagraph_mode

75ab97b48ffab568b69f9dfd34ffbee4d10c771b meta

f67b2e2ede2b88bf27827a8edd96e38188bccb69 移除 "async_scheduling": false 和 "disable_custom_all_reduce": true

9c497637ad23eb9a9abaf53327e4ff263a4630ea Encode-Prefill-Decode Disaggregation on v6d

b739c437bdac2ba0751853ed4335019f7b7e8486 移除 "async_scheduling": false

85a66eb3a241f900ea785ae0a9b2ac5981f9e9b6 支持 util/vllmgen/configs/qwen3-30b-a3b/1m-thinking-0728-fp4-cs-gate/h20.config

44c01d5177f36e4b0c2802b6aac8439136f79685 支持 util/vllmgen/configs/qwen3-omni/qwen3_omni_final_ckpt_multilingual_0915/h20.config

936f71e642edd3a87286deabff38ae73c7bd3aea 修改 mm_processor_cache_gb 50 -> 10

==0c8dab3e33fc93e98fa15a37b4aa784aa1316abc== 降低 decode max_num_batched_tokens 8192 -> 1024, 提高 decode max_num_seqs 128 -> 192, 提高 prefill max_num_batched_tokens 4096 -> 8192，修改 decode 的 cuda_graph_sizes，增加 128 和 192

ca65f85a37efa5ef95912d1618b0f5405df53c7c support moe eplb

741d586dd1fc0bc98c16fd16146d1f77e72ba4e8 支持 qwen3-max-fp pd

49486c6187263204427074780ac22b4aef475a55 meta

d62a67eeb1eba461fa434a0297717c838d1e7d7d 支持 kvs，gpu_memory_utilization 0.89 -> 0.88

e1fdbf4629f8b70463ae45cc2b0e408712e60af4 add qwen3-vl-plus pd

6b18610c39857c90d5e076b8b693ab847b92a107 PD use eth1

0cb6b11757a5eb46f6a021cee8b7f08b84256410 支持 qwen3-plusp

8915d3fe5c587c2268dfa49dfbf022d2bfd6c7b0 更新 qwen-vl-max

383ce3e60eb9904faa61006452b2be4ff250ec24 chore：mm_processor_cache_gb 含义 false -> 0

8b30846690623a80b51e975718a84a0d571a97ed 添加支持：util/vllmgen/configs/qwen-vl-max/epd_disagg_llm/h20.config

de80aaf239033cf0d59e32e0bf3beee16651fed7 移除 qwen-vl-max 在 a800 上使用 fp8（不被 a800 支持）

9d63c50b3328a1d748929fb4f76cff49ac883b7d chore：mm_processor_cache_gb 含义 false -> 0

==2fe8ab568315c227cfbade4e7759b1767cfa003c== util/vllmgen/configs/qwen3-coder-plus/1m-0922-re-fp8/h20.config 设置 TP4，关闭 kv transfer

5a12337e3f38b0d11b21604a1f3f5e739d6b126b chore: 移除 num_experts: 0

5f591ffe74f15fe9e5b4cd5864471b3ffa76874a 将模型解码配置中的松散 top-k 验证关闭，并调整了异步调度为禁用状态，同时略微增加了 GPU 内存利用率

2e87a5d3e86e597efea8478cc74dd92a9d6dba0b 支持 coder plus 0923 pd + kvs

bdbdf44d4c67462ca5d120b25684a5b8804a7a18 因为今天的 commit 更新了 fp4 perchannel 的加载逻辑，所以需要对模型配置进行更新

85c50bf76194bf52dc2e3e1ce7c8b2e0e17cbfc1 添加 loose topk 相关

"use_loose_topk_verify": 1,
"loose_topk_verify_threshold": 0.95,
"loose_topk_verify_max_tokens": 2000,

d350466cf7d71b4dbcd03bb8ff1ec60b648940a6 chore: VLLM_KVT_MAX_DELAY_MS

936a3b7286425fdd7dc996b6b4f23f19cabdb83b 支持 util/vllmgen/configs/draft-models/ci-test/model-version-v1/h20_batch.config

b3d96f257d229ab7b8d6d6a1b5f92f7d740acd7b util/vllmgen/configs/qwen3-30b-a3b-with-gate-next-fp4/instruct-fp4/h20.config 支持 kvs，max_num_batched_tokens, 1024 -> 4096

1ca19f8042d081c437bf036ca469c946c6c30868 添加

"pass_config": {
	"fuse_norm_quant": false,
	"fuse_act_quant": false,
	"fuse_attn_quant": false
}

80e602a32f0cd59f84e834049161dff5a1aaa6a8 支持 util/vllmgen/configs/qwen3-30b-code-switch/v2/5090.config，移除 flashinfer

7018965a139a5763809e888eb0c35ef9743ad3d8 添加 util/vllmgen/configs/qwen3-235b-a22b/256k-0723-think-cs/h20_prefill.config，更新所有 model 的 PD connection 相关环境变量

6a1b40876d4bc884a805effa0cc7c7a28c38ea01 plusp 等模型支持 kvs

613d885a17360b9f90c10bedf8d900815d8b5668 util/vllmgen/configs/qwen3-plusp/256k-1106/h20_prefill.config，移除 "enforce_eager": false 与 cuda_graph_sizes

29f88ea3e6addf5a155c2bf000e7819171be0b39 fix

1ad174a24cad5e51e2ccf71a828751d4e65c51a6 util/vllmgen/configs/qwen3-omni/qwen3_omni_final_ckpt_multilingual_1124/h20.config, enable_chunked_prefill 开启，添加 max_model_len: 65535

c8f776e277a6545b3e1696a4e9261282bca681f9 Disable the preprocess cache for vl model by default

9d011bf9ec443f7d3ccecd7e44b6d9a526a0089a 增加了任务绕过配置项 VLLM_ENABLE_BYPASS_TASK 并调整了异步调度、GPU内存利用率及前缀缓存的相关设置，关闭 enable_prefix_caching

dab633c1871054cfe823669e970b04d89ba3b7b5 删除：

"DS_LLM_ENABLE_DISAGGREGATED_VIT": "1",
"DS_LLM_LAUNCH_VINEYARD": "0",
"SRPC_STREAM_DISABLE_BAREX": "1"

67ab53a5f673f4fc629c2a4354e2b3ddf556dc08 Support Qwen3.5 VL MTP

27d64ee33ecac2b94efaa44f5bbefa5998574d05 Add KVS config for Qwen3-VL-Plus

8fb2d746069f17e5c6e951b0fd2f5da4c608f3e1 util/vllmgen/configs/qwen3-max/256k-0922-fp4-pc-eplb/h20_decode.config, max_num_seqs 256 -> 512

ebf2b71630984c383f3824eb7e4e45a617416274 "max_num_batched_tokens": 8192 for util/vllmgen/configs/qwen3-vl-plus, prefill

c18e84e20cc15bbc2d14ddb17b26aaf7dc78e94f 添加 speculative_config：

"num_speculative_tokens": 32,
"hf_overrides": {
"max_position_embeddings": 262144
}

3bef0c622d1ec18e652e82cbc24ebf481e9025d5 支持 qwen3-max on l20c

ce495cc242affcfb321cf6dcabf190c3f1589667 qwen3-vl-flash: enable async_schedule

8152532eeb0a191e69b868cc888392a0c74ab0fe qwen3-vl-flash 添加

"pass_config": {
	"fuse_norm_quant": false,
	"fuse_act_quant": false,
	"fuse_attn_quant": false
},

下面这份结论，是基于你给出的 commit 摘要做的归类分析，不是逐个 diff 逐行审阅后的法证级结论；但从系统角度看，已经足够支持一个很清晰的判断：这个仓库里的 config churn，大多数不是在做真正的性能调优，而是在做模型接入、功能启用、兼容修复和运行稳定性修补。

Commit Analysis

1. 结论先说

你列出的 commit 一共 91 个。

我建议用两个口径看“性能相关占比”：

口径	定义	数量	占比
严格口径	直接修改已有配置中的性能 flag 取值，例如 `max_num_batched_tokens`、`max_num_seqs`、`gpu_memory_utilization`、`async_scheduling`、`cuda_graph_sizes`、`torch compile`、`prefix caching` 等	28	30.8%
宽口径	在严格口径基础上，再加上新引入性能相关机制/后端/并行形态，例如 speculative、FP8 attention、PD/KVS 相关配置接入等	约 40	44.0%

也就是说：

如果你关心的是“真正做 tuning 的 commit”，占比大约只有三成；
如果你把性能相关 feature enablement 也算进去，最多也就 四成多；
因此，“绝大部分 commit 与性能优化本身无关”这个观察，在严格口径下是成立的。

这其实很有价值：它说明生产配置仓库的变化，主要是 control-plane churn，而不是 dataplane tuning。

2. 从第一性原理看，为什么会这样

一个线上 vLLM per-model config 仓库，commit 变多，未必意味着“性能状态空间巨大”。更常见的是四类变化：

接入新模型 / 新硬件 / 新模式 例如新增 qwen3-vl、omni、5090、A800、L20C、PD、KVS、MTP。这类变化本质上是“能不能跑 / 怎么接入”，不是“已经能跑后如何把 goodput 调到最优”。
兼容性与正确性修复 例如 typo、rope scaling 位置修复、fp4 per-channel 加载逻辑变化、某后端 upstream 不可用、某硬件不支持 fp8。这类变化的目标是“避免错 / 避免 crash / 避免不支持”。
稳定性与资源安全边界调整 例如 gpu_memory_utilization 从 0.89 到 0.88，避免 KVS swap OOM。这类变化和性能有关系，但很多时候优先级是 survivability，不是 peak throughput。
真正的 steady-state 性能调优 例如：
- max_num_batched_tokens
- max_num_seqs
- async_scheduling
- cuda_graph_sizes
- cudagraph_mode
- torch compile
- prefix caching
- chunked_prefill
- TP
这类 commit 才是你论文里最该抓住的部分。

3. 哪些 commit 真正改了性能相关 flag

我把它们按系统机制分组。

A. batching / scheduling / graph capture 相关

这组是最“像 tuning”的。

7f392d7e... 修改 max_num_batched_tokens
f66a954d... 修改 gpu_memory_utilization、max_num_batched_tokens、cuda_graph_sizes、cudagraph_mode，并区分 P / D
0c8dab3e... decode: max_num_batched_tokens 8192 -> 1024 decode: max_num_seqs 128 -> 192 prefill: max_num_batched_tokens 4096 -> 8192 同时修改 decode cuda_graph_sizes
f67b2e2e... 移除 "async_scheduling": false、"disable_custom_all_reduce": true
b739c437... 移除 "async_scheduling": false
5f591ffe... 关闭 loose top-k verify，关闭 async scheduling，略微增加 gpu_memory_utilization
8fb2d746... decode max_num_seqs 256 -> 512
ebf2b716... prefill max_num_batched_tokens = 8192
ce495cc2... qwen3-vl-flash 开启 async_schedule
1ad174a2... 开启 enable_chunked_prefill，增加 max_model_len
613d885a... 移除 enforce_eager: false 与 cuda_graph_sizes

这类变化背后的理由

这是最典型的系统 tradeoff：

max_num_batched_tokens 决定单 step 的 token 工作量上限。增大它，通常有助于提高 GPU occupancy 和算子摊薄开销；但也会带来更高显存压力、更长单步尾延迟、更难 graph capture。
max_num_seqs 决定并发宽度。 decode 场景中，增大它往往是为了让更多序列并发推进，提升 tokens/s；但太大时 scheduler overhead、KV 压力、尾延迟都会上来。
prefill 和 decode 的最优点本来就不一样。 0c8dab3e... 这种“prefill 提大 token budget，decode 降低 token budget 但提高 seq 数”的改法，系统上非常合理：
- prefill 更偏大矩阵、吃吞吐、适合更大的 batch-tokens
- decode 更偏 memory/bandwidth、每步 token 少、适合更高并发序列数而不是更大 token lump
cuda_graph_sizes / cudagraph_mode 本质是在赌shape 是否足够稳定。如果 workload 形状集中，graph capture 能减少 launch overhead；如果 shape 太散，graph 容易失效甚至成为负担，所以会看到 PIECEWISE 被加上又删掉。
async_scheduling 不是“永远更快”。它在高并发下可能更好，但也可能引入调度抖动、与某些校验逻辑冲突、或在某些模型/路径上带来额外复杂性，所以会出现有的模型开启、有的关闭。

B. memory / cache / 长上下文相关

cb65b0c1... 加长 max_seq_len
4e90f058... 开启 enable_prefix_caching
e1d1b644... 调整 gpu_memory_utilization，避免 KVS swap OOM
d62a67ee... 支持 KVS 时，gpu_memory_utilization 0.89 -> 0.88
936f71e6... mm_processor_cache_gb 50 -> 10
383ce3e6..., 9d63c50b... mm_processor_cache_gb false -> 0
c8f776e2... 默认关闭 VL preprocess cache
9d011bf9... 调整 gpu_memory_utilization、关闭 enable_prefix_caching
5b2f35fe..., ea95b933..., cc3484b9... VLLM_VL_VISION_NUM_GRID_PER_SIDE = 27，随后删除

背后的理由

这组变化本质上都在处理一个问题：

显存不是只给模型权重和 KV cache 用的。 在长上下文、VL、KVS、PD 这些场景里，预处理缓存、视觉网格、prefix cache、KV 传输缓冲都会争显存。

所以你会看到两个典型方向：

给显存留安全边界 gpu_memory_utilization 下调，不是因为更快，而是因为再高就会触发 swap / OOM / 碎片化恶化。这类 commit 是“性能相关”，但更准确说是容量边界调优。
缓存未必总是划算 prefix caching、preprocess cache、mm_processor_cache_gb 只有在命中率高时才值得。在多模态、长上下文、任务混杂的真实线上场景里，缓存可能带来：
- 显存占用
- 管理开销
- 缓存污染
- 命中不高
所以会出现“先开后关”或“默认关闭”的变化，这说明它不是 universally beneficial 的 knob。

C. kernel / backend / compile path 相关

09b00519... compilation_config.use_inductor = false，custom_ops = ["all"]
60296b81... 删除 VLLM_ENABLE_TORCH_COMPILE
a3389997... 使用 PIECEWISE 的 cudagraph_mode
21619496... 删除 PIECEWISE
34b32eb8... VLLM_USE_FLASHINFER_SAMPLER = 0 VLLM_ENABLE_TORCH_COMPILE = 1
adba5593... 设置 VLLM_FLASH_ATTN_USE_UPSTREAM = 0
dc83943a... 设置 VLLM_USE_UPSTREAM_FA3 = 0
4994e414..., 213d8940... 启用 VLLM_FLASH_ATTN_FP8_ATTENTION
1ca19f80..., 8152532e... pass_config.fuse_* = false
31a07b6e... no bladnn gdn by default

背后的理由

这一组非常像现实生产环境中的“后端路径钉死”：

理论上更激进的 backend / fusion / compile path 不一定更快，更不一定更稳；
一旦涉及 FP4/FP8、VL、quant、特殊注意力后端、特定硬件，实际最优路径往往依赖非常具体的组合条件。

所以这类 commit 的真实含义通常不是：

“发现了一个更高级的性能优化”

而是：

“某条后端路径在这个模型/精度/硬件组合上不稳、不可用、或者综合收益不好，所以钉到已验证的实现上”。

这类 commit 当然影响性能，但其本质更接近后端选择与兼容性收敛，不是典型意义上的 black-box tuning。

D. 并行形态 / 系统结构相关

2fe8ab56... TP=4，关闭 KV transfer
85c50bf7..., 5f591ffe... loose top-k verify 相关开关，后来关闭
c18e84e2... 增加 speculative_config.num_speculative_tokens = 32
ae600ea0..., de918bd2..., b3d465ad..., 9c497637..., 741d586d..., e1fdbf46..., 2e87a5d3..., 27d64ee3... PD / EPD / KVS 相关支持

背后的理由

这一组说明一个更重要的事实：

真正影响 serving config 的，常常不是单个 flag，而是系统结构变了。

例如：

一旦引入 PD/EPD，prefill 和 decode 的最优 max_num_batched_tokens、max_num_seqs、cuda_graph_sizes 就不该相同；
一旦引入 KVS，你必须重新分配显存 headroom；
一旦使用 speculative decoding，decode 最优点就会改变；
TP 的选择本质上是算力并行收益 vs 通信开销 vs KV 布局 vs 单机容量的平衡。

所以这些 commit 说明的不是“flag 很多”，而是：

配置空间真正复杂的来源，是系统形态切换，而不是几十个 flag 都在频繁被精细调参。

4. 真正被反复调的“核心性能 flag”其实不多

从你这批 commit 看，反复出现的核心性能 knob 主要就这些：

max_num_batched_tokens
max_num_seqs
gpu_memory_utilization
async_scheduling
cuda_graph_sizes
cudagraph_mode
VLLM_ENABLE_TORCH_COMPILE
enable_prefix_caching
mm_processor_cache_gb
TP
若干 backend 选择：
- VLLM_FLASH_ATTN_FP8_ATTENTION
- VLLM_FLASH_ATTN_USE_UPSTREAM
- VLLM_USE_UPSTREAM_FA3
- VLLM_USE_FLASHINFER_SAMPLER
- pass_config.fuse_*

这对你的故事很重要： 配置文件里看起来 flag 很多，但真正反复进入性能决策回路的，是一个相对低维、重复出现的核心子集。

5. 这批 commit 最能支持你的论文/文档里的什么结论

我建议你把结论写成下面这个脉络：

结论 A：生产环境 config churn 很大，但大部分不是性能 tuning

因为大量 commit 属于：

新模型接入
新硬件适配
PD/KVS/VL/MTP 等功能接入
typo / meta / chore
正确性与兼容性修复

所以不能把“commit 多”直接等价成“性能配置空间巨大且持续被深度优化”。

结论 B：真正的性能 tuning 集中在少数几个 recurring knobs 上

主要就是：

batching 宽度
scheduling 策略
graph/compile 开关
memory headroom
cache 开关
backend path
TP / PD / KVS 等结构性选择

也就是说，性能空间不是“很多杂乱 flag 的完全黑盒空间”，而是有明显系统结构的。

结论 C：许多所谓“性能相关 commit”，本质是在修资源边界和后端稳定性

例如：

gpu_memory_utilization 下调避免 OOM
关闭 prefix / preprocess cache
钉死某个 flash-attn 或 compile backend
删除不稳定的 graph mode

这说明线上 config 演化的第一目标往往是：

先稳定可运行，再在少数核心 knob 上做局部优化。

6. 我给你的最终判断

你的原始直觉是对的，而且这个观察其实很强：

vLLM per-model config 的 commit 很多，但绝大多数并不是“性能相关的精细调优”；真正持续影响性能的，是少数几个 recurring flag，以及少数系统结构切换（PD/KVS/TP/speculative）。

如果你愿意，我下一步可以直接把这些内容整理成一份更正式的中文内部文档，结构做成：

背景 → 方法 → commit 分类统计 → 高频性能 flag → 每类 flag 的系统解释 → 对 AITuner 研究的启示

这样你可以直接发给同事或 supervisor。

25 KiB Raw Blame History Unescape Escape

现存的问题

现状总结

补充

configs commit 总结

Commit Analysis

1. 结论先说

2. 从第一性原理看，为什么会这样

3. 哪些 commit 真正改了性能相关 flag

A. batching / scheduling / graph capture 相关

这类变化背后的理由

B. memory / cache / 长上下文相关

背后的理由

C. kernel / backend / compile path 相关

背后的理由

D. 并行形态 / 系统结构相关

背后的理由

4. 真正被反复调的“核心性能 flag”其实不多

5. 这批 commit 最能支持你的论文/文档里的什么结论

结论 A：生产环境 config churn 很大，但大部分不是性能 tuning

结论 B：真正的性能 tuning 集中在少数几个 recurring knobs 上

结论 C：许多所谓“性能相关 commit”，本质是在修资源边界和后端稳定性

6. 我给你的最终判断

25 KiB

Raw Blame History