Model-Optimizer 量化模型精度验证基准选型指南：AA Index v2 评测套件与 NEL 配置实践

本文聚焦 Model-Optimizer 仓库中 evaluation skill 的量化感知基准推荐（quantization-aware benchmark recommendations），面向"评估一个量化 checkpoint（NVFP4、FP8、INT4-AWQ 等）的精度损失"这一核心场景。文章完整继承 skill 文档中的任务配方表、按场景推荐集合与量化运行注意事项，并结合仓库内的任务 recipe、示例配置（example_eval.yaml）与 .env 模板，给出可直接落地的 NEL（NeMo Evaluator Launcher）评测配置与调优指南。读完本文，你将能针对量化 checkpoint 挑选对精度损失最敏感的评测基准、按 AA（Artificial Analysis）套件规则组装多任务配置、正确设置并发与采样参数，并读懂 MLflow 中的指标字段。

为什么量化模型需要专门的基准选型

量化（如 FP8、NVFP4、INT4-AWQ）会以不同幅度侵蚀模型精度：知识召回类任务对精度损失高度鲁棒，而长链推理、代码生成、长上下文任务往往对单 token 错误极其敏感。用"过宽"的基准集评估量化 checkpoint，噪声会掩盖真实回归；用"过敏感"的基准集，则会把无害的格式差异误判为严重退化。因此，evaluation skill 默认以 Artificial Analysis (AA) Index v2 套件 作为量化 checkpoint 验证的基准集——它是为捕捉精度损失而设计的敏感度分层基准组合，位于 recipes/tasks/aa/ 目录下。

该 skill 的定位（见 SKILL.md）是评估量化或未量化 LLM 的精度，通常作为 PTQ → Deploy → Eval 流程的最后一环：先量化模型（ptq skill），再部署（deployment skill），最后用本 skill 生成 NEL YAML 配置并执行评测。

GDPVal 的移除与套件边界

GDPVal 已不再被该 skill 支持。 它是 AA 套件成员，因此本 skill 的"AA 套件"实际上是 AA 套件减去 GDPVal 之后的集合。这意味着：

• 套件用于相对 baseline-vs-candidate 对比，并按任务报告各自分数；
• 不要拿结果与公开发布的 AA Index 总分直接对齐——缺失的 agentic-deliverables 维度（GDPVal）会使得总分不完整；
• 当对比以公开 AA Index 为参照时，应明确说明该维度缺失，而不是把剩余任务包装成完整套件。

全部可用任务配方一览

skill 文档维护了一张完整配方表，每个配方对应 recipes/tasks/ 下的一个 recipe 文件（或 recipes/tasks/aa/、recipes/tasks/gym/ 子目录），字段包括评测基准、harness、衡量内容与量化敏感度：

配方文件	基准	衡量内容	量化敏感度
tasks/mmlu_pro.md	MMLU-Pro（ns_mmlu_pro，nemo-skills，num_repeats: 1）	通用知识（10 选 boxed）	低——知识回忆对精度损失鲁棒；廉价 sanity check，而非回归探测器
tasks/aime_2025.md	AIME 2025（AIME_2025_aa_v2，simple-evals）	竞赛数学（n_samples: 64）	高——长链推理中单 token 错误会级联成最终答案错误
tasks/livecodebench.md	LiveCodeBench v6（ns_livecodebench，nemo-skills）	代码生成（num_repeats: 8）	高——代码对单 token 错误脆弱（一个错误标识符 = 测试失败）
tasks/aa/gpqa_diamond.md	GPQA Diamond（ns_gpqa，nemo-skills，num_repeats: 16）	硬科学 MCQ（4 选）	高——虽是 MCQ，但答案需要多步推理，量化可能破坏推理链
tasks/aa/hle.md	HLE（Humanity's Last Exam，纯文本，judge 评分）	前沿难题	高——边界答案对小的精度损失敏感
tasks/aa/lcr.md	LCR	长上下文推理（约 120K 输入，judge 评分）	极高——KV-cache 与 attention 量化误差在整个上下文窗口累积
tasks/aa/scicode.md	SciCode	多步科学代码 + 沙箱执行	极高——推理 + 代码 + 沙箱叠加，错误跨子任务复合
tasks/aa/ifbench.md	IFBench	指令跟随	低——格式合规鲁棒；即使激进的 FP4 通常也只显示小幅下降
tasks/aa/mmmu_pro.md	MMMU-Pro	多模态推理	仅 VLM；通常低/中（只量化 LLM 时，视觉编码器/适配器通常保持 BF16）
tasks/aa/tau2_bench_telecom.md	Tau2-Bench Telecom	Agentic 工具调用（user-simulator + judge）	中高——工具调用 JSON 脆弱，但 user-sim + judge 方差常主导信号
tasks/aa/omniscience.md	AA-Omniscience	知识可靠性（ns_omniscience，nemo-skills，num_repeats: 10）——对冷门事实判断 正确/幻觉/弃答，judge 评分	中——衡量幻觉/弃答平衡；激进的精度损失会侵蚀事实回忆并偏移 omni-index
tasks/gym/mrcr.md	MRCR（nemo_gym simple agent，独立配置，非 AA）	长上下文共指检索（最长 1M token）；确定性前缀门控 SequenceMatcher 评分，按 needle 数分层	极高——此处可用的最长上下文任务；KV-cache 与 attention 量化误差全窗口累积。无 judge，信号干净。按需启用：仅当用户要求 MRCR 或长上下文覆盖

注意目录语义：tasks/gym/ 按 harness（NeMo Gym）分组而非套件分组，MRCR 虽放在 gym/ 下但不是 AA 基准，绝不可为 "AA" 请求生成它。同理，tasks/aa_next/（如 SWE-bench Verified、Terminal-Bench 2.1）走的是 nel-next/harbor 路径，与 0.2.6 的 evaluation.tasks 列表不兼容。

按使用场景的推荐基准集合

使用场景	推荐基准
快速 sanity check	GPQA
标准量化验证（文本 LLM）	GPQA、SciCode、LCR
AA / Artificial Analysis 套件（文本 LLM）	全部 tasks/aa/ 文本任务：GPQA、HLE、LCR、SciCode、IFBench、Tau2-Bench Telecom、AA-Omniscience（GDPVal 是 AA 成员但此处不支持）
AA / Artificial Analysis 套件（多模态）	AA 文本套件 + MMMU-Pro
代码向模型	LiveCodeBench、SciCode
推理模型	AIME 2025、GPQA、HLE

作用域规则（scope rule）与请求消歧

skill 文档对两种典型请求给出了明确的配置生成规则：

• 默认量化验证（用户只说"评估这个量化 checkpoint"）：使用 AA 套件（aa/ 任务）加上 三个始终包含的基准 recipes/tasks/*.md（MMLU-Pro、AIME 2025、LiveCodeBench）。
• 显式 AA 请求（提到 "AA" / "Artificial Analysis" / "AA Index v2"）：只用 aa/ 任务，不要静默附加那三个 always-include 任务——它们位于 recipes/tasks/*.md，是独立的另一组。同时在开始就声明 GDPVal 不在覆盖范围内。

# "AA" 请求的正确姿态
# 1. 将 recipes/tasks/aa/ 下的任务生成到一个多任务配置中；
# 2. 不要静默加入 MMLU-Pro / AIME 2025 / LiveCodeBench；
# 3. 明确告知 GDPVal（AA 成员）不受支持。

量化 checkpoint 运行的核心注意事项

AA-LCR：全套件最敏感的任务

LCR 的量化敏感度最高，KV-cache 与 attention 量化误差会横跨约 120K 输入 token 的整个上下文窗口累积。只要 checkpoint 支持所需上下文长度（recipe 要求 --max-model-len 131072 起，实际建议至少 196608），就应该包含它。 具体部署要求（见 lcr.md）：

• 部署侧 vllm serve 命令必须带 --max-model-len 196608（或更高），且该 flag 要放在 deployment.command: 字段内（SKILL.md Step 3 的约定，extra_args 字段已废弃）；baseline 与量化部署必须使用同一值。
• 并行度要设得比顶层默认更低，原因有二：其一（KV-bound），每个请求携带约 120K 输入 token，KV 占用巨大，高 parallelism 会触发 preemption，而重算 120K token 的 prefill 代价极高，过度并行反而更慢（详见 parallelism.md 的 "Balanced sizing"）；其二（judge-bound），equality-checker 端点会先于被服务模型触发限流。建议 GQA 模型从约 16–32 起步，MLA 模型（如 Kimi）可耐受数倍于此，仅在 preemption ≈ 0 且 judge 无 429 时再上调。选定后需按规则重算部署侧 --max-num-seqs（= ceil(max_parallelism / data_parallel_size)）。

LCR 的任务 YAML 片段（judge 为硬编码的 Qwen3 235B，可换等价端点）：

- name: ns_aa_lcr
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
    LOG_LEVEL: lit:WARNING # Skip logging the long context inputs.
  nemo_evaluator_config:
    target:
      api_endpoint:
        adapter_config:
          use_request_logging: false
          use_response_logging: false
    config:
      params:
        parallelism: ???   # 设得比顶层低：长上下文（KV-bound）+ judge-bound；设定后重算 --max-num-seqs
        extra:
          num_repeats: 16
          judge:
            model_id: nvidia/qwen/qwen-235b   # Qwen3 235B；自有端点可用等价模型替换
            url: <INFERENCE_JUDGE_URL>              # 来自 .env（/v1 base）
            api_key: INFERENCE_API_KEY       # env-var 名；导出后被 harness 读取

MLflow 指标字段：aalcr_pass_at_1_avg-of-N_judge_correct（0-100），N 为重复次数；若重复次数未知，取可用的最高 avg-of-N。

重复次数/采样数：为低方差而调，不要为量化对比调低

recipe 中的重复/采样数是按低方差目标校准的，量化对比时下调它们会让噪声掩盖真实回归。字段名因 harness 而异：

• n_samples（simple-evals 系）：AIME 为 64，tau2-bench 为 8；
• num_repeats（nemo-skills 系）：AA-LCR/GPQA 16、AA-Omniscience 10、LiveCodeBench 8、IFBench 5、MMLU-Pro 1；
• SciCode 是例外：num_repeats: 1 × 8+ 次独立提交再取平均（见下文）。

Judge / user-simulator 端点：对比时必须固定

AA-LCR、HLE（AA）、AA-Omniscience、Tau2-Bench Telecom 都依赖 judge / user-simulator 端点。baseline 与量化运行必须保持 judge 与（Tau2 的）user-simulator 模型完全一致，才能保证 apples-to-apples 对比。这些 judge 的 model_id 在各 recipe 中硬编码（如 HLE 用 GPT-4o、Omniscience 用 gemini-3-flash-preview、Tau2 的 judge 用 gpt-oss-120B、user 用 Qwen3 235B），可在自有端点上换等价模型；只有端点 URL（INFERENCE_JUDGE_URL、TAU2_ENDPOINT_URL）来自 .env，属于配置而非机密，无需 export——只有 api_key（INFERENCE_API_KEY）被导出供 harness 读取。

.env 模板（env.example）中与本主题直接相关的项：

# 所有任务必需（模型/数据集下载）
HF_TOKEN=hf_...

# nemo_skills.* 任务必需（占位值，非真实 key）
DUMMY_API_KEY=dummy

# NEL pre_cmd 执行必需
NEMO_EVALUATOR_TRUST_PRE_CMD=1

# judge / 推理端点 key（HLE、AA-LCR、Tau2、AIME 等）
INFERENCE_API_KEY=

# judge / user-simulator 端点 URL（仅 URL；nemo-skills 用 /v1 base）
INFERENCE_JUDGE_URL=https://<your-inference-host>/v1
# Tau2 需要完整 /v1/chat/completions
TAU2_ENDPOINT_URL=https://<your-inference-host>/v1/chat/completions

# NeMo Gym 任务（MRCR）必需
NEMO_EVALUATOR_TRUST_UNLISTED_TASKS=1

IFBench：最不敏感的回归检查

IFBench 是套件中量化敏感度最低的任务，但对激进格式（NVFP4、INT4-AWQ）仍是有价值的回归检查——格式合规被破坏时会暴露。其片段为 ns_ifbench，num_repeats: 5，MLflow 指标 ifbench_pass_at_1_avg-of-N_prompt_loose_accuracy。

MRCR：非 AA 的确定性长上下文任务

MRCR（OpenAI Multi-Round Co-reference Resolution）运行在 NeMo Gym simple_agent 上，无 judge——使用确定性的前缀门控 SequenceMatcher.ratio() 评分，0 除非响应以要求的前缀开始，并按 needle 数（2/4/8）分层。它是 skill 中上下文最长的任务（最长 1M token），量化损伤会最先击中 8-needle 层，而聚合分数仍可能看似平稳，因此报告分数时必须同时给出 2/4/8 各层（完整操作见 mrcr.md）。

使用要点：

• 独立配置，绝不同其他任务混合：一个 gym eval 对应一个配置，从自包含示例 example_mrcr.yaml 起步，不要向其他配置复制片段；
• 先选变体（config_n3_1m / config_n3_128k / config）：它同时决定上下文上限、数据集和指标前缀，三个变体使用不同数据集，互不可比；必须在 data_prep_params 和 collect_rollout_params 两处都设置，只改一处会"准备一个数据集却 rollout 另一个"；
• KV dtype 跟随 checkpoint 而非模板：从 checkpoint 的 hf_quant_config.json 读取 kv_cache_quant_algo，传入匹配的 --kv-cache-dtype。vLLM 不会自动推断它（config.json 的 quantization_config 不含 kv_cache 键）——FP8-KV 校准过的 checkpoint 必须显式传 flag；未校准的 checkpoint 绝不能强制给 fp8（等于对从未校准过的模型强加 KV 量化，而这里恰恰是误差会横跨约 1M token 累积的场景）。BF16 KV 可用且是安全默认，但 KV 占用约翻倍，在 1M 场景下决定 cache 是否放得下；若 baseline 与 candidate 声明了不同 KV 算法，该差异本身就是 delta 的一部分，应报告而非强行拉平；
• 1M 变体的 serving envelope：--max-model-len 1100000 + VLLM_ALLOW_LONG_MAX_MODEL_LEN=1、gpu_memory_utilization: 0.95、--enable-prefix-caching、--enable-chunked-prefill、--max-num-batched-tokens 131072；绝不封顶输出 token（答案要复现整段前文）；
• 分数不在 results.yml，需读取 artifacts/evaluator_rollouts_aggregate_metrics.json 的 [0].agent_metrics：报告 pass@1/accuracy（已是 0-100，勿再 ×100）与各 needle 分层，mean/prefix_matched 约 0.55 视为健康；
• 参考形态（golden，BF16 Nano 3.5，1M）：pass@1 = 26.91（2/4/8 needle = 36.81 / 27.12 / 16.74），2363/2363 rollouts——仅用于 sanity-check 形态而非给别的模型设标杆。

SciCode：8 次提交是硬性下限

SciCode 是 nemo-skills 的代码/推理基准，多步提示 + 代码执行沙箱。skill 文档明确：单次运行永远不是可报告的 SciCode 分数——在 temperature 1.0 下其噪声可匹敌 1% 的门槛（实测：配对对比重复后移动了 3.92 pp 并改变了符号；DeepSeek-V4-Pro 在 1 次运行时读作 2.96 pp 的 REGRESSION，8 次时却是 -0.96 pp 的 PASS）。规则如下（完整版见 scicode.md）：

• 提交直至至少持有 8 次有效运行（通常 8 次提交，更多则更好；对比双方各至少 8 次，8-vs-1 不是 apples-to-apples）；多任务 AA 配置中套件跑一轮后，单独循环跑 SciCode：for _ in $(seq 7); do nel run --config <cfg> -t ns_scicode; done；
• 每次必须是全新的 nel run——重新提交某次运行的 run.sub 会从响应缓存恢复并重放生成；相等分数是"需要核查的信号"而非证据（SciCode 分数是离散的，独立运行经常平局），应从 provenance（invocation id、输出目录、响应产物）确认没有重放后再处理；
• 报告 n 次合并运行的均值，用样本标准差（n-1 分母）除以 √n 作为标准误，并给出 n；合并前逐次按 run-validation.md 验证，无效运行应重提替换，而不是把沙箱崩溃的运行混入；
• 少于 8 次有效运行 = INDETERMINATE，永远不是 pass/fail 结论；
• 预期会出现导出超时：导出任务同时落在 CPU 分区且每次针对固定的 30 分钟 sbatch 限制重装 launcher；分数保留在运行产物中，重提该运行的 export.sbatch 即可，并非丢失。

SciCode 的 YAML 片段：

- name: ns_scicode
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03
  nemo_evaluator_config:
    config:
      params:
        parallelism: 8
        extra:
          args: ++prompt_config=eval/scicode/default ++with_background=true
          num_repeats: 1 # 保持 1；该配置提交 8 次后取平均（见上）

其他关键要求：部署上下文至少 --max-model-len 65536（示例模板默认 131072 更优，勿无内存理由下调）；parallelism: 8 精确值，baseline 与 candidate 一致；重复用"独立多次提交"而非 num_repeats: 8（运行内重复会成倍增加代码执行沙箱暴露面）。

MLflow 字段陷阱：num_repeats: 1 时没有 avg-of-N 段（harness 仅在 N > 1 时添加，如 gpqa_pass_at_1_avg-of-16_symbolic_correct），avg-of-1 这个名字会静默收获空值。单次运行字段为 scicode_pass_at_1_subtask_accuracy（0-100），最终报告值 = 该字段跨全部合并运行的均值。

单任务配方速查（含 YAML 片段与 MLflow 字段）

以下配方均为 evaluation.tasks 列表条目，可直接复制进配置。

GPQA Diamond（gpqa_diamond.md）：AA 4 选 MCQ prompt（++prompt_config=eval/aai/mcq-4choices），num_repeats: 16；指标 gpqa_pass_at_1_avg-of-16_symbolic_correct。

- name: ns_gpqa
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03
  nemo_evaluator_config:
    config:
      params:
        extra:
          num_repeats: 16
          args: "++prompt_config=eval/aai/mcq-4choices"

HLE（hle.md）：纯文本、judge 评分，参数对齐 AA Index v2；judge 硬编码 GPT-4o；hle_strict_judge: true 开启严格评判。指标 hle_pass_at_1_judge_correct（0-100）。不要为自部署模型加 ++server.enable_soft_fail=True——在 nemo-skills 0.7.0 中它会强制客户端从被服务模型名加载 tokenizer，而该名字不是真实 HF 仓库时会 404 导致运行失败；若确需 soft-fail，须同时设置 ++tokenizer 为 HF id 或容器可加载的本地 tokenizer。

- name: ns_hle_aa
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
  nemo_evaluator_config:
    config:
      params:
        extra:
          judge:
            model_id: azure/openai/gpt-4o   # GPT-4o；自有端点可用等价模型替换
            url: <INFERENCE_JUDGE_URL>              # 来自 .env（/v1 base）
            api_key: INFERENCE_API_KEY       # env-var 名；导出后被 harness 读取
            hle_strict_judge: true

AA-Omniscience（omniscience.md）：知识/幻觉基准，num_repeats: 10，judge 硬编码 gemini-3-flash-preview；++parse_reasoning=False 是 golden knob（omniscience 评分最终答案而非推理轨迹）。主指标是 Omniscience Index（-100 到 100）：omniscience_pass_at_1_avg-of-N_judge_omni_index——AA 的头条指标，等于扣掉幻觉后的准确率，奖励弃答而非乱猜（因此可为负）。同时报告 Accuracy（..._judge_correct）与非幻觉率（100 - ..._judge_omni_hallucination）。

- name: nemo_skills.ns_omniscience
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.05.1
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
  nemo_evaluator_config:
    config:
      params:
        extra:
          num_repeats: 10
          args: "++parse_reasoning=False"
          judge:
            api_key: INFERENCE_API_KEY
            model_id: gcp/google/gemini-3-flash-preview   # 自有端点可用等价模型替换
            url: <INFERENCE_JUDGE_URL>                     # 来自 .env（/v1 base）

Tau2-Bench Telecom（tau2_bench_telecom.md）：被评估模型作为 agent + 独立 user-simulator 端点，两端都必须跨运行固定；judge（gpt-oss-120B）与 user（Qwen3 235B）硬编码在片段中。需要完整 /v1/chat/completions URL（nemo-skills 的 judge 用 /v1 base）。部署侧强制要求工具调用：服务模型必须带 --enable-auto-tool-choice --tool-call-parser <parser> 启动，否则每个 trial 都返回 avg_reward 0.0 且零 tool_calls；parser 从 checkpoint 的 chat_template.jinja 选择：XML <tool_call><function=…> → qwen3_coder（Qwen3/3.5），JSON <tool_call>{"name":…} → hermes。若 --reasoning-parser 开启导致频繁出现仅 <think> 无工具调用的空响应，考虑 enable_thinking: false。并行度上限 512，建议保守起步（如 32–128）观察 429 再上调。指标 tau2_bench_telecom_pass_at_1（0-1）。

- name: tau2_bench_telecom
  container: nvcr.io/nvidia/eval-factory/tau2-bench:26.03
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
  nemo_evaluator_config:
    config:
      params:
        parallelism: ???   # 必填：见上；上限 512；设定后重算 --max-num-seqs
        extra:
          cache:
            cache_dir: /results/native_cache
            enabled: true
          skip_failed_samples: true
          n_samples: 8
          user:
            model_id: nvidia/qwen/qwen-235b    # Qwen3 235B；自有端点可用等价模型替换
            url: <TAU2_ENDPOINT_URL>           # 来自 .env（完整 /v1/chat/completions）
            api_key: INFERENCE_API_KEY         # env-var 名；导出后被 harness 读取
          judge:
            model_id: nvidia/openai/gpt-oss-120b   # gpt-oss-120B；自有端点可用等价模型替换
            url: <TAU2_ENDPOINT_URL>           # 来自 .env（完整 /v1/chat/completions）
            api_key: INFERENCE_API_KEY         # env-var 名；导出后被 harness 读取

MMLU-Pro（mmlu_pro.md）：always-include 集合之一，AA 10 选 boxed MCQ prompt（++prompt_config=eval/aai/mcq-10choices-boxed），num_repeats: 1；指标 mmlu-pro_pass_at_1_symbolic_correct（注意连字符 mmlu-pro）。

AIME 2025（aime_2025.md）：simple-evals harness，n_samples: 64，judge 硬编码 GPT-4o。必须按片段覆写 judge，而不是依赖 simple-evals 默认（integrate.api.nvidia.com + JUDGE_API_KEY）——默认端点在占位 key 下返回 401，即使模型服务器返回 200 任务也会失败。指标 AIME_2025_score_micro_avg_of_N（0-1）。

- name: AIME_2025_aa_v2
  container: nvcr.io/nvidia/eval-factory/simple-evals:26.03
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
  nemo_evaluator_config:
    config:
      params:
        extra:
          n_samples: 64
          judge:
            model_id: azure/openai/gpt-4o   # GPT-4o；自有端点可用等价模型替换
            url: <INFERENCE_JUDGE_URL>              # 来自 .env（/v1 base）
            api_key: INFERENCE_API_KEY       # env-var 名；导出后被 harness 读取

LiveCodeBench v6（livecodebench.md）：num_repeats: 8、dataset_split: test_v6_2408_2505；指标 livecodebench_pass_at_1_avg-of-N_accuracy（0-100）。

IFBench（ifbench.md）：num_repeats: 5；指标 ifbench_pass_at_1_avg-of-N_prompt_loose_accuracy（0-100）。

MMMU-Pro（mmmu_pro.md）：多模态任务，需多模态端点；num_repeats: 1；指标 mmmu-pro_pass_at_1_symbolic_correct。

端到端：从示例配置起步的量化验证流程

skill 文档给出了明确的操作姿态（"How to use"）：当用户要评估量化 checkpoint 时，先呈现上文的推荐集合并询问选择；若用户已指定基准列表，保留其选择，但标记出他们遗漏的、常用于量化验证的 AA 套件基准；然后在编辑配置前先读取对应的 recipe 文件。

实际起步点是 example_eval.yaml——一个 AA 对齐的单任务模板（默认含 ns_gpqa，num_repeats=16，AA mcq-4choices），把 recipes/tasks/aa/*.md 的任务片段复制进 evaluation.tasks 列表即可扩展。模板同时定义了部署与运维约定，这些约定与量化验证直接相关：

• 运行命令：nel run --config recipes/examples/example_eval.yaml -o deployment.checkpoint_path=/path/to/quantized/checkpoint -o deployment.served_model_name=my-model-nvfp4 -o execution.hostname=<slurm_host> -o execution.account=<slurm_account> -o execution.output_dir=/path/to/output；单任务加 -t ns_gpqa；canary 用 -o ++evaluation.nemo_evaluator_config.config.params.limit_samples=2；
• 优先 checkpoint_path 而非 hf_model_handle：后者在当前 NEL 中不能可靠挂载到 /checkpoint，会导致 vLLM 把 /checkpoint 当 HF repo id 报 HFValidationError；未暂存的 HF 模型先 snapshot_download 到集群再指向 checkpoint_path；
• 量化 checkpoint 默认不额外加 vLLM 量化 flag：新版 vLLM 从 checkpoint 读取 ModelOpt 量化元数据；仅在模型卡、vLLM 版本或 dry-run 错误要求时才显式加（如 NVFP4 MoE 需要 VLLM_USE_FLASHINFER_MOE_FP4=1、VLLM_FLASHINFER_MOE_BACKEND=throughput）；
• --served-model-name 必填，否则 vLLM 以 /checkpoint 服务且评测请求 404；MoE 加 --enable-expert-parallel，自定义代码模型加 --trust-remote-code；--model-loader-extra-config 开启多线程加载（默认开，128 线程）可将大 checkpoint 加载从几十分钟缩短到几分钟；
• 并行度与 --max-num-seqs：填完顶层 + 各任务的 parallelism 后，在命令末尾追加 --max-num-seqs N，N = ceil(max_parallelism / data_parallel_size)（详见 parallelism.md 的拓扑与并发两层决策——TP/DP/EP 布局只影响吞吐不影响分数，量化位宽决定拓扑而非模型名）；
• 采样参数（temperature: 1.0、top_p: 0.95、max_new_tokens 等）与 export.mlflow 里的字面量必须同步修改——NEL 不会把采样配置记入 MLflow run params，export 块是唯一可查记录，且它不能使用 ${deployment.*} 交叉引用（提交时解析不到会硬失败），只能接受 env-var 插值；
• 推理模型注意 adapter 的 use_reasoning: true 与 thinking 开关（chat_template_kwargs 里的 enable_thinking/thinking 按模型家族选择，DeepSeek 系列用 Python encoder，未用到的 key 会报错而非被忽略，不要同时给出）。

实战检查清单

1. 区分两种请求：默认量化验证 = AA 套件 + MMLU-Pro/AIME/LiveCodeBench；显式 AA 请求 = 仅 aa/ 任务，不附加，并声明 GDPVal 缺口；
2. 只要上下文支持就包含 AA-LCR（--max-model-len 至少 196608，baseline/量化保持一致），其并行度要低于顶层默认；
3. 不降低重复/采样数（n_samples/num_repeats 字段名按 harness 区分）；SciCode 例外——num_repeats: 1 但提交 8+ 次取均值，少于 8 次有效运行 = INDETERMINATE；
4. judge / user-simulator 模型跨 baseline 与量化运行固定，端点 URL 来自 .env，仅 INFERENCE_API_KEY 导出；
5. 激进格式（NVFP4、INT4-AWQ）用 IFBench 做格式回归检查；
6. MRCR 永不加入 "AA" 请求，报告 2/4/8 needle 分层，KV dtype 跟随 checkpoint 的 kv_cache_quant_algo（读取 hf_quant_config.json），绝不为未校准 checkpoint 强加 fp8；
7. Tau2 必须带 --enable-auto-tool-choice --tool-call-parser 部署，否则零 tool_calls 全部 0 分；
8. 运行前读取对应 recipe，运行后按 run-validation.md 验证日志与采样覆盖，再报告分数。