Ollama, vLLM hay llama.cpp: chọn máy chủ bạn sẽ không phải thay
Câu hỏi luôn đến với cùng một hình dạng: “Chúng tôi có GPU rồi. Nên chạy cái nào — Ollama, vLLM hay llama.cpp?”
Thường thì người hỏi đã đọc ba bài viết, mỗi bài tuyên bố một người thắng khác nhau. Đó là kết quả hợp lý, bởi vì rất có thể cả ba bài đều đúng — với hoàn cảnh của riêng họ. Ba dự án này không cạnh tranh xem ai là máy chủ suy luận tốt nhất. Chúng là ba lựa chọn khác nhau về việc bao nhiêu người sẽ dùng hệ thống cùng một lúc.
Nhìn theo cách đó thì lựa chọn gần như tự hiện ra.
Chúng giống nhau nhiều hơn bạn tưởng
Cả ba đều nạp một mô hình transformer, chạy attention trên KV cache, và trả token về
theo luồng qua một endpoint /v1/chat/completions tương thích OpenAI. Trỏ ứng dụng của
bạn vào bất kỳ cái nào cũng chạy được. Ollama vốn được xây trên llama.cpp và đến nay
vẫn chia sẻ phần lớn nguồn gốc đó. Trên một GPU, một người dùng, mỗi lần một yêu cầu,
với mức lượng tử hóa tương đương, cả ba sẽ cho cảm giác gần như nhau — và llama.cpp
hay Ollama thậm chí có thể nhanh hơn, vì chúng mang theo ít bộ máy điều phối hơn.
Điểm cuối cùng đó đáng để dừng lại, vì nó là nguồn gốc của phần lớn lời khuyên sai về chủ đề này. Ai đó đo tốc độ sinh phản hồi đơn lẻ trên laptop, thấy vLLM chẳng có gì ấn tượng, rồi viết bài. Phép đo ấy không sai. Nó chỉ đang đo đúng cái trường hợp duy nhất mà toàn bộ thiết kế của vLLM không đóng góp được gì.
Ba cái này chỉ tách nhau ra khi có tải — và chỉ khi có tải.
Mỗi cái đang tối ưu cho điều gì
Ollama tối ưu cho thời gian đến lần chạy đầu tiên. Gõ ollama run qwen3 là bạn có
mô hình. Nó lo việc tải về, lưu trữ, chuyển đổi mô hình, và một dịch vụ nền tự giải
phóng mô hình đang nhàn rỗi. Không có công cụ nào khác trong lĩnh vực này tôn trọng
buổi chiều của bạn đến thế.
llama.cpp tối ưu cho việc chạy được ở mọi nơi. Trọng số GGUF, một thang lượng tử hóa từ Q2 đến Q8, suy luận trên CPU, đẩy một phần lớp sang GPU, hỗ trợ Metal, CUDA, ROCm, Vulkan. Đây là cái duy nhất trong ba cái chạy được mô hình lớn hơn VRAM của bạn — bạn đẩy sang GPU bao nhiêu lớp vừa được, phần còn lại chạy trên CPU. Chậm, nhưng chạy được, và “chậm” vẫn hơn “không nạp nổi”.
vLLM tối ưu cho số token mỗi giây trên mỗi đồng, ở mức đồng thời cao. PagedAttention và cơ chế gộp lô liên tục tồn tại để giữ GPU luôn bận trong khi nhiều người cùng trò chuyện với nó. Nó muốn toàn bộ mô hình nằm trong VRAM, ở FP16 hoặc một dạng lượng tử hóa gốc cho GPU (AWQ, GPTQ, FP8), và nó muốn một môi trường CUDA đàng hoàng. Đổi lại, nó phục vụ được cả một đám đông trên phần cứng mà lẽ ra chỉ phục vụ nổi vài người.
Khác biệt cốt lõi: KV cache được chia như thế nào
Tính toán cho một GPU rốt cuộc quy về KV cache — trọng số là phần dễ, còn cache mới là thứ thật sự cạn. Lớp phục vụ quyết định bạn tiêu ngân sách đó hiệu quả đến đâu, và đây chính là chỗ ba cái khác nhau thật sự.
Máy chủ của llama.cpp có tham số --parallel N, chia cửa sổ ngữ cảnh thành N khe.
Ollama đưa ra cùng ý tưởng đó qua OLLAMA_NUM_PARALLEL. Cách chia này là tĩnh: cấp
cho máy chủ 32K ngữ cảnh và yêu cầu 8 khe, thì mỗi khe được 4K, bất kể có ai cần đến
hay không. Một người dán vào tài liệu dài sẽ đụng trần ở mức 4K trong khi bảy khe khác
đang ngồi trên phần ngữ cảnh không ai dùng.
vLLM thì cấp phát cache theo trang. Một chuỗi lấy thêm khối khi nó dài ra và trả lại khi kết thúc, nên một người có thể giữ 20K trong khi bảy người khác dùng mỗi người 1K. Cộng thêm gộp lô liên tục — yêu cầu mới nhập vào lô đang chạy ở vòng lặp kế tiếp thay vì đợi lô hiện tại rút hết — và trần số phiên đồng thời trên thực tế tăng lên nhiều lần trên cùng một phần cứng.
Đó là toàn bộ lập luận. Không phải “vLLM nhanh hơn”. Mà là vLLM lãng phí ít hơn trên một ngân sách KV cố định khi nhu cầu không đồng đều — và nhu cầu thật thì luôn không đồng đều.
Để hình dung sơ bộ (hãy tự đo — những con số này thay đổi theo mô hình, mức lượng tử hóa và độ dài ngữ cảnh, và tôi sẽ nghi ngờ bất kỳ bảng nào không nói rõ điều đó):
| Người dùng đồng thời | Ollama / llama.cpp | vLLM |
|---|---|---|
| 1 | Rất tốt — thường là nhanh nhất | Ổn, có chút chi phí phụ |
| 2–4 | Tốt | Tốt |
| 5–15 | Bắt đầu thấy rõ việc xếp hàng | Thoải mái |
| 20+ | Không phải công cụ dành cho việc này | Đúng lý do nó tồn tại |
RAG làm thay đổi phép tính
Nếu bạn phục vụ câu trả lời có truy xuất thay vì trò chuyện thông thường, dạng tải công việc khác đi theo một cách rất đáng kể ở đây. Một yêu cầu RAG gửi đi tám đoạn văn bản đã truy xuất cộng với prompt hệ thống — vài nghìn token đầu vào — và sinh ra vài trăm token trả về. Nó nặng về prefill, mà prefill thì bị giới hạn bởi năng lực tính toán và gộp lô cực kỳ hiệu quả.
Nó cũng lặp lại. Mọi yêu cầu trong một hệ thống RAG đều dùng chung phần hướng dẫn neo nội dung, và nhiều yêu cầu dùng chung cả đoạn văn bản đã truy xuất. Cơ chế cache tiền tố của vLLM tái sử dụng phần KV đã tính cho tiền tố dùng chung thay vì tính lại cho từng yêu cầu — với dạng tải này thì gần như là thông lượng miễn phí.
Vì vậy ngưỡng đồng thời mà vLLM bắt đầu có ý nghĩa đến sớm hơn với RAG so với chat. Một trợ lý tài liệu nội bộ cho mười người đã nằm trong vùng của vLLM rồi, dù mười người nghe có vẻ ít.
Chi phí chuyển đổi mà không ai tính tới
Lời khuyên phổ biến — “bắt đầu với Ollama, chuyển sang vLLM khi vượt quá sức nó” — về cơ bản là đúng, và chính tôi cũng khuyên vậy. Nhưng nó thường được bán như một bước đi miễn phí vì API tương thích, trong khi API chưa bao giờ là phần tốn kém.
Cái thật sự tốn của bạn:
- Trọng số. GGUF không chạy trên vLLM theo cách bạn muốn cho môi trường thật. Bạn phải lấy lại mô hình ở dạng AWQ, GPTQ hoặc FP8. Khác tệp, khác cách lượng tử hóa, khác chất lượng đầu ra.
- Mốc chất lượng. Q4_K_M và AWQ 4-bit không phải cùng một mô hình. Đầu ra sẽ dịch chuyển — thường là nhẹ, thỉnh thoảng lại đúng vào cái prompt mà khách hàng của bạn quan tâm. Nếu bạn không có bộ đánh giá, bạn sẽ không phát hiện ra; bạn chỉ nhận được phản hồi “nó tệ đi” mà không có gì để đối chiếu.
- Tham số sinh mặc định. Mỗi dự án đặt mặc định khác nhau cho temperature, top-p, hình phạt lặp. Chuyển một prompt đã tinh chỉnh theo bộ này sang bộ khác thì hành vi thay đổi vì những lý do chẳng liên quan gì đến mô hình.
- Vận hành. Ollama là một dịch vụ cứ thế chạy. vLLM là một tiến trình Python có quan điểm riêng về phiên bản CUDA, khởi động lâu, và chiếm sẵn bộ nhớ GPU. Giờ phải có người chịu trách nhiệm cho chuyện đó.
Không điều nào ở trên là lý do để bắt đầu bằng vLLM. Chúng là lý do để giữ một bộ đánh giá ngay từ ngày đầu, để việc chuyển đổi là một phép đo chứ không phải một cuộc tranh cãi. Phần đó thì đúng là miễn phí, và bỏ qua nó là sai lầm tôi gặp nhiều nhất.
Tôi sẽ khuyên bạn chạy cái gì
| Hoàn cảnh | Chạy | Vì sao |
|---|---|---|
| Làm thử, một lập trình viên, “liệu cái này có chạy được không” | Ollama | Đường ngắn nhất đến một mô hình chạy được. Đừng nghĩ nhiều. |
| Máy Mac, phần cứng hỗn hợp, hoặc mô hình lớn hơn VRAM | llama.cpp | Cái duy nhất xuống cấp một cách êm ái thay vì từ chối nạp. |
| Công cụ nội bộ, dưới khoảng 5 người dùng đồng thời | Ollama hoặc llama.cpp | Tiết kiệm vận hành thật sự, và bạn còn xa mới chạm trần. |
| Từ 10 người dùng đồng thời trở lên trên GPU chuyên dụng | vLLM | Đây đúng là trường hợp nó được sinh ra để giải quyết. |
| RAG trên một kho tài liệu thật | vLLM, sớm hơn bạn nghĩ | Nặng prefill và cache được tiền tố. |
| Chạy lô qua một tập tài liệu suốt đêm | vLLM | Thông lượng là mục tiêu duy nhất; độ trễ không quan trọng. |
Một lưu ý về Ollama khiến người ta mất thời gian nhiều hơn bất cứ điều gì khác trên trang này: hãy kiểm tra độ dài ngữ cảnh. Mặc định của nó nhỏ, và một prompt RAG dài sẽ bị cắt bớt trong im lặng thay vì báo lỗi. Mô hình sau đó trả lời dựa trên phần còn sót lại, một cách đầy tự tin, và lớp truy xuất phải chịu tiếng oan cho một giới hạn vốn được đặt trong cấu hình máy chủ.
Tóm lại
Hãy chọn theo mức đồng thời, đừng chọn theo bài đo hiệu năng. Một người dùng: cái nào cũng được, chọn theo sự tiện lợi. Một nhóm nhỏ trên phần cứng khó chiều: llama.cpp. Một đội ngũ, một GPU chuyên dụng, và một hệ thống mà người ta phụ thuộc vào: vLLM, và không có gì sát nút cả.
Rồi hãy giữ một bộ đánh giá ngay từ tuần đầu tiên, vì cuộc di chuyển rẻ tiền duy nhất là cuộc di chuyển bạn đo được. Máy chủ bạn bắt đầu hiếm khi là máy chủ bạn kết thúc — và điều đó không sao cả, miễn là bạn chứng minh được việc chuyển đổi không làm bạn mất gì.
Demo trên trang này chạy theo hướng đám mây chứ không phải máy chủ tự vận hành, nhưng hình dạng truy xuất thì giống hệt: tám đoạn văn bản, một prompt neo nội dung, một trích dẫn cho mỗi khẳng định. Nếu bạn đang tính toán một cỗ máy để chạy điều đó nội bộ, đó là cuộc trò chuyện đáng có trước khi mua GPU, chứ không phải sau.