รันโมเดล 2.78 ล้านล้านพารามิเตอร์บนแล็ปท็อป 8GB: เจาะลึก kimi-k3-in-c

โปรเจกต์หนึ่งในชุมชนโอเพนซอร์สที่ทำให้คุณต้องหยุดดู: kimi-k3-in-c — เอนจิน inference ของ Kimi K3 เขียนด้วย C99 แบบพกพาได้ โค้ด 176KB ไม่มี BLAS ไม่มีเฟรมเวิร์ก ไม่มี GPU รันโมเดล 2.78 ล้านล้านพารามิเตอร์บนแล็ปท็อปธรรมดา 8GB ได้ นี่ไม่ใช่คำโฆษณา: รีโปมีบันไดตรวจสอบครบและข้อมูลวัดจริง — peak RSS ที่วัดได้ 8.24GB และผลลัพธ์ เหมือนกันแบบ byte-identical ตั้งแต่เครื่อง 8GB ไปจนถึง 224GB เปลี่ยนแค่เวลา

โปรเจกต์นี้คืออะไร

kimi-k3-in-c เริ่มโดยนักพัฒนา FareedKhan-dev ภายใต้ Apache-2.0 ปัจจุบันเวอร์ชัน 1.1.0 ประโยคเดียวสรุปได้ว่า เขียน inference ของ Kimi K3 ใหม่ด้วย C แบบพกพาที่เรียบง่ายที่สุด และได้ผลเหมือนกันทุกงบหน่วยความจำ

สิ่งสำคัญคือ ดิสก์คือประตู ไม่ใช่คอมพิวเตอร์ เช็กพอยต์ต้องการพื้นที่ว่างราว 1.7TB, RAM เริ่มที่ 8GB, คอมไพเลอร์ GCC 9+ หรือ Clang 10+ ก็สร้างได้ กล่าวคือ เครื่องพัฒนาธรรมดาบวกฮาร์ดดิสก์ใหญ่หนึ่งลูกก็รันได้ ไม่ต้องมีคลัสเตอร์ GPU

สี่วิศวกรรมที่ทำให้เป็นไปได้

โมเดล 2.8T ต้องการหน่วยความจำระดับ TB โปรเจกต์นี้บีบเหลือ 8GB ด้วยการตัดสินใจสี่อย่าง

หนึ่ง ผู้เชี่ยวชาญคงสภาพแพ็ก 4-bit น้ำหนัก routed experts 1.45TB ไม่เคยอยู่ในหน่วยความจำทั้งชุด แต่คูณตรงจากรูปแพ็กแบบครึ่งไบต์ ต่างจาก "คลายแพ็กก่อนคำนวณ" ซึ่งจะขยายความต้องการหน่วยความจำหลายเท่า

สอง KDA attention หน่วยความจำไม่โตตามบริบท กลไก attention แบบเดิมโตเชิงเส้นตามความยาวบริบท ทำให้หน้าต่างยาวระเบิดหน่วยความจำ KDA ทำให้ state ของ attention คงขนาด fixed

สาม MLA หนึ่ง latent แทน 96 หัว KV cache เป็นตัวกินหน่วยความจำรายใหญ่ MLA บีบ KV ของหลายหัวเป็น latent เดียว ลดพื้นที่ cache อย่างมีนัยสำคัญ

สี่ trunk แบบสตรีมบวก LRU cache ของผู้เชี่ยวชาญ trunk หนาแน่น 93 ชั้นอ่านจากดิสก์ตามต้องการ (หนึ่งครั้งต่อชั้น) และน้ำหนักผู้เชี่ยวชาญอยู่หลัง LRU cache หน่วยความจำมากก็เก็บ trunk ไว้มาก หน่วยความจำน้อยก็อ่านดิสก์มาก

บันไดความหน่วงที่วัดจริง

ข้อมูลที่โปรเจกต์เผยแพร่ (เครื่องเดียวกัน 124 คอร์ NVMe เร็ว พร้อมต์สั้นชุดเดียวกัน):

สองตัวอย่างรันจริงจาก README:

# แล็ปท็อป 8GB
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
         --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB

# เวิร์กสเตชัน 128GB+
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset server \
         --tok ~/k3model --prompt "def fibonacci(n):" --gen 28 --incremental
28 tokens in 299.3 s, 10.69 s/token average
PEAK RSS for the whole run: 127.92 GB

จุดที่ควรดูไม่ใช่ความเร็วสัมบูรณ์แต่ รูปทรงของเส้นโค้ง: หน่วยความจำมากขึ้นเร็วขึ้น คำตอบไม่เปลี่ยน เวอร์ชัน 1.1.0 เทียบกับ 1.0.0 ลดคำนวณต่อโทเคนราวแปดเท่า คำถามตามในแชทเร็วขึ้น 3.9 เท่า พร้อมต์ยาวถูกลงครึ่งหนึ่ง — โปรเจกต์ยังปรับปรุงเร็ว

ตรวจสอบในหนึ่งนาทีโดยไม่ต้องมีเช็กพอยต์

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

git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

make -j        # คอมไพล์: ไม่กี่วินาที
make test      # ชุดทดสอบเต็ม: ต่ำกว่าหนึ่งนาที

ผลลัพธ์พิมพ์สามด่าน — teacher forcing 32/32, greedy decode 20/20, incremental decode (KV cache + KDA state ที่พกต่อ) 20/20 — ปิดท้ายด้วย VERDICT: ENGINE MATCHES THE REFERENCE EXACTLY ไม่มีเช็กพอยต์ก็ยังตรวจทุกเคอร์เนล แคชสตรีม ตัวอ่าน safetensors ตัวอ่านคอนฟิก และโทเค็นไนเซอร์ เทียบกับ PyTorch reference ที่คอมมิตไว้ในรีโป

กล่าวอีกอย่างคือ คุณยืนยันได้ว่าเอนจินน่าเชื่อถือก่อนจ่ายเงินซื้อดิสก์หลายพันดอลลาร์ นี่คือวิศวกรรมโอเพนซอร์สที่ลงตัว และเป็นแบบอย่างที่คอนเทนต์ ecosystem ควรชี้ให้เห็น

เส้นทางสู่ข้อความจริง

จะ generate ข้อความได้ต้องมีเช็กพอยต์ Kimi K3 ทางการ เส้นทาง: โคลนรีโป → รัน ./scripts/k3-doctor.sh (เช็ก toolchain, จับคู่ RAM กับ preset, วัดความเร็ว storage, พิมพ์คำสั่งถัดไปให้ตรง ๆ) → ดาวน์โหลดเช็กพอยต์ 1.56TB → แพ็ก trunk → รัน

• --preset เลือกงบ laptop (8GB ขึ้นไป) ถึง server (เวิร์กสเตชันหน่วยความจำใหญ่) บวก preset ultra ที่ใหม่กว่า
• โหมดโต้ตอบ โปรเจกต์มี chat REPL (XTML) สำหรับหลายรอบสนทนา
• ติดตามแคชผู้เชี่ยวชาญ python3 tools/sim_cache.py tests/fixtures/expert_trace.bin เล่น trace คำขอผู้เชี่ยวชาญ 100,096 ครั้งที่บันทึกไว้ เพื่อสร้างตารางความจุแคชใหม่โดยไม่ต้องใช้เช็กพอยต์

โปรเจกต์นี้หมายถึงอะไรสำหรับนักพัฒนา

ถ้าคุณสร้าง inference engine หรือทำ systems optimization นี่คือ reference implementation ระดับตำรา — ตั้งแต่อ่าน header safetensors, แยกคอนฟิก, โทเค็นไนเซอร์ระดับไบต์ ไปจนattention variants และ MoE routing README Part II ไล่สร้างทุกชิ้นทีละอัน จับต้องได้กว่าอ่านเปเปอร์มาก

ถ้าคุณอยากเข้าใจว่าทำไม MoE "ประหยัด compute แต่ไม่ประหยัดหน่วยความจำ" โปรเจกต์ตอบด้วยการกระทำ น้ำหนักผู้เชี่ยวชาญต้องอยู่ที่ใดสักแห่ง (ที่นี่คือดิสก์) แต่แต่ละโทเคนเปิดใช้เพียงส่วนเดียว อัตราส่วน cache hit เป็นตัวกำหนดปริมาณ I/O ของดิสก์ — นั่นคือเหตุที่เครื่อง 128GB ลดจาก 26 วินาทีเหลือ 5.6 วินาทีต่อโทเคน

ถ้าคุณอยากสัมผัสความสามารถ K3 ด้วยต้นทุนต่ำ ตามตรง 26 วินาที/โทเคนไม่ใช่ประสบการณ์แชท คุณค่าของโปรเจกต์คือการเรียนรู้ การทดลองออฟไลน์ และคำถามวิศวกรรมว่าจะยัดโมเดลยักษ์ลงเครื่องเล็กได้อย่างไร สำหรับสนทนาจริง cloud API เหมาะกว่า — kimi-k3 ของ EXAIV ให้บริการโมเดลเดียวกันที่ความหน่วงระดับวินาที

อ่านตัวเลขของโปรเจกต์อย่างเป็นธรรม

ทุกตัวเลขประสิทธิภาพในบทความนี้มาจากเอกสารของรีโปเองใต้ docs/data/ — นั่นคือการวัดที่โปรเจกต์เผยแพร่ ไม่ใช่ benchmark อิสระ ความแตกต่างนี้สำคัญเวลาประเมินเอนจินใด ๆ:

• การเปิดเผยฮาร์ดแวร์: ตัวเลขวัดบนเครื่องเดียว (124 คอร์ NVMe เร็ว) ดิสก์ช้ากว่าทำให้แถวที่ติดดิสก์ช้าลง ซึ่งโปรเจกต์เองก็ระบุ
• อะไรตรวจได้จริง อะไรเป็นการวัด: ข้อกล่าวอ้างความถูกต้องใครก็ reproduce ได้ — โคลน บิลด์ รันชุดทดสอบแบบไม่มีน้ำหนักเทียบ oracle ที่คอมมิตไว้ ส่วนตัวเลขความหน่วงขึ้นกับฮาร์ดแวร์
• เชื่ออะไรก่อน: สมบัติ byte-identical เป็นสถาปัตยกรรม (เส้นทางคำนวณ deterministic) จึงข้ามเครื่องได้ เวลาสัมบูรณ์ไม่สามารถ

นี่คือท่าทีที่ถูกต้องต่อคำกล่าวอ้างประสิทธิภาพของโอเพนซอร์สใด ๆ ทำซ้ำสิ่งที่ทำซ้ำได้ อ่านส่วนที่เหลือพร้อมบริบทฮาร์ดแวร์ รีโปทำให้ง่ายด้วยการแถมผลวัดดิบแทนสรุปการตลาด

FAQ

บทความนี้ตอบอะไร

• K3 รันบนแล็ปท็อป 8GB อย่างไร
• CPU inference ทำงานอย่างไรที่นี่
• การนำ disk streaming มาใช้อย่างไร

แผนที่สถานการณ์โดยย่อ

มองข้างหน้า

แคตตาล็กและเวตยังคงเปลี่ยนแปลงต่อเนื่อง ข้อตกลงการเชื่อมต่อและการเรียกในที่นี้เป็นไปตามเอกสารทางการ ณ เวลาเผยแพร่

แหล่งที่มาและการตรวจสอบ

ข้อเท็จจริงสำคัญในบทความนี้มาจาก README ของโปรเจกต์ kimi-k3-in-c และ checkpoint ของ Kimi K3 และตรวจสอบเมื่อ 2026-11-09 รหัสโมเดล ราคา และความพร้อมใช้งานตามแคตตาล็อกสดของแพลตฟอร์ม โดยเจตนาไม่เขียนตัวเลขที่จะล้าสมัย โค้ดตัวอย่างตามสัญญา API ณ เวลาเผยแพร่ ตรวจสอบเอกสารทางการก่อนนำไปใช้งานจริง

ขอบเขตและกลุ่มผู้อ่าน

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

บันทึกบรรณาธิการและการแก้ไข

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

อ่านต่อ

• คู่มือเชื่อมต่อ Kimi K3
• ติดตั้ง Kimi K3 แบบโอเพนเวต
• เปรียบเทียบ GGUF quantizer
• คู่มือติดตั้งโลคอล
• โมเดลต้นทุนคอมพิวต์โลคอล