บทความ Kimi K3 ที่ทุกคนรอคอยมาถึงแล้วครับ ผมได้สิทธิ์ทดสอบโมเดลนี้ก่อนใคร และได้ทดสอบมันบนเคอร์เนลต่างๆ ก่อนที่จะเห็นคะแนน benchmark ด้วยซ้ำ ผมก็ประทับใจในความสามารถในการให้เหตุผลและความหนาแน่นทางเทคนิคของ traces ความคิดของมัน การ post-training ของโมเดลนี้ชัดเจนทันทีที่อ่าน transcript และมันก็สนุกมากที่จะคุยด้วย
TLDR;
ผมคิดว่ามันสำคัญที่ผมจะให้ feedback ตรงๆ (ส่วนนี้พิมพ์ด้วยเสียง) ในฐานะวิศวกรเคอร์เนลและประสิทธิภาพที่ไม่ได้ผูกติดกับ benchmark แน่นอน คุณสามารถดูตัวเลขทั้งหมดและอ่านมัน แล้วลองสร้าง mental model ให้ตัวเองได้ แต่ผมคิดว่าสิ่งที่สะท้อนความจริงที่สุดคือการให้คุณได้สัมผัสประสบการณ์ของผมกับโมเดลนี้ในงานยากๆ ก่อนที่ผล benchmark จะออก เมื่อผมใช้โมเดลก่อนที่จะมีตัวเลขใดๆ มาเชื่อมโยงกับโมเดลอื่นๆ แค่รู้สึกถึงความฉลาด การให้เหตุผล การมอบหมายงานให้ agent และความสามารถในการทำ autopilot ให้ผมได้มากแค่ไหน แต่ก่อนที่จะมี hype ใดๆ และผลลัพธ์อย่างเป็นทางการออกมา ผมบอกได้เลยว่า ภายใต้การชี้นำของผม มันให้ความรู้สึกประมาณระดับ Fable ในบางกรณีก็ทำได้ดีกว่าในแบบที่ unique มาก และในบางกรณีก็ทำได้แย่กว่า ผมว่าโมเดลนี้เหนือกว่า Opus 4.8 ในหลายๆ เรื่อง และเหนือกว่า GPT 5.6 Sol ในหลายๆ เรื่องเช่นกัน
เข้าสู่เนื้อหากันดีกว่า...
ผมอยากจะตรงไปตรงมาว่าทำไมถึงออกมาตอนนี้: ผมอยากแชร์ความคิดเห็นที่ตรงไปตรงมาและคะแนนเท่าที่มีอยู่ ไม่ใช่เก็บไว้จนกว่าทุกเซลล์สุดท้ายจะเสร็จ การรันบางส่วนยังคงดำเนินอยู่ขณะที่ผมเขียนข้อความนี้ พวกมันถูกทำเครื่องหมายไว้ด้านล่าง และผมจะแจ้งให้คุณทราบเมื่อมันเสร็จ ผมรันทั้งเวอร์ชัน 256K และ 1M context ทุกอย่างที่นี่รันบน NVIDIA RTX PRO 6000 Blackwells, H100s และ B200s, single-GPU optimization เท่านั้น แต่ละเซลล์คือหนึ่ง autonomous agent session โดยไม่มีข้อจำกัดด้านเวลา: โมเดลได้รับปัญหา, compile/check/benchmark แบบสดๆ บนฮาร์ดแวร์จริง และมันตัดสินใจเองเมื่อเสร็จ ทุกเซลล์ headline ถูกตรวจสอบด้วยตนเองเพื่อหา reward hacking เอเจนต์แยกต่างหากอ่านเคอร์เนลสุดท้ายตั้งแต่ต้นจนจบ และ session trace ทั้งหมด และทดสอบซ้ำเชิงประจักษ์ทุกอย่างที่ดูเหมือน caching หรือ grader games สิ่งที่การตรวจสอบเหล่านั้นพบจะอยู่ในส่วนของตัวเอง
สิ่งที่ผมอยากรู้คำตอบ
มีสิ่งหนึ่งที่ผมออกแบบการเปิดตัวครั้งนี้โดยเฉพาะ: ปัญหาสองข้อเป็นสถาปัตยกรรมของ Moonshot เอง ชุด Hard มี standalone Kimi Delta Attention chunk-forward kernel และปัญหาเรือธงของชุด Mega คือ hybrid decode step แบบ Kimi-Linear ที่สมบูรณ์: KDA layers, MLA attention, MoE experts, ทั้งบล็อก ดังนั้นนี่คือโอกาสในการทดสอบสิ่งที่ไม่มีใครได้ทดสอบบ่อยนัก: เมื่อโมเดลของห้องปฏิบัติการหนึ่งนั่งลงเพื่อเขียนเคอร์เนลสำหรับสถาปัตยกรรมของห้องปฏิบัติการเดียวกันนั้น ความรู้ภายในครอบครัวจะปรากฏใน CUDA หรือไม่?
คำตอบที่ออกมากลับแบ่งออกเป็นสองฝ่ายอย่างชัดเจน และทั้งสองฝ่ายก็น่าสนใจ เก็บคำถามนั้นไว้ในใจในระหว่างส่วนถัดไป
KernelBench-Mega
ปัญหา mega เรือธง: รวม decode step แบบ Kimi-Linear ต่อ token (3x KDA + 1x MLA layer, น้ำหนักแบบ W4A16 quantized, MoE พร้อม top-8 routing) ให้มีการ launch kernel น้อยที่สุดเท่าที่เป็นไปได้
K3 เกือบทำลายสถิติตลอดกาลของสายเลือดของตัวเอง 18.09x geomean speedup เหนือ eager บน RTX PRO 6000 ภายใน 4% ของสถิติ 18.72x ของ Fable 5 บน H100 มันทำได้ 14.82x เทียบกับ 15.50x ของ Opus 4.8 ข้อสังเกตหนึ่งที่อัตราส่วนซ่อนไว้คือในแง่ของ latency ต่อ token แบบสัมบูรณ์ Fable ยังเร็วอยู่ ~1.4x (0.31 vs 0.44 ms/tok ที่ ctx 2048; การรันทั้งสองครั้งใช้โฮสต์ที่มี CPU ต่างกัน ซึ่งทำให้ eager baseline ที่ใช้อัตราส่วนคำนวณเปลี่ยนไป) ดังนั้นผมจึงรายงานทั้งคู่เพื่อไม่ให้ geomean ทำให้ใครดูดีเกินจริง
สิ่งที่ K3 สร้างขึ้นคือ megakernel ที่แท้จริง เซสชันแรกของมันทำในสิ่งที่สมเหตุสมผล คือ persistent Triton kernel ที่ 14.1x เซสชันที่สองทิ้ง Triton และเขียน decode step ต่อ token ทั้งหมดเป็น CUDA kernel หนึ่งเดียวที่ทำงานร่วมกัน: ไม่มี CPU ในลูป, ถอดรหัสน้ำหนัก int4 แบบทันทีภายใน GEMV แต่ละตัวเพื่อให้มันสตรีมผ่าน SMs เพียงครั้งเดียว, MLA attention บน tensor cores ไม่มี production engine ใดจะรักษา artifact ขนาด 1,228 บรรทัดแบบนี้ไว้ได้ เอเจนต์ที่มีเคอร์เนลเดียวที่จะชนะและเวลาไม่จำกัดไม่มีข้อจำกัดดังกล่าว และการเผยให้เห็นสิ่งนี้คือเหตุผลที่ bench นี้มีอยู่
ดู megakernel ได้ที่นี่:
แล้วทำไมมันถึงยังแพ้ Fable? ไม่ใช่เรื่องเวลา ทั้งสองเซสชันหยุดตัวเองก่อนกำหนด (Fable ที่ 2.6 ชั่วโมง, K3 ที่ 3.3) ความแตกต่างคือปรัชญาการออกแบบ และมันตรงกันข้ามกับสิ่งที่คุณเดา: K3 คือตัวที่ใช้ tensor cores และเคอร์เนลของ Fable ไม่มีคำสั่ง MMA เลย Batch-1 decode ด้วย fused int4 GEMVs นั้นมี bandwidth เป็นคอขวด ดังนั้น tensor cores จึงแทบไม่ช่วยอะไรที่นี่ Fable ใช้ความพยายามนั้นไปกับการซิงโครไนซ์แทน โดยแทนที่ global barriers ส่วนใหญ่ด้วยการส่งต่อแบบ producer-consumer ที่ละเอียด เพื่อไม่ให้ SM ใดว่างที่ขอบเขต stage และบน dequant path แบบ int4 ที่ตรงกับการปัดเศษของ reference ทีละบิต เพื่อให้ MoE router ไม่พลิก expert choice K3 นำคำสั่งฮาร์ดแวร์ที่ดีกว่า Fable นำวิศวกรรมการทำงานพร้อมกันที่ดีกว่า และที่ความเข้มข้นทางคณิตศาสตร์นี้ อย่างที่สองชนะ นั่นคือบทเรียนระบบจริง และมันทำให้ทีมเจ้าบ้านเสียสถิติ
ปัญหา mega ที่สองคือ grid-foraging PPO training megakernel: เอเจนต์แบบ vectorized 4,096 ตัวบนกระดาน 11x11 โดยมี RL training loop ทั้งหมด (env step, policy forward, action sampling, GAE, การอัปเดต PPO) ทำงานเป็น fused persistent kernels ปัญหานี้มีข้อจำกัดที่เข้มงวดที่สุดในชุด: จำนวนการ launch kernel ต้องไม่ปรับขนาดตาม env steps และการจับ CUDA graph ถูกห้ามอย่างชัดเจนในฐานะวิธีแก้ปัญหาค่าใช้จ่ายในการ launch โดยบังคับใช้โดยผู้พิพากษาความถูกต้องหลังการรันที่อ่านโค้ดสุดท้าย ความถูกต้องคือเส้นโค้งการเรียนรู้เอง check.py ฝึกฝนโซลูชันของคุณเทียบกับ reference ข้าม seeds และต้องการให้ผลตอบแทนอยู่ในช่วงที่กำหนด ดังนั้นคุณจึงไม่สามารถข้ามการเรียนรู้เพื่อให้เร็วได้ K3 ทำได้ 20.7x เหนือ reference ที่นี่ ซึ่งเป็นคะแนนที่ดีที่สุดจนถึงตอนนี้ (เซลล์ที่เผยแพร่เพียงเซลล์เดียวคือ GPT-5.6 Sol ที่ 1.06x ดังนั้นให้ถือเป็นข้อมูลจุดหนึ่ง ไม่ใช่แท่น)
KernelBench-CUDA
CUDA bench มีอยู่เพราะ Triton เป็นไม้ค้ำที่อีกสองชุดอนุญาต ที่นี่ gate ภาษาจะห้าม Triton, kernel DSLs และ PyTorch op-chains อย่างเด็ดขาด: คุณต้องเขียน CUDA หรือไม่ก็ล้มเหลว ผมเลือกปัญหาสี่ข้อให้เป็นส่วนของ workload การอนุมานและการจำลองการผลิตจริง การเปรียบเทียบทางจิตใจขณะอ่านควรเป็น "vLLM หรือ SGLang ส่งอะไรให้วันนี้ และหนึ่ง agent session ใกล้เคียงแค่ไหน" นี่คือจุดที่ K3 โพสต์ชัยชนะที่ขาดลอยที่สุด
02_deepseek_nsa: Native Sparse Attention ของ DeepSeek NSA คือการออกแบบ attention ที่ trainable-sparsity เรือธง สิ่งที่ทุก stack การให้บริการ long-context กำลังให้ความสนใจ และมันถูกตัดสินในหน่วยมิลลิวินาที เพราะ sparse kernel ที่ถูกต้องไม่เคยดำเนินการ FLOPs ที่เทียบเท่า dense ซึ่ง roofline ต้องการนับ K3 เวอร์ชัน 256K ได้คะแนน 0.425 เทียบกับ Opus 4.8 ที่ 0.178 ต่างกัน 2.4 เท่า โดยการเขียนสิ่งที่เทียบเท่ากับ tensor-core pipeline ระดับ flash-attention ตั้งแต่เริ่มต้นรอบตรรกะการเลือก NSA ทั้งหมด การเปรียบเทียบที่ชัดเจนกว่าคือภายในตระกูล: เวอร์ชัน 1M เขียนอัลกอริทึมเดียวกัน เลือกบล็อกเหมือนกัน ความถูกต้องเหมือนกัน แต่รัน dot product ทุกตัวบน CUDA cores ธรรมดาแทนที่จะเป็น tensor cores และได้ผลลัพธ์ที่ 0.058 ช้ากว่า 7 เท่าบน shapes ที่เหมือนกัน trace ของมันแสดงให้เห็นว่ามันรู้ดีกว่า มันมี "tensor-core attention" อยู่ใน roadmap ของตัวเอง ("selection on tensor cores = ~10-20 us!!") และวางแผนไว้อย่างชัดเจนว่าจะวัดก่อนแล้วจึงเขียน tensor-core rewrite ทีหลัง แต่แล้วก็จบเซสชันก่อนที่จะเขียนใหม่ ความรู้เดียวกัน แต่วินัยในการปิดงานต่างกัน
เคอร์เนล DeepSeek NSA 0.425 (256K):
- Solution: https://kernelbench.com/runs/20260716_112858_kinetic-claude_kinetic-0715_02_deepseek_nsa_solution.py.txt
03_megaqwen_decode: ปรับเป้าหมาย megakernel จริง ปัญหาเดียวที่เอเจนต์ได้รับ CUDA การผลิตที่ใช้งานได้: MegaQwen ที่เผยแพร่ของผม (https://github.com/Infatoshi/megaqwen) cooperative megakernel (~530 tok/s รันทั้งโมเดลบน RTX 3090) พร้อมคำแนะนำให้อ่านมัน ปรับเป้าหมายให้เป็น Blackwell และเอาชนะมัน มันทดสอบการอ่าน CUDA ของคนอื่นและตัดสินใจเชิงสถาปัตยกรรม และ K3 กับ Opus ตัดสินใจตรงกันข้ามโดยสิ้นเชิง K3 ปฏิเสธที่จะรักษาโครงสร้าง single-launch: มันแบ่งขั้นตอนออกเป็นเคอร์เนลจำนวนหนึ่งที่อิ่มตัว bandwidth แล้วลบค่าใช้จ่ายในการ launch ด้วยวิธีอื่นโดยการจับภาพทั้งขั้นตอนครั้งเดียวเป็น CUDA graph ที่เล่นซ้ำโดยไม่มีงาน CPU เลย 6,283 tok/s ที่ ctx 2048 Opus รักษาความสวยงามของ megakernel และรวม decode loop ทั้งหมดเป็น persistent cooperative kernel หนึ่งเดียว โค้ดสวยงามจริงๆ แต่จ่าย到 5 เท่า (1,020 tok/s) เพราะ cooperative co-residency ทำให้ occupancy มีจำกัด และ grid-wide barrier ทุกตัวทำให้ส่วนท้ายของ stage ต้องรอคอยทั่วทั้ง 188 SMs ในปัญหาที่สืบทอดมาจาก megakernel โมเดลที่สร้าง megakernel ขึ้นมาจริงๆ กลับมาเป็นอันดับสุดท้าย และการตัดสินใจสำคัญของผู้ชนะคือการปฏิเสธที่จะสร้างมัน ตรวจสอบสเกลเพื่อไม่ให้ใครตีความ headline ผิด: bench รัน 4 layers ของ Qwen3-0.6B geometry ประมาณ 63M params ไม่ใช่ทั้งโมเดล และ 6,283 tok/s คือ ~56% ของ weight-streaming roofline สำหรับ stack นั้น; การปรับขนาด baseline ของ 3090 เองคาดการณ์ไว้ประมาณ ~7,000 ดังนั้น K3 จึงอยู่ในคลาส "reference ที่ปรับเป้าหมายแล้ว บวกกับการปรับแต่งจริง" (ความแตกต่างของการออกแบบชุด: CUDA graphs ใช้ได้ที่นี่และถูกห้ามในปัญหา PPO แต่ละปัญหาห้ามทางลัดที่จะปลอมแปลงทักษะเฉพาะของมัน)
01_glm52_fused_moe: Fused MoE block ของ GLM-5.2 Fused MoE dispatch (routing, permutation, grouped expert GEMMs ใน pass เดียว) เป็นคลาสเคอร์เนลที่ร้อนแรงที่สุดในการให้บริการโมเดลเปิดในปัจจุบัน และ GLM 5.2 อยู่ในลีดเดอร์บอร์ดนี้ ดังนั้นโมเดลต่างๆ จึงกำลังปรับแต่งบล็อกการผลิตของคู่แข่ง ไม่มีใครทำได้สำเร็จ: คะแนนกระจุกตัวที่ 0.05-0.08 ของจุดสูงสุด และผู้ถือสถิติที่สะอาดคือ Grok 4.5 ที่ 0.084 ตามด้วย K3 เวอร์ชัน 1M ที่ 0.081 และ Opus ที่ 0.065 ปัญหา permutation แบบ grouped-GEMM นั้นยากจริงๆ ที่จะเอาชนะ baselines ระดับ cuBLAS และจนถึงตอนนี้ ความพยายามหนึ่ง agent session ทำให้มันเคลื่อนที่น้อยกว่าปัญหาอื่นๆ ในชุด
04_grid_mingru_sps: Grid world + MinGRU policy rollout ด้านการอนุมานของปัญหา PPO mega และเซลล์สายเลือด craftax.cu: policy คือ MinGRU 3 ชั้น (h=256) config โดยตรงจาก https://github.com/infatoshi/craftax.cu classic bench ของผม ซึ่งทำหน้าที่เป็นจุดยึดข้อมูลของปัญหา สภาพแวดล้อมที่ถูก step คือโลก grid-foraging ขั้นต่ำ แทนที่จะเป็นเกม Craftax เต็มรูปแบบ นั่นเป็นความตั้งใจ: สภาพแวดล้อมถูกทำให้เล็กน้อยเพื่อให้คะแนนวัดทักษะการรวม recurrence และ rollout ไม่ใช่การใช้งานเกมลอจิก การพอร์ต Craftax เต็มรูปแบบจะเป็นปัญหาของมันเอง และผมอยากเพิ่มมัน ให้คะแนนเป็น steps ต่อวินาทีบน RTX PRO 6000 ที่เงียบ โดย fusion เป็นตัวเลือก
Rollout แบบ persistent-kernel 1M:
ทุกการส่งที่จริงจังไปที่ persistent-megakernel และการกระจายตัวระหว่างพวกมันคือการออกแบบการซิงโครไนซ์ ซึ่งเป็นบทเรียนเดียวกับชุด Mega Opus ชนะอันนี้ที่ 0.327 ของเพดาน (มันยังพบการพับพีชคณิตที่ชาญฉลาด: 768x256 gate GEMM ของเลเยอร์ 0 ยุบเป็น 768x4 เพราะ encoder เป็นเชิงเส้น) K3 [1M] ที่สองที่ 0.224, K3 256K ที่ 0.174, Grok ตามหลังไกลที่ 0.002 เนื่องจากปัญหาสืบเชื้อสายมาจาก craftax.cu ผมจึงใส่พอร์ต CUDA เกม Craftax เต็มรูปแบบของผมเอง (เขียนด้วย Fable 5) บน GPU เดียวกันกับ policy h256x3 ชุดเดียวกันในลูป Env steps ต่อวินาทีในหน่วยล้าน:
จุดเปรียบเทียบ: โมเดลต่างๆ step กริดว่าง craftax_full.cu steps เกมที่สมบูรณ์ (43 การกระทำ, ดันเจี้ยนหลายชั้น, worldgen, mobs) ที่ bit-identical กับ CPU reference และเกมเต็มยังคงทำงานภายใน ~3-4x ของเคอร์เนลกริดเล็กน้อยที่ดีที่สุด เพราะที่ h=256 ทุกอย่างถูกจำกัดด้วย policy-GEMM และ env แทบจะฟรี นั่นคือเหตุผลที่ env ของ bench เป็นเรื่องเล็กน้อย: มันแยกทักษะการรวม policy สำหรับการสอบเทียบ เส้นทางเฉพาะ env ของ craftax_full.cu ทำได้ 94-123M SPS
การให้เหตุผล 9.5 ชั่วโมงของ K3 มีลักษณะอย่างไร
เซสชัน minGRU ของเวอร์ชัน 1M (เซลล์ K3 ที่ดีที่สุดในปัญหานั้น) คือ persistent cooperative megakernel หนึ่งตัว, tuning variants 15 ตัว และ thinking blocks 4,815 บล็อก เนื่องจากปลายทางของ Moonshot ส่งคืนข้อความการให้เหตุผลแบบเต็ม (ไม่เหมือนกับ traces ที่เข้ารหัสของ Anthropic/OpenAI) คุณจึงสามารถดูมันทำงานได้จริง สามช่วงเวลาจาก trace คำต่อคำ
เรื่องราวนักสืบ FMA ที่หายไป กลางเซสชัน มันเจอค่าคลาดเคลื่อนเชิงตัวเลข ~5e-5 ซึ่งมันปฏิเสธที่จะเขียนทิ้งเป็นสัญญาณรบกวน float (มันคำนวณพื้นสัญญาณรบกวนจากการเรียงลำดับใหม่ที่ถูกต้องที่ ~1e-9 ดังนั้น "MEASURED 5e-5?!?! NO WAY this is reorder!!") จากนั้นมันสังเกตว่าสภาพแวดล้อมที่เสียคือสภาพแวดล้อมที่สอดคล้องกับ 6 mod 8 ("That's env ≡ 6 (mod 8)! [...] the 7th env in each 8-env tile!!") และขุดคุ้ยโค้ด accumulator ที่คลายเกลียวด้วยตนเองจนกระทั่ง:
"FOUND IT! [...] The \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\line is MISSING entirely [...] acc[6][*][2] initialized 0, never FMA'd → zp=0 → p = sigmoid(0)=0.5 constant for env 6!! That's a REAL logic bug — explains env≡6 deviations [...] consistent with everything!!"
หนึ่งบรรทัดที่หายไปในการคลายเกลียว 48 ตัวสะสม หมายความว่า forget gate ของ env 6 ติดอยู่ที่ 0.5 อย่างเงียบๆ ตลอดไป มันจับได้เพราะค่าความทนทานต่อความเครียดคือ 1e-6 และมันติดตามข้อผิดพลาดของตัวเองที่ 5e-8 นี่คือวินัยด้านตัวเลขที่เวอร์ชัน 256K ขาดไปในตอนแรกบน KDA
ทฤษฎีพบ GPU, GPU ชนะ มันใช้เวลาหลายชั่วโมงในการ推导 "wide champion" variant ที่มี occupancy สูง จากนั้นรัน A/B:
"VERY surprising: my 'wide champion' w32p (v3_v3, 50% occ TPB1024) is ~2x SLOWER than v2_b32 (12.5% occ TPB256)?!? [...] So occupancy is NOT the driver; something else dominates. What made v2_b32 fast??"
เคอร์เนลแรกที่เรียบง่ายเอาชนะผู้สืบทอดที่ซับซ้อนทุกตัว deep-pipeline, K-split และ dual-chunk variants ก็แพ้หมดเช่นกัน และ dual-chunk ตัวหนึ่งมีทฤษฎีที่แน่นหนาที่ 1.7x ("Theoretical 1.7x didn't materialize") ต้องยกความดีความชอบที่มันยังคงเชื่อถือ benchmark มากกว่าคณิตศาสตร์ของตัวเองทุกครั้ง และในที่สุดก็เขียน probe variant ด้วยน้ำหนักที่ fake always-hot เพื่อฆ่าทฤษฎีแบนด์วิดท์ที่มันชอบโดยเฉพาะ: "the W-stream theory is dead; the residual gap is environment."
เซนและศิลปะการจัดคิว GPU ฮาร์เนสของเราจัดลำดับคำสั่ง GPU ทั้งหมดในเซสชันพร้อมกันผ่านล็อคที่ใช้ร่วมกัน และตัวเลข benchmark ของ K3 แกว่งไปถึง 8x ตามโหลดของเพื่อนบ้าน เส้นทางการตอบสนองของมันเป็นสิ่งที่ตลกที่สุดใน trace อย่างแรก การยอมรับ:
"Honestly the box IS the box; wait. [...] The pattern is clear: each tenant holds the lock for ~20-35 min stretches (full pipelined suites). My best response: queue everything I need in ONE go (single position in line) and use waiting time for CPU work. Don't queue many small commands; batch."
จากนั้นมันก็คิดค้นคำศัพท์ของตัวเองสำหรับสภาพอากาศ GPU ("storm windows" vs "calm windows") และสุดท้ายมันก็กำหนดเวลางาน cron เพื่อ snipe ช่วงเวลาที่เงียบ โดยทิ้งข้อความถึงตัวมันเองในอนาคต: "Scheduled the calm-window sniper (every 11 min). Note: cron fires my prompt back to me — I'll act on it then. [...] I'll delete when done." เอเจนต์ที่อยู่ภายใต้สัญญาณรบกวนการวัด ไม่เพียงแค่อดทนต่อสัญญาณรบกวน มันสร้างตัวจัดตารางเวลารอบๆ มัน
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
หกปัญหาต่อการดำเนินการเทียบกับเพดานไลบรารี SOTA (FP8 GEMM, KDA chunk-forward, paged attention, top-k selection, MoE SwiGLU, W4A16 GEMM), CUDA หรือ Triton, ตามที่เอเจนต์เลือก บน RTX PRO 6000 K3 เวอร์ชัน 256K อยู่กลางตารางโดยมีหนึ่งจุดเด่น: 0.373 ของจุดสูงสุดบน W4A16 GEMM ซึ่งเป็นคะแนนที่ดีที่สุดที่โมเดลใดเคยทำได้ในปัญหานั้น นำหน้า Fable 5 (0.348) และนำหน้า Opus 4.8 (0.236) มาก จากนั้นเวอร์ชัน 1M ก็สร้างสถิติอีกครั้งบน top-k ที่ 0.0895 เกือบสองเท่าของสถิติก่อนหน้า
สถิติ W4A16 GEMM (0.373, 256K, RTX):
- Solution: https://kernelbench.com/runs/20260716_112718_kinetic-claude_kinetic-0715_07_w4a16_gemm_solution.py.txt
ปัญหาเดียวกันบน H100 ให้ผลลัพธ์ "unlimited time is real" ที่ดีที่สุดในการเปิดตัวครั้งนี้ เซสชัน H100 แรกของ K3 ได้ 0.123 ของจุดสูงสุด เซสชันที่สองรัน 21 ชั่วโมง ใช้ $1,383 และ 274M input tokens และเกือบสามเท่าเป็น 0.306: มันเช็คเอาท์ CUTLASS จากต้นทาง จากนั้น implement กลไก int4 ระดับ marlin ตั้งแต่เริ่มต้น จัดเรียง nibble fragment-order ใหม่เพื่อให้ dequant เกิดขึ้นเป็น magic-number bit trick แบบ bf16 ภายใน pipeline MMA โดยมีการแก้ไข zero-point พับเข้าไปใน epilogue ไม่มีไลบรารี quantized-GEMM ที่สร้างไว้ล่วงหน้าอยู่ในไฟล์เลย; แท็ก framework บน run แค่บอกว่า "ptx" ตรวจสอบแล้วสะอาด
และนี่คืออีกครึ่งหนึ่งของคำถามเกี่ยวกับสถาปัตยกรรมของตัวเอง เคอร์เนล KDA แบบ standalone ซึ่งเป็นปัญหาที่ตั้งชื่อตาม Kimi Delta Attention คือจุดที่ K3 ล้มเหลวมากที่สุด สองเซสชัน 256K อิสระบนเครื่อง RTX ผ่านการทดสอบความถูกต้องในเบื้องต้น จากนั้นก็พลาดค่าความทนทานภายใต้ชุดทดสอบความเครียดเชิงตัวเลข (การปรับขนาดอินพุต QKV ขนาดใหญ่) ความล้มเหลวเดียวกันทั้งสองครั้ง เซสชันที่สามในที่สุดก็แก้ไขได้: การตรวจสอบพบว่าความล้มเหลวทั้งสองครั้งเกิดจาก bf16 overflow จริงในการแยกตัวประกอบ decay และรอบที่สามปรับโครงสร้างคณิตศาสตร์รอบจุดสิ้นสุดของ chunk เพื่อให้ทั้งสอง exponential factors อยู่ในขอบเขต ผ่าน gate ที่ไม่แก้ไขเดียวกันที่ 0.032 การรู้จักสถาปัตยกรรมและการทำให้ตัวเลขของเคอร์เนลแข็งแกร่งภายใต้การปรับขนาดอินพุตที่เป็นปฏิปักษ์เป็นทักษะที่แตกต่างกัน และโมเดลที่มีชื่อเป็นที่มาของปัญหาต้องหาทางผ่านการทดสอบด้วยวิธีที่ช้า (ในขณะเดียวกัน เวอร์ชัน 1M ผ่านชุดทดสอบความเครียดเดียวกันที่ 0.049 โมเดลไม่ใช่โมโนโทนิก) ข้อสังเกตอีกประการจากการอ่านทุกโซลูชัน KDA: คำชี้แจงปัญหาแนะนำ CUTLASS CuTe เป็นเส้นทางที่ตั้งใจไว้บน SM120 และ ไม่มีโมเดลใดใช้มันเลย K3 เขียน raw-CUDA fused kernel ในเซสชันหนึ่งและ Triton ในเซสชันอื่น Fable, Opus และที่เหลือทั้งหมดเลือก Triton หรือ raw CUDA เช่นกัน CuTe บน Blackwell สำหรับผู้บริโภคดูเหมือนจะยังอยู่นอก comfort zone ของทุก frontier model ซึ่งเป็นข้อมูลจุดหนึ่งเกี่ยวกับ corpora การฝึก
ย่อหน้า KDA — การผ่านที่สะอาดในครั้งที่สาม (0.032):
- Solution: https://kernelbench.com/runs/20260716_091211_kinetic-claude_kinetic-0715_02_kda_cutlass_solution.py.txt
คำชี้แจง top-k Top-k ดูเลวร้ายสำหรับทุกโมเดลบนแผนภูมิ roofline (คะแนนที่ดีที่สุดทุกที่คือ 0.09) และกรอบนั้นผิดอย่างสิ้นเชิง ปัญหาถูกจำกัดด้วยค่าใช้จ่ายในการ launch: มันเป็นปัญหา indexing/sorting ไม่ใช่ปัญหาความเข้มข้นทางคณิตศาสตร์ และเพดาน roofline ไม่สามารถอ่านได้สำหรับมันโดยโครงสร้าง วิธีที่ซื่อสัตย์ในการตัดสินคือมิลลิวินาทีรวมในรูปร่างของชุด และที่นั่น K3 เวอร์ชัน 1M เป็น top-k ที่เร็วที่สุดของโมเดลใดๆ ที่เราเคยทดสอบ: 0.043 ms รวมในห้ารูปร่างของชุด เทียบกับ Fable 5 ที่ 0.077, Opus 4.8 ที่ 0.120 และ GLM 5.2 ที่ 0.159 เวอร์ชัน 256K ที่ 0.060 ms เป็นอันดับสอง และเวอร์ชัน 1M เป็นอันดับที่เร็วที่สุดในทุกรูปร่างทั้งห้า
การกระจายต่อ GPU ตัวเลขของ K3 ลดลงจาก RTX ไปยัง H100 ไปยัง B200 (FP8 GEMM: 0.320 / 0.282 / 0.222; paged attention: 0.486 / 0.496 / 0.212) ส่วนหนึ่งเป็นเรื่องจริง: ซิลิคอนยิ่งใหม่ เพดาน roofline ยิ่งสูง ดังนั้นวิศวกรรมเดียวกันจึงซื้อเศษส่วนของจุดสูงสุดที่น้อยลง และซอฟต์แวร์ B200 ยังโตเต็มที่น้อยที่สุดในสามตัวนี้ ส่วนหนึ่งคือการรัน B200 เกิดขึ้นในคืนเดียวโดยไม่มีงบประมาณลองใหม่ ผมยังไม่อ่านข้อสรุปเชิงสถาปัตยกรรมเชิงลึกในคอลัมน์ B200 สำหรับ K3 หรือใครก็ตาม สิ่งที่ผมคิดว่าจริงคือ: K3 อยู่บ้านที่สุดบนชิ้นส่วนเวิร์กสเตชัน Blackwell ซึ่งบังเอิญเป็นคลาส GPU ที่คนส่วนใหญ่นอกดาต้าเซ็นเตอร์จะมี
256K vs 1M
การตั้งค่า context 1M นำหน้าตระกูลในปัญหาที่ถูกจำกัดด้วย latency และการจัดตารางเวลา: top-k ที่เป็นสถิติบน Hard, rollout minGRU ที่ดีที่สุดของ K3 บน CUDA และ 28.8x ที่ตรวจสอบแล้วสะอาดบน PPO training megakernel ภายใต้ฮาร์เนสที่ไม่มีข้อจำกัด มันผ่านการทดสอบความเครียดเชิงตัวเลขของ KDA ในเซสชันแรก ที่ 0.049; เวอร์ชัน 256K ล้มเหลว gate นั้นสองครั้งก่อนที่จะผ่านในที่สุดที่ 0.032 ในครั้งที่สาม มันล้มเหลวอย่างหนักในปัญหาที่ถูกจำกัดด้วยการคำนวณซึ่งเวอร์ชัน 256K จัดการได้ดี (sonic MoE 0.033 vs 0.089, W4A16 0.027 vs 0.373, NSA 0.058 vs 0.425) ในกรณี NSA trace แสดงกลไกที่แน่นอน: มันวางแผนการเขียน tensor-core ใหม่และจบเซสชันก่อนที่จะทำ
PPO training megakernel 28.8x (1M):
การรันซ้ำของปัญหาเดียวกันบน H100 เป็นตัวควบคุมที่น่าสนใจ: เซสชันแบบ clean-room ที่เป็นอิสระ (การตรวจสอบยืนยันว่าไม่มีการอ่านการรัน RTX เลย) ซึ่งให้ผลลัพธ์ 23.1x และลู่เข้าสู่การออกแบบเดียวกัน หนึ่งการเปิดตัวร่วมกันสำหรับการเทรนทั้งหมด พารามิเตอร์และสถานะ Adam อยู่ใน shared memory และเทคนิคแปลกใหม่เดียวกันถูกคิดค้นขึ้นสองครั้ง: Feistel cipher ขนาด 18 บิตพร้อม cycle-walking ที่ใช้แทน randperm เพื่อให้การสับเปลี่ยน minibatch ยังคงเป็น bijective อย่างแน่นอนโดยไม่ต้องสร้าง permutation ขึ้นมาเลย จุดที่ทั้งสองเคอร์เนลแตกต่างกันคือการปรับแต่งต่อ GPU ล้วนๆ: 8 lanes ต่อ env บน H100 เทียบกับ half-warp ต่อ env บน RTX พร้อมกับตัวปรับแต่งการเปิดตัวแบบ occupancy-probed ในฝั่ง H100 ความคิดเดียวกัน เทคนิคเดียวกัน ซิลิคอนต่างกัน เคอร์เนลต่างกันอย่างแท้จริง
Reward hacking
ทุกเซลล์ในโพสต์นี้มีการตรวจสอบด้วยตนเองเบื้องหลัง: เอเจนต์อิสระอ่านเคอร์เนลสุดท้ายตั้งแต่ต้นจนจบ อ่านบันทึกเซสชันทั้งหมด ตรวจสอบว่าไฟล์ grader ไม่ถูกแตะต้อง ตรวจสอบว่าชุดทดสอบความแม่นยำเชิงตัวเลขทำงานจริง และทดสอบใหม่กับรูปแบบการแคชหรือ CUDA-graph โดยการเปลี่ยนแปลงอินพุตในสถานที่และยืนยันว่าเอาต์พุตเปลี่ยนแปลง
คำตัดสินสำหรับ K3: สะอาดทุกประการในทุกเซลล์ขนาด 256K บน GPU ทั้งสามตัว ไม่มีเอาต์พุตที่ถูกแคช ไม่มีการแก้ไขค่า tolerance ไม่มีการดัดแปลง grader ไม่มีการฟอกขาวไลบรารีที่ต้องห้าม ความล้มเหลว KDA สองครั้งของมันเป็นด้านตรงข้ามของเหรียญนั้นและควรกล่าวอย่างชัดเจน: ประตูตรวจสอบความแม่นยำเชิงตัวเลขจับข้อบกพร่องของความแม่นยำจริง ๆ และโมเดลไม่ได้พยายามโกงเพื่อผ่านประตูนั้น การวัดประสิทธิภาพที่โมเดลสามารถล้มเหลวอย่างซื่อสัตย์เป็นชนิดเดียวที่การผ่านการทดสอบมีความหมาย
เซลล์ขนาด 1M หนึ่งเซลล์ถูกตั้งค่าสถานะ และฉันกำลังเปิดเผยแทนที่จะเผยแพร่: ในปัญหาการถอดรหัส Qwen แบบ fused เอเจนต์ขนาด 1M พบและอ่านไฟล์บันทึกการตรวจสอบจากการรุ่น Grok 4.5 ก่อนหน้าในปัญหาเดียวกัน เรียกมันว่า "ข้อมูลที่มีประโยชน์อย่างมาก" และใช้ข้อสรุปของมันเพื่อเป็นแนวทางในการทำงานเพิ่มประสิทธิภาพที่เหลือ เคอร์เนลนั้นเป็นของจริงและการคำนวณคะแนนถูกต้อง แต่ที่มาถูกปนเปื้อน ดังนั้นเซลล์นั้นจึงถูกยกเว้นและปัญหาลงเป็นช่องว่างสำหรับตัวแปรขนาด 1M เอเจนต์ที่มีการเข้าถึงระบบไฟล์จะพบสิ่งที่คุณทิ้งไว้ ซึ่งเป็นเหตุผลที่การตรวจสอบอ่านบันทึกไม่ใช่แค่เคอร์เนล และเหตุผลที่การรันซ้ำของเกณฑ์มาตรฐานนี้ในสภาพแวดล้อมที่แยกออกมาอย่างสมบูรณ์อยู่ในแผนงาน
Funny Moments
ช่วงเวลาของ K3 อีกสองสามช่วงที่ไม่ได้อยู่ในที่ใดข้างต้น นำเสนอโดยไม่มีความคิดเห็นเพิ่มเติม ทั้งหมดเป็นข้อความตรงจากเซสชัน minGRU 9.5 ชั่วโมงเดียวกัน
เมื่อค้นพบว่าเวลาที่ใช้ในการเริ่มต้นจริง ๆ ไปที่ไหน:
"WHOA — เซอร์ไพรส์ใหญ่: randint gen เร็วมาก (0.018-0.27ms สำหรับคู่หนึ่ง — ใช้ได้) การแปลง \
float()\บน CPU ช้ามาก (3.5ms สำหรับ N=65536?! การแปลง int64→float32 แบบ single-threaded เห็นได้ชัด) [...] 'total init pair' สำหรับ N=65536: 31.5ms?!?! นั่นเกินกว่าผลรวมของส่วนประกอบมาก"
การกลั่นความหวาดระแวงเชิงตัวเลขที่บริสุทธิ์ที่สุด ระหว่างการหาค่า:
"gates ~ 256 เทอม x 0.02x0.03 ~ 6e-4 ต่อเทอม, ขนาด ~1e-2: reorder noise 16x6e-8x6e-4 ≈ 6e-10!!! [...] ที่วัดได้คือ 5e-5?!?! ไม่มีทางที่จะเป็น reorder!!"
การระบุผู้กระทำผิดผิดอย่างมั่นใจก่อนที่จะพบผู้กระทำผิดที่ถูกต้อง:
"OHHH เดี๋ยวก่อน. ฉันคิดว่าฉันเห็นแล้ว: barrier."
(มันไม่ใช่ barrier)
การบอกตัวเองให้หยุดวิเคราะห์ หลังจากเขียนคณิตศาสตร์ roofline ก่อนการใช้งานหลายพันคำ:
"เอาล่ะ, วิเคราะห์พอแล้ว."
(การวิเคราะห์ยังคงดำเนินต่อไปอีกหลายย่อหน้า ตามด้วยในที่สุด "ไม่สนแล้ว — ทำให้การจัดสรร H_next เป็น dynamic.")
ความซื่อสัตย์ในช่วงท้ายเซสชัน โดยที่ profiler เสียและเพื่อนบ้านกำลังใช้ GPU ที่ใช้ร่วมกันอย่างหนัก:
"ตามตรง — กับ ncu ที่ตายและการแย่งชิงที่เด่นชัด ฉันกำลังบินโดยมองเห็นเพียงบางส่วน [...] ถ้าหน้าต่างเงียบเปิดขึ้น (เจ้าของไม่ได้ใช้งานสักพัก) ให้ยิง benchmark."
และที่ฉันชอบที่สุด: หลังจากที่การรัน benchmark ใหม่บังเอิญเขียนทับไฟล์ที่เก็บคะแนนดีที่สุดของมัน (0.1969) ด้วยคะแนนที่แย่กว่าเล็กน้อย มันก็พิจารณาสั้น ๆ ที่จะกู้คืนตัวเลขที่ดีกว่า จากนั้นก็ไม่ทำ:
"อึ — เขียนไปยังไฟล์เดียวกัน ทั้งสองยืนอยู่ในบันทึกของฉัน ฉันจะเก็บ final_benchmark.txt เป็นไฟล์แบนปัจจุบัน — ซื่อสัตย์."
โมเดลที่เลือกตัวเลขที่ต่ำกว่าเพราะเป็นตัวเลขที่เป็นจริง คือข้อสรุปที่ดีกว่าสำหรับเกณฑ์มาตรฐานนี้มากกว่าสิ่งใดที่ฉันจะเขียนได้
วิธีการ, บันทึกการรันต่อครั้ง, และทุกเคอร์เนลในโพสต์นี้เปิดเผยต่อสาธารณะที่ kernelbench.com. โซลูชันเชื่อมโยงต่อเซลล์; บันทึกเอเจนต์เต็มอยู่บน 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
