วิธีรัน GLM-5.3-Flash บนเครื่อง

รัน GLM-5.3-Flash ด้วยตัวเอง: ฮาร์ดแวร์ การควอนไทซ์ และต้นทุนจริง

GLM-5.3-Flash เป็นโมเดล 320 พันล้านพารามิเตอร์ภายใต้ใบอนุญาต MIT ซึ่งหมายความว่าคุณใช้งาน แก้ไข และเผยแพร่ซ้ำได้ แต่ขนาดของโมเดลก็ยังต้องการฮาร์ดแวร์ที่จริงจังสำหรับการรัน

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

จุดสำคัญคือมีพารามิเตอร์ที่ทำงานจริงเพียง 18B ต่อโทเค็น และมีเวอร์ชัน quantized ให้เลือก จึงสามารถรันบนเวิร์กสเตชันหรือระบบหลาย GPU ที่เล็กกว่าโหนด 8x H200 ได้ โดยข้อจำกัดหลักคือหน่วยความจำ ไม่ใช่ FLOPs

สิ่งที่ต้องโหลด

คุณสมบัติ	ค่า
พารามิเตอร์ทั้งหมด	320B
ทำงานต่อโทเค็น	18B
สถาปัตยกรรม	MoE, hybrid linear and sparse attention
บริบท	1,048,576 โทเค็น
ใบอนุญาต	MIT
น้ำหนักโมเดล	zai-org/GLM-5.3-Flash
GGUF quants	unsloth/GLM-5.3-Flash-GGUF

Mixture-of-Experts (MoE) ทำให้มี experts เพียงบางส่วนทำงานต่อโทเค็น แม้น้ำหนักทั้งหมด 320B จะต้องอยู่ในหน่วยความจำก็ตาม

Z.ai ระบุว่า KV cache มีขนาดเล็กกว่า GLM-5.3 ประมาณ 4.4 เท่า ซึ่งสำคัญมากสำหรับงานบริบทยาว อย่างไรก็ตาม KV cache ยังเพิ่มขึ้นตามความยาวบริบทและจำนวนคำขอพร้อมกัน

ระดับ 1: ความแม่นยำเต็มรูปแบบบนโหนดการผลิต

สำหรับคุณภาพเต็มรูปแบบและการให้บริการพร้อมกันจริง ให้ใช้ 8x H200 (141GB ต่อ GPU หรือรวมราว 1,128GB) หรือ 8x H20

น้ำหนักโมเดลต้องใช้พื้นที่ราว 700–800GB ตามความแม่นยำ และยังต้องเผื่อ KV cache กับ runtime overhead ค่าเช่าโหนดระดับนี้อยู่ที่ประมาณ $24–$48 ต่อวัน

vLLM

vLLM เป็นตัวเลือกทั่วไปที่มี ecosystem กว้าง ใช้ tensor parallel เป็นเลขยกกำลังของสอง:

vllm serve zai-org/GLM-5.3-Flash \
  --tensor-parallel-size 8 \
  --max-model-len 1048576 \
  --trust-remote-code

เริ่มด้วย --max-model-len ที่สั้นกว่าเพื่อยืนยันการตั้งค่าก่อน เพราะการขอ 1 ล้านโทเค็นจะจัดสรร KV cache ตามนั้นทันที และอาจจบด้วย out-of-memory

SGLang

SGLang รองรับโมเดลนี้ตั้งแต่วันแรก พร้อมสูตรสำหรับ H100, H200, B200, B300, GB200 และ GB300 รวมถึงงานมัลติโมดอล โดย Z.ai ใช้สแต็กที่อิง SGLang สำหรับการให้บริการก่อนเปิดตัว

python -m sglang.launch_server \
  --model-path zai-org/GLM-5.3-Flash \
  --tp 8 \
  --context-length 1048576

SGLang มักทำได้ดีสำหรับ structured output และ workload แบบ agentic ที่มี concurrency สูง ส่วน vLLM มีการรองรับ ecosystem ที่กว้างกว่า จึงควร benchmark ทั้งสองกับ workload จริงของคุณ

หากต้องใช้ function calling ให้ตรวจสอบและตั้งค่า tool-call parser ตามเอกสารเวอร์ชันปัจจุบันของแต่ละโปรเจกต์

ระดับ 2: รันเวอร์ชัน quantized บนฮาร์ดแวร์เล็กลง

unsloth/GLM-5.3-Flash-GGUF มี quantization แบบ 1-bit และ 2-bit เช่น IQ1_S และ IQ2_XXS ซึ่งทำให้โมเดล 320B สามารถรันบนเวิร์กสเตชัน RAM สูงหรือหลาย GPU ได้ โดยเฉพาะเมื่อ offload บางส่วนไป CPU

สิ่งที่ต้องระวัง:

• Quantization ที่รุนแรงลดคุณภาพจริง IQ1_S ห่างจากความแม่นยำเต็มรูปแบบมาก แม้โมเดล MoE อาจทนการลดทอนได้ดีกว่า dense model แต่ “รันได้” ไม่เท่ากับ “ใช้งานได้ดี” ให้ทดสอบกับงานจริงของคุณ
• คำแนะนำจาก Unsloth ยังเปลี่ยนแปลงได้ ตรวจสอบ quant ที่เผยแพร่และคำแนะนำล่าสุดก่อนออกแบบระบบ
• KTransformers เหมาะกับ CPU/hybrid setup เพราะเก็บ MoE experts ใน system RAM และย้ายเฉพาะส่วนจำเป็นไป GPU
• TokenSpeed เป็นอีก runtime ที่รองรับโมเดลนี้

ดูแนวทางพื้นฐานได้จากคู่มือ รัน GLM-4.7-Flash บนเครื่องของคุณ และ รัน GLM-5 บนเครื่องของคุณฟรี

คำนวณงบประมาณหน่วยความจำ

ประเมินจากสองส่วนนี้:

• น้ำหนักโมเดล: BF16 ใช้ประมาณ 2 ไบต์ต่อพารามิเตอร์ ดังนั้น 320B ใช้ราว 640GB ก่อน overhead; FP8 ลดลงราวครึ่งหนึ่ง; 4-bit เหลือประมาณ 160GB; 2-bit เล็กลงอีกแต่ลดคุณภาพมากขึ้น
• KV cache: เพิ่มตามความยาวบริบทและ concurrency ระบบที่รันได้ที่ 8K อาจล้มเหลวที่ 128K เพราะ KV cache ไม่ใช่น้ำหนักโมเดล

กำหนดขนาดระบบจากบริบทที่ใช้งานจริง ไม่ใช่ 1 ล้านโทเค็นที่โมเดลรองรับ แอปพลิเคชันส่วนใหญ่ไม่จำเป็นต้องจองบริบทเต็มขนาดนั้น

สำหรับข้อมูลเกี่ยวกับน้ำหนักแบบเปิดของตระกูลนี้ ดู โพสต์การโฮสต์ GLM-5.3 ด้วยตัวเอง ซึ่งเผยแพร่ก่อนรุ่น Flash จะเปิดน้ำหนักภายใต้ MIT

การปรับแต่งโมเดล

MIT อนุญาตให้ fine-tune และเผยแพร่ซ้ำได้ แต่ full fine-tuning ของโมเดล 320B ไม่เหมาะกับทีมส่วนใหญ่

แนวทางที่ใช้งานได้จริงคือ LoRA หรือวิธี parameter-efficient อื่น ๆ สำหรับ MoE คุณต้องเลือกว่าจะปรับ router, experts หรือ attention layers ซึ่งยังเป็นพื้นที่ที่มีแนวทางไม่ชัดเจนเท่า dense models

หากเป้าหมายคือ domain adaptation ให้ทดสอบ prompt engineering และ retrieval กับโมเดลพื้นฐานก่อน หน้าต่างบริบท 1 ล้านโทเค็นอาจทำให้การใส่ความรู้เฉพาะโดเมนใน prompt ถูกกว่าและเหมาะกว่าการฝึกโมเดล

Sampling settings

Z.ai แนะนำค่าตามประเภทงาน:

กรณีใช้งาน	temperature	top_p
ทั่วไป	1.0	0.95
การเขียนโค้ด	0.95	1.0

โมเดลรองรับ reasoning_effort สามระดับ: low, high และ max โดย max เป็นค่าเริ่มต้น บนฮาร์ดแวร์ท้องถิ่น

สำหรับการรันเอง ค่า reasoning มีผลโดยตรงต่อเวลาในการตอบ หากเครื่องสร้างคำตอบช้า ให้เริ่มทดสอบด้วย low

การโฮสต์เองคุ้มค่าหรือไม่?

โดยทั่วไปไม่คุ้มในแง่ต้นทุนล้วน ๆ

GLM-5.3-Flash มีราคา API ปกติ $0.15 ต่อหนึ่งล้านโทเค็นอินพุต ขณะที่โหนด 8x H200 ที่เช่าราว $1,000 ต่อเดือน เทียบเท่ากับการเรียก API ราว 6.7 พันล้านโทเค็นอินพุต คุณต้องมีการใช้งานสูงและต่อเนื่องมากเพื่อให้ค่าใช้จ่ายคงที่คุ้มกว่า API

เหตุผลที่ควร self-host จึงมักเป็น:

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

อ่านการเปรียบเทียบฝั่ง API เพิ่มเติมได้ที่ การวิเคราะห์ราคา GLM-5.3-Flash

ตรวจสอบการติดตั้ง

vLLM และ SGLang มี OpenAI-compatible endpoint จึงใช้รูปแบบคำขอเดียวกันกับเซิร์ฟเวอร์โลคัลและ Z.ai ได้:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "reply with OK"}]
  }'

นอกจาก smoke test ให้ทดสอบ:

• บริบทยาวตามความยาวที่ใช้งานจริง
• อินพุตรูปภาพสำหรับงานมัลติโมดอล
• tool calling ด้วย schema จริง
• throughput ภายใต้ concurrency จริง

ใช้ Apidog กับเซิร์ฟเวอร์โลคัลและ Z.ai โดยกำหนด Base URL เป็น environment variable จากนั้นรันชุดทดสอบเดียวกันกับทั้งสองปลายทาง วิธีนี้ช่วยตรวจสอบได้เร็วว่า quantized build ยังรองรับ tool schema ที่แอปพลิเคชันของคุณต้องใช้หรือไม่

คำถามที่พบบ่อย

• ฮาร์ดแวร์ขั้นต่ำคืออะไร? ความแม่นยำเต็มรูปแบบต้องใช้ 8x H200 ส่วน GGUF quantized ใช้ฮาร์ดแวร์น้อยกว่า แต่คุณภาพลดลงตามระดับ quantization
• ต้องเก็บ 320B ทั้งหมดในหน่วยความจำหรือไม่? ต้องเก็บ แม้จะมีเพียง 18B ที่ทำงานต่อโทเค็น หน่วยความจำคือข้อจำกัดหลัก
• vLLM หรือ SGLang ดีกว่า? SGLang รองรับโมเดลตั้งแต่วันแรกและมักดีสำหรับ concurrency กับ structured output; vLLM มี ecosystem กว้างกว่า ให้ benchmark ทั้งคู่กับ workload ของคุณ
• รันบน GPU เดียวได้หรือไม่? ไม่ได้สำหรับความแม่นยำเต็มรูปแบบ แต่ด้วย quantization หนักและ CPU offload ผ่าน KTransformers อาจทำได้บน GPU memory สูงพร้อม system RAM มาก โดยต้องยอมรับความเร็วที่ต่ำ
• ใบอนุญาตเป็น MIT จริงหรือไม่? ใช่ น้ำหนักโมเดลอยู่ภายใต้ MIT จึงอนุญาตให้ใช้เชิงพาณิชย์ แก้ไข และเผยแพร่ซ้ำได้