OUI-1: ไฟน์จูน DiffusionGemma ให้เขียน UI ได้ 71.7% จากฐาน 13.0% — เปิดน้ำหนัก 4B active แต่ต้องอ่านเงื่อนไขให้ครบก่อนคิดว่ารันบนการ์ดเกมได้

วันที่ 8 กันยายน 2026 ทีมวิศวกรรมของ Thesys เปิดตัว OUI-1 ซึ่งเรียกตัวเองว่าโมเดล diffusion ตัวแรกที่สร้างมาเพื่องาน generative UI โดยเฉพาะ มันคือการไฟน์จูน DiffusionGemma 26B-A4B-it ของ Google ให้เขียนหน้าจอผู้ใช้ออกมาเป็นภาษา openui-lang — ภาษาประกาศ UI แบบหนึ่งคอมโพเนนต์ต่อหนึ่งบรรทัด แล้วต่อสายเข้า root

ตัวเลขพาดหัวคือ 71.7% บน Generative UI Benchmark เทียบกับ 13.0% ของโมเดลฐาน หรือ 5.5 เท่า โดยใช้พารามิเตอร์แอ็กทีฟเพียง 4B ที่น่าสนใจกว่าตัวเลขคือวิธีที่พวกเขาไปถึงมัน และช่องว่างระหว่างสิ่งที่บล็อกเขียนกับสิ่งที่ไฟล์จริงบน Hugging Face บอก

ทำไมต้องเป็น diffusion และปัญหาที่ตามมา

เหตุผลที่ Thesys เลือก DiffusionGemma ไม่ใช่เพราะฉลาดกว่า แต่เพราะ เร็วกว่าเชิงสถาปัตยกรรม โมเดล autoregressive สร้างทีละโทเคนและติดคอขวดที่แบนด์วิดท์หน่วยความจำ ส่วน DiffusionGemma เขียนบล็อกขนาด 256 โทเคนพร้อมกันจากสัญญาณรบกวน แล้วค่อยยืนยันแต่ละโทเคนเมื่อมั่นใจ — ค่า canvas_length: 256 ยืนยันได้จาก config.json ในรีโปจริง

แต่ความเร็วอย่างเดียวไม่ทำให้ได้ซอฟต์แวร์ที่ใช้งานได้ เฟสแรกคือ supervised fine tuning ด้วยตัวอย่าง openui-lang ราว 700 ชุดจาก 7 คอมโพเนนต์ไลบรารี รัน LoRA บน A100 หนึ่งใบ ผลคือ loss ลดลง แต่คะแนนเบนช์มาร์กลดลงตาม เพราะโมเดลเรียนรู้ที่จะเขียนโปรแกรมยาวขึ้นและแน่นขึ้นโดยที่แทบไม่มีชิ้นไหน parse ผ่าน

เมื่อบีบให้เหลือไลบรารีเดียวคะแนนขึ้นจาก 13.0% เป็น 28.8% แต่เจอปัญหาแบบกระดานหก: รันหนึ่งลด wiring error แล้ว schema error เพิ่ม รันถัดไปสลับกัน (78/66 → 112/40 → 51/65) ไม่มีรันไหนกดลงพร้อมกันได้ทั้งสองแบบ

ปัญหาที่สองแสบกว่า — โมเดลช้าลง ทั้งที่ควรเร็วขึ้น จากบรีฟชุดเดิม 20 ชิ้น เวลาสร้างขึ้นจาก 1.6 วินาทีเป็น 4.3 วินาทีต่อชิ้น สาเหตุคือโมเดลฐานเร็วเพราะเอาต์พุตสั้นและกลาง ๆ เฉลี่ย 22 โทเคนต่อสเตตเมนต์ ส่วนตัวไฟน์จูนเขียนชื่อและค่าจริงเฉลี่ย 32 โทเคน จึงต้องใช้ขั้น denoising ราวสองเท่า

Self-distillation: ใช้ parser เป็น reward

จุดพลิกคือการมองว่า openui-lang มี reward ที่ตรวจสอบได้ เพราะ parser บอกได้ว่าโครงสร้างถูกหรือไม่ และผิดตรงไหน (schema error คือ enum ผิด/prop ขาด/คอมโพเนนต์ที่ไม่มีจริง ส่วน wiring error คือชื่อที่ใช้แต่ไม่ได้นิยาม หรือ section ที่นิยามแล้วไม่ได้ต่อเข้า root)

วิธีที่ใช้คือ rejection-sampled self-training พร้อมการซ่อม: โมเดลเขียนโปรแกรมไม่กี่ร้อยชิ้น parser เก็บชิ้นที่ผ่าน ชิ้นที่เกือบผ่านส่งเข้าขั้นซ่อมที่แก้เฉพาะข้อบกพร่องที่ parser รายงาน และปฏิเสธการแก้ที่รื้อเขียนใหม่ (การซ่อมค่ามัธยฐานเปลี่ยนแค่ 1 สเตตเมนต์) แล้วให้ judge ตรวจว่าตรงบรีฟไหม ผลลัพธ์กลายเป็นชุดเทรนรอบถัดไป 500 สเต็ป ใช้เวลาชั่วโมงสองชั่วโมงบน A100 ใบเดียว

ผลคือ ทั้งสองอย่างดีขึ้นพร้อมกันเป็นครั้งแรก: เวลาสร้างลดจาก 4.3 กลับมาเหลือ 1.9 วินาที ทั้งที่เอาต์พุตมีโทเคนมากกว่าโมเดลฐาน 28%, คะแนนขึ้นเป็น 57.1%, schema error ลดจาก 292 เหลือ 76 และ wiring error ลดจาก 971 เหลือ 484 จากนั้นจึงขยายสูตรเดิมไปยัง 27 คอมโพเนนต์ไลบรารีจนได้ OUI-1 ที่ 71.7%

โปรโตคอลของ generative-ui-bench คือบรีฟหน้าจอ 46 ชิ้นใน 5 ช่วงขนาด ชิ้นละ 4 การสร้าง รวม 184 รัน — ฐานได้ 24/184 (13.0%) OUI-1 ได้ 132/184 (71.7%) และทีมคอมมิตเอาต์พุตดิบลงรีโปเบนช์มาร์กให้ตรวจซ้ำออฟไลน์ได้ ซึ่งเป็นมาตรฐานที่แล็บส่วนใหญ่ไม่ทำ

ตารางเทียบที่ควรอ่านให้ครบบรรทัด

บนกระดานโมเดลเปิดน้ำหนักที่แอ็กทีฟไม่เกิน 31B: OUI-1 (4B แอ็กทีฟ) 71.7%, 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%, DiffusionGemma 13% และ LFM 2.5 2.6B 3.3%

แต่บรรทัดที่บล็อกเขียนไว้ตรง ๆ และไม่ควรข้ามคือ Qwen3.8 27B ยังชนะที่ 78.8% — Thesys ยอมรับเองว่าเป็นข้อยกเว้นเดียว โดยแย้งว่า Qwen3.8 เป็นโมเดล dense ที่ใช้ 27B ทุกโทเคน เทียบกับ 4B แอ็กทีฟของ OUI-1 ข้อสรุปที่ถูกต้องจึงไม่ใช่ “OUI-1 เก่งที่สุด” แต่คือ ไม่มีอะไรที่แอ็กทีฟ 4B หรือต่ำกว่าทำได้ดีกว่า และการจะได้คะแนนสูงกว่านี้ต้องกระโดดไปที่ dense 27B

การทดสอบนอกไลบรารีเบนช์มาร์กก็มี: บนไลบรารีของ AppLess ด้วยโจทย์ 60 ข้อที่ไม่เคยเห็นตอนเทรน OUI-1 ได้เอาต์พุตที่ใช้ได้ 55/60 ส่วน DiffusionGemma ได้ 23/60

สิ่งที่การ์ดโมเดลบอกแต่พาดหัวไม่บอก

ตรงนี้คือส่วนที่นักพัฒนาต้องอ่านก่อนวางแผน เพราะการ์ดบน Hugging Face ระบุรายละเอียดที่ต่างจากความประทับใจแรก:

• ไฟล์ที่ดาวน์โหลดคือ bf16 ไม่ใช่ FP8 รีโป thesysdev/OUI-1 รวมทั้งหมด 51.98 GB (safetensors สองไฟล์ ~51.6 GB) การ์ดระบุว่า “น้ำหนักกินพื้นที่ 25.8 GiB ที่ FP8” ซึ่งเกิดขึ้นตอน vLLM แปลงให้ตอนเสิร์ฟด้วย --quantization fp8 ไม่ใช่ขนาดไฟล์ที่โหลดมา คำโฆษณาว่า “รันบน RTX 5090 ได้” จึงจริงเฉพาะหลังผ่านขั้นนี้ ไม่ใช่โหลดแล้วรันได้เลย
• คอนเท็กซ์ที่เสิร์ฟจริงคือ 16,384 โทเคน แม้ config.json จะระบุ max_position_embeddings: 262144 ก็ตาม — การ์ดเขียนตรง ๆ ว่า “16,384 tokens as served” และคำสั่งตัวอย่างก็ใช้ --max-model-len 16384
• ไลเซนส์คือ Gemma Terms of Use ไม่ใช่ Apache หรือ MIT การ์ดระบุเองว่าเป็นอนุพันธ์ของ Gemma และข้อจำกัดการใช้งานของไลเซนส์ฐานมีผลทั้งหมด นี่คือ “เปิดน้ำหนัก” ไม่ใช่ “โอเพนซอร์ส”
• บน A100 ไม่มี FP8 เนทีฟ vLLM จึงใช้ weight-only FP8 ผ่าน Marlin ซึ่งการ์ดเขียนเองว่า “ประหยัดหน่วยความจำได้จริง แต่เร็วขึ้นไม่จริง” — ตัวเลข “ราวหนึ่งวินาที” ทั้งหมดวัดบน A100 80GB แบบยิงทีละรีเควสต์ หน้าจอที่แน่นใช้ 3–6 วินาที
• temperature และ seed ถูกเพิกเฉย เพราะ sampler เดินตามตารางของเช็กพอยต์เอง สองรีเควสต์ที่เหมือนกันจึงได้หน้าจอที่ใช้ถ้อยคำต่างกันได้ ใครวางแผนทำ regression test ต้องรู้ข้อนี้ก่อน
• กับดัก tool calling โมเดลรองรับฟอร์แมต tool call ของ Gemma 4 (ทดสอบแล้วเรียกถูก 9/9 และไม่เรียกเลยใน 3 โจทย์ที่ไม่เกี่ยว) แต่ tool_choice แบบ "required" หรือระบุชื่อฟังก์ชัน ถูกรับแล้วเพิกเฉย และที่อันตรายคือกรณี "required" จะได้ finish_reason: "tool_calls" กลับมาพร้อม tool_calls ที่ว่างเปล่า — การ์ดเตือนเองว่าอย่าแตกกิ่งโค้ดจาก finish_reason อย่างเดียว
• สตรีมมิงทำงานได้ แต่ข้อความมาทีละ canvas 256 โทเคน หน้าจอที่พอดีหนึ่ง canvas จึงมาเป็นก้อนเดียว ไม่ไหลทีละคำ

นอกจากนี้ config.json ยังเผยว่ามันมี vision_config ติดมาจากฐาน Gemma 4 (แท็กบน HF คือ image-text-to-text) ซึ่งบล็อกเปิดตัวไม่พูดถึงเลย และโครงสร้าง MoE คือ 128 experts เลือกใช้ 8 ตัวต่อโทเคน 30 เลเยอร์ สลับ sliding attention กับ full attention อัตราส่วน 5:1

มุมมอง AI Curator

เรื่องที่ควรจำจาก OUI-1 ไม่ใช่คะแนน 71.7% แต่คือ สูตรที่ทำซ้ำได้: ถ้างานของคุณมีตัวตรวจที่บอกถูกผิดได้แบบกลไก — parser, คอมไพเลอร์, type checker, schema validator, ชุดเทสต์ — คุณมี reward function ฟรีอยู่แล้ว และ rejection sampling ด้วย reward นั้นคือ RL รูปแบบง่ายที่สุดที่ทีมขนาดเล็กทำได้จริงบน A100 ใบเดียว ครั้งละหนึ่งถึงสองชั่วโมง ไม่ต้องมีคลัสเตอร์ ไม่ต้องมี PPO ไม่ต้องมีคนมานั่งเลเบล นี่คือรูปแบบที่ทีมไทยที่มีการ์ดสองสามใบทำตามได้จริง ตราบใดที่โดเมนของคุณมี parser

ข้อสังเกตที่สองน่าสนใจกว่าในเชิงเทคนิค: ทีมนี้เจอว่า supervised fine tuning ทำให้โมเดล diffusion ช้าลง เพราะเขียนของจริงมากขึ้นจึงต้อง denoise มากขึ้น นี่เป็นข้อแลกเปลี่ยนที่ไม่มีในโมเดล autoregressive และเป็นเหตุผลว่าทำไมความเร็วของ diffusion LLM ที่โฆษณากันจึงต้องอ่านคู่กับว่าเอาต์พุตมีเนื้อหาแค่ไหน — บังเอิญที่เมื่อวานเราเพิ่งเขียนถึง Mercury 2.5 ที่ประกาศ 1,107 tok/s โดยไม่มีตารางเบนช์มาร์กสักช่อง ทั้งสองเรื่องชี้ไปที่บทเรียนเดียวกัน คือ throughput ของ diffusion LLM ไม่มีความหมายถ้าไม่บอกว่าวัดจากเอาต์พุตแบบไหน

ส่วนที่ต้องระวังคือช่องว่างระหว่างการตลาดกับไฟล์จริง คำว่า “รันบนการ์ดเกม” กับไฟล์ bf16 ขนาด 51.98 GB อยู่ในหน้าเดียวกัน และมันไม่ได้ขัดกัน — แต่มันต้องการขั้นตอน quantize ที่ผู้อ่านต้องทำเอง เช่นเดียวกับคอนเท็กซ์ 16K ที่เป็นเลขใช้งานจริง ไม่ใช่ 262K ในคอนฟิก บทเรียนเดิมที่เราเจอซ้ำ ๆ ยังใช้ได้: การ์ดโมเดลและ config.json คือแหล่งข้อมูลปฐมภูมิ ส่วนบล็อกเปิดตัวคือการตลาด — ในกรณีนี้ต้องให้เครดิต Thesys ว่าการ์ดของเขาซื่อสัตย์ผิดปกติ ทั้งเรื่อง Marlin ที่ “ไม่เร็วขึ้นจริง” และกับดัก finish_reason ซึ่งเป็นสิ่งที่ทีมส่วนใหญ่เลือกจะไม่เขียน

สำหรับบริบทไทย generative UI มีมุมที่ยังไม่มีใครตอบ: การ์ดระบุภาษาไว้แค่ en และเบนช์มาร์กทั้งหมดเป็นบรีฟภาษาอังกฤษ คำถามว่าโมเดลที่แอ็กทีฟ 4B ตัวนี้จะรับบรีฟภาษาไทยแล้วเขียนหน้าจอที่ parse ผ่านได้หรือไม่ ยังไม่มีใครวัด — และเพราะเบนช์มาร์กเปิดโค้ดพร้อมเอาต์พุตดิบ นี่คือการทดลองที่ทีมไทยรันเองได้ในหนึ่งบ่าย

แหล่งข่าว

• Introducing OUI-1: world’s first model for Generative UI — OpenUI Blog (8 ก.ย. 2026)
• thesysdev/OUI-1 — การ์ดโมเดลและน้ำหนักบน Hugging Face
• thesysdev/generative-ui-bench — โปรโตคอลเบนช์มาร์กและเอาต์พุตดิบ
• Generative UI Benchmark — กระดานคะแนน