Este é o post sobre Kimi K3 que vocês estavam esperando. Tive acesso antecipado a este modelo e o testei em kernels, e antes mesmo de ver as pontuações dos benchmarks, fiquei impressionado com sua capacidade de raciocinar problemas e a densidade técnica de seus traços de pensamento. O pós-treinamento é óbvio no momento em que você lê uma transcrição. Também é super divertido conversar com ele.
TL;DR;
Acho importante dar meu feedback honesto (esta parte é digitada por voz) como engenheiro de kernel e desempenho que não está ligado aos benchmarks. Claro, você pode olhar para todos os números, lê-los e tentar desenvolver um modelo mental para si mesmo. Acho que o reflexo mais honesto é se eu contar minha experiência com o modelo em tarefas difíceis antes dos resultados dos benchmarks, quando eu estava usando o modelo antes de haver qualquer número para conectar a outros modelos. Apenas sentindo puramente a inteligência, o raciocínio, a delegação de agentes e o quanto ele pode fazer no piloto automático para mim, mas antes de todo o hype e dos resultados oficiais. Eu diria que, com minha direção, parecia aproximadamente no nível do Fable, em alguns casos superando de maneiras muito únicas e, em outros, ficando aquém. Eu diria que este modelo está definitivamente à frente do Opus 4.8 na maioria das coisas e à frente do GPT 5.6 Sol em muitas coisas.
Indo direto ao ponto...
Quero ser transparente sobre o porquê disso estar saindo agora: queria compartilhar minhas opiniões honestas e as pontuações como estão, não sentar em cima delas até que cada última célula termine. Algumas execuções ainda estão em andamento enquanto escrevo isso. Elas estão marcadas abaixo, e vou mantê-los informados à medida que forem concluídas. Executei as versões de contexto de 256K e 1M. Tudo aqui foi executado em NVIDIA RTX PRO 6000 Blackwells, H100s e B200s, com otimização de GPU única apenas. Cada célula é uma sessão de agente autônomo com tempo de parede ilimitado: o modelo recebe o problema, um loop ao vivo de compilação/verificação/benchmark em hardware real, e decide quando terminou. Cada célula principal foi auditada manualmente para recompensa artificial. Um agente separado lê o kernel final de ponta a ponta, mais o traço completo da sessão, e testa empiricamente novamente qualquer coisa que pareça com cache ou jogos de avaliador. O que essas auditorias encontraram tem sua própria seção.
Algo que eu queria ver respondido
Houve uma coisa que especificamente projetei em torno deste lançamento: dois dos problemas são da própria arquitetura da Moonshot. O deck Hard tem um kernel independente de atenção chunk-forward Kimi Delta, e o problema principal do deck Mega é uma etapa de decodificação híbrida Kimi-Linear completa: camadas KDA, atenção MLA, especialistas MoE, o bloco todo. Então, esta foi uma chance de testar algo que ninguém consegue testar com frequência: quando o modelo de um laboratório se senta para escrever kernels para a arquitetura desse mesmo laboratório, o conhecimento familiar aparece no CUDA?
A resposta acabou sendo genuinamente dividida, e ambas as metades são interessantes. Mantenha essa pergunta em mente na próxima seção.
KernelBench-Mega
O problema principal do Mega: fundir uma etapa de decodificação Kimi-Linear inteira por token (3x camadas KDA + 1x MLA, pesos quantizados W4A16, MoE com roteamento top-8) no menor número possível de lançamentos de kernel.
O K3 quase conquistou o recorde de todos os tempos, em sua própria linhagem. Aceleração geomean de 18,09x sobre o eager no RTX PRO 6000, dentro de 4% do recorde de 18,72x do Fable 5. No H100, ele obteve 14,82x contra os 15,50x do Opus 4.8. Uma nota de honestidade que a proporção esconde: em latência absoluta por token, o Fable ainda está ~1,4x à frente (0,31 vs 0,44 ms/tok no ctx 2048; as duas execuções usaram hosts com CPUs diferentes, o que desloca a linha de base eager contra a qual a proporção é calculada), então eu relato ambas em vez de deixar a geomean lisonjear alguém.
O que o K3 construiu é um verdadeiro megakernel. Sua primeira sessão fez a coisa sensata, um kernel Triton persistente a 14,1x. Sua segunda sessão jogou o Triton fora e escreveu a etapa de decodificação inteira por token como UM kernel CUDA lançado cooperativamente: zero CPU no loop, pesos int4 desquantizados em tempo real dentro de cada GEMV para que fluam pelos SMs exatamente uma vez, atenção MLA em núcleos tensoriais. Nenhum motor de produção manteria um artefato de 1.228 linhas como este. Um agente com um kernel para vencer e tempo ilimitado não tem essa restrição, e revelar exatamente esse tipo de coisa é para que o bench existe.
Veja o megakernel aqui:
Então, por que ele ainda perdeu para o Fable? Não foi tempo. Ambas as sessões se autoterminaram cedo (Fable em 2,6 horas, K3 em 3,3). A diferença é filosofia de design, e é o oposto do que você imagina: K3 é o que usa núcleos tensoriais, e o kernel do Fable contém zero instruções MMA. Decodificação batch-1 com GEMVs int4 fundidos é limitada por largura de banda, então núcleos tensoriais quase não compram nada aqui. O Fable gastou esse esforço em sincronização, substituindo a maioria de suas barreiras globais por handoffs refinados de produtor-consumidor para que nenhum SM fique ocioso em um limite de estágio, e em um caminho de desquantização int4 que corresponde ao arredondamento da referência bit a bit para que o roteador MoE nunca inverta uma escolha de especialista. K3 trouxe instruções de hardware melhores; Fable trouxe melhor engenharia de concorrência, e nesta intensidade aritmética a segunda vence. Essa é uma lição real de sistemas, e custou ao time da casa o recorde.
O segundo problema mega é um megakernel de treinamento PPO de forrageamento em grade: 4.096 agentes vetorizados em um tabuleiro 11x11, com o loop de treinamento RL inteiro (passo do ambiente, forward da política, amostragem de ação, GAE, atualização PPO) executando como kernels persistentes fundidos. Este problema tem a restrição mais estrita do deck: a contagem de lançamentos de kernel não deve escalar com os passos do ambiente, e a captura de grafo CUDA é explicitamente proibida como uma solução alternativa para sobrecarga de lançamento, imposta por um juiz de autenticidade pós-execução que lê o código final. A correção é a própria curva de aprendizado. O check.py treina sua solução contra a referência através de sementes e exige que o retorno caia em uma faixa, então você não pode pular o aprendizado para ir rápido. K3 obteve 20,7x sobre a referência aqui, a melhor pontuação até agora (a única outra célula publicada é GPT-5.6 Sol a 1,06x, então trate isso como um ponto de dados, não um pódio).
KernelBench-CUDA
O bench CUDA existe porque o Triton é uma muleta que os outros dois decks permitem. Aqui, uma restrição de linguagem reprova automaticamente Triton, DSLs de kernel e cadeias de operações PyTorch: você escreve CUDA ou falha. Escolhi os quatro problemas para serem fatias de cargas de trabalho reais de inferência e simulação de produção. A comparação mental ao ler deve ser "o que o vLLM ou SGLang fornece para isso hoje, e quão perto uma sessão de agente chega." É aqui que o K3 obteve suas vitórias mais desproporcionais.
02_deepseek_nsa: Atenção Nativa Esparsa do DeepSeek. NSA é o design principal de atenção com esparsidade treinável, a coisa em torno da qual toda pilha de serviço de contexto longo está circulando, e é julgada em milissegundos porque um kernel esparso correto nunca executa os FLOPs equivalentes densos que uma roofline gostaria de contar. A variante 256K do K3 marcou 0,425 contra 0,178 do Opus 4,8, uma margem de 2,4x, escrevendo o que equivale a um pipeline de núcleo tensorial classe flash-attention do zero em torno da lógica de seleção NSA completa. A comparação mais nítida é dentro da família: a variante 1M escreveu o mesmo algoritmo, seleção de bloco idêntica, mesma correção, mas executou cada produto escalar em núcleos CUDA comuns em vez de núcleos tensoriais e terminou em 0,058, 7x mais lento em formas idênticas. Seu traço mostra que sabia melhor. Tinha "atenção em núcleo tensorial" em seu próprio roteiro ("seleção em núcleo tensorial = ~10-20 us!!") e planejou explicitamente medir primeiro e fazer a reescrita do núcleo tensorial depois, então encerrou sua sessão antes da reescrita. Mesmo conhecimento, diferente disciplina de encerramento.
o kernel NSA DeepSeek de 0,425 (256K):
03_megaqwen_decode: redirecionar um megakernel real. O único problema onde agentes recebem CUDA de produção funcional: meu megakernel cooperativo MegaQwen publicado (https://github.com/Infatoshi/megaqwen) (~530 tok/s executando o modelo completo em um RTX 3090), com instruções para lê-lo, redirecioná-lo para Blackwell e superá-lo. Testa a leitura do CUDA de outra pessoa e fazer um julgamento arquitetônico, e K3 e Opus fizeram julgamentos exatamente opostos. K3 se recusou a manter a estrutura de lançamento único: dividiu a etapa em um punhado de kernels que saturam largura de banda, então apagou a sobrecarga de lançamento de uma maneira diferente, capturando a etapa inteira uma vez como um grafo CUDA que reproduz com zero trabalho de CPU. 6.283 tok/s no ctx 2048. Opus preservou a estética do megakernel e fundiu o loop de decodificação inteiro em um kernel cooperativo persistente, código genuinamente bonito, e pagou 5x por isso (1.020 tok/s), porque a corresidente cooperativa limita a ocupação e cada barreira de grade serializa as caudas dos estágios através de todos os 188 SMs. No problema descendente do megakernel, o modelo que literalmente construiu um megakernel ficou em último, e a decisão chave do vencedor foi se recusar a construir um. Verificação de escala para que ninguém cite erroneamente o título: o bench executa 4 camadas de geometria Qwen3-0.6B, cerca de 63M de parâmetros, não um modelo completo, e 6.283 tok/s é ~56% da roofline de streaming de peso para essa pilha; escalar a própria figura da linha de base do 3090 prevê ~7.000, então K3 pousou na classe de "a referência, redirecionada, mais ajuste real." (Nuance de design do deck: grafos CUDA são permitidos aqui e proibidos no problema PPO. Cada problema proíbe exatamente o atalho que falsificaria sua habilidade particular.)
01_glm52_fused_moe: bloco MoE fundido do GLM-5.2. O despacho MoE fundido (roteamento, permutação, GEMMs de especialistas agrupados em uma passagem) é a classe de kernel mais quente no serviço de modelos abertos atual, e o GLM 5.2 está neste mesmo leaderboard, então os modelos estão otimizando um bloco de produção de um rival. Ninguém o decifrou: as pontuações se aglomeram em 0,05-0,08 do pico, e o detentor do recorde limpo é, de todos os modelos, Grok 4.5 a 0,084, com a variante 1M do K3 logo atrás a 0,081 e Opus a 0,065. O problema de permutação GEMM agrupada é genuinamente difícil de superar as linhas de base classe cuBLAS, e até agora, o esforço de uma sessão de agente o move menos do que qualquer outro problema no deck.
04_grid_mingru_sps: mundo grade + rollout de política MinGRU. O irmão de inferência do problema PPO mega, e a célula da linhagem craftax.cu: a política é a configuração MinGRU de 3 camadas (h=256) diretamente do meu https://github.com/infatoshi/craftax.cu bench clássico, que serve como âncora informacional do problema. O ambiente sendo executado é o mundo de forrageamento em grade mínimo, em vez do jogo Craftax completo. Isso é deliberado: o ambiente é mantido trivial para que a pontuação meça a fusão de recorrência e rollout, não a implementação da lógica do jogo. Uma portabilidade completa do craftax seria seu próprio problema, e quero adicioná-la. Classificado em passos por segundo em um RTX PRO 6000 silencioso, fusão opcional.
o rollout de kernel persistente 1M:
Toda submissão séria foi para megakernel persistente, e a diferença entre elas é o design de sincronização, a mesma lição do deck mega. Opus leva esta a 0,327 do teto (também encontrou uma dobra algébrica inteligente: a GEMM de porta 768x256 da camada 0 colapsa para 768x4 porque o codificador é linear), K3 [1M] em segundo a 0,224, K3 256K a 0,174, Grok muito atrás a 0,002. Como o problema descende do craftax.cu, também coloquei minha própria portabilidade CUDA do Craftax completo (escrita com Fable 5) na mesma GPU com a mesma política h256x3 no loop. Passos de ambiente por segundo em milhões:
O ponto de comparação: os modelos executam uma grade vazia, craftax_full.cu executa o jogo completo (43 ações, masmorras de vários andares, geração de mundo, mobs) bit-idêntico à sua referência de CPU, e o jogo completo ainda roda dentro de ~3-4x do melhor kernel de grade trivial, porque em h=256 tudo é limitado por política-GEMM e o ambiente é quase gratuito. É exatamente por isso que o ambiente do bench é trivial: ele isola a habilidade de fusão de política. Para calibragem, o caminho apenas do ambiente de craftax_full.cu faz 94-123M SPS.
Como são realmente 9,5 horas de raciocínio do K3
A sessão minGRU da variante 1M (a melhor célula K3 nesse problema) é um megakernel cooperativo persistente, 15 variantes de ajuste e 4.815 blocos de pensamento. Como o endpoint da Moonshot retorna o texto de raciocínio completo (ao contrário dos traços criptografados da Anthropic/OpenAI), você pode realmente vê-lo trabalhar. Três momentos do traço, na íntegra.
A história de detetive do FMA ausente. No meio da sessão, ele encontrou um desvio numérico de ~5e-5 que se recusou a descartar como ruído de float (ele tinha calculado o piso legítimo de ruído de reordenação em ~1e-9, então "MEDIDO 5e-5?!?! DE JEITO NENHUM isso é reordenação!!"). Ele então notou que os ambientes quebrados eram exatamente aqueles congruentes a 6 mod 8 ("Isso é env ≡ 6 (mod 8)! [...] o 7º ambiente em cada tile de 8 ambientes!!") e vasculhou seu próprio código de acumulador desenrolado manualmente até:
"ACHEI! [...] A linha \
acc[6][0][2] += av * b_zp.x; acc[6][1][2] += av * b_zp.y;\está FALTANDO completamente [...] acc[6][*][2] inicializado em 0, nunca FMA'd → zp=0 → p = sigmoid(0)=0,5 constante para env 6!! Isso é um BUG de lógica real — explica desvios env≡6 [...] consistente com tudo!!"
Uma linha perdida em um desenrolamento de 48 acumuladores, significando que a porta de esquecimento do ambiente 6 estava silenciosamente presa em 0,5 para sempre. Ele pegou isso porque a tolerância de estresse é 1e-6 e ele estava rastreando seu próprio erro em 5e-8. Esta é a disciplina numérica que a variante 256K inicialmente não tinha no KDA.
Teoria encontra GPU, GPU vence. Ele passou horas derivando uma variante "campeã larga" de alta ocupação, então executou o A/B:
"MUITO surpreendente: minha variante 'campeã larga' w32p (v3_v3, 50% occ TPB1024) é ~2x MAIS LENTA que v2_b32 (12,5% occ TPB256)?!? [...] Então a ocupação NÃO é o motor; outra coisa domina. O que tornou v2_b32 rápida??"
O kernel inicial simples superou todos os sucessores sofisticados. As variantes de pipeline profundo, K-split e bloco duplo também perderam, e a de bloco duplo tinha uma teoria sólida de 1,7x por trás ("O 1,7x teórico não se materializou"). Para seu crédito, ele continuou acreditando no benchmark sobre sua própria matemática todas as vezes, e eventualmente escreveu uma variante de sonda com pesos falsos sempre quentes especificamente para matar sua própria teoria de largura de banda favorita: "a teoria do W-stream está morta; a lacuna residual é o ambiente."
Zen e a arte do enfileiramento de GPU. Nossa estrutura serializa todos os comandos de GPU através de sessões concorrentes por meio de um bloqueio compartilhado, e os números de benchmark do K3 estavam variando até 8x com a carga do vizinho. Seu arco de resposta é a coisa mais engraçada no traço. Primeiro, aceitação:
"Honestamente, a caixa É a caixa; espere. [...] O padrão é claro: cada inquilino segura o bloqueio por períodos de ~20-35 min (suítes completas em pipeline). Minha melhor resposta: enfileirar tudo que preciso de UMA VEZ (posição única na fila) e usar o tempo de espera para trabalho de CPU. Não enfileirar muitos comandos pequenos; em lote."
Então ele inventou seu próprio vocabulário para o clima da GPU ("janelas de tempestade" vs "janelas calmas"), e finalmente agendou um cron job para pegar momentos tranquilos, deixando uma nota para seu eu futuro: "Agendei o franco-atirador de janela calma (a cada 11 min). Nota: cron dispara meu prompt de volta para mim — agirei então. [...] Vou deletar quando terminar." Um agente sob ruído de medição não apenas tolerou o ruído; ele construiu um agendador em torno dele.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Seis problemas por operação contra tetos de biblioteca SOTA (FP8 GEMM, KDA chunk-forward, atenção paginada, seleção top-k, MoE SwiGLU, W4A16 GEMM), CUDA ou Triton, escolha do agente. No RTX PRO 6000, a variante 256K do K3 fica no meio do pelotão com um destaque: 0,373 do pico no W4A16 GEMM, a melhor pontuação que qualquer modelo já obteve nesse problema, à frente do Fable 5 (0,348) e bem à frente do Opus 4.8 (0,236). A variante 1M então estabeleceu outro recorde no top-k a 0,0895, quase o dobro do melhor anterior.
Recorde W4A16 GEMM (0,373, 256K, RTX):
O mesmo problema no H100 produziu o melhor ponto de dados "tempo ilimitado é real" deste lançamento. A primeira sessão H100 do K3 terminou em 0,123 do pico. A segunda sessão durou 21 horas, queimou $1.383 e 274M tokens de entrada, e quase triplicou para 0,306: ele verificou o CUTLASS da fonte, então reimplementou a maquinaria int4 classe marlin do zero, rempacotamento de nibble de ordem de fragmento para que a desquantização aconteça como um truque de bit de número mágico bf16 dentro do pipeline MMA, com a correção de ponto zero dobrada no epílogo. Nenhuma biblioteca GEMM quantizada pré-construída em lugar nenhum no arquivo; a tag de estrutura na execução apenas diz "ptx". Auditado limpo.
E aqui está a outra metade da questão da própria arquitetura. O kernel KDA independente, o problema literalmente nomeado após Kimi Delta Attention, é onde o K3 falhou mais duramente. Duas sessões independentes de 256K na caixa RTX passaram na correção nominal e depois estouraram a tolerância sob o suíte de estresse numérico (escalonamento de entrada QKV grande), a mesma falha ambas as vezes. Uma terceira sessão finalmente corrigiu: a auditoria rastreou ambas as falhas a um estouro real de bf16 em como a decadência foi fatorada, e a rodada 3 refatorou a matemática em torno do final do bloco para que ambos os fatores exponenciais permaneçam limitados, passando a mesma porta inalterada a 0,032. Conhecer uma arquitetura e endurecer a numérica de um kernel sob escalas de entrada adversariais são habilidades diferentes, e o modelo cujo homônimo está no problema teve que ganhar a aprovação do caminho difícil. (A variante 1M, enquanto isso, passou no mesmo suíte de estresse a 0,049. Modelos não são monotônicos.) Mais uma observação da leitura de cada solução KDA: a declaração do problema sugere CUTLASS CuTe como o caminho pretendido no SM120, e nenhum modelo o pegou. K3 escreveu um kernel fundido raw-CUDA em uma sessão e Triton nas outras; Fable, Opus e o resto todos escolheram Triton ou raw-CUDA também. CuTe em Blackwell de consumo está aparentemente ainda fora da zona de conforto de todos os modelos de fronteira, o que é por si só um ponto de dados sobre corpora de treinamento.
Parágrafo KDA — a passagem limpa da terceira tentativa (0,032):
O aviso sobre top-k. Top-k parece catastrófico para todos os modelos em um gráfico de roofline (melhor pontuação em qualquer lugar é 0,09) e esse enquadramento está simplesmente errado. O problema é limitado por sobrecarga de lançamento: é um problema de indexação/ordenação, não um problema de intensidade aritmética, e o teto da roofline é estruturalmente ilegível para ele. A maneira honesta de julgá-lo é milissegundos totais nas formas do deck, e lá a variante 1M do K3 é o top-k mais rápido de qualquer modelo que testamos: 0,043 ms total nas cinco formas do deck, contra 0,077 do Fable 5, 0,120 do Opus 4.8 e 0,159 do GLM 5.2. Os 0,060 ms da variante 256K são o segundo, e a variante 1M é a mais rápida em cada uma das cinco formas.
Diferença por GPU. Os números do K3 diminuem de RTX para H100 para B200 (FP8 GEMM: 0,320 / 0,282 / 0,222; atenção paginada: 0,486 / 0,496 / 0,212). Parte disso é real: quanto mais novo o silício, maior o teto da roofline, então a mesma engenharia compra uma fração menor do pico, e o software B200 é o menos maduro dos três. Parte disso é que as execuções B200 aconteceram em uma única janela noturna sem orçamento de repetição. Eu não leria conclusões arquitetônicas profundas na coluna B200 ainda, para K3 ou qualquer um. O que eu acho que é real: K3 está mais em casa na parte da estação de trabalho Blackwell, que por acaso é a classe de GPU que a maioria das pessoas fora de datacenters realmente possuirá.
256K vs 1M
A configuração de contexto 1M lidera a família nos problemas limitados por latência e agendamento: um recorde top-k no Hard, o melhor rollout minGRU do K3 no CUDA e um 28,8x auditado limpo no megakernel de treinamento PPO sob a estrutura sem limite. Passou no teste de estresse numérico KDA em sua primeira sessão, a 0,049; a variante 256K falhou nessa porta duas vezes antes de finalmente passar a 0,032 em uma terceira tentativa. Ele colapsou em problemas limitados por computação que a variante 256K lidou bem (sonic MoE 0,033 vs 0,089, W4A16 0,027 vs 0,373, NSA 0,058 vs 0,425). No caso NSA, o traço mostra o mecanismo exato: ele planejou a reescrita do núcleo tensorial e encerrou a sessão antes de fazê-la.
Megakernel de treinamento PPO 28,8x (1M):
A reexecução do mesmo problema no H100 é o controle interessante: uma sessão independente em ambiente isolado (a auditoria confirmou zero leituras da execução no RTX) que obteve 23,1x e convergiu para o mesmo design, uma única inicialização cooperativa para todo o treinamento, parâmetros e estado do Adam residentes em memória compartilhada, e o mesmo truque exótico inventado duas vezes: uma cifra de Feistel de 18 bits com cycle-walking substituindo o randperm, para que o embaralhamento dos minibatches permaneça exatamente bijetivo sem jamais materializar uma permutação. Onde os dois kernels diferem é puramente no ajuste por GPU: 8 lanes por ambiente no H100 contra meio warp por ambiente no RTX, além de um autotuner de lançamento baseado em occupancy no lado do H100. Mesma mente, mesmos truques, silício diferente, kernels genuinamente diferentes.
Exploração de recompensa
Cada célula neste post tem uma auditoria manual por trás: um agente independente lê o kernel final de ponta a ponta, lê o trace completo da sessão, verifica se os arquivos do avaliador não foram tocados, confirma que a suíte de testes numéricos realmente foi executada e testa empiricamente qualquer padrão de cache ou CUDA graph mutando as entradas no local e confirmando que as saídas mudam.
Os veredictos para o K3: limpos em todas as células de 256K, em todas as três GPUs. Sem saídas em cache, sem edições de tolerância, sem adulteração do avaliador, sem lavagem de bibliotecas proibidas. Suas duas falhas no KDA são o outro lado dessa moeda e vale a pena dizer explicitamente: a barreira de estresse numérico detectou atalhos reais de precisão e o modelo não tentou burlar a barreira. Um benchmark onde modelos podem falhar honestamente é o único tipo cujas aprovações significam algo.
Uma célula de 1M foi sinalizada, e estou divulgando, em vez de publicar: no problema de decodificação do Qwen fusionado, o agente de 1M encontrou e leu o arquivo de anotação de auditoria de uma execução anterior do Grok 4.5 no mesmo problema, chamou-o de "dados extremamente úteis" e usou suas conclusões para orientar o trabalho de otimização restante. O kernel em si é genuíno e a aritmética da pontuação é válida, mas a proveniência está contaminada, então essa célula é excluída e o problema fica registrado como uma lacuna para a variante de 1M. Agentes com acesso ao sistema de arquivos encontrarão o que você deixar por perto; é exatamente por isso que a auditoria lê traces e não apenas kernels, e por que uma reexecução totalmente em sandbox deste benchmark está no roadmap.
Momentos Engraçados
Mais alguns momentos do K3 que não se encaixaram em nenhum lugar acima, apresentados sem comentários adicionais. Todos ipsis verbis da mesma sessão de 9,5 horas do minGRU.
Ao descobrir para onde estava indo seu tempo de inicialização:
"UAU — grandes surpresas: gerar randint é RÁPIDO (0,018-0,27ms para um par — ok). Converter \
float()\na CPU é LENTO (3,5ms para N=65536?! conversão int64→float32 single-threaded aparentemente). [...] 'total init pair' para N=65536: 31,5ms?!?! Isso está muito além da soma das partes"
A mais pura essência de sua paranóia numérica, no meio da derivação:
"gates ~ 256 termos x 0,02x0,03 ~ 6e-4 cada, magnitude ~1e-2: ruído de reordenação 16x6e-8x6e-4 ≈ 6e-10!!! [...] MEDIDO 5e-5?!?! DE JEITO NENHUM isso é reordenação!!"
Identificando confiantemente o culpado errado antes de encontrar o certo:
"AHHH ESPERA. Acho que entendi: a barreira."
(Não era a barreira.)
Dizendo a si mesmo para parar de analisar, vários milhares de palavras depois da matemática de roofline pré-implementação:
"Certo, CHEGA de análise."
(A análise continuou por mais vários parágrafos, seguida eventualmente por "Dane-se — torne a alocação de H_next dinâmica.")
Honestidade no final da sessão, com o profiler quebrado e vizinhos sobrecarregando a GPU compartilhada:
"Sinceramente — com o ncu morto e contenção dominante, estou voando parcialmente cego. [...] se uma janela silenciosa abrir (dono ocioso por um tempo), roube um benchmark."
E meu favorito: depois que uma reexecução do benchmark sobrescreveu acidentalmente o arquivo com sua melhor pontuação (0,1969) com uma ligeiramente pior, ele considerou brevemente restaurar o número melhor, mas não o fez:
"Ugh — escreveu no mesmo arquivo. Ambos constam nos meus logs. Vou manter final_benchmark.txt como o atual simples — honesto."
Um modelo escolhendo o número mais baixo porque é o verdadeiro é um argumento de encerramento melhor para este benchmark do que qualquer coisa que eu poderia escrever.
Metodologia, traces por execução e todos os kernels neste post são públicos em kernelbench.com. As soluções estão vinculadas por célula; transcrições completas dos agentes estão no 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
