Qual é o melhor Qwen3.8-27B?

Autoria: Sam Witteveen · 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: Which is The Best Qwen3.8-27B? · Canal: Sam Witteveen · 21:00 · Assistir no YouTube

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

Resumo

O vídeo compara três fine-tunes do Qwen 3.8-27B — Thinking Cap, Swift 1.5 e QwenPi — que buscam reduzir tokens de raciocínio sem perder muita precisão. O Thinking Cap reduz em média 37% dos tokens, enquanto o Swift 1.5 busca cortes mais agressivos e se destaca em tarefas de código e agentes. O QwenPi é ajustado especificamente para funcionar com o harness Pi e para melhorar o desempenho nas configurações de raciocínio médio e baixo. Nos testes práticos, os resultados variam conforme a tarefa: os três fine-tunes costumam ser mais rápidos que o modelo base, mas não há um vencedor universal.

Pontos-chave

Mais tokens de raciocínio significam mais tempo de espera e maior custo de inference; em execução local, a redução de tokens também pode acelerar a geração.
O Thinking Cap foi ajustado para produzir respostas mais curtas no nível x-high, com redução média de 37% dos tokens e pequena queda média de precisão nos benchmarks relatados.
O Swift 1.5 usa penalização de padrões de sobrepensamento, reinforcement learning e on-policy distillation; seus dados de treinamento também foram publicados.
O QwenPi foi treinado com sessões bem-sucedidas do Pi e otimizado para tarefas de programação dentro desse harness específico.
Segundo os resultados apresentados, o QwenPi em nível médio iguala o modelo base em x-high no Terminal Bench usando cerca de 41% menos tokens de saída.
As demonstrações mostram que a velocidade e a qualidade variam de acordo com a tarefa; o Thinking Cap vence em vários exemplos, enquanto o Swift e o QwenPi também se destacam em certos casos.
O apresentador considera o QwenPi mais indicado para programação e vê o Thinking Cap e o Swift como opções mais generalistas.
Os resultados de um fine-tune não necessariamente se transferem para outros harnesses ou casos de uso; o apresentador recomenda testar os modelos na aplicação específica.

Capítulos

Início	Capítulo	Resumo
00:00	O custo de pensar por mais tempo	O apresentador explica como cadeias de raciocínio mais longas aumentam a espera e o custo, e introduz os fine-tunes que prometem usar menos tokens.
03:50	Thinking Cap: menos tokens sem reduzir muito a precisão	O vídeo apresenta a origem do Thinking Cap e seus resultados, incluindo a redução média de tokens e as limitações de licença e aplicação.
08:40	Swift 1.5: redução agressiva e foco em tarefas de agentes	O apresentador descreve o treinamento do Swift 1.5, seus resultados em programação, as opções de execução e os termos de licença.
11:50	QwenPi e o ajuste para o harness Pi	O vídeo explica o treinamento do QwenPi com sessões bem-sucedidas do Pi e discute seu foco em programação e a incerteza sobre a transferência para outros harnesses.
15:01	Comparação prática dos quatro modelos	O apresentador reproduz resultados de inference do modelo base e dos três fine-tunes em perguntas de lógica, matemática, programação e geração de SVG.
19:20	Conclusões e recomendações por uso	O vídeo ressalta que o desempenho varia conforme a tarefa e indica o QwenPi para programação, enquanto Thinking Cap e Swift são opções mais generalistas.

Citações

Um modelo voa até a resposta o mais rápido possível; o outro dá uma volta panorâmica pela costa. — 00:00

Eles não tentaram tornar o modelo mais inteligente nem ensiná-lo nada novo. — 06:30

Thinking Cap e Swift tentam encurtar o x-high. O Pi tenta fazer os níveis baixo e médio funcionarem bem. — 13:56

Você provavelmente deveria testar cada um deles no seu caso de uso específico. — 19:20

Conceitos e entidades

Qwen3.8 27B (modelo): Modelo base usado como ponto de partida para os três fine-tunes comparados.
Thinking Cap (modelo): Fine-tune da BottleCapAI que busca reduzir tokens de raciocínio preservando a precisão do modelo base.
Swift 1.5 (modelo): Fine-tune da UkisAI que reduz padrões de sobrepensamento e é avaliado em tarefas de programação e agentes.
QwenPi (modelo): Fine-tune do Qwen 3.8-27B concebido para funcionar especificamente com o harness Pi.
Pi (ferramenta): Agente de programação open source minimalista, com um conjunto reduzido de ferramentas e um system prompt curto.
BottleCapAI (empresa): Laboratório de Praga responsável pelo fine-tune Thinking Cap.
UkisAI (empresa): Equipe responsável pelo fine-tune Swift 1.5.
Tomáš Mikolov (pessoa): Cofundador da BottleCapAI e primeiro autor do artigo sobre Word2vec, conforme mencionado no vídeo.
vLLM (ferramenta): Ferramenta de serving usada no vídeo para executar os modelos.
Terminal-Bench (conceito): Benchmark citado na comparação de desempenho do QwenPi com o modelo base.

Tradução completa (pt-BR)

00:00 Certo, então esta é a mesma pergunta feita a duas versões do mesmo modelo. Os pesos subjacentes são os mesmos, e a resposta final é semelhante, mas uma delas usou muito mais tokens de pensamento para chegar lá, enquanto a outra usou pouquíssimos em comparação. Na minha máquina, isso representa uma diferença entre dezoito segundos e noventa segundos. E, se você pensar bem, esse é mais ou menos o problema dos modelos de raciocínio hoje, certo? Eles chegam à resposta, mas demoram muito para isso. É quase como se um modelo voasse até lá para obter a resposta o mais rápido possível, enquanto o outro desse uma volta pela costa para seguir um caminho panorâmico.

00:34 E você vai notar isso de maneiras que muitas vezes não são totalmente ruins. Eles fazem coisas como reformular a pergunta, verificar e verificar de novo. Dizem para si mesmos: “Espera, vamos reconsiderar.” E cada um desses tokens representa tempo que você passa esperando pela resposta e, claro, dinheiro que está pagando pela inference. No passado, falei sobre a OpenAI se concentrar em reduzir o número de tokens entre o modelo 5.0 e o modelo 5.5. Bem, eles não são os únicos focados nisso, certo?

01:06 A maioria dos grandes laboratórios tem investigado como reduzir essas longas cadeias de pensamento sem perder a precisão. E o interessante é que também há equipes tentando fazer isso com modelos open source. No passado, falei sobre o modelo Thinking Cap para o Qwen 3.6-27B. E, sem surpresa, vou falar sobre o novo modelo deles neste vídeo. Mas também quero ver algumas das outras equipes que pegaram o Qwen 3.8-27B e fizeram fine-tuning para que ele pense menos. Então, além do Thinking Cap, também temos o QwenPi, que é mais ou menos

01:39 uma versão especializada, com menos pensamento, para agentes de programação. Temos o Swift 1.5. Todos afirmam usar menos tokens com praticamente a mesma precisão, mas parece que cada um faz isso de um jeito bem diferente. E também parece que provavelmente são muito bons em coisas diferentes. Então, neste vídeo, quero ver como cada um foi feito; depois, vou testar todos contra o modelo base e ver se as alegações realmente se confirmam. Certo, antes de fazermos o fine-tuning e analisarmos esses modelos, você precisa saber um pouco sobre o tipo de pensamento e raciocínio que o Qwen 3.8 já oferece pronto para uso

02:12 e que eles chamam de esforço de raciocínio. Há três configurações: baixo, médio e x-alto. E, surpreendentemente, x-alto é a configuração padrão desde o início. Então, se você estiver servindo com vLLM, define isso no template de chat, e dá para ver que, quando ajustamos esse esforço de raciocínio, isso afeta o tamanho das cadeias de pensamento retornadas. Falei sobre isso quando fiz o vídeo sobre servir o Qwen 3.8 27B e preciso dizer que esse modelo ainda é um dos melhores modelos open que você pode obter e servir

02:44 em hardware razoavelmente modesto para alguns usos. O 3.8 Next provavelmente é melhor, mas isso vai exigir uma GPU maior ou várias unidades. Agora, voltando ao 3.8.27B: o esforço de raciocínio significa basicamente que você está dizendo ao modelo para se esforçar menos. Então, sim, você pode obter menos tokens, mas, quando realmente reduz o raciocínio, isso costuma custar em precisão. E, se estiver executando o modelo localmente em uma GPU, você vai ficar limitado pela decodificação.

03:15 Então, os tokens de pensamento ou de raciocínio correspondem praticamente de forma direta aos segundos que você espera para obter o resultado final. Se você conseguir reduzir esses tokens, vai reduzir aproximadamente pela metade o tempo que precisa esperar pela resposta final. Em segundo lugar, esses modelos têm cabeças de previsão de múltiplos tokens para decodificação especulativa, que funciona melhor com rastros mais curtos do que com rastros mais longos, e vemos isso em alguns dos resultados divulgados. O cartão do modelo Thinking Cap, por exemplo, informa que a decodificação especulativa passa de cerca de 2,6 tokens por etapa em X-alto para mais de 3

03:50 tokens por etapa em médio e baixo. Então, dá para pensar nisso assim: pensar menos não significa apenas usar menos tokens. Cada token também sai mais rápido. Certo. A grande pergunta aqui é: o que esses fine-tunes estão tentando fazer exatamente? E eles vão trazer essa economia sem prejudicar a precisão? Certo, aqui está a árvore genealógica. Tudo começa com o Qwen 3.8 27B. Em um dos ramos da árvore, temos o Thinking Cap, da BottleCapAI. O primeiro modelo Thinking Cap foi o que apresentei há alguns meses. E

04:22 ele foi criado naquela época com base no modelo Qwen 3.6. Também podemos dizer que o modelo Swift, da UkisAI, é relacionado a ele. Quando criaram a primeira versão do Swift, parte dessa receita foi um componente de transferência do modelo ThinkingCap. Então, dá para pensar no Swift como tendo parte do DNA do ThinkingCap e sendo relacionado a ele. Agora, em um ramo completamente separado, temos o Qwen Pi, que está seguindo uma estratégia totalmente diferente. Vou explicar isso à medida que analisarmos cada modelo. Mas vamos começar pelo ThinkingCap. A Bottlecap AI é um laboratório em Praga, e um dos cofundadores

04:55 de lá é Tomáš Mikolov. Quando gravei o vídeo original sobre o primeiro Thinking Cap, eu ainda não sabia disso, até que alguém apontou nos comentários. Então, para quem não sabe quem é Tomáš Mikolov, ele foi o primeiro autor de um artigo muito famoso, Word2vec. Esse é um dos artigos fundamentais que realmente mudaram o processamento de linguagem natural. A ideia era ter vetores capazes de representar palavras, que depois poderiam ser usados em coisas como classificação, entre várias outras aplicações. Na época, Mikolov trabalhava no Google e, pelo que me lembro, também estava

05:28 trabalhando em muitas das ideias para Seq2Seq, que foram precursores muito iniciais da ideia de transformer: sequência entra, sequência sai. Depois que alguém apontou isso, entrei em contato com ele para enviar o vídeo e perguntar se fariam uma versão para o 3.8. E descobri que estão trabalhando em um projeto interessante, que espero poder apresentar em breve. Mas, claramente, eu não era o único dando o feedback de que a comunidade queria uma versão 3.8 dos modelos Thinking Cap. Então, acho que realocaram parte do compute que estavam usando

05:58 para o outro projeto para este. E só um comentário rápido: acho que deveríamos mesmo ser gratos por startups como essa. A startup dele não é uma startup de bilhões de dólares em São Francisco que está treinando os próprios modelos de fronteira para competir com OpenAI ou Anthropic e outras empresas. A Bottle Cap é uma startup que levantou uma fração minúscula desse dinheiro em comparação com algumas dessas empresas maiores e, muito provavelmente, tem uma fração do compute de que dispõem essas startups mais conhecidas. Então, acho muito legal que estejam destinando compute para fazer algo assim pela comunidade.

06:30 Certo, como isso foi feito exatamente? Bem, a BottleCap não publicou a receita de treinamento propriamente dita, mas deixou claro o objetivo: o foco era uma coisa só, quantos tokens de pensamento são necessários para chegar à mesma resposta. E eles mencionaram que a abordagem foi deliberadamente conservadora. Não tentaram deixar o modelo mais inteligente, ensiná-lo a fazer algo novo nem mudar a maneira como ele fala. Não tentaram acrescentar conhecimento, nem mesmo melhorar o seguimento de instruções, a segurança ou qualquer outra coisa desse tipo. A ideia era deixar tudo isso totalmente inalterado. Então, o treinamento foi feito em X-alto, e

07:01 desta vez eles deram mais atenção a benchmarks e tarefas bem mais difíceis. Coisas como matemática, raciocínio, contexto longo, tarefas agênticas e assim por diante. Dá para pensar nisso como ensinar o modelo a reconhecer quando terminou, em vez de ensiná-lo a ser breve. O destaque é uma redução média de 37% nos tokens em 12 benchmarks, com a precisão média caindo de 86,6 para cerca de 85,8. Então, a precisão diminuiu apenas um pouquinho. Por exemplo, no GPQ8 Diamond, a média passa de 12.800

07:36 os tokens de raciocínio na versão original para 7.300 na versão Thinking Cap. E, curiosamente, alguns deles, como o resultado de contexto longo, são realmente interessantes. No benchmark de recuperação em contexto longo, ela usa 39% menos raciocínio, mas a precisão aumenta alguns pontos. Mas acho que o gráfico mais útil da publicação no blog é este, porque ele se conecta diretamente ao nível de esforço de raciocínio que definimos. Se você pegar o modelo base e simplesmente reduzi-lo para médio, elimina cerca de

08:07 metade do raciocínio, mas abre mão de cerca de nove pontos de precisão. O Thinking Cap no X-high elimina 37% do raciocínio, com uma perda de menos de um ponto de precisão. Então, de repente, esse nível X-high fica realmente útil. Certo, então para que este modelo serve? Basicamente, é um substituto direto da versão do Qwen no X-high. Portanto, qualquer coisa que exija raciocínio geral, perguntas de conhecimento, documentos longos etc., tudo isso pode ser feito simplesmente usando este modelo. Talvez a única desvantagem, eu diria, sejam os rastros agentic.

08:40 E não porque não sejam mais curtos. Eles são mais curtos, mas parece que o raciocínio diminui apenas cerca de 11%. Agora, curiosamente, a outra coisa é que esta versão foi feita para X-high. Se você quiser uma versão feita para raciocínio médio ou baixo e otimizada para isso, é algo que eles estão vendendo para empresas. E, junto com isso, a outra mudança é a licença em si. Então, ela passou da Apache 2 na versão 3.6 para uma licença de uso por pequenas empresas e uso pessoal nesta versão, o que faz todo o sentido se eles estiverem

09:12 tentando ganhar dinheiro para cobrir os custos de computação etc. Certo, o próximo é o Swift 1.5, da Ukis AI, e este é bem mais agressivo. Ele busca reduzir em até 58,5% os tokens de raciocínio no Qwen 3.8/27B. Eles fizeram isso em duas etapas. No Swift 1.0, procuraram tokens específicos no raciocínio do Qwen que pareciam desencadear pensamento excessivo. Alguns exemplos seriam quando ele diz coisas como

09:44 “Espera, deixa eu perguntar o que o usuário quer.” “Hmm.” E então, sabe, faz uma pergunta a si mesmo. “Deixa eu reconsiderar.” Aí eles fizeram fine-tuning no modelo para penalizar esses tokens, em vez de simplesmente penalizar o comprimento. Depois, adicionaram isso à versão original do modelo ThinkingCap. Para a versão 1.5, porém, eles pegaram o modelo e ampliaram o aprendizado por reforço e a destilação on-policy. O foco principal foi em tarefas agentic de longo horizonte e tarefas de programação. O interessante é que eles não publicaram apenas os modelos; os

10:16 dados de treinamento também estão no Hugging Face, o que é ótimo de ver. Dá para notar isso nos números de programação. No cartão do modelo, o LiveCodeBench passa de pouco menos de 77% no modelo base, com cerca de 11.200 tokens de saída, para uma precisão de 81,7%, com apenas 8.400 tokens de saída. Outra coisa interessante é que eles também afirmam que a economia obtida se mantém em todos os níveis de esforço. No nível baixo, a pontuação fica ligeiramente acima da do modelo base, com cerca de 29%

10:48 menos tokens de raciocínio. Na prática também, este provavelmente é o que oferece mais opções para executá-lo. Há versões padrão em GGUF para LlamaCPP. Há versões pequenas para GPUs menores. Tem MLX, uma versão em NVFP4 e até uma compilação para AMD. Eles também oferecem uma API de pesquisa gratuita, sem chave de API, caso você queira apenas experimentar. Mas esse número de destaque, de 58% menos tokens de raciocínio, provavelmente fica um pouco menor quando você começa a analisar a redução média de raciocínio ao longo de

11:19 tudo isso, mas ainda é muito impressionante. Outra coisa em que eles se concentraram é a afirmação de que o modelo base entra em ciclos e falha cedo, algo que, segundo eles, a versão deles não faz. A licença desta versão é uma licença personalizada própria, gratuita até um milhão de dólares em receita. Depois disso, você precisa basicamente entrar em contato com eles. Certo. Isso me leva ao terceiro modelo, que é meio que o diferente dos demais. E, por sinal, este é o único dos três que tem licença Apache 2. É o QwenPi. Para entendê-lo, primeiro é preciso saber o que é o Pi.

11:50 O Pi é um agent de programação open source, deliberadamente minimalista. Ele tem um conjunto muito limitado de ferramentas para ler, escrever, editar e usar bash e, da última vez que conferi, até o system prompt tinha menos de 1.000 tokens. Então, o Qwen Pi é o Qwen 3.8/27B com fine-tuning feito especificamente para funcionar dentro do harness do Pi. E quis falar sobre este modelo porque acho que veremos muito mais casos em que as pessoas fazem fine-tuning de um modelo específico para um harness muito específico. E isso faz todo o sentido.

12:22 Se você conseguir fazer o modelo e o harness funcionarem juntos, e o modelo puder ser preparado para o tipo de entrada que vai receber e para o tipo de saída que deve gerar, provavelmente vai acabar com um modelo muito mais adequado a um harness vertical específico. Essa é uma ideia que tenho testado recentemente com vários harnesses verticais na área de co-cientistas. Então, sinto que este modelo mostra um pouco para onde essa direção está indo. Como ele foi criado? Primeiro, basicamente, é fine-tuning supervisionado em sessões reais do Pi,

12:52 mas apenas nas que tiveram sucesso. Assim, o modelo aprende os workflows completos: como analisar o código, como fazer uma alteração, como executar testes, como corrigir o que está quebrado etc. Em segundo lugar, eles garantem que, nessas tarefas, o próprio código funcional e o código quebrado sejam verificados separadamente. Em terceiro lugar, fazem aprendizado por reforço com GRPO e uma recompensa personalizada para a eficiência do raciocínio. Então, obviamente, o objetivo é basicamente reduzir as longas cadeias de pensamento. Curiosamente, essa recompensa é voltada para as configurações baixa e média, enquanto o X-high

13:23 fica focado em acertar. Outra coisa interessante mencionada aqui é que eles escolhem os checkpoints com base nos resultados reais do agent, não apenas na perda de treinamento. Dá para imaginar que, à medida que o modelo melhora e o RL entra em ação para reduzir essa perda de treinamento, isso nem sempre leva às melhores execuções do agent. Portanto, eles estão muito mais focados em fazer isso funcionar de verdade nas execuções do agent do que simplesmente atingir algum objetivo de treinamento de LLM. Meu palpite é que um dos principais motivos para isso funcionar é que o Pi é um harness minimalista.

13:56 Como ele tem apenas algumas ferramentas e um prompt realmente pequeno, cada sessão é razoavelmente parecida. E dá para imaginar que isso gera dados muito bons para fazer fine-tuning. A ideia deste modelo é diferente. ThinkingCap e Swift tentam deixar seu X-high mais curto. O Pi tenta fazer com que as configurações de esforço baixo e médio sejam realmente boas. Segundo os números deles, a configuração média do Pi iguala o X-high do modelo base no Terminal Bench, com cerca de 41% menos tokens de saída. Eles estão tentando reduzir o número de tokens usados ao

14:28 fazer você usar os níveis baixo e médio, elevando a inteligência deles até o nível alto. Agora, obviamente, o ponto fraco deste modelo é o caso de uso muito restrito. Todas as evidências vêm do uso dentro do Pi. Pelo que vi, ninguém realmente mostrou que isso se transfere para outros harnesses, caso você queira usar o open code ou outras coisas etc. E, em tarefas gerais de raciocínio, como o GPQA, o modelo base ainda vence na configuração média. Então, em muitos aspectos, eu diria que isso é uma espécie de esforço de teste da comunidade que

15:01 talvez ainda não esteja totalmente comprovado, mas certamente é muito promissor. Então, vamos começar e olhar de fato algumas das saídas que obtivemos. Certo, cada um desses modelos está sendo executado em uma torre Dell Pro Max, com uma RTX Pro 6000 e o vLLM padrão. Não otimizei nada disso aqui. Então, obrigado à Dell por patrocinar a computação para isso. Isso realmente torna possível fazer o benchmark desses modelos. Certo, vou preparar a demonstração. Basicamente, pedi ao Claude, ao Fable e ao Opus para

15:34 gerar várias perguntas ou prompts que vão criar uma grande quantidade de tokens de pensamento ou tokens de raciocínio, etc. E então o que fiz foi passar por todos eles, renderizar a inference de cada um desses modelos e salvá-la com timestamps exatos, para podermos reproduzir os quatro ao mesmo tempo aqui. Então, você pode ver aqui que temos o Qwen 3.8-27B original. Tecnicamente, este é o modelo fine-tuned que eles lançaram a partir do modelo

16:05 base, mas esta é uma espécie de versão padrão do modelo. Tenho o Qwen Pi, o Thinking Cap e o Swift aqui. Então, você vai ver que, se eu avançar e escolher algo como isto, estou reproduzindo em 16 vezes a velocidade em que foi gravado. E você pode ver que, de fato, o Thinking Cap já terminou. Ele concluiu e chegou à resposta correta. O Swift 1.5 também terminou, mais uma vez, com a resposta correta.

16:38 O modelo Qwen Pi terminou com a resposta correta. E, por fim, em algum momento, veremos o 3.8 27B original analisando este também, com a resposta correta. Então, neste caso, todos os modelos deram exatamente a mesma resposta. Mas podemos ver claramente que, neste caso, o Thinking Cap foi muito mais rápido, certo? Usou apenas quatro mil tokens. Você pode ver que as velocidades de inference também são mais ou menos iguais; o segundo é o modelo

17:08 Swift, e o terceiro é o modelo Pi; por fim, vem a versão longa. Então, os três estão se saindo muito melhor do que a versão original. Vamos tentar com outro prompt. Certo, mais uma vez, você pode ver que todos estão desligados. E, neste caso, podemos ver que o modelo Swift foi o mais rápido, seguido pelo Pi Thinking e pelo modelo original. Neste caso, o Thinking Cap ficou por último, certo? Agora, vale apontar que esta é mais uma tarefa de programação, com isso.

17:43 E lembre-se de que o modelo Pi foi feito para tarefas de programação e tende a se especializar nesse tipo de coisa. Certo, se olharmos outro, como este, podemos ver que, de fato, neste caso, o modelo Swift foi muito bem, seguido pelo Thinking Cap. O modelo Pi demorou mais do que os dois, mas ainda assim foi muito mais rápido do que o original. Certo. Se dermos a ele um tipo de problema de lógica para resolver, você verá que, neste caso, o Thinking Cap 1 ficou em primeiro, o Swift em segundo, seguido pelo modelo base e, depois, pelo Pi.

18:14 Se dermos a ele outro problema de matemática, podemos ver que, neste caso, o Thinking Cap venceu. O Swift ficou em segundo, o Pi em terceiro, e o modelo original ficou bem para trás. E, se convertermos isso em tempo, veremos uma enorme economia com alguns desses modelos. O Thinking Cap 1 é simplesmente muito mais rápido e conciso no que produz. Mais um exemplo: novamente, Thinking Cap em primeiro, seguido pelo Swift. E, neste caso, a versão base realmente superou a versão Pi. Então,

18:45 para concluir, vou mostrar um que é um pouco surpreendente. Neste caso, o modelo Swift teve um desempenho um pouco melhor. Depois, temos o modelo base em segundo lugar, seguido pelo Thinking Cap e, por fim, pelo modelo Pi. Para mim, o interessante aqui é que, embora o prompt seja o mesmo para criar o SVG, cada modelo gera um SVG um pouco diferente. E eu diria que este é o exemplo perfeito de quando você provavelmente deveria experimentar cada um deles no seu caso de uso específico,

19:20 porque, assim como a qualidade dos SVGs varia aqui, você vai perceber que outras respostas, que nem sempre têm uma resposta exata, também podem variar bastante de um modelo para outro. Embora, nos meus testes, o Thinking Cap pareça vencer na maioria das vezes, a variação pode ser bem diferente para diferentes tipos de perguntas. E acho que isso tem muito a ver com a forma como as pessoas fazem o fine-tuning: aquilo em que fazem o modelo se concentrar e para o que usam RL é aquilo em que ele vai ficar bom.

19:52 E acho que, para cada um desses três fine-tunes, eles adotaram abordagens um pouco diferentes para a curadoria de dados e talvez para o aprendizado por currículo na maneira como os montaram. Se você se lembra, também falei que o modelo Qwen Pi foi treinado para ter um desempenho melhor no nível médio. E o que percebo é que, de fato, este modelo é muito mais rápido no nível médio do que o modelo base original. Mas isso não significa que ele será sempre mais rápido em todos os casos. Muitas vezes, o Thinking Cap 1 ainda será mais rápido em algumas dessas tarefas.

20:25 E percebo que até o Thinking Cap 1 tende a ser um pouco mais preciso em muitas tarefas diferentes e coisas do tipo quando está configurado no nível médio. Neste caso específico, porém, você pode ver que, ao compararmos, o modelo Pi é, na verdade, mais rápido do que os outros dois quando a configuração está no nível médio. Enfim, me contem nos comentários se vocês já experimentaram esses modelos, o que acharam e qual dos três é o favorito de vocês. Eu diria que os três são muito bons. Em geral, todos tendem a se sair melhor do que o modelo base em

21:00 muitas tarefas específicas. Agora, o Pi 1 me parece definitivamente mais adequado para tarefas de programação, e é nelas que ele realmente se destaca. O Thinking Cap e o Swift são modelos bem mais generalistas. Enfim, como sempre, se gostou do vídeo, clique em gostei e inscreva-se. E a gente se fala no próximo vídeo. Até mais.

Transcrição original

[00:00] Okay, so this is the same question going into two versions of the same model. same weights underneath, similar answer at the end, But one of them has used a lot more thinking tokens to get there, And the other has used hardly any in comparison to get there. So on my machine, that’s a difference between eighteen seconds and ninety seconds. And if you think about it, that’s sort of the problem with reasoning models now, right? They get the answer, but they take a long time to get there. it’s almost like one model flies there to get the answer as fast as possible, and the other one drives around the coast to take a scenic route.

[00:34] and you’ll see this in ways that are often not totally bad. They’ll do things like they restate the question, they check, they check again. They say to themselves, “Wait, let’s reconsider.” And every one of those tokens is time that you’re spent waiting for this answer and of course, money that you’re paying for the inference for this now in the past, I’ve talked about OpenAI focusing on reducing the number of tokens between the 5.0 model and the 5.5 model. well, they’re not the only ones that have been focused on this, right?

[01:06] Most of the major labs have been looking at how do they take these long chains of thought and reduce them but still keep the accuracy. And the cool thing is that there are also teams trying to do this with open source models. So in the past, I covered the Thinking Cap model for the Qwen 3.6-27B. And no surprise, I’m gonna cover their new model in this video. But also, I want to look at some of the other teams that have taken on the Qwen 3.8-27B and fine-tuned it to think less. so on top of Thinking Cap, we’ve also got QwenPi, which is sort of

[01:39] like a specialized version with less thinking for coding agents. Got Swift 1.5. They all claim fewer tokens for about the same accuracy, but it seems they all go about it in really different ways. And it also seems that They’re probably really good at different things. So this video, I want to look at how each one was made, then I’ll run all of them against the base model and see if the claims actually hold up. All right, so before we do the fine-tunes and look at those, you need to know a bit about the sort of thinking and reasoning on Qwen 3.8

[02:12] that it already gives you out of the box, and they call it reasoning effort. It has three settings, low, medium, and x-high. and amazingly out of the box, x-high is actually the default. So if you’re serving with vLLM, you actually set this in the chat template and you can see that when we set that reasoning effort, that’s going to affect how long the chains of thought are that’s coming back. Now, I talked about this when I made the video about serving Qwen 3.8 27B and I got to say that model is still one of the best open models, that you can get and serve

[02:44] on reasonably small hardware for some uses the 3.8 Next is probably better, But that’s gonna move you into the realm of needing a bigger GPU or needing multiple units in there Now back to the 3.8.27B. The whole reasoning effort there is you are basically telling the model to try less hard So yes, you can get less tokens out of it, but when you actually turn that reasoning down it’s often gonna cost you in accuracy and if you’re running this locally on one GPU, you’re really going to be decode bound.

[03:15] So the thinking or reasoning tokens there match pretty much directly to seconds for you getting your final result out. if you can have those tokens, you’re roughly halving the weight that you’re going to have to wait for your final answer out secondly, these models have multi-token prediction heads for speculative decoding, and that actually works better on shorter traces than longer traces and we actually see this in some of the reported results. So Thinking Cap’s model card actually reports that speculative decoding goes from about 2.6 tokens per step at X high to over 3

[03:50] tokens per step at medium and low. So you can actually think about this as thinking less doesn’t just mean fewer tokens. Each token comes out faster as well. Alright. So the big question here is what are these fine-tunes actually trying to do, and are they going to get you the savings without any sort of accuracy hit here? Alright, so here’s the family tree. Everything starts from Qwen 3.8 27B. On one branch of the tree, you’ve got Thinking Cap from BottleCapAI. Their first Thinking Cap model was the one that I covered a couple of months back And

[04:22] that was built on the Qwen 3.6 model then. And you could say related to this was the UkisAI Swift model. So when they built their first version of Swift, part of that recipe was a transfer component from the ThinkingCap model. So you can sort of think of Swift of having some of the ThinkingCap DNA in it and being related, now, on a completely separate branch here, you’ve got Qwen Pi, which is playing a different game totally. I’ll get to that as we go through each of the models. But let’s start with ThinkingCap. so Bottlecap AI is a lab in Prague, and One of the co-founders

[04:55] there is Tomáš Mikolov. so at the time that I recorded the original video about the first Thinking Cap, I didn’t actually know that until one of you pointed it out in the comments. And so for those of you who don’t know who Tomáš Mikolov is, he was actually the first author on a very famous paper Word2vec. So this is one of the key papers that really changed, natural language processing. The whole idea of having vectors that could represent words and then could be used for things like classification, like a whole bunch of these things. at the time Mikolov was working at Google, from memory, he was also

[05:28] working on a lot of the ideas for Seq2Seq, which all of these were very early precursors to the transformer idea of sequence in, sequence out. now after one of you had pointed that out, I actually reached out to him to send the video and message him were they gonna do one for 3.8? And I found out they’re working on an interesting project that hopefully I can cover in the near future But clearly I wasn’t the only one giving feedback that the community wanted a 3.8 version of the Thinking Cap models. So I think they reallocated some of the compute that they were using

[05:58] for their other project to this And just a very quick side note here, I would say that We really should be grateful for startups like this. his startup is not some billion-dollar startup in San Francisco that’s training their own frontier models to compete with OpenAI or Anthropic, et cetera Bottle Cap is a startup that’s raised a tiny fraction of that money compared to some of these bigger ones and most likely has a fraction of the compute that those more famous startups actually have. So the fact that they’re allocating compute to do something like this for the community, I think is very cool.

[06:30] All right, so how was this actually made? Well, BottleCap didn’t publish the actual training recipe, but they’re clear about the objective here. The target was one thing, how many thinking tokens it takes to reach the same answer and they mentioned that the aim was deliberately conservative here. They didn’t try to make the model smarter, to teach it anything new, to change how it talks. They haven’t tried to add any knowledge in here or even improve the instruction following or safety or any of those things. Those are meant to come through totally untouched So it’s trained at X-high, and

[07:01] this time they put more focus on much harder sort of benchmarks and tasks. So things like math, reasoning, long context, agentic tasks, et cetera you can kind of think of this is teaching the model when it’s done rather than teaching it to be brief. So the headline here is 37% fewer tokens on average across 12 benchmarks With the average accuracy going from 86.6 to sort of 85.8. So it’s just a tiny percentage less accuracy there. So for example, on the GPQ8 Diamond, This goes from an average of 12,800

[07:36] thinking tokens on the original version down to 7,300 on the Thinking Cap one. And interesting on some of them, like The long context result is a really interesting one. On their long context retrieval benchmark, it uses 39% less thinking, but the accuracy actually goes up a couple of points there But the chart I think that is most useful, in their blog post about this is this one because it ties Straight back to where we set the reasoning effort. If you take the base model and just drop it to medium, you remove about

[08:07] half the thinking, but you give up about nine points of accuracy. Thinking Cap at X high removes 37% for under a point of accuracy So suddenly that x high level gets really useful there. All right, so what’s this model actually good for? it’s basically just a drop-in replacement for the Qwen version at x-high. So anything that needs general reasoning, knowledge questions, long documents, et cetera all of those things you can basically just drop this model in. Perhaps the only downside I would say here would be the agentic traces.

[08:40] and not because they’re not shorter. They’re shorter, But it seems that the reasoning only drops by about 11% there now interestingly, the other thing here is that this version is made for X-high. if you want a version that’s made for the medium or low thinking and optimize for that that’s something that they’re actually selling to enterprises and along with that, the other change here is the actual license. So it’s gone from being Apache 2 for the 3.6 version to this one being a small business plus personal use kind of license Which totally makes sense if they’re

[09:12] trying to make some money to actually cover their compute costs, et cetera all right, so next up is Swift 1.5 from Ukis AI, and this one’s quite a lot more aggressive. So this one is going for up to 58.5% fewer thinking tokens on the Qwen 3.8/27B. They built it in two steps. So for Swift 1.0, they were really looking for specific tokens in Qwen’s reasoning that seemed to trigger overthinking And you could think of some examples

[09:44] of those are where things like it says, “Wait, let me ask, what the user wants.” “Hmm.” And then, you know, asks itself something. “Let me reconsider.” And then they fine-tuned the model to penalize those tokens rather than just penalizing the length. And then they added that to the original version of the ThinkingCap model. For 1.5, though, they took the model and scaled up the reinforcement learning and on-policy distillation. With their main focus being on long horizon agentic and coding tasks. Now the cool thing here is that not only have they published the models, the

[10:16] training data is also on Hugging Face which is really good to see here You can see it in the coding numbers here. On their model card, LiveCodeBench goes from just under 77% for the base model with around eleven thousand two hundred tokens out to actually an increase of accuracy of eighty one point seven percent with only eight thousand four hundred tokens out. So the other interesting thing here is that they also claim that the savings that they’re getting hold at every effort level. At low, it actually scores slightly above the base model with about 29%

[10:48] fewer thinking tokens practically too, this one has probably the most ways for you to run it. there are standard LlamaCPP, GGUFs for this. there are small ones to fit on small GPUs. There’s MLX there’s an NVFP4 version, and even an AMD build here and they even have like a free research API for this with no API key if you wanna just try this out Now that headline of the 58% fewer thinking tokens probably turns out to be a bit less when you start looking at the mean thinking reduction across

[11:19] this, but it’s still very impressive here. Another thing that they’ve focused on is that they claim that the base model loops and fails early Which they’re claiming that their version doesn’t do. now the license for this one is their own custom license, which is free up to a million dollars in revenue. After that, you need to basically contact them. Alright. So that brings me to the third one, which is kind of the odd one out here And incidentally, this is the only one of the three that actually has an Apache 2 license. So this is QwenPi. To understand it, you first need to know about what Pi is.

[11:50] Pi is an open source coding agent that’s very deliberately minimal It has a very limited set of tools for doing read, write, edit, and bash and last time I checked, it even has a system prompt that’s under 1,000 tokens. so Qwen Pi is Qwen 3.8/27B fine-tuned specifically to work inside of the Pi harness. And I wanted to cover this one because I think this is something we’re going to see a lot more of where people fine-tune a particular model for a very specific harness And it totally makes sense.

[12:22] If you can get the model and the harness to work together And the model can be primed for what kind of inputs it’s gonna see, what kind of inputs it should generate out You’re probably gonna end up with a model that’s a lot more suited to a very particular vertical harness there And this idea is something that I’ve been running tests on recently with a number of vertical harnesses in the co-scientist area So I feel like this model shows a little bit of where that direction is actually going. So how was this made? first, it’s basically supervised fine-tuning on real Pi sessions,

[12:52] but only the successful ones. So the model learns the whole workflows, how to look at code, how to make a change, how to run tests, how to fix what’s broken, et cetera. Secondly, they make sure in those tasks that they actually check for working code versus broken code separately themselves. Thirdly, they’re doing reinforcement learning with GRPO and a custom reward for reasoning efficiency there. So obviously the goal there is to basically reduce the long chains of thought. Interestingly, that reward is aimed at the low and medium settings while X-high

[13:23] is left to focus on getting it right the other interesting thing that’s mentioned in here is that they actually pick the checkpoints based on actual agent results, not just based on training loss. So you could imagine that as the model gets better and the RL kicks in to reduce that training loss, that doesn’t always lead to the best agent runs. So they’re much more focused on getting this to actually work for agent runs than purely just for some LLM training goal now my guess here is a big part of why this works is that Pi is a minimal harness

[13:56] When it’s only got a few tools and a really tiny prompt like that, every session looks reasonably similar. and you can imagine that that generates really nice data to actually fine-tune on So the idea with this one is different. ThinkingCap and Swift are trying to make your X high shorter. Pi is actually trying to make the low and medium effort settings actually good On their numbers, Pi’s medium setting matches the base model’s x high on Terminal Bench with about 41% fewer output tokens. they’re trying to reduce the number of tokens you’re using by actually

[14:28] getting you to use the lower and the medium levels by increasing their intelligence up to the high level. Now, obviously the weakness for this one is that it’s a very narrow use case All the evidence comes from using it inside of Pi. From what I’ve seen, nobody has really shown that this carries over to other harnesses if you wanted to use open code or you wanted to use other things, et cetera. and on the general sort of reasoning tasks, like the GPQA, the base model Still actually wins at the medium level. so in many ways I’d say this is sort of like a community testing effort that

[15:01] perhaps isn’t totally proven yet, but is certainly very promising here so let’s jump in and actually take a look at some of the outputs that we’ve got here Okay, so Each of these models is running on a Dell Pro Max tower here, and they’re running on an RTX Pro 6000 with standard vLLM here. I haven’t really optimized any of that in here. So thank you to Dell for sponsoring the compute for this It really makes it possible for me to be able to benchmark these models out Okay, so let me set up the demo here. What I’ve basically done is I’ve gotten Claude, Fable, and Opus to

[15:34] generate a bunch of questions or prompts that, they’re gonna create a large amount of thinking tokens or reasoning tokens, et cetera. and then what I’ve done is I’ve gone through and actually rendered out the inference for each of these models and saved it with exact timestamps so that we can look at all four of them playing back at once here. So you can see here we’ve got the, original Qwen 3.8-27B. This is technically the fine-tuned model that they released of their

[16:05] base model, but this is sort of the standard, version of the model. I’ve got the Qwen Pi one, I’ve got the Thinking Cap one And I’ve got the Swift one in here. So you’ll see that if I come up and I pick something like this, I’m actually playing back at 16 times the speed, that it was, recorded. And you can see, sure enough, here, this is now, Thinking Cap has done, it’s completed. it’s got the correct answer. we’ve now got Swift 1.5 done, completed with, again, with the correct answer.

[16:38] We’ve got the Qwen, Pi model done with the correct answer. And finally, at some point, we will get the original 3.8 27B looking at this one also with the correct answer there So in this case, each of the models has given us the exact same, answer back. But we can see very clearly in this case that ThinkingCap was way shorter, right? With only, four thousand tokens. You can see that even the inference speeds are roughly the same, second is, the

[17:08] Swift, model, and third is the Pi model, and then finally is the long version. So all three of them are doing much better than the original version. Let’s try it with a different prompt Okay, so again, you can see, these are all off. and we can see in this case, the Swift model actually, was fastest, followed by the Pi Thinking, followed by the original model, And in this case, Thinking Cap actually came last, right? Now, I will point out that this one is more of a sort of coding task, with this.

[17:43] And remember that the Pi model is made for coding tasks and tends to specialize in that kind of thing Alright, If we look at another one, like this, we can see that sure enough, in this case, the Swift model did really well, followed by Thinking Cap. The Pi model took longer than both of those, but still was way shorter than the original one Alright. If we give it sort of a logic puzzle to go through, you see in this case the Thinking Cap 1, Swift came second, followed by The base model and then Pi

[18:14] If we give it another mathematics one, we can see in this one that Thinking Cap won. Swift came second, Pi came third, and then the original model was quite a long way behind that And you see if we translate these into time, that we’re getting huge savings with some of these models. The ThinkingCap 1 is just a lot faster, a lot more concise in what it’s actually producing there Another example, again, ThinkingCap first, followed by Swift. and in this case, the base version actually beat the Pi version So

[18:45] just to finish up, I’ll show you one that, is kind of a bit surprising. in this one, you’ve got, the Swift model actually doing slightly better. we’ve then got the base model coming second, followed by Thinking Cap, and finally the Pi model in here. For me, the interesting thing here is that even though we’ve got the same prompt, for making the SVG, each of them is making a slightly different SVG, you know, coming out of it And I would say this is sort of the perfect example of where you probably should try each of them out for your specific use case.

[19:20] because just as the SVGs change, in quality in here, you will find that other answers that don’t necessarily always have an exact answer also can change quite a lot from model to model in here While in my test Thinking Cap seems to be winning most of the time, the variance can be really different on different kinds of questions. And I think that’s got a lot to do with just how people are doing the fine-tunings here whatever they make the model focus on and use the RL on, it’s going to get good at that.

[19:52] and I think For each of these three fine-tunes here, they’ve gone for slightly different, data curation and perhaps curriculum learning in the way that they’ve actually put these together. So if you remember back, I also talked about that the Qwen Pi model was actually trained to do better on medium. And the thing I find is that sure enough, this model actually is a lot faster out on medium than the original base model. it doesn’t mean though that it’s always gonna be faster for all of them. often the Thinking Cap 1 will still be faster, for some of these.

[20:25] And I find that even the Thinking Cap 1 tends to be a little bit more accurate at a lot of the different, tasks and stuff when you have it actually set to medium in this particular use case here, you can see, though , when we compare this, that the, Pi model, is actually being faster than both of them when we’ve got the setting on medium there so anyway, let me know in the comments if you’ve actually had a play with these, how you found them out, which one of the three is your favorite. I would say that all three of these are actually very good. In general, they all tend to do better than the base model for

[21:00] a lot of the particular tasks. Now, The Pi 1 seems to me to be definitely more suited to coding kind of tasks, and it really shines at those The Thinking Cap and the Swift one are much more sort of generalist models So anyway, as always, if you like the video, click like and subscribe. and I will talk to you in the next video. Bye for now.