เร่งความเร็ว Gemma 4: อนุมานได้เร็วขึ้นด้วย drafter แบบคาดการณ์หลายโทเค็น

 (blog.google)
3 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Google เผยว่า Gemma 4 มียอดดาวน์โหลดทะลุ 60 ล้านครั้งภายในไม่กี่สัปดาห์หลังเปิดตัว และได้เปิดตัว drafter แบบคาดการณ์หลายโทเค็น (MTP) สำหรับตระกูลผลิตภัณฑ์ Gemma 4
  • MTP drafter เป็นสถาปัตยกรรม speculative decoding แบบเฉพาะทาง ที่เพิ่มความเร็วในการอนุมานได้สูงสุด 3 เท่าโดยไม่ลดคุณภาพผลลัพธ์หรือตรรกะการอนุมาน และได้ทดสอบบนฮาร์ดแวร์ที่ใช้ LiteRT-LM, MLX, Hugging Face Transformers และ vLLM
  • การอนุมานของ LLM แบบมาตรฐานมีคอขวดด้าน memory bandwidth สูง เพราะต้องย้ายพารามิเตอร์หลายพันล้านตัวจาก VRAM ไปยังหน่วยประมวลผลเพื่อสร้างโทเค็นทีละตัว ขณะที่ MTP ใช้ drafter น้ำหนักเบาเสนอหลายโทเค็นในอนาคต แล้วให้โมเดลเป้าหมายตรวจสอบแบบขนาน
  • หากโมเดลเป้าหมายยอมรับโทเค็นร่าง ก็จะรับทั้งลำดับได้ภายในการส่งผ่านไปข้างหน้าเพียงครั้งเดียว และสร้างโทเค็นเพิ่มอีกหนึ่งตัวด้วย ทำให้แอปพลิเคชันสามารถแสดงทั้ง ลำดับโทเค็นร่างและโทเค็นเพิ่มเติม ได้ภายในเวลาที่โดยทั่วไปใช้สร้างเพียงโทเค็นเดียว
  • MTP drafter ใช้ค่ากระตุ้นของโมเดลเป้าหมายร่วมกันและแชร์ KV cache ด้วย และสำหรับโมเดล edge อย่าง E2B·E4B ก็ใช้การทำคลัสเตอร์ embedder ที่มีประสิทธิภาพ โดยน้ำหนักโมเดลเปิดให้ใช้ภายใต้ Apache 2.0 ที่ Hugging Face และ Kaggle

เหตุใดจึงต้องมี speculative decoding

  • การอนุมานของ LLM แบบมาตรฐานติดข้อจำกัดด้าน memory bandwidth จึงเกิดคอขวดด้าน latency สูง
  • โปรเซสเซอร์ต้องใช้เวลาส่วนใหญ่ในการย้ายพารามิเตอร์หลายพันล้านตัวจาก VRAM ไปยังหน่วยประมวลผลเพื่อสร้างโทเค็นเพียงตัวเดียว
  • โครงสร้างนี้ทำให้โดยเฉพาะบนฮาร์ดแวร์ฝั่งผู้บริโภค ไม่สามารถใช้ทรัพยากรการประมวลผลได้เต็มที่และทำให้ latency สูงขึ้น
  • speculative decoding แยกการสร้างโทเค็นออกจากการตรวจสอบ
  • โดยจับคู่โมเดลเป้าหมายที่มีขนาดใหญ่ เช่น Gemma 4 31B เข้ากับ MTP ซึ่งเป็น drafter น้ำหนักเบา เพื่อคาดการณ์หลายโทเค็นในอนาคตพร้อมกันด้วยทรัพยากรประมวลผลที่ว่างอยู่
  • drafter สามารถเสนอหลายโทเค็นได้ในเวลาที่สั้นกว่าที่โมเดลเป้าหมายใช้ประมวลผลหนึ่งโทเค็น และโมเดลเป้าหมายจะตรวจสอบโทเค็นที่เสนอมาแบบขนาน

MTP ทำงานอย่างไร

  • โมเดลภาษาขนาดใหญ่แบบมาตรฐานสร้างข้อความแบบ autoregressive โดยสร้างได้ทีละหนึ่งโทเค็นเท่านั้น
  • วิธีนี้ใช้ปริมาณการประมวลผลเท่ากันทั้งกับการต่อข้อความง่าย ๆ อย่าง “Actions speak louder than…” ด้วยคำว่า “words” และกับการแก้ปริศนาเชิงตรรกะที่ซับซ้อน
  • MTP ลดความไม่มีประสิทธิภาพนี้ด้วย speculative decoding ที่นักวิจัยของ Google นำเสนอไว้ใน Fast Inference from Transformers via Speculative Decoding
  • หากโมเดลเป้าหมายเห็นด้วยกับโทเค็นร่าง ก็จะรับทั้งลำดับภายในการส่งผ่านไปข้างหน้าเพียงครั้งเดียว และตัวโมเดลเป้าหมายเองก็จะสร้างโทเค็นเพิ่มอีกหนึ่งตัวพร้อมกัน
  • โดยทั่วไป แอปพลิเคชันจึงสามารถแสดงทั้งลำดับโทเค็นร่างทั้งหมดและโทเค็นเพิ่มเติมอีกหนึ่งตัวได้ภายในเวลาที่ใช้สร้างโทเค็นเดียว

ผลด้านประสิทธิภาพสำหรับนักพัฒนา

  • สำหรับนักพัฒนา ความเร็วในการอนุมานมักเป็นคอขวดสำคัญของการนำไปใช้จริงในโปรดักชัน
  • ในระบบอย่างเอเจนต์อัตโนมัติที่ต้องวางแผนหลายขั้นอย่างรวดเร็ว, coding assistant และแอปมือถือแบบตอบสนองไวที่รันบนอุปกรณ์ทั้งหมด ความหน่วงระดับมิลลิวินาทีก็มีความสำคัญ
  • เมื่อใช้โมเดล Gemma 4 ร่วมกับ drafter นี้ จะได้ผลดังต่อไปนี้

  • การตอบสนองดีขึ้น

    • ลด latency ได้อย่างมากสำหรับแชตเกือบเรียลไทม์ แอปเสียงแบบ immersive และเวิร์กโฟลว์แบบ agentic

  • เร่งการพัฒนาแบบโลคัล

    • รันโมเดล 26B MoE และ 31B Dense ได้เร็วขึ้นบนคอมพิวเตอร์ส่วนบุคคลและ GPU สำหรับผู้บริโภค เพื่อรองรับงานโค้ดดิ้งออฟไลน์ที่ซับซ้อนและเวิร์กโฟลว์แบบ agentic

  • เพิ่มประสิทธิภาพบนอุปกรณ์

    • ทำให้โมเดล E2B และ E4B สร้างผลลัพธ์ได้เร็วขึ้นบนอุปกรณ์ edge ซึ่งช่วยลดการใช้แบตเตอรี่ของอุปกรณ์ได้

  • ไม่มีคุณภาพตก

    • เนื่องจากโมเดล Gemma 4 ต้นฉบับยังคงทำหน้าที่ตรวจสอบขั้นสุดท้าย จึงให้ระดับการให้เหตุผลและความแม่นยำเท่าเดิมแต่เร็วขึ้นมาก
    • ตัวอย่างของ Gemma 4 26B ที่รันบน NVIDIA RTX PRO 6000 เปรียบเทียบจำนวนโทเค็นต่อวินาทีระหว่างการอนุมานแบบมาตรฐานกับ MTP drafter และแสดงให้เห็นว่า latency เหลือเพียงประมาณครึ่งหนึ่งโดยคุณภาพผลลัพธ์เท่าเดิม
    • สามารถดาวน์โหลดวิดีโอเปรียบเทียบได้ที่ ดาวน์โหลด

การปรับแต่งภายในของ MTP drafter

  • มีการปรับปรุงสถาปัตยกรรมหลายอย่างเพื่อให้ MTP drafter ทั้งเร็วและแม่นยำ
  • โมเดลร่างสามารถใช้ค่ากระตุ้นของโมเดลเป้าหมายได้อย่างเป็นธรรมชาติ และแชร์ KV cache ของโมเดลเป้าหมายร่วมกัน
  • การแชร์ KV cache ช่วยไม่ให้เสียเวลาไปกับการคำนวณบริบทที่โมเดลใหญ่ได้ประมวลผลไปแล้วซ้ำอีก
  • ในโมเดล edge อย่าง E2B และ E4B การคำนวณ logits ขั้นสุดท้ายเป็นคอขวดใหญ่ จึงมีการใช้เทคนิคการทำคลัสเตอร์กับ embedder ที่มีประสิทธิภาพเพื่อเร่งการสร้างผลลัพธ์
  • ยังมีการวิเคราะห์การปรับแต่งตามฮาร์ดแวร์ด้วย
  • บน Apple Silicon โมเดล mixture-of-experts ขนาด 26B มีโจทย์ด้าน routing เฉพาะตัวเมื่อใช้ batch size 1 แต่เมื่อประมวลผลหลายคำขอพร้อมกัน จะได้ความเร็วเพิ่มขึ้นสูงสุดราว 2.2 เท่าในเครื่อง
  • ตัวอย่าง batch size อยู่ที่ 4~8 และบน NVIDIA A100 ก็พบการปรับปรุงลักษณะใกล้เคียงกันเมื่อเพิ่ม batch size
  • สามารถดูรายละเอียดเชิงลึกเกี่ยวกับสถาปัตยกรรมแบบภาพ การแชร์ KV cache และการทำงานของ embedder ที่มีประสิทธิภาพได้จาก คำอธิบายทางเทคนิคเชิงลึก

วิธีใช้งานและแหล่งที่มีให้ใช้

  • MTP drafter สำหรับตระกูล Gemma 4 เปิดให้ใช้ภายใต้สัญญาอนุญาต Apache 2.0 แบบโอเพนซอร์สเช่นเดียวกับ Gemma 4
  • วิธีใช้ MTP ร่วมกับ Gemma 4 ดูได้ในเอกสาร
  • สามารถดาวน์โหลดน้ำหนักโมเดลได้จาก Hugging Face และ Kaggle
  • สามารถทดลองการอนุมานที่เร็วขึ้นได้ด้วย transformers, MLX, vLLM, SGLang, Ollama
  • สามารถลองใช้งานได้โดยตรงผ่าน Google AI Edge Gallery บน Android หรือ iOS
  • Google คาดหวังว่าการเพิ่มความเร็วนี้จะช่วยเร่งการพัฒนาในระบบนิเวศ Gemma หรือ Gemmaverse

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

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

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

  • Gemma และ Gemini ใช้ โทเค็นเอาต์พุตน้อยกว่ามาก เมื่อเทียบกับโมเดลอื่น แต่ก็ยังทำผลงานบนเบนช์มาร์กระดับบนได้ใกล้เคียงมาก
    ถ้าเทียบ Gemma กับ Qwen จะเห็นว่า Qwen ทำได้ดีกว่านิดหน่อย แต่ใช้เวลา 22 นาทีกับงานหนึ่ง ขณะที่ Gemma มักทำพรอมป์ต์เดียวกันเสร็จใน 4 นาที แม้จะจัดแนวปุ่มผิดก็ตาม
    มองเผินๆ Gemma อาจมีประสิทธิภาพต่ำกว่าโมเดลโอเพนชั้นนำอยู่ 5~10% แต่ใช้ เวลาเพียง 1/10 เท่านั้น

    • จากที่ใช้งานจริง แพ็กเกจพื้นฐาน Gemini แบบ 15 ดอลลาร์ต่อเดือน ใช้เขียนโค้ดได้ทั้งวันโดยไม่ชนลิมิต
      ไม่เคยรู้สึกว่าต้องอัปเกรดเหมือนที่คนอื่นโพสต์กันว่าใช้แพ็กเกจ 100 ดอลลาร์ต่อเดือนของ Claude หรือ Codex
      แต่ Gemini ก็เคยมีช่วงที่ประสิทธิภาพตกลงหลายครั้งในรอบปีที่ผ่านมา และข้อจำกัดด้านอัตราการใช้งานก็เข้มขึ้นด้วย เลยไม่แน่ใจว่าในอนาคตจะยังดีได้เท่านี้ไหม
    • ในพอดแคสต์ของ Dwarkesh, Dylan Patel จาก SemiAnalysis บอกว่า Google สามารถรองรับโมเดลขนาดใหญ่กว่าคู่แข่งได้ เพราะมีทรัพยากรประมวลผลและการเข้าถึง TPU มากกว่ามาก
      โดยทั่วไปโมเดลที่ใหญ่กว่าจะใช้โทเค็นน้อยกว่าต่อระดับความฉลาดเดียวกัน จึงดูเป็นคำอธิบายความต่างของปริมาณโทเค็นได้
    • เพราะ Gemma เร็ว จึงสามารถรันได้แม้บน GPU ที่เดิมทีอาจเล็กเกินไป
      ลองรันบน 4070 แล้ว ถึงเอาต์พุตจะไม่เร็วมาก แต่ก็ใช้งานได้
      ยังไม่ได้ลองกับงานซับซ้อน และคิดว่าน่าจะต่างออกไปในกรณีนั้น
    • ตอนนี้ Claude กำลังเป็นที่นิยมมาก แต่ไม่เคยมีปัญหากับ Gemini หรือรู้สึกว่าต้องย้ายไปใช้อย่างอื่น
      หลัง Google I/O คนอาจเริ่มรู้มากขึ้นว่า Gemini ดีแค่ไหน
    • ก็จริง แต่ถ้าจะให้ยุติธรรมต้องนับ ปริมาณโทเค็นเอาต์พุตสะสมรวมกัน
      ถ้ามีปัญหาเรื่องการจัดแนว ก็ต้องใช้โทเค็นอินพุตและเอาต์พุตเพิ่มอีกรอบเพื่อแก้

  • กำลังมีการเพิ่ม การรองรับ MTP ใน llama.cpp และอย่างน้อยสำหรับโมเดล Qwen ก็อยู่ระหว่างดำเนินการ(https://github.com/ggml-org/llama.cpp/pull/20533)
    Gemma 4 ก็น่าจะตามมาในไม่ช้า
    ช่วงไม่กี่เดือนที่ผ่านมา คุณภาพและความเร็วของโมเดลแบบรันในเครื่อง/โฮสต์เองพัฒนาขึ้นอย่างน่าทึ่ง

    • มี PR ที่ใหม่กว่านี้และน่าจะรวมเข้ามาเร็วๆ นี้: https://github.com/ggml-org/llama.cpp/pull/22673
    • ไม่กี่วันก่อนเพิ่งย้ายกลับจาก Qwen3.6 ไปใช้ Gemma 4 สำหรับงานส่วนตัว และพบว่า เวอร์ชัน 26B ของตัวหลังให้ผลงานโดยเฉลี่ยดีกว่า 27B ของตัวแรก
      สำหรับคนที่รันโมเดลโลคัลมานาน นี่เป็นช่วงเวลาที่น่าตื่นเต้นจริงๆ
    • คนเริ่มสนใจ การรวม DFlash มากขึ้นด้วย: https://github.com/ggml-org/llama.cpp/issues/21978
      อยากเห็นเร็วๆ ว่าจะเทียบกับ MTP แล้วเป็นอย่างไร
    • อยากเห็นสิ่งนี้ใน oMLX ด้วย
      เป็นเครื่องมือที่ค่อนข้างดี
    • ไม่แน่ใจนักว่า MTP inference อยู่ตรงไหนของสแตกการอนุมาน แต่ถ้าใครรู้ว่าสามารถทำได้ใน ระบบนิเวศ MLX หรือไม่ก็อยากทราบ

  • Google แทบจะเป็นคนเดียวที่ค้ำจุน โมเดลโอเพนซอร์ส ฝั่งตะวันตก
    Gemma 4 31B ยอดเยี่ยมมาก
    แต่ถ้าจะยัดเวอร์ชันที่ดีที่สุดลงใน 24GB VRAM พร้อมความสามารถด้านภาพและ drafter ที่กำลังจะมา มันค่อนข้างทรมาน
    เครื่องที่ใช้อยู่เพิ่ม GPU ไม่ได้แล้ว และถ้าจะเอาประสิทธิภาพสูงสุดก็คงต้องซื้อ 4090 เพิ่มอีกใบซึ่งแพงเกินไป หรือไม่ก็เปลี่ยนเครื่องใหม่ทั้งชุด

    • ใน llama.cpp ถ้าใช้ --no-mmproj-offload จะย้าย multimodal projector หรือส่วนทำความเข้าใจเสียง·ภาพ·PDF ไปไว้ใน RAM ของระบบได้
      แน่นอนว่าพอทำแบบนั้นจะไม่ได้ใช้ GPU acceleration แต่ก็ประหยัด VRAM
    • ถึงอย่างนั้นก็ยังมองว่า Qwen ดีกว่า Gemma
      ปรับแต่งตามงานได้มากกว่า จึงเลือกได้ว่าจะเน้นการคิดและความแม่นยำ หรือจะเน้น ความเร็วในการอนุมาน

  • เวลามองคอมพิวเตอร์เขียนข้อความ มันทำให้นึกถึงสมัยก่อนที่ ต่อโมเด็มเข้า BBS
    นี่ให้ความรู้สึกเหมือนอัปเกรดจาก 300 baud ไป 1200 baud เป็นการพัฒนาที่ใหญ่ แต่ก็ยังช้าอยู่มาก และสักวันหนึ่งเราอาจสงสัยว่าทนใช้แบบนี้กันมาได้อย่างไร

    • สภาพตอนนี้เหมือน ยุคอินเทอร์เน็ตโทรศัพท์หมุน มากจริงๆ และทำให้นึกต่อไปเรื่อยๆ ว่าอนาคตแบบ “บรอดแบนด์” จะหน้าตาเป็นอย่างไร
      การดูโทเค็นไหลออกมาคล้ายกับการดู JPEG โหลดทีละไม่กี่บรรทัดของพิกเซล และยังทำให้นึกถึงแอนิเมชันโหลดหรือเชื่อมต่อต่างๆ ที่แต่ละแอปเคยทำกันก่อนที่ความเร็วจะเร็วพอ
      งานที่ Cerebras หรือ Taalas กำลังทำอยู่เป็นสัญญาณที่น่าสนใจว่าทิศทางนี้จะทำอะไรได้บ้าง
      แค่นึกภาพว่าถ้าโมเดลล้ำสมัยตอนนี้สามารถใช้ได้ถึงล้านโทเค็นต่อวินาทีในต้นทุนที่ต่ำมาก จะเกิดอะไรขึ้นได้บ้างก็น่าสนุกแล้ว
    • เห็นด้วยว่ามันชวนให้นึกถึงยุคต่อสาย แต่ถ้าจะเทียบคงใกล้กับ 4800 baud มากกว่า ไม่ใช่ 300 ไป 1200
      Claude คำนวณการเทียบระหว่างโมเด็มกับ Claude ไว้แบบนี้: ที่ 2368 ตัวอักษร, 300 ใช้ 1 นาที 19 วินาที, 1200 ใช้ 19.7 วินาที, 2400 ใช้ 9.9 วินาที, 14.4K ใช้ 1.6 วินาที, 33.6K ใช้ 705ms, 56K ใช้ 447ms, ส่วน Claude ใช้ 7.9 วินาที
    • มีสตาร์ตอัปรายหนึ่งที่เคยโพสต์ที่นี่สร้าง ฮาร์ดแวร์เฉพาะทาง เพื่อให้ AI ตอบได้ทันที
      ได้ระดับหลายพันโทเค็นต่อวินาที

  • กลยุทธ์ของ Google ดูจะแตกต่างจากผู้ให้บริการ frontier รายอื่นอยู่บ้าง
    เหมือนจะโฟกัสที่ ประสิทธิภาพต่อทรัพยากรประมวลผล มากกว่าประสิทธิภาพล้วนๆ เลยอาจทำให้ Gemini ดูเหมือนตามหลังอยู่
    ผู้ให้บริการรายอื่นกำลังชนข้อจำกัดด้านความจุ และการอุดหนุนต้นทุน inference ก็เริ่มไปต่อได้ยาก
    กลยุทธ์ของ Google ดูเหมือนมุ่งไปที่การขยายและกระจายโมเดลเหล่านี้สู่ผู้ใช้เดิมที่มีอยู่หลายพันล้านคน

    • ไม่คิดว่า Gemini กำลังตามหลัง
      กลับรู้สึกว่าเป็นความฉลาดคนละแบบกับ GPT-5 รุ่นล่าสุดและตระกูล Claude
      ฝั่งหลังยิ่งเน้นเรื่องผลิตภาพและระบบอัตโนมัติในงานมากขึ้น และเหมาะกับลูปการให้เหตุผลแบบ self-correction ที่ยาวและเป็นเอเจนต์
      ส่วน Gemini เหมือนเป็นโมเดลฐานที่ฉลาดกว่ามาก โดยเฉพาะใน โหมด Deep Think ที่ให้ความรู้สึกว่ามีสัญชาตญาณลึกกว่าเยอะ แต่กลับทำลูปเอเจนต์แบบแก้ตัวเองระยะยาวได้ไม่ดีเท่า
      ตลอดหลายเดือนที่ผ่านมา เวิร์กโฟลว์ของฉันคือใช้ Gemini สำหรับการกระโดดทางความคิดและอินไซต์เชิงสร้างสรรค์ แต่จะเลือก Codex, Claude, GPT-5.5 Pro สำหรับงานที่ซ้ำๆ หรือต้องการความแม่นยำสูง
    • เหมือนว่ากลยุทธ์ของทุกเจ้าก็กำลังเปลี่ยนไปในทิศทางนั้นไม่ใช่หรือ

  • หยุดเล่นโมเดลโลคัลไปพักหนึ่ง แล้วล่าสุดลองตั้งค่า โมเดล 26B A4B บน RTX 3090 ด้วย vLLM แบบ 4 บิต รู้สึกทึ่งมากกับความเร็วและคุณภาพที่ได้จากการลงทุนต่ำกว่า 1,000 ดอลลาร์
    ตอนแรกลองกับ Qwen แต่ไม่เสถียร และร่องรอยการคิดก็ยาวเกินเหตุ

    • quantization รุ่นแรกๆ ของ qwen3.6 บางตัวเสียหายอยู่
      ตอนนี้ก็ยังจุกจิกอยู่บ้าง แต่ถ้าปรับนิดหน่อยแล้วมันยอดเยี่ยมจริงๆ
      โมเดลโลคัลคืออนาคต ซึ่งเจ๋งมาก
    • ถ้าใช้ turboquant / Q4 มันขึ้นได้แม้แต่บน 3060 และได้ความเร็วประมาณ 40T/s ซึ่งถือว่าดีพอสมควรสำหรับการ์ดราคาราว 200 ดอลลาร์
    • โมเดล A4B เร็วมากและดีมากกับคำถามทั่วไป
      สำหรับงานเขียนโค้ดมันด้อยกว่า Qwen 3.6 อย่างชัดเจน แต่ก็สะท้อนว่า โมเดล Qwen นั้นโดดเด่นมากกว่า
    • แม้แต่ 31B ก็ยังเร็วอย่างน่าประหลาดสำหรับโมเดล dense
      บนเครื่องของฉัน เมื่อเทียบกับโมเดล 30B อื่นๆ ค่า tg เร็วกว่าที่คาดไว้อย่างน้อยสองเท่า น่าจะเพราะ hybrid attention
      แต่ฝั่งประมวลผลอินพุตจะช้ากว่านิดหน่อย

  • อยากรู้ว่ามีใครทำให้สิ่งนี้ทำงานใน LM Studio ได้สำเร็จไหม
    ใน UI มีตัวเลือกอยู่ แต่ดูเหมือนจะเปิดใช้งานไม่ได้

    • ตอนนี้ยังไม่ได้ถูกทำใน mlx[1] หรือ llama.cpp[2] เลยอาจต้องใช้เวลาอีกหน่อย
      [1] https://github.com/ml-explore/mlx-lm/pull/990
      [2] https://github.com/ggml-org/llama.cpp/pull/22673
    • ใช้ได้
      เพราะยังไม่มีโมเดลเล็ก จึงต้องแน่ใจว่าไม่ได้ใช้ Gemma sparse model อยู่
      และฉันก็ลบโมเดลภาพทั้งหมดออกจาก workspace แล้ว
    • ปกติสิ่งที่ LM Studio ไม่ชอบคือการมี ไฟล์ mmproj อยู่ในโฟลเดอร์
      บางทีลบไฟล์พวกนี้ออกแล้วมันถึงจะโผล่มาให้ใช้
      ไฟล์เหล่านี้ดูเหมือนจะเกี่ยวข้องกับความสามารถด้านภาพและไปขัดขวาง speculative decoding ไม่ทางใดก็ทางหนึ่ง อย่าถามว่าทำไม
      สำหรับ Gemma เส้นทาง llama-server ใช้งาน speculative decoding ได้ดีกว่า LM Studio
    • เคยทำให้ใช้กับโมเดลอื่นได้
      โดยทั่วไปผู้ให้บริการ, quantization ฯลฯ ต้องเข้าคู่กันอย่างพอดี
      อาจต้องใช้เวลาหน่อยกว่าจะหาเซ็ตที่จับคู่กันได้ลงตัว

  • ในการทดสอบของฉัน โมเดล Gemma 4 31B ให้การเพิ่มความเร็วมากที่สุดกับงานเขียนโค้ดเมื่อใช้ MLX runner ของ Ollama ประมาณ 2 เท่า
    แต่ quantization ทำให้อัตราการยอมรับลดลงมาก จึงต้องใช้ Mac ที่ค่อนข้างแรง
    โมเดลเล็กอีกสามตัวไม่ดีเท่า เพราะเวลาในการตรวจสอบโมเดล draft กินผลประโยชน์ด้านประสิทธิภาพไปเกือบหมด
    ตอนนี้ยังจูนอยู่เพื่อดูว่าจะทำให้ดีกว่านี้ได้ไหม
    ลองทดสอบได้ด้วยการรัน ollama run gemma4:31b-coding-mtp-bf16 บน Ollama 0.23.1

  • ถ้า merge เข้า llama.cpp เมื่อไร อยากลองใช้ทันที
    ในสภาพแวดล้อมของฉัน Gemma 4 26B-A4B เร็วกว่า Qwen3.6-35B-A3B ราว 3 เท่า อยู่แล้ว ดังนั้นแค่คิดว่าจะได้เร่งเพิ่มอีก 1.5 เท่าก็น่าสนใจมาก
    เคยลองโมเดล draft แล้วเหมือนกัน แต่ผลลัพธ์มีจำกัด และทั้งโมเดล draft ขนาดเล็ก 3B กับโมเดล dense 14B Ministral ก็สร้าง overhead มากเกินไปอยู่แล้ว

    • ใน vLLM ถ้าใช้ 5090 จะได้ 120~180TPS ด้วย awq quantization แบบ 4 บิตและ MTP speculative decoding
      Gemma4 26B ได้เกิน 200TPS ภายใต้ quantization แบบเดียวกัน
      อีกประเด็นสำคัญคือ Qwen มีประสิทธิภาพการอนุมานต่ำมาก
      chain of thought โดยเฉลี่ยยาวกว่า Gemma ประมาณ 3 เท่า

  • มันเหมือน branch prediction ของระบบปฏิบัติการหรือเปล่า
    เพียงแต่ตรงนี้ความน่าจะเป็นถูกฝังอยู่ในตัวโมเดลเอง จึงเป็นรูปแบบที่เชื่อถือได้มากกว่า

    • แนวคิดคล้ายกัน แต่รูปแบบความล้มเหลวดีกว่า
      branch prediction ที่พลาดจะเผาผลาญรอบการทำงานไปเปล่าๆ แต่ที่นี่การเดาผิดส่วนใหญ่แค่ทำให้ไม่ได้ โทเค็นโบนัส
      https://arxiv.org/abs/2211.17192