Chọn vLLM, TGI, Ollama hay llama.cpp để self-host model open-weight
Thử nghiệm cộng đồng với model cỡ 8B cho thấy mỗi engine hợp một bài toán khác: vLLM cho tải đồng thời cao, Ollama cho dev, TGI cho hệ sinh thái Hugging Face và llama.cpp khi phần cứng bị giới hạn.
Self-host model open-weight không chỉ là chuyện “nạp model lên GPU rồi chạy”. Khi có nhiều request đồng thời, khác biệt giữa vLLM, TGI, Ollama và llama.cpp sẽ hiện rõ ở độ trễ, thông lượng, VRAM và công sức vận hành.
Một team trong cộng đồng đã thử bốn công cụ này với model cỡ 8B tham số, gồm bản gốc và bản lượng tử hoá 4-bit. Hạ tầng gồm một máy có 1 GPU 24GB và một máy có 2 GPU 80GB; tải giả lập là 50 người dùng đồng thời, đầu vào trung bình 800 token và đầu ra khoảng 300 token.
Điểm quan trọng: đây là kết quả từ một thử nghiệm cụ thể, không phải benchmark có thể áp dụng nguyên xi cho mọi model, GPU hay workload. Nhưng cách chọn tiêu chí đo là rất sát thực tế production.
Bảng chọn nhanh
| Công cụ | Phù hợp nhất khi | Điểm mạnh được ghi nhận | Điều cần cân nhắc |
|---|---|---|---|
| vLLM | Production có nhiều request đồng thời, GPU riêng | Thông lượng cao trong thử nghiệm, API tương thích OpenAI, hỗ trợ chia model trên nhiều GPU | Có thể chiếm phần lớn VRAM khi khởi động; cần tinh chỉnh cấu hình |
| TGI | Team quen hệ sinh thái Hugging Face | Triển khai Docker gọn, có chỉ số giám sát, hiệu năng gần vLLM ở tải vừa | Hỗ trợ model mới đôi khi chậm hơn |
| Ollama | Máy dev, demo, công cụ nội bộ ít người dùng | Cài đặt và tải model đơn giản, tự quản lý việc nạp và giải phóng model | Độ trễ tăng nhanh hơn khi tải đồng thời cao |
| llama.cpp server | CPU, thiết bị biên hoặc phần cứng hạn chế | Nhẹ, ít phụ thuộc, hỗ trợ nhiều mức lượng tử hoá | Thông lượng đa người dùng trên GPU không bằng vLLM trong thử nghiệm |
Khi nào nên chọn vLLM?
Theo bài thử nghiệm, vLLM có thông lượng cao nhất trong bốn lựa chọn khi số người dùng đồng thời tăng lên. Team đăng bài cho rằng lợi thế đến từ cách quản lý KV cache và gộp request liên tục.
Đây là lựa chọn nên đưa vào shortlist đầu tiên nếu bạn có:
GPU chuyên dụng cho dịch vụ model;
nhiều request đồng thời;
nhu cầu chạy model trên nhiều GPU;
ứng dụng đã sử dụng API theo phong cách OpenAI-compatible.
Đánh đổi là vLLM có nhiều tham số vận hành hơn và có thể sử dụng gần hết bộ nhớ GPU ngay từ lúc khởi động. Nếu GPU còn phải chia sẻ cho workload khác, đây là điểm cần kiểm tra kỹ.
TGI hợp với đội nào?
TGI phù hợp khi team đã quen với Hugging Face và muốn triển khai theo hướng Docker. Trong trải nghiệm được chia sẻ, TGI ổn định, có sẵn chỉ số giám sát và đạt hiệu năng gần vLLM ở mức tải vừa.
Tuy nhiên, bài đăng cũng lưu ý rằng việc hỗ trợ model mới đôi khi có thể đến chậm hơn. Vì vậy, nếu model bạn định dùng vừa ra mắt hoặc có kiến trúc đặc thù, hãy xác minh mức độ hỗ trợ trước khi chốt hạ tầng.
Ollama: rất tiện cho dev, nhưng cần thận trọng khi chịu tải
Ollama nổi bật ở trải nghiệm bắt đầu nhanh: cài đặt đơn giản, tải model thuận tiện và tự quản lý việc nạp hoặc giải phóng model. Đây là lý do nó hợp với máy cá nhân, môi trường thử nghiệm và demo nội bộ.
Nhưng với workload của bài thử nghiệm, Ollama không phải lựa chọn tốt nhất cho tải đồng thời cao. Người đăng bài ghi nhận rằng ở mức 50 người dùng đồng thời, thời gian chờ token đầu tiên của Ollama cao hơn khoảng 4 lần so với vLLM.
Con số này chỉ phản ánh cấu hình và workload cụ thể của team thử nghiệm. Dù vậy, nó là lời nhắc hữu ích: một công cụ tối ưu cho trải nghiệm developer chưa chắc đã là công cụ tối ưu cho hàng đợi production.
llama.cpp khi phần cứng là ràng buộc lớn nhất
llama.cpp server là lựa chọn thực dụng nếu bạn phải chạy trên CPU, máy cấu hình thấp hoặc thiết bị biên. Công cụ này nhẹ, ít phụ thuộc và hỗ trợ nhiều mức lượng tử hoá.
Nếu mục tiêu là phục vụ nhiều người dùng trên GPU mạnh, bài thử nghiệm đánh giá thông lượng của llama.cpp không bằng vLLM. Nhưng khi không có GPU mạnh hoặc cần triển khai gọn trên phần cứng hạn chế, llama.cpp vẫn có vị trí riêng.
Đừng chỉ đo token/giây với một request
Điểm đáng học nhất từ bài chia sẻ không nằm ở việc công cụ nào thắng tuyệt đối, mà là cách đo gần với tải thật.
Trước khi chọn engine, hãy đo ít nhất các chỉ số sau:
Thời gian đến token đầu tiên: người dùng thường cảm nhận độ nhanh của ứng dụng qua chỉ số này.
Token/giây khi có tải đồng thời: không suy luận production từ kết quả chạy một request.
VRAM còn trống: kiểm tra sau khi nạp model, với độ dài context và số request đồng thời gần thực tế.
Tỷ lệ timeout, lỗi và request phải xếp hàng: đây là phần dễ bị bỏ qua khi chỉ thử chat thủ công.
Chi phí GPU hàng tháng so với API hiện tại: self-host không phải lúc nào cũng rẻ hơn khi tải thấp.
Một ý kiến trong thảo luận cũng nhắc đến việc đặt giới hạn độ dài context. Nếu không kiểm soát, một request rất dài có thể ảnh hưởng đến độ trễ của cả hệ thống.
Gợi ý triển khai theo từng tình huống
Máy dev và thử nghiệm nội bộ
Bắt đầu với Ollama nếu ưu tiên là cài nhanh, thử model nhanh và giúp lập trình viên dễ tiếp cận model local.
Production có GPU riêng và nhiều người dùng
Ưu tiên đánh giá vLLM nếu hệ thống cần chịu tải đồng thời. Team trong bài đăng chọn vLLM trên máy hai GPU, đặt sau gateway để giới hạn tốc độ và ghi log.
Hạ tầng bám sát Hugging Face
Đưa TGI vào danh sách đánh giá nếu đội đã quen Docker, hệ sinh thái Hugging Face và muốn có chỉ số giám sát sẵn.
CPU, edge hoặc máy cấu hình thấp
Thử llama.cpp server cùng các bản model lượng tử hoá phù hợp. Trong trường hợp này, khả năng chạy được trong giới hạn phần cứng quan trọng hơn throughput cao.
Checklist trước khi chốt
[ ] Đã dùng prompt và độ dài context gần với sản phẩm thật.
[ ] Đã đo thời gian đến token đầu tiên dưới tải đồng thời.
[ ] Đã đo token/giây khi nhiều request cùng chạy.
[ ] Đã kiểm tra VRAM với model, context và mức đồng thời mục tiêu.
[ ] Đã đặt giới hạn context và giới hạn tốc độ request.
[ ] Đã so sánh chi phí GPU với chi phí API ở mức sử dụng thực tế.
[ ] Đã kiểm tra khả năng vận hành: log, lỗi, hàng đợi và giám sát.
Tóm lại: Ollama hợp cho dev và demo; vLLM đáng ưu tiên cho production nhiều tải trên GPU; TGI phù hợp với team dùng Hugging Face; llama.cpp hữu ích khi phần cứng là giới hạn chính.
Đừng chọn engine chỉ vì model khởi động được. Hãy chọn theo tải đồng thời, context, VRAM và mức vận hành mà hệ thống thực tế phải gánh.