[Bugfix] Make compressed-tensors MoEs respect ignored layers

[HDCharles]

Purpose

Applying quantization to some MoE layers but not others would cause model load errors due to vllm assuming all the layers were quantized since there was no check of the ignore list.

Changes

• added helper function get_scheme_dict used by get_scheme so only a single interface for MoE and Linear to match layers
• MoE matching previously would assume the 'Linear' target is used for MoE. instead, added helper which adds 'FusedMoE' to target_scheme_map and then match normally by either layer or Module type
• New test to check this
• Added conch-triton-kernels to be installed for the new test otherwise this tiny model has no kernels

Test Plan

pytest tests/quantization/test_compressed_tensors.py::test_compressed_tensors_moe_ignore_with_model -vs -rs

Test Result

PASSED

=============================== warnings summary ===============================
<frozen importlib._bootstrap>:241
  <frozen importlib._bootstrap>:241: DeprecationWarning: builtin type SwigPyPacked has no __module__ attribute

<frozen importlib._bootstrap>:241
  <frozen importlib._bootstrap>:241: DeprecationWarning: builtin type SwigPyObject has no __module__ attribute

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
======================== 1 passed, 2 warnings in 25.78s ========================
sys:1: DeprecationWarning: builtin type swigvarlink has no __module__ attribute

@kylesayrs @dsikka

[gemini-code-assist]

Code Review

This pull request addresses a bug where models with partially quantized Mixture-of-Experts (MoE) layers would fail to load. The fix involves refactoring the quantization scheme retrieval logic and explicitly handling unquantized MoE layers by introducing an UnquantizedFusedMoEMethod. The changes are logical and correctly solve the described problem. My main feedback is regarding the new logic for determining the MoE quantization scheme, which currently only checks the first expert and assumes all others are the same. This could lead to incorrect behavior for models with more complex or heterogeneous expert configurations. I've added a comment with a suggestion to make this more robust.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[heheda12345]

CC @mgoin

[mgoin]

Can you update the title to be more clear?

[mgoin]

Thanks for explaining, LGTM!

[mgoin]

@HDCharles the test failure looks related PTAL

[2025-11-21T00:24:56Z] FAILED quantization/test_compressed_tensors.py::test_compressed_tensors_moe_ignore_with_model - pydantic_core._pydantic_core.ValidationError: 2 validation errors for VllmConfig
[2025-11-21T00:24:56Z] scale_dtype
[2025-11-21T00:24:56Z]   Extra inputs are not permitted [type=extra_forbidden, input_value=None, input_type=NoneType]
[2025-11-21T00:24:56Z]     For further information visit https://errors.pydantic.dev/2.12/v/extra_forbidden
[2025-11-21T00:24:56Z] zp_dtype
[2025-11-21T00:24:56Z]   Extra inputs are not permitted [type=extra_forbidden, input_value=None, input_type=NoneType]
[2025-11-21T00:24:56Z]     For further information visit https://errors.pydantic.dev/2.12/v/extra_forbidden

[dsikka]

FYI - failure is because config was generated using a newer ct nightly whereas ct 12.2 is used by vLLM.

We should use 12.2 for test configs until support is upgraded in vLLM (or simply remove the scale_dtype / zp_dtype fields)

[mgoin]

Why is this needed now if we didn't need this before? Is it needed for the new model somehow?

[HDCharles]

the new test needs this or else there's no kernel for the test of the tiny model I made