slotstream: รัน Qwen3.8-Flash-Next 125B (104 GB) บน Mac 48 GB ได้ 12 tok/s — สตรีม expert จาก SSD ทีละสล็อต ไบนารี Swift ตัวเดียว ไม่ต้องมี Python

1 กันยายน 2026 โปรเจกต์ชื่อ slotstream ขึ้นหน้าแรก Hacker News (รายการ 49524447, 130 คะแนน, 82 ความเห็น) ด้วยพาดหัวที่ฟังเหมือนคำโม้: รัน Qwen3.8-Flash-Next โมเดล MoE ขนาด 125B พารามิเตอร์ ที่กินพื้นที่ 104 GB บนดิสก์ที่ 4-bit บน Mac ที่มีแรม 48 GB และได้ความเร็วถอดรหัสราว 12 โทเคนต่อวินาที

ตัวเลขนั้นไม่ได้มาจากการบีบอัดใหม่ ไม่ได้มาจาก quantization ที่ก้าวร้าวกว่าเดิม และไม่ได้มาจากการตัด expert ทิ้ง มันมาจากการยอมรับว่า โมเดล MoE ส่วนใหญ่นอนเฉย ๆ แล้วออกแบบระบบไฟล์-ต่อ-แคชขึ้นมารอบข้อเท็จจริงนั้น สิ่งที่ทำให้โปรเจกต์นี้น่าอ่านกว่าโปรเจกต์ “รันโมเดลใหญ่บนเครื่องเล็ก” ทั่วไปคือ README ของมันบอกเองว่าเลขไหนวัดจริงและเลขไหนเป็นการประมาณ

กายวิภาคของ 104 GB — ทำไมการสตรีมถึงเป็นไปได้

เราเคยลงรายละเอียดสถาปัตยกรรม Qwen3.8-Flash-Next ตอนเปิดน้ำหนักเมื่อ 27 ส.ค. ไว้แล้ว slotstream เอาโครงนั้นมากางเป็นตัวเลขไบต์ตรง ๆ:

ส่วนของโมเดล	ขนาด	พฤติกรรม
dense trunk	3.8 GB	โหลดค้างในหน่วยความจำตลอด
routed experts	68 GB	512 ตัวต่อเลเยอร์ ใช้จริง 10 ตัวต่อโทเคน
ตาราง n-gram	32 GB	อ่านแบบกระจาย

หัวใจอยู่ที่บรรทัดกลาง: ต่อการถอดรหัสหนึ่งโทเคน โมเดลแตะ expert แค่ 10 จาก 512 ตัวในแต่ละเลเยอร์ นั่นแปลว่าถ้าอ่าน expert ที่ต้องใช้จากดิสก์ทันเวลา ก็ไม่จำเป็นต้องมี 68 GB นั้นอยู่ในแรมเลย

slotstream อ่าน expert ด้วย pread เข้าไปใน พูลของ “สล็อต” แคชขนาดคงที่ที่แชร์กันทั้ง 48 เลเยอร์ — ประโยคสำคัญคือคำว่า แชร์ เพราะมันแปลว่าเลเยอร์ที่ร้อนยืมสล็อตจากเลเยอร์ที่เย็นได้ ไม่ต้องแบ่งโควตาตายตัวต่อเลเยอร์ แผนหน่วยความจำที่มันพิมพ์ออกมาบนเครื่อง 48 GB คือ ~152 จาก 512 expert ต่อเลเยอร์ (7,280 สล็อตรวม = พูล 20.1 GB)

คำอธิบายที่ตรงประเด็นที่สุดใน README คือคำตอบของคำถาม “ทำไมไม่ใช้ mmap เอา”:

MLX ไม่สามารถ materialize เพียงบางส่วนของ tensor ที่ mmap ไว้ได้ — การ gather expert top-10 ของเลเยอร์หนึ่งจะประเมิน expert ทั้ง 512 ตัวของเลเยอร์นั้น ทำให้เส้นทาง mmap โหลด ~100 GB แล้วตาย

และเขาบอกผลของทางที่ทำไม่ได้ไว้ด้วย: mlx_lm.load() มาตรฐานพาเครื่อง 48 GB เข้าไปใช้ swap 48 GB โดยไม่ได้โทเคนออกมาสักตัว

ข้อรับประกันที่ควรอ่านคู่กัน — ขนาดแคชเปลี่ยนความเร็ว ไม่เคยเปลี่ยนผลลัพธ์ การถอดรหัสแบบ greedy ให้ผลไบต์ต่อไบต์เหมือนกันระหว่างแคช 4 GB กับ 24 GB และเรื่องนี้ถูกตรึงไว้เป็นเทสต์ถาวร ไม่ใช่คำสัญญาลอย ๆ

ตารางความเร็ว และบรรทัดที่ผู้เขียนเตือนเอง

เครื่องของคุณ	slotstream กินไป	ถอดรหัสอุ่นแล้ว
8 GB	8.1 GB (ขั้นต่ำ)	~3 tok/s — doctor เตือนว่าจะ page
16 GB	10 GB	~4 tok/s
24 GB	16 GB	~8 tok/s
32 GB	22 GB	~9 tok/s
48 GB ขึ้นไป	33 GB	~12 tok/s

จุดที่ทำให้ตารางนี้น่าเชื่อคือประโยคที่ตามมาทันที: มีแค่แถว 48 GB เท่านั้นที่วัดบนฮาร์ดแวร์จริง (M5 Pro 48 GB) แถวที่เหลือเป็นค่าประมาณจากเส้นโค้งของเครื่องนั้น และผู้เขียนเสริมเองว่า Mac เล็กกว่ามักมี SSD ช้ากว่าด้วย — ซึ่งเป็นตัวแปรที่สำคัญเป็นพิเศษกับเอนจินที่อ่านดิสก์ทุกโทเคน

บรรทัดที่ต้องอ่านให้จบก่อนตื่นเต้นคือ prefill ไม่ใช่ decode:

• โทเคนอินพุต 8,000 ตัว รอราว 1 นาที บน Mac 48 GB และ เกิน 3 นาที บนเครื่อง 16 GB
• เพดานคอนเท็กซ์ prompt + completion อยู่ที่ 32,768 โทเคน (--max-context)

พูดตรง ๆ คือ 12 tok/s เป็นเลขของการพิมพ์ตอบ ไม่ใช่เลขของการอ่านโค้ดเบสยาว ๆ เข้าไปครั้งแรก ข้อบรรเทาคือ prefix cache: ในบทสนทนาเดียวกัน เทิร์นถัดไป prefill เฉพาะส่วนใหม่ วัดได้ 6.0 วินาทีในเทิร์นที่แปด เทียบกับ 25.8 วินาที ถ้าคำนวณใหม่ทั้งหมด (ที่เป้าหมาย 16 GB) แลกกับการที่สถานะที่ใช้ซ้ำไม่ได้ตรงบิตต่อบิตกับการคำนวณใหม่ จึงมี --no-prefix-cache ให้ปิดเมื่อต้องการผลลัพธ์ที่ทำซ้ำได้เป๊ะ

ส่วน --mtp (multi-token prediction, ใหม่ใน 0.2.0) เป็นตัวอย่างการรายงานที่ซื่อสัตย์แบบที่หาไม่ค่อยได้: หัว draft ทายถูก 86% (วัดจริง) แต่ตัวเลข ×1.5–1.9 ที่คาดว่าจะเร็วขึ้นนั้น README บอกเองว่าเป็น เลขคำนวณจากอัตรารับ ไม่ใช่ผล A/B ขณะที่เคสแคชเล็ก A/B บอกว่า ×0.96 คือช้าลง — ระบบจึงปิดมันเองต่ำกว่าเป้าหมาย ~26 GB

ของจริงที่ต้องเตรียมก่อนกดติดตั้ง

ดิสก์กัดก่อนแรม ข้อกำหนดคือ Apple Silicon, macOS 14+ และพื้นที่ว่าง ~110 GB ซึ่งทำให้ Mac 512 GB เป็นขั้นต่ำที่สมจริง ไม่ว่าจะมีแรมเท่าไหร่ คำสั่ง slotstream doctor พิมพ์แผนของเครื่องคุณให้ดูก่อนดาวน์โหลดอะไรเลย

การดาวน์โหลดคือ 103.8 GB ใน 24 ไฟล์ ครั้งเดียว และผู้เขียนวัดของจริงไว้ที่ 35 นาที พร้อมข้อสังเกตที่มีประโยชน์กับคนไทยมาก: Hugging Face จำกัดการโอนไว้ราว 36–57 MB/s ไม่ว่าจะเปิดกี่คอนเนกชัน ดังนั้นเกิน ~400 Mbps ไปแล้วคอขวดคือฝั่ง Hugging Face ไม่ใช่เน็ตบ้านคุณ — ที่ 100 Mbps ราว 2 ชั่วโมง 20 นาที, ที่ 25 Mbps ราว 9 ชั่วโมง การขัดจังหวะปลอดภัย pull ทำต่อจากจุดเดิม และทั้ง 24 ไฟล์ถูกตรวจกับ sha256 ที่คอมไพล์ฝังไว้ในไบนารี

ด้านการต่อกับของเดิม: slotstream serve ฟังที่ พอร์ต 11434 และรองรับ subset ของ chat/generate ที่ไคลเอนต์ Ollama กับ OpenAI SDK ใช้ — Open WebUI และ OpenAI SDK ผ่านการทดสอบแล้ว สิ่งที่ยังไม่รองรับ (tools, images, JSON-schema output, logprobs) คืน 400 อย่างชัดเจนแทนที่จะเงียบ ๆ ไม่ทำ ซึ่งเป็นการตัดสินใจที่ถูกต้องสำหรับคนที่จะเอาไปเสียบใต้ agent

ข้อจำกัดที่ประกาศเองในหัวข้อ Status:

• v0 รันได้รุ่นเดียวคือ qwen3.8-flash-next:4bit เอนจินถูกสร้างรอบเรขาคณิตของโมเดลนี้ และหนึ่งโปรเซสต่อผู้ใช้
• macOS 14 และ 15 ทดสอบแค่ตัวติดตั้ง ยังไม่ได้ทดสอบ runtime
• ollama run (0.32) ยังต่อไม่ได้ เพราะเปิดด้วยคำขอ /api/show ที่มีฟิลด์ซึ่ง validator เข้มงวดปฏิเสธ — curl / Open WebUI / OpenAI SDK ใช้ได้

สัญญาอนุญาตของโค้ดคือ MIT แต่ต้องอ่านให้ครบ: น้ำหนักมาจาก pipenetwork/Qwen3.8-Flash-Next-MLX-4bit และยังอยู่ใต้ Qwen community license — เครื่องมือเปิดไม่ได้แปลว่าโมเดลเปิดตามเงื่อนไขเดียวกัน รีโปสร้างเมื่อ 28 ส.ค. 2026 และปล่อย v0.2.0 เมื่อ 1 ก.ย. เวลา 22:38 UTC (ก่อนหน้านั้น v0.1.9 และ v0.1.10 ออกในวันเดียวกันคือ 31 ส.ค.) ตอนเขียนมีดาว 121 ดวง

มุมมอง AI Curator

สิ่งที่ควรเก็บจากโปรเจกต์นี้ไม่ใช่ “12 tok/s” แต่คือ การที่ MoE เปลี่ยนคำถามเรื่องฮาร์ดแวร์จาก “แรมพอไหม” เป็น “SSD ทันไหม” ตลอดสองปีที่ผ่านมา สูตรของคนรันโมเดลในเครื่องคือหาว่าโมเดลใหญ่สุดที่ยัดลงแรมได้คือตัวไหน สถาปัตยกรรม MoE แบบกระจัดกระจายจัด ๆ อย่าง Qwen3.8-Flash-Next (125B แต่กระตุ้น 6B) ทำให้สมการนั้นผิดตั้งแต่ต้น — พารามิเตอร์ที่โมเดลแตะจริงต่อโทเคนน้อยกว่าที่มันมีอยู่หลายสิบเท่า และแบนด์วิดท์ SSD ของ Apple Silicon สมัยใหม่ก็อยู่ในระดับที่ตามทันจังหวะนั้นพอดี slotstream ไม่ได้ประดิษฐ์เทคนิคใหม่ มันแค่เป็นคนแรกที่ยอมเขียนชั้นแคชเองแทนที่จะรอให้ MLX รองรับ ซึ่งเป็นเหตุผลเดียวกับที่ FreeToken เลือกเขียนชั้นเสิร์ฟ MoE เองสำหรับ edge เมื่อ 23 ส.ค.

สำหรับนักพัฒนาไทย ผมคิดว่านี่เป็นข่าวที่ต้องอ่านสองชั้น ชั้นแรกคือชั้นที่ดูดี: ทีมเล็กที่มีข้อจำกัดด้าน data residency — ทำงานกับข้อมูลลูกค้า, เอกสารสัญญา, ข้อมูลสุขภาพ — เพิ่งได้ทางเลือกที่ไม่ต้องจ่ายค่า GPU เดือนละหลายหมื่นเพื่อให้ข้อมูลไม่ออกจากออฟฟิศ MacBook Pro เครื่องเดียวกับที่นักพัฒนาใช้อยู่แล้วรันโมเดลระดับ 125B ได้

ชั้นที่สองคือชั้นที่ต้องคำนวณ: ราคาของทางนี้คือดิสก์ ไม่ใช่แรม และ Mac ที่มี SSD 512 GB ขึ้นไปในไทยยังแพงกว่าที่หลายทีมคิด ประกอบกับ prefill 8,000 โทเคนที่ใช้เวลาเป็นนาที ทำให้ workload ที่เหมาะจริง ๆ แคบกว่าที่พาดหัวชวนคิด — งานที่ prompt สั้นแต่คำตอบยาว (สรุป, แปล, ตอบคำถามสั้น, เขียนดราฟต์) ได้ประโยชน์เต็ม ส่วนงานเอเจนต์ที่ยัดโค้ดเบสหลายหมื่นโทเคนเข้าไปทุกรอบจะเจ็บกับ prefill ก่อนที่จะได้เห็น 12 tok/s ด้วยซ้ำ ทางที่ผมแนะนำคือ รัน slotstream doctor --sim-ram N บนเครื่องที่มีอยู่ก่อนตัดสินใจซื้ออะไร เพราะแถวในตารางที่ไม่ใช่ 48 GB นั้น ผู้เขียนบอกเองว่าเป็นค่าประมาณ และการวัดกับเครื่องจริงของคุณใช้เวลาไม่กี่วินาที

ข้อสุดท้ายที่อยากให้จำ: ความน่าเชื่อถือของโปรเจกต์นี้มาจากการที่มันแยก “วัดแล้ว” ออกจาก “คำนวณเอา” ทุกจุด — รวมถึงไฟล์ MEASUREMENTS.md ที่บันทึก การทดลองที่ล้มเหลว ไว้ด้วย นั่นคือมาตรฐานที่เราควรใช้ตัดสินทุกโปรเจกต์ที่อ้างตัวเลขความเร็วโมเดลในเครื่อง และตรงข้ามกับ README ส่วนใหญ่ที่โชว์แต่เลขบนเครื่องที่ดีที่สุดโดยไม่บอกว่ามันคือเครื่องไหน

แหล่งข่าว

• slotstream — GitHub (carloslfu/slotstream), MIT
• Show HN: Running 104GB Qwen3.8-Flash-Next on 48GB Mac with at ~12 tok/s — Hacker News, 1 ก.ย. 2026
• Qwen/Qwen3.8-Flash-Next — Hugging Face
• pipenetwork/Qwen3.8-Flash-Next-MLX-4bit (น้ำหนักที่ slotstream ใช้) — Hugging Face