VPS GPU hay CPU: Khi nào bạn thực sự cần?

Bạn có cần VPS có GPU hay CPU là đủ?

VPS có GPU thay đổi 2 yếu tố khi bạn tự chạy một model: tốc độ sinh token và kích thước model có thể vừa trong memory. GPU không thay đổi gì khác. Nếu workload của bạn là model chat 7B đến 27B đã quantize, trả lời từng người một; một tác vụ embedding với lưu lượng thấp; hoặc transcription giọng nói bằng Whisper small, thì VPS CPU thông thường với đủ RAM đã có thể xử lý. Hãy bắt đầu bằng CPU, đo chỉ số khiến bạn không hài lòng, rồi nâng cấp khi cần.

Nguyên nhân là memory bandwidth. Khi language model sinh một token, nó đọc mọi weight cần thiết từ memory. Model 8B được quantize xuống 4 bit chiếm khoảng 4.7 GB trên disk và gần tương đương trong memory, nên để sinh một token cần truyền khoảng 4.7 GB. Lấy memory bandwidth của máy chia cho con số đó, bạn sẽ có giới hạn trên về số token mỗi giây. Phép chia này giải thích gần như mọi benchmark bạn sẽ đọc.

GPU thực sự mang lại gì

Băng thông. DDR5 của server trên một host hiện đại có thể truyền hàng chục gigabyte mỗi giây. Bộ nhớ GPU (VRAM, video RAM) có thể truyền từ hàng trăm đến hơn một nghìn gigabyte mỗi giây. Tỷ lệ này chính là mức tăng tốc, và nó rất lớn.

Dung lượng đi kèm tốc độ. Một máy CPU có 64 GB RAM có thể nạp model 70B ở mức 4 bit. Model vẫn chạy, nhưng tốc độ gần với đọc hơn là trò chuyện. GPU chỉ giúp được trong trường hợp này nếu model vừa trong VRAM, vì ngay khi các layer tràn sang system RAM, đường xử lý chậm lại chiếm quyền.

Thông lượng theo batch. Đây là phần thường bị đánh giá thấp. GPU khi tạo nội dung cho một user sẽ để phần lớn compute ở trạng thái nhàn, vì nó đang chờ bộ nhớ. Phục vụ 20 request cùng lúc cho phép cùng một lần đọc weight phục vụ cả 20 request. Tổng số token mỗi giây tăng lên vài lần, trong khi tốc độ của từng user chỉ giảm nhẹ. CPU không làm được như vậy. Hai user chạy đồng thời trên một máy CPU sẽ gần như chia đôi tốc độ của nhau. Nếu bạn đang xây dựng một API được nhiều client gọi, batching là lý do nên dùng GPU, còn quan trọng hơn tốc độ của một luồng đơn.

Xử lý prompt. Đọc một prompt dài phụ thuộc vào compute, không phụ thuộc vào băng thông bộ nhớ. Đây là phần GPU vượt trội với cách biệt lớn nhất. Một context 30,000 token mà CPU cần 1 phút để xử lý thì GPU chỉ cần vài giây. Các hệ thống retrieval chèn tài liệu vào mọi request sẽ liên tục gặp trường hợp này.

Ước lượng sơ bộ và cách đọc

Khối bên dưới chứa các số liệu đơn luồng thường được công bố cho model 8B ở mức quantization 4-bit, tính đến tháng 7 năm 2026. Đây là hướng dẫn theo bậc độ lớn, không phải cam kết. Quantization, độ dài context và inference engine của bạn sẽ làm các giá trị này thay đổi.

[
  {
    "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
  }
]

Hàng GPU 24 GB đạt 50 token mỗi giây, so với 11 của một máy CPU DDR5. Con số này cao hơn khoảng năm lần, phù hợp với tỷ lệ băng thông thay vì khác biệt về khả năng tính toán thô. Throughput thực tế cũng thấp hơn kết quả lấy băng thông chia cho kích thước model, vì attention trên context ngày càng dài làm phát sinh thêm công việc mà phép chia đơn giản này không tính đến.

Để so sánh, một người đọc khoảng 5 đến 10 từ mỗi giây. Từ 15 token mỗi giây trở lên đã có cảm giác tương đương tốc độ gõ bình thường đối với một người đọc. Vì vậy, nhiều hệ thống chỉ dùng CPU vẫn đáp ứng tốt mà không gây chú ý.

Định cỡ VRAM trước khi mua

Kích thước file model chỉ là mức tối thiểu, không phải yêu cầu thực tế. Bạn cần tính cả phần weights, KV cache (key-value cache, vùng nhớ cho từng token mà attention duy trì), và khoảng 1 GB overhead.

Quy tắc thực tế tính đến tháng 7 năm 2026: lấy kích thước file model theo gigabyte và cộng thêm 20 phần trăm cho context thông thường từ 8k đến 16k. Model 8B có dung lượng 4.7 GB cần khoảng 6 GB VRAM. Model 27B ở mức 4 bits có dung lượng khoảng 16 GB và cần khoảng 20 GB. Model 70B ở mức 4 bits có dung lượng khoảng 40 GB và cần card 48 GB, hoặc hai card nhỏ hơn.

Context dài làm quy tắc này không còn chính xác. KV cache tăng tuyến tính theo độ dài context, và ở 128k token, nó có thể lớn hơn chính phần weights. Nếu dự định dùng context dài, hãy định cỡ theo cache trước và kiểm tra engine của bạn hỗ trợ những tùy chọn quantization cache nào.

Kiểm tra máy thực sự có gì

Trên một GPU instance, trước tiên hãy xác nhận driver nhận được card.

nvidia-smi

Bạn cần thấy một bảng liệt kê tên GPU, phiên bản driver và dung lượng bộ nhớ đã dùng trên tổng dung lượng. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver nghĩa là driver chưa được cài hoặc kernel module chưa được build lại sau khi nâng cấp kernel. Trên image Ubuntu mặc định, cách sửa thường là sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, sau đó reboot để nạp module mới.

Với container, chỉ có driver là chưa đủ. Docker cần NVIDIA Container Toolkit để truyền thiết bị vào container.

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

Sau đó, kiểm tra rằng passthrough hoạt động từ bên trong container:

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

Bảng tương tự phải xuất hiện. Dòng docker: Error response from daemon: could not select device driver, trong đó nêu một gpu capability mà nó không thể đáp ứng, nghĩa là toolkit đã được cài nhưng Docker chưa được cấu hình lại hoặc chưa được restart. Vì vậy, hãy chạy lại dòng nvidia-ctk và restart. Trong Compose, cấu hình tương đương là một mục deploy.resources.reservations.devices có driver là nvidia và danh sách capabilities chứa gpu. Mục này được thêm vào các service definition thông thường đã trình bày trong Docker Compose trên VPS.

Đo trước khi nâng cấp

Chạy đúng model bạn định sử dụng trên máy CPU hiện có, rồi ghi lại các số liệu. Với Ollama tự host LLM trên VPS, bạn chỉ cần thêm một flag:

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

Phần cuối output hiển thị thời gian đo. eval rate là tốc độ sinh, tính bằng token mỗi giây. prompt eval rate là tốc độ máy đọc input của bạn. Hai số này cho biết nên nâng cấp thành phần nào: eval rate thấp cho thấy vấn đề nằm ở băng thông memory, còn prompt eval rate thấp khi input dài cho thấy vấn đề nằm ở năng lực tính toán.

Trên máy có GPU, hãy kiểm tra model thực sự được chạy trên GPU:

ollama ps

Cột PROCESSOR hiển thị 100% GPU khi toàn bộ model vừa trong GPU, hoặc giá trị tương tự 43%/57% CPU/GPU khi không đủ chỗ. Việc chia model một phần thường cho hiệu năng kém hơn dự kiến, vì mỗi token vẫn phải chờ phần chậm hơn.

Bài toán chi phí

GPU instance có chi phí cao gấp nhiều lần CPU instance tương đương. Chúng tính phí theo từng giờ tồn tại, không tính theo số token đã tạo ra. Một GPU luôn bật nhưng chỉ xử lý vài request mỗi ngày là cách chạy inference tốn kém nhất. Điểm hòa vốn nằm ở mức sử dụng: GPU chạy nhiều thì chi phí trên mỗi token thấp, còn GPU không hoạt động chỉ gây lãng phí.

Có 3 cách triển khai thực tế. Giữ các tác vụ ổn định nhưng ít yêu cầu trên CPU VPS. Gửi các request khó nhưng không thường xuyên đến hosted API và trả phí theo token. Thuê GPU theo giờ cho các batch job, fine-tuning hoặc một đợt chạy embedding số lượng lớn, rồi hủy instance. Kết hợp các cách này là bình thường. Nguyên tắc kiểm soát ngân sách trong Kiểm soát chi phí AI agent trên VPS luôn bật cũng áp dụng ở đây. Điểm khác biệt là thời gian không sử dụng mới là khoản thất thoát, không phải số token.

Những gì vẫn chạy tốt mà không cần GPU

Embeddings với lưu lượng thấp. Một embedding model nhỏ xử lý được hàng trăm tài liệu ngắn mỗi phút trên vài CPU core. Index chỉ cần xây dựng một lần nên không cần tốc độ cao.

Whisper small và base để transcription. Faster-whisper trên CPU thực hiện transcription gần thời gian thực với model small. Mức này đủ cho pipeline chạy qua đêm.

Các chat model đã quantize lên đến khoảng 27B, dành cho một hoặc hai người dùng. Tốc độ chậm nhưng kết quả dễ đọc và vẫn dùng được.

Mọi tác vụ bạn có thể gọi là batch job. Nếu không ai theo dõi màn hình, thời gian chạy thực tế chỉ là yếu tố lập lịch chứ không phải yêu cầu bắt buộc.

Những gì thực sự cần GPU: training hoặc fine-tuning vượt quá một adapter nhỏ, phục vụ nhiều người dùng đồng thời, tạo ảnh và video, cùng speech theo thời gian thực khi độ trễ là yêu cầu chính của sản phẩm.

FAQ

Tôi cần bao nhiêu VRAM cho model 7B hoặc 8B?

Khoảng 6 GB cho model 8B được quantize 4-bit với context 8k đến 16k thông thường. Weights chiếm khoảng 4.7 GB. Phần còn lại dành cho KV cache và khoảng 1 GB overhead. Card 12 GB có đủ dung lượng để chạy context dài hơn. Nếu dự định chạy context 128k, hãy tính riêng dung lượng cho cache vì cache có thể lớn hơn weights.

Tôi có thể chạy Ollama mà không cần GPU không?

Có. Ollama tự động chuyển sang CPU và chỉ cần đủ RAM để chứa model. Với model 8B 4-bit, tốc độ dự kiến khoảng 5 đến 12 tokens mỗi giây, tùy tốc độ memory. Tốc độ này gần bằng tốc độ đọc của một người dùng. Prompt dài mới là điểm nghẽn chính trên CPU. CPU phải xử lý 30,000 tokens context, nên thời gian này lâu hơn nhiều so với thời gian tạo câu trả lời.

Tại sao GPU của tôi hầu như không nhanh hơn CPU?

Nguyên nhân thường gặp là model không vừa hoàn toàn trong VRAM. Vì vậy, một số layer chạy trên CPU và mỗi token phải chờ phần chậm hơn. Chạy ollama ps và kiểm tra xem cột PROCESSOR có hiển thị 100% GPU hay không. Nếu có split, hãy dùng quantization nhỏ hơn hoặc model nhỏ hơn. Nguyên nhân thường gặp khác là benchmark quá ngắn, trong đó thời gian load model chiếm phần lớn kết quả đo.

GPU VPS có đáng thuê cho một người dùng không?

Thường là không. Một người đọc với tốc độ 5 đến 10 từ mỗi giây. CPU đã tạo tokens nhanh hơn tốc độ đó với các model tối đa khoảng 13B. Các trường hợp có thể đáng trả chi phí cho một người dùng là xử lý prompt dài, tạo ảnh và fine-tuning. Phục vụ nhiều người dùng cùng lúc là lý do thuyết phục nhất. Batching cho phép một GPU xử lý hai mươi request với chi phí gần bằng xử lý một request.

Tôi nên thuê GPU theo giờ hay chạy liên tục?

Hãy thuê theo giờ khi workload không liên tục, chẳng hạn như fine-tuning, chạy embedding hàng loạt hoặc job batch để chuyển âm thanh thành văn bản. Chỉ chạy liên tục khi card luôn bận, vì GPU instance tính phí theo thời gian tồn tại instance chứ không theo số tokens đã tạo. Assistant có traffic thấp sẽ rẻ hơn khi chạy trên CPU VPS hoặc dùng hosted API tính phí theo token, thay vì chạy trên GPU đang nhàn rỗi.