Repository navigation
feat(vllm): support Decode Context Parallelism (DCP) for Qwen3.5 in MaxTextForCausalLM - #5609
sierraisland wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces support for context parallelism (dcp) in vLLM inference within MaxText. It updates the logical axis rules and data sharding configurations to include the dcp axis, and integrates dcp_forward in the attention layer's vLLM serving path. Additionally, it refines the expert parallelism name configuration in MoE layers, adjusts the KV cache specification for hybrid Qwen3 models to correctly handle attention layers alongside Mamba layers, and dynamically determines the GDN head axis based on the attention configuration in Qwen3. There are no review comments, and I have no feedback to provide.
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
4ab1c50 to
7cf3740
Compare
7cf3740 to
a4b21fb
Compare
a4b21fb to
eb3d60e
Compare
…axTextForCausalLM
eb3d60e to
d370f9e
Compare
Description
Adds support for Decode Context Parallelism (DCP,
--decode-context-parallel-size) when serving hybrid/MoE models (such as Qwen3.5-397B-A17B) viaMaxTextForCausalLMon vLLM /tpu-inference.Notice 1: Once all tests pass, the "pull ready" label will automatically be assigned.
This label is used for administrative purposes. Please do not add it manually.
For models with a small number of KV heads (e.g., Qwen3.5-397B-A17B with only 2 KV heads on 8 TPU chips), sharding KV heads beyond 2 ways requires duplicating KV heads across devices. Under Decode Context Parallelism (DCP, e.g.,
tp=1, ep=2, dcp=4), the 2 KV heads are sharded 2-way across('model', 'expert')while the KV cache sequence/context dimension is sharded 4-way across'dcp', and Q heads, GDN heads, MoE experts, and vocabulary remain sharded 8-way across('model', 'expert', 'dcp')/('attn_dp_expert', 'expert', 'dcp').Previously, enabling
--decode-context-parallel-size > 1withMaxTextForCausalLMfailed because:vllm.ymllogical axis rules did not include'dcp'on Q/GDN/MoE/MLP/vocab axes.Attention.forward_serve_vllmalways called single-devicerpa_opsinstead of dispatching totpu_inference'sdcp_forwardwhenmesh.shape["dcp"] > 1.RoutedMoE.__init__only included"attn_dp_expert"in_expert_parallelism_namewhenenable_dp_attention=True, causing an axis mismatch withtpu-inference'sShardingAxisName.EXPERTwhenenable_dp_attention=False.Qwen3NextGatedDeltaNethardcodedKV_HEAD(['model', 'expert'], 2-way under DCP) for activationPartitionSpecs while GDN weights and Mamba state caches were sharded 8-way acrossgdn_head(['model', 'expert', 'dcp']).patch_kv_cache_managerinadapter.pyusedShardingAxisName.ATTN_HEAD(which includes'dcp') instead ofShardingAxisName.KV_HEADto computenum_kv_headspadding for full-attention KV cache specs.Tests
Verified end-to-end serving and multi-turn agentic benchmarking on
tpu7x-8withQwen/Qwen3.5-397B-A17B-FP8(MaxTextForCausalLM), comparingattndp4(enable_dp_attention=True, tp=1, ep=8) vs.dcp4(--decode-context-parallel-size 4, tp=4, ep=2):attndp4g=1, c=1dcp4g=1, c=1attndp4g=2, c=2dcp4g=2, c=2Checklist
Before submitting this PR, please make sure (put X in square brackets):
gemini-reviewlabel.