[KV Connector] Remove compat support for pre-v0.12.0 constructor signatures without KVCacheConfig#39832
Conversation
Signed-off-by: yewentao256 <zhyanwentao@126.com>
There was a problem hiding this comment.
Code Review
This pull request removes various deprecated tests and compatibility layers across the codebase, specifically targeting pooling tasks, weight utilities, argparse utilities, and KV connector integrations. However, feedback indicates that several tests—including those for deprecated KV scale mapping, argparse back-compatibility for the --model flag, and LMCache integration contracts—are being removed while the underlying implementation logic remains active in the repository, resulting in a significant loss of test coverage.
I am having trouble creating individual review comments. Click here to see my feedback.
tests/model_executor/test_weight_utils.py (105-110)
The test test_deprecated_kv_scale is being removed, but the corresponding compatibility logic in vllm/model_executor/model_loader/weight_utils.py (lines 1521-1538) is still present in the codebase. Removing tests for features that are still active and supported (even if deprecated) increases the risk of regressions. It is recommended to retain these tests until the underlying code is actually removed from the repository.
tests/utils_/test_argparse_utils.py (279-321)
This PR removes the test coverage for the --model argument back-compatibility in vllm serve. However, the remapping logic and the associated warning are still present in vllm/utils/argparse_utils.py (lines 185-217). Furthermore, the commented-out test block intended for when compatibility ends is also being deleted. It is safer to keep these tests active as long as the code they verify remains in the repository, or to update the code to the final state (raising an error) and update the tests accordingly to ensure the transition is correctly enforced.
tests/v1/kv_connector/unit/test_lmcache_integration.py (1-229)
Removing test_lmcache_integration.py eliminates critical contract tests that ensure vLLM's internal changes do not break the LMCache integration. These tests verify that key attributes and methods on classes like VllmConfig, ModelConfig, and Request remain stable. Unless the LMCache integration is also being removed or these tests have been moved to a different suite, this represents a significant loss in integration testing coverage for a major external component.
|
For pooling-related tests, please wait for #37861 to land in v0.20.0. These tests are important before this, please do not remove them. |
Signed-off-by: yewentao256 <zhyanwentao@126.com>
|
@yewentao256 If we remove this test it means we no longer support old style connectors. instead of: |
Signed-off-by: yewentao256 <zhyanwentao@126.com>
|
Documentation preview: https://vllm--39832.org.readthedocs.build/en/39832/ |
kv_cache_config None support
yewentao256
left a comment
There was a problem hiding this comment.
@orozery OK updated, thanks for the feedback!
| if kv_cache_config is None: | ||
| raise ValueError("kv_cache_config must be set for KVConnectorBase_V1") |
There was a problem hiding this comment.
Is this check necessary given the type annotation of kv_cache_config?
NickLucche
left a comment
There was a problem hiding this comment.
I think we're mixing retro-compat with ci optimizations.
We can't just crash on OOT connectors after we went through the trouble of ensuring backward compatibility without raising a warning at least a version earlier.
Also as importantly, I don't understand what kind of savings are we getting from deleting cpu-only tests that work against the interface. Tbh this is the kind of unit tests I'd like to see more of.
We should:
- mark tests as cpu only
- raise a warning that the old api is deprecated and the eventually apply this PR
cc @markmc that added this in case he has a different opinion on this.
|
Thanks @NickLucche for the review! if self._kv_cache_config is None:
logger.warning(
"KVConnectorBase_V1 initialized without kv_cache_config. "
"This is deprecated - please update your connector to accept "
"kv_cache_config as the third constructor argument and pass it "
"to super().__init__()."
)The warning has been added in #27887 and lasts for around 6 months, I think we can safely remove the support of it. As we remove the support of None param, the compatibility test can be removed safely as well. The previous PR description is kind of misleading so I also updated that. |
|
Ok, I had to page this context back in, so here it is:
So this warning has been in place since |
kv_cache_config None supportKVCacheConfig
markmc
left a comment
There was a problem hiding this comment.
Generally lgtm, couple of small suggestions
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com>
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com>
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com>
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com>
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com> Signed-off-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
…atures without `KVCacheConfig` (vllm-project#39832) The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a KVCacheConfig argument was added to KV connector constructors. Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning. See vllm-project#25712 and vllm-project#27887. Since the warning has been around for over 5 months, we can safely remove the support of it. Signed-off-by: yewentao256 <zhyanwentao@126.com>
The v0.12.0 release contained initial support for HMA in KV Connectors. As part of these changes, a
KVCacheConfigargument was added to KV connector constructors.Backwards compatibility support for out-of-tree connectors was included in this change, with a very prominent warning:
See #25712 and #27887
Since the warning has been around for over 5 months, I think we can safely remove the support of it. The compatibility test can be removed safely as well.