最近我在一个空闲窗口里折腾了一个叫 nano-banana 的绘图实验。说它是项目不如说是一次对「多模态大语言模型MLLM到底能轻到什么程度」的极限测试。nano-banana 要做的事情很简单输入一句描述性的 Prompt模型端到端生成一张图全程不需要访问外部绘图服务所有逻辑都跑在本地的中小规模模型上。它的目标不是对标商业级绘图模型而是验证一条更紧凑的技术路线——小参数、低显存、单机可跑、开箱即用。这篇文章想把从立项到跑通的完整过程捋一遍包括整体架构取舍、文本编码与对齐设计、训练细节和显存调优、以及实测翻车点。如果你也想做轻量级多模态绘图或者单纯好奇「一个几百兆的模型究竟能不能画出像样的图」这篇内容应该能给你一些可以抄作业的参考。1. 为什么做 nano-banana轻量多模态绘图的一次极限试探1.1 小模型到底配不配画图先说一个反直觉的结论模型体积和绘图质量并不是严格的线性关系。三年前大家普遍觉得生成图片必须是十亿甚至百亿参数级别的玩法但随着蒸馏、量化、小模型扩散架构的成熟几亿参数的绘图模型已经能在特定场景里拿出可用的结果。nano-banana 的核心出发点就是验证「小模型能不能端到端画图」这件事。它的名字也挺直白——nano 代表极小的规模banana 是内部叫惯了的实验代号没有任何实际含义纯粹为了好记。整个项目最终压缩到大约 4 亿参数左右在消费级显卡上不仅能推理还能用可控的时间完成微调。我给自己定的验收标准也很朴素单张显卡推理显存占用不超过 8GB支持中英文短句描述能画风景、物体、简单的场景组合单张图生成时间控制在 5 秒以内。这几个标准加起来其实已经劝退了很多复杂的通用模型方案逼着你在每一个模块上都做减法。1.2 立项边界什么坚决不做轻量项目最怕的不是能力弱而是什么都想沾。nano-banana 在立项时就划了三道明确的红线。第一不做通用的长对话理解。它只需要理解输入的 Prompt 并生成对应的图像不需要像完整 MLLM 那样具备多轮对话、视觉问答、推理规划等能力。这能大幅简化文本编码器的压力。第二不做摄影级细节渲染。小模型的容量有限硬学复杂的材质反射、光影物理和超精细纹理只会让模型的注意力被稀释。nano-banana 的重点是构图合理、主体清晰、色彩协调而不是放大后每一根毛发都纤毫毕现。第三不追求复杂 Prompt 的精确解析。像「一个戴红帽子的男孩站在蓝色房子前手里拿着黄色的伞天空中有三只鸟」这种包含多个实体、多个属性、空间关系的 Prompt对小型文本编码器来说是地狱难度。nano-banana 的目标是正确理解两三个核心实体和它们的主要属性复杂多实体指令本来就不在它的能力圈内。这个边界划定很重要。很多小模型绘图项目做砸了不是模型本身不行而是拿它去跟商业级大模型比全能然后得出「小模型没用」的结论。nano-banana 从一开始就承认自己是窄路选手在轻量场景里做到足够好就已经完成了使命。2. Pipeline 全貌从 Prompt 到像素的五段链路2.1 文本编码器用小号文本塔压缩语义整条绘图链路的第一步是把用户输入的 Prompt 变成模型能懂的语义向量。nano-banana 没有直接用现成的大号文本编码器而是选了一个自己训练的中小型双语文本编码器模型规模控制在 1.5 亿参数左右。这个体量的文本塔无法像大模型那样逐字逐句地推理复杂语法但应付「视觉相关的短句描述」已经绰绰有余。选型时我有过犹豫要不要直接拿现成的大文本模型来做蒸馏后来想通了文本编码器在 MLLM 绘图链路里承担的任务非常特殊它要服务的不是语言理解本身而是把语言空间中的描述精确映射到图像特征空间。大文本模型在很多语言任务上表现好但它学到的语言知识大量和视觉无关蒸馏的时候反而会带来噪声。自研小文本塔配合对齐层做端到端训练更直接。2.2 图像语义空间与对齐层光有文本向量还不够模型必须知道「描述中的词」和「画面中的像素区域」之间的对应关系。nano-banana 的第二个模块是图像特征提取与语义对齐层。训练图像会先经过一个轻量的图像编码器映射成潜在的图像特征序列。然后通过对比学习的方式让文本向量和图像特征在同一个向量空间里靠得足够近。这一步做的是「跨模态对齐」本质上和很多图文检索模型做的事情是一样的只是 nano-banana 把对齐结果直接作为生成模型的启动条件。我自己的经验是对齐层的质量几乎决定了最终生成图像的上限。如果文本向量和图像特征没有在训练中充分对齐后面的扩散模型哪怕再强也像是在听一个口音极重的导游用模糊的手势指路——方向是有的但一定会跑偏。2.3 扩散生成从噪声倒推画面核心生成模块用的是轻量化的扩散模型Denoising Diffusion Model。扩散模型的工作原理可以粗暴地理解成一个「倒放」过程训练时不断给图片加噪声直到画面完全变成一片随机噪点生成时则从纯噪声出发一步步预测并去除噪声让图像从混沌中逐渐显现。nano-banana 选的主干结构是 DiT 的轻量版也就是把图像当成序列化的视觉 Token用 Transformer 来预测每一步的噪声。相比传统的 UNet 结构DiT 在相同参数下更容易利用文本条件做交叉注意力注入训练过程也更稳定。整个生成主干控制在 2.5 亿参数左右先输出 128x128 的低分辨率图再由独立的超分模块放大到 512x512。2.4 上采样与后处理低分辨率图直接输出显然是没法用的。nano-banana 的超分模块没有采用复杂的生成式超分模型而是用了一个相对轻量的增强网络专门学习从 128x128 到 512x512 的细节补全。这里有个关键取舍超分模块不能做太重否则推理时间会翻倍但也不能太弱否则放大后的图会有明显的涂抹感。实测下来把超分模块放在扩散模型后面单独训练而不是和生成主干一起端到端训练效果更好。原因是生成主干只需要关注低分辨率下的构图和语义正确性超分模块专心补细节两者各管一段任务分工越清晰小模型越不容易出现两头不到岸的情况。2.5 模块协作数据流整个 nano-banana 的单次推理流程可以浓缩成下面的数据流Prompt 输入文本编码器得到 1x768 维的文本语义向量。向量经过对齐层映射成扩散模型能理解的图像条件特征通常是 77x768 的序列。扩散模型随机初始化一个 128x128 的噪声图逐步去噪每一步都用交叉注意力参考文本条件。迭代 20 到 30 步后低分辨率图像逐渐成形。超分模块放大到 512x512做最后一步锐化输出最终图像。每一步的参数我都记录在了一份配置表里后面调试的时候全靠它对照找问题这个习惯建议大家也养成。小模型项目参数少互相牵连也很少反而更容易定位问题出在哪个模块。3. 多模态对齐的设计细节文本向量如何真正「看懂」画面3.1 文本编码器的理想容量很多新手做 MLLM 绘图会理所当然地认为文本编码器越大越好我一开始也这么想后来被实验数据打脸了。在同样训练数据和同样生成主干的条件下我把文本编码器从 3 亿参数压缩到 1.5 亿参数图像质量在多数简单 Prompt 下几乎没有下降但在涉及多个物体关系的复杂 Prompt 上明显变弱。这说明一个问题小型文本编码器在复杂语义解析上的瓶颈不是单纯靠堆参数就能解决的更多是训练目标和表示空间的匹配问题。对 nano-banana 来说真正有效的做法是在文本编码器的训练阶段就混入大量「图像描述风格」的语料比如短句、属性词、空间介词、颜色词。而不是指望模型自己从通用文本里悟出视觉关系。文本塔见过的表达方式越接近真实绘图场景对齐效果就越好。3.2 我试过的三种对齐方案对比关于跨模态对齐层的设计我用三组实验做了横向对比结果很有参考价值。对齐方案实现难度语义保真度生成稳定性最终选择线性映射极低一般中等否单层 Transformer 跨注意力中等较好较高是Q-Former 风格查询向量高优秀高备选线性映射最省事就是把文本向量乘一个参数矩阵变成图像特征。问题在于它是逐点映射无法处理文本序列内部的词序关系和语义组合遇到「蓝色的花和红色的叶子」这种需要区分属性归属的 Prompt 就直接混乱。单层 Transformer 跨注意力是我最终采用的方案具体做法是让图像特征序列作为 Query文本特征序列作为 Key 和 Value通过一层注意力交互让每个图像位置都能从文本序列中「查询」到关联的语义信息。这么做的好处是保留了文本内部的顺序和组合信息生成时语义保真度明显高于线性映射。Q-Former 风格的效果最好但参数量和训练开销也上来了。对 nano-banana 的定位来说收益不够大最终没有采用不过如果你有更大的显存余量可以优先考虑这种方案。3.3 交叉注意力在生成阶段的实际作用对齐层做好之后还有一个关键设计扩散模型在生成时需要持续参考文本条件而不是只在最开始用一次。nano-banana 的 DiT 主干里每隔两层就会做一次交叉注意力让视觉 Token 和文本条件重新融合一遍。这个设计对小模型尤其重要。小模型的容量有限如果文本条件只在第一步注入生成到后半程时模型早就把最初的任务「忘」得差不多了。我试过只在第一层注入文本条件出来的图经常出现「主体漂移」——一开始像是按 Prompt 画的越到后面越偏离题意。改成隔层注入后这个问题大幅缓解。代价是计算量稍有增加但视觉一致性提升非常明显。如果你要自己搭类似的模型强烈建议把交叉注意力分散到多个深度位置不要图省事只做单点注入。3.4 中文输入为什么比英文更容易翻车nano-banana 支持中英文双语输入但从实验结果看中文的绘图质量明显比英文低一截。这不是模型有偏见而是中文描述的特点在作祟。中文的语序灵活很多修饰语可以放在主语前后而且中文很少用冠词和介词显式标记关系。比如「一只坐在椅子上的猫」和「椅子上一只猫坐着」描述的是同一个画面但分词后的 Token 序列差异很大。小型文本编码器很难从这种灵活语序里稳定提取潜台词。我的应对方案有两个第一在文本编码器预训练阶段加入大量中文图像描述语料让编码器提前适应中文的修饰语位置变化第二在训练数据里把中文描述统一做一次简单的句式归一化让同一语义尽量用相近的表达方式进训练集。这两步做完中文绘图成功率提高了不少但仍然没有赶上英文的稳定性目前只能算「堪用」。4. 训练细节与显存调优在消费级显卡上把项目跑通4.1 训练数据准备质量比数量更关键nano-banana 的训练数据来自公开图文数据集但我没有直接拿原始数据硬灌。第一轮清洗就筛掉了约 40% 的数据主要针对三类问题。第一类是无意义水印图图上盖着一大片半透明 logo模型很容易把水印当成画面内容生成结果里到处是奇怪的文字纹路。第二类是图文不符描述文本和图像内容匹配度低这类数据训练多了会让模型学会「胡说八道」。第三类是低分辨率图直接拉低超分模块的学习上限。清洗之后我保留了大约 120 万条高质量的图文对。这个量级对大型模型来说可能九牛一毛但配合分阶段训练策略足够支撑 nano-banana 练出可用能力。4.2 分阶段训练先学对齐再学生成一次性端到端训练所有模块是我第一次实验失败的主要原因。模型同时要学文本理解、跨模态对齐、去噪生成任务太杂小模型的优化路径根本走不稳定。后来我把训练拆成了三个阶段。阶段一是对齐预训练。冻结生成主干只训练文本编码器的一部分层和对齐层目标是让文本向量和图像特征的距离拉近。这个阶段不需要生成图像训练速度快损失函数用的是对比学习损失。阶段二是生成主干微调。冻结对齐层开放 DiT 主干。这个阶段模型开始真正「画图」损失函数是扩散模型的标准噪声预测损失。文本编码器大部分层继续冻结防止在生成任务上出现过拟合式的偏移。阶段三是联合微调。此时才解锁全部核心参数用很小的学习率端到端更新。这一步的目的是消除模块之间残留的配合误差让整条链路顺滑跑通。三个阶段各有侧重比一步到位收敛快得多最终质量也更高。4.3 显存优化三板斧模型整体不大但加上训练中间变量显存压力依然存在。我在 8GB 显存的显卡上跑通了训练流程主要靠三个手段。首先是梯度检查点。训练时不再保留每一层的中间激活值而是在反向传播时重新计算用时间换空间。开合梯度检查点后训练显存直接降了大约 35%速度损失在 15% 左右完全能接受。其次是混合精度。训练全程使用了 bf16 混合精度梯度计算和参数更新用高精度中间张量用低精度。这一步不仅省显存还顺带把训练速度提升了 20% 上下。小模型对精度的敏感度低于大模型bf16 对收敛质量的影响微乎其微。最后是梯度累积。受限于显存每批只能喂 8 条样本但我想等效模拟 32 的批大小于是每 4 步累积一次梯度再更新参数。这种做法能让小批次的噪声梯度被平滑掉训练稳定性提升明显。4.4 一份可供参考的训练配置训练时最重要的几个超参数我整理成了一张表。具体数值请结合自己的数据和显卡情况做调整但它可以作为起步的锚点。配置项数值备注文本编码器参数量1.5 亿自研小文本塔生成主干参数量2.5 亿轻量 DiT生成分辨率128x128后接超分最终输出分辨率512x512超分模块放大对比学习批次大小256对齐阶段扩散训练批次大小32梯度累积后等效初始学习率3e-4联合微调降到 5e-5扩散步数1000训练时推理只需 20-30 步采样器DPM 2M质量与速度折中训练日志里我特别关注两个指标对齐阶段的语义召回率以及生成阶段的可感知图像质量。这两个指标一个负责判断「理解对不对」一个负责判断「画得好不好」任何一项掉下去都值得停下来查超参。5. 实测表现与常见翻车点nano-banana 能做到什么、做不到什么5.1 表现合格的三类场景nano-banana 在简单场景上的表现其实比很多人的预期要好。实测下来以下三类 Prompt 的生成效果称得上「稳定可用」。一是单物体加上简单属性。比如「一只橘色的猫坐在窗台上」模型能准确生成橘色、坐姿、窗台这三个关键元素背景处理也比较干净。二是自然风景短句。比如「日落时的海边有棕榈树」构图通常合理色彩氛围到位。三是抽象风格描述。比如「低多边形风格的山脉」模型能从训练数据里学到风格特征输出结果具备很强的风格辨识度。在这些场景下单张图生成时间在 2 到 4 秒之间显存占用 6GB 左右符合当初的立项指标。对于做创意素材批量预览、早期概念稿快速出图这个水平的输出已经足够用了。5.2 一遇到复杂语义就崩的典型问题说实话nano-banana 的翻车场面也很有规律。我觉得最有代表性的几个问题是这样的。多人称关系错乱是最频繁出现的翻车类型。比如「两个人面对面下棋」模型经常画成两个人肩并肩坐着对「面对面」的空间逻辑理解基本失效。原因是小型文本编码器在空间位置关系上的语料覆盖太薄它知道有人、知道下棋但无法把「面」的方位指令落实到构图。数量信息失真也经常发生。输入「三只鸟在电线杆上」模型偶尔会画出两只或四只鸟。小模型对精确数量的感知非常不稳定。定量语料在训练数据中占比本来就不高加上生成时没有可靠的约束机制模型倾向于凭概率分布「自由发挥」数量。中文多属性绑定的失败率更高。输入「红色领带配蓝色西装的男人」模型有概率把领带和西装的颜色搞反甚至直接把颜色混在一起。问题出在属性归属的建模上小模型无法稳定地区分「A 的颜色」和「B 的颜色」这两组绑定关系。5.3 我的补救手段与调参心得翻车不可怕关键是有没有补的手段。我在 nano-banana 上试过几种补救策略有些效果不错有些直接放弃。负面提示调参法在推理时额外提供一个「不要出现的东西」的文本约束比如输入「没有多余人、没有文字水印」能明显改善画面干净度。小模型生成的图容易带多余物体和文字噪声负面提示是性价比最高的过滤器。CFG 引导系数调整是我调得最多的参数。CFG 控制模型对文本条件的服从程度数值太低模型自由发挥数值太高画面容易出现过度饱和的伪影。nano-banana 在 4.5 到 7.0 之间表现最好我最终固定在 5.5。每次换 Prompt 类型我都会先快速扫一遍 CFG 区间再大批量生成。采样器换用 DPM 之后画质整体提升明显。相比基础采样器DPM 在 20 步内就能达到较满意的收敛质量细节纹路更干净伪影更少。如果你在复现类似项目建议直接把它作为默认采样器。超分增强则无法救回逻辑错误。超分模块能补细节、补边缘、补纹理但没有能力修正语义错误。它会把「两个人并肩下棋」放大成细节更清晰的「两个人并肩下棋」不会帮你把座位关系改对。这种错误必须在生成主干层面解决靠后处理是徒劳的。5.4 后续还能往哪些方向扩展nano-banana 现在能跑通但它离一个完整的产品化 MLLM 绘图工具还有不小距离。我自己思考过几个可行的扩展方向也打算后面逐步实验。蒸馏更大模型到 nano-banana 的骨干是最有潜力的方向。用高阶模型做教师把复杂 Prompt 的语义理解能力蒸馏到小模型里有机会解决一部分数量感知和空间关系的问题比单纯标注新数据更高效。接入智能体链路让 nano-banana 成为其中一环。用户可以先用大模型把模糊想法拆解成适合绘图的短句再交给 nano-banana 快速出图。这避开了小模型的理解短板只发挥它的生成速度优势是很务实的组合方式。量化到更低精度比如把模型压缩到 int8 或 int4可以进一步降低推理成本。nano-banana 虽然已经轻量但还没有尝试极限压缩如果固定场景使用且不需要训练可以走这条路线。我个人的体感是轻量多模态绘图的边界不在模型本身而在你如何使用它。每垮掉一道关卡翻车点就少一个模型的可用场景就多一圈。nano-banana 四百兆的体量能换来一整套端到端绘图能力这个性价比已经远超我立项时的预期。下一步我大概率会拿它的蒸馏版和大模型调度做一次整合实验把「小模型自己的答案」换成「大模型出题、小模型作答」的新协作模式。绘图这件事路还长着。