Triển khai Kimi K3 open-weight trên máy của bạn: ngưỡng tính toán, chọn quantization và các phương án thay thế

Kimi K3 ra mắt 16/7/2026 và công bố weights đầy đủ 27/7 — mô hình open-weight lớn nhất từng phát hành: 2.8 nghìn tỷ tham số tổng trong kiến trúc mixture-of-experts, kích hoạt khoảng 104 tỷ mỗi lượt tính toán. Open-weight nghĩa là bạn có thể chạy hoàn toàn offline — nhưng hãy đặt kỳ vọng đúng: đây là mô hình hạng nặng, và tự triển khai là một dự án tính toán thực thụ, không phải thứ bạn có thể chạy thoải mái trên một GPU tiêu dùng.

Ước tính VRAM trước khi tải

Bước đầu không phải tải mà là tính toán. VRAM có ba thành phần:

VRAM tổng ≈ weights + KV cache + runtime overhead

Số hạng weights = số tham số × byte trên mỗi tham số. Cấp quantization quyết định byte trên mỗi tham số:

Đây là phép đổi công thức công khai áp trực tiếp cho 2.8T; kích thước file thực phụ thuộc implementation GGUF và cách đóng gói, hãy theo trang tải. Kết luận rất thẳng: dù ở Q4, số hạng weights vẫn ở mức TB; GPU đơn 24GB / 48GB không chứa nổi — cần server nhiều GPU, máy unified-memory cấp TB, hoặc đi thẳng lên cloud.

Số hạng KV cache tỉ lệ với độ dài ngữ cảnh và batch size. Ngữ cảnh 1 triệu token của K3 là điểm mạnh, nhưng KV cache của ngữ cảnh dài cũng tiêu tốn tương ứng — hãy chừa nhiều dung lượng.

Số hạng overhead gồm inference framework, activation, buffer tạm; thường ước 10–20% của số hạng weights.

Đặc thù MoE ảnh hưởng triển khai

Kiến trúc MoE của K3 có một hệ quả quan trọng mà nhiều người tính sai:

Toàn bộ 2.8T tham số phải thường trú trong VRAM; 104B kích hoạt chỉ ảnh hưởng tốc độ tính toán, không ảnh hưởng bộ nhớ. MoE tiết kiệm compute bằng cách đưa mỗi token qua một tập con chuyên gia, nhưng weights của mọi chuyên gia phải sẵn sàng trong bộ nhớ — bạn không biết token tiếp theo sẽ route tới chuyên gia nào. Vì vậy tính bộ nhớ theo 2.8T, không phải 104B.

Thứ MoE tiết kiệm thật sự là compute trên mỗi token (104B kích hoạt tương đương chi phí của mô hình dense 104B), nghĩa là trên máy có đủ bộ nhớ, tốc độ inference nhanh hơn nhiều so với mô hình dense cùng kích thước. Kỳ vọng đúng là: đây là mô hình dành cho máy bộ nhớ cấp TB, nhưng một khi chạy được thì không hề chậm.

Chọn cấp quantization

Quantization đánh đổi bộ nhớ lấy chất lượng, với quy luật chung:

• Q8: mất chất lượng ít nhất, tốn bộ nhớ nhất. Chọn khi bộ nhớ dư.
• Q4: cấp đáng giá nhất, mất chất lượng trong tầm kiểm soát, giảm một nửa bộ nhớ. Mặc định cho đa số self-hosting.
• Q2 và thấp hơn: tiết kiệm thêm một nấc nhưng mất chất lượng rõ rệt; chỉ phù hợp cho thử nghiệm hoặc tác vụ không yêu cầu chất lượng cao.

K3 ở mức 2.8T, dù Q4 vẫn cấp TB — ở quy mô này lợi ích "ép thêm một nấc để tiết kiệm vài trăm GB" là có thật, nhưng cái giá chất lượng của Q2 cũng có thật. Trước khi chọn, replay một lượt bộ prompt nghiệp vụ thật ở từng cấp rồi quyết định bằng kết quả, không bằng cảm giác.

Bốn lộ trình khi thiếu tài nguyên tính toán

Nói thẳng: số team self-host được mô hình 2.8T là rất ít. Khi phần cứng không đủ:

Lộ trình một — cloud API (kimi-k3 trên EXAIV). Không quản GPU, tính theo token, cùng dòng mô hình với bản open. Phù hợp đa số team: chứng minh mô hình khớp workload trên cloud trước, rồi mới đánh giá có nên tự xây không.

Lộ trình hai — mô hình họ Kimi nhỏ hơn. Tổ chức moonshotai có nhiều open-weight nhẹ hơn, ví dụ Kimi-Linear-48B-A3B (MoE linear-attention) ở 48B tham số tổng: máy hai GPU 48GB hoặc unified-memory cấu hình cao chạy được. Năng lực không bằng K3 flagship nhưng ngưỡng triển khai thấp hơn một bậc.

Lộ trình ba — thuê GPU. Node nhiều GPU trên cloud tính theo giờ hợp lý cho batch job và phân tích lớn chạy một lần; chỉ tải nặng liên tục mới đáng mua card.

Lộ trình bốn — CPU inference stream từ đĩa (kimi-k3-in-c). Dự án cộng đồng kimi-k3-in-c dùng engine C99 176KB stream checkpoint 1.56TB từ đĩa, laptop 8GB chạy được — cái giá là chờ khoảng 26 giây mỗi token. Không phải trải nghiệm chat, nhưng biến việc "không có RAM lớn vẫn chạm được mô hình 2.8T" thành hiện thực. Nhiều RAM hơn thì nhanh hơn (128GB+ còn 5.6 giây/token), và câu trả lời byte-identical ở mọi mức ngân sách.

Nếu quyết định self-host

Khi phần cứng sẵn sàng, quy trình giống các mô hình mở khác: tải weights (hoặc GGUF cộng đồng) → chọn inference framework (llama.cpp / Ollama / vLLM theo hệ sinh thái) → cấu hình cấp quantization và độ dài ngữ cảnh → chạy smoke test → replay prompt nghiệp vụ thật.

Sau khi triển khai, hiệu chuẩn ba việc: nvidia-smi so bộ nhớ thực với ước tính; chạy một lượt tải đầy ở độ dài ngữ cảnh tối đa để xác nhận chừa đủ KV cache; ghi tốc độ token first-token và trạng thái ổn định làm baseline cho lần mở rộng sau.

FAQ

Bài viết này trả lời những gì

• tự host K3 cần bao nhiêu VRAM
• chọn quantization cho triển khai cục bộ thế nào
• làm gì khi thiếu hardware

Sơ đồ tình huống nhanh

Nhìn về phía trước

Catalog và trọng số tiếp tục thay đổi; các quy ước tích hợp và gọi ở đây theo tài liệu chính thức tại thời điểm xuất bản.

Nguồn và xác minh

Các sự kiện chính trong bài viết này lấy từ trọng số mở Kimi K3 (moonshotai) và công thức ước tính VRAM công khai và được xác minh vào 2026-11-09. Model ID, giá và khả dụng theo catalog trực tiếp của nền tảng — cố tình không ghi số cố định dễ lỗi thời. Code mẫu theo hợp đồng API tại thời điểm xuất bản; kiểm tra tài liệu chính thức trước khi đưa vào production.

Phạm vi và đối tượng

Đối tượng: team đánh giá tự host K3. Phạm vi: phần cứng và quantization cho triển khai cục bộ. Không bao gồm: tích hợp cloud API hoặc fine-tuning.

Ghi chú biên tập và chính tả

Viết bởi đội nội dung EXAIV từ các sự kiện kiểm chứng được, kiểm tra nguồn và code trước khi xuất bản. Nếu có nội dung lỗi thời hoặc sai, trang phát hành chính thức và catalog trực tiếp là chuẩn — hãy báo qua kênh phản hồi của trang để chúng tôi cập nhật.

Đọc tiếp

• kimi-k3-in-c: 2.8T trên laptop 8GB
• Sổ tay triển khai local
• Công thức tính VRAM
• So sánh GGUF quantizer
• Mô hình chi phí tính toán local