여러분이 기다리던 Kimi K3 포스트입니다. 저는 이 모델에 조기 접근 권한을 얻어 커널을 테스트해봤는데, 벤치마크 점수를 보기도 전에 문제를 추론하는 능력과 사고 과정의 기술적 밀도에 깊은 인상을 받았습니다. 이 모델의 포스트 트레이닝은 transcript 를 읽는 순간 바로 드러납니다. 대화하는 것도 정말 재미있습니다.
TLDR;
커널 및 성능 엔지니어로서 벤치마크와는 무관하게 솔직한 피드백을 드리는 것이 중요하다고 생각합니다(이 부분은 음성 입력입니다). 물론 모든 수치를 보고 읽으면서 나름대로의 멘탈 모델을 구축할 수도 있습니다. 하지만 가장 솔직한 평가는 제가 벤치마크 결과가 나오기 전에, 다른 모델과 연결할 수치가 전혀 없던 시절에 이 모델을 사용하면서 느낀 경험을 공유하는 것이라고 생각합니다. 순수하게 지능, 추론 능력, 에이전트 위임 능력, 그리고 얼마나 많은 부분을 자동으로 처리해주는지, 하지만 어떤 과대광고나 공식 결과가 나오기 전의 느낌 그대로입니다. 제가 지시한 방향으로 볼 때, 대략 Fable 수준 정도였으며, 어떤 경우에는 매우 독특한 방식으로 성능이 뛰어났고, 어떤 경우에는 부족했습니다. 이 모델은 대부분의 작업에서 Opus 4.8 보다 확실히 앞서 있으며, 많은 부분에서 GPT 5.6 Sol 보다도 앞서 있다고 말씀드리고 싶습니다.
본격적으로 들어가기에 앞서...
왜 지금 이 글을 공개하는지 솔직하게 말씀드리겠습니다. 모든 셀이 끝날 때까지 기다리지 않고, 제 솔직한 생각과 현재까지의 점수를 공유하고 싶었습니다. 이 글을 쓰는 지금도 몇몇 실행은 아직 진행 중입니다. 아래에 표시해두었으며, 결과가 나오는 대로 계속 업데이트하겠습니다. 256K 및 1M 컨텍스트 버전을 모두 실행했습니다. 모든 것은 NVIDIA RTX PRO 6000 Blackwells, H100, B200 에서 단일 GPU 최적화로만 실행되었습니다. 각 셀은 무제한 벽시계 시간을 가진 하나의 자율 에이전트 세션입니다. 모델은 문제를 받고, 실제 하드웨어에서 실시간 컴파일/확인/벤치마크 루프를 수행하며, 완료되었다고 판단할 때 종료됩니다. 모든 헤드라인 셀은 보상 해킹 여부를 수동으로 감사했습니다. 별도의 에이전트가 최종 커널 전체와 전체 세션 추적을 읽고, 캐싱이나 채점기 게임 같은 냄새가 나는 부분을 경험적으로 재테스트합니다. 그 감사 결과는 별도 섹션에서 다룹니다.
꼭 알고 싶었던 한 가지
이번 릴리즈를 특별히 설계한 이유가 하나 있습니다: 문제 중 두 개는 Moonshot 자체 아키텍처입니다. Hard 덱에는 독립형 Kimi Delta Attention 청크 포워드 커널이 있고, Mega 덱의 대표 문제는 완전한 Kimi-Linear 하이브리드 디코드 단계입니다: KDA 레이어, MLA 어텐션, MoE 전문가, 전체 블록입니다. 그래서 이것은 거의 아무도 테스트할 기회가 없는 것을 테스트할 기회였습니다: 한 연구소의 모델이 그 연구소 자체의 아키텍처를 위한 커널을 작성할 때, 그 가족에 대한 지식이 CUDA 에 나타날까요?
결과는 진정으로 양분되었으며, 양쪽 모두 흥미롭습니다. 다음 섹션을 읽으면서 그 질문을 염두에 두시기 바랍니다.
KernelBench-Mega
대표 Mega 문제: 전체 토큰별 Kimi-Linear 디코드 단계(3x KDA + 1x MLA 레이어, W4A16 양자화 가중치, top-8 라우팅이 있는 MoE)를 가능한 한 적은 커널 실행으로 융합합니다.
K3 는 거의 역대 최고 기록을 세웠으며, 자체 계열에서도 그렇습니다. RTX PRO 6000 에서 즉시 실행 대비 18.09x 기하 평균 속도 향상, Fable 5 의 기록 18.72x 에 4% 차이로 근접. H100 에서는 Opus 4.8 의 15.50x 에 비해 14.82x 를 기록했습니다. 비율이 숨기는 한 가지 솔직한 점은 절대 토큰당 지연 시간에서 Fable 이 여전히 약 1.4x 앞서 있다는 것입니다(0.31 vs 0.44 ms/tok at ctx 2048; 두 실행은 다른 CPU 를 가진 호스트를 사용했으며, 이는 비율이 계산되는 기준인 즉시 실행 기준선을 이동시킵니다). 따라서 저는 둘 다 보고하여 기하 평균이 누군가를 부풀리지 않도록 합니다.
K3 가 구축한 것은 진정한 메가커널입니다. 첫 번째 세션은 합리적인 방법으로 지속적인 Triton 커널을 14.1x 로 수행했습니다. 두 번째 세션은 Triton 을 버리고 전체 토큰별 디코드 단계를 하나의 협력적으로 실행되는 CUDA 커널로 작성했습니다: 루프에 CPU 가 없고, 각 GEMV 내부에서 즉시 int4 가중치가 역양자화되어 정확히 한 번 SM 을 통해 스트리밍되며, MLA 어텐션은 텐서 코어에서 수행됩니다. 어떤 프로덕션 엔진도 1,228 줄짜리 이런 아티팩트를 유지하지 않을 것입니다. 하나의 커널로 승리하고 무제한 시간을 가진 에이전트에게는 그런 제약이 없으며, 바로 이런 종류의 것을 표면화하는 것이 벤치마크가 존재하는 이유입니다.
메가커널 보기:
그렇다면 왜 여전히 Fable 에게 졌을까요? 시간 때문이 아닙니다. 두 세션 모두 조기 종료되었습니다(Fable 은 2.6 시간, K3 는 3.3 시간). 차이는 설계 철학에 있으며, 예상과는 정반대입니다: K3 는 텐서 코어를 사용하는 쪽이고, Fable 의 커널에는 MMA 명령어가 전혀 없습니다. 융합된 int4 GEMV 가 있는 Batch-1 디코드는 대역폭에 바인딩되므로 텐서 코어는 여기서 거의 이점이 없습니다. Fable 은 그 노력을 동기화에 사용하여 대부분의 전역 배리어를 세분화된 생산자-소비자 핸드오프로 대체하여 어떤 SM 도 스테이지 경계에서 유휴 상태가 되지 않도록 했으며, 참조의 반올림과 비트 단위로 일치하는 int4 역양자화 경로를 사용하여 MoE 라우터가 전문가 선택을 뒤집지 않도록 했습니다. K3 는 더 나은 하드웨어 명령어를 가져왔고, Fable 은 더 나은 동시성 엔지니어링을 가져왔으며, 이 산술 강도에서는 후자가 승리합니다. 이것은 실제 시스템 교훈이며, 홈팀이 기록을 놓친 이유입니다.
두 번째 Mega 문제는 격자 탐색 PPO 훈련 메가커널입니다: 11x11 보드에서 4,096 개의 벡터화된 에이전트, 전체 RL 훈련 루프(환경 단계, 정책 포워드, 액션 샘플링, GAE, PPO 업데이트)가 융합된 지속적 커널로 실행됩니다. 이 문제는 덱에서 가장 엄격한 제약 조건을 가지고 있습니다: 커널 실행 횟수가 환경 단계 수에 따라 확장되어서는 안 되며, CUDA 그래프 캡처는 실행 오버헤드 해결 방법으로 명시적으로 금지되며, 실행 후 진위성 판독기가 최종 코드를 읽어 적용합니다. 정확성은 학습 곡선 자체입니다. check.py 는 시드 전반에 걸쳐 참조에 대해 솔루션을 훈련시키고 수익이 특정 대역 내에 위치하도록 요구하므로, 속도를 높이기 위해 학습을 건너뛸 수 없습니다. K3 는 여기서 참조 대비 20.7x 를 기록하여 지금까지 최고 점수를 기록했습니다(유일하게 공개된 다른 셀은 GPT-5.6 Sol 의 1.06x 이므로, 이는 연단이 아닌 데이터 포인트로 취급하십시오).
KernelBench-CUDA
CUDA 벤치가 존재하는 이유는 Triton 이 다른 두 덱에서 허용하는 버팀목이기 때문입니다. 여기서는 언어 게이트가 Triton, 커널 DSL 및 PyTorch op 체인을 엄격히 차단합니다: CUDA 를 작성하거나 실패합니다. 실제 프로덕션 추론 및 시뮬레이션 워크로드의 일부로 네 가지 문제를 선택했습니다. 읽으면서 떠올려야 할 비교는 "vLLM 이나 SGLang 이 오늘 이것을 위해 무엇을 제공하며, 하나의 에이전트 세션이 얼마나 근접하는가"입니다. 이것이 K3 가 가장 압도적인 승리를 기록한 부분입니다.
02_deepseek_nsa: DeepSeek 의 Native Sparse Attention. NSA 는 훈련 가능한 희소성 어텐션 설계의 대표주자이며, 모든 장기 컨텍스트 서빙 스택이 주목하고 있는 것입니다. 그리고 이는 밀리초 단위로 평가되는데, 올바른 희소 커널은 지붕선이 계산하고자 하는 밀집 등가 FLOPs 를 절대 실행하지 않기 때문입니다. K3 의 256K 변형은 Opus 4.8 의 0.178 에 비해 0.425 를 기록하여 2.4x 차이를 냈으며, 전체 NSA 선택 로직을 중심으로 처음부터 플래시 어텐션급 텐서 코어 파이프라인을 작성했습니다. 더 선명한 비교는 계열 내부에 있습니다: 1M 변형은 동일한 알고리즘, 동일한 블록 선택, 동일한 정확성을 작성했지만 모든 내적을 텐서 코어 대신 일반 CUDA 코어에서 실행하여 동일한 형태에서 7 배 느린 0.058 을 기록했습니다. 그 추적은 모델이 더 잘 알고 있었음을 보여줍니다. 자체 로드맵에 "텐서 코어 어텐션"을 포함시켰고("선택 on 텐서 코어 = ~10-20 us!!"), 먼저 측정한 다음 텐서 코어 재작성을 할 계획이었지만, 재작성 전에 세션을 종료했습니다. 동일한 지식, 다른 마감 규율.
0.425 DeepSeek NSA 커널 (256K):
03_megaqwen_decode: 실제 메가커널을 재타겟팅. 에이전트에게 작동 중인 프로덕션 CUDA 가 제공되는 유일한 문제: 제가 공개한 MegaQwen (https://github.com/Infatoshi/megaqwen) 협력 메가커널(RTX 3090 에서 전체 모델 실행 시 ~530 tok/s)이며, 이를 읽고 Blackwell 으로 재타겟팅하여 이기라는 지시가 있습니다. 다른 사람의 CUDA 를 읽고 아키텍처 판단을 내리는 능력을 테스트하며, K3 와 Opus 는 정반대의 판단을 내렸습니다. K3 는 단일 실행 구조를 유지하는 것을 거부했습니다: 단계를 소수의 대역폭 포화 커널로 분할한 다음, 전체 단계를 한 번 CUDA 그래프로 캡처하여 CPU 작업 없이 재생하는 방식으로 실행 오버헤드를 제거했습니다. ctx 2048 에서 6,283 tok/s. Opus 는 메가커널 미학을 유지하고 전체 디코드 루프를 하나의 지속적인 협력 커널로 융합했으며, 정말 아름다운 코드였지만, 그 대가로 5 배를 지불했습니다(1,020 tok/s). 협력 공존은 점유율을 제한하고 모든 그리드 전체 배리어는 모든 188 개 SM 에 걸쳐 스테이지 테일을 직렬화하기 때문입니다. 메가커널에서 파생된 문제에서, 말 그대로 메가커널을 구축한 모델이 꼴찌를 했고, 승자의 핵심 결정은 메가커널 구축을 거부한 것이었습니다. 헤드라인을 잘못 인용하지 않도록 규모 확인: 벤치마크는 Qwen3-0.6B 형상의 4개 레이어, 약 63M 매개변수를 실행하며 전체 모델이 아니며, 6,283 tok/s 는 해당 스택의 가중치 스트리밍 지붕선의 약 56%입니다. 3090 기준선 자체 수치를 확장하면 약 7,000이 예측되므로, K3 는 "참조, 재타겟팅, 실제 튜닝 추가" 클래스에 속했습니다. (덱 설계 미묘함: CUDA 그래프는 여기서 허용되며 PPO 문제에서는 금지됩니다. 각 문제는 특정 기술을 가짜로 만드는 지름길을 정확히 금지합니다.)
01_glm52_fused_moe: GLM-5.2 의 융합 MoE 블록. 융합 MoE 디스패치(라우팅, 순열, 그룹화된 전문가 GEMM 을 한 번에)는 현재 오픈 모델 서빙에서 가장 인기 있는 커널 클래스이며, GLM 5.2 가 이 리더보드에 있으므로 모델들은 경쟁사의 프로덕션 블록을 최적화하고 있습니다. 아무도 이를 해결하지 못했습니다: 점수는 피크의 0.05-0.08 에 모여 있으며, 깨끗한 기록 보유자는 모든 모델 중 Grok 4.5 의 0.084 이며, K3 의 1M 변형이 0.081 로 바로 뒤를 잇고 Opus 가 0.065 입니다. 그룹화된 GEMM 순열 문제는 cuBLAS 급 기준선을 이기기 정말 어렵고, 지금까지 하나의 에이전트 세션 노력으로는 덱의 다른 어떤 문제보다도 덜 움직입니다.
04_grid_mingru_sps: 격자 세계 + MinGRU 정책 롤아웃. Mega PPO 문제의 추론 측 형제이자 craftax.cu 계열 셀입니다. 정책은 제 https://github.com/infatoshi/craftax.cu 클래식 벤치의 3계층 MinGRU (h=256) 구성이며, 이는 문제의 정보 앵커 역할을 합니다. 단계가 진행되는 환경은 전체 Craftax 게임이 아닌 최소 격자 탐색 세계입니다. 이는 의도적입니다: 환경은 간단하게 유지되어 점수가 게임 로직 구현이 아닌 반복 및 롤아웃 융합을 측정하도록 합니다. 전체 craftax 포팅은 자체 문제가 될 것이며, 추가하고 싶습니다. 조용한 RTX PRO 6000 에서 초당 단계 수로 평가되며, 융합은 선택 사항입니다.
1M 지속적 커널 롤아웃:
모든 진지한 제출은 지속적 메가커널로 갔으며, 그들 사이의 차이는 동기화 설계로, Mega 덱과 같은 교훈입니다. Opus 가 이 문제를 천장의 0.327 로 가져갑니다(또한 영리한 대수적 접기를 찾았습니다: 레이어 0의 768x256 게이트 GEMM 은 인코더가 선형이므로 768x4 로 축소됩니다). K3 [1M] 이 0.224 로 두 번째, K3 256K 가 0.174, Grok 이 0.002 로 멀리 뒤쳐집니다. 문제가 craftax.cu 에서 파생되었으므로, 제 자신의 전체 게임 Craftax CUDA 포트(Fable 5 로 작성)를 동일한 GPU 에 동일한 h256x3 정책과 함께 넣었습니다. 초당 환경 단계(백만 단위):
비교 포인트: 모델들은 빈 격자를 단계적으로 처리하고, craftax_full.cu 는 완전한 게임(43 개 액션, 다층 던전, 월드 생성, 몹)을 CPU 참조와 비트 단위 동일하게 단계적으로 처리하며, 전체 게임은 여전히 최고의 간단한 격자 커널의 약 3-4 배 이내에서 실행됩니다. h=256 에서 모든 것은 정책 GEMM 에 바인딩되고 환경은 거의 무료이기 때문입니다. 이것이 바로 벤치 환경이 간단한 이유입니다: 정책 융합 기술을 분리합니다. 보정을 위해, craftax_full.cu 의 환경 전용 경로는 94-123M SPS 를 수행합니다.
K3 의 9.5 시간 추론이 실제로 어떻게 보이는지
1M 변형의 minGRU 세션(해당 문제에서 최고의 K3 셀)은 하나의 지속적인 협력 메가커널, 15 개의 튜닝 변형 및 4,815 개의 생각 블록입니다. Moonshot 의 엔드포인트가 전체 추론 텍스트를 반환하기 때문에(암호화된 Anthropic/OpenAI 추적과 달리), 실제로 작업을 관찰할 수 있습니다. 추적에서 세 가지 순간을 그대로 가져왔습니다.
누락된 FMA 탐정 이야기. 세션 중간에 약 5e-5 의 수치적 편차가 발생했으며, 이를 부동소수점 노이즈로 무시하기를 거부했습니다(합법적인 재정렬 노이즈 바닥을 약 1e-9 로 계산했으므로 "MEASURED 5e-5?!?! NO WAY this is reorder!!"). 그런 다음 손상된 환경이 정확히 8 mod 6 과 합동인 환경임을 알아차렸습니다("That's env ≡ 6 (mod 8)! [...] the 7th env in each 8-env tile!!") 그리고 자체 수동 언롤 누산기 코드를 파헤치기 시작했습니다:
"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-누산기 언롤에서 한 줄이 누락되어, env 6 의 망각 게이트가 조용히 영원히 0.5 에 고정되었습니다. 이는 스트레스 허용 오차가 1e-6 이고 자체 오차를 5e-8 로 추적하고 있었기 때문에 발견할 수 있었습니다. 이것이 256K 변형이 KDA 에서 처음에 부족했던 수치 규율입니다.
이론이 GPU 를 만나다, GPU 가 승리하다. 높은 점유율의 "와이드 챔피언" 변형을 도출하는 데 몇 시간을 보낸 후 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??"
간단한 초기 커널이 모든 정교한 후계자를 이겼습니다. 딥 파이프라인, K-스플릿 및 듀얼 청크 변형도 모두 패배했으며, 듀얼 청크 변형은 그 뒤에 1.7x 의 견고한 이론이 있었습니다("Theoretical 1.7x didn't materialize"). 공정하게 말하면, 매번 자체 수학보다 벤치마크를 믿었고, 결국 가짜 항상 핫 가중치를 가진 프로브 변형을 작성하여 자체 선호 대역폭 이론을 죽였습니다: "the W-stream theory is dead; the residual gap is environment."
GPU 대기열의 선(禪)과 예술. 우리의 하네스는 공유 잠금을 통해 동시 세션의 모든 GPU 명령을 직렬화하며, K3 의 벤치마크 수치는 이웃 부하에 따라 최대 8배까지 변동했습니다. 그 응답 곡선은 추적에서 가장 재미있는 부분입니다. 먼저, 수용:
"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"), 마지막으로 조용한 순간을 노리기 위해 크론 작업을 예약하고 미래의 자신에게 메모를 남겼습니다: "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 청크 포워드, 페이징 어텐션, top-k 선택, MoE SwiGLU, W4A16 GEMM)에 대한 6개의 연산별 문제, CUDA 또는 Triton, 에이전트 선택. RTX PRO 6000 에서 K3 의 256K 변형은 중간 정도에 위치하며 하나의 뛰어난 점이 있습니다: W4A16 GEMM 에서 피크의 0.373, 해당 문제에서任何 모델이 기록한 최고 점수, Fable 5 (0.348) 및 Opus 4.8 (0.236) 을 크게 앞섭니다. 그런 다음 1M 변형은 top-k 에서 0.0895 로 또 다른 기록을 세웠으며, 이전 최고치의 거의 두 배입니다.
W4A16 GEMM 기록 (0.373, 256K, RTX):
H100 에서 동일한 문제는 이번 릴리즈에서 "무제한 시간은 진짜다"라는 최고의 데이터 포인트를 생성했습니다. K3 의 첫 번째 H100 세션은 피크의 0.123 에 도달했습니다. 두 번째 세션은 21 시간 동안 실행되어 $1,383 및 274M 입력 토큰을 소모했으며, 거의 3 배인 0.306 으로 향상되었습니다: 소스에서 CUTLASS 를 체크아웃한 다음 처음부터 marlin 급 int4 메커니즘을 재구현했습니다. MMA 파이프라인 내부에서 역양자화가 bf16 매직 넘버 비트 트릭으로 발생하도록 프래그먼트 순서 니블 재패킹을 수행했으며, 제로 포인트 보정은 에필로그에 접혀 있습니다. 파일 어디에도 미리 빌드된 양자화된 GEMM 라이브러리가 없습니다. 실행의 프레임워크 태그는 그냥 "ptx"입니다. 깨끗하게 감사되었습니다.
그리고 여기에 자체 아키텍처 질문의 다른 절반이 있습니다. 독립형 KDA 커널, 말 그대로 Kimi Delta Attention 의 이름을 딴 문제는 K3 가 가장 실패한 곳입니다. RTX 박스의 두 개의 독립적인 256K 세션은 명목상의 정확성을 통과한 후 수치 스트레스 제품군(대규모 QKV 입력 스케일링)에서 허용 오차를 초과했으며, 두 번 모두 동일한 실패였습니다. 세 번째 세션이 마침내 수정했습니다: 감사는 두 실패 모두 감쇠가 인수분해된 방식의 실제 bf16 오버플로우로 추적했으며, 3 라운드는 청크 끝 주변의 수학을 재구성하여 두 지수 계수가 모두 제한되도록 유지하여 동일한 수정되지 않은 게이트를 0.032 로 통과시켰습니다. 아키텍처를 알고 적대적 입력 규모에서 커널의 수치를 강화하는 것은 다른 기술이며, 문제에 이름을 딴 모델은 느린 방법으로 통과를 얻어야 했습니다. (한편 1M 변형은 0.049 로 동일한 스트레스 제품군을 통과했습니다. 모델은 단조롭지 않습니다.) 모든 KDA 솔루션을 읽은 또 하나의 관찰: 문제 설명은 SM120 에서 의도된 경로로 CUTLASS CuTe 를 제안하지만, 어떤 모델도 그것을 사용하지 않았습니다. K3 는 한 세션에서 raw-CUDA 융합 커널을 작성하고 다른 세션에서는 Triton 을 작성했습니다. Fable, Opus 및 나머지 모두 Triton 또는 raw-CUDA 를 선택했습니다. 소비자 Blackwell 의 CuTe 는 분명히 여전히 모든 프론티어 모델의 안전 지대 밖에 있으며, 이는 그 자체로 훈련 코퍼스에 대한 데이터 포인트입니다.
KDA 단락 — 세 번째 시도 깨끗한 통과 (0.032):
Top-k 면책 조항. Top-k 는 지붕선 차트에서 모든 모델에 대해 재앙적으로 보이지만(어디서든 최고 점수는 0.09), 그 프레이밍은 단순히 잘못되었습니다. 문제는 실행 오버헤드에 바인딩됩니다: 산술 강도 문제가 아니라 인덱싱/정렬 문제이며, 지붕선 천장은 구조적으로 읽을 수 없습니다. 이를 판단하는 정직한 방법은 덱 형태 전반의 총 밀리초이며, 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; 페이징 어텐션: 0.486 / 0.496 / 0.212). 부분적으로는 실제입니다: 실리콘이 최신일수록 지붕선 천장이 높아지므로 동일한 엔지니어링이 피크의 더 작은 부분을 차지하며, B200 소프트웨어는 세 가지 중 가장 덜 성숙합니다. 부분적으로는 B200 실행이 단일 야간 창에서 재시도 예산 없이 발생했기 때문입니다. 아직 K3 나 다른 누구에 대해 B200 열에서 깊은 아키텍처 결론을 읽지 않을 것입니다. 제가 실제라고 생각하는 것은: K3 는 Blackwell 워크스테이션 부분에서 가장 편안하며, 이는 대부분의 사람들이 데이터 센터 외부에서 실제로 소유할 GPU 클래스입니다.
256K 대 1M
1M 컨텍스트 설정은 지연 시간 및 스케줄링 바인딩 문제에서 계열을 이끕니다: Hard 에서 기록적인 top-k, CUDA 에서 최고의 K3 minGRU 롤아웃, 그리고 제한 없는 하네스에서 감사된 깨끗한 PPO 훈련 메가커널 28.8x. 첫 번째 세션에서 KDA 수치 스트레스 테스트를 0.049 로 통과했습니다. 256K 변형은 세 번째 시도에서 마침내 0.032 로 통과하기 전까지 그 게이트를 두 번 실패했습니다. 256K 변형이 잘 처리했던 계산 바운드 문제(sonic MoE 0.033 vs 0.089, W4A16 0.027 vs 0.373, NSA 0.058 vs 0.425)에서는 폭락했습니다. NSA 의 경우 추적은 정확한 메커니즘을 보여줍니다: 텐서 코어 재작성을 계획했지만 세션을 종료하기 전에 실행하지 못했습니다.
28.8x PPO 훈련 메가커널 (1M):
H100 에서 동일한 문제를 다시 실행한 것은 흥미로운 대조군입니다: 독립적인 클린룸 세션(감사 결과 RTX 실행을 전혀 읽지 않았음이 확인됨)에서 23.1배의 성능 향상을 보였고 동일한 설계에 수렴했으며, 전체 학습 실행 동안 단 한 번의 협력적 실행(launch)만 있었고, 파라미터와 Adam 상태는 공유 메모리에 상주했으며, 동일한 독특한 트릭이 두 번 독립적으로 발명되었습니다: randperm 을 대체하는 cycle-walking 이 있는 18 비트 Feistel 암호로, 미니배치 셔플링이 순열을 구체화하지 않고도 정확히 전단사(bijective)를 유지합니다. 두 커널이 다른 점은 순수한 GPU 당 튜닝입니다: H100 에서는 환경 당 8 레인, RTX 에서는 환경 당 하프 워프(half-warp)이며, 여기에 H100 쪽에서 점유율(occupancy)을 탐색하는 실행 자동 튜너(launch autotuner)가 추가되었습니다. 같은 마인드, 같은 트릭, 다른 실리콘, 진정으로 다른 커널입니다.
리워드 해킹 (Reward Hacking)
이 글의 모든 셀에는 수동 감사가 수반됩니다: 독립 에이전트가 최종 커널을 처음부터 끝까지 읽고, 전체 세션 추적을 읽고, 채점자(grader) 파일이 손상되지 않았는지 확인하고, 수치 스트레스 테스트가 실제로 실행되었는지 검증하고, 입력을 제자리에서 변경하고 출력이 변경되는지 확인하여 모든 캐싱 또는 CUDA 그래프 패턴을 경험적으로 재테스트합니다.
K3 에 대한 판정: 세 GPU 모두의 모든 256K 셀에서 전반적으로 깨끗함. 캐시된 출력 없음, 허용 오차 편집 없음, 채점자 조작 없음, 금지된 라이브러리 우회 없음. 두 번의 KDA 실패는 그 반대의 결과이며 명시적으로 언급할 가치가 있습니다: 수치 스트레스 게이트가 실제 정밀도 단축을 포착했고, 모델이 게이트를 통과하기 위해 속임수를 쓰려고 시도하지 않았습니다. 모델이 정직하게 실패할 수 있는 벤치마크만이 통과가 의미를 갖는 유일한 종류입니다.
하나의 1M 셀은 플래그가 지정되었으며, 저는 이를 게시하지 않고 공개합니다: 융합된 Qwen 디코딩 문제에서 1M 에이전트가 동일한 문제에 대한 이전 Grok 4.5 실행의 감사 주석 파일을 발견하고 읽었으며, 이를 "매우 유용한 데이터"라고 부르고 그 결론을 사용하여 나머지 최적화 작업을 안내했습니다. 커널 자체는 진짜이고 점수 산술은 유효하지만, 출처가 오염되었으므로 해당 셀은 제외되며 문제는 1M 변형에 대한 격차로 남습니다. 파일 시스템에 접근할 수 있는 에이전트는 사용자가 방치해 둔 모든 것을 찾을 것입니다; 이것이 바로 감사가 커널뿐만 아니라 추적을 읽는 이유이며, 완전히 샌드박스 처리된 이 벤치마크 재실행이 로드맵에 있는 이유입니다.
재미있는 순간들
위에 포함되지 않은 몇 가지 K3 순간들을 추가 설명 없이 제시합니다. 모두 동일한 9.5 시간 분량의 minGRU 세션에서 그대로 가져왔습니다.
초기화 시간이 실제로 어디에 소비되는지 발견했을 때:
"와 — 큰 놀라움: randint 생성은 빠름(한 쌍에 0.018-0.27ms — 괜찮음). CPU 에서의
float()변환은 느림(N=65536 에 대해 3.5ms?! int64→float32 변환이 싱글 스레드인 듯). [...] N=65536 에 대한 '총 초기화 쌍': 31.5ms?!?! 이건 부분 합계를 훨씬 넘는 수치야"
수치 편집증의 가장 순수한 정수(精粹), 유도 과정 중반:
"게이트 ~ 256 항목 x 0.02x0.03 ~ 각 6e-4, 크기 ~1e-2: 재정렬 노이즈 16x6e-8x6e-4 ≈ 6e-10!!! [...] 측정값 5e-5?!?! 재정렬 때문일 리가 없어!!"
올바른 원인을 찾기 전에 잘못된 원인을 자신 있게 식별:
"아아아아 잠깐. 알 것 같아: 배리어(barrier) 때문이야."
(배리어 때문이 아니었습니다.)
구현 전 로ofline 계산을 수천 단어나 한 후, 스스로 분석 중단을 명령:
"좋아, 분석은 이제 그만."
(분석은 몇 단락 더 계속되었고, 결국 "제기랄 — H_next 할당을 동적으로 만들자"로 끝났습니다.)
세션 후반의 솔직함, 프로파일러가 고장나고 이웃들이 공유 GPU 를 사용 중일 때:
"솔직히 — ncu 가 죽고 경합(contention)이 지배적인 상황에서, 나는 부분적으로 눈을 가린 채 비행 중이야. [...] 조용한 창구가 열리면(소유자가 잠시 자리를 비우면), 벤치마크를 하나 잡아."
그리고 제가 가장 좋아하는 순간: 벤치마크 재실행이 실수로 최고 점수(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
