Inkling ensina modelos a administrar seu orçamento de raciocínio

A OpenRouter informou que comandos que exigem raciocínio podem consumir 10–1000× mais tokens do que aqueles que não exigem. A queda no preço dos tokens faz essa faixa parecer administrável — até que o modelo precise decidir quanto dela usar.

A ampliação da computação em tempo de inferência transformou capacidade em um insumo tarifado

O o3, da OpenAI, ajudou a demonstrar que mais computação em tempo de inferência poderia melhorar o desempenho em avaliações de referência, deslocando o foco para além da ideia de que quase toda capacidade precisava ser adquirida durante o pré-treinamento. A computação passou a poder ser aplicada depois da chegada do comando, por meio de deliberação mais longa, amostragens adicionais, verificação ou busca.

Depois que o desenvolvedor escolhe um modelo convencional e um comando, o custo da chamada parece aproximadamente fixo. Já um modelo de raciocínio pode gerar volumes diferentes de saída e consumir quantidades distintas de tempo e computação, conforme a duração da deliberação. O desenvolvedor pode ajustar a qualidade durante a inferência, mas a conta varia junto.

A busca em tempo de inferência trouxe outra forma de destinar computação a determinadas tarefas, embora especialistas questionem até que ponto os ganhos se aplicam de maneira ampla. Essa ressalva torna a alocação ainda mais importante. Se cada token adicional melhorasse todas as respostas na mesma proporção, a política seria simples: gastar tanto quanto o cliente estiver disposto a tolerar. Como o retorno depende da tarefa, “quanto gastar?” torna-se um problema de otimização à parte.

Os desenvolvedores também pagam em latência. Um modelo que demora mais pode melhorar a resposta, mas, em sistemas interativos, o tempo de espera faz parte da qualidade do produto. O sistema precisa ponderar a melhora esperada em relação ao custo dos tokens, ao atraso e a tudo o que a aplicação perde enquanto o modelo continua raciocinando.

Inkling atribui um preço implícito ao raciocínio durante o treinamento

O lançamento de Inkling pela Thinking Machines Lab vai além de permitir que os usuários solicitem diferentes níveis de esforço. Durante as trajetórias de aprendizagem por reforço, o laboratório variou tanto o esforço solicitado quanto um coeficiente de custo dos tokens de raciocínio, λ. O objetivo do treinamento penalizava o fracasso na tarefa e o uso de tokens de raciocínio.

Esse coeficiente funciona como um preço implícito do raciocínio. Quando λ muda, o modelo não recebe apenas a instrução de produzir uma resposta mais curta ou mais longa. Ele aprende uma política: diante da tarefa, do esforço solicitado e do preço implícito de continuar raciocinando, deve decidir se vale a pena usar mais computação.

O treinamento com penalidade por token faz mais do que acrescentar um botão “rápido” ao lado de outro “aprofundado”. Um modo estático exige que o usuário ou o desenvolvedor da aplicação defina o orçamento antecipadamente. Nesse caso, o modelo aprende como seu comportamento deve mudar conforme o orçamento varia.

A arquitetura de Inkling torna essa lógica de alocação particularmente clara. Trata-se de um modelo de mistura de especialistas com pesos abertos, 975B parâmetros totais e 41B parâmetros ativos, treinado para desenvolver capacidades amplas, e não restritas. A mistura de especialistas torna seletivo o uso da computação ao longo da largura do modelo. Variar o custo do raciocínio estende essa seletividade ao longo do tempo: não apenas qual capacidade deve ser ativada, mas por quanto tempo o sistema deve continuar empregando-a.

Como um modelo de uso amplo lida com tarefas heterogêneas, adotar um único nível fixo de esforço é uma escolha economicamente rudimentar. Alguns comandos não justificam uma deliberação prolongada; outros, sim. O treinamento com diferentes valores de λ dá ao modelo um motivo para distinguir essas situações, em vez de tratar o esforço máximo como definição padrão de qualidade.

Inkling, por si só, não permite concluir que a aprendizagem por reforço com penalidade por token encontra o orçamento adequado para diferentes cargas de trabalho em produção. O orçamento correto depende da distribuição das tarefas, dos requisitos de latência, da qualidade da avaliação e das consequências de uma falha. Uma penalidade por token pode ensinar parcimônia em relação a um objetivo de treinamento, mas não comprova que esse objetivo atribua o custo correto a um erro no mundo real.

Tokens mais baratos ainda podem tornar as tarefas mais caras

Os desenvolvedores já enfrentam essa pressão. Em uma análise que abrangeu mais de 100T tokens, centenas de modelos e mais de 3M usuários, a OpenRouter constatou que os modelos de raciocínio responderam por mais da metade do uso de tokens, enquanto o uso de modelos com pesos abertos cresceu de forma constante. Essa participação precisa ser interpretada com cuidado: comandos que exigem raciocínio podem consumir muito mais tokens do que aqueles que não exigem, portanto a maioria dos tokens não significa necessariamente a maioria dos comandos.

Quando um comando que exige raciocínio usa 10–1000× mais tokens, a queda do preço unitário não resolve a questão do custo. A redução do preço por token coincidiu com o aumento dos custos para os desenvolvedores, porque modelos de raciocínio mais recentes podem usar mais tokens para concluir uma tarefa. O insumo ficou mais barato, mas a quantidade necessária para cada resultado útil aumentou.

Por isso, os desenvolvedores devem acompanhar o custo de IA por tarefa útil, e não o preço do token isoladamente. Uma aplicação só deve consumir outra unidade de inferência quando a redução esperada do custo do erro superar a computação e a latência adicionais. Isso vincula o orçamento de raciocínio à decisão que o sistema ajuda a tomar.

Em uma tarefa de baixo impacto, o sistema racional pode aceitar uma resposta rápida ou um modelo mais barato. Quando o custo de errar aumenta, o mesmo sistema pode justificar um raciocínio mais longo, o uso de ferramentas, tentativas paralelas, verificação ou revisão humana.

Quem implanta o sistema também não pode usar a extensão visível do raciocínio como uma medida confiável de qualidade. Pesquisadores de alinhamento da Anthropic concluíram que a clareza e a fidelidade da cadeia de raciocínio não são confiáveis e que os modelos podem ocultar seu raciocínio. É possível contabilizar os tokens de raciocínio emitidos, mas seu volume não permite concluir que o processo interno do modelo foi transparente ou correto. As equipes precisam avaliar a alocação pelos resultados, e não se deixar impressionar pelas transcrições.

Pesos abertos transferem o controle do orçamento sem desfazer o poder da infraestrutura

Pesos abertos permitem que quem implanta o sistema examine, adapte e reproduza o comportamento posterior ao treinamento. Não é necessário aceitar a relação opaca que um fornecedor fechado estabelece entre esforço, latência e preço. Se os desenvolvedores conseguem incorporar ao modelo o controle do esforço e ajustá-lo às cargas de trabalho locais, passam a ter uma alternativa ao orçamento de raciocínio que um fornecedor de API decide oferecer.

A sequência mais ampla de produtos da Thinking Machines Lab aponta na mesma direção. Tinker, sua API de ajuste fino, passou a ter disponibilidade geral com suporte ao Kimi K2 Thinking, reforçando a ênfase em comportamentos adaptáveis após o treinamento. Em seguida, Inkling disponibiliza um modelo de ponta com pesos abertos para implantação e experimentação externas. Juntos, eles transferem parte do controle sobre o comportamento do modelo do catálogo do fornecedor para a estrutura de treinamento e implantação do desenvolvedor.

Pesos abertos não descentralizam a infraestrutura de raciocínio. A Thinking Machines Lab também fechou um acordo com a Nvidia para implantar mais de um gigawatt de chips Vera Rubin, acompanhado de um investimento significativo da Nvidia. Os pesos abertos mudam quem pode definir a política de orçamento, mas não eliminam a concentração de capital necessária para treinar e operar sistemas de ponta.

Um desenvolvedor pode controlar λ sem controlar o centro de dados. Os responsáveis pelas aplicações ganham mais opções de comportamento e de fornecedores, enquanto os provedores de computação concentrados mantêm a capacidade subjacente.

O orçamento final de raciocínio cabe ao fluxo de trabalho

Uma política de esforço aprendida é apenas a camada mais básica da alocação de computação. O modelo pode estimar se vale a pena prolongar o raciocínio, mas é a organização ao redor dele que arca com as consequências da decisão.

As equipes precisam tomar as decisões determinantes no encaminhamento das tarefas e no desenho dos fluxos de trabalho. Devem especificar quanto vale um resultado correto, quanto custa um erro, quando selecionar um modelo maior, em que situações ferramentas ou tentativas paralelas se justificam, quais evidências servem como verificação e onde o julgamento humano precisa entrar.

Nenhum produto pode se apoiar na regra de “sempre pensar mais”. Essa orientação trata a computação como gratuita, a latência como irrelevante e todos os erros como igualmente custosos. Um controle de esforço no nível do modelo pode economizar recursos dentro de uma chamada, mas o mecanismo de alocação do sistema precisa comparar essa chamada com outros modelos, outras ferramentas e até com a opção de não automatizar a decisão.

O modelo pode estimar se mais computação tende a melhorar uma resposta; quem implanta o sistema precisa decidir quanto vale pagar por essa melhora. Quando esses papéis se confundem, os fornecedores otimizam a capacidade visível, enquanto os clientes absorvem uma combinação sem preço explícito de latência, consumo de tokens e erro residual.

O λ de Inkling não resolve esse problema de alocação; ele o incorpora ao objetivo de treinamento. O comprador ainda precisa avaliar os modelos pelos resultados obtidos em cada tarefa, em vários níveis de esforço, e não por uma única pontuação de referência ou pelo preço do token.

A faixa informada de 10–1000× não é uma escada a ser percorrida em toda tarefa. A vantagem de quem implanta o sistema está em saber onde parar — quando o próximo token custa mais do que o erro que ele poderia evitar.