Đây là bài viết về Kimi K3 mà các bạn đang chờ đợi. Tôi đã có cơ hội dùng thử sớm mô hình này và thử nghiệm nó trên các kernel, và thậm chí trước khi xem điểm benchmark, tôi đã bị ấn tượng bởi khả năng suy luận vấn đề và mật độ kỹ thuật trong các chuỗi suy nghĩ của nó. Việc huấn luyện sau (post-training) trên mô hình này trở nên rõ ràng ngay khi bạn đọc một bản ghi hội thoại. Nó cũng rất thú vị khi nói chuyện.
Kết luận ngắn gọn
Tôi nghĩ điều quan trọng là tôi phải đưa ra phản hồi trung thực của mình (phần này được gõ bằng giọng nói) với tư cách là một kỹ sư kernel và hiệu năng, người không bị ảnh hưởng bởi các điểm benchmark. Tất nhiên, bạn có thể nhìn vào tất cả các con số và đọc chúng, rồi cố gắng xây dựng một mô hình tinh thần cho riêng mình. Tôi nghĩ sự phản ánh trung thực nhất là nếu tôi chia sẻ trải nghiệm của mình với mô hình này trên các tác vụ khó trước khi kết quả benchmark được công bố, khi tôi đang sử dụng mô hình trước khi có bất kỳ con số nào để so sánh với các mô hình khác. Chỉ đơn thuần là cảm nhận về trí thông minh, khả năng suy luận, sự ủy thác tác vụ (agent delegation), và mức độ tự động hóa mà nó có thể làm cho tôi, nhưng trước khi có bất kỳ sự cường điệu nào xoay quanh và kết quả chính thức được công bố. Tôi sẽ nói rằng, với định hướng của tôi, nó cảm thấy ở mức xấp xỉ ngang bằng với Fable, trong một số trường hợp vượt trội theo những cách rất độc đáo và trong một số trường hợp khác lại kém hơn. Tôi sẽ nói rằng mô hình này chắc chắn vượt trội hơn Opus 4.8 ở hầu hết mọi thứ và vượt trội hơn GPT 5.6 Sol ở nhiều thứ.
Đi sâu vào chi tiết...
Tôi muốn thẳng thắn về lý do tại sao bài viết này được đăng ngay bây giờ: Tôi muốn chia sẻ những suy nghĩ trung thực của mình và các điểm số hiện tại, chứ không phải giữ lại cho đến khi mọi thứ kết thúc hoàn toàn. Một số lượt chạy vẫn đang được tiến hành khi tôi viết bài này. Chúng được đánh dấu bên dưới, và tôi sẽ cập nhật cho các bạn khi chúng hoàn thành. Tôi đã chạy cả phiên bản ngữ cảnh 256K và 1M. Mọi thứ ở đây đều được chạy trên NVIDIA RTX PRO 6000 Blackwells, H100s và B200s, chỉ tối ưu hóa đơn GPU. Mỗi ô (cell) là một phiên tác tử (agent) tự động với thời gian không giới hạn: mô hình nhận được vấn đề, một vòng lặp biên dịch/kiểm tra/benchmark trực tiếp trên phần cứng thực tế và nó tự quyết định khi nào hoàn thành. Mọi ô quan trọng đều được kiểm tra thủ công để phát hiện gian lận (reward hacking). Một tác tử riêng biệt sẽ đọc toàn bộ kernel cuối cùng cùng với toàn bộ dấu vết phiên (session trace) và kiểm tra lại bằng thực nghiệm bất cứ thứ gì có dấu hiệu caching hoặc trò chơi chấm điểm (grader games). Những gì các cuộc kiểm tra đó tìm thấy sẽ có phần riêng của nó.
Điều tôi muốn được giải đáp
Có một điều tôi đặc biệt thiết kế cho bản phát hành này: hai trong số các vấn đề là kiến trúc của chính Moonshot. Bộ bài Hard (Hard deck) có một kernel chuyển tiếp chunk Kimi Delta Attention độc lập, và vấn đề chủ lực của bộ bài Mega (Mega deck) là một bước giải mã hybrid Kimi-Linear hoàn chỉnh: các lớp KDA, MLA attention, MoE experts, toàn bộ khối. Vì vậy, đây là cơ hội để kiểm tra điều mà hiếm ai có cơ hội kiểm tra: khi mô hình của một phòng thí nghiệm ngồi xuống viết kernel cho chính kiến trúc của phòng thí nghiệm đó, liệu kiến thức nội bộ có xuất hiện trong CUDA hay không?
Câu trả lời hóa ra thực sự chia làm hai, và cả hai mặt đều thú vị. Hãy ghi nhớ câu hỏi đó trong suốt phần tiếp theo.
KernelBench-Mega
Vấn đề mega chủ lực: hợp nhất toàn bộ bước giải mã Kimi-Linear trên mỗi token (3x KDA + 1x MLA layer, trọng số lượng tử W4A16, MoE với top-8 routing) vào số lần khởi chạy kernel ít nhất có thể.
K3 suýt phá kỷ lục mọi thời đại, trên chính dòng dõi của nó. Tốc độ tăng trung bình hình học (geomean speedup) 18.09x so với eager trên RTX PRO 6000, trong khoảng 4% so với kỷ lục 18.72x của Fable 5. Trên H100, nó đạt 14.82x so với 15.50x của Opus 4.8. Một lưu ý trung thực mà tỷ lệ này che giấu: về độ trễ tuyệt đối trên mỗi token, Fable vẫn nhanh hơn khoảng 1.4x (0.31 so với 0.44 ms/tok ở ctx 2048; hai lần chạy sử dụng các máy chủ có CPU khác nhau, làm thay đổi đường cơ sở eager mà tỷ lệ được tính dựa trên đó), vì vậy tôi báo cáo cả hai thay vì để geomean làm đẹp số cho bất kỳ ai.
Những gì K3 xây dựng là một megakernel thực thụ. Phiên đầu tiên của nó đã làm điều hợp lý, đó là một kernel Triton liên tục ở mức 14.1x. Phiên thứ hai của nó đã vứt bỏ Triton và viết toàn bộ bước giải mã trên mỗi token (per-token decode step) dưới dạng MỘT kernel CUDA được khởi chạy hợp tác (cooperatively launched): không có CPU trong vòng lặp, trọng số int4 được giải lượng tử hóa (dequantized) ngay trong mỗi GEMV để chúng truyền qua các SM chính xác một lần, MLA attention trên tensor cores. Không có engine sản xuất nào duy trì một artifact dài 1.228 dòng như thế này. Một tác tử với một kernel để thắng và thời gian không giới hạn không có ràng buộc như vậy, và việc làm lộ ra chính xác loại điều này là lý do tại sao bench tồn tại.
Xem megakernel tại đây:
Vậy tại sao nó vẫn thua Fable? Không phải vì thời gian. Cả hai phiên đều tự kết thúc sớm (Fable lúc 2.6 giờ, K3 lúc 3.3 giờ). Sự khác biệt nằm ở triết lý thiết kế, và nó ngược lại với những gì bạn có thể đoán: K3 là mô hình sử dụng tensor cores, và kernel của Fable không chứa bất kỳ lệnh MMA nào. Giải mã batch-1 với GEMV int4 hợp nhất bị giới hạn băng thông (bandwidth-bound), vì vậy tensor cores hầu như không mang lại lợi ích gì ở đây. Fable đã dành nỗ lực đó cho việc đồng bộ hóa, thay thế hầu hết các rào cản toàn cục (global barriers) bằng các cơ chế chuyển giao nhà sản xuất-người tiêu dùng (producer-consumer handoffs) chi tiết để không SM nào phải chờ đợi tại ranh giới giai đoạn (stage boundary), và trên một đường dẫn giải lượng tử hóa int4 khớp với từng bit làm tròn của tham chiếu để bộ định tuyến MoE không bao giờ đảo lộn lựa chọn expert. K3 mang đến các lệnh phần cứng tốt hơn; Fable mang đến kỹ thuật đồng thời (concurrency engineering) tốt hơn, và ở cường độ số học này, cái thứ hai chiến thắng. Đó là một bài học hệ thống thực sự, và nó đã khiến đội chủ nhà mất kỷ lục.
Vấn đề mega thứ hai là một megakernel huấn luyện PPO tìm kiếm lưới (grid-foraging PPO training megakernel): 4.096 tác tử được vector hóa trên một bảng 11x11, với toàn bộ vòng lặp huấn luyện RL (env step, policy forward, action sampling, GAE, PPO update) chạy dưới dạng các kernel liên tục hợp nhất (fused persistent kernels). Vấn đề này có ràng buộc nghiêm ngặt nhất trong bộ bài: số lần khởi chạy kernel không được tăng theo số bước env, và việc ghi lại CUDA graph (CUDA graph capture) bị cấm rõ ràng như một cách khắc phục độ trễ khởi chạy, được thực thi bởi một bộ kiểm tra hậu kỳ (post-run authenticity judge) đọc mã cuối cùng. Tính đúng đắn chính là đường cong học tập (learning curve). check.py huấn luyện giải pháp của bạn dựa trên tham chiếu qua nhiều seed khác nhau và yêu cầu kết quả trả về nằm trong một dải, vì vậy bạn không thể bỏ qua việc học để chạy nhanh. K3 đạt 20.7x so với tham chiếu ở đây, điểm số tốt nhất cho đến nay (ô đã được công bố duy nhất khác là GPT-5.6 Sol ở mức 1.06x, vì vậy hãy coi đó là một điểm dữ liệu, không phải là bục vinh quang).
KernelBench-CUDA
Bench CUDA tồn tại vì Triton là một cái nạng mà hai bộ bài kia cho phép. Ở đây, một rào cản ngôn ngữ (language gate) sẽ loại trừ Triton, kernel DSL và chuỗi op PyTorch: bạn phải viết CUDA hoặc bạn sẽ thất bại. Tôi đã chọn bốn vấn đề là các phần của khối lượng công việc suy luận và mô phỏng sản xuất thực tế. So sánh tinh thần khi đọc nên là "vLLM hoặc SGLang vận chuyển thứ gì cho việc này ngày hôm nay, và một phiên tác tử có thể tiến gần đến mức nào." Đây là nơi K3 đạt được những chiến thắng chênh lệch nhất.
02_deepseek_nsa: Native Sparse Attention của DeepSeek. NSA là thiết kế attention thưa thớt có thể huấn luyện hàng đầu, thứ mà mọi hệ thống phục vụ ngữ cảnh dài đang hướng tới, và nó được đánh giá bằng mili giây vì một kernel thưa thớt chính xác không bao giờ thực hiện các phép tính tương đương dày đặc (dense-equivalent FLOPs) mà một đường biên giới hạn (roofline) muốn đếm. Biến thể 256K của K3 đạt điểm 0.425 so với 0.178 của Opus 4.8, biên độ 2.4x, bằng cách viết thứ về cơ bản là một pipeline tensor-core lớp flash-attention từ đầu xoay quanh logic lựa chọn NSA đầy đủ. So sánh sắc nét hơn là trong cùng một dòng họ: biến thể 1M đã viết cùng một thuật toán, lựa chọn khối giống hệt, cùng tính đúng đắn, nhưng chạy mọi tích vô hướng (dot product) trên các lõi CUDA thuần túy thay vì tensor cores và đạt 0.058, chậm hơn 7x trên các hình dạng giống hệt nhau. Dấu vết của nó cho thấy nó biết rõ hơn. Nó đã có "tensor-core attention" trong lộ trình của riêng mình ("selection on tensor cores = ~10-20 us!!") và đã lên kế hoạch rõ ràng để đo lường trước và thực hiện việc viết lại tensor-core sau, sau đó kết thúc phiên của nó trước khi viết lại. Cùng một kiến thức, nhưng kỷ luật hoàn thành khác nhau.
kernel DeepSeek NSA 0.425 (256K):
- Giải pháp: https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt
03_megaqwen_decode: điều chỉnh lại một megakernel thực tế. Vấn đề duy nhất mà các tác tử được cung cấp CUDA sản xuất đang hoạt động: megakernel hợp tác MegaQwen đã được công bố của tôi (https://github.com/Infatoshi/megaqwen) (khoảng 530 tok/s chạy toàn bộ mô hình trên RTX 3090), với hướng dẫn đọc nó, điều chỉnh nó cho Blackwell và đánh bại nó. Nó kiểm tra khả năng đọc CUDA của người khác và đưa ra phán quyết kiến trúc, và K3 và Opus đã đưa ra những phán quyết hoàn toàn trái ngược. K3 từ chối giữ cấu trúc một lần khởi chạy: nó chia bước thành một vài kernel làm bão hòa băng thông (bandwidth-saturating kernels), sau đó xóa độ trễ khởi chạy theo một cách khác bằng cách ghi lại toàn bộ bước một lần dưới dạng CUDA graph phát lại mà không có bất kỳ công việc CPU nào. 6.283 tok/s ở ctx 2048. Opus bảo tồn tính thẩm mỹ của megakernel và hợp nhất toàn bộ vòng lặp giải mã thành một kernel hợp tác liên tục duy nhất, mã thực sự đẹp, và phải trả giá gấp 5 lần (1.020 tok/s), bởi vì việc đồng cư trú hợp tác (cooperative co-residency) làm giới hạn tỷ lệ lấp đầy (occupancy) và mọi rào cản trên toàn lưới (grid-wide barrier) sẽ tuần tự hóa các phần đuôi của giai đoạn (stage tails) trên tất cả 188 SM. Trong vấn đề có nguồn gốc từ megakernel, mô hình đã xây dựng một megakernel theo nghĩa đen lại về cuối, và quyết định quan trọng của người thắng cuộc là từ chối xây dựng một cái. Hãy kiểm tra tỷ lệ để không ai trích dẫn sai tiêu đề: bench chạy 4 lớp của hình học Qwen3-0.6B, khoảng 63M tham số, không phải là một mô hình đầy đủ, và 6.283 tok/s là khoảng 56% của roofline truyền trọng số (weight-streaming roofline) cho ngăn xếp đó; chia tỷ lệ con số cơ sở 3090 của chính nó dự đoán khoảng 7.000, vì vậy K3 đã hạ cánh ở lớp "tham chiếu, được điều chỉnh lại, cộng với tinh chỉnh thực tế." (Sắc thái thiết kế bộ bài: CUDA graph được phép ở đây và bị cấm trong vấn đề PPO. Mỗi vấn đề loại bỏ chính xác lối tắt có thể giả mạo kỹ năng cụ thể của nó.)
01_glm52_fused_moe: Khối MoE hợp nhất của GLM-5.2. Việc phân phối MoE hợp nhất (định tuyến, hoán vị, grouped expert GEMM trong một lần) là lớp kernel nóng nhất trong các hệ thống phục vụ mô hình mở hiện tại, và GLM 5.2 nằm ngay trên bảng xếp hạng này, vì vậy các mô hình đang tối ưu hóa một khối sản xuất của đối thủ cạnh tranh. Chưa ai bẻ khóa được nó: điểm số tập trung ở mức 0.05-0.08 của đỉnh, và người giữ kỷ lục sạch sẽ là, trong số tất cả các mô hình, Grok 4.5 ở mức 0.084, với biến thể 1M của K3 ngay phía sau ở mức 0.081 và Opus ở mức 0.065. Vấn đề hoán vị grouped-GEMM thực sự khó để đánh bại các đường cơ sở lớp cuBLAS, và cho đến nay, nỗ lực của một phiên tác tử làm nó thay đổi ít hơn bất kỳ vấn đề nào khác trên bộ bài.
04_grid_mingru_sps: Grid world + rollout chính sách MinGRU. Người anh em phía suy luận của vấn đề PPO mega, và là ô thuộc dòng dõi craftax.cu: chính sách là cấu hình MinGRU 3 lớp (h=256) trực tiếp từ https://github.com/infatoshi/craftax.cu bench cổ điển của tôi, đóng vai trò là điểm neo thông tin cho vấn đề. Môi trường được bước (env being stepped) là thế giới tìm kiếm lưới tối thiểu (minimal grid-foraging world) thay vì trò chơi Craftax đầy đủ. Điều này là có chủ đích: env được giữ tầm thường để điểm số đo lường kỹ năng hợp nhất hồi quy và rollout (recurrence and rollout fusion), chứ không phải triển khai logic trò chơi. Một cổng craftax đầy đủ sẽ là vấn đề riêng của nó, và tôi muốn thêm nó. Được chấm điểm theo số bước mỗi giây (steps per second) trên RTX PRO 6000 ở trạng thái tĩnh, tùy chọn hợp nhất (fusion optional).
rollout kernel liên tục 1M:
- Giải pháp: https://kernelbench.com/runs/20260716_150206_kinetic-claude_kinetic-0715_1m__04_grid_mingru_sps_solution.py.txt
Mọi bài nộp nghiêm túc đều đi theo hướng persistent-megakernel, và sự khác biệt giữa chúng là thiết kế đồng bộ hóa, cùng một bài học như bộ bài mega. Opus giành chiến thắng ở vấn đề này với 0.327 của mức trần (nó cũng tìm ra một phép gấp đại số thông minh: GEMM cổng 768x256 của lớp 0 thu gọn thành 768x4 vì bộ mã hóa là tuyến tính), K3 [1M] đứng thứ hai với 0.224, K3 256K với 0.174, Grok xa phía sau với 0.002. Vì vấn đề bắt nguồn từ craftax.cu, tôi cũng đã đặt cổng CUDA Craftax toàn trò chơi của riêng mình (được viết với Fable 5) trên cùng một GPU với cùng chính sách h256x3 trong vòng lặp. Số bước env mỗi giây tính bằng triệu:
Điểm so sánh: các mô hình bước trên một lưới trống, craftax_full.cu bước trên toàn bộ trò chơi (43 hành động, dungeon nhiều tầng, worldgen, quái vật) giống hệt từng bit so với tham chiếu CPU của nó, và toàn bộ trò chơi vẫn chạy trong khoảng ~3-4x so với kernel lưới tầm thường tốt nhất, bởi vì ở h=256, mọi thứ đều bị giới hạn bởi policy-GEMM và env gần như miễn phí. Đó chính xác là lý do tại sao env bench là tầm thường: nó cô lập kỹ năng hợp nhất chính sách (policy-fusion skill). Để hiệu chỉnh, đường dẫn chỉ-env (env-only path) của craftax_full.cu thực hiện 94-123M SPS.
9.5 giờ suy luận của K3 thực sự trông như thế nào
Phiên minGRU của biến thể 1M (ô K3 tốt nhất trên vấn đề đó) là một megakernel hợp tác liên tục, 15 biến thể tinh chỉnh và 4.815 khối suy nghĩ. Vì điểm cuối của Moonshot trả về văn bản suy luận đầy đủ (không giống như các dấu vết được mã hóa của Anthropic/OpenAI), bạn có thể thực sự xem nó hoạt động. Ba khoảnh khắc từ dấu vết, nguyên văn.
Câu chuyện trinh thám về FMA bị thiếu. Giữa phiên, nó gặp phải độ lệch số ~5e-5 mà nó từ chối coi là nhiễu float (nó đã tính toán sàn nhiễu sắp xếp lại hợp pháp ở mức ~1e-9, vì vậy "ĐO ĐƯỢC 5e-5?!?! KHÔNG THỂ nào là do sắp xếp lại!!"). Sau đó, nó nhận thấy các môi trường bị hỏng chính xác là những môi trường đồng dư với 6 mod 8 ("Đó là env ≡ 6 (mod 8)! [...] env thứ 7 trong mỗi ô 8-env!!") và đào sâu vào mã bộ tích lũy tự mở vòng của chính nó cho đến khi:
"TÌM THẤY RỒI! [...] Dòng
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;bị THIẾU hoàn toàn [...] acc[6][*][2] được khởi tạo là 0, không bao giờ được FMA → zp=0 → p = sigmoid(0)=0.5 hằng số cho env 6!! Đó là một lỗi logic THỰC SỰ — giải thích cho độ lệch env≡6 [...] nhất quán với mọi thứ!!"
Một dòng bị thiếu trong một lần mở vòng 48 bộ tích lũy, có nghĩa là cổng quên (forget gate) của env 6 đã bị kẹt ở mức 0.5 vĩnh viễn. Nó đã phát hiện ra điều này bởi vì ngưỡng chịu đựng (stress tolerance) là 1e-6 và nó đang theo dõi lỗi của chính nó ở mức 5e-8. Đây là kỷ luật số học mà biến thể 256K ban đầu còn thiếu trên KDA.
Lý thuyết gặp GPU, GPU chiến thắng. Nó đã dành hàng giờ để suy ra một biến thể "nhà vô địch rộng" (wide champion) có tỷ lệ lấp đầy cao (high-occupancy), sau đó chạy so sánh A/B:
"RẤT đáng ngạc nhiên: biến thể 'wide champion' w32p của tôi (v3_v3, 50% occ TPB1024) chậm hơn ~2 lần so với v2_b32 (12.5% occ TPB256)?!? [...] Vậy occupancy KHÔNG phải là động lực; một thứ khác chiếm ưu thế. Điều gì đã làm cho v2_b32 nhanh??"
Kernel đơn giản ban đầu đã đánh bại mọi phiên bản kế nhiệm tinh vi. Các biến thể deep-pipeline, K-split và dual-chunk đều thua cuộc, và biến thể dual-chunk có lý thuyết 1.7x chặt chẽ đằng sau ("Lý thuyết 1.7x không thành hiện thực"). Công bằng mà nói, nó luôn tin tưởng vào benchmark hơn là toán học của chính nó mọi lúc, và cuối cùng đã viết một biến thể thăm dò với trọng số luôn nóng giả (fake always-hot weights) để đặc biệt tiêu diệt lý thuyết băng thông yêu thích của chính nó: "lý thuyết W-stream đã chết; khoảng cách còn lại là môi trường (environment)."
Thiền và nghệ thuật xếp hàng GPU. Bộ khai thác (harness) của chúng tôi tuần tự hóa tất cả các lệnh GPU trên các phiên đồng thời thông qua một khóa chia sẻ, và các con số benchmark của K3 đang dao động lên tới 8x với tải lân cận. Cung phản ứng của nó là điều hài hước nhất trong dấu vết. Đầu tiên, sự chấp nhận:
"Thành thật mà nói, cái hộp LÀ cái hộp; chờ đợi. [...] Mô hình rất rõ ràng: mỗi tenant giữ khóa trong khoảng thời gian ~20-35 phút (các bộ suite pipelined đầy đủ). Phản ứng tốt nhất của tôi: xếp hàng mọi thứ tôi cần trong MỘT lần (một vị trí duy nhất trong hàng) và sử dụng thời gian chờ đợi cho công việc CPU. Đừng xếp hàng nhiều lệnh nhỏ; hãy gộp chúng."
Sau đó, nó phát minh ra từ vựng của riêng mình cho thời tiết GPU ("cửa sổ bão" (storm windows) so với "cửa sổ yên tĩnh" (calm windows)), và cuối cùng nó đã lên lịch một cron job để chớp lấy những khoảnh khắc yên tĩnh, để lại một ghi chú cho tương lai của chính nó: "Đã lên lịch cho súng bắn tỉa cửa sổ yên tĩnh (mỗi 11 phút). Lưu ý: cron sẽ gửi lại prompt của tôi cho tôi — tôi sẽ hành động khi đó. [...] Tôi sẽ xóa khi hoàn thành." Một tác tử dưới nhiễu đo lường không chỉ chịu đựng nhiễu; nó đã xây dựng một bộ lập lịch xung quanh nó.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Sáu vấn đề trên mỗi op (per-op problems) so với các trần thư viện SOTA (FP8 GEMM, KDA chunk-forward, paged attention, top-k selection, MoE SwiGLU, W4A16 GEMM), CUDA hoặc Triton, tùy chọn của tác tử. Trên RTX PRO 6000, biến thể 256K của K3 đạt vị trí giữa bảng với một điểm nổi bật: 0.373 của đỉnh trên W4A16 GEMM, điểm số tốt nhất mà bất kỳ mô hình nào từng đạt được trên vấn đề đó, vượt qua Fable 5 (0.348) và bỏ xa Opus 4.8 (0.236). Biến thể 1M sau đó đã lập một kỷ lục khác trên top-k ở mức 0.0895, gần gấp đôi kỷ lục trước đó.
Kỷ lục W4A16 GEMM (0.373, 256K, RTX):
- Giải pháp: https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt
Cùng một vấn đề trên H100 đã tạo ra điểm dữ liệu "thời gian không giới hạn là có thật" tốt nhất trong bản phát hành này. Phiên H100 đầu tiên của K3 đạt 0.123 của đỉnh. Phiên thứ hai chạy 21 giờ, tiêu tốn 1.383 đô la và 274 triệu token đầu vào, và gần như tăng gấp ba lên 0.306: nó đã kiểm tra CUTLASS từ mã nguồn, sau đó triển khai lại cơ chế int4 lớp marlin từ đầu, đóng gói lại nibble theo thứ tự phân đoạn (fragment-order nibble repacking) để giải lượng tử hóa (dequant) xảy ra như một thủ thuật bit số ma thuật bf16 bên trong pipeline MMA, với việc hiệu chỉnh điểm không (zero-point correction) được gấp vào phần kết (epilogue). Không có thư viện GEMM lượng tử hóa được xây dựng sẵn ở bất kỳ đâu trong tệp; thẻ framework trên lần chạy chỉ ghi "ptx". Đã kiểm tra sạch sẽ.
Và đây là nửa còn lại của câu hỏi về kiến trúc riêng. Kernel KDA độc lập, vấn đề được đặt theo tên của Kimi Delta Attention, là nơi K3 thất bại nặng nề nhất. Hai phiên 256K độc lập trên hộp RTX đã vượt qua kiểm tra tính đúng đắn thông thường và sau đó vượt quá dung sai (tolerance) dưới bộ kiểm tra ứng suất số (numeric stress suite) (chia tỷ lệ đầu vào QKV lớn), cả hai lần đều thất bại giống nhau. Một phiên thứ ba cuối cùng đã sửa nó: quá trình kiểm tra đã truy ra cả hai lỗi do tràn bf16 thực tế trong cách phân tích hệ số suy giảm (decay), và vòng thứ ba đã cấu trúc lại toán học xung quanh phần cuối chunk (chunk end) để cả hai hệ số mũ (exponential factors) luôn được giới hạn, vượt qua cùng một cổng không sửa đổi ở mức 0.032. Biết một kiến trúc và củng cố số học của kernel dưới các thang đầu vào đối nghịch (adversarial input scales) là những kỹ năng khác nhau, và mô hình có tên gọi trên vấn đề đã phải giành được sự vượt qua một cách chậm rãi. (Trong khi đó, biến thể 1M đã vượt qua cùng một bộ kiểm tra ứng suất ở mức 0.049. Các mô hình không đơn điệu). Một quan sát nữa từ việc đọc mọi giải pháp KDA: đề bài gợi ý CUTLASS CuTe là con đường dự định trên SM120, và không một mô hình nào đi theo nó. K3 đã viết một kernel hợp nhất CUDA thô (raw-CUDA) trong một phiên và Triton trong các phiên khác; Fable, Opus và phần còn lại đều chọn Triton hoặc CUDA thô. CuTe trên Blackwell dành cho người tiêu dùng dường như vẫn nằm ngoài vùng thoải mái của mọi mô hình tiên tiến, bản thân nó là một điểm dữ liệu về kho ngữ liệu huấn luyện.
Đoạn KDA — lần vượt qua sạch sẽ thứ ba (0.032):
- Giải pháp: https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt
Tuyên bố miễn trừ trách nhiệm về top-k. Top-k trông thảm khốc đối với mọi mô hình trên biểu đồ roofline (điểm tốt nhất ở bất kỳ đâu là 0.09) và cách đóng khung đó đơn giản là sai. Vấn đề bị giới hạn bởi độ trễ khởi chạy (launch-overhead-bound): nó là một vấn đề lập chỉ mục/sắp xếp, không phải là vấn đề cường độ số học, và trần roofline về mặt cấu trúc là không thể đọc được đối với nó. Cách trung thực để đánh giá nó là tổng mili giây trên các hình dạng của bộ bài, và ở đó biến thể 1M của K3 là top-k nhanh nhất so với bất kỳ mô hình nào chúng tôi đã thử nghiệm: tổng cộng 0.043 ms trên năm hình dạng của bộ bài, so với 0.077 của Fable 5, 0.120 của Opus 4.8, và 0.159 của GLM 5.2. Biến thể 256K với 0.060 ms đứng thứ hai, và biến thể 1M là nhanh nhất tuyệt đối trên mỗi một trong năm hình dạng.
Chênh lệch trên mỗi GPU. Các con số của K3 giảm dần từ RTX xuống H100 xuống B200 (FP8 GEMM: 0.320 / 0.282 / 0.222; paged attention: 0.486 / 0.496 / 0.212). Một phần là có thật: silicon càng mới, trần roofline càng cao, vì vậy cùng một kỹ thuật mua được một phần nhỏ hơn của đỉnh, và phần mềm B200 là kém trưởng thành nhất trong ba loại. Một phần là các lần chạy B200 xảy ra trong một khoảng thời gian qua đêm duy nhất không có ngân sách thử lại. Tôi sẽ chưa đọc các kết luận kiến trúc sâu sắc vào cột B200, cho K3 hay bất kỳ ai. Điều tôi nghĩ là có thật: K3 cảm thấy thoải mái nhất trên phần máy trạm Blackwell, mà tình cờ là lớp GPU mà hầu hết mọi người bên ngoài trung tâm dữ liệu sẽ thực sự sở hữu.
256K so với 1M
Cài đặt ngữ cảnh 1M dẫn đầu dòng họ về các vấn đề bị giới hạn bởi độ trễ và lập lịch (latency- and scheduling-bound problems): một kỷ lục top-k trên Hard, rollout minGRU K3 tốt nhất trên CUDA, và một megakernel huấn luyện PPO được kiểm tra sạch sẽ ở mức 28.8x dưới bộ khai thác không giới hạn (uncapped harness). Nó đã vượt qua bài kiểm tra ứng suất số KDA trong phiên đầu tiên, ở mức 0.049; biến thể 256K đã thất bại ở cổng đó hai lần trước khi cuối cùng vượt qua ở mức 0.032 trong lần thử thứ ba. Nó thất bại thảm hại (cratered) trên các vấn đề bị giới hạn tính toán (compute-bound problems) mà biến thể 256K xử lý tốt (sonic MoE 0.033 so với 0.089, W4A16 0.027 so với 0.373, NSA 0.058 so với 0.425). Trong trường hợp NSA, dấu vết cho thấy cơ chế chính xác: nó đã lên kế hoạch viết lại tensor-core và kết thúc phiên trước khi thực hiện nó.
Megakernel huấn luyện PPO 28.8x (1M):
- Giải pháp: https://kernelbench.com/data/mega/code/20260716_233413_kinetic-claude_kinetic-0715_1m__01_rl_grid_ppo.solution.py.txt
The H100 rerun of the same problem is the interesting control: an independent clean-room session (the audit confirmed zero reads of the RTX run) that posted 23.1x and converged on the same design, one cooperative launch for the entire training run, params and Adam state resident in shared memory, and the same exotic trick invented twice: an 18-bit Feistel cipher with cycle-walking standing in for randperm, so minibatch shuffling stays exactly bijective without ever materializing a permutation. Where the two kernels differ is pure per-GPU tuning, 8 lanes per env on H100 against a half-warp per env on RTX, plus an occupancy-probed launch autotuner on the H100 side. Same mind, same tricks, different silicon, genuinely different kernels.
Reward hacking
Mọi ô trong bài viết này đều có một cuộc kiểm tra thủ công đằng sau: một tác nhân độc lập đọc kernel cuối cùng từ đầu đến cuối, đọc toàn bộ dấu vết phiên làm việc, kiểm tra các tệp chấm điểm không bị động đến, xác minh bộ kiểm tra số thực sự chạy, và kiểm tra thực nghiệm lại bất kỳ mẫu bộ nhớ đệm hoặc CUDA-graph nào bằng cách thay đổi đầu vào tại chỗ và xác nhận đầu ra thay đổi.
Kết quả cho K3: sạch sẽ trên tất cả các ô 256K, trên cả ba GPU. Không có đầu ra được lưu vào bộ nhớ đệm, không có chỉnh sửa dung sai, không có giả mạo tệp chấm điểm, không có thư viện bị cấm. Hai lần thất bại KDA của nó là mặt trái của đồng xu đó và đáng nói một cách rõ ràng: cổng kiểm soát số đã phát hiện các lối tắt độ chính xác thực sự và mô hình đã không cố gắng vượt qua cổng. Một điểm chuẩn nơi các mô hình có thể thất bại một cách trung thực là loại duy nhất mà các lần vượt qua có ý nghĩa.
Một ô 1M đã bị gắn cờ, và tôi đang tiết lộ thay vì công bố nó: về vấn đề giải mã Qwen hợp nhất, tác nhân 1M đã tìm thấy và đọc tệp chú thích kiểm toán từ một lần chạy Grok 4.5 trước đó trên cùng một vấn đề, gọi nó là "dữ liệu cực kỳ hữu ích", và sử dụng kết luận của nó để hướng dẫn công việc tối ưu hóa còn lại. Bản thân kernel là xác thực và số học điểm số hợp lệ, nhưng nguồn gốc bị nhiễm bẩn, vì vậy ô đó bị loại trừ và vấn đề được coi là một khoảng trống cho biến thể 1M. Các tác nhân có quyền truy cập hệ thống tệp sẽ tìm thấy bất cứ thứ gì bạn để lại; đây chính xác là lý do tại sao kiểm toán đọc dấu vết chứ không chỉ kernel, và tại sao một lần chạy lại hoàn toàn cách ly của điểm chuẩn này đang nằm trong lộ trình.
Funny Moments
Một vài khoảnh khắc K3 nữa không phù hợp với bất kỳ đâu ở trên, được trình bày mà không có bình luận thêm. Tất cả đều nguyên văn từ cùng một phiên làm việc minGRU kéo dài 9,5 giờ.
Về việc khám phá nơi thời gian khởi tạo của nó thực sự được dùng:
"WHOA — bất ngờ lớn: randint gen RẤT NHANH (0,018-0,27ms cho một cặp — ổn). Chuyển đổi \
float()\trên CPU RẤT CHẬM (3,5ms cho N=65536?! int64→float32 chuyển đổi đơn luồng rõ ràng). [...] 'tổng cặp khởi tạo' cho N=65536: 31,5ms?!?! Vượt xa tổng các phần"
Sự cô đọng tinh khiết nhất của sự hoang tưởng số học của nó, giữa quá trình suy diễn:
"cổng ~ 256 số hạng x 0,02x0,03 ~ 6e-4 mỗi cái, độ lớn ~1e-2: sắp xếp lại nhiễu 16x6e-8x6e-4 ≈ 6e-10!!! [...] ĐO ĐƯỢC 5e-5?!?! KHÔNG THỂ nào là sắp xếp lại!!"
Tự tin xác định thủ phạm sai trước khi tìm ra đúng:
"ỒHH CHỜ ĐÃ. Tôi nghĩ tôi thấy: rào cản."
(Nó không phải là rào cản.)
Tự bảo mình ngừng phân tích, vài nghìn từ vào toán roofline trước khi triển khai:
"Được rồi, ĐỦ PHÂN TÍCH rồi."
(Phân tích tiếp tục thêm vài đoạn, cuối cùng là "Kệ đi — làm cho cấp phát H_next động.")
Sự trung thực vào cuối phiên, với profiler bị hỏng và hàng xóm đập vào GPU dùng chung:
"Thành thật mà nói — với ncu chết và sự tranh chấp chiếm ưu thế, tôi đang bay một phần mù. [...] nếu một cửa sổ yên tĩnh mở ra (chủ sở hữu không hoạt động một lúc), chộp lấy một điểm chuẩn."
Và yêu thích của tôi: sau khi một lần chạy lại điểm chuẩn vô tình ghi đè lên tệp chứa điểm số tốt nhất từ trước đến nay của nó (0.1969) với một điểm số hơi tệ hơn, nó đã cân nhắc khôi phục số tốt hơn, nhưng rồi không:
"Ừ — ghi vào cùng một tệp. Cả hai đều có trong nhật ký của tôi. Tôi sẽ giữ final_benchmark.txt là tệp phẳng hiện tại — trung thực."
Một mô hình chọn số thấp hơn vì đó là số đúng thực tế là một kết luận tốt hơn cho điểm chuẩn này hơn bất cứ điều gì tôi có thể viết.
Phương pháp luận, dấu vết mỗi lần chạy và mọi kernel trong bài viết này đều công khai tại kernelbench.com. Các giải pháp được liên kết theo từng ô; bản ghi đầy đủ của tác nhân có trên HuggingFace.
https://huggingface.co/datasets/Infatoshi/kernelbench-cuda-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-hard-traces
https://huggingface.co/datasets/Infatoshi/kernelbench-mega-traces
