CodeFuse-VLM 多任务微调跑到一半loss 发散或者某个子任务不收敛是常见现象。我在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建了 TaoToken 的 Key把 Codex 的 Base URL 指向 https://taotoken.net/api让 AI 帮我读 shscripts/finetune_multinode.sh从脚本和数据配比里找原因。CodeFuse-VLM 框架本身就是为了让多模态多任务微调能同时跑起来原文里也写明要解决任务间数据量不平衡、难易不一和收敛速度不一致的问题复现时 finetune 脚本里每个任务的 loss 权重、每个数据集采样多少样本都会直接影响最终能不能收敛。与其翻半天 training log不如把脚本和数据集表格一起丢给 Codex让它给出可执行的修改方案。1. 复现 CodeFuse-VLM 多任务微调loss 发散先别动学习率1.1 多任务微调的典型症状一个任务把另一个任务的 loss 带偏CodeFuse-VLM 是一个可自由组合视觉编码器和语言底座的多模态多任务微调框架视觉侧可以接 CLIP、Chinese CLIP、Qwen Clip语言侧可以接 Vicuna、LLAMA-2、Qwen通过配置文件拼出适合自己数据的模型结构。多任务同时微调时每个数据集被当作一个独立训练任务共享同一个 backbone 和大部分参数只有任务头或部分模块独立更新。这种结构的好处是模态对齐和指令理解能一起学坏处是任务之间会互相干扰OCR 类任务样本多、loss 下降快复杂推理类任务样本少、loss 下降慢前者的梯度很容易把后者的学习方向带偏。复现时最常见的现象是整体 loss 在前几百步下降得不错接着某个子任务的验证指标开始停滞再往后训练 loss 反而反弹。这不是模型容量不够更多是 loss 组合和数据采样比例的问题。CodeFuse-VLM 原文提到通过结合多种损失函数来缓解多任务干扰但那属于框架能力具体到一次复现损失函数的权重、各数据集每轮采样多少样本都要在 finetune_multinode.sh 里实际配置。此时先不要急着调学习率或换更大的底座把脚本里每个任务对应的 loss 系数和数据路径列出来比盲目重训更有效。1.2 两个脚本入口排障先看 finetune_multinode.sh原文给出的训练入口有两个。shscripts/pretrain_multinode.sh 负责预训练阶段的模态对齐它把 synthdog-en、synthdog-zh、CC3M、SBU、Visual Genome 等数据分别当成 OCR、Image Caption、VQA、Ref Grounding 等任务来训练 cross attention 模块shscripts/finetune_multinode.sh 负责指令微调阶段用 LLAVA-1.5 的指令数据把大语言模型和视觉特征进一步对齐。启动命令形式上都是多机训练脚本区别集中在数据集列表、训练轮数和 loss 组合。排查收敛问题时优先看 finetune_multinode.sh大多数不收敛现象都发生在指令微调阶段因为这个阶段的任务类型更杂OCR_VQA、GQA、Visual Genome、COCO、Text-VQA有的要求详细描述有的要求复杂推理有的要求区域定位。用编辑器打开脚本后重点核对三处每个 dataset 对应的 loss 权重、每个数据集的采样上限、优化器是否对不同任务用了同一套学习率。这三项就是之后让 Codex 分析的主要对象提前在脚本里定位好行号提问时会更精确。2. 给 Codex 配上 TaoToken 通道拿 Key 与 config.toml2.1 打开 TaoToken 控制台创建 API Key要让 Codex 稳定回复先把模型通道配通。打开 TaoToken 注册登录进入控制台创建一个 API Key。Key 是一段以 sk- 开头的字符串创建后先复制保存后续只通过环境变量引用不要写进任何会被提交的脚本或配置文件。模型 ID 不要在键盘上凭记忆敲统一以 TaoToken 模型广场当时列出的名称为准有些底座的版本号会随上游更新旧笔记里的 ID 可能已经失效。如果之前配过其他兼容通道先把旧的 base_url 相关配置清掉再写 TaoToken避免 Codex 请求发到错误地址。TaoToken 在这里只承担统一 API 通道的角色不替代训练脚本也不连接训练服务器。2.2 修改 ~/.codex/config.toml 的 model_providerCodex CLI 把模型提供方配置放在 ~/.codex/config.toml。打开这个文件在顶层设置 model 和 model_provider再在文件底部新增一个 provider 块。model 字段不能乱填必须以 TaoToken 模型广场上实际存在的模型 ID 为准base_url 直接写接口地址 https://taotoken.net/api不要按 OpenAI 官网的手感补 /v1否则 Codex 组装请求时会多拼一段路径导致路由错误。以下配置可以直接保存model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY设置完 config.toml 后还需要把 Key 放进环境变量。export 命令里的变量名要和上方 provider 块中 env_key 的值保持一致Codex 启动时会从这个环境变量读取密钥export TAOTOKEN_API_KEYYOUR_API_KEY如果你之前配过其他服务先确认 OPENAI_API_KEY、ANTHROPIC_API_KEY 这类旧变量没有残留在当前终端残留变量可能把请求引到错误地址。验证通道是否打通执行一句 codex 的简单提问比如请它读取当前目录下的 README 并总结返回正常结果后再让它读 shscripts/finetune_multinode.sh。3. 把 CodeFuse-VLM 的数据配比交给 Codex 做交叉核对3.1 预训练数据配比模态对齐阶段也要查预训练阶段主要做模态对齐但它的数据配比会直接影响之后 finetune 的收敛起点。原文公开的预训练数据集大致包括英文 OCR 50 万、中文 OCR 50 万、CC3M 下采样 55 万、SBU 85 万、Visual Genome 的 VQA 50 万、Region Description 50 万、Object Caption with Grounding 50 万、OCR_VQA 50 万。把这张表整理成给 Codex 的上下文它就能判断OCR 类任务合计约 150 万Caption 类任务约 140 万VQA 类约 100 万整体上任务间样本量差距并不极端。如果预训练时某个任务的 loss 不降多半不是数据量问题而是 loss 系数没对齐或者该任务的学习率被共享参数拖累。预训练阶段的另一个检查点是 cross attention 模块的训练方式。原文说得很清楚预训练阶段用多任务方式训练模态对齐模块每个数据集对应一个训练任务。Codex 分析 pretrain_multinode.sh 时会关注任务数是否过多、是否有两个任务的数据高度重叠、某个任务的梯度是否在每次迭代中都占据主导地位。这些判断依赖数据表格所以要先把上面的数据描述放进提问里不要让 Codex 只盯着脚本代码猜。3.2 指令微调数据配比不收敛高发区指令微调阶段的不收敛问题数据配比嫌疑更大。原文使用的 LLAVA-1.5 指令数据集共 65 万样本细分下来是 OCR_VQA 7 万、GQA 8 万、Visual Genome 10 万、COCO 37 万、Text-VQA 3 万各任务占比大致如下子数据集原文公开样本量占比COCO37 万约 57%Visual Genome10 万约 15%GQA8 万约 12%OCR_VQA7 万约 11%Text-VQA3 万不到 5%COCO 占了近六成Text-VQA 只有不到 5%。如果 finetune_multinode.sh 里按数据集的原始大小直接采样Text-VQA 每轮只能被抽到很少的 batch它的 loss 会被 COCO 的详细描述任务持续压住表现就是该子任务长期不收敛。这正好对得上原文总结的三个挑战数据量不平衡是 COCO 和 Text-VQA 的差距难易不一是简单 OCR 任务和复杂推理任务的差距收敛速度不一致是先收敛任务继续贡献梯度、干扰难任务。把这三句话展开描述给 Codex它给出的建议才不会是一段通用调参话术。3.3 一个能直接粘贴给 Codex 的提问模板以下是我整理给 Codex 的提问内容在终端里直接粘贴即可脚本路径替换成你的实际路径请阅读本机 shscripts/finetune_multinode.sh 和 shscripts/pretrain_multinode.sh。 背景CodeFuse-VLM 多任务微调指令微调阶段 loss 到 2000 步后发散 其中 Text-VQA 子任务几乎不收敛。训练数据配比是 OCR_VQA 7 万、 GQA 8 万、Visual Genome 10 万、COCO 37 万、Text-VQA 3 万。 请帮我检查 1. finetune_multinode.sh 里每个任务对应的 loss 权重是否按数据量做了反比缩放 2. 采样器是否支持按任务加权当前配置是否会把 Text-VQA 的样本稀释 3. 如果调整最小改动是改 loss 权重还是改数据采样比例 4. 有没有必要对先收敛的 OCR 任务提前冻结或者降低学习率。 请给出可以落到 finetune_multinode.sh 的具体修改不要只说通用调参思路。提示Codex 分析的是你贴出的脚本内容和日志文本不会连接你的训练机去执行命令。改完 finetune_multinode.sh 后请由你在训练机上重新启动训练再把新的日志贴回对话继续排查。4. 按 Codex 建议改参数回训练机重新验证4.1 最小改动优先先采样比例后 loss 权重多任务微调收敛问题的最小改动通常是调整采样比例而不是重写 loss。Codex 给出的建议如果包含「将 Text-VQA 的采样倍数提高」「给 OCR_VQA 的 loss 增加衰减」「在训练后半段降低简单任务的学习率」都属于可落地的方向。拿到建议后不要一次性改多个参数逐项验证先只调数据采样看子任务 loss 是否开始下降两个 epoch 后没有效果再动 loss 权重。每次修改后用相同的评测集做对比避免把不同因素的影响混在一起。训练脚本的修改必须由你在训练机上完成。Codex 通过 TaoToken 通道返回的是修改建议和改动后的脚本片段你可以把片段保存到本地再对照原文件确认差异确保没有破坏多机训练的分布式配置。比较稳妥的做法是先把原文件复制一份例如 finetune_multinode.bak.sh改出问题随时能回滚。4.2 用子任务 loss 和公开 benchmark 双线判断收敛判断是否收敛不能只看整体 loss。把文本生成 loss、视觉 grounding loss、OCR loss 分开记录单独画曲线整体 loss 降但子任务不降通常是数据采样问题整体 loss 和子任务 loss 都在震荡则优先怀疑 loss 权重。训练日志里如果出现某个任务长时间不更新检查该任务对应的 loss 项是否为 0这往往是数据加载阶段就把该任务的 batch 过滤掉了。对照基准方面原文公开了 CodeFuse-VLM-14B 在 MMBench 中英文榜单上的排名高于 Qwen-VL。这个结果可以作为复现是否成功的参考线如果按调参后的配置重训模型在 MMBench_CN 上能接近或超过原文公布的分数说明训练配置没有系统性错误如果差距明显则继续回到脚本核对数据配比而不是怀疑硬件。4.3 验证时打开控制台对一下这次调用跑通 Codex 后回到 TaoToken 模型对话 用同一把 Key 发一条测试消息确认请求确实走到了 https://taotoken.net/api顺便核对这次排障过程中 Codex 的调用有没有被记录。若后面要长时间反复让 Codex 分析训练日志可以在 Coding Plan 查看套餐余量需要新增 Key 或查看用量明细直接进控制台 API Keys 页面操作。5. Base URL、模型 ID、Key填错位置各有各的报错5.1 base_url 多写 /v1Codex 返回路由错误Codex 的 config.toml 里 base_url 填的是 https://taotoken.net/api末尾没有 /v1。如果你之前使用过 OpenAI 官方接口习惯性写成 https://taotoken.net/api/v1Codex 组装请求时会得到路由错误或 404。TaoToken 作为统一接入通道接口地址以 https://taotoken.net/api 为准这个地址和官网落地页 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 不要混用前者填进工具后者用来注册、创建 Key、看用量。如果确认 base_url 没问题但 Codex 仍提示接口格式不兼容在 provider 块里加上 wire_api chat 再试。5.2 模型 ID 不在模型广场Codex 直接报 model not foundconfig.toml 中的 model 字段必须写模型广场上真实存在的模型 ID。TaoToken 模型广场会随上游底座更新调整列表不要用手头旧的笔记随便填一个版本号。核对方式打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end进模型广场搜索对应名称复制页面上给出的 ID粘贴到 config.toml。如果配置的是多模态模型确认该模型 ID 是否支持 Codex 所需的接口格式不支持时换成广场列出的替代模型再重新发起一次简单提问。模型 ID 错误通常会在第一次请求时就报出来不会等到长对话中途。5.3 Key 无效回到控制台核对先看用量再看 Key 状态Codex 通过 env_key 指定的变量名读取 API Key。如果环境变量设置后仍然 401先确认当前终端里 TAOTOKEN_API_KEY 是否存在以及是否和 config.toml 中 env_key 的大小写完全一致。不要同时保留旧的 OPENAI_API_KEY 和 TAOTOKEN_API_KEY两个变量都存在时部分版本 Codex 可能优先读取旧变量把请求发到旧地址。清掉旧变量重新 export TAOTOKEN_API_KEYYOUR_API_KEY再跑一次简单提问验证。如果确认环境变量无误仍然 401回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 检查 Key 状态或直接在 API Keys 控制台 新建一把 Key 重试。