Swiftlet รัน Qwen 80B บน Mac ด้วย RAM 4.3GB และ 35B บน iPhone — เคล็ดลับคือไม่โหลด expert เข้า RAM เลย แต่ pread จาก SSD ทีละตัว

repo ชื่อ Swiftlet ถูกสร้างขึ้นเมื่อวันที่ 3 สิงหาคม และภายในวันเดียวก็ขึ้นหน้าแรก Hacker News พร้อมคำอ้างที่ฟังดูเป็นไปไม่ได้: รันโมเดล Qwen3-Next-80B-A3B บน Mac ด้วย peak RAM 4.3 GB และรัน Qwen3.6-35B-A3B บน iPhone ด้วย ~2.5 GB

ตอนนี้ repo มี 336 ดาว 9 fork ใบอนุญาต Apache 2.0 — และตัวเลขนั้นไม่ได้มาจากการ quantize อย่างเดียว แต่มาจากการตัดสินใจทางสถาปัตยกรรมว่า จะไม่โหลดโมเดลเข้า RAM ตั้งแต่แรก

ตัวเลขจริง

โมเดล	พื้นที่ดิสก์	Peak RAM	ความเร็ว
Qwen3.6-35B-A3B (4-bit)	18 GB	2.6 GB	7–11 tok/s บน M5 Mac
Qwen3-Next-80B-A3B (4-bit)	42 GB	4.3 GB	4.5–5 tok/s
35B บน iPhone	18 GB	~2.5 GB	~1 tok/s

ต้องการ Apple Silicon Mac หรือ iPhone, macOS 14+ หรือ iOS 17+ และที่สำคัญที่สุดคือ พื้นที่ SSD ว่างตามขนาดเต็มของโมเดล — 42 GB ไม่ได้หายไปไหน มันแค่ย้ายจาก RAM ไปดิสก์

กลไก: dense core อยู่ใน RAM, expert อยู่บนดิสก์

หัวใจอยู่ที่คำว่า A3B ในชื่อโมเดล — ทั้งสองตัวเป็น Mixture-of-Experts ที่ active เพียงราว 3B พารามิเตอร์ต่อโทเคน แม้พารามิเตอร์รวมจะ 35B หรือ 80B ก็ตาม Swiftlet ใช้ประโยชน์จากช่องว่างนี้เต็มที่ด้วยสามชั้นซ้อนกัน:

1. Quantization 4-bit — ลดขนาดตั้งต้น
2. MoE streaming — เก็บเฉพาะ “แกน dense เล็ก ๆ” ไว้ใน RAM ตลอด แล้ว stream น้ำหนัก expert ที่ router เรียกจริงขึ้นมาจาก storage ตามต้องการ
3. Expert caching — cache expert ที่ร้อนไว้ใน pool ขนาดจำกัด ไล่ออกด้วย LFU บวกความสดของการใช้งาน

รายละเอียดวิศวกรรมที่ทำให้ข้อ 2 เร็วพอใช้งานได้จริงคือการ แพ็ก expert ลงดิสก์ที่ stride คงที่ ผลคือ “หนึ่ง expert คือหนึ่ง pread จาก SSD พอดี” — ไม่ต้อง seek ไม่ต้องแกะ index ไม่ต้อง parse อะไรทั้งนั้น หนึ่ง syscall ได้น้ำหนักที่ต้องการมาเลย นี่คือเหตุผลว่าทำไม 4.5 tok/s ถึงเป็นไปได้บนสิ่งที่ปกติจะช้าจนใช้งานไม่ได้

อีกชิ้นที่ช่วยมากคือสถาปัตยกรรมของ Qwen3-Next เอง — 75% ของ layer ใช้ Gated DeltaNet linear attention ที่มี recurrent state ขนาดคงที่ จึงไม่มี KV cache ที่โตขึ้นเรื่อย ๆ ถ้าเป็น transformer attention เต็มรูปแบบ KV cache อย่างเดียวก็กินเกิน 4.3 GB ไปแล้วตั้งแต่บริบทไม่กี่พันโทเคน ตัวเลข peak RAM นี้จึงไม่ได้เป็นผลงานของ Swiftlet ล้วน ๆ แต่เป็นผลของการเลือกโมเดลที่เข้ากับเทคนิคนี้พอดี

ฝั่ง Metal ใช้ shader ที่คอมไพล์ตอน runtime จึงไม่ต้องมี Metal toolchain ตอน build

ใช้งานได้สี่ทาง

• Swift package (SwiftletCore) สำหรับฝังในแอป
• CLI: swiftlet (chat/generate) และ swiftlet-repack
• เซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI API (swiftlet-server) — เสียบแทน endpoint เดิมได้
• แอป iOS สำเร็จรูปชื่อ Priv AI บน App Store

ผู้เขียนระบุตรง ๆ ว่า Swiftlet สร้างด้วย Claude Code

ข้อจำกัดที่ผู้เขียนพูดเอง

README ระบุข้อแลกเปลี่ยนไว้ชัดและตรงไปตรงมา: เพราะ active แค่ ~3B ต่อโทเคน โมเดลเหล่านี้ “คุยและเขียนเหมือนโมเดลใหญ่ แต่จำข้อเท็จจริงได้เหมือนโมเดลเล็ก”

ประโยคนี้สำคัญกว่าที่เห็น — MoE ให้คุณภาพการใช้ภาษาและการให้เหตุผลระดับโมเดลใหญ่ เพราะ router เลือก expert ที่เหมาะกับงานได้ แต่ความรู้เชิงข้อเท็จจริงกระจายอยู่ทั่วพารามิเตอร์ 80B ที่คุณไม่ได้เรียกใช้พร้อมกัน อย่าคาดหวังว่ามันจะตอบคำถามความรู้รอบตัวได้เท่าโมเดล dense 70B และ ~1 tok/s บน iPhone คือความเร็วระดับ “อ่านทันทุกตัวอักษรที่มันพิมพ์” ซึ่งเหมาะกับงาน batch หรือ demo มากกว่าการสนทนาจริง

มุมมอง AI Curator

สิ่งที่ Swiftlet พิสูจน์ไม่ใช่ “iPhone รันโมเดล 35B ได้” แต่คือ นิยามของ ‘โมเดลนี้ใหญ่เกินเครื่องฉัน’ กำลังเปลี่ยนจากคำถามเรื่อง RAM ไปเป็นคำถามเรื่องแบนด์วิดท์ดิสก์

ตลอดสองปีที่ผ่านมา สูตรคิดของคนรันโมเดลในเครื่องคือ “พารามิเตอร์ × บิตต่อพารามิเตอร์ ต้องน้อยกว่า RAM” ใครมี Mac 16GB ก็จบที่โมเดล ~13B ที่ 4-bit Swiftlet ฉีกสูตรนี้ด้วยการชี้ว่าถ้าโมเดลเป็น MoE ที่ sparse จริง สิ่งที่ต้องอยู่ใน RAM คือแค่ส่วนที่ทำงานทุกโทเคน ที่เหลือเป็นปัญหา I/O — และ SSD ของ Apple Silicon เร็วพอจะรับได้ ผลคือเครื่องราคาเท่าเดิมขยับจาก 13B ไป 80B โดยไม่ต้องซื้ออะไรเพิ่มนอกจากพื้นที่ว่าง

สำหรับตลาดไทยและ SEA นี่มีนัยที่ตรงกว่าที่หลายคนคิด ราคา RAM คือส่วนที่แพงที่สุดของ Mac และเป็นตัวที่อัปเกรดทีหลังไม่ได้ ส่วนต่างระหว่าง MacBook 16GB กับ 64GB คือหลายหมื่นบาท ขณะที่ SSD ภายนอกความจุ 1TB ราคาไม่กี่พัน ถ้าเทคนิคนี้ทำซ้ำได้จริงในวงกว้าง มันเปลี่ยนสมการการซื้อเครื่องสำหรับนักพัฒนาที่อยากรัน LLM ในเครื่อง — และเปลี่ยนคำแนะนำที่เราให้กันมาตลอดว่า “ซื้อ RAM ให้เยอะที่สุดเท่าที่จ่ายไหว”

แต่ให้เก็บความคาดหวังไว้ในกรอบ นี่คือ repo อายุสองวันจากนักพัฒนาคนเดียว ที่รองรับสองโมเดลและแพลตฟอร์มเดียว ยังไม่มีใครทำ benchmark คุณภาพอิสระ และตัวเลข tok/s ทั้งหมดมาจากผู้เขียนเอง เทคนิคที่เขาใช้ก็ไม่ใช่ของใหม่ในเชิงแนวคิด — llama.cpp มี MoE offload มานานแล้ว สิ่งที่ใหม่คือการออกแบบ layout บนดิสก์ให้ลงตัวกับ pread เดียวและจับคู่กับโมเดลที่ไม่มี KV cache โต ซึ่งเป็นงานวิศวกรรมที่พอดีตัวมาก และนั่นก็แปลว่าอาจย้ายไปใช้กับโมเดลอื่นได้ยากกว่าที่หัวข้อข่าวทำให้รู้สึก

จุดที่ควรจับตาคือถ้ารูปแบบ “dense core ใน RAM + expert บนดิสก์” นี้ถูกดูดเข้า llama.cpp หรือ MLX เมื่อไหร่ ตอนนั้นคำถามว่าเครื่องคุณรันอะไรได้จะเปลี่ยนไปทั้งวงการ ไม่ใช่แค่บน Apple

แหล่งข่าว

• leonickson1/Swiftlet — GitHub (Apache 2.0)
• Show HN: Run an 80B Qwen in 4.3 GB of RAM on a Mac, and a 35B on an iPhone (3 ส.ค. 2026)
• Qwen3-Next-80B-A3B — Hugging Face