คู่มือเลือก Local LLM: ฮาร์ดแวร์ + โมเดล สำหรับ Agentic Coding

1 เลือกฮาร์ดแวร์ Local LLM

ก่อนหน้านี้ทางเลือกเดียวคือเอา GPU ของ NVIDIA มารัน Local LLM ตอนนี้มี 3 ก๊กใหญ่ ที่ใช้สถาปัตยกรรม Unified Memory Architecture (UMA)

    💡 UMA คืออะไร? Unified Memory Architecture — RAM ระบบและ VRAM ใช้ร่วมกันได้เลย ไม่ต้อง Offload ข้อมูลไปมาให้เกิดคอขวด ทำให้รันโมเดลใหญ่ๆได้สะดวกขึ้นมาก
  

    ⚡ TOPS คืออะไร? Tera Operations Per Second — หน่วยวัดพลังประมวลผลของชิป AI หมายถึงสามารถทำคำนวณได้กี่ ล้านล้านครั้งต่อวินาที (10¹² ops/sec)

    ยิ่ง TOPS สูง = ประมวลผล Prompt (Pre-fill) ได้ไวขึ้น = LLM ตอบกลับได้เร็วขึ้นในขั้นตอนแรก

    📌 DGX Spark = ~1,000 TOPS · Mac Studio (M-series) = ~32 TOPS · RTX 4090 = ~1,300 TOPS (เฉพาะ FP16)

3 ก๊กใหญ่ของ UMA

🍎 ก๊ก M (Apple)

Memory bandwidth สูงมาก (800+ GB/s)
Power efficient – ร้อนน้อยกว่าก๊กอื่น
UMA สูงสุดถึง 512 GB
ใช้งานทั่วไปได้ด้วย เหมือนคอมบ้านที่ไส้ในโหด

M1 → M6 Series

⚡ ก๊ก DGX Spark (NVIDIA)

พลังประมวลผลสูงสุด (1,000 TOPS)
เครื่องเล็ก พร้อม DGX OS + CUDA Stack
รองรับ NVFP4 (พระเอกของเรื่อง)
Scalable – ต่อ 2 ตัวได้ → 256 GB

NVIDIA, MSI, Lenovo, Gigabyte, Asus

🔴 ก๊ก Strix Halo (AMD)

ราคาจับต้องได้
Memory bandwidth ต่ำกว่า 2 ก๊กบน
พลังประมวลผลต่ำกว่าด้วย
ส่วนใหญ่เจอแต่ Notebook

ตัดออกได้เลย – ไม่สุดสักทาง

Mac Studio vs DGX Spark — ตัวไหนเร็วกว่า?

คำตอบคือ "มันต้องวัดทั้ง 2 อย่าง" เพราะการประมวลผล LLM แบ่งเป็น 2 ช่วง:

📝

Pre-fill (Prompt Processing)

ประมวลผล Prompt ทั้งหมดก่อน – ใช้ พลังการประมวลผล

DGX Spark ชนะ

→

⌨️

Token Generation

พิมพ์ผลลัพธ์กลับมา (TPS) – ใช้ Memory Bandwidth

Mac Studio ชนะ

Factor	🍎 Mac Studio	⚡ DGX Spark
Memory Bandwidth	800+ GB/s ✓	273 GB/s
พลังประมวลผล (TOPS)	~32 TOPS	1,000 TOPS ✓
RAM สูงสุด	512 GB ✓	128 GB (256 GB ถ้าต่อ 2)
NVFP4 (4-bit แม่นเทียบ 8-bit)	ไม่มี	มี ✓
การใช้งาน	GUI ง่าย ✓	SSH + Terminal เป็นหลัก
Fine-tune โมเดลเอง	ทำได้แต่ช้า	เร็วกว่า – CUDA Stack ✓

⚠️ จุดด้อยของ DGX Spark

SSH เข้าไปทำงานเกือบทั้งหมด
ร้อน – อุณหภูมิขึ้นได้ถึง 85°C ง่ายๆ (MSI เย็นกว่า Founder Edition ~5-10%)
RAM แค่ 128 GB – ยัดโมเดลใหญ่ๆแบบ FP16 ไม่ได้
ช่วงแรกอาจเจอ Kernel Panic / Hard Shutdown (OOM, Thermal)

2 Quantization – ย่อโมเดลให้รันได้

ปรับ slider เพื่อดูว่าโมเดลขนาดต่างๆ ต้องใช้ Memory เท่าไหร่ ในแต่ละระดับ Quantization

🧮 คำนวณ Memory ที่ใช้

ขนาดโมเดล (B) 122 B

Quantization

Memory ที่ใช้

~61 GB

ความแม่นยำ

~94.5%

เครื่องที่รันได้

DGX Spark 128GB ✓

หลักการ: Memory ที่ใช้ ≈ ขนาดโมเดล × bits ÷ 8 (เป็น GB) + KV cache overhead

เปรียบเทียบความแม่นยำของแต่ละ Quantization

FP16 (baseline)

100%

FP8 (8-bit)

99.9%

NVFP4 ⭐ DGX Spark

99.5%

FP4 ทั่วไป

~94.5%

    🎯 ทำไม NVFP4 ถึงเป็นพระเอก?

    เพราะ Quantize เป็น 4-bit แต่ความแม่นยำใกล้เคียง 8-bit (~99.5% vs ~94.5% ของ FP4 ทั่วไป) — เท่ากับใช้ Memory แค่ครึ่งเดียว แต่ฉลาดเกือบเท่าเดิม! และ DGX Spark รัน NVFP4 แบบ Native ที่ระดับ Hardware

3 เลือกโมเดลมาใช้ Agentic Coding

ดูแค่คะแนน SWE-bench ไม่พอ เพราะ โพยพวกนั้นเอาไปเทรนได้ มาดู 4 ปัจจัยที่สำคัญจริงๆ

📝 Code Quality – คุณภาพการเขียนโค้ด

ข้อนี้ง่ายที่สุด เพราะโมเดลทุกตัวที่เค้าบอกว่าเก่งๆ คือเก่งจริงทั้งนั้น ถ้าบอกโจทย์ดีๆ เขียนออกมาได้เป๊ะกลับกลับมาเหมือนกัน

⚠️ ไม่เกี่ยวกับความถูกต้องในภาพรวมโดยรวม — แค่หมายถึงว่าโค้ดแต่ละชิ้นเขียนออกมาดี

🧠 Reasoning – การคิด/วางแผน/Chain-of-Thought

สำคัญมากๆ! ต่อให้เขียนโค้ดดี แต่ถ้าตีโจทย์ผิด วางแผนผิด ก็กลายเป็นโค้ดใช้งานไม่ได้ทันที

ส่งผลโดยตรงไปถึงการหาและแก้ Bug ด้วย ถ้า Reasoning ดี = พุ่งเป้าไปต้นเหตุได้ถูก แก้ได้ไว

      ฟันธง: โมเดลแบบ Dense ส่วนใหญ่ทำ Reasoning ได้เก่งกว่า MoE
    

🛠️ Tools Calling – ม้ามืดของจริง

นี่คือจุดที่หลายโมเดล ตกม้าตาย แม้จะเก่งทั้ง Code Quality และ Reasoning

เครื่องมือ Agentic Coding (Claude Code, OpenCode CLI, Pi, etc.) ต้องการให้โมเดลส่งสัญญาณบอกว่า "ไปอ่านไฟล์นี้" หรือ "เขียนผลลัพธ์ลงไฟล์นี้" ถ้าโมเดลคุยกับเครื่องมือไม่รู้เรื่อง → ค้างกลางทาง

ตัวอย่างของจริง: Qwen3 35B → Reasoning เก่ง เขียนโค้ดเก่ง แต่ Tools Calling ห่วย ทำงานสเต็ปต่อเนื่องไม่ได้ ต้องพิมพ์ continue เอง

ในขณะที่ Qwen3-Coder-Next 80B ลื่นปรื๊ดๆๆ เพราะถูกเทรนมาเพื่องาน Agentic Coding โดยเฉพาะ

📚 Context Length – สำคัญน้อยสุด

บน DGX Spark ที่มี RAM 128 GB จะใช้ Context ได้ราวๆ 128k-256k เท่านั้น (เพื่อให้ KV Cache ได้หายใจ)

โมเดลพวกนี้รองรับขนาดนี้ได้สบายๆอยู่แล้ว

ถามว่ารับทั้ง Codebase ได้มั้ย? ไม่ได้ แต่ Coding Agent ฉลาดพอที่จะเลือกเฉพาะส่วนที่เกี่ยวข้องส่งไป

Dense vs MoE — เปรียบเทียบ

Dense Model — Generalist เป็ดโคตรๆ

มี Expert คนเดียวที่รู้ทุกอย่าง เวลาทำงานต้องประมวลผลจากทุกอย่างที่รู้

✅ Reasoning เก่งกว่า – เชื่อมโยงทุกอย่างได้รอบด้าน
✅ VRAM ที่ต้องใช้เล็กกว่า MoE
❌ ทำงานช้ากว่า MoE มาก

ตัวอย่าง: Qwen3.5 27B (Dense) — เขียนโค้ดดีกว่า Qwen3-Coder-Next 80B A3B แทบทุกอย่าง

โมเดลที่ผู้เขียนเลือกใช้

โมเดล	Type	Reasoning	Tools	ผล
Qwen3-Coder-Next 80B A3B	MoE	กาก	ดีเยี่ยม	❌ สอบตก งานหยาบ
Qwen3 35B A3B	MoE	เก่ง	คุยไม่รู้เรื่อง	⚠️ ต้อง continue เอง
Qwen3.5 27B (Dense)	Dense	เก่งมาก	ปานกลาง	⚠️ ช้าแต่ดี
Qwen3.5 27B Opus 4.6 Distilled	Dense	ดีขึ้น	สอบตก	⚠️ ยังไม่ใช่
lyf/Qwen3.5-27B-Uncensored-HauhauCS-Aggressive-NVFP4	Dense	เก่ง	ดี	⭐ ตัวที่ใช่

4 🎯 ช่วยตัดสินใจ

ตอบคำถาม 4 ข้อ เพื่อให้เราแนะนำว่าควรซื้อตัวไหน

คำถามที่ 1: คุณสะดวกกับ Terminal / SSH แค่ไหน?

5 💡 FAQ & ข้อคิดจากผู้ใช้จริง

มี 2 เหตุผลหลัก:

Cloud AI ราคาถูกชั่วคราว — OpenAI/Anthropic แบกต้นทุนเพื่อหาฐานผู้ใช้ พ้นช่วงโปรไปแล้วราคาจะพุ่งสูง
Cloud AI อัปเดทตามใจตัวเอง — เคยมีช่วงที่ Claude Code update แล้วโง่ลง ต้องไปใช้ Codex CLI แทน ถ้ามี Local LLM เราจูนจน Workflow ลงตัวแล้ว Freeze ใช้ไปยาวๆได้

RAM ไม่พอ ถ้าจะไปสาย Mac แนะนำ Mac Studio Ultra RAM 256GB ขึ้นไป เท่านั้น

EXO Lab ทดสอบเอา DGX Spark + Mac Studio ต่อกัน โดย:

DGX Spark ทำ Pre-fill (ใช้พลังประมวลผล)
ส่งต่อให้ Mac Studio ทำ Token Generation (ใช้ Memory Bandwidth)

แบบนี้ไวสุด เพราะใช้จุดเด่นของทั้ง 2 ก๊ก แต่ราคาก็... โหดสุดเช่นกัน 😅

เครื่องมือ = คนขับ — รถคันเดียวกัน คนขับคนละคน ขับขี่ไม่เหมือนกัน

ตัวเลือกในตลาด: Claude Code, Gemini CLI, OpenCode CLI, Qwen-code CLI, Cline CLI, Pi และอื่นๆ — แต่ละตัวมีวิธีจัดการ Context, Tools, Reasoning ต่างกัน ส่งผลต่อคุณภาพงานเอามากๆ

NVIDIA ตัดออกหลังจาก RTX 3090 — เพราะถ้ายังให้ผู้ใช้ทั่วไปต่อ GPU 2 ตัวได้ จะแย่งตลาด GPU เกรด Enterprise ที่ราคาสูงกว่ามาก

คู่มือเลือก Local LLMฮาร์ดแวร์ + โมเดล สำหรับ Agentic Coding