OUI-1：一秒生成一整屏 UI，代价是什么

OpenUI 是做 openui-lang 的公司——一种声明式的 UI 描述语言，模型不直接吐 HTML/JSX，吐的是一份更紧凑的组件清单，再由前端的组件库把它渲染成真实界面。2026 年 9 月 8 日，他们发布了 OUI-1：第一个专门为「生成式 UI」（Generative UI）训练的开放权重模型¹。

是什么：不是逐字生成，是整屏一次性「显影」

OUI-1 是微调自 Google DiffusionGemma 26B-A4B-it 的扩散模型，4B 活跃参数（LoRA 微调后合并回基座权重）²。和一般语言模型逐 token 往外吐字不同，扩散模型的生成方式是「从一整块噪声开始，整体去噪」——OUI-1 一次性写一个 256 token 的块，从噪声出发，每个 token 一旦「确定」了就提交，所以一整屏界面是同时成型的，不是从上到下一行行长出来的¹。这个设计直接服务于官方定的三条目标：界面要在一秒内生成完、要可靠到能当软件用（不是能看的草图）、模型要小到能在消费级硬件上本地跑¹。

怎么用：component library 签名 + 一句话需求，换一份组件代码

用法是给它一份组件库的签名放进系统提示词（告诉模型有哪些组件、各自接受什么参数），再给一句人话描述的需求，它返回的是用这些组件拼出来的整屏代码——每行一个组件，最后接到一个根节点上¹。返回的不是最终 HTML，是 openui-lang，还需要过一道解析器校验，再交给对应的组件库渲染。

部署上有三条路：通过 vLLM 起一个 OpenAI 兼容的 API（支持流式输出和工具调用）；直接用 Transformers 的 DiffusionGemmaForBlockDiffusion 类调用（注意 max_new_tokens 必须超过 256，一个去噪块的大小）；或者用 PEFT 格式的 adapter（r=64, alpha=128）接进已有的基座模型里，不必用合并后的完整权重²。采样用的是熵界采样器（entropy bound 0.1），48 步去噪，上下文长度 16,384 token²。

硬件要求要分清楚说：模型卡片给出的具体延迟数字（轻量屏幕约 1 秒、复杂屏幕 3-6 秒）是在 A100 80GB 上测的；量化到 FP8 之后显存占用是 25.8 GiB，BF16 精度约 52 GiB²。官方博客说的「能在消费级 GPU 上跑」，对应的应该是 FP8 这一档——RTX 5090 有 32GB 显存，装得下 25.8 GiB——但这个具体配置下的延迟数字我没有找到官方给出的实测值，不确定和 A100 上的 1 秒是不是同一个量级，这里如实说没有验证到，不是我替官方估算的。

效力：官方给的分数不错，官方自己披露的失败案例更值得看

Generative UI Bench 上，OUI-1 拿到 71.7%，是同一个基座模型微调前得分（13.0%）的 5.5 倍；测试集是 46 份屏幕设计简报、每份生成 4 轮，一共 184 个评测样本¹²。用 4B 活跃参数打过 Gemma 4 31B（参数量多 8 倍），是这次发布最抓眼球的一句话。

但比起这个分数，官方自己披露的两个问题更能说明这个模型的效力边界在哪，而且这两个问题都是「诚实的坏消息」，不是竞品挑出来的：

一是微调本身一度让模型变慢了。基座 DiffusionGemma 的延迟是 1.6 秒，第一版微调完之后退化到 4.3 秒，靠自蒸馏（self-distillation）才拉回到约 1.9 秒——但即便拉回来了，输出的 token 数量还是比基座模型多出约 28%，也就是说 OUI-1 本身比它自己的基座模型慢，只是慢得没那么夸张了³。这条信息值得记一笔：像「整屏一次性生成」这类专精化改造，不是理所当然地比通用基座更快，专精换来的是准确率，不是免费的速度。

二是复杂界面会触发解析错误。让它生成一个柱状图和表格拼在同一屏的仪表盘（dashboard），它确实产出了结果，但同时报了好几个解析器错误——缺一个必填字段、两个组件之间的类型对不上、协调两种不同数据展示组件放在一起时明显吃力³。这类错误的性质其实比「看起来对、实际错了」的那种要好一些——站内之前写过《一次误解的代价》，说结构完整、语气自信的错误最贵，因为读者没有信号可以提防。OUI-1 复杂场景下的失败是响亮的失败：解析器直接报错，不会悄悄生成一个字段缺失但看起来能跑的界面——这对一个要接进生产流程的生成式 UI 工具来说，是一个比分数更重要的设计取向。71.7% 这个数字掩盖不了它：简单、单组件、样式明确的屏幕它应付得好，一旦要求它自己协调多个组件之间的数据关系，可靠性就掉下去了。

未来使用场景：这是个窄场景工具，不是全能生成器——这部分是我自己的推测，不是官方给的结论

官方自己说得很直白：这不是通用聊天模型（not a general chat model），是给「延迟敏感、想自托管小模型」的 OpenUI 应用场景用的³。把这句话和上面的两个失败案例放在一起看，能推出几个相对靠谱的场景边界：

适合：表单、设置页、单一数据展示卡片这类结构固定、组件之间耦合浅的界面，尤其是需要实时生成（用户一边描述一边看界面成型）、又不想把请求发到云端大模型的场景——比如某些本地优先（local-first）的编辑器或者需要离线生成 UI 的嵌入式场景。一秒内出结果、4B 参数能塞进消费级显卡，这两条决定了它的位置更接近「UI 脚手架生成器」，不是「设计师替代品」。

不适合：一屏里有多个组件需要共享状态、互相联动（点了图表要联动表格高亮这种）的复杂仪表盘——官方自己的例子已经证明这类需求会让它露怯。也不适合当成通用代码生成工具的替代——它的整个训练和推理路径（openui-lang、组件库签名、block diffusion）都是围绕「UI 是一种结构化、可枚举的输出空间」这个假设设计的，这个假设在表单和卡片上成立，在需要真正业务逻辑判断的界面上未必成立。

扩散模型用来生成结构化输出（不只是 UI，理论上任何「整体一致性比逐步生成更重要」的输出空间）这个方向本身值得关注——但 OUI-1 目前证明的，是这个方向在「UI 生成」这个具体、约束清楚的子问题上能打多少分，还没有证据说明它能不能泛化到约束更松的领域。这句判断是我自己往前推的，不是 OpenUI 或者第三方评测已经验证过的结论。

Footnotes

1. Introducing OUI-1: world’s first model for Generative UI，OpenUI 官方博客，2026-09-08。 ↩ ↩² ↩³ ↩⁴ ↩⁵

2. thesysdev/OUI-1，Hugging Face 模型卡片。 ↩ ↩² ↩³ ↩⁴ ↩⁵

3. 微调延迟回退数字（1.6s → 4.3s → 自蒸馏后约 1.9s，多 28% 输出 token）与仪表盘解析错误案例，来自第三方对 OUI-1 发布内容的技术解读，见 OUI-1: The Diffusion Model That Builds UI Screens in One Second。 ↩ ↩² ↩³