ชุมชนขุดคุ้ยการซ่อน MTP ใน Gemma 4 ก่อนที่ Google จะรองรับแบบอ้อมในภายหลัง

(reddit.com)

5 คะแนน โดย darjeeling 1 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

Google เคยถอดฟีเจอร์ดังกล่าวออกจากชุดเผยแพร่สาธารณะของ Gemma 4 ที่ฝึกด้วย MTP ก่อนจะถูกชุมชนจับได้จากการทำรีเวิร์สเอนจิเนียริง และภายหลังก็เริ่มรองรับแบบอ้อมในรูปของโมเดลผู้ช่วยภายนอก

ขณะนักพัฒนาโอเพนซอร์สกำลังวิเคราะห์ไฟล์ .litertlm (อิง TFLite) ซึ่งเป็นฟอร์แมตที่ Google แจกจ่ายสำหรับอุปกรณ์มือถือ/เอดจ์ พวกเขาก็พบข้อเท็จจริงที่น่าตกใจ ระบุว่า สถาปัตยกรรม MTP (Multi-Token Prediction, การทำนายหลายโทเคน) ซึ่งไม่มีอยู่ในค่าน้ำหนักโมเดลมาตรฐานที่เปิดเผยบน HuggingFace กลับถูกใส่ไว้เฉพาะในไฟล์คอมไพล์สำหรับเอดจ์เท่านั้น

เมื่อมีการตั้งคำถามเรื่องนี้ต่อสาธารณะ Google ก็ยอมรับข้อเท็จจริงและตอบว่า:

> "หัวทำนายที่เกี่ยวข้องกับ MTP ถูกตัดออกจากโมเดลสาธารณะโดยตั้งใจ เพื่อให้เข้ากันได้กับ HuggingFace Transformers API ส่วนในรันไทม์ LiteRT ยังคงเก็บไว้เพื่อเพิ่มประสิทธิภาพบนอุปกรณ์"

MTP คืออะไร

LLM ทั่วไปจะสร้างโทเคนทีละตัวตามลำดับ ส่วน MTP เป็นเทคนิคที่ทำนายหลายโทเคนพร้อมกันได้ใน forward pass เดียว และเมื่อใช้ร่วมกับ speculative decoding ก็สามารถเพิ่มความเร็วการอนุมานได้มากโดย ไม่เปลี่ยนคุณภาพของผลลัพธ์ เป็นการปรับแต่งเชิงทฤษฎีแบบไม่สูญเสีย (lossless)

ความพยายามรีเวิร์สเอนจิเนียริงของชุมชน

ผู้ค้นพบคนแรกสามารถดึงไฟล์ .tflite หลายไฟล์ออกมาจากไฟล์ .litertlm ได้สำเร็จ จากนั้นจึงเผยแพร่ไฟล์ที่ดึงออกมาและขั้นตอนการทำซ้ำบน HuggingFace พร้อมขอความร่วมมือจากผู้ที่ถนัด C++ ต่อมาผู้มีส่วนร่วมในชุมชนก็เริ่มลงมือรีเวิร์สเอนจิเนียริงอย่างจริงจัง

อุปสรรคทางเทคนิค: โครงสร้างเคอร์เนลของ TFLite โหดมาก โดยเป็นลำดับแบบ quantize เวกเตอร์ attention ขนาด 1024-wide เป็น INT8 → คูณกับค่าน้ำหนัก INT8 → requantize ผลลัพธ์ → แล้ว dequantize กลับอีกครั้ง

ผลลัพธ์: หลังจากทำงานอย่างเข้มข้นหลายวัน ก็สามารถสร้างส่วนต่อไปนี้กลับขึ้นมาได้สำเร็จ:

โครงสร้าง GQA (Grouped-Query Attention) และการแมป external KV cache
การทำงานของ sliding local window
เส้นทาง quantization ของ pre_project / q_proj / MLP / o_proj / post_project
การทำงานของ RoPE แบบบางส่วน
ทำ end-to-end TFLite parity ได้ top-1 match 20/20

ไลเซนส์เป็น Apache 2.0 จึงไม่มีปัญหาทางกฎหมาย

ประสิทธิภาพจริง: เร็วขึ้นแค่ไหน

ผลวัดจริงของชุมชน (อิง Strix Halo):

งาน	เดิม	หลังใช้ MTP
สร้างโค้ด	8 tps	25 tps (ประมาณ 3x)
เขียนข้อความทั่วไป	7~8 tps	11~14 tps

เมื่อเทียบกับ speculative decoding ในตระกูล LLaMA/Qwen3 เดิมที่มักอยู่ราว 1.5~1.7x และสูงสุดประมาณ 2x แล้ว ตัวเลข 3x ในงานเขียนโค้ดถือว่าผิดปกติ เหตุผลที่วิเคราะห์กันคือธรรมชาติของการสร้างโค้ดมี boilerplate ซ้ำ ๆ มาก ทำให้อัตราการยอมรับ draft token สูง

ปฏิกิริยาและข้อสงสัยจากชุมชน

เสียงวิจารณ์หลักพุ่งไปสองทาง

① คำวิจารณ์เรื่องไม่ทำเอกสารกำกับ (Undocumented): ฝึกด้วย MTP แล้วกลับจงใจถอดออกจากชุดเผยแพร่สาธารณะโดยไม่พูดถึงเลย

② ข้อสงสัยเรื่องเจตนาทางการค้า: มีการอ้างว่า "หากโมเดลโอเพนซอร์ส 31B ที่รันบนเครื่องโลคัลเร็วเกินไป ก็จะกระทบความสามารถในการแข่งขันของ API เชิงพาณิชย์ของบริษัทเอง (เช่น Flash Lite) จึงถูกเนิร์ฟโดยตั้งใจ" โมเดล 122B ที่เคยหลุดแล้วถูกลบก็ถูกยกมาพูดถึงในบริบทเดียวกัน

การเลือกเชิงโครงสร้างของ Google

ช่องทางเผยแพร่	มี MTP หรือไม่
ค่าน้ำหนักสาธารณะบน HuggingFace	❌ ถอดออกโดยตั้งใจ
LiteRT (เอดจ์/มือถือ)	✅ ฝังมาในตัว
gemma4_assistant (ใหม่ 5/5)	✅ รองรับแบบอ้อมผ่านโมเดลผู้ช่วยภายนอก

การตอบสนองอย่างเป็นทางการที่ล่าช้าของ Google (5–6 พฤษภาคม)

เมื่อแรงกดดันจากชุมชนรุนแรงขึ้น Google ก็ปล่อยโมเดลผู้ช่วย gemma4_assistant แยกต่างหากบน HuggingFace เมื่อวันที่ 5 พฤษภาคม และประกาศ Gemma 4 MTP drafter ผ่านบล็อกทางการ เป็นรูปแบบการรองรับแบบอ้อมโดยแยกฟีเจอร์ที่เดิมควรอยู่ในตัวโมเดลออกมาเป็นโมเดลภายนอก

ความเร็ว: เพิ่มความเร็วการอนุมานได้สูงสุด 3 เท่าโดยคุณภาพไม่ลดลง
โมเดลผู้ช่วย: drafter ขนาดเล็กประมาณ 500M พารามิเตอร์
วิธีใช้: เพียงส่งผ่านในอาร์กิวเมนต์ assistant_model= ของฟังก์ชัน generate() ก็ใช้งานได้ ไม่ต้องทำ MTP แบบคัสตอมเอง
สภาพแวดล้อมที่รองรับ: HuggingFace Transformers, vLLM, MLX(Apple Silicon), LiteRT-LM

> 💡 สรุปสั้น ๆ: Google เคยถอดฟีเจอร์ MTP ออกจาก Gemma 4 เวอร์ชันสาธารณะที่ฝึกมาด้วย MTP ก่อนถูกชุมชนจับได้จากการรีเวิร์สเอนจิเนียริง และภายหลังจึงเริ่มรองรับแบบอ้อมผ่านโมเดลผู้ช่วยภายนอก