多模态统一序列建模实战：NextFlow从设计到训练解析

1. 从两套模型到一套统一序列建模NextFlow在做什么如果你最近在公司里折腾过多模态项目大概率也撞上过那个经典尴尬模型 A 能把一张图说得头头是道你问它里面有几只鸟、什么颜色、正在干什么它都能给你憋出一段像模像样的回答可你要是让它照着一只坐在沙发上的橘猫这句话画一张图出来的东西基本就是色块拼贴。反过来模型 B 在文生图上表现惊艳但你喂它一张故障截图问问题它只会把图片里的文字和标签复述一遍完全不会推理。这种割裂感几乎成了当前多模态模型研发的默认状态。NextFlow 就是我们在内部搭的一个多模态项目核心思路极简把文本、图像、音频统统拆成 token 串用同一个自回归 next-token prediction 目标去训练一个 Transformer 模型。当所有模态在模型内部共享同一套序列建模逻辑多模态理解与多模态生成就不再是两套系统而是同一种能力的两面。这个项目适合谁参考如果你正在做多模态大模型、想做 unified multimodal model或者只是好奇为什么有人敢把图像和文本塞进同一个自回归框架这篇笔记应该能给你一个从设计到训练的完整落地方案。我尽量少讲抽象概念多写实操细节和踩坑记录。1.1 理解与生成被拆成两条线问题到底在哪现在的普遍做法是理解侧用图像编码器 大语言模型图像先变成视觉 embedding再跟文本指令一起进 LLM目标是预测文本答案生成侧则用文本编码器 图像解码器目标是预测像素、图像 token 或扩散噪声。两侧各自维护一套词汇表、一套损失函数、一套数据流程看起来没什么问题直到你需要它们协作。我印象最深的是跨模态编辑类任务比如输入一张室内照片告诉模型把沙发换成蓝色然后输出一张新图。按传统方案你得先让理解模型把图描述成文本再把文本作为生成模型的条件。中间那层描述会把大量视觉细节丢掉比如光影方向、材质纹理、物体精确位置最后生成出来的图总觉得味道不对。工程上也很别扭。两套模型意味着两套部署服务、两套显存预算、两套推理流程。前端要判断当前请求该路由到哪个服务还要处理时序依赖。一句话总结理解模型拿到的中间表征不是生成模型想消耗的那个表征。NextFlow 想绕开这个结构性问题干脆让所有模态住在同一个序列空间里。1.2 统一序列建模带来的三个直接转变第一个转变是训练目标的统一。理解任务可以写成给定图像 token 序列和问题 token 序列预测答案 token 序列生成任务可以写成给定文本 token 序列预测图像 token 序列。两者本质上都是条件 next-token prediction所以一个模型、一个 loss 就能覆盖。第二个转变是数据利用方式的统一。以前图文数据要么拿去训对齐模型要么拿去训生成模型两条线各自消费各自的数据现在同一批图文对可以直接构造出文本 - 图像和图像 文本 - 文本两种序列样本相当于一份标注数据同时为理解和生成提供梯度。第三个转变是部署架构的统一。一个权重、一个入口推理时模型内部通过特殊 token 决定下一个要吐的是文本还是图像 token前端根本不用关心模态差异。有收益当然也有代价。统一序列建模最常见的三个麻烦图像 token 数量大导致序列极长、不同模态的 loss 相互干扰导致训练不稳定、自回归逐 token 生成图像的速度让人着急。这些我后面都会展开讲毕竟决定一个项目能不能落地的往往不是思路本身而是这些藏在细节里的坑。2. NextFlow 的序列化方案文本、图像和音频怎么共用一条流水线2.1 各模态的 tokenizer 选择统一序列建模的前提是所有输入输出都能变成离散 token。文本侧相对成熟直接用 SentencePiece 训练一个 BPE 词表我习惯把词表大小放到 32K 左右。太小了表达能力不足太大了 embedding 参数暴涨训练压力会明显增加。图像侧是重头戏。我们需要一个能把像素变成离散 token 的自编码器我选了 VQGAN 这一路方案。视觉 codebook 大小取 16384编码器对输入做 8 倍下采样也就是说一张 256x256 的图会被压成 32x32 共 1024 个视觉 token。选 VQGAN 而不是简单 VQVAE是因为它的感知损失和对抗训练能保留更多高频细节重建出来的图不会像涂抹了一层水粉。这里有一个必须强调的认知图像 tokenizer 的重建质量基本决定整个生成模型的上限。模型再强如果 tokenizer 把边角细节丢光了它也只能在残废的词汇表里打转。音频侧我是在后期加进来的。主流做法是用残差矢量量化RVQ把音频编码成离散 token类似语音编解码器那条路线。由于 NextFlow 的核心序列模板不关心 token 具体来自哪个模态音频接入成本反而很低只要在序列里加上对应的起始和结束标记再把多级量化结果按时间步展平即可。2.2 构造一条按位对齐的混合模态序列有了 tokenizer下一步是把不同模态的 token 拼成一条文本和视觉按位对齐的序列。我们用几个特殊 token 来划区域简单列一下模板图文理解样本[BOS] [IMG] 图像token [/IMG] [TXT] 问题 [TXT] 答案 [EOS]训练时只对答案部分计算 loss。文生图样本[BOS] [TXT] 一只坐在沙发上的橘猫 [/TXT] [IMG] 图像token [/IMG] [EOS]训练时只对图像token部分计算 loss。纯文本样本[BOS] [TXT] 文本内容 [/TXT] [EOS]这是为了保留基础语言能力防止加入视觉数据后文本能力退化。图生图编辑样本[BOS] [IMG] 原图token [/IMG] [TXT] 把沙发换成蓝色 [/TXT] [IMG] 目标图token [/IMG] [EOS]训练时只对目标图像 token 计算 loss。这个模板设计有个细节容易被人忽略区域标记和内容标记最好分开。很多人上来只用[IMG]一个标记结果模型分不清哪一段是图像内容和接下来该输出图像了。我用[IMG]表示进入图像区域用[/IMG]表示区域结束语义清晰很多推理时也更好做模态切换。数据拼好后每个样本就是一个普通的一维序列和 GPT 类模型训练时看到的文本序列没有任何区别。Transformer 的 attention 会自然跨模态建模不需要额外的对齐模块。2.3 为什么预测下一个 token能同时驱动理解和生成理解任务乍一看跟预测下一个词不太像但你可以把它改写成条件语言建模把图像 token 和问题文本当作已知上下文模型要最大化答案文本的概率。生成任务同理把描述文本当作已知上下文模型要最大化图像 token 序列的概率。两者共享同一个损失函数只是被 mask 关注的输出区域不同。我经常跟同事用一个类比解释这件事人看图不是一眼吞下全部像素而是沿着视觉路径扫视先轮廓后细节画画也不是同时落笔全图总得一笔一笔来。自回归模型天然贴合这种过程让 attention 覆盖所有模态之后看懂和画出来都只是对下一个 token 的条件概率进行估计。这个思路最有力的地方在于不需要引入任何任务分支。有些方案会在理解任务里加分类头在生成任务里加扩散头最后做成一个缝合怪。NextFlow 从头到尾只有一个 transformer decoder一个输出头换来的是更干净的结构和更简单的部署。3. 训练细节数据配比、损失平衡和稳定性控制3.1 两阶段训练预训练与指令微调我把 NextFlow 的训练拆成两个阶段。第一阶段是预训练目标是让模型学会混合模态序列的基本语法数据来源包括图文对、纯文本语料、纯图像数据和音频数据。第二阶段是指令微调SFT目标是让模型学会跟随人类指令数据包括图文对话、文生图指令、图像编辑指令、多轮对话等。数据配比是最容易被低估的陷阱。纯文本数据占比太低模型的语言能力和指令遵从能力会明显退化图文数据占比太低多模态能力又起不来。我实测下来预训练阶段文本与视觉数据的 token 配比在 3:1 到 2:1 之间比较稳并且要按 token 数而不是样本数量来采样。因为一张图的 1024 个 token往往顶得上几百个文本 token按样本数配比会直接把序列内容推向图像主导。SFT 阶段要更小心。指令微调数据里如果塞了太多文生图任务模型会慢慢忘掉阅读理解能力反过来理解指令太多生成能力又会被挤压。我常用的做法是固定一个比例比如理解类对话占 40%、文生图占 30%、图生图编辑占 20%、纯文本指令占 10%每个 epoch 结束后抽测四类基准连续掉点就回退数据比例。3.2 Loss 设计与实现文本词表 32K、图像 codebook 16K、音频 token 数量也不同如果所有位置共享一个大输出 headlogits 计算范围要覆盖所有模态词汇的并集这会带来两个问题维度大导致显存开销高不同模态的 token 分布差异大直接相加会让模型偏科。我给 NextFlow 设计的是带 mask 的逐位置交叉熵。对于每个训练样本只有目标区域参与 loss 计算# logits: [batch_size, seq_len, vocab_total] # labels: [batch_size, seq_len]其中 ignore 位置填 -100 import torch.nn.functional as F loss F.cross_entropy( logits.reshape(-1, vocab_total), labels.reshape(-1), reductionnone ).reshape(batch_size, seq_len) loss loss * token_mask # token_mask 为 1 表示该位置需要监督 loss loss.sum() / token_mask.sum()总 loss 还需要按模态分别加权total_loss text_loss_weight * text_loss image_loss_weight * image_loss我最初用的是text_weight1.0, image_weight1.0结果图像生成始终欠拟合生成的图像细节稀疏后来把图像权重逐步加到 1.5 甚至 2.0情况明显改善。原因是图像 token 序列长、每个位置的信息熵高如果不额外加权梯度贡献会被数量庞大的文本 token 稀释。每个项目最优权重不同但一个可行的起点是给图像 loss 一点偏置。3.3 稳定训练的一些实操细节多模态序列模型在训练稳定性上比纯文本模型更敏感这里列几个我确认有效的技巧。第一是初始化。图像 codebook 的 embedding 和文本 embedding 一样都从均值为 0、标准差偏小的分布里初始化实测方差太大时预训练初期 loss 会出现明显震荡。第二是学习率调度。我用的峰值学习率是 3e-4warmup 步数 2000 步之后 cosine 衰减到 1e-5。不要跳过 warmup因为图像 token 分布初始时还没稳定一上来用大学习率很容易把 embedding 空间冲散。第三是位置编码。因为图像 token 序列动辄上千我选择旋转位置编码配合预归一化 Transformer并且给 Q 和 K 都加了 LayerNorm。多模态长序列训练里qk-norm 对防止 attention 分数爆炸非常有效。第四是序列长度上限。训练时把单条序列截断在 4096 左右如果图像分辨率再大就通过降低采样尺寸来适配。很多人贪心把序列加到 8192显存只能跑很小的 batch收敛反而更慢。我是先把 batch size 压在合理范围再考虑更大分辨率。4. 推理时如何把理解切换成生成4.1 模态路由特殊 token 与输出头训练时我们在序列里埋了[IMG] / [/IMG] / [TXT] / [/TXT]这些特殊 token推理回路自然由它们驱动。模型解码时每次只吐一个 token如果刚吐完[/IMG]下一个 token 大概率是[TXT]模型就会进入文本生成模式如果刚吐完[/TXT]下一个 token 大概率是[IMG]模型就会切到图像生成模式。实现层面有两种做法。第一种是把所有模态词汇放一个大输出头推理时在 softmax 前把不可能的词表位置 mask 掉第二种是给文本和图像分别设独立的输出头根据当前是否处于图像区域选择使用哪个 head。我推荐第二种因为训练时 loss 本来就是按模态分开算的两个头可以更灵活地调节各自的 logit 尺度。自回归模型的 classifier-free guidance 也值得引入。训练时我以 15% 左右的概率随机丢弃条件文本或条件图像推理时对条件输入和无条件输入分别算一次 logits再按final uncond_logits gamma * (cond_logits - uncond_logits)强化条件响应。这个操作对文本到图像的对齐质量提升非常明显语义相关性比单纯调高温度靠谱得多。4.2 图像 token 的采样策略与加速方法文本生成一般直接用 temperature top-k top-p 采样即可。图像生成不能直接照搬否则行与行之间容易断裂。我采用的策略是 raster order让模型从左到右、从上到下逐 token 生成图像序列同时在相邻行之间做 overlap 预测。也就是说模型生成第 N 行 token 时输入里保留第 N-1 行的最后 16 个 token 作为上下文这样可以极大缓解横向纹理断层的问题。自回归生成速度是个绕不开的问题。生成 1024 个图像 token 意味着至少 1024 次前向慢是自然的。我做了两个优化。一是 KV cache 复用已经算过的历史 token 不再重复计算这是必须项。二是尝试 block-wise 并行预测一次预测 8 个 token然后用一个小的自回归 verifier 去纠正边界 token速度和质量的平衡点比较合适。如果对生成质量有更高要求另一个可行路线是两阶段串联NextFlow 先自回归生成一套图像 token再做一个小型扩散 refine 模型在 token 层重绘细节。离散 token 上的扩散可以让生成结果比纯自回归更细腻缺点是系统复杂度上升。我建议项目早期先不要上第二步等第一步的序列建模彻底稳定了再加精修模块。4.3 统一能力的测评方案单看一个指标容易产生错觉。我自己在实践里至少同时看四组指标任务类别指标说明图像描述CIDEr、BLEU评估模型看懂图并用语言表达的能力图文问答准确率判断视觉细节中的事实性信息是否被正确提取文生图FID、CLIPScore、人工评分FID 衡量分布接近程度CLIPScore 衡量图文语义匹配图生图编辑编辑指令准确率、人工偏好直接检验统一序列带来的跨模态连贯性测试时千万不要只看 FID。我见过一个模型 FID 刷得挺漂亮但生成的图和指令语义完全跑偏原因就是它把所有风格模板化的图像都生成了一遍分布接近但不含正确语义。最后要对每次实验都抽 50 到 100 条生成结果做人工盲评这个步骤省不得。5. 实战排查记录训练不稳、图像变糊怎么办5.1 高频问题速查做 NextFlow 过程中团队踩过的坑基本可以汇总成一张表现象常见原因处理方式图像生成模糊、细节丢失图像 tokenizer 重建质量不足图像 loss 权重过低换更高保真的 VQGAN把 image loss 权重从 1.0 提到 1.5 以上模型在应该生成图像时输出文本分隔符使用不一致SFT 数据中[IMG]标记缺失统一所有样本模板检查模态路由分支文本理解能力掉点严重视觉数据配比过高调高纯文本数据比例减少非指令式视觉样本训练 loss 正常但生成内容语义不符图文对描述文本太模板化清洗数据丰富描述语句多样性显存溢出图像 token 序列过长降低训练分辨率限制序列长度至 4096图像纹理断裂自回归逐行生成没有做 overlap引入相邻行 overlap token 上下文这些问题是排查优先级的参考不是最终结论。每个项目的数据管线不一样最快定位方式是先把数据、loss、tokenizer 三个嫌疑项排除再去怀疑模型结构。5.2 一次图像越练越糊的排障全流程有一轮实验印象很深前 5000 步文本理解和图文问答指标都正常上涨图像生成一开始还行训练到 20000 步时生成的图开始出现局部纹理崩坏像油画颜料乱堆。第一反应是模型过拟合于是先查数据。回看训练集发现这批样本里加入了大量高饱和度的艺术风格图片分布和最开始的自然图混在一起。把新增数据暂时剔除后纹理崩坏的问题缓解了但图像生成细节依然上不去。第二嫌疑落在 loss 平衡。打开训练日志看 text loss 和 image loss 的贡献量发现 image loss 的 scale 只有 text loss 的十分之一左右原因是按位置加权时文本位置的 loss 数量远多于图像位置。把图像权重调到 2.0 后细节恢复肉眼可见。第三个动作更关键把图像 tokenizer 从可训练改成冻结。本来想端到端微调 tokenizer 让 codebook 更适配新数据但实测端到端更新导致视觉 embedding 和文本 embedding 的方向漂移模型整体稳定性变差。最终版本是固定图像 tokenizer 权重只更新 Transformer 主干图像生成质量从此稳定下来。这次排障给我一个启发当多模态模型出现某个模态能力倒退时绝大多数原因不在模型结构而在数据分布、loss 比例、tokenizer 冻结与否这三件事上。先把这三件排查完再动架构能省很多调试时间。6. 我个人的几点实操心得最后说点感性的经验。统一序列建模在理论上非常干净漂亮但真把 NextFlow 搭起来之后我发现模型结构本身反而是最省心的一环。真正决定项目成败的是 tokenizer 质量、数据配比、loss mask 这些看起来不起眼的细节。如果让我重新做一遍自建多模态模型我会把至少一半时间花在图像 tokenizer 和训练数据清洗上而不是堆参数、扩分辨率。另一个经验是不要试图一步到位支持所有模态。文本加图像已经足够暴露大量工程问题先把这条线跑通跑稳再考虑音频接入。用一套小规模模型把数据、模板、训练管线验证清楚比直接上来做大模型省钱省时间得多。如果要做扩展我目前觉得最有价值的方向是完善音频模态的序列化方式以及把 block-wise 并行解码从实验性加速变成默认推理路径。多模态这条路没有银弹统一序列建模给了一个不错的起点后面的功夫还是在细节里。