DeepGrove ปล่อย Maple-Preview โมเดล 20B ที่เทรนเป็น ternary ตั้งแต่ต้น — เคลม 218 tok/s บน Mac mini M4 และเช็คพอยต์ 5.31GB แต่ไฟล์ที่โหลดได้จริงคือ 40.4GB

วิธีย่อโมเดลให้ลงเครื่องเล็กที่เราคุ้นกันมาตลอดคือ เทรนเสร็จก่อนแล้วค่อยควอนไทซ์ทีหลัง — GGUF Q4, INT8, ไปจนถึงงาน 1-bit อย่าง Bonsai 27B ที่เราเขียนถึงเมื่อ 15 กรกฎาคม ซึ่งเอา Qwen3.6-27B มาบีบเหลือ 3.9GB สตาร์ทอัพ DeepGrove เพิ่งอัปโหลด Maple-Preview ขึ้น Hugging Face เมื่อ 4 สิงหาคม 2026 เวลา 20:50 UTC พร้อมประโยคที่ท้าทายวิธีคิดนั้นตรง ๆ ใน Show HN ของตัวเอง: การควอนไทซ์ย้อนหลัง “เป็นแนวทางที่ผิดโดยพื้นฐาน” — Maple ถูกออกแบบและเทรนให้น้ำหนักเป็น ternary (มีแค่ -1, 0, +1) ตั้งแต่ต้นทาง

ตัวเลขบนโมเดลการ์ดน่าสนใจมาก: 20B-A1B (พารามิเตอร์รวม 20B, ทำงานจริงราว 1B ต่อโทเคน), เช็คพอยต์ 5.31GB, 218 tok/s บน Mac mini M4, คอนเท็กซ์ 131,072 โทเคน และปล่อยใต้ MIT License เต็มรูปแบบ พร้อมเคลมว่าเร็วกว่าโมเดลประหยัดอย่าง Gemma 4, Qwen3.5 และ gpt-oss ราว 5–16 เท่า และ “แก้โจทย์ระดับ IMO ได้”

แต่ถ้าคุณกดโหลดจริง สิ่งที่ได้ไม่ใช่ 5.31GB

ไฟล์บน Hugging Face คือ bf16 ขนาด 40.4GB

เราไล่ดู manifest ของรีโปโดยตรง model.safetensors.index.json ระบุ total_size ไว้ที่ 40,428,060,672 ไบต์ — ราว 40.4GB กระจายเป็น safetensors 9 ชาร์ด (8 ไฟล์ละ 5GB + เศษอีก 0.43GB) และ config.json ระบุ "dtype": "bfloat16" ชัดเจน

พูดง่าย ๆ คือสิ่งที่ DeepGrove ปล่อยออกมาคือ น้ำหนักต้นฉบับความละเอียดเต็ม ไม่ใช่เช็คพอยต์ ternary แบบแพ็กบิตที่ทำให้ได้ตัวเลข 5.31GB ตัวเลข 5.31GB นั้นสอดคล้องกับสถาปัตยกรรมอยู่ (20B ที่ ~1.58 บิตต่อน้ำหนัก บวก embedding กับ output head ที่ยังเป็นความละเอียดสูง ก็ได้ราวนั้น) แต่มัน ไม่ใช่สิ่งที่อยู่ในรีโป ณ ตอนนี้

ที่สำคัญกว่านั้นคือหมายเหตุที่ DeepGrove เขียนไว้เองในโมเดลการ์ด:

“โค้ด Transformers ที่แนบมาต้องพึ่ง Triton และ FlashAttention และตั้งใจให้รันบนสภาพแวดล้อม CUDA ที่รองรับ ส่วนผลลัพธ์บน Apple Silicon ที่รายงานไว้ใช้รันไทม์บนเครื่องอีกตัวหนึ่ง”

รันไทม์ตัวนั้น ไม่ได้อยู่ในรีโป ไฟล์ทั้งหมดที่ปล่อยมามีแค่ modeling_maple.py, configuration_maple.py, fa3.py (FlashAttention-3) และ tokenizer — ไม่มีเคอร์เนล Metal, ไม่มี MLX, ไม่มี GGUF แปลว่าตัวเลข 218 tok/s บน M4 ที่เป็นหัวใจของข่าวนี้ ยังทำซ้ำไม่ได้จากของที่แจก คุณโหลดได้แค่โมเดล bf16 40GB ที่ต้องมีการ์ด CUDA มารัน ซึ่งตรงข้ามกับคำโฆษณา “รันบนเครื่องคุณ” อย่างสิ้นเชิง

สถาปัตยกรรมที่ออกแบบมาเพื่อเครื่องเล็กจริง ๆ

ถ้ามองข้ามเรื่องไฟล์ที่ยังไม่ครบ ดีไซน์เองน่าสนใจ เราอ่านจาก config.json ได้ตรง ๆ:

• 24 เลเยอร์, hidden size แค่ 2048
• MoE 256 experts เลือกใช้ 8 ตัวต่อโทเคน ไม่มี shared expert และ moe_intermediate_size เล็กมากที่ 512 — นี่คือเหตุผลที่ active param เหลือราว 1B
• attention แบบ 3:1 — sliding window 512 สามเลเยอร์ สลับ full attention หนึ่งเลเยอร์ วนไป (นับจาก layer_types ได้ full attention 6 เลเยอร์จาก 24)
• nope_on_global_attention: true — เลเยอร์ global ไม่ใส่ positional encoding, ส่วน sliding layer ใช้ RoPE บางส่วน (partial_rotary_factor: 0.5)
• vocab 151,936 (ชุดเดียวกับตระกูล Qwen), คอนเท็กซ์ 131,072

การรวม expert เยอะแต่เล็กมาก เข้ากับ sliding window 512 เป็นส่วนใหญ่ คือสูตรที่ตั้งใจกดทั้งแบนด์วิดท์หน่วยความจำและขนาด KV cache พร้อมกัน ซึ่งเป็นคอขวดจริงบนมือถือ/แล็ปท็อป มากกว่าจำนวน FLOPs

DeepGrove เขียนข้อจำกัดไว้เองด้วยว่าพรีวิวตัวนี้ “ผ่าน post-training สำหรับงาน agentic น้อยมาก และทำ RL ทั่วไปแค่ขนาดเล็ก” จึง “อาจทำได้ไม่ดีบน benchmark ฝั่ง agentic” — เป็นความซื่อสัตย์ที่หาไม่ค่อยได้ แต่ก็แปลว่าอย่าเพิ่งเอาไปวางเป็นสมองของ agent

เสียงจากคนที่ลองแล้ว

กระทู้ Show HN (โพสต์เมื่อราว 13 ชั่วโมงก่อนเขียนข่าวนี้) ให้ภาพที่สมดุลกว่าโมเดลการ์ด มีคนลองถามคำถามเชิงนิรุกติศาสตร์ที่ค่อนข้างเฉพาะทางแล้วได้คำตอบที่ “มั่นใจมากและผิดมาก” — แต่งที่มาของคำขึ้นเอง ซึ่งเป็นอาการคลาสสิกของโมเดลที่ active param แค่ 1B: ความจำเชิงข้อเท็จจริงมีน้อย ต่อให้ความสามารถด้านการให้เหตุผลจะดีก็ตาม

ประเด็นที่ตามมาในกระทู้น่าคิดกว่า — โมเดลบนเครื่องขนาดนี้ควรถูกคาดหวังให้ “รู้” อะไรหรือไม่ หรือควรทำหน้าที่เป็นตัวเรียบเรียง/เรียกเครื่องมือ แล้วปล่อยให้ข้อเท็จจริงมาจาก RAG และโค้ดปกติ อีกคนตั้งข้อสังเกตว่าเดโมกินหน่วยความจำพีคราว 5.9GB ซึ่งชนเพดาน jetsam ของ iOS บนไอโฟนหลายรุ่น — คำว่า “รันบนไอโฟน” จึงยังต้องดูว่าเป็นเครื่องรุ่นไหน

สังเกตด้วยว่าพาดหัวบน HN พูดถึง 120 tok/s บนไอโฟน แต่ตัวเลขนั้น ไม่ปรากฏในโมเดลการ์ด ซึ่งพูดถึงแค่ 218 tok/s บน Mac mini M4 เท่านั้น

มุมมอง AI Curator

Maple-Preview เป็นตัวอย่างที่ดีของสองอย่างที่มาพร้อมกัน: ไอเดียที่ถูกทาง กับ การปล่อยของที่ยังไม่ครบ

ไอเดียถูกทางตรงที่ ถ้าเป้าหมายคือรันบนเครื่องผู้ใช้จริง การเทรนให้เป็น ternary ตั้งแต่ต้นย่อมเหนือกว่าการบีบทีหลัง เพราะโมเดลได้เรียนรู้ที่จะใช้ความละเอียดเท่าที่มีจริง แทนที่จะถูกตัดทิ้งความรู้บางส่วนตอนควอนไทซ์ ตัวเลข 89.5% / 94.6% ที่ Bonsai เคลมไว้ตอนกรกฎาคมสะท้อนว่าการบีบทีหลังมี “ภาษี” ที่จ่ายเสมอ — Maple พยายามไม่ต้องจ่ายภาษีนั้นเลย

แต่การปล่อยของยังไม่ครบ และเป็นแบบที่ทำให้ตรวจสอบไม่ได้พอดี: ทุกตัวเลขที่ทำให้ข่าวนี้น่าตื่นเต้น (5.31GB, 218 tok/s, รันบนมือถือ) ผูกอยู่กับรันไทม์ที่ยังไม่ปล่อย ส่วนของที่ปล่อยจริงคือ bf16 40GB ที่ต้องใช้ CUDA — ซึ่งเป็นโปรไฟล์ตรงข้ามกับที่โฆษณา นี่ไม่ได้แปลว่าเคลมนั้นเท็จ แต่แปลว่า ณ วันนี้มันคือ เคลมที่ยังไม่มีใครนอกบริษัทยืนยันได้ ต่างจาก Bonsai ที่ปล่อย GGUF/MLX ให้คนโหลดไปรันบน llama.cpp ได้ทันที

สำหรับนักพัฒนาไทย คำแนะนำเชิงปฏิบัติชัดเจน: MIT License เป็นเรื่องดีมากและทำให้ Maple เป็นฐานที่เอาไปต่อยอดเชิงพาณิชย์ได้จริง แต่ ยังไม่ใช่เวลาที่จะเอาไปวางแผนโปรดักต์ สิ่งที่ควรจับตาคือรีโปเดียวกันนี้ในอีกไม่กี่สัปดาห์ — ถ้ามีเช็คพอยต์แพ็กบิตจริงและรันไทม์ Apple Silicon ตามมา นี่จะกลายเป็นหนึ่งในโมเดล on-device ที่น่าสนใจที่สุดของปี ถ้าไม่มี มันก็คือเปเปอร์ที่มาพร้อมน้ำหนักที่ไม่มีใครรันในโหมดที่ตั้งใจได้

และบทเรียนที่กว้างกว่านั้น — ซึ่งเราเจอซ้ำ ๆ ในรอบนี้ ทั้งกรณี “MiniMax H3 รัน 2K บน RTX 3060” เมื่อวานและกรณีนี้ — คือ พาดหัวเรื่องความเร็วบนเครื่องเล็กต้องถูกอ่านคู่กับรายการไฟล์ในรีโปเสมอ ตัวเลข tok/s ที่ไม่มีรันไทม์แนบมา ยังไม่ใช่ตัวเลขที่คุณจะได้

แหล่งข่าว

• deepgrove/maple-preview — Hugging Face
• รายการไฟล์ของโมเดล (tree/main)
• Show HN: Maple-Preview – ternary 20B MoE running at 120 tok/s on a iPhone
• DeepGrove