So sánh các bộ điều phối suy luận tự lưu trữ: LocalAI, exo, GPUStack, vLLM

Khi bạn sở hữu một hoặc nhiều máy có GPU và muốn dựng một endpoint tương thích OpenAI ở phía trước, câu hỏi đặt ra là nên chọn bộ điều phối tự lưu trữ nào. Bài viết này tổng hợp các giải pháp hiện có tính đến tháng 9 năm 2026, phân tích chúng thực sự làm được gì trên nhiều máy và nên chọn cái nào cho từng tình huống cụ thể.

Bảng so sánh tổng quan

Dưới đây là các tiêu chí quan trọng cần cân nhắc khi lựa chọn bộ điều phối:

• Số sao GitHub: phản ánh mức độ phổ biến và cộng đồng hỗ trợ
• Đa phương thức (Modalities): server tự sinh ra gì, không tính plugin
• Đa máy (Multi-machine): một mô hình hoặc một yêu cầu có thể dùng nhiều máy không
• Định tuyến nhận biết cache: yêu cầu tiếp theo có được gửi đến nơi đã có sẵn KV/prefix cache không
• Mở rộng lên cloud (Cloud burst): server có tự thuê GPU không
• Phân tán phi LLM: một yêu cầu ảnh/âm thanh/embedding có được chia qua nhiều máy không

Một số con số đáng chú ý (tính đến 20/09/2026):

• Ollama: 181k sao — chỉ chạy một máy, một mô hình tại một thời điểm
• llama.cpp (llama-server): 129k sao — hỗ trợ RPC layer/row split
• vLLM: 92k sao — tensor/pipeline parallel trên Ray, prefix caching
• LiteLLM (proxy): 59k sao — định tuyến giữa các endpoint, không tự chạy mô hình
• LocalAI: 49k sao — P2P federated, sharding llama.cpp, ảnh cosign
• exo: 47k sao — pipeline + tensor parallel, RDMA qua Thunderbolt 5
• Xinference: 9.6k sao — supervisor/workers, KV chia sẻ giữa các replica vLLM
• GPUStack: 5.7k sao — hỗ trợ 9 nhà cung cấp accelerator
• NVIDIA Dynamo / llm-d: 8.1k / 4.6k sao — yêu cầu Kubernetes và NVIDIA

Từng giải pháp dùng cho việc gì?

Ollama và Open WebUI — mặc định cho một máy

Một binary, gõ ollama pull là có câu trả lời. Đây là lựa chọn đúng đắn cho laptop hoặc một máy để bàn, với thư viện mô hình cùng định dạng Modelfile và, khi kết hợp Open WebUI phía trước, sẽ thành một sản phẩm chat mà người không chuyên cũng dùng được.

Hạn chế: chỉ một máy, một mô hình tại một thời điểm, không có câu chuyện cluster nào ngoài việc Open WebUI xoay vòng nhiều URL Ollama. Nếu đó là nhu cầu của bạn, dừng đọc ở đây là đủ.

llama.cpp và vLLM — những engine mà mọi thứ khác bọc quanh

Cả hai chỉ là bộ điều phối theo nghĩa hẹp vì có thể trải qua nhiều máy. llama.cpp dùng rpc-server trên mỗi máy và cờ --rpc trên server (mặc định chia theo layer, chia theo row cho tensor parallel khi có kết nối nhanh). vLLM dùng Ray cho tensor và pipeline parallelism.

Cả hai đều không quản lý mô hình, người dùng, vị trí triển khai hay bất cứ thứ gì ngoài một mô hình cho mỗi tiến trình. Chúng chính là nền tảng bên dưới LocalAI, GPUStack, Xinference và CoderAI. Nếu chỉ cần một mô hình, chạy thẳng engine là đơn giản nhất.

LiteLLM — router, không phải runtime

LiteLLM đứng trước hàng trăm nhà cung cấp và các endpoint của riêng bạn với key, ngân sách và theo dõi chi tiêu, nhưng không bao giờ tự chạy mô hình. Đây là mảnh ghép bạn đặt trước bất kỳ giải pháp nào khác khi nhiều nhóm cùng chia sẻ. Nhiều người nhầm nó là giải pháp tự lưu trữ — thực tế không phải.

LocalAI — gần nhất với "làm được tất cả"

API tương thích OpenAI cho text, ảnh, video, âm thanh và embedding, mỗi backend là một dịch vụ gRPC trong image OCI riêng, không cần GPU, có Helm chart, và từ tháng 6/2026 là chế độ phân tán thực sự:

• --p2p tạo token chia sẻ, các instance tự khám phá nhau qua libp2p/EdgeVPN
• Yêu cầu được liên hợp đến node ít tải nhất hoặc mô hình llama.cpp được sharding qua các worker
• Router "v3" dựa trên NATS nhận biết VRAM và prefix cache
• Image backend được ký bằng cosign

Điểm chưa làm được: thuê GPU, chia yêu cầu phi LLM qua nhiều máy, huấn luyện. Thông lượng LLM thô chậm hơn engine chuyên dụng vài chục phần trăm vì tính tổng quát phải trả giá. Đây là lựa chọn phổ thông nếu bạn muốn độ phủ rộng cùng cộng đồng lớn.

exo — biến chồng Mac thành một máy tính

Khám phá zero-config, phân vùng ring/pipeline/tensor tỷ lệ theo bộ nhớ mỗi thiết bị, MLX bên dưới, và RDMA qua Thunderbolt 5 trên macOS gần đây cho tensor parallelism thực sự mở rộng (3,2× trên bốn thiết bị theo công bố của họ).

Tuy nhiên, tính đến tháng 9/2026, exo chỉ chạy CPU trên Linux, còn NVIDIA và AMD vẫn "đang phát triển". Nó phục vụ mô hình ngôn ngữ (tạo ảnh nằm sau feature flag). Nếu phần cứng của bạn là Apple Silicon, không gì sánh bằng; nếu không, exo chưa dành cho bạn.

GPUStack và Xinference — console cho doanh nghiệp

Cả hai đều là mô hình supervisor-cộng-workers với console web, được công ty hậu thuẫn, và đều là thứ tôi thấy được triển khai thực tế dưới dạng cluster ở châu Á.

GPUStack thiên về vận hành hơn: người dùng và vai trò, API key có đo lường, Prometheus và Grafana, tự phục hồi mô hình lỗi, log worker Ray trên UI, llama-box (llama.cpp RPC) cùng vLLM/SGLang/TensorRT-LLM với tensor và pipeline parallelism, hỗ trợ chín nhà cung cấp accelerator gồm Ascend, Hygon và MThreads. Worker chỉ chạy Linux.

Xinference bao phủ nhiều loại mô hình hơn (giọng nói, ảnh, rerank) với registry tích hợp, KV chia sẻ giữa các replica vLLM, và bản enterprise có tính năng đa người thuê.

Cả hai đều không tự khám phá node, không burst lên cloud, không chia công việc phi LLM, không huấn luyện. Nếu bạn quản lý GPU của một phòng ban và cần cho ai đó xem dashboard, hãy chọn một trong hai.

NVIDIA Dynamo và llm-d — hạ tầng datacenter

Disaggregated prefill và decode, định tuyến nhận biết KV cache, lưu trữ KV nhiều tầng, trên Kubernetes và NVIDIA. Chúng giải quyết các bài toán bắt đầu từ quy mô rack và là công cụ sai dưới ngưỡng đó. Được đưa vào đây vì "định tuyến nhận biết KV" chính là ý tưởng mà các dự án nhỏ hơn đang vay mượn.

SkyPilot và dstack — burst job, không phải request

Cả hai lập lịch job qua Kubernetes nội bộ và mọi cloud, burst lên cloud khi cluster nội bộ đầy, tìm dung lượng rẻ nhất. Chúng xuất sắc ở việc đó nhưng không phải inference server: bạn mang vLLM đến, chúng đặt chỗ. Nếu bạn cần endpoint tự quyết định từng request chạy nội bộ hay thuê ngoài, không giải pháp nào trong hai là thứ đó.

CoderAI — leo thang và mọi phương thức phân tán

Đây là dự án của chính tác giả, nên hãy đọc với lưu ý đó. Một endpoint tương thích OpenAI cho text, ảnh, video, TTS, STT, diarization, embedding, rerank và OCR, với engine được chọn theo từng mô hình.

Lớp đa máy giống GPUStack (node như engine, llama.cpp RPC với layer hoặc row split, vLLM trên Ray, SGLang đa node) cộng với zero-config kiểu LocalAI (một token chia sẻ, khám phá mDNS, định tuyến prefix cache) và vận hành (Prometheus, đo lường theo key, log node, image ký cosign).

Điểm không ai khác có là leo thang ba tầng: mô hình chạy trên card của bạn, rồi trên máy bạn sở hữu, rồi trên GPU RunPod thuê theo giây với giá trần và ngân sách, chọn theo từng mô hình và có thể chuyển sang chế độ "chỉ khi bận". Ngoài ra còn có phân tán yêu cầu ảnh, video, embedding, giọng nói, phiên âm và OCR qua mọi máy có mô hình, pipeline video chuyển tiếp từng phần, và huấn luyện LoRA/QLoRA song song dữ liệu qua các node từ cùng server.

Điểm còn thiếu: Kubernetes, Apple Silicon, danh mục mô hình, và cộng đồng. Các đường đa máy mới được kiểm thử với giả lập và localhost, chưa qua cáp thật.

Chọn theo tình huống

• Một máy, muốn chạy là xong: Ollama (kèm Open WebUI)
• Một mô hình, thông lượng tối đa, nhiều người dùng: vLLM trực tiếp, LiteLLM phía trước nếu nhiều nhóm chia sẻ
• Chồng Mac: exo. Không gì gần bằng trên Apple Silicon
• Mọi thứ (ảnh, âm thanh, video) trên Linux, cộng đồng lớn, không cloud: LocalAI
• GPU của phòng ban với người dùng, key và dashboard: GPUStack; Xinference nếu cần registry mô hình rộng hơn
• Một rack trên Kubernetes: Dynamo hoặc llm-d, kèm SkyPilot hoặc dstack để burst job
• Vài máy bạn sở hữu cộng card thuê khi thiếu, mọi phương thức, một endpoint: CoderAI. Cũng là giải pháp duy nhất ở đây huấn luyện LoRA qua các máy của bạn

Ghi chú về nguồn dữ liệu

Số sao lấy từ GitHub API ngày 20/09/2026. Các ô tính năng lấy từ README và tài liệu của chính dự án. Ở những chỗ không xác nhận được, bảng ghi rõ thay vì đoán. Petals (commit cuối 2024) và Hugging Face TGI (lưu trữ tháng 3/2026) đã được loại khỏi khảo sát.