
Bạn có một chiếc laptop hoặc PC dùng hàng ngày, RAM 16 GB hoặc 32 GB, một ổ NVMe còn trống vài chục GB. Bạn muốn chạy thử một model MoE frontier như GLM-5.2 hay Kimi K3 ngay trên máy đó: dữ liệu ở lại máy mình, không trả phí API, không phụ thuộc mạng. Rồi bạn mở trang model lên và khựng lại: model nặng vài trăm GB, card đồ họa chỉ có vài GB VRAM, có khi không có GPU rời. Cách chạy quen thuộc là nạp toàn bộ model vào VRAM, và với con số đó thì cửa đã đóng ngay từ đầu.
Câu hỏi đáng đặt ra là: nếu mỗi token chỉ kích hoạt một phần nhỏ của model MoE, vì sao phải giữ toàn bộ model trong VRAM? Colibri trả lời đúng câu hỏi đó: chỉ giữ phần đang dùng trong RAM hoặc VRAM, còn lại stream từ ổ đĩa khi cần. Nhờ vậy, model hàng trăm tỉ tham số vẫn chạy được trên máy bạn đã có, với điều kiện bạn chấp nhận tốc độ chậm hơn nhiều so với chạy resident trên GPU chuyên dụng.
Lưu ý: mình chưa tự cài đặt hay đo Colibri; mọi số tốc độ trong bài đều là số đo của dự án, không phải benchmark của blog.
Colibri là gì và giải quyết vấn đề gì?
Colibri là một inference engine thuần C, chạy model MoE mở rất lớn trên máy người dùng đã có, không bắt buộc GPU. Triết lý của dự án gói trong khẩu hiệu “tiny engine, immense model”. Tính đến ngày kiểm tra 2026-11-03, repo JustVugg/colibri dùng giấy phép Apache-2.0, phiên bản v2.1.0 (2026-10-31), khoảng 46.968 sao, vẫn đang được duy trì tích cực.
Vấn đề nằm ở bản chất của kiến trúc MoE. Model dense dùng gần như toàn bộ tham số cho mỗi token, nên bộ nhớ cần có xấp xỉ bằng kích thước model. Model MoE thì khác: mỗi token chỉ đi qua một tập expert nhỏ ở mỗi layer, nên lượng tham số thực sự tham gia vào một token nhỏ hơn rất nhiều so với tổng số tham số. Colibri biến bài toán “không đủ VRAM” thành bài toán “có đủ ổ đĩa nhanh và đủ RAM làm cache hay không”.
Phù hợp: sysadmin, DevOps/SRE, dev backend/full-stack, homelab self-hoster, người dùng coding-agent muốn chạy LLM offline mà không thuê GPU datacenter. Không phù hợp: người cần tốc độ cao cho production, phục vụ nhiều người cùng lúc, hoặc máy chỉ có HDD/SSD chậm và ít dung lượng trống.
Kiến trúc Colibri: cơ chế stream expert MoE từ NVMe
flowchart LR
A["Prompt / token vào"] --> B["Router từng layer:\nchọn expert cho token đó"]
B --> C{"Expert đã ở\ntầng nào?"}
C --> D["VRAM — hot set:\nexpert nóng, ghim sẵn"]
C --> E["RAM — warm cache:\nLRU theo từng layer"]
C --> F["NVMe — cold store:\ntoàn bộ model"]
F -. "cache miss: nạp lên RAM / VRAM" .-> E
E -. "expert dùng nhiều" .-> D
D --> G["Tính toán layer\nvà sinh token ra"]
E --> G
F --> G
B -. "Prefetch: nạp trước expert\nlayer tiếp theo" .-> F
G --> H["Learn: cập nhật\n.coli_usage và hot set"]
H -.-> D
Mỗi token đi qua từng layer, router chọn expert, hệ thống lấy expert từ tầng nhanh nhất đang có và nạp trước expert của layer tiếp theo. Ba tầng: VRAM (hot set ghim sẵn), RAM (cache LRU theo layer), NVMe (toàn bộ model, một pread cho ba ma trận mỗi expert).
Điểm quan trọng nhất: vị trí lưu trú chỉ quyết định tốc độ, không quyết định router chọn expert nào hay độ chính xác của trọng số. Cache miss làm chậm, không làm sai kết quả. Vì vậy, bạn có thể đo và cải thiện Colibri như một hệ cache — tỉ lệ hit theo layer, độ ấm của hot set — thay vì coi nó như một bài toán mua GPU.
Luồng xử lý mỗi token: route (chọn expert), union (hợp nhất nhu cầu), place (đặt expert vào tầng phù hợp), overlap (nạp expert chồng lấn với tính toán), learn (học từ hội thoại, ghi vào .coli_usage, ghim hot set cho lần sau).
Về thành phần, engine thuần C, một file cho mỗi họ model, hỗ trợ backend CPU, Vulkan và CUDA, cùng file GGUF cho các model ngôn ngữ. DIRECT=1 thường giúp nhiều trên NVMe nhanh nhưng có thể tệ hơn trên ổ khác, nên phải đo trên chính ổ của mình; COLI_MODEL_MIRROR cho phép dùng thêm một ổ thứ hai.
Giới hạn: lần chạy lạnh chậm hơn hẳn lần chạy ấm; mỗi model tốn hàng chục GB đĩa; Qwen-Image-2.1 chỉ dùng phi thương mại.
Model nào chạy được trên máy nào?
Phạm vi đã xác minh: GLM-5.2/5.3, Kimi K3, DeepSeek V4 Flash/V4.1 Flash, Qwen3.6, Qwen3-Coder, OLMoE, Qwen-Image-2.1, Laya, GLiNER2.5-Decide. Yêu cầu tối thiểu: RAM 8 GB (16 GB trở lên thoải mái hơn), trống 22 GB cho model nhỏ nhất, cần Internet lúc tải. GPU tùy chọn.
| Model | ID | Tải về | RAM chạy được / thoải mái |
|---|---|---|---|
| Qwen3.6-35B-A3B | qwen36-35b | 23 GB | 10 GB / 20 GB |
| Qwen3-Coder-30B-A3B | qwen3-coder-30b | 19 GB | 8 GB / 18 GB |
| Qwen-Image-2.1 | — | 33 GB | 12 GB / 18 GB, phi thương mại |
Cách đọc: cột RAM thấp là mức chạy được, cột cao là mức chạy thoải mái. Với GLM-5.2 744B, dung lượng tải về lớn hơn nhiều, nhưng nguyên lý không đổi. Thay vì đoán, chạy ./start-here.sh --list để xem model phù hợp với máy của mình.
Hướng dẫn cài đặt Colibri và chạy model MoE local
Phiên bản kiểm chứng: Colibri v2.1.0 (2026-10-31), kiểm tra ngày 2026-11-03. Trước khi cài, kiểm tra RAM, dung lượng NVMe trống và Internet.
Cài đặt trên Linux
Các lệnh dưới đây được đối chiếu với tài liệu chính thức của dự án:
sudo apt install git python3 build-essential
git clone https://github.com/JustVugg/colibri
cd colibri
./start-here.sh
Luồng setup: kiểm tra máy, gợi ý model phù hợp, build engine nếu có compiler (nếu không thì tải bản prebuilt), tải model có tiến trình và khả năng resume, rồi khởi động Colibri và mở dashboard. Các tùy chọn hữu ích: --list, --model ID, --dir DIR, --backend vulkan|cuda|cpu, --no-gpu, --reconfigure.
Cài đặt trên macOS và Windows
Trên macOS: cài Xcode command line tools và các gói cần thiết qua Homebrew, rồi clone repo và chạy ./start-here.sh. Trên Windows: tải file ZIP từ trang repo và chạy START-HERE.bat (đề nghị cài Python nếu thiếu). Lưu ý cho WSL: tránh đặt model trên /mnt/c vì hiệu năng đọc đĩa qua đường đó kém.
xcode-select --install
brew install libomp git python
Xác minh cài đặt thành công
Sau khi setup chạy xong, kiểm tra bằng c/coli status, dừng bằng c/coli stop (Windows: c\coli.cmd status/stop). Kết quả mong đợi: dashboard tại http://127.0.0.1:8000/, OpenAI base URL tại http://127.0.0.1:8000/v1, Anthropic base URL tại http://127.0.0.1:8000. Chạy thử bằng ./coli chat. Ví dụ của dự án: GLM-5.2 744B MoE int4 streaming trên CPU “ready in 32s, resident 9.9 GB” — đây là ví dụ của dự án, không phải kết quả tự đo của blog.
Từ đây, bạn trỏ coding-agent hoặc ứng dụng tương thích OpenAI về base URL trên để dùng model local cho việc viết code, rà soát hay tóm tắt. Nếu bạn đã tự host một lớp gateway, Colibri là engine suy luận phía sau gateway đó. Đọc thêm góc gateway: tự host New API làm AI gateway.
Đánh giá kỹ thuật: ưu điểm, nhược điểm, bảo mật và hiệu năng
Ưu điểm rõ nhất là chạy model MoE hàng trăm tỉ tham số trên máy sẵn có, không cần GPU datacenter, không phí API, dữ liệu ở lại máy. Cài đặt một bước bằng start-here.sh, có resume khi tải dở. API tương thích OpenAI và Anthropic trên localhost nên gắn được ngay với công cụ sẵn có. Mã nguồn mở Apache-2.0, hỗ trợ GGUF, CPU/Vulkan/CUDA.
Nhược điểm cũng phải kể đủ. Tốc độ thấp hơn nhiều so với chạy model resident trên GPU chuyên dụng, và trải nghiệm phụ thuộc mạnh vào ổ đĩa cùng trạng thái cache. Mỗi model tải về tốn hàng chục GB đĩa. Dự án còn trẻ và phát triển nhanh — v2.1.0 mới ra cuối tháng 10/2026 — nên tên model và tùy chọn có thể đổi theo bản mới; kiểm tra lại tài liệu hiện tại.
Về hiệu năng thực tế, toàn bộ số liệu dưới đây là số đo của dự án trên phần cứng của dự án. Với GLM-5.2, decode đạt 5.8–6.8 tok/s trên 6x RTX 5090, 1.83 tok/s ở trạng thái ấm trên CPU-only 128 GB, 1.07 tok/s trên laptop RTX 5070 Ti, và sàn lạnh chỉ 0.05–0.1 tok/s. Với Qwen3.6-35B-A3B: 6.0 tok/s trên CPU, 9.9 tok/s trên Vulkan iGPU và 30.0 tok/s trên CUDA. Đừng dùng các số này để suy ra tốc độ trên máy của bạn.
Theo mình, thứ tự nâng cấp mới là insight quan trọng nhất. Với MoE streaming, VRAM/RAM thực tế chỉ còn bằng active experts mỗi token cộng KV cache; tổng số tham số trở thành bài toán dung lượng và băng thông đọc ngẫu nhiên của NVMe. Vì vậy, hãy ưu tiên NVMe nhanh hơn, đo thực tế DIRECT=1, rồi RAM làm cache lớn hơn, trước khi nghĩ tới CPU hay GPU đắt hơn. Decode disk-bound thì thêm nhân CPU không giải quyết thời gian chờ pread, và routing phân tán mạnh sẽ gây cache thrash, kéo tốc độ về gần sàn lạnh.
Về bảo mật và riêng tư, lợi ích thật là model và prompt chạy local, không gửi lên API bên ngoài khi bạn dùng đúng endpoint localhost. Nhưng các địa chỉ mặc định bind 127.0.0.1, và tài liệu không mô tả cơ chế xác thực cho endpoint local. Vì vậy, tuyệt đối không expose cổng 8000 ra LAN hay Internet; nếu cần truy cập từ xa, phải đặt endpoint sau reverse proxy có xác thực, không mở cổng trần.
So sánh với llama.cpp, Ollama và inference server GPU
Tiêu chí: phần cứng, xử lý MoE lớn, tốc độ, độ dễ cài đặt, API, trường hợp dùng. So sánh ở mức nguyên lý, không bịa benchmark đối đầu.
- Colibri: stream expert MoE theo tầng VRAM/RAM/NVMe, kèm prefetch và hot set học được; chọn khi cần “chạy được model MoE rất lớn trên máy sẵn có”, GPU tùy chọn.
- llama.cpp / Ollama: suy luận tổng quát với GGUF, hệ sinh thái rộng, đơn giản; chọn khi cần hệ sinh thái GGUF tổng quát.
- vLLM / SGLang: throughput và phục vụ đồng thời trên GPU chuyên dụng; chọn khi cần throughput và đồng thời cho production GPU.
Chọn Colibri khi cần chạy model MoE rất lớn trên máy sẵn có; chọn Ollama/llama.cpp cho hệ sinh thái GGUF đơn giản; chọn server GPU cho throughput và đồng thời.
Colibri dùng thực tế cho những việc gì?
Với homelab, Colibri cho bạn một phòng lab AI riêng tư tại nhà: chạy trợ lý local, thử model lớn mà không trả API, đặt model trên NVMe và tách thư mục model bằng --dir. Với coding-agent, bạn trỏ công cụ sẵn có về http://127.0.0.1:8000/v1 để dùng model local cho việc viết code, rà soát và tóm tắt. Với doanh nghiệp, Colibri là cách kiểm chứng model MoE trên máy sẵn có trước khi mua GPU hay thuê cloud.
Lỗi thường gặp, sao lưu và rollback
Tải gián đoạn: chạy lại setup để resume, không xóa thư mục model giữa chừng. Thiếu gói GPU: cài đủ gói theo lệnh tài liệu in ra, rồi chạy lại setup. Hết đĩa: dùng --dir/--model-dir sang ổ còn trống, ưu tiên NVMe. Chạy chậm: kiểm tra loại ổ đĩa trước tiên, thử DIRECT=1, đo lại, xác định trạng thái lạnh hay ấm.
Rollback: dừng bằng c/coli stop, xóa thư mục model trong ~/colibri-models hoặc --dir đã chọn; không cần gỡ engine. Trên ổ chậm, đường lui là quay lại API cloud hoặc model nhỏ hơn như Qwen3-Coder-30B-A3B.
Kết luận: ai phù hợp, ai không, và bước tiếp theo
Phù hợp: người có NVMe trống hàng chục GB, chấp nhận tốc độ streaming để đổi lấy riêng tư và không phí API. Không phù hợp: người cần trả lời nhanh cho production, phục vụ nhiều người dùng, chỉ có HDD/SSD chậm, hoặc không muốn tải hàng chục GB.
Bước tiếp theo ít rủi ro nhất: chạy ./start-here.sh --list, chọn model nhỏ nhất phù hợp (ví dụ Qwen3-Coder-30B-A3B), đo tốc độ ấm sau vài hội thoại rồi mới quyết định tải model lớn hơn.
Bài học rút ra
- Kích thước model không còn là rào cản tuyệt đối: với MoE, câu hỏi đúng là expert nào đang nóng.
- Ổ đĩa là tài nguyên hiệu năng chính: NVMe nhanh và
DIRECT=1đo thực tế đáng giá hơn nâng CPU mù quáng. - Lần chạy đầu không đại diện cho tốc độ ổn định: tốc độ ấm khác hẳn tốc độ lạnh.
- Tương thích API là giá trị vận hành: endpoint localhost giúp gắn Colibri vào công cụ sẵn có.
- Đừng expose endpoint local khi chưa có lớp xác thực phía trước.
Phạm vi kiểm chứng
Ngày kiểm tra: 2026-11-03. Nguồn chính: README và GitHub API của JustVugg/colibri, tài liệu tại justvugg.github.io/colibri, phiên bản v2.1.0 phát hành 2026-10-31. Đã xác minh: yêu cầu tối thiểu, lệnh cài đặt, endpoint, tùy chọn CLI, danh sách model và bảng RAM/dung lượng. Mặc định: GPU là tùy chọn, setup tự kiểm tra máy và gợi ý model; DIRECT=1 và COLI_MODEL_MIRROR là tùy chọn theo ổ đĩa; GGUF là đường chạy bổ sung cho model ngôn ngữ. Các con số tốc độ là số đo của dự án, không phải benchmark của blog. Bài viết chưa tự cài đặt, chạy hay đo hiệu năng Colibri. Chưa kiểm chứng: số sao lúc xuất bản, giao diện tiếng Việt, tốc độ trên máy của người đọc.
Tài liệu tham khảo
- Colibri trên GitHub: https://github.com/JustVugg/colibri
- Tài liệu Colibri: https://justvugg.github.io/colibri
Bình luận
Bình luận được duyệt trước khi hiển thị.Đang tải bình luận…
Để lại bình luận