WASTE: รัน Kimi K3 ตัวเต็ม 2.78 ล้านล้านพารามิเตอร์บนโน้ตบุ๊ก 64GB ด้วยการสตรีม expert จาก NVMe

ตั้งแต่ Moonshot ปล่อยน้ำหนัก Kimi K3 เมื่อ 27 กรกฎาคม คำถามที่ตามมาทันทีคือ “แล้วใครจะรันมันได้” — โมเดลขนาด 2.78 ล้านล้านพารามิเตอร์ กินพื้นที่ราว 1.42 TiB (≈ 1.56 TB แบบที่ผู้ขายดิสก์นับ) ตามที่เผยแพร่ คำตอบมาตรฐานคือ “เครื่องที่มี RAM ระดับเทราไบต์” ซึ่งแปลว่าไม่ใช่เครื่องของนักพัฒนาทั่วไป

โปรเจกต์ WASTE (Weight-Aware Streaming Tensor Engine) จาก sqliteai เสนอคำตอบอีกแบบ: repo สร้างเมื่อ 28 กรกฎาคม 2026 ขึ้นหน้า Hacker News วันที่ 31 กรกฎาคมด้วยหัวข้อตรงไปตรงมาว่า “Run Kimi K3 using 29 GB of RAM at 0.50 tok/s” และตอนนี้มี 353 ดาว / 33 fork ภายใต้ Apache 2.0 ตัวเลขที่ทีมวัดเองคือ K3 ตัวเต็มรันบน MacBook Pro M5 แรม 64GB ที่ 0.49–0.54 tok/s โดยมี RAM ขั้นต่ำ 29.05 GiB

ย้ำจุดที่ README เน้นตัวหนาไว้เอง: นี่ไม่ใช่รุ่น distilled, pruned หรือย่อส่วน — เป็น K3 ตัวเต็ม

แนวคิด: น้ำหนักที่ไม่ได้ใช้ ไม่จำเป็นต้องอยู่ใน RAM แค่ต้อง “ไปถึงทันเวลา”

หัวใจของเรื่องนี้คือธรรมชาติของ MoE ที่คนพูดถึงกันมานาน แต่ยังไม่ค่อยมีใครเอามาใช้ในฝั่ง memory จริงจัง: K3 activate พารามิเตอร์เพียงราว 4% ของตัวเองต่อหนึ่งโทเคน แปลว่าน้ำหนักเกือบทั้งหมดนิ่งอยู่เฉย ๆ ในทุกจังหวะ

WASTE จึงแบ่งโมเดลเป็นสองส่วน:

• trunk (ส่วนที่ทุกโทเคนต้องใช้) — 27.28 GB อยู่ใน RAM ถาวร นี่คือที่มาเกือบทั้งหมดของ RAM ขั้นต่ำ 29.05 GiB
• experts — อยู่บนดิสก์ ถูกสตรีมเข้ามาเฉพาะตัวที่ router เลือกจริง

รายละเอียดวิศวกรรมที่ทำให้มันเวิร์ก:

• หนึ่ง expert = หนึ่ง pread() เรคคอร์ดถูกจัดวางแบบ align 4 KiB และวางเมทริกซ์ที่ต้องใช้ร่วมกันไว้ติดกัน อ่านทีเดียวจบ ไม่ต้องกระโดด
• บายพาส page cache ด้วยแฟล็กเฉพาะ OS — ไม่ปล่อยให้ระบบปฏิบัติการมาเดาแทน
• quantization experts ใช้ residual vector quantization สามชั้น codebook ละ 256 entry บนเวกเตอร์ 8 มิติ = 3.00 บิตต่อน้ำหนัก ส่วน trunk อยู่ที่ 4–8 บิต ผลคือคอนเทนเนอร์ 982 GiB จาก 1.42 TiB ที่เผยแพร่
• LFRU expert cache ใช้ RAM ที่เหลือทั้งหมดเป็น working set แบบมีขอบเขต

ทีมยังวัดด้วยว่า working set ของหนึ่งโทเคนคือ 17 GB และประสิทธิภาพจะขยับเป็นขั้นตามตัวคูณของตัวเลขนี้ — บนเครื่อง 64GB เอนจินตั้งงบให้ตัวเอง 46 GB โดยเป็น expert cache 17.56 GB ซึ่งเป็นจุดสูงสุดของเส้นโค้งที่วัดได้

ตัวเลขที่ควรอ่านก่อนจะไปลอง

เรื่องนี้ง่ายที่จะเล่าเกินจริง ทีมผู้พัฒนาเองกลับเป็นฝ่ายเบรกไว้ค่อนข้างหนัก และข้อจำกัดเหล่านี้สำคัญกว่าตัวเลข headline:

หัวข้อ	ตัวเลข
Kimi K3 2.78T — คอนเทนเนอร์	982 GiB (ต้องเผื่อดิสก์ ~1 TB)
พื้นที่ staging ตอนแปลงไฟล์	อีก 1.42 TiB (คืนได้หลังเสร็จ)
RAM ขั้นต่ำที่เอนจินยอมเปิด (4K context)	29.05 GiB
RAM ที่ใช้จริงเพื่อได้ตัวเลขนี้	64 GB
ความเร็ว decode	0.49–0.54 tok/s
prefill	0.47 tok/s (แบบ chunked)
vision tower (ภาพ 1024 patch)	15.7 วินาที
Kimi-Linear 48B (ทางเลือกเบา)	คอนเทนเนอร์ 19 GB, RAM 1.87 GB, 10.7 tok/s

ความเร็วดิสก์ไม่ใช่รายละเอียดปลีกย่อย — หนึ่งโทเคนอ่าน expert รวม 17 GB บน SSD ภายในเครื่องได้ 12.78 GB/s แล้วโมเดลไหลลื่น แต่ผ่านกล่อง USB ภายนอกเหลือ 0.94 GB/s และโทเคนเดียวกันใช้เวลา สิบสามวินาที README สั่งตรง ๆ ว่าให้แปลงลง NVMe ภายในเครื่องเท่านั้น ใช้ดิสก์นอกแค่ตอนดาวน์โหลด

และหน้าต่าง RAM ก็แคบกว่าที่คิด: ที่ 46 GB ได้ 0.32 tok/s แต่พอขยับเป็น 52 GB กลับ ตกลงเหลือ 0.11–0.14 tok/s เพราะ OS เริ่ม page เอง ทีมบอกชัดว่าเครื่อง 32 GB “เปิดได้ทางเทคนิค แต่จะ page อย่างหนัก” ให้ถือว่า 64 GB คือความต้องการจริง

ข้อควรระวังอื่นที่ทีมประกาศเอง: trunk ไม่มี checksum เลย (การตรวจสอบมีเฉพาะ expert ผ่านแฟล็ก --verify), API ยังไม่ freeze, per-expert bit allocation และ MSVC ยังไม่ทำ, ส่วน Windows เป็น cross-compile ที่ทดสอบน้อยมาก และ AVX-512 มีโค้ดแต่ยังไม่เคยถูกรันจริง

ฝั่งความถูกต้องกลับแน่นกว่าที่คาด: ทุกเลเยอร์ถูก validate เทียบกับ reference บน PyTorch, logits สุดท้ายตรงกันที่ระดับ 3.6e-06 และ vision tower ตรงกับ oracle ของตัวเองที่ 2.3e-06

สิ่งที่น่าสนใจกว่าความเร็ว คือสิ่งที่ทีมเลือกจะไม่ทำ

เอกสาร docs/EFFICIENCY.md เล่าว่าทีมลองสามทางแล้วผ่านแค่ทางเดียว — การ overlap การอ่าน expert เข้ากับการคำนวณได้มา ~1.6 เท่า และถูก ship ส่วนอีกสองทางที่ “ดูน่าจะได้เยอะกว่า” คือการอ่านไบต์น้อยลงต่อโทเคน และการเก็บไว้ใน RAM มากขึ้น ถูกวัดแล้วปฏิเสธทั้งคู่ เพราะ router ของโมเดลตระกูลนี้ไม่มีหางให้ลดความสำคัญ และแคชที่เครื่องไม่ยอมให้อยู่ resident นั้นซื้อไม่ได้ในทุกราคา

แม้ overlap แล้ว การอ่านดิสก์ยังกิน 55% ของหนึ่ง decode step เทียบกับการคำนวณที่ 27% ข้อสรุปของทีมจึงตรงไปตรงมา: สิ่งที่เหลือคือดิสก์ที่เร็วขึ้นหรือเครื่องที่ RAM มากขึ้น ไม่ใช่การไปไล่ปรับ kernel อีกรอบ

ทีมยังเขียนกำกับไว้อย่างซื่อสัตย์ผิดปกติว่า พวกเขา “ไม่ทราบว่ามีการสาธิตอื่นที่โมเดลขนาดนี้สตรีมจากดิสก์บนเครื่องผู้ใช้ทั่วไป” แต่ตามด้วยว่านี่คือ “รายงานว่าการค้นหาของเราเจออะไร ไม่ใช่การสำรวจ” และเชิญให้ส่งตัวอย่างแย้งเข้ามา — พร้อมกับเก็บตัวเลขที่เคยผิดไว้ใน docs/LEARNED.md แทนที่จะแก้เงียบ ๆ

มุมมอง AI Curator

0.5 tok/s ไม่ใช่ความเร็วที่ใครจะเอาไปทำ chatbot หรือ coding agent ได้ ประโยคเดียวใช้เวลาสามสิบวินาที ถ้าวัดกันที่ “ใช้งานได้จริงวันนี้ไหม” คำตอบคือยัง แต่ผมคิดว่านั่นเป็นการวัดผิดเกณฑ์ และทีมผู้พัฒนาเองก็บอกไว้แล้วว่าอย่าอ่านความช้าเป็นคำแก้ตัว

สิ่งที่เปลี่ยนไปจริง ๆ คือ เส้นแบ่งระหว่าง “เป็นไปไม่ได้” กับ “เป็นเรื่องวิศวกรรม” ก่อนหน้านี้การรันโมเดลระดับล้านล้านพารามิเตอร์นอกดาต้าเซ็นเตอร์เป็นคำถามเชิงความเป็นไปได้ ตอนนี้มันกลายเป็นคำถามว่าดิสก์เร็วพอหรือยัง ซึ่งเป็นคำถามที่เวลาตอบให้เองเสมอ — NVMe รุ่นใหม่เร็วขึ้นทุกปี และเมื่อการอ่านดิสก์กิน 55% ของ decode step ทุกเท่าที่ดิสก์เร็วขึ้นจะแปลงเป็นความเร็วเกือบตรง ๆ

สำหรับนักพัฒนาไทย ผมคิดว่านัยที่สำคัญที่สุดไม่ใช่เรื่องราคา แต่เป็นเรื่อง ข้อมูลที่ส่งออกไปไม่ได้ README เขียนประโยคที่ตรงกับปัญหาที่ทีมองค์กรในไทยเจอบ่อยที่สุด: ความต่างระหว่าง “คุณส่งข้อมูลนี้ไป API ไม่ได้” กับ “รันมันตรงนี้เลย” งานที่ติดอยู่ที่ PDPA, สัญญากับลูกค้าองค์กร, หรือนโยบายภายในของธนาคารและโรงพยาบาล — งานพวกนี้ไม่ได้ต้องการ 50 tok/s มันต้องการแค่ “ประมวลผลได้โดยไม่มีอะไรออกจากเครื่อง” และหลายงานเป็น batch ที่รันข้ามคืนได้อยู่แล้ว ที่ 0.5 tok/s เอกสารหนึ่งชุดต่อคืนคือสิ่งที่ทำได้จริงวันนี้

แต่ต้องพูดให้ครบ: ต้นทุนที่แท้จริงของเส้นทางนี้คือ ดิสก์ 1 TB บวก staging อีก 1.42 TiB บวกเครื่อง 64GB ที่มี NVMe ภายใน ซึ่งในไทยแปลว่า MacBook Pro หรือเวิร์กสเตชันที่ประกอบเอง — ไม่ใช่โน้ตบุ๊กที่บริษัทแจก และเส้นทางที่ผมแนะนำให้ลองก่อนจริง ๆ คือ Kimi-Linear 48B ที่คอนเทนเนอร์ 19 GB, RAM 1.87 GB, ได้ 10.7 tok/s — เร็วพอใช้งานจริง และใช้ฟอร์แมตกับเอนจินเดียวกัน ถ้ามันเวิร์กกับงานคุณ ค่อยตัดสินใจว่าจะยอมสละดิสก์หนึ่งเทราไบต์ให้ K3 หรือไม่

สุดท้าย จุดที่ผมชอบที่สุดของโปรเจกต์นี้ไม่ใช่ตัวเลข แต่เป็นวิธีรายงาน — ระบุว่าวัดบน commit ไหน, บันทึกตัวเลขที่เคยผิดไว้แทนที่จะแก้เงียบ ๆ, และบอกเองว่า “เราไม่ได้ทำ survey” แทนที่จะเคลมว่าเป็นที่แรกของโลก ในยุคที่ README ของโปรเจกต์ AI แข่งกันเคลม นี่คือมาตรฐานที่ควรเป็นค่าเริ่มต้น

แหล่งข่าว

• sqliteai/waste — GitHub repository
• docs/EFFICIENCY.md — บันทึกว่าแต่ละทางเลือกถูกวัดและตัดสินอย่างไร
• Hacker News: “Run Kimi K3 using 29 GB of RAM at 0.50 tok/s”
• moonshotai/Kimi-K3 — น้ำหนักต้นทางบน Hugging Face