IFBench 指令遵循评估实战：基于 NeMo Evaluator Launcher 在 Model-Optimizer 中验证量化模型

人工智能大模型模型优化模型量化模型压缩【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址https://gitcode.com/GitHub_Trending/te/Model-Optimizer点击查看免费下载导读IFBench 是 Model-Optimizer 仓库中 evaluation 技能所维护的 Artificial AnalysisAAIndex v2 评估套件成员之一用于衡量大语言模型的指令遵循instruction following能力。本指南基于 ifbench.md 任务配方完整讲解如何在 NeMo Evaluator LauncherNEL配置中以ns_ifbench任务评估量化或未量化模型包括 YAML 片段、运行流程、并行度选型以及从 MLflow 中提取ifbench_pass_at_1_avg-of-N_prompt_loose_accuracy分数的规范方法。读完本文你将能够把 IFBench 作为 AA 多任务评估配置的一部分落地运行并正确解读其 0-100 分的输出指标。IFBench 在 AA 套件中的定位与量化敏感度任务本质IFBench 评测的是模型的指令遵循能力——模型能否严格按用户指令的格式、约束与步骤完成输出。在 quantization-benchmarks.md 的敏感性对照表中IFBench 被标记为低量化敏感度LowIFBench | Instruction following | Low — format-compliance is robust; even aggressive FP4 usually shows only small drops这意味着与代码生成LiveCodeBench、长上下文推理AA-LCR、竞赛数学AIME 2025等单 token 错误即级联失败的高敏感任务不同指令遵循主要考验格式合规性即使采用激进的 NVFP4 / INT4-AWQ 等压缩格式分数通常也只出现小幅下降。因此 IFBench 不适合作为量化回归的探测器但非常适合作为激进压缩格式的回归检查regression check。何时选用 IFBench依据 SKILL.md 与 quantization-benchmarks.md 的 Scope 规则默认量化验证用户只说评估这个量化 checkpoint使用 AA 套件recipes/tasks/aa/下全部文本任务含 IFBench加上 MMLU-Pro、AIME 2025、LiveCodeBench 三个 always-include 任务明确要求 AA / Artificial Analysis仅生成recipes/tasks/aa/下的任务不额外追加上述三个 always-include 任务AA 套件文本任务完整集合为GPQA Diamond、HLE、LCR、SciCode、IFBench、Tau2-Bench Telecom、AA-OmniscienceGDPVal 已不再被本技能支持。推荐组合参考使用场景基准集合快速 sanity checkGPQA标准量化验证文本 LLMGPQA、SciCode、LCRAA 套件文本 LLMAA 套件全部文本任务含 IFBench激进格式回归检查全套件中低敏感任务IFBench作为观察项前置条件.env 与任务密钥配置 .envworkspace 根目录NEL 从提交 shell 的环境变量读取密钥host:前缀.env应放置在运行nel的工作目录根而不是技能目录下。若尚未创建从模板复制[ -f .env ] || cp $SKILL_DIR/recipes/env.example .env set -a source .env set a模板见 env.exampleIFBench 相关的关键项变量用途是否必需HF_TOKEN模型/数据集下载所有任务必需是DUMMY_API_KEYdummynemo_skills.*任务含ns_ifbench必需占位密钥是NEMO_EVALUATOR_TRUST_PRE_CMD1允许 NEL 执行配置中的pre_cmd是如配置含 pre_cmd为什么 nemo-skills 任务必须有 DUMMY_API_KEYns_ifbench属于 nemo-skills harness其客户端硬性要求所声明 API 密钥环境变量在评估容器内有值否则直接报错ValueError: api_key_env_varDUMMY_API_KEY but the value is not set。在 SLURM 环境下shell 里export DUMMY_API_KEYdummy不会传播进容器——NEL 只注入在env_vars中声明的变量。因此必须在配置的evaluation.env_vars中显式声明evaluation: env_vars: DUMMY_API_KEY: lit:dummy # lit: 前缀表示字面量见下 nemo_evaluator_config: target: api_endpoint: api_key_name: DUMMY_API_KEYNEL env-var 前缀规则env_vars映射中每个值都必须带显式前缀——host:VAR提交时从 shell 环境读取、lit:value字面量、runtime:VAR作业运行时读取。裸值如DUMMY_API_KEY: dummy会硬报错Env var value … must have an explicit prefix.。常量用lit:密钥HF_TOKEN、INFERENCE_API_KEY等用host:。YAML 片段将 IFBench 加入 evaluation.tasks任务片段ifbench.md 给出的片段需放入顶层evaluation.tasks列表NEL 0.2.6 路径- name: ns_ifbench container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03 nemo_evaluator_config: config: params: extra: num_repeats: 5各字段说明name任务标识ns_前缀表示 nemo-skills harness。单任务重跑/金丝雀时用-t ns_ifbench定位container评估任务容器镜像nvcr.io/nvidia/eval-factory/nemo-skills:26.03NGC 仓库AA 套件任务共用num_repeats: 5重复次数。IFBench 属于 nemo-skills harness对应字段名为num_repeatssimple-evals 的 AIME/Tau2 用n_samplesSciCode 是num_repeats: 1× 8 次提交取均值。重复次数直接影响下游指标键中的avg-of-N值。注意AA 任务IFBench、GPQA、LCR 等运行在当前已验证的nemo-evaluator-launcher0.2.6 路径上Agentic 类基准Terminal-Bench 2.x、SWE-bench属于aa_next/目录走独立的 nel-nextnemo-evaluator[harbor]0.4.x流程不要混入evaluation.tasks列表。与多任务 AA 配置集成IFBench 通常作为 AA 多任务配置的一个条目。以 example_eval.yaml 为基础模板将上述片段追加进evaluation.tasks。模板默认含ns_gpqanum_repeats: 16、prompt_configeval/aai/mcq-4choicesAA 套件生成时把recipes/tasks/aa/各任务片段一并复制即可。参考片段IFBench GPQA 并存evaluation: nemo_evaluator_config: config: params: parallelism: ??? # 每个基准的在飞请求数见并行度一节 request_timeout: 3600 max_retries: 10 max_new_tokens: 65536 # 推理模型 64K非推理 16K以模型卡为准 temperature: 1.0 # 推理模式来自模型卡 top_p: 0.95 tasks: - name: ns_gpqa container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03 nemo_evaluator_config: config: params: extra: num_repeats: 16 args: prompt_configeval/aai/mcq-4choices - name: ns_ifbench container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03 nemo_evaluator_config: config: params: extra: num_repeats: 5顶层nemo_evaluator_config.config.params必须恰好包含六个字段parallelism、request_timeout、max_retries、max_new_tokens、temperature、top_p不要混入top_k、presence_penalty等。max_new_tokens禁止做 per-task 覆盖只设一个顶层上限temperature/top_p则允许且常需要按任务覆盖模型卡中的分场景采样设置。部署与并行度选型vLLM 部署要点以 example_eval.yaml 的deployment块为基准模型路径优先checkpoint_path集群上已存在的路径NEL 将其挂载到容器内/checkpointhf_model_handle在 NEL 中不保证挂载可能触发HFValidationError。未暂存的 HF 模型先huggingface_hub.snapshot_download再指向 checkpoint_pathserved_model_name必须设置否则 vLLM 以/checkpoint为服务名评估请求会 404镜像默认vllm/vllm-openai:v0.26.0是下限而非推荐值按模型的 recipes.vllm.ai 最低版本升级禁止:latest破坏可复现性。NVFP4 在 Blackwell B300/GB300sm_103上需要 CUDA-13 构建按镜像报告的CUDA_VERSION选 tag不要按 tag 名字猜测量化 checkpoint默认不加--quantization标志——新版 vLLM 从 checkpoint 的quantization_config/hf_quant_config.json自动读取 ModelOpt 量化元数据。仅当模型卡、vLLM 版本或 dry-run 报错要求时才显式添加。IFBench 的并行度策略依据 parallelism.mdparallelism与--max-num-seqs只影响吞吐不影响分数serving_capacity max-num-seqs × DP × num_instances max-num-seqs ceil(parallelism / (DP × num_instances))IFBench 属于短上下文、模型/GPU KV 受限的一类任务与ns_gpqa同类瓶颈在模型而非 judge/沙箱因此使用顶层默认 parallelismpreemption-free 的 KV-fit 并发无需像ns_aa_lcr长上下文或ns_scicode沙箱那样压低或单独限制。选型要点parallelism上限取两个值中的较小者总请求数dataset_size × repeats与任务上下文的免抢占容量--max-num-seqs ceil(顶层各任务最大 parallelism / DP)部署必须服务最繁忙的任务目标约为任务工作上下文下免抢占 KV-fit 并发的70–80%金丝雀阶段在Preempted N出现时调低、KV 使用率远低于 100% 时调高。运行流程dry-run → canary → fullStep 8 三阶段门控launcher-workflow.md 规定评估必须按门控顺序执行8.1 Dry-run配置校验nel run --config path --dry-run修复未决???、Hydra 覆盖错误、缺失环境变量、无效挂载与 sbatch 拒绝。注意 dry-run不会校验镜像/vLLM 版本镜像在部署时才拉取ns_*任务的 unlisted task 提示属于预期噪声设置NEMO_EVALUATOR_TRUST_UNLISTED_TASKS1即可。8.2 Canary限量样本nel run --config path -o evaluation.nemo_evaluator_config.config.params.limit_samples10捕获 dry-run 无法发现的问题容器失败、OOM、请求格式错误、低评估计数。单任务金丝雀nel run --config path -t ns_ifbench -o ...limit_samples10。随后检查日志nel status id nel info id --logs8.3 全量运行nel run --config path移除limit_samples覆盖保留金丝雀验证过的并行度。金丝雀失败必须先修复再重跑金丝雀不得跳过。运行验证报告分数前必须完成 run-validation.md 规定的验证扫描客户端/部署/judge 日志中的Traceback、OOM、timeout、rate limit等故障串确认样本覆盖与重复次数一致完成 Timeout 与 Output-Limit 核算finish_reason: length本身不构成解析失败确认 reasoning 轨迹在打分前被正确剥离use_reasoning适配器。SLURM 墙钟超时是 NEL 依赖链恢复的预期事件不要误判为失败也不要通过scancel释放 GPU 中断运行会丢弃响应缓存。从 MLflow 提取 IFBench 分数指标键ifbench.md 规定结果0-100 分从 MLflow 中提取的指标键为ifbench_pass_at_1_avg-of-N_prompt_loose_accuracy其中N 为重复次数。由于配方固定num_repeats: 5实际键为ifbench_pass_at_1_avg-of-5_prompt_loose_accuracy。若重复次数未知使用可用的最高avg-of-N键。指标键结构解读ifbench_基准名前缀对比 GPQA 的gpqa_pass_at_1_avg-of-N_symbolic_correct、HLE 的hle_pass_at_1_judge_correctpass_at_1单次生成即正确的通过率avg-of-N跨 N 次重复取平均prompt_loose_accuracyIFBench 特有的宽松格式匹配打分prompt-based loose accuracy。指标与 MLflow 导出的配套设置MLflow 自动导出依赖 example_eval.yaml 中两个缺一不可的配置块execution.auto_export.destinations: [mlflow]触发开关缺失则运行不自动上传与export.mlflow块。关键约束export.mlflow块内必须使用字面量如experiment_name: ${oc.env:USER}/served_model_name禁止${deployment.*}/${evaluation.*}交叉引用——自动导出在提交时解析该块作用域不含这两个节点会报Interpolation key ... not foundtemperature/top_p/max_new_tokens标签是 MLflow 中采样配置的唯一可查记录NEL 不把它们记为 run params必须与顶层params保持一致并在同一编辑中同步更新否则陈旧标签会静默误报本次运行若 checkpoint 含.experiment.jsonhf_ptq.py --mlflow写入将其experiment_name原样用于experiment_namerun_name/run_id/run_url转入modelopt_run_name/modelopt_run_id/modelopt_run_url标签使评估归组到量化它的 PTQ 运行之下。基线对比与量化回归注意事项从 quantization-benchmarks.md 的量化 checkpoint 运行注意事项出发涉及 IFBench 的关键结论不要降低重复/样本数num_repeats等已按低方差调优量化对比时降低会放大噪声、掩盖真实回归IFBench 是套件中量化敏感度最低的任务但作为 NVFP4、INT4-AWQ 等激进格式的回归检查仍有价值——如果连 IFBench 都出现明显下降说明压缩已损害基础的格式合规能力报告对比结果时按任务分别报告分数不要拼成一个与公开 AA Index 直接比较的聚合值本套件不含 GDPVal聚合值缺少 agentic-deliverables 维度若与发布基线对比先完成 run-validation.md 的 External Baseline Sanity Check外部可对照分数与本机基线绝对差约 ≤5 个百分点视为验证通过否则标记failed并阻止对比结论。延伸阅读任务配方GPQA Diamond gpqa_diamond.md、HLE hle.mdjudge 打分任务需在.env配置INFERENCE_API_KEY与INFERENCE_JUDGE_URL完整配置模板example_eval.yaml评估流程总览SKILL.mdNEL 启动器逐步工作流launcher-workflow.md量化感知基准选型quantization-benchmarks.md并行度与并发选型parallelism.md运行验证与分数报告run-validation.md赞分享人工智能大模型模型优化模型量化模型压缩【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址https://gitcode.com/GitHub_Trending/te/Model-Optimizer点击查看免费下载相关推荐Model-Optimizer 中基于 NeMo Evaluator 评估 Puzzletron AnyModel 压缩模型Ray 部署与 MMLU 评测实战Model Optimizer 中基于 NeMo Evaluator 评估 Puzzletron AnyModel 压缩模型Ray 部署与 MMLU 评测实战人工智能大模型模型优化模型量化模型压缩lm-evaluation-harness 中的 IFEval 任务基于可验证指令的指令遵循评估完整指南lm evaluation harness 中的 IFEval 任务基于可验证指令的指令遵循评估完整指南 导读 IFEvalInstruction Foll人工智能模型评测AI 评测NNI NAS 模型评估器Model Evaluator实战指南从 FunctionalEvaluator 到 PyTorch-LightningNNI NAS 模型评估器Model Evaluator实战指南从 FunctionalEvaluator 到 PyTorch Lightning 在 N人工智能AutoML机器学习深度学习模型压缩特征工程上一篇XXMI Launcher一站式游戏模组管理平台完全指南下一篇Windows驱动存储清理终极指南DriverStoreExplorer完全教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考