CLM-8B vs Jev: o que a demonstração de velocidade 9× realmente mostra

Autoria: Prompt Engineer 48 · 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: CLM-8B vs Jev: What the 9× Speed Demo Actually Shows · Canal: Prompt Engineer 48 · 08:56 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Modelos de IA, Modelos locais e open source

Resumo

CLM é um modelo de decisão que pontua ações candidatas em vez de gerar respostas em texto; na demonstração apresentada, foi cerca de nove vezes mais rápido que Jev em uma tarefa, mas isso não prova desempenho equivalente. Em testes próprios, CLM escolheu opções razoáveis em situações simples, porém continuou selecionando uma ação quando a opção correta não estava disponível. Sua arquitetura pode ser especialmente rápida quando as ações possíveis se repetem, pois permite pré-calcular e armazenar em cache as representações dessas ações. Os resultados publicados pela equipe incluem diferenças de desempenho entre tarefas e configurações, então o vídeo recomenda testar o modelo nos próprios dados e criar mecanismos de abstenção e segurança.

Pontos-chave

CLM recebe um estado e uma lista de ações candidatas e atribui uma pontuação ou probabilidade a cada uma; não é um modelo de chat para gerar respostas.
O teste próprio do vídeo encontrou escolhas plausíveis em casos simples, mas não constitui uma avaliação abrangente de confiabilidade.
Quando a ação correta foi removida das opções, CLM ainda escolheu uma das alternativas disponíveis, em vez de indicar que nenhuma era adequada.
A arquitetura separa a codificação do estado e das ações; ações repetidas podem ser pré-computadas e armazenadas em cache.
O ganho de velocidade depende, em parte, de usar um conjunto conhecido e recorrente de ações; há menos oportunidade de reutilização quando cada ação é diferente.
Segundo a avaliação publicada pela equipe, CLM foi mais rápido nas quatro tarefas mostradas, mas Jev teve resultados melhores em algumas delas.
Na demonstração do jogo de dinossauro, um safety shield podia substituir as escolhas do modelo; sobreviver às rodadas não prova que os modelos tomaram decisões independentes igualmente boas.
Os resultados de tarefas de programação citados envolvem um modelo forte que gera soluções candidatas e um CLM fine-tuned que atua como verificador, não apenas o modelo geral lançado.
O vídeo recomenda incluir uma opção explícita de abstenção quando necessário, medir erros em dados próprios e manter um modelo generativo ou de raciocínio para outras tarefas.

Capítulos

Início	Capítulo	Resumo
00:00	O que CLM faz e como foi testado	O vídeo apresenta a comparação de velocidade com Jev, explica o papel de CLM como modelo de decisão e descreve o teste próprio com o encoder e o checkpoint lançados.
02:05	Testes de roteamento e o limite das opções	O apresentador mostra escolhas plausíveis em casos simples e um caso em que CLM seleciona uma opção inadequada porque não havia uma rota de abstenção.
04:09	Arquitetura, cache e treinamento	A separação entre estados e ações explica a possibilidade de reutilizar vetores, enquanto as etapas de treinamento buscam melhorar a distinção entre respostas corretas e plausíveis, mas erradas.
06:16	Comparação de desempenho e interpretação das demonstrações	Os resultados publicados mostram vantagem de velocidade para CLM, mas Jev supera o modelo em algumas tarefas, e a proteção do jogo limita o que se pode concluir sobre as decisões independentes.
08:24	Onde testar CLM e quais proteções usar	O apresentador considera CLM promissor para decisões entre opções bem definidas e recomenda testar em dados próprios, permitir abstenção e manter modelos generativos para outras tarefas.

Citações

Nesta execução, Jev é cerca de nove vezes mais lento. — 00:00

Se você quer uma rota de abstenção, precisa projetá-la e testá-la. — 03:39

As descrições das ações não mudam; por isso, seus vetores podem ser calculados uma vez e armazenados em cache. — 04:41

Não interprete uma probabilidade softmax alta como prova de que uma opção ausente é segura. — 08:24

Conceitos e entidades

CLM 8B (modelo): Modelo de decisão que pontua ações candidatas usando um encoder e uma cabeça de projeção treinada para esse tipo de comparação.
Jev (modelo): Modelo de decisão da Type Safe usado como referência de velocidade e desempenho na comparação.
TypeSafe (empresa): Equipe responsável pelo Jev e pela avaliação publicada que inclui comparações com CLM.
Qwen3 8B (modelo): Encoder de 8 bilhões de parâmetros usado para codificar os estados no setup de referência descrito no vídeo.
RunPod (ferramenta): Plataforma na qual o apresentador executou o modelo em uma GPU A40 temporária.
aprendizado contrastivo (conceito): Método de treinamento que aproxima representações de pares corretos de estado e ação e afasta pares incompatíveis.
Safety shield (conceito): Mecanismo que identifica movimentos seguros e inseguros e pode substituir uma escolha do modelo.
BFCL (conceito): Avaliação de tool calling citada na comparação publicada entre CLM e Jev.
Apache License 2.0 (conceito): Licença sob a qual, segundo o vídeo, o código e a cabeça do modelo CLM são disponibilizados.

Tradução completa (pt-BR)

00:00 Então, olhe para isto. Na parte de cima, um modelo chamado CLM está jogando o jogo do dinossauro. Na parte de baixo está Jev, o novo decision model da Type Safe. O site do CLM responde em cerca de 16 milissegundos. Jev leva cerca de 150, ou seja, é aproximadamente nove vezes mais rápido nesta execução. Mas eis a pergunta que realmente me interessa: se eu der uma decisão a esse modelo dentro do meu próprio agent, ele escolherá a ação certa? E, quando a ação certa não estiver disponível, ele vai perceber? Baixei o código, executei o modelo lançado em uma GPU da RunPod,

00:32 e testei exatamente isso. Depois, analisei os números por trás desse lançamento, porque a demonstração tem um detalhe que muda a forma como a interpreto. Primeiro, o que é essa coisa? CLM significa modelo de linguagem contrastivo. A equipe o chama de modelo System 1. A Type Safe usou o mesmo rótulo quando lançou Jev alguns dias antes. A ideia é simples. Um agent muitas vezes não precisa de mais um parágrafo de texto. Precisa escolher uma ferramenta, encaminhar um ticket, classificar várias correções possíveis ou pontuar uma possível próxima ação. Você fornece ao CLM o

01:03 estado atual e um conjunto de ações. Ele retorna uma pontuação ou probabilidade para cada ação. Não escreve uma nova resposta do zero. Portanto, eu não pediria que ele redigisse um e-mail ou resolvesse um problema de programação por conta própria. Eu o colocaria em um ponto de decisão dentro de um sistema maior. Essa distinção importa para a manchete. 8 bilhões se refere ao encoder de 8 bilhões de parâmetros do Quinn 3, usado internamente. O projection head do CLM que pode ser baixado tem apenas cerca de 75 megabytes, mas ainda é preciso executar o encoder QN para produzir os embeddings. Este não é um modelo independente de 75

01:33 megabytes. Então, o que fiz foi clonar o repositório público, iniciar o Quen 38B no modo de pooling e executar o servidor do CLM com o checkpoint lançado. Usei uma A40 temporária na RunPod porque a GPU de 8 GB do meu laptop é pequena demais para essa configuração de referência. O servidor disponibiliza um playground simples, mas também enviei minha própria solicitação diretamente à API. Assim, pude salvar a entrada e a saída exatas. Isto não é uma reprodução do benchmark da equipe. É um pequeno teste de funcionamento para um caso de uso real de quem desenvolve: roteamento de ferramentas. Também fiz ao

02:05 CLM bruto as mesmas perguntas; ele pontua usando os embeddings do encoder subjacente, sem o head treinado do CLM, o que me dá uma ablação básica na mesma máquina. Não é Jev, e não vou fingir que seja. Eis o primeiro estado. Uma tarefa de CI está falhando porque o piest não consegue importar um módulo após uma alteração no código. O usuário quer que o teste seja corrigido. Ofereci quatro ações: editar o código, pesquisar na web, gerar uma imagem ou abrir o calendário. O CLM escolheu o editor de código, atribuindo 98% da probabilidade a essa opção.

02:36 O encoder bruto também escolheu o editor de código, mas com uma distribuição bem mais uniforme, cerca de 78%. Depois, mudei o estado. Agora, o usuário pergunta sobre um modelo lançado naquela manhã e, após o anúncio, o CLM escolheu a pesquisa na web, que também seria minha escolha. Atribuiu cerca de 70% à pesquisa na web; os embeddings brutos também a escolheram, com cerca de 46%. Novamente, trata-se de uma solicitação, não de uma medida de confiabilidade, mas mostra como usar o head treinado para tornar mais precisa uma decisão de roteamento com opções limitadas. Minha terceira pergunta foi menos

03:08 clara. Veja o novo artigo do CLM e explique o exemplo de código no repositório. O agent deveria ler o artigo primeiro ou inspecionar o código primeiro? O CLM escolheu o editor de código com bastante convicção. Eu aceitaria isso como um primeiro passo razoável, mas esses 99% nos dizem mais sobre esse conjunto de opções e essas descrições do que sobre alguma confiança universal de que a tarefa inteira está resolvida. Agora, o caso de falha: peço que corrija um teste de Python que está falhando, mas removo deliberadamente o editor de código das opções. As únicas opções restantes eram pesquisa na web, geração de imagens e

03:39 calendário. Mesmo assim, o CLM escolheu uma opção: pesquisa na web, com 84%. Não disse que nenhuma dessas opções era a ferramenta de que precisava. Isso não é um bug de software na API. É o contrato: dê opções ao modelo e ele as classifica. Se quiser uma opção de recusa, você precisa projetá-la e testá-la. Não transforme essas probabilidades em autorização para um agent executar qualquer ação automaticamente. Você encontra todos os prompts e respostas desse pequeno teste nos arquivos do projeto. Eu não tinha acesso à API de Jev, então minha própria execução não comprova a comparação de nove vezes. Esse número de velocidade vem da avaliação

04:09 publicada pela equipe. Então, por que essa abordagem deveria ser rápida? A escolha de projeto importante é codificar separadamente o estado e as ações. O CLM processa o estado atual por um caminho do encoder. Processa cada ação candidata por outro. Projeta ambos no mesmo espaço e verifica quais vetores mais se alinham. O modelo foi treinado para aproximar um par verdadeiro de estado e ação e afastar pares incompatíveis. O objetivo é chamado de aprendizado contrastivo para um agent

04:41 com a mesma lista de ações em cada etapa. Os vetores das ações podem ser calculados uma vez e armazenados em cache. Na demonstração do Mario, há quatro ações fixas. A tela do jogo continua mudando, mas as descrições das ações não. Então, depois da configuração inicial, cada nova etapa só precisa de um novo embedding do estado e de algumas pontuações de similaridade. Essa é a origem da vantagem de velocidade da arquitetura. O repositório até tem um cache de vetores separado para estados e ações repetidos. Mas há um limite. Um novo estado ainda precisa passar pelo Quen 38B. E, se suas ações candidatas

05:12 forem diferentes a cada vez, haverá menos coisas que podem ser reutilizadas. É uma boa opção para decisões repetidas dentro de um menu conhecido. É menos evidente que seja adequada quando cada ação é um plano longo e único. A equipe não simplesmente acoplou um classificador ao QN e deu o trabalho por concluído. Descreveu três etapas de treinamento. Primeiro, cerca de 60 milhões de pares de pergunta e resposta do Neatrom ensinam um alinhamento amplo entre uma pergunta e sua resposta correta. Segundo, cerca de 30 milhões de exemplos negativos difíceis fazem o modelo distinguir respostas plausíveis, mas erradas, da

05:44 resposta certa. Terceiro, cerca de 1 milhão de trajetórias de agent foram adaptadas a estados e ações dentro de workflows reais. Eis um detalhe de que gostei. No experimento da equipe, apenas o pré-treinamento escolheu a resposta correta entre 10 exemplos negativos difíceis em cerca de 52% das vezes. Uma etapa posterior com exemplos negativos difíceis elevou esse índice para cerca de 69%. Começar com exemplos negativos difíceis desde o início atingiu um pico de cerca de 62% com o mesmo orçamento de computação. Eles também repetiram os dados gerais de perguntas e respostas durante o pós-treinamento agentic para que o head não os

06:16 esquecesse. Esses são experimentos da equipe, mas explicam por que isto vai além da similaridade comum de embeddings. O blog também apresenta curvas de escalabilidade para computação, dados, tamanho do head e tamanho do encoder. O maior ganho veio do aumento do encoder. Eu trataria isso como evidência a favor dessa família de treinamento, não como uma promessa de que o próximo modelo resolverá automaticamente as tarefas mais difíceis. Vamos voltar à manchete. No gráfico zero-shot da equipe, o C0M é mais rápido nas quatro tarefas mostradas. No T-Rex, são 16,5 milissegundos contra

06:48 149,8 para Jev. No Mario, cerca de 33 contra 133. Mas desempenho comparável não significa desempenho idêntico. Jev tem uma pontuação maior no resultado de tool calling do BFCL. E, no Wiki Racing, o gráfico da equipe mostra o CLM com 26 de 30, enquanto Jev obtém 30 de 30. As amostras nas demonstrações dos jogos são pequenas. A partida do dinossauro é especialmente interessante. Abri os resultados JSON no repositório. Os dois modelos sobreviveram a todos os cinco percursos com assento, mas o escudo de segurança estava ativado. O harness já identifica movimentos seguros e inseguros e pode substituir a escolha do modelo. O relatório mostra que o CLM concordou com o melhor movimento do planejador de física em cerca de 66% das vezes, enquanto Jev concordou em cerca de 99%. Também registra milhares de intervenções do escudo na execução do CLM. Então, posso mostrar a diferença de velocidade no vídeo, mas não posso usar cinco sobrevivências sem incidentes como prova de que os dois modelos tomaram decisões independentes igualmente boas. Os números maiores de programação vêm de uma configuração totalmente diferente. A equipe relata 81,6% em 38 tarefas SWE profundas reservadas para avaliação e 87,6% em 30 tarefas reservadas para avaliação

07:20 jogadas e pode substituir a escolha do modelo. O relatório mostra que o CLM concordou com a melhor jogada do planejador de física cerca de 66% das vezes, enquanto Jev concordou cerca de 99%. Ele também registra milhares de intervenções do mecanismo de proteção na execução do CLM. Então, posso mostrar a diferença de velocidade no vídeo, mas não posso usar cinco sobrevivências sem problemas como prova de que os dois modelos tomaram decisões independentes igualmente boas. Os números maiores de programação vêm de uma configuração totalmente diferente. A equipe relata 81,6% em 38 tarefas difíceis de SWE reservadas para avaliação e 87,6% em 30 tarefas reservadas para avaliação

07:51 tarefas do Terminal-Bench 2.1 em cada tarefa. Outro modelo forte primeiro gerou várias soluções candidatas. Depois, um head CLM com fine-tuning atuou como verificador e escolheu uma delas. Esses não são resultados zero-shot do head geral lançado, nem execuções completas no leaderboard público. O repositório da versão lançada fornece um checkpoint e um caminho de avaliação para pelo menos o resultado do deepsw, o que é bom para análise. Ainda gostaria de ver novas execuções independentes antes de chamá-lo de estado da arte consolidado. Então, eu usaria o CLM hoje para um roteador de ferramentas, um classificador de tickets ou um seletor da melhor opção, com

08:24 opções bem definidas? Sim, é interessante o bastante para testar. O código e o head estão disponíveis sob a licença Apache 2.0. A interface é simples, e a arquitetura de cache é uma ideia de engenharia real. Na minha pequena execução ao vivo, ele fez escolhas sensatas nos casos fáceis, mas eu colocaria proteções em torno dele. Inclua uma opção real de “nenhuma das alternativas” se isso puder acontecer. Meça os erros com seus próprios dados. Não interprete uma probabilidade alta de softmax como prova de que uma opção ausente é, de algum modo, segura, e mantenha um modelo generativo ou de raciocínio disponível para o trabalho. Para mim, o fato de essa pontuação não fazer isso é a

08:56 história útil aqui. O CLM não é um novo modelo de chat que tenta responder a tudo. É uma tentativa open source de acelerar uma parte específica do loop de um agent: decidir entre ações. Os gráficos de velocidade da equipe fazem isso merecer atenção. As condições por trás desses gráficos nos dizem exatamente onde testar em seguida. Se você está criando um agent com um conjunto de ações repetido, me conte qual decisão você daria ao CLM. Quero ver onde esse design ajuda em um workflow real e onde a lista de candidatos se torna o gargalo.

Transcrição original

[00:00] So look at this. On the top, a model called CLM is playing the dinosaur game. On the bottom is Jev, the new decision model from type safe. The CLM site is answering in about 16 milliseconds. Jev is around 150, that is roughly nine times faster in this run. But here’s the question I actually care about. If I give this model a decision in my own agent, will it pick the right action? And when the right action is missing, will it notice? I downloaded the code, ran the released model on a runpod GPU,

[00:32] and tested exactly that. Then I went through the numbers behind this launch because the demo has a detail that changes how I read it. First, what even is this thing? CLM stands for contrastive language model. The team calls it a system one model. Type safe used the same label when it launched Jeff a few days earlier. The idea is simple. An agent often does not need another paragraph of text. It needs to choose a tool, route a ticket, rank several candidate fixes, or score a possible next move. You give CLM the

[01:03] current state and a set of actions. It returns a score or probability for each action. It does not write a new answer from scratch. So, I would not ask this to draft an email or solve a coding problem by itself. I would put it at a decision point inside a larger system. That distinction matters for the headline. 8 billion refers to the Quinn 3 8 billion parameter encoder under the hood. The downloadable CLM projection head is only about 75 megabytes, but you still need to run the QN encoder to produce the embeddings. This is not a 75

[01:33] megabyte standalone model. So, what I did is clone the public repository, start Quen 38B in its pooling mode, and run the CLM server with the release checkpoint. I used a temporary A40 on RunPod because the 8 GB GPU in my laptop is too small for this reference setup. The server exposes a little playground, but I also sent my own request directly to its API. So, I could save the exact input and output. This is not a reproduction of the team’s benchmark. It is a small smoke test for a real builder use case tool routing. I also ask the

[02:05] same questions of CLM raw, which scores with the underlying encoder embeddings without the trained CLM head that gives me a basic ablation on the same machine. It is not Jev and I’m not going to pretend that it is. Here is the first state. ACI job is failing because piest cannot import a module after a code change. The user wants the test fixed. I offered four actions. Edit code, search the web, generate an image, or open the calendar. CLM chose the code editor with 98% of its probability on that option.

[02:36] The raw encoder also chose the code editor, but with a much flatter distribution, about 78%. Then I changed the state. Now the user is asking about a model launched this morning and once the announcement source CLM chose web search which is what I would do too. It gave web search about 70% raw embeddings also picked it at about 46%. Again this is one request not a reliability score but it shows how you can use the trained head to sharpen a bounded routing decision. My third question was less

[03:08] clean. Look at the new CLM paper and explain the code example in the repository. Should the agent read the paper first or inspect the code first? CLM picked the code editor very strongly. I would accept that as a reasonable first step, but that 99% tells us more about this candidate set and these descriptions than about some universal confidence that the whole task is solved. Now for the failure case, I ask it to fix a failing Python test but deliberately remove the code editor from the choices. The only options left were web search, image generation, and

[03:39] calendar. CLM still picked one web search with 84%. It did not say none of these is the tool I need. That is not a software bug in the API. It is the contract. Give it candidates and it ranks them. If you want an abstain route, you must design one and test it. Do not turn these probabilities into permission for an agent to take any action automatically. You can find every prompt and response from this small test in the project files. I did not have Jev API access, so my own run does not establish the nine times comparison. That speed figure comes from the team’s

[04:09] published evaluation. So why should this approach be quick? The important design choice is that the state and the actions are encoded separately. CLM takes the current state through one encoder path. It takes each candidate action through another. It projects them into the same space and checks which vectors line up best. The model was trained to pull a real state action pair together and push mismatched pairs apart. The objective is called contrastive learning for an agent

[04:41] with the same action list on every step. The action vectors can be computed once and cached. In the Mario demo, there are four fixed actions. The game screen keeps changing, but the action descriptions do not. So, after setup, each new step only needs a fresh state embedding and a few similarity scores that is the source of the architectural speed advantage. The repository even has a separate vector cache for repeated states and actions. There is a limit though. A new state still has to pass through Quen 38B. And if your candidate

[05:12] actions are different every time, there is less to reuse. This is a good fit for repeated decisions over a known menu. It is a less obvious fit when every action is a long unique plan. The team did not just bolt a classifier onto QN and call it done. They described three training stages. First, around 60 million neatron question answer pairs teach broad alignment between a question and its correct answer. Second, around 30 million hard negative examples make the model distinguish plausible wrong

[05:44] answers from the right one. Third, around 1 million agent trajectories adapted to states and actions inside actual workflows. Here’s a detail I liked. In the team’s experiment, pre-training alone picked the correct answer against 10 hard negatives. about 52% of the time. A later hard negative stage lifted that to about 69%. Starting with hard negatives from the beginning peaked around 62% at the same compute budget. They also replayed the broad question answer data during agentic post training so the head would

[06:16] not forget it. Those are team experiments but they explain why this is more than ordinary embedding similarity. The blog also shows scaling curves for compute data head size and encoder size. Their strongest gain came from increasing the encoder. I would treat those as evidence for this training family, not a promise that the next model automatically solves the harder tasks. Let us come back to the headline on the team’s zero shot chart. C0M is faster in all four shown tasks. In T-Rex, it is 16.5 milliseconds versus

[06:48] 149.8 for Jev. In Mario, about 33 versus 133. But comparable performance is not identical performance. Jev scores higher on the BFCL tool calling result. And in Wiki Racing, the team’s chart has CLM at 26 out of 30, while Jev gets 30 out of 30. The sample sizes in the game demos are small. The dinosaur run is especially interesting. I opened the JSON results in the repository. Both models survived all five seated courses, but the safety shield was enabled. The harness already labels safe and unsafe

[07:20] moves and can override a model choice. Its report shows CLM agreed with the physics planner’s best move about 66% of the time, while Jev agreed about 99%. It also records thousands of shield interventions in the CLM run. So, I can show you the speed difference in the video, but I cannot use five clean survivals as proof that the two models made equally good independent decisions. The bigger coding numbers are a different setup entirely. The team reports 81.6% on 38 held out deep SWE tasks and 87.6% 6% on 30 held out

[07:51] terminal bench 2.1 tasks in each task. Another strong model first generated several candidate solutions. A fine-tuned CLM head then acted as the verifier and picked one. These are not zero shot scores for the release general head and they are not full public leaderboard runs. The release repository does provide a checkpoint and evaluation path for at least the deepsw result which is good for scrutiny. I would still like to see independent reruns before calling it a settled state-of-the-art. So would I use CLM today for a tool router ticket classifier or best of end selector with

[08:24] well-defined options? Yes, it is interesting enough to test. The code and head are open under Apache 2.0. The interface is simple and the caching architecture is a real engineering idea. My small live run made sensible choices in the easy cases, but I would put guard rails around it. Include a real none of the above path if that can happen. Measure mistakes on your own data. Do not interpret a high softmax probability as proof that an absent option is somehow safe and keep it generative or reasoning model available for the work. This score does not do that to me is the

[08:56] useful story here. CLM is not a new chat model. Trying to answer everything. It is an open attempt to make one narrow part of an agent loop faster. Deciding among actions, the team’s speed charts make that worth attention. The conditions behind those charts tell us exactly where to test next. If you’re building an agent with a repeated action set, tell me the decision you would give CLM. I want to see where this design helps in a real workflow and where the candidate list becomes the bottleneck.