vllm-project/vllm · error · ValueError

Group count mismatch: tracker has {len(self.allocated_block_

Error message

Group count mismatch: tracker has {len(self.allocated_block_ids)} groups, update has {len(new_block_ids)}

What it means

RequestTracker.update() accepts a tuple with one block-id list per KV cache group and must match the number of groups the tracker was initialized with (len(self.allocated_block_ids)). A plain list is broadcast to a single group for backward compat, so the mismatch almost always means the scheduler handed back a different group count than the tracker was built with.

Source

Thrown at vllm/distributed/kv_transfer/kv_connector/v1/mooncake/store/data.py:343

    prefill_end_tokens: int = 0

    def reset(self) -> None:
        self.token_len = 0
        self.allocated_block_ids = ()
        self.num_saved_tokens = 0
        self.token_ids = None
        self.has_pending_offload = False
        self.prefill_end_tokens = 0

    def update(
        self,
        new_block_ids: tuple[list[int], ...] | list[int],
    ) -> None:
        # Backward-compat: accept a single list (broadcast to single group).
        if isinstance(new_block_ids, list):
            new_block_ids = (new_block_ids,)
        if len(new_block_ids) != len(self.allocated_block_ids):
            raise ValueError(
                f"Group count mismatch: tracker has "
                f"{len(self.allocated_block_ids)} groups, update has "
                f"{len(new_block_ids)}"
            )
        for existing, new in zip(self.allocated_block_ids, new_block_ids, strict=True):
            if new:
                existing.extend(new)


@dataclass
class ReqMeta:
    """Per-request metadata for store put/get operations."""

    req_id: str
    token_len_chunk: int
    block_ids: tuple[list[int], ...]
    block_hashes: list[BlockHash]

View on GitHub (pinned to c794754062)

Solutions

1. Recreate the tracker/request state whenever kv_cache_config changes — do not reuse trackers across configs
2. If calling update() yourself, build the argument as tuple of len(tracker.allocated_block_ids) empty-or-new lists
3. Check that the model topology (number of KV cache groups) is identical at connector init time and at scheduling time; report a bug if vLLM itself produced the mismatch

Example fix

# before
tracker.update(([new_ids], [new_ids]))  # tracker has 1 group -> ValueError

# after
tracker.update([new_ids])              # list broadcast to the single group
# or match arity: tracker.update(([new_ids_0], [new_ids_1]))  # 2 groups

if isinstance(new_block_ids, list):
    new_block_ids = (new_block_ids,)
assert len(new_block_ids) == len(tracker.allocated_block_ids), (
    f"expected {len(tracker.allocated_block_ids)} groups")

When it happens

Trigger: A model whose kv_cache_config.kv_cache_groups count differs from what the store tracker allocated (e.g. hybrid models where mamba groups appear/disappear, or a config change between init and update), or a caller passing a tuple with the wrong arity.

Common situations: Version drift between the scheduler's group layout and the store connector's per-request tracker; manually invoking update() in tests/driver code with a list-of-lists sized differently than the tracker's groups.

Related errors

• Request {req_id} is not in _unfinished_requests
• Partial-tail offloads for one request must share a boundary
• Unsupported new_block_ids type {type(new_block_ids)}: should
• Request {req_id} is not in _unfinished_requests, but it is s
• Mooncake is not available

AI-assisted analysis of vllm-project/vllm@c794754062 (2026-08-14). Data as JSON: /api/errors/d4448b38196b5fa5. Report an issue: GitHub.