เช่า 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.9 GB บนดิสก์และในหน่วยความจำ ดังนั้นการสร้างโทเค็นหนึ่งตัวหมายถึงการย้ายข้อมูลประมาณ 4.9 GB ให้นำ memory bandwidth ของเครื่องหารด้วยตัวเลขนี้ คุณจะได้ค่าเพดานของจำนวนโทเค็นต่อวินาที การหารเพียงครั้งเดียวนี้สามารถอธิบายผลการทดสอบ (benchmark) เกือบทุกอย่างที่คุณเคยอ่านมาได้

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

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

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

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

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

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

ปริมาณงานจริง (throughput) มักต่ำกว่าค่าแบนด์วิดท์หารด้วยขนาดโมเดล เนื่องจากกลไก attention ที่ทำงานบนบริบทที่เพิ่มขึ้นเรื่อยๆ นั้นต้องใช้การประมวลผลเพิ่มเติม ซึ่งการหารแบบง่ายไม่ได้นำมาคำนวณด้วย

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

การประเมินขนาด VRAM ก่อนตัดสินใจซื้อ

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

ควรคำนวณส่วนของ cache แยกต่างหากแทนการบวกเปอร์เซ็นต์แบบเหมา เพราะการทำ quantization ให้กับน้ำหนักไม่ได้ส่งผลต่อ cache สำหรับแต่ละโทเค็น โมเดลแบบ full-attention จะเก็บ key และ value สำหรับทุกเลเยอร์และทุก KV head โดยใช้ขนาด 2 ไบต์ต่อหนึ่งตัวเลขในรูปแบบ FP16 ซึ่งเป็นประเภท cache เริ่มต้นของ Ollama ข้อมูล metadata ของโมเดลใน Ollama ณ วันที่ 2026-10-27 ระบุว่า Llama 3.1 8B มี 32 เลเยอร์ และ 8 KV heads ที่ขนาด 128 มิติ ซึ่งคำนวณได้ 128 KiB ต่อโทเค็น: ประมาณ 1.07 GB ที่ context 8k และ 2.15 GB ที่ 16k ดังนั้นโมเดล 8B ขนาด 4.9 GB จึงต้องการ VRAM ประมาณ 7 GB ที่ context 8k และประมาณ 8 GB ที่ 16k สำหรับโมเดล 27B ที่ 4 บิต จะมีขนาดประมาณ 17 GB (Gemma 3 27B ในคลังของ Ollama) metadata ของ Gemma 3 ระบุว่าใช้ sliding window ขนาด 1,024 โทเค็น ซึ่งช่วยป้องกันไม่ให้ cache ขยายตัวมากเกินไป ดังนั้นควรเตรียมไว้ที่ 20 GB หรือมากกว่า ส่วนโมเดล 70B ที่ 4 บิต จะมีขนาดประมาณ 43 GB (Llama 3.3 70B) ด้วย 80 เลเยอร์ cache แบบ FP16 จะเพิ่มขึ้นอีกประมาณ 2.7 GB ที่ 8k และ 5.4 GB ที่ 16k ดังนั้นจึงต้องใช้การ์ดขนาด 48 GB โดยมีพื้นที่เหลือไม่มาก หรือใช้การ์ดขนาดเล็กกว่าสองใบ การคำนวณแบบเดียวกันนี้ยังคงใช้ได้แม้ในโมเดลที่ใหญ่กว่านั้น และ การคำนวณ VRAM สำหรับโมเดลที่มีพารามิเตอร์ 2.8 ล้านล้านตัวอย่าง Kimi K3 จะแสดงให้เห็นว่าเมื่อถึงจุดหนึ่ง การเลือกการ์ดจอจะไม่ใช่ประเด็นหลักอีกต่อไป

context ที่ยาวเป็นจุดที่สำคัญที่สุด ในโมเดลแบบ full-attention เช่น Llama 3.1 ขนาดของ KV cache จะเพิ่มขึ้นเป็นเส้นตรงตามความยาวของ context และที่ 128k โทเค็น มันอาจมีขนาดใหญ่กว่าตัวโมเดลเอง โมเดลที่ใช้ sliding-window หรือ chunked attention จะแตกต่างออกไป: เอกสารประกอบของ Hugging Face Transformers ระบุชื่อ Mistral, Gemma 2 และ Llama 4 ว่าเป็นตัวอย่างที่ cache ในเลเยอร์เหล่านั้นจะหยุดขยายตัวเมื่อถึงขนาด window หรือ chunk ที่กำหนด ทำให้ยอดรวมเพิ่มขึ้นช้ากว่า หากคุณวางแผนจะใช้ context ยาว ให้คำนวณขนาดสำหรับ cache เป็นอันดับแรก และตรวจสอบว่า engine ของคุณรองรับการทำ cache quantization หรือไม่ ใน Ollama นั้น OLLAMA_KV_CACHE_TYPE=q8_0 จะใช้หน่วยความจำประมาณครึ่งหนึ่งของ f16 แบบปกติ และการทำ cache quantization จะใช้ได้เฉพาะเมื่อเปิดใช้งาน Flash Attention เท่านั้น ควรตั้งค่าความยาว context ให้ชัดเจนด้วย Ollama จะเลือกค่าเริ่มต้นจาก VRAM: 4k สำหรับ VRAM ต่ำกว่า 24 GiB, 32k สำหรับ 24 ถึง 48 GiB, และ 256k สำหรับ 48 GiB ขึ้นไป บนการ์ด 48 GB ที่รันโมเดล 70B ค่าเริ่มต้นนี้จะเรียกใช้ cache มากกว่าที่การ์ดจะรับไหว

ตรวจสอบทรัพยากรที่มีอยู่จริงบนเครื่อง

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

nvidia-smi

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

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

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 ที่ไม่สามารถตอบสนองได้ หมายความว่า Docker ไม่พบไดรเวอร์อุปกรณ์ที่ตรงกับคำขอ ให้ตรวจสอบว่ามีการติดตั้ง toolkit แล้ว จากนั้นรันคำสั่ง nvidia-ctk อีกครั้งแล้วรีสตาร์ท ใน Docker Compose สิ่งที่เทียบเท่ากันคือรายการ deploy.resources.reservations.devices ซึ่งมี driver เป็น nvidia และรายการความสามารถ (capabilities) ประกอบด้วย 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 instances คิดค่าบริการตามเวลาที่จองใช้งานประมวลผล ไม่ใช่ตามจำนวน tokens โดยอัตราค่าบริการและค่าธรรมเนียมสำหรับ instance ที่หยุดทำงานจะถูกกำหนดโดยผู้ให้บริการ GPU ที่เปิดทิ้งไว้ตลอดเวลาแต่มีคำขอใช้งานเพียงเล็กน้อยต่อวัน จะเสียค่าใช้จ่ายส่วนใหญ่ไปกับช่วงเวลาที่ไม่ได้ประมวลผล จุดคุ้มทุนขึ้นอยู่กับอัตราการใช้งาน: GPU ที่ทำงานหนักจะมีต้นทุนต่อ token ที่ต่ำ ในขณะที่ GPU ที่ปล่อยว่างไว้ถือเป็นการสิ้นเปลืองโดยเปล่าประโยชน์

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

สำหรับโมเดล 8B ที่ทำ 4-bit quantization และใช้ context 8k จะต้องใช้ VRAM ประมาณ 7 GB และประมาณ 8 GB สำหรับ context 16k โดยอ้างอิงจากค่าเริ่มต้นของ FP16 cache ใน Ollama น้ำหนักของโมเดล (weights) อยู่ที่ประมาณ 4.9 GB ส่วน KV cache จะเพิ่มขึ้นอีกประมาณ 1.07 GB ที่ 8k หรือ 2.15 GB ที่ 16k และส่วนที่เหลืออีกประมาณ 1 GB คือ overhead การ์ดจอขนาด 8 GB สามารถรองรับที่ 8k ได้ แต่จะค่อนข้างตึงตัวที่ 16k ในขณะที่การ์ดจอ 12 GB จะมีพื้นที่เหลือเพียงพอสำหรับ context ที่ยาวขึ้น การเปลี่ยน cache ไปใช้ q8_0 จะช่วยลดขนาดส่วนแบ่งของ cache ลงได้ประมาณครึ่งหนึ่ง หากคุณวางแผนจะรันที่ 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 คุ้มค่าสำหรับผู้ใช้คนเดียวหรือไม่?

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

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

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