Con số nổi bật của Kimi K3 là 2.8 nghìn tỷ tham số. Đó là con số ít thú vị nhất trong báo cáo.
Điều thú vị là kiến trúc được tổ chức quanh một câu hỏi không liên quan đến kích thước: thông tin đang bị nghẽn ở đâu? Câu trả lời có ba phần — dọc chuỗi, theo chiều sâu, theo chiều rộng — và mỗi phần có cơ chế riêng.
Cùng lượng tính toán, hiệu quả mở rộng khoảng 2.5× Kimi K2. Con số đó đến từ các đường cong quy luật mở rộng do chính nhóm khớp dữ liệu, không phải kết quả tái lập của bên thứ ba, nên hãy hiểu đó là tuyên bố của họ. Nhưng các cơ chế phía sau đủ cụ thể để tranh luận, và đó là điều khiến báo cáo đáng dành thời gian đọc.
Đây là bài phân tích kỹ báo cáo kỹ thuật Kimi K3 (Moonshot AI), tập trung vào phần kiến trúc. Trước đây chúng tôi đã viết về thiết kế tác nhân thực hiện tác vụ dài; bài này đi xuống một tầng sâu hơn trong hệ thống.
Ba hướng, không chỉ một con số
Mỗi lớp trong transformer trộn thông tin theo ba cách. Giữa các token, để vị trí 900,000 có thể ảnh hưởng đến vị trí 1. Theo chiều sâu, để lớp 90 có thể dùng điều lớp 3 nhận ra. Giữa các kênh, để đặc trưng có thể tái tổ hợp.
Phần lớn công việc mở rộng tác động cả ba cùng lúc bằng cách tăng kích thước mọi thứ. K3 tách chúng ra và dành cho mỗi hướng một cơ chế riêng:
- Chuỗi — cơ chế chú ý lai: cứ ba lớp Kimi Delta Attention có một lớp Gated MLA.
- Chiều sâu — Attention Residuals: mỗi lớp dùng cơ chế chú ý trên đầu ra của mọi lớp trước thay vì thừa hưởng một trạng thái tích lũy duy nhất.
- Chiều rộng — Stable LatentMoE: 896 chuyên gia được định tuyến, 16 chuyên gia được kích hoạt cho mỗi token.
Số chiều ẩn không thay đổi chút nào. 7,168 ở K2, 7,168 ở K3. Dù thứ gì đã lớn hơn, đó không phải chiều rộng của một lớp.
Chuỗi: ba phần tư số lớp ngừng đọc mọi thứ
Cơ chế chú ý tiêu chuẩn đọc lại toàn bộ tiền tố cho mỗi token mới. Ở một triệu token, chính chi phí đó làm hệ thống quá tải.
K3 chia công việc ra. Ba lớp KDA giữ một trạng thái cập nhật liên tục có kích thước cố định — giống ghi chú hơn là đọc lại nguồn — rồi đến một lớp Gated MLA thực hiện chú ý toàn cục đầy đủ. Mẫu này lặp lại, với thêm một lớp MLA ở cuối cùng để lớp cuối luôn thấy mọi thứ. Trong 93 lớp: 69 KDA, 24 MLA.
Kích thước cố định chính là điểm cốt lõi. Trạng thái không tăng theo chuỗi, nên không thể phình mất kiểm soát. Nó cũng làm mất thông tin, vì thế cứ đến lớp thứ tư lại có một lớp chú ý đầy đủ để khôi phục những gì phần ghi chú bỏ sót.
Sau đó là một tác động bậc hai. Vì trạng thái hồi quy có suy giảm — token gần tự nhiên hiện diện rõ hơn token cũ — thông tin vị trí có sẵn mà không tốn thêm chi phí. Vì vậy K3 hoàn toàn không dùng mã hóa vị trí cho các lớp chú ý toàn cục. Không RoPE, không có gì cần đổi thang.
Điều đó nghĩa là mở rộng lên một triệu token không cần can thiệp mã hóa vị trí. Không thủ thuật nội suy nào mà lĩnh vực này tích lũy để mở rộng ngữ cảnh áp dụng ở đây, vì không có mã hóa để nội suy.
Một cận dưới loại bỏ một nhánh mã GPU
Đây là phần chúng tôi thích nhất trong báo cáo, và nó đủ nhỏ để dễ bị lướt qua.
Trạng thái hồi quy quên dần khi tiến lên. Tính toán điều đó hiệu quả theo từng khối đòi hỏi chia cho hệ số suy giảm tích lũy, mà hệ số này là tích của các số nhỏ hơn một. Để nó diễn ra không kiểm soát, bạn sẽ chia cho một giá trị gần không tùy ý.
Thế hệ trước xử lý bằng cách chia mỗi khối thành các ô 16 token và tính trong miền logarit. Cách này hoạt động, nhưng các ô trên đường chéo vẫn phải tính từng cặp vị trí — một nhánh xử lý riêng chậm, không dùng được lõi tensor.
Cách sửa của K3 chỉ là một dòng tham số hóa. Đặt cận dưới cho logarit hệ số suy giảm: mỗi bước được phép quên đến mức chỉ còn 0.67% những gì nó đang giữ, không thấp hơn nữa.
Lần theo hệ quả. Với cận đó, logarit suy giảm tích lũy trên một ô 16 token nằm trong (−80, 0). Vì vậy nghịch đảo nhỏ hơn e80 ≈ 5.5 × 1034, nằm an toàn trong phạm vi khoảng 3.4 × 10 của BF1638. Không có gì tràn số. Vì thế các ô đường chéo có thể dùng cùng phép nhân ma trận đặc như mọi ô khác.
Nhánh xử lý riêng không được tối ưu. Nó biến mất.
Đọc ngược quan hệ nhân quả còn thú vị hơn: dải động của phần cứng quyết định khoảng chấp nhận được, khoảng đó quyết định hằng số, hằng số quyết định hàm kích hoạt phải có cận dưới. Tính toán số chọn phép toán, không phải ngược lại.
Chiều sâu: từ chạy tiếp sức sang trò chuyện nhóm
Với độ sâu chín mươi ba lớp, luồng phần dư tiêu chuẩn là một cuộc chạy tiếp sức. Lớp 50 nhận một trạng thái tích lũy từ lớp 49. Những gì từng lớp từ 1 đến 48 nhận ra đã được cộng vào trạng thái đó và không còn tách riêng được.
Bài báo xem đây là cùng nút thắt mà RNN gặp theo thời gian — và lĩnh vực này đã giải quyết nó bằng cơ chế chú ý. Attention Residuals áp dụng cùng cách sửa cho chiều sâu: mỗi lớp mang một truy vấn giả có thể học và dùng chú ý trên đầu ra của mọi lớp trước, tự chọn thứ cần đọc.
Nếu làm đúng nguyên nghĩa, chi phí tính toán tăng bậc hai theo chiều sâu, và tệ hơn là phải giữ đầu ra của mọi lớp trong bộ nhớ và truyền qua kết nối khi song song hóa đường ống. Vì thế K3 dùng biến thể theo khối: 93 lớp chia thành các nhóm mười hai, cộng trong nhóm, chú ý đầy đủ giữa các nhóm. Chi phí phụ giảm từ theo từng lớp xuống theo từng nhóm, và trạng thái lúc suy luận vẫn được giới hạn.
Chiều rộng: 896 chuyên gia, 16 được kích hoạt
Mô hình hỗn hợp chuyên gia duy trì một tập lớn và kích hoạt vài chuyên gia cho mỗi token. K2 chọn 8 trong 384. K3 chọn 16 trong 896 — độ thưa là 56.
Mở rộng tập chuyên gia đến mức đó làm hỏng hai thứ, và báo cáo thẳng thắn khác thường về cả hai.
Truyền thông. Trong MoE thông thường, mỗi chuyên gia được chọn nhận token đủ chiều rộng, nên lưu lượng truyền tăng theo số chuyên gia bạn chọn. LatentMoE tách hai yếu tố này: chuyên gia được định tuyến làm việc trong không gian tiềm ẩn gọn, bằng nửa chiều rộng mô hình, còn hai chuyên gia dùng chung đủ chiều rộng xử lý những gì mọi token đều cần. Tập chuyên gia có thể tăng mà chi phí truyền không tăng theo.
Độ ổn định. Ở độ thưa này, nhánh định tuyến trở thành chuỗi gần bốn phép nhân ma trận liên tiếp, và các giá trị kích hoạt bùng nổ. Hai cách sửa: đặt RMSNorm giữa bước tổng hợp chuyên gia và phép chiếu tăng chiều, cùng hàm kích hoạt mới SiTU-GLU, dùng tanh được điều chỉnh thang để chặn cả hai thừa số của SwiGLU, ngăn chúng tăng mất kiểm soát ở độ chính xác thấp.
Cân bằng. Cách sửa thứ ba đáng học theo. Giữ tải cân bằng cho khoảng 900 chuyên gia đòi hỏi điều chỉnh độ lệch riêng của từng chuyên gia ở mỗi bước. Phương pháp tiêu chuẩn dịch mỗi độ lệch một lượng cố định theo hướng sai số, dẫn đến dao động hoặc chậm theo kịp. K3 giải trực tiếp thay vào đó: chạy top-(k+1) thay vì top-k, và phần tử bổ sung chính là điểm số mà một token đòi hỏi để được chọn. Có các ngưỡng đó, tải mà một chuyên gia nhận dưới một độ lệch ứng viên là đơn điệu, nên độ lệch đạt tải mục tiêu đơn giản là một phân vị của các độ chênh. Một lượt truyền xuôi, không có độ lớn bước cần tinh chỉnh.
Ở quy mô lớn, phân vị đó bao trùm hàng triệu giá trị trên mọi tiến trình, nên họ ước lượng bằng biểu đồ tần suất: mỗi tiến trình đếm các khoảng của mình, một phép all-reduce cộng chúng lại, rồi đọc phân vị từ tổng số đếm. Số đếm có tính cộng, nên ước lượng phản ánh toàn bộ lô bất kể token được phân mảnh ra sao, với chi phí vài trăm khoảng cho mỗi chuyên gia.
Chi phí dồn về hệ thống phục vụ suy luận
Không điều nào ở đây miễn phí, và phần thẳng thắn của báo cáo là mục hạ tầng, nơi chi phí thực sự phát sinh.
Trạng thái hồi quy kích thước cố định rẻ để lưu và di chuyển, nhưng cập nhật tuần tự và không thể chỉ cộng đơn giản. Cả hai tính chất đều tạo thêm việc:
- Chia một chuỗi trên nhiều thiết bị. Chú ý tuyến tính thông thường cho phép mỗi thiết bị tính trạng thái cục bộ từ không rồi cộng kết quả. KDA áp dụng phép chuyển đổi phụ thuộc token lên trạng thái đầu vào, nên cộng là sai. Cách sửa phân rã mỗi đoạn thành một phép chuyển đổi tích lũy và một trạng thái khởi đầu từ không — hai đại lượng có thể hợp thành — rồi khôi phục trạng thái đầu vào của mỗi thiết bị bằng phép quét tiền tố và một phép all-gather kích thước cố định.
- Tái sử dụng tiền tố giữa các yêu cầu. Một nửa bộ nhớ đệm là các trang theo token, nửa còn lại là một trạng thái cố định cho mỗi yêu cầu, và một lần tìm thấy dữ liệu trong bộ nhớ đệm cần cả hai có thể khôi phục ở cùng ranh giới. Câu trả lời của họ là tách độ hạt: băm theo 512 token, cấp phát theo 1024–6144, và chỉ lưu điểm kiểm tra trạng thái hồi quy ở một tập con thưa của các điểm cuối băm.
- Giải mã suy đoán. Trạng thái được cập nhật tại chỗ, nên không thể hoàn tác một bản nháp bị từ chối. Thay vào đó, họ lưu đệm các đầu vào đã được chiếu — nhỏ hơn nhiều so với bản thân trạng thái — rồi tái dựng ngay trên chip.
Điểm chung của cả ba là mô thức từ giới hạn suy giảm, nhưng theo chiều ngược lại: kiến trúc chọn cách biểu diễn, và cách biểu diễn quyết định công việc ở cấp hệ thống.
Một thông lệ mà bài báo âm thầm bỏ qua
K3 vốn đã là mô hình đa phương thức, và bộ mã hóa thị giác của nó được huấn luyện từ đầu bằng dự đoán token tiếp theo. Không khởi tạo bằng SigLIP, không tiền huấn luyện tương phản — vốn là công thức tiêu chuẩn, kể cả trong mô hình trước đó của chính nhóm.
Lý do được nêu không phải chất lượng, mà là độ ổn định: bộ mã hóa khởi tạo bằng học tương phản liên tục có chuẩn gradient cao hơn, thường xuyên tăng vọt khi tối ưu hóa đồng thời, còn bộ huấn luyện từ đầu giữ ổn định. Kết quả đánh giá thị giác ngang nhau.
Điều đó khiến phát hiện này sắc nét hơn cả một chiến thắng. Nếu huấn luyện từ đầu tốt hơn, bạn sẽ gọi đó là một công thức tốt hơn. Nhưng nó chỉ ngang bằng — nên luận điểm ở đây là ở quy mô này, một bước mà cả lĩnh vực xem là bắt buộc thực ra chỉ là tùy chọn.
Điều này có ý nghĩa gì nếu bạn chạy tác tử trên các mô hình này
Chúng tôi xây dựng ứng dụng máy tính đa tác tử, nên điều chúng tôi quan tâm là liệu một lượt chạy dài hơi có giữ được chi phí hợp lý hay không, chứ không phải mô hình nào đứng đầu bảng xếp hạng.
Con số quan trọng không phải kích thước cửa sổ ngữ cảnh, mà là chi phí phục vụ một triệu token. Ba phần tư số lớp mang trạng thái có kích thước cố định, nên bộ nhớ đệm tăng theo cuộc hội thoại chỉ bằng một phần tư so với mô hình cùng độ sâu dùng hoàn toàn cơ chế chú ý. Trên BrowseComp, báo cáo ghi nhận K3 đạt 91.2% với khoảng $2 mỗi tác vụ — bằng khoảng một nửa chi phí của kết quả gần nhất từ mô hình độc quyền, và thấp hơn một bậc độ lớn so với các mô hình Claude ở mức nỗ lực tối đa.
Với một tác tử thực hiện hàng trăm lệnh gọi công cụ, tỷ lệ đó quyết định liệu một tác vụ có đáng thử hay không. Công việc kiến trúc từng có vẻ thuần nghiên cứu nay trực tiếp quyết định liệu một lượt chạy dài có hợp lý về kinh tế hay không.
Điều chúng tôi rút ra
Hai điều, đều có thể áp dụng ở nơi khác.
Thứ nhất, cách đặt vấn đề. Thông tin đang bị nghẽn ở đâu? dẫn đến công việc khác với chúng ta có thể tăng quy mô thêm bao nhiêu? — và vấn đề đó có thể được phân rã, nhờ vậy ba cơ chế có thể được phát triển và đo lường riêng biệt.
Thứ hai, giới hạn suy giảm. Một ràng buộc gần như không làm giảm khả năng biểu đạt đã loại bỏ toàn bộ một nhánh xử lý trường hợp đặc biệt khỏi kernel. Không phải nhánh nhanh hơn — mà là không còn nhánh đó. Sự đánh đổi này có thể thực hiện thường xuyên hơn nhiều so với thực tế, và chỉ những người đồng thời nắm cả toán học lẫn phần cứng mới nhìn thấy nó.
Báo cáo và trọng số được công khai trên GitHub. Phần kiến trúc dài tám trang và rất đáng đọc kỹ.