คนส่วนใหญ่เดาขนาด RAM เอาเอง ไม่ซื้อเกินจำเป็น “เผื่อไว้ก่อน” ก็ได้รู้จัก OOM killer ตอนตีสาม ที่จริงหน่วยความจำเป็นสิ่งที่เลือกขนาดง่ายที่สุดอย่างหนึ่ง เพราะงานต่าง ๆ คาดเดาได้เมื่อคุณรู้ตัวเลขคร่าว ๆ นี่คือตัวเลขเหล่านั้น ตั้งแต่เครื่อง 1 GB สำหรับบอทไปจนถึงเซิร์ฟเวอร์ 64 GB ที่คนค้นหาเมื่ออยากรันโมเดลขนาดใหญ่ในเครื่องตัวเอง
ตัวเลขคร่าว ๆ ตามประเภทงาน
นี่คือค่าจริงในสภาวะคงที่สำหรับการตั้งค่าทั่วไป ไม่ใช่ขั้นต่ำที่ผู้พัฒนาซอฟต์แวร์ระบุ
| ประเภทงาน | RAM ที่ใช้จริง | แพ็กเกจที่เหมาะ |
|---|---|---|
| บอท Telegram/Discord (Python, Node.js) | 100–300 MB | Nano 1 GB |
| เว็บสแตติก + Caddy/Nginx | 50–150 MB | Nano 1 GB |
| WordPress + MariaDB ทราฟฟิกปกติ | 0.8–1.5 GB | Micro-IP 2 GB |
| PostgreSQL สำหรับแอปขนาดเล็ก | 0.5–2 GB (คุณกำหนดผ่าน shared_buffers) | Micro / Small |
| n8n กับเวิร์กโฟลว์ไม่กี่ตัว | 0.5–1.5 GB | Micro 2 GB |
| โฮสต์ Docker ที่มีบริการเล็ก 5–10 ตัว | 2–4 GB | Small 4 GB |
| Coolify + build + ฐานข้อมูล | 3–4 GB | Small-IP 4 GB |
| LLM 7–8B, 4 บิต, ประมวลผลบน CPU | 5–6 GB | Medium 6 GB |
| LLM 14B, 4 บิต | ~10 GB | Pro-32 |
| LLM 32B, 4 บิต | ~20 GB | Pro-32 |
| LLM 70B, 4 บิต | ~40–45 GB | Pro-48 / Pro-64 |
มีสองเรื่องที่น่าสังเกต หนึ่ง ช่องว่างระหว่างงาน “ปกติ” กับ LLM ใหญ่มาก: บอทกับโมเดล 70B ต่างกันถึงสองร้อยเท่า สอง บริการส่วนใหญ่ทำงานได้ดีด้วย 1–4 GB คนซื้อเกินเพราะเลือกขนาดเผื่ออนาคตที่แทบไม่เคยมาถึง
สูตรสำหรับ LLM
สำหรับโมเดลภาษา มีวิธีประมาณง่าย ๆ คือ จำนวนพารามิเตอร์ × จำนวนบิตต่อน้ำหนัก ÷ 8 บวกส่วนเพิ่ม โมเดล 8B ที่ราว 4.5 บิต (quantization แบบ Q4 ทั่วไป) คือ 8 × 4.5 ÷ 8 ≈ น้ำหนัก 4.5 GB บวก 1–2 GB สำหรับหน้าต่างบริบท (KV cache โตตามความยาวบริบท) และรันไทม์ คุณจะได้ 5–6 GB
ส่วนที่ต้องพูดตามจริง: บนเซิร์ฟเวอร์ที่มีแต่ CPU หน่วยความจำเป็นแค่ครึ่งเดียวของเรื่องราว คาดว่าจะได้ไม่กี่โทเค็นต่อวินาทีสำหรับโมเดล 7–8B บน vCPU ไม่กี่ตัว และราวหนึ่งโทเค็นต่อวินาทีสำหรับ 70B ซึ่งเพียงพอสำหรับงานแบบ batch เอเจนต์เบื้องหลัง และการทดลองส่วนตัว แต่ไม่ใช่ประสบการณ์แชตสำหรับผู้ใช้จำนวนมากพร้อมกัน หากคุณเรียก API ของโมเดลที่โฮสต์ไว้เป็นหลัก เอเจนต์ของคุณต้องการทรัพยากรน้อยกว่ามาก: ดู การเลือกขนาด VPS สำหรับเอเจนต์ AI
วัดแทนการเดา
ถ้าคุณมีเซิร์ฟเวอร์อยู่แล้ว ตัวเลขอยู่ตรงนั้นเลย:
free -h # look at "available", not "free"
ps aux --sort=-rss | head -n 8 # the biggest processes, by resident memory
docker stats --no-stream # per-container usage
Linux ใช้ RAM ที่ว่างเป็นแคชดิสก์ ค่า “free” จึงน้อยเสมอ และนั่นเป็นเรื่องปกติ ตัวเลขที่สำคัญคือ available: หน่วยความจำที่เคอร์เนลให้โปรแกรมได้ทันที ถ้า available อยู่เหนือ ~25% ในชั่วโมงที่ยุ่งที่สุด แสดงว่าขนาดพอดีแล้ว ถ้ามันลงไปถึงศูนย์บ่อย ๆ และ swap เพิ่มขึ้น ให้อัปเกรด
ตรวจดูด้วยว่าเคยมีการถูก OOM kill หรือไม่:
journalctl -k | grep -i "out of memory"
Swap: เข็มขัดนิรภัย ไม่ใช่เครื่องยนต์
ไฟล์ swap ขนาด 1–2 GB บนเซิร์ฟเวอร์เล็กเป็นประกันราคาถูก: การอัปเดตแพ็กเกจหรือการ build Docker ที่ต้องการหน่วยความจำเพิ่มชั่วครู่จะรอดแทนที่จะถูกหยุด แต่ถ้าบริการใดอยู่ใน swap ทุกคำขอจะต้องรอดิสก์ Swap มีไว้สำหรับช่วงพีก การ swap ตลอดเวลาแปลว่าคุณต้องใช้แพ็กเกจถัดไป
แล้วควรซื้อเท่าไร?
- 1 GB: บอทหนึ่งตัว API เล็กหนึ่งตัว เว็บสแตติกหนึ่งเว็บ
- 2 GB: ค่าเริ่มต้นที่สมเหตุสมผลสำหรับทุกอย่างที่มีฐานข้อมูลหรือ Docker
- 4–6 GB: หลายบริการบนเครื่องเดียว build บนเซิร์ฟเวอร์ หรือโมเดลเล็กในเครื่อง
- 32–64 GB: เฉพาะเมื่อมีสิ่งใหญ่ที่ต้องอยู่ในหน่วยความจำ: โมเดลในเครื่องที่ใหญ่กว่า 14B ดัชนี RAG ขนาดใหญ่ หรือกลุ่มเอเจนต์ นี่คือสิ่งที่ แพ็กเกจหน่วยความจำสูง มีไว้รองรับ
เริ่มจากขนาดที่เล็กกว่าที่สัญชาตญาณบอกหนึ่งขั้น ดู free -h ไปหนึ่งสัปดาห์ แล้วอัปเกรดถ้าตัวเลขบอกเช่นนั้น ที่ EQVPS การอัปเกรดแพ็กเกจจะเก็บข้อมูลของคุณไว้และคิดเงินเฉพาะส่วนต่างตามสัดส่วน (การเปลี่ยนแพ็กเกจทำงานอย่างไร)
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกสิ