企业官网建设流程全解析

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 数量也不同，如果所有位置共享一个大输出 head，logits 计算范围要覆盖所有模态词汇的并集，这会带来两个问题：维度大导致显存开销高；不同模态的 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), reduction="none" ).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_weight=1.0, image_weight=1.0，结果图像生成始终欠拟合，生成的图像细节稀疏；后来把图像权重逐步加到 1.5 甚至 2.0，情况明显改善。原因是图像 token 序列长、每个位置的信息熵高，如果不额外加权，梯度贡献会被数量庞大的文本 token 稀释。每个项目最优权重不同，但一个可行的起点是给图像 loss 一点偏置。

3.3 稳定训练的一些实操细节

多模态序列模型在训练稳定性上比纯文本模型更敏感，这里列几个我确认有效的技巧。

第一是初始化。图像 codebook 的 embedding 和文本 embedding 一样，都从均值为 0、标准差偏小的分布里初始化，实测方差太大时预训练初期 loss 会出现明显震荡。

第二是学习率调度。我用的峰值学习率是 3e-4，warmup 步数 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 统一能力的测评方案

单看一个指标容易产生错觉。我自己在实践里至少同时看四组指标：

测试时千万不要只看 FID。我见过一个模型 FID 刷得挺漂亮，但生成的图和指令语义完全跑偏，原因就是它把所有风格模板化的图像都生成了一遍，分布接近但不含正确语义。最后要对每次实验都抽 50 到 100 条生成结果做人工盲评，这个步骤省不得。

5. 实战排查记录：训练不稳、图像变糊怎么办

5.1 高频问题速查

做 NextFlow 过程中，团队踩过的坑基本可以汇总成一张表：

这些问题是排查优先级的参考，不是最终结论。每个项目的数据管线不一样，最快定位方式是先把数据、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 并行解码从实验性加速变成默认推理路径。多模态这条路没有银弹，统一序列建模给了一个不错的起点，后面的功夫还是在细节里。