Ollama hay llama.cpp trên VPS: nên dùng cái nào?

Ollama so với llama.cpp: bạn muốn vận hành ở lớp nào?

Ollama và llama.cpp không phải đối thủ cạnh tranh theo cách câu hỏi này ngụ ý. llama.cpp là inference engine: nó tải model file và chuyển prompt thành các token. Ollama là model manager, background daemon và HTTP API chạy trên engine đó. README của Ollama vẫn liệt kê llama.cpp là inference backend (được kiểm tra ngày 2 August 2026). Vì vậy, câu hỏi thực sự là bạn muốn vận hành lớp nào trên VPS, không phải lớp nào nhanh hơn.

Chạy Ollama khi bạn muốn một service tự fetch model theo tên và tiếp tục hoạt động mà không cần theo dõi thường xuyên. Chạy trực tiếp llama.cpp khi máy có cấu hình nhỏ và bạn cần chọn chính xác model file, context size và thread count, vì trên VPS nhỏ, mỗi thiết lập này đều tiêu tốn lượng memory mà bạn không có.

Bản chất của từng project

llama.cpp là triển khai suy luận transformer bằng C và C++, xây dựng trên thư viện ggml. Nó đọc các file GGUF. GGUF (GGML universal file format) là container một file chứa weights, tokeniser và metadata mà engine cần để chạy model. Project cung cấp các binary riêng cho từng tác vụ. llama-server là HTTP server, llama-cli là prompt tương tác, còn llama-bench dùng để đo throughput. Các bản release được gắn tag theo build number thay vì semantic version. Tag hiện tại là b10224, được phát hành vào 2 August 2026, và thường có tag mới vào hầu hết các ngày làm việc.

Ollama là một chương trình Go. Một background daemon, được khởi động bằng ollama serve, load model và xử lý HTTP request; một command line client giao tiếp với daemon đó. Bên dưới cả hai là registry tại ollama.com, nơi chứa các model được đóng gói sẵn. Ollama dùng semantic version, và v0.32.5 được phát hành vào 27 July 2026. ollama pull tải một GGUF cùng prompt template và một bộ parameter mặc định, rồi lưu chúng dưới /usr/share/ollama/.ollama/models trên Linux. Các file này nằm trên root disk và mỗi file có thể chiếm vài gigabyte. Vì vậy, trên VPS có root volume 25 GB, nên biết lệnh pull để lại những gì và cách chuyển thư mục model sang nơi khác trước khi lần download thứ ba làm đầy ổ đĩa.

Đó là toàn bộ khác biệt về cách đóng gói. Ollama tự quyết định quantisation, template và context length cho bạn, đồng thời cung cấp một tên duy nhất để ghi nhớ. llama.cpp không tự quyết định gì và cung cấp cho bạn các flag.

Trục 1: kiểm soát model và quantisation

Quantisation giảm mỗi weight từ 16 hoặc 32 bit xuống còn 4, 5 hoặc 8 bit. Đây là lý do model 8 tỷ parameter có thể vừa trong RAM của một VPS thông thường. Cách đặt tên GGUF dễ đọc khi bạn biết quy luật: Q4_K_M nghĩa là K-quant 4-bit, kích thước trung bình. Số lớn hơn giữ lại độ chính xác cao hơn và tốn nhiều memory hơn.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Đó là kích thước file được publish trong repository bartowski/Meta-Llama-3.1-8B-Instruct-GGUF trên Hugging Face, được đọc vào ngày 2 August 2026 và chuyển đổi từ byte sang GiB. Có 6 build của cùng một model, bản nhỏ nhất là 2.96 GiB còn bản lớn nhất là 7.95 GiB. Mặc định phổ biến, Q4_K_M, có kích thước 4.58 GiB. Trên VPS 4 GiB, lựa chọn này quyết định model có load được hay không. Kích thước chỉ là một nửa quyết định đó, vì một row vừa khả năng chi trả không có nghĩa là đáng dùng, và chi phí thực tế của Q4, Q8 và fp16 đối với chất lượng câu trả lời mới cho biết số gigabyte bổ sung có tạo ra khác biệt mà bạn nhận thấy hay không.

Với llama.cpp, bạn chỉ định tên file, nên tự chọn row đó.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c là context size tính bằng token, -t là số thread, còn -ngl xác định số layer được chuyển sang GPU (đặt là 0 trên máy chỉ dùng CPU). Không có giá trị nào được tự đoán cho bạn.

Với Ollama, quantisation đi kèm tag mà bạn pull, còn ollama ls cho biết chính xác những gì đang có trên disk. Khi registry không có build bạn cần, hãy tự import một file GGUF. Tạo một Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Sau đó build và kiểm tra kết quả:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Context length là setting thường gây nhầm lẫn. Ollama chọn giá trị mặc định dựa trên VRAM khả dụng, còn máy không có GPU sẽ rơi vào mức nhỏ nhất: 4096 token. Nếu gửi cho nó một tài liệu 20,000 token, các token vượt quá giới hạn sẽ bị loại bỏ trước khi model đọc được, nên câu trả lời có thể sai một cách chắc chắn về một file mà model chỉ đọc được một nửa. Tăng giá trị này bằng OLLAMA_CONTEXT_LENGTH trên daemon, hoặc bằng PARAMETER num_ctx trong Modelfile. Nếu chỉ một job cần context window lớn hơn, có thể đặt num_ctx theo từng request thay vì áp dụng cho toàn server, nhờ đó cache bổ sung không ảnh hưởng đến các job khác mà daemon xử lý. llama.cpp cũng không có giá trị mặc định đủ đáng tin cậy. Hãy đặt -c một cách tường minh và biết rõ bạn đã đặt giá trị nào.

Phép tính bộ nhớ mà tài liệu thường bỏ qua

File model không phải là toàn bộ chi phí. KV cache (key/value cache) lưu một entry cho mỗi layer và mỗi token trong context. Cache này tăng theo độ dài cuộc hội thoại.

Hãy tính với Llama 3.1 8B. Model có 32 layer, 8 key/value head và head dimension là 128. Mỗi token lưu cả key và value, mỗi giá trị chiếm 2 byte trong f16, nên 2 x 8 x 128 x 2 = 4096 byte cho mỗi layer. Với 32 layer, con số này là 128 KiB cho mỗi token. Context 4096 token cần 512 MiB, còn context 32,768 token cần 4 GiB.

Vì vậy, model Q4_K_M 8B với context 4k cần khoảng 4.58 GiB cho weights, cộng khoảng 0.5 GiB cho cache và phần runtime. Model này không vừa trong 4 GiB RAM. Nó chạy được trên máy có 8 GiB RAM và vẫn còn dung lượng để hoạt động. Nếu tăng context lên 32k trên cùng máy 8 GiB, riêng cache đã chiếm hết phần RAM còn trống. Hãy theo dõi trực tiếp bằng free -h khi model đang được load. Không nên tin một ước tính chưa được đo thực tế. Nếu bạn cần tính cho model lớn hơn nhiều so với 8B, phép tính tương tự trong model 27B chạy trên VPS chỉ dùng CPU cho thấy mỗi mức từ 8 đến 64 GB thực sự chứa được gì.

Ollama còn nhân mức sử dụng này lên. OLLAMA_NUM_PARALLEL mặc định là 1, và lượng bộ nhớ model cần dùng tăng theo tích của giá trị này với độ dài context. Nếu tăng cả hai cùng lúc, daemon có thể âm thầm yêu cầu RAM nhiều gấp vài lần mức bạn dự kiến. Phép tính này cũng quyết định giới hạn số người dùng đồng thời, vì mỗi request đồng thời cần một phần KV cache riêng. Đây là lý do server chạy ổn với một người nhưng bị nghẽn khi có năm người.

Trục 2: daemon mà bạn phải vận hành

Script cài đặt Ollama ghi một systemd unit, tạo một system user ollama và enable service. Bạn có sẵn cơ chế quản lý vòng đời mà không phải tự viết. Cấu hình được thực hiện qua systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE quan trọng hơn trên CPU VPS so với mọi môi trường khác. Mặc định, model được giữ trong memory trong 5 phút rồi bị unload. Request tiếp theo phải đọc lại toàn bộ file từ disk trước khi có thể trả lời, nên việc reload 4.58 GiB có thể biến phản hồi 2 giây thành 30 giây trên storage chậm. keep-alive dài giúp loại bỏ độ trễ này nhưng giữ RAM bị chiếm dụng liên tục. Cả hai đều có chi phí thực tế. Hãy chọn phương án gây ảnh hưởng ít hơn. Nếu bạn muốn model luôn resident, đặt keep_alive để model tồn tại qua các khoảng idle và các lần reboot chỉ cần vài dòng, đồng thời không phải warm model thủ công mỗi khi máy khởi động lại.

llama.cpp không cung cấp daemon, nên bạn phải tự viết unit dưới dạng /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Enable unit bằng sudo systemctl enable --now llama-server. Sau đó process giữ model trong toàn bộ thời gian hoạt động. Model không bị unload khi idle, nên không có bất ngờ do reload, nhưng cũng không thể thu hồi memory nếu không stop service. Nếu bạn chưa quen viết unit, đây là cùng pattern với chạy các service tự quản lý dưới systemd trên VPS.

Trục 3: API mà ứng dụng của bạn sẽ gọi

Phạm vi khác biệt trên trục này đã thu hẹp đáng kể. Hiện cả hai project đều dùng format OpenAI chat, nên hầu hết client library đều hoạt động với cả hai sau khi chỉ đổi base URL.

Ollama lắng nghe trên 127.0.0.1:11434. Route tương thích với OpenAI của nó là http://localhost:11434/v1/chat/completions, đồng thời vẫn cung cấp native API tại /api/chat. Tài liệu cũng có mô tả route tương thích với Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server lắng nghe trên 127.0.0.1:8080 và cung cấp /v1/chat/completions, /v1/completions và /v1/embeddings, cùng với endpoint riêng /completion và web UI tích hợp. Nó cũng cung cấp các route vận hành mà Ollama không có: /health để kiểm tra readiness, /props để xem các thiết lập của model đã load, /slots để xem mỗi request slot đang xử lý gì, và /metrics ở format Prometheus. Nếu bạn định monitor service này, khác biệt đó có thể là yếu tố quyết định.

Không server nào tự bật authentication cho bạn. Cả hai mặc định chỉ bind vào loopback vì lý do chính đáng. Hãy truy cập chúng qua SSH tunnel hoặc từ phía sau reverse proxy, và tuyệt đối không mở 11434 hoặc 8080 ra Internet.

VPS chỉ có CPU thực sự làm được gì

VPS chỉ có CPU chạy được các model nhỏ, nhưng chậm. Đó là tóm tắt chính xác. Điều quan trọng là biết giới hạn nằm ở đâu. Hãy đo trước khi thiết kế bất kỳ thứ gì dựa trên VPS đó:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Cột pp là tốc độ xử lý prompt, còn cột tg là tốc độ sinh token. Cả hai đều tính bằng token mỗi giây. Trên gói vCPU dùng chung, model 8B ở mức Q4_K_M thường chỉ đạt vài token mỗi giây ở tg. Khâu xử lý prompt là phần gây chậm rõ nhất: toàn bộ prompt phải được xử lý trước khi token đầu tiên xuất hiện, nên system prompt dài sẽ thêm thời gian chờ vào mọi request. Độ dài câu trả lời là phần chi phí bạn có thể kiểm soát, vì ở tốc độ 3 token mỗi giây, một model trả lời lan man 600 token sẽ giữ máy bận trong 3 phút. Vì vậy, giới hạn output bằng num_predict là cách rẻ nhất để ngăn một câu trả lời quá dài biến thành timeout.

CPU có thể dùng được cho: model 1B đến 4B thực hiện classification, extraction, tóm tắt ngắn hoặc routing. Câu trả lời xuất hiện trong vài giây và lượng memory phù hợp với một gói VPS thông thường. Nếu cần một ví dụ cụ thể ở kích thước này thay vì một khoảng kích thước, Nemotron 3.5 Lightning được pull và đo benchmark trên VPS cung cấp tag chính xác, lượng RAM thực tế cần dùng và tốc độ đạt được khi không có GPU. CPU không phù hợp cho: chat tương tác với tốc độ đọc, coding assistant, xử lý tài liệu dài hoặc bất kỳ tác vụ nào có agent loop thực hiện nhiều call liên tiếp. Một loop thực hiện 12 call, mỗi call mất 4 giây, sẽ mất 1 phút trước khi tạo ra kết quả. Nếu ngay từ đầu bạn đã định dùng coding assistant, trỏ một agent đến model do bạn tự host sẽ nêu rõ những tác vụ nào model local nhỏ thực sự làm tốt và những tác vụ nào phải tiếp tục dùng hosted API.

Có 2 hướng xử lý khi các con số không đáp ứng yêu cầu. Nếu vấn đề là concurrency, tức nhiều user cùng lúc gửi request đến một model, bạn cần đổi engine. So sánh Ollama với vLLM khi phục vụ nhiều request đồng thời trình bày phần này. Nếu vấn đề là tốc độ thô, câu trả lời là VPS có gắn GPU, khi đó -ngl mới bắt đầu có ý nghĩa. Trước cả hai hướng này, hãy đo baseline cho chính hardware, vì băng thông disk và memory ảnh hưởng đến thời gian load không kém CPU. Benchmark VPS có thể lặp lại là việc đáng dành 1 giờ để thực hiện.

Cài đặt llama.cpp và cố định build

Cả hai project đều được cập nhật hằng tuần, vì vậy hãy ghi lại version đã triển khai. One-liner của upstream sẽ cài đặt build hiện tại:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Để cố định một build cụ thể, hãy tải tarball đã build sẵn từ trang releases. Build b10224 là tag hiện tại tính đến ngày 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Hoặc build chính tag đó từ source:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev là dependency được tài liệu ghi nhận cho các tính năng HTTPS. Quá trình compile mất vài phút và cần nhiều RAM hơn các gói nhỏ nhất, vì vậy hãy build trên một máy lớn hơn rồi copy các binary nếu máy nhỏ không đủ tài nguyên.

Cài đặt Ollama và ghim vào một phiên bản

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Script đọc OLLAMA_VERSION, vì vậy bạn có thể giữ một release đã xác nhận là ổn định thay vì nhận bất kỳ phiên bản nào được phát hành sáng nay. v0.32.5 được phát hành vào ngày 27 July 2026. Nếu không muốn pipe script vào shell, bạn cũng có thể cài đặt thủ công:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Cách thủ công không tạo systemd unit hoặc service user, vì vậy bạn phải tự tạo chúng. Hướng dẫn đầy đủ về Ollama trên VPS trình bày từng bước cấu hình service đó.

Các chế độ lỗi và chuỗi bạn sẽ thấy

Ollama từ chối load model. ollama run trả về một dòng có dạng sau:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama kiểm tra kích thước trước khi load, nên fail ngay và cho biết nguyên nhân. Chuyển xuống một dòng quantisation thấp hơn, giảm context length hoặc chọn model nhỏ hơn.

llama.cpp không fail mà chạy cực chậm. Mặc định, llama.cpp memory-map file GGUF, nên file lớn hơn RAM vẫn có thể bắt đầu chạy. Sau đó kernel liên tục đọc weights từ disk vào và ghi ra trên mỗi token. Tốc độ generation giảm xuống còn vài giây cho mỗi token, trong khi disk bị ghim ở mức 100 phần trăm. Truyền --no-mmap để buộc cấp phát thực sự. Khi đó tiến trình sẽ fail ngay thay vì chạy chậm dần. Khi kernel can thiệp, dmesg hiển thị nguyên nhân:

Out of memory: Killed process 1234 (llama-server)

Model file hoàn toàn không load được. GGUF được build cho model family mới hơn engine của bạn sẽ trả về lỗi, trong đó nêu architecture mà engine không nhận biết:

error loading model architecture: unknown model architecture: 'qwen3next'

Cách khắc phục là upgrade engine, không phải đổi file. Đây là cái giá của việc pin version, và cũng là lý do bạn phải ghi lại build number. Bạn cần biết mình đang upgrade từ bản nào.

API trả lời được trên máy local nhưng app của bạn không truy cập được. Ollama bind vào 127.0.0.1:11434, nên host khác sẽ nhận lỗi connection refused. Chỉ đặt OLLAMA_HOST=0.0.0.0:11434 thông qua systemctl edit ollama khi port nằm sau firewall hoặc trên private network, vì API không có authentication ở phía trước.

Reply đầu tiên sau một khoảng tạm dừng rất chậm. Model đã bị unload sau 5 phút idle và đang được đọc lại từ disk. Chạy ollama ps ngay trước request sẽ không hiển thị model nào đang được load, qua đó xác nhận nguyên nhân. Tăng OLLAMA_KEEP_ALIVE.

Vậy nên chạy công cụ nào?

Chạy Ollama khi bạn muốn hệ thống tự quản lý model và cung cấp endpoint theo chuẩn OpenAI mà không cần cấu hình thêm. Đây là lựa chọn mặc định phù hợp cho lần triển khai đầu tiên và cho mọi trường hợp bạn sẽ liên tục thay đổi model.

Chạy trực tiếp llama.cpp khi bộ nhớ hạn chế đến mức bạn cần tự chọn dòng quantisation, khi muốn dùng /health, /slots và /metrics để monitoring, hoặc khi cần một flag mà Ollama không cung cấp. Đây là lựa chọn phù hợp trên VPS chỉ vừa đủ chạy model, vì các thiết lập giúp model chạy vừa bộ nhớ cũng chính là những thiết lập Ollama tự chọn thay bạn.

Chạy cả hai là việc bình thường. Dùng Ollama để thử nghiệm, còn llama.cpp cho model duy nhất được đưa vào production và bạn không muốn model đó tự thay đổi.

FAQ

Ollama chỉ là một wrapper quanh llama.cpp phải không?

Gần đúng, nhưng wrapper này thực hiện nhiều việc. README của Ollama liệt kê llama.cpp là inference backend của nó (được kiểm tra ngày 2 August 2026). Ollama bổ sung registry model, prompt template để chuyển các message trong cuộc trò chuyện thành prompt, một tập sampling parameter mặc định, daemon tự unload model khi idle và HTTP API. Khi so sánh số token mỗi giây với cùng thiết lập, bạn đang so sánh cùng một engine với chính nó. Thứ bạn thực sự lựa chọn là management layer.

Bản nào nhanh hơn trên VPS chỉ dùng CPU?

Hai bản dùng chung engine, nên với cùng model file, quantisation, context size và thread count, tốc độ thường gần tương đương. Những khác biệt được báo cáo thường đến từ các giá trị mặc định khác nhau, phổ biến nhất là context length và thread count, chứ không phải từ engine. Hãy đo bằng llama-bench -m <file> -p 512 -n 128 và so sánh cột tg trên chính máy của bạn trước khi tin bất kỳ số liệu được công bố nào.

Tôi có thể dùng file GGUF của mình với Ollama không?

Có. Đặt file trên server, tạo một Modelfile có dòng đầu tiên là FROM ./your-model.gguf, thêm các dòng PARAMETER cần thiết, chẳng hạn num_ctx, rồi chạy ollama create your-name -f ./Modelfile. ollama ls sẽ liệt kê file này cùng với các model bạn đã pull từ registry. Đây là cách dùng một quantisation không có trong registry.

Tôi cần bao nhiêu RAM cho model 8B?

Hãy tính dung lượng file, cộng với KV cache và runtime. Bản Llama 3.1 8B Q4_K_M có dung lượng khoảng 4.58 GiB trên disk, còn context 4096 token thêm khoảng 512 MiB cache. Vì vậy, 8 GiB RAM là mức thoải mái, còn 4 GiB là không đủ. Cache tăng theo context: cùng model đó với context 32,768 token cần riêng khoảng 4 GiB cache. Với Ollama, hãy nhớ requirement cũng tăng theo OLLAMA_NUM_PARALLEL.