วิธีรัน Kimi K3 บนเครื่อง (และข้อควรระวัง)

Moonshot AI ได้เปิดเผยน้ำหนักโมเดล Kimi K3 เมื่อวันที่ 27 กรกฎาคม และยอดดาวน์โหลดบน Hugging Face ก็ใกล้จะถึง 100,000 ครั้งแล้ว จุดเด่นนั้นชัดเจน: โมเดลที่มีพารามิเตอร์ 2.8 ล้านล้านตัวที่ เอาชนะ Claude Opus 4.8 ได้ในทุกเกณฑ์มาตรฐานที่ Moonshot เผยแพร่ และตอนนี้คุณสามารถโฮสต์มันเองได้

ข้อเสียก็ชัดเจนเช่นกันเมื่อดูตัวเลข การอนุมานด้วยความแม่นยำเต็มรูปแบบต้องใช้พื้นที่ดิสก์ 1.57 TB แม้แต่น้ำหนัก MXFP4 ที่ปล่อยออกมาก็ยังเป็นไฟล์ดาวน์โหลดขนาด 594 GB นี่คือโมเดลที่คุณสามารถเป็นเจ้าของได้ แต่ "ภายในเครื่อง" มีความหมายแตกต่างกันในขนาดนี้เมื่อเทียบกับ Llama ขนาด 8B

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

สิ่งที่คุณกำลังดาวน์โหลด

ขั้นแรก รูปร่างของมัน หากคุณต้องการข้อมูลเบื้องหลังทั้งหมด เริ่มต้นด้วย Kimi K3 คืออะไร?; ฉบับย่อ:

• พารามิเตอร์ทั้งหมด 2.8T เปิดใช้งาน 104B ต่อโทเค็น K3 เป็นโมเดล Mixture-of-Experts ที่มีผู้เชี่ยวชาญ 896 คน แต่ละโทเค็นจะส่งผ่านผู้เชี่ยวชาญที่เลือก 16 คนบวกกับผู้เชี่ยวชาญที่ใช้ร่วมกัน 2 คน ดังนั้นการประมวลผลต่อโทเค็นจึงเป็นเพียงเศษส่วนของตัวเลขหลัก
• 93 เลเยอร์: 69 เลเยอร์ Kimi Delta Attention (KDA) และ 24 เลเยอร์ Gated MLA การออกแบบ KDA คือเหตุผลที่หน้าต่างบริบท 1 ล้านโทเค็นสามารถใช้งานได้
• การมองเห็นแบบเนทีฟ ผ่านเอนโค้ดเดอร์ MoonViT-V2 ขนาด 401 ล้านพารามิเตอร์ น้ำหนักที่ปล่อยออกมาจัดการกับข้อความ รูปภาพ และอินพุตวิดีโอ
• น้ำหนัก MXFP4, การเปิดใช้งาน MXFP8 Moonshot ได้ทำการฝึกอบรมที่คำนึงถึงการควอนไทเซชัน ดังนั้นการปล่อย 4-บิตจึงเป็นรูปแบบการให้บริการที่ตั้งใจไว้ ไม่ใช่สิ่งที่คิดขึ้นภายหลัง ซึ่งหมายความว่าน้ำหนักจะถูกบีบอัดได้ไม่ดีเกินกว่านั้น; ส่วนหัวบิตต่ำถูกใช้ไปแล้ว
• คิดเท่านั้น K3 จะใช้เหตุผลเสมอก่อนที่จะตอบ โดยมีระดับความพยายามต่ำ กลาง และสูงสุด ไม่มีโหมดทันที

น้ำหนักถูกจำกัดโดย Kimi K3 License บน Hugging Face repo ยอมรับใบอนุญาต จากนั้นดึงด้วย huggingface-cli บนการเชื่อมต่อ 1 Gbps ให้เผื่อเวลาประมาณ 80 ถึง 90 นาทีสำหรับ 594 GB

ตัวเลือกที่ 1: การให้บริการระดับดาต้าเซ็นเตอร์ด้วย vLLM หรือ SGLang

Moonshot แนะนำสามเอ็นจิ้น: vLLM, SGLang และ TokenSpeed การมีส่วนร่วมของ KDA prefill-cache ใน vLLM พร้อมกับน้ำหนักโมเดล ดังนั้น vLLM จึงเป็นวิธีที่ง่ายที่สุด:

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

ข้อสังเกตจากภาคสนาม:

• ฮาร์ดแวร์ Moonshot ประเมินบนคลัสเตอร์ H20 ในความเป็นจริง คุณต้องมีโหนด 8-GPU ที่มีการประมวลผลแบบขนานเทนเซอร์เป็นพื้นฐาน บนฮาร์ดแวร์คลาส B200 สามารถทำปริมาณงานได้เกิน 100 โทเค็น/วินาที
• บริบท โมเดลรองรับได้สูงสุด 1,048,576 โทเค็น แต่แคช KV ที่บริบทเต็มรูปแบบมีขนาดประมาณ 27 GB ด้วยตัวมันเอง เริ่มต้นที่ 131K และเพิ่มขึ้นก็ต่อเมื่อปริมาณงานของคุณต้องการเท่านั้น
• การสุ่มตัวอย่าง ค่าเริ่มต้นของ Moonshot คือ temperature 1.0 และ top-p 0.95 สำหรับปริมาณงานของเอเจนต์ ให้รักษา temperature ไว้ที่ 1.0 และย้าย top-p ไปที่ 1.0

นี่คือ "ภายในเครื่อง" ในแง่ของอธิปไตยของข้อมูล: โครงสร้างพื้นฐานของคุณ, บันทึกของคุณ, เรื่องราวการปฏิบัติตามข้อกำหนดของคุณ ไม่ใช่ภายในเครื่องในแง่ของแล็ปท็อป และไม่มีการควอนไทเซชันใดเปลี่ยนแปลงสิ่งนั้นสำหรับการใช้งานแบบโต้ตอบ

ตัวเลือกที่ 2: GGUF quants บนเวิร์กสเตชันขนาดใหญ่

Unsloth เผยแพร่การแปลง GGUF สำหรับผู้ใช้ llama.cpp และ quants แบบไดนามิกของพวกเขาเป็นวิธีเดียวที่เป็นไปได้ในการลดขนาด K3 ให้ต่ำกว่ารุ่นอย่างเป็นทางการ:

กฎการทำงาน: RAM ของคุณบวก VRAM ควรมมีขนาดประมาณเท่ากับขนาดของ quant หากน้อยไป llama.cpp จะยังคงรันผ่านการ offloading แต่ทุกๆ กิกะไบต์ที่ขาดหายไปจะทำให้คุณเสียความเร็ว Mac Studio ที่เชื่อมต่อกับเครื่อง 128 GB หรือ DGX Station อยู่ในระดับต่ำสุดที่ใช้งานได้จริง

การเรียกใช้ llama.cpp ขั้นต่ำ รวมถึงวิชวลโปรเจคเตอร์:

./llama.cpp/llama-cli \
    --model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
    --mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
    --temp 1.0 \
    --top-p 0.95

หากฮาร์ดแวร์ของคุณมีประสิทธิภาพไม่ถึงระดับนี้ อย่าฝืน รายการ LLM ท้องถิ่นที่ดีที่สุดปี 2026 มีโมเดลโอเพนซอร์สที่สามารถทำงานได้ใน 24 ถึง 128 GB และตอบกลับได้แบบเรียลไทม์; K3 ที่ 1-บิตบน RAM ที่ไม่เพียงพอจะไม่เป็นเช่นนั้น

การทดลอง M1 Max: ใช่ แต่ 16 วินาทีต่อโทเค็น

กระทู้ Hacker News สัปดาห์นี้ได้บันทึกการรัน K3 บน M1 Max 64 GB โดยการสตรีมน้ำหนักจาก SSD ขนาด 2 TB แทนที่จะเก็บไว้ในหน่วยความจำ ตัวเลขเหล่านี้อธิบายทั้งเหตุผลที่มันใช้งานได้ และเหตุผลที่คุณไม่ควรใช้:

• K3 มีพารามิเตอร์หนาแน่นประมาณ 115 GB ที่ทุกโทเค็นต้องแตะ รวมถึงน้ำหนักผู้เชี่ยวชาญที่ถูกกำหนดเส้นทางประมาณ 25 GB ต่อโทเค็น ส่วนที่หนาแน่นเพียงอย่างเดียวก็เกิน RAM ของเครื่องแล้ว ดังนั้น SSD จึงกลายเป็นหน่วยความจำที่ทำงานช้า
• ผลลัพธ์: ประมาณ 16 วินาทีต่อโทเค็น การกำหนดค่าบางอย่างรายงานว่าใช้เวลามากกว่าหนึ่งนาทีต่อโทเค็น นั่นคือหนึ่งย่อหน้าต่อชั่วโมง
• ปริมาณงานดิสก์คือสิ่งสำคัญที่สุด SSD ยุค M1 อ่านช้ากว่า Apple silicon ในปัจจุบันมาก และการสตรีมผู้เชี่ยวชาญผ่านเครือข่ายก็ยังช้ากว่านั้นอีก

ในฐานะหลักฐานว่าความหนาแน่นของ MoE บวกกับ mmap สามารถรันโมเดล 2.8T บนแล็ปท็อปได้ ถือเป็นผลลัพธ์ที่น่าสนใจอย่างแท้จริง ในฐานะวิธีการใช้ K3 มันไม่ใช่ หากคุณต้องการคำตอบจาก K3 บน MacBook แพ็กเกจฟรี หรือ API ที่โฮสต์ไว้จะให้บริการคุณได้ดีกว่า

การเชื่อมต่อ K3 ภายในเครื่องของคุณเข้ากับเวิร์กโฟลว์ API

ไม่ว่าคุณจะให้บริการผ่าน vLLM หรือโหมดเซิร์ฟเวอร์ของ llama.cpp คุณก็จะได้ผลลัพธ์เดียวกัน: ปลายทาง HTTP ที่เข้ากันได้กับ OpenAI บน localhost จากนี้ไปมันก็คือ API เหมือนกับ API อื่นๆ และเวิร์กโฟลว์เดียวกับที่เราใช้สำหรับ การทดสอบ LLM ภายในเครื่องเป็น API ก็ใช้ได้:

1. ชี้ Apidog ไปยังปลายทาง สร้างสภาพแวดล้อมโดยตั้งค่า base_url เป็น http://localhost:8000/v1 (ค่าเริ่มต้นของ vLLM) และสลับกับปลายทางที่โฮสต์ของ Moonshot ในภายหลัง คำขอเดียวกัน สองแบ็กเอนด์ หนึ่งตัวแปร
2. ตรวจสอบสตรีมการคิด K3 คิดเท่านั้น ดังนั้นการตอบกลับจะมีการให้เหตุผลก่อนคำตอบ Apidog's SSE debugging view จะแสดงสตรีมตามที่มาถึง ซึ่งทำให้ง่ายต่อการดูว่าระดับความพยายามในการให้เหตุผลเปลี่ยนแปลงไปอย่างไร
3. ยืนยันโครงสร้าง ไม่ใช่อารมณ์ เพิ่มการทดสอบอัตโนมัติที่ตรวจสอบสคีมาการตอบกลับ งบประมาณความหน่วง และฟิลด์การใช้โทเค็น เพื่อให้การสลับ quant หรือการอัปเกรดเอ็นจิ้นที่ทำให้ผลลัพธ์แย่ลงปรากฏในการทดสอบที่ล้มเหลว แทนที่จะเป็นรายงานของผู้ใช้
4. จำลอง K3 ในขณะที่ GPU กำลังยุ่ง โมเดลขนาด 594 GB ใช้เวลาโหลดนาน บันทึกการตอบกลับจริงหนึ่งครั้ง จากนั้นให้เซิร์ฟเวอร์จำลองส่งคืน เพื่อให้งานส่วนหน้าไม่ต้องรอการอนุมาน ดาวน์โหลด Apidog เพื่อตั้งค่าฟรี; เครื่องมือจำลองและทดสอบทำงานได้กับเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ทุกชนิด

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

แล้วคุณควรจะรันมันบนเครื่องของคุณเองหรือไม่?

ตารางการตัดสินใจอย่างรวดเร็ว:

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

ไม่ว่าคุณจะอยู่ฝั่งไหนของตารางนั้น ปลายทางคือจุดที่โมเดลมาพบกับโค้ดของคุณ ทดสอบมันเหมือนกับ API อื่นๆ: การตรวจสอบสคีมา การตรวจสอบสตรีม และการจำลองที่ช่วยให้การพัฒนาดำเนินต่อไปในขณะที่โมเดลกำลังคิด