Nên chọn Ollama hay vLLM để chạy LLM trên server?

Ollama và vLLM, trong một đoạn văn

Ollama là trình quản lý mô hình tích hợp sẵn server: nó tải xuống các trọng số đã được lượng tử hóa, nạp chúng vào bộ nhớ và phản hồi qua 127.0.0.1:11434, ngay cả khi máy chỉ có CPU. vLLM là engine tối ưu lưu lượng: nó duy trì GPU ở trạng thái hoạt động tối đa với nhiều yêu cầu chạy cùng lúc, và đây là công cụ không phù hợp trên máy không có GPU. Đó là toàn bộ vấn đề cần quyết định. Một người dùng trò chuyện với trợ lý cục bộ là công việc của Ollama. Một ứng dụng phục vụ cho cả một đội ngũ là công việc của vLLM.

Cả hai đều sử dụng HTTP API tương thích với OpenAI, vì vậy mã nguồn client có thể chuyển đổi giữa hai công cụ này chỉ bằng cách thay đổi base URL. API không phải là điểm khác biệt. Điểm khác biệt nằm ở cách hệ thống xử lý khi có yêu cầu thứ hai gửi đến trong lúc yêu cầu thứ nhất vẫn đang tạo token.

Ollama thực chất là gì

Ollama là một lớp tiện ích. Nó cung cấp cho bạn một registry mô hình (ollama pull llama3.1:8b), kho lưu trữ trọng số cục bộ, prompt trò chuyện, dịch vụ systemd và HTTP API, tất cả chỉ trong một lệnh cài đặt. Các mô hình mà nó phục vụ là các tệp GGUF, thường được lượng tử hóa 4-bit, đó là lý do tại sao một mô hình 7B hoặc 8B chỉ chiếm khoảng 5 GB trên ổ đĩa thay vì 16 GB. Lượng tử hóa là yếu tố giúp việc suy luận trên CPU trở nên khả thi.

Bộ chạy (runner) của nó được xây dựng dựa trên llama.cpp, thư viện suy luận C++ đã giúp việc lượng tử hóa GGUF trở nên thực tế trên phần cứng thông thường. Ollama sau đó đã bổ sung engine riêng cho một số dòng mô hình mới hơn, nhưng llama.cpp vẫn là nền tảng cho hầu hết những gì nó phục vụ. Vì vậy, khi mọi người so sánh Ollama với llama.cpp, họ chủ yếu đang so sánh một lớp công thái học với thứ mà nó bao bọc.

Mục tiêu thiết kế là dành cho một người dùng. Tính đến tháng 7 năm 2026, giá trị mặc định cho OLLAMA_NUM_PARALLEL là 1, nghĩa là một mô hình xử lý một yêu cầu tại một thời điểm và mọi thứ khác sẽ chờ trong hàng đợi chứa mặc định 512 mục (OLLAMA_MAX_QUEUE). Bạn có thể tăng thiết lập song song, và phần dưới đây giải thích chi phí bạn phải trả. Nếu bạn chưa từng chạy Ollama trước đây, hãy bắt đầu với lưu trữ Ollama trên VPS và giữ đóng cổng 11434, vì API không có bất kỳ hình thức xác thực nào.

vLLM thực chất là gì

vLLM chỉ là một inference server và không gì khác. Nó không quản lý thư viện model, không có chat prompt và sẽ không tự tải model cho bạn khi có yêu cầu. Bạn chỉ định một Hugging Face repository khi khởi chạy, nó sẽ tải model đó và phục vụ cho đến khi bạn dừng tiến trình.

Đổi lại sự hạn chế đó, bạn nhận được throughput cao. Hai cơ chế thực hiện công việc này. PagedAttention lưu trữ KV cache (key-value cache, trạng thái attention trên mỗi token mà model giữ cho mọi yêu cầu đang hoạt động) trong các block có kích thước cố định, tương tự cách hệ điều hành phân trang bộ nhớ. Một yêu cầu không còn cần một vùng nhớ liên tục lớn được đặt trước cho trường hợp xấu nhất, vì vậy bộ nhớ vốn bị chiếm dụng mà không dùng đến nay đã có sẵn cho nhiều yêu cầu đồng thời hơn. Continuous batching cho phép một yêu cầu mới tham gia vào batch đang chạy tại bước giải mã tiếp theo thay vì phải đợi batch hiện tại kết thúc. Một chuỗi đã hoàn thành sẽ rời khỏi batch ngay lập tức và vị trí của nó được lấp đầy.

Kết quả thực tế: trên một GPU duy nhất, việc tăng từ một người dùng đồng thời lên ba mươi sẽ làm tăng mạnh tổng số token mỗi giây, trong khi tốc độ trên mỗi người dùng giảm ít hơn nhiều so với dự kiến. Với thiết lập mặc định của Ollama, việc tăng từ một người dùng lên ba mươi chỉ khiến hai mươi chín người còn lại phải chờ đợi.

Continuous batching là sự khác biệt cốt lõi

Hãy hình dung năm yêu cầu cùng gửi đến một server tại cùng một thời điểm trên phần cứng giống hệt nhau.

Ollama với các thiết lập mặc định sẽ chạy yêu cầu thứ nhất cho đến khi hoàn tất, sau đó đến yêu cầu thứ hai, và cứ tiếp tục như vậy. Người gọi thứ năm phải đợi bốn lượt tạo nội dung đầy đủ. Tổng lưu lượng xử lý chỉ xấp xỉ tốc độ của một lượt tạo, vì bộ xử lý chỉ đang làm việc trên một chuỗi duy nhất tại một thời điểm.

vLLM giải mã cả năm yêu cầu trong cùng một forward pass. Việc tạo một token cho năm chuỗi gần như không tốn kém hơn so với việc tạo một token cho một chuỗi, vì phần tốn kém nhất là đọc trọng số mô hình từ bộ nhớ, và thao tác đọc đó được chia sẻ cho toàn bộ batch. Đây chính là thực tế về băng thông bộ nhớ khiến cho việc suy luận trên CPU bị chậm: bạn phải trả chi phí cho việc di chuyển trọng số, chứ không phải cho các phép tính số học.

Bạn có thể thiết lập OLLAMA_NUM_PARALLEL=4 và nhận được một phần hiệu quả này. Cái giá phải trả là bộ nhớ. Mỗi slot song song cần KV cache riêng của nó, và Ollama chia nhỏ cửa sổ ngữ cảnh cho các slot, vì vậy bốn yêu cầu song song đối với một mô hình được cấu hình cho 8192 token sẽ để lại cho mỗi yêu cầu 2048 token ngữ cảnh. Paged cache của vLLM là thứ giúp tránh được sự đánh đổi đó, vì các block được cấp phát cho một yêu cầu khi yêu cầu đó thực sự tăng kích thước.

Cài đặt và chạy với Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Script cài đặt tạo một người dùng hệ thống ollama, cài đặt file binary và đăng ký ollama.service gắn với 127.0.0.1:11434. Dòng eval rate được in bởi --verbose là tốc độ token trên giây thực tế trên máy chủ đó. Hãy tin tưởng con số này hơn bất kỳ số liệu nào được công bố.

Để tăng mức độ đồng thời, hãy sử dụng một file drop-in của systemd để bản nâng cấp không ghi đè lên thay đổi của bạn:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps hiển thị những gì đã được tải, và cột PROCESSOR của nó cho biết thông tin chính xác. 100% CPU nghĩa là không có GPU nào được sử dụng, đây là lời giải thích trung thực cho hầu hết các báo cáo rằng Ollama chạy chậm.

Cài đặt và chạy vLLM

vLLM yêu cầu Linux và Python từ 3.10 đến 3.13. Hãy cài đặt nó vào một môi trường ảo riêng biệt, vì nó yêu cầu một bản build PyTorch cụ thể:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Sau đó, hãy chạy model. Tên model là ID repository trên Hugging Face, không phải là một tag ngắn:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Lần khởi động đầu tiên sẽ chậm vì hệ thống cần tải xuống các trọng số (weights) và thực hiện profiling GPU để quyết định số lượng block KV cache phù hợp. Nó lắng nghe trên cổng 8000. Hãy kiểm tra trước khi viết bất kỳ mã client nào:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Nếu Docker đã có sẵn trên máy, image chính thức sẽ giúp bạn tránh được các vấn đề về phụ thuộc CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host là bắt buộc, không phải tùy chọn: PyTorch truyền các tensor giữa các tiến trình thông qua bộ nhớ chia sẻ (shared memory), và dung lượng bộ nhớ chia sẻ mặc định của Docker quá nhỏ cho việc suy luận (inference) song song trên tensor.

Các flag quan trọng nhất trong môi trường production là --max-model-len (cửa sổ ngữ cảnh mà bạn sẵn sàng cấp phát), --gpu-memory-utilization (tỷ lệ phần trăm dung lượng card mà vLLM được phép chiếm dụng, mặc định là 0.92 tính đến tháng 7 năm 2026), --tensor-parallel-size để chia một model ra nhiều GPU, và --api-key.

Xác thực là một flag trên vLLM và không có trên Ollama

vLLM bắt buộc sử dụng bearer token nếu bạn cung cấp cho nó:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Giá trị tương tự có thể được lấy từ biến môi trường VLLM_API_KEY. Một yêu cầu không có token sẽ nhận phản hồi HTTP 401. Điều này vẫn chưa phải là lý do để mở port 8000 trên giao diện công cộng, vì vLLM không có tính năng giới hạn tốc độ (rate limiting) và token HTTP thuần có thể bị đọc được trong quá trình truyền tải, nhưng nó có nghĩa là server có khái niệm về người gọi.

Ollama thì không có tính năng này. Không có key, không có đăng nhập, không có danh sách cho phép (allow-list). Bất kỳ tiến trình nào có thể kết nối tới port 11434 đều có thể chạy, tải về hoặc xóa các model. Hãy giữ nó trên loopback và truy cập thông qua một VPN WireGuard do bạn tự quản lý, hoặc thông qua một reverse proxy có xác thực để kết thúc TLS (transport layer security).

Phần cứng: yêu cầu cho từng loại

Ollama chạy trên CPU. Một model được lượng tử hóa 4-bit tiêu tốn khoảng nửa gigabyte RAM cho mỗi tỷ tham số, cộng thêm khoảng một gigabyte overhead khi chạy và thêm dung lượng cho context. Do đó, một model 3B cần khoảng 4 GB RAM trống và model 8B cần khoảng 8 GB. Tốc độ trên một vCPU dùng chung chỉ đạt mức một chữ số hoặc thấp hơn hai chữ số token mỗi giây. Đây là giới hạn băng thông bộ nhớ, không phải do cấu hình sai và không có flag nào khắc phục được điều này.

vLLM yêu cầu GPU. Đường dẫn mặc định của nó phục vụ các trọng số không lượng tử hóa ở độ chính xác 16-bit, tương đương khoảng 2 GB cho mỗi tỷ tham số: một model 8B cần khoảng 16 GB bộ nhớ video chỉ riêng cho trọng số, chưa tính đến KV cache giúp bạn đạt được khả năng xử lý đồng thời mà bạn cài đặt vLLM để có. Trên một card 24 GB, bạn sẽ còn lại dung lượng cache khả dụng. Trên card 16 GB thì không, vì vậy bạn phải chọn model nhỏ hơn hoặc truyền --quantization với một checkpoint đã được lượng tử hóa. Backend CPU có tồn tại, nhưng các gói cài đặt tiêu chuẩn không được xây dựng cho nó, và việc sử dụng backend này làm mất đi lý do chính để chạy vLLM.

Do đó, câu hỏi về phần cứng thường quyết định câu hỏi về phần mềm. Không có GPU nghĩa là dùng Ollama. Một GPU thuê ngoài đang ở mức sử dụng 5 phần trăm vì các yêu cầu đang được xử lý tuần tự nghĩa là bạn cần vLLM.

Lựa chọn cho khối lượng công việc của bạn

• Một người dùng, một VPS CPU, soạn thảo và tóm tắt: Ollama. Tốc độ ở mức chấp nhận được và không có giải pháp nào đơn giản hơn.
• Một trợ lý lập trình, hoặc một máy chủ MCP kết nối các công cụ của bạn với một model cục bộ, mà chỉ mình bạn sử dụng: Ollama. Khả năng xử lý đồng thời một yêu cầu là khối lượng công việc thực tế.
• So sánh năm model trong tuần này: Ollama. Việc tải về và xóa các model đã gắn thẻ chính là thế mạnh của nó, trong khi vLLM yêu cầu khởi động lại tiến trình cho mỗi model.
• Một ứng dụng nội bộ, một sản phẩm chat, hoặc một pipeline truy xuất có người dùng thực tế: vLLM. Đây là nơi việc xử lý theo lô (batching) xứng đáng với chi phí GPU.
• Một tác vụ hàng loạt chấm điểm hàng trăm nghìn tài liệu qua đêm: vLLM, với --max-num-seqs cao. Thông lượng (throughput) là chỉ số duy nhất quan trọng và độ trễ trên mỗi tài liệu thì không.
• Một nền tảng tác nhân (agent platform) nơi nhiều tác nhân AI tự lưu trữ truy cập model cùng lúc: vLLM, vì lưu lượng truy cập của tác nhân có tính chất bùng nổ và song song.

Các chế độ lỗi và thông báo tương ứng

vLLM từ chối khởi động với lỗi KV cache. Thông báo hiển thị cả hai con số:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Model khai báo cửa sổ ngữ cảnh lớn hơn bộ nhớ còn lại sau khi tải trọng số. Hãy giảm giá trị này bằng --max-model-len 8192, hoặc tăng --gpu-memory-utilization nếu không có tiến trình nào khác đang sử dụng card đồ họa. Việc đẩy mức sử dụng vượt quá khoảng 0.95 thường dẫn đến lỗi này khi khởi động, thay vì lỗi CUDA out-of-memory khi đang tải, vốn là tình trạng tệ hơn.

Ollama in ra Killed trong khi đang tạo phản hồi. Trình quản lý bộ nhớ của Linux (OOM killer) đã dừng tiến trình vì model cần nhiều RAM hơn mức máy chủ hiện có. Xác nhận bằng lệnh sudo dmesg | grep -i oom. Cách khắc phục là sử dụng model nhỏ hơn hoặc được lượng tử hóa mạnh hơn, không phải thay đổi cài đặt.

Ollama phản hồi bình thường khi chạy đơn lẻ nhưng bị treo khi chịu tải. Không có lỗi nào xuất hiện. Các yêu cầu mất nhiều thời gian hơn khi có nhiều người gọi, vì OLLAMA_NUM_PARALLEL=1 đang xử lý tuần tự chúng. Hãy tăng giá trị này và chấp nhận ngữ cảnh nhỏ hơn cho mỗi yêu cầu, hoặc chuyển khối lượng công việc sang vLLM.

vLLM trả về lỗi 401 cho mọi yêu cầu. Bạn đã khởi động nó với --api-key nhưng client không gửi header Authorization. Hầu hết các thư viện client OpenAI đều gửi bất kỳ giá trị nào bạn truyền vào làm key, vì vậy hãy thiết lập key tại đó thay vì bỏ cờ này.

vLLM báo không tìm thấy model. Ollama tự động tải model khi cần, còn vLLM thì không. Trường model trong nội dung yêu cầu phải khớp với id kho lưu trữ mà bạn đã sử dụng khi khởi chạy, hoặc giá trị của --served-model-name nếu bạn đã thiết lập. Xác nhận chuỗi chính xác bằng curl http://localhost:8000/v1/models.

Chạy cả hai là một giải pháp hợp lý

Chúng không loại trừ lẫn nhau. Một mô hình phổ biến là chạy vLLM trên một instance GPU để phục vụ ứng dụng, đồng thời chạy Ollama trên một VPS thông thường bên cạnh để xử lý các script cục bộ, cron job và thử nghiệm các bản phát hành model mới. Cả hai endpoint đều tương thích với OpenAI, vì vậy bạn chỉ cần một thư viện client và thay đổi base-URL là có thể sử dụng cả hai. Việc kiểm soát chi phí ở đây quan trọng hơn bất kỳ engine nào, vì một GPU nhàn rỗi vẫn tính phí như khi đang hoạt động, và việc giữ cho chi phí agent và inference ở mức dự đoán được là một lĩnh vực riêng biệt so với việc chọn server.

FAQ

vLLM có nhanh hơn Ollama không?

Với một yêu cầu đơn lẻ trên cùng một GPU, sự chênh lệch là không đáng kể vì cả hai đều thực hiện cùng một phép tính. Với nhiều yêu cầu đồng thời, vLLM vượt trội hơn hẳn vì cơ chế continuous batching giải mã mọi chuỗi đang hoạt động trong một lần forward pass, trong khi mặc định của Ollama chạy chúng lần lượt. Trên máy chỉ có CPU, câu hỏi này không áp dụng: Ollama chạy được ở đó còn vLLM thì thực tế là không.

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

Không hiệu quả. Các bản cài đặt chuẩn nhắm đến GPU NVIDIA hoặc AMD, và lý do vLLM tồn tại — giữ cho bộ tăng tốc luôn bão hòa với các yêu cầu được batch — sẽ biến mất trên CPU. Một backend CPU tồn tại để phục vụ công việc phát triển. Để suy luận (inference) thực tế trên CPU, hãy sử dụng trực tiếp Ollama hoặc llama.cpp.

Sự khác biệt giữa Ollama và llama.cpp là gì?

llama.cpp là thư viện suy luận, còn GGUF là định dạng trọng số đã được lượng tử hóa của nó. Runner của Ollama được xây dựng dựa trên đó và bổ sung các phần mà llama.cpp để bạn tự xử lý: registry mô hình, tự động tải xuống, server thường trú, unit systemd và endpoint tương thích với OpenAI. Ollama đã thêm engine riêng cho một số dòng mô hình mới hơn, vì vậy cả hai không còn giống hệt nhau ở bên dưới.

vLLM cần bao nhiêu bộ nhớ GPU cho mô hình 8B?

Ở độ chính xác 16-bit, riêng trọng số đã chiếm khoảng 16 GB, tương đương khoảng 2 GB cho mỗi tỷ tham số, và KV cache cần thêm không gian ngoài mức đó. Một card 24 GB là thoải mái. Một card 16 GB yêu cầu checkpoint đã lượng tử hóa hoặc một mô hình nhỏ hơn. vLLM chiếm một phần của card được thiết lập bởi --gpu-memory-utilization, mặc định là 0.92 tính đến tháng 7 năm 2026.

Tôi có cần thay đổi mã nguồn ứng dụng để chuyển đổi giữa chúng không?

Thường chỉ cần thay đổi base URL, API key và tên mô hình. Ollama cung cấp giao diện tương thích OpenAI tại http://127.0.0.1:11434/v1 và bỏ qua key, trong khi vLLM cung cấp tại http://localhost:8000/v1 và bắt buộc sử dụng key nếu bạn đã thiết lập. Tên mô hình khác nhau về định dạng: llama3.1:8b cho Ollama, một id kho lưu trữ đầy đủ như Qwen/Qwen2.5-1.5B-Instruct cho vLLM.