เช่า VPS แบบ GPU หรือ CPU ดี? วิธีเลือกให้เหมาะกับงาน

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

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

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

สิ่งที่ GPU มอบให้คุณจริงๆ

Bandwidth (แบนด์วิดท์): หน่วยความจำ DDR5 บนเซิร์ฟเวอร์สมัยใหม่สามารถรับส่งข้อมูลได้หลายสิบกิกะไบต์ต่อวินาที ในขณะที่หน่วยความจำของ GPU (VRAM) สามารถรับส่งข้อมูลได้ตั้งแต่หลายร้อยไปจนถึงมากกว่าหนึ่งพันกิกะไบต์ต่อวินาที อัตราส่วนนี้คือความเร็วที่เพิ่มขึ้น ซึ่งถือว่าสูงมาก

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

Batch throughput (ปริมาณงานแบบกลุ่ม): นี่คือส่วนที่คนมักประเมินค่าต่ำเกินไป GPU ที่กำลังสร้างข้อความให้ผู้ใช้เพียงคนเดียวจะปล่อยให้ส่วนประมวลผลส่วนใหญ่ว่างงาน เพราะต้องรอข้อมูลจากหน่วยความจำ แต่หากให้บริการ 20 คำขอพร้อมกัน ข้อมูลน้ำหนัก (weight) ชุดเดียวกันจะถูกนำไปใช้กับทั้ง 20 คำขอนั้น ส่งผลให้จำนวนโทเค็นต่อวินาทีโดยรวมเพิ่มขึ้นหลายเท่าตัว ในขณะที่ความเร็วต่อผู้ใช้ลดลงเพียงเล็กน้อย CPU ไม่สามารถทำเช่นนี้ได้ การมีผู้ใช้สองคนพร้อมกันบนเครื่องที่ใช้ CPU จะทำให้ความเร็วของแต่ละคนลดลงประมาณครึ่งหนึ่ง หากคุณกำลังสร้าง API ที่มีไคลเอนต์เรียกใช้งานจำนวนมาก การทำ batching คือเหตุผลสำคัญที่ควรใช้ GPU ยิ่งกว่าความเร็วในการประมวลผลแบบสตรีมเดี่ยวเพียงอย่างเดียว

การประมวลผล Prompt: การอ่าน Prompt ที่มีความยาวเป็นการทำงานที่เน้นการคำนวณ (compute-bound) ไม่ใช่เน้นหน่วยความจำ (memory-bound) และนี่คือจุดที่ GPU ชนะขาดลอยที่สุด บริบทขนาด 30,000 โทเค็นที่ CPU ต้องใช้เวลาประมวลผลถึงหนึ่งนาที GPU สามารถทำเสร็จได้ในเวลาเพียงไม่กี่วินาที ระบบดึงข้อมูล (Retrieval setups) ที่ใส่เอกสารจำนวนมากลงในทุกคำขอจะเห็นผลลัพธ์ที่แตกต่างนี้อย่างชัดเจนตลอดเวลา

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

บล็อกด้านล่างนี้แสดงตัวเลขประสิทธิภาพแบบ single-stream ทั่วไปสำหรับโมเดลขนาด 8B ที่การทำ quantization ระดับ 4-bit ณ เดือนกรกฎาคม 2026 ตัวเลขเหล่านี้เป็นเพียงแนวทางในระดับ order-of-magnitude เท่านั้น ไม่ใช่การรับประกัน ค่าที่ได้จริงจะเปลี่ยนแปลงไปตามการทำ 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 ซึ่งเร็วกว่าประมาณ 5 เท่า โดยตัวเลขนี้สอดคล้องกับอัตราส่วนของ bandwidth มากกว่าความแตกต่างของพลังการประมวลผลดิบ (raw compute) ประสิทธิภาพการทำงานจริงจะต่ำกว่าค่า bandwidth หารด้วยขนาดโมเดลเสมอ เนื่องจากกระบวนการ attention ในขณะที่ context เพิ่มขึ้นจะสร้างภาระงานเพิ่มเติม ซึ่งการหารแบบง่ายไม่ได้นำมาคำนวณด้วย

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

การคำนวณขนาด VRAM ก่อนตัดสินใจซื้อ

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

หลักการปฏิบัติ ณ เดือนกรกฎาคม 2026 คือ ให้นำขนาดไฟล์โมเดลในหน่วยกิกะไบต์มาบวกเพิ่มอีก 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 หรือใช้การ์ดขนาดเล็กกว่าสองใบร่วมกัน การคำนวณนี้ยังคงใช้ได้ผลแม้ในระดับที่สูงกว่านั้น และ การคำนวณ VRAM สำหรับโมเดลที่มีพารามิเตอร์ 2.8 ล้านล้านตัวอย่าง Kimi K3 จะแสดงให้เห็นว่าในจุดนั้นการเลือกการ์ดจอไม่ใช่ประเด็นหลักอีกต่อไป

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

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

บน instance ที่มี GPU ให้ยืนยันก่อนว่าไดรเวอร์มองเห็นการ์ดจอหรือไม่

nvidia-smi

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

สำหรับคอนเทนเนอร์ ไดรเวอร์เพียงอย่างเดียวไม่เพียงพอ 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 ใหม่หรือรีสตาร์ท ให้รันคำสั่ง nvidia-ctk อีกครั้งแล้วรีสตาร์ท ในกรณีของ Compose สิ่งที่เทียบเท่ากันคือรายการ deploy.resources.reservations.devices ซึ่งมี driver เป็น nvidia และมีรายการความสามารถที่ระบุ gpu ซึ่งสามารถนำไปใส่ในนิยามของ service ปกติที่อธิบายไว้ใน Docker Compose บน VPS

วัดค่าก่อนทำการอัปเกรด

ให้รันโมเดลที่คุณตั้งใจจะใช้งานจริงบนเครื่อง CPU ที่คุณมีอยู่แล้ว และบันทึกตัวเลขที่ได้ สำหรับ การทำ self-hosting 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 คือความเร็วที่เครื่องอ่านข้อมูลนำเข้าของคุณ ตัวเลขสองค่านี้จะบอกคุณว่าการอัปเกรดส่วนใดจะช่วยได้: ค่า eval rate ที่ต่ำเป็นปัญหาเรื่อง memory bandwidth ส่วนค่า prompt eval rate ที่ต่ำเมื่อได้รับข้อมูลนำเข้ายาวๆ เป็นปัญหาเรื่องพลังการประมวลผล

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

ollama ps

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

ประเด็นเรื่องค่าใช้จ่าย

GPU instance มีค่าใช้จ่ายสูงกว่า CPU instance ที่มีประสิทธิภาพใกล้เคียงกันหลายเท่าตัว โดยจะคิดค่าบริการตามชั่วโมงที่เปิดใช้งานจริง ไม่ใช่ตามจำนวน token ที่สร้างขึ้น การเปิด GPU ทิ้งไว้ตลอดเวลาเพื่อรองรับคำขอเพียงไม่กี่รายการต่อวันถือเป็นวิธีที่สิ้นเปลืองที่สุดในการทำ inference จุดคุ้มทุนขึ้นอยู่กับอัตราการใช้งาน (utilisation): GPU ที่ทำงานหนักจะมีต้นทุนต่อ token ที่ต่ำ ในขณะที่ GPU ที่ปล่อยว่างไว้คือความสูญเปล่าโดยแท้จริง

มีรูปแบบการใช้งานที่เหมาะสมอยู่ 3 วิธี ได้แก่ การรันงานที่มีปริมาณน้อยและสม่ำเสมอบน CPU VPS, การส่งคำขอที่ซับซ้อนซึ่งเกิดขึ้นไม่บ่อยไปยัง hosted API แล้วจ่ายเงินตามจำนวน token จริง และการเช่า GPU เป็นรายชั่วโมงสำหรับงานประมวลผลแบบ batch, การทำ fine-tuning หรือการทำ bulk embedding แล้วจึงยกเลิก instance นั้นทิ้ง การผสมผสานวิธีการเหล่านี้เป็นเรื่องปกติ และระเบียบวินัยในการควบคุมงบประมาณตามที่อธิบายไว้ใน การควบคุมค่าใช้จ่าย AI agent บน VPS ที่เปิดตลอดเวลา ยังคงนำมาปรับใช้ได้ที่นี่ โดยมีข้อแตกต่างคือช่วงเวลาที่ปล่อยให้ GPU ว่างงานคือจุดที่ทำให้เกิดการรั่วไหลของงบประมาณ แทนที่จะเป็นจำนวน token

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

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

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

โมเดลแชทแบบ Quantized ขนาดสูงสุดประมาณ 27B สำหรับผู้ใช้หนึ่งหรือสองคน แม้จะช้าแต่ก็ยังอ่านรู้เรื่องและใช้งานได้

งานทุกประเภทที่คุณจัดว่าเป็น batch job หากไม่มีใครเฝ้าหน้าจออยู่ ความเร็วแบบ wall-clock ก็เป็นเพียงรายละเอียดของการจัดตารางเวลา ไม่ใช่ข้อกำหนดที่จำเป็น

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

FAQ

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

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

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

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

ทำไม GPU ของฉันถึงทำงานเร็วกว่า CPU เพียงเล็กน้อย?

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

GPU VPS คุ้มค่าสำหรับผู้ใช้คนเดียวหรือไม่?

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

ฉันควรเช่า GPU เป็นรายชั่วโมงหรือเปิดทิ้งไว้ตลอดเวลา?

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