จะติดตั้งและใช้งาน Kimi K3 บนเครื่องโลคัลได้อย่างไร?

TL;DR

Kimi K3 เป็นโมเดลแบบเปิดน้ำหนัก (open-weight) แต่ไม่ได้อยู่ในสเกลสำหรับเวิร์กสเตชัน: การให้บริการด้วยโมเดลเนทีฟต้องใช้ GPU ระดับดาต้าเซ็นเตอร์และหน่วยความจำแบบกระจาย ใช้ vLLM สำหรับเส้นทางสู่โปรดักชันที่ตรงที่สุด หรือเลือก SGLang เมื่อโทโพโลยี แบบขนานผู้เชี่ยวชาญ (expert parallelism) และการควบคุมแคชมีความสำคัญ ชุมชนมีบิลด์ GGUF ที่ช่วยลดเกณฑ์ฮาร์ดแวร์ แต่ยังต้องการหน่วยความจำที่เข้าถึงได้ราว 500 GB ไปจนเกิน 1 TB และต้องแลกความเร็วหรือคุณภาพกับความเป็นไปได้ สำหรับพีซีและ Mac ทั่วไป ควรทดสอบผ่าน API แบบโฮสต์ก่อน แล้วค่อยโฮสต์เองเมื่อมีเหตุผลด้านความเป็นส่วนตัว การใช้งานต่อเนื่อง หรือการควบคุมโครงสร้างพื้นฐานที่คุ้มค่า

What Is Kimi K3?

Kimi K3 คือโมเดลมัลติโหมดเนทีฟระดับเรือธงแบบเปิดน้ำหนักของ Moonshot AI สำหรับงานโค้ดระยะยาว งานความรู้เชิงเอเจนต์ การให้เหตุผล และความเข้าใจเชิงภาพ

Moonshot อธิบายว่าเป็นโมเดลเปิดระดับ 3T ตัวแรกของโลก สถาปัตยกรรมผสาน Kimi Delta Attention และ Attention Residuals เข้ากับการออกแบบ MoE แบบสpars ที่เลือกใช้ผู้เชี่ยวชาญเพียงบางส่วนต่อโทเค็น

สเกลของโมเดลนี้ถือว่าแปลกใหม่แม้เทียบกับแนวหน้าของวงการ ปกติจะไม่เปิดใช้งานพารามิเตอร์ 2.8T ทั้งหมดต่อโทเค็น แต่ K3 จะเลือก 16 จากผู้เชี่ยวชาญที่ถูกส่งทาง (routed experts) 896 คน พร้อมผู้เชี่ยวชาญที่แชร์กัน ซึ่งช่วยลดการคำนวณต่อโทเค็นอย่างมาก แม้ว่าน้ำหนักของโมเดลทั้งหมดจะยังต้องพร้อมอยู่ที่ใดที่หนึ่งในระบบอินเฟอเรนซ์ก็ตาม

K3 ใช้การฝึกที่คำนึงถึงควอนไทเซชันตั้งแต่ช่วง SFT ไม่ได้มองการเสิร์ฟแบบความละเอียดต่ำเป็นเพียงขั้นตอนบีบอัดหลังการฝึก

ดังนั้นสถาปัตยกรรมจึงเหมาะกับการให้บริการสเกลใหญ่มากเป็นพิเศษ—but “sparse compute” ไม่ได้หมายถึง “ใช้หน่วยความจำน้อย” เครือข่ายคำนวณเพียงบางส่วนต่อโทเค็น แต่พูลผู้เชี่ยวชาญทั้งหมดยังต้องเข้าถึงได้

How Does Kimi K3 Perform?

ชุดเบนช์มาร์กอย่างเป็นทางการของ Kimi K3 ของ Moonshot จัดวางโมเดลไว้ใกล้โมเดลเชิงพาณิชย์ระดับแนวหน้า โดยเฉพาะในงานวิศวกรรมซอฟต์แวร์ระยะยาว เอเจนต์ และงานให้เหตุผล

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

คะแนนอย่างเป็นทางการจัดให้ Kimi K3 อยู่ใกล้ GPT-5.6 Sol, Claude Fable 5 และ Claude Opus 4.8 ในงานให้เหตุผล โค้ด เอเจนต์ และวิชัน จงมองผลที่ผู้ให้บริการรายงานเป็นบริบทด้านขีดความสามารถ ไม่ใช่อันดับสากล; การวิเคราะห์เบนช์มาร์กแบบละเอียด กล่าวถึงแยกต่างหาก สำหรับคู่มือนี้ ประเด็นเชิงปฏิบัติคือการโฮสต์เองจะให้ความสามารถระดับแนวหน้าและการควบคุมโครงสร้างพื้นฐาน แต่ไม่ใช่ทางลัดราคาถูกบนเดสก์ท็อป

Can You Actually Run Kimi K3 Locally?

ได้ แต่ “โลคอล” มีสองความหมายที่ต่างกันมาก

โลคอลเซิร์ฟเวอร์ / ดาต้าเซ็นเตอร์ส่วนตัว: สมจริง

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

vLLM Kimi K3 recipe ปัจจุบันตั้งค่ามาตรฐานไว้สูงมาก:

• NVIDIA: อย่างน้อย 8× GB300
• AMD ROCm: อย่างน้อย 8× MI355X หรือ MI350X
• NVIDIA driver: R580+ สำหรับอิมเมจ CUDA 13 ของ K3 ปัจจุบัน
• แนะนำให้ใช้โครงสร้างพื้นฐานหลายโหนดสำหรับทราฟฟิกโปรดักชันจริง

คู่มือวันแรกของ vLLM ยังสาธิต เส้นทางเริ่มต้นแบบ 8-GPU B300 หรือ 8-GPU MI355X สำหรับการดีพลอยใหม่ ให้ทำตามเรซิปีเวอร์ชันใหม่ เพราะสะท้อนสแต็กเสิร์ฟวิ่งหลังการปรับแต่งวันเปิดตัว

ใจความสำคัญคือ: K3 เป็น open-weight แต่ไม่ใช่โมเดลเปิดในสเกลผู้บริโภค

Official Weights vs Community GGUF Quantizations

อีกวิธีหนึ่งเพื่อลดเกณฑ์ฮาร์ดแวร์คือการควอนไทซ์โดยชุมชน

ที่เก็บ K3 ของ Unsloth ปัจจุบันมีหลายรูปแบบ GGUF ที่รันผ่านซอฟต์แวร์ที่เข้ากันได้กับ llama.cpp

การเปรียบเทียบโดยรวม ตัวเลขหน่วยความจำที่เข้าถึงได้คือประมาณการสำหรับการวางแผน (ขนาดดาวน์โหลดบวกส่วนเผื่อรันไทม์ราว 10–15%) ไม่ใช่การรับประกัน; การตั้งค่าบริบท แคช วิชัน และออฟโหลด อาจต้องการมากกว่านั้น

ความแตกต่างนี้ยังอธิบายได้ว่าทำไมบทความดีพลอยโลคอลช่วงแรกๆ บางชิ้นถึงอ้าง 594 GB: 594 GB ตอนนี้หมายถึงบิลด์ชุมชน UD-IQ1_S GGUF ไม่ใช่คำบรรยายที่เป็นประโยชน์ของเช็คพอยต์เนทีฟเวอร์ชันล่าสุด

โมเดลขนาด 466–649 GB เล็กกว่ารอยเท้าดีพลอยเมื่อตอนเริ่มต้นอย่างมาก แต่ยังใหญ่มากในมาตรฐานเวิร์กสเตชัน คุณยังควรเผื่อหน่วยความจำสำหรับสถานะรันไทม์ บริบท แคช โปรเจคเตอร์วิชัน โพรเซสของระบบปฏิบัติการ และโอเวอร์เฮดอื่นๆ

ความจุของดิสก์ไม่เท่ากับหน่วยความจำอินเฟอเรนซ์ การมี SSD 1 TB ไม่ได้หมายความว่าโมเดล 600 GB จะรันได้เร็วบนเครื่องที่มี RAM 64 GB การออฟโหลดไป SSD อาจทำให้การทดลองที่สุดโต่งเป็นไปได้ในหลักการ แต่การสร้างโทเค็นอาจช้าจนใช้งานแบบโต้ตอบไม่ได้

How to Deploy Kimi K3 with vLLM

สำหรับการโฮสต์เองอย่างจริงจัง vLLM คือจุดเริ่มต้นที่ตรงไปตรงมาที่สุด

Moonshot ปัจจุบันระบุ vLLM เป็นหนึ่งในเอนจินอินเฟอเรนซ์ K3 ที่แนะนำ และ vLLM มีการรองรับเฉพาะโมเดลสำหรับ KDA, MXFP4 MoE, การพาร์ส reasoning, การเรียกใช้เครื่องมือ, การแคชพรีฟิกซ์ และการดีพลอยแบบกระจาย

Check the prerequisites

สำหรับการดีพลอยโปรดักชันบน NVIDIA เรซิปีที่ทดสอบปัจจุบันใช้คอนเทนเนอร์ vllm/vllm-openai:kimi-k3

ตรวจสอบ GPU:

nvidia-smi

ยืนยัน Docker:

docker --version

ยืนยันว่า NVIDIA Container Toolkit มองเห็นตัวเร่ง:

docker run --rm --gpus all nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

ถ้าคำสั่งสุดท้ายไม่เห็น GPU ทั้งหมด แก้รันไทม์ GPU ของโฮสต์/คอนเทนเนอร์ก่อนดาวน์โหลดโมเดลระดับหลายเทราไบต์

Set your Hugging Face token

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

export HF_TOKEN="YOUR_HUGGING_FACE_TOKEN"

Pull the K3 vLLM container

docker pull vllm/vllm-openai:kimi-k3

เรซิปีปัจจุบันระบุ บิลด์ CUDA 13 และไดรเวอร์ NVIDIA R580 ขึ้นไป

Launch Kimi K3

Current Blackwell TP8 starting template (vLLM recipe updated 2026-09-10): ใช้เป็นฐาน แล้วจึงสร้างใหม่หรือเบนช์มาร์กให้ตรงกับฮาร์ดแวร์และทราฟฟิกของคุณ

docker run --rm \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HF_TOKEN="$HF_TOKEN" \
  -e VLLM_USE_V2_MODEL_RUNNER=1 \
  vllm/vllm-openai:kimi-k3 \
  --model moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95 \
  --kv-cache-dtype fp8 \
  --attention-backend TOKENSPEED_MLA \
  --attention-config '{"use_prefill_query_quantization":true,"mla_prefill_backend":"TOKENSPEED_MLA"}' \
  --prefix-match-unit 128 \
  --enable-prefix-caching \
  --max-model-len 131072 \
  --enable-auto-tool-choice \
  --tool-call-parser kimi_k3 \
  --reasoning-parser kimi_k3

เรซิปีปัจจุบันต้องใช้ภาพ K3 CUDA 13 และไดรเวอร์ NVIDIA R580 ขึ้นไป FP8 KV cache ต้องจับคู่กับแบ็กเอนด์ MLA สำหรับ prefill/decode ที่เข้ากันได้; ควรเบนช์มาร์กทางเลือกก่อนเปลี่ยนการตั้งค่า attention

ที่มา: vLLM Kimi K3 recipe สิ่งนี้แทนที่คำสั่งวันแรก แทนที่จะนำเสนอเป็นเรซิปีโปรดักชันปัจจุบัน

สำหรับการรันทดสอบครั้งแรก พิจารณาจำกัดความยาวโมเดลสูงสุด แทนที่จะจัดสรรความสามารถ 1,048,576 โทเค็นเต็มทันที เรซิปี vLLM ปัจจุบันแนะนำให้ปรับ max-model-len ตามเวิร์กโหลด

ตัวอย่างเช่น:

--max-model-len 131072

สิ่งนี้ไม่เปลี่ยนขีดจำกัดบริบทเชิงสถาปัตยกรรมของ K3 แต่ทำให้เอนจินเสิร์ฟวิ่งมีกรอบการทำงานที่จัดการได้มากขึ้นสำหรับการทดสอบระยะแรก

Test the local endpoint

vLLM เปิด API ที่เข้ากันได้กับ OpenAI ที่พอร์ต 8000

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between tensor parallelism and expert parallelism."
      }
    ],
    "max_tokens": 512
  }' 

หรือใช้ OpenAI Python SDK:

python

from openai import OpenAI

 client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="EMPTY",
    timeout=3600,
 )

response = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=[
        {
            "role": "user",
            "content": "Write a Python function that validates a JSON schema.",
        }
    ],
    max_tokens=1024,
 )

print(response.choices[0].message.content)

เรซิปี vLLM อย่างเป็นทางการ ใช้แพทเทิร์น OpenAI-compatible แบบ localhost เดียวกัน ทำให้ง่ายต่อการสลับแอปพลิเคชันระหว่างอินเฟอเรนซ์โลคอลและแบบโฮสต์

How to Deploy Kimi K3 with SGLang

SGLang เป็นเส้นทางดีพลอยหลักอีกเส้นทางที่ Moonshot แนะนำ

เหมาะอย่างยิ่งเมื่อคุณต้องการควบคุมการเสิร์ฟวิ่งแบบกระจายเชิงลึก แบบขนานผู้เชี่ยวชาญ เคอร์เนลเฉพาะฮาร์ดแวร์ หรือโทโพโลยีโปรดักชันที่ซับซ้อน

ใช้ SGLang Kimi K3 Cookbook โดยเฉพาะ แล้วเลือกโทโพโลยีที่เฉพาะฮาร์ดแวร์ ต่อไปนี้คือโปรไฟล์แบบโหนดเดียว 8×B300 Unified/Balanced ที่ตรวจยืนยันจากคุกบุ๊ก; วัดกับ SGLang v0.5.18 ที่คอมมิต 71de97b2

ติดตั้งบิลด์ที่รองรับ K3:

pip install --upgrade pip
pip install uv
uv pip install --prerelease=allow sglang

เปิดใช้โปรไฟล์ B300 TP8/DCP8 ที่ตรวจยืนยัน:

sglang serve \
  --trust-remote-code \
  --model-path moonshotai/Kimi-K3 \
  --tp-size 8 \
  --dcp-size 8 \
  --mem-fraction-static 0.85 \
  --mamba-full-memory-ratio <value-from-official-calculator> \
  --reasoning-parser kimi_k3 \
  --tool-call-parser kimi_k3 \
  --host 0.0.0.0 \
  --port 30000

--mamba-full-memory-ratio ขึ้นอยู่กับเวิร์กโหลด: คำนวณจากความยาวอินพุตบวกเอาต์พุตเฉลี่ยใน cookbook อย่างเป็นทางการ อย่าคัดลอกโทโพโลยี B300 นี้ไปยัง H100/H200, GB200/GB300, AMD หรือดีพลอยหลายโหนด; โปรไฟล์เหล่านั้นใช้เลย์เอาต์ TP/PP/DCP/EP ที่ต่างกัน

ทดสอบเซิร์ฟเวอร์:

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [{"role": "user", "content": "Give me a five-step debugging plan for a distributed Python application."}]
  }'

สำหรับการดีพลอยจริง ให้ตรวจยืนยันความจุ คุณภาพเอาต์พุต และการกู้คืนความล้มเหลว บนเวอร์ชัน SGLang โทโพโลยี ความยาวบริบท และมิกซ์ทราฟฟิกที่คุณตั้งใจจะรันจริง

vLLM vs SGLang vs llama.cpp

การเลือกเอนจินอินเฟอเรนซ์ขึ้นกับฮาร์ดแวร์และวัตถุประสงค์เป็นหลัก

หากคุณมีเซิร์ฟเวอร์ 8-GPU ระดับ Blackwell/MI35x ให้เริ่มจาก vLLM

หากคุณออกแบบคลัสเตอร์อินเฟอเรนซ์แบบกระจายเฉพาะทางและต้องการตัวควบคุมการเสิร์ฟวิ่งระดับลึก ให้ประเมิน SGLang ด้วยเช่นกัน.assistant_message

หากเป้าหมายคือ “อยากพิสูจน์ว่า K3 รันบนฮาร์ดแวร์ที่ฉันมีได้” GGUF ร่วมกับ llama.cpp จะเข้าถึงได้มากกว่ามาก—ตราบใดที่เครื่องของคุณมีหน่วยความจำในระดับมหาศาลจริงๆ

How to Run a Quantized Kimi K3 with llama.cpp or Ollama

ที่เก็บ Kimi K3 GGUF ของชุมชน มีรุ่นที่เข้ากันได้กับ llama.cpp แล้ว

เส้นทางนี้ลดอุปสรรคฮาร์ดแวร์ลงมากเมื่อเทียบกับการดีพลอยน้ำหนักเนทีฟระดับดาต้าเซ็นเตอร์ แต่ “มาก” เป็นเชิงเปรียบเทียบ: แม้รุ่นที่เล็กกว่าก็ยังมีขนาดหลายร้อยกิกะไบต์

Install llama.cpp on macOS or Linux

การ์ดโมเดล GGUF ปัจจุบันให้:

curl -LsSf https://llama.app/install.sh | sh

บน Windows:

winget install llama.cpp

Start an OpenAI-compatible server

รีโพปัจจุบันเอกสาร UD-Q4_K_XL เป็นตัวอย่าง:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

คุณยังสามารถรัน CLI ได้โดยตรง:

llama cli \
  -hf unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

คำสั่งเหล่านี้มาจาก การ์ดโมเดล Kimi K3 GGUF ปัจจุบัน

อย่างไรก็ตาม UD-Q4_K_XL มีขนาดประมาณ 1.51 TB จึงไม่ใช่รุ่นที่ผู้ใช้เวิร์กสเตชันส่วนใหญ่จะเริ่มต้น หากคุณเน้นลดความต้องการหน่วยความจำมากกว่ารักษาคุณภาพ ให้พิจารณารุ่น 1 บิตและ 2 บิตที่เล็กกว่าก่อน

ตัวอย่าง:

llama serve \
  -hf unsloth/Kimi-K3-GGUF:UD-IQ1_M

ไดเรกทอรี UD-IQ1_M ปัจจุบันมีขนาดประมาณ 649 GB

โมเดล 649 GB ก็ยังไม่ใช่โมเดลสำหรับแล็ปท็อปทั่วไป โดยอุดมคติแล้ว สถานะโมเดลที่ถูกเข้าถึงบ่อยควรอยู่ในหน่วยความจำที่เร็ว การออฟโหลดหนักไปยัง SSD อาจทำให้การทดลองที่สุดโต่งเป็นไปได้ทางเทคนิค โดยไม่ทำให้เหมาะกับงานโต้ตอบ

Run the Same GGUF Build with Ollama

Ollama เป็นเลเยอร์เพื่อความสะดวกสำหรับเส้นทางดีพลอย GGUF เดียวกัน ไม่ใช่วิธีโฮสต์เองอิสระวิธีที่สี่

ที่เก็บ K3 GGUF ยังเปิดเส้นทางผ่าน Ollama ด้วย

ตัวอย่าง:

bash

ollama run hf.co/unsloth/Kimi-K3-GGUF:UD-Q4_K_XL

Ollama ทำให้ง่ายขึ้นทั้งการจัดการโมเดลและประสบการณ์ API แต่ไม่ได้เปลี่ยนความต้องการหน่วยความจำของ K3

การเปลี่ยนตัวเรียกจาก llama.cpp เป็น Ollama ไม่สามารถทำให้ควอนไทซ์ขนาดหลายร้อยกิกะไบต์กลายเป็นโมเดล GPU 24 GB ได้ ข้อมูลโมเดลพื้นฐานยังต้องถูกเก็บและเข้าถึง

ดังนั้น ควรมอง Ollama เป็นตัวห่อรันไทม์ที่สะดวก ไม่ใช่ทางลัดด้านฮาร์ดแวร์

Which Kimi K3 Quantization Should You Choose?

สำหรับการทดลอง ทางเลือกหลักคือการแลกเปลี่ยนระหว่างขนาดโมเดลกับความเที่ยงตรง

Important Kimi K3 Serving Behavior

มีรายละเอียดการติดตั้งเฉพาะของ K3 ที่มองข้ามได้ง่ายอย่างหนึ่ง

K3 ใช้ preserved thinking history Moonshot ระบุว่าบทสนทนาหลายเทิร์นและเวิร์กโฟลว์การเรียกเครื่องมือควรส่งกลับ ข้อความ assistant ก่อนหน้าทั้งก้อนกลับไปที่โมเดล รวมทั้ง reasoning_content และ tool_calls ไม่ใช่แค่เนื้อหาที่มองเห็น

แพทเทิร์นแอปพลิเคชันอย่างง่ายมีลักษณะดังนี้:

messages = [
    {
        "role": "user",
        "content": "Inspect this project and propose a migration plan.",
    }
 ]

first = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

assistant_message = first.choices[0].message

 # Preserve the whole message object, not just assistant_message.content.
 messages.append(
    assistant_message.model_dump(exclude_none=True)
 )

messages.append(
    {
        "role": "user",
        "content": "Now identify the riskiest part of that plan.",
    }
 )

second = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    messages=messages,
    max_tokens=2048,
 )

สิ่งนี้สำคัญเป็นพิเศษสำหรับเอเจนต์ด้านโค้ด ลูปเครื่องมือ และเซสชันอัตโนมัติระยะยาว

K3 เปิดใช้งาน reasoning โดยค่าเริ่มต้น และรองรับระดับความพยายาม reasoning แบบต่ำ สูง และสูงสุด เมื่อเลเยอร์เสิร์ฟวิ่งของคุณเปิดพารามิเตอร์เหล่านี้ ให้มองความพยายาม reasoning เป็นตัวควบคุมความหน่วง/คุณภาพอีกตัว แทนที่จะดันสูงสุดเสมอสำหรับทุกคำขอ

How to Optimize a Local Kimi K3 Deployment

Do not allocate the full 1M context immediately

K3 รองรับ 1,048,576 โทเค็น แต่ความสามารถสูงสุดของโมเดลกับการตั้งค่าเซิร์ฟเวอร์ที่เหมาะสมเป็นคนละเรื่อง

สำหรับการพัฒนา เริ่มจากเช่น:

--max-model-len 131072

แล้วค่อยเพิ่มบริบทหลังจากวัดหน่วยความจำที่มี เวลาโทเค็นแรก ทรูพุต และความพร้อมรองรับการทำงานพร้อมกัน

Enable prefix caching

เอเจนต์ด้านโค้ดมักใช้คำสั่งรีโป สคีมาเครื่องมือ พร็อมต์ระบบ และพรีฟิกซ์ยาวซ้ำบ่อย

กับ vLLM:

--enable-prefix-caching

สถาปัตยกรรม attention แบบไฮบริดของ K3 ต้องการการจัดการพิเศษสำหรับ prefix caching และ vLLM ได้ทำการรองรับเฉพาะโมเดลไว้แล้ว

Use the K3 parsers

สำหรับเวิร์กโหลดเอเจนต์ ให้เพิ่ม:

--tool-call-parser kimi_k3 \
--reasoning-parser kimi_k3

เพื่อให้การเรียกเครื่องมือและเอาต์พุต reasoning จัดรูปแบบสอดคล้องกับ K3

Keep storage fast

โมเดลในสเกลนี้กดดันสตอเรจโลคอลอย่างมากระหว่างการดาวน์โหลดครั้งแรก การโหลดเช็คพอยต์ การอัปเดต และการกู้คืน

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

Monitor more than GPU utilization

ติดตาม:

• การใช้งาน HBM/VRAM
• RAM ของ CPU
• อัตราการถูกแคช (cache hit rate)
• เวลาไปยังโทเค็นแรก
• อัตรา decode โทเค็นต่อวินาที
• ความลึกของคิวคำขอ
• การสื่อสารระหว่าง GPU
• แบนด์วิดท์ระหว่างโหนด
• การพาร์สการเรียกเครื่องมือที่ล้มเหลว
• เวลาโหลดโมเดล

ในสเกล K3 ตัวเลขการใช้งาน GPU ที่ดู “ปกติดี” ไม่ได้บอกว่าการจัดวางเสิร์ฟวิ่งมีประสิทธิภาพหรือไม่

Local Kimi K3 vs Hosted Kimi K3

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

สำหรับการวิเคราะห์ฮาร์ดแวร์และจุดคุ้มทุนแบบเต็ม อ่าน Kimi K3 Self-Hosting vs API สำหรับราคาโทเค็น แคช และการเปรียบเทียบ K2.7 ใช้คู่มือราคา Kimi K3 ดังนั้นบทความนี้จึงย่อการเปรียบเทียบ และเน้นคำสั่งดีพลอย การคอนฟิก และการแก้ปัญหา

Common Kimi K3 Local Deployment Problems

The model does not fit in GPU memory

นี่คือความล้มเหลวที่คาดเดาได้ที่สุด

อย่าคำนวณหน่วยความจำจาก 104B พารามิเตอร์ที่ถูกใช้งาน ตัวเลขนั้นอธิบายคอมพิวต์ต่อโทเค็น ไม่ใช่ปริมาณน้ำหนักของผู้เชี่ยวชาญที่ระบบเสิร์ฟวิ่งต้องเข้าถึงได้

ใช้โทโพโลยีแบบกระจายที่รองรับ ควอนไทซ์ GGUF ที่เล็กลง หรือบริการแบบโฮสต์

CUDA or NVIDIA driver errors

อิมเมจ vLLM K3 ปัจจุบันอ้างอิง CUDA 13 และต้องการไดรเวอร์โฮสต์ R580+

หากโฮสต์ยังอยู่บนสแต็ก R575/CUDA 12.9 ให้ปรับปรุงหรือทำตามเส้นทาง build-from-source ที่ vLLM อธิบาย แทนที่จะคิดว่าคอนเทนเนอร์จะแก้ความไม่เข้ากันของไดรเวอร์โฮสต์ให้

The first request is extremely slow

ตรวจสอบว่าเช็คพอยต์ยังโหลดอยู่ คอมไพล์เคอร์เนล อุ่นแคช หรือดึงไฟล์อยู่หรือไม่

กับแอสเซ็ตระดับหลายเทราไบต์ “โปรเซสเซิร์ฟเวอร์เริ่มแล้ว” ไม่ได้เท่ากับ “โมเดลพร้อมรับทราฟฟิกโปรดักชัน”

Tool calls fail intermittently

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

Long conversations become less stable

ตรวจสอบว่าคุณส่งกลับข้อความ assistant ทั้งก้อน—รวมทั้งข้อมูล reasoning และเครื่องมือ—ไปยังเทิร์น K3 ถัดไป

การดรอปฟิลด์สถานะ reasoning ที่ซ่อนอยู่สามารถทำลายแพทเทิร์น preserved-thinking-history ที่ K3 ผ่านการฝึกมา

So, What Is the Best Way to Deploy Kimi K3 Locally?

สำหรับองค์กรส่วนใหญ่ที่มีฮาร์ดแวร์เหมาะสม vLLM คือเส้นทางดีพลอยแรกที่ดีที่สุด มีการรองรับ K3 โดยเฉพาะ API ที่เข้ากันได้กับ OpenAI พาร์สเซอร์เฉพาะโมเดล การแคชพรีฟิกซ์ การรองรับ speculative decoding และเรซิปีฮาร์ดแวร์ล่าสุด

เลือก SGLang เมื่อวิศวกรรมอินเฟอเรนซ์แบบกระจายและการควบคุมการเสิร์ฟวิ่งละเอียดสำคัญกว่าความง่ายในการตั้งค่า

เลือก llama.cpp พร้อมควอนไทซ์ GGUF จากชุมชนเมื่อเป้าหมายคือการทดลองบนเวิร์กสเตชัน/เซิร์ฟเวอร์ และคุณเข้าใจว่าต่อให้เป็นรุ่น 1 บิตก็ยังมีขนาดหลายร้อยกิกะไบต์

สำหรับเวิร์กสเตชันนักพัฒนาทั่วไป ข้อสรุปที่ใช้งานได้จริงต่างออกไป: อย่าซื้อ RAM หลายร้อยกิกะไบต์เพื่อบังคับให้ K3 รันบนเดสก์ท็อป ทดสอบ Kimi K3 ผ่าน CometAPI ก่อน วัดประโยชน์กับงานของคุณเอง แล้วค่อยย้ายไปโฮสต์เองเมื่อเหตุผลด้านความเป็นส่วนตัว การใช้งานต่อเนื่อง หรือการควบคุมโครงสร้างพื้นฐานทำให้คุ้มค่า

FAQ

Can Kimi K3 run on a single consumer GPU?

ไม่สมจริง โมเดลนี้ เกินความจุ VRAM ของ GPU ผู้บริโภคไปไกล ควอนไทซ์ GGUF แบบบิตต่ำจากชุมชนช่วยลดรอยเท้าลงอย่างมาก แต่รุ่นที่เล็กที่สุดในปัจจุบันก็ยังมีขนาดหลายร้อยกิกะไบต์

Can I run Kimi K3 on a Mac?

การรันด้วย CPU/Apple Silicon แบบทดลองร่วมกับ GGUF และการออฟโหลดสตอเรจทำได้ในหลักการ แต่ประสิทธิภาพเชิงโต้ตอบและความจุหน่วยความจำเป็นข้อจำกัด MacBook ทั่วไปไม่ควรถูกมองว่าเป็นแพลตฟอร์มเสิร์ฟ K3 ที่ใช้งานได้จริง

Does Kimi K3 support Ollama?

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

Is vLLM or SGLang better for Kimi K3?

vLLM ง่ายกว่าเป็นค่าเริ่มต้นสำหรับดีพลอยโปรดักชันใหม่ SGLang น่าสนใจสำหรับทีมที่สร้างโทโพโลยีการเสิร์ฟวิ่งแบบกระจายที่ซับซ้อน ทั้งสองอยู่ในเอนจินอินเฟอเรนซ์ K3 ที่ Moonshot แนะนำ

How much context does Kimi K3 support?

สเปกทางการรองรับ 1,048,576 โทเค็น เซิร์ฟเวอร์โลคอลไม่จำเป็นต้องเปิดหน้าต่างบริบททั้งหมด; การตั้งค่า max-model-len ที่ต่ำลงอาจเหมาะกว่าสำหรับการดีพลอยแรกเริ่มและรองรับคอนเคอเรนซีที่สูงขึ้น

Is Kimi K3 open source?

ที่ถูกต้องกว่าคือ open-weight Moonshot เผยแพร่น้ำหนักโมเดลภายใต้ Kimi K3 License โปรดอ่านไลเซนส์โดยตรงก่อนการกระจายเชิงพาณิชย์หรือการใช้งานอื่นๆ ที่เงื่อนไขไลเซนส์มีผล

What is the easiest way to use Kimi K3 without local GPUs?

API แบบโฮสต์คือเส้นทางที่ง่ายที่สุด Kimi K3 มีให้ใช้ผ่าน CometAPI ด้วยอินเทอร์เฟซ chat-completions ที่เข้ากันได้กับ OpenAI ดังนั้นโค้ดแอปจึงใกล้เคียงกับที่ใช้กับเซิร์ฟเวอร์ vLLM หรือ SGLang แบบโลคอลอยู่แล้ว