VPS có GPU: khi nào bạn thực sự cần?

Bạn 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à kích thước model có thể chứa trong memory. Ngoài ra không có gì thay đổi. Nếu workload của bạn là chat model đã quantize từ 7B đến 27B, 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, 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ó chịu, rồi mới nâng cấp.

Nguyên nhân nằm ở 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 có kích thước khoảng 4.9 GB trên disk và gần tương đương trong memory, nên mỗi token cần di chuyển khoảng 4.9 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 giản này giải thích gần như mọi benchmark bạn sẽ đọc.

GPU thực sự mang lại lợi ích gì

Băng thông. Server DDR5 trên một host hiện đại xử lý hàng chục gigabyte mỗi giây. Bộ nhớ GPU (VRAM, video RAM) xử lý 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 bits. 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 VRAM, vì ngay khi các layer tràn sang system RAM thì đường xử lý chậm lại chi phối.

Thông lượng khi batching. Đây là phần thường bị đánh giá thấp. GPU sinh output cho một user sẽ để phần lớn năng lực tính toán ở trạng thái idle vì đang chờ đọc 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 tokens 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ẹ. Các inference engine trên CPU như llama.cpp cũng hỗ trợ batching, với mức cải thiện phụ thuộc vào phần cứng và workload. 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, quan trọng hơn tốc độ của một stream đơ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à phần GPU có lợi 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ẽ liên tục gặp tình huống này.

Số liệu ước tính và cách đọc chúng

Thông lượng thực tế cũng thấp hơn phép chia băng thông cho kích thước model, vì attention trên context ngày càng dài tạo thêm công việc mà phép chia đơn giản này bỏ qua.

Để so sánh, tốc độ đọc thầm của người lớn bằng tiếng Anh trung bình khoảng 4.0 đến 4.3 từ mỗi giây: 238 từ mỗi phút đối với văn bản phi hư cấu và 260 đối với văn học hư cấu. Tốc độ từ 15 token mỗi giây trở lên đã tạo cảm giác như đang 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 hoạt động tốt mà không gây chú ý.

Ướ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 dung lượng cần thiết. Hãy tính cả weights, KV cache (key-value cache, phần memory được attention giữ lại cho từng token) và khoảng 1 GB overhead.

Hãy tính riêng cache thay vì cộng một tỷ lệ cố định, vì quantize weights không quantize cache. Với mỗi token, model dùng full attention lưu một key và một value cho mỗi layer và mỗi KV head, mỗi số chiếm 2 bytes trong FP16, là loại cache mặc định của Ollama. Metadata của model trong Ollama, được kiểm tra vào 2026-10-27, cho biết Llama 3.1 8B có 32 layer và 8 KV head, mỗi head có 128 dimension. Tính ra cache chiếm 128 KiB cho mỗi token: khoảng 1.07 GB ở context 8k và 2.15 GB ở 16k. Vì vậy, model 8B 4.9 GB cần khoảng 7 GB VRAM ở 8k và khoảng 8 GB ở 16k. Model 27B ở 4 bit chiếm khoảng 17 GB (Gemma 3 27B trong library của Ollama). Metadata của Gemma 3 cho biết sliding window 1,024 token, nên phần lớn cache không tiếp tục tăng; hãy dự trù từ 20 GB trở lên. Model 70B ở 4 bit chiếm khoảng 43 GB (Llama 3.3 70B). Với 80 layer, cache FP16 cộng thêm khoảng 2.7 GB ở 8k và 5.4 GB ở 16k. Vì vậy, model này cần card 48 GB với rất ít dư địa, hoặc 2 card nhỏ hơn. Cách tính tương tự vẫn áp dụng cho model lớn hơn nhiều, và phần tính VRAM cho model 2.8 nghìn tỷ parameter như Kimi K3 cho thấy đến một lúc việc chọn card không còn là vấn đề chính nữa.

Context dài là trường hợp cách tính này quan trọng nhất. Với các model full attention như Llama 3.1, KV cache tăng tuyến tính theo độ dài context, và ở 128k token, nó có thể lớn hơn chính weights. Các model dùng sliding-window attention hoặc chunked attention thì khác: tài liệu Transformers của Hugging Face nêu Mistral, Gemma 2 và Llama 4 là những ví dụ trong đó cache của các layer này dừng tăng khi đạt đến kích thước window hoặc chunk, nên tổng dung lượng tăng chậm hơn. Nếu bạn định dùng context dài, hãy dự trù cache trước và kiểm tra engine hỗ trợ cache quantization ra sao. Trong Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 dùng khoảng một nửa memory so với f16 mặc định, và cache quantization chỉ áp dụng khi Flash Attention được bật. Bạn cũng nên đặt rõ context length. Ollama chọn giá trị mặc định theo VRAM: 4k khi dưới 24 GiB, 32k từ 24 đến 48 GiB và 256k khi từ 48 GiB trở lên. Trên card 48 GB chạy model 70B, giá trị mặc định đó yêu cầu lượng cache lớn hơn nhiều so với dung lượng card.

Kiểm tra phần cứng thực tế của máy

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 thấy một bảng liệt kê tên GPU, phiên bản driver và lượng memory đã dùng trên tổng memory. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver nghĩa là NVIDIA-SMI không thể kết nối tới driver; hãy kiểm tra driver đã được cài đặt và kernel module của nó đã được load. 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 các máy dùng cho tác vụ tính toán, tài liệu server của Ubuntu khuyến nghị sudo ubuntu-drivers install --gpgpu, lệnh này sẽ chọn nhánh server driver.

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 đó, hãy xác nhận 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ự sẽ 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à Docker không tìm được device driver phù hợp với request; hãy kiểm tra toolkit đã được cài đặt, rồi chạy lại dòng nvidia-ctk và thao tác restart. Trong Compose, phần tương đương là một entry deploy.resources.reservations.devices có driver là nvidia và danh sách capabilities chứa gpu; phần này đặt vào các service definition 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.

Chi phí

GPU instance tính phí theo thời gian compute được provision thay vì theo token, với mức giá và phí cho instance đã dừng do provider quy định. Một GPU luôn bật nhưng chỉ xử lý vài request mỗi ngày sẽ dành phần lớn thời gian đã trả phí ở trạng thái idle. Điểm hòa vốn nằm ở mức sử dụng: GPU bận thì chi phí trên mỗi token thấp, còn GPU idle chỉ gây lãng phí.

Có 3 mô hình phù hợp. Giữ các workload ổn định với lưu lượng thấp trên một CPU VPS. Gửi những request khó nhưng không thường xuyên đến một hosted API và trả phí theo token. Thuê GPU theo giờ cho batch job, fine-tuning hoặc một lần chạy embedding quy mô lớn, rồi destroy instance. Kết hợp các mô hình này là bình thường. Quy tắc kiểm soát chi phí AI agent trên một VPS luôn bật trong kiểm soát chi phí AI agent trên một VPS luôn bật cũng áp dụng ở đây, nhưng điểm thất thoát là thời gian idle thay vì 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 7 GB cho model 8B được quantize 4-bit ở context 8k, và khoảng 8 GB ở 16k, khi dùng cache FP16 mặc định của Ollama. Weights chiếm khoảng 4.9 GB, KV cache thêm khoảng 1.07 GB ở 8k hoặc 2.15 GB ở 16k, phần còn lại là khoảng 1 GB overhead. Card 8 GB đủ dùng ở 8k nhưng khá sát giới hạn ở 16k, còn card 12 GB vẫn dư chỗ cho context dài hơn. Chuyển cache sang q8_0 sẽ giảm khoảng một nửa phần dung lượng dành cho cache. Nếu bạn dự định chạy ở context 128k, hãy tính riêng dung lượng cho 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 sẽ tự động chuyển sang CPU và chỉ cần đủ RAM để chứa model. Với model 8B 4-bit, tốc độ thường khoảng 5 đến 12 token mỗi giây, tùy tốc độ memory; với một người dùng, tốc độ này gần với tốc độ đọc. Prompt dài mới là điểm nghẽn thực sự trên CPU vì việc đọc context 30,000 token bị giới hạn bởi năng lực tính toán và mất nhiều thời gian hơn đáng kể so với 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 và kiểm tra cột PROCESSOR có giá trị 100% GPU. Nếu có dấu hiệu 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, khiến 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. Tốc độ đọc thầm trung bình của người lớn bằng tiếng Anh là khoảng 4.0 đến 4.3 từ mỗi giây, và bạn phải chuyển token mỗi giây thành từ mỗi giây trước khi so sánh CPU box với tốc độ đó. Những trường hợp đáng trả chi phí cho một người dùng 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 vì batching cho phép một GPU dùng chung việc đọc weights giữa nhiều request.

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

Hãy thuê theo giờ nếu công việc xảy ra theo đợt, chẳng hạn fine-tuning, chạy embedding hàng loạt hoặc transcription theo batch. Chỉ nên để GPU chạy liên tục khi card luôn bận, vì chi phí GPU được provision tính theo thời gian chứ không theo số token đã tạo. Một 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ì để một GPU không hoạt động.