AutoThink: melhorando o desempenho de LLMs locais com inferência adaptativa

• É uma técnica que ajuda LLMs locais a ajustar tokens de inferência de acordo com a dificuldade da consulta, produzindo respostas mais eficientes com os mesmos recursos
• Em vez de dar o mesmo “tempo para pensar” a todas as consultas, ela as divide em complexidade HIGH/LOW e aloca 70–90% dos tokens para raciocínios complexos e 20–40% para consultas simples
• Usa vetores de direcionamento baseados no Pivotal Token Search do artigo do Microsoft Phi-4 para induzir padrões de raciocínio como precisão numérica, autocorreção e exploração minuciosa
• No DeepSeek-R1-Distill-Qwen-1.5B, o GPQA-Diamond subiu de uma linha de base de 21,72% para 31,06%, uma melhoria relativa de 43%, e o MMLU-Pro aumentou de 25,58% para 26,38%
• Funciona em modelos locais de raciocínio como DeepSeek, Qwen e modelos com fine-tuning customizado, usa menos tokens do que a abordagem de referência e não depende de APIs

---

Ajuste de recursos de inferência por consulta

• O AutoThink é uma técnica de alocação adaptativa de recursos que distribui os recursos de inferência de LLMs locais de forma diferente para cada consulta
• Primeiro, classifica a consulta como de complexidade HIGH ou LOW e, em seguida, ajusta a proporção de tokens de inferência conforme a complexidade
  • Raciocínio complexo: 70–90% do total de tokens
  • Consulta simples: 20–40% do total de tokens
• Os vetores de direcionamento são derivados do Pivotal Token Search e orientam a direção de raciocínio do modelo durante a geração
  • Os comportamentos induzidos incluem precisão numérica, autocorreção e exploração minuciosa
• A implementação é composta por dois eixos
  • Um framework de classificação adaptativa capaz de aprender novas categorias de complexidade sem retreinamento
  • Uma implementação open source do Pivotal Token Search

Resultados de benchmark e escopo de aplicação

• No DeepSeek-R1-Distill-Qwen-1.5B, apresentou os seguintes resultados
  • GPQA-Diamond: 31,06%, melhoria relativa de 43% em relação à linha de base de 21,72%
  • MMLU-Pro: 26,38%, alta em relação à linha de base de 25,58%
  • Usa menos tokens do que a abordagem de referência
• O AutoThink pode ser aplicado a modelos locais de raciocínio em geral
  • Exemplos de modelos: DeepSeek, Qwen, modelos com fine-tuning customizado
  • Sem dependência de API
• Materiais relacionados
  • Technical paper
  • Code and examples
  • PTS implementation

[GN⁺]

Comentários do Hacker News

• Quero deixar claro que a motivação do AutoThink veio da experiência de observar modelos de raciocínio existentes desperdiçando recursos computacionais — a ineficiência ficava evidente ao ver que até perguntas muito fáceis, como “quanto é 2+2?”, consumiam o mesmo “tempo de pensamento” que uma prova matemática complexa. O mais surpreendente foi que, ao combinar duas coisas que eu vinha experimentando separadamente — classificação adaptativa (capaz de aprender novas categorias sem retreinamento) e o Pivotal Token Search, aberto como open source no artigo do Phi-4 da Microsoft — e aplicar a isso uma alocação dinâmica de orçamento de tokens, o ganho de desempenho foi muito maior do que eu esperava. Na prática, o número médio de tokens usados caiu, porque consultas simples realmente terminavam muito mais rápido e só as consultas complexas recebiam computação extra. Alguns pontos técnicos: o steering vector é pequeno, menos de 1 MB por padrão, então o overhead de memória é quase nulo; o processo de classificação adiciona cerca de 10 ms de latência, algo desprezível; e a escolha da target layer é importante (na maioria dos modelos, as camadas intermediárias 15~20 mostraram os melhores resultados). O que eu gostaria de ouvir como feedback: experiências com abordagens adaptativas parecidas, padrões de raciocínio que seriam mais úteis para steer, e ideias para detectar automaticamente a target layer ideal. Perguntem qualquer coisa sobre a implementação ou os resultados

  • Isso já não é necessariamente verdade. Você já usou o Gemini 2.5 Pro? Em perguntas simples ele quase não “pensa”, enquanto em perguntas de programação escreve respostas como longos artigos de lógica. O o3 parece ser igual

  • Parabéns! Toda tentativa de tornar LLMs mais eficientes é muito bem-vinda. Até agora venho fazendo uma otimização preguiçosa: no Mac Mini M4, uso modelos MLX só para consultas simples, e mando as complexas para uma Nvidia 4090 — a eficiência do M4 em comparação com a Nvidia é realmente impressionante. Acho que a Apple está no caminho certo com MLX. Vou ler mais sobre o AutoThink e planejo integrar ao meu fluxo de trabalho pessoal

  • Acho que valeria tentar inserir, depois do prompt do usuário, a “resposta de um non-reasoning model” — por exemplo: “A seguir está o que um non-reasoning model pensou: ... Isso é o resultado que o usuário quer?”. Quando a versão sem raciocínio for suficiente, pode haver a vantagem de o reasoning model também chegar à resposta mais rápido

  • Até o Claude Sonnet 3.5 (nem estou falando do 3.7 ou 4 mais recentes) já mostra tempos de processamento claramente diferentes dependendo da complexidade da consulta — dá para ver esse ajuste dinâmico do tempo de processamento

• Fico curioso sobre como é possível classificar uma pergunta como “complexa” ou “simples”. Uma pergunta aparentemente simples pode ser, na verdade, extremamente difícil. Por exemplo, a solução inteira de x³+y³+z³=42 exigiu mais de 100 anos de recursos computacionais. Ou uma expressão como x/(y+z)+y/(z+x)+z/(x+y)=4 também pode parecer simples à primeira vista, mas tem soluções gigantescas que exigem teoria de curvas elípticas. Link para a solução

  • Classificar a dificuldade de um problema é, por si só, uma técnica separada — é uma habilidade que pode ser aprendida independentemente da resolução em si. Por exemplo, ao olhar para a expressão acima, você deveria perceber imediatamente três dificuldades: domínio dos inteiros, três variáveis e uma equação cúbica. A combinação desses três fatores faz a dificuldade disparar. Se fossem números reais ou complexos, menos variáveis ou grau menor, seria bem mais fácil resolver. Claro que isso não significa necessariamente que seja difícil, mas pode indicar um problema não resolvido. Eu pessoalmente não tenho habilidade para resolver isso de fato, mas treinei para ter noção de onde procurar informação, então consigo perceber na hora que “isso é muito difícil”. Talvez um LLM também possa aprender esses indícios e desenvolver a capacidade de classificar a dificuldade do problema sem de fato resolvê-lo (ou talvez já tenha aprendido)

  • Neste contexto, a dificuldade da consulta é definida com base em quantos tokens o modelo consumiu para produzir a resposta correta em datasets com gabarito, como GSM8k. O classificador adaptativo é treinado nesse dataset e usa isso para classificar durante a inferência

• Quando saiu o toggle de extended thinking no Claude 3.7, eu também fiz um POC parecido com o autothink — inclusive com o mesmo nome
  github.com/NiloCK/autothink
  blog think-toggles-are-dumb
  Na minha versão, há uma primeira passada em que o LLM atribui uma nota de dificuldade de 0 a 100 para a consulta, e com base nessa nota o orçamento de pensamento é alocado linearmente. Claro que é mais simples que o trabalho do OP, mas fiquei realmente feliz em ver resultados quantitativos — trabalho muito bem feito!

• Parece uma otimização óbvia, e fico surpreso que essa mudança ainda não tenha acontecido. Impressionante como foi bem explicada e implementada

• Em modelos de raciocínio como QwQ ou Qwen 3, honestamente eu não gastei muito tempo tentando melhorar os resultados, só fiz tentativas de limitar a saída de reasoning tokens com prompts variados. O Gemma 3 27B QAT não é um modelo de raciocínio, mas é muito bom em seguir instruções quando usado em cadeias ou rotas de LLM, então pode ser empregado para pré-classificação/otimização de idioma e depois usado no estágio seguinte para o raciocínio real. Também é possível intercalar respostas intermediárias entre várias thinking tags. Nesses experimentos com modelos, “tokens de pensamento” são definidos separadamente da conclusão, como todos os tokens que servem de degraus para resolver o problema por etapas. Minha experiência é que instruir o modelo a priorizar certos tokens ou expressões específicas geralmente melhora o resultado, e a forma como o AutoThink usa automaticamente os tokens de melhor desempenho no dataset parece poder virar uma otimização mais geral e eficaz. Ainda assim, se usar pivot tokens demais, existe o risco de overfitting às perguntas do benchmark, então quero observar melhor o quanto isso generaliza. Pessoalmente, vejo a escolha cuidadosa de palavras/tokens como uma otimização barata e de alta eficiência que pode melhorar bastante a qualidade dos resultados, e tenho expectativa sobre a capacidade de generalização do AutoThink

• É muito legal que, graças aos modelos pequenos, equipes pequenas e pesquisadores individuais agora consigam provar abordagens inovadoras ou experimentos com muito mais facilidade, sem invejar os grandes labs de IA. À medida que a competitividade dos SMLs (Small Language Models) aumenta, o que pode ser implementado on-device se expande muito além do que se imaginava

  • Acho que o termo correto é SLM, não “small language models (SML)”

• Se você hospeda um modelo para outras pessoas, é ótimo também economizar recursos computacionais no tratamento de perguntas muito simples. Nesse caso, pode haver a desvantagem de o modelo tratar com menos cuidado perguntas que parecem fáceis, mas esse custo não sou eu quem paga. Por outro lado, se eu uso o modelo diretamente no meu PC, depois de já ter investido bastante em GPU, quero aproveitar ao máximo os recursos — reduzir computação até em consultas simples é algo que eu nem quero

• Bom ponto para reflexão! Nós também vamos discutir internamente, no desenho de crawlers de IA, a necessidade de reconhecer dinamicamente quando fazer mais ou menos consultas dependendo do site visitado. Para contexto, somos o samaritanscout.org, um projeto de mecanismo de busca que reúne todas as oportunidades locais de voluntariado publicadas em vários sites de organizações sem fins lucrativos

• Entrei muito recentemente no mundo de LLMs e IA, mas senti um grande interesse por este projeto. Acho extremamente intuitiva e marcante a ideia de o AutoThink ajustar o esforço computacional para fazer a IA “pensar de forma mais inteligente” dependendo da dificuldade do problema — dá para comparar com pessoas resolvendo 2+2 imediatamente e só refletindo seriamente sobre problemas difíceis. Não entendo bem os detalhes técnicos, como orçamento de tokens ou steering vector, mas fico fascinado com essa forma de ficar ao mesmo tempo mais rápido e mais inteligente. Vou continuar acompanhando

• Acho melhor não usar os termos “pensamento” ou “raciocínio” em LLMs — as duas palavras têm significados específicos e um pano de fundo filosófico, mas na prática os LLMs não pensam nem raciocinam assim; é mais um método computacional que dedica mais computação (tempo de processador) para gerar um resultado

  • Esse barco já partiu. Assim como “computador” no passado significava um calculista humano, mas hoje passou completamente a significar a máquina, aqui também houve uma mudança de uso do termo

  • Faço uma analogia com “ping” — quando você dá “ping” em um endereço IP, não está realmente emitindo ondas sonoras contra um casco de metal, mas o termo é usado metaforicamente de forma compatível com o funcionamento real. Se a metáfora for útil, ela é usada no dia a dia mesmo sem corresponder 1:1 à realidade

  • Minha visão de mundo é, em princípio, materialista e determinista. Mesmo assim, no cotidiano, misturo isso com existencialismo e até um pouco de sensibilidade espiritual. De um ponto de vista prático, atribuir temporariamente características antropomórficas a essas ferramentas pode facilitar o fluxo da conversa e ajudar a entendê-las intuitivamente. Às vezes esse método mostra limites, mas, quando isso acontece, acho fácil mudar para uma estrutura mais analítica