ประมาณ VRAM ที่ LLM ต้องใช้ และตรวจว่าพอดีกับ GPU ของคุณหรือไม่
เปรียบเทียบต้นทุน API ต่อคำขอและรายเดือนของ OpenAI, Anthropic และ Gemini พร้อมวันที่ตรวจราคา
เปิด →วางเอกสารเพื่อดูการแบ่ง RAG และต้นทุน embedding แบบสด ข้อความไม่ถูกอัปโหลด
เปิด →แปลงหน่วยใน 12 หมวด เช่น ความยาว น้ำหนัก อุณหภูมิ พื้นที่ และปริมาตร
เปิด →ยังไม่มีความคิดเห็น มาเป็นคนแรกกันเลย!
เครื่องคำนวณ VRAM ของ LLM ประมาณหน่วยความจำที่คุณต้องใช้เพื่อ รัน โมเดลภาษาขนาดใหญ่ในเครื่องหรือโฮสต์เอง รวม ≈ น้ำหนัก + KV cache + ค่าโสหุ้ยรันไทม์ โดยน้ำหนัก = พารามิเตอร์ × บิตต่อน้ำหนัก ÷ 8 และ KV cache = 2 × จำนวนเลเยอร์ × KV head × มิติของ head × ไบต์ต่อองค์ประกอบ × บริบท × ซีเควนซ์พร้อมกัน เลือกโมเดล ควอนไทเซชัน และอุปกรณ์ แล้วเครื่องมือจะบอกว่าพอดีหรือไม่ ส่วนที่เหลือ บริบทที่ยาวที่สุดที่พอดี และเพดานความเร็วในการสร้าง
รวม ≈ น้ำหนัก + แคช KV + โอเวอร์เฮดขณะรัน น้ำหนัก = พารามิเตอร์ × บิตต่อน้ำหนัก ÷ 8 เช่น โมเดล 8 พันล้านพารามิเตอร์ต้องใช้ประมาณ 15 GiB ใน FP16 (16 บิต) และประมาณ 4.6 GiB ใน Q4_K_M (ประมาณ 4.9 บิต) แคช KV โตตามความยาวบริบทและจำนวนซีเควนซ์พร้อมกัน จึงควรตั้งค่าทั้งสอง
สำหรับทุกโทเคนที่ประมวลผล โมเดลเก็บ Key และ Value ของแต่ละเลเยอร์เพื่อไม่ต้องคำนวณใหม่ตอนสร้างข้อความ ขนาด = 2 × เลเยอร์ × หัว KV × มิติหัว × ไบต์ต่อองค์ประกอบ × ความยาวบริบท × ซีเควนซ์ จึงเป็นสัดส่วนกับความยาวบริบท โมเดลที่ใช้ grouped-query attention (หัว KV น้อยกว่า) หรือหน้าต่างเลื่อนต้องการน้อยกว่ามาก
บิตที่น้อยลงทำให้น้ำหนักเล็กลงและมักเร็วขึ้น แลกกับคุณภาพ Q8_0 ใกล้เคียงต้นฉบับ Q5_K_M และ Q6_K เป็นทางสายกลางที่พบบ่อย Q4_K_M เป็นจุดเริ่มต้นปกติเมื่อหน่วยความจำจำกัด และคุณภาพที่เสียไปจะสังเกตได้ต่ำกว่า Q3 ตารางแสดงว่าแต่ละระดับพอดีกับการตั้งค่าปัจจุบันของคุณหรือไม่
ต้องโหลดผู้เชี่ยวชาญทุกตัว น้ำหนักจึงใช้พารามิเตอร์ ทั้งหมด ไม่ใช่พารามิเตอร์ที่ทำงานต่อโทเคน แต่ความเร็วในการสร้างขึ้นกับพารามิเตอร์ที่ ทำงานอยู่ ซึ่งเป็นเหตุผลที่โมเดล MoE มักใช้หน่วยความจำมากแต่ไม่ได้ช้าเป็นพิเศษ
โดยปกติไม่ได้ ตามค่าเริ่มต้นระบบให้ GPU ใช้เพียงบางส่วนของหน่วยความจำรวม (ประมาณสองในสามถึงสามในสี่) การเลือก “หน่วยความจำรวมของ Apple” จึงถือว่า 75% ใช้ได้ เลือก “สัดส่วนที่ใช้ได้แบบกำหนดเอง” เพื่อให้ตรงกับการตั้งค่าจริงของคุณ
สมมติว่าน้ำหนักและแคช KV แบ่งเท่า ๆ กันข้ามการ์ด และแต่ละการ์ดรับโอเวอร์เฮดขณะรันคงที่ของตัวเอง ยอดรวมจึงสูงกว่าการ์ดเดียวเล็กน้อย การแบ่งจริง (แบบ tensor หรือ pipeline parallelism) และโอเวอร์เฮดการสื่อสารขึ้นกับเอนจิน ดังนั้นควรเผื่อไว้เพิ่ม
เป็นค่าประมาณสำหรับวางแผน เฉพาะ การอนุมาน (INFERENCE): น้ำหนัก แคช KV และโอเวอร์เฮดที่ปรับได้ การใช้งานจริงแตกต่างตามเอนจิน (vLLM, llama.cpp และอื่น ๆ) การทำแบตช์ เวอร์ชัน CUDA และการตั้งค่า paged-KV การฝึกและ fine-tune ต้องใช้หน่วยความจำมากกว่ามาก (เกรเดียนต์ สถานะออปติไมเซอร์ แอกติเวชัน) และอยู่นอกเครื่องมือนี้
การสร้างแต่ละโทเคนอ่านน้ำหนักที่ทำงานอยู่หนึ่งครั้ง ที่ขนาดแบตช์ 1 เพดานจึงประมาณ “แบนด์วิดท์หน่วยความจำ ÷ ไบต์น้ำหนักที่อ่านต่อโทเคน” เป็นขีดจำกัดตามทฤษฎีที่ละเลยขีดจำกัดการคำนวณ การอ่านแคช KV และโอเวอร์เฮดซอฟต์แวร์ ความเร็วจริงจึงมักต่ำกว่า และจะปรากฏหลังจากคุณกรอกแบนด์วิดท์ของอุปกรณ์เท่านั้น
| การควอนไทซ์ | bpw | น้ำหนัก | รวม | พอไหม? |
|---|---|---|---|---|
| FP32 | 32 | 29.92 GiB | 34.91 GiB | ไม่ |
| FP16 | 16 | 14.96 GiB | 18.45 GiB | ใช่ |
| Q8_0 | 8.5008 | 7.95 GiB | 10.74 GiB | ใช่ |
| FP8 | 8 | 7.48 GiB | 10.23 GiB | ใช่ |
| Q6_K | 6.5633 | 6.14 GiB | 8.75 GiB | ใช่ |
| Q5_K_M | 5.7036 | 5.33 GiB | 7.87 GiB | ใช่ |
| Q5_K_S | 5.5704 | 5.21 GiB | 7.73 GiB | ใช่ |
| Q4_K_M | 4.8944 | 4.58 GiB | 7.03 GiB | ใช่ |
| Q4_K_S | 4.6672 | 4.36 GiB | 6.80 GiB | ใช่ |
| Q3_K_L | 4.2979 | 4.02 GiB | 6.42 GiB | ใช่ |
| Q3_K_M | 3.996 | 3.74 GiB | 6.11 GiB | ใช่ |
| Q3_K_S | 3.6429 | 3.41 GiB | 5.75 GiB | ใช่ |
| Q2_K | 3.1593 | 2.95 GiB | 5.25 GiB | ใช่ |
ข้อกำหนดของโมเดลมาจากไฟล์ config.json ของ Hugging Face และเมทาดาทา safetensors (ตรวจสอบเมื่อ 2026-10-20) ค่า bpw ของการควอนไทซ์เป็นค่าที่วัดด้วย llama.cpp บน Llama-3.1-8B และต่างออกไปเล็กน้อยสำหรับโมเดลอื่น
นี่คือการประมาณเพื่อวางแผนหน่วยความจำที่ต้องใช้ในการรัน (อนุมาน) โมเดล ไม่ใช่การฝึกหรือไฟน์จูน การใช้งานจริงแตกต่างไปตามเอนจิน (vLLM, llama.cpp, TensorRT-LLM ฯลฯ) การทำแบตช์ และเวอร์ชัน CUDA โปรดเผื่อไว้บ้าง
