VPS ต้องใช้ GPU เมื่อไร หรือ CPU ก็พอ

คุณจำเป็นต้องใช้ VPS ที่มี GPU หรือ CPU ก็เพียงพอ

VPS ที่มี GPU เปลี่ยน 2 เรื่องเมื่อคุณรันโมเดลด้วยตนเอง ได้แก่ ความเร็วในการสร้างโทเค็น และขนาดโมเดลสูงสุดที่สามารถจัดเก็บในหน่วยความจำได้ ส่วนอื่นไม่เปลี่ยนแปลง หากภาระงานของคุณคือโมเดลแชตแบบ quantized ขนาด 7B ถึง 27B ที่ตอบผู้ใช้ทีละ 1 คน งานสร้าง embedding ในปริมาณไม่มาก หรือการถอดเสียงด้วย Whisper small VPS ที่ใช้ CPU ทั่วไปและมี RAM เพียงพอก็สามารถทำงานได้แล้ว ให้เริ่มจาก CPU วัดค่าที่เป็นปัญหาสำหรับคุณ แล้วจึงปรับไปใช้ทรัพยากรระดับสูงขึ้น

สาเหตุคือแบนด์วิดท์หน่วยความจำ เมื่อ language model สร้างโทเค็น 1 รายการ โมเดลจะอ่าน weight ที่จำเป็นทั้งหมดจากหน่วยความจำ โมเดลขนาด 8B ที่ทำ quantization เป็น 4 bits มีขนาดบนดิสก์ประมาณ 4.7 GB และมีขนาดในหน่วยความจำใกล้เคียงกัน ดังนั้นการสร้างโทเค็น 1 รายการจึงต้องย้ายข้อมูลประมาณ 4.7 GB หารแบนด์วิดท์หน่วยความจำของเครื่องด้วยตัวเลขดังกล่าว แล้วคุณจะได้ขีดจำกัดของจำนวนโทเค็นต่อวินาที การหารเพียงครั้งเดียวนี้อธิบายผลการทดสอบประสิทธิภาพเกือบทั้งหมดที่คุณจะพบ

GPU ให้อะไรกับคุณบ้างในทางปฏิบัติ

แบนด์วิดท์ หน่วยความจำ DDR5 ของเซิร์ฟเวอร์บนโฮสต์รุ่นใหม่สามารถถ่ายโอนข้อมูลได้หลายสิบกิกะไบต์ต่อวินาที หน่วยความจำ GPU (VRAM หรือ video RAM) สามารถถ่ายโอนได้ตั้งแต่หลายร้อยกิกะไบต์ต่อวินาทีไปจนถึงมากกว่า 1,000 กิกะไบต์ต่อวินาที อัตราส่วนนี้คือความเร็วที่เพิ่มขึ้น และมีขนาดใหญ่

ความจุพร้อมความเร็ว เครื่อง CPU ที่มี RAM 64 GB สามารถโหลดโมเดล 70B แบบ 4 บิตได้ โมเดลจะทำงานได้ แต่มีความเร็วใกล้เคียงกับการอ่านมากกว่าการสนทนา GPU จะช่วยในกรณีนี้ได้ก็ต่อเมื่อโมเดลมีขนาดพอดีกับ VRAM เพราะทันทีที่บางเลเยอร์ล้นไปยัง system RAM เส้นทางการทำงานที่ช้ากว่าจะกลับมาควบคุมความเร็วอีกครั้ง

ปริมาณงานแบบแบตช์ นี่คือส่วนที่ผู้คนมักประเมินต่ำเกินไป GPU ที่สร้างผลลัพธ์ให้ผู้ใช้ 1 รายจะปล่อยให้ความสามารถในการประมวลผลส่วนใหญ่ไม่ได้ใช้งาน เนื่องจากกำลังรอการอ่านข้อมูลจากหน่วยความจำ หากให้บริการคำขอ 20 รายการพร้อมกัน การอ่าน weight ชุดเดียวกันจะให้บริการคำขอทั้ง 20 รายการ อัตรา tokens per second รวมจะเพิ่มขึ้นหลายเท่า ขณะที่ความเร็วของผู้ใช้แต่ละรายลดลงเพียงเล็กน้อย CPU ไม่สามารถทำเช่นนี้ได้ ผู้ใช้พร้อมกัน 2 รายบนเครื่อง CPU จะแบ่งความสามารถในการประมวลผลของกันและกันจนความเร็วลดลงประมาณครึ่งหนึ่ง หากคุณกำลังสร้าง API ที่ไคลเอ็นต์จำนวนมากเรียกใช้งาน การประมวลผลแบบแบตช์คือเหตุผลสำคัญที่ควรใช้ GPU และมีน้ำหนักมากกว่าความเร็วของการประมวลผลสตรีมเดียว

การประมวลผลพรอมต์ การอ่านพรอมต์ที่ยาวเป็นงานที่ติดข้อจำกัดด้านการประมวลผล ไม่ใช่งานที่ติดข้อจำกัดด้านหน่วยความจำ และเป็นจุดที่ GPU เหนือกว่าอย่างชัดเจนที่สุด context ขนาด 30,000 token ซึ่ง CPU ใช้เวลา 1 นาทีในการประมวลผล จะใช้เวลาเพียงไม่กี่วินาทีบน GPU ระบบ Retrieval ที่ใส่เอกสารจำนวนมากลงในทุกคำขอจะได้รับผลกระทบจากความแตกต่างนี้อยู่ตลอดเวลา

ตัวเลขโดยประมาณและวิธีอ่านตัวเลข

บล็อกด้านล่างแสดงค่าทั่วไปที่มีการเผยแพร่สำหรับการประมวลผลแบบสตรีมเดียวของโมเดล 8B ที่ใช้ quantization แบบ 4-bit ณ เดือน July 2026 ตัวเลขเหล่านี้ใช้เป็นแนวทางตามระดับขนาดเท่านั้น ไม่ใช่การรับประกัน ค่า quantization, ความยาว context และ inference engine ที่ใช้จะทำให้ตัวเลขเปลี่ยนแปลงได้

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

แถว GPU ขนาด 24 GB แสดงความเร็ว 50 tokens ต่อวินาที เทียบกับ 11 สำหรับเครื่อง CPU ที่ใช้ DDR5 ค่านี้เร็วขึ้นประมาณห้าเท่า ซึ่งสอดคล้องกับอัตรา bandwidth มากกว่าความแตกต่างของ raw compute ทรูพุตจริงยังต่ำกว่าค่าที่คำนวณจาก bandwidth หารด้วยขนาดโมเดล เนื่องจากการประมวลผล attention บน context ที่เพิ่มขึ้นต้องใช้ทรัพยากรเพิ่มเติม ซึ่งการหารแบบง่ายไม่ได้คำนึงถึง

เพื่อใช้เปรียบเทียบ คนทั่วไปอ่านได้ประมาณ 5 ถึง 10 คำต่อวินาที ความเร็วตั้งแต่ 15 tokens ต่อวินาทีขึ้นไปจะให้ความรู้สึกเหมือนการพิมพ์ตามปกติสำหรับผู้อ่านหนึ่งคน ดังนั้นการติดตั้งที่ใช้ CPU เท่านั้นจำนวนมากจึงเพียงพอโดยไม่ต้องปรับแต่งเพิ่มเติม

การประเมิน VRAM ก่อนซื้อ

ขนาดไฟล์โมเดลเป็นเพียงค่าขั้นต่ำ ไม่ใช่ข้อกำหนดทั้งหมด ให้เผื่อพื้นที่สำหรับ weights, KV cache (แคช key-value ซึ่งเป็นหน่วยความจำต่อ token ที่กลไก attention ใช้เก็บข้อมูล) และ overhead ประมาณ 1 GB

หลักเกณฑ์ที่ใช้ได้จริง ณ เดือน July 2026 คือ ให้นำขนาดไฟล์โมเดลเป็น gigabytes แล้วเพิ่ม 20 เปอร์เซ็นต์สำหรับ context ขนาดปกติ 8k ถึง 16k โมเดล 8B ขนาด 4.7 GB ต้องใช้ VRAM ประมาณ 6 GB โมเดล 27B ที่ 4 bits มีขนาดประมาณ 16 GB และควรมี VRAM ประมาณ 20 GB โมเดล 70B ที่ 4 bits มีขนาดประมาณ 40 GB และต้องใช้การ์ดขนาด 48 GB หรือการ์ดขนาดเล็กกว่า 2 ใบ

context ขนาดยาวทำให้หลักเกณฑ์นี้ใช้ไม่ได้ KV cache จะเพิ่มขึ้นตามความยาวของ context และที่ 128k tokens อาจมีขนาดใหญ่กว่า weights เอง หากวางแผนใช้ context ขนาดยาว ให้ประเมินความต้องการสำหรับแคชเป็นอันดับแรก และตรวจสอบว่า engine ของคุณรองรับการทำ quantization ของแคชหรือไม่

ตรวจสอบสิ่งที่เครื่องมีอยู่จริง

ในอินสแตนซ์ GPU ให้ยืนยันก่อนว่าไดรเวอร์ตรวจพบการ์ด ก่อนดำเนินการอื่น

nvidia-smi

ผลลัพธ์ควรเป็นตารางที่แสดงชื่อ GPU เวอร์ชันไดรเวอร์ และหน่วยความจำที่ใช้จากทั้งหมด NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver หมายความว่าไม่มีไดรเวอร์ หรือโมดูลเคอร์เนลไม่ได้สร้างใหม่หลังจากอัปเกรดเคอร์เนล ในอิมเมจ Ubuntu มาตรฐาน วิธีแก้ไขมักเป็น sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install จากนั้นรีบูตเพื่อให้โหลดโมดูลใหม่

สำหรับคอนเทนเนอร์ มีเพียงไดรเวอร์อย่างเดียวยังไม่เพียงพอ Docker ต้องใช้ NVIDIA Container Toolkit เพื่อส่งต่ออุปกรณ์เข้าไปในคอนเทนเนอร์

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

จากนั้นยืนยันว่าการส่งต่ออุปกรณ์ทำงานจากภายในคอนเทนเนอร์:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

ควรแสดงตารางเดียวกัน หากมีบรรทัด docker: Error response from daemon: could not select device driver ซึ่งระบุความสามารถของ GPU ที่ไม่สามารถรองรับได้ หมายความว่าติดตั้ง toolkit แล้ว แต่ยังไม่ได้กำหนดค่า Docker ใหม่หรือรีสตาร์ต Docker ให้เรียกใช้บรรทัด nvidia-ctk และคำสั่งรีสตาร์ตอีกครั้ง ใน Compose รายการที่เทียบเท่าคือ deploy.resources.reservations.devices ซึ่งมีค่า driver เป็น nvidia และรายการ capabilities มี gpu โดยสามารถใส่รายการนี้ในนิยาม service ทั่วไปที่อธิบายไว้ใน Docker Compose บน VPS

วัดผลก่อนอัปเกรด

เรียกใช้โมเดลที่คุณตั้งใจจะใช้จริงบนเครื่อง CPU ที่มีอยู่แล้ว และบันทึกตัวเลขไว้ เมื่อ โฮสต์ LLM ด้วยตนเองบน VPS โดยใช้ Ollama การดำเนินการนี้ใช้เพียง flag เดียว:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

ผลลัพธ์จะแสดงเวลาไว้ท้ายสุด eval rate คือความเร็วในการสร้างผลลัพธ์ หน่วยเป็นโทเค็นต่อวินาที prompt eval rate คือความเร็วที่เครื่องอ่านอินพุตของคุณ ตัวเลข 2 ค่านี้ช่วยระบุได้ว่าควรอัปเกรดส่วนใด: ค่า eval rate ที่ต่ำแสดงว่ามีปัญหาด้านแบนด์วิดท์หน่วยความจำ ส่วนค่า prompt eval rate ที่ต่ำเมื่ออินพุตมีขนาดยาว แสดงว่ามีปัญหาด้านการประมวลผล

หากเครื่องมี GPU ให้ตรวจสอบว่าโมเดลถูกโหลดไปยัง GPU จริง:

ollama ps

คอลัมน์ PROCESSOR จะแสดงค่า 100% GPU เมื่อข้อมูลทั้งหมดพอดีกับ GPU หรือแสดงค่าลักษณะเดียวกับ 43%/57% CPU/GPU เมื่อข้อมูลไม่พอดี การแบ่งโมเดลเพียงบางส่วนมักให้ผลแย่กว่าที่คาดไว้ เนื่องจากทุกโทเค็นยังต้องรอส่วนที่ทำงานช้ากว่า

ประเด็นด้านต้นทุน

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

มีรูปแบบการใช้งานที่เหมาะสมอยู่ 3 รูปแบบ เก็บงานปริมาณน้อยที่เกิดขึ้นอย่างสม่ำเสมอไว้บน CPU VPS ส่งคำขอที่ซับซ้อนเป็นครั้งคราวไปยัง API ที่ให้บริการแบบโฮสต์และชำระเงินตามจำนวนโทเค็น เช่า GPU แบบรายชั่วโมงสำหรับงานแบบกลุ่ม การปรับแต่งละเอียด หรือการสร้าง embeddings จำนวนมาก แล้วลบอินสแตนซ์ทิ้ง การผสมผสานรูปแบบเหล่านี้เป็นเรื่องปกติ และหลักการควบคุมต้นทุนตามที่อธิบายไว้ใน การควบคุมต้นทุนของ AI agent บน VPS ที่เปิดทำงานตลอดเวลา ก็ใช้กับกรณีนี้เช่นกัน แต่ความแตกต่างคือเวลาที่ไม่มีการใช้งานเป็นจุดรั่วไหลของต้นทุน ไม่ใช่จำนวนโทเค็น

สิ่งที่ยังทำงานได้ดีโดยไม่มี GPU

การสร้าง embeddings ในปริมาณต่ำ โมเดล embedding ขนาดเล็กประมวลผลเอกสารสั้นได้หลายร้อยฉบับต่อนาทีโดยใช้ CPU เพียงไม่กี่คอร์ และดัชนีที่สร้างเพียงครั้งเดียวไม่จำเป็นต้องทำงานอย่างรวดเร็ว

Whisper small และ base สำหรับการถอดเสียง Faster-whisper บน CPU สามารถถอดเสียงได้ใกล้เคียงแบบเรียลไทม์สำหรับโมเดล small ซึ่งเพียงพอสำหรับ pipeline ที่ทำงานข้ามคืน

โมเดลแชตที่ทำ quantization แล้วซึ่งมีขนาดไม่เกินประมาณ 27B สำหรับผู้ใช้ 1 หรือ 2 ราย ทำงานช้า แต่ผลลัพธ์อ่านได้และใช้งานได้

งานใดก็ตามที่จัดเป็น batch job หากไม่มีผู้เฝ้าดูหน้าจอ ความเร็วตามเวลาจริงเป็นเพียงรายละเอียดด้านการจัดตารางเวลา ไม่ใช่ข้อกำหนด

สิ่งที่ต้องใช้ GPU อย่างแท้จริง ได้แก่ การฝึกหรือ fine-tuning ที่เกินกว่าการใช้ adapter ขนาดเล็ก การให้บริการผู้ใช้พร้อมกันจำนวนมาก การสร้างภาพและวิดีโอ และการประมวลผลเสียงพูดแบบเรียลไทม์ซึ่งเวลาแฝงเป็นองค์ประกอบหลักของผลิตภัณฑ์

FAQ

ฉันต้องใช้ VRAM เท่าใดสำหรับโมเดล 7B หรือ 8B

ประมาณ 6 GB สำหรับโมเดล 8B ที่ทำ quantization แบบ 4-bit และใช้ context ปกติขนาด 8k ถึง 16k โดย weights ใช้พื้นที่ประมาณ 4.7 GB ส่วนที่เหลือเป็น KV cache และ overhead ประมาณ 1 GB การ์ดขนาด 12 GB จะมีพื้นที่เพียงพอสำหรับ context ที่ยาวขึ้น หากวางแผนใช้ context ขนาด 128k ให้คำนวณพื้นที่สำหรับ cache แยกต่างหาก เพราะ cache อาจมีขนาดใหญ่กว่า weights

ฉันสามารถใช้งาน Ollama โดยไม่มี GPU ได้หรือไม่

ได้ Ollama จะสลับไปใช้ CPU โดยอัตโนมัติ และต้องมี RAM เพียงพอสำหรับเก็บโมเดล คาดการณ์ความเร็วประมาณ 5 ถึง 12 tokens ต่อวินาทีสำหรับโมเดล 8B แบบ 4-bit โดยขึ้นอยู่กับความเร็วของหน่วยความจำ ซึ่งใกล้เคียงกับความเร็วในการอ่านสำหรับผู้ใช้ 1 คน ปัญหาหลักบน CPU คือ prompt ที่ยาว เนื่องจากการอ่าน context จำนวน 30,000 tokens ใช้การประมวลผลมาก และใช้เวลานานกว่าการสร้างคำตอบมาก

เหตุใด GPU ของฉันจึงเร็วกว่า CPU เพียงเล็กน้อย

สาเหตุที่พบบ่อยคือโมเดลมีขนาดใหญ่เกินกว่าจะเก็บใน VRAM ได้ทั้งหมด ทำให้บาง layer ทำงานบน CPU และทุก token ต้องรอส่วนที่ช้ากว่า ให้เรียกใช้ ollama ps และตรวจสอบว่าคอลัมน์ PROCESSOR แสดงค่า 100% GPU หากแสดงการแบ่งการทำงาน ให้ใช้ quantization ที่มีขนาดเล็กลงหรือใช้โมเดลที่มีขนาดเล็กลง อีกสาเหตุที่พบบ่อยคือ benchmark มีระยะเวลาสั้น ทำให้เวลาโหลดโมเดลมีผลต่อการวัดมากกว่าการประมวลผลจริง

GPU VPS คุ้มค่าสำหรับผู้ใช้ 1 คนหรือไม่

โดยทั่วไปไม่คุ้ม ผู้ใช้ 1 คนอ่านได้ที่ความเร็ว 5 ถึง 10 คำต่อวินาที และเครื่องที่ใช้ CPU ก็สร้าง tokens ได้เร็วกว่านั้นสำหรับโมเดลขนาดไม่เกินประมาณ 13B กรณีที่อาจคุ้มค่ากับค่าใช้จ่ายสำหรับผู้ใช้ 1 คน ได้แก่ prompt ที่ยาว การสร้างภาพ และการ fine-tuning การให้บริการผู้ใช้หลายคนพร้อมกันเป็นเหตุผลที่ชัดเจนที่สุด เนื่องจาก batching ทำให้ GPU 1 ตัวตอบคำขอ 20 รายการได้ด้วยต้นทุนใกล้เคียงกับการตอบคำขอ 1 รายการ

ควรเช่า GPU แบบคิดค่าบริการรายชั่วโมง หรือเปิดใช้งานตลอดเวลา

ให้เช่าแบบรายชั่วโมงเมื่อปริมาณงานเกิดขึ้นเป็นช่วง ๆ เช่น fine-tuning การสร้าง embedding จำนวนมาก หรือการถอดเสียงแบบ batch ให้เปิดใช้งานตลอดเวลาเฉพาะเมื่อ GPU มีงานอย่างต่อเนื่อง เพราะ GPU instance คิดค่าบริการตามเวลาที่มีการใช้งาน ไม่ใช่ตามจำนวน tokens ที่สร้างขึ้น assistant ที่มีทราฟฟิกต่ำมีค่าใช้จ่ายถูกกว่าหากทำงานบน CPU VPS หรือใช้ hosted API ที่คิดค่าบริการตามจำนวน tokens แทนการใช้ GPU ที่ไม่มีงาน l