Ollama hay llama.cpp trên VPS: nên chạy gì?

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

Ollama và llama.cpp không phải là đối thủ cạnh tranh theo cách câu hỏi này ngụ ý. llama.cpp là inference engine: nó tải file model và chuyển prompt thành token. Ollama là model manager, background daemon và HTTP API chạy trên inference engine đó. README của Ollama vẫn liệt kê llama.cpp là inference backend (đã kiểm tra ngày 27 October 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.

Hãy chạy Ollama khi bạn muốn một service tự tải model theo tên và tiếp tục hoạt động mà không cần bạn can thiệp. Hãy 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 file model, context size và số thread, vì trên VPS nhỏ, mỗi thiết lập đó đều tiêu tốn phần memory vốn đã không đủ.

Thực tế mỗi project là gì

llama.cpp là implementation bằng C và C++ cho việc inference transformer, xây dựng trên thư viện ggml. Nó đọc các file GGUF. GGUF (GGML universal file format) là một container dạng single-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à một HTTP server, llama-cli là prompt tương tác, còn llama-bench đo throughput. Hiện project phát hành các release theo semantic version (MAJOR.MINOR.PATCH), và v0.7.0, được phát hành vào 15 October 2026, là bản mới nhất tính đến 27 October 2026. Các nightly tag có build number vẫn được phát hành song song, vài bản mỗi ngày, và bản mới nhất vào 27 October 2026 là b11913.

Ollama là một program viết bằng Go. Một background daemon, được khởi động bằng ollama serve, load model và trả lời HTTP request; một command line client giao tiếp với daemon đó. Đằng sau cả hai là một registry tại ollama.com, chứa các model đã được đóng gói sẵn. Ollama dùng semantic version. v0.32.5 được phát hành vào 27 July 2026, còn v0.40.12 được release vào 27 October 2026 lúc 00:07 UTC. ollama pull tải một GGUF cùng prompt template và một bộ parameter mặc định, sau đó lưu chúng tạ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, bạn nên biết 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ự chọn 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 đưa các lựa chọn đó thành các flag, với default tự động cho những setting bạn không chỉ định.

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

Quantisation lưu weights bằng số bit ít hơn 16 hoặc 32 bit của model gốc. Các bản build GGUF phổ biến thường dùng khoảng 4, 5 hoặc 8 bit cho mỗi weight. Độ chính xác không đồng nhất trong toàn bộ file. Theo source quantiser của llama.cpp (đọc ngày 27 October 2026), bản build Q4_K_M giữ hầu hết tensor ở 4-bit, nhưng chuyển output layer cùng tensor attention value và feed-forward down ở khoảng một nửa số layer sang 6-bit Q6_K. Các tensor nhỏ như norm thì không quantise. Nhờ vậy, model 8 billion 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 medium. Số càng cao thì giữ độ chính xác càng nhiều 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 công bố trong repository bartowski/Meta-Llama-3.1-8B-Instruct-GGUF trên Hugging Face, đọc ngày 2 August 2026 và chuyển đổi từ byte sang GiB. Có 6 bản build của một model. Bản nhỏ nhất là 2.96 GiB, còn bản lớn nhất là 7.95 GiB. Bản 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ỉ giải quyết một nửa vấn đề. Một bản build vừa với khả năng của bạn chưa chắc là bản đáng dùng. 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 thêm vào 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 bản build đó.

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 đặt số layer chuyển sang GPU (đặt 0 trên máy chỉ chạy bằng CPU). Các setting không được đặt sẽ dùng giá trị mặc định. --fit được bật mặc định để điều chỉnh các argument chưa đặt cho phù hợp với memory của thiết bị.

Với Ollama, quantisation đi kèm tag bạn pull. ollama ls hiển thị chính xác những gì đang có trên disk. Khi registry không có bản build bạn muố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 hiện có. Máy không có GPU sẽ rơi vào bucket nhỏ nhất: 4096 token. Nếu gửi cho nó một tài liệu 20,000 token, các token dư sẽ bị bỏ trước khi model đọc đến. Vì vậy, model có thể trả lời rất tự tin nhưng sai về một file mà nó 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 cho 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 phải xử lý. llama.cpp cũng không có giá trị mặc định đủ đáng tin để bạn bỏ qua. Hãy đặt -c một cách rõ ràng và biết chính xác bạn đã đặt gì.

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 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ó được khả năng quản lý vòng đời mà không phải tự viết các phần đó. Cấu hình được thực hiện thông 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. Theo mặc định, model được giữ trong memory trong 5 phút rồi bị unload. Request tiếp theo phải load lại toàn bộ file trước khi có thể trả lời. Nếu kernel vẫn giữ file trong page cache thì việc này nhanh, nhưng chỉ phần RAM còn trống mới giữ được file ở đó. Khi các tác vụ khác đẩy file ra khỏi cache, file phải được đọc lại từ disk. Vì vậy, việc reload 4.58 GiB có thể biến thời gian phản hồi 2 giây thành 30 giây trên storage chậm. Keep-alive dài sẽ loại bỏ độ trễ này nhưng chiếm RAM liên tục. Cả hai đều có chi phí thực tế. Hãy chọn phương án ít gây ảnh hưởng hơn. Nếu bạn muốn model luôn nằm trong memory, cấu hình 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 giúp bạn không phải tự warm model mỗi khi máy khởi động lại.

llama.cpp không cung cấp daemon hoặc service user, nên bạn phải tự thiết lập cả hai. Từ thư mục llama.cpp mà bạn đã build, hãy cài binary và các library của nó vào /usr/local, tạo user llama, rồi cấp cho user này một bản sao của model:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Nếu bạn dùng release archive thay vì build, hãy trỏ ExecStart đến llama-server bên trong archive, vì archive giữ các library cạnh binary. Sau đó 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. Khi đó process sẽ giữ model trong suốt vòng đời của nó. Theo mặc định, không có gì bị unload khi idle. Tuy nhiên, thêm --sleep-idle-seconds sẽ bật cơ chế tự động unload và reload mà không cần stop service. Nếu bạn chưa quen với việc viết unit, đây là cùng một mẫu với chạy service riêng dưới systemd trên VPS.

Trục 3: API mà app của bạn sẽ kết nối đến

Trục này đã thu hẹp đáng kể. Hiện cả hai project đều dùng định dạng chat của OpenAI, vì vậy hầu hết client library đều hoạt động với cả hai, chỉ cần thay đổi base URL.

Ollama lắng nghe trên 127.0.0.1:11434. Route tương thích với OpenAI là http://localhost:11434/v1/chat/completions, đồng thời Ollama cũng cung cấp native API tại /api/chat. Ollama cũng có tài liệu về route tương thích với Anthropic. Không route nào trong số này cho phép model tự tra cứu thông tin, vì vậy nếu ứng dụng cần câu trả lời mới hơn dữ liệu huấn luyện của model, hãy dự tính tích hợp web search thông qua API của Ollama, Open WebUI hoặc một vòng lặp tool ngắn.

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"}]}'

Khi khởi động bằng các flag ở trên, llama-server lắng nghe tại 127.0.0.1:8080. Nếu không chỉ định gì, hiện nó mặc định dùng port 9931 (đã kiểm tra ngày 27 October 2026), vì vậy hãy giữ --port trên command line nếu app của bạn cần port 8080. Nó cung cấp /v1/chat/completions, /v1/completions và /v1/embeddings, cùng endpoint /completion riêng và web UI tích hợp sẵn. 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 settings của model đã load, /slots để xem từng request slot đang xử lý gì, và /metrics ở định dạng Prometheus sau khi bạn thêm --metrics, vì endpoint đó mặc định bị tắt. Nếu bạn dự đị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 đều mặc định chỉ lắng nghe trên 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à không bao giờ mở port 11434 hoặc 8080 ra Internet.

Một 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 nhất. Điều hữu ích 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 nó:

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 và cột tg là tốc độ sinh token, đề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 đối với tg. Khâu xử lý prompt là phần gây chậm: toàn bộ prompt phải được xử lý trước khi token đầu tiên của output xuất hiện, nên system prompt dài sẽ tạo thêm thời gian chờ cho mọi request. Độ dài reply là phần chi phí bạn có thể kiểm soát trực tiếp, vì ở tốc độ 3 token mỗi giây, model tạo một reply dài 600 token sẽ chiếm máy trong 200 giây, tức hơn 3 phút chỉ để sinh nội dung. Vì vậy, giới hạn output bằng num_predict là cách rẻ nhất để ngăn một reply quá dài biến thành timeout.

Có thể dùng trên CPU: model từ 1B đến 4B để phân loại, trích xuất, tạo summary ngắn hoặc định tuyến. Reply 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ể thay vì một khoảng kích thước, Nemotron 3.5 Lightning được pull và đo 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. Không phù hợp trên CPU: chat tương tác ở 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ẽ cần 1 phút trước khi tạo ra kết quả. Nếu bạn vốn định dùng coding assistant, trỏ một agent đến model tự host sẽ nêu rõ những tác vụ mà 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 người cùng gửi request đến một model, hãy thay đổi engine; phần so sánh Ollama với vLLM khi phục vụ đồng thời trình bày vấn đề này. Nếu vấn đề là tốc độ thuần túy, câu trả lời là VPS có gắn GPU, nơi -ngl bắt đầu có ý nghĩa. Trước cả 2 hướng trên, hãy lấy baseline cho chính phần cứng, vì disk bandwidth và memory bandwidth ảnh hưởng đến thời gian load không kém CPU. Benchmark VPS có thể lặp lại đáng để dành 1 giờ thực hiện.

Cài đặt llama.cpp, cố định theo một build

Cả hai project đều cập nhật hằng tuần, nên hãy ghi lại version bạn đã deploy. 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 dựng sẵn từ trang phát hành. Hiện project cũng phát hành các version theo semantic version: v0.7.0 là bản mới nhất vào ngày 27 October 2026, và trang phát hành của bản này trỏ đến nightly b11669 để tải binary. v0.8.0 được phát hành tiếp vào ngày 28 October 2026, với trang phát hành trỏ đến nightly b11960 để tải binary. Các lệnh bên dưới sử dụng b10224, tag hiện tại vào ngày 2 August 2026; hãy thay bằng tag bạn đã kiểm thử:

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 chính thức yêu cầu 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 plan nhỏ nhất, nên hãy build trên một máy lớn hơn rồi copy 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 lỗi thường gặp và chuỗi bạn sẽ thấy

Ollama từ chối tải model. Các bản Ollama cũ kiểm tra kích thước trước khi tải, và ollama run trả về một dòng có dạng như sau:

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

Source Ollama hiện tại không còn chứa thông báo đó (đã kiểm tra ngày 27 October 2026). Ollama hiện chuyển việc tải model cho llama-server, nên model không vừa sẽ xuất hiện dưới dạng lỗi runner, với các lỗi bắt đầu như sau:

llama-server reported out-of-memory during startup
llama-server process has terminated

Dù gặp trường hợp nào, cách xử lý vẫn giống nhau. Chuyển xuống một dòng quantisation, giảm context length hoặc chọn model nhỏ hơn.

llama.cpp không bị lỗi mà chạy rất chậm. Theo mặc định, llama.cpp memory-map GGUF nên file lớn hơn RAM vẫn có thể khởi động. Sau đó kernel phải đọc weights vào và ghi chúng ra disk cho từng token, khiến tốc độ sinh giảm xuống còn vài giây mỗi token và disk bị ghim ở mức 100 phần trăm. Truyền --load-mode none để tắt memory mapping. Tùy chọn đó đã thay thế --no-mmap; tùy chọn này được ghi nhận là deprecated trong build b10224 được pin và không còn xuất hiện trong các build hiện tại (đã kiểm tra ngày 29 October 2026). Khi kernel can thiệp, dmesg hiển thị nguyên nhân:

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

File model hoàn toàn không tải được. GGUF được build cho một model family mới hơn engine của bạn sẽ trả về lỗi nêu tên architecture mà engine không nhận diện được; <arch> là tên được lưu trong metadata của file:

llama_model_load: error loading model: unknown model architecture: '<arch>'

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

API trả lời từ local nhưng không trả lời từ app của bạn. 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 qua systemctl edit ollama khi port nằm sau firewall hoặc trong private network, vì API không có lớp authentication phía trước.

Reply đầu tiên sau khi tạm dừng rất chậm. Cơ chế unload sau 5 minute idle đã xảy ra và model đang được tải lại, từ disk nếu page cache không giữ được model. Chạy ollama ps ngay trước request không hiển thị model nào đang được load, xác nhận điều này. 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 có chỉ là một wrapper quanh llama.cpp 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à backend inference của nó (được kiểm tra ngày 27 October 2026). Ollama xây dựng thêm trên đó một model registry, prompt template để chuyển các chat message thành prompt, một bộ sampling parameter mặc định, daemon tự unload khi idle và một HTTP API. Khi bạn so sánh số token mỗi giây với các thiết lập giống hệt nhau, 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.

Cái 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, kết quả thường khá sát nhau. 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 vào bất kỳ con số đượ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 như num_ctx, rồi chạy ollama create your-name -f ./Modelfile. ollama ls sẽ liệt kê file đó cùng với những file 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 build Q4_K_M của Llama 3.1 8B chiếm khoảng 4.58 GiB trên disk, còn context 4096 token thêm khoảng 512 MiB cache, nên 8 GiB RAM là đủ thoải mái nhưng 4 GiB thì 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ớ rằng yêu cầu này cũng tăng theo OLLAMA_NUM_PARALLEL.