OUI-1: 世界初の生成UIモデル
OUI-1: world's first model for Generative UI (openui.com)
要約
OpenUIは、OpenUI-Langでユーザーインターフェースを生成する、世界初の生成UIモデル「OUI-1」を発表しました。このモデルは、消費者向けGPUで実行可能であり、従来のソフトウェアと同等の速度で信頼性の高いインターフェースをローカル生成することを目指しています。
全文翻訳
OUI-1の紹介：ジェネレーティブUI向け世界初のモデル
Generative UI Benchmarkで71.7%を達成、ベースモデルの5.5倍。
OUI-1は、DiffusionGemmaモデルをファインチューニングしたもので、openui-langでユーザーインターフェースを記述します。これは26Bパラメータのモデルで、コンシューマーグレードのGPU（RTX 5090、FP8）で実行可能です。重みはApache 2.0ライセンスの下、Hugging Faceで公開されています。これはベースモデルと同じライセンスです。
OUI-1を構築した理由
エージェント駆動型インターフェースはソフトウェアの未来です。しかし、そこに至るまでには3つの制約があります。インターフェースは1秒未満で生成される必要があります。ソフトウェアとして使用できるほど信頼性がなければなりません。そして、モデルはコンシューマーハードウェアでローカルに実行できるほど小さくなければなりません。
AppLessでは、Cerebras上のGemma 4を使用してその体験を探求しました。しかし、それはクラウド上の特殊なハードウェアに依存していました。それをデバイス上に移行するには、より難しい問題の解決が必要です。計算リソースが劇的に少ない状況で応答性を維持しつつ、生成されるインターフェースの品質や正確性を犠牲にしないことです。
OUI-1は、その問題解決に向けた私たちの最初のステップです。コンシューマーハードウェア上で信頼性の高いインターフェースを生成するために構築された、オープンウェイトモデルです。目標は、従来のソフトウェアの速度で、ローカルで生成される信頼性の高いエージェント駆動型インターフェースです。
制約に合ったモデルの発見
プロトコルはすでに確立されていました。OpenUI Langは、JSONやストリームよりも最大67%少ないトークンで済むため、モデルが生成を完了する前にインターフェースが表示され始めます。より困難だったのは、適切な速度とハードウェアプロファイルを持つモデルを見つけることでした。
そこでDiffusionGemmaを選択しました。autoregressiveモデルは一度に1トークンを生成し、メモリ帯域幅がボトルネックになります。DiffusionGemmaは、ノイズから開始し、確信した瞬間に各トークンをコミットすることで、一度に256トークンのブロックを書き出します。Googleによると、単一のH100で毎秒1,000トークン以上、RTX 5090で700トークン以上を処理できます[1]。
DiffusionGemmaは私たちが求めていた速度を提供してくれました。しかし、速度だけではソフトウェアになりません。インターフェースは機能しなければならないのです。それが、私たちが埋める必要があったギャップでした。
ギャップが北極星になった
ベンチマークによって、そのギャップは具体的になりました。DiffusionGemmaはGenerative UI Benchmarkで13.0%のスコアでした。求めていた速度とハードウェアプロファイルはありましたが、信頼性がありませんでした。
OpenUI Langパーサーにより、その失敗は容易に可視化されました。スキーマエラーは、間違ったenum、必須プロパティの欠落、または存在しないコンポーネントの導入です。配線エラーは、使用されているが定義されていない名前、またはルートにアタッチされていない定義済みのセクションです。
header = CardHeader("Spending", "last 7 days")
total = Heading("$24,180", "h9")// schema: h9 is not a heading level
chart = AreaChart(days, [spend], "wavy")// schema: "wavy" is not a curve type
footer = TextContent("Updated today")// wiring: defined, never attached to root
root = Card([header, total, chart, summary])// wiring: summary is never defined
それが私たちの北極星となりました。速度を犠牲にすることなく、両方の種類のエラーを削減することです。
トレーニング方法
トレーニングは2段階で展開されました。まず、教師ありファインチューニングを通じてDiffusionGemmaにOpenUI Langを書くことを教えました。次に、自己蒸留を使用して速度を回復し、信頼性を向上させました。これが1つのコンポーネントライブラリで機能した後、27のライブラリ全体でプロセスを繰り返しました。
フェーズ1：教師ありファインチューニング
私たちは、より大きなモデルによって書かれた約700のOpenUI Langの例（7つのコンポーネントライブラリに分散）から始め、1つのA100でLoRAファインチューニングを実行しました。損失は低下しました。しかし、ベンチマークスコアもそれに伴って低下しました。モデルはより長く、より密度の高いプログラムを書くことを学習しましたが、そのほとんどはクリーンに解析されませんでした。
問題をベンチマークで使用されるコンポーネントライブラリ1つに絞り込みました。スコアは13.0%から28.8%に上昇しましたが、進歩にはトレードオフが伴いました。ある実行では配線エラーを減らし、スキーマエラーを増加させました。次の実行ではその逆でした。
| run | schema errors | orphaned sections |
|---|---|---|
| n | 78 | 66 |
| n + 1 | 112 | 40 |
| n + 2 | 51 | 65 |
2つのエラータイプはシーソーのように動きました。私たちはベースモデルよりはるかに進んでいましたが、両方を同時に削減する実行はありませんでした。LoRAの容量限界に達したと仮定しました。それは一度に1つの規律しか学習できず、後でフルファインチューニングでトレードオフが解決されるだろうと考えました。
エラーの行方
2802
DiffusionGemma
24/184回の実行完了
100ステートメントあたり35.3の欠陥
1263
教師ありファインチューニング後
53/184回の実行完了
100ステートメントあたり16.4の欠陥
20313.8倍少ない
OUI-1
132/184回の実行完了
100ステートメントあたり3.8の欠陥
スキーマエラー
配線エラー：未定義の名前と孤立したセクション
次に、2番目の問題を発見しました。モデルは遅くなっていました。ファインチューニングによってモデルが速くなることを期待していました。サンプラーは、エントロピーが境界を下回るとトークンをコミットするため、言語を知っているモデルはより早く確信できるようになるはずです。しかし、同じ20のライトブリーフで、生成時間は1.6秒/出力から4.3秒に増加しました。
ベースモデルは、その出力が短く汎用的で、ステートメントあたり平均22トークンだったため高速でした。ファインチューニングされたモデルは、実際の名前と値を書き出し、ステートメントあたり平均32トークンで、各トークンをコミットするために約2倍のデノイジングステップを必要としました。より有用なインターフェースを生成するように教えましたが、DiffusionGemmaを興味深いものにしていた速度を失ってしまいました。
出力あたりの秒数、教師ありファインチューニングの前と後
同じ20のライトブリーフ、一度に1つのリクエスト、両方の行で同じサービング設定：vLLM、FP8、1つのA100。
DiffusionGemma
1.6秒
教師ありファインチューニング後
4.3秒
ファインチューニングされたモデルはより長い出力を書き、トークンあたりのデノイジングステップは約2倍必要とします。DiffusionGemmaが短く汎用的なものをコミットするのに対し、実際の名前と値をコミットしています。
フェーズ2：自己蒸留
ブレークスルーは、OpenUI Langには検証可能な報酬があるという認識でした。パーサーは、インターフェースが構造的に有効かどうかを判断し、無効な場合は正確なスキーマまたは配線エラーを特定できます。これは、モデルが自身の教師になれることを意味しました。プログラムを生成し、パーサーからのフィードバックを使用してそれらを保持または修復し、結果から学習します。自己蒸留は、拡散言語モデルで使用されるデノイジングステップを削減する既知の方法であるため、速度を回復する道も提供しました[2][3]。
私たちのバージョンは、リジェクションサンプリングによる自己トレーニングと修復を使用します。モデルは数百のOpenUI Langプログラムを書き出し、パーサーは受け入れたものを保持します。惜しいものは修復パスを通過し、パーサーが報告した欠陥のみを修正します。書き換えや新規作成を行う編集はすべて拒否されます。中央値の修復は1つのステートメントを変更します。その後、ジャッジが各生存プログラムがブリーフと一致するかどうかを確認します。それらのプログラムが次の実行のトレーニングセットになります。500ステップで、A100 1台で1〜2時間かかります。結果のモデルが次のバッチを生成し、ループが再び始まります。
自己蒸留：生成、検証、再トレーニング
1・生成
モデルが数百のOpenUI Langプログラムを書く
2・検証
パーサーがクリーンに通過したものを保持します。ジャッジが各プログラムをブリーフと照合して確認します。
3・修復
LLMによって修正された惜しいもの。リストされた欠陥のみ。書き換えは拒否されます。
4・再トレーニング
生存したものが次のトレーニングセットになります。
各パスは、次のバッチを書くモデルをトレーニングします。
速度が戻ってきました。同じ20のライトブリーフで、生成時間は4.3秒/出力から1.9秒に減少しました。それにもかかわらず、出力にはDiffusionGemmaの出力よりも28%多くのトークンが含まれていました。その後、シーソーは止まりました。ベンチマークスコアは57.1%に達し、スキーマエラーは292から76に、配線エラーは971から484に減少しました（同じモデルで）。以前のすべての実行は一方のエラータイプを他方と交換していましたが、自己蒸留は両方を改善しました。
実質的に、これは最も単純な形の強化学習です。パーサーを報酬とするリジェクションサンプリングです。私たちの仮説（まだ分離していませんが）は、モデル自身のテキストでトレーニングすることで、ほとんどすべての場所で損失が低く保たれ、勾配が変更された少数のものに集中することです。修理されたステートメントとモードに向かってプッシュされたサンプリングされた選択肢です。前者は配線修正を教え、後者はモデルをシャープにしてエントロピー境界がトークンをより早くコミットできるようにします。教師が書いたデータは、完全に異なるライティングスタイル全体にその勾配を広げます。
フェーズ3：27のコンポーネントライブラリ全体での一般化
単一ライブラリの結果は、モデルがインターフェースを生成することを学んだのか、それとも1つのコンポーネントライブラリを学んだのかという別の疑問を残しました。私たちは同じレシピ（教師ありファインチューニングとその後の自己蒸留）を27のコンポーネントライブラリ全体に適用しました。
結果
その結果がOUI-1です。Generative UI Benchmarkで71.7%のスコアを達成し、DiffusionGemmaの13.0%から向上しました。31Bまでのアクティブパラメータを持つすべてのオープンモデルは、Qwen3.8 27B（78.8%）を除くほとんどが低いスコアでした。Qwen3.8は、OUI-1の4Bアクティブパラメータと比較して、各トークンで27Bパラメータを使用する密なモデルです。4Bアクティブパラメータ以下のモデルでこれより高いスコアはありませんでした。スコアで次のステップアップには、密な27Bが必要でした。
Generative UI Benchmark、31Bアクティブまでのオープンウェイトモデル
フロンティアモデル、オープンおよびクローズド・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%
データを見る
| model | active params | OpenUI score |
|---|---|---|
| OUI-1 (DiffusionGemma, finetuned) | 4B | 71.7% |
| DiffusionGemma | 4B | 13% |
| Qwen3.8 27B | 27B | 78.8% |
| Qwen3.6 27B | 27B | 68.5% |
| Qwen3.6 35B-A3B | 3B | 61.4% |
| Gemma 4 31B | 31B | 46.7% |
| Phi-4 14B | 14B | 44% |
| Gemma 4 26B-A4B | 4B | 29.9% |
| Ministral 8B | 8B | 27.2% |
| Granite 4.1 8B | 8B | 14.7% |
| LFM 2.5 2.6B | 2.6B | 3.3% |
この向上は、ベンチマークライブラリを超えて一般化しました。AppLessライブラリでは、トレーニング中にモデルが一度も見たことのない60個の質問をテストしました。OUI-1は55個の有効な出力を生成しました。DiffusionGemmaは23個でした。
AppLess電話ライブラリでの有効な出力
トレーニングファイルとは独立して書かれた60個の質問、それぞれ1つの出力。解析がクリーンな場合に有効とカウント：スキーマエラーなし、すべての名前が定義されている、少なくとも3つのステートメント。
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%を上回りました。当初は特殊な推論ハードウェアを必要としたエクスペリエンスが、現在ではコンシューマーハードウェアで実行するために構築された、オープンウェイトの4Bアクティブモデルによって可能になりました。
OUI-1を入手する
Hugging Faceからオープンウェイトモデルをダウンロードしてください。
26Bパラメータ・4Bアクティブ・FP8
モデルウェイトを見る
ベンチマークを探索する
GitHubでスコアリングコードと生の生成結果を確認してください。
71.7% Generative UI Benchmark
ベンチマークを見る
今後の方向性
ここからの3つの方向性が重要です。
- パーソナルデバイス。 OUI-1のようなモデルをユーザーの近くで実行し、コンテキストの多くをデバイス上に保持します。
- OpenUI Lang 0.5。 独自のステート、クエリ、ミューテーションを持つインターフェースを生成し、モデルではなくランタイムが各インタラクションを処理するようにします。
- 低レイテンシ。 1秒未満で到着する、信頼性が高くローカルで生成されたインターフェースを目指します。