OUI-1：全球首款用于 Generative UI 的模型

# OpenUI——生成式界面的开放标准 来源：https://www.openui.com/blog/oui-1 基于DiffusionGemma微调，在生成式界面基准测试中达到71.7%得分，性能是其基础模型的5.5倍。 OUI-1是基于DiffusionGemma微调的模型（https://blog.google/innovation-and-ai/technology/developers-tools/diffusion-gemma-faster-text-generation/），可使用openui-lang语言（https://www.openui.com/docs/openui-lang）编写用户界面。这是个260亿参数（40亿激活参数）的模型，可在消费级GPU（RTX 5090，FP8精度）上运行，权重已发布在Hugging Face（https://huggingface.co/thesysdev/OUI-1）上，并遵循Gemma使用条款。 代理驱动的界面是软件的未来。但实现这一目标面临三个关键约束：界面生成必须在一秒内完成；可靠性必须达到软件级标准；模型必须足够小以便在消费级硬件上本地运行。 通过AppLess项目（https://github.com/thesysdev/appless），我们曾用Gemma 4在Cerebras芯片上探索这种体验，但这依赖于云端专用硬件。将其迁移到设备端意味着要解决更难的问题：在算力显著减少的情况下保持响应速度，同时不牺牲生成界面的质量或正确性。 OUI-1是我们解决该问题的第一步：一个为在消费级硬件上生成可靠界面而设计的开源权重模型。其目标是以传统软件的速度，本地生成可靠且由代理驱动的界面。 协议基础已经就绪。OpenUI Lang比JSON和流式传输最多可节省67%的令牌消耗，因此界面能在模型完成生成前就开始呈现。更困难的部分是找到具有合适速度和硬件适配性的模型。 这就是我们选择DiffusionGemma的原因。自回归模型每次生成一个令牌，受限于内存带宽。而DiffusionGemma能一次性生成256个令牌的块——从噪声开始，一旦确定每个令牌就立即提交。谷歌报告称其在单块H100上运行速度超过每秒1000个令牌，在RTX 5090上超过700个令牌[[1]](https://www.openui.com/blog/oui-1#source-1)。 DiffusionGemma提供了我们寻求的速度。但仅有速度不足以成为软件：界面还必须功能正常。这正是我们需要弥合的差距。 基准测试使这个差距变得具体。DiffusionGemma在生成式界面基准测试（https://www.openui.com/benchmarks）中得分仅为13.0%。它拥有我们想要的速度和硬件特性，但缺乏可靠性。 OpenUI Lang解析器使这些故障显而易见。模式错误指错误的枚举、缺失的必需属性或虚构的组件。布线错误指使用了未定义的名称，或定义了部分却未将其连接到根节点。 ``` header = CardHeader("Spending", "last 7 days") total = Heading("$24,180", "h9") // 模式错误：h9不是标题等级 chart = AreaChart(days, [spend], "wavy") // 模式错误："wavy"不是曲线类型 footer = TextContent("Updated today") // 布线错误：已定义但未连接到根节点 root = Card([header, total, chart, summary]) // 布线错误：summary从未定义 ``` 这成为我们的指引原则：在不牺牲速度的前提下降低这两类错误。 训练分为两个阶段。首先通过监督微调教会DiffusionGemma编写OpenUI Lang。然后利用自蒸馏恢复其速度并提高可靠性。当这种模式在单一组件库上生效后，我们将其重复应用于27个组件库。 ### 第一阶段：监督微调 (https://www.openui.com/blog/oui-1#phase-1-supervised-fine-tuning) 我们从约700个由更大模型编写的OpenUI Lang示例开始，这些示例分布在七个组件库中，并在单块A100上运行LoRA微调。损失函数下降了，但基准测试分数也随之下降。模型学会了编写更长、更复杂的程序，但几乎无法正确解析。 我们将问题范围缩小到基准测试使用的单一组件库。分数从13.0%提升至28.8%，但进展伴随着权衡：一次运行减少了布线错误却增加了模式错误；下一次运行则相反： | 运行阶段 | 模式错误 | 孤立部分数量 | |---------|---------|------------| | n786 | +111 | 240 | | n+251 | 65 | | 两种错误像跷跷板一样此消彼长。虽然远超基础模型表现，但没有任何运行能同时降低两种错误。我们假设已达到LoRA的容量极限——它一次只能学习一种规范，后续全参数微调将解决这个权衡。 **错误分布变化** | 阶段 | 运行完成数 | 每百条语句缺陷数 | |----------------------|-----------|----------------| | DiffusionGemma | 24/184 | 35.3 | | 监督微调后 | 53/184 | 16.4 | | OUI-1 | 132/184 | 3.8 | 随后我们发现了第二个问题：模型变慢了。我们原本期望微调能提升速度。采样器在令牌熵值低于阈值时才会提交，因此掌握语言的模型应该能更快确定。但在相同的20个轻量级需求测试中，生成时间从**每次输出1.6秒增至4.3秒**。 基础模型快速是因为输出简短通用，平均每条语句22个令牌。微调模型则编写真实名称和数值，平均32个令牌/语句，且需要约两倍的去噪步骤来提交每个令牌。虽然我们教会了它生成更有用的界面，却失去了让DiffusionGemma初现时令人瞩目的速度。 **监督微调前后的单次输出耗时** 使用相同20个轻量级需求、单次请求、相同服务设置（vLLM, FP8, 单块A100）： - DiffusionGemma：1.6秒 - 监督微调后：4.3秒 微调模型输出更长且每个令牌需要约两倍去噪步骤：它在DiffusionGemma提交简短通用内容的地方提交了真实名称和数值。 ### 第二阶段：自蒸馏 (https://www.openui.com/blog/oui-1#phase-2-self-distillation) 突破在于认识到OpenUI Lang具有可验证的奖励信号。解析器可以判断界面结构是否有效，并能识别具体的模式或布线错误。这意味着模型可以自我教学：生成程序，利用解析器反馈保留或修复它们，并从结果中学习。自蒸馏还提供了恢复速度的途径，因为它是已知能减少扩散语言模型去噪步骤的方法[[2]](https://www.openui.com/blog/oui-1#source-2)[[3]](https://www.openui.com/blog/oui-1#source-3)。 我们的方法采用带修复的拒绝采样自训练。模型编写数百个OpenUI Lang程序，解析器保留通过的程序。接近正确的程序经过修复流程，仅修正解析器报告的缺陷；我们拒绝任何重写或虚构内容的编辑。中位修复仅修改一条语句。然后检查器验证每个留存程序是否符合需求说明。这些程序成为下一轮训练的训练集：500个步骤，在单块A100上耗时约一两小时。生成的模型产出下一批数据，循环往复。 **自蒸馏流程：生成、验证、重训练** 1. 生成：模型编写数百个OpenUI Lang程序 2. 验证：解析器保留通过验证的程序；检查器根据需求说明核对每个程序 3. 修复：由大语言模型修复接近正确的程序，仅处理列出的缺陷，拒绝重写 4. 重训练：留存的程序成为下一轮训练集 每个流程都训练下一批程序的生成模型。 速度得以恢复：在相同的20个轻量级需求测试中，生成时间从**每次输出4.3秒降至1.9秒**，即使输出内容比DiffusionGemma多出28%的令牌。跷跷板效应停止了。基准测试分数达到57.1%，模式错误从292降至76，布线错误从971降至484，且发生在同一个模型中。早期运行都是用一种错误换取另一种，而自蒸馏同时改进了两者。 这实质上是最简单的强化学习形式：将解析器作为奖励信号的拒绝采样。我们的假设（尚未完全验证）是：在模型自身文本上训练能让损失函数在大部分区域保持低位，将梯度集中在少数变化点：修复的语句和被推向模式的选择。前者教授布线修正；后者使模型更确定，从而让熵阈值能更早提交令牌。教师数据则将梯度分散在完全不同的写作风格上。 ### 第三阶段：跨27个组件库泛化 (https://www.openui.com/blog/oui-1#phase-3-generalizing-across-27-component-libraries) 单个库的结果引出了另一个问题：模型是学会了生成界面，还是仅学会了一个组件库？我们将相同的配方——监督微调接续自蒸馏——应用于27个组件库。 这产生了OUI-1。在生成式界面基准测试（https://www.openui.com/benchmarks）中，它得分71.7%，较DiffusionGemma的13.0%大幅提升。所有激活参数在310亿以下的开源模型得分都更低，包括46.7%的Gemma 4 31B，只有一个例外：78.8%的Qwen3.8 27B。Qwen3.8是密集模型，每个令牌使用270亿参数，而OUI-1仅激活40亿参数。没有任何40亿及以下激活参数的模型得分更高；要获得更高分数需要270亿密集模型。 **生成式界面基准测试（激活参数≤310亿的开源模型）** ``` 前沿模型（开闭源）：90%–99.5% 0–20–40–60–80–100 参数规模：31B 14B 8B 4B 2B 更少激活参数→ OUI-1：71.7%（基础模型的5.5倍） DiffusionGemma：13% Qwen3.8 27B：78.8% Qwen3.6 27B：68.5% Qwen3.6 35B-A3B：61.4% Gemma 4 31B：46.7% Phi-4 14B：44% Gemma 4 26B-A4B：29.9% Ministral 8B：27.2% Granite 4.1 8B：14.7% LFM 2.5 2.6B：3.3% ``` 这种提升也泛化到了基准测试库之外。在AppLess库上，我们测试了模型在训练中从未见过的60个需求。OUI-1生成了55个有效输出；DiffusionGemma仅生成23个。 **AppLess手机库的有效输出** 60个与所有训练文件无关独立编写的需求，每个生成一个输出，满足以下条件视为有效：解析通过、无模式错误、所有名称已定义、至少包含三条语句。 - DiffusionGemma：23/60 - OUI-1：55/60 使用与基准测试不同的组件库，系统提示词中包含其专属签名。这些需求和输出均未参与训练。 OUI-1不仅让我们回到了起点。AppLess此前依赖运行在Cerebras上的Gemma 4，现在可使用OUI-1运行。在基准测试中，OUI-1的71.7%超越了Gemma 4 31B（46.7%）和Gemma 4 26B-A4B（29.9%）。最初需要专用推理硬件的体验，现在可由为消费级硬件设计的开源40亿激活参数模型提供支持。 ### 模型发布 **获取OUI-1** 从Hugging Face下载开源权重模型。 260亿参数 · 40亿激活参数 · FP8精度 [查看模型权重](https://huggingface.co/thesysdev/OUI-1) **开放评估** 在GitHub上查看评分代码和原始生成结果。 71.7% 生成式界面基准测试 [查看基准测试](https://github.com/thesysdev/Generative-ui-bench) 未来三个方向值得关注： - **个人设备**：在更靠近用户的地方运行类似OUI-1的模型，将更多上下文保留在设备端。 - **OpenUI Lang 0.5**（https://www.openui.com/docs/openui-lang/specification-v05）：生成带有自身状态、查询和变更的界面，使运行时（而非模型）处理每次交互。 - **更低延迟**：迈向能在一秒内可靠生成的本地化界面。 1. 谷歌，《DiffusionGemma：更快的文本生成》（https://blog.google/innovation-and-ai/technology/developers-tools/diffusion-gemma-faster-text-generation/） 2. Deschenaux和Gulcehre，《超越自回归：通过时间自蒸馏实现快速大语言模型》（https://arxiv.org/abs/2410.21035） 3. Zhang等人，《T3D：通过轨迹自蒸馏与直接判别优化实现少步扩散语言模型》（https://arxiv.org/abs/2602.12262）