VPS có GPU: 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 model: tốc độ sinh token và việc model có đủ nhỏ để chứa trong memory hay không. Những yếu tố khác không thay đổi. Nếu workload của bạn là chat model từ 7B đến 27B đã quantize, chỉ trả lời từng người một; job tạo embedding với lưu lượng thấp; hoặc speech transcription bằng Whisper small, thì VPS CPU thông thường với đủ RAM đã đáp ứng được. Hãy bắt đầu bằng CPU, đo chỉ số khiến bạn thấy chậm, 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, hệ thống phải 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 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 dùng CPU có 64 GB RAM có thể nạp model 70B ở mức 4 bit. Model vẫn chạy được, nhưng tốc độ gần với đọc văn bản hơn là trò chuyện. GPU chỉ giúp được trong trường hợp này nếu model vừa với VRAM, vì ngay khi các layer tràn sang system RAM thì đường xử lý chậm lại chi phối.

Throughput khi xử lý theo batch. Đây là phần nhiều người đánh giá thấp. GPU khi sinh nội dung cho một user thường để phần lớn năng lực tính toán ở trạng thái nhàn, vì nó phải chờ đọc dữ liệu từ memory. Khi xử lý đồng thời 20 request, cùng một lần đọc weight có thể phục vụ cả 20 request. Tổng số token mỗi giây tăng lên nhiều lần, trong khi tốc độ của từng user chỉ giảm nhẹ. CPU không hoạt động như vậy. Hai user chạy đồng thời trên một máy CPU sẽ làm tốc độ của nhau giảm khoảng một nửa. Nếu bạn 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 năng lực tính toán, không phải băng thông memory, và đây là điểm GPU có ưu thế lớn nhất. Một context 30,000 token mà CPU cần một 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ẽ luôn nhận thấy điều này.

Các con số ước tính 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 dùng 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 bạn dùng sẽ làm các con số 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
  }
]

Dòng GPU 24 GB đạt 50 token mỗi giây, so với 11 trên một máy CPU dùng DDR5. Mức này cao hơn khoảng 5 lần, phù hợp với tỷ lệ băng thông chứ không phải do khác biệt về compute 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 đang tăng dần tạo 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 đã tạo 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 cấu hình chỉ dùng CPU vẫn đáp ứng tốt.

Ước tính VRAM trước khi mua

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

Một 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ó kích thước 4.7 GB cần khoảng 6 GB VRAM. Model 27B ở mức 4 bit có kích thước khoảng 16 GB và cần khoảng 20 GB. Model 70B ở mức 4 bit có kích thước khoảng 40 GB và cần một card 48 GB, hoặc hai card nhỏ hơn. Cách tính này vẫn áp dụng được với các model lớn hơn nhiều, và cách tính VRAM cho model 2.8 nghìn tỷ tham số như Kimi K3 cho thấy đến một lúc, việc chọn card không còn là vấn đề phù hợp nữa.

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 ưu tiên dự trù cho cache 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 hết hãy xác nhận driver nhận diện được card.

nvidia-smi

Bạn cần 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 có nghĩa là driver bị thiếu 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 khắc phục thường là sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install, sau đó reboot để module mới được load.

Với container, chỉ có driver là chưa đủ. Docker cần NVIDIA Container Toolkit để truyền thiết bị GPU 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 đó, hãy kiểm tra 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à container không đáp ứng được, có 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 rồi 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ể đặt cùng các định nghĩa service thông thường được 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ó và ghi lại các số đo. Với Ollama: tự host LLM trên VPS, việc này 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. eval rate là tốc độ sinh 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 phần nào: eval rate thấp là vấn đề về băng thông bộ nhớ, còn prompt eval rate thấp khi input dài là vấn đề về 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 hiển thị giá trị như 43%/57% CPU/GPU khi model không vừa. Chia model giữa GPU và CPU thường chậm hơn bạn dự đoán, vì mỗi token vẫn phải chờ phần chậm hơn.

Câu hỏi về chi phí

GPU instance có chi phí cao gấp nhiều lần CPU instance tương đương. Nhà cung cấp tính phí cho từng giờ instance tồn tại, không phải theo số token instance 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 hoạt động nhiều có chi phí thấp trên mỗi token, còn GPU nhàn rỗi chỉ gây lãng phí.

Có 3 mô hình thực tế. Giữ các tác vụ ổn định nhưng ít lưu lượng 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 batch job, fine-tuning hoặc một đợt embedding số lượng lớn, sau đó hủy instance. Kết hợp các mô hình 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, nhưng điểm khác là thời gian nhàn rỗi mới là khoản thất thoát, không phải số lượng token.

Những tác vụ vẫn chạy tốt khi không có GPU

Embeddings với lưu lượng thấp. Một embedding model nhỏ có thể xử lý hàng trăm tài liệu ngắn mỗi phút trên vài CPU core, còn index chỉ cần build một lần thì không cần tốc độ cao.

Whisper small và base để chuyển giọng nói thành văn bản. Faster-whisper trên CPU có thể chuyển giọng nói gần như theo thời gian thực với model small. Mức này đủ cho pipeline chạy qua đêm.

Chat model đã quantize với kích thước tối đa khoảng 27B, cho một hoặc hai người dùng. Tốc độ chậm nhưng kết quả dễ đọc và vẫn sử dụng được.

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

Những tác vụ thực sự cần GPU gồm 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, và xử lý speech theo thời gian thực khi độ trễ là yếu tố cốt lõi 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 lượng tử hóa 4-bit với context thông thường từ 8k đến 16k. Phần weights chiếm khoảng 4.7 GB; phần còn lại là KV cache và khoảng 1 GB overhead. Card 12 GB sẽ có đủ dư địa cho context dài hơn. Nếu bạn dự định chạy context 128k, hãy tính riêng dung lượng cache vì nó có thể lớn hơn weights.

Tôi có thể chạy Ollama mà không có 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 token mỗi giây tùy tốc độ memory. Mức này gần với tốc độ đọc của một người dùng. Prompt dài mới là vấn đề chính trên CPU, vì việc đọc 30,000 token context phụ thuộc vào năng lực tính toán và mất nhiều thời gian hơn hẳn việc sinh câu trả lời.

Tại sao GPU của tôi chỉ nhanh hơn CPU một chút?

Nguyên nhân thường gặp là model không vừa hoàn toàn trong VRAM, nên 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 rồi kiểm tra cột PROCESSOR có giá trị 100% GPU hay không. Nếu thấy model bị chia giữa GPU và CPU, hãy dùng quantization nhỏ hơn hoặc model nhỏ hơn. Nguyên nhân phổ biến 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 tiền 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, còn máy CPU đã sinh token nhanh hơn mức đó đối với model tối đa khoảng 13B. Những trường hợp đáng trả chi phí cho một người dùng là prompt dài, sinh ả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, vì 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 mang tính đợt ngắn, như fine-tuning, chạy embedding hàng loạt hoặc batch transcription. Chỉ nên để GPU 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ố token đã sinh. Assistant có ít traffic 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 idle.