MOSS-Image-SFT 开源解读JSON 布局控制文字与排版MOSS-Image-SFT 是少数把布局当成一等输入的开放权重模型值得排进试用名单①**5B只指 DiT 主干**整包约 13.5B / 27.2GB其中 Qwen3.5-9B 文本编码器占 16.8GB比主干还大②官方分数LLTB 96.3、7Bench mIoU 0.88、RLA Elo全部出自自建基准 官方自测。关键词MOSS-Image文生图JSON 布局文字渲染DiTDiffusersComfyUI开源模型显存文章目录MOSS-Image-SFT 开源解读JSON 布局控制文字与排版一、模型速览二、它想解决的问题让模型知道字该写在哪三、架构拆解5B 主干 9B 编码器 FLUX.2 VAE四、核心能力三种输入形式与原生 JSON 布局4.1 同一个接口三种提示4.2 JSON 布局的字段结构4.2.1 bbox 从哪来4.3 布局还能当编辑用4.4 中英双语长文本五、Base 与 SFT该下哪个六、评测三张卷子但都是自己出的6.1 官方给出的分数6.2 必须说清楚的口径问题七、上手环境、代码与显存账单7.1 环境7.2 最小调用7.3 默认采样参数7.4 显存账单八、小结一、模型速览项目内容模型名称MOSS-Image-SFT发布方OpenMOSS开源组织openmoss论文与技术报告署名MOSI.AI权重发布2026-10-16与技术报告同步基座模型OpenMOSS-Team/MOSS-Image-Base关系finetune任务类型text-to-image-synthesis文生图生成主干5B 单流扩散 TransformerDiT从零预训练文本编码器Qwen3.5-9B冻结4096 维经线性投影到 3072VAEFLUX.2 VAE32 个潜通道空间下采样 82×2 潜 patch → 有效步长 16 像素提示形式自然语言 / 标签序列tag/JSON 布局提示长度最长4K tokens分辨率示例 1024×1024、1456×1456宽高需为16 的整数倍支持约 0.25M–4M 像素整包权重约 27.2 GB8 个 safetensors 分片参数规模约13.5B按权重元数据推算官方 README 未直接给出总数许可证Apache-2.0权重管线代码与第三方组件各自保留原有许可平台数据魔搭下载8,518次、Star46截至 2026-10-20在线体验平台未内置 Demo官方提供 Hugging Face Space 演示一个容易被忽略的口径问题宣传里的5B指的是扩散主干不含文本编码器。所以5B 的文生图模型并不等于下载 10GB 就能跑——整包 27.2GB其中文本编码器占 16.8GB比主干还大。第七章的显存账单会说明这 16.8GB 直接决定了你的卡能不能装下。二、它想解决的问题让模型知道字该写在哪现阶段的开放权重文生图模型普遍卡在同一件事上密集文字会糊、复杂版面会散。业界的应对通常有三条路路径做法代价外挂控制ControlNet / 深度图 / 分割图约束构图要额外模型与工作流且不解决字写得对不对后期排版先生成底图再 P 文字结果可控但费人力本质不是模型能力原生布局把元素与坐标直接写进 prompt模型原生理解需要模型在预训练阶段就见过这种监督信号MOSS-Image 选的是第三条。技术报告摘要里的原话是闭源系统已经能生成信息密集的图形而开放权重模型在密集文字与复杂布局上仍有明显差距MOSS-Image 的目标是高保真视觉合成 意图感知构图。它自建了LongLongTextBenchLLTB与RealLayoutArenaRLA两个基准分别对应长文本渲染和端到端布局生成这两件它想证明的事。三、架构拆解5B 主干 9B 编码器 FLUX.2 VAE组件规格权重体积扩散主干5B 单流 DiT42 个联合 blockhidden 307224 头 × 128 维FFN 8192SiTU-GLU四轴 RoPE≈ 10.2 GB3 分片文本编码器Qwen3.5-9B冻结输出 4096 维 → 线性投影至 3072另有 2 个纯文本 transformer block≈ 16.8 GB4 分片VAEFLUX.2 VAE源自 FLUX.2-klein-4B32 潜通道下采样 8≈ 0.25 GB合计—≈ 27.2 GB几个值得注意的设计取舍文本编码器冻结、且比主干大。这是用大编码器换文字理解力的典型做法Qwen3.5-9B 的语言与多语言能力直接决定它能不能读懂长 prompt 和中文内容。代价是推理时必须把 16.8GB 的编码器也搬进来——除非你让它待在 CPU 上。从头预训练from scratch而非改造现成模型。技术报告给出的训练配方是三阶段渐进分辨率256px 跑 2.1M 步 → 512px 跑 2.1M 步 → 约 1024² 跑 0.31M 步每样本最大 token 从 576 递增到 3072、8192语料为 ReLAION 衍生集去重并剔除 AI 生成图后从约 50 亿降到 30 亿张优化器为Muon–AdamW 混合报告称 1B 参数消融下同等损失比纯 AdamW 少约 33.2% / 28.6% 的步数。VAE 直接沿用 FLUX.2 的隐空间。好处是生态互通ComfyUI 的 VAE、潜空间工具链可以直接复用。需要说明以上训练细节来自技术报告的公开描述与第三方解读官方模型卡本身没有披露训练数据构成与超参。四、核心能力三种输入形式与原生 JSON 布局4.1 同一个接口三种提示提示形式适用场景特点自然语言常规创作、写实/动漫风格图最省事但位置只能靠描述标签序列tag动漫风、二次元风格化与社区常见 tag 习惯兼容JSON 布局海报、信息图、UI 稿、白板可精确指定元素与文字的位置4.2 JSON 布局的字段结构官方给出的坐标规范有两个关键点bbox_format: yxyx即[y_min, x_min, y_max, x_max]bbox_coord_space: abs_centralized以画布中心为原点的绝对像素坐标不是 0–1 相对坐标。{summary:{canvas:1024x1456,caption:A travel poster about mountains, clean layout},items:[{label:text,text:EXPLORE,bbox:[-460,-420,-300,420]},{label:object,caption:an illustration of blue mountains,bbox:[40,-380,420,380]}],bbox_format:yxyx,bbox_coord_space:abs_centralized}上面是结构示意字段名与坐标规范来自官方用户指南具体取值需按画布尺寸自行计算。把这段 JSON 用json.dumps(layout, ensure_asciiFalse)序列化后直接当 prompt 传入即可不需要额外的控制分支。选择绝对中心坐标而不是相对坐标官方给出的理由是更适合多分辨率但对使用者的实际影响是你现有的提示词/布局逻辑要重写换分辨率时坐标也要跟着换算。这是迁移成本不是免费的能力升级。4.2.1 bbox 从哪来这是文档里最容易被跳过、上手时最先卡住的一步没有人会手算画布中心坐标。转换公式本身很简单——左上原点的(x1, y1, x2, y2)减去画布中心后按yxyx重排defto_abs_centralized(box,w,h):左上原点 xyxy - abs_centralized yxyx。x1,y1,x2,y2box cx,cyw/2,h/2return[round(y1-cy),round(x1-cx),round(y2-cy),round(x2-cx)]# 1024x1024 画布文字框左上角 (100, 80)、右下角 (500, 200)print(to_abs_centralized((100,80,500,200),1024,1024))# - [-432, -412, -312, -12]真正的工序不在这里而在于框是哪来的正常流程是先有版面、再填 JSON——从设计稿导坐标、用目标检测或 OCR 拿框、或者让一个 VL 模型先把版式描述成 JSON再交给 MOSS-Image 渲染。指望模型自己读懂一段自然语言就精确排在你想要的位置等于放弃了你唯一的确定性优势。4.3 布局还能当编辑用把 JSON 当成一份可修改的构图说明书改文字内容、改元素描述、改边界框再重跑一次其余区域通常会在布局约束下保持相近。这比完全重新生成一遍碰运气可控得多。但有两件事要说清楚①它不是图像编辑模型——输入仍是文本 / JSON不是一张图 一句指令官方定位就是文生图②改完 JSON 之后整张图是重新生成的没改动的元素只是在布局约束下倾向于保持原样不是像素级不变。把它当成精确局部编辑会失望。4.4 中英双语长文本官方示例直接让模型在冰箱便签上手写三段中文“记得买牛奶和鸡蛋牛奶两盒鸡蛋一打。顺便带一袋面包。”并把双语长文本渲染写进了技术报告的核心能力。第三方早期实测也提到日文文字生成接近完美、人体解剖结构优于部分 FLUX 变体——不过这类单点反馈不能当作系统性结论。五、Base 与 SFT该下哪个维度MOSS-Image-BaseMOSS-Image-SFT定位预训练检查点为微调保留在精选数据上微调推荐直接推理架构与推理接口完全相同完全相同官方说明Base 刻意不做后训练与 CFG 蒸馏便于社区训练 LoRA文字分组更清晰、白板版面更规整适合谁要自己微调、训 LoRA、做领域适配想直接出图、做海报/信息图的普通用户一句话出图用 SFT微调用 Base。Base 未经推理侧的后训练参数敏感、随手提示效果不稳官方也只给了定性对比图同参数同 seed没有分数。六、评测三张卷子但都是自己出的6.1 官方给出的分数基准指标MOSS-Image对照LLTB长文本渲染240 个任务120 英/120 中平均文字覆盖率96.3英文 97.1 / 中文 92.4GPT Image 299.0、Nano Banana Pro 96.6、Qwen-Image-2512 64.97Bench布局控制平均 IoU / Layout AUC0.88 / 0.70Ideogram 4.0 0.44 / 0.16–0.20Nano Banana Pro、Seedream 5.0 Pro 均 0.33GPT Image 2 0.30RLA端到端布局生成Elo1698.70第 2GPT Image 2 1844.35第 1、Seedream 5.0 Pro 1661.16、Qwen Image 3.0 Pro 1614.84、Nano Banana Pro 1590.19RLA仅骨干共用增强提示Elo1807.34第 1ERNIE Image 1748.51、SenseNova-U1 1689.23读表提醒LLTB 那行的 96.3 是官方汇总口径与表中英文 97.1 / 中文 92.4两个子项的算术平均94.75对不上。差异可能来自按 token 或按任务加权也可能是汇总时另含子集——这一点只有技术报告正文能说清转述时不要直接把 96.3 当成中英平均。其中两个数字值得单独看布局接口的消融同一个系统JSON 布局提示1622.87vs 自然语言提示1506.20差约117 Elo是下面要说的 CI 半宽约 42.5的两倍多。方向上明确支持布局接口是主要增益来源但两个分数出自同一批盲测样本、误差并不独立所以这是强信号不是可写进结论的显著性检验。开源权重内的最好成绩LLTB 96.3 是开放权重模型里的最高值但仍低于闭源的 GPT Image 299.0——官方把这行自己输的数据也列了出来。6.2 必须说清楚的口径问题这部分比分数本身更重要问题具体说明全部为厂商自测两个基准LLTB、RLA由官方自建基线分数由官方自己跑别家模型得出无第三方复现、无审计端到端成绩混入了第三方模型官方提示增强模块Prompt Enhancer面向GPT-6 系列 agent第三方分析指出最强端到端 Elo 实际上是双模型流水线不纯是生成器能力样本量与置信区间RLA 仅 61 个任务20 海报 / 20 信息图 / 21 UI、人工盲测95% CI 为1656–1741即 1698.70 ±42.5、宽度约 85 Elo排名差距小于误差第 2 名 MOSS1698.70与第 3 名 Seedream 5.0 Pro1661.16只差37.5 Elo小于半宽 42.5两条区间大幅重叠——第 2这个名次本身分不出高下能说的只是进入第一梯队指标接受度7Bench 上 0.88 对 0.30–0.44 的差距由指标作者本人测得LLTB 的文字覆盖率口径需看报告正文才能判断严苛程度模型卡无分数魔搭与项目页都没有列任何 benchmark 数值只有定性对比图所有数字需回到技术报告结论可以把这组数据当作官方内部记分板来读——它足以说明在它自己定义的任务上布局接口确实有效但不足以证明它在通用画质或综合体验上领先。七、上手环境、代码与显存账单7.1 环境# Linux / macOS / Git Bash反斜杠续行有效pipinstalldiffusers0.38transformers5.3accelerate1.10\safetensors0.6Pillow10# Windows PowerShell / CMD反斜杠不是续行符直接写一行pip installdiffusers0.38transformers5.3accelerate1.10safetensors0.6Pillow10Python ≥ 3.10、PyTorch ≥ 2.9、NVIDIA GPU CUDA官方明确要求不支持纯 CPU 推理。在 Windows 上除了这一条还要注意transformers5.3对 CUDA 版本的要求——装之前先用nvidia-smi对一下驱动比装完再回退快得多。7.2 最小调用importtorchfromdiffusersimportDiffusionPipeline pipeDiffusionPipeline.from_pretrained(OpenMOSS-Team/MOSS-Image-SFT,custom_pipelinepipeline_moss_image,trust_remote_codeTrue,# 分模块指定精度主干与编码器 bf16VAE 必须留在 fp32torch_dtype{default:torch.bfloat16,vae:torch.float32},)# 照搬自官方 README。from_pretrained 已自带默认调度器# 这行只是按 config 显式重建一次删掉不影响出图结果pipe.schedulertype(pipe.scheduler).from_config(pipe.scheduler.config)pipe.to(cuda)# 27.2GB 全驻留显存不够先看 7.4别硬扛promptA wide view of a refrigerator beside a kitchen counter with a fruit bowl. A small sticky note on the refrigerator door is handwritten in Chinese: 记得买牛奶和鸡蛋牛奶两盒鸡蛋一打。顺便带一袋面包。imagepipe(prompt,height1024,width1024,num_inference_steps50,guidance_scale3.0,uncond_skip_layers[22],generatortorch.Generator(cpu).manual_seed(42),).images[0]image.save(refrigerator_note.png)四个必须知道的细节custom_pipelinepipeline_moss_image与trust_remote_codeTrue都不能省少任一个都会在加载阶段直接报错。精度是分模块的VAE 与初始噪声用 float32主干与文本编码器用 bfloat16。把 VAE 也压成 bf16 是常见的省显存操作代价是出图颜色/细节异常别顺手改。宽高必须是16 的整数倍否则在 VAE 的 2×2 潜 patch 那一步对不齐。uncond_skip_layers[22]默认开启意味着CFG 要算两次前向见 7.3 的成本说明。7.3 默认采样参数项默认值采样器Flow-matching Euler步数50CFG3shift5层跳过负分支第 22 层uncond_skip_layers[22]类似 SLG负向提示空注意成本默认引导路径每步要做 2 次 Transformer 前向50 步并不便宜。关掉uncond_skip_layers或改用少步蒸馏 LoRA 都会改变画质与风格的平衡需自行验证。7.4 显存账单官方没有公布任何显存数字只在显存不足时建议切 Sequential 模式或降分辨率。可参考的公开数据有两类① 官方 Demo 的硬件Hugging Face Space 跑在**单张 A10G24GB**上。这个数字比看上去更有信息量A10G 只有 24GB而下面的估算表说 BF16 全驻留 1MP 就要 30GB——这两件事不可能同时成立。合理的解释只有一个官方 Demo 没有全驻留必然用了 Sequential / CPU offload 这类分时搬运。也就是说24GB 能跑起来和24GB 能跑得舒服是两件事官方 Demo 展示的是前者你如果照着跑出图速度会明显慢于预期。② 第三方的规划级估算明确标注估算、非实测请留余量配置1MP1024²约 2MP4MP2048²BF16全部驻留显存约 30.0 GB约 32.2 GB约 36.6 GBBF16文本编码器放 CPU约 13.2 GB约 15.4 GB约 19.8 GB8-bit 权重编码器放 CPU约 8.1 GB约 10.3 GB约 14.7 GB4-bit 权重编码器放 CPU约 6.1 GB约 8.3 GB约 12.7 GB给你的实际判断想装得下关键是把 16.8GB 的文本编码器挪到 CPU想跑得快则要显存全驻留。社区已有 INT8 / W4A8 / GGUF 量化与 8 步蒸馏 LoRA官方未背书可在 8–12GB 显卡上试但质量与稳定性需自行验证。另有社区在 RTX 5090 上用 INT8 50 步跑 4MP 约 55 秒的记录——单点样本仅供参考。八、小结维度结论是什么OpenMOSS 开源的文生图模型5B DiT 主干 Qwen3.5-9B 文本编码器Base 的 SFT 版最大差异点原生 JSON 布局元素/文字/bbox 直接写进 prompt不依赖 ControlNetprompt 上限 4K tokens最实用的能力中英双语长文本渲染、可编辑的版面改字/改框即可调构图成绩官方自测LLTB 文字覆盖率 96.3开源最高仍低于 GPT Image 2 的 99.0、7Bench mIoU 0.88、RLA 系统第 2 / 骨干第 1代价整包 27.2GB、BF16 全驻需约 30GB 显存官方未给显存与速度指标许可Apache-2.0 仅覆盖权重编码器与 VAE 沿用各自许可不宜直接判定为商用友好风险评测全部自测、vLLM-Omni 支持仍停在未合并 PR、生态量化均非官方一句话总结MOSS-Image-SFT 的价值不在于又一个开源文生图模型而在于它把版式变成了模型的一等输入——元素、文字、边界框都能直接写进 prompt不必另挂 ControlNet。对海报、信息图、UI 稿这类布局本身就是交付物的场景这是开放权重模型过去最缺的一环。但它同时是个边界划得很清楚的发布评测是自己出的卷子、最强的端到端成绩混入了第三方提示增强、官方连显存数字都没给。所以建议得分档给不能一句值得上手打发手上有 ≥24GB 显存、且正在做带文字的版式类需求值得试。先跑通 SFT 1024²确认文字覆盖与排版符合预期再考虑 4MP。只有 8–12GB 消费卡等社区量化再成熟一轮或者接受 Sequential 模式的速度损耗。要通用画质对标、要托管 API、要下载就能用现在都不合适。这个模型的默认形态就是大权重 重配置它的收益只在位置要准这件事上兑现。