WASTE เอนจินรันโมเดลแบบโอเพนซอร์สจากทีม sqliteai เปิดโมเดล Kimi K3 เต็มก้อนให้ทำงานบน MacBook Pro เครื่องเดียวที่มีหน่วยความจำ 64 GB ได้ โมเดลตัวนี้มีพารามิเตอร์ 2.78 ล้านล้านตัว คำถามที่พิมพ์เข้าไปคือเมืองหลวงของอิตาลีอยู่ที่ไหน คำตอบสั้นๆ ว่า Rome ยาว 16 token ใช้เวลา 25.78 วินาที โมเดลนี้ไม่ได้ผ่านการย่อ ไม่ได้ตัดบางส่วนทิ้ง และไม่ได้กลั่นออกมาเป็นรุ่นเล็ก มันคือของที่เผยแพร่จริงทั้งก้อน แค่แปลงรูปแบบไฟล์ใหม่หนึ่งรอบก่อนใช้งาน

ความเร็วไม่ใช่ประเด็น เพราะราวครึ่ง token ต่อวินาทีนั้นช้าเกินกว่าจะนั่งโต้ตอบด้วย สิ่งที่ขยับคือเส้นแบ่งว่าอะไรรันบนเครื่องส่วนตัวได้บ้าง หน้าโปรเจกต์ระบุว่าเท่าที่ทีมค้นดู ยังไม่เจอการสาธิตโมเดลที่มีพารามิเตอร์นับล้านล้านตัว สตรีมน้ำหนักจากดิสก์บนเครื่องผู้ใช้ทั่วไป และย้ำว่านั่นคือผลเท่าที่ค้นเจอ ไม่ใช่การสำรวจอย่างเป็นระบบ ผลรันจริงเป็นแบบนี้

$ waste run ~/models/k3.waste 'What is the capital of Italy?'
waste: no --budget, using 46.24 GB of 64.00 GB (expert cache 17.56 GB)
The capital of Italy is Rome.
[16 tokens, 25.78 s, 0.62 tok/s | experts 9038 hit / 14514 miss = 38%]

แยกของที่ใช้ทุกคำ ออกจากของที่นอนเฉย

ข้างใน Kimi K3 ไม่ใช่ก้อนตัน มันซอยเป็นชิ้นย่อยที่เรียกว่า expert อยู่ 896 ชิ้น กระจายกันใน 92 ชั้น ทุกชั้นมี router คอยชี้ว่าข้อความถัดไปต้องใช้ expert ตัวไหน แต่ละชั้นใช้แค่ 16 ตัวเท่านั้น ที่เหลือนอนเฉยอยู่กับที่ น้ำหนักที่ทำงานจริงต่อการผลิตข้อความหนึ่ง token มีราว 4% ของทั้งโมเดล

ส่วนที่ไม่ถูกเรียกใช้ก็ไปพักอยู่บนดิสก์ได้ WASTE จึงผ่าโมเดลออกเป็นสองส่วน ส่วนแกนที่ใช้ทุกครั้งมีขนาด 27.28 GB วางค้างในหน่วยความจำตลอด ส่วน expert ทั้งหมดนอนอยู่บนดิสก์ แล้วอ่านขึ้นมาเฉพาะตัวที่ router เพิ่งเรียกชื่อ หน่วยความจำที่เหลือกันไว้เป็นแคช คอยเก็บ expert ที่เรียกซ้ำในรอบถัดๆ ไป

คำถามเดิมคือยัดโมเดลทั้งก้อนลงหน่วยความจำได้ไหม พอผ่าเป็นสองส่วน คำถามเปลี่ยนเป็นว่าชิ้นที่ต้องใช้จะมาถึงทันเวลาหรือเปล่า แนวคิดนี้เคยเห็นมาแล้วในสเกลเล็กกว่ามาก อย่าง TurboFieldfare ที่รัน Gemma 4 ขนาด 26B บน MacBook Air หน่วยความจำ 8 GB ที่วางแกนกลางในหน่วยความจำก่อน แล้วค่อยดึงชิ้นส่วนที่คำถัดไปเรียกใช้ออกจาก SSD ทีละคำเหมือนกัน

สิ่งที่ทำให้วิธีนี้ไม่พังคือการจัดวางไฟล์ เมทริกซ์สามก้อนของ expert แต่ละตัววางติดกันในไฟล์ การหยิบ expert หนึ่งตัวเท่ากับการอ่านดิสก์หนึ่งครั้งพอดี ไม่ใช่สามครั้งกระจายกันคนละที่

17 GB ต่อหนึ่ง token คือเหตุผลที่ดิสก์ต้องอยู่ในตัวเครื่อง

สิ่งที่ต้องจ่ายสำหรับวิธีนี้เห็นได้ชัดจากตัวเลข ทุกครั้งที่โมเดลสร้างข้อความหนึ่ง token มันต้องอ่านข้อมูล expert จากดิสก์ราว 17 GB ความเร็วดิสก์กลายเป็นตัวกำหนดความเร็วโมเดลไปโดยปริยาย

บนเครื่องทดสอบ SSD ในตัวเครื่องวัดได้ 12.78 GB/s ก้อน 17 GB ใช้เวลาราว 1.3 วินาที ส่วนกล่อง SSD ภายนอกต่อผ่าน USB วัดได้ 0.94 GB/s ก้อนเดียวกันต้องใช้เวลาราว 13 วินาที คอขวดไม่ได้อยู่ที่ตัว NVMe ในกล่อง แต่อยู่ที่สะพาน USB ที่คั่นอยู่ ข้อสรุปชัดเจนว่าไฟล์โมเดลที่แปลงแล้วต้องนอนอยู่บนดิสก์ NVMe ในตัวเครื่องเท่านั้น ส่วนดิสก์ภายนอกใช้พักไฟล์ตอนดาวน์โหลดได้ แต่เอามารันไม่ได้

ต้องมีอะไรบ้างถึงจะเปิด Kimi K3 ได้

ไฟล์โมเดลต้นทางที่เผยแพร่ไว้มีขนาด 1.42 TB แบ่งเป็น 96 ไฟล์ย่อย ต้องแปลงเป็นไฟล์รูปแบบคอนเทนเนอร์ของ WASTE เสียหนึ่งรอบก่อน แล้วจะได้ของขนาด 982 GB ออกมา เท่ากับต้องเตรียมพื้นที่ราวหนึ่งเทราไบต์ไว้เก็บของที่แปลงเสร็จ บวกอีก 1.42 TB สำหรับพักไฟล์ต้นทางระหว่างทาง ลบทิ้งได้หลังแปลงเสร็จ ขั้นตอนแปลงเป็นจุดเดียวที่ต้องใช้ Python ใช้เวลาราว 4.7 ชั่วโมงเมื่อสั่งพร้อมกันสามโปรเซสบนชิป M5 Pro

tools/fetch_weights.sh --dest /Volumes/staging/k3 --dry-run
tools/fetch_weights.sh --dest /Volumes/staging/k3
uv run --with torch --with safetensors python tools/convert.py \
  --src /Volumes/staging/k3 \
  --out ~/models/k3.waste --jobs 3

ส่วนหน่วยความจำมีสองตัวเลขที่ไม่เท่ากันและต้องแยกให้ออก ตัวแรกคือขั้นต่ำที่เอนจินยอมเปิดโมเดลให้ อยู่ที่ 29.05 GB เมื่อตั้งความยาวบริบทไว้ที่ 4K ความยาวบริบทคือปริมาณข้อความที่โมเดลถือไว้ได้ในหนึ่งรอบสนทนา ตัวเลขนี้เกือบทั้งหมดคือส่วนแกน 27.28 GB ที่ต้องค้างในหน่วยความจำ ตัวที่สองคือปริมาณหน่วยความจำที่ทำให้ใช้งานไหว คือ 64 GB เท่าเครื่องทดสอบ เครื่อง 32 GB เปิดโมเดลขึ้นได้ในทางเทคนิค แต่จะเข้าสู่อาการสลับข้อมูลลงดิสก์จนอืด และยิ่งตั้งบริบทยาวก็ยิ่งกินเพิ่ม ที่ 128K ต้องการ 35.63 GB ส่วนที่ 1 ล้าน token ต้องการ 83.21 GB

ความเร็วที่วัดได้จริงบนเครื่องนี้อยู่ที่ 0.45 ถึง 0.62 token ต่อวินาที ในหน้าโปรเจกต์บอกไว้ด้วยว่าคอนเทนเนอร์ที่แปลงเสร็จแล้วกำลังจะทยอยขึ้นไปวางที่ huggingface.co/sqliteai แต่ระบุไว้เองว่ายังไม่ได้ขึ้น คนที่อยากลองวันนี้ต้องโหลดไฟล์ต้นทางจาก moonshotai/Kimi-K3 มาแปลงเอง

ให้ RAM เพิ่ม แล้วมันกลับช้าลง

ถ้าไม่สั่งอะไรเลย เอนจินจะเลือกงบหน่วยความจำให้ตัวเองที่ 46.24 GB จาก 64 GB แบ่งเป็นแคช expert 17.56 GB แล้วพิมพ์บอกออกมาว่าเลือกเท่าไร ค่าตั้งต้นนี้ไม่ได้กินหน่วยความจำจนหมดเครื่อง และการฝืนให้มันกินมากกว่านี้ก็ได้ผลตรงข้าม

คอลัมน์อัตราเจอในแคชไต่ขึ้นเรื่อยๆ แต่คอลัมน์ความเร็วดิ่งลง ที่ 58 GB แคชจ่าย expert ให้ได้ถึง 39% แต่ช้ากว่าตอน 46 GB อยู่ยี่สิบเท่า เหตุผลคือเอนจินยังอยู่ในงบของตัวเอง แต่เครื่องทั้งเครื่องไม่ไหวแล้ว ระบบปฏิบัติการเริ่มบีบอัดและย้ายหน่วยความจำลงดิสก์ ของที่เอนจินนับว่าอยู่ในแคชต้องรอระบบดึงกลับขึ้นมาก่อนใช้ กลายเป็นการรอที่เอนจินมองไม่เห็นและจัดคิวให้ไม่ได้

หน้าต่างที่ใช้งานได้แคบกว่าที่คิด มันเปิดที่ราว 46 GB เป็นจุดที่แคชใหญ่พอจะเก็บของครบหนึ่ง token และปิดไปแล้วตั้งแต่ 52 GB บทเรียนที่โปรเจกต์สรุปไว้เป็นเรื่องของมารยาทมากกว่าขนาด คือเอนจินควรหยุดขอหน่วยความจำก่อนระบบปฏิบัติการจะเริ่มยึดคืน เพราะแคชที่เราคุมไม่ได้ ก็ไม่นับเป็นแคชอีกต่อไป

ทางที่ลองได้จริงวันนี้คือ Kimi-Linear 48B

เอนจินตัวเดียวกันและรูปแบบไฟล์เดียวกันนี้ รันโมเดลที่เล็กกว่าอย่าง Kimi-Linear-48B-A3B-Instruct ได้จากคอนเทนเนอร์ขนาด 19 GB หน่วยความจำขั้นต่ำเหลือ 1.87 GB และความเร็วขึ้นมาอยู่ที่ 10.7 token ต่อวินาทีเมื่อให้งบ 8 GB แคชเจอของที่ต้องใช้ 78% ทางนี้เปิดได้โดยไม่ต้องหาดิสก์ขนาดเป็นเทราไบต์ และไม่ต้องมีเครื่อง 64 GB

ตัวเลขความเร็วของรุ่นนี้สองแหล่งรายงานไว้ไม่ตรงกันเสียทีเดียว คือ 10.7 token ต่อวินาที กับราว 8.9 บนเครื่องเดียวกัน ห่างกันไม่มาก แต่ควรอ่านเป็นช่วงมากกว่าตัวเลขเป๊ะ ส่วนการเริ่มต้นคือดึงโค้ดมาแล้วสั่งคอมไพล์ ไม่มีขั้นตอนตั้งค่า และไม่ต้องไล่ติดตั้งไลบรารีเพิ่ม

git clone https://github.com/sqliteai/waste && cd waste
make
make check

make check ไม่ต้องใช้ไฟล์โมเดลใดๆ มันสร้างคอนเทนเนอร์จำลองก้อนเล็กขึ้นมาแล้วรันเอนจินใส่ โค้ดที่เพิ่งดึงมาใหม่จะได้ผลเป็นผ่าน 23 ข้าม 11 เพราะสิบเอ็ดข้อที่ข้ามไปนั้นต้องใช้ของที่ไม่ได้ติดมากับโค้ด เช่นไฟล์โมเดลจริงและตัวอ้างอิงฝั่ง PyTorch ตัวเอนจินเขียนด้วยภาษา C ไม่พึ่งไลบรารีภายนอกตอนรัน ไม่ใช้ CUDA และไม่มี Python มาเกี่ยวข้องในจังหวะตอบคำถาม เปิดให้ใช้ภายใต้สัญญาอนุญาต Apache 2.0

คำตอบที่เกิดขึ้นบนเครื่องที่เราถืออยู่

เหตุผลที่คนทำงานควรตามเรื่องนี้ไม่ได้อยู่ที่จำนวนพารามิเตอร์ แต่อยู่ที่เงื่อนไขสามข้อที่เปลี่ยนพร้อมกันเมื่อคำตอบเกิดขึ้นในเครื่องตัวเอง คือไม่มีบิลที่คิดตามจำนวน token ไม่ต้องลุ้นว่าเน็ตจะมาหรือบริการปลายทางจะล่ม และข้อมูลที่ป้อนเข้าไปไม่ได้เดินทางออกไปไหน สำหรับองค์กรที่ติดกฎว่าข้อมูลชุดนี้ห้ามหลุดออกนอกบริษัท เส้นแบ่งอยู่ตรงนั้นพอดี คือระหว่างงานที่ทำไม่ได้เลย กับงานที่ช้าหน่อยแต่ทำได้

ในทางกลับกัน Kimi K3 ที่ความเร็วระดับนี้ยังเป็นผลทางเทคนิคมากกว่าเครื่องมือทำงาน คนที่หวังจะใช้จริงในวันนี้ควรมองที่รุ่น 48B ส่วนก้อน 2.78 ล้านล้านพารามิเตอร์เก็บไว้ดูว่าวิธีนี้ยืดไปได้ไกลแค่ไหน

สิ่งที่สร้างเสร็จแล้วถอดออก

สิ่งที่ทำให้ตัวเลขทั้งหมดข้างบนน่าเชื่อ ไม่ใช่เพราะตัวเลขมันดูดี แต่เพราะโปรเจกต์บันทึกของที่ไม่เวิร์คเอาไว้ด้วย ทุกชั้นของโมเดลผ่านการตรวจเทียบกับผลจาก PyTorch ที่ใช้เป็นตัวอ้างอิง ค่าที่ออกมาต่างกันในระดับ 3.6e-06 ส่วนตัวประมวลผลภาพต่างจากตัวอ้างอิงของมันเองที่ 2.3e-06

ของที่ลองแล้วถอดออกมีหลายชิ้น การบีบส่วนแกนจาก 4 บิตเหลือ 3 บิตปล่อยหน่วยความจำคืนมาได้เกินหกกิกะไบต์ และทำให้แคชเจอของบ่อยขึ้นจริง แต่คุณภาพคำตอบพัง เพราะโมเดลฝึกมาให้ทนการบีบเฉพาะฝั่ง expert ไม่ได้ฝึกส่วนแกนมาด้วย อีกชิ้นคือการจัดดัชนี expert แบบใหม่ วัดในสนามทดสอบเล็กๆ แล้วเร็วขึ้น 1.44 เท่า พอแปลงโมเดลจริงขนาด 19 GB มาลองทั้งระบบกลับไม่เร็วขึ้นอย่างมีนัย ตัวประมาณการความเร็วรอบแรกก็ผิด คาดไว้ที่ 1 ถึง 1.5 token ต่อวินาที ของจริงออกมาราว 0.3 และคำทำนายที่ผิดนั้นยังเก็บไว้ในโปรเจกต์พร้อมคำอธิบายว่าพลาดตรงไหน

ฝั่งการ์ดจอก็ได้คำตอบที่คนน่าจะเดาผิด ทีมทำระบบประมวลผลฝั่ง Metal ขึ้นมาและตรวจแล้วว่าให้ผลถูกต้อง แต่มันช้ากว่าการรันบน CPU อยู่ 22% เลยติดมาด้วยแต่ปิดไว้เป็นค่าตั้งต้น เพราะงานของ WASTE คือการคูณเมทริกซ์กับเวกเตอร์ก้อนเล็กๆ จำนวนมากที่ต้องรอผลกันเป็นทอด ไม่ใช่งานที่ GPU ถนัด ผลนี้เป็นเรื่องเฉพาะของงานลักษณะนี้ ไม่ใช่ข้อสรุปว่า GPU บนเครื่อง Mac สู้ CPU ไม่ได้ อย่าง BaseRT ที่เขียนให้คุยกับ Metal ตรงๆ ก็รายงานว่าโมเดลเดิมบนเครื่องเดิมทำงานได้เร็วขึ้น

กฎข้อนี้ไม่ได้มาจากอุดมคติ แต่มาจากราคาความผิดพลาดในโปรเจกต์นี้ที่แพงผิดปกติ การเดาผิดครั้งเดียวอาจแปลว่าต้องโหลดไฟล์ 1.42 TB ใหม่ หรือแปลงคอนเทนเนอร์เกือบหนึ่งเทราไบต์ใหม่ทั้งรอบ กระทั่งเรื่องดิสก์ภายนอกก็มาจากการวัดก่อนลงมือ ทีมตั้งใจจะรันจากกล่องภายนอกมาตั้งแต่แรก แต่พอเขียนชุดทดสอบที่เลียนแบบรูปแบบการอ่านจริงของเอนจิน แทนการวัดแบบไล่อ่านไฟล์ยาวๆ ตัวเลข 0.94 GB/s ก็โผล่มาเปลี่ยนแผนตั้งแต่ยังไม่ได้โหลดโมเดล

ชื่อ WASTE มาก่อนตัวย่อ ตอนแรกมันหมายถึงกำลังประมวลผล หน่วยความจำ และพื้นที่เก็บข้อมูลบนเครื่องที่คนมีอยู่แล้ว แต่ปล่อยว่างไว้ เพราะงานคิดคำตอบไปเกิดขึ้นที่อื่นหมด ส่วนคำเต็มอย่าง Weight-Aware Streaming Tensor Engine เพิ่งเลือกมาสวมทีหลัง

ครึ่ง token ต่อวินาทีอาจฟังดูไม่เข้าท่า แต่ของที่เหลือจากนี้เป็นงานปรับจูน ไม่ใช่งานพิสูจน์ว่าเป็นไปได้

ที่มา:

• โปรเจกต์ sqliteai/waste บน GitHub
• บทความ The WASTE inference engine จาก Marco Bambini