为 MOSS-Image 发布生成的标题卡,主标题为“MOSS-Image”,副标题为“OpenMOSS 发布了一款 5B 扩散 Transformer,可读取提示词中的边界框”,三个标签分别写着“5B DiT 主干”、“Apache 2.0 权重”和“Layout JSON 提示词”,还有一个扁平线条图标,是一个矩形内包含三个位于不同位置的描边方框。
Engineering & Research

MOSS-Image 发布:OpenMOSS 推出 5B DiT,可在提示词中接收边界框

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

关于 MOSS-Image 发布,有个尴尬的细节:围绕它最响亮的说法其实还并不完全属实。10 月 17 日,vLLM 官方账号祝贺 OpenMOSS 团队完成开源发布,并表示"很自豪能通过 vLLM-Omni 在 Day 0 就支持 MOSS-Image"。[Model] 使用 SLG 为 MOSImage 添加文生图功能——真正把这个模型加进该运行时的那个 pull request,25 个文件、新增 3,605 行代码,提交于 10 月 14 日,至今仍处于打开状态,评审者还要求提供针对某个固定参考实现的输出一致性证据。vLLM-Omni 最新发布的版本是 v0.31.0rc1,日期为 10 月 6 日。因此,已发布的 vLLM-Omni 版本中没有任何一个包含这个模型;"Day 0" 这一说法的诚实版本是:这条服务路径只以你可以自行构建的分支形式存在,而不是一个可以安装的软件包。这一区别在这里比通常更重要,因为 MOSS-Image 是一个确实有意思的发布,其真正的内容在权重里:MOSS-Image-Base和 MOSS-Image-SFT,于 2026 年 10 月 16 日以 Apache 2.0 许可发布,其核心是一个紧凑的扩散 Transformer,可接受结构化 JSON 布局作为提示词。

想快速了解它大致轮廓的人,看这个简版就够了。OpenMOSS——MOSS 语言与语音系列背后的实验室,与 MOSI Intelligence 及学术伙伴合作——发布了一个从零训练的 5B 单流扩散 Transformer,搭配冻结的 Qwen3.5-9B 文本编码器和冻结的 FLUX.2 VAE,采用宽松许可,同时覆盖权重与推理代码。它的卖点不是原始画质,而是你可以把一个包含边界框、字面文本字符串和排版说明的 JSON 对象交给它,而它会照单执行。随它一同给出的基准测试数字来自厂商自己,而且是在厂商同样自建的两个基准上测得的。这并不构成否定它的理由,但这确实意味着,你该把它们当作实验室的内部记分板,而不是一份联赛积分榜。

实际发布的是什么,以及在哪里发布

这些成果直观且易于核查。OpenMOSS-Team/MOSS-Image-Base 与 OpenMOSS-Team/MOSS-Image-SFT均承载着模型权重,两者都有 ModelScope 镜像,一个运行在单张 A10G 上的 Gradio Space,以及一个存放流水线、ComfyUI 插件和技术报告的 GitHub 仓库。openmoss.ai 上的项目页面标注了同样的日期:2026 年 10 月 16 日 — 推出 MOSS-Image-Base,代码与模型权重均已开放。

两个检查点,同一套架构。Base 是预训练模型;SFT 则是在精选数据上微调过的。厂商自己的对比示例显示,SFT 能产生更紧凑的文本分组和更有条理的布局,而这大致就是你对一个被刻意保持未蒸馏的基础模型进行精选数据微调时所能预期到的结果。Base 的模型卡明确说明,它“未经过任何后训练,也未对 CFG 等推理参数进行蒸馏”,给出的原因是保留训练信息,并让模型更容易训练 LoRA。实际结果是,Base 是更适合微调的宿主,却是不太适合随手提示的默认选择。

许可方面,权重和独立流水线代码均采用 Apache 2.0——没有收入门槛,没有可接受使用附录,也没有单独的商用层级。对于一个以将清晰可读文本渲染进图像为核心卖点的模型而言,这一事实比基准测试表更具深远影响,因为文本渲染恰恰是在商业工作中会用到的那项能力:产品效果图、UI 设计稿、信息图、海报、广告版式。

A screenshot of the MOSS-Image project page at openmoss.ai captured October 17, 2026, showing the headline 'MOSS-Image: Text-to-Image Generation with Native Layout Control', the OpenMOSS Team byline, the paragraph introducing MOSS-Image-Base and the curated-data fine-tuned model, and a News entry reading 'October 16, 2026 - Introducing MOSS-Image-Base, with code and model weights available.'

架构,用关键数字说话

技术报告的配置表,正是这次发布不再只是一份新闻稿、而开始成为一份规格说明的地方。5B 这个数字仅指扩散生成器本身——一个单流 Transformer,深度为 42 个联合块,隐藏宽度 3072,24 个注意力头、每个 128 维,一个 8192 宽的前馈层并使用 SiTU-GLU 激活,以及一种四轴旋转位置编码;其第一个轴预留给参考索引,因此以后添加参考条件生成时无需改变位置编码方案。

然后还有“5B”这个标签悄悄排除掉的那部分:

• 文本编码器 — Qwen3.5-9B,冻结,将维度为 4096 的最后一层 token 隐藏状态依次经过一个到 3072 的线性投影和两个纯文本 Transformer 块进行馈送。把一个 9B 编码器加装到 5B 生成器上,其实际资源占用显著大于标称数字所暗示的规模。

• VAE — FLUX.2 的 VAE,已冻结并从 FLUX.2-klein-4B 加载,具有 32 个潜在通道,空间下采样因子为 8,2×2 的潜在分块带来 16 像素的有效图像步幅。MOSS-Image 自己的模型卡指出,它使用的是 FLUX.2 小型解码器。

• 下载大小 — SFT 仓库总计约 27.2 GB,其中文本编码器约占 16.8 GB,分布在四个分片中,Transformer 约占 10.2 GB,分布在三个分片中。要按编码器来规划,而不是按徽章。

• 提示词上限——最终预训练阶段为 4096 个 token,与厂商“最高 4K tokens”的说法一致。输出尺寸必须是 16 的正倍数,指南建议采用 100 万、150 万或 200 万像素,并支持从 0.25M(512×512)到 4M 的外推范围。

• 采样默认值——流匹配 Euler,50 步,CFG 3.0,shift 5.0,并在第 22 层的负分支上使用跳层引导。默认引导路径每步需要两次 Transformer 前向,所以 50 步并不像听起来那么省算力。

• 训练 — 三个渐进式分辨率阶段:256px 训练 2.1M 步,512px 训练 2.1M 步,然后约 1024² 训练 0.31M 步,每个样本的最大 token 数从 576 增至 3,072 再到 8,192。语料库是一个由 ReLAION 衍生的数据集,通过去重和移除 AI 生成图像,从约 50 亿张缩减至 30 亿张;报告称未应用进一步过滤——标题中含有伪影的图像被保留并描述其伪影,而非被丢弃。优化采用混合的 Muon–AdamW,厂商自己的 10 亿参数消融实验报告称,在两个检查点上,达到相同损失所需的步数比 AdamW 分别少 33.2% 和 28.6%。报告称训练使用了异构 GPU 平台,这是关于硬件供应的说法,而非关于模型本身,且报告未指明具体平台。

在基准测试之前,有一点值得提一下

提示增强模块——那个把“设计一张英文考拉知识信息图”变成完整内容与布局规范的部分——并不是厂商自家的小模型。报告明确表示,LayoutPE 在推理时使用带模块化任务指令的 GPT-6,而仓库随附的 prompt-enhancer 技能被描述为面向 GPT-6 系列智能体设计。因此,下文中最强的端到端结果不是单个模型的输出;而是一个双模型流水线,其中负责规范的那一半运行在他人的 API 上。如果你一直把 Elo 排名当作对生成器的纯粹衡量,那它并非如此。

A generated single-column infographic titled 'MOSS-Image - the scoreboard' listing six rows: Backbone 5B single-stream DiT, 42 blocks; Text encoder Qwen3.5-9B, frozen; VAE FLUX.2, 32 latent channels; Licence Apache 2.0 (weights and code); LongLongTextBench coverage 96.3 Mean-6; RealLayoutArena 1698.70 Elo, second overall. A footer reads 'All figures vendor-reported and unreproduced; both benchmarks are OpenMOSS's own. Weights total about 27 GB to download.'

基准测试表,以及它的作者是谁

MOSS-Image 在两个随发布版本一同提供的基准上接受评估,这两个基准源于厂商自己的主张:现有测试并未衡量它所关心的东西。LongLongTextBench 包含 240 项文学文本渲染任务——120 项英文、120 项中文,平均目标长度为 1,339.8 个字符,约为 LongTextBench 平均长度的十一倍。RealLayoutArena 包含 61 项设计任务(20 张海报、20 张信息图、21 个用户界面),通过盲测成对人类比较进行评判,并拟合到 Bradley–Terry Elo 量表。凡出现基线之处,都是厂商对他人模型的运行结果。本节中的每一个数字均由厂商报告,未经复现,且没有任何一项经过独立审计。

在 LongLongTextBench 的 Mean-6 文本覆盖率上,MOSS-Image 得分为 96.3——这是厂商表格中最好的开放权重成绩,明显领先于 Qwen-Image-2512 的 64.9,其最长条件下的得分为英文 97.1、中文 92.4。让这张表保持诚实的数字就在它上面一行:在厂商自己的基准上、用厂商自己的运行结果,GPT Image 2得分为 99.0,Nano Banana Pro 为 96.6。OpenMOSS 发布了一张竞争对手仍然获胜的表格,这本身就有价值。

在 7Bench 布局控制上,差距要大得多——在检测到的目标对象上,MOSS-Image 的平均 IoU 为 0.88,而 Ideogram 4.0 为 0.44,Nano Banana Pro 和 Seedream 5.0 Pro 为 0.33,Qwen Image 3.0 Pro 为 0.31,GPT Image 2 为 0.30;其布局 AUC 为 0.70,而同领域其他模型则在 0.16 到 0.20 之间。如果这些数字经得起复现,那么精确的对象放置就是这款模型真正具备的能力。

在 RealLayoutArena 端到端评测中,MOSS-Image 以 1698.70 Elo 的成绩位列其中,95% 置信区间为 1655.96 至 1741.43——总排名第二,落后于 1844.35 的 GPT Image 2,领先于 Seedream 5.0 Pro(1661.16)、启用提示增强的 Qwen Image 3.0 Pro(1614.84)以及 Nano Banana Pro(1590.19)。当比较范围仅限于在共享增强自然语言提示下的骨干模型本身时,MOSS-Image 以 1807.34 位居第一,领先于 1748.51 的 ERNIE Image 和 1689.23 的 SenseNova-U1。对于任何计划使用它的人来说,提示策略消融实验是论文中最有用的一句话:在同一系统上,JSON 布局提示得分为 1622.87,自然语言提示为 1506.20。布局接口并非附加功能。性能正源于此。

报告自我提出的两点提醒值得重申。LongTextBench 被描述为对当前强模型而言已接近饱和,这是供应商在解释为何要构建一个更难的测试,而不是停留在旧测试上。而端到端 Elo 的置信区间与其他区间毫无重叠,但它的跨度很宽——在一个由人类评分者评判的 61 项任务竞技场上,达到了 85 Elo 分。

自己运行,以及这样做的成本

目前,我们无法验证 MOSS-Image 存在任何可用的商业 API,它也不在我们自己的目录中——OrcaRouter 提供 200 多个模型,MOSS-Image 并不在其列,因此这里的内容不应被解读为我们在提供该模型。现有的方式都是自托管:配合自定义管道的 Diffusers 路线(pipeline_moss_image,需要 diffusers 0.38 或更高版本、transformers 5.3 或更高版本、torch 2.9 或更高版本、Python 3.10+)、一个 Gradio 应用,以及可通过 ComfyUI Manager 安装的原生 ComfyUI 插件,而接入官方 ComfyUI 仓库的工作据称正在进行中。此外还有一个面向 agent 框架的提示词增强技能,它能把像素坐标草稿编译成模型所使用的中心坐标 JSON 格式,且无需调用任何图像服务——这是一个小巧却确实有用的工具。

社区已经完成了厂商没有做的部分。在发布后大约一天内,Hugging Face 上就出现了第三方构建版本:该模型的 Comfy-Org 打包版本、一个实验性的 Kijai 构建、GGUF 量化版本、INT8 和 INT4 ConvRot 转换、一个 W4A8 OrbitQuant 构建,以及——对任何没有数据中心的人来说最有用的是——一个 4 步 DMD LoRA 和一个 8 步蒸馏变体,它们直接向 50 步默认设置发起冲击。这些都没有厂商支持,也都没有经过基准测试,但它们是一个正常信号:一次发布已经落到了那些打算使用它而不是引用它的人手中。

这正是路由层体现价值的地方,而把边界说清楚是值得的。我们并不托管 MOSS-Image,因此无法提供该服务,也不会暗示并非如此。我们能做的是这场对比的另一半:如果你想拿自托管的 MOSS-Image 与托管式图像模型进行评测对比,托管这一侧只需一个 API 密钥即可通过我们的目录按提供商标价访问,零加价——因此托管模型上厂商的价格变动当天就能在这里生效,而不是等到季度合同周期才更新——并具备跨提供商自动故障转移,以及一套路由 DSL,让你能把多个模型置于同一个端点之后。用一个尚未验证的检查点去对比一个租来的检查点,不应该还需要再接入一套 SDK,而这也正是我们唯一的主张。

A screenshot of the OrcaRouter model page for openai/gpt-image-2, captured October 17, 2026, showing the 'Home » Models » openai' breadcrumb, the model id, the pricing figures $8.00 and $30.00, latency figures 10.60 s and 10.00 s with 1.8M tokens, and the line 'Point your existing OpenAI client at OrcaRouter's base URL and set the model to /v1/images/generations'.

谁应该对此采取行动,谁又应该等待?

如果你的工作涉及生成包含正确、清晰可读的多语言文本且位置特定的图像——海报、界面 mockup、信息卡片,以及任何布局本身就是交付成果而非偶然所得的场景——那么 MOSS-Image 是上个月最直接针对这一需求的开源权重发布,而 Apache 2.0 许可证意味着通常的商业审查流程会很短。从 SFT 检查点开始,预期需要提供结构化 JSON 而不是散文,并且在为生成器做预算之前,先为编码器的 16.8 GB 做好预算。

如果你本周就需要一个可调用的端点,如果你是租用算力而非自己拥有,或者你想在正式投入前先拿到一个独立的数字,那就再等等。该架构是一种干净的单流设计,配有冻结的编码器和冻结的 VAE,这让它运行起来很直接——但每步两次前向、共 50 步,是实实在在的服务成本,“5B”这个标签低估了下载量,而那些亮眼分数是厂商在自己家的基准上跑出来的,用的还是一个运行在第三方模型上的规格设定阶段。等一次复现,或者等 vLLM-Omni 这条路合并成你能直接安装的东西。

本次发布未能解决的两个问题

模型的布局控制是否能证明工作流程变更的合理性?

这取决于你是否能将意图表达为框和字符串。布局 JSON 使用从画布中心测量的绝对像素坐标,并采用 bbox_format "yxyx",这与近期其他几种布局系统采用的相对坐标约定不同——厂商认为绝对像素更适合多分辨率工作。采用它意味着要重写你现有的所有提示逻辑,而厂商自己的 7Bench 差距(0.88 mIoU,而同类方案在 0.30–0.44)是证明这次重写有回报的唯一证据。它是由编写该指标的那些人测得的。

微调这件事真的像许可证所暗示的那样开放吗?

部分未知。权重和流水线代码采用 Apache 2.0,且 Base 被刻意保持未蒸馏,好让 LoRA 有可学习之处,这确实是一种实打实的投入。但报告中的训练配方——分阶段分辨率课程、ReLAION 过滤决策、Muon–AdamW 拆分——只是文档说明,而非已发布的数据;而目前的微调指导由具体指令(保持文本编码器冻结;不要对其进行微调)外加一个图像描述提示词组成。关于简单 SFT 能解锁基于参考的生成和 GIF 输出的说法,被表述为一项附带“敬请期待”的发现,而不是你今天就能核查的结果。

有三件事能让 MOSS-Image 从一个令人印象深刻的仓库变成一个稳妥的选择,而这三件事目前都还不存在:由作者以外的人独立跑一次 LongLongTextBench 或 RealLayoutArena;把 vLLM-Omni 补丁合并进带标签的发布版本,并附上其评审者所要求的输出一致性证据;以及一个获得厂商认可、而不只是社区转换而来的少步蒸馏检查点。在那之前,准确的总结是这样——一个文档完备的 5B 扩散 Transformer,拥有异常强大的文本与版式接口;一个宽松的许可证,同时覆盖代码和权重;在其自己编写的测试上领跑基准,在端到端对比中位列第二;以及一套真实存在、却仍停留在未合并拉取请求中的服务方案。

此类发布背后有据可查的 AI 故障与智能体事件,均收录于OrcaRouter AI 事件档案,其中每条记录都带有自己的来源、严重程度、置信度评级和争议标记。