วิธี self-host Kimi K3 ต้องใช้ทรัพยากรเท่าไหร่

สิ่งที่จำเป็นสำหรับการทำ self-host Kimi K3

การทำ self-host Kimi K3 หมายถึงการจัดหาพื้นที่สำหรับพารามิเตอร์จำนวน 2.8 ล้านล้านตัว Moonshot ได้เผยแพร่ open weights ในรูปแบบ MXFP4 ซึ่งมีขนาดประมาณครึ่งไบต์ต่อหนึ่งพารามิเตอร์ ดังนั้นเฉพาะตัว weights เพียงอย่างเดียวก็มีขนาดประมาณ 1.4 TB ก่อนที่คุณจะจัดสรรหน่วยความจำสำหรับ cache แม้แต่ token เดียว ปัจจุบันยังไม่มี accelerator รุ่นใดที่วางจำหน่ายในท้องตลาดสามารถรองรับข้อมูลขนาดนี้ได้ด้วยตัวเครื่องเดียว K3 จึงเป็นโมเดลแบบ multi-node และสำหรับเซิร์ฟเวอร์เพียงเครื่องเดียว คำตอบคือไม่สามารถทำได้

นั่นคือบทสรุปของเรื่องนี้ เนื้อหาทั้งหมดด้านล่างคือการคำนวณที่อยู่เบื้องหลังข้อสรุปดังกล่าว เนื่องจากคุณสามารถนำวิธีการคำนวณนี้ไปใช้กับรุ่นถัดไปได้ ผู้ให้บริการโครงสร้างพื้นฐานหลายรายได้เผยแพร่คู่มือการติดตั้ง K3 ในช่วงสัปดาห์หลังจากที่มีการประกาศเมื่อวันที่ 17 กรกฎาคม 2026 โดยแต่ละรายต่างตั้งสมมติฐานว่าคุณมี cluster อยู่แล้ว หน้าเว็บนี้จะเริ่มต้นจากอีกมุมมองหนึ่ง คือค่าใช้จ่ายที่เกิดขึ้น สิ่งที่คุณสามารถใช้งานทดแทนได้ และวิธีตรวจสอบว่าคุณอยู่ในสถานะใดระหว่างสองทางเลือกนี้

จำนวนพารามิเตอร์ทั้งหมดและพารามิเตอร์ที่ใช้งานจริงไม่เท่ากัน

K3 เป็นโมเดลประเภท Mixture of Experts (MoE) โดย MoE จะแบ่งโครงข่ายออกเป็นโครงข่ายย่อยจำนวนมากและใช้ตัวกำหนดเส้นทาง (router) เลือกใช้งานเพียงบางส่วนต่อหนึ่งโทเค็น โมเดลนี้ระบุพารามิเตอร์รวมไว้ที่ 2.8T และพารามิเตอร์ที่ถูกเรียกใช้งานจริง 104B ต่อโทเค็น จากผู้เชี่ยวชาญ (experts) ที่ถูกกำหนดเส้นทางไว้ 896 รายการ โดยจะมี 16 รายการที่ทำงานต่อหนึ่งโทเค็น กระจายอยู่บน 93 เลเยอร์

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

พารามิเตอร์ที่ใช้งานจริง (Active parameters) เป็นตัวกำหนดต้นทุนในการประมวลผล โทเค็นหนึ่งตัวจะถูกคูณผ่านพารามิเตอร์ประมาณ 104B ดังนั้นปริมาณงาน (throughput) ที่คุณควรคาดหวังจะใกล้เคียงกับโมเดลแบบ dense ขนาด 104B มากกว่าขนาด 2.8T ซึ่งนี่คือเหตุผลทั้งหมดในการสร้าง MoE ขึ้นมา

พารามิเตอร์ทั้งหมด (Total parameters) เป็นตัวกำหนดต้นทุนในการจัดเก็บข้อมูล ตัวกำหนดเส้นทางอาจเลือกผู้เชี่ยวชาญคนใดก็ได้สำหรับโทเค็นใดก็ตาม ดังนั้นผู้เชี่ยวชาญทุกคนจะต้องถูกโหลดไว้ในหน่วยความจำก่อนที่คำขอแรกจะมาถึง คุณไม่สามารถเก็บข้อมูล 104B ไว้ใน VRAM แล้วค่อยดึงส่วนที่เหลือมาใช้ตามความต้องการได้ เพราะการดึงข้อมูลจะต้องเสร็จสิ้นภายในระดับไมโครวินาที ในขณะที่การเชื่อมต่อผ่าน PCIe สามารถย้ายข้อมูลได้เพียงหลักสิบกิกะไบต์ต่อวินาทีเท่านั้น หลายคนพยายามทำเช่นนั้น การสตรีมผู้เชี่ยวชาญจาก NVMe จะทำให้โมเดลที่ควรจะสร้างโทเค็นได้หลายสิบตัวต่อวินาที กลายเป็นโมเดลที่สร้างได้เพียงหนึ่งโทเค็นในทุกๆ สองสามวินาที

ดังนั้น โมเดลนี้จึงมีต้นทุนการประมวลผลที่ต่ำแต่มีต้นทุนการจัดเก็บที่สูง ให้คุณเลือกขนาดฮาร์ดแวร์โดยอิงจาก 2.8T และคาดหวังความเร็วโดยอิงจาก 104B

จำนวนไบต์ต่อน้ำหนักและที่มาของหน่วยเทราไบต์

จำนวนพารามิเตอร์คูณด้วยจำนวนไบต์ต่อน้ำหนัก นี่คือสูตรทั้งหมดสำหรับน้ำหนัก

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 ถูกฝึกมาโดยคำนึงถึงการทำ quantisation และปล่อยออกมาพร้อมกับน้ำหนักแบบ MXFP4 และ activation แบบ MXFP8 ดังนั้นแถวที่ระบุว่าเป็น 4-bit จึงเป็นค่าที่แท้จริง ส่วนแถวที่อยู่ด้านบนมีไว้เพื่อเปรียบเทียบขนาดเท่านั้น: หากเป็น bf16 โมเดลเดียวกันนี้จะต้องการพื้นที่ 5.6 TB นอกจากนี้ MXFP4 ยังจัดเก็บค่า scale ขนาด 8-bit ที่ใช้ร่วมกันสำหรับทุกกลุ่มน้ำหนัก 32 ค่า ซึ่งเพิ่มขนาดขึ้นอีกประมาณ 6 เปอร์เซ็นต์ ดังนั้น repository ที่เผยแพร่อยู่จึงมีขนาดใกล้เคียง 1.5 TB มากกว่าที่จะเป็น 1.4 TB ตามทฤษฎี

ประเด็นนี้ปิดช่องทางหนีตามปกติไป การบอกว่า "แค่ทำ quantise ก็พอ" ไม่ช่วยในกรณีนี้ เพราะ checkpoint ที่ปล่อยออกมานั้นเป็น 4-bit อยู่แล้ว การลดลงไปเหลือ 2-bit จะทำให้น้ำหนักลดลงเหลือ 0.7 TB และต้องแลกมาด้วยความแม่นยำที่ยังไม่มีใครวัดผลได้สำหรับ checkpoint นี้ ซึ่งคุณก็จะยังคงต้องการทรัพยากรเกินกว่าที่การ์ดใบเดียวจะรับไหวอยู่ดี

Kimi K3 ต้องการ GPU จำนวนเท่าใด

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

ให้ถือว่าตัวเลขเหล่านี้เป็นค่าต่ำสุด ไม่ใช่ค่าเป้าหมาย ตัวเลขดังกล่าวคำนวณเฉพาะน้ำหนัก (weights) เท่านั้น โดยไม่รวม KV cache, activation buffers, การกระจายตัวของหน่วยความจำ (allocator fragmentation) และไม่มีพื้นที่เหลือสำหรับคำขอที่เข้ามาพร้อมกันรายการที่สอง นอกจากนี้ยังสมมติว่ามีการแบ่งแบบขนานที่หารลงตัว ซึ่งในความเป็นจริงจำนวน 93 เลเยอร์และ 896 ผู้เชี่ยวชาญ (experts) ไม่ได้เอื้อต่อการแบ่งเช่นนั้นเสมอไป

คำแนะนำที่เผยแพร่อยู่สูงกว่าค่าต่ำสุดเหล่านี้มาก ณ เดือนสิงหาคม 2026 Moonshot แนะนำให้ใช้ supernode ที่มี accelerator ตั้งแต่ 64 ตัวขึ้นไป และคู่มือ SGLang ได้ระบุการตั้งค่า H100 ที่สร้างจากโหนด 8-GPU จำนวน 4 โหนด รวมเป็น 32 GPU และหน่วยความจำรวม 2,560 GB ซึ่งสูงกว่าค่าต่ำสุดที่ 18 การ์ด ช่องว่างดังกล่าวไม่ใช่ความสูญเปล่า แต่เป็นพื้นที่สำหรับ KV cache, หน่วยความจำสำหรับ activation และ headroom ที่ช่วยให้เซิร์ฟเวอร์สามารถประมวลผลคำขอจำนวนมากพร้อมกันได้ แม้แต่แถวที่ดูเป็นมิตรที่สุดอย่างการ์ดระดับ 5 GB300 ก็ยังอธิบายถึงเครื่องที่ผู้ให้บริการส่วนใหญ่ไม่มีให้เช่าในรูปแบบ SKU เดียว

KV cache คือส่วนที่ทำให้หลายคนประหลาดใจ

Weights เป็นต้นทุนคงที่ แต่ KV (key value) cache ไม่ใช่ เพราะมันจะเพิ่มขึ้นตามความยาวของ context และเพิ่มขึ้นอีกตามจำนวนผู้ใช้งานพร้อมกัน สำหรับ attention แบบปกติ สูตรคำนวณคือ bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element จากนั้นให้นำไปคูณด้วยความยาวของ context และจำนวนผู้ใช้งานพร้อมกัน

นี่คือตัวอย่างการคำนวณ (เป็นเพียงตัวอย่างเท่านั้น): 64 layers, 8 KV heads, head dimension 128, fp8 ซึ่งจะได้ 2 64 8 128 1 = 131,072 bytes หรือเท่ากับ 128 KiB ต่อหนึ่ง token

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

ผู้ใช้งาน 1 รายที่ context 128k จะใช้หน่วยความจำ 16 GiB และผู้ใช้งาน 1 รายที่ context เต็มหนึ่งล้านจะใช้ 128 GiB ซึ่งมากกว่าที่การ์ดใบเดียวจะรองรับได้สำหรับการสนทนาเพียงรายการเดียว

K3 ไม่ได้ใช้ attention แบบปกติ และตัวเลขสุดท้ายนั้นคือเหตุผล โดยมี 93 layers แบ่งเป็น 69 KDA (Kimi Delta Attention) layers และ 24 Gated MLA (multi-head latent attention) layers ตัว KDA จะเก็บสถานะแบบ recurrent ที่มีขนาดคงที่แทนการใช้ cache ที่ขยายตัวตามทุก token ที่เพิ่มเข้ามา ส่วน MLA จะบีบอัด key และ value ให้เหลือเพียง latent vector อันดับต่ำหนึ่งชุด ดังนั้นต้นทุนจริงต่อ token จึงต่ำกว่าตัวอย่างที่คำนวณไว้มาก Moonshot ยังไม่ได้เปิดเผยขนาดของ latent dimensions ดังนั้นผมจึงจะไม่ระบุตัวเลขต่อผู้ใช้งานสำหรับ K3 โดยตรง ให้คุณวัดค่าด้วยตัวเองแทน: เริ่มต้น server ด้วย --max-model-len ขนาดเล็ก, ตรวจสอบหน่วยความจำด้วย nvidia-smi จากนั้นค่อยๆ เพิ่มขีดจำกัดจนกว่าการจองหน่วยความจำจะล้มเหลว

รูปแบบของการใช้เหตุผลจะยังคงอยู่ในการปล่อยรุ่นถัดไป หากโมเดลโฆษณาว่ารองรับ context หนึ่งล้าน token แต่ไม่ได้ระบุรายละเอียดเกี่ยวกับการออกแบบ attention ให้สันนิษฐานไว้ก่อนว่า cache คือข้อจำกัดหลักจนกว่าจะมีหลักฐานพิสูจน์เป็นอย่างอื่น

ระดับที่ 1: เช่าคลัสเตอร์แบบรายชั่วโมง

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

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

อัตราค่าบริการนี้เป็นการสมมติ ไม่ใช่ราคาเสนอจริง ราคาตามความต้องการ (on-demand) ของตัวเร่งความเร็วในศูนย์ข้อมูลอยู่ที่ประมาณ 2 ถึง 5 ดอลลาร์สหรัฐต่อ GPU ต่อชั่วโมงตลอดปี 2026 และความจุแบบจองล่วงหน้าจะมีราคาถูกกว่า ให้ใช้ตัวเลขจริงจากผู้ให้บริการของคุณแล้วคำนวณใหม่: จำนวน GPU คูณจำนวนชั่วโมง คูณอัตราค่าบริการ จุดประสงค์ของตารางนี้คือเพื่อแสดงสัดส่วน การใช้งานโหนดขนาด 8 GPU เป็นเวลาสี่ชั่วโมงต่อวันจะมีค่าใช้จ่าย 2,400 ดอลลาร์สหรัฐต่อเดือน ในขณะที่การเปิดทิ้งไว้ด้วยการตั้งค่า 32 GPU สำหรับ SGLang จะมีค่าใช้จ่าย 57,600 ดอลลาร์สหรัฐ

เซิร์ฟเวอร์หลักทั้งสองแบบจะระบุคำสั่งเปิดใช้งานไว้บน model card

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

คำสั่งพื้นฐานเหล่านั้นไม่ใช่สิ่งที่คุณใช้รันบนคลัสเตอร์จริง ให้เพิ่มแฟล็กการทำงานแบบขนาน (parallelism flags) ที่ตรงกับฮาร์ดแวร์ของคุณ: SGLang ใช้ --tp-size สำหรับ tensor parallel และ --ep-size สำหรับ expert parallel โดยผลคูณของค่าทั้งสองต้องเท่ากับจำนวน GPU ที่คุณมีจริง

ตรวจสอบว่าเซิร์ฟเวอร์ทำงานแล้วก่อนที่จะส่ง traffic จริงเข้าไป:

curl http://127.0.0.1:30000/v1/models

เซิร์ฟเวอร์ที่ทำงานปกติจะตอบกลับด้วย JSON object ที่ระบุ model id หากได้รับ Connection refused หมายความว่ากระบวนการกำลังโหลด weights หรือได้ปิดตัวลงไปแล้ว ดังนั้นให้อ่าน log ของเซิร์ฟเวอร์ก่อนที่จะลองใหม่

ความผิดพลาดที่พบบ่อยในวันแรกคือ runtime ที่เก่ากว่าตัวโมเดล K3 เปิดตัวพร้อมกับ KDA และเลเยอร์ MoE ใหม่ ซึ่ง vLLM และ SGLang เวอร์ชันเสถียรยังไม่มีในช่วงเปิดตัว อาการคือเซิร์ฟเวอร์จะปิดตัวลงระหว่างการเริ่มต้นพร้อมข้อความในรูปแบบ Model architectures [...] are not supported for now การแก้ไข config ไม่สามารถช่วยได้เนื่องจากโค้ดสำหรับรันเลเยอร์เหล่านั้นไม่มีอยู่ใน build ของคุณ ให้ติดตั้งเวอร์ชัน nightly ที่ระบุไว้ใน model card หรือรอเวอร์ชันที่รวมฟีเจอร์ดังกล่าว

ข้อควรระวังเรื่องค่าใช้จ่ายที่มักทำให้เกิดปัญหาคือ มิเตอร์จะเริ่มนับตั้งแต่ instance เริ่มทำงาน ไม่ใช่เมื่อโมเดลพร้อมใช้งาน การดาวน์โหลดข้อมูลขนาด 1.5 TB ที่ความเร็ว 1 GB/s จะใช้เวลาประมาณ 25 นาทีของเวลาคลัสเตอร์ก่อนที่จะได้ token แรก ให้จัดเก็บ weights ไว้ใน volume ที่คงอยู่ถาวรแม้ instance จะถูกลบ เพื่อให้การรันครั้งที่สองเริ่มต้นได้ภายในไม่กี่นาที

ระดับ 2: รันโมเดลขนาดเล็กบนตัวเร่งความเร็วหนึ่งตัว

คุณไม่ได้รัน K3 ในระดับนี้ ให้พูดประโยคนี้ออกมาดังๆ ก่อนเริ่ม เพราะกระทู้ "รัน K3 ในเครื่อง" ส่วนใหญ่จบลงที่จุดนี้โดยไม่ยอมรับความจริง

กฎการคำนวณขนาดโมเดลยังคงใช้สูตรเดิมในสเกลที่เล็กลง: จำนวนพารามิเตอร์คูณด้วยจำนวนไบต์ต่อค่าน้ำหนัก (weight) บวกด้วย KV cache และบวกด้วย overhead ของ runtime อีกประมาณ 2 GB ทั้งหมดนี้ต้องมีขนาดไม่เกิน VRAM ของคุณ ที่ระดับ 4-bit จะใช้พื้นที่ประมาณครึ่งไบต์ต่อหนึ่งพารามิเตอร์ ซึ่งทำให้เกิดการจับคู่ที่เหมาะสมดังนี้:

• การ์ด 16 GB: โมเดล 7B ที่ 4-bit โดยมีพื้นที่เหลือสำหรับ context ที่ยาวขึ้น
• การ์ด 24 GB: โมเดล 14B ที่ 4-bit
• การ์ด 48 GB: โมเดล 32B ที่ 4-bit
• การ์ด 80 GB: โมเดล 70B ที่ 4-bit หรือ MoE ระดับ 30B ที่ 8-bit

การจับคู่ข้างต้นทั้งหมดตั้งสมมติฐานว่ามีการประมวลผลทีละหนึ่งคำขอ หากมีคนที่สองส่ง prompt เข้ามาพร้อมกัน แต่ละช่องสัญญาณ (slot) จะต้องการ KV cache ของตัวเอง ซึ่งเป็นสิ่งที่ การตั้งค่า NUM_PARALLEL และ MAX_QUEUE ของ Ollama ช่วยจัดการให้คุณระหว่างการรันแบบขนาน, การต่อคิวคำขอ และ VRAM ที่เหลืออยู่

Ollama เป็นวิธีที่สั้นที่สุดในการรันเซิร์ฟเวอร์บน VPS ที่ติดตั้ง GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run จะดาวน์โหลดโมเดลในการใช้งานครั้งแรก จากนั้นจะเข้าสู่หน้า prompt หากระบุ tag ที่ไม่มีอยู่จริง ระบบจะคืนค่า Error: model "..." not found ดังนั้นให้คัดลอก tag จากหน้า library แทนการพิมพ์จากความจำ คู่มือฉบับเต็มรวมถึงการตั้งค่า systemd unit และการเข้าถึงจากระยะไกลอยู่ใน การรัน Ollama บน VPS

llama.cpp ช่วยให้คุณควบคุมการทำ quantisation และการ offload ได้มากขึ้น:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 เป็นการสั่งให้โหลดทุกเลเยอร์ลงบน GPU ให้ตรวจสอบ log การโหลด ระบบจะแสดงจำนวนเลเยอร์ที่ถูก offload ออกมา เลเยอร์ที่ล้นไปอยู่ใน RAM ของระบบจะทำงานด้วยแบนด์วิดท์ของ RAM แทนที่จะเป็นแบนด์วิดท์ของ HBM ดังนั้นความเร็วในการสร้างข้อความจะลดลงอย่างมากทันทีที่โมเดลไม่สามารถโหลดลง VRAM ได้ทั้งหมด ข้อดีข้อเสียของทั้งสองเครื่องมือนี้ครอบคลุมอยู่ใน การเปรียบเทียบ Ollama และ llama.cpp

ระดับ 3: Hosted API และ Self-hosted Orchestration

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Endpoint นี้รองรับมาตรฐาน OpenAI ดังนั้นไคลเอนต์ที่มีอยู่เดิมจะสามารถใช้งานได้ทันทีหลังจากที่คุณเปลี่ยน base URL

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

คีย์ที่ใช้งานได้จะส่งคืน JSON object พร้อมด้วยอาร์เรย์ choices หากได้รับ 401 แสดงว่าคีย์ไม่ถูกต้องหรือขาด prefix Bearer ไป ข้อผิดพลาดประเภท model-not-found มักเกิดจาก ID ของโมเดลมีการเปลี่ยนแปลง เนื่องจากผู้ให้บริการมักยกเลิกการใช้งาน ID เก่าระหว่างการอัปเดต checkpoint

มาดูจุดคุ้มทุนโดยใช้ค่าเช่าที่สมมติไว้ข้างต้น โหนดขนาด 8 GPU ที่เปิดใช้งานตลอดเวลาจะมีค่าใช้จ่าย 14,400 USD ต่อเดือน และที่ราคา 15.00 USD ต่อล้าน output tokens เงินจำนวนเท่ากันนี้จะซื้อ output tokens จาก API ได้ประมาณ 960 ล้าน tokens หากต้องการให้คุ้มทุน คุณต้องสร้าง output tokens ให้ได้ใกล้เคียงหนึ่งพันล้าน tokens ต่อเดือน หรือประมาณ 30 ล้าน tokens ต่อวัน และต้องใช้งานคลัสเตอร์อย่างต่อเนื่องตลอดเวลา เนื่องจาก GPU ที่ไม่ได้ใช้งานยังคงถูกคิดค่าบริการในอัตราเดียวกับช่วงที่ใช้งานหนัก งานประเภท agent ที่เน้น prompt จะยิ่งทำให้จุดคุ้มทุนขยับออกไปไกลขึ้นอีก เพราะ context ที่ถูกเรียกซ้ำจะถูกคิดค่าบริการในอัตรา cache-hit ที่ 0.30 USD ต่อล้าน tokens แทนที่จะเป็นอัตรา cache-miss ที่ 3.00 USD

สิ่งที่คุณทำ self-host ในระดับนี้คือทุกอย่างที่อยู่รอบตัวโมเดล ได้แก่ gateway ที่ทำหน้าที่เก็บ API key ไว้ไม่ให้หลุดไปถึงไคลเอนต์, การบันทึก log ของ request และ response, การทำ retry, การจำกัด rate limit และการจัดการงบประมาณต่อผู้ใช้งาน ซึ่งทั้งหมดนี้รันบน VPS ขนาดเล็กที่ไม่จำเป็นต้องมี GPU เลย การแบ่งส่วนในลักษณะเดียวกันนี้ยังใช้กับโมเดลแบบ closed weights ซึ่งการ self-hosting Claude ในระดับโมเดลนั้นไม่สามารถทำได้ และ orchestration เป็นเพียงส่วนเดียวที่คุณสามารถควบคุมเองได้

Stack การให้บริการแบบใดจัดอยู่ใน Tier ใด

vLLM และ SGLang จัดอยู่ใน Tier 1 โดยมีจุดประสงค์เพื่อรองรับคำขอจำนวนมากพร้อมกัน ด้วยเทคนิค continuous batching และ paged KV cache รวมถึงการทำ tensor และ expert parallelism กระจายข้ามหลายโหนด ระบบเหล่านี้ถูกออกแบบมาสำหรับ accelerator ในศูนย์ข้อมูลและต้องการการเชื่อมต่อระหว่างโหนดที่รวดเร็ว หากติดตั้งบนการ์ดจอสำหรับผู้บริโภคเพียงใบเดียว จะมีความซับซ้อนในการติดตั้งสูงและไม่เห็นความแตกต่างของประสิทธิภาพอย่างชัดเจน

llama.cpp และ Ollama จัดอยู่ใน Tier 2 โดยมุ่งเน้นการทำงานบนเครื่องเดียว รองรับการทำ GGUF quantisation, การย้ายภาระงานไปที่ CPU เมื่อโมเดลมีขนาดใหญ่เกินกว่าหน่วยความจำ และรองรับการทำงานแบบ concurrency ต่ำ ในทางเทคนิคแล้ว llama.cpp สามารถโหลดโมเดล MoE ขนาดใหญ่มากได้โดยเก็บเลเยอร์ส่วนใหญ่ไว้ใน system RAM ซึ่งสำหรับโมเดลขนาด 2.8T นั้น ความเร็วในการประมวลผลจะอยู่ที่ระดับหลายวินาทีต่อหนึ่ง token ซึ่งเป็นการพิสูจน์ว่าไฟล์สามารถอ่านได้จริง แต่ไม่ใช่บริการที่เหมาะสมสำหรับการเปิดให้ผู้ใช้งานทั่วไปเข้าถึง การเปรียบเทียบฉบับเต็มอยู่ใน Ollama เทียบกับ vLLM และข้อสรุปนี้ไม่เปลี่ยนแปลงตามประเภทของโมเดล โดยประเด็นสำคัญอยู่ที่ว่าคุณกำลังให้บริการผู้ใช้จำนวนมากบนฮาร์ดแวร์ที่ใช้ร่วมกัน หรือให้บริการผู้ใช้เพียงคนเดียวบนฮาร์ดแวร์ของคุณเอง

ตัวเลข 4 ประการที่สำคัญกว่าจุดตรวจสอบนี้

1. จำนวนพารามิเตอร์รวมคูณด้วยจำนวนไบต์ต่อค่าน้ำหนัก (weight) คือค่าต่ำสุดของหน่วยความจำที่ต้องใช้ ไม่มีสิ่งใดทำงานได้หากต่ำกว่าเกณฑ์นี้ และไม่มีเทคนิคการทำ quantisation ใดที่จะช่วยลดขนาดลงได้มากนักเมื่อ release นั้นเป็นแบบ 4-bit แล้ว
2. จำนวนพารามิเตอร์ที่ทำงานจริง (active parameters) เป็นตัวกำหนดระดับของ throughput โมเดลแบบ MoE ขนาด 2.8T ที่มีพารามิเตอร์ทำงานจริง 104B จะมีประสิทธิภาพการคำนวณเทียบเท่ากับโมเดลขนาด 104B
3. KV cache ต่อ token คูณด้วยความยาวของ context และคูณด้วยจำนวน concurrency คือต้นทุนที่เพิ่มขึ้นอย่างต่อเนื่องหลังจากที่คุณจ่ายค่าโหลดโมเดล (weights) ไปแล้ว
4. จำนวน tokens ต่อวินาทีต่อดอลลาร์ คือตัวเลขเดียวที่ใช้ตัดสินระดับของบริการ ข้อมูลทั้งหมดข้างต้นเป็นเพียงปัจจัยนำเข้าสำหรับตัวเลขนี้

ให้นำหลักการทั้ง 4 ประการนี้ไปใช้กับทุก release แล้วคุณจะได้คำตอบที่ถูกต้องก่อนที่จะเปิดคู่มือของผู้ให้บริการ จากนั้นให้ระบุวันที่กำกับตัวเลขทุกชุดที่คุณจดบันทึกไว้ เนื่องจากราคาและรายการสถาปัตยกรรมที่รองรับมีการเปลี่ยนแปลงภายในเวลา 2 สัปดาห์หลังจากที่ K3 เปิดตัว และตัวเลขทุกตัวในหน้านี้เป็นข้อมูลที่เผยแพร่ในเดือนกรกฎาคม 2026

FAQ

ฉันสามารถรัน Kimi K3 บน GPU ตัวเดียวได้หรือไม่?

ไม่ได้ น้ำหนักโมเดลมีขนาดประมาณ 1.4 TB ตามความละเอียด MXFP4 ที่ Moonshot ปล่อยออกมา ในขณะที่ตัวเร่งความเร็ว (accelerator) ตัวเดียวที่ใหญ่ที่สุดในตลาดมีความจุเพียง 288 GB โมเดลประเภท MoE ไม่สามารถดึงข้อมูล expert ที่ไม่ได้ใช้งานจากดิสก์ด้วยความเร็วที่ใช้งานได้จริง เนื่องจาก router อาจเลือก expert ตัวใดก็ได้ในทุก token และการดึงข้อมูลผ่าน PCIe นั้นใช้เวลานานเกินกว่าที่งบประมาณเวลาต่อ token จะอนุญาต การติดตั้ง Kimi K3 ที่เหมาะสมที่สุดคือการใช้โหนดแบบหลาย GPU โดยสูตรการตั้งค่าที่เผยแพร่แนะนำให้ใช้ตัวเร่งความเร็วตั้งแต่ 32 ตัวขึ้นไป

Kimi K3 ต้องการ VRAM เท่าใด?

เริ่มต้นที่ 1.4 TB สำหรับน้ำหนักโมเดลเพียงอย่างเดียว ซึ่งเทียบเท่ากับ H100 80GB จำนวน 18 ใบ หรือการ์ดระดับ GB300 จำนวน 5 ใบ จากนั้นต้องบวกหน่วยความจำสำหรับ KV cache และ activation เพิ่มเติม ณ เดือนสิงหาคม 2026 Moonshot แนะนำให้ใช้ตัวเร่งความเร็ว 64 ตัวขึ้นไป และคู่มือ SGLang ได้เผยแพร่การตั้งค่าที่ใช้ H100 จำนวน 32 GPU โดยมี VRAM รวม 2,560 GB ดังนั้นให้ถือว่าตัวเลขน้ำหนักโมเดลเป็นเพียงค่าขั้นต่ำ ไม่ใช่ความต้องการทั้งหมด

การทำ quantisation ช่วยให้ Kimi K3 รันบนโหนดเดียวได้หรือไม่?

ไม่สามารถใช้งานได้จริง Checkpoint ที่ปล่อยออกมาเป็นแบบ 4-bit ที่ผ่านการฝึกฝนด้วยเทคนิค quantisation-aware มาแล้ว ซึ่งเป็นการลดขนาดที่ทำได้ง่ายที่สุดไปแล้ว การลดลงไปเหลือ 2-bit จะทำให้น้ำหนักโมเดลเหลือ 0.7 TB ซึ่งยังคงมากกว่าความจุของการ์ดที่ใหญ่ที่สุดเกินสองเท่า และยังไม่มีการวัดผลกระทบด้านความแม่นยำที่เกิดจากการใช้ 2-bit กับโมเดลนี้

การเช่า GPU มีราคาถูกกว่าการใช้ Kimi K3 API หรือไม่?

เฉพาะในกรณีที่มีปริมาณการใช้งานสูงและต่อเนื่องเท่านั้น หากสมมติราคาที่ 2.50 USD ต่อ GPU ชั่วโมง โหนดขนาด 8 GPU ที่เปิดใช้งานตลอดเวลาจะมีค่าใช้จ่าย 14,400 USD ต่อเดือน ซึ่งเงินจำนวนเดียวกันนี้สามารถซื้อ output tokens ได้ประมาณ 960 ล้าน token ตามราคาที่ประกาศไว้ที่ 15.00 USD ต่อล้าน token นอกจากนี้คุณยังต้องจ่ายค่าชั่วโมงที่ไม่ได้ใช้งาน ค่าดาวน์โหลดน้ำหนักโมเดล และค่าจ้างบุคลากรที่ดูแลคลัสเตอร์ให้ทำงานได้ตลอดเวลา แนะนำให้เช่าเป็นรายชั่วโมงสำหรับช่วงที่มีการใช้งานสูง และเปรียบเทียบกับปริมาณ token ที่คุณวัดได้จริงแทนการคาดเดา

104B active parameters หมายความว่าอย่างไรในแง่ของความเร็ว?

หมายความว่าการคำนวณทางคณิตศาสตร์ต่อหนึ่ง token จะเท่ากับโมเดลขนาด 104B ดังนั้น throughput จึงอยู่ในระดับนั้น ไม่ใช่ระดับ 2.8T ข้อมูลนี้ไม่ได้บ่งบอกถึงหน่วยความจำ: พารามิเตอร์ทั้งหมด 2.8T จะต้องถูกโหลดไว้ในหน่วยความจำตลอดเวลา เพราะ router สามารถเรียกใช้ expert ตัวใดก็ได้ในทุก token ให้ใช้จำนวน active parameters ในการคาดการณ์จำนวน token ต่อวินาที และใช้จำนวนพารามิเตอร์ทั้งหมดในการคำนวณขนาด VRAM ที่ต้องใช้