
- 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](https://code.alibaba-inc.com/PAI-LLM/vllm/commit/2f5a20b76049a33d79bbe2a4ab8abd8ae84581c7?spm=21540d8c.2ca2ac6d.0.0.62cf790b5rvf9T)

内部存在更多不存在清楚文档定义的中间状态值，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 变多，未必意味着“性能状态空间巨大”。更常见的是四类变化：

1. **接入新模型 / 新硬件 / 新模式**
   例如新增 qwen3-vl、omni、5090、A800、L20C、PD、KVS、MTP。
   这类变化本质上是“能不能跑 / 怎么接入”，不是“已经能跑后如何把 goodput 调到最优”。

2. **兼容性与正确性修复**
   例如 typo、rope scaling 位置修复、fp4 per-channel 加载逻辑变化、某后端 upstream 不可用、某硬件不支持 fp8。
   这类变化的目标是“避免错 / 避免 crash / 避免不支持”。

3. **稳定性与资源安全边界调整**
   例如 `gpu_memory_utilization` 从 0.89 到 0.88，避免 KVS swap OOM。
   这类变化和性能有关系，但很多时候**优先级是 survivability，不是 peak throughput**。

4. **真正的 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 传输缓冲都会争显存。

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

1. **给显存留安全边界**
   `gpu_memory_utilization` 下调，不是因为更快，而是因为再高就会触发 swap / OOM / 碎片化恶化。
   这类 commit 是“性能相关”，但更准确说是**容量边界调优**。

2. **缓存未必总是划算**
   `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。
