Moonshot AI đã phát hành trọng số mã nguồn mở (open weights) cho Kimi K3 vào ngày 27 tháng 7, và số lượt tải xuống trên Hugging Face đã gần đạt 100.000. Điều đáng chú ý là: một mô hình với 2.8 nghìn tỷ tham số đã đánh bại Claude Opus 4.8 trên mọi tiêu chuẩn mà Moonshot công bố, và giờ đây bạn có thể tự lưu trữ nó.
Nhược điểm cũng trở nên rõ ràng khi bạn xem xét các con số. Suy luận độ chính xác đầy đủ cần 1.57 TB dung lượng đĩa. Ngay cả trọng số MXFP4 được phát hành cũng có kích thước tải xuống là 594 GB. Đây là một mô hình bạn có thể sở hữu, nhưng ở quy mô này, "cục bộ" mang ý nghĩa khác so với một mô hình Llama 8B.
Hướng dẫn này sẽ trình bày những gì cần thiết để chạy K3 trên phần cứng của riêng bạn, những gì cộng đồng đã thực hiện được trên các máy tính cá nhân, và cách kết nối một điểm cuối (endpoint) K3 tự lưu trữ vào quy trình làm việc API của bạn với Apidog sau khi nó hoạt động.
Những gì bạn đang tải xuống
Đầu tiên, về cấu trúc của nó. Nếu bạn muốn tìm hiểu toàn bộ thông tin cơ bản, hãy bắt đầu với Kimi K3 là gì?; phiên bản tóm tắt:
- Tổng cộng 2.8 nghìn tỷ tham số, 104 tỷ được kích hoạt mỗi token. K3 là một mô hình Mixture-of-Experts (MoE) với 896 chuyên gia. Mỗi token được định tuyến qua 16 chuyên gia được chọn cộng với 2 chuyên gia chia sẻ, do đó, lượng tính toán trên mỗi token chỉ là một phần nhỏ so với con số tổng.
- 93 lớp: 69 lớp Kimi Delta Attention (KDA) và 24 lớp Gated MLA. Thiết kế KDA là lý do tại sao cửa sổ ngữ cảnh 1 triệu token có thể sử dụng được.
- Khả năng thị giác tự nhiên (Native vision) thông qua bộ mã hóa MoonViT-V2 có 401 triệu tham số. Các trọng số được phát hành xử lý đầu vào văn bản, hình ảnh và video.
- Trọng số MXFP4, kích hoạt MXFP8. Moonshot đã thực hiện huấn luyện nhận biết lượng tử hóa (quantization-aware training), vì vậy phiên bản 4-bit là định dạng phục vụ dự kiến, không phải là một suy nghĩ bổ sung. Điều này cũng có nghĩa là các trọng số nén kém hơn nhiều; khoảng trống bit thấp đã được sử dụng hết.
- Chỉ suy nghĩ (Thinking-only). K3 luôn suy luận trước khi trả lời, với các mức độ nỗ lực thấp, cao và tối đa. Không có chế độ tức thì.
Các trọng số được bảo vệ bởi Giấy phép Kimi K3 trên kho lưu trữ Hugging Face. Chấp nhận giấy phép, sau đó tải về bằng huggingface-cli. Với kết nối 1 Gbps, hãy dự trù khoảng 80 đến 90 phút để tải xuống 594 GB.
Tùy chọn 1: Triển khai cấp trung tâm dữ liệu với vLLM hoặc SGLang
Moonshot đề xuất ba engine: vLLM, SGLang và TokenSpeed. Đóng góp prefill-cache KDA của họ đã được tích hợp trong vLLM cùng với các trọng số, vì vậy vLLM là lựa chọn dễ dàng nhất:
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--max-model-len 131072
Lưu ý từ thực tế:
- Phần cứng. Moonshot đã đánh giá trên các cụm H20. Thực tế, bạn cần một nút 8 GPU với song song tensor (tensor parallelism) làm mức tối thiểu. Trên phần cứng loại B200, thông lượng trên 100 token/giây có thể đạt được.
- Ngữ cảnh. Mô hình hỗ trợ tới 1.048.576 token, nhưng bộ nhớ cache KV ở ngữ cảnh đầy đủ đã chiếm khoảng 27 GB. Hãy bắt đầu với 131K và chỉ tăng lên nếu khối lượng công việc của bạn yêu cầu.
- Lấy mẫu (Sampling). Các cài đặt mặc định của Moonshot là nhiệt độ 1.0 và top-p 0.95. Đối với các khối lượng công việc tác nhân (agentic workloads), hãy giữ nhiệt độ ở 1.0 và di chuyển top-p về 1.0.
Đây là "cục bộ" theo nghĩa chủ quyền dữ liệu: cơ sở hạ tầng của bạn, nhật ký của bạn, câu chuyện tuân thủ của bạn. Nó không phải là cục bộ theo nghĩa máy tính xách tay, và không có mức độ lượng tử hóa nào có thể thay đổi điều đó cho việc sử dụng tương tác.
Tùy chọn 2: Lượng tử hóa GGUF trên một máy trạm lớn
Unsloth đã xuất bản các chuyển đổi GGUF cho người dùng llama.cpp, và các lượng tử hóa động của họ là cách duy nhất thực tế để thu nhỏ K3 dưới phiên bản phát hành chính thức:
| Lượng tử hóa | Kích thước | Ý nghĩa |
|---|---|---|
| UD-IQ1_M | ~345 GB | Mức tối thiểu. Lượng tử hóa động 1-bit mạnh mẽ. |
| UD-IQ1_S | ~650 GB | Điểm cân bằng được Unsloth khuyến nghị. |
| UD-Q4_K_XL | ~1.55 TB | Gần với độ chính xác đầy đủ. |
| UD-Q8_K_XL | ~1.6 TB | Thực tế là không mất dữ liệu. |
Nguyên tắc hoạt động: RAM cộng với VRAM của bạn nên xấp xỉ bằng kích thước lượng tử hóa. Nếu thiếu, llama.cpp vẫn sẽ chạy thông qua offloading, nhưng mỗi gigabyte thiếu hụt sẽ làm giảm tốc độ của bạn. Một chiếc Mac Studio nối với máy 128 GB, hoặc một DGX Station, nằm ở mức thấp nhất trong thực tế.
Một lệnh llama.cpp tối thiểu, bao gồm cả trình chiếu thị giác (vision projector):
./llama.cpp/llama-cli \
--model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
--mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
--temp 1.0 \
--top-p 0.95
Nếu phần cứng của bạn không đạt được mức này, đừng cố ép. Danh sách các LLM cục bộ tốt nhất năm 2026 có các mô hình mã nguồn mở phù hợp với 24 đến 128 GB và trả lời trong thời gian thực; K3 ở 1-bit trên RAM không đủ sẽ không hoạt động như vậy.
Thử nghiệm M1 Max: có, nhưng 16 giây mỗi token
Một chủ đề trên Hacker News tuần này đã ghi nhận K3 chạy trên M1 Max 64 GB bằng cách truyền tải trọng số từ ổ SSD 2 TB thay vì giữ chúng trong bộ nhớ. Các con số giải thích cả lý do tại sao nó hoạt động và tại sao bạn sẽ không sử dụng nó:
- K3 mang khoảng 115 GB tham số dày đặc mà mỗi token chạm vào, cộng thêm khoảng 25 GB trọng số chuyên gia được định tuyến mỗi token. Riêng phần dày đặc đã vượt quá RAM của máy, do đó SSD trở thành bộ nhớ chuyển động chậm.
- Kết quả: khoảng 16 giây mỗi token. Một số cấu hình báo cáo hơn một phút mỗi token. Đó là một đoạn văn mỗi giờ.
- Thông lượng đĩa là yếu tố then chốt. SSD thế hệ M1 đọc chậm hơn nhiều so với chip Apple hiện tại, và việc truyền tải các chuyên gia qua mạng còn chậm hơn nữa.
Là một bằng chứng cho thấy sự phân tán MoE cộng với mmap có thể chạy một mô hình 2.8 nghìn tỷ trên máy tính xách tay, đó là một kết quả thực sự thú vị. Nhưng để sử dụng K3, nó không phải là một cách khả thi. Nếu bạn muốn câu trả lời từ K3 trên MacBook, các gói miễn phí hoặc API được lưu trữ sẽ phục vụ bạn tốt hơn.
Kết nối K3 cục bộ của bạn vào quy trình làm việc API
Cho dù bạn triển khai thông qua vLLM hay chế độ máy chủ của llama.cpp, bạn đều nhận được kết quả tương tự: một điểm cuối HTTP tương thích OpenAI trên localhost. Từ đây, nó giống như bất kỳ API nào khác, và quy trình làm việc tương tự mà chúng tôi sử dụng để kiểm tra các LLM cục bộ dưới dạng API vẫn được áp dụng:
- Trỏ Apidog đến điểm cuối. Tạo một môi trường với
base_urlđược đặt thànhhttp://localhost:8000/v1(mặc định của vLLM) và sau này thay thế nó bằng điểm cuối được lưu trữ của Moonshot. Các yêu cầu tương tự, hai backend, một biến. - Kiểm tra luồng suy nghĩ. K3 chỉ suy nghĩ, vì vậy các phản hồi mang nội dung lý luận trước câu trả lời. Chế độ xem gỡ lỗi SSE của Apidog hiển thị luồng khi nó đến, giúp dễ dàng hơn nhiều để xem các mức độ nỗ lực lý luận thay đổi như thế nào.
- Xác nhận cấu trúc, không phải cảm tính. Thêm các thử nghiệm tự động xác thực lược đồ phản hồi, ngân sách độ trễ và các trường sử dụng token, để việc thay đổi lượng tử hóa hoặc nâng cấp engine làm giảm chất lượng đầu ra sẽ hiển thị trong một thử nghiệm thất bại thay vì báo cáo của người dùng.
- Giả lập K3 trong khi GPU bận. Một mô hình 594 GB mất khá nhiều thời gian để tải. Ghi lại các phản hồi thực một lần, sau đó để một máy chủ giả lập trả về chúng để công việc giao diện người dùng không bao giờ phải chờ hộp suy luận. Tải xuống Apidog để thiết lập miễn phí; công cụ giả lập và kiểm thử đều hoạt động với bất kỳ máy chủ tương thích OpenAI nào.
Bản thân định dạng yêu cầu khớp với những gì chúng tôi đã đề cập trong hướng dẫn API Kimi K3, vì vậy các thử nghiệm được viết cho API được lưu trữ sẽ chuyển trực tiếp sang triển khai cục bộ của bạn.
Vậy bạn có nên chạy nó cục bộ không?
Một bảng quyết định nhanh:
| Tình huống của bạn | Đề xuất |
|---|---|
| Nút có 8+ GPU, cần chủ quyền dữ liệu hoặc tuân thủ | Có. vLLM với song song tensor, trọng số MXFP4. |
| Máy trạm với 350 GB+ RAM/VRAM | Có thể hoạt động. GGUF 1-bit của Unsloth, kỳ vọng vừa phải. |
| Mac hoặc PC 64 đến 128 GB | Không. Bạn sẽ nhận được giây/token, chứ không phải token/giây. |
| Chỉ muốn K3 trong sản phẩm của bạn | Sử dụng API được lưu trữ; nó tương thích với OpenAI và Anthropic. |
Tóm tắt thành thật: trọng số mã nguồn mở của K3 quan trọng vì bạn có thể kiểm tra, tinh chỉnh và tự lưu trữ một mô hình đẳng cấp tiên tiến, chứ không phải vì hầu hết mọi người nên làm vậy. Đối với các nhóm có phần cứng phù hợp, con đường vLLM hoạt động tốt và hiệu quả ngày nay. Đối với những người khác, việc phát hành mã nguồn mở vẫn mang lại lợi ích gián tiếp, thông qua việc truy cập được lưu trữ rẻ hơn và các nhà cung cấp bên thứ ba cạnh tranh để phục vụ nó.
Dù bạn thuộc nhóm nào trong bảng đó, điểm cuối (endpoint) là nơi mô hình gặp gỡ mã của bạn. Hãy kiểm tra nó như một thực thể: kiểm tra lược đồ, kiểm tra luồng và giả lập để giữ cho quá trình phát triển tiếp diễn trong khi mô hình đang suy nghĩ.
