deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak Hacker News – Front Page (hnrss.org)

OpenUI, tüketici GPU'larında çalışan açık ağırlıklı üretken arayüz modeli OUI-1'i yayınladı

OpenUI, akış tabanlı OpenUI Lang formatında arayüzler üreten ince ayarlı DiffusionGemma modeli OUI-1'i yayınladı; model, Generative UI Benchmark'ta temel modelin 13.0%'sına kıyasla 71.7% puan aldı.

OpenUI, tüketici GPU'larında çalışan açık ağırlıklı üretken arayüz modeli OUI-1'i yayınladı

OpenUI, kullanıcı arayüzleri üretmek için özel olarak geliştirilmiş, Google'ın DiffusionGemma modelinin ince ayarlı hali olan OUI-1'i yayınladı; şirket modeli ilk özel amaçlı üretken arayüz modeli olarak tanıtıyor. Model, Generative UI Benchmark'ta 71.7% puan aldı — bu, temel modelin 13.0% puanının 5.5 katı — ve OpenUI, 26 milyar parametreli (4 milyar aktif parametre) modelin tüketici donanımında, yani FP8'de bir RTX 5090 üzerinde çalıştığını söylüyor. Ağırlıklar, Hugging Face'te Gemma Terms of Use kapsamında yayınlandı.

Neden bir diffusion modeli

OpenUI'nin argümanı şu: agent destekli yazılım, bir saniyenin altında üretilen, gerçek yazılım gibi ele alınacak kadar doğru olan ve yerel olarak çalışacak kadar küçük bir modelle üretilen arayüzlere ihtiyaç duyuyor. Önceki bir deney olan AppLess, Cerebras donanımındaki Gemma 4 ile ilk iki gereksinimi karşıladı, ancak deneyimi özel bulut hızlandırıcılara bağlı tuttu.

Çıktı formatı zaten mevcuttu: OpenUI'nin iddiasına göre JSON'a kıyasla %67'ye varan oranda daha az token gerektiren ve üretildiği sırada akış tabanlı çalışan OpenUI Lang, böylece arayüz üretim bitmeden render edilmeye başlıyor. Geriye kalan sorun modelin kendisiydi.

DiffusionGemma gereksinimlere uuyordu. Autoregressive modeller tek seferde bir token üretip bellek bant genişliğiyle sınırlıyken, DiffusionGemma tek geçişte 256 tokenlık bloklar üretiyor, gürültüden rafine ediyor ve emin olduğu tokenları yerinde kilitliyor. OpenUI'nin aktardığı Google verilerine göre, bir H100'de saniyede 1.000 tokenı, bir RTX 5090'da ise 700 tokenı aşıyor. Sorun doğruluktu: ince ayar yapılmamış model, Generative UI Benchmark'ta yalnızca 13.0% puan aldı.

Denetimli ince ayar bir sorunu çözdü, ama başka birini yarattı

İlk eğitim aşamasında, daha büyük modeller tarafından yazılmış, yedi bileşen kütüphanesini kapsayan yaklaşık 700 OpenUI Lang programı kullanıldı; tek bir A100 üzerinde LoRA ile ince ayar yapıldı. Loss düştü, ama benchmark puanı da onunla birlikte düştü — model çoğunlukla ayrıştırılamayan, daha uzun ve yoğun programlar üretti.

Eğitimi benchmark'ın kendi bileşen kütüphanesiyle sınırlamak puanı 13.0%'dan 28.8%'e çıkardı, ancak inatçı bir ödünleşimi ortaya çıkardı. Şema hataları (geçersiz enum değerleri, eksik zorunlu proplar, kütüphanede var olmayan bileşenler) ve bağlantı hataları (hiç tanımlanmamış isimlere yapılan referanslar ya da kök düğüme hiç bağlanmamış bölümler) farklı denemelerde ters yönlere hareket ediyordu: birini düzeltmek diğerini kötüleştirmeye eğilimliydi.

Hız da geriledi. Sabit bir 20 kısa brief setinde, üretim süresi çıktı başına 1.6 saniyeden 4.3 saniyeye çıktı; çünkü ince ayarlı model gerçek isimler ve değerler yazıyordu — ifade başına temel modelde 22 token iken 32 token — ve her tokenı oturtmak için yaklaşık iki kat fazla denoising adımına ihtiyaç duyuyordu.

Jüri olarak parser ile self-distillation

OpenUI'ye göre kilit içgörü şu: OpenUI Lang makine tarafından doğrulanabilir; parser, bir arayüzün yapısal olarak geçerli olup olmadığına karar verebilir ve olmadığında hatayı tam olarak adlandırabilir. Bu, parser'ı bir ödül sinyaline dönüştürür ve modelin kendi çıktısı üzerinde eğitim almasına olanak tanır.

Döngü şöyle çalışıyor: model birkaç yüz program yazıyor, parser geçenleri tutuyor ve sınırda kalanlar, yalnızca parser'ın bildirdiği kusurlara dokunan bir onarım turundan geçiyor — medyan onarım tek bir ifadeyi değiştiriyor. Ardından bir jüri, hayatta kalan her programı brief'iyle karşılaştırıyor ve hayatta kalanlar bir sonraki eğitim seti oluyor. Her tur 500 eğitim adımı sürüyor — tek bir A100'de bir-iki saat — sonra gelişmiş model sonraki grubu üretiyor.

Bu, hız ve güvenilirliği birlikte geri kazandırdı. Çıktılar temel modelininkinden %28 daha fazla token taşısa da üretim süresi çıktı başına 1.9 saniyeye düştü. Benchmark puanı 57.1%'e ulaştı, şema hataları 292'den 76'ya, bağlantı hataları 971'den 484'e düştü — her iki hata türünün aynı modelde düştüğü ilk nokta bu oldu. OpenUI tekniği, parser'ın ödül olarak hareket ettiği, reinforcement learning'in reddetme örneklemesine (rejection sampling) indirgenmiş hali olarak tanımlıyor.

Eğitim sürecini 27 bileşen kütüphanesi boyunca tekrarlamak, nihai modeli benchmark'ta 71.7%'ye taşıdı. Kusurlar, temel modelde 100 ifade başına 35.3'ten denetimli ince ayar sonrası 16.4'e, OUI-1 için ise 3.8'e düştü; tamamlanan benchmark koşuları ise 184'ün 24'ünden 184'ün 132'sine yükseldi.

Neden önemli

OpenUI'nin kendi ifadesiyle OUI-1, arayüz üretmek için özel olarak geliştirilmiş ilk açık ağırlıklı model ve tüketici GPU'larına sığıyor. Bu iki açıdan önemli. Bir kere, arayüzleri bir sunucudan alınmak yerine talep üzerine, yerel olarak ve etkileşimli bir hızda üretilen agent destekli yazılıma somut bir adım. Ayrıca eğitim tarifi — yapılandırılmış, ayrıştırılabilir bir çıktı dilini, parser'ı ödül olarak ele alan bir self-distillation döngüsüyle eşleştirmek — doğrulanabilir bir formata sahip herhangi bir ekibin yeniden kullanabileceği bir örüntü. Bir uyarı: tüm veriler OpenUI'nin kendi duyurusundan ve benchmark'ından geliyor, dolayısıyla doğal bir sonraki soru bağımsız değerlendirme.

  • #generative-ui
  • #open-weights
  • #diffusion-models
  • #gemma
  • #front-end

İlgili yazılar