- Gemini Diffusion ที่กูเกิลประกาศเปิดตัว เป็น LLM รุ่นแรกที่ใช้แนวทางการแพร่กระจาย (Diffusion) แทนทรานส์ฟอร์เมอร์
- คล้ายกับที่ใช้ในโมเดลภาพอย่าง Imagen หรือ Stable Diffusion
- โมเดลนี้สร้างข้อความผ่านกระบวนการ diffusion ที่ค่อย ๆ กลั่นกรอง noise ทีละขั้น แทนที่จะใช้ วิธีอัตโนมัติแบบออโตรีเกรสซีฟ เดิม
- ผลลัพธ์คือ ตอบสนองได้รวดเร็วมาก โดยในการทดสอบแสดงประสิทธิภาพที่ระดับ 857 โทเค็นต่อวินาที
- แม้ยังมีเบนช์มาร์กที่แม่นยำไม่มากนัก แต่กูเกิลอ้างว่าเร็วกกว่า Gemini 2.0 Flash-Lite ถึง 5 เท่า
ภาพรวมของ Gemini Diffusion
- Gemini Diffusion คือโมเดลภาษาขนาดใหญ่ (LLM) ตัวใหม่ที่กูเกิลเปิดเผย
- แทนที่จะใช้แนวทางออโตรีเกรสซีฟ (autoregressive) ของ LLM แบบทรานส์ฟอร์เมอร์เดิม โมเดลนี้เลือกใช้ แนวทาง diffusion
- วิธี diffusion นี้ถูกนำไปใช้กับการสร้างข้อความ แม้หลักการจะทำงานคล้ายโมเดลสร้างภาพอย่าง Imagen และ Stable Diffusion
- จุดเด่นสำคัญคือ ความเร็วในการตอบสนองสูง และความสามารถในการแก้ข้อผิดพลาดระหว่างกระบวนการสร้างได้อย่างมีประสิทธิภาพ
- ในตัวอย่างการใช้งาน เมื่อใส่พรอมป์ต์ "Build a simulated chat app" โมเดลสามารถให้ผลลัพธ์เป็น HTML+JavaScript ได้ภายในไม่กี่วินาที และทำความเร็วได้ สูงสุด 857 โทเค็นต่อวินาที
วิธีการทำงานของโมเดลภาษาแบบ diffusion
- โมเดลภาษาแบบออโตรีเกรสซีฟ เดิมจะสร้างโทเค็นทีละตัวตามลำดับ จึงช้ากว่าและมีข้อจำกัดด้านความสอดคล้องของผลลัพธ์
- ขณะที่ โมเดล diffusion เริ่มจาก noise แล้วค่อย ๆ ปรับปรุงผลลัพธ์ โดยประมวลผลทั้งประโยคหรือทั้งย่อหน้าในคราวเดียวผ่านหลายขั้นตอน
- ด้วยเหตุนี้จึงสามารถ สร้างโทเค็นแบบขนาน ได้ และทำให้สร้างผลลัพธ์ได้รวดเร็วมาก
- จึงมีประสิทธิภาพในงานอย่างการแก้ไขข้อความ คณิตศาสตร์ และโค้ด ซึ่งเป็น งานที่ต้องการฟีดแบ็กทันที
โมเดลที่คล้ายกันและการเปรียบเทียบประสิทธิภาพ
- ก่อนหน้านี้แทบไม่มี diffusion LLM เชิงพาณิชย์ โดยในเดือนกุมภาพันธ์ 2024 โปรเจ็กต์ Inception Mercury ได้ปรากฏขึ้นเป็นกรณีแรก
- ในแง่ความเร็วและประสิทธิภาพ Gemini Diffusion มีระดับใกล้เคียงกับ Gemini 2.0 Flash-Lite ตามเกณฑ์ของกูเกิล แต่เร็วกว่าอยู่ราว 5 เท่า
- โมเดลนี้แสดงความเร็วในการสร้างสูงคล้ายกับ Cerebras Coder และคาดว่าจะมี ข้อมูลเบนช์มาร์กเชิงวัตถุวิสัย เพิ่มเติมในอนาคต
คำอธิบายเพิ่มเติมและการแก้ความเข้าใจ
- โมเดลภาษาแบบ diffusion ไม่ได้ แทนที่สถาปัตยกรรมทรานส์ฟอร์เมอร์ ทั้งหมด แต่เปลี่ยนโครงสร้างการสร้างข้อความจากแบบออโตรีเกรสซีฟมาเป็นแบบ diffusion
- ทั้ง Mercury และ Gemini Diffusion ยังอยู่บนพื้นฐานทรานส์ฟอร์เมอร์ แต่ ประมวลผลอินพุตทั้งหมดพร้อมกัน และมีวิธีการสร้างที่แตกต่างกัน
- นี่คือรูปแบบที่พัฒนาต่อจากแนวทาง การมาสก์และกู้คืนแบบ BERT โดยค่อย ๆ เพิ่มอัตราการมาสก์ และยังค่อย ๆ สร้างผลลัพธ์ให้สมบูรณ์ได้แม้ในสถานะที่ทุกโทเค็นถูกมาสก์ทั้งหมด
- วิธี diffusion จะยืนยันโทเค็นเพียงบางส่วนในแต่ละขั้นตอน แล้วเพิ่มสัดส่วนของโทเค็นที่ยืนยันแล้วซ้ำ ๆ จนได้ลำดับทั้งหมดที่สมบูรณ์
- แนวคิดหลัก ของ diffusion LLM คือการกู้คืนแบบค่อยเป็นค่อยไปและการสร้างแบบขนาน
บทสรุป
- Gemini Diffusion เป็น LLM รุ่นใหม่ที่แสดงคุณสมบัติพลิกเกมทั้งด้านความเร็วและคุณภาพการสร้าง
- มันขยายข้อดีของโมเดล diffusion ที่พิสูจน์แล้วในงานสร้างภาพ มาสู่การสร้างข้อความได้อย่างสำเร็จ
- ทำให้ความคาดหวังต่อการใช้งานจริงในหลากหลายงานและผลเบนช์มาร์กในอนาคตเพิ่มสูงขึ้น
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมเองก็ไม่แน่ใจว่าภายในของ Google มันทำงานอย่างไรจริง ๆ แต่ฝั่ง RWKV ช่วงหลังมีเรื่องน่าสนใจเกิดขึ้น พวกเขาทดลองเปลี่ยนกลไก attention เดิมทั้งหมดเป็น WKV (linear attention) และทำทั้งหมดนี้ได้ด้วย post-training เท่านั้น สิ่งที่ชวนให้คิดคือ ความรู้อันเป็นประโยชน์ส่วนใหญ่อาจอยู่ใน FFN (feedforward network) เป็นหลัก และตัว attention เองอาจไม่ได้มีความพิเศษหรือสำคัญอย่างที่เคยคิดก็ได้ ลองดูลิงก์ที่เกี่ยวข้องประกอบก็น่าสนใจดี อีกด้านหนึ่ง การนำ attention ที่ฝึกมาแล้วมาใช้ และลองวัดว่าการเทรนเฉพาะ FFN ในความเร็วระดับ GPT-2 เร็วได้แค่ไหน แม้จะผิดกฎอยู่บ้าง แต่ก็เป็นการทดลองที่น่าอ่านในรูปแบบเปเปอร์ เมื่อวานผมยังได้อ่านเรื่องที่บอกว่า ในบางช่วง embedding ของทุกโมเดลจะมีความคล้ายกันมาก จนสามารถฝึกตัวแปลงแบบง่าย ๆ ได้ และถ้าทั้งสองอย่างนี้เป็นจริง เราอาจแชร์ embedding กับ attention ร่วมกันและทำให้การฝึกทั้งหมดเร็วขึ้นมากได้
ถ้าจะอธิบาย attention โดยให้ความเคารพสูงสุดต่อนักวิจัยทั้งหลาย ผมมองว่ามันคือการรับข้อมูลอดีตทั้งหมดของเครือข่าย แล้วโยนเข้าไปในโครงข่ายประสาทแบบ reverse-MoE โดยที่ “ผู้เชี่ยวชาญ” ตรงนี้ไม่ได้เลือกบางส่วนของเครือข่ายมาทำงาน แต่เลือกบางส่วนของอินพุตแทน เรารู้กันอยู่แล้วว่าวิธีนี้น่าจะได้ผล แต่ไร้ประสิทธิภาพมากจนแม้แต่ผู้ใช้ R หรือ Python ก็ยังไม่คิดจะลองรัน โครงสร้างแบบนี้ช้ามากจนแทบทดลองใช้งานจริงไม่ได้
เลยเริ่มคิดว่า "Attention is all you need" อาจตีความได้อีกความหมายหนึ่ง ว่า attention อาจไม่ได้จำเป็นอย่างที่ว่า
ประเด็นที่ว่า embedding ของโมเดลต่าง ๆ มีความคล้ายกันมากจน map หากันได้ด้วยตัวแปลงง่าย ๆ มาจากตรงนี้
ผมมองว่า attention เป็นเพียงวิธีที่ค่อนข้างตามอำเภอใจในการแบ่งเครือข่ายเพื่อให้เทรนแบบขนานได้ สิ่งที่มีส่วนทำให้สำเร็จจริง ๆ คือ shortcut connection ระหว่างเลเยอร์ ซึ่งทำให้เลเยอร์ช่วงต้นมีอิทธิพลต่อการเรียนรู้มากขึ้น
ทุกวันนี้ก็รู้กันอยู่แล้วว่า SDPA attention ที่ใช้ใน transformer สมัยใหม่ไม่ได้มีความสำคัญสัมพัทธ์สูงนัก FFN, normalization และ residual connection แทบจะขาดไม่ได้ แต่ attention นั้นแทนที่ได้ค่อนข้างง่ายด้วยเลเยอร์แบบอื่นที่ใช้แบ่งปันข้อมูลระหว่างโทเค็น เช่น pooling, convolution หรือ random mixing
เร็วแบบเหลือเชื่อจริง ๆ จนถึงตอนนี้ผมยังคิดว่ากรณีใช้งานที่ดีที่สุดของโมเดลคือการเขียนโค้ดใหม่ทั้งหมดและการทำ prototype อย่างรวดเร็ว แต่ยังไม่เห็นว่ามันเก่งมากกับการปรับปรุง codebase ขนาดใหญ่ที่ผ่านการแก้ซ้ำ ๆ มาหลายรอบแล้ว เหตุผลหนึ่งคือ โดยนิยามแล้ว โมเดลย่อมไม่รู้เรื่องสิ่งที่ “ไม่ได้ถูกรวมอยู่” ใน codebase ทั้งที่การ “ไม่มีบางอย่างอยู่ในโค้ด” เองก็เป็นสัญญาณที่มีความหมายมาก และเป็นสิ่งที่ถ่ายทอดออกมาได้ค่อนข้างยาก ต่อให้โมเดลฉลาดแค่ไหน ผมก็ยังคิดว่ามันติดข้อจำกัดพื้นฐานตรงที่ขาด “บริบทและประสบการณ์ภายใน” เช่น ถ้าคุณให้ codebase ใหญ่มากแก่โปรแกรมเมอร์ฝีมือเยี่ยมแล้วให้แก้ปัญหาเฉพาะหน้าในทันที นักพัฒนาระดับธรรมดาที่รู้จัก codebase นั้นดีอาจสร้างผลลัพธ์ที่มีคุณค่ากว่าได้ในเวลาเท่ากัน
ถ้าโฟกัสที่วิธีการสื่อสาร ปัญหานี้พอแก้ได้ เวิร์กโฟลว์หลักของผมช่วงนี้คือ ถ้ามีงานใหญ่ ๆ อย่างฟีเจอร์ใหม่หรือการรีแฟกเตอร์ ผมจะเริ่มคุยกับ o3 เหมือนเป็นเพื่อนร่วมงาน คอยแปะไฟล์ซอร์สที่จำเป็นเพิ่มเข้าไปเพื่อให้บริบท แล้วคุยกันในระดับสูงทั้งเรื่องเป้าหมายและสภาพโค้ดปัจจุบัน ผมรู้สึกว่ากระบวนการนี้ช่วยให้ทั้งสิ่งที่ผมต้องการทำและบริบทของ codebase ชัดเจนขึ้น จากนั้นผมจะให้ o3 ช่วยวางแผนการ implement แล้วส่งต่อให้ Codex ไปทำขั้นตอนอัตโนมัติต่อ เช่น อ่านซอร์ส แก้ไฟล์ รันทดสอบ ฯลฯ พอได้ PR แล้ว บางครั้งก็แก้ด้วยมืออีกนิดหน่อย หรือบางครั้งก็ merge ได้เลย ผมเห็นด้วยว่าโมเดลต้องการบริบทที่เข้มข้น แต่ผมไม่คิดว่านี่เป็นข้อจำกัดโดยเนื้อแท้ มันเป็นเรื่องของวิธีร่วมงานกันอย่างมีประสิทธิภาพมากกว่า ถ้าคุณชำนาญพอ มันไม่เพียงเพิ่ม productivity แต่ยังทำให้กระบวนการทำงานสนุกขึ้นมากสำหรับผมด้วย
ผมรู้สึกเห็นด้วยอย่างลึกซึ้งกับมุมมองที่ว่า “สิ่งที่ไม่มีอยู่ใน codebase ก็เป็นสัญญาณที่มีความหมาย” ทำซอฟต์แวร์มานาน แต่ไม่เคยตระหนักถึงความจริงพื้นฐานข้อนี้ได้ชัดเจนขนาดนี้มาก่อน ขอบคุณสำหรับมุมมองนี้
จากประสบการณ์ของผม LLM เก่งในการเลียนแบบโค้ดดี ๆ ที่มีอยู่แล้ว แต่ไม่ค่อยสร้างส่วนที่ใหม่และมีความคิดสร้างสรรค์จริง ๆ ด้วยตัวเอง เว้นแต่เราจะระบุขออย่างชัดเจน และบ่อยครั้งมันก็ยัง ingest codebase ได้ไม่พอ จนเราต้องระบุส่วนอื่น ๆ ของโปรเจกต์ให้โดยตรงอยู่ดี ถึงอย่างนั้น ถ้าใส่ “negative prompt” ได้เหมือนใน Stable Diffusion ก็คงเจ๋งมาก
ผมสงสัยว่าถ้า LLM สามารถอ่านข้อความทั้งหมดของ git history, issue tracker และแม้แต่บันทึกการประชุมเป็น context ได้ ผลลัพธ์จะออกมาแบบไหน คงต้องดูกันต่อไปว่าคอนเท็กซ์ขนาดมหาศาลแบบนั้นจะนำไปสู่ผลลัพธ์ที่ใช้ได้จริงหรือไม่
ผมประหลาดใจกับประกาศนี้มาก คิดว่านี่คือประกาศที่ใหญ่ที่สุดในงาน IO แต่กลับถูกข่าวอื่นอย่าง Veo 3 กลบไป น่าเสียดายมาก การใช้ diffusion model มาสร้างโค้ดมีนัยสำคัญมาก ถ้าใช้ transformer ก็จะอยู่ในตระกูล DiT (diffusion transformer) ผมเคยมีส่วนร่วมกับโมเดลไฮบริดที่ผสาน diffusion แบบ U-Net เมื่อหลายปีก่อน และหลังจากนั้นก็มีความก้าวหน้าอีกมาก ผมคิดว่าวงการ diffusion กำลังจะมีการก้าวกระโดดครั้งใหญ่
ผมสงสัยว่าถ้าเอาสัญชาตญาณจาก vision transformer มาปรับใช้กับโค้ด มันจะทำงานอย่างไร ในงานด้านภาพ เราเริ่มจาก noise แล้วค่อย ๆ ทำให้ภาพเป้าหมายชัดขึ้นทีละระดับ ถ้าใช้หลักการเดียวกันกับการสร้างโค้ด อาจต้องมีโครงสร้างแบบลำดับชั้นที่ค่อย ๆ ลดระดับความเป็นนามธรรมลง เช่น “ต้องใช้ Django”, “กำหนดรายการ endpoint”, แล้วค่อย “สร้างโค้ดจริง” แต่ diffusion ไม่มีกลไก backtracking ดังนั้นถ้าตรวจพบปัญหาระดับล่าง ก็อาจส่ง feedback กลับไปยังเลเยอร์บนได้ไม่ดีนัก ในทางกลับกัน transformer รันทั้งโมเดลต่อหนึ่งโทเค็น จึงย้อนกลับไปเปลี่ยนการออกแบบตามปัญหาได้ง่ายกว่า โมเดลในหัวผมอาจมีข้อบกพร่องก็ได้ อยากฟังมุมมองเพิ่ม
Veo 3 กลายเป็นกระแสเพราะเห็นประสิทธิภาพและจุดต่างได้อย่างตรงไปตรงมา แต่การจะเข้าใจคุณค่าของความก้าวหน้าสำคัญในงาน text completion ต้องรู้ทั้งความสำเร็จเดิมและศักยภาพในการใช้งาน หลายคนตอนนี้ยังไม่มั่นใจด้วยซ้ำว่า LLM มีประโยชน์กับงานเขียนโค้ดจริง
โมเดลสร้างโค้ดแบบ diffusion นี่ถือว่าพลิกเกมจริง ๆ ไอเดียง่าย ๆ ที่โมเดลแบบนี้ทำได้ เช่น กำหนด function signature กับผลลัพธ์ไว้ตายตัว แล้วสร้างโทเค็นตรงกลางโดยใช้ข้อมูลจากสองฝั่ง หรือร่างโครงใหญ่ของฟังก์ชันก่อน เหมือนให้ LLM เขียน “บท” ของบทความ แล้วค่อยแตกงานย่อยลงเป็นระดับ implementation ใช้สัญญาณต่าง ๆ อย่าง linters, ข้อมูล AST ฯลฯ ภายใน context ที่ใหญ่กว่าเพื่อคอยกำหนดทิศทางระหว่างการสร้าง มีอะไรให้ทดลองอีกเยอะมาก
ตามหลักการแล้ววิธีนี้น่าจะมีข้อได้เปรียบมาก แต่จากที่ผมลองโมเดลอย่าง LLaDA แม้ใช้ทรัพยากรฝึกไม่มากก็ยังน่าประทับใจ อย่างไรก็ดี ในเกณฑ์อย่าง perplexity ก็ยังตามหลังอยู่ และมันมีแนวโน้มจะ “ตรึงตัว” ระหว่างการสร้าง ทำให้มีข้อจำกัดในการแก้ไขข้อความแบบลึก ๆ ยิ่งความน่าจะเป็นของการ masking สูง การแก้หลายจุดพร้อมกันก็ยิ่งยาก ถึงแบบนั้น ในการทดลองจริงก็ยังได้ผลลัพธ์ที่ใช้ได้ค่อนข้างดี
ผมเคยเห็นเดโมจาก InceptionLabs และที่อื่น ๆ มาแล้ว เลยไม่ได้รู้สึกเซอร์ไพรส์ขนาดนั้น
ดูเหมือนประเด็นสำคัญของข่าวนี้จะถูกมองข้ามไป มันคือ InstructGPT ที่เร็วมากและคุณภาพดี ต่อไปมันจะต้องถูกนำไปใช้ในตัวตรวจการสะกด, codemod และ code editor อย่างแน่นอน ฟีเจอร์ Instant edits ทำให้แก้ไขข้อความได้เร็วและแม่นมาก โดยไม่ชอบแทรกสิ่งเกินจำเป็นหรือเสนอแนะพร่ำเพรื่อ ผมลองเอาโค้ดตัวอย่างจาก ShaderToy ไปขอให้เปลี่ยนชื่อตัวแปรให้อ่านง่ายขึ้น แล้วคัดลอกผลลัพธ์ไปรัน ก็ยังทำงานได้ดีเหมือนเดิม น่าทึ่งมาก
ข้อดีของ diffusion ไม่ได้มีแค่ความเร็ว ตาม benchmark แรก ๆ มันเหนือกว่า AR ในด้านการอนุมานและการวางแผน แม้ใช้พารามิเตอร์เท่ากัน Diffusion ยังแก้ไขตรงกลางได้ และไม่เจอปัญหาอคติจากโทเค็นช่วงต้น
เป็นข้ออ้างที่น่าสนใจ อยากรู้ว่ามีลิงก์ benchmark หรือหลักฐานอ้างอิงที่เกี่ยวข้องไหม
ตัว AR เองไม่ได้ขัดขวางการวางแผนระยะยาวโดยเนื้อแท้ แต่ข้อจำกัดแบบนั้นมักเกิดจากวิธี implement ของโมเดล AR ยอดนิยมในปัจจุบัน และ AR เองก็สำคัญมากในการเรียนรู้ distribution ที่ถูกต้อง
โดยส่วนตัวผมเห็นด้วย หรืออย่างน้อยก็อยากให้เป็นจริง แต่ผมยังไม่เคยเห็นเปเปอร์หรือเดโมเกี่ยวกับ revise diffusion text เลย ถ้ามีข้อมูลเปเปอร์ก็อยากให้แชร์ เพราะอยากลองใช้มาก
ผมสนใจการนำ diffusion มาใช้กับการสร้างข้อความมานานแล้ว ในที่สุด Google ก็ออกโมเดลแบบนี้มา ทำให้ผมรู้สึกเหมือนได้รับการยืนยันว่าที่คิดไว้นั้นมาถูกทาง ในแง่ฮาร์ดแวร์ที่ใช้ทดลอง ส่วนใหญ่ทุกวันนี้ต้องพึ่งบริการเสียเงินหรืออุปกรณ์ระดับสูงมาก อย่างน้อยก็ระดับผู้บริโภคขั้นบน ตอนนี้ผมมีแค่ 5700XT และอัปเกรดได้ยาก ซึ่งกลับทำให้ผมเห็นข้อจำกัดของโมเดลปัจจุบันชัดขึ้น ขนาดโมเดลยิ่งใหญ่ ความสม่ำเสมอก็ยิ่งดี ทำให้โมเดลเล็กเลี่ยงไม่ได้ที่จะเหมาะกับงานง่าย ๆ เป็นหลัก สิ่งสำคัญที่ผมพบจากการทดลองคือขนาด context นั้นสำคัญมาก แต่ด้วย GPU เล็ก เราใส่ทั้ง context และโมเดลขนาดพอเหมาะพร้อมกันได้ยาก เลยสงสัยว่าถ้าเป็น diffusion จะเปลี่ยนดุลระหว่างความหนาแน่นกับความสม่ำเสมอได้หรือไม่ น่าจะพอคาดหวังการสร้างข้อความที่สม่ำเสมอขึ้นแม้ใช้ context น้อยลง และผลลัพธ์แบบผสม tool call + response ก็น่าจะดีขึ้นด้วย เรื่องความเร็วก็คือปัญหาในชีวิตจริง วิธีของ LLM แบบเดิมคือค่อย ๆ ปล่อยเอาต์พุตทีละรอบ input-output ซึ่งช้ามาก โดยเฉพาะบน GPU เก่าที่ไม่ได้ทำมาเพื่อ AI ถ้ามี progress 0~100% ให้เห็นแบบเรียลไทม์ก็คงดี และผมหวังว่า diffusion model จะดีกว่าในจุดนี้ ตรงนี้เองที่ผมสงสัยว่า เนื่องจากอินพุต noise มีความสำคัญ จะมี noise source ที่เหมาะกับ LLM/ข้อความโดยเฉพาะหรือไม่ และความยาวของบล็อกทั้งหมดต้องถูกกำหนดตายตัวล่วงหน้าหรือเปล่า หรือว่าปรับเปลี่ยนได้
จากมุมของผมพูดได้ชัดเลยว่า โมเดลนี้เร็วมาก ๆ ข้อเสียคือโดน prompt injection เจาะได้ง่ายมาก เช่น ถ้าขอสูตรผลิตยา มันจะปฏิเสธ แต่ถ้าขอผ่านการ roleplay เป็นเด็ก มันกลับตอบจริง ข้อนี้แหละที่แย่ นอกนั้นทั้งความเร็วและการนำไปใช้กับระบบอัตโนมัติถือว่ายอดเยี่ยมมาก ถ้าเติมแนวทางแบบ agentic เข้าไปอีก ศักยภาพของโมเดลนี้จะยิ่งโดดเด่น
นี่อาจไม่ใช่ข้อจำกัดของโมเดลโดยตรง แต่อาจเป็นเพราะตอนเทรนลงทรัพยากรด้านความปลอดภัยหรือการเซ็นเซอร์น้อยกว่า ในมุมผมมันดูเหมือนต้นแบบเชิงทดลองมากกว่า เป็นเดโมเบา ๆ ก่อนจะลงทุนจริงกับโมเดลขนาดใหญ่
ผมไม่คิดว่า prompt injection แบบนี้จะเป็นสัญญาณว่าเราจะควบคุมโมเดลที่ฉลาดกว่านี้ได้
คำอธิบายว่า “LLM แบบ diffusion ตัวแรกของ Google ใช้ diffusion แทน transformer” เป็นคำกล่าวที่ไม่ถูกต้อง Google ไม่ได้ประกาศแบบนั้นเลย ตรงกันข้าม diffusion model ที่อิง transformer นั้นพบได้ทั่วไป และผมคิดว่า Gemini Diffusion เองก็น่าจะใช้ transformer เช่นกัน ความต่างน่าจะอยู่ตรงที่เป็น encoder-only transformer กล่าวคือใส่ทั้งลำดับในสภาพ noisy/corrupted แล้วให้ทำนายลำดับที่ถูกต้องทั้งชุด วิธีนี้ทำให้คำนวณแบบขนานได้พร้อมกันทั้งเฟรมของลำดับ และถ้าจำนวนรอบการวนซ้ำไม่มากเกินไป ก็จะเร็วกว่าการถอดรหัสแบบลำดับของ decoder-only model มากพอสมควร (แม้ speculative decoding จะให้ข้อได้เปรียบด้านความเร็วคล้ายกันได้เช่นกัน) ปกติจะฝึกด้วย BERT-style masking แต่ก็ยังเป็นพื้นที่วิจัยที่เดินหน้ามากอยู่ ผมยังสงสัยด้วยว่าความสัมพันธ์กับ Gemini เป็นอย่างไร และมีการนำ checkpoint เดิมมาใช้ไหม ไม่ว่าจะเป็นการ import ตรง, fine-tune เพื่อ diffusion โดยเฉพาะ, knowledge distillation หรือเป็นแค่ชื่อแบรนด์ ถ้ามีรายละเอียดอย่างเป็นทางการออกมาก็คงดี
เร็วจนน่าเหลือเชื่อ GPU น่าจะทำงานเต็มกำลังตลอด และผมเดาว่าแทบไม่มีประโยชน์จากการประหยัดคอมพิวต์แบบ batch processing แต่พอคิดดูแล้วก็อาจเรียกเป็น tradeoff แบบตรง ๆ ไม่ได้ สิ่งที่ผมกังวลคือ diffusion objective อาจด้อยกว่า AR ในด้านคุณภาพ ถ้าเป็นอย่างนั้น ทางเลือกหนึ่งคือ multi-token AR model อาจทำความเร็วได้ใกล้ diffusion หรือใช้ diffusion model เป็นตัวร่างสำหรับ speculative decoding ก็ได้
ผมอยากรู้ว่าทำไมคุณถึงคิดว่า dLLM จะคุณภาพด้อยกว่า arLLM เพราะในเมื่อมันประมวลผลเอาต์พุตเป็น “องค์รวมที่มีโครงสร้าง” แบบวนซ้ำ ทั้งระดับหัวข้อ ประเด็น แนวคิด และโครงสร้างคำ มันอาจให้คุณภาพดีกว่าด้วยซ้ำ
tradeoff เชิงโครงสร้างแบบนี้จะได้เปรียบมากกว่าในสภาพแวดล้อมโฮสต์เอง เพราะไม่ต้องใช้ batch ใหญ่ ๆ ในคลาวด์อาจไม่เด่นมาก แต่กับ local LLM ถือว่าเป็นข้อดีชัดเจน
ผมตื่นเต้นกับ diffusion LLM มาก ทีมของเราฝันถึงระบบกลไกเกมแบบเสียงพูด → โค้ด และ diffusion อาจเป็นชิ้นส่วนสุดท้ายที่ทำให้มันสมบูรณ์ได้ Cerebras กับ Groq นั้นยอดเยี่ยม แต่เพราะเป็นฮาร์ดแวร์เฉพาะทางจึงมีข้อจำกัดเรื่องการ fine-tune และการสเกล ทางเลือกอื่นที่เหลือคือ MoE ที่มี active parameter ราว 0.5b แต่ตอนนี้เรายังไม่มีทรัพยากรพอจะทุ่มให้โปรเจกต์นั้น ถ้ามีคนจาก Google/DeepMind มาเห็น อยากขอให้ช่วยเปิด API ให้ด้วย ทีมเรากำลังพัฒนาเกม sandbox เชิงสร้างสรรค์ โดยผลงานแรกเป็นเกมที่ผู้เล่นออกคำสั่งให้มอนสเตอร์แบบเรียลไทม์ เรามีวิดีโอต้นแบบด้วย ถ้าได้ดูก็น่าจะช่วยเห็นภาพ