Edge0 รันโมเดล MoE 35B บน Mac ด้วยหน่วยความจำ 2.9 GiB โดยสตรีม expert จาก SSD — แต่ runtime ตัดจำนวน expert ต่อโทเคนจาก 8 เหลือ 4 และผู้ใช้ M1 วัดได้ช้ากว่าตัวเลขที่ประกาศราว 30 เท่า

edge0 เป็นเฟรมเวิร์กอินเฟอเรนซ์โอเพนซอร์ส (Apache-2.0) สำหรับโมเดล Mixture-of-Experts ที่ปล่อยขึ้น GitHub และ Hugging Face ตั้งแต่ 8 กันยายน 2026 แม้จะเปิดตัวมาเกือบหนึ่งสัปดาห์แล้ว (โพสต์นี้จึงเป็นการตามเก็บข่าว) แต่ถึงเช้า 14 ก.ย. รีโปยังได้ดาวราว 1,600 ดวง และ Edge0-35B-A3B-preview ยังอยู่ในอันดับ 3 ของโมเดลมาแรงบน Hugging Face (1,033 ไลก์) ทีมยังแก้บั๊กอยู่ทุกวัน คอมมิตล่าสุดคือวันที่ 13 ก.ย.

จุดขายที่การ์ดโมเดลเขียนไว้ตัวใหญ่คือ “A 35B-class sparse MoE that runs in phone-class memory” หรือโมเดลคลาส 35B ที่ใช้หน่วยความจำเท่ามือถือ ตัวเลขที่ประกาศคือหน่วยความจำขณะทำงานสูงสุด 2.9 GiB และความเร็ว 14.9–17.7 โทเคน/วินาทีบน Mac mini M4 Pro แรม 24 GB ถ้าเป็นจริงแปลว่าโมเดลที่ปกติต้องใช้แรมกว่า 20 GB รันบน MacBook Air รุ่นเล็กสุดได้ เราไล่อ่านซอร์สโค้ด config และ issue ของผู้ใช้จริงดูว่าตัวเลขเหล่านี้ได้มาอย่างไร และอะไรที่การ์ดไม่ได้บอก

สามกลไกที่ทำให้ 35B ใช้แรม 3 GiB

edge0 ไม่ได้ย่อโมเดลให้เล็กลง สิ่งที่ทำคือไม่โหลดโมเดลทั้งก้อนเข้าแรม ซึ่งอาศัยสามส่วนประกอบกัน

• SSD expert offload — น้ำหนักของ expert ทั้ง 256 ตัวต่อชั้นอยู่บนดิสก์ในรูป mmap และถูกอ่านขึ้นมาเฉพาะตัวที่ router เลือกในแต่ละโทเคน แรมจึงถือแค่ส่วนที่ใช้งานอยู่ (เจ้าของโปรเจกต์ตอบใน issue ว่าแคช LRU ของ expert ตั้งค่าเริ่มต้นไว้ที่ 256 MB)
• Prerouter — หัวทำนายขนาดเล็กที่เทรนมาให้เดาว่าโทเคนถัดไปจะใช้ expert ตัวไหน เพื่อให้โหลดจาก SSD ทับซ้อนกับการคำนวณ ไม่ต้องหยุดรอ การ์ดอ้างว่าเพิ่มความเร็ว decode ได้ สูงสุด +59% และได้ผลมากขึ้นเมื่อสตอเรจช้าหรือโมเดลใหญ่ขึ้น
• Recover-LoRA — ตรึงน้ำหนัก int4 ไว้ แล้วเทรน LoRA ด้วยการกลั่นจากโมเดลต้นฉบับความละเอียดเต็ม เพื่อกู้คุณภาพที่เสียไปตอน quantize อะแดปเตอร์ไม่ถูก merge ลงไป น้ำหนักฐานชุดเดียวจึงใช้กับอะแดปเตอร์หลายชุดได้

ปล่อยมาสองระดับ: edge0-35b บนฐาน Qwen3.5-35B-A3B (ไฟล์ 4 บิตราว 23 GB บนดิสก์) และ edge0-8b บนฐาน Ling 3.0 tiny ของ inclusionAI (ราว 7.9B รวม / 1.2B active, ไฟล์ราว 4.2 GB, ใช้แรม 1.0 GiB, 23.9–25.3 tok/s) ทั้งคู่เปิด API แบบ OpenAI-compatible ผ่าน edge0 serve ตอนนี้รองรับเฉพาะ macOS บน Apple Silicon ผ่าน MLX เท่านั้น

แนวทางนี้ไม่ใช่ของใหม่ บล็อกนี้เคยเขียนถึง TurboFieldfare ที่รัน Gemma 4 26B ด้วย RAM 2 GB และ Deltafin ที่สตรีม Kimi K3 ตัวเต็มจาก SSD สี่ลูก สิ่งที่ edge0 เพิ่มเข้ามาคือ prerouter กับ LoRA ที่เทรนมาเฉพาะ และการแพ็กทุกอย่างให้ดาวน์โหลดครั้งเดียวแล้วรันได้เลย

สิ่งที่การ์ดไม่ได้บอก: runtime ใช้ expert แค่ 4 จาก 8 ตัว

config.json ของ Edge0-35B-A3B-preview ระบุ num_experts_per_tok: 8 ตรงกับ Qwen3.5-35B-A3B ต้นฉบับทุกค่า (40 ชั้น, hidden 2048, 256 expert) แต่ในซอร์สโค้ดของ edge0 ไฟล์ src/edge0/models/edge0_35b/__init__.py เขียนไว้ตั้งแต่บรรทัดแรกว่า “Qwen3.5-MoE (K=4 tier)” และตั้งค่า MoESpec(num_experts=256, top_k=4, ...) กับ prerouter_top_k=4 ตารางในการ์ดโมเดลก็เขียนตรง ๆ ว่า “Experts / active per token: 256 / 4 (K=4)”

แปลว่าตอนรันบน edge0 แต่ละโทเคนผ่าน expert แบบ routed แค่ ครึ่งเดียว ของที่โมเดลถูกเทรนมา ซึ่งอธิบายได้ส่วนหนึ่งว่าทำไมแรมกับ I/O ถึงต่ำขนาดนี้ เพราะต้องดึงจาก SSD น้อยลงครึ่งหนึ่งต่อชั้น แต่ก็หมายความว่าชื่อ “A3B” ไม่ได้สะท้อนสิ่งที่รันจริง ส่วนรุ่น 8B ใช้ K=8 ตรงกับ config ของ Ling 3.0 tiny ไม่ได้ตัด

เรื่องนี้ไม่ได้ผิดในตัวเอง เพราะ LoRA ที่กลั่นจากโมเดลเต็มน่าจะเทรนมาเพื่อชดเชยการตัด K อยู่แล้ว แต่เมื่อการ์ดบอกว่าคุณภาพ “หายไปแค่ 3.9 คะแนนเฉลี่ย” ตัวเลขนั้นคือผลรวมของสามอย่างพร้อมกัน: quantize เป็น int4, ลด K จาก 8 เหลือ 4 และใส่อะแดปเตอร์กลับเข้าไป ไม่ใช่แค่ผลของ quantization

คะแนนฐานที่รันเอง ต่ำกว่าตัวเลขทางการของ Qwen

ตารางคุณภาพในการ์ดเทียบ edge0-35b (int4) กับ “Qwen3.5-MoE 35B-A3B (fp16)” ที่ทีมรันเองด้วย OpenCompass ได้เฉลี่ย 79.2 ต่อ 83.2 แต่ถ้าเอาคอลัมน์ฐานไปเทียบกับการ์ดทางการของ Qwen3.5-35B-A3B จะเห็นว่าฐานที่รันเองได้ต่ำกว่าตัวเลขของ Qwen เองในทุกข้อที่มีให้เทียบ

เบนช์มาร์ก	edge0-35b (int4, K=4)	ฐาน fp16 ที่ edge0 รันเอง	ตัวเลขทางการของ Qwen
MMLU-Pro	81.0	84.6	85.3
GPQA-Diamond	79.8	81.8	84.2
IFBench	57.9	61.7	70.2

การที่แต่ละทีมรันแล้วได้ไม่เท่ากันเป็นเรื่องปกติ เพราะ prompt, ตัวให้คะแนน และงบ reasoning ต่างกัน แต่ถ้าวัดเทียบกับตัวเลขที่คนส่วนใหญ่รู้จักของ Qwen ช่องว่างจะกว้างกว่าที่การ์ดบอกมาก โดยเฉพาะ IFBench (การทำตามคำสั่ง) ที่ห่างถึง 12.3 คะแนน ไม่ใช่ 3.8 ส่วน AIME 2026 และ HumanEval ในตาราง edge0 ไม่มีในการ์ดของ Qwen ให้เทียบ

อีกจุดที่แปลกคือรุ่น 8B ที่ได้ MMLU-Pro 70.1 สูงกว่าฐาน fp16 ของตัวเอง (65.8) ทั้งที่ AIME 2026 ตกจาก 73.3 เหลือ 63.3 ส่วนเล็ก ๆ อีกเรื่องคือช่อง base_model ในการ์ด 35B ชี้ไปที่ Qwen/Qwen3.5-MoE-35B-A3B ซึ่งไม่มีรีโปนี้อยู่จริง (รีโปจริงคือ Qwen/Qwen3.5-35B-A3B) ลิงก์ lineage บน Hugging Face จึงไม่ทำงาน

ผู้ใช้จริงเจออะไรบ้าง

ภายในห้าวัน รีโปมี issue และ PR เข้ามา 25 รายการ ที่น่าอ่านที่สุดคือ

• M1 แรม 8 GB ช้ากว่าที่ประกาศราว 30 เท่า (#17) — ผู้ใช้วัดรุ่น 8B ได้ 0.66–0.81 tok/s เทียบกับ 23–25 tok/s ในการ์ด ขณะที่ Qwen3-4B 4 บิตผ่าน mlx_lm บนเครื่องเดียวกันได้ 11.38 tok/s หน่วยความจำ ~1 GB ตรงตามที่บอก แต่ kernel_task พุ่งไป 20–49% ระหว่างรัน ผู้ดูแลยอมรับว่าบนเครื่องแรมน้อย decode ถูกจำกัดด้วย page fault ไม่ใช่การคำนวณ และแนะนำให้ลอง EDGE0_PREWARM=1 กับ MLX_CACHE_LIMIT_MB=1024 ประเด็นคือตัวเลขในการ์ดวัดบน M4 Pro 24 GB ที่แรมเหลือพอให้ page cache ของ macOS เก็บน้ำหนักไว้ได้เกือบทั้งหมด พอเป็นเครื่องที่ต้องดึงจาก SSD จริงทุกโทเคน ภาพจะเปลี่ยนไปมาก
• MacBook Air M4 16 GB กับ SSD ภายนอกแบบ USB ได้ราว 5 tok/s และเจอบั๊ก 35B ตอบเป็น !!!! ต่อเนื่องทุก request หลังเจน degenerate ครั้งเดียว (#16) ต้นเหตุคือ fp16 overflow ในบางชั้นทำให้ logits เป็น NaN ทั้งหมด แก้แล้วใน PR #12 ด้วยการ clip ค่า hidden (QWEN_HIDDEN_CLIP ค่าเริ่มต้น 1000)
• ชิป A18 Pro (MacBook Neo) ได้ผลลัพธ์เป็นขยะหลายภาษา (#8) เพราะเวอร์ชัน MLX 0.30.4 ที่ pin ไว้มีบั๊ก NAX kernel บนชิปสาย A ตอนนี้ขยับ pin เป็น 0.30.6 แล้ว
• ยังไม่มี CUDA — มีคนพอร์ตรุ่น 8B ขึ้น NVIDIA T4 ผ่าน MLX CUDA ได้ 32 โทเคนใน 82.2 วินาที (#20) ผู้ดูแลตอบว่าเส้นทาง offload ผูกกับ unified memory ของ Mac ต้องออกแบบใหม่แบบ DirectStorage และทีมกำลังเขียนเวอร์ชัน CUDA เอง ส่วนแอป iPhone ผู้ดูแลบอกไว้เมื่อ 10 ก.ย. ว่าจะปล่อย “ภายในไม่กี่วัน” ซึ่งยังไม่มา

การ์ดเองก็เขียนข้อจำกัดไว้ตรง ๆ ว่ารุ่น preview นี้ ยังอ่อนเรื่อง tool use, การวางแผนหลายขั้น และงานเอเจนต์ระยะยาว ส่วน context ยาวจะทำให้ KV cache โตจนเกิน 3 GiB ที่โฆษณา

มุมมอง AI Curator

การสตรีม expert จาก SSD กำลังกลายเป็นหมวดซอฟต์แวร์ของมันเองอย่างรวดเร็ว สามโปรเจกต์ในสองเดือน (TurboFieldfare, Deltafin, edge0) พิสูจน์สิ่งเดียวกันคือโมเดล MoE ที่ active แค่ไม่กี่พันล้านพารามิเตอร์ไม่จำเป็นต้องอยู่ในแรมทั้งก้อน สิ่งที่ edge0 ทำได้ดีกว่ารุ่นก่อนคือความสะดวก เพราะดาวน์โหลดครั้งเดียว ได้ทั้งฐาน, LoRA และ prerouter แล้วเรียก API แบบ OpenAI ได้ทันที นักพัฒนาที่มี Mac Apple Silicon ลองได้ในไม่กี่นาที

แต่ตัวเลขพาดหัวต้องอ่านพร้อมเงื่อนไขสามข้อ ข้อแรก “35B ใน 3 GiB” มาพร้อมการตัด K ครึ่งหนึ่ง ซึ่งการ์ดบอกไว้ในตารางแต่ไม่ได้ขึ้นพาดหัว ข้อสอง “เสียคุณภาพแค่ 3.9 คะแนน” เป็นการเทียบกับฐานที่ทีมรันเอง ซึ่งต่ำกว่าตัวเลขของ Qwen อยู่แล้ว ข้อสาม “15 tok/s” วัดบนเครื่องที่แรม 24 GB และ SSD เร็ว เครื่องที่ต้องการหน่วยความจำ 3 GiB ที่สุดคือเครื่องแรมน้อย ซึ่งกลับเป็นกลุ่มที่ issue #17 แสดงว่าช้าลงเป็นสิบเท่า “phone-class memory” จึงยังไม่ใช่ “phone-class hardware” จนกว่าจะมีคนวัดบนมือถือจริง

สำหรับนักพัฒนาไทย ในห้องเรียนและออฟฟิศยังมี MacBook Air M1/M2 แรม 8–16 GB อยู่มาก ตรงนี้น่าสนใจจริง แต่ให้วัดบนเครื่องของตัวเองก่อนเชื่อตัวเลขในการ์ด และลองรุ่น 8B ก่อน 35B ส่วนงานภาษาไทยขึ้นกับ Qwen3.5 ต้นฉบับ ซึ่งยังไม่มีใครวัดว่าเหลือเท่าไรหลังผ่าน int4 และ K=4 องค์กรที่อยากรันโมเดลในเครื่องเพื่อไม่ต้องส่งข้อมูลส่วนบุคคลออกนอกองค์กรตาม PDPA ควรมองว่านี่คือ preview ที่น่าจับตา ยังไม่ใช่ของสำหรับ production โดยเฉพาะเมื่อการ์ดบอกเองว่างานเอเจนต์ยังอ่อน สิ่งที่ควรรอดูต่อคือเวอร์ชัน CUDA ถ้าออกแบบใหม่ได้จริง เครื่องเล่นเกม GPU 8 GB ที่มีอยู่ทั่วไปจะกลายเป็นเครื่องรันโมเดล 35B ได้

แหล่งข่าว

• Edge0-AI/edge0 — GitHub (README, ตารางเบนช์มาร์ก, ซอร์สโค้ด edge0_35b ที่ตั้ง top_k=4)
• Edge0/Edge0-35B-A3B-preview — Hugging Face (การ์ดโมเดล, config.json, ตารางคุณภาพ)
• Edge0/Edge0-8B-A1B-preview — Hugging Face (รุ่น 8B บนฐาน Ling 3.0 tiny)
• Issue #17: Decode speed ~30x below documented benchmarks on Apple M1 (8GB) — GitHub
• Qwen/Qwen3.5-35B-A3B — Hugging Face (โมเดลฐานและตัวเลขเบนช์มาร์กทางการ)