DiffusionGemma: การสร้างข้อความเร็วขึ้น 4 เท่า

 (blog.google)
3 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DiffusionGemma เป็นโมเดลเปิดสำหรับการทดลองแบบ 26B MoE ภายใต้ไลเซนส์ Apache 2.0 ที่สร้างบล็อกข้อความทั้งก้อนพร้อมกันด้วยแนวทาง text diffusion
  • แทนการสร้างโทเค็นแบบลำดับทีละตัวของ LLM แบบออโตรีเกรสซีฟทั่วไป โมเดลนี้ใช้การสร้างแบบขนาน 256 โทเค็น จึงให้การสร้างข้อความได้เร็วขึ้นสูงสุด 4 เท่าบน GPU เฉพาะทาง
  • ระหว่างการอนุมาน จะเปิดใช้งานพารามิเตอร์เพียง 3.8B พารามิเตอร์ จากทั้งหมด 26B และเมื่อทำ quantization แล้วสามารถทำงานให้พอดีกับ GPU เฉพาะทางระดับผู้ใช้ขั้นสูงภายใต้ข้อจำกัด VRAM 18GB
  • ด้วย bidirectional attention และการแก้ไขตัวเองแบบวนซ้ำ จึงมีข้อได้เปรียบกับงานที่มี โครงสร้างไม่เชิงเส้น เช่น การแก้ไขแบบ inline, code infilling, ลำดับกรดอะมิโน และกราฟคณิตศาสตร์
  • เนื่องจากเป็นโมเดลทดลองที่ให้ความสำคัญกับความเร็วและการสร้างเลย์เอาต์แบบขนาน คุณภาพผลลัพธ์โดยรวมจึงต่ำกว่า Gemma 4 มาตรฐาน และแนะนำให้ใช้งาน Gemma 4 มาตรฐาน สำหรับแอปพลิเคชันที่ต้องการคุณภาพสูงสุด

คุณค่าใหม่สำหรับนักพัฒนา

  • DiffusionGemma เป็นโมเดลเปิดเชิงทดลองที่สำรวจ text diffusion และสร้างบล็อกข้อความทั้งก้อนพร้อมกัน แทนที่จะประมวลผลแบบลำดับทีละโทเค็นเหมือน LLM แบบออโตรีเกรสซีฟทั่วไป
  • โมเดลนี้เป็น Mixture of Experts (MoE) ขนาด 26B ที่เผยแพร่ภายใต้ไลเซนส์ Apache 2.0 และให้การสร้างข้อความเร็วขึ้นสูงสุด 4 เท่าบน GPU
  • พัฒนาต่อยอดจากความฉลาดต่อพารามิเตอร์ของตระกูล Gemma 4 และ Gemini Diffusion research พร้อมผสาน diffusion head แบบใหม่เพื่อเร่งความเร็วในการสร้างให้สูงสุด
  • โมเดล Gemma 4 แบบออโตรีเกรสซีฟยังคงเป็นมาตรฐานสำหรับผลลัพธ์ระดับโปรดักชันคุณภาพสูง ขณะที่ DiffusionGemma ถูกออกแบบมาสำหรับนักวิจัยและนักพัฒนาที่ต้องการสำรวจเวิร์กโฟลว์แบบโต้ตอบบนเครื่องโลคัลซึ่งความเร็วมีความสำคัญ

  • จุดแลกเปลี่ยนหลัก

    • การอนุมานที่รวดเร็ว ย้ายคอขวดของการถอดรหัสจากแบนด์วิดท์หน่วยความจำไปสู่การประมวลผล ทำให้ส่งออกโทเค็นได้เร็วขึ้นสูงสุด 4 เท่าบน GPU เฉพาะทาง
    • สร้างโทเค็นได้มากกว่า 1000 โทเค็นต่อวินาทีบน NVIDIA H100 เดี่ยว และมากกว่า 700 โทเค็นต่อวินาทีบน NVIDIA GeForce RTX 5090
    • การเข้าถึงฮาร์ดแวร์ได้ง่ายขึ้น มาจากสถาปัตยกรรมที่เปิดใช้งานพารามิเตอร์เพียง 3.8B ระหว่างการอนุมาน จาก 26B MoE ทั้งหมด
    • เมื่อทำ quantization แล้ว สามารถทำงานให้พอดีกับขีดจำกัด VRAM 18GB ของ GPU เฉพาะทางระดับผู้ใช้ขั้นสูง
    • bidirectional attention สร้าง 256 โทเค็นแบบขนานในแต่ละ forward pass ทำให้ทุกโทเค็นอ้างอิงถึงกันและกันได้
    • มีข้อได้เปรียบในโดเมนไม่เชิงเส้น เช่น การแก้ไขแบบ inline, code infilling, ลำดับกรดอะมิโน และกราฟคณิตศาสตร์
    • การแก้ไขตัวเอง คือการที่โมเดลค่อย ๆ ปรับผลลัพธ์แบบวนซ้ำ โดยประเมินบล็อกข้อความทั้งหมดพร้อมกันและแก้ข้อผิดพลาดแบบเรียลไทม์
    • สถานะเชิงทดลองและคำแนะนำสำหรับโปรดักชันมีความชัดเจน โดยเนื่องจากให้ความสำคัญกับความเร็วและการสร้างเลย์เอาต์แบบขนาน คุณภาพผลลัพธ์โดยรวมจึงต่ำกว่า Gemma 4 มาตรฐาน

  • ตัวอย่างการ fine-tuning

    • ประสิทธิภาพในงานเฉพาะสามารถปรับปรุงได้ด้วย fine-tuning
    • Unsloth ได้ fine-tune DiffusionGemma ให้แก้ซูโดกุ ซึ่งเป็นงานที่โมเดลออโตรีเกรสซีฟทำได้ยาก เพราะแต่ละโทเค็นต้องพึ่งพาโทเค็นในอนาคต
    • bidirectional attention ของ DiffusionGemma ทำให้งานอย่างซูโดกุง่ายขึ้นมาก

ทำไมต้องใช้ diffusion กับข้อความ

  • ชุมชนวิจัย AI สำรวจ การสร้างข้อความแบบ diffusion-based มาหลายปีแล้ว แต่การนำมาใช้กับโมเดลขนาดใหญ่ยังคงเป็นความท้าทาย
  • DiffusionGemma จัดการปัญหานี้ด้วยการเปลี่ยนวิธีที่โมเดลใช้งานฮาร์ดแวร์

  • จุดแลกเปลี่ยนเมื่อเทียบกับโมเดลเดิม

    • โมเดลภาษาส่วนใหญ่สร้างโทเค็นทีละตัวจากซ้ายไปขวา เหมือนเครื่องพิมพ์ดีด
    • บนคลาวด์ วิธีนี้มีประสิทธิภาพเพราะเซิร์ฟเวอร์สามารถ batch คำขอจากผู้ใช้หลายพันรายร่วมกันและแชร์ภาระของฮาร์ดแวร์ได้
    • แต่เมื่อผู้ใช้คนเดียวรันบนเครื่องโลคัล การสร้างทีละคำทำให้ใช้ GPU หรือ TPU เฉพาะทางได้ไม่เต็มที่ และฮาร์ดแวร์มักต้องรอ “การกดปุ่มพิมพ์” ถัดไป
    • DiffusionGemma ร่างย่อหน้าทั้งย่อหน้าขนาด 256 โทเค็นพร้อมกัน จึงส่งงานก้อนใหญ่ให้ตัวประมวลผลของคอมพิวเตอร์ได้ในครั้งเดียว
    • สถาปัตยกรรมนี้เปลี่ยนการอนุมานของโมเดลจากเครื่องพิมพ์ดีดแบบลำดับ ให้กลายเป็นเครื่องพิมพ์ขนาดใหญ่ที่พิมพ์บล็อกข้อความทั้งก้อนพร้อมกัน

  • ความเร็วที่ออกแบบมาสำหรับการอนุมานแบบโลคัลและ low-concurrency

    • การเพิ่มความเร็วของ DiffusionGemma ถูกออกแบบมาสำหรับ การอนุมานแบบโลคัล และการอนุมานที่มี concurrency ต่ำ
    • สำหรับการให้บริการบนคลาวด์ที่มี QPS สูง โมเดลออโตรีเกรสซีฟก็สามารถ deploy ให้ใช้การประมวลผลได้เต็มประสิทธิภาพเช่นกัน
    • ในสภาพแวดล้อม QPS สูง ข้อได้เปรียบของการถอดรหัสแบบขนานของ DiffusionGemma จะลดลง และค่าใช้จ่ายในการให้บริการอาจสูงกว่า
    • ข้อได้เปรียบด้าน throughput เด่นชัดที่สุดบนตัวเร่งเดี่ยวที่มีขนาด batch ตั้งแต่ต่ำถึงปานกลาง

text diffusion ทำงานอย่างไร

  • text diffusion นำขั้นตอนที่คล้ายกับการสร้างภาพด้วย AI ซึ่งเริ่มจาก visual noise แล้วค่อย ๆ ปรับปรุงซ้ำจนได้ภาพคมชัด มาประยุกต์ใช้กับข้อความ
  • ในขั้นตอนแรกที่เป็น canvas โมเดลจะเริ่มจากแคนวาสที่ประกอบด้วยโทเค็น placeholder แบบสุ่ม
  • ในขั้นตอนการปรับปรุงซ้ำ โมเดลจะทำหลาย pass ล็อกโทเค็นที่ถูกต้องไว้ แล้วใช้เป็นเบาะแสเชิงบริบทเพื่อปรับส่วนที่เหลือ
  • ในขั้นตอนเก็บรายละเอียดสุดท้าย ข้อความจะค่อย ๆ ลู่เข้าสู่ผลลัพธ์คุณภาพสูง
  • เนื่องจากโมเดลสามารถประมวลผลทั้งย่อหน้าได้ระหว่างการสร้าง จึงทำให้เกิดรูปแบบการทำงานที่สามารถปิด Markdown ที่ซับซ้อนได้อย่างถูกต้อง หรือสร้างและเรนเดอร์โค้ดได้แทบจะเรียลไทม์

วิธีเริ่มต้น

  • น้ำหนักโมเดลสำหรับการทดลองเปิดให้ใช้ภายใต้ไลเซนส์ Apache 2.0 แบบผ่อนปรน และเข้าถึงได้ผ่าน Hugging Face
  • ดูวิธีผสานรวมได้จาก DiffusionGemma developer guide และดูกลไกภายในเชิงลึกเพิ่มเติมได้ที่ A Visual Guide to DiffusionGemma
  • การให้บริการโมเดลสามารถทำได้ด้วย MLX, vLLM, Hugging Face Transformers
  • การผสานรวม vLLM ได้รับการสนับสนุนจาก Red Hat
  • สำหรับการทดลองอย่างรวดเร็ว มีทิวทอเรียล fine-tuning ที่อิงกับ Hackable Diffusion ซึ่งเป็นชุดเครื่องมือ JAX แบบโมดูลาร์ที่ออกแบบมาเพื่อ composability
  • ยังสามารถสำรวจการ fine-tuning ผ่าน Unsloth และ NVIDIA NeMo
  • การรองรับอย่างเป็นทางการใน llama.cpp จะมาในเร็ว ๆ นี้

การปรับแต่งและสภาพแวดล้อมการรัน

  • มีการปรับแต่งร่วมกับ NVIDIA ครอบคลุมทั้งฮาร์ดแวร์สแตก เพื่อให้ได้ทั้งความเข้ากันได้และประสิทธิภาพในสภาพแวดล้อมสำหรับผู้ใช้ทั่วไปและระบบองค์กร
  • สภาพแวดล้อมสำหรับผู้ใช้ทั่วไป รองรับ quantization สำหรับ GPU GeForce RTX 5090 และ 4090
  • สภาพแวดล้อมระดับองค์กร ให้ประสิทธิภาพสูงบน Hopper และ Blackwell ที่ใช้เคอร์เนล NVFP4 ขั้นสูง
  • NVIDIA DGX Spark และ DGX Station สำหรับการติดตั้งใช้งานแบบเดสก์ไซด์โลคัล รวมถึง RTX PRO สำหรับผู้เชี่ยวชาญด้าน AI ก็เป็นเป้าหมายเช่นกัน
  • การรองรับแบบเนทีฟของ NVFP4 floating point 4 บิต ช่วยเร่ง throughput ในการประมวลผล ทำให้โมเดลรันได้เร็วขึ้นพร้อมความแม่นยำที่แทบไม่สูญเสีย
  • สามารถเลือกวิธีรันได้ระหว่าง GPU เดสก์ท็อปเฉพาะทาง, Gemini Enterprise Agent Platform Model Garden, และ NVIDIA NIM

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Hacker News

  • ช่วงนี้ย้ายไปใช้ OpenCode เลยได้ลองใช้โมเดลที่ไม่ใช่ของแล็บวิจัย frontier หลัก ๆ ในอเมริกาเยอะขึ้น และโมเดลที่ชอบที่สุดแบบเหนือความคาดหมายคือ Mercury
    ไม่ใช่เพราะมัน “ฉลาด” แต่เพราะมันเร็วแบบเหลือเชื่อ ประสบการณ์มันใกล้กับการ pair programming มากกว่าประสบการณ์แบบเอเจนต์สมัยใหม่ที่ต้องใส่พรอมป์ต์แล้วรอ ทำให้ยังได้ข้อดีของ AI แต่ก็ได้ความรู้สึกในการเขียนโค้ดแบบก่อนยุค AI กลับมาบางส่วน เลยสนุกกว่า มันไม่เหมือนสล็อตแมชชีนที่ต้องใส่พรอมป์ต์แล้วรอลุ้นว่าทิศทางจะถูกไหม และทำให้หันไปใช้โมเดลเล็กอย่าง Gemini Flash Lite หรือ GPT Mini/Nano บ่อยขึ้นด้วย พอมีโมเดล open weights ออกมาก็น่าตื่นเต้นและตั้งใจจะลองทันที

    • ถ้าสามารถรันการทดสอบได้เร็วและถูก และยังสร้าง ตัวชี้วัดต้นทุนต่ำ เพื่อคัดแยกโค้ดแย่หรือโค้ดที่เขียนลวก ๆ ได้อย่างรวดเร็ว เวลาที่เวลาเป็นปัจจัยสำคัญ โมเดลที่เร็วกว่าแต่ด้อยกว่านิดหน่อยอาจดีกว่าโมเดลที่ช้ากว่าแต่ดีกว่ามาก
      พอมีตัวชี้วัดที่วัดความซับซ้อนจริงแทนความซับซ้อนแบบไซโคลแมติก แล้วตั้งให้ย้อนกลับอัตโนมัติจนกว่าความซับซ้อนที่เพิ่มเข้ามาเทียบกับฟังก์ชันการทำงานจะอยู่ในช่วงที่สมเหตุสมผล ผลลัพธ์จากการใช้ LLM ก็ค่อนข้างดีเลย
    • Mercury-2 ยอดเยี่ยมมาก ใช้เป็นผู้ตัดสินใน llm-consortium บ่อย ๆ
      หน้าต่างบริบทค่อนข้างเล็ก เลยถ้าจะใช้กับ consortium ที่ใหญ่กว่านี้ก็อาจจัดเป็นอะไรคล้าย meta-consortium แบบเรียกซ้ำได้:
      llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
      จากนั้นก็ใส่พรอมป์ต์ให้ cns-meta-glm-kimi เพื่อให้มันเลือกคำตอบที่ดีที่สุดจาก 5 คำตอบของ kimi และ glm อย่างละชุด แล้วสังเคราะห์คำตอบผู้ชนะทั้งสองเข้าด้วยกัน
    • สงสัยว่ามันจะมีผลกับ โมเดลโลคัล สำหรับเขียนโค้ดมากแค่ไหน ถ้าใช้ diffusion model ที่เร็วกว่า Qwen หรือ Gemma 4 หลายเท่า ฉันอาจต้องเตรียมอะไรเองมากขึ้นเหมือนก่อนยุค AI แต่บางทีมันอาจเป็นเรื่องดีก็ได้ และน่าจะทำงานกับโมเดลที่เร็วมากและถูกมากบนเครื่องโลคัลได้
      ถ้าไม่ต้องทำการคำนวณหนัก ๆ นาน ๆ ต้นทุนการรันบนฮาร์ดแวร์โลคัลก็น่าจะถูกลงด้วยหรือเปล่า
    • เข้าใจเลยว่าหมายถึงอะไร ในโปรเจกต์ส่วนตัว Claude ช้าเกินไปจนหงุดหงิด เลยเปลี่ยนไปใช้ Google Antigravity กับโมเดล Flash แล้วความเร็วต่างกันมหาศาล
      ทำให้เข้าจังหวะการทำงานได้ดีขึ้นและโฟกัสกับงานมากขึ้น ไม่คิดมาก่อนว่าความเร็วจะสร้างความต่างได้ขนาดนี้ สำหรับโค้ดเบสที่ใหญ่มากและซับซ้อนจริง ๆ Claude ยังอาจคุ้มที่จะแลกเวลาตอบที่ช้ากว่ากับความสามารถรับมือความซับซ้อนของงาน แต่ Antigravity หรือโมเดลเร็วตัวอื่นเหมาะกว่ามากเวลาที่อยากวนลูปเขียนโค้ด รัน และดีบักแบบเล็ก ๆ เบา ๆ
    • ใช่เลย ความเร็ว คือหัวใจสำคัญ การให้มันสร้าง boilerplate POJO หรือ data class ด้วยความเร็วบ้าคลั่งระดับ 300+ tok/s นี่ดีมาก และในลักษณะแบบนี้ Flash-Lite มีประโยชน์กว่า GPT-5.5 เสียอีก
      ถ้าช้าเกินไปก็จะติดอยู่ในลูปรอแบบอะซิงก์นรกนั่นแหละ

  • Google ยังคงแสดงให้เห็นถึงพลังอย่างต่อเนื่อง น่าแปลกที่ Gemini ยังไม่ได้แข่งขันได้มากกว่าพวก Claude หรือโมเดลของ OpenAI ในงานโค้ดหรือการใช้งานแบบเอเจนต์ แต่ก็ชัดเจนว่า Google ยังมีบุคลากร AI ระดับแนวหน้าของอุตสาหกรรมอยู่
    แต่ดูเหมือน Google จะโฟกัสกับกรณีใช้งานที่รันบนมือถือหรือเกือบเรียลไทม์ มากกว่า LLM ขนาดใหญ่สาย reasoning การปรับปรุง ประสิทธิภาพ แบบนี้มีแนวโน้มว่าจะสำคัญมากกับ AI ในอนาคต ช่วงเวลาที่แจกโทเค็นราคาถูกเหมือนเงินอุดหนุนเพื่อมัดผู้ใช้ไว้กับ ecosystem ใด ecosystem หนึ่งกำลังจะจบลง และกำลังเข้าสู่ช่วงที่ต้องจ่ายต้นทุนจริง บริษัทที่หาวิธีรันโมเดลที่ฉลาดมาก ๆ ได้อย่างคุ้มค่าที่สุดจะเป็นฝ่ายชนะ DeepSeek ถูกกว่า GPT 5.5 หรือ Opus 4.8 มากกว่าระดับหนึ่งหลัก แม้จะด้อยกว่าทั้งคู่ แต่ก็ไม่ได้แย่ถึงขั้นรับไม่ได้ ถ้าโมเดลเขียนโค้ดที่ดีที่สุดช่วยประหยัดเวลาคนได้มากพอ ฉันก็ยอมจ่ายแพงกว่า 10 เท่าได้สบาย แต่ถ้าต่างกัน 100 เท่าแบบกรณีที่ benchmark ล่าสุด GPT 5.5 Pro แพงกว่า DeepSeek มากกว่า 200 เท่า และแพงกว่า Opus 4.8 ราว 30 เท่า แบบนั้นยอมรับได้ยาก

    • Fable มีต้นทุนแพงกว่า Opus สองเท่า และก็ดูสูสีกับ GPT-Pro พอสมควร ดังนั้นถ้าระบบ safety ที่ไวเกินเหตุไม่ใช่ปัญหาใหญ่ มันก็อาจเป็นตัวเลือกที่โอเค
      Google เองก็มีตัวเลือก “Deep Research” ของตัวเองในพื้นที่นี้ และดูเหมือนจะทำงานได้ดี จุดเด่นของ DeepSeek คือสามารถรันบนฮาร์ดแวร์โลคัลได้โดยไม่มีค่าใช้จ่าย API ถ้าให้ความสำคัญกับจุดนั้น การที่มันด้อยกว่า Opus หรือ GPT อยู่เล็กน้อยก็ไม่ใช่ปัญหาใหญ่
    • ท้ายที่สุดแล้ว Google น่าจะชนะ เพราะกำลังโฟกัสกับส่วนสำคัญอย่างประสิทธิภาพต่อวัตต์และประสิทธิภาพต่อดอลลาร์
      กำลังสร้างฮาร์ดแวร์สำหรับ inference ของตัวเอง และกำลังมุ่งไปทาง edge computing เพื่อลด latency และ computational overhead ส่วน LLM ขนาดใหญ่ยังไม่คุ้มต้นทุน และ Google ก็กำลังปล่อยให้คู่แข่งเผาเงินลงทุนเพื่อ “ขาย” ให้ผู้บริโภคต่ำกว่าต้นทุนต่อไป หลังฟองสบู่ AI แตก บริษัทอย่าง Google ก็ยังน่าจะอยู่รอดอย่างสบาย และฟองสบู่นี้ก็ดูเหมือนกำลังลอกเปลือกของบริษัทยักษ์ใหญ่บางรายออกมา

  • ปฏิกิริยาบางส่วนกำลังมองข้ามข้อดีของแนวทางแบบ diffusion อยู่ ซึ่งอาจส่งผลอย่างมากกับอุปกรณ์ edge อย่าง GPU บนมือถือหรือคอมพิวเตอร์
    ตัวถอดรหัสของ LLM ต้องพิจารณาโทเค็นก่อนหน้าทั้งหมด จึงคำนวณทีละโทเค็นได้เท่านั้น ตัวถอดรหัส LLM แบบเดิมขยายสเกลได้ดีเมื่อมีโหลดมากพอที่จะรวมงานอนุมานหลายรายการเป็นแบตช์ และในสภาพแวดล้อมแบบนั้นข้อดีของ diffusion จะมีจำกัด แต่บน edge ปัญหาต่างออกไป ตัวเร่งการอนุมานมักอยู่ในภาวะรอข้อมูลเพราะต้องย้ายน้ำหนักขนาดหลาย GB จาก RAM อยู่ตลอด หน่วยความจำสำหรับผู้บริโภคอย่าง LPDDRx/GDDRx มีแบนด์วิดท์ต่ำกว่า HBM และเพราะคำขอเป็นแบบลำดับ จึงรวมการคำนวณน้ำหนักร่วมกันเป็นแบตช์ไม่ได้ diffusion สามารถคำนวณโทเค็นแบบขนานได้ จึงช่วยบรรเทาคอขวดด้านแบนด์วิดท์หน่วยความจำ

    • อุปกรณ์ edge ไม่ได้ขาดแค่แบนด์วิดท์หน่วยความจำ แต่ยังมีสมรรถนะการประมวลผลจำกัดมากด้วย ในทางปฏิบัติ แม้ไม่มีแบตช์จำนวนมาก ก็ใช้ปริมาณการคำนวณที่เป็นไปได้จนเต็มได้อย่างรวดเร็ว และติดข้อจำกัดด้านความร้อนกับพลังงานอย่างชัดเจน
      ที่บอกว่าใน edge inference “คำขอมีลักษณะเป็นลำดับโดยเนื้อแท้” ก็ไม่จริงนัก ในเวลาเดียวกันอาจมีหลายคำขอ หรือหลายแชตกำลังดำเนินอยู่ และหากมีหน่วยความจำพอสำหรับเก็บ KV cache ก็สามารถใช้การประมวลผลแบบแบตช์ได้ หากโมเดล diffusion ใช้การคำนวณมากกว่าแต่ให้คุณภาพต่ำกว่า และการประหยัดแบนด์วิดท์หน่วยความจำก็ยังไม่ชัดเจน ก็ไม่ค่อยเข้าใจว่ามันช่วยอย่างไร
    • โดยรวมก็ถูก แต่กำลังปนเรื่อง attention เข้ากับโครงสร้างแบบ autoregressive/causal ปัญหาจริงที่ทำให้ใช้การคำนวณเพิ่มไม่ได้คือโครงสร้างแบบ autoregressive/causal
      diffusion ก็ใช้ attention ได้ และโมเดลนี้ก็ใช้ attention อยู่จริง

  • NVIDIA มี endpoint ฟรี สำหรับโมเดลนี้ รายละเอียดอยู่ที่ https://build.nvidia.com/google/diffusiongemma-26b-a4b-it และต้องสร้างบัญชี รวมถึงอาจต้องยืนยันหมายเลขโทรศัพท์ด้วย
    ผมลองให้มันวาดนกกระทุงด้วย: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • ถ้าเป็นโมเดลที่เร็วมาก ก็น่าจะขอเฟรมแอนิเมชันได้ด้วย เช่น เฟรม 1 เท้าขวาอยู่ตำแหน่ง 12 นาฬิกา เท้าซ้ายอยู่ 6 นาฬิกา เฟรม 2 เท้าขวาอยู่ 3 นาฬิกา เท้าซ้ายอยู่ 9 นาฬิกา
      แบบนั้นก็ควรรายงานเป็นจำนวนเฟรมนกกระทุงต่อวินาที ไม่ใช่จำนวนโทเค็นต่อวินาทีตามปกติ
    • ผมลงทะเบียนไปเมื่อหลายสัปดาห์ก่อน แต่ถึงจะทำตามขั้นตอนแล้ว บัญชีก็ยังไม่ได้รับการยืนยัน หากบัญชีไม่ได้รับการยืนยันก็ใช้ API ไม่ได้

  • คำอธิบายเชิงภาพที่ดีสำหรับการทำงานของโมเดล diffusion สำหรับข้อความอย่าง DiffusionGemma: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • เมื่อไม่กี่วันก่อน ผมยังคิดอยู่เลยว่า Google ไม่พูดถึงโมเดลสร้างข้อความแบบ diffusionนี้อีกเลย หลังจากสาธิตไว้ในงาน I/O เมื่อปีที่แล้ว
    มีข่าวลือว่ามันแพงเกินกว่าจะรันได้ แต่ถ้าเทียบ DiffusionGemma กับ Gemma ปกติบนฮาร์ดแวร์ 1x H100 เดียวกันตามกราฟที่ให้มา ก็ดูไม่เป็นเช่นนั้น นอกจากมันจะด้อยกว่า Gemma เล็กน้อย ก็สงสัยว่าข้อเสียของความเร็วระดับนี้คืออะไร

    • คำตอบของ “สงสัยว่าข้อเสียของความเร็วระดับนี้คืออะไร” น่าจะเป็นส่วนนี้:
      “การเพิ่มความเร็วของ DiffusionGemma ถูกออกแบบมาสำหรับการอนุมานแบบ local และกรณีที่มี concurrency ต่ำ ในการให้บริการบนคลาวด์ที่มี QPS สูง โมเดล autoregressive สามารถจัดแบตช์ได้อย่างมีประสิทธิภาพจนใช้การประมวลผลได้เต็มที่ ดังนั้นข้อได้เปรียบของการถอดรหัสแบบขนานของ DiffusionGemma จะลดลง และต้นทุนการให้บริการอาจสูงกว่า”
    • ถ้าเป็นโมเดล autoregressive มาตรฐาน เมื่อมีผู้ใช้ 256 คน ก็อาจสร้างได้ครั้งละ 256 โทเค็น ตัววิธีนี้อาจสร้าง 256 โทเค็นให้ผู้ใช้คนเดียวได้ แต่ต้องใช้หลายรอบของขั้นตอน forward pass
      ดังนั้นกระบวนการ diffusion จึงใช้ GFLOPs มากกว่า และหากมีผู้ใช้มากพอ ก็อาจปรับสมดุลระหว่างหน่วยความจำกับการคำนวณได้อยู่แล้ว

  • “DiffusionGemma กลับด้านความไร้ประสิทธิภาพนี้ แทนที่จะทำนายคำทีละคำตามลำดับ มันสร้างร่างทั้งย่อหน้าขนาด 256 โทเค็นพร้อมกัน โดยมอบงานก้อนใหญ่ให้ตัวประมวลผลคอมพิวเตอร์ทีเดียว จึงใช้ฮาร์ดแวร์ได้เต็มประสิทธิภาพ เปลี่ยนการอนุมานของโมเดลจากเครื่องพิมพ์ดีดที่พิมพ์ทีละตัวอักษร ไปเป็นแท่นพิมพ์ขนาดใหญ่ที่พิมพ์บล็อกข้อความทั้งก้อนพร้อมกัน”
    “มันทำงานเป็นโมเดล mixture-of-experts (MoE) ขนาดรวม 26B ที่เปิดใช้งานเพียง 3.8B พารามิเตอร์ระหว่างการอนุมาน และเมื่อทำ quantization แล้วก็ใส่ลงในข้อจำกัด 18GB VRAM ของ GPU เฉพาะทางระดับผู้บริโภคชั้นสูงได้สบาย”
    งั้น Gemma 4 26B ก็เป็นโมเดล MoEที่รันได้เร็วมากบน GPU 24GB ของผมด้วย ollama นี่ฟังดูเหมือน speculative decoding แต่ผมนึกว่าในโมเดล MoE มันใช้แบบนั้นไม่ได้ สำหรับคนที่ไม่ได้ตามเรื่องนี้เป็นงานประจำ การเปลี่ยนแปลงมันเยอะเกินไปจนตามไม่ทัน

    • นี่เป็นอีกโมเดลหนึ่งที่ทำให้สับสน เพราะมีจำนวนพารามิเตอร์เกือบเท่ากับ gemma4 MoE เดิม ยังไม่ชัดจากการอ่านผ่าน ๆ ว่าตัวหนึ่งถูกฝึกจากอีกตัวหนึ่งอย่างไรหรือไม่
      กลไกของมันไม่เหมือน speculative decoding ซึ่งทำงานแบบลำดับและมักไปทีละไม่กี่โทเค็น diffusion ไม่ใช่แบบนั้น แต่มันจัดการบล็อกข้อความทั้งก้อนพร้อมกัน ผมยังไม่ได้อ่านเอกสาร แต่เดาว่าน่าจะฝึกให้ expert บางตัวคงที่อย่างมีเสถียรภาพตลอดทั้งบล็อก diffusion

  • บน3090 Ti ของผม มันยังไม่ใกล้เคียงความเร็วที่โฆษณาไว้ แต่การได้เห็นมันค่อย ๆ “เติม” คำตอบก็ดูน่าสนุก
    ผมลองทดสอบ “นกกระทุง SVG ขี่จักรยาน” ของ Simon แล้ว ผลลัพธ์ค่อนข้างมินิมอลแต่ก็ตรงตามข้อกำหนด: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- เป็นผลจากการรัน Q4 quantization บน llama.cpp ที่แพตช์แล้ว ผมก็สงสัยเหมือนกันว่าผลลัพธ์ของ Simon ต่างกันมากไหม

  • โมเดลการให้เหตุผลแบบดิฟฟิวชัน จะมีหน้าตาแบบไหนกันนะ? จะเป็นการดิฟฟิวส์บล็อก [thinking] ที่มีความยาวกำหนดไว้ล่วงหน้าเป็นเวลานาน แล้วให้บล็อกเอาต์พุตสุดท้ายใช้เนื้อหาในบล็อก thinking นั้นเป็นส่วนหนึ่งของอินพุตหรือเปล่า?
    แล้วโมเดลดิฟฟิวชันกำหนดความยาวเอาต์พุตตั้งแต่แรกได้อย่างไร? เป็นพารามิเตอร์ที่กำหนดไว้ล่วงหน้าหรือว่าให้ [end] token ถูกดิฟฟิวส์ขึ้นมาระหว่างทางตรงไหนสักแห่งก็สงสัยอยู่

    • อ่านคอมเมนต์ที่เหลือแล้วได้คำตอบมาอย่างหนึ่ง ว่ากระบวนการดิฟฟิวชันเองโดยเนื้อแท้แล้วเป็น กระบวนการคล้ายการให้เหตุผล ซึ่งก็ฟังดูมีเหตุผลดี: https://www.inceptionlabs.ai/blog/introducing-mercury-2

  • เท่ดีอยู่หรอก แต่ถึงโมเดลรันโลคัลตอนนี้จะใช้ได้แล้ว ก็ยังให้ความรู้สึกว่าด้อยกว่าพวก API ที่ถูกที่สุดอย่างชัดเจนอยู่ดี เลยไม่ค่อยอยากยอมเสียคุณภาพแม้แต่นิดเดียวเพื่อแลกกับความเร็ว
    แน่นอนว่าน่าจะมีคุณค่าสำหรับบาง use case แต่ก็อยากรู้ว่ามีกรณีแบบไหนที่ตั้งใจจะเอาไป deploy ใช้งานจริงใน production

    • น่าจะโอเคสำหรับการเขียน unit test หรือการ bootstrap
      ถึงไม่ใช่ระดับ Opus ก็ยังเขียนได้ และวนซ้ำปรับแก้ได้ง่ายด้วย