ติดตั้ง Kimi K3 แบบโอเพนเวตบนเครื่องตัวเอง: ขีดจำกัดคอมพิวต์ การเลือก quantization และเส้นทางอื่น

Kimi K3 เปิดตัว 16 กรกฎาคม 2026 และปล่อยเวตเต็ม 27 กรกฎาคม — โมเดลโอเพนเวตที่ใหญ่ที่สุดถึงปัจจุบัน: พารามิเตอร์รวม 2.8 ล้านล้านในสถาปัตยกรรม mixture-of-experts ที่เปิดใช้ราว 104 พันล้านต่อรอบคำนวณ โอเพนเวตหมายความว่าคุณรันออฟไลน์ได้ทั้งหมด แต่ต้องตั้งความคาดหวังก่อน: นี่คือโมเดลน้ำหนักมาก และการติดตั้งเองคือโปรเจกต์คอมพิวต์จริงจัง ไม่ใช่สิ่งที่คุณสบาย ๆ รันบน GPU การ์ดเดียวได้

ประมาณ VRAM ก่อนดาวน์โหลด

ก่อนอื่นไม่ใช่ดาวน์โหลด แต่คือคำนวณ VRAM มีสามส่วน

VRAM รวม ≈ น้ำหนัก + KV cache + โอเวอร์เฮดรันไทม์

พจน์น้ำหนัก = จำนวนพารามิเตอร์ × ไบต์ต่อพารามิเตอร์ ระดับ quantization กำหนดไบต์ต่อพารามิเตอร์:

นี่คือการแปลงสูตรสาธารณะกับ 2.8T โดยตรง ขนาดไฟล์จริงขึ้นกับ GGUF implementation และวิธีแพ็ก ให้ยึดตามหน้าดาวน์โหลด ข้อสรุปตรงไปตรงมา: แม้ Q4 พจน์น้ำหนักก็อยู่ระดับ TB การ์ดเดียว 24GB / 48GB ใส่ไม่ได้ — ต้องใช้เซิร์ฟเวอร์หลายการ์ด เครื่อง unified memory ระดับ TB หรือไปใช้คลาวด์

พจน์ KV cache แปรผันตามความยาวบริบทและขนาด batch บริบท 1 ล้านโทเคนของ K3 คือจุดขาย แต่ KV cache ของบริบทยาวก็สิ้นเปลืองตามกัน ต้องสำรองพื้นที่ให้มาก

พจน์โอเวอร์เฮด คือ inference framework, activation, บัฟเฟอร์ชั่วคราว ประมาณ 10–20% ของพจน์น้ำหนัก

ความพิเศษของ MoE ที่กระทบการติดตั้ง

สถาปัตยกรรม MoE ของ K3 มีผลสำคัญที่หลายคนคำนวณผิด

พารามิเตอร์รวม 2.8T ต้องค้างใน VRAM ทั้งหมด 104B ที่เปิดใช้มีผลต่อความเร็วคำนวณ ไม่ใช่การใช้หน่วยความจำ MoE ประหยัดคอมพิวต์โดยส่งแต่ละโทเคนผ่านผู้เชี่ยวชาญบางส่วน แต่น้ำหนักของผู้เชี่ยวชาญทุกตัวต้องอยู่ในหน่วยความจำพร้อมรับงาน — คุณไม่รู้ว่าโทเคนถัดไปจะ route ไปหาใคร ดังนั้นต้องคำนวณหน่วยความจำตาม 2.8T ไม่ใช่ 104B

สิ่งที่ MoE ประหยัดจริงคือคอมพิวต์ต่อโทเคน (104B ที่เปิดใช้เทียบเท่าโมเดลหนาแน่น 104B) ซึ่งหมายความว่าบนเครื่องที่มีหน่วยความจำพอ ความเร็ว inference จะเร็วกว่าโมเดลหนาแน่นขนาดเดียวกันมาก ความคาดหวังที่ถูกต้องคือ นี่คือโมเดลสำหรับเครื่องหน่วยความจำระดับ TB แต่พอรันแล้วไม่ได้ช้า

เลือก quantization อย่างไร

Quantization คือแลกหน่วยความจำกับคุณภาพ กฎทั่วไป:

• Q8: เสียคุณภาพน้อยสุด ใช้หน่วยความจำสูงสุด เลือกเมื่อหน่วยความจำเหลือ
• Q4: ระดับคุ้มค่า เสียคุณภาพพอรับได้ หน่วยความจำลดครึ่ง ค่าเริ่มต้นของ self-hosting ส่วนใหญ่
• Q2 และต่ำกว่า: ประหยัดอีกชั้น แต่เสียคุณภาพชัด เหมาะกับงานที่ไม่ต้องการคุณภาพสูงหรือทดลองล้วน

K3 อยู่ระดับ 2.8T แม้ Q4 ก็ยังระดับ TB — ที่ขนาดนี้ "บีบอีกระดับเพื่อประหยัดหลายร้อย GB" ได้ประโยชน์จริง แต่ต้นทุนคุณภาพของ Q2 ก็จริงเช่นกัน ก่อนเลือกให้ replay ชุดพรอมต์ธุรกิจจริงคนละรอบในแต่ละระดับ แล้วตัดสินจากผล ไม่ใช่จากความรู้สึก

สี่เส้นทางเมื่อคอมพิวต์ไม่พอ

พูดตามตรง: ทีมที่ self-host โมเดล 2.8T ได้มีน้อย เมื่อเครื่องไม่พอ:

เส้นทางหนึ่ง cloud API (kimi-k3 บน EXAIV) ไม่ต้องจัดการ GPU คิดตามโทเคน สายโมเดลเดียวกับโอเพน เหมาะกับทีมส่วนใหญ่ — พิสูจน์ว่าโมเดลเข้ากับ workload ในคลาวด์ก่อน แล้วค่อยประเมินว่าควรสร้างเองไหม

เส้นทางสอง โมเดลตระกูล Kimi ที่เล็กกว่า องค์กร moonshotai มีโมเดลโอเพนเวตเบาหลายตัว เช่น Kimi-Linear-48B-A3B (MoE แบบ linear attention) ที่ 48B พารามิเตอร์รวม เครื่องสองการ์ด 48GB หรือ unified memory สเปกสูงรันได้ ความสามารถสู้ K3 รุ่น flagship ไม่ได้ แต่ขีดจำกัดต่ำกว่าหนึ่ง order ของขนาด

เส้นทางสาม เช่า GPU โหนดหลายการ์ดคิดรายชั่วโมงบนคลาวด์คุ้มกับงานแบตช์และงานวิเคราะห์ใหญ่ครั้งเดียว เฉพาะโหลดหนักต่อเนื่องเท่านั้นที่ซื้อการ์ดคุ้มกว่า

เส้นทางสี่ CPU inference แบบสตรีมจากดิสก์ (kimi-k3-in-c) โปรเจกต์ชุมชน kimi-k3-in-c ใช้เอนจิน C99 ขนาด 176KB สตรีมเช็กพอยต์ 1.56TB จากดิสก์ แล็ปท็อป 8GB ก็รันได้ — ต้นทุนคือรอราว 26 วินาทีต่อโทเคน ไม่ใช่ประสบการณ์แชท แต่ทำให้ "ไม่มี RAM ใหญ่ก็แตะโมเดล 2.8T ได้" เป็นจริง หน่วยความจำมากขึ้นเร็วขึ้น (128GB+ ลดเหลือ 5.6 วินาที/โทเคน) และคำตอบเหมือนกันทุกงบแบบ byte-identical

ถ้าตัดสินใจ self-host

เมื่อฮาร์ดแวร์พร้อม กระบวนการเหมือนโมเดลเปิดอื่น: ดาวน์โหลดเวต (หรือ GGUF ชุมชน) → เลือก inference framework (llama.cpp / Ollama / vLLM ตาม ecosystem) → ตั้งระดับ quantization และความยาวบริบท → รัน smoke test → replay พรอมต์ธุรกิจจริง

หลังติดตั้ง calibrate สามอย่าง: nvidia-smi เทียบหน่วยความจำจริงกับที่ประมาณ, รันโหลดเต็มด้วยความยาวบริบทสูงสุดเพื่อยืนยันว่าสำรอง KV cache พอ, และจดความเร็วโทเคน first-token กับ steady-state เป็น baseline ของการขยาย capacity ครั้งหน้า

FAQ

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

• ติดตั้ง K3 ในเครื่องต้องใช้ VRAM เท่าไร
• เลือก quantization สำหรับการปรับใช้ในเครื่องอย่างไร
• ทำอย่างไรเมื่อฮาร์ดแวร์ไม่พอ

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

มองข้างหน้า

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

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

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

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

กลุ่มผู้อ่าน: ทีมที่ประเมินการโฮสต์ K3 เอง ครอบคลุม: ฮาร์ดแวร์และ quantization ของการปรับใช้ในเครื่อง ไม่ครอบคลุม: การเชื่อมต่อ API คลาวด์หรือการฝึกปรับ

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

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

อ่านต่อ

• kimi-k3-in-c: 2.8T บนแล็ปท็อป 8GB
• คู่มือติดตั้งโลคอล
• สูตรคำนวณ VRAM
• เปรียบเทียบ GGUF quantizer
• โมเดลต้นทุนคอมพิวต์โลคอล