[Nixl][PD] DCP support for MLA models

[NickLucche]

Alternative to #38433 as we iterate on the design with @pisceskkk .

I feel this version is much closer to the changes we should see to the core files in terms of code structure and modifications to the workflow - it should result closer to injecting DCP login into current abstraction, rather than building something on the side.
However, it makes some significant assumptions to do that, described below.

---

NIXL P/D disaggregation assumed MLA's KV cache is fully duplicated across TP, so a remote rank only needs to be read once. Decode Context Parallel (DCP) breaks that: it shards KV by block across ranks.

  Producer  (dcp_size=4) -- KV sharded into 4 slices, one per rank
  +------+------+------+------+
  |  P0  |  P1  |  P2  |  P3  |
  +--+---+--+---+--+---+--+---+
     |      |      |      |
     v      v      v      v
  +------+------+------+------+
  |  D0  |  D1  |  D0  |  D1  |   <-  remote_rank % local_dcp_size == local_dcp_rank
  +------+------+------+------+
  Decoder   (dcp_size=2) -- each rank owns 2x the slice, reads 2 remote ranks

    D0 reads {P0, P2}   D1 reads {P1, P3}

Note

Key simplifying assumption: per side, dcp_size is either 1 (fully replicated, unchanged pre-existing behavior) or tp_size (fully sharded, disjoint 1/dcp_size slice per rank) — never partial (1 < dcp_size < tp_size).

This means DCP sharding and the old "multiple TP replicas, pick one canonically" logic never have to compose on the same side, which is what keeps the routing logic to three flat cases (both replicated / one-replicated-one-sharded / both-sharded) instead of a general partial-overlap solver.

Two supporting assumptions that follow from it:

• DCP sizes across sides always divide one another (real deployments use power-of-two/highly-composite degrees) — avoids needing gcd/lcm logic, plain modulo suffices.
• DCP shards at block granularity when a KV connector is attached (cp_kv_cache_interleave_size pinned to block_size) — this is quite fundamental. However I had to update a few attn backends to make sure they get the updated value.

Sweep

gsm8k eval sweep, ran at block_size=64 (128 needs this fix #51031) on deepseek-ai/DeepSeek-V2-Lite-Chat

Configuration	Status	Strict match
P TP4/DCP1 → D TP4/DCP1	PASS	0.6535253980288097
P TP2/DCP1 → D TP4/DCP1	PASS	0.6489764973464746
P TP4/DCP4 → D TP4/DCP4	PASS	0.6588324488248674
P TP4/DCP1 → D TP4/DCP4	PASS	0.6648976497346475
P TP4/DCP4 → D TP4/DCP1	PASS	0.6595905989385898
P TP2/DCP2 → D TP4/DCP4	PASS	0.6573161485974223
P TP2/DCP1 → D TP4/DCP4	PASS	0.6542835481425322

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @NickLucche.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[NickLucche]

/ci run

[github-actions]

✅ Triggered Buildkite CI #82667 for commit e4d32ec81fe9.

[NickLucche]

/ci retry

[github-actions]

✅ Triggered Buildkite CI #85980 for commit 7a79d4664f70.

[NickLucche]

/ci retry

[github-actions]

✅ The previous CI build is still running: https://buildkite.com/vllm/ci/builds/85980

[NickLucche]

/ci run

[github-actions]

✅ Triggered Buildkite CI #86145 for commit 86244e386bed.

[cjackal]

I think this conflicts with DCP + CPU offloading usecase, the previously working deployment now raises at

vllm/vllm/v1/attention/backends/mla/indexer.py

Lines 543 to 548 in e79961c

	if self.dcp_world_size > 1 and self.cp_kv_cache_interleave_size > 1:
	raise NotImplementedError(
	"DCP sparse indexer currently supports only "
	f"cp_kv_cache_interleave_size=1 (got "
	f"{self.cp_kv_cache_interleave_size})."
	)

due to cp_kv_cache_interleave_size guard.

I don't think either that adjustment here should be applied to "local" kv connectors like CPUOffloadingConnector, could we reduce the effective radius to only the NIXL case?

[cjackal]

Hotfix at #54457, although I haven't fully opt-out the cp_kv_cache_interleave_size for other connectors (haven't validated the accuracy for them), just CPU offloaders.