GPU สำหรับรัน LLM ต้องใช้ VRAM เท่าไร คำนวณยังไง

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

VRAM สำหรับรัน LLM คำนวณอย่างไร

VRAM ที่ต้องใช้รัน LLM เท่ากับผลรวมของสามก้อน คือน้ำหนักโมเดล (weights), KV cache ของข้อความที่กำลังประมวลผล และ overhead ของโปรแกรมที่รันโมเดล ถ้าผลรวมเกิน VRAM ของการ์ด โมเดลจะโหลดไม่ขึ้น หรือต้องย้ายบางส่วนไปไว้ใน RAM ของเครื่องซึ่งช้ากว่ามาก

VRAM     ≈ weights + KV cache + overhead
weights  = จำนวนพารามิเตอร์ × byte ต่อพารามิเตอร์
KV cache = 2 × layers × kv_heads × head_dim × byte ต่อค่า × จำนวน token
overhead ≈ เผื่อไว้ราว 10% ของ VRAM

• weights คือก้อนที่ใหญ่และคงที่ที่สุด ขนาดขึ้นกับจำนวนพารามิเตอร์และความละเอียดที่เก็บ 16-bit (BF16 หรือ FP16) ใช้ 2 byte ต่อพารามิเตอร์ 8-bit ใช้ 1 byte และ 4-bit ใช้ราวครึ่ง byte
• KV cache คือก้อนที่โตขึ้นระหว่างใช้งาน ยิ่ง context ยาวและยิ่งมีคำขอพร้อมกันหลายตัว ก็ยิ่งใหญ่
• overhead คือที่ที่ runtime ใช้เอง เช่น CUDA context และค่าระหว่างคำนวณ ตัวเลข 10% เป็นการเผื่อแบบหยาบ

ทางลัดสำหรับคนที่ใช้คนเดียวและ context ไม่ยาว คือเอาขนาดไฟล์โมเดลบวกเพิ่มอีกราว 20–30% แต่ถ้าจะให้ทีมใช้ร่วมกันหรือใช้กับ coding agent ต้องคิด KV cache ตามหัวข้อถัดไป

โมเดลแต่ละขนาดใช้ VRAM เท่าไรที่ 16-bit, 8-bit และ 4-bit

น้ำหนักของ LLM คิดได้ง่ายๆ ว่าพารามิเตอร์ 1 พันล้านตัว (1B) ใช้ราว 2 GB ที่ 16-bit, 1 GB ที่ 8-bit และ 0.5 GB ที่ 4-bit ตารางนี้เป็นขนาดน้ำหนักอย่างเดียวตามสูตร ยังไม่รวม KV cache และ overhead

ไฟล์จริงมักใหญ่กว่าสูตรเล็กน้อย ตัวอย่างจาก Hugging Face คือ Qwen3-32B ซึ่งมี 32.8B พารามิเตอร์ ไฟล์ BF16 รวมราว 65.5 GB, FP8 ราว 34.3 GB, AWQ 4-bit ราว 19.3 GB และ GGUF แบบ Q4_K_M ราว 19.8 GB ส่วนที่เกินจากสูตรมาจากบางชั้นที่ยังเก็บเป็น 16-bit และค่า scale ที่ quantization ต้องเก็บเพิ่ม ถ้ายังไม่แน่ใจว่า 4-bit แต่ละแบบต่างกันอย่างไร อ่านต่อที่ Quantization คืออะไร

โมเดลแบบ MoE (Mixture of Experts) ต้องระวังเป็นพิเศษ เพราะต้องโหลดพารามิเตอร์ทั้งหมดไว้ใน VRAM แม้แต่ละ token จะใช้แค่บางส่วน ตัวอย่างคือ gpt-oss-120b มีพารามิเตอร์รวม 117B แต่ active ต่อ token 5.1B การ์ดโมเดลระบุว่าลง GPU 80GB ใบเดียวได้ เพราะน้ำหนักส่วน MoE ถูกเก็บแบบ MXFP4 มาตั้งแต่ต้น ส่วน gpt-oss-20b รันได้ในหน่วยความจำ 16GB

KV cache คืออะไร ทำไม context ยาวกิน VRAM เพิ่ม

KV cache คือหน่วยความจำที่โมเดลใช้เก็บค่า key และ value ของทุก token ที่อ่านไปแล้ว เพื่อไม่ต้องคำนวณซ้ำทุกครั้งที่เขียน token ถัดไป ขนาดของ KV cache จึงโตตามความยาว context และจำนวนคำขอที่รันพร้อมกัน ในงานที่ context ยาวอย่าง coding agent ก้อนนี้อาจใหญ่พอๆ กับตัวโมเดล

ตัวเลขที่ต้องใช้อยู่ในไฟล์ config.json ของโมเดลบน Hugging Face ลองคิดกับ Qwen3-32B ซึ่งมี 64 layers, KV head 8 ตัว, head_dim 128 และเก็บ KV เป็น BF16 (2 byte)

KV ต่อ token = 2 × 64 × 8 × 128 × 2 byte
             = 262,144 byte ≈ 0.25 MB ต่อ token

8K token   ≈ 2 GB
32K token  ≈ 8 GB
128K token ≈ 32 GB

เลข 2 ตัวหน้าคือ key กับ value สังเกตว่า Qwen3-32B มี attention head 64 ตัว แต่มี KV head แค่ 8 ตัว เพราะใช้ grouped-query attention (GQA) ที่ให้หลาย head ใช้ KV ชุดเดียวกัน KV cache จึงเล็กลงหลายเท่า บางโมเดลใช้ sliding window หรือ attention แบบอื่นในบางชั้น KV cache จริงจึงเล็กกว่าสูตรนี้

ลองใส่ตัวเลขจริงสองกรณี

กรณีแรกรันได้ แต่ context รวมทั้งการ์ดราว 9K token พอสำหรับแชตคนเดียว แต่ไม่พอสำหรับ agent ที่ต้องเปิดอ่านหลายไฟล์ (ดูว่าทำไม agent กิน context เร็วใน Context window คืออะไร) ส่วนกรณีที่สอง 140K token นั้นแบ่งกันใช้ทุกคำขอ เช่น 4 เซสชันพร้อมกันที่ราว 32K ต่อเซสชัน

ถ้า KV cache ไม่พอ ทางแก้ที่ใช้บ่อยคือเก็บ KV เป็น 8-bit ซึ่งลดขนาดลงราวครึ่งหนึ่ง ใน vLLM ใช้ --kv-cache-dtype fp8 ส่วนใน llama.cpp ใช้ -ctk q8_0 -ctv q8_0 ควรทดสอบคุณภาพกับงานของตัวเองก่อนใช้จริง

ทำไม memory bandwidth สำคัญพอๆ กับขนาด VRAM

memory bandwidth คือความเร็วที่ GPU อ่านข้อมูลจาก VRAM ได้ต่อวินาที ในช่วง decode ที่โมเดลเขียนคำตอบทีละ token โมเดลแบบ dense ต้องอ่านน้ำหนักทั้งก้อนหนึ่งรอบต่อ token หนึ่งตัว ความเร็วในการตอบของผู้ใช้คนเดียวจึงถูกจำกัดด้วย bandwidth มากกว่าพลังคำนวณ

เพดาน token/วินาที (คนเดียว) ≈ memory bandwidth ÷ ขนาดน้ำหนักที่อ่านต่อ token

ตัวอย่างกับ Qwen3-32B ที่ 4-bit (ราว 19 GB) บนการ์ดต่างรุ่น

ตัวเลขจริงจะต่ำกว่านี้ เพราะต้องอ่าน KV cache ด้วย ตารางนี้ใช้เทียบการ์ดกันเท่านั้น ส่วนช่วง prefill ที่อ่าน prompt ทั้งก้อนพร้อมกัน ใช้พลังคำนวณเป็นหลัก

ข้อนี้อธิบายอีกสองเรื่อง เรื่องแรก โมเดล MoE ตอบเร็วกว่าโมเดล dense ที่ขนาดรวมเท่ากัน เพราะแต่ละ token อ่านเฉพาะพารามิเตอร์ส่วนที่ active เรื่องที่สอง เซิร์ฟเวอร์ที่รับหลายคำขอพร้อมกันอ่านน้ำหนักหนึ่งรอบแล้วใช้เขียน token ให้หลายคำขอได้ throughput รวมจึงสูงกว่าตัวเลขในตารางมาก แลกกับ VRAM ที่ต้องเผื่อให้ KV cache ของทุกคำขอ นี่คือหลักที่ inference server ใช้ อ่านต่อได้ที่ vLLM คืออะไร

การ์ดจอรุ่นไหนรัน LLM ได้ เทียบ RTX 4090, RTX 5090, H100

การ์ดสำหรับรัน LLM แบ่งคร่าวๆ เป็นสามกลุ่ม คือการ์ดเกม GeForce ที่ VRAM 16–32 GB, การ์ดเวิร์กสเตชันที่ VRAM ถึง 96 GB และการ์ด data center ที่ VRAM 48–141 GB ในตารางนี้ ซึ่งรุ่นที่ใช้หน่วยความจำ HBM มี bandwidth สูงกว่ามาก สเปกในตารางตรวจจากหน้าของ NVIDIA ณ พฤศจิกายน 2569 ส่วนคอลัมน์สุดท้ายเป็นตัวอย่างโดยประมาณจากสูตรข้างบน

สิ่งที่ควรรู้ก่อนเลือก

• การ์ดเกมคุ้มสำหรับลองและใช้คนเดียว RTX 5090 ให้ VRAM 32 GB และ bandwidth 1,792 GB/s เท่ากับ RTX PRO 6000 แต่ VRAM น้อยกว่าสามเท่า
• การ์ด data center อย่าง H100 และ H200 ใช้หน่วยความจำ HBM bandwidth จึงสูงกว่าการ์ดเกมราว 2–5 เท่า และรุ่น SXM ติดตั้งบนบอร์ดเซิร์ฟเวอร์ ซื้อมาเสียบเครื่องทั่วไปไม่ได้ คนส่วนใหญ่จึงเช่าเป็นรายชั่วโมง
• เครื่องที่ใช้ unified memory อย่าง DGX Spark (NVIDIA ระบุว่ารันโมเดลได้ถึง 200B พารามิเตอร์) หรือ Mac รุ่น Apple Silicon โหลดโมเดลใหญ่ได้ แต่ bandwidth ต่ำกว่า จึงตอบช้ากว่า ดูวิธีตั้งค่าบนเครื่องตัวเองใน รัน LLM บนเครื่องตัวเองด้วย Ollama และ LM Studio

ถ้ายังลังเลระหว่างซื้อการ์ดกับเช่า GPU ต่อชั่วโมง ดูการคำนวณเป็นเงินบาทได้ที่ ต้นทุน AI Inference

ใช้การ์ดหลายใบรวมกันรัน LLM ได้ไหม

ได้ inference server ส่วนใหญ่แบ่งโมเดลไปไว้บนการ์ดหลายใบได้ เช่น vLLM ใช้ tensor parallel ผ่าน --tensor-parallel-size และ llama.cpp แบ่งชั้นของโมเดลไปตามการ์ดผ่าน --split-mode แต่การ์ด 24 GB สองใบไม่ได้เท่ากับการ์ด 48 GB ใบเดียวเสียทีเดียว เพราะการ์ดต้องส่งข้อมูลหากันระหว่างคำนวณ และแต่ละใบมี overhead ของตัวเอง

# vLLM: แบ่งโมเดลไป 2 การ์ดแบบ tensor parallel
vllm serve Qwen/Qwen3-32B-FP8 --tensor-parallel-size 2

# llama.cpp: แบ่งชั้นของโมเดลไปตามการ์ด (layer เป็นค่าเริ่มต้น)
llama-server -m Qwen3-32B-Q4_K_M.gguf --split-mode layer -ngl all

เรื่องที่ทำให้ผลต่างกันมาก

1. ทางเชื่อมระหว่างการ์ด หน้าสเปกของ NVIDIA ระบุว่า H100 SXM เชื่อมกันด้วย NVLink 900 GB/s ส่วน PCIe Gen5 ได้ 128 GB/s การ์ด GeForce คุยกันผ่าน PCIe จึงเหมาะกับการแบ่งแบบ layer ที่ส่งข้อมูลหากันน้อยกว่า
2. จำนวนการ์ด tensor parallel มักใช้ 2, 4 หรือ 8 ใบ ให้หารจำนวน attention head ของโมเดลลงตัว
3. การ์ดต่างขนาดกัน llama.cpp กำหนดสัดส่วนให้แต่ละใบได้ด้วย --tensor-split เช่น 3,1
4. KV cache ก็ถูกแบ่งไปด้วย การ์ดหลายใบจึงช่วยให้ context ยาวขึ้นหรือรับผู้ใช้พร้อมกันได้มากขึ้นด้วย

ไม่อยากซื้อการ์ดเอง buzzAI ใช้ GPU แบบไหน

buzzAI เป็น API สำหรับ coding agent ที่รันโมเดล open-weight Qwen3.8-27B ในรุ่น NVFP4 (4-bit) ที่ NVIDIA ทำจากโมเดลนี้ บนการ์ด GPU ที่ buzzAI ดูแลเอง ใส่ชื่อโมเดลนี้ได้ตรงๆ ที่ base URL https://api.heybuzzai.com/v1 ใช้กับ Claude Code, Codex CLI และเครื่องมือที่ตั้ง base URL เองได้แบบ OpenAI-compatible ตอนนี้งานประมวลผลอยู่บนเซิร์ฟเวอร์ GPU ของผู้ให้บริการคลาวด์ในต่างประเทศ ส่วนแพ็ก Dedicated ที่ได้การ์ดทั้งใบสำหรับลูกค้ารายเดียว (เสนอราคาแยก) วางเครื่องในไทยได้

แพ็กเป็นแบบเหมาจ่าย ไม่คิดค่า token และไม่มีโควตารายวันหรือรายสัปดาห์ สิ่งที่จำกัดแทนคือเรื่องเดียวกับที่บทความนี้อธิบาย คือจำนวน agent ที่รันพร้อมกัน ขนาด context ตามแพ็ก (64K ถึง 256K) และคิวในช่วงที่คนใช้เยอะ API ยังไม่เปิดให้ใช้ทั่วไป กดขอร่วมทดสอบได้ที่หน้าแรก แล้วเราจะส่ง API key ทางอีเมลเมื่อมีผู้สมัครครบโควต้าที่กำหนด ดูแพ็กทั้งหมดที่หน้าราคา