รัน LLM 28.9 ล้านพารามิเตอร์บนไมโครคอนโทรลเลอร์ราคา 8 ดอลลาร์ — เทคนิค Per-Layer Embeddings ของ Gemma ย่อโมเดลลง ESP32-S3 ได้ 9.5 tok/s
โปรเจกต์ที่ขึ้นหน้าแรก Hacker News เมื่อ 25 ก.ค. 2026 (เผยแพร่บน GitHub เมื่อ 23 ก.ค.) เป็นงานที่อ่านแล้วต้องกลับไปอ่านหัวข้ออีกรอบ: โมเดลภาษา 28.9 ล้านพารามิเตอร์ ที่รันจบในตัวบน ESP32-S3 — ไมโครคอนโทรลเลอร์ราคาประมาณ 8 ดอลลาร์ ที่มี SRAM แค่ 512KB ไม่มีการต่อเน็ต ไม่มีเซิร์ฟเวอร์ ตัวชิปพิมพ์ข้อความออกจอเล็ก ๆ ที่ต่อสายไว้ ด้วยความเร็วราว 9.5 โทเคน/วินาที
ตัวเลขที่ทำให้เรื่องนี้น่าสนใจไม่ใช่ 28.9 ล้าน แต่คือ สถิติเดิม: โมเดลภาษาที่เคยรันบนชิปคลาสนี้มีขนาดราว 260,000 พารามิเตอร์ งานชิ้นนี้จึงใหญ่กว่าราว 100 เท่า บนฮาร์ดแวร์เดิม และวิธีที่ทำให้มันฟิตได้ก็ไม่ใช่การบีบอัดที่แรงขึ้น แต่เป็นการ เปลี่ยนสมมติฐานว่าโมเดลต้องอยู่ในหน่วยความจำเร็ว
กำแพงจริงคือ SRAM ไม่ใช่จำนวนพารามิเตอร์
ปกติเวลารันโมเดลบนไมโครคอนโทรลเลอร์ ทั้งโมเดลต้องเข้าถึงได้จากหน่วยความจำเร็ว ซึ่งบน ESP32-S3 คือ SRAM 512KB นั่นแหละคือเพดานที่ล็อกทุกคนไว้กับโมเดลจิ๋ว
ทางออกของโปรเจกต์นี้คือ เลิกพยายามยัดโมเดลเข้าหน่วยความจำเร็วตั้งแต่แรก ข้อสังเกตตั้งต้นคือพารามิเตอร์ส่วนใหญ่ของโมเดลภาษาอยู่ใน ตารางเอ็มเบดดิง ซึ่งโมเดล “อ่าน” มากกว่า “คำนวณ” ด้วย ดังนั้นตาราง 25 ล้านพารามิเตอร์จึงถูกทิ้งไว้ใน แฟลชที่ช้าแต่ใหญ่ แล้วดึงขึ้นมาเฉพาะแถวที่แต่ละโทเคนต้องใช้ — ราว 6 แถว หรือประมาณ 450 ไบต์ต่อโทเคน ส่วนแกนที่ทำงานคำนวณจริงซึ่งเล็กกว่ามาก ยังนั่งอยู่ใน SRAM
ผลคือ “โมเดลใหญ่” แทบไม่มีต้นทุนตอนรัน เพราะคุณไม่เคยโหลดมันทั้งก้อน มันแค่นอนอยู่ในแฟลชแล้วถูกสุ่มอ่านทีละนิด
การแบ่งชั้นหน่วยความจำในโปรเจกต์เป็นแบบนี้:
| ชั้น | ขนาด/ความเร็ว | เก็บอะไร |
|---|---|---|
| SRAM | 512KB (เร็ว, จิ๋ว) | แกน “คิด” ที่ใช้ทุกโทเคน |
| PSRAM | 8MB (กลาง) | output head และหน่วยความจำทำงาน |
| Flash | 16MB (ใหญ่, ช้า) | ตารางเอ็มเบดดิง 25M พารามิเตอร์ |
โมเดลทั้งหมดหลังควอนไทซ์ 4-bit มีขนาด 14.9MB พอดีกับแฟลช 16MB
เทคนิคนี้มาจาก Gemma โดยตรง
ไอเดียนี้ไม่ใช่ของใหม่ในเชิงหลักการ — มันคือ Per-Layer Embeddings (PLE) ซึ่งเป็นดีไซน์ที่ Google ใช้ใน Gemma 3n และ Gemma 4 เพื่อให้โมเดลใหญ่ทำงานบนมือถือได้ จุดที่งานชิ้นนี้เพิ่มเข้ามาคือการเอา PLE มาวางบน memory layout ของไมโครคอนโทรลเลอร์ แทนที่จะเป็นโทรศัพท์หรือ GPU ซึ่งผู้เขียนระบุว่าเท่าที่ตรวจสอบได้ ยังไม่มีใครลองบนชิปเล็กขนาดนี้มาก่อน
อีกครึ่งหนึ่งของเครดิตอยู่ที่ TinyStories ชุดข้อมูลเรื่องสั้นสังเคราะห์จาก Microsoft Research (arXiv:2305.07759) ที่ง่ายพอให้โมเดลเล็กเรียนเขียนให้ต่อเนื่องได้จริง และสายเลือดทางความคิดจาก llama2.c ของ Andrej Karpathy
ต้องพูดให้ครบ: มันทำอะไร “ไม่ได้” บ้าง
ส่วนที่โปรเจกต์นี้ซื่อสัตย์มากและควรอ่านให้จบ — เพราะพาดหัวแบบนี้ชวนให้เข้าใจผิดได้ง่าย:
- โมเดลเทรนบน TinyStories จึง เขียนได้แค่เรื่องสั้นง่าย ๆ และส่วนใหญ่ยังต่อเนื่องพอใช้
- มัน ตอบคำถามไม่ได้ ทำตามคำสั่งไม่ได้ เขียนโค้ดไม่ได้ และไม่รู้ข้อเท็จจริงอะไรเลย
- ข้อจำกัดนี้มาจาก แกนคำนวณที่เล็ก ไม่ใช่จากเทคนิคหน่วยความจำ — และ PLE ไม่ได้ช่วยแก้ตรงนี้
พูดอีกแบบคือ ของที่น่าสนใจคือ สถาปัตยกรรม ไม่ใช่คุณภาพข้อความที่ออกมา
ผู้เขียนยังจงใจทิ้งประวัติ commit ที่ “รก” ไว้ในรีโป รวมถึง บั๊กในการนับพารามิเตอร์ของตัวเองที่เคยทำให้ตัวเลขช่วงแรกสูงเกินจริง และผลที่แก้แล้ว ซึ่งเป็นมาตรฐานการรายงานที่หายากในโปรเจกต์แนวนี้ ทั้งวิธีการ ablation และผลวัดบนชิปจริงอยู่ใน RESULTS.md ส่วนเฟิร์มแวร์ การต่อสาย และขั้นตอนแฟลชอยู่ใน firmware/esp32_llm/
ข้อควรทราบสำหรับคนจะเอาไปใช้ต่อ: ณ เวลาที่เขียน รีโป ยังไม่ได้ระบุไลเซนส์ ไว้ ถ้าจะนำโค้ดไปใช้ในงานจริงควรรอหรือติดต่อผู้เขียนก่อน
มุมมอง AI Curator
สิ่งที่โปรเจกต์นี้พิสูจน์ไม่ใช่ “โมเดล 28.9M ทำงานได้ดี” — มันทำได้ไม่ดีเลย และผู้เขียนก็บอกเองชัด ๆ สิ่งที่มันพิสูจน์คือ ข้อจำกัดที่วงการ embedded AI ยอมรับกันมานานว่าเป็นกำแพงฮาร์ดแวร์ จริง ๆ แล้วเป็นกำแพงของสมมติฐาน ทุกคนคิดว่าโมเดลต้องอยู่ใน RAM พอเลิกคิดแบบนั้น เพดานก็ขยับขึ้น 100 เท่าทันทีบนชิปตัวเดิมราคาเท่าเดิม
จุดที่ผมคิดว่าสำคัญกว่าตัวเดโมคือ PLE เพิ่งเดินทางจากงานวิจัยของ Google ลงมาถึงมือแฮกเกอร์คนเดียวภายในเวลาไม่กี่เดือน Gemma 3n ออกแบบ PLE มาเพื่อมือถือ แต่พอเทคนิคถูกเขียนไว้ชัดในโมเดลโอเพนเวต มันก็ถูกยกไปวางบนแพลตฟอร์มที่ผู้ออกแบบไม่เคยตั้งใจได้ นี่คือมูลค่าที่จับต้องได้ของ “โอเพนเวต + เปเปอร์ที่อธิบายสถาปัตยกรรมจริง” ที่ API แบบปิดให้ไม่ได้ ต่อให้ API นั้นเก่งกว่าสิบเท่าก็ตาม
สำหรับไทยและ SEA ผมมองว่าทิศทางนี้ตรงกับโจทย์ที่เรามีจริงมากกว่าข่าวโมเดลระดับล้านล้านพารามิเตอร์ งานที่ต้องการ NLP เบา ๆ แบบ ออฟไลน์ล้วน — เครื่องอ่านมิเตอร์ในพื้นที่ไม่มีสัญญาณ, อุปกรณ์เกษตร, ป้ายอัจฉริยะในโรงงาน, ของเล่นเพื่อการศึกษา — คือตลาดที่ต้นทุนต่อชิ้นระดับหลักสิบบาทเป็นตัวตัดสิน ไม่ใช่คะแนนเบนช์มาร์ก และเป็นตลาดที่ไทยผลิตฮาร์ดแวร์ได้เองอยู่แล้ว
แน่นอนว่ายังต้องรออีกหลายรอบกว่าจะมีโมเดลระดับ ทำตามคำสั่งได้ บนชิป 8 ดอลลาร์ — โจทย์นั้นต้องขยายแกนคำนวณ ไม่ใช่ขยายตารางเอ็มเบดดิง ซึ่งเป็นคนละปัญหาและยากกว่ามาก แต่ถ้าใครกำลังคิดจะทำ โมเดลภาษาไทยขนาดจิ๋วสำหรับงานเฉพาะทางบน edge เทคนิคการวางเลเยอร์หน่วยความจำในรีโปนี้คือของที่ควรอ่านก่อนเริ่มเขียนโค้ดบรรทัดแรก
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog