Este é o post do Kimi K3 que vocês estavam esperando. Consegui acesso antecipado a este modelo e venho testando ele em kernels, e mesmo antes de ver os resultados dos benchmarks, fiquei impressionado com sua capacidade de raciocinar sobre problemas e a densidade técnica de seus traços de pensamento. O pós-treinamento disso é óbvio no momento em que você lê uma transcrição. Também é muito divertido conversar com ele.
TLDR;
Acho importante dar meu feedback honesto (esta parte é digitada por voz) como engenheiro de kernel e performance que está dissociado dos benchmarks. Claro, você pode olhar todos os números e 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 saírem, 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 de piloto automático ele pode fazer por mim, mas antes de qualquer hype e dos resultados oficiais saírem. Eu diria que, com minha direção, parecia aproximadamente no nível do Fable, em alguns casos superando de maneiras muito únicas e em alguns casos ficando abaixo. 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.
Entrando no assunto...
Quero ser transparente sobre por que isso está saindo agora: queria compartilhar minhas opiniões honestas e as pontuações como estão, não ficar sentado nelas 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 versões de contexto de 256K e 1M. Tudo aqui foi executado em NVIDIA RTX PRO 6000 Blackwells, H100s e B200s, apenas otimização de GPU única. 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 está pronto. 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 qualquer coisa que pareça cache ou jogos de avaliador. O que essas auditorias encontraram tem sua própria seção.
Algo que eu queria responder
Houve uma coisa que eu especificamente projetei neste lançamento: dois dos problemas são da própria arquitetura da Moonshot. O baralho Hard tem um kernel autônomo de chunk-forward Kimi Delta Attention, e o problema principal do baralho Mega é uma etapa de decodificação híbrida Kimi-Linear completa: camadas KDA, atenção MLA, especialistas MoE, todo o bloco. Então essa foi uma chance de testar algo que ninguém testa 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 mega principal: fundir uma etapa de decodificação Kimi-Linear inteira por token (3x camada KDA + 1x MLA, pesos quantizados W4A16, MoE com roteamento top-8) em quantos lançamentos de kernel forem possíveis.
O K3 quase levou o recorde de todos os tempos, em sua própria linhagem. 18,09x de speedup geométrico sobre eager na RTX PRO 6000, dentro de 4% do recorde de 18,72x do Fable 5. Em H100, ele postou 14,82x contra 15,50x do Opus 4.8. Uma nota de honestidade que a razã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 razão é calculada), então reporto ambas em vez de deixar a média geométrica 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 toda a etapa de decodificação por token como UM kernel CUDA lançado cooperativamente: zero CPU no loop, pesos int4 desquantizados na hora dentro de cada GEMV para que fluam pelos SMs exatamente uma vez, atenção MLA em tensor cores. 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 é por que o benchmark existe.
Veja o megakernel aqui:
Então, por que ainda perdeu para o Fable? Não foi o tempo. Ambas as sessões se autoterminaram cedo (Fable em 2,6 horas, K3 em 3,3). A diferença é a filosofia de design, e é o oposto do que você imaginaria: K3 é o que usa tensor cores, 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 tensor cores não compram quase nada aqui. O Fable gastou esse esforço em sincronização, substituindo a maioria de suas barreiras globais por handoffs produtor-consumidor de granulação fina 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 nessa 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 de 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 baralho: a contagem de lançamentos de kernel não deve escalar com os passos de ambiente, e a captura de grafo CUDA é explicitamente proibida como contorno de sobrecarga de lançamento, aplicada 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 em todas as sementes e exige que o retorno caia em uma faixa, então você não pode pular o aprendizado para ir rápido. K3 postou 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 benchmark CUDA existe porque Triton é uma muleta que os outros dois baralhos permitem. Aqui, uma barreira de linguagem reprova Triton, DSLs de kernel e cadeias de operações PyTorch: você escreve CUDA ou falha. Escolhi os quatro problemas como recortes 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 enviam para isso hoje, e quão perto uma sessão de agente chega." É aqui que o K3 postou suas vitórias mais desequilibradas.
02_deepseek_nsa: Atenção Esparsa Treinável da DeepSeek. NSA é o design principal de atenção esparsa treinável, a coisa que toda pilha de serviço de contexto longo está rondando, e é julgada em milissegundos porque um kernel esparso correto nunca executa os FLOPs equivalentes densos que uma linha de teto gostaria de contar. A variante 256K do K3 pontuou 0,425 contra 0,178 do Opus 4.8, uma margem de 2,4x, ao escrever o que equivale a um pipeline de tensor-core 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 tensor cores e chegou a 0,058, 7x mais lento em formas idênticas. Seu traço mostra que sabia melhor. Tinha "atenção tensor-core" em seu próprio roteiro ("seleção em tensor cores = ~10-20 us!!") e planejou explicitamente medir primeiro e fazer a reescrita tensor-core depois, então encerrou sua sessão antes da reescrita. Mesmo conhecimento, disciplina de fechamento diferente.
o kernel DeepSeek NSA 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 uma RTX 3090), com instruções para lê-lo, redirecioná-lo para Blackwell e superá-lo. Testa ler o 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 toda a etapa 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 todo o loop de decodificação em um kernel cooperativo persistente, código genuinamente bonito, e pagou 5x por isso (1.020 tok/s), porque a co-residência cooperativa limita a ocupação e toda barreira de grade serializa as caudas de estágio em 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 errado o título: o benchmark executa 4 camadas da geometria Qwen3-0.6B, cerca de 63M de parâmetros, não um modelo completo, e 6.283 tok/s é ~56% da linha de teto de transmissão de peso para essa pilha; escalar a própria figura da linha de base da 3090 prevê ~7.000, então K3 pousou na classe de "a referência, redirecionada, mais ajuste real." (Nuance de design do baralho: 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. Despacho MoE fundido (roteamento, permutação, GEMMs de especialistas agrupados em uma passada) é a classe de kernel mais quente no serviço de modelos abertos atualmente, e o GLM 5.2 está neste mesmo ranking, então os modelos estão otimizando um bloco de produção de um rival. Ninguém conseguiu decifrá-lo: as pontuações se aglomeram em 0,05-0,08 do pico, e o detentor do recorde limpo é, de todos os modelos, o 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 da classe cuBLAS, e até agora, o esforço de uma sessão de agente o move menos do que qualquer outro problema no baralho.
04_grid_mingru_sps: mundo de 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 benchmark clássico, que serve como âncora informacional do problema. O ambiente sendo executado é o mundo mínimo de forrageamento em grade, 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. Avaliado em passos por segundo em uma RTX PRO 6000 silenciosa, 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 baralho 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-igual à 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 benchmark é trivial: ele isola a habilidade de fusão de política. Para calibração, o caminho apenas de ambiente do craftax_full.cu faz 94-123M SPS.
Como 9,5 horas de raciocínio K3 realmente se parecem
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 funcionar. Três momentos do traço, na íntegra.
A história de detetive do FMA ausente. No meio da sessão, encontrou um desvio numérico de ~5e-5 que se recusou a descartar como ruído de float (tinha calculado o piso de ruído de reordenação legítimo em ~1e-9, então "MEDIDO 5e-5?!?! DE JEITO NENHUM é reordenação!!"). Então notou que os ambientes quebrados eram exatamente os congruentes a 6 mod 8 ("Isso é env ≡ 6 (mod 8)! [...] o 7º ambiente em cada bloco 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á AUSENTE completamente [...] acc[6][*][2] inicializado em 0, nunca passou por FMA → zp=0 → p = sigmoid(0)=0.5 constante para o ambiente 6!! Isso é um BUG de lógica real — explica os 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 travada em 0,5 para sempre. Ele percebeu isso porque a tolerância de estresse é 1e-6 e 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. 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 ocupação NÃO é o motor; algo mais 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 teórico de 1,7x não se materializou"). Para seu crédito, continuou acreditando no benchmark mais do que em 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 favorita de largura de banda: "a teoria de transmissão W está morta; a lacuna residual é o ambiente."
Zen e a arte de enfileiramento em GPU. Nosso harness serializa todos os comandos de GPU entre sessões concorrentes através de um lock compartilhado, e os números de benchmark do K3 estavam variando até 8x com carga vizinha. 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 lock 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; fazer lote."
Então inventou seu próprio vocabulário para clima de GPU ("janelas de tempestade" vs "janelas calmas"), e finalmente agendou um cron job para atacar momentos tranquilos, deixando uma nota para seu futuro eu: "Agendei o atirador de janela calma (a cada 11 min). Nota: cron dispara meu prompt de volta para mim — agirei nele então. [...] Vou deletar quando terminar." Um agente sob ruído de medição não apenas tolerou o ruído; construiu um agendador em torno dele.
KernelBench-Hard
RTX PRO 6000 Blackwell
H100
B200
Seis problemas por operação contra tetos de bibliotecas de última geração (FP8 GEMM, chunk-forward KDA, atenção paginada, seleção top-k, MoE SwiGLU, W4A16 GEMM), CUDA ou Triton, escolha do agente. Na RTX PRO 6000, a variante 256K do K3 fica no meio do pacote com um destaque: 0,373 do pico em W4A16 GEMM, a melhor pontuação que qualquer modelo já postou 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 em 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 chegou a 0,123 do pico. A segunda sessão durou 21 horas, queimou $1.383 e 274M de tokens de entrada, e quase triplicou para 0,306: fez checkout do CUTLASS do código fonte, então reimplementou maquinaria int4 classe marlin do zero, reempacotamento de nibble em ordem de fragmento para que a desquantização ocorra como um truque de bit de número mágico bf16 dentro do pipeline MMA, com a correção de zero-point dobrada no epílogo. Nenhuma biblioteca GEMM quantizada pré-construída em lugar nenhum no arquivo; a tag de framework na execução apenas diz "ptx". Auditado limpo.
E aqui está a outra metade da questão da própria arquitetura. O kernel KDA autônomo, o problema literalmente nomeado após Kimi Delta Attention, é onde o K3 falhou mais severamente. 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 para um overflow real de bf16 em como a decadência foi fatorada, e a rodada 3 refatorou a matemática em torno do final do chunk 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 jeito difícil. (A variante 1M, enquanto isso, passou o 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 em SM120, e nenhum modelo o seguiu. 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 consumidor aparentemente ainda está 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 terceira tentativa de passagem limpa (0,032):
O aviso do top-k. Top-k parece catastrófico para todos os modelos em um gráfico de linha de teto (melhor pontuação em qualquer lugar é 0,09) e esse enquadramento é simplesmente errado. O problema é limitado por sobrecarga de lançamento: é um problema de indexação/classificação, não um problema de intensidade aritmética, e o teto da linha de teto é estruturalmente ilegível para ele. A maneira honesta de julgá-lo é milissegundos totais em todas as formas do baralho, 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 baralho, contra 0,077 do Fable 5, 0,120 do Opus 4.8 e 0,159 do GLM 5.2. A variante 256K com 0,060 ms é a segunda, e a variante 1M é a mais rápida absoluta em cada uma das cinco formas.
Distribuição 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 linha de teto, 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, nem para K3 nem para ninguém. 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 o harness 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. 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: planejou a reescrita tensor-core 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 na memória compartilhada, e o mesmo truque exótico inventado duas vezes: uma cifra Feistel de 18 bits com cycle-walking substituindo randperm, para que o embaralhamento dos minibatches permaneça exatamente bijetivo sem jamais materializar uma permutação. Onde os dois kernels diferem é puro ajuste por GPU: 8 lanes por ambiente no H100 contra meio warp por ambiente no RTX, além de um autotuner de inicialização baseado em ocupação no lado do H100. Mesma mente, mesmos truques, silício diferente, kernels genuinamente diferentes.
Recompensa ardilosa
Cada célula deste post tem uma auditoria manual por trás: um agente independente lê o kernel final de ponta a ponta, lê o rastro 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 novamente, de forma empírica, qualquer padrão de cache ou CUDA graph, alterando as entradas no lugar e confirmando que as saídas mudam.
Os vereditos para o K3: limpo em todas as células de 256K, em todas as três GPUs. Nenhuma saída em cache, nenhuma edição de tolerância, nenhuma adulteração do avaliador, nenhuma lavagem de biblioteca proibida. Suas duas falhas no KDA são o outro lado dessa moeda e vale a pena dizer explicitamente: a barreira de estresse numérico pegou 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 fusionada do Qwen, o agente de 1M encontrou e leu o arquivo de anotações 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 como uma lacuna para a variante de 1M. Agentes com acesso ao sistema de arquivos encontrarão qualquer coisa que você deixar por perto; é exatamente por isso que a auditoria lê os rastros e não apenas os kernels, e por que uma reexecução totalmente isolada deste benchmark está no roteiro.
Momentos Engraçados
Mais alguns momentos do K3 que não se encaixaram em lugar nenhum acima, apresentados sem comentários adicionais. Todos ipsis litteris da mesma sessão de 9,5 horas do minGRU.
Ao descobrir para onde seu tempo de inicialização estava realmente indo:
"UAU — grandes surpresas: randint gen é RÁPIDO (0,018-0,27ms para um par — tranquilo). A conversão \
float()\na CPU é LENTA (3,5ms para N=65536?! conversão int64→float32 aparentemente single-threaded). [...] 'total init pair' para N=65536: 31,5ms?!?! Isso está muito além da soma das partes"
A destilação mais pura de sua paranoia 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árias milhares de palavras depois da matemática de roofline pré-implementação:
"Certo, CHEGA de análise."
(A análise continuou por vários parágrafos, seguidos eventualmente por "Dane-se — tornar a alocação de H_next dinâmica.")
Honestidade no final da sessão, com o profiler quebrado e vizinhos usando a GPU compartilhada:
"Honestamente — com o ncu morto e contenção dominante, estou voando parcialmente cego. [...] se uma janela silenciosa abrir (dono ocioso por um tempo), roubar um bench."
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 estão 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, rastros por execução e todos os kernels deste 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
