refactor: rework FlagOS migration pipeline — dual-branch, multi-version release, gates - #20
Open
Lxiparer wants to merge 144 commits into
Open
refactor: rework FlagOS migration pipeline — dual-branch, multi-version release, gates#20Lxiparer wants to merge 144 commits into
Lxiparer wants to merge 144 commits into
Conversation
- Add skills/ (11 skill modules for automated model migration) - Add shared/ (common utilities and context template) - Add prompts/ (pipeline scripts: run_pipeline.sh, run_batch.sh) - Add docs/ (SKILLS-OVERVIEW, field_reference, project_guide) - Add CLAUDE.md project instructions - Add start_deployment.sh interactive entry point - Merge permissions into .claude/settings.local.json
feat: migrate main changes + improve pipeline robustness
主要变更： - NPU/Ascend 适配：AICore 错误诊断、graph capture 崩溃处理 - 算子名标准化：全链路大写显示名→小写函数名转换 - 健壮性增强：端口自动递增、进程活跃度探测、环境变量安全过滤 - 路径变更：/data/ → /mnt/data/ - Plugin 发布策略：不达标时私有发布 - 崩溃重试策略：不限轮次 + 多种人工定位手段 - 跨段耗时传递：stream_filter 支持 load/save durations - MetaX GPU 检测命令更新 - generate_report 新增 summary 模式和 ledger 兼容
run_batch.sh now archives previous run data before checkpoint detection, consistent with run_pipeline.sh behavior. Updated tasks.txt with new model targets. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…expand permissions - Add `< /dev/null` to all claude invocations in run_pipeline.sh to prevent stdin interference in headless mode - Add token passing documentation to seg3/seg4 prompts - Update config.py to load all tokens (HARBOR_USER/PASSWORD, MODELSCOPE_TOKEN, HF_TOKEN) from container's /flagos-workspace/.env file - Expand settings.local.json with additional curl/network permissions and standard tool permissions (Read, Edit, Write, etc.) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
所有发布统一为私有模式，达标与否仅在总结报告中注明。 移除 config.py 中从 workflow.qualified 推导 publish.private 的逻辑， 更新 SKILL.md、CLAUDE.md 和 generate_report.py 的相关描述。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…tainers Root cause: During Hunyuan-7B-Instruct seg2, Claude read task.txt listing both models, then wasted tool calls on MiniCPM4.1-8B evaluation instead of completing steps 5/6/7 for the target model. Fixes: - Add single-model constraint to seg2 prompt (forbid reading task files, forbid operating other containers, require V1+V2 before moving on) - Hide task.txt/tasks.txt/tasks1.txt during seg2 execution - Expand seg2 completion check to verify both step 4 and step 6 - Add secondary retry if step 6 still incomplete after first retry
- eval_wrapper.py: 新增 --context-yaml/--api-base，自动从 context.yaml 读取端口 - fast_gpqa.py: model_name 为空时自动探测；输出增加 _producer 签名 - run_pipeline.sh: service_ok 兜底条件扩展（status=running/flaggems_active=true） - run_pipeline.sh: 段2跳过时 SEG2_MIN/SEC/COST 兜底默认值 - run_pipeline.sh: run_eval_if_missing 直接执行评测（校验 _producer+时间戳） - prompt: 禁止内联 evalscope，强制通过 eval_wrapper.py 执行
问题：
- 发布到 ModelScope/HuggingFace 的 README 中，容器启动命令和服务启动命令使用固定模板，与实际迁移过程中使用的命令不一致
- 不同芯片（nvidia/ascend/mthreads）的命令格式不同，应该从迁移流程中获取实际成功执行的命令
修改：
1. prompts/run_pipeline.sh
- 步骤1完成后：要求 Claude 记录实际执行的 docker run 命令到 context.yaml commands.container_run
- 步骤3完成后：要求 Claude 记录实际执行的 vllm serve 命令到 context.yaml commands.serve_start
2. skills/flagos-release/tools/src/config.py
- load_config_from_context() 优先从 context.commands 读取实际命令
- container_run_cmd: 替换镜像为 {{IMAGE}} 占位符，替换模型挂载为 -v /data:/data，移除 workspace 挂载
- serve_start_cmd: 替换模型路径为 /data/<flagrelease_name>，替换端口为 8000
- serve_infer_cmd: 使用实际模型短名替代硬编码的 "flagOS"
- 回退逻辑: commands 字段不存在时使用简化模板
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
低吞吐芯片上单题推理可能超过 5 分钟，原逻辑会误判为卡死。 现在 stall timeout 触发时先检查服务是否存活（进程 + /v1/models API）， 服务正常则重置计时器继续等待，服务无响应才终止进程。
- model_short 改为从 config.model_info.source_of_model_weights 获取 - existing_harbor_image 存在时优先作为 image_target_tag，避免重新生成时间戳
超时后发送 SIGTERM，60 秒内未退出则 SIGKILL，记录为 timeout 状态并跳到下一个模型。
第399行和第471行的 update_context.py --set commands.serve_start 示例中， bash -c "..." 的内层双引号提前关闭了外层 PROMPT_SEG1="..."， 导致后续文本被 shell 当作命令执行，触发 set -e 退出。
- 所有 segment --max-turns 提升到 500，防止慢机器步骤截断 - SKILL.md 服务启动示例对齐 start_service.sh - wait_for_service.sh 失败退出前清理 Triton/FlagGems 编译缓存 - seg2 结束后增加 step7 补充检查兜底
- 段4开始前保存 SEG3_HARBOR_IMAGE（步骤8已推送的镜像地址） - 兜底 Harbor 判定：crash_stopped=true 时跳过重新 commit - MS/HF 兜底前恢复 registry_url 为步骤8原始镜像
修复两个 bug： 1. 性能对比区域增加 V3/V1 optimized ratio 显示（从 context.perf.optimized_ratio_pct 读取） 2. ratio 转换阈值从 < 1 改为 < 2，修复 1.004 被显示为 1.0% 的问题（应为 100.4%） 影响范围： - 文本报告性能对比区域（lines 619-629） - JSON 报告 performance 字段（line 1009） - 算子搜索日志显示（5 处 ratio 转换逻辑） Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- setup_workspace.sh: 工作空间部署修复 - SKILL.md: 综合评测文档更新 - persist_tuning_checkpoint.py: 新增调优检查点持久化工具 - diagnose_failure.py: 日志分析诊断修复 - operator_search.py: 算子搜索修复 - publish.py: 发布阶段修复 - start_service.sh / wait_for_service.sh: 服务启动修复 - tasks.txt: 任务更新
- inspect_env.py：_find_cold_inject_anchors/_cold_inject_single_file 自引入起从未定义，plugin 镜像无 enable() 调用点时走冷注入分支必崩 collect_all（环境检测整体失败）。补全实现：锚点=vllm worker/model_runner.py（import 定位+site-packages 兜底），插入跳过 shebang/docstring、带备份与幂等 - release SKILL.md：发布命令 --plugin-mode 旧别名改为 --version-tag v3（产出 -v3 tag，与 config.py 实际逻辑一致），触发条件 accuracy_ok AND performance_ok 改为仅 accuracy_ok（与编排层门控一致） Co-Authored-By: Claude <noreply@anthropic.com>
问题： - 分支B（gems_tree_plugin）V1基线缺失时，V2=V3同镜像双tag发布 - 原判定逻辑只检查versions.v3.harbor_image，导致误判为未上传 - 实际V3镜像已在步骤8随V2同时上传，但qualified被误判为false 修复： - 更新Claude分析Prompt，新增双tag场景上传判定逻辑 - 支持从versions.v2.harbor_image/-v3 tag/traces/08_release.json判定 - 保持标准场景判定逻辑不变，完全向后兼容 影响： - 避免已达标模型被误报为未达标 - 仅修改Prompt文件，不涉及代码逻辑变更 - 风险：低 文档： - 新增完整设计文档（12KB） - 新增详细更新日志（5.7KB） - 包含测试清单、故障排查、代码位置索引 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 删除日志文件 (*.log, ~1.3MB) - 清理 Python 缓存 (__pycache__, .pytest_cache, *.pyc) - 归档旧文档 CHANGELOG_test_branch.md 到 docs/archive/ - 补充 .gitignore: .pytest_cache/, *.egg-info/, docs/archive/
- 84 行数据 → 82 新条目（Darwin-9B-NEG 双 org 合并、AceInstruct-1.5B 保留已有实测） - aliases 覆盖 org id/小写/下划线变体，查表 + 判定链路冒烟全过 Co-Authored-By: Claude <noreply@anthropic.com>
- run_pipeline.sh/run_batch.sh 支持 --datasets "gpqa_diamond,mmlu,math_500"（默认 gpqa_diamond，零行为变化）
- 每数据集独立评测、独立判定（accuracy_compare_{ds}.json），全部达标才 accuracy_ok=true；调优针对不达标数据集
- fast_gpqa.py 多数据集循环 + 小上下文 max_tokens 防御（max_model_len<=16384 时收敛到一半，防 prompt+output 超限全拒 0 分）
- update_context.py accuracy_ok 校验按 KNOWN_ACC_FILES 白名单逐数据集验证（排除历史 v3 判定产物干扰）
- accuracy_compare.py --metric 标题泛化（GPQA Diamond/MMLU/MATH-500）；SKILL.md/CLAUDE.md 文档同步
Co-Authored-By: Claude <noreply@anthropic.com>
对齐 2026-08 手工修复口径，从生成源头杜绝脏数据： - chip_spec.normalize_vendor 兜底：中文名/括号 display 变体（"英伟达(Nvidia)"、 "沐曦(Metax" 未闭合括号）→ 规范 key；合法输入行为不变 - 新增 canonical_chip_with_flag：vendor-scoped 未命中时跨厂商全局最长关键字 匹配兜底（裸 "C550" → "Metax C550"），多义返回原值 - generate_report：MD 厂商展示改纯英文（英伟达(Nvidia) → Nvidia）；JSON gpu.type/vendor 走规范表（NVIDIA H20-3e → H20-3e、nvidia → Nvidia）； 修复已规范输入被剥 -3e 的 bug（H20-3e → H20）；模型名去空白/尾部斜杠 - chip_spec.yaml：MetaX C550 → Metax C550（与 vendor_en 拼写一致） - 报告文件名厂商取 vendor_en 首字母大写（nvidia_Qwen... → Nvidia_Qwen...， huawei → Ascend，zhenwu → T-Head），run_batch 汇聚同口径 Co-Authored-By: Claude <noreply@anthropic.com>
步骤1捕获的 container_run_cmd 残留基础镜像名，ctx.image.name 替换
{{IMAGE}} 落空时基础镜像原样流进 README，导致用户 pull 发布镜像却
run 基础镜像（线上共 8 个仓库受影响，已单独修复）。
- config.py: 捕获阶段兜底，{{IMAGE}} 未命中时按 harbor 镜像 token 正则替换
- publish.py: 渲染阶段强制 container_run_cmd 镜像与 image_harbor 同源
（与 docker pull 命令同一来源，杜绝不一致）
Co-Authored-By: Claude <noreply@anthropic.com>
发布阶段卡死根因：huggingface.co 直连不可达（CN 环境实测 Network unreachable）时，现代码仍对直连发起 3600s×5 重试链 + SDK 降级， 整轮空耗直到 task_runner 6h 杀任务，hf-mirror 完全没机会被尝试。 修复：上传前在容器内预检各端点联通性（HEAD 请求，30s 超时，与上传 同容器同代理环境），只对可达端点发起上传（按延迟升序），全部不可达 直接快速失败。主上传与 README 更新两处接入。探测明细回显发布日志。 Co-Authored-By: Claude <noreply@anthropic.com>
迁移成本优化：评测题数降采样为默认配置（2026-08-14 用户定稿）。 Hermes-2-Pro-8B 实测（20 种子重采样）：mmlu 40/子集 gap +0.04pt、 95% 带 ±1.54pt；math 200 题 gap -0.42pt、95% 带 ±5.4pt（用户确认 接受该噪声换取成本）；速度 2.5×（生产慢芯片口径每轮 mmlu 46→18min、 math 32→13min，每模型 V1/V2/V3 两数据集约省 2.3h 评测墙钟）。 - fast_gpqa.py：mmlu default_limit 100→40、math_500 500→40（per-subset 语义 = 200 题；--limit 0 仍可全量） - run_pipeline.sh：预算表 mmlu 21600s→7200s、math_500 7200s→3600s， 预算注释与 EVAL_BUDGET_NOTE 文案同步新题数与实测时长 - CLAUDE.md 评测时长预算行、SKILL.md 数据集表、config 注释同步 Co-Authored-By: Claude <noreply@anthropic.com>
约束14 本意澄清（用户定稿）：V1/V2 必须一致的是一卡数/TP，而非同一 批物理卡。原"禁止重新检测 GPU"过严——共享机器上别人的任务会走会来， 允许换物理卡反而能避开新被占的卡。 - 首次启动检测空闲卡 → 选定 N 张 → 锁定卡数（runtime.gpu_count_locked =true），此后 V2/V3/V4 全程 gpu_count/TP 不变 - 后续启动照常重新检测：空闲 ≥ N 时优先复用上次的卡、不足部分补齐； 空闲 < N 时复用上次完整卡列表硬上（卡数优先，宁可共享不变 N） - service-startup SKILL 步骤 2.4 重写为锁卡数流程；eval/perf SKILL 的 V1/V2 强制规则同步（CUDA_VISIBLE_DEVICES 允许换、TP_SIZE 锁定） - context.template.yaml 新增 gpu_count_locked 字段；CLAUDE.md 约束14 与自动决策规则同步新语义 Co-Authored-By: Claude <noreply@anthropic.com>
用户定稿调整：40/子集仍偏多，降到 20/子集 = 1140 题。 实测（20 种子重采样）：gap -0.4pt、95% 带 ±2.05pt，速度再快 2× （H20 实测 ~56s/轮，生产慢芯片口径每轮 ~9min）。 预算表 mmlu max-timeout 7200s→3600s；CLAUDE.md/SKILL.md/config 注释同步。math_500 维持 200 题不变。 Co-Authored-By: Claude <noreply@anthropic.com>
用户指正：降采样同步收紧上限会在国产慢卡上误杀。评测 timeout 应 按 gpqa 的宽松逻辑设防挂死上限，题数降采样省的是时间，上限不必 跟着收紧。 - mmlu max-timeout 3600s→21600s（1140 题慢 10 倍 9min，上限给到 30× 慢卡也不误杀） - math_500 max-timeout 3600s→7200s - CLAUDE.md/SKILL.md 预算说明同步："timeout 是防挂死上限而非性能 预期，国产慢卡（10×~30×）不得误杀" Co-Authored-By: Claude <noreply@anthropic.com>
V3(步骤11) 和 V4(减算子终检) 之前只按主数据集(第一个)判精度，与 V2 步骤4 的'全部 --datasets 逐个独立判定'口径不一致，多数据集时会漏判非主 数据集的精度退化。 - operator_reduction.py: 新增 --accuracy-datasets 'ds:base,...' 与 run_accuracy_guard_multi()，对每个数据集逐个评测、逐个算 rel_drop， 全部达标才通过；无基线的数据集跳过判定不否定 V4。--accuracy-baseline 单参数保留向后兼容。state/result 记录 accuracy_details/accuracy_datasets。 - run_pipeline.sh: V3 段新增 V3_DATASET_SPEC 逐数据集任务规格；V4 段新增 V4_ACC_DATASETS 逐数据集基线映射并传入 --accuracy-datasets。 - CLAUDE.md / SKILL.md: 口径文案同步。 验证: py_compile + argparse + 多数据集聚合逻辑单测(掉分判负/全达标/无基线 未验证/单数据集向后兼容) 均通过，并在 granite 容器真实 Python 3.12 复验。
diagnose_ops.py 的启发式提取过去只要算子名不在 known_ops 白名单就直接 丢弃，导致版本新增/命名变体的算子哪怕在日志里出现也抓不到，crashed_ops 返回空 → '连续 2 轮定位不到新算子' 提前成立 → 把本可禁用救回的模型误判 为不可恢复。 - extract_ops_from_text 新增 return_candidates：正则命中但白名单外的名字 收进低置信 candidate_ops(不再丢弃)；xxx_func_tensor_scalar 等强命名仍 升为高置信。analyze_crash_log 输出 candidate_ops，_crash_suggestion 在 无高置信算子但有候选时给出'逐个/二分禁用候选'的可操作路径。 - triton kernel 正则补 IGNORECASE：真实 vLLM 日志中 'Triton compilation failed for xxx_kernel' 的 T 大写，旧正则区分大小写导致 kernel 名在最常见 日志格式下根本抓不到——此缺陷在 granite 容器真实日志验证时才暴露。 - 编排层(run_pipeline.sh/CLAUDE.md/service-startup/operator-replacement SKILL): 不可恢复闸门口径统一收紧为 crashed_ops 与 candidate_ops 均空且 人工分析无果，candidate_ops 必须先逐个试过。 验证: granite 容器真实 Python3.12 + 真实 ops_list.json 白名单——混合场景 (add 高置信/exotic_fused_gate 候选)、纯候选误判场景(crashed_ops 空但给出 可操作候选)、clean 日志无误报，均通过。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 算子列表: collect() 补读 flaggems_enable_oplist.txt / ops_list.json, V2/V3 算子来源链补入,修复实际有算子却显示无数据 - 精度对比: 读 accuracy_compare*.json 按 rel_drop 格式渲染,V1 无独立分时 回退 NV 基线;补小样本噪声容忍(差≤2题判达标),消除与结论闸门的矛盾 - V3 精度: 补读 gpqa_v3_plugin.json,修复 V3 精度结果漏读 - 字段格式: 基本信息厂商改中文(英文);空值/None 统一兜底为 -; 显存整数化;卡数 0 视为无效 - 一致性: 精度表与性能表算子数统一到去重白名单同源 验证: granite + 5 个 NV 容器端到端通过,跨厂商函数单元验证通过
问题：gemma 等模型的 generation_config.json 声明 do_sample=true 但
不含数值型 temperature，现有白名单循环抓不到采样参数，导致回退到
temperature=0.0 贪心解码，小模型在选择题上确定性循环到 max_tokens，
答案无法解析、精度崩溃（实测 mmlu 掉到 33.25%）。
修复：在白名单循环后增加 do_sample 补偿逻辑——当模型声明 do_sample=true
且未显式配置 temperature 时，补采样默认值 temperature=0.7 / top_p=0.95 /
top_k=64，让解码模式回到模型要求的采样，而不是掉进贪心。
边界保护：
- 仅当 temperature 不在 applied（模型未显式配置）时才补，尊重模型
配置里明确写的 temperature=0 / 0.9 等值
- gc.get('do_sample') is True 严格检查布尔型，不会被 do_sample=1 误触发
- thinking 模型默认 0.6 != 0.0，修复条件不满足、不干扰
- top_p/top_k 同样检查 applied，不覆盖模型显式配置
已通过 11 个边界用例验证，包括 gemma 场景、显式配置、thinking 模型、
do_sample=false/缺失/数值型等。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
在宿主机和容器内模型搜索路径列表前端增加 /data1 和 /data2， 优先级排序为 /data → /data1 → /data2，覆盖多盘挂载场景。 变更： - DEFAULT_SEARCH_PATHS（宿主机）: /data, /data1, /data2, /nfs, ... - CONTAINER_SEARCH_PATHS（容器内）: /data, /data1, /data2, /models, ... - 同步更新 CLAUDE.md 自动决策规则表 适用场景：服务器将多块硬盘分别挂载到 /data、/data1、/data2， 模型权重可能分散在任一盘，搜索机制现在能覆盖所有三个路径。
在宿主机和容器内模型搜索路径列表最前端增加 /mnt/data/， 作为最高优先级搜索目录。 变更： - DEFAULT_SEARCH_PATHS（宿主机）: /mnt/data/, /data, /data1, /data2, ... - CONTAINER_SEARCH_PATHS（容器内）: /mnt/data/, /data, /data1, /data2, ... - 同步更新 CLAUDE.md 自动决策规则表 适用场景：/mnt/data/ 作为统一挂载点存放模型权重， 搜索机制现在能优先从该路径查找。
npu-smi 在部分 910 环境(如 SOC=ascend910_9391)报裸 Ascend910,
不带 B/C 后缀,原 chip_spec 仅有 910B/910C,导致 canonical_chip
hit=False → 型号未归一、报告 card_model 落未命中分支。
新增 { display: 910, match: [ascend910, 910] } 作最短兜底。
_chips_candidates 按 match 长度降序,ascend910b(10)/910c/910b 仍
优先命中,裸 910(3) 不影响 910B/910C 归一;全厂商仅 ascend 含
910 子串,跨厂商全局兜底无多义。
--pid=host 下 start_service.sh 的 pkill -f 'vllm serve' 会误杀 argv 含该字样的宿主机 claude 进程(exit137)，从两处 docker run 模板中移除该参数
根因：detect_gpu.py 的 GPU_VENDORS/_FREE_QUERY_CMDS 用非规范名 tianshu 作为天数注册键，而全项目规范名是 iluvatar（chip_spec.yaml aliases 收敛、 chip_detector.py _normalize_vendor_for_naming 归一、context.yaml 实际存 iluvatar）。线上调用链（service-startup SKILL 步骤2.4）从 context 读 gpu.vendor=iluvatar 传给 --check-free --vendor iluvatar，而 _FREE_QUERY_CMDS 里既无 iluvatar 也无 tianshu 查询命令 → 静默返回空 → total=0 → GPU 空闲 检测失效 → 从 GPU 0 盲选 → 撞上前序未释放进程 → CUDA OOM 连锁失败。 修复（与全项目命名规范对齐，消除 detect_gpu.py 唯一的 tianshu 异类）： - GPU_VENDORS: 注册名 tianshu → iluvatar - _FREE_QUERY_CMDS: 新增 iluvatar 条目，ixsmi 标准 CSV query（含 free 列， 天数真机实测支持 nvidia-smi 风格 --query-gpu=...--format=csv） - has_free 判断加入 iluvatar（ixsmi CSV 输出含真实 free 列，直接读取而非 total-used 估算） - 新增 _VENDOR_ALIASES（tianshu → iluvatar）并在 check_gpu_free 入口做 归一化，.lower() 容错大小写，兼容历史数据传 tianshu/大写的情况 - VENDOR_KEYWORDS 补 iluvatar 名称推断（bi-v150/bi-v200/tg-v200 等）， 防 ixsmi 命令探测失败时走名称推断推成 unknown - context.template.yaml 注释厂商列表 tianshu → iluvatar 验证（本机模拟真实调用路径，无 ixsmi 环境）： - 别名归一化：iluvatar/tianshu/大写 均正确收敛到 iluvatar - _FREE_QUERY_CMDS 查表：线上实际传的 iluvatar 正确命中 - CSV 解析 + busy/free 分类：16 卡识别，18GB 占用判 BUSY、68MiB 开销判 FREE - 名称推断 fallback：BI-V150/BI-V200/TG-V200 均推为 iluvatar 天数机器此前已在工作区本地验证过等价功能（--vendor iluvatar → 16 free/ 16 total），本提交将修复以规范对齐方式落入 git，供所有机器 pull 共享。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 新增 shared/probe_versions.py：以 pip list 为权威源现场探测组件版本， 不依赖 context 的 __version__ 采集值（源码装/中途装/漏项都能抓到）， semver 口径对齐 get_image_name.sh；支持 --field/--ops/--output - generate_report.py：collect 现场调探测，基本信息版本字段现场优先、 context 兜底，统一过滤 installed/True 占位符；json 报告新增 environment.versions 段 - setup_workspace.sh：挂载 probe_versions.py 到部署清单 granite-4.0-micro 容器实测：plugin-FL installed→0.2.0、flagtree 采集漏项→0.6.0；脚本缺失时优雅降级不崩
- 抽出通用 _run_probe() 探测脚本执行器，probe_versions/detect_gpu 共用 - 新增 _probe_live_gpu()：调 detect_gpu.py 抓厂商/型号/物理卡数/单卡显存， name→type 字段映射为报告口径 - gpu 定义处现场值覆盖 context（仅覆盖非空值），下游 MD/性能表/summary 统一受益 - JSON 报告 gpu 段 + 新增 _gpu_field() 走同口径 - 卡数按物理卡数取现场值（用户定稿）；detect_gpu 已在部署清单，无需改 setup granite-4.0-micro 实测：显存 context 缺失→现场 140GB；脚本缺失时回退 context 不崩
- fast_gpqa.py 注册 mm_star:多模态4选一MCQ,6子集×250=全量1500题 - 多模态专用 max_tokens 硬上限4096(防复读死循环吃满窗口)+prompt预留16K+并发对半下调 - 采样参数抽取 _resolve_model_dir():优先 --model-name 本地目录读 generation_config.json,context.yaml兜底 - default_limit=0 默认全量(采样偏最难子集显著偏低:300题44.67% vs 全量62.6%) - 文本数据集(gpqa/mmlu/math_500)路径逐行不变,改动全部门控在 is_multimodal 之后 - SKILL.md/CLAUDE.md 同步 mm_star 数据集说明/预算/图像输入门控 实测 Qwen3-VL-4B-Instruct 全量1500题 62.6%,并发8约15分钟
- 根因：image_harbor 取到 N/A 时 {{IMAGE}} 替换整段被跳过，占位符原样漏进 README
- 改为多级兜底解析镜像名：image_harbor → image_harbor_path → harbor_path
→ existing_harbor_image → image_target_tag，任一非空即用
- 彻底解析不到时明确 raise 阻断，拒绝写出含 {{IMAGE}} 的坏 README（不静默产出）
- 4 场景单测通过：正常/N/A兜底/全空阻断/harbor名替换
Populate mm_star (MMStar, val 1500-question) reference accuracy for 38 VLM models spanning 4B~78B (Qwen3-VL, InternVL2.5/3/3.5, Molmo2, MiniCPM-V/o, Ovis2, SAGE-MM, CapRL). Each entry carries the metrics.mm_star score plus aliases covering org-prefixed, lowercase, and underscore/hyphen variants so accuracy_compare.py --metric mm_star resolves both HF-style and plain model names. Enables NV-baseline accuracy gating (relative drop <=5%) for multimodal runs; scores are external leaderboard references pending internal NV measurement. Verified: YAML valid, 38 mm_star metrics present, all lookups hit, no normalized alias collisions across 253 models.
Add gpqa_diamond/mmlu/math_500 reference scores for 123 language models from external eval table; fill Hunyuan-7B-Instruct (mmlu/math_500) and overwrite AceInstruct-1.5B mmlu/math_500 with the reference-table values. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
accuracy_compare.py --nv-baseline 查表默认路径为容器内 /flagos-workspace/shared/nv_baseline.yaml， 但此文件此前从无任何脚本部署，靠 Agent 进入 NV 模式时临时 docker cp——漏 cp 会「缺基线」， 且该表高频更新（近期扩至 376 条），旧容器易带过期表导致新模型查表 MISS(exit 3)。 在 setup_workspace.sh 紧贴 context.yaml 初始化处新增平行部署块（3.6 节）： 每次流程启动（步骤1）无条件 docker cp 仓库 shared/nv_baseline.yaml 到容器默认路径， 父目录由第212行先建、docker cp 幂等覆盖保证新鲜，文件缺失只 warn 不 fail。 run_pipeline.sh / accuracy_compare.py / V4 终检均无需改动，纯增量零回归。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…处理崩溃误判失败
detect_runaway 第370行 (text or '').strip() 假设 content 为 str，但 reasoning 模型
(Qwen3/MiMo/QwQ/DeepSeek-R1 等) 的 message.content 是结构化 block 列表
([{type:reasoning,reasoning:...},{type:text,text:...}])。list 传入 .strip() 抛
AttributeError，且第447行调用仅被 except OSError 包裹抓不住、第1000行(Step 8.5)
无 try 兜底 → 崩在写 report(Step 9)之前 → 退出码1 → 编排层误判评测失败，
而 evalscope 早已完成判分落盘、分数本可救回。
新增 _content_to_text() 归一化：list 时拼接 reasoning/text/content 三键(复读主要
发生在长推理链，只取答案会漏检 CoT 复读)，非 str/list 一律 str() 兜底。
生产数据验证：51 预测文件中 7 个为 list 型 content(Qwen3-0.6B/MiMo-7B-RL 等)。
修复后 Qwen3-0.6B 全量 198 题跑通并检出 7 题 runaway(改前必崩)，str 路径
(Qwen3.5-0.8B 66题) 无回归，7 个 list 目录回归 0 崩溃。
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
概述
本 PR 汇集 52 个提交,对 FlagOS 模型迁移流水线做了一轮系统性重构,覆盖编排架构、
版本发布策略、防错闸门、评测口径、报告生成与通知体系,并批量补充 NV 精度基线数据。
主要变更
编排架构
镜像不重装只 verify。
V4 减算子算法重写;V2/V3/V4 多版本镜像自动产出。
发布前精度终检,防止流程在未达标时"自我判定通过"。
发布与门控
评测与调优
报告生成(shared/generate_report.py)
不再凭 context 残留镜像 tag 字符串误判;报告顶部加「迁移结果 ✅/❌」醒目行。
GPU 型号归一化/时间格式/plugin 真实版本/文件命名)。
通知与批量汇总(新增)
数据与文档