Repository navigation
[Attention] Make the sparse MLA prefill workspace size configurable - #61023
robertgshaw2-redhat merged 2 commits into
Conversation
LucasWilkinson
left a comment
There was a problem hiding this comment.
looks good to me, but might be nicer to have the default be lower at large max_model_len (per your findings), i.e. 5 for max_model_len <= 256k else 2
|
✅ @vMaroon, CI is now available for this PR.
|
d418f78 to
06a24c3
Compare
|
Done in 06a24c3: the field is unset by default and |
|
/ci run |
|
❌ This PR is 31 commits behind upstream |
The FlashMLA sparse prefill workspace (5 x max_model_len) and the DSA indexer prefill buffer sized from it (40 x max_model_len) hold several GiB per GPU at a 1M max_model_len. Add AttentionConfig.sparse_mla_prefill_workspace_factor (default 5, minimum 2) so long-context deployments can return that memory to the KV cache. The indexer buffer still fits inside the workspace. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Maroon Ayoub <mayoub@redhat.com>
…del_len Leave sparse_mla_prefill_workspace_factor unset by default and resolve it in VllmConfig: 5 up to a 256K max_model_len, 2 above. Long-context deployments get the smaller reservation without a flag. It is resolved once because KV cache auto-fit can lower max_model_len after the workspace is reserved, and factor * max_model_len must stay within it. Drop the buffer-size unit test; the indexer buffer fits the workspace by construction. Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Maroon Ayoub <mayoub@redhat.com>
06a24c3 to
ca4c57b
Compare
|
/ci run |
|
✅ Triggered Buildkite CI #94233 for commit |
CI selector (shadow): 29 test steps (61 jobs) instead of 85 (115 jobs)Shadow mode: this changes nothing about what CI runs. It shows what the evidence-based selector would pick for this PR, next to today's rules. How it works. Feedback welcome: reply here if it would skip a step this change needs, or runs something unrelated. Selector would run (29)
Would skip (today's rules run them) (66)
Would add (today's rules do not run them) (10)
AMD mirrors: would skip (70)
AMD mirrors: would add (8)
4 changed files · base |
…llm-project#61023) Signed-off-by: Maroon Ayoub <mayoub@redhat.com> Co-authored-by: Claude <noreply@anthropic.com> Signed-off-by: Andreas Karatzas <AndreasKaratzas@users.noreply.github.com>
…llm-project#61023) Signed-off-by: Maroon Ayoub <mayoub@redhat.com> Co-authored-by: Claude <noreply@anthropic.com>

Overview
Adds
AttentionConfig.sparse_mla_prefill_workspace_factor. It replaces the fixed5 * max_model_lenFlashMLA sparse prefill workspace and the40 * max_model_lenDSA indexer prefill buffer sized from it. Unset,VllmConfigresolves it to 5 up to a 256Kmax_model_lenand to 2 above. At a 1Mmax_model_lenthe fixed reservations hold several GiB per GPU that a long-context deployment can return to the KV cache.Related: #60874 (right-sizes the DeepSeek-V4.1 copies of these buffers), #42856 (fixed lower factors on SM120 only), #59319 (skips the FlashMLA workspace on the fp8 mixed-batch path).
Claims
max_model_lenthe default keeps every size identical to main.2 * max_model_len, indexer16 * max_model_len.--attention-config.sparse_mla_prefill_workspace_factor=5restores the main sizes.VllmConfig.__post_init__. KV cache auto-fit can lowermax_model_lenafter the workspace is reserved, so a factor derived later could switch from 2 to 5 and size a step past the reservation.(576 * 2 // 132) * factorrows, so it still fits inside the FlashMLA workspace.ge=2). Under PCP+DCP the per-rank budget isfactor * max_model_len // dcp, and a full-length request's shard can round up pastmax_model_len // dcp, whichsplit_prefill_chunksasserts against.max_model_len(PCP8, DCP8, TP1): factor 2 raises available KV cache from 9.07 to 18.36 GiB per GPU.Validation
Default, CPU. On 06a24c3, a real
VllmConfig(Qwen/Qwen2.5-0.5B, CPU device) resolves the factor and both buffer sizes as follows:max_model_lenAn explicit factor of 3 at 1M is kept, and
AttentionConfig(sparse_mla_prefill_workspace_factor=1)raises a validation error.test_indexer_prefill_budget_matches_compressed_workspacereads the resolved factor throughcreate_vllm_config; it needs a GPU, so CI runs it in thev1/attentionjob. pre-commit (ruff, mypy,validate-config, test tethering) passes on the changed files.GLM-5.3 on H100, same sizes. We run GLM-5.3 FP8 in production with these exact sizes (workspace 2x, indexer 16x) applied to the same two functions on our vLLM build. The prefill engines are PCP8, DCP8, TP1,
--max-model-len 1048576,fp8_ds_mla, block size 64,--gpu-memory-utilization 0.93.All 28 production prefill engines have run factor 2 since 2026-10-10 18:08 UTC, and every one booted without OOM.
This branch on GPU: not run. The production numbers come from the same sizes on our build.
Details
sparse_mla_force_mqa,indexer_kv_dtype,hisparse_config) live inAttentionConfig.get_prefill_workspace_sizenow takes theVllmConfig, likeget_max_prefill_buffer_sizealready does.FLASHMLA_SPARSEwith a quantized DS-MLA cache.get_max_prefill_buffer_sizealso sizes the indexer indeepseek_v2(DeepSeek-V3.2, GLM-5.x),deepseek_v32,deepseek_v4,deepseek_v41,hy_v4andglm5next, so the factor applies there too. The DeepSeek-V4.1 FlashMLA workspace is sized inmodels/deepseek_v41and does not read it.factor * max_model_lencontext tokens in total. At the default above 256K (factor 2), that takes three or more concurrent near-full-length prefills.gh pr list --state open --searchfor "sparse prefill workspace", "prefill workspace size configurable", "flashmla sparse workspace", "indexer prefill buffer" and "workspace factor":FlashMLASparseImpl.__init__.Pull Request Checklist
I used vLLM's
/pr-checklistskill. (Mandatory for agents, optional for humans).AI assistance was used during the creation of this PR.
Design Fit: Minimizes impact on core components, reuses existing functionality, and justifies added complexity.
Testing and Validation: Validates the change and ensures any added tests are meaningful and reliable, with CI coverage or documented CI resource constraints and validation performed outside CI.
Code Quality and Style: Keeps code and comments clear and concise, and updates relevant documentation and examples.
Pull Request Contents: Includes a brief summary and relevant links, supports claims with evidence, explains root causes and implementation trade-offs, and follows the contributing guide.