执行摘要

• 一句话：添加 deepseek_v32 到 Quark MXFP4 模型类型检查
• 推荐动作：本 PR 是紧急 bugfix，建议尽快合并。同时建议为 maybe_update_config 逻辑添加单元测试，覆盖各种 model_type 和 quantization_config 组合，防止后续回归。

功能与动机

DeepSeek-V3.2 的 HuggingFace 配置使用 model_type="deepseek_v32"，但 Quark 量化配置的 _DEEPSEEK_V3_FAMILY_MODEL_TYPES 只包含 "deepseek_v3"，导致动态 MXFP4 重新量化未启用，注意力投影使用了错误的未量化方法，产生全零或乱码输出。本 PR 旨在修复此问题，使 DeepSeek-V3.2 模型在 Quark MXFP4 路径下正确推理。

实现拆解

1. 在 vllm/model_executor/layers/quantization/quark/quark.py 中，将 _DEEPSEEK_V3_FAMILY_MODEL_TYPES 从 frozenset({"deepseek_v3"}) 扩展为 frozenset({"deepseek_v3", "deepseek_v32"})。
2. 新增 QuarkConfig.maybe_update_config 方法，该方法接收 hf_config 参数，检查其 model_type 是否在家族集合中，并通过 quantization_config 确认权重 dtype 为 "fp4" 后，将 self.dynamic_mxfp4_quant 设置为 True。
3. 导入 transformers.PretrainedConfig 用于类型注解。
4. 无测试文件改动，但已在 8× AMD MI355X 上验证了功能测试和 GSM8K 准确率。

关键文件：

• vllm/model_executor/layers/quantization/quark/quark.py（模块 量化层；类别 source；类型 data-contract；符号 _DEEPSEEK_V3_FAMILY_MODEL_TYPES, maybe_update_config）: 核心变更文件：修改了 DeepSeek V3 系列模型类型集合，新增 maybe_update_config 方法来启用动态 MXFP4 量化。

关键符号：maybe_update_config

关键源码片段

vllm/model_executor/layers/quantization/quark/quark.py

核心变更文件：修改了 DeepSeek V3 系列模型类型集合，新增 maybe_update_config 方法来启用动态 MXFP4 量化。

# vllm/model_executor/layers/quantization/quark/quark.py
# 定义 DeepSeek V3 系列模型类型集合，用于门控动态 MXFP4 重量化
_DEEPSEEK_V3_FAMILY_MODEL_TYPES = frozenset({"deepseek_v3", "deepseek_v32"})
​
​
class QuarkConfig(QuantizationConfig):
    # ... 其他代码 ...
​
    def maybe_update_config(
        self,
        model_name: str,
        hf_config: PretrainedConfig | None = None,
        revision: str | None = None,
    ):
        """启用动态 MXFP4 仅当模型属于 DeepSeek-V3 系列且为 fp4 检查点。"""
        if hf_config is None:
            return
​
        # 检查 model_type 是否在家族集合中
        if (
            getattr(hf_config, "model_type", None)
            not in _DEEPSEEK_V3_FAMILY_MODEL_TYPES
        ):
            return
​
        # 从配置中获取量化配置字典
        quant_config = getattr(hf_config, "quantization_config", None)
        if isinstance(quant_config, dict):
            # 检查权重 dtype 是否为 "fp4"
            quant_dtype = (
                quant_config.get("global_quant_config", {})
                .get("weight", {})
                .get("dtype")
            )
            if quant_dtype == "fp4":
                self.dynamic_mxfp4_quant = True

评论区精华

• Reviewer @tjtanaa 询问 NVFP4 格式是否仍在使用以及当前模型是否直接存储 MXFP4 权重。作者 @shantipriya-amd 确认 NVFP4 路径仍存在（PR #35859），而 amd/DeepSeek-V3.2-mxfp4 模型直接以 MXFP4 格式存储权重（OCP-MX 格式），通过 _is_w_ocp_mx_a_x 路径处理。

• 此外，CI 构建失败被确认为基础设施问题，与 PR 改动无关。

• NVFP4 与 MXFP4 存储格式确认 (question): 确认 NVFP4 路径仍活跃，当前模型使用直接 MXFP4 存储，因此需要 maybe_update_config 门控来触发动态 MXFP4 重新量化。

风险与影响

• 风险：主要风险是对非 DeepSeek-V3 系列模型的影响。maybe_update_config 首先检查 model_type 是否在 _DEEPSEEK_V3_FAMILY_MODEL_TYPES 中，只有匹配时才启用动态 MXFP4，因此不会影响其他模型。另一个风险是如果未来 DeepSeek-V3 系列出现新的 model_type 且也需要 MXFP4，需要再次更新该集合。当前变更没有测试覆盖，主要依赖手工验证。
• 影响：用户影响：使用 amd/DeepSeek-V3.2-mxfp4 模型且启用 Quark 量化的用户将获得正确的输出，之前可能遇到全零或乱码。系统影响：无性能开销，因为动态 MXFP4 启用在加载配置时决定。团队影响：需要关注未来模型类型的扩展。
• 风险标记：缺少测试覆盖, 量化路径变更

关联脉络

• PR #37682 [Bugfix] Zero-init ROCm MLA attention output buffers for graph padding: 此 PR 的修复依赖 #37682 的 MLA zero-init 修复，两者共同确保 DeepSeek-V3.2 在 ROCm 上正确推理。
• PR #42754 [Bugfix] Add deepseek_v32 to Quark dynamic MXFP4 model type check (duplicate): 与此 PR 内容相同的重复 PR，已关闭。