这次要拆的主题是 Cosmos 3 后训练实战。先给结论它解决的不是某个单点功能而是把世界模型、VLM 推理、合成数据生成串成一条能落地的链路覆盖智慧城市监控视频理解和农业机器人感知数据生产两个典型场景。适合正在做视觉大模型后训练、需要批量跑 VLM 推理或者为机器人感知补充训练数据的人看。最值得关注的不是某一个命令而是“先准备域数据再做后训练再批量推理最后用合成数据回流”这条完整工作流。简单交代背景。Cosmos 3 这一代世界模型平台核心能力是按照文本或控制条件生成和真实世界比较一致的视频内容。通用模型直接拿到智慧城市或农田场景里用生成内容不够聚焦理解类任务的输出也不够稳定所以才需要“后训练”这个环节用目标场景的数据把模型再校准一遍。VLM 负责看懂视频并输出结构化文本合成数据则把生成能力反向用于扩充训练集。这三者不是三个独立任务而是一条互相依赖的数据链路。下面按实际测试的顺序来拆先讲数据准备和环境检查再讲 VLM 推理然后讲农业机器人场景的合成数据生成最后给参数速查表、验证指标、排查顺序和边界提示。标题里带“双语”我的处理方式是以中文为主体关键术语保留英文比如 post-training、VLM、world foundation model、synthetic data这样对照官方文档和论文时不容易对不上号。1. 先搞清楚 Cosmos 3 后训练到底解决什么问题1.1 生成、理解、补数据这三个角色分别干什么一条完整链路里通常有三个模型角色容易混在一起。第一个是生成模型。它接收文本描述、相机参数或控制条件输出视频。世界模型平台里的基础生成模型默认覆盖通用场景但如果你想让它生成“傍晚菜地行间视角的番茄采摘机器人画面”这种具体内容直接生成的结果可能会出现作物形态不对、光照不真实、相机高度离谱等问题。后训练就是针对这类缺口做的。第二个是理解模型也就是 VLM。它接收图像或视频帧输出文字描述、目标数量、异常事件判断等。智慧城市场景里VLM 一般用来做监控视频的粗理解路上有没有拥堵、有没有行人横穿、某类事件是否发生。后训练对它有两大价值一是输出更贴近业务的结构化格式二是减少对城市常见物体的误判。第三个是合成数据生成。这个角色比较特殊它不直接对外服务而是把生成模型的产出变成其他模型的训练集。农业机器人需要识别的作物、杂草、果实样本真实采集受季节、天气、地块条件限制很难一次拿全用后训练好的世界模型先批量生成几乎一样的场景画面再抽帧、标注、放进感知模型训练是目前比较常见的做法。1.2 智慧城市和农业机器人为什么能放到同一条链路里讲表面看一个在城区一个在农田差别很大。但落到工程上它们面对的问题是同一类基础模型见过大量互联网视频但没见过足够的“本场景数据”。智慧城市监控视频有固定的镜头角度、固定的道路结构、复杂的天气和光照。农业机器人则有低视角、高遮挡、植株密集、目标尺寸小这些特点。这两类数据都难以靠通用语料覆盖。所以解决方式也一致先收集少量领域数据做后训练把模型校准到目标分布上再部署推理或批量生成。换句话说场景不同方法通用。这也是我把两件事放一起写的原因。1.3 什么样的人适合直接上手如果你满足下面几个条件这套实践可以跟着走手里有几张支持 16GB 以上显存的显卡或者至少能使用云 GPU。接触过 PyTorch 和模型微调的基本流程哪怕只是跑通过训练脚本。手头有价值不高但数量可观的场景视频比如监控录像片段、机器人行走拍摄的农田视频。明确知道下游任务是什么比如检测行人、判断交通事件、识别作物行距。如果只是好奇、没有任何领域数据建议先跑基础模型的推理 Demo不要急着做后训练。没有真实数据约束的后训练很容易把模型训偏。2. 后训练前准备什么数据、环境和最小验证样例2.1 两个场景的数据采集策略先看智慧城市场景。不需要一上来就收几百小时监控先按 100 到 300 个短视频片段准备每段 5 到 15 秒覆盖这些变量时间白天、傍晚、夜间。天气晴天、阴天、雨天。路口类型十字路口、丁字路口、园区出入口。目标类型行人、机动车、非机动车、施工区域。这样做的原因是后训练的核心是“分布覆盖”不是“绝对数量”。视频片段在场景类型上的多样性比片段总时长更重要。农业机器人场景类似但变量不同。重点是相机高度和角度。机器人挂在行间行走时视角偏低作物会形成明显的透视关系。建议采集以下类型苗期、生长期、成熟期的同一作物。有杂草和无杂草的地块。强光照、背光、阴天三种光照。站在行间正中和靠近植株两种位置。如果没有条件拍这么多先去公开的农业视觉数据集里找相近画面的片段再做少量补充拍摄。2.2 数据清洗、标注和目录组织拿到原始视频后第一件事是清洗。模糊、剧烈抖动、长时间静止、重复帧过多的素材要剔除。不要心疼数据量脏数据对后训练的伤害比数据量小更大。清洗之后要抽帧。视频理解任务一般不需要逐帧标注常见做法是每秒抽 1 到 2 帧或者按场景变化抽关键帧。抽帧不仅降低标注成本也让后续 VLM 推理的速度更快。目录结构建议参考这样dataset/ smart_city/ train/ day_001.mp4 night_003.mp4 frames/ day_001_0001.jpg day_001_0002.jpg captions.json agriculture/ train_videos/ prompts.txt generated_frames/captions.json 里每一条要包含视频路径、文本描述、时间区间、场景标签。这里最容易踩的坑是描述写得太短。比如只写“有一个行人”后训练时模型很难学到更细的视觉差异。建议写成完整的一句话比如“傍晚城市主干道一辆白色轿车停在路口等待右侧人行道有两名行人正在通过”。对 VLM 后训练来说标注文本的质量直接决定输出质量。2.3 环境依赖显卡、显存、框架版本按常见配置来评估如果做 LoRA 级别的后训练建议单卡显存不低于 24GB如果只是想跑已训练好的模型做推理8 到 16GB 也能撑住但要注意分辨率、批量数和帧数的限制。依赖方面基础项包括 PyTorch、transformers、diffusers、flash-attention、xformers 这类常见库。具体用哪些取决于你加载的是生成模型还是 VLM。原始材料里没有给出明确版本落地时建议先确认 Python、CUDA 和 PyTorch 的匹配关系再装上层依赖。步骤上很推荐先建一个干净的 conda 环境不要直接装在系统 Python 里不然几个项目之间互相踩依赖版本排查起来非常痛苦。如果你在 Windows 上用 WSL2 跑这类任务先确认 GPU 驱动在宿主机装好再在 WSL2 里检查 nvidia-smi 能否看到显卡。WSL2 对 NVIDIA 的支持相对成熟但如果是 AMD 显卡做 ROCm 推理需要单独验证硬件映射和内核支持情况这条路比 NVIDIA 容易踩坑得多建议先用一个小模型实测不要把时间浪费在环境配置阶段。2.4 最小验证样例一定要先跑这是整个流程里我最强调的一步正式后训练之前先用 20 到 30 条样本跑通全流程。具体顺序是加载基础模型。在原始模型上做一次推理记录生成结果和 VLM 理解结果。跑一遍后训练脚本用最小步数训练。保存新权重再做一次推理对比结果。这样做的原因很简单如果没有基线结果后面模型效果变好变差你都不知道是后训练带来的还是数据、参数、环境变化带来的。我见过太多人直接开训跑了十个小时最后发现一开始加载模型就用了错误的数据路径。先用最小样例验证整个链路只要几分钟能排除掉大部分低级问题。注意不要一上来就开最大并发或最大批量。先把单条命令跑通再逐步加量。批量任务跑出问题时很难知道是模型问题还是并发问题。3. 智慧城市 VLM 推理实战流程3.1 从单条视频到结构化输出先说推理任务的实现思路不绑定具体模型。VLM 推理的输入一般是一张或几张图像输出是文本。对视频需要先抽帧再把关键帧传给模型。城市监控视频单段 15 秒按每秒 1 帧抽就是 15 帧。通常不需要全部传进去先按间隔取 5 到 6 帧减少输入长度也减少推理耗时。加载模型后单条推理的伪代码大致是from vlm_loader import load_model, process_frames model load_model(your_vlm_path) frames sample_frames(night_003.mp4, interval3) prompt 分析这组交通监控画面按 JSON 输出检测结果 result process_frames(model, frames, prompt) print(result)这里有两个关键点。第一抽帧间隔不能太大否则快速移动的行人或车辆容易丢失。建议短片段间隔 2 到 3 帧长片段先抽关键片段再细看。第二prompt 要固定下来不要在批量推理里频繁换句式否则输出格式会不稳定。3.2 提示词设计和 JSON 输出格式智慧城市 VLM 推理最忌讳的是“模型看得懂返回结果没法用”。所以提示词里要明确要求结构化输出。一个稳定的提示词模板可以这样写你是城市交通监控分析助手。请分析给定视频画面输出 JSON字段如下 { vehicle_count: int, pedestrian_count: int, congestion_level: none|low|medium|high, abnormal_events: [event1, event2], description: str } 只输出 JSON不要输出多余文字。为什么要强调“只输出 JSON”因为很多开源 VLM 会默认在结果前后加上解释性文字批量解析时容易出问题。加了这句约束之后绝大部分结果可以直接被 json.loads 解析。如果模型仍然偶尔输出多余文字就在后处理里加一个提取 JSON 片段的函数按第一个{和最后一个}截取。不要指望提示词能 100% 约束住模型后处理保险非常重要。3.3 批量推理的命名、日志和结果落盘单条推理通过后再进入批量。批量推理真正要解决的不是“能不能循环”而是三件事输入怎么组织、输出怎么命名、失败了怎么办。输入组织上建议把待处理视频列表写成 CSV 或 JSON包含文件路径、场景类型、视频时长。输出命名一定要带上输入文件名、时间戳和模型版本比如night_003_20250217_v2.json这样不同版本模型跑出来的结果不会互相覆盖。日志也要单独落盘每次推理记录输入路径、抽帧数、推理耗时、是否成功、异常信息。不要只在终端打印批量任务跑一小时后终端窗口早就被冲掉了。失败策略上推荐“跳过并记录”不要“失败即停”。监控视频数量多单条失败很常见。批量脚本里捕获异常把失败的路径写入 error.log继续跑下一条。全部结束后再统一检查错误日志。3.4 推理参数怎么调温度、Top-p、推理强度VLM 推理参数不是只调一个温度就行。常见参数包括 temperature、top_p、max_tokens还有现在很多模型支持的 reasoning effort也就是“推理强度”或“思考深度”。在智慧城市场景里我的建议是temperature 设低一点比如 0.1 到 0.3输出更稳定。top_p 设在 0.9 左右不要拉满。max_tokens 不要设太小JSON 结构本身会占不少 token。如果模型支持推理强度默认值通常够用夜间小目标识别场景可以调高一档但单条耗时可能明显增加。这里要解释一下原因。推理强度越高模型内部生成推理链条就越长准确率可能提升但延迟和 token 消耗同步上升。如果是近实时监控场景要优先保证速度推理强度别开太高如果是离线批量分析可以调高一档换取质量。先看你的任务对延迟是否敏感再决定参数。4. 农业机器人合成数据生成从后训练到数据回流4.1 为什么一定要做合成数据农业机器人感知模型的训练最大瓶颈是真实数据不够。真实采集受季节限制番茄成熟期就那几周受天气限制雨天和强光照的数据很难一次收齐受地块限制不同地理位置的土壤和行距差异也很大。用世界模型生成合成数据核心价值不是生成张好看的照片而是可控地补足分布缺口。比如真实数据里晴天多、阴天少就专门生成阴天场景成熟番茄样本不够就专门生成成熟期的视频。这种方式比重新下地采集快得多。但它有边界。合成数据不能完全替代真实数据尤其是涉及精细操作、危险场景和极端天气时生成结果可能与真实视觉差距较大。建议把合成数据当作真实数据的补充而不是替代。比较好的配比是先拿真实数据打底再用合成数据把数量不足的类别补上来。4.2 用 LoRA 做农业场景的后训练农业场景的后训练比起全参数微调更推荐 LoRA。原因很实际显存占用低、训练时间短、容易迭代。如果换一个作物品种或地块重新训一个低秩适配器比全量微调方便得多。LoRA 的几个关键参数在农业场景里的一般选择rank8 到 32 之间。数据量少选小值数据多样选大值。alpha通常取 rank 的一倍或两倍不要盲目调大。target modules默认覆盖注意力层的 q、k、v、o 通常够用。epochs3 到 10 之间。小数据跑太久容易过拟合。learning rate1e-4 左右比较稳不要一上来就试 1e-3。训练数据里要有成对的“文本描述 视频片段”。描述要覆盖视角、光照、作物状态这些关键因素。示例低角度近距离视角菜地行间番茄植株绿色茂盛 少量成熟红色番茄晴天光线从左前方照射这里要特别提醒后训练生成模型时数据里的描述就是你推理时的控制条件。描述字段如果写“强光”推理时你输入“强光”生成结果才会按这个逻辑走。标注字段不统一后面可控生成就是空谈。4.3 可控生成相机视角、光照、季节轮换后训练完成后合成数据生成不再只是随意生成而是按需求控制。常见控制维度包括相机高度和角度低视角、俯视、45 度倾斜。光照条件顺光、逆光、阴天、傍晚。季节和作物状态苗期、花期、结果期。背景环境土地颜色、滴灌带、栅栏。如果你用的生成模型支持 depth 或 segmentation 条件输入建议用真实视频帧提取条件图再重新生成新画面。这样生成结果能保持布局相似但纹理和光照发生变化相当于给同一场景做“风格迁移”非常适合扩充目标检测训练集。生成时还可以用 seed 控制随机性。固定 seed 可以复现同一条生成结果方便排查问题不固定 seed 可以增加样本多样性。批量生成时建议每条样本记录 seed、prompt、模型版本、生成参数方便后续筛选和分析失败原因。4.4 合成数据如何回流到感知模型生成视频之后不能直接把原始视频丢给感知模型训练。需要做一次数据流水线抽帧每段生成视频按固定间隔抽帧得到训练图像。筛选剔除模糊、过度畸变、内容重复的帧。这个环节不能省生成模型偶尔会产生不符合物理规律的画面。标注用规则或基础检测模型生成初步标签人工抽样修正。不要指望全自动标注完全准确。混入真实数据按一定比例把合成帧和真实帧混合组成训练集。训练和验证训练 YOLO 这类检测模型然后在真实测试集上评估 mAP。这里的验证标准非常关键不是合成数据生成的画面好看而是加入合成数据后真实测试集上的精度有没有提升。如果提升不明显先看合成数据的分布和真实数据是否差异过大。比如真实数据都是俯视视角合成数据却生成了大量平视视角那对目标检测的训练帮助就很小。先分析分布差异再继续提高生成数量。注意不要把合成数据数量无限加大。合成数据的价值是补足分布缺口数量过多反而会把感知模型带到合成分布里导致真实场景效果下降。5. 参数速查、验证指标和资源占用5.1 后训练参数速查表参数建议范围说明LoRA rank8 - 32数据多样时取大值数据少时取小值LoRA alpharank 的 1 - 2 倍一般不必单独调很大learning rate1e-4 左右从低到高试不要直接上大学习率epochs3 - 10小数据集跑太久容易过拟合batch size1 - 8 按显存调整大批量能提速但显存和稳定性受限输入分辨率与目标任务一致不要随意缩小后续推理质量会受影响样本数100 到 500 个片段起步先覆盖多样性再扩充数量5.2 VLM 推理参数速查表参数建议范围使用场景temperature0.1 - 0.3结构化输出、批量分析top_p0.9 左右默认比较稳max_tokens256 - 1024按输出 JSON 大小调整抽帧间隔2 - 3 秒/帧短片段取密长片段按需batch size按显存调整优先保证单条成功率reasoning effort默认或高一档近实时场景保持默认5.3 结果质量怎么判断判断不是凭感觉要有记录。生成质量看三类指标视觉真实感画面是否明显模糊、畸变、闪烁。抽帧后放到显示器上人工快速抽样。提示词一致输入“傍晚逆光”生成画面里是否真的是傍晚逆光。时间一致性视频连续帧之间作物和机器人姿态是否平滑变化。如果跳变严重合成数据不能直接用于训练。VLM 推理质量看结构化输出成功率所有返回结果里能被正常解析成 JSON 的比例。低于 90% 时先检查提示词和后处理。字段准确性抽取 50 到 100 条人工核对车辆数、行人数的误差在多少范围内。异常事件命中率对标注过的事件样本看模型能不能正确识别。建议每次实验前先确定测试集固定 50 到 100 条样本所有对比都在同一测试集上跑。否则效果好坏根本无法比较。5.4 资源占用和推理加速先估算单条推理耗时的参考值再决定要不要优化。一般来说VLM 单帧推理在消费级显卡上可能耗时几秒到十几秒取决于模型大小、输入分辨率和推理强度。如果批量任务有几百条视频单条耗时和总耗时就差距巨大一定要提前算。加速选项按优先级排bf16 / fp16 精度最基础也最有效能明显降低显存和耗时。批量推理把多张图塞进同一个 batch吞吐量会比逐条快不少。图编译比如 torch.compile适合固定输入形状的部署场景。TensorRT 部署推理适合固定模型、固定输入尺寸的生产环境但安装部署成本高调试周期也长。模型卸载显存不足时把部分层计算放到 CPU 或使用 offload 机制。速度会变慢但能跑起来。低显存环境下如果只是做小批量验证先开 bf16再把抽帧数降低。不要一上来就上 TensorRT复杂度会掩盖真正的性能瓶颈。6. 常见报错、排查顺序和边界提示6.1 先按这个顺序排查遇到问题不要慌按固定顺序查不要乱改参数。看日志有没有明显的 traceback、路径错误、权限错误、CUDA 错误。看输入文件路径是否存在、视频是否完整、图片格式是否支持、帧是否全部是黑屏。看环境CUDA 版本、PyTorch 版本、依赖库版本、显存占用。看参数batch size 是不是太大、输入分辨率是不是过高、prompt 是不是写错。看模型权重是否真的加载了后训练后的权重而不是误加载了基础模型。很多“模型效果变差”的报修查到最后一层才发现是加载了错误版本的权重文件。先把路径和版本对一遍比调参数省时间得多。6.2 显存不够怎么办显存不足是最常见的问题尤其在农业场景里生成高分辨率视频时特别明显。解决办法按影响从小到大排降低 batch size先变成 1。降低输入分辨率或抽帧数。开启 bf16 或 fp16。开启模型卸载或 offload 机制。换更大的显卡或云主机。如果降低分辨率后 VLM 输出质量明显下降就不要为了跑通而压太多优先考虑换一个更小的模型。这里容易陷入的误区是为了在低显存上硬跑把输入分辨率从 1080 降到 256结果输出质量完全不可用。省下来的显存没有意义。6.3 输出质量问题排查VLM 返回空结果先看 prompt 里是否要求了过长的输出再看 max_tokens 是不是太小。JSON 解析失败先看输出里是否多了解释性文字再看是否有非法字符。生成模型输出模糊或重复先看是不是训练过拟合再看推理时是不是用了过高的去噪步数或错误的 CFG 系数。连续性跳变明显先看抽帧是否太少再看生成模型是否对长视频支持不足。一个容易被忽略的点生成结果和图例里的参考图分辨率不一致也会造成明显质量差异。确保训练时的分辨率、生成时的分辨率、以及下游任务的输入分辨率保持一致比反复调模型参数更有效。6.4 低配环境能做到什么程度如果你的机器只有 8GB 显存一些事可以做一些事不建议做。可以做跑量化后的 VLM 推理单条短视频分析低分辨率合成数据探索性实验。这类任务对显存要求低速度慢一点而已。不建议做大规模后训练、高分辨率批量生成、长时间视频的完整生成。这些任务在低配环境里要么跑不动要么需要非常长的时间性价比很低。把这类任务放到云 GPU 上更稳。另外如果你在 WSL2 里跑 GPU 推理环境本身会占一部分显存和系统资源。先用nvidia-smi确认 GPU 驱动、显存和实际可用算力都正常再跑任务。很多时候不是代码问题而是 WSL2 环境本身的驱动映射或权限问题。6.5 不要过度期待的部分最后说几点边界提醒。原始材料没有给出 Cosmos 3 的明确版本和官方参数配置落地时一定要先确认你用的具体版本以及它对应的模型文件、依赖库和推理接口不同版本之间的行为差异可能很大。合成数据不会一夜之间解决所有数据短缺问题。它的价值是可控地把补充分布但生成结果的标注质量、物理真实性和时间一致性仍需人工把关。后训练也不能替代数据清洗脏数据跑再多次后训练模型只会把脏模式学得更牢。如果你第一次跑通整条链路别急着追求效果上的惊艳提升。先把“数据准备 - 后训练 - 推理 - 合成数据回流”这个流程稳定跑起来再逐步扩大数据量和参数规模。踩过几次坑之后你会发现很多问题不是模型能力不够而是前置环境、数据路径、输入格式和输出检查这些基本功没有做扎实。把单任务和最小样例跑稳比盲目拉大并发和参数更值得。
