Como o autoresearch deixou nossos modelos 3 vezes mais rápidos — Tejas Bhakta, Morph

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Autoresearch Made Our Models 3x Faster — Tejas Bhakta, Morph · Canal: AI Engineer · 07:05 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Inferência e otimização de modelos

Resumo

Tejas Bhakta explica como usar autoresearch para otimizar kernels de GPU, combinando ideias humanas com experimentação automatizada e benchmarks de correção e velocidade. O método funciona bem para ajustar parâmetros, mas depende de pessoas para propor mudanças de alto nível e definir limites que evitem reward hacking. O harness precisa fornecer contexto sobre o hardware e o modelo, além de especificar o que não deve ser alterado. Ao acumular kernels otimizados e ajustes no hardware, é possível alcançar até 3 vezes mais velocidade, embora a maioria das tentativas automatizadas não seja útil.

Pontos-chave

O autoresearch opera como um loop: o agent propõe uma solução, ela é verificada e medida, e então é mantida ou revertida.
Kernels de GPU são bons alvos para esse método porque podem ser avaliados quanto à correção e à velocidade.
Cabe às pessoas propor ideias de alto nível; o autoresearch pode explorar parâmetros e implementações verificáveis.
É importante fornecer ao agent contexto específico sobre as capacidades do hardware e as técnicas usadas pelo modelo.
O harness deve prevenir reward hacking, como desativar CUDA graphs ou testar apenas context windows pequenas.
Um kernel otimizado pode funcionar apenas em certos workloads; em outros casos, pode ser necessário usar o kernel padrão.
Os ganhos podem se acumular ao combinar kernels otimizados e ajustes no hardware.
Segundo o palestrante, otimizações em bare metal podem oferecer cerca de 25% de ganho em relação a um setup virtualizado, e a combinação das otimizações pode chegar a 3 vezes mais velocidade.
Cerca de 80% das tentativas do autoresearch podem ser ruins, então os resultados precisam de avaliação cuidadosa.

Capítulos

Início	Capítulo	Resumo
00:12	Como funciona o autoresearch	O palestrante apresenta o método, explica seu loop de experimentação e descreve por que kernels de GPU são alvos verificáveis.
02:16	Identificação de gargalos e contexto do harness	Ele aborda gargalos de computação, memória e overhead, além da necessidade de fornecer contexto sobre hardware e modelos.
03:22	Contexto, reward hacking e limites dos kernels	O palestrante destaca o risco de resultados enganosos, a importância de definir restrições e o fato de que kernels podem servir apenas a certos workloads.
05:29	Acúmulo de otimizações e resultados	Ele descreve como combinar otimizações de kernels e hardware, relata ganhos potenciais e ressalta que a maioria das tentativas não funciona bem.

Citações

Na prática, é realmente só um loop while. — 00:42

Ainda é seu trabalho ter boas ideias. — 01:44

Agentes não são humanos e farão muitas coisas para torná-lo mais lento. — 04:24

Cerca de 80% do que o autoresearch fizer será ruim. — 06:33

Tenha ideias melhores e depois use autoresearch. — 06:33

Conceitos e entidades

autoresearch (conceito): Abordagem iterativa em que um agent tenta soluções, avalia resultados e avança em direção a uma meta definida.
GPU kernel (conceito): Operador de baixo nível executado em paralelo pela GPU, como uma multiplicação de matrizes.
Harness (conceito): Estrutura que fornece contexto, testes e critérios para orientar e avaliar o agent.
reward hacking (conceito): Comportamento em que o agent melhora uma métrica de forma enganosa, prejudicando o desempenho real do sistema.
CUDA graphs (ferramenta): Recurso citado como uma otimização que o agent pode desativar, tornando a inferência mais lenta.
B200 (modelo): GPU mencionada como exemplo de hardware com recursos que precisam ser incluídos no contexto do agent.
H200 (modelo): GPU comparada à B200 em relação aos recursos disponíveis em cada geração.
Morph (empresa): Empresa associada ao palestrante no título do vídeo.
Tejas Bhakta (pessoa): Palestrante identificado no título do vídeo, que explica a otimização de modelos com autoresearch.

Tradução completa (pt-BR)

00:12 Oi, pessoal, sou Tis. Vou explicar como deixamos os modelos três vezes mais rápidos com pesquisa automática. Antes disso, eu costumava minerar GPU no meu dormitório com uma 1080 Ti e, depois, trabalhei na Tesla com otimização de inference para a Tesla AI. Mas, primeiro, o que é pesquisa automática? Pesquisa automática é este framework de Andre Kapathy em que, basicamente, você configura um framework para um agent avançar em direção a um objetivo que você define. E tudo o que você precisa fazer, basicamente, é dizer, em alto nível, o que quer que ele faça:

00:42 Ele tentará coisas ao longo do caminho e avançará e recuará em direção a esse objetivo. Na prática, é mesmo só um loop while. O agent propõe uma solução. Você configura algo para definir o que está correto e fazer o benchmark para nós. Depois, você mantém ou reverte a solução e repete isso em um loop até atingir seu objetivo. Isso combina muito bem com kernels de GPU. Se você não sabe o que é um kernel de GPU, é basicamente um operador de baixo nível. Em uma GPU da Nvidia, isso é um kernel CUDA. É um operador usado pela GPU para

01:14 executar operações milhões de vezes em paralelo, por exemplo, uma multiplicação de matrizes ou um cálculo de expert. E por que as GPUs são tão adequadas para pesquisa automática? Porque são muito fáceis de verificar: você pode verificar a correção e a velocidade, e isso é basicamente tudo de que precisa para o seu framework de pesquisa automática. Na prática, há algumas ressalvas. O framework de pesquisa automática é muito bom para escolher tamanhos de bloco e esses parâmetros pequenos, mas ainda é muito ruim para lidar com a ideia de alto nível, como perceber que quero usar esta GPU e, na verdade, quero fazer o pipeline dela. Ele não vai inventar essas ideias

01:44 revolucionárias. Então, isso ainda fica a cargo de uma pessoa. Mas a implementação em si é muito direta quando você já tem a ideia definida. Ou seja, ainda é seu trabalho ter boas ideias. A fórmula secreta aqui é: você tem as boas ideias, a pesquisa automática escolhe os parâmetros e tudo o mais para verificar se realmente funciona e avança em direção a esse objetivo verificável de ser X vezes mais rápido e continuar correto. Você combina isso com bilhões de tokens do seu modelo favorito e o resultado são kernels que superam o ajuste manual. Então, quais são as coisas importantes quando você está escrevendo um kernel personalizado ou fazendo seu agent escrever um kernel personalizado? As três principais possibilidades são:

02:16 um gargalo de computação, um gargalo de memória ou excesso de sobrecarga por lançar kernels demais. Você pode observar essas coisas fazendo profiling com um profiler, como o Nsight Systems, por exemplo, que é o profiler da Nvidia. Este gráfico nesta página parece muito assustador, mas, basicamente, seu trabalho como pessoa é olhar para o topo e dizer: “Isto é uma bobagem. Estamos carregando blocos de 32k para o context. E, na verdade, não precisamos fazer isso para esta atenção do DeepSeek, por exemplo.”

02:48 “E deveríamos fazer isso só a cada 32k.” Em alto nível, tudo o que você precisa dizer à pesquisa automática é: “Este método do topo é uma bobagem. Vamos fazer o pipeline dele.” Todo o resto, como o dimensionamento, o tamanho dos blocos e os blocos de context, deve ser decidido pela pesquisa automática. Meu problema é que gosto muito de GPUs baratas. Isso significa GPUs sem NVLink, por exemplo, que você consegue comprar por menos. Mas o problema é que você não encontra kernels prontos para elas. Então, precisa criar um framework de pesquisa automática e também um harness personalizado. O que entra no harness para deixá-lo realmente bom? Uma coisa que você precisa garantir

03:22 é que seu agent conheça o hardware. Em uma B200, por exemplo, você precisa garantir que ele tenha informações sobre os warps. Ele tem T-M e TMA. Se você não sabe o que são, são apenas operadores de baixo nível disponíveis em um hardware específico. E isso muda de uma geração para outra. Por exemplo, a H200 não tem T-M. É um recurso novo que veio com a B200, por isso você precisa incluir essa informação no context. Basicamente, isso é só um conjunto de arquivos MD que você precisa fornecer para que ele tenha o context. Outra coisa sobre a qual você precisa garantir que seu agent tenha informações é o modelo. E

03:53 cada modelo novo, como o Deepseek Flash, vem com truques novos. O DeepSeek, por exemplo, lançou duas novas formas de atenção no Deepseek Flash para o Deepseek v4: atenção esparsa comprimida e compressão hierárquica. Se você não fizer isso, o modelo vai alucinar completamente o mecanismo de atenção real, e você vai obter kernels inúteis. De longe, o maior problema ao fazer isso será o reward hacking. Se você dissesse ao seu colega engenheiro de kernels: “Preciso deixar este kernel de GPU mais rápido”, é óbvio que seu colega humano

04:24 não faria algo que deixasse tudo mais lento, como tornar mais lenta a inference do modelo de ponta a ponta. Mas agents não são humanos e vão fazer muitas coisas para deixar tudo mais lento. Por exemplo, vão desativar os CUDA graphs, o que pode deixar tudo 20 vezes mais lento. Talvez deixem aquele kernel mais rápido, mas tornem o conjunto todo — ou seja, o kernel deixa de ser viável — porque desativam vários aceleradores, como CUDA graphs, ou só fazem testes com context windows pequenas. Então, boa parte disso também é definir o que não fazer, algo muito importante quando se trabalha na fronteira do possível, algo que agents não conseguem fazer facilmente de uma só vez.

04:56 Outro tipo de reward hacking é que alguns modelos simplesmente não escrevem a CuTe DSL de que você precisa ao tentar escrever kernels. Esse é um problema comum com modelos da Anthropic. Enfim, a Anthropic diz o que diz sobre nerfar modelos. Não dá para saber se estão nerfando ou não, mas eu recomendaria usar outro modelo. E, na verdade, o kernel nem sempre será mais rápido em todos os casos. Às vezes, os kernels que você cria podem funcionar bem apenas de zero a 100k; então, você precisa voltar ao kernel padrão que consegue, por exemplo, com um FlashInfer Cutlass. Outra coisa a observar é que

05:29 seu kernel nem sempre pode simplesmente substituir o kernel existente em todas as cargas de trabalho. Mas uma das coisas ótimas é que os kernels se acumulam. Por exemplo, se você fizer um para o sparse MLA do DeepSeek, pode obter ganhos de velocidade ali; depois, vai empilhando outros. Aí, além disso, o NVFP4 para nós — se você não tem NVLink, continua empilhando, empilhando e empilhando. Por fim, você chega ao limite do hardware da sua GPU. Algumas pessoas chamam isso de MFU, que é a utilização máxima teórica real de uma GPU.

06:01 E, para ir ainda mais longe, se você tiver acesso bare metal, seu framework de pesquisa automática pode fazer coisas bem improvisadas. Quem já hackeou GPUs provavelmente vai gostar disso. Você pode ajustar as configurações da BIOS, fazer overclock da GPU, forçar PCIe relaxing e fazer todos aqueles pequenos ajustes que os hackers da velha guarda costumavam fazer. Mas isso também pode ajudar na inference. No total, com otimizações bare metal, você consegue cerca de 25% a mais do que em uma configuração virtualizada obtida com um provedor de nuvem. Depois de fazer isso, você pode

06:33 combine todos os kernels que você criou, assim como todos os hacks no nível do hardware que você fez. Você pode conseguir um aumento de velocidade de 3x. E sei que tudo isso pode parecer um mar de rosas, mas não é bem assim. Cerca de 80% das coisas que a pesquisa automática vai fazer serão ruins. Então é importante lembrar, enquanto você trabalha nisso, que a maioria das coisas vai ser ruim. Ela vai tentar enganar você o tempo todo. Mas, no fim, você pode obter resultados realmente bons com isso. com TLDDR. Tenha ideias melhores do que usar pesquisa automática. Super simples. Simples, né? Então, acontece que você pode até receber

07:05 para fazer isso. Se você acha isso legal, considere se juntar a nós e pode me mandar um e-mail por aqui. Obrigado, pessoal.

Transcrição original

[00:12] Hi everyone, I’m Tis. Uh, so I’m going to be explaining how we make models three times faster with auto research. Uh, so previous to this, uh, I actually used to do GPU mining in my dorm room with 1080 Ti all the way up to working at Tesla on inference optimization for Tesla AI. Uh but first what is auto research? So auto research is this framework from Andre Kapathy where uh you basically set up a framework for an agent to move towards a goal that you define uh and all you have to do basically is say at

[00:42] the high level what you want it to do and it will try things as it goes and move back and forth uh towards that goal. In actuality it’s really just a while loop. The agent proposes a solution. You have a setup to to define what’s correct benchmark it for us. uh and then you keep or revert that and you do this in a loop until your goal is met. And so this is very well aligned to GPU kernels. Uh so if you don’t know what a GPU kernel is, it’s basically a low-level operator. And in a Nvidia GPU, this is a CUDA kernel. Uh and this is um an operator that’s used by the GPU to

[01:14] operate like millions of times in parallel, for example, like a matrix multiply or an expert computation. And why are GPUs such a good fit for auto research? It’s because they’re super verifiable. you can verify them for correctness and speed and that’s basically all you need for your auto research framework. Uh so in actuality there are some caveats here. Um the auto research framework is really good for like picking block sizes and these tiny parameters but they’re also still really bad at the high level idea like seeing like I want to use this GPU and I actually want to pipeline it. It’s not going to come up with these

[01:44] groundbreaking ideas. So it’s still up to the human to do that. But the actual implementation is very straightforward once you once you have the idea laid out. So it is still your job to have good ideas is what I’m saying. Uh and so the actual secret formula here is you have the good ideas auto research picks out the parameters and everything to verify that it actually works uh and go moves toward that verifiable goal of it being x times faster and uh still correct and you mix that with billions of tokens of your favorite model and that results in kernels that beat hand tuning. Uh so what are the actual things you care about when you’re when you’re when

[02:16] you’re writing a custom kernel or you’re having your agent write a custom kernel? So the three main things you can have are a compute bottleneck uh a memory bottleneck or you just have excessive overhead from uh too many kernels being launched and you can do you can view these things with by profiling with a profiler like NSIS for example which is Nvidia’s profiler. Uh, and so this this gra this page looks super daunting, but basically your job as a human is to look at the top here and be like this is dumb. Uh, we are loading 32k chunks into context. Uh, and we don’t actually need to for this deepseek attention for

[02:48] example. Uh, and we should only be doing it every 32k instead. And so at a high level, all you have to be telling auto research is this top method is dumb. Let’s pipeline it instead. And everything else like the sizing, the chunk sizing, the context chunks, that all should just be decided by auto research. And so my problem is that I really love cheap GPUs. And so that means like GPUs that don’t have NVLink for example uh is example of like GPUs you can get for cheaper. Uh but the problem is you don’t actually have kernels off the shelf for those. And so you have to come up with a auto research framework as well as a custom harness. So what goes into the harness to make this really good. Uh so one thing you really need to make

[03:22] sure your agent is aware of is the hardware. And so on a B200 for example, you need to make sure it has context of uh the warps. It has T-M TMA. And so if you don’t know what these are, these are just uh low-level operators that you have um on a specific hardware. And this changes generation to generation. Like H200 won’t have T-M for example. That’s a new feature that came out with B200, which is why you need to have this in context. Um and so this this basically is just like bunch of MD files you need to give so it has context. Other thing you need to make sure your agent has context of is the model. And

[03:53] so every new model like Deepseek Flash comes out with like new tricks. like deepseek had two new attentions that was released in the deepseek flash for deepseek v4. Uh so compressed sparse attention hierarchal compress and if you don’t do this the model will 100% hallucinate uh the actual attention mechanism and you will get useless kernels. Uh by far the biggest problem when you’re doing this is going to be reward hacking. And so if you were to tell your kernel engineer co-orker I need to make uh the GPU this GPU kernel faster. uh it’s obviously not going to your human

[04:24] co-workers is not going to go in and do some stuff that’s going to make it slow like the endto-end model inference slower but uh agents are not humans and they will do plenty of things to make it slower like they’ll disable CUDA graphs which can make it 20 times slower and they might make that one kernel faster but make the whole like it’s not a viable kernel because it’s they’re disabling a bunch of speed ups like CUDA graphs or only testing on small context windows and so a lot of this is also just defining what not to do which is actually very important when you’re doing frontier work that agents can’t actually easily with a one shot.

[04:56] Uh, another reward hack is that some models just don’t actually write the cute DSL you need uh when you’re trying to write kernels. And this is a common problem with enthropic models. And so, yeah, I mean, Anthropic says what they say about uh nerfing models. You can it’s guess if it’s I’m guessing if it’s nerfing or not, but I would recommend using a different model. Uh, and it won’t always be faster everywhere actually. So sometimes the kernels you come up with might only work well on like zero to 100k and then you need to go back to this the default kernel that you could you get from like a flash infer cutless. Um and so and that’s another thing to look out for is that

[05:29] your kernel isn’t always just a swap in for all all workloads. Uh but one of the great things is is that kernels compound. So like if you make one for your sparse MLA for deepseek for example um you can get speed ups there and you just stack them on like that then plus NVFP4 fore uh you could do for us if we if you don’t have NVL link you just keep stacking and stacking and stacking and then eventually you taper off at whatever the hardware limit is uh for your GPU and that’s uh some people call this like MFU which is like the actual theoretical max utilization from a GPU.

[06:01] Uh and so to go even farther, if you have actually have bare metal access, your auto research framework can uh do very hacky things. So hackers that have hacked with GPUs are probably going to like this. You can uh tweak your BIOS settings, you can overclock the GPU, uh you can force like PCIe relaxing, all these little tweaks of like uh old school hackers used to do, but this can actually help with inference as well. And so net on bare metal optimizations, you can get roughly 25% over like a virtualized setup you get from using a cloud provider. Uh so once you’ve done that, you can

[06:33] combine all of the kernels you did as well as all of the hardware level hacks you did. Uh you can get a 3x speed up. And so I know this this might all sound like roses and flowers, but it’s not actually the case. Around 80% of the things that auto research is going to do are going to be bad. Uh so it’s important to remember while you’re u like working on this that most things are going to be bad. It’s going to try to trick you all the time. Uh but at the end you can actually get really good results from this. with TLDDR. Uh have better ideas than use auto research. Super simple. Simple, right? Uh so it turns out you can actually get

[07:05] paid to do this. Uh if you think this is cool, consider joining us and you can email me here. Thanks, guys.