ผมสามารถรันโมเดลภาษาขนาด 284 พันล้านพารามิเตอร์บนแล็ปท็อปที่มี RAM เพียง 3.2 GB ได้ โดยใช้เพียงแค่ภาษา C99 และไดรฟ์ NVMe เท่านั้น เคล็ดลับคือการสตรีมน้ำหนักของ expert แทนที่จะโหลด checkpoint ขนาด 160 GB ทั้งหมดลงในหน่วยความจำ ซึ่งพิสูจน์ให้เห็นว่าแม้แต่โมเดล mixture-of-experts (MoE) ที่ใหญ่ที่สุดก็สามารถบีบอัดลงบนฮาร์ดแวร์ระดับผู้บริโภคได้

ทำไมเรื่องนี้ถึงสำคัญ

โมเดลภาษาขนาดใหญ่ (LLMs) เป็นขุมพลังในการสร้างโค้ด การช่วยงานวิจัย และอื่นๆ แต่ขนาดของมันมักจะบังคับให้ผู้ใช้ต้องไปใช้เซิร์ฟเวอร์ที่มี GPU หลายตัวซึ่งมีราคาแพง หรือต้องใช้การทำ quantisation อย่างหนักซึ่งส่งผลเสียต่อคุณภาพ การแสดงให้เห็นว่าโมเดล MoE ขนาด 284 พันล้านพารามิเตอร์สามารถรันได้ด้วย RAM เพียงไม่กี่กิกะไบต์ ช่วยเปิดประตูให้เหล่านักอดิเรก สตาร์ทอัพขนาดเล็ก และนักวิจัยที่มีงบประมาณจำกัด สามารถทดลองกับโมเดลระดับ state-of-the-art ได้โดยไม่ต้องสูญเสียความแม่นยำ

โมเดลและคอขวดทางฮาร์ดแวร์

DeepSeek-V4-Flash เก็บพารามิเตอร์ 284 พันล้านตัว กระจายอยู่ใน 256 experts ต่อหนึ่ง transformer layer โดย checkpoint ดิบนั้นใช้พื้นที่บนดิสก์ประมาณ 160 GB ซึ่งเป็นขนาดที่ใหญ่กว่า RAM 3.2 GB ในแล็ปท็อปทั่วไปอย่างมหาศาล โดยปกติแล้ว pipeline การทำ inference จะพยายามแมป checkpoint ทั้งหมดลงในหน่วยความจำ ซึ่งจะทำให้ RAM เต็มอย่างรวดเร็วและเกิดการ crash

การสตรีมน้ำหนักของ expert: แนวคิดหลัก

สถาปัตยกรรม MoE จะเปิดใช้งาน expert เพียงกลุ่มเล็กๆ เท่านั้นสำหรับแต่ละ token ใน DeepSeek-V4-Flash ตัว router จะเลือก 6 experts จาก 256 ตัวต่อหนึ่ง layer เนื่องจากกระบวนการคำนวณไม่ได้แตะต้อง expert ที่ไม่ได้ใช้งาน inference engine จึงสามารถข้ามการโหลดพวกมันได้

การนำไปใช้งานจริงจะมองว่า checkpoint เป็นแหล่งข้อมูลแบบสตรีมมิ่ง เมื่อ router ตัดสินใจว่าต้องใช้ expert ตัวไหนสำหรับ token ปัจจุบัน engine จะดึง weight blocks เหล่านั้นจากไดรฟ์ NVMe เข้าสู่ LRU (least-recently-used) cache ที่อยู่ใน RAM หาก cache มีขนาดใหญ่พอ expert ตัวเดิมจะถูกนำกลับมาใช้ใหม่ใน token ที่ต่อเนื่องกัน ทำให้เกิด cache hits แต่หาก cache เล็กเกินไป engine ก็จะต้องอ่านจากดิสก์บ่อยขึ้น ผลลัพธ์ที่ได้คือการใช้หน่วยความจำสูงสุด (peak memory footprint) อยู่ที่ 3.23 GB ซึ่งอยู่ในขีดจำกัดของแล็ปท็อป ในขณะที่ยังคงรักษาน้ำหนักแบบ full-precision ไว้ได้และไม่จำเป็นต้องใช้การเร่งความเร็วด้วย GPU

บทเรียนอันล้ำค่าจากการลงมือทำจริง

1. ผลลัพธ์ที่อ่านลื่นไหลไม่ใช่ข้อพิสูจน์ว่าถูกต้อง kernel ที่มีบั๊กยังคงสามารถสร้างประโยคที่ดูสมเหตุสมผลได้ โดยเฉพาะอย่างยิ่งเมื่อรูปแบบภาษาของโมเดลช่วยปกปิดข้อผิดพลาดทางตัวเลข ผมได้ตรวจสอบการทำงานที่สำคัญทั้ง 14 รายการเทียบกับ PyTorch reference ที่เตรียมไว้ เพื่อเช็คว่าความแตกต่างทางตัวเลขยังอยู่ในค่าความคลาดเคลื่อน (tolerance) ที่น้อยมาก หากข้ามขั้นตอนนี้ไป ความคลาดเคลื่อนเพียงเล็กน้อยอาจหลุดรอดสายตาไปได้

2. รูปแบบความล้มเหลวที่เหมือนกันอาจหลอกการทดสอบของคุณได้ บั๊กการคอร์รัปชันของหน่วยความจำ (memory-corruption bug) ทำให้ตัวเลือกการ routing ตกไปอยู่ที่ expert เพียงไม่กี่ตัว ส่งผลให้อัตรา cache-hit พุ่งจาก 52% เป็น 95% และสร้างภาพลวงตาว่าความเร็วเพิ่มขึ้นอย่างมหาศาล เนื่องจากชุดทดสอบเปรียบเทียบโค้ดที่มีบั๊กเหมือนกันสองเวอร์ชัน มันจึงตรวจไม่พบปัญหา วิธีแก้คือการเพิ่ม independent reference path หรือโค้ดที่ไม่ใช้ตรรกะร่วมกับตัวหลัก เพื่อไม่ให้ข้อผิดพลาดที่เหมือนกันผ่านการทดสอบไปได้

3. วัดผลก่อนที่จะปรับแต่ง (optimise) ผมสมมติว่าการคัดลอกหน่วยความจำ (memory copy) ใช้เวลา 1 ms และเสียเวลาไปกับการปรับแต่งมัน แต่การทำ profiling แสดงให้เห็นว่าการทำงานนั้นใช้เวลาจริงถึง 3.6 ms หรือคิดเป็น 22% ของเวลา inference ทั้งหมด บทเรียนคือ: อย่าเชื่อสัญชาตญาณในส่วนที่สำคัญต่อประสิทธิภาพ การวัดผลที่แม่นยำคือแนวทางที่เชื่อถือได้เพียงอย่างเดียว

4. สภาวะความร้อนส่งผลกระทบต่อ throughput อย่างมหาศาล การรัน benchmark บนแล็ปท็อปที่ "ร้อนจัด" ให้ผลลัพธ์ที่ช้ากว่าเครื่องที่เย็นอยู่ถึงสามเท่า อุณหภูมิที่สูงขึ้นทำให้ throughput ของไดรฟ์ NVMe ลดลงและทำให้ CPU ช้าลง ซึ่งส่งผลให้ผลลัพธ์คลาดเคลื่อน ดังนั้นควรบันทึกสภาวะความร้อนของระบบทุกครั้งที่คุณเผยแพร่ตัวเลขประสิทธิภาพ

ตัวเลขที่ได้เป็นอย่างไร

  • ขนาดโมเดลบนดิสก์: ~160 GB
  • การใช้ RAM สูงสุด: 3.23 GB
  • Experts ต่อ token: 6 (จาก 256)
  • อัตรา cache-hit: แปรผันตาม RAM; สำหรับ 3.2 GB จะมีความผันผวน
  • ไม่มีการทำ quantisation: มีการสตรีมน้ำหนักแบบ full-precision เพื่อรักษาคุณภาพของโมเดล

หากงบประมาณ RAM ลดลงต่ำกว่าประมาณ 3.21 GB ตัว cache จะไม่สามารถเติมเต็มได้ และ engine จะต้องสตรีมข้อมูลในทุกๆ token ซึ่งจะทำให้ประสิทธิภาพลดลงอย่างรวดเร็ว

ซอร์สโค้ดเปิดให้ใช้งานได้ทั่วไปที่ github.com/ronak-create/deepseek-v4-in-c และมีช่องทางพูดคุยในชุมชนที่ t.me/GyaanSetuAi สำหรับใครก็ตามที่ต้องการทำซ้ำหรือต่อยอดการทดลองนี้

บทสรุป

การสตรีมเฉพาะ experts ที่โมเดล MoE ใช้งานจริง ช่วยให้ LLM ขนาด 284 B-parameter สามารถรันบนแล็ปท็อปสเปกทั่วไปได้โดยไม่ต้องทำ quantisation หรือใช้การเร่งความเร็วด้วย GPU การทดลองนี้แสดงให้เห็นว่าการเคลื่อนย้ายข้อมูลอย่างชาญฉลาด การตรวจสอบที่เข้มงวด และการวัดผลอย่างมีระเบียบวินัย สามารถก้าวข้ามข้อจำกัดด้านฮาร์ดแวร์ที่หลายคนเชื่อว่าไม่สามารถเปลี่ยนแปลงได้