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

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

ลองใช้ Apidog วันนี้

ข้อเสียก็ชัดเจนจากตัวเลขเช่นกัน: การอนุมานแบบความแม่นยำเต็มรูปแบบต้องใช้พื้นที่ดิสก์ 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 แนะนำเอ็นจิ้น 3 ตัว ได้แก่ vLLM, SGLang และ TokenSpeed โดย contribution สำหรับ KDA prefill-cache ใน vLLM มาพร้อมน้ำหนักโมเดลแล้ว ดังนั้น vLLM จึงเป็นจุดเริ่มต้นที่ง่ายที่สุด

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

ก่อนรัน ให้ตรวจสอบข้อจำกัดหลักต่อไปนี้:

• ฮาร์ดแวร์
  
  Moonshot ประเมินโมเดลบนคลัสเตอร์ H20 ในทางปฏิบัติ คุณต้องมีโหนด 8 GPU เป็นอย่างน้อยสำหรับ tensor parallelism บนฮาร์ดแวร์ระดับ B200 สามารถทำปริมาณงานได้เกิน 100 โทเค็นต่อวินาที

• บริบท
  
  โมเดลรองรับสูงสุด 1,048,576 โทเค็น แต่ KV cache ที่บริบทเต็มขนาดประมาณ 27 GB เริ่มที่ 131072 โทเค็นก่อน และเพิ่มเมื่อเวิร์กโหลดจำเป็นจริง ๆ

• การสุ่มตัวอย่าง
  
  ค่าเริ่มต้นของ Moonshot คือ temperature=1.0 และ top_p=0.95 สำหรับเวิร์กโหลดเอเจนต์ ให้คง temperature ที่ 1.0 และปรับ top_p เป็น 1.0

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

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

Unsloth เผยแพร่การแปลง GGUF สำหรับผู้ใช้ llama.cpp โดย dynamic quant ของพวกเขาเป็นแนวทางหลักในการลดขนาด K3 ให้เล็กกว่ารุ่นทางการ

Quant	ขนาด	ความหมาย
UD-IQ1_M	~345 GB	พื้นฐาน: การควอนไทเซชันแบบไดนามิก 1 บิตอย่างหนัก
UD-IQ1_S	~650 GB	จุดสมดุลที่ Unsloth แนะนำ
UD-Q4_K_XL	~1.55 TB	ใกล้เคียงกับความแม่นยำเต็มรูปแบบ
UD-Q8_K_XL	~1.6 TB	แทบไม่สูญเสียข้อมูล

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

ตัวอย่างการเรียก llama.cpp ขั้นต่ำ พร้อม visual projector:

./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

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

การทดลอง M1 Max: รันได้ แต่ประมาณ 16 วินาทีต่อโทเค็น

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

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

• ผลลัพธ์อยู่ที่ประมาณ 16 วินาทีต่อโทเค็น และบางการตั้งค่ารายงานว่าเกินหนึ่งนาทีต่อโทเค็น ซึ่งเทียบได้กับหนึ่งย่อหน้าต่อชั่วโมง

• ปริมาณงานของดิสก์เป็นปัจจัยสำคัญ SSD ในยุค M1 อ่านข้อมูลช้ากว่า Apple silicon รุ่นปัจจุบัน และการสตรีมผู้เชี่ยวชาญผ่านเครือข่ายจะช้าลงไปอีก

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

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

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

1. ชี้ Apidog ไปยัง endpoint
   
   สร้าง environment และกำหนด base_url เป็น http://localhost:8000/v1 ซึ่งเป็นค่าเริ่มต้นของ vLLM จากนั้นสลับไปยัง endpoint ที่โฮสต์โดย Moonshot ได้ภายหลังด้วยตัวแปรเดียวกัน

2. ตรวจสอบสตรีมการคิด
   
   K3 เป็นโมเดลคิดเท่านั้น ดังนั้นการตอบกลับจะมีเหตุผลก่อนคำตอบ มุมมอง SSE debugging ของ Apidog ช่วยให้ตรวจสอบสตรีมที่เข้ามาแบบเรียลไทม์ และดูผลของระดับความพยายามในการให้เหตุผลได้

3. ตรวจสอบโครงสร้าง ไม่ใช่ความรู้สึก
   
   เพิ่ม automated tests เพื่อตรวจสอบ response schema งบประมาณความหน่วง และฟิลด์การใช้โทเค็น เมื่อเปลี่ยน quant หรืออัปเกรดเอ็นจิ้นแล้วผลลัพธ์แย่ลง ระบบควรล้มเหลวในชุดทดสอบก่อนผู้ใช้จะรายงานปัญหา

4. จำลอง K3 ระหว่างที่ GPU ยังไม่พร้อม
   
   โมเดล 594 GB ใช้เวลาโหลดนาน บันทึก response จริงอย่างน้อยหนึ่งชุด แล้วให้ mock server ส่งคืน response นั้นเพื่อให้ทีม frontend ทำงานต่อได้โดยไม่ต้องรอการอนุมาน เครื่องมือจำลองและทดสอบของ Apidog ใช้ได้กับเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ทุกประเภท

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

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

ใช้ตารางนี้เพื่อเลือกแนวทาง:

สถานการณ์ของคุณ	คำแนะนำ
มีโหนด 8+ GPU และต้องการอธิปไตยข้อมูลหรือการปฏิบัติตามข้อกำหนด	ใช่: ใช้ vLLM พร้อม tensor parallelism และน้ำหนัก MXFP4
มีเวิร์กสเตชันที่ RAM/VRAM 350 GB+	ใช้งานได้: ใช้ Unsloth 1-bit GGUF พร้อมความคาดหวังด้านความเร็วที่สมเหตุสมผล
ใช้ Mac หรือ PC ที่มี RAM 64–128 GB	ไม่แนะนำ: คุณจะได้เวลาเป็นวินาทีต่อโทเค็น ไม่ใช่โทเค็นต่อวินาที
ต้องการใช้ K3 ในผลิตภัณฑ์เท่านั้น	ใช้ Hosted API ซึ่งเข้ากันได้กับ OpenAI และ Anthropic

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

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