Model-Optimizer 评测实战：使用 NEL 在 AA 多模态套件中配置并运行 MMMU-Pro 基准

本文以仓库中 MMMU-Pro 任务配方文档 为核心，讲解如何在 Model-Optimizer 项目的 NeMo Evaluator Launcher（NEL）评测体系中接入 MMMU-Pro 多模态基准。你将掌握该任务的 YAML 配置片段、多模态部署端点要求、dry-run → canary → full 三级运行流程，以及从 MLflow 中准确提取 mmmu-pro 分数的完整方法，可用于对量化前后模型进行多模态推理能力的端到端验证。

MMMU-Pro 任务定位

MMMU-Pro 是一个多模态推理基准（multimodal reasoning benchmark），用于评估模型在结合图像与文本输入的场景下进行推理、解析和作答的能力。在 Model-Optimizer 的评测技能体系中，它属于 AA（Artificial Analysis）Index v2 多模态套件的一部分：根据 quantization-benchmarks.md 中的套件划分，多模态 AA 套件 = 全部 AA 文本任务（GPQA、HLE、LCR、SciCode、IFBench、Tau2-Bench Telecom、AA-Omniscience）+ MMMU-Pro。

从量化评测敏感性的角度看，MMMU-Pro 属于"VLM-only"（仅视觉语言模型可测）任务：当只量化 LLM 主体（视觉编码器/适配器通常保持 BF16）时，其分数下降通常处于 Low/Medium 区间。因此它非常适合作为视觉语言模型量化验证的补充信号，而不应单独作为量化敏感度的强判别指标。

该任务运行在已验证的 nemo-evaluator-launcher 0.2.6 路径上（aa/ 套件），使用 nemo-skills 评测镜像，不依赖 nel-next 通道。

运行前的准备工作

在拼接 MMMU-Pro 任务片段之前，先确认以下前提（详见 SKILL.md 与 launcher-workflow.md）：

1. NEL 已安装：执行 nel --version；若缺失，通过 pip install nemo-evaluator-launcher 安装。
2. 工作区与 .env：.env 位于工作区根目录（即运行 nel 的目录），通过 set -a && source .env && set +a 加载。MMMU-Pro 通过 nemo-skills 自部署端点评测，需要在 evaluation.env_vars 中声明 DUMMY_API_KEY: lit:dummy（nemo-skills 客户端在容器内若检测不到该变量值会直接 ValueError 失败；SLURM 下 shell 的 export 不会传入容器，必须显式声明）。若使用 judge-scored 任务还需从 env.example 复制并填充。
3. 任务配方先行：编辑任何任务前先读对应配方，MMMU-Pro 的配方即 recipes/tasks/aa/mmmu_pro.md。

MMMU-Pro 的 YAML 配置片段

MMMU-Pro 是多模态任务，必须使用多模态能力的端点（multimodal-capable endpoint）——这是该任务配方中唯一且必须遵守的硬性要求。将其作为一条任务追加到顶层 evaluation.tasks 列表中，完整片段如下（来自原配方文档）：

- name: ns_mmmu_pro
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03
  nemo_evaluator_config:
    config:
      params:
        extra:
          num_repeats: 1

要点解读：

• name: ns_mmmu_pro：任务名沿用 nemo-skills 命名空间，与 aa/ 套件其他任务（ns_gpqa、ns_hle_aa 等）保持一致，便于 nel run -t ns_mmmu_pro 单独重跑该任务。
• container：使用 NGC 的 nvcr.io/nvidia/eval-factory/nemo-skills:26.03 评测镜像（26.03 版本标签，与 AA 套件其余任务一致），属于公共镜像，提交前无需额外的镜像认证。
• num_repeats: 1：MMMU-Pro 只做一次重复采样（对比 GPQA 的 num_repeats: 16、Omniscience 的 num_repeats: 10），这是由 AA Index 协议决定的，不应为了追求统计量而擅自加大。

将片段粘贴进 evaluation.tasks 后，与 example_eval.yaml 中已有的 ns_gpqa 并列即可组成多任务配置；也可以在 shortcut 路径下直接以该模板为基础复制多个 aa/ 任务片段。

多模态部署端点配置

由于 MMMU-Pro 需要多模态端点，部署层必须满足视觉编码器的加载与推理要求。参考 example_eval.yaml 中单命令（command: 字段）的 vLLM 部署约定：

deployment:
  checkpoint_path: /path/to/quantized/checkpoint
  served_model_name: my-vlm-nvfp4
  image: vllm/vllm-openai:v0.26.0
  command: >-
    vllm serve /checkpoint
    --served-model-name ${deployment.served_model_name}
    --host 0.0.0.0
    --port ${deployment.port}
    --tensor-parallel-size <N>
    --data-parallel-size <M>
    --max-model-len 131072
    --model-loader-extra-config '{"enable_multithread_load": true, "num_threads": 128}'
    --max-num-batched-tokens 8192
    --enable-chunked-prefill

针对 MMMU-Pro 的多模态特性需要额外关注：

• 视觉编码器后端：在 Blackwell B300/GB300（sm_103）等平台上运行 VLM 时，可能需要追加 --mm-encoder-attn-backend TRITON_ATTN（ViT flash-attn 的 workaround；若编码器无此依赖可省略）。这是 vLLM 后端层面的多模态兼容开关，属于"配方未提及就按默认、配方/卡片明确要求才追加"的范畴。
• CUDA 版本匹配：NVFP4 检查点在 B300/GB300（sm_103）上需要 CUDA-13 构建的 vLLM 镜像（cu12 构建缺少 sm_103 的 FP4 kernel，引擎初始化会报 CUDA error: no kernel image is available）。v0.20.0 起发布标签默认即 CUDA-13（不带后缀），-cu129 才是 CUDA-12 选项；v0.19.x 及更早则相反。不要按标签名猜，应核对所选平台子清单中报告的 CUDA_VERSION ≥ 13。
• --max-model-len：需同时满足"提示（含图像 token 序列化）+ max_new_tokens"的总长度，VLM 图像 token 会显著拉长 prompt，建议从 config.json 的 max_position_embeddings 与任务实际输入规模出发取值。
• --served-model-name 必须显式设置：否则 vLLM 以 /checkpoint 作为服务名，评测请求会 404（"model does not exist"）。

若部署自建端点而非 NEL 托管部署（External 模式），则需确保对外暴露的 OpenAI 兼容端点本身具备多模态推理能力——这是配方"Use a multimodal-capable endpoint"的落地含义。

顶层评估参数模板

任务级片段只定义 num_repeats，采样与并发参数由顶层 nemo_evaluator_config.config.params 统一控制。按 launcher-workflow.md 的约束，该块必须恰好包含六个字段，不允许出现 top_k、presence_penalty、repetition_penalty、min_p：

nemo_evaluator_config:
  config:
    params:
      parallelism: ???    # 并发请求数：参考 references/parallelism.md 按请求总量与 GPU 服务容量估算
      request_timeout: 3600
      max_retries: 10
      max_new_tokens: 65536   # 推理模型 64K；非推理模型 16K；优先采用模型卡推荐值
      temperature: 1.0        # 按模型卡（推理模式）调整
      top_p: 0.95             # 按模型卡（推理模式）调整

关键规则：

• max_new_tokens 不允许按任务覆盖：只设一个全局上限。对多轮/代理式基准，上限必须满足 n_turns × max_new_tokens + prompt < max_model_len（模型卡给出的通常是单轮数值，直接照搬可能让样本以 HTTP 400 或 finish_reason: length 丢失）。
• temperature / top_p 允许按任务覆盖：模型卡常按场景给出不同采样参数，可在任务级 nemo_evaluator_config.config.params 下覆盖；但 MLflow 的 tags 只记录顶层值，若有覆盖需在 run 的 description 中注明，避免误报。
• parallelism：根据 dataset_size × repeats（MMMU-Pro 即数据集规模 × 1）与 GPU 服务容量的关系确定，并在 command 中追加 --max-num-seqs N = ceil(max_parallelism / data_parallel_size)。

运行流程：dry-run → canary → full

MMMU-Pro 与 aa/ 套件其他任务共用 SKILL.md 中的三级门禁流程：

Step 8.1 — 配置校验（dry-run）：

nel run --config <path> --dry-run

修复未解析的 ???、Hydra override 错误、缺失环境变量、非法挂载与 sbatch 错误。注意 dry-run 不会拉取镜像，image: 的 vLLM 版本是否达标需在提交前人工核对。对 ns_* / 配方任务出现的 "unlisted task"、"minimal task definition" 等噪音属预期现象，可设 NEMO_EVALUATOR_TRUST_UNLISTED_TASKS=1。

Step 8.2 — 小样本 canary：

nel run --config <path> -o ++evaluation.nemo_evaluator_config.config.params.limit_samples=10

canary 验证 dry-run 无法覆盖的部分：容器启动、多模态请求格式、图像处理链路、OOM、低评估计数等。用 nel status <id> / nel info <id> --logs 检查日志，在 judge/多模态链路日志干净后再提高 parallelism。单独重跑本任务用 nel run --config <path> -t ns_mmmu_pro（可与 limit_samples 叠加）。

Step 8.3 — 全量运行：

nel run --config <path>

移除 limit_samples，保持 canary 验证过的并发设置。若需 MLflow 自动导出，需同时具备触发开关 execution.auto_export.destinations: [mlflow] 与 export.mlflow 配置块（其中 experiment_name / tags 必须用字面值，不得引用 ${deployment.*} / ${evaluation.*}，且 temperature / top_p / max_new_tokens 三个 tag 要与顶层 params 同步更新）；若检查点带有 .experiment.json（由 hf_ptq.py --mlflow 写入），应把其中的 experiment_name、run_name 等以 modelopt_* 前缀的 tag 带入，使评测归组到产生该检查点的 PTQ 运行下。

从 MLflow 提取 MMMU-Pro 分数

运行完成后，MMMU-Pro 的结果指标在 MLflow 中的键名为（0-100 分数）：

mmmu-pro_pass_at_1_symbolic_correct

• 该指标名与任务名 ns_mmmu_pro 一一对应，语义为"符号级正确率的 pass@1"，可直接作为端到端报告分数写入评测结论。
• 对照同套件其他任务的提取键（如 gpqa_pass_at_1_avg-of-16_symbolic_correct、hle_pass_at_1_judge_correct），MMMU-Pro 的键不含 judge 或 repeat 后缀，因为它不依赖外部 judge，且 num_repeats: 1。
• 上报前请遵循 run-validation.md：核对日志与样本覆盖，完成 Timeout 与 Output-Limit 核算；若存在缺失遥测，如实标注为 unknown，不要以不完整数据冒充完整结果。

量化模型评测建议

将 MMMU-Pro 纳入量化验证时的实操建议（依据 quantization-benchmarks.md）：

• 适用场景：多模态模型（VLM）的量化检查点验证，或作为 AA 多模态套件的组成部分；纯文本 LLM 的量化验证请使用 GPQA、SciCode、LCR 等文本任务。
• 预期敏感性：只量化 LLM 主体时通常 Low/Medium——视觉编码器/适配器常保持 BF16，因此图像理解链路不受量化影响，分数主要反映量化后 LLM 跨模态推理能力的损失。
• 组合使用：多模态报告建议同时给出文本套件 + MMMU-Pro 的逐任务分数，并明确标注套件范围（本技能生成的套件不含 GDPVal，聚合分数与公开发布的 AA Index 不可直接对比）。
• 部署匹配：务必使用多模态端点（含视觉编码器加载配置与必要的 --mm-encoder-attn-backend 参数），并对同一模型的多模态配置保持评测环境一致，确保基线（BF16）与量化版本可比。