- เช็กพอยต์ Quantization-Aware Training (QAT) ของ Gemma 4 ปรับความต้องการหน่วยความจำและประสิทธิภาพบนอุปกรณ์ให้เหมาะสม เพื่อช่วยให้รันแบบโลคัลได้บนอุปกรณ์เอดจ์ทั่วไปและ GPU สำหรับผู้บริโภค
- QAT จำลองการทำ quantization ระหว่างการฝึก เพื่อลดการสูญเสียคุณภาพเมื่อบีบอัด และให้ผลลัพธ์ที่มีคุณภาพโดยรวมสูงกว่าค่าอ้างอิง PTQ มาตรฐาน
- เช็กพอยต์ที่เปิดเผยรองรับรูปแบบ Q4_0 และรูปแบบที่ออกแบบมาสำหรับมือถือโดยเฉพาะ ซึ่งรูปแบบมือถือช่วยลด memory footprint ของ Gemma 4 E2B ลงเหลือ 1GB
- สคีมาสำหรับมือถือใช้ static activation, การทำ quantization แบบ per-channel, selective 2-bit quantization และการปรับแต่ง embedding·KV cache เพื่อลดภาระงานและการใช้ active memory บนชิปมือถือ
- รองรับ Hugging Face weights, llama.cpp·Ollama·LM Studio, LiteRT-LM·Transformers.js, SGLang·vLLM·MLX·Unsloth ทำให้สามารถ รันแบบโลคัล ดีพลอยบนอุปกรณ์ และ fine-tuning ได้
ที่มาและขอบเขตของการเปิดเผย
- สองเดือนหลังการเปิดตัว Gemma 4 Google ได้เปิดเผยเช็กพอยต์ QAT ต่อจาก Multi-Token Prediction(MTP) สำหรับเร่งการอนุมาน และ โมเดล 12B ที่มาเติมช่องว่างระหว่างโมเดล MOE ขนาด E4B·26B
- เช็กพอยต์ใหม่นี้เป็นงานปรับประสิทธิภาพเพื่อให้สามารถรัน Gemma 4 แบบโลคัลได้บนอุปกรณ์เอดจ์ทั่วไปและ GPU สำหรับผู้บริโภค
- QAT เป็นวิธีที่จำลองการทำ quantization ระหว่างการฝึก เพื่อลดการสูญเสียคุณภาพระหว่างการบีบอัดโมเดลให้น้อยที่สุด
- รีลีสครั้งนี้มีทั้งเช็กพอยต์ QAT สำหรับรูปแบบ quantization ยอดนิยม Q4_0 และรูปแบบ quantization ใหม่ที่ออกแบบมาเฉพาะสำหรับการใช้งานบนมือถือ
จุดแลกเปลี่ยนระหว่างการบีบอัดกับคุณภาพ
- Quantization เป็นเทคโนโลยีสำคัญสำหรับการรันโมเดลบนฮาร์ดแวร์สำหรับผู้บริโภค โดยช่วยลด memory footprint และเพิ่มความเร็วในการถอดรหัส
- Post-Training Quantization (PTQ) แบบมาตรฐานมักทำให้ประสิทธิภาพลดลง แต่ QAT ผสานกระบวนการ quantization เข้าไปในการฝึกโดยตรง
- PTQ ก็มีประสิทธิภาพในการรักษาคุณภาพเช่นกัน แต่ผลลัพธ์จาก QAT ให้คุณภาพโดยรวมสูงกว่าค่าอ้างอิง PTQ มาตรฐาน
- Google ใช้ recipe ของ QAT กับรูปแบบ Q4_0 เพื่อดึงประสิทธิภาพของทุกโมเดลให้สูงสุด และออกแบบสคีมา quantization สำหรับมือถือแยกต่างหากสำหรับโมเดลเอดจ์ E2B·E4B
โครงสร้างการปรับแต่งสำหรับมือถือ
- รูปแบบการบีบอัดมาตรฐานมักรันบนโปรเซสเซอร์มือถือได้อย่างไม่มีประสิทธิภาพ ดังนั้น Gemma 4 จึงใช้สคีมา mobile quantization แบบปรับแต่งสำหรับฮาร์ดแวร์เอดจ์
- Static activation คำนวณการตั้งค่า data scale ล่วงหน้าระหว่างการฝึก เพื่อลดภาระงานของชิปมือถือและเพิ่มความเร็วในการตอบสนอง
- Per-channel quantization จัดโครงสร้างข้อมูลที่บีบอัดให้สอดคล้องกับสถาปัตยกรรมของ mobile accelerator เพื่อให้คำนวณแบบเนทีฟได้โดยไม่ต้องใช้วิธีอ้อมที่ช้ากว่า
- Selective 2-bit quantization บีบอัดส่วนการสร้างโทเคนอย่างหนักด้วย 2 บิต ขณะที่คงเลเยอร์อนุมานหลักไว้ที่ความละเอียดสูงกว่า เพื่อประหยัดพื้นที่จัดเก็บ
- การปรับแต่ง embedding และ KV cache มุ่งบีบอัดไปที่รายการคำศัพท์และหน่วยความจำระยะสั้นของโมเดล เพื่อลด active memory footprint อย่างมากและรองรับการสนทนายาวขึ้น
- ในกรณีใช้งานที่ไม่ต้องใช้ออดิโอ·วิชันเอนโค้ดเดอร์ สามารถดีพลอยเฉพาะ modality ที่จำเป็นเพื่อลด memory footprint เพิ่มเติมได้ และโมเดล Gemma 4 E2B แบบข้อความล้วนที่ไม่มี Per-Layer Embeddings ต้องการหน่วยความจำน้อยกว่า 1GB
วิธีใช้งานและการรองรับเครื่องมือ
- Google ให้บริการน้ำหนักโมเดล Q4_0 และ mobile บน Hugging Face
- รูปแบบ GGUF ใช้งานได้ทันทีใน llama.cpp, เทนเซอร์ที่บีบอัดแล้วมีให้สำหรับ vLLM และสำหรับเวิร์กโฟลว์อื่น Google แชร์เช็กพอยต์ที่ยังไม่ quantize ซึ่งสามารถแปลงและทำ quantization เป็นรูปแบบที่รองรับ Q4_0 ได้
- วิธีดีพลอยสามารถดูได้ในเอกสาร
- บนเดสก์ท็อป สามารถดาวน์โหลด·จัดการ·รันโมเดล Gemma 4 QAT แบบโลคัลได้ด้วย llama.cpp, Ollama, LM Studio
- สำหรับการดีพลอยบนอุปกรณ์ สามารถใช้รันไทม์น้ำหนักเบา LiteRT-LM ของ Google และบนเว็บสามารถรันได้โดยตรงด้วย Transformers.js
- สำหรับการเสิร์ฟโมเดลขนาดใหญ่ สามารถใช้ SGLang และ vLLM ได้ และสำหรับการปรับแต่งบน Apple Silicon สามารถใช้ MLX ได้
- เช็กพอยต์ MTP QAT รักษาความเร็วที่เพิ่มขึ้นของ MTP ไว้ได้ระหว่างการทำ quantization ของโมเดล และสามารถทำ fine-tuning น้ำหนักได้โดยตรงด้วย Hugging Face Transformers และ Unsloth
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ลองรัน Gemma 4 E2B แบบโลคัลบน Mac ด้วย
uvx litert-lm runแล้ว ตอนรันครั้งแรกดาวน์โหลดไฟล์ 3.2GB ไปไว้ที่~/.cache/huggingface/hub/models--litert-community--gemma-4-E2B-it-litert-lmค่อนข้างน่าประทับใจที่โมเดลขนาดเท่านี้รองรับอินพุตทั้งเสียงและภาพด้วย โดยสำหรับภาพสามารถรันแบบ
--attachment image.jpg --prompt describeและสำหรับเสียงใช้--attachment audio.wav --prompt transcribeได้ผลลัพธ์ SVG รูปนกกระทุงเองไม่ได้ดีนัก แต่ก็น่าทึ่งที่ไฟล์ขนาด 3.2GB สร้าง SVG ที่ใช้งานได้ออกมา: https://gist.github.com/simonw/94b318afde4b1ce5ff67d4b5d0362...
โมเดลของ MLX Community จะมีคำนี้อยู่ในชื่อ แต่โมเดลพวกนี้ไม่มี และวันที่อัปโหลดก็ดูไม่ตรงกันเสียทีเดียว
ตอนนี้เริ่มเป็นไปได้แล้วสำหรับการสนทนาแบบเรียลไทม์พื้นฐานที่รับรู้วิดีโอและเสียงได้ภายในอุปกรณ์
uvxใช้งานสะดวกมากจริงๆอยากให้ Nvidia รองรับแบบจริงจังบ้าง แทนที่จะให้คนต้องทำขั้นตอนอ้อม Docker กันเอง
มี คอลเลกชัน Unsloth ด้วย [0] และมีการเปิดเผยผลลัพธ์ไว้แล้ว [1]
ดูเหมือนว่าความแม่นยำจะใกล้เคียงกับโมเดล BF16 ที่ไม่ควอนไทซ์แทบ 100% และการควอนไทซ์ของ Unsloth ก็ดูดีกว่า QAT ต้นฉบับของ Google ที่กล่าวถึงในบทความ
ส่วนตัวตอนนี้ก็ใช้งานโมเดล 2B ผ่าน Unsloth Studio และ API สำหรับการค้นหาเว็บและสร้างเอาต์พุต JSON แบบมีโครงสร้าง แม้จะมีโมเดลอยู่ในโทรศัพท์ด้วยอยู่แล้ว ซึ่งเหมาะกับงานลักษณะนี้มาก
[0] https://huggingface.co/collections/unsloth/gemma-4-qat
[1] https://unsloth.ai/docs/models/gemma-4/qat#qat-analysis
สิ่งที่เห็นตรงนั้นไม่ใช่ BF16 ปกติ แต่เป็น BF16 QAT Q4_0
ความหมายใกล้เคียงกว่าคือ Google ควอนไทซ์โมเดลเป็น 4 บิตก่อน แล้วเก็บผลลัพธ์ในรูปแบบ BF16 เพื่อความเข้ากันได้กับตัวแพ็กระดับล่างและเพื่อความสะดวก
มันคล้ายกับการเอาเลข 8 บิตเล็กๆ ไปเก็บไว้ในจำนวนเต็ม 32 บิต ดังนั้นไม่ได้หมายความว่าใกล้เคียง 100% ของ BF16 ที่ไม่ควอนไทซ์
แต่ก็ยังสงสัยว่าทำไม 4-bit QAT Q4_0 ที่ Google ปล่อยออกมาถึงไม่แม่นยำ 100% ของ BF16 QAT Q4_0 พอดี เพราะการแปลงระหว่างสองการแพ็กนี้น่าจะเป็นแค่การจัดการบิตโดยไม่มีการควอนไทซ์เพิ่ม อย่างไรก็ตาม Unsloth บอกว่ามีปัญหาเรื่อง grid alignment
นอกเหนือจากนั้น ผมไม่ชอบที่ผู้ทำโมเดลขนาดเล็กอย่าง Google หรือ Qwen เวลาออกโมเดลใหม่มักโชว์แต่เบนช์มาร์ก BF16 ทั้งที่ในความเป็นจริงคนส่วนใหญ่รันแบบควอนไทซ์ 4~8 บิต ทำให้รู้ได้ยากมากว่าสูญเสียไปแค่ไหนใน 4 บิตหรือ 6 บิต
แค่สัปดาห์นี้ก็เห็นได้ชัดว่า ecosystem ของ Gemma พัฒนาเร็วแค่ไหน
มีทั้ง Gemma 12B, multi-token prediction และโมเดลควอนไทซ์อย่างเป็นทางการออกมาแล้ว ดูเหมือน Google จะทุ่มแรงกับรอบการปล่อยนี้จริงๆ เลยทำให้น่าคาดหวัง
เป็นวันศุกร์ก่อน WWDC และก็น่าสนใจที่ Apple มีกำหนดจะประกาศ Siri เวอร์ชัน “ปรับปรุง” ที่อิงกับโมเดลของ Google
ตอนนี้อาจยังเป็นพาร์ตเนอร์ชิพแบบปิดอยู่ แต่ก็เป็นไปได้ว่า Google กำลังเปิดเผยโมเดลล่วงหน้าที่ Apple จะสาธิตในสัปดาห์หน้า
ไม่มีข้อมูลยืนยัน เป็นแค่การคาดเดา
ลองรัน
hf.co/google/gemma-4-12B-it-qat-q4_0-gguf:Q4_0ผ่านollamaบนโน้ตบุ๊กที่มี AMD Ryzen 9 8940HX, NVIDIA GeForce RTX 5060 8GB และ RAM 14GB แล้ว เร็วกว่าที่คาดไว้การเปิดตัว Gemma 4 12B(https://news.ycombinator.com/item?id=48385906) แล้วอีกไม่กี่วันค่อยออก Q4_0 Gemma 4 12B อย่างเป็นทางการก็ดูแปลกๆ นิดหน่อย
ถึงอย่างนั้นก็ดีที่บทความนี้ระบุว่า Q4_0 Gemma 4 12B คาดว่าจะใช้ VRAM 6.7GB และยืนยันได้ว่าตรงกับคำกล่าวของ Google ว่าใส่อยู่ใน 16GB ได้สบาย แต่สุดท้ายก็ใช้ได้เฉพาะเวอร์ชันควอนไทซ์เท่านั้น
ที่เกี่ยวข้องกันคือใน Edge Gallery for macOS ที่ Google เพิ่งออกมาใหม่ กลับระบุว่า Gemma 4 12B ไม่รองรับบนเครื่อง 16GB เพราะ RAM ไม่พอ แต่เมื่อดูจากการใช้ VRAM ที่คาดไว้ตรงนี้ รุ่นย่อย Q4_0 ก็ควรจะรันได้ชัดเจน ดังนั้น Google ควรแก้ไข
ผมคิดว่าปล่อยโมเดลและรุ่นย่อยออกมาตามที่พร้อม ดีกว่ากักไว้จนทุกอย่างพร้อมทีเดียว
Q4_0 ไม่ได้เป็นแค่ Gemma 4 12B ที่ถูกควอนไทซ์ทีหลัง แต่เป็นเช็กพอยต์ที่ฝึกแบบรับรู้การควอนไทซ์
Google Pixel Intelligence อาจชนะ Apple Intelligence ได้
การรัน โมเดล 12B ได้บน VRAM 8GB ถือว่าเปลี่ยนเกมมาก
น่าทึ่งที่โมเดลโลคัลขนาดเล็กพัฒนาเร็วได้ขนาดนี้
ลองใช้ Gemma 4 E2B Unsloth 4Q แล้วทำงานได้ค่อนข้างดี: https://youtube.com/shorts/XLsAnz5aAAI
โมเดล E4B ขึ้น TPU ของโทรศัพท์ผมไม่ได้เลยเลยต้องสลับไปใช้ RAM แต่ถ้าเป็นเวอร์ชัน QAT แล้วความแม่นยำดีขึ้นก็ถือว่าน่ายินดี
พวกเรามองว่าแม้แต่ โมเดล E2B แบบไม่ควอนไทซ์ก็ไร้ประโยชน์โดยสิ้นเชิงกับงานจัดหมวดหมู่จริงที่ง่ายที่สุด
ผมเองก็อยากลองทดสอบบน Pixel ของผมเหมือนกัน