Serving là lớp biến một tệp mô hình tĩnh thành một dịch vụ chạy được — nhận yêu cầu, sinh câu trả lời, phục vụ nhiều người. Ba lựa chọn phổ biến: Ollama (dễ nhất, khởi đầu bằng 1 lệnh), vLLM (throughput cao khi nhiều người dùng cùng lúc) và llama.cpp (nhẹ, tốt cho CPU/Apple Silicon). Kết hợp với quantization (GGUF Q4/Q5/Q8) để tiết kiệm bộ nhớ và một API tương thích OpenAI để ứng dụng nội bộ gọi vào. Đây là bài 4/8 trong series tự xây AI nội bộ.
Tóm tắt nhanh
- Serving là gì: phần mềm nạp mô hình và mở một endpoint để nhận yêu cầu — không có nó, mô hình chỉ là tệp nằm trên đĩa.
- Ollama: dễ nhất, cài xong chạy một model bằng đúng một lệnh — hợp cho khởi đầu và bản thử.
- vLLM: tối ưu throughput khi phục vụ đồng thời nhiều người dùng (batching liên tục).
- llama.cpp: nhẹ, chạy tốt trên CPU và Apple Silicon; nền tảng cho định dạng GGUF.
- Quantization: Q4/Q5/Q8 đánh đổi bộ nhớ lấy chất lượng; Q4 thường cân bằng tốt để bắt đầu.
- API tương thích OpenAI: chuẩn hóa endpoint
/v1/chat/completionsđể mọi ứng dụng nội bộ gọi vào như gọi OpenAI.
Chọn công cụ serving: Ollama, vLLM hay llama.cpp?
Không có công cụ "tốt nhất" tuyệt đối — mỗi cái tối ưu cho một tình huống. Bạn chọn theo số người dùng đồng thời, loại phần cứng và mức độ bạn muốn tự cấu hình.
- Ollama — dễ nhất, khởi đầu bằng 1 lệnh. Cài đặt gọn, quản lý model như quản lý image, mở sẵn API cục bộ. Phù hợp khi bạn cần dựng bản thử nhanh, chạy trên một máy cho một nhóm nhỏ. Ollama sử dụng llama.cpp bên dưới nên chạy tốt cả trên Apple Silicon lẫn máy có GPU.
- vLLM — throughput cao cho nhiều người dùng. Thiết kế để phục vụ đồng thời nhiều yêu cầu với batching liên tục và quản lý bộ nhớ hiệu quả, thường chạy trên GPU. Phù hợp khi AI nội bộ đã lên "sản xuất" và nhiều nhân viên dùng cùng lúc.
- llama.cpp — nhẹ, tốt cho CPU/Apple Silicon. Viết bằng C/C++, phụ thuộc tối thiểu, là engine gốc cho định dạng GGUF. Phù hợp khi bạn muốn kiểm soát sâu, chạy trên máy không có GPU rời, hoặc nhúng vào ứng dụng.
| Tiêu chí | Ollama | vLLM | llama.cpp |
|---|---|---|---|
| Độ dễ khởi đầu | Dễ nhất (1 lệnh) | Cần cấu hình hơn | Trung bình (build/CLI) |
| Nhiều người dùng đồng thời | Ổn cho nhóm nhỏ | Mạnh nhất (batching) | Hạn chế hơn |
| Phần cứng hợp nhất | Apple Silicon / GPU | GPU | CPU / Apple Silicon |
| Định dạng model | GGUF (qua llama.cpp) | Chủ yếu trọng số gốc | GGUF |
| Khi nào dùng | Khởi đầu, bản thử | Sản xuất, tải cao | Nhúng, CPU-only |
Cách thực dụng: bắt đầu với Ollama để chứng minh giá trị, rồi khi số người dùng tăng thì cân nhắc chuyển sang vLLM cho throughput. Trên máy Apple Silicon không có GPU rời, llama.cpp (hoặc Ollama chạy nền llama.cpp) là lựa chọn tự nhiên. Xem thêm bài Phần cứng để chọn máy tương ứng.
Quantization — GGUF Q4/Q5/Q8
Quantization là kỹ thuật giảm độ chính xác của trọng số mô hình (ví dụ từ 16-bit xuống 4-bit) để mô hình chiếm ít bộ nhớ hơn và thường chạy nhanh hơn. Định dạng GGUF (dùng bởi llama.cpp và Ollama) đóng gói sẵn các mức lượng tử hóa phổ biến: Q4, Q5, Q8.
- Q4: nén mạnh nhất trong ba mức, tiết kiệm bộ nhớ nhiều nhất — mức phổ biến vì cân bằng tốt giữa dung lượng và chất lượng, thường là điểm khởi đầu hợp lý.
- Q5: nén vừa phải, chất lượng nhích lên so với Q4, đổi lại tốn bộ nhớ hơn một chút.
- Q8: nén nhẹ, giữ chất lượng gần với bản gốc nhất trong ba mức, nhưng tốn bộ nhớ nhiều nhất.
Nguyên tắc chung: quantization càng mạnh → bộ nhớ càng ít, nhưng chất lượng đầu ra có thể giảm dần. Đây là một sự đánh đổi, không phải "miễn phí". Mức độ ảnh hưởng tùy mô hình và tác vụ, nên cách đúng là thử nghiệm trên chính dữ liệu của bạn thay vì tin vào một con số phần trăm cố định. Với đa số doanh nghiệp mới bắt đầu, Q4 là điểm xuất phát an toàn; nếu thấy chất lượng chưa đạt cho tác vụ quan trọng, nâng lên Q5/Q8 hoặc chọn mô hình lớn hơn (xem bài Chọn mô hình).
Context length & concurrency/batching
Hai tham số ảnh hưởng lớn tới bộ nhớ và độ trễ khi phục vụ nhiều người:
- Context length (độ dài ngữ cảnh): số token tối đa mô hình xử lý trong một lượt (prompt + câu trả lời). Ngữ cảnh dài cho phép đưa nhiều tài liệu hơn, nhưng tốn thêm bộ nhớ và có thể làm chậm hơn. Đặt vừa đủ cho tác vụ thay vì bật tối đa "cho chắc".
- Concurrency / batching: để phục vụ nhiều người cùng lúc, engine gộp nhiều yêu cầu và xử lý song song. vLLM nổi bật ở batching liên tục — tăng throughput tổng khi tải cao. Đánh đổi: nhiều yêu cầu đồng thời → cần thêm bộ nhớ, và độ trễ của từng yêu cầu riêng lẻ có thể tăng khi hàng đợi dài.
Nói ngắn gọn: context dài hơn + nhiều người dùng đồng thời hơn = cần nhiều bộ nhớ hơn, và bạn phải cân bằng giữa throughput (tổng lượng phục vụ) và latency (độ trễ mỗi người cảm nhận). Hãy đo trên tải thực tế của bạn để chọn cấu hình phù hợp thay vì phỏng đoán.
API tương thích OpenAI
Điểm mạnh lớn của hệ sinh thái serving hiện nay là hầu hết đều mở một API tương thích OpenAI — cùng dạng endpoint /v1/chat/completions, cùng cấu trúc request/response. Nhờ đó, mọi ứng dụng nội bộ (chat UI, backend, script tự động hóa) có thể gọi vào AI nội bộ y như đang gọi OpenAI, chỉ cần đổi địa chỉ máy chủ (base URL) sang máy on-premise của bạn.
Lợi ích: chuẩn hóa — thư viện, ví dụ mẫu và công cụ sẵn có đều dùng được; và dễ chuyển đổi — nếu sau này đổi engine (Ollama → vLLM) hay đổi model, các ứng dụng gọi vào gần như không phải sửa. Đây cũng là nền để làm bước tiếp theo — RAG — và bước Giao diện & tích hợp.
Xem thêm bài đồng hành: Sơ đồ kiến trúc hệ thống AI nội bộ, Hệ thống bảo mật AI nội bộ và Trending Pool — cập nhật tri thức toàn cầu.
Khởi đầu nhanh nhất — Ollama, chạy một model bằng đúng một lệnh:
# cài Ollama rồi chạy thử một model mã nguồn mở
ollama run qwen2.5:7b # chat ngay trong terminal, 100% offlineKhi cần throughput cao cho nhiều người dùng — vLLM mở một server tương thích OpenAI:
# phục vụ một model qua vLLM (server tương thích OpenAI)
vllm serve <model> # mở endpoint /v1/... trên GPUỨng dụng nội bộ gọi vào endpoint tương thích OpenAI — chỉ đổi base URL sang máy on-premise:
# gọi chat completion vào máy chủ nội bộ (tương thích OpenAI)
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"Xin chào"}]}'Góc nhìn Namtech
Namtech triển khai lớp serving cho AI nội bộ chạy 100% tại chỗ trên Apple Silicon (cụm Mac Mini/Studio, điện năng thấp): khởi đầu với engine đơn giản để chứng minh giá trị, rồi tối ưu quantization, context và batching theo tải thực tế của khách hàng. Chúng tôi luôn chuẩn hóa qua API tương thích OpenAI để ứng dụng nội bộ của bạn không bị khóa vào một engine cụ thể — đổi model hay engine về sau vẫn nhẹ nhàng. Con số tốc độ cụ thể phụ thuộc phần cứng, mô hình và tải, nên chúng tôi đo trực tiếp trên hệ của bạn thay vì hứa những con số chung chung.
Câu hỏi thường gặp
Nên bắt đầu với Ollama hay vLLM?
Hầu hết nên bắt đầu với Ollama vì cài xong chạy một model chỉ bằng một lệnh — nhanh để chứng minh giá trị. Khi số người dùng đồng thời tăng và cần throughput cao trên GPU, cân nhắc chuyển sang vLLM. Cả hai đều mở API tương thích OpenAI nên ứng dụng gọi vào gần như không phải sửa.
Quantization Q4 có làm mô hình kém đi nhiều không?
Quantization là một sự đánh đổi: nén càng mạnh thì tiết kiệm bộ nhớ càng nhiều nhưng chất lượng có thể giảm dần. Q4 phổ biến vì cân bằng tốt và thường là điểm khởi đầu hợp lý. Mức ảnh hưởng tùy mô hình và tác vụ — hãy thử trên chính dữ liệu của bạn; nếu chưa đạt cho tác vụ quan trọng, nâng lên Q5/Q8.
Không có GPU thì chạy AI nội bộ được không?
Được. llama.cpp (và Ollama chạy nền llama.cpp) hoạt động tốt trên CPU và đặc biệt trên Apple Silicon nhờ bộ nhớ hợp nhất. Tốc độ và cỡ model chạy được sẽ tùy phần cứng — xem bài Phần cứng để chọn cấu hình theo số người dùng.
API tương thích OpenAI nghĩa là gì?
Là engine serving mở endpoint có cùng dạng như API của OpenAI (ví dụ /v1/chat/completions). Nhờ đó ứng dụng nội bộ gọi vào AI on-premise y như gọi OpenAI, chỉ cần đổi base URL sang máy chủ của bạn — không phải viết lại tích hợp.
Muốn có AI nội bộ mà không phải bắt đầu từ số 0?
Namtech triển khai nền tảng AI riêng tư nội bộ — mô hình mã nguồn mở chạy 100% trên hạ tầng của bạn, dữ liệu không rời tổ chức.
Đặt lịch tư vấn miễn phíLưu ý: Bài viết mang tính hướng dẫn tổng quan, cập nhật 02/07/2026; công cụ và mô hình thay đổi nhanh — hãy kiểm chứng phiên bản mới nhất khi triển khai.