Create test_deepseek_v32_config.py

[puririshi98]

This test aims to cover: #34899

Not sure where this test would be put in the tests folder, open to suggestions from reviewers.

This is part of the NVIDIA effort to add CI to upstream github.

[gemini-code-assist]

Code Review

This pull request introduces a new test file, test_deepseek_v32_config.py, to validate the changes from PR #34899. The tests cover the architectural changes and config update logic for DeepseekV32ForCausalLM. While the tests are generally well-structured, I've found a significant issue where one of the tests is ineffective because it checks for a class's removal in the wrong module. This could lead to a false sense of security that the refactoring was completed correctly.

[gemini-code-assist]

This test is intended to verify the removal of the DeepseekV3ForCausalLM class. However, it only checks for its absence in the vllm.model_executor.models.config module. Based on the existing codebase, this class is defined elsewhere (e.g., in vllm.model_executor.models.deepseek_v2.py) and is not expected to be in the config module. This means the test will pass regardless of whether the class has been properly removed, making it ineffective.

To correctly verify the removal, the assertion should check against the vllm.model_executor.models package, which is where the class would be exposed if it still exists.

Suggested change

	from vllm.model_executor.models import config as config_module
	assert not hasattr(config_module, 'DeepseekV3ForCausalLM'), (
	"DeepseekV3ForCausalLM workaround class should be removed"
	)
	from vllm.model_executor import models
	assert not hasattr(models, 'DeepseekV3ForCausalLM'), (
	"DeepseekV3ForCausalLM workaround class should be removed"
	)

[mergify]

Hi @puririshi98, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[mergify]

Hi @puririshi98, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[mergify]

Hi @puririshi98, the pre-commit checks have failed. Please run:

uv pip install pre-commit
pre-commit install
pre-commit run --all-files

Then, commit the changes and push to your branch.

For future commits, pre-commit will run automatically on changed files before each commit.

Tip

Is mypy or markdownlint failing?

mypy and markdownlint are run differently in CI. If the failure is related to either of these checks, please use the following commands to run them locally:

# For mypy (substitute "3.10" with the failing version if needed)
pre-commit run --hook-stage manual mypy-3.10
# For markdownlint
pre-commit run --hook-stage manual markdownlint

[wzhao18]

kv cache dtype is not converted automatically from "fp8" to "fp8_ds_mla" after PR #35891 for DS v3.2

[jasonlizhengjian]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a new test file to validate changes from a previous pull request related to DeepseekV32ForCausalLM configuration. The tests are generally well-structured and use mocking effectively to isolate the logic under test. However, I've identified a significant issue in two of the tests that are intended to verify the removal of a class; they are checking the wrong module, which could lead to a false sense of security. I've provided specific suggestions to correct this.

[gemini-code-assist]

This test incorrectly checks for the removal of DeepseekV3ForCausalLM from the config module. This class was originally defined in vllm.model_executor.models.deepseek_v2, so the test should check that module to correctly verify its removal. As written, this test does not provide the intended verification.

Suggested change

	from vllm.model_executor.models import config as config_module
	assert not hasattr(config_module, "DeepseekV3ForCausalLM"), (
	"DeepseekV3ForCausalLM workaround class should be removed"
	)
	from vllm.model_executor.models import deepseek_v2 as models_module
	assert not hasattr(models_module, "DeepseekV3ForCausalLM"), (
	"DeepseekV3ForCausalLM workaround class should be removed"
	)

[gemini-code-assist]

Similar to the test_deepseek_v3_class_removed test, this check for the removal of DeepseekV3ForCausalLM is targeting the wrong module. The class was defined in vllm.model_executor.models.deepseek_v2, not config. The test should be updated to check the correct module to ensure the test is effective.

Suggested change

	from vllm.model_executor.models import config as config_module
	assert not hasattr(config_module, "DeepseekV3ForCausalLM")
	from vllm.model_executor.models import deepseek_v2 as models_module
	assert not hasattr(models_module, "DeepseekV3ForCausalLM")