เอนจิน kimi-k3-in-c รันโมเดล Kimi K3 ของ Moonshot AI จนพิมพ์คำตอบออกมาได้บนซีพียูตัวเดียว ไม่มีการ์ดจอ และวัดแรมสูงสุดตลอดการรันได้ 8.24 กิกะไบต์

โมเดลนี้เก็บค่าตัวเลขที่ใช้คำนวณคำตอบไว้ 2.78 ล้านล้านค่า ค่าพวกนี้เรียกว่าพารามิเตอร์ ไฟล์ที่ต้องโหลดมาเก็บไว้กินพื้นที่ 1.56 เทระไบต์ และถ้ากางทุกค่าไว้ในแรมพร้อมกันแบบทั่วไป ต้องเตรียมแรมราว 5,560 กิกะไบต์

ไฟล์เอนจินมีขนาดเพียง 176 กิโลไบต์ เป็นโค้ดภาษา C ล้วน และไม่ต้องพึ่งชุดคำนวณสำเร็จรูปจากภายนอก ทั้งหมดนี้เป็นงานของ Fareed Khan ที่เปิดซอร์สโค้ดไว้ทั้งชุดบน GitHub

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

kimi-k3-in-c รันแล้วได้อะไร

เอกสารของโปรเจกต์เก็บทั้งคำสั่งและผลการรันจริง พรีเซ็ตเล็กสุดชื่อ laptop เป็นชุดตั้งค่าที่กินแรมน้อยที่สุด โทเคนคือข้อความชิ้นเล็กๆ ที่โมเดลสร้างทีละชิ้น คำสั่งที่ใช้คือป้อนประโยค "The capital of France is" เข้าไป แล้วให้โมเดลเขียนต่ออีก 8 โทเคน

$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
  --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental

--- generated text ---
Paris.",
+ "The Eiffel
----------------------
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB

คำแรกคือ Paris ซึ่งตอบถูก ส่วน "The Eiffel" ที่ตามมาไม่ใช่อาการเพี้ยน Kimi K3 ที่รันตรงนี้เป็นรุ่นพื้นฐานที่ยังไม่ได้ฝึกให้ตอบแบบแชต มันจึงเขียนต่อจากข้อความที่เห็น เหมือนอ่านรายการประโยคเกี่ยวกับฝรั่งเศสแล้วเขียนบรรทัดถัดไป

แต่ต้องพูดตรงๆ ว่าช้ามาก 8 โทเคนใช้เวลา 261.5 วินาที เฉลี่ย 32.69 วินาทีต่อโทเคน ต้องรอครึ่งนาทีกว่าจะได้ข้อความหนึ่งชิ้น เอกสารต้นทางบอกตั้งแต่แรกว่าความเร็วไม่ใช่เป้าหมายของงานนี้

ส่วนโปรเจกต์นี้เปิดเมื่อต้นเดือนสิงหาคม 2026 ใช้สัญญาอนุญาต Apache 2.0 และได้ดาวราวสองพันสามร้อยดวงในไม่กี่วัน

Kimi K3 ใช้ผู้เชี่ยวชาญ 16 จาก 896 ตัวต่อโทเคน

Kimi K3 ไม่ได้ใช้ทุกส่วนพร้อมกัน ในแต่ละชั้น ค่าพารามิเตอร์ที่เรียกว่าน้ำหนักจะแบ่งเป็นกลุ่มย่อย 896 กลุ่ม ระบบจะเลือกใช้เพียง 16 กลุ่มต่อหนึ่งโทเคน กลุ่มย่อยเหล่านี้เรียกว่าผู้เชี่ยวชาญ ส่วนโครงสร้างแบบนี้มีชื่อเรียกว่า mixture of experts

โมเดลทั้งตัวมี 93 ชั้น โดยชั้นแรกสุดทำงานเต็มตัวทุกครั้งแบบชั้นธรรมดา อีก 92 ชั้นที่เหลือเป็นชั้นเลือกผู้เชี่ยวชาญ

รวมทั้ง 93 ชั้นแล้ว การเขียนหนึ่งโทเคนใช้พารามิเตอร์จริงราว 104 พันล้านตัว คิดเป็นแค่ 3.7 เปอร์เซ็นต์ของโมเดลทั้งก้อน อีก 96.3 เปอร์เซ็นต์ยังต้องอยู่ครบและเรียกใช้ได้ แต่ไม่ต้องค้างในแรม

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

ตัวเลข 2.78 ล้านล้านบนพาดหัวตอนเปิดตัว จึงไม่ใช่ตัวเลขเดียวกับภาระที่เครื่องต้องแบก ตอน Moonshot AI เปิดตัวโมเดลนี้พร้อมพาดหัวว่าแซงรุ่นท็อปของตลาด คนก็พูดถึงตัวเลขใหญ่ก้อนนี้

นับไบต์แล้วพบว่า 93 เปอร์เซ็นต์ของไฟล์ไม่ต้องอยู่ในแรม

เอกสารต้นทางนับไว้ชัดๆ ระบบมีผู้เชี่ยวชาญให้เลือกทั้งหมด 82,432 ตัว มาจาก 896 ตัวในแต่ละชั้น คูณด้วย 92 ชั้นที่มีการเลือก แต่ละตัวใช้พื้นที่เท่ากันที่ 17,547,264 ไบต์ รวมเป็น 1.447 เทระไบต์ หรือ 93 เปอร์เซ็นต์ของทั้งไฟล์

ส่วน 93 เปอร์เซ็นต์นี้ถูกบีบไว้ในรูปแบบ 4 บิตและจะอ่านจากดิสก์เมื่อถูกเรียกใช้ เอนจินคำนวณต่อได้ทันทีโดยไม่ต้องคลายข้อมูลใส่แรมก่อน

ส่วนที่ทำงานทุกครั้งมี 56,743,648,000 พารามิเตอร์ หรือ 113.49 กิกะไบต์ แบ่งเป็นแกนหลักที่ทำงานทุกชั้น 108.81 กิกะไบต์ และตารางคำศัพท์กับชั้นสุดท้ายที่ใช้เลือกคำอีก 4.70 กิกะไบต์

สี่ก้าวจาก 5,560 กิกะไบต์เหลือ 8.24

แต่ละขั้นตัดสินว่าไบต์ก้อนไหนควรอยู่ตรงไหน

ขั้นสุดท้ายลดจากขั้นแรก 675 เท่า และลดจากขนาดไฟล์จริง 189 เท่า ไม่มีการประมาณค่าและไม่มีน้ำหนักหาย คำตอบจึงเหมือนขั้นแรกทุกไบต์

ทำไมไม่บีบแกนหลักให้เล็กลงอีก เอกสารมีผลวัดอยู่ สุ่มน้ำหนักในแกนหลักมา 31 ก้อนแล้วลองบีบดู เมื่อลองบีบให้เหลือ 8 บิต ค่าคลาดเคลื่อนอยู่ราว 1 เปอร์เซ็นต์ พอลดเหลือ 4 บิต ค่าเฉลี่ยพุ่งเป็นราว 17 เปอร์เซ็นต์ ผลที่แย่ที่สุดคลาดเคลื่อนถึง 45 ถึง 65 เปอร์เซ็นต์ เอนจินจึงไม่ให้บีบส่วนนี้

เพิ่มแรมแล้วเร็วขึ้น แต่คำตอบไม่ได้ดีขึ้น

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

งบแรม 8 กิกะไบต์ใช้จริงสูงสุด 8.24 กิกะไบต์ ที่ความเร็ว 32.69 วินาทีต่อโทเคน ส่วนงบ 224 กิกะไบต์ใช้จริงสูงสุด 223.82 กิกะไบต์ ที่ความเร็ว 19.21 วินาทีต่อโทเคน เท่ากับเพิ่มแรม 28 เท่าเพื่อให้เร็วขึ้น 1.70 เท่า และพรีเซ็ตทุกระดับระหว่างนั้นได้คำตอบตรงกันทุกไบต์

พรีเซ็ตใหญ่สุด 224 กิกะไบต์ยังไม่เร็วกว่าพรีเซ็ต 128 กิกะไบต์ในการวัดชุดนี้ ผลจากแรมที่เพิ่มอีก 96 กิกะไบต์ยังอยู่ในช่วงความคลาดเคลื่อนของการวัด

ที่ว่างในดิสก์ 1.7 เทระไบต์เป็นเงื่อนไขที่ยากกว่าแรม

แรม 8 กิกะไบต์ฟังดูเหมือนเครื่องบ้านก็มี แต่เงื่อนไขถัดไปคือที่ว่างในดิสก์

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

จากผลวัดทั้งหมด เวลาที่หมดไปกับการรอดิสก์อยู่ที่ 40.9 ถึง 60.6 เปอร์เซ็นต์ของเวลาทั้งหมด พูดง่ายๆ คือเกือบครึ่งหนึ่งไม่ได้รอซีพียูคำนวณ แต่รออ่านไฟล์

ส่วนความสามารถของโมเดลกับความสามารถของเอนจินต้องแยกจากกัน ผู้พัฒนาโมเดลระบุว่า Kimi K3 รับข้อความ ภาพ และวิดีโอได้ และรับข้อความได้ยาวถึงหนึ่งล้านโทเคน แต่เอนจินภาษา C ตัวนี้ไม่มีส่วนที่อ่านภาพเลย และจำกัดการเขียนต่อไว้ที่ 4,096 โทเคน ส่วนข้อความที่ป้อนได้ยาวสุด 32,768 โทเคน

ตัวเลขที่ควรดูก่อนเลือกโมเดลลงเครื่อง

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

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

เรื่องคล้ายกันเคยเกิดกับความเร็ว ตอนมีคนวัดความเร็วโมเดลโอเพนซอร์ส 13 ตัวกับข้อความยาวๆ แล้วพบว่าจำนวนพารามิเตอร์ไม่ใช่ตัวเลขที่ควรดู

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

คำว่ารันได้บนเครื่องตัวเองมีสองความหมาย อย่างแรกคือเครื่องรับไหว อย่างที่สองคือคนรอไหว โปรเจกต์นี้ตอบอย่างแรกด้วยการแจกแจงว่าทุกไบต์ไปอยู่ตรงไหน ส่วนอย่างที่สองต้องชั่งใจกันเอง

ที่มา:

• โปรเจกต์ kimi-k3-in-c บน GitHub
• เอกสารทางการของ Kimi K3