Esta nova arquitetura de IA toma decisões 13 vezes mais rápido

Ver no idioma original →

Autoria: Prompt Engineering · 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: This New AI Architecture Makes Decisions 13x Faster · Canal: Prompt Engineering · 16:22 · Assistir no YouTube

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

Resumo

O vídeo apresenta o CLM, uma arquitetura contrastiva que transforma a escolha de ações em uma comparação entre a representação de uma situação e representações pré-computadas das opções. Como as opções podem ser codificadas uma vez e armazenadas em cache, a latência quase não aumenta mesmo quando há centenas de candidatos. Demonstrações em um DGX Spark mostram usos em classificação de tickets, seleção de ferramentas e navegação por links, além de limitações de precisão quando as opções são numerosas ou parecidas. O apresentador sugere usar o CLM para reduzir uma lista de candidatos e deixar um modelo mais cuidadoso tomar a decisão final.

Pontos-chave

• O CLM codifica uma situação e cada ação em espaços de embedding e pontua as ações pela proximidade com a situação.
• As opções podem ser codificadas uma vez e armazenadas em cache, reduzindo o custo de chamadas subsequentes.
• No teste citado, com 1.024 opções, o CLM levou 44 milissegundos, contra 570 milissegundos do Jev.
• O treinamento contrastivo usa exemplos positivos e negativos; uma etapa com hard negatives melhora a distinção entre respostas plausíveis, mas incorretas.
• O backbone de 8 bilhões de parâmetros permanece congelado, enquanto pequenas heads de cerca de 20 milhões de parâmetros são treinadas.
• Nas demonstrações do apresentador, a precisão caiu de 86% com oito ferramentas para 17% com 1.080 ferramentas.
• Como cada opção é avaliada individualmente, o CLM não compara diretamente as opções entre si e pode confundir alternativas semelhantes.
• Uma aplicação proposta é usar o CLM para reduzir rapidamente milhares de opções a uma lista curta e então recorrer a um modelo que avalie as opções em conjunto.

Capítulos

Início	Capítulo	Resumo
00:00	O que é o CLM	O vídeo apresenta o CLM como uma arquitetura contrastiva para selecionar ações e explica sua relação com o CLIP.
03:22	Treinamento contrastivo e velocidade	O apresentador explica o uso de exemplos positivos e negativos e como o cache de opções reduz a latência.
06:34	Treinamento em etapas e escala	O vídeo aborda as limitações de comparar opções separadamente e descreve as etapas de treinamento e o backbone congelado.
09:48	Demonstrações no DGX Spark	O apresentador demonstra classificação de tickets, respostas a perguntas e seleção entre mais de mil ferramentas.
12:36	Precisão e limites com muitas opções	Os testes mostram que a latência escala bem, mas a precisão cai quando há muitas opções parecidas.
14:43	Como usar o CLM e perspectivas	O apresentador propõe usar o CLM para pré-selecionar candidatos e comenta a possível volta de métodos contrastivos.

Citações

O modelo mental mais simples é o CLIP, mas para decisões. — 01:39

Estamos falando de cerca de treze vezes mais rápido. — 06:03

Eles transformaram a decisão em recuperação: codificam a situação e então procuram a ação. — 14:11

Deixe o CLM reduzir mil ferramentas ou candidatos às dez melhores em milissegundos. — 14:43

Conceitos e entidades

• CLM (modelo): Arquitetura contrastiva que representa situações e ações separadamente e pontua as ações candidatas pela proximidade com a situação.
• Jev (modelo): Modelo usado no vídeo como referência para comparar a velocidade e a precisão do CLM.
• CLIP (modelo): Modelo mencionado como analogia por mapear imagens e textos em um mesmo espaço de embedding.
• Stanford (empresa): Instituição cuja equipe de pesquisa, junto com pesquisadores da Nvidia, é creditada pelo CLM.
• NVIDIA (empresa): Empresa cujos pesquisadores participaram do desenvolvimento do CLM e cujos dados NeMo Nemotron são citados no treinamento.
• DGX Spark (ferramenta): Sistema em que o apresentador executa as demonstrações do CLM.
• Qwen3 (modelo): Modelo usado como encoder congelado nas demonstrações e no treinamento descritos no vídeo.
• vLLM (ferramenta): Software usado para servir o encoder Qwen3 nas demonstrações.
• Gemini (modelo): Modelo usado para gerar hard negatives durante uma das etapas de treinamento do CLM.
• RTX 4090 (ferramenta): GPU citada como o hardware em que uma execução completa de pré-treinamento levou cerca de uma hora.
• aprendizado contrastivo (conceito): Método de treinamento que aproxima representações de situações e ações corretas e afasta as de ações incorretas.
• hard negatives (conceito): Exemplos de respostas plausíveis, mas erradas, usados para ensinar o modelo a distinguir semelhança de correção.
• System 1 e System 2 (conceito): Distinção apresentada entre decisões rápidas e não raciocinadas e decisões mais cuidadosas.

Tradução completa (pt-BR)

00:00 Com o lançamento do Jeff, agora todo mundo está falando de modelos system one. Modelos que não pensam nem raciocinam de repente estão em alta de novo. E a ideia faz muito sentido. A maioria das decisões dentro de softwares reais não precisa de um modelo pensando por 30 segundos. Coisas como: qual ferramenta deve ser executada em seguida? Este ticket é urgente? Qual link o agent deve clicar? Você quer essas respostas em milissegundos, e não em segundos ou minutos. Já vimos várias réplicas open source do Jeff, ou que afirmam ser.

00:33 Mas a maioria delas ainda é formada por modelos de linguagem por baixo dos panos. Ele lê seu texto, lê cada opção e, depois, escreve uma resposta. Mesmo que a resposta seja apenas uma palavra com alguma probabilidade associada a ela. Agora, nesta semana, surgiu um novo modelo com uma arquitetura bem diferente. Ele se chama modelo de linguagem contrastivo, ou CLM. Ele vem de uma equipe de pesquisa de Stanford e da Nvidia. E é extremamente diferente de tudo que vimos até agora. Eles estão fazendo algumas afirmações ousadas, dizendo

01:09 que ele é até nove vezes mais rápido que o Jeff, com precisão equivalente. Mas não estou fazendo este vídeo para comparar diretamente com o Jeff. O que torna esse modelo interessante é como ele foi desenvolvido e em que escala. É um modelo de 8 bilhões de parâmetros, do mesmo tamanho de muitos desses clones. Agora, o interessante é que a velocidade não vem de tornar o modelo menor. Na verdade, ela vem da maneira como ele foi projetado e arquitetado. Então, neste vídeo, quero não só explicar

01:39 em que ele é diferente, como foi desenvolvido e o que há de interessante nele, mas também mostrar uma demonstração funcional rodando em um DGX Spark. Certo, então o que exatamente é um CLM? A analogia mental mais simples é o CLIP, mas para decisões. Se você se lembra do CLIP, ele coloca imagens e texto no mesmo espaço de embedding. Por exemplo, a foto de um cachorro fica bem ao lado das palavras “uma foto de um cachorro”. O CLM faz o mesmo com situação e ação. Há um encoder de estado, que lê o que está acontecendo agora,

02:15 e um encoder de ação, que lê o que você poderia fazer. Imagine o Mario com um Goomba caminhando em sua direção. O estado é a tela do jogo, e as ações são ir para a esquerda, pular ou correr para a direita. Para tomar uma decisão, você gera o embedding do estado, gera o embedding de cada opção e pontua cada opção de acordo com o quanto ela fica próxima daquele estado. Depois, aplica um softmax a essas pontuações e obtém uma probabilidade para cada ação. Por exemplo, pular pode receber 80%, ir para a direita pode receber 15%,

02:49 ir para a esquerda pode receber 5% e, nesse caso, Mario vai pular. Eles o projetaram para que ele fale a mesma API do Jev. Assim, você tem três primitivas diferentes: uma pergunta de sim ou não, uma pergunta de múltipla escolha e uma pontuação. Agora, por baixo dos panos, todas essas coisas são exatamente iguais: um estado mais uma lista fechada de candidatos. Sim ou não são apenas dois candidatos: verdadeiro e falso. Certo, então o que isso significa para você, que está desenvolvendo? Assim como o Jev, ele nunca pode inventar uma resposta que não esteja na lista. Mas,

03:22 ainda pode escolher a resposta errada dessa lista. E, quando isso acontece, pode fazê-lo com confiança. Essa é a mesma linha que o Type-Safe usou: o Jev nunca pode alucinar. Isso também é verdade para o CLM. Mas isso não significa que ele esteja sempre certo. Então, como fazer com que a ação correta fique mais próxima? A solução é treiná-lo de forma contrastiva. O treinamento começa com muitos exemplos. Cada um é um par: uma situação e uma

03:55 ação que alguém realmente realizou. Vamos usar o exemplo do jogo do Mario. Mario vê um Goomba, e o jogador precisa pular. Agora, a tarefa do modelo é simples: colocar cada situação perto da ação correspondente e longe de todas as outras ações. Se você fizer isso milhões de vezes, cada situação acaba ficando bem ao lado dos movimentos que combinam com ela. É assim que você treina o modelo. Agora, aqui está o truque legal. Você não precisa

04:27 de ninguém para escrever as respostas erradas. Veja só: você pega mil exemplos de uma vez. Para a tela do Mario, pular é a resposta certa. E as outras 999 ações daquele arquivo pertencem a outras situações. Então, elas são automaticamente respostas erradas para esta situação. E isso é essencial para o aprendizado contrastivo. Você quer exemplos positivos e negativos e, nesse caso, está recebendo esses exemplos negativos totalmente de graça. Certo, é daqui que vem a velocidade.

04:59 Com um modelo no estilo do Jeff, o estado e todas as opções entram juntos no modelo em cada chamada. Agora, se você dobrar o número de opções ou torná-las mais longas, vai acabar precisando ler o dobro. Você vai precisar decodificar a resposta token por token a partir de um LLM grande, o que fica muito caro muito rápido. No gráfico deles, a decodificação restrita com 238 bilhões chega a mais de 4 segundos. O CLM

05:30 separa as duas coisas. Na maioria dos ciclos de agent, as ações não mudam de uma etapa para outra. O estado é que muda. Então, a ideia é gerar o embedding das ações uma vez e armazená-lo em cache. Cada nova etapa custa um embedding para o estado, mais um produto escalar para as opções — e, neste caso, um produto escalar é praticamente uma computação gratuita. Na demonstração deles com Mario, isso reduz cada etapa de cinco passagens forward para uma. Agora, dá para ver isso neste gráfico. À medida que

06:03 o número de candidatos vai de um a mil, a linha do CLM quase não se move. Com quase 1.024 opções, ele leva 44 milissegundos, contra 570 milissegundos do Jeff. Então, estamos falando de cerca de 13 vezes mais rápido. Agora, no meu vídeo sobre system one versus system two, eu disse que system one escala em largura. Muitas perguntas pequenas respondidas ao mesmo tempo. O CLM leva isso quase tão longe quanto

06:34 é possível. Com mil opções pelo preço aproximado de uma. Mas há uma ressalva. E é a clássica troca envolvida nesse tipo de arquitetura com dois encoders. Como o estado é codificado sozinho, ele nunca vê as opções. Não pode colocá-las lado a lado e compará-las. Cada opção é avaliada individualmente, por si só. Isso é um grande problema. Vamos falar disso em um minuto. Mas você pode estar pensando: já temos modelos de embedding, então por que não simplesmente

07:07 usá-los? Eis o motivo. Se você perguntar a embeddings do Aquaint 38 quem escreveu Romeu e Julieta, William Shakespeare aparece em terceiro lugar, embora devesse ser a resposta certa. Então, ser parecido não é o mesmo que estar certo. Depois do treinamento do CLM, Shakespeare fica em primeiro lugar. E tudo se resume à maneira como esse modelo é treinado. O treinamento acontece em três etapas diferentes. A etapa um usa 60 milhões de pares de perguntas e respostas dos dados NeMo tron da Nvidia.

07:39 A pergunta é o estado, e a resposta é a ação. É aí que ele aprende conhecimentos gerais sobre o mundo. A etapa dois é onde a coisa fica interessante. Eles usaram o Gemini para gerar 30 milhões de exemplos negativos difíceis. São respostas próximas, mas erradas. Coisas como Vênus em vez de Mercúrio para o planeta mais próximo do Sol. Isso é importante porque ensina ao modelo a diferença entre “parece certo” e “está certo”. E a ordem realmente importa. Em um teste cheio

08:13 de exemplos negativos difíceis, só o pré-treinamento chega a 52%. Quando acrescentam a etapa de exemplos negativos difíceis, o resultado sobe para 69%. Mas, se você treinar com exemplos negativos difíceis desde o primeiro dia, o resultado chega ao máximo de apenas 62% e, depois, o modelo começa a sobreajustar. Então, primeiro você aprende sobre o mundo e, depois, as distinções sutis. É como o pré-treinamento seguido do pós-treinamento. Agora, a etapa três transforma isso em um agent. São cerca de um milhão de etapas de trajetórias reais de agent, em que cada etapa é algo como “aqui está meu contexto e aqui está o que fiz”. Depois, misturam de volta 40% dos dados originais de perguntas e respostas. Sem essa repetição, as pontuações nos exemplos negativos difíceis caem de 69 para 56. Agora, aqui está a parte que realmente me surpreendeu. O modelo de 8 bilhões fica congelado. É só um Qwen3 8B usado como leitor, e agora ele recebe um único gradiente. A única coisa que é treinada é

08:44 trajetórias de agent, em que cada etapa é algo como: “este é meu contexto e foi isso que fiz”. E então misture de volta 40% dos dados originais de QA. Sem essa repetição, as pontuações dos negativos difíceis caem de 69 para 56. Agora, aqui está a parte que realmente me surpreendeu. O modelo de 8 bilhões está congelado. É apenas um Qwen 3 HP usado como leitor, e agora recebe um único gradiente. A única coisa que é treinada é

09:15 uma cabeça pequena de cada lado, com cerca de 20 milhões de parâmetros. Como o backbone nunca muda, você gera embeddings do conjunto de dados inteiro uma única vez e, depois disso, uma execução completa de pré-treinamento leva cerca de uma hora em uma única RTX 4090, o que é meio incrível. E o sistema escala de forma previsível. A perda segue uma lei de potência em relação à computação e aos dados, ao tamanho da cabeça e ao tamanho do encoder. O tamanho do encoder traz os maiores ganhos entre os quatro fatores. Então, o próximo passo óbvio é um backbone maior,

09:48 e eles dizem que um CLM multimodal chega no início do próximo mês. Certo, chega de teoria. Agora, vou mostrar como isso funciona em um único DGX Spark. Certo, vou mostrar algumas das minhas demonstrações. Tudo isso está rodando em um DGX Spark. Ele está executando o encoder Qwen de 3,8 bilhões de parâmetros, servido por meio do vLLM. Por cima dele fica o servidor CLM que a equipe realmente lançou. O servidor em si tem cerca de 75 MB, mas o conjunto todo ocupa cerca de 25 GB de memória. Eu forneço a ele um

10:21 estado — neste caso, um chamado de suporte de um cliente que foi cobrado duas vezes e não consegue falar com ninguém. Então, fiz três perguntas tipadas em uma única chamada: isso é urgente? Qual equipe deve cuidar disso? E quão frustrado está o cliente? E dá para ver que cada resposta vem como uma probabilidade. A probabilidade de ser urgente é de 84%. A de ser da equipe de cobrança é de 99%. A frustração é de muita raiva, certo? E, depois que ele vê esse chamado, se eu perguntar de novo, a resposta vem

10:53 em menos de 2 milissegundos, porque tudo fica em cache. Essa é uma das vantagens: se você fornecer a ele essa lista de opções ou esse conjunto de ferramentas, tudo será armazenado em cache e as respostas seguintes serão extremamente rápidas. Agora, lembram do exemplo de Romeu e Julieta que mencionei no começo? Temos o mesmo encoder, os mesmos candidatos, e a única diferença é aquela pequena cabeça por cima, certo? Com os embeddings brutos do Qwen, Christopher Marlowe vem primeiro e Shakespeare, em segundo. Agora, se mudarmos para CLM, a probabilidade de Shakespeare salta para

11:28 98%. Então, aqueles 20 milhões de parâmetros de treinamento realmente remodelam o espaço, fazendo com que ele passe de similar para correto. Agora, com esta demonstração, a arquitetura realmente se destaca. Criei uma lista de 1.080 ferramentas, coisas como Stripe, Twilio, QuickBooks e assim por diante. Para dar uma ideia, Jev limita a escolha a 255 opções. Então, isso nem caberia em uma única chamada, certo? Agora, a primeira solicitação leva alguns segundos, porque o CLM

12:00 gera embeddings de cada ferramenta uma vez. Mas, depois disso, cada nova solicitação leva cerca de 80 milissegundos. E aqui está a parte de que gosto muito: escolher entre uma ferramenta ou entre 1.000 ferramentas basicamente leva o mesmo tempo, depois que tudo está em cache. Agora, esta é divertida. O código do Wiki racing não foi lançado, então eu o reconstruí por conta própria. Você começa em uma página da Wiki e precisa chegar a um destino clicando em links. Neste caso, é de tectônica de placas a bioluminescência.

12:36 Em cada página, o CLM dá uma pontuação a todos os links, de acordo com o quanto aproximam do destino. Neste caso, estamos falando de 934 links nesta primeira página, todos avaliados de uma só vez. Então, ele escolhe biosfera e, depois, bioma. Na página de plantas, a bioluminescência aparece em primeiro lugar, com 58%, certo? Basicamente, foram cerca de quatro cliques. Na demonstração deles, acho que relataram cerca de seis cliques. Então, isso é

13:06 realmente impressionante. Então, eis o que concluí com meus experimentos com o CLM. Ele escala muito bem com a computação. O número de opções quase não altera a latência, porque as opções recebem embeddings uma vez e depois ficam em cache. Agora, o que não escala da mesma forma é a precisão. À medida que o número de opções aumenta, a precisão cai. Com oito ferramentas para escolher, ele selecionou a correta em 86% das vezes nos meus experimentos. Mas, com todas as 1.080 ferramentas,

13:36 a precisão caiu para 17%. Principalmente porque ele confundiu ferramentas com nomes parecidos, como várias ferramentas diferentes para reembolsos. A mesma coisa aconteceu no Wiki racing. Em algumas corridas, ele acerta; em outras, se perde. E esse é o problema de que falamos antes. Cada opção é codificada separadamente, então ele nunca pode compará-las lado a lado. Além disso, alguns desses exemplos que testei eram um pouco extremos. Você não vai querer disponibilizar 1.000 ferramentas para um agent escolher. Provavelmente, vai querer

14:11 criar subagents, cada um com um conjunto diferente de ferramentas disponíveis. No geral, acho que essa é uma direção muito interessante para modelos de sistema um. Eles transformaram a decisão em recuperação: basicamente, codificam a situação e depois buscam a ação. E isso faz com que mil opções custem quase o mesmo que uma em termos de latência, pelo menos. Certo. Então, como desenvolvedor, eu usaria isso hoje como uma primeira etapa. A ideia seria

14:43 deixar o CLM reduzir mil ferramentas ou candidatos às dez melhores em milissegundos e, depois, deixar um modelo que lê as opções em conjunto tomar a decisão final. Assim, os modelos de pensamento rápido, ou de sistema um, são usados para criar listas curtas, e as decisões cuidadosas ficam a cargo do sistema dois. E, se o seu conjunto de ações já for pequeno e estável, como em um loop de jogo ou em algumas rotas, isso funciona muito bem. Agora, esta

15:15 versão é apenas de texto, mas está a caminho um modelo de 35 bilhões de parâmetros, que deve ser multimodal. Pessoalmente, tenho interesse nisso porque a curva de escalabilidade deles indica que um encoder maior é onde estão os ganhos, e um encoder maior é exatamente o que deve ajudar a distinguir opções parecidas. Vai ser muito interessante ver como isso se desenvolve. Mas, perto do fim, quero compartilhar uma ideia. Sinto que algoritmos antigos estão voltando. Os modelos de sistema um

15:49 basicamente são modelos rápidos, sem raciocínio, e isso voltou a torná-los populares. Com isso, estão trazendo de volta as máquinas de aprendizado contrastivo, ou os algoritmos contrastivos, que estavam muito em alta em 2017 e 2018. Então, acho que eles também estão voltando. Estou bem animado com isso, porque não acho que tenhamos levado os algoritmos existentes até seus limites. Enfim, contem o que acham: o que pensam sobre modelos de sistema um e sistema dois, e que tipo de aplicações veem nos próprios

16:22 workflows. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, até o próximo.

Transcrição original

[00:00] With the release of Jeff, everybody now is talking about system one models. Non-thinking, non-reasoning models are suddenly hot again. And the idea makes a lot of sense. Most of the decisions inside real softwares don’t need a model to think for 30 seconds. Things like which tool should run next? Is this ticket urgent? Uh which link should the agent click? You want those answers in milliseconds rather than seconds or minutes. We have already seen quite a few open-source replications of Jeff or ones

[00:33] that claim to be. But most of them are still language models under the hood. It reads your text, reads every single option, and then writes out an answer. Even if the answer is just a single word with some probability associated with it. Now, this week a new one landed with a very different architecture. It’s called a contrastive language model or CLM. This is from a team at Stanford and Nvidia research. And it’s extremely different than what we have seen so far. They’re making some bold claims, saying

[01:09] up to nine times faster than Jeff or on par in accuracy. But I’m not making this video to do a head-to-head with Jeff. What makes this model interesting is how it’s built and the scale it’s built at. It’s a 8 billion parameter model, the same size as a lot of those clones. Now, the interesting part is that the speed does not come from making the model smaller. It actually comes from the way it is designed and architected. So, in this video, not only I want to explain

[01:39] how this is different, how it’s built, and what’s interesting about it, but I’ll also show you a working demo of this running on a DGX Spark. Okay, so what exactly is a CLM? The easiest mental model is CLIP, but for decisions. If you remember CLIP, it puts images and text into the same embedding space. For example, a photo of a dog lands right next to the word a photo of a dog. CLM does the same thing with situation and action. There’s a state encoder which reads what’s going on right now

[02:15] and an action encoder which reads what you could do. Take Mario with a Goomba walking towards him. The state is the game screen and the actions are left, jump, or run right. To make a decision, you embed the state, embed every option, and score each option by how close it lands to that state. Then, you run a softmax over those scores and you get a probability for every action. For example, things like jump gets 80%, right might get 15%,

[02:49] left might get 5%, and in that case, Mario is going to jump. They have designed it such that it speaks the same Jevs API. So, you get three different primitives, a yes/no question, a multi-choice question, and a score. Now, all of these things are exactly the same underneath, a state plus a closed list of candidates. Yes/no is just two candidates, true and false. Okay, so what this means for you as a builder? Now, just like Jev, it can never invent an answer that is not on the list. But,

[03:22] it can still pick the wrong answer from that list. And when it does, it can do that confidently. That is the same line which Type-Safe used that Jev can never hallucinate. It’s true for CLM as well. But, it doesn’t mean it’s always right. So, how do you get a space where the right action actually lands closest? The solution is to train it contrastively. Training starts with a lot of examples. Each one is a pair, a situation, and an

[03:55] action somebody actually took. Uh let’s take the example of the Mario game. So, Mario sees Goomba, and the player has to jump. Now, the model job is simple. Put each uh situation close to its own action and far away from every other action. Now, if you do that millions of times, in the situation ends up sitting right next to the moves that fit them. That’s how you train the model. Now, here’s the nice trick. You don’t need

[04:27] anyone to write down wrong answers. See, you grab 1,000 examples at once. For Mario screen, jump is the right answer. And the other 999 actions in that file belong to other situations. So, they’re automatically wrong for this one. And this is essential for contrastive learning. You want both positive and negative examples, and in this case, you are getting those negative examples for absolutely free. Okay, so here’s where the speed comes

[04:59] from. With a Jeff style model, uh the state and all the options go into the model together on every single call. Now, if you double the options or make them longer, you’re going to end up need to read twice as much. You are going to need to decode the answer token by token out of a uh large language model, which gets really expensive really quickly. On their chart, constrained decoding with 238 billion climbs to over 4 seconds. CLM

[05:30] splits them apart. In most agent loops, the actions don’t change from step to step. The state changes. So, the idea is that you embed the actions once and cache them. Each new step costs one embedding for the state plus a dot product for options and a dot product in this case is essentially free computation. In their Mario demo, uh that takes each step from five forward passes down to one. Now, you can see it in this chart. As

[06:03] the number of candidates goes from one up to a thousand, CLM’s line barely moves. At almost a thousand twenty-four options, it’s forty-four milliseconds against five hundred and seventy milliseconds for Jeff. So, we’re looking at about thirteen times faster. Now, in my system one versus system two video, I said system one scales in width. Uh lots of small questions answered at once. Now, CLM pushes that about as far as it

[06:34] will go. With a thousand options for roughly the price of one. But, there’s a catch. And it’s the classic trade-off with this kind of two encoder design. Because the state is encoded on its own, it never sees the options. It cannot lie them side by side and compare them. Each option is judged on its own individually. Now, this is a big problem. We’re going to talk about it in a minute. But, you might be thinking, we already have embedding models, so why not just

[07:07] use those? Now, here’s why. If you ask plain Aquaint 38 embeddings who wrote Romeo and Juliet, and William Shakespeare actually comes in in third, which is supposed to be the right answer. So, similar is not the same as right. After CLM’s training, Shakespeare comes first. And it all comes down to how this model is trained. It’s trained in three different stages. Stage one is sixty million question answer pairs from Nvidia’s NeMo tron data.

[07:39] Uh the question is the state and the answer is the action. That’s where it learns general knowledge about the world. Stage two is where it gets interesting. They used Gemini to generate 30 million hard negatives. These are the answers that are close, but wrong. Things like Venus instead of Mercury for the planet closest to the sun. Now, this is important because this is what teaches the model the difference between sounds right and is right. And the order really matters. On a test full

[08:13] of hard negatives, pre-training alone gets 52%. Now, when they add the hard negative stage on top, it actually jumps to 69%. But, if you train on hard negatives from day one, it simply peaks at 62% and then starts overfitting. So, you learn the world first and then the fine distinctions second. This is like pre-training and then post-training. Now, stage three turns it into an agent. That’s about a million steps of real

[08:44] agent trajectories, where each step is um something like here’s my context and here is what I did. And then mix 40% of the original QA data back in. Without that replay, the hard negative scores fall from uh 69 to 56. Now, here’s the part that actually kind of surprised me. The 8-billion model is frozen. It’s just a queen 3 HP used as a reader, and it now gets a single gradient. The only thing that trains is

[09:15] a small head on each side, which are about 20 million parameters. Because the backbone never changes, you embed the whole data set once, and after that, a full pre-training run takes about an hour on a single RTX 4090, which is kind of incredible. And it does uh scale predictably. The loss follows a power law in compute and data, in head size, and in encoder size. Encoder size gives the biggest gains of the four. So, the obvious next step is a bigger backbone,

[09:48] and they say a multimodal CLM is coming early next month. Okay, that’s enough theory. Now, let me show you how it works on a single DGX Spark. Okay, let me show you some of my demos. So, all of this is running on a DGX Spark. It’s running the Quinn 3.8 billion encoder served through VLLM. On top of that sits the CLM server that the team actually released. And now, the server itself is about 75 MB, but the whole thing takes about 25 GB of memory. I give it a

[10:21] state, in this case, a support ticket from a customer who got charged twice and can’t reach anyone. Then I asked three typed question in one call. Is this urgent? Which team should handle it? And how frustrated is the customer? And you can see every answer comes back as a probability. Urgent has 84% probability. Billing has 99%. Frustration is very angry, right? And once it’s seen this ticket, asking again comes back

[10:53] under 2 milliseconds because everything is cached. So, this is one of the beauties, like if you provide it with this list of options or set of tools, everything is going to be cached and the subsequent responses going to be extremely fast. Now, remember the Romeo and Juliet example that we mentioned in the beginning? We have same encoder, same candidates, and the only difference is that uh that small head on top, right? So, with raw Quinn embeddings, uh Christopher Marlowe comes first and Shakespeare second. Now, if we switch to CLM, Shakespeare’s probability jumps to

[11:28] 98%. So, those uh 20 million parameters of training really do reshape the space from similar to right. Now, with this demo, the architecture actually really shows up. So, I built a list of 1,080 tools, things like Stripe, Twilio, uh QuickBooks, and so on. So, for contacts, Jev caps a choice to 255 options. So, this won’t even fit into a single call there, right? Now, the first request takes a few seconds because CLM

[12:00] embeds every tool once. But, after that, every new request takes about 80 milliseconds. And here’s the part that I love. Picking from one tool or uh from 1,000 uh it’s going to basically cost you the same amount of time when it’s once it’s cached. Now, this one is a fun one. Wiki racing code is not released, so I rebuilt it myself. You start on one Wiki page, and you have to reach a target by clicking links. So, here it’s plate tectonics to bioluminescence.

[12:36] On every page, CLM scores every single link towards the target. We are In this case, we’re talking about 934 links on this first page, all scored in one go. Then it picks biosphere, then biome, then plant con on the plant con page bioluminescence comes up first at 58% right? Basically, took about four clicks. In their own demo, I think they reported around six clicks. So, this is

[13:06] actually pretty impressive. So, here’s what I took away from my experiments with CLM. It actually scales beautifully with compute. The number of options barely changes the latency because the options are embedded once and then cached. Now, what does not scale the same way is accuracy. As the number of options grow, so with eight tools to choose from, it picked the right ones 86% of the time in my experiments. But, with all 1,080 tools,

[13:36] that actually dropped to 17%. Mostly because it confused tools that sounded alike, like several different refund tools. Now, the same thing showed up in the Ubi Key racing. So, some races it nails, others it wanders off. And that’s the catch we talked about earlier. Each option is encoded on its own, so it never gets to compare them side by side. Also, some of these examples that I tried were a little extreme. You do not want to be putting 1,000 tools for a agent to select from. You probably want

[14:11] to create sub-agents where you have a different set of tools available to each sub-agent. So, overall, I think it’s a very interesting direction for system one models. They have turned the decision into retrieval, which basically encodes the situation, then looks up the action. And that makes a thousand options cost about the same as one in terms of latency, at least. Okay. So, as a builder, the way I would use this today is as a first stage. So,

[14:43] the idea would be let CNN cut thousand tools or candidates down to top 10 in milliseconds, then let a model that reads the option together make the final call. So, here, the fast thinking or system one models are used as short lists, and then careful decisions are going to be followed by system two. And if your set of actions is already small and stable, like a game loop or a handful of routes, it actually works pretty well. Now, this

[15:15] version is text-only, but there’s a 35 billion parameter model coming up, which is supposed to be multimodal. Now, I’m personally interested in that because their scaling curve says a bigger encoder is where the gains are, and a bigger encoder is exactly what should help it tell similar options apart. So, it’s going to be very interesting to see how that shapes up. But, towards the end, I actually want to share this thought. I feel like older algorithms are making a comeback. System one models

[15:49] basically are fast, non-reasoning models which have made them hot again. And with this, they’re actually bringing back contrastive learning machines or contrastive algorithms, which were really hot in 2017-2018. So, I think they are also making a comeback. I’m actually pretty excited about it because I don’t think we have actually pushed the limits of existing algorithms. Anyways, do let me know your thoughts, how you think about system one and system two models, and what type of applications that you see in your own

[16:22] workflows. Anyways, I hope you found this video useful. Thanks for watching, and as always, see you in the next one.