Cách chạy Kimi K3 cục bộ và khi nào không nên

Moonshot AI đã phát hành trọng số mở (open weights) cho Kimi K3 vào ngày 27 tháng 7, và số lượt tải trên Hugging Face đã gần đạt 100.000. Đáng chú ý, đây là mô hình 2,8 nghìn tỷ tham số đã vượt Claude Opus 4.8 trên mọi benchmark do Moonshot công bố, đồng thời bạn có thể tự lưu trữ nó.

Dùng thử Apidog ngay hôm nay

Đổi lại, yêu cầu hạ tầng rất lớn: suy luận ở độ chính xác đầy đủ cần khoảng 1,57 TB dung lượng đĩa, còn trọng số MXFP4 được phát hành cũng có kích thước tải xuống 594 GB. Bạn có thể sở hữu K3, nhưng “cục bộ” ở đây khác hoàn toàn với việc chạy một mô hình Llama 8B trên máy cá nhân.

Bài viết này tập trung vào cách:

1. Đánh giá phần cứng trước khi tải mô hình.
2. Triển khai K3 bằng vLLM hoặc llama.cpp.
3. Hiểu giới hạn khi chạy trên máy trạm hoặc Mac.
4. Kết nối endpoint K3 tự lưu trữ vào quy trình kiểm thử API bằng Apidog.

Những gì bạn đang tải xuống

Trước khi triển khai, cần hiểu cấu trúc của mô hình. Nếu cần phần giới thiệu đầy đủ, hãy đọc Kimi K3 là gì?. Tóm tắt kỹ thuật:

• Tổng cộng 2,8 nghìn tỷ tham số; 104 tỷ tham số được kích hoạt cho mỗi token. K3 là 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 2 chuyên gia chia sẻ, nên lượng tính toán thực tế thấp hơn nhiều so với tổng số tham số.
• 93 lớp: gồm 69 lớp Kimi Delta Attention (KDA) và 24 lớp Gated MLA. Kiến trúc KDA giúp cửa sổ ngữ cảnh 1 triệu token khả dụng.
• Native vision: thông qua MoonViT-V2, bộ mã hóa thị giác 401 triệu tham số. Trọng số phát hành hỗ trợ đầu vào văn bản, hình ảnh và video.
• Trọng số MXFP4, kích hoạt MXFP8: Moonshot dùng quantization-aware training. Bản 4-bit là định dạng phục vụ dự kiến, không phải bản nén bổ sung sau huấn luyện.
• Thinking-only: K3 luôn thực hiệ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ế độ phản hồi tức thì.

Trọng số được bảo vệ bởi Giấy phép Kimi K3 trong kho Hugging Face. Sau khi chấp nhận giấy phép, bạn có thể tải bằng huggingface-cli.

Với đường truyền 1 Gbps, hãy dự trù khoảng 80–90 phút để tải 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. Prefill cache cho KDA đã được tích hợp vào vLLM cùng thời điểm phát hành trọng số, vì vậy vLLM là điểm bắt đầu thực tế nhất.

Chạy máy chủ vLLM với song song tensor trên 8 GPU:

vllm serve moonshotai/Kimi-K3 \
  --tensor-parallel-size 8 \
  --max-model-len 131072

Sau khi server khởi động, vLLM thường cung cấp endpoint tương thích OpenAI tại:

http://localhost:8000/v1

Checklist triển khai

• Phần cứng: Moonshot đánh giá trên các cụm H20. Trong thực tế, cấu hình tối thiểu là một node 8 GPU với tensor parallelism. Trên phần cứng như B200, có thể đạt thông lượng trên 100 token/giây.
• Ngữ cảnh: K3 hỗ trợ tối đa 1.048.576 token, nhưng KV cache ở ngữ cảnh đầy đủ chiếm khoảng 27 GB. Bắt đầu với 131072 token, sau đó chỉ tăng nếu workload thực sự cần.
• Sampling: Thiết lập mặc định của Moonshot là temperature=1.0 và top_p=0.95. Với workload tác nhân, giữ temperature=1.0 và tăng top_p lên 1.0.

Ví dụ request kiểm tra nhanh endpoint sau khi triển khai:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai/Kimi-K3",
    "messages": [
      {
        "role": "user",
        "content": "Giải thích ngắn gọn cách hoạt động của tensor parallelism."
      }
    ],
    "temperature": 1.0,
    "top_p": 0.95
  }'

Đây là “cục bộ” theo nghĩa chủ quyền dữ liệu: hạ tầng, nhật ký và phạm vi tuân thủ đều do bạn kiểm soát. Tuy nhiên, đây không phải kiểu “cục bộ trên laptop”; lượng tử hóa không thể biến K3 thành mô hình tương tác nhẹ cho máy cá nhân.

Tùy chọn 2: Lượng tử hóa GGUF trên máy trạm lớn

Unsloth đã phát hành các bản chuyển đổi GGUF dành cho người dùng llama.cpp. Các bản lượng tử hóa động là lựa chọn thực tế nhất nếu bạn muốn chạy K3 với dung lượng thấp hơ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.
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	Gần như không mất dữ liệu.

Nguyên tắc cần nhớ:

Tổng RAM và VRAM nên xấp xỉ kích thước bản lượng tử hóa bạn chọn.

Nếu thiếu bộ nhớ, llama.cpp vẫn có thể chạy bằng offloading, nhưng tốc độ sẽ giảm theo lượng dữ liệu phải chuyển ra ngoài bộ nhớ chính. Mac Studio 128 GB hoặc DGX Station là mức cấu hình thấp nhất có thể xem xét trong thực tế.

Ví dụ lệnh llama.cpp, bao gồm 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 máy không đạt mức này, không nên cố ép chạy. Danh sách LLM cục bộ tốt nhất năm 2026 có các mô hình phù hợp với 24–128 GB RAM/VRAM và phản hồi gần thời gian thực. K3 1-bit trên bộ nhớ không đủ sẽ không mang lại trải nghiệm đó.

Thử nghiệm M1 Max: chạy được, nhưng khoảng 16 giây mỗi token

Một thảo luận trên Hacker News ghi nhận K3 chạy trên M1 Max 64 GB bằng cách stream trọng số từ SSD 2 TB thay vì giữ toàn bộ trong bộ nhớ.

Các con số cho thấy vì sao phương pháp này hoạt động, nhưng không phù hợp để sử dụng tương tác:

• K3 có khoảng 115 GB tham số dense mà mỗi token truy cập, cộng thêm khoảng 25 GB trọng số chuyên gia được định tuyến theo token.
• Chỉ riêng phần dense đã vượt RAM 64 GB, nên SSD trở thành tầng bộ nhớ chậm hơn.
• Kết quả được ghi nhận là khoảng 16 giây/token; một số cấu hình có thể vượt 1 phút/token.
• Băng thông ổ đĩa là nút thắt. SSD trên thế hệ M1 chậm hơn phần cứng Apple mới hơn, còn việc truyền chuyên gia qua mạng chậm hơn nữa.

Đây là một minh chứng thú vị rằng MoE sharding kết hợp với mmap có thể khởi chạy mô hình 2,8 nghìn tỷ tham số trên laptop. Nhưng nó không phải phương án khả thi để dùng K3 hằng ngày.

Nếu bạn chỉ muốn nhận câu trả lời từ K3 trên MacBook, gói miễn phí hoặc API được lưu trữ sẽ phù hợp hơn.

Kết nối K3 cục bộ vào quy trình làm việc API

Dù dùng vLLM hay chế độ server của llama.cpp, kết quả cuối cùng đều là một endpoint HTTP tương thích OpenAI trên localhost.

Bạn có thể áp dụng quy trình tương tự như khi kiểm tra LLM cục bộ dưới dạng API.

1. Tạo môi trường cho endpoint cục bộ

Trong Apidog, tạo environment với biến:

base_url = http://localhost:8000/v1

Sau đó, dùng biến này trong request:

POST {{base_url}}/chat/completions
Content-Type: application/json

Body:

{
  "model": "moonshotai/Kimi-K3",
  "messages": [
    {
      "role": "user",
      "content": "Tóm tắt nội dung tài liệu API này thành 3 gạch đầu dòng."
    }
  ],
  "temperature": 1.0,
  "top_p": 0.95
}

Khi chuyển sang endpoint được lưu trữ, bạn chỉ cần thay đổi base_url; request và bộ kiểm thử có thể giữ nguyên.

2. Kiểm tra luồng suy luận

K3 là mô hình thinking-only, nên phản hồi có thể chứa nội dung suy luận trước câu trả lời cuối cùng. Chế độ debug SSE của Apidog giúp quan sát dữ liệu stream khi đến endpoint.

Khi kiểm tra streaming, hãy xác nhận:

• Kết nối SSE được mở thành công.
• Chunk phản hồi đến theo thứ tự.
• Ứng dụng xử lý đúng trạng thái đang suy luận và câu trả lời hoàn chỉnh.
• Client không timeout trước khi K3 hoàn tất suy luận.

3. Xác thực cấu trúc thay vì đánh giá cảm tính

Thêm test tự động cho các điều kiện mà ứng dụng phụ thuộc vào:

• Lược đồ phản hồi hợp lệ.
• Các trường usage/token tồn tại khi backend trả về.
• Độ trễ nằm trong ngân sách cho phép.
• Nội dung cuối cùng xuất hiện đúng định dạng mà frontend cần.

Ví dụ kiểm tra cơ bản:

pm.test("Status code là 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Phản hồi có choices", function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property("choices");
  pm.expect(body.choices).to.be.an("array").that.is.not.empty;
});

pm.test("Phản hồi có nội dung", function () {
  const body = pm.response.json();
  pm.expect(body.choices[0].message.content).to.be.a("string").and.not.empty;
});

Cách này giúp phát hiện thay đổi do nâng cấp engine hoặc thay bản lượng tử hóa qua test thất bại, thay vì chờ báo cáo từ người dùng.

4. Giả lập K3 khi GPU đang bận

Mô hình 594 GB cần thời gian để tải. Để không chặn công việc frontend:

1. Ghi lại một số phản hồi thực từ endpoint K3.
2. Tạo mock response trả về cùng cấu trúc.
3. Cho frontend dùng mock server trong khi cụm GPU khởi động hoặc bảo trì.
4. Chuyển về endpoint thật khi model server sẵn sàng.

Bạn có thể tải Apidog để thiết lập miễn phí. Tính năng mock và kiểm thử hoạt động với mọi server tương thích OpenAI.

Định dạng request tương tự nội dung trong hướng dẫn API Kimi K3, vì vậy các test viết cho API được lưu trữ có thể chuyển trực tiếp sang triển khai cục bộ.

Vậy bạn có nên chạy K3 cục bộ không?

Tình huống	Đề xuất
Node có từ 8 GPU trở lên, cần chủ quyền dữ liệu hoặc tuân thủ	Có. Dùng vLLM, tensor parallelism và trọng số MXFP4.
Máy trạm có từ 350 GB RAM/VRAM	Có thể. Dùng GGUF 1-bit của Unsloth, với kỳ vọng thực tế về tốc độ.
Mac hoặc PC có 64–128 GB	Không. Bạn sẽ nhận được giây/token thay vì token/giây.
Chỉ cần tích hợp K3 vào sản phẩm	Dùng API được lưu trữ; tương thích OpenAI và Anthropic.

Tóm lại, trọng số 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 cấp cao, không phải vì mọi nhóm nên triển khai nó tại chỗ.

Nếu có hạ tầng phù hợp, con đường vLLM hiện khả thi và hiệu quả. Nếu không, bản phát hành mở vẫn mang lại lợi ích gián tiếp thông qua dịch vụ lưu trữ rẻ hơn và cạnh tranh từ các nhà cung cấp bên thứ ba.

Dù chọn phương án nào, endpoint vẫn là nơi mô hình gặp mã nguồn của bạn. Hãy xử lý nó như một API production: kiểm tra schema, kiểm tra streaming và dùng mock để quy trình phát triển không bị chặn khi mô hình đang suy luận.