Chạy mô hình 2.78 nghìn tỷ tham số trên laptop 8GB: mổ xẻ kimi-k3-in-c

Một dự án gần đây trong cộng đồng open-source khiến bạn phải dừng lại nhìn: kimi-k3-in-c — engine inference Kimi K3 viết bằng C99 di động, 176KB mã, không BLAS, không framework, không GPU, chạy được mô hình 2.78 nghìn tỷ tham số trên laptop 8GB thông thường. Đây không phải lời quảng cáo: repo có đầy đủ thang kiểm chứng và dữ liệu đo — peak RSS đo được 8.24GB, và đầu ra giống hệt từng byte từ máy 8GB đến 224GB, chỉ khác đồng hồ.

Dự án này là gì

kimi-k3-in-c do developer FareedKhan-dev khởi xướng theo Apache-2.0, hiện ở phiên bản 1.1.0. Gói gọn trong một câu: viết lại inference của Kimi K3 bằng C di động đơn giản nhất, và tạo ra kết quả đồng nhất ở mọi ngân sách bộ nhớ.

Điều cốt lõi: đĩa là cửa ải, không phải máy tính. Checkpoint cần khoảng 1.7TB trống; RAM bắt đầu từ 8GB; GCC 9+ hoặc Clang 10+ là build được. Nói cách khác, một máy phát triển bình thường cộng một ổ cứng lớn là chạy được — không cần cụm GPU.

Bốn quyết định kỹ thuật

Mô hình 2.8T đòi hỏi bộ nhớ cấp TB. Dự án này nén xuống 8GB bằng bốn quyết định:

Một, expert giữ nguyên dạng đóng gói 4-bit. 1.45TB trọng số routed experts không bao giờ thường trú toàn bộ; nó được nhân thẳng từ dạng đóng gói nửa byte. Khác với giải nén rồi tính — cách đó phình bộ nhớ lên nhiều lần.

Hai, KDA attention với bộ nhớ không tăng. Attention truyền thống tăng tuyến tính theo ngữ cảnh, làm bùng nổ bộ nhớ ở ngữ cảnh dài. KDA (attention có trạng thái) giữ attention state ở kích thước cố định, nên chi phí bộ nhớ của ngữ cảnh dài gần như bằng không.

Ba, MLA: một latent thay cho 96 head. KV cache là kẻ ngốn bộ nhớ lớn; MLA nén KV của nhiều head thành một biểu diễn latent duy nhất, thu nhỏ cache đáng kể.

Bốn, stream trunk cộng LRU cache cho expert. Trunk dày 93 lớp được đọc từ đĩa theo nhu cầu (một lần đọc mỗi lớp), và trọng số expert nằm sau một LRU cache. Nhiều bộ nhớ hơn nghĩa là nhiều trunk thường trú hơn; ít bộ nhớ hơn nghĩa là đọc đĩa nhiều hơn.

Thang latency đo thực

Số liệu do dự án công bố (cùng máy: 124 lõi, NVMe nhanh; cùng một prompt ngắn):

Hai lần chạy batch thật từ README:

# Laptop 8GB
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset laptop \
         --tok ~/k3model --prompt "The capital of France is" --gen 8 --incremental
8 tokens in 261.5 s, 32.69 s/token average
PEAK RSS for the whole run: 8.24 GB

# Workstation 128GB+
$ ./bin/k3 ~/k3model --trunk ~/k3trunk --preset server \
         --tok ~/k3model --prompt "def fibonacci(n):" --gen 28 --incremental
28 tokens in 299.3 s, 10.69 s/token average
PEAK RSS for the whole run: 127.92 GB

Điểm cần đọc không phải tốc độ tuyệt đối mà là hình dạng đường cong: nhiều bộ nhớ hơn thì nhanh hơn, câu trả lời không đổi. Phiên bản 1.1.0 so với 1.0.0 giảm tính toán mỗi token khoảng tám lần, câu hỏi nối tiếp trong chat nhanh hơn 3.9 lần, prompt dài rẻ hơn một nửa — dự án vẫn đang tối ưu nhanh.

Kiểm chứng một phút, không cần checkpoint

Lựa chọn thiết kế đáng học nhất ở đây: kiểm chứng mất khoảng một phút và không cần trọng số mô hình.

git clone https://github.com/FareedKhan-dev/kimi-k3-in-c.git
cd kimi-k3-in-c

make -j        # biên dịch: vài giây
make test      # toàn bộ test: dưới một phút

Kết quả in ba cổng — teacher forcing 32/32, greedy decode 20/20, incremental decode (KV cache + KDA state mang theo) 20/20 — kết thúc bằng VERDICT: ENGINE MATCHES THE REFERENCE EXACTLY. Không có checkpoint, bạn vẫn kiểm chứng mọi kernel, streaming cache, safetensors reader, config reader và tokenizer so với PyTorch reference được commit trong repo.

Nói cách khác: bạn xác nhận engine đáng tin trước khi chi hàng nghìn đô cho ổ cứng. Đó là kỹ thuật open-source chín chắn, và đúng là kiểu thực hành mà tuyến nội dung ecosystem nên làm nổi bật.

Đường tới văn bản thật

Để sinh văn bản cần checkpoint Kimi K3 chính thức. Lộ trình: clone repo → chạy ./scripts/k3-doctor.sh (kiểm toolchain, khớp RAM với preset, đo tốc độ lưu trữ, in đúng lệnh tiếp theo) → tải checkpoint (1.56TB) → đóng gói trunk → chạy.

• --preset chọn ngân sách: laptop (từ 8GB) đến server (workstation bộ nhớ lớn), cộng preset ultra mới hơn
• Chế độ tương tác: dự án có chat REPL (XTML) cho hội thoại nhiều lượt
• Truy vết expert cache: python3 tools/sim_cache.py tests/fixtures/expert_trace.bin phát lại trace 100,096 yêu cầu expert để tái tạo bảng dung lượng cache — không cần checkpoint

Dự án này có ý nghĩa gì với developer

Nếu bạn xây inference engine hoặc tối ưu hệ thống: đây là reference implementation gần mức giáo trình — từ đọc header safetensors, parse config, tokenizer mức byte, đến attention variant và MoE routing. README Part II dựng từng thành phần một, trực quan hơn đọc paper nhiều.

Nếu bạn muốn hiểu vì sao MoE "tiết kiệm compute mà không tiết kiệm bộ nhớ": dự án trả lời bằng hành động. Trọng số expert phải tồn tại ở đâu đó (ở đây là đĩa), nhưng mỗi token chỉ kích hoạt một phần, nên compute có hạn. Tỷ lệ cache hit quyết định lượng I/O đĩa — đó là lý do máy 128GB giảm từ 26 giây xuống 5,6 giây mỗi token.

Nếu bạn muốn trải nghiệm K3 với chi phí thấp: nói thẳng, 26 giây/token không phải trải nghiệm chat. Giá trị của dự án là học tập, thí nghiệm offline và câu hỏi kỹ thuật nhét mô hình khổng lồ vào máy nhỏ. Với hội thoại thật, cloud API là đúng — kimi-k3 của EXAIV phục vụ cùng mô hình ở độ trễ vài giây.

Đọc các con số của dự án cho công bằng

Mọi số hiệu năng trong bài này lấy từ tài liệu của chính repo dưới docs/data/ — tức phép đo do dự án công bố, không phải benchmark độc lập. Sự phân biệt này quan trọng khi đánh giá bất kỳ engine nào:

• Công bố phần cứng: số liệu lấy trên một máy (124 lõi, NVMe nhanh); ổ chậm hơn làm các hàng phụ thuộc đĩa chậm hơn, điều mà chính dự án cũng ghi chú
• Cái gì kiểm chứng được, cái gì là đo lường: khẳng định đúng đắn thì ai cũng reproduce — clone, build, chạy test không trọng số so với PyTorch oracle đã commit. Khẳng định latency phụ thuộc phần cứng
• Tin cái nào trước: tính byte-identical là thuộc tính kiến trúc (đường tính toán xác định) nên đi được qua máy; thời gian tuyệt đối thì không

Đây là tư thế đúng với mọi khẳng định hiệu năng open-source: tái hiện cái tái hiện được, đọc phần còn lại cùng bối cảnh phần cứng. Repo làm điều đó dễ dàng bằng cách gửi kèm đầu ra đo thô thay vì bản tóm tắt marketing.

FAQ

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

• K3 chạy trên laptop 8GB thế nào
• CPU inference hoạt động thế nào ở đây
• disk streaming được hiện thực thế nào

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ừ README dự án kimi-k3-in-c và checkpoint Kimi K3 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: developer nghiên cứu inference engine và triển khai cục bộ. Phạm vi: các quyết định kỹ thuật và dữ liệu đo được của dự án. Không bao gồm: lời khuyên tối ưu hiệu năng hoặc triển khai thương mại.

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

• Hướng dẫn Kimi K3
• Triển khai Kimi K3 open-weight
• So sánh GGUF quantizer
• Sổ tay triển khai local
• Mô hình chi phí tính toán local