MOSS图像模型开放权重，支持结构化排版

OpenMOSS 发布了 MOSS-Image-Base 和 MOSS-Image-SFT 的代码与权重。这套 5B 参数的文生图模型，最值得关注的是：它允许把文字、元素位置和构图要求写成 JSON，让布局成为可以保存和编辑的数据。

对想把生图接进编辑器或设计工具的开发者，这个接口比单纯调整提示词更有用。但结构化输入不等于精确输出。原文没有提供文字准确率、位置遵循度等评测，能否稳定交付，还得自己验证。

JSON 能描述布局，但能保证位置吗

MOSS-Image 使用 DiT，也就是基于 Transformer 的扩散模型架构。项目把文字渲染、布局生成和高效微调列为主要方向，其中最具体的接口是 JSON 布局提示。

这份 JSON 包含场景摘要和一个 items 数组。每个元素可以带有标签、描述、可选的待渲染文字，以及边界框。文档示例采用以画布中心为基准的像素坐标，边界框使用 yxyx 格式。坐标必须与请求的输出尺寸匹配，然后把整个 JSON 作为 prompt 字符串传入 Python API。

对于已经知道标题、插图应该放在哪里的编辑器，这种方式有明确价值。布局信息可以直接保存、修改，再交给模型生成，减少反复用自然语言描述位置的工作。

JSON 让布局要求可记录、可编辑，并没有把生成结果变成确定性的排版。

原文没有给出模型严格遵守每个坐标、正确绘制每段文字的证据。文字是否准确、元素是否越界、构图是否合理，仍需要独立检查。文档里的效果示例和能力声明，不能代替这些验证。

接入入口齐全，参数却不能当作性能证明

项目提供两个版本：MOSS-Image-Base 是基础文生图模型，MOSS-Image-SFT 则是在精选数据上继续微调的版本。原文没有提供两者的对照结果，无法据此判断 SFT 在你的任务上能提升多少。

接入方面，仓库提供基于 diffusers.DiffusionPipeline 的 Python 示例，也有本地 Gradio 应用。项目还表示 ComfyUI 已原生支持 MOSS-Image，并提供 ComfyUI 格式权重的内置加载器。

文档推荐的推理配置是 Flow-matching Euler 采样、50 steps、CFG 3、shift 5，以及在第 22 层跳过负分支。这些参数值得保留，方便首次运行时建立一致的基线；但它们只是项目推荐值，没有附带独立性能测量。

显存模式也有三种：GPU 常驻、组件卸载和顺序执行。顺序模式通过牺牲推理速度来降低显存占用。原文没有给出各模式的具体显存需求与耗时，因此不能只看「支持卸载」就判断自己的机器能否顺畅运行。

6GB 微调与 Apache 许可，都有适用边界

社区工具支持对两个版本进行全量微调和 LyCORIS 训练，其中包括 LoRA。项目特别提到 KohakuMossTrainer，称其支持多种精度模式、多 GPU 方案，并能以最低 6GB 显存进行适配器训练。

这里的限定条件不能省：6GB 指向适配器训练，并不是全量微调、推理或部署的统一显存要求。相关描述来自仓库发布说明，原文没有交代完整硬件与训练配置，团队采用前需要核对训练器的实际条件。

许可也要分对象看。独立 pipeline 代码采用 Apache License 2.0，但所提供的仓库说明没有分别讲清所有模型权重、第三方社区产物的许可。商业部署或再分发时，不能仅凭 pipeline 的代码许可推断整个依赖链都适用相同条款。

我的判断

我看好的是「把布局作为数据」这个方向。相比只写自然语言提示词，JSON 更容易接入已有编辑器，也方便保存版本、复用模板和定位问题。

不过，结构化接口解决的是要求如何表达，输出是否可靠是另一件事。原文没有量化评测，也没有与其他模型或纯自然语言提示方案做对照。目前能够确认的是接口形式更明确，不能确认它的成图质量或布局遵循度更好。

如果任务要求文字一字不差、坐标严格固定，我会优先考虑让模型生成视觉素材，再用 HTML/CSS、Canvas 或 SVG 完成排版。这是工程上的取舍，原文并未比较这些方案。MOSS-Image 更适合先进入允许筛选、重试和人工修正的生成流程。

能拿来做什么

• 在已有编辑器中，把标题、插图的区域信息转换为 JSON，先验证坐标转换与输出尺寸是否一致，再观察生成结果对布局的遵循程度。
• 做一个小型验证集，覆盖实际使用的中文标题、长文本和多元素构图，分别记录错字、越界和需要重试的情况。
• 首次测试沿用文档推荐的 50 steps、CFG 3、shift 5 等配置，再逐项调整，并记录不同显存模式的耗时与占用。
• 有品牌风格或固定视觉需求时，再评估 LoRA 等微调方式，同时核对 KohakuMossTrainer 的 6GB 条件及相关权重、工具的许可。