最近大模型后训练、VLM 推理、合成数据这几个词频繁出现在一起。很多人手里已经有基础视觉语言模型也能跑通微调但一到真实项目就卡住。比如智慧城市项目里监控图像中的夜晚小目标漏检严重模型输出一会儿中文一会儿英文JSON 格式还不稳定农业机器人项目里真实果园的光照、遮挡、果叶重叠变化太大靠人工采集数据又慢又贵。这些问题的共同点是没有把“后训练”当成一套有数据、有评测、有回滚的工程流程而只是当成一次脚本运行。这篇文章围绕 Cosmos 3 展开想拆解一条从智慧城市 VLM 推理到农业机器人合成数据生成的实战路径。先给一个明确判断。Cosmos 3 这类世界模型/合成数据方案的价值不在于“生成图片多逼真”而在于“可以控制生成什么场景、出现什么目标、附带什么标签”。后训练的价值也不是让模型记住更多知识而是让模型学会按业务格式输出、按业务语义理解。把这两点连起来才是物理 AI 项目真正能落地的原因。这篇文章不会把某个平台的官方接口当黑盒吹捧也不会只讲理论。我会聚焦在一条可以复用的工程链路上如何定义场景如何生成双语合成数据如何训练 VLM如何推理验证以及从智慧城市迁移到农业机器人时需要注意什么。阅读时可以把手上的项目替换到对应场景中操作思路是一致的。1. 这篇文章真正要解决的问题先说一个观察现在很多人提到“后训练”第一反应是找一个开源框架把数据集扔进去跑几个 epoch 就算完了。但在实际项目里模型的最终效果往往不是死在训练参数上而是死在数据分布和业务约束上。基础 VLM 在通用 benchmark 上能拿到不错的结果一旦进入垂直场景问题会立刻暴露输出格式不稳定、长尾事件没见过、业务概念没有对齐。这些都不是单靠调学习率能解决的。智慧城市就是一个典型场景。摄像头采集的监控图像数量很大但真正需要关注的异常事件往往是少数例如夜晚横穿马路、交通事故、违规停车、井盖缺失。人工标注这些长尾事件成本高而且不同标注员对同一事件的描述可能不一致。如果只靠真实数据做后训练模型对高频场景会过拟合对低频异常依然漏报。这时候合成数据就有优势可以精确控制异常事件的出现频率让模型在训练阶段就能见到足够多的小概率场景。农业机器人场景的问题正好相反。果园里的数据不是不够多而是分布太散。同一颗苹果树上午、中午、傍晚的光照完全不同机械臂从不同角度拍摄果实遮挡比例也会变化。机器人需要识别果实、判断成熟度、区分果子和叶子甚至要辨识杂草。真实采集数据要覆盖所有光照、角度、品种成本非常惊人。合成数据可以批量生成这些变量组合并且自动携带准确标注这正是 Cosmos 3 这类方案能派上用场的核心原因。因此这篇文章真正要解决的不是“如何训练一个 VLM”而是“如何用合成数据把 VLM 后训练做成一个可持续迭代的工程闭环”。适合读这篇文章的读者包括正在做视觉语言模型微调但效果不稳定的人做智慧城市、工业视觉、农业机器人等物理 AI 项目的工程师以及想了解大模型后训练和合成数据工作流如何结合的算法同学。2. Cosmos 3 是什么为什么后训练才是落地关键先说明一个前提我不把 Cosmos 3 当做一个已经定型的开源项目来介绍而是把它作为“世界模型 合成数据 后训练”这条技术路线的一个工程代号。不同团队手里的 Cosmos 3 可能差异很大生成接口也可能完全不同一旦绑定某个具体版本反而学不到可复用的东西。因此下面先拆开三个基础概念再解释它们为什么必须绑定在一起。2.1 先分清三个概念VLM、后训练、合成数据VLMVision-Language Model视觉语言模型是能同时处理图像和文本的模型。它输入一张图片加上一句问题输出自然语言描述或结构化结果。例如输入一张交通路口照片模型可以回答“有几辆车、是否有行人闯红灯”也可以直接返回 JSON 对象。注意“VLM 推理”这个说法在项目里通常不是指数学推理而是指基于视觉输入做业务判断。这部分工作流能不能稳定取决于模型是否见过足够多符合业务格式的样本。后训练post-training指的是预训练完成之后的模型适配阶段包括指令微调、偏好优化、蒸馏等。它不改变模型的底层能力而是改变模型对提示词、输出格式和任务语义的响应方式。大模型后训练在真实项目中的地位甚至比预训练选择更重要因为基础模型大家都差不多适配做得好不好直接决定了业务效果。很多人误以为后训练是“再学一遍知识”其实它更像“给一个聪明但没有工作经验的员工做入职培训”。合成数据是使用程序化渲染、世界模型或生成式模型产生的数据而不是从真实设备采集。它与数据增强的区别是数据增强基于已有真实样本做变换合成数据则可以从场景参数开始生成全新的样本能精确控制目标位置、光照、天气和标注。两者可以配合使用但合成数据在长尾场景覆盖上更有优势。2.2 为什么“能推理”不等于“能落地”一个开源 VLM 在通用评测集上表现不错放到智慧城市监控项目里往往会出三件事。第一输出格式不稳定同一个问题问十次模型有时输出自然语言有时输出 Markdown有时又夹带 JSON。第二长尾场景没覆盖基础模型可能见过“车辆”和“行人”但不理解“井盖缺失”“电动车进电梯”这类业务事件。第三垂直概念没对齐业务上需要输出“成熟度三级”或“遮挡率”基础模型根本没有这些概念。农业机器人同理。模型的视觉特征可能见过草莓但“草莓成熟度三级”这类业务标签没有学过。合成数据的意义就在这里可以直接把业务标签渲染进图像让后训练把标签和视觉特征绑定起来。换句话说合成数据承担的是“培训教材”的角色后训练承担的是“培训过程”的角色VLM 是被培训的员工缺了任何一环最后的效果都不稳定。2.3 双语不是翻译问题而是对齐问题标题里的“双语”不是简单翻译。真正的双语后训练要求中文问题、英文问题都能触发同样的视觉理解结果模型输出中文或英文时对象标签和数量要保持一致。很多团队先训练中文数据再单独接英文 prompt结果模型在两种语言下对同一张图的检测结果不一致甚至英语描述里多了一个目标。更好的做法是在合成数据阶段同时生成双语标注让训练样本天然带有对齐关系。这一点的工程含义是合成数据生成模板里中英文描述必须来自同一组标注对象不能分别随机生成。否则模型会学到错误的关联例如中文描述里有“行人”英文描述里却没有。后面我会在第 5 节给出一个具体的双语 JSONL 构造示例。3. 整体架构与工作流设计3.1 一条主线任何物理 AI 项目的后训练都可以归纳成一条主线场景定义 - 合成数据生成 - 数据清洗与标注 - VLM 后训练 - 推理部署 - 效果评测 - badcase 回流。这条链路是闭环的因为评测阶段发现的失败案例必须能回到数据生成阶段变成下一轮合成数据的输入。如果中间任何一步断开项目就会退化成“一次性微调”无法持续优化。Cosmos 3 这类方案带来的变化主要体现在场景定义和合成数据生成这两个环节。以前做一个智慧城市模型需要先凑真实数据、再找标注团队现在可以先用场景模板生成一批带标签数据让模型快速跑通再逐步加入真实数据校正分布。这不是替代人工标注而是把人工标注从“生产主力”变成“质量抽检”。3.2 智慧城市场景怎么拆智慧城市项目的输入通常是路口或街道监控图像任务是检测车辆、行人、交通设施并输出事件描述。难点在于夜间弱光、逆光、小目标、目标遮挡。合成数据生成时要模拟不同天气、不同时段、不同相机高度最好还要模拟监控摄像头特有的广角畸变和低分辨率效果。这样生成出来的数据才能让后训练模型适应真实监控画质。事件描述也是智慧城市 VLM 推理的关键。模型不仅要输出“画面中有几辆车”还要输出“一辆电动车在红灯时横穿路口”这类结构化事件。事件标签需要和检测结果联动否则模型很容易“看到目标但说不出事件”。3.3 农业机器人场景怎么拆农业机器人项目的输入来自果园巡检相机或采摘机械臂上的视觉传感器任务是检测果实并判断成熟度、区分果与叶、识别杂草。难点是光照剧烈变化、果叶重叠、同品种形态差异大。合成数据生成时要重点做域随机化改变地面材质、叶片密度、果实颜色、相机角度、光照方向。域随机化越充分模型迁移到真实果园时的适应性越好。农业机器人对输出格式的要求往往更严格因为机械臂执行动作需要精确的坐标和置信度。模型输出不能是一段自由文本而应该是结构化的检测框列表。因此后训练阶段要在 prompt 和训练数据里反复强调“只输出 JSON不要输出多余解释”。3.4 为什么要先跑通一个场景我不建议一上来就同时做智慧城市和农业机器人两个场景。更稳妥的顺序是先选一个相对标准、反馈快的场景跑通闭环再迁移到另一个场景。城市监控场景相对标准化公开数据多失败反馈快农业机器人场景更开放长尾更严重。先用智慧城市验证数据生成、后训练、推理评测这套流程再迁移到农业机器人是成本更低也更容易排查问题的做法。4. 环境准备与基础配置4.1 硬件与软件建议操作系统推荐 Ubuntu 22.04或者带 GPU 直通的 WSL2 环境。Python 版本建议 3.10 及以上。GPU 显存建议从 24GB 起步如果资源紧张可以先选择 6B 到 7B 级别的 VLM并使用 QLoRA 降低显存占用。具体版本和模型大小请以你实际使用的项目为准本文不绑定某个具体版本重点演示通用思路。4.2 项目目录结构建议先建立清晰的项目目录避免后训练实验混乱。cosmos3-project/ ├── configs/ │ └── cosmos3_vlm_lora.yaml ├── data/ │ ├── real/ │ └── synthetic/ ├── scripts/ │ ├── generate_synthetic.py │ └── vlm_inference.py ├── output/ │ └── cosmos3-lora/ └── requirements.txt目录分层的逻辑是配置文件和代码分离原始数据和生成数据分离训练输出单独存放。这样每个实验都有独立的配置文件、数据快照和输出目录后面做版本回溯会轻松很多。4.3 依赖安装下面是一个通用依赖列表覆盖了数据生成、模型训练、推理验证和评测常用的 Python 库。# requirements.txt torch2.1,3.0 transformers4.40 accelerate0.30 peft0.11 deepspeed0.14 datasets2.18 pillow10.0 requests2.31 rich13.0安装命令pip install -r requirements.txttorch 是深度学习框架transformers 负责模型结构和分词器peft 提供 LoRAaccelerate 和 deepspeed 负责分布式与混合精度训练datasets 用来管理数据集pillow 处理图像requests 用来调用推理服务rich 主要用于日志输出。版本范围建议不要追求最新优先选稳定版本。4
合成数据与后训练：VLM在智慧城市与农业机器人中的落地路径
最近大模型后训练、VLM 推理、合成数据这几个词频繁出现在一起。很多人手里已经有基础视觉语言模型也能跑通微调但一到真实项目就卡住。比如智慧城市项目里监控图像中的夜晚小目标漏检严重模型输出一会儿中文一会儿英文JSON 格式还不稳定农业机器人项目里真实果园的光照、遮挡、果叶重叠变化太大靠人工采集数据又慢又贵。这些问题的共同点是没有把“后训练”当成一套有数据、有评测、有回滚的工程流程而只是当成一次脚本运行。这篇文章围绕 Cosmos 3 展开想拆解一条从智慧城市 VLM 推理到农业机器人合成数据生成的实战路径。先给一个明确判断。Cosmos 3 这类世界模型/合成数据方案的价值不在于“生成图片多逼真”而在于“可以控制生成什么场景、出现什么目标、附带什么标签”。后训练的价值也不是让模型记住更多知识而是让模型学会按业务格式输出、按业务语义理解。把这两点连起来才是物理 AI 项目真正能落地的原因。这篇文章不会把某个平台的官方接口当黑盒吹捧也不会只讲理论。我会聚焦在一条可以复用的工程链路上如何定义场景如何生成双语合成数据如何训练 VLM如何推理验证以及从智慧城市迁移到农业机器人时需要注意什么。阅读时可以把手上的项目替换到对应场景中操作思路是一致的。1. 这篇文章真正要解决的问题先说一个观察现在很多人提到“后训练”第一反应是找一个开源框架把数据集扔进去跑几个 epoch 就算完了。但在实际项目里模型的最终效果往往不是死在训练参数上而是死在数据分布和业务约束上。基础 VLM 在通用 benchmark 上能拿到不错的结果一旦进入垂直场景问题会立刻暴露输出格式不稳定、长尾事件没见过、业务概念没有对齐。这些都不是单靠调学习率能解决的。智慧城市就是一个典型场景。摄像头采集的监控图像数量很大但真正需要关注的异常事件往往是少数例如夜晚横穿马路、交通事故、违规停车、井盖缺失。人工标注这些长尾事件成本高而且不同标注员对同一事件的描述可能不一致。如果只靠真实数据做后训练模型对高频场景会过拟合对低频异常依然漏报。这时候合成数据就有优势可以精确控制异常事件的出现频率让模型在训练阶段就能见到足够多的小概率场景。农业机器人场景的问题正好相反。果园里的数据不是不够多而是分布太散。同一颗苹果树上午、中午、傍晚的光照完全不同机械臂从不同角度拍摄果实遮挡比例也会变化。机器人需要识别果实、判断成熟度、区分果子和叶子甚至要辨识杂草。真实采集数据要覆盖所有光照、角度、品种成本非常惊人。合成数据可以批量生成这些变量组合并且自动携带准确标注这正是 Cosmos 3 这类方案能派上用场的核心原因。因此这篇文章真正要解决的不是“如何训练一个 VLM”而是“如何用合成数据把 VLM 后训练做成一个可持续迭代的工程闭环”。适合读这篇文章的读者包括正在做视觉语言模型微调但效果不稳定的人做智慧城市、工业视觉、农业机器人等物理 AI 项目的工程师以及想了解大模型后训练和合成数据工作流如何结合的算法同学。2. Cosmos 3 是什么为什么后训练才是落地关键先说明一个前提我不把 Cosmos 3 当做一个已经定型的开源项目来介绍而是把它作为“世界模型 合成数据 后训练”这条技术路线的一个工程代号。不同团队手里的 Cosmos 3 可能差异很大生成接口也可能完全不同一旦绑定某个具体版本反而学不到可复用的东西。因此下面先拆开三个基础概念再解释它们为什么必须绑定在一起。2.1 先分清三个概念VLM、后训练、合成数据VLMVision-Language Model视觉语言模型是能同时处理图像和文本的模型。它输入一张图片加上一句问题输出自然语言描述或结构化结果。例如输入一张交通路口照片模型可以回答“有几辆车、是否有行人闯红灯”也可以直接返回 JSON 对象。注意“VLM 推理”这个说法在项目里通常不是指数学推理而是指基于视觉输入做业务判断。这部分工作流能不能稳定取决于模型是否见过足够多符合业务格式的样本。后训练post-training指的是预训练完成之后的模型适配阶段包括指令微调、偏好优化、蒸馏等。它不改变模型的底层能力而是改变模型对提示词、输出格式和任务语义的响应方式。大模型后训练在真实项目中的地位甚至比预训练选择更重要因为基础模型大家都差不多适配做得好不好直接决定了业务效果。很多人误以为后训练是“再学一遍知识”其实它更像“给一个聪明但没有工作经验的员工做入职培训”。合成数据是使用程序化渲染、世界模型或生成式模型产生的数据而不是从真实设备采集。它与数据增强的区别是数据增强基于已有真实样本做变换合成数据则可以从场景参数开始生成全新的样本能精确控制目标位置、光照、天气和标注。两者可以配合使用但合成数据在长尾场景覆盖上更有优势。2.2 为什么“能推理”不等于“能落地”一个开源 VLM 在通用评测集上表现不错放到智慧城市监控项目里往往会出三件事。第一输出格式不稳定同一个问题问十次模型有时输出自然语言有时输出 Markdown有时又夹带 JSON。第二长尾场景没覆盖基础模型可能见过“车辆”和“行人”但不理解“井盖缺失”“电动车进电梯”这类业务事件。第三垂直概念没对齐业务上需要输出“成熟度三级”或“遮挡率”基础模型根本没有这些概念。农业机器人同理。模型的视觉特征可能见过草莓但“草莓成熟度三级”这类业务标签没有学过。合成数据的意义就在这里可以直接把业务标签渲染进图像让后训练把标签和视觉特征绑定起来。换句话说合成数据承担的是“培训教材”的角色后训练承担的是“培训过程”的角色VLM 是被培训的员工缺了任何一环最后的效果都不稳定。2.3 双语不是翻译问题而是对齐问题标题里的“双语”不是简单翻译。真正的双语后训练要求中文问题、英文问题都能触发同样的视觉理解结果模型输出中文或英文时对象标签和数量要保持一致。很多团队先训练中文数据再单独接英文 prompt结果模型在两种语言下对同一张图的检测结果不一致甚至英语描述里多了一个目标。更好的做法是在合成数据阶段同时生成双语标注让训练样本天然带有对齐关系。这一点的工程含义是合成数据生成模板里中英文描述必须来自同一组标注对象不能分别随机生成。否则模型会学到错误的关联例如中文描述里有“行人”英文描述里却没有。后面我会在第 5 节给出一个具体的双语 JSONL 构造示例。3. 整体架构与工作流设计3.1 一条主线任何物理 AI 项目的后训练都可以归纳成一条主线场景定义 - 合成数据生成 - 数据清洗与标注 - VLM 后训练 - 推理部署 - 效果评测 - badcase 回流。这条链路是闭环的因为评测阶段发现的失败案例必须能回到数据生成阶段变成下一轮合成数据的输入。如果中间任何一步断开项目就会退化成“一次性微调”无法持续优化。Cosmos 3 这类方案带来的变化主要体现在场景定义和合成数据生成这两个环节。以前做一个智慧城市模型需要先凑真实数据、再找标注团队现在可以先用场景模板生成一批带标签数据让模型快速跑通再逐步加入真实数据校正分布。这不是替代人工标注而是把人工标注从“生产主力”变成“质量抽检”。3.2 智慧城市场景怎么拆智慧城市项目的输入通常是路口或街道监控图像任务是检测车辆、行人、交通设施并输出事件描述。难点在于夜间弱光、逆光、小目标、目标遮挡。合成数据生成时要模拟不同天气、不同时段、不同相机高度最好还要模拟监控摄像头特有的广角畸变和低分辨率效果。这样生成出来的数据才能让后训练模型适应真实监控画质。事件描述也是智慧城市 VLM 推理的关键。模型不仅要输出“画面中有几辆车”还要输出“一辆电动车在红灯时横穿路口”这类结构化事件。事件标签需要和检测结果联动否则模型很容易“看到目标但说不出事件”。3.3 农业机器人场景怎么拆农业机器人项目的输入来自果园巡检相机或采摘机械臂上的视觉传感器任务是检测果实并判断成熟度、区分果与叶、识别杂草。难点是光照剧烈变化、果叶重叠、同品种形态差异大。合成数据生成时要重点做域随机化改变地面材质、叶片密度、果实颜色、相机角度、光照方向。域随机化越充分模型迁移到真实果园时的适应性越好。农业机器人对输出格式的要求往往更严格因为机械臂执行动作需要精确的坐标和置信度。模型输出不能是一段自由文本而应该是结构化的检测框列表。因此后训练阶段要在 prompt 和训练数据里反复强调“只输出 JSON不要输出多余解释”。3.4 为什么要先跑通一个场景我不建议一上来就同时做智慧城市和农业机器人两个场景。更稳妥的顺序是先选一个相对标准、反馈快的场景跑通闭环再迁移到另一个场景。城市监控场景相对标准化公开数据多失败反馈快农业机器人场景更开放长尾更严重。先用智慧城市验证数据生成、后训练、推理评测这套流程再迁移到农业机器人是成本更低也更容易排查问题的做法。4. 环境准备与基础配置4.1 硬件与软件建议操作系统推荐 Ubuntu 22.04或者带 GPU 直通的 WSL2 环境。Python 版本建议 3.10 及以上。GPU 显存建议从 24GB 起步如果资源紧张可以先选择 6B 到 7B 级别的 VLM并使用 QLoRA 降低显存占用。具体版本和模型大小请以你实际使用的项目为准本文不绑定某个具体版本重点演示通用思路。4.2 项目目录结构建议先建立清晰的项目目录避免后训练实验混乱。cosmos3-project/ ├── configs/ │ └── cosmos3_vlm_lora.yaml ├── data/ │ ├── real/ │ └── synthetic/ ├── scripts/ │ ├── generate_synthetic.py │ └── vlm_inference.py ├── output/ │ └── cosmos3-lora/ └── requirements.txt目录分层的逻辑是配置文件和代码分离原始数据和生成数据分离训练输出单独存放。这样每个实验都有独立的配置文件、数据快照和输出目录后面做版本回溯会轻松很多。4.3 依赖安装下面是一个通用依赖列表覆盖了数据生成、模型训练、推理验证和评测常用的 Python 库。# requirements.txt torch2.1,3.0 transformers4.40 accelerate0.30 peft0.11 deepspeed0.14 datasets2.18 pillow10.0 requests2.31 rich13.0安装命令pip install -r requirements.txttorch 是深度学习框架transformers 负责模型结构和分词器peft 提供 LoRAaccelerate 和 deepspeed 负责分布式与混合精度训练datasets 用来管理数据集pillow 处理图像requests 用来调用推理服务rich 主要用于日志输出。版本范围建议不要追求最新优先选稳定版本。4