วิเคราะห์ Show HN: เอนจิน Open-Source รัน Gemma 4 26B ใน RAM แค่ 2 GB บน Mac ตระกูล M ได้ยังไง

เอนจิ้นโอเพนซอร์สตัวนี้รัน Gemma 4 26B-A4B ได้ในแรมแค่ 2GB บน Mac ตระกูล M-series ซึ่งคือก้าวกระโดดเรื่อง memory efficiency จริงๆ เพราะโมเดลระดับ 26B ปกติกินแรมหลัก 10GB ขึ้นไปสบายๆ

ตัวเลขจาก repo ผู้พัฒนา: M2 MacBook Air (8GB) ทำได้ 5.1–6.3 tokens/s ส่วน M5 Pro (24GB) ได้ถึง 31–35 tokens/s เทคนิคหลักคือ stream เฉพาะ experts ที่ต้องการต่อ token จาก SSD โดยเก็บ core 1.35GB และ FP16 KV cache ไว้ใน RAM ตลอดเวลา ไม่โหลดทั้งโมเดล 14.3GB พร้อมกัน

ข้อจำกัดสำคัญที่ต้องรู้ก่อน: ต้องใช้ macOS 26 + Metal 4 และเนื้อที่เก็บข้อมูลอีก 14.3GB สำหรับตัวโมเดล ตอนนี้รองรับเฉพาะ Gemma 4 26B-A4B เท่านั้น ยังไม่มี benchmark เทียบตัวต่อตัวกับ llama.cpp หรือ MLX จากฝั่ง community

รันโมเดล 26B บนแรม 2GB จริงหรือ — หน้าตาตอนใช้งานจริง

เทคนิคหลักของ engine นี้ไม่ใช่แค่ loading weights ทีละชั้น แต่ใช้สถาปัตยกรรม MoE (Mixture of Experts) ของ Gemma 4 เป็นข้อได้เปรียบ — เก็บ core 1.35GB และ FP16 KV cache ไว้ใน RAM ตลอดเวลา แล้ว stream เฉพาะ experts ที่จำเป็นต่อการสร้างแต่ละ token จาก SSD ทำให้โมเดลขนาด 14.3GB วิ่งได้ใน RAM แค่ 2GB

ตัวเลขจาก README: M2 MacBook Air (8GB) ทำได้ 5.1–6.3 tokens/s, M5 Pro (24GB) ทำได้ 31–35 tokens/s ส่วน benchmark เทียบตัวต่อตัวกับ llama.cpp หรือ MLX ในงานประเภทเดียวกันยังต้องรอ community รันให้ครบก่อน

ถ้าใครมี MacBook M-series อยู่แล้วอยากลองเอง วิธีเช็คง่ายสุดคือเปิด Activity Monitor คู่กันตอนรัน ดู memory footprint ของ process ตรงๆ จะได้รู้ว่าตัวเลขที่โพสต์อ้างมาตรงกับที่เจอจริงแค่ไหน

งบมี Mac M1 แรม 8GB สักเครื่อง อยากรันโมเดลภาษาใหญ่ในเครื่องเอง จะได้ไม่ต้องส่งข้อมูลลูกค้าหรือโค้ดบริษัทออกไปให้ cloud API ไหนทั้งนั้น

พอลองโหลดโมเดลระดับ 20B+ มารันตรงๆ ผ่าน tool ทั่วไป เจอปัญหาเดิมซ้ำๆ คือแรมไม่พอ เครื่องค้าง หรือช้าจนใช้งานจริงไม่ได้ ทางเลือกที่เหลือคือถอยไปใช้โมเดลเล็กลงที่ตอบได้ไม่ฉลาดเท่า หรือยอมเสียหลักการแล้วพึ่ง API ข้างนอกไปก่อน

นี่คือจุดที่โพสต์ Show HN นี้เข้ามาโดนใจ เพราะสัญญาว่าจะรันโมเดล 26B ได้ในแรมแค่ 2GB — ถ้าทำได้จริง มันแก้ปัญหาคอขวดที่คนใช้ Mac แรมน้อยเจอกันมานานพอดี แต่คำถามคือทำได้จริงแค่ไหน ต้องแลกอะไรบ้าง

เอนจิ้นนี้ยืนอยู่ตรงไหนในโลก local LLM

ในตลาด on-device inference ตอนนี้มีผู้เล่นหลักคือ llama.cpp (GGUF quantization), MLX (framework ของ Apple เอง optimize สำหรับ Apple Silicon), และ Ollama ที่ทำหน้าที่เป็น wrapper ให้ใช้ง่ายขึ้น โปรเจกต์นี้ไม่ได้มาแทนที่สามเจ้านั้น แต่วางตัวเป็น engine แยกที่เน้น memory footprint เป็นหลัก — ต่างจาก MLX ที่เน้น speed บน unified memory ของ Apple Silicon

Gemma เองก็เป็นโมเดลตระกูลที่ Google ออกแบบมาให้ efficient ตั้งแต่ต้นอยู่แล้ว (เทียบกับ Llama หรือ Mistral ในขนาดใกล้กัน) การเอา Gemma มาทดสอบก่อนจึงไม่ใช่เรื่องบังเอิญ — มันคือโมเดลที่เหมาะกับการโชว์ของว่า “บีบแรมได้ขนาดไหนโดยยังใช้งานได้จริง”

Streaming MoE vs Quantize ทั่วไป — สิ่งที่เปลี่ยนจริงในระดับเทคนิค

จุดต่างหลักไม่ได้อยู่ที่ตัวโมเดล Gemma เอง แต่อยู่ที่เอนจิ้นที่ใช้รัน วิธีเดิมด้วย quantize มาตรฐานบน MLX ยังต้องใช้ unified memory ตามขนาดโมเดลเกือบเต็มๆ ถ้าจะรันระดับ 26B เครื่องต้องมีแรมเหลือเยอะพอสมควร

ส่วนเอนจิ้นใหม่ที่โพสต์ใน Show HN นี้ บีบให้เหลือแค่ RAM 2GB ได้ ซึ่งเป็นตัวเลขที่ทำให้กระทู้นี้ถูกพูดถึงเยอะ เพราะปกติโมเดลขนาดนี้ไม่มีทางรันบนเครื่องแรมน้อยขนาดนี้เลย

ความเร็วที่ผู้พัฒนาระบุใน README: M2 Air ได้ 5–6 tokens/s, M5 Pro ได้ 31–35 tokens/s แต่ยังขาด benchmark เทียบตัวต่อตัวกับ quantize มาตรฐานบน MLX ในงานเดียวกัน ต้องรอ community รันเปรียบเทียบจริงก่อนสรุปว่าคุณภาพ output ต่างกันมากแค่ไหน

ใช้งานแล้วเปลี่ยนอะไรในชีวิตจริงบ้าง

ฟีเจอร์ memory streaming ที่โหลดโมเดลเข้า RAM แค่บางส่วนแทนที่จะยัดทั้งก้อน คือตัวเปลี่ยนเกมจริงๆ ครับ

เอามาแมปกับชีวิตจริงได้ตรงๆ เลย: MacBook Air รุ่นเก่าที่ RAM ไม่พอรันโมเดลใหญ่แต่ก่อน ตอนนี้เปิด terminal รันเป็น coding assistant ได้เลยแม้ไม่มีเน็ต เหมาะกับเวลานั่งเขียนโค้ดบนเครื่องบินหรือที่สัญญาณไม่ถึง

อีกเคสคือ private assistant — ข้อมูลไม่ต้องหลุดออกไปไหน รันในเครื่องล้วนๆ เหมาะกับคนที่กังวลเรื่อง privacy หรือทำงานกับข้อมูลบริษัทที่ห้ามส่งออก cloud

ส่วนคนมีแล็ปท็อปสำรองสเปกต่ำๆ ก็เอาไปรันโมเดลระดับ 26B ได้โดยไม่ต้องซื้อเครื่องใหม่ แต่ตรงนี้ต้องย้ำว่าความเร็วที่ได้จะขึ้นกับรุ่น Mac และ SSD speed มาก — M2 Air ได้ 5–6 tokens/s ซึ่งพอใช้ได้แต่ไม่ใช่ระดับคุย real-time ส่วนคุณภาพ output เทียบกับรันแบบเต็ม RAM ยังต้องรอ benchmark จาก community อีกชุดหนึ่ง

ทางเลือกอื่นในตลาดตอนนี้เป็นยังไงบ้าง

พอเทียบกับเครื่องมือรัน local LLM ที่คนสาย dev คุ้นเคยอยู่แล้ว จุดขายของตัวนี้คือ RAM footprint ที่เล็กกว่าชัดเจน ส่วนเรื่อง speed/quality เทียบตัวต่อตัวยังไม่มีตัวเลขยืนยันในข้อมูลที่มี ต้องรอ benchmark จริงก่อนสรุป

ถ้าเน้นความเสถียรตอนนี้ Ollama หรือ llama.cpp ยังตอบโจทย์กว่า แต่ถ้าอยากลองของใหม่ที่ RAM กินน้อย engine นี้น่าจับตาดูต่อ

ข้อดีข้อเสียที่ควรรู้ก่อนลอง

โปรเจกต์นี้น่าสนใจตรงที่แก้ pain point จริงของคนใช้ Mac รุ่นเก่าที่ RAM จำกัด แต่ก่อนโดดลงไปลอง ควรรู้ทั้งจุดแข็งจุดอ่อนให้ครบก่อน

สรุปคือเหมาะกับคนอยากทดลองของใหม่ ไม่ใช่งาน production ที่ต้องการความนิ่ง

ต้นทุนที่ไม่ได้อยู่บนตัวเลข 2GB

ตัวเลข 2GB ดูสวยบนหน้า README แต่ต้นทุนจริงไม่ได้อยู่ตรงนั้น เวลาที่เสียไปกับการตั้งค่า อ่าน source code แทนเอกสาร คือต้นทุนที่มองไม่เห็นในกราฟ benchmark.

เวลารันโมเดลบีบอัดขนาดนี้ต่อเนื่องนาน ๆ พัดลม Mac จะทำงานหนักขึ้น เครื่องร้อนขึ้น ถ้าเป็น MacBook ก็กินแบตเร็วกว่าใช้งานทั่วไปแน่นอน แม้ตัวเลขแบตที่แน่นอนจะขึ้นกับรุ่นเครื่อง.

อีกจุดที่ต้องคิด: บีบโมเดลให้พอดี RAM 2GB ได้ยังไง คำตอบส่วนใหญ่คือ quantization ซึ่งมักแลกมาด้วยคุณภาพคำตอบที่ลดลงบ้าง สุดท้ายที่เสี่ยงสุดคือโปรเจกต์โอเพนซอร์สหน้าใหม่ ถ้า maintainer เลิกทำต่อ ก็ต้องหาทางย้ายเองทั้งหมด.

เหมาะกับใคร ใครควรรอไปก่อน

เทรนด์นี้บอกอะไรเราชัดๆ อย่างหนึ่ง: กำแพงระหว่าง “โมเดลใหญ่” กับ “เครื่องเล็ก” กำลังบางลงเรื่อยๆ ครับ

เมื่อก่อนรัน 26B ต้องมี GPU แรงๆ หรือ RAM หลักสิบ GB วันนี้เหลือแค่ 2 GB บน MacBook ทั่วไป — ถ้า engine แบบนี้พัฒนาต่อ โจทย์ต่อไปคือความเร็วและความแม่นยำหลัง quantization จะไล่ทันโมเดลตัวเต็มแค่ไหน

สำหรับคนอยากตาม ผมว่าเริ่มจากลองรันบนเครื่องที่มีอยู่แล้วดูก่อน ไม่ต้องซื้อเครื่องใหม่ ดู GitHub repo ว่า community fix bug เรื่อง context กับ quantization ไปถึงไหนแล้ว แล้วรอดูว่า framework ใหญ่ๆ อย่าง llama.cpp หรือ MLX จะดูดแนวคิดนี้ไปทำ mainstream ต่อหรือเปล่า — นี่แหละคือจุดที่ local AI จะเปลี่ยนจาก niche เป็นของใช้จริงในชีวิตประจำวัน