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 布局 文字渲染 DiT Diffusers ComfyUI 开源模型 显存

文章目录

[MOSS-Image-SFT 开源解读：JSON 布局控制文字与排版](#MOSS-Image-SFT 开源解读：JSON 布局控制文字与排版)
- 一、模型速览
- 二、它想解决的问题：让模型"知道字该写在哪"
- [三、架构拆解：5B 主干 + 9B 编码器 + FLUX.2 VAE](#三、架构拆解：5B 主干 + 9B 编码器 + FLUX.2 VAE)
- [四、核心能力：三种输入形式与原生 JSON 布局](#四、核心能力：三种输入形式与原生 JSON 布局)
- - [4.1 同一个接口，三种提示](#4.1 同一个接口，三种提示)
  - [4.2 JSON 布局的字段结构](#4.2 JSON 布局的字段结构)
  - - [4.2.1 bbox 从哪来](#4.2.1 bbox 从哪来)
  - [4.3 布局还能当"编辑"用](#4.3 布局还能当"编辑"用)
  - [4.4 中英双语长文本](#4.4 中英双语长文本)
- [五、Base 与 SFT：该下哪个](#五、Base 与 SFT：该下哪个)
- 六、评测：三张卷子，但都是自己出的
- - [6.1 官方给出的分数](#6.1 官方给出的分数)
  - [6.2 必须说清楚的口径问题](#6.2 必须说清楚的口径问题)
- 七、上手：环境、代码与显存账单
- - [7.1 环境](#7.1 环境)
  - [7.2 最小调用](#7.2 最小调用)
  - [7.3 默认采样参数](#7.3 默认采样参数)
  - [7.4 显存账单](#7.4 显存账单)
- 八、小结

一、模型速览

项目	内容
模型名称	MOSS-Image-SFT
发布方	OpenMOSS （开源组织 `openmoss`，论文与技术报告署名 `MOSI.AI`）
权重发布	2026-10-16（与技术报告同步）
基座模型	`OpenMOSS-Team/MOSS-Image-Base`（关系：finetune）
任务类型	text-to-image-synthesis（文生图）
生成主干	5B 单流扩散 Transformer（DiT），从零预训练
文本编码器	Qwen3.5-9B（冻结），4096 维经线性投影到 3072
VAE	FLUX.2 VAE（32 个潜通道，空间下采样 8，2×2 潜 patch → 有效步长 16 像素）
提示形式	自然语言 / 标签序列（tag）/ JSON 布局
提示长度	最长 4K tokens
分辨率	示例 1024×1024、1456×1456；宽高需为 16 的整数倍，支持约 0.25M--4M 像素
整包权重	约 27.2 GB（8 个 safetensors 分片）
参数规模	约 13.5B（按权重元数据推算，官方 README 未直接给出总数）
许可证	Apache-2.0（权重；管线代码与第三方组件各自保留原有许可）
平台数据	魔搭下载 8,518 次、Star 46（截至 2026-10-20）
在线体验	平台未内置 Demo；官方提供 Hugging Face Space 演示

一个容易被忽略的口径问题：宣传里的"5B "指的是扩散主干 ，不含文本编码器。所以"5B 的文生图模型"并不等于"下载 10GB 就能跑"------整包 27.2GB，其中文本编码器占 16.8GB，比主干还大。第七章的显存账单会说明这 16.8GB 直接决定了你的卡能不能装下。

二、它想解决的问题：让模型"知道字该写在哪"

现阶段的开放权重文生图模型，普遍卡在同一件事上：密集文字会糊、复杂版面会散。业界的应对通常有三条路：

路径	做法	代价
外挂控制	ControlNet / 深度图 / 分割图约束构图	要额外模型与工作流，且不解决"字写得对不对"
后期排版	先生成底图，再 P 文字	结果可控但费人力，本质不是模型能力
原生布局	把元素与坐标直接写进 prompt，模型原生理解	需要模型在预训练阶段就见过这种监督信号

MOSS-Image 选的是第三条。技术报告摘要里的原话是：闭源系统已经能生成"信息密集的图形"，而开放权重模型在密集文字与复杂布局上仍有明显差距；MOSS-Image 的目标是高保真视觉合成 + 意图感知构图 。它自建了 LongLongTextBench（LLTB） 与 RealLayoutArena（RLA） 两个基准，分别对应"长文本渲染"和"端到端布局生成"这两件它想证明的事。

三、架构拆解：5B 主干 + 9B 编码器 + FLUX.2 VAE

组件	规格	权重体积
扩散主干	5B 单流 DiT，42 个联合 block，hidden 3072，24 头 × 128 维，FFN 8192（SiTU-GLU），四轴 RoPE	≈ 10.2 GB（3 分片）
文本编码器	Qwen3.5-9B（冻结），输出 4096 维 → 线性投影至 3072，另有 2 个纯文本 transformer block	≈ 16.8 GB（4 分片）
VAE	FLUX.2 VAE（源自 FLUX.2-klein-4B），32 潜通道，下采样 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 相对坐标）。

json 复制代码

{
  "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_ascii=False) 序列化后直接当 prompt 传入即可，不需要额外的控制分支。

选择"绝对中心坐标"而不是相对坐标，官方给出的理由是更适合多分辨率 ；但对使用者的实际影响是：你现有的提示词/布局逻辑要重写，换分辨率时坐标也要跟着换算。这是迁移成本，不是免费的能力升级。

4.2.1 bbox 从哪来

这是文档里最容易被跳过、上手时最先卡住的一步：没有人会手算画布中心坐标 。转换公式本身很简单------左上原点的 (x1, y1, x2, y2) 减去画布中心后按 yxyx 重排：

python 复制代码

def to_abs_centralized(box, w, h):
    """左上原点 xyxy -> abs_centralized yxyx。"""
    x1, y1, x2, y2 = box
    cx, cy = w / 2, h / 2
    return [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-Base	MOSS-Image-SFT
定位	预训练检查点，为微调保留	在精选数据上微调，推荐直接推理
架构与推理接口	完全相同	完全相同
官方说明	Base 刻意不做后训练与 CFG 蒸馏，便于社区训练 LoRA	文字分组更清晰、白板版面更规整
适合谁	要自己微调、训 LoRA、做领域适配	想直接出图、做海报/信息图的普通用户

一句话 ：出图用 SFT，微调用 Base。Base 未经推理侧的后训练，参数敏感、随手提示效果不稳，官方也只给了定性对比图（同参数同 seed），没有分数。

六、评测：三张卷子，但都是自己出的

6.1 官方给出的分数

基准	指标	MOSS-Image	对照
LLTB（长文本渲染，240 个任务：120 英/120 中）	平均文字覆盖率	96.3（英文 97.1 / 中文 92.4）	GPT Image 2 99.0、Nano Banana Pro 96.6、Qwen-Image-2512 64.9
7Bench（布局控制）	平均 IoU / Layout AUC	0.88 / 0.70	Ideogram 4.0 0.44 / 0.16--0.20；Nano Banana Pro、Seedream 5.0 Pro 均 0.33；GPT Image 2 0.30
RLA（端到端布局生成）	Elo	1698.70（第 2）	GPT Image 2 1844.35（第 1）、Seedream 5.0 Pro 1661.16、Qwen Image 3.0 Pro 1614.84、Nano Banana Pro 1590.19
RLA（仅骨干，共用增强提示）	Elo	1807.34（第 1）	ERNIE Image 1748.51、SenseNova-U1 1689.23

读表提醒：LLTB 那行的 96.3 是官方汇总口径，与表中"英文 97.1 / 中文 92.4"两个子项的算术平均（94.75）对不上。差异可能来自按 token 或按任务加权，也可能是汇总时另含子集------这一点只有技术报告正文能说清，转述时不要直接把 96.3 当成"中英平均"。

其中两个数字值得单独看：

布局接口的消融 ：同一个系统，JSON 布局提示 1622.87 vs 自然语言提示 1506.20 ，差约 117 Elo，是下面要说的 CI 半宽（约 42.5）的两倍多。方向上明确支持"布局接口是主要增益来源"；但两个分数出自同一批盲测样本、误差并不独立，所以这是强信号，不是可写进结论的显著性检验。
开源权重内的最好成绩 ：LLTB 96.3 是开放权重模型里的最高值，但仍低于闭源的 GPT Image 2（99.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 名 MOSS（1698.70）与第 3 名 Seedream 5.0 Pro（1661.16）只差 37.5 Elo ，小于半宽 42.5，两条区间大幅重叠------"第 2"这个名次本身分不出高下，能说的只是"进入第一梯队"
指标接受度	7Bench 上 0.88 对 0.30--0.44 的差距由指标作者本人测得；LLTB 的"文字覆盖率"口径需看报告正文才能判断严苛程度
模型卡无分数	魔搭与项目页都没有列任何 benchmark 数值，只有定性对比图；所有数字需回到技术报告

结论：可以把这组数据当作"官方内部记分板 "来读------它足以说明"在它自己定义的任务上，布局接口确实有效"，但不足以证明它在通用画质或综合体验上领先。

七、上手：环境、代码与显存账单

7.1 环境

bash 复制代码

# Linux / macOS / Git Bash：反斜杠续行有效
pip install "diffusers>=0.38" "transformers>=5.3" "accelerate>=1.10" \
            "safetensors>=0.6" "Pillow>=10"

powershell 复制代码

# Windows PowerShell / CMD：反斜杠不是续行符，直接写一行
pip install "diffusers>=0.38" "transformers>=5.3" "accelerate>=1.10" "safetensors>=0.6" "Pillow>=10"

Python ≥ 3.10、PyTorch ≥ 2.9、NVIDIA GPU + CUDA （官方明确要求，不支持纯 CPU 推理）。在 Windows 上除了这一条，还要注意 transformers>=5.3 对 CUDA 版本的要求------装之前先用 nvidia-smi 对一下驱动，比装完再回退快得多。

7.2 最小调用

python 复制代码

import torch
from diffusers import DiffusionPipeline

pipe = DiffusionPipeline.from_pretrained(
    "OpenMOSS-Team/MOSS-Image-SFT",
    custom_pipeline="pipeline_moss_image",
    trust_remote_code=True,
    # 分模块指定精度：主干与编码器 bf16，VAE 必须留在 fp32
    torch_dtype={"default": torch.bfloat16, "vae": torch.float32},
)
# 照搬自官方 README。from_pretrained 已自带默认调度器，
# 这行只是按 config 显式重建一次，删掉不影响出图结果
pipe.scheduler = type(pipe.scheduler).from_config(pipe.scheduler.config)

pipe.to("cuda")  # 27.2GB 全驻留，显存不够先看 7.4，别硬扛

prompt = '''A 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:
"记得买牛奶和鸡蛋！牛奶两盒，鸡蛋一打。顺便带一袋面包。"'''

image = pipe(
    prompt, height=1024, width=1024,
    num_inference_steps=50,
    guidance_scale=3.0,
    uncond_skip_layers=[22],
    generator=torch.Generator("cpu").manual_seed(42),
).images[0]
image.save("refrigerator_note.png")

四个必须知道的细节：

custom_pipeline="pipeline_moss_image" 与 trust_remote_code=True 都不能省，少任一个都会在加载阶段直接报错。
精度是分模块的：VAE 与初始噪声用 float32，主干与文本编码器用 bfloat16。把 VAE 也压成 bf16 是常见的"省显存"操作，代价是出图颜色/细节异常，别顺手改。
宽高必须是 16 的整数倍，否则在 VAE 的 2×2 潜 patch 那一步对不齐。
uncond_skip_layers=[22] 默认开启，意味着 CFG 要算两次前向，见 7.3 的成本说明。

7.3 默认采样参数

项	默认值
采样器	Flow-matching Euler
步数	50
CFG	3
shift	5
层跳过	负分支第 22 层（`uncond_skip_layers=[22]`，类似 SLG）
负向提示	空

注意成本 ：默认引导路径每步要做 2 次 Transformer 前向 ，50 步并不便宜。关掉 uncond_skip_layers 或改用少步蒸馏 LoRA 都会改变画质与风格的平衡，需自行验证。

7.4 显存账单

官方没有公布任何显存数字，只在显存不足时建议"切 Sequential 模式或降分辨率"。可参考的公开数据有两类：

① 官方 Demo 的硬件：Hugging Face Space 跑在**单张 A10G（24GB）**上。

这个数字比看上去更有信息量：A10G 只有 24GB，而下面的估算表说 BF16 全驻留 1MP 就要 30GB------这两件事不可能同时成立。合理的解释只有一个：官方 Demo 没有全驻留，必然用了 Sequential / CPU offload 这类分时搬运。也就是说，"24GB 能跑起来"和"24GB 能跑得舒服"是两件事，官方 Demo 展示的是前者；你如果照着跑，出图速度会明显慢于预期。

② 第三方的规划级估算（明确标注"估算、非实测"，请留余量）：

配置	1MP（1024²）	约 2MP	4MP（2048²）
BF16，全部驻留显存	约 30.0 GB	约 32.2 GB	约 36.6 GB
BF16，文本编码器放 CPU	约 13.2 GB	约 15.4 GB	约 19.8 GB
8-bit 权重，编码器放 CPU	约 8.1 GB	约 10.3 GB	约 14.7 GB
4-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，不依赖 ControlNet；prompt 上限 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、要"下载就能用"：现在都不合适。这个模型的默认形态就是"大权重 + 重配置"，它的收益只在"位置要准"这件事上兑现。