[main][Bugfix] Remove the ZMQ communication setup on the D node

[SlightwindSec]

In the PD separation scenario, the D node does not need to perform get operations, and therefore does not need to create ZeroMQ (ZMQ) communication.

• vLLM version: v0.12.0
• vLLM main: vllm-project/vllm@ad32e3e

[gemini-code-assist]

Code Review

This pull request correctly removes the ZeroMQ communication setup on the D node in ascend_store_connector.py to prevent the LookupKeyServer from starting on a consumer node. However, the changes in pool_scheduler.py introduce a critical bug. The conditional initialization of LookupKeyClient is incorrect and will lead to a runtime AttributeError when a consumer node is configured to load data, as self.client will be None but its lookup method is still called. I've provided a critical review comment to fix this logic and a follow-up comment to remove the type: ignore which was masking this bug.

[gemini-code-assist]

The condition for initializing LookupKeyClient is incorrect. If self.kv_role == "kv_consumer" and self.consumer_is_to_load is True, self.client will be None. However, get_num_new_matched_tokens will then attempt to call self.client.lookup, leading to a runtime AttributeError. The client should only be None when it's a consumer that is not configured to load.

Suggested change

	self.client = LookupKeyClient(
	vllm_config) if self.kv_role != "kv_consumer" else None
	if self.kv_role == "kv_consumer" and not self.consumer_is_to_load:
	self.client = None
	else:
	self.client = LookupKeyClient(vllm_config)

[gemini-code-assist]

With the suggested fix for the self.client initialization, this type: ignore comment is no longer necessary and should be removed to improve code clarity. The code path that reaches this line will always have self.client initialized.

        num_external_hit_tokens = self.client.lookup(token_len, request.block_hashes)

[github-actions]

👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:‌‌

• A PR should do only one thing, smaller PRs enable faster reviews.
• Every PR should include unit tests and end-to-end tests ‌to ensure it works and is not broken by other future PRs.
• Write the commit message by fulfilling the PR description to help reviewer and future developers understand.

If CI fails, you can run linting and testing checks locally according Contributing and Testing.