 |
| Bellacosa Mainframe introduz thinking tokens em ia |
☕ Um Café no Bellacosa Mainframe
O Que Todo Programador COBOL Precisa Saber Sobre os "Thinking Tokens"
Você Não Está Pagando por um Cérebro Artificial. Está Pagando por Tokens de Saída que Você Nunca Vê.
"Toda geração de programadores cria novos nomes para conceitos antigos. O desafio não é decorar a nova terminologia, mas compreender a engenharia que continua existindo por trás dela."
Durante décadas trabalhando com IBM Mainframe aprendemos uma lição importante.
Os nomes mudam.
A tecnologia evolui.
As interfaces ficam mais bonitas.
Mas os princípios fundamentais da computação continuam praticamente os mesmos.
Foi assim quando surgiram os bancos de dados relacionais.
Foi assim quando apareceram as CASE Tools.
Foi assim com Java.
Com SOA.
Com APIs.
Com Microservices.
Com Cloud.
E agora está acontecendo novamente com a Inteligência Artificial.
Um dos melhores exemplos dessa confusão moderna é a expressão Thinking Tokens.
Se você acompanha anúncios da OpenAI, Anthropic, Google, xAI ou DeepSeek, provavelmente já viu frases como:
O modelo utilizou 2.500 reasoning tokens.
Foram consumidos 8.000 thinking tokens.
O modelo pensou antes de responder.
O raciocínio interno foi ocultado.
Para quem está chegando agora ao universo dos LLMs, parece que existe uma nova categoria de tokens.
Como se o Transformer tivesse criado uma espécie de memória secreta onde a IA realmente "pensa".
Mas isso não é exatamente verdade.
Hoje vamos desmontar esse mito.
E, como sempre fazemos aqui no Bellacosa Mainframe, vamos explicar tudo usando conceitos familiares para quem passou anos desenvolvendo sistemas COBOL no IBM Z.
Pegue seu café.
Porque, no final deste artigo, você provavelmente enxergará os modelos de IA de uma maneira completamente diferente.
O primeiro erro é acreditar que existem três tipos de tokens
Muita documentação simplifica o assunto dizendo que existem:
Input Tokens
Output Tokens
Thinking Tokens
Parece lógico.
Mas essa classificação mistura arquitetura com marketing.
Na prática, um Transformer trabalha apenas com duas grandes fases:
Entrada (Prefill)
e
Saída (Decode)
Todo o resto são interpretações sobre aquilo que acontece durante a geração da resposta.
Vamos lembrar como funciona um programa COBOL
Imagine um programa extremamente simples.
ACCEPT WS-CLIENTE
PERFORM PROCESSA-DADOS
DISPLAY RESULTADO
STOP RUN.
Ninguém diria que existem três tipos de processamento.
Existe apenas:
entrada
processamento
saída.
A IA segue exatamente essa lógica.
O Pipeline de um Transformer
Todo Large Language Model moderno funciona aproximadamente assim:
Prompt
↓
Tokenização
↓
Embeddings
↓
Transformer
↓
Prefill
↓
KV Cache
↓
Decode
↓
Resposta
Observe uma coisa interessante.
Não existe nenhuma etapa chamada:
Thinking Engine
Nem:
Reasoning Processor
Nem:
Artificial Brain
Esses nomes simplesmente não existem dentro da arquitetura.
O Prefill é parecido com a leitura de um arquivo VSAM
Imagine um programa COBOL lendo um cadastro inteiro.
READ CLIENTES
Antes de tomar qualquer decisão, seu programa precisa conhecer o conteúdo.
O Transformer faz algo semelhante.
Quando você envia um prompt como:
Explique a arquitetura do CICS.
O modelo primeiro lê tudo.
Essa leitura acontece em paralelo.
Todas as palavras são analisadas simultaneamente.
Esse processo chama-se Prefill.
É como se o modelo dissesse:
"Primeiro vou entender completamente o problema."
O Decode lembra um programa Batch escrevendo registros
Depois que termina o Prefill, começa uma fase completamente diferente.
Agora o modelo precisa escrever.
E escreve exatamente como um programa COBOL grava registros.
Um por vez.
Token 1
↓
Token 2
↓
Token 3
↓
Token 4
Não existe paralelismo aqui.
Cada novo token depende do anterior.
Da mesma forma que um programa COBOL não consegue escrever o registro 500 antes de criar o registro 499.
É aqui que nasce o famoso "raciocínio"
Imagine que você perguntou:
Quanto é 27 × 34?
O modelo poderia gerar internamente algo parecido com:
27 × 30 = 810
27 × 4 = 108
810 + 108 = 918
Depois entregar apenas:
918
A pergunta é:
Onde aconteceu o raciocínio?
A resposta surpreende muita gente.
No mesmo lugar onde nasceu a resposta final.
Durante o Decode.
Não existe um mecanismo separado.
O maior mito da IA moderna
Muitas pessoas imaginam algo parecido com isto.
Prompt
↓
Cérebro Artificial
↓
Resposta
Bonito.
Mas incorreto.
Na realidade acontece algo muito mais simples.
Prompt
↓
Decode
↓
Token
↓
Token
↓
Token
↓
Token
↓
Resposta
O chamado raciocínio nada mais é do que uma sequência maior de tokens produzidos antes da resposta definitiva.
Os Thinking Tokens são apenas Output Tokens
Esse talvez seja o conceito mais importante deste artigo.
Do ponto de vista da arquitetura Transformer, não existe diferença entre escrever:
Vou resolver passo a passo...
e escrever:
A resposta é 918.
Os dois são produzidos exatamente pelo mesmo algoritmo.
Mesmo Softmax.
Mesmo Sampling.
Mesma GPU.
Mesmo Decoder.
Mesma KV Cache.
Mesmo mecanismo autoregressivo.
A única diferença é o destino dado a esses tokens.
Quem esconde os Thinking Tokens?
Essa é outra dúvida comum.
Muita gente acredita que o próprio Transformer possui um compartimento secreto onde guarda pensamentos.
Não possui.
Quem decide ocultar esses tokens é a aplicação que envolve o modelo.
Imagine um programa COBOL gerando um relatório.
Durante o processamento ele escreve dezenas de mensagens no SYSOUT.
Lendo arquivo...
Registro encontrado...
Validando CPF...
Atualizando saldo...
Fim do processamento.
Mas o usuário recebe apenas:
Processamento concluído com sucesso.
As mensagens existiram.
Foram produzidas.
Consumiram CPU.
Consumiram I/O.
Mas nunca apareceram na tela do usuário.
É exatamente isso que acontece com os Thinking Tokens.
Por que eles custam dinheiro?
Aqui chegamos ao ponto que interessa às empresas.
Imagine duas respostas.
Resposta A
100 tokens.
Resposta B
900 tokens ocultos
100 tokens visíveis.
Qual delas custa mais?
A segunda.
Mesmo que você nunca veja os 900 tokens.
Por quê?
Porque a GPU precisou calcular todos eles.
Cada token exige milhares de operações matemáticas.
Multiplicações matriciais.
Atenção.
Softmax.
Sampling.
Atualização do KV Cache.
Nada disso é gratuito.
A infraestrutura trabalhou para gerar cada token, mesmo aqueles descartados antes da entrega.
Pense como um gerente de CPD dos anos 1980
Quem trabalhou com IBM Mainframe lembra muito bem.
O usuário não pagava apenas pelas páginas impressas.
Pagava pelo tempo de CPU.
Pelo canal.
Pelo DASD.
Pela memória.
Pelos acessos ao banco.
Com IA acontece exatamente o mesmo.
Você não paga apenas pelo texto recebido.
Você paga por todo o processamento necessário para produzir esse texto.
Mesmo quando parte dele nunca chega até você.
Existe realmente pensamento?
Agora entramos numa questão filosófica.
Quando o modelo escreve:
Vou resolver primeiro a multiplicação.
Depois farei a soma.
Agora posso responder.
Ele realmente está pensando?
Depende da definição de pensamento.
Do ponto de vista computacional, isso é apenas texto sendo gerado.
Não existe consciência.
Não existe intenção.
Não existe uma voz interior.
Existe apenas previsão estatística do próximo token mais provável.
Ainda assim, esse processo produz um comportamento que lembra muito o raciocínio humano.
É um exemplo clássico de comportamento emergente.
A inteligência não aparece porque existe um módulo chamado "pensamento".
Ela emerge da sequência de bilhões de operações matemáticas executadas ao longo da geração dos tokens.
Uma analogia que todo programador COBOL entenderá
Imagine um analista experiente escrevendo um programa.
Primeiro ele faz um rascunho.
Abrir arquivo.
Validar cliente.
Atualizar saldo.
Fechar arquivo.
Depois escreve comentários.
Depois reorganiza os parágrafos.
Depois remove código.
No final entrega apenas o programa limpo.
Ninguém vê o rascunho.
Mas ele existiu.
Consumiu tempo.
Consumiu esforço.
Os Thinking Tokens são exatamente esse rascunho.
O papel da auditabilidade
Em ambientes corporativos, especialmente bancos, seguradoras e órgãos governamentais, entender esse processo é essencial.
Imagine um modelo aprovando um empréstimo.
Ele responde apenas:
Aprovado.
Mas internamente gerou centenas de tokens avaliando renda, histórico, garantias e inconsistências.
Esses tokens podem ser úteis para auditoria, depuração e análise de qualidade. Ao mesmo tempo, expô-los integralmente pode revelar detalhes do funcionamento do modelo, facilitar ataques ou criar interpretações equivocadas. Por isso, muitos fornecedores optam por ocultá-los e fornecer mecanismos de explicação específicos em vez da cadeia completa de raciocínio.
Essa distinção é especialmente importante em ambientes regulados, onde transparência e segurança precisam coexistir.
O verdadeiro modelo mental
Depois de tudo isso, talvez seja melhor abandonar a ideia de três tipos de tokens.
Pense apenas assim.
Entrada
O modelo lê.
(Prefill)
Saída
O modelo escreve.
(Decode)
Dentro da saída podem existir:
tokens mostrados;
tokens resumidos;
tokens ocultados;
tokens descartados.
Mas continuam sendo apenas saída.
O que um Programador COBOL Padawan deve aprender com isso?
Se você está começando sua jornada em Inteligência Artificial depois de anos trabalhando com COBOL, CICS, JCL e DB2, a principal lição é simples:
não se deixe impressionar pela terminologia de marketing.
Sempre procure entender a arquitetura por trás dos nomes.
Foi assim com:
CASE Tools;
Orientação a Objetos;
SOA;
ESB;
APIs REST;
Microservices;
Cloud Computing.
Agora acontece novamente com os LLMs.
Os nomes mudam.
Os princípios permanecem.
Quem entende arquitetura enxerga além das buzzwords.
O Café Terminou...
Durante décadas, os profissionais de Mainframe aprenderam a separar interface de implementação. Um operador via apenas uma tela do CICS; por trás dela existiam TCBs, filas, buffers, logs, gerenciamento de memória e milhares de instruções executadas silenciosamente. Da mesma forma, um usuário conversa com um chatbot e recebe uma resposta elegante, mas por trás dela ocorreu uma longa sequência de cálculos matriciais e geração de tokens.
Os chamados Thinking Tokens não são uma terceira categoria mágica de dados. Eles não representam um "cérebro oculto" nem um mecanismo especial de raciocínio. São, simplesmente, tokens de saída gerados durante o Decode, produzidos pelo mesmo algoritmo que gera a resposta final. A diferença não está na arquitetura do Transformer, mas na política da plataforma: alguns tokens são entregues ao usuário; outros permanecem ocultos.
Para o programador COBOL, essa distinção soa familiar. Assim como um JOB Batch pode produzir centenas de mensagens no SYSOUT enquanto o usuário recebe apenas um relatório resumido, um LLM pode gerar centenas de tokens intermediários antes de apresentar sua resposta. O processamento aconteceu. A CPU — ou, neste caso, a GPU — trabalhou. O custo foi incorrido. Apenas a visibilidade mudou.
No fim das contas, a maior habilidade continua sendo a mesma que diferenciou bons profissionais de Mainframe durante décadas: compreender os mecanismos internos, e não apenas decorar os nomes das tecnologias da moda. Quem domina os fundamentos consegue atravessar gerações de plataformas, linguagens e arquiteturas sem perder a capacidade de entender o que realmente está acontecendo dentro da máquina.
Porque, ontem como hoje, a engenharia continua sendo muito mais interessante do que o marketing.
