IA, inferência e tokens, meu Deus!

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Certo, pessoal, vamos parar tudo agora. Estou ouvindo termos como “tokens” e “modelos” sendo usados como se fossem gírias da geração Z em um vídeo do TikTok e, na maioria das vezes, de forma completamente errada.

Eu disse o que disse.

Já passou da hora de explicar como os aplicativos baseados em inferência são desenvolvidos, onde os tokens são criados e consumidos e como as várias peças desse quebra-cabeça se encaixam. Então, pegue um café e vamos direto ao assunto.

O que é um servidor de inferência?

Eu não deveria precisar começar por aqui, mas vou começar. Quando dizemos “inferência”, estamos falando, na verdade, da maneira como um modelo de linguagem de grande escala (LLM) raciocina com base em seu enorme volume de dados. Você não chama um LLM diretamente. Na verdade, não existe uma “API de LLM”, e vou lançar aquele “olhar de mãe” se você disser isso.

As APIs usadas para invocar a inferência passam — pasmem — por um servidor de inferência.

Os servidores de inferência são ambientes de execução para modelos de IA, assim como os servidores de aplicações são ambientes de execução para Java e diversas outras linguagens de desenvolvimento. Em geral, não se executa um modelo localmente sem um servidor de inferência. Entre as opções mais populares estão Ollama, vLLM, NVIDIA Triton e HuggingFace Text Generation Interface (TGI).

Agora, assim como nos servidores de aplicações — nos quais normalmente se implanta um pacote de aplicação —, você implanta um “pacote de IA” (um modelo) em um servidor de inferência. O servidor disponibiliza os recursos do modelo de IA por meio de uma API com um conjunto mínimo de endpoints (por exemplo, /generate, /completions ou /embeddings em REST ou gRPC), voltados a tarefas de inferência do modelo, como geração de texto, tokenização ou embeddings.

Para interagir com um servidor de inferência, você cria um aplicativo. Sim, um aplicativo tradicional (que pode ser moderno, porque é claro que pode) e ele se comunicará com o servidor de inferência.

Os usuários também têm um aplicativo, seja no navegador ou no celular, que geralmente usa uma API tradicional para se comunicar com o aplicativo que você criou. E voilà! Você tem um fluxo completo de mensagens, do cliente para o aplicativo, depois para o servidor de inferência e de volta.

Sim, na verdade, é apenas uma nova abordagem para a aplicação web de três camadas, em que a camada de dados é substituída pela camada de inferência. Eu sei, terrivelmente decepcionante, não é?

A forma mais simples de um aplicativo de IA é uma aplicação web de três camadas na qual a camada de dados é substituída por um servidor de inferência.

1. Recebe uma solicitação JSON, opcionalmente realiza geração aumentada por recuperação (RAG) e, em seguida, chama o servidor de inferência com JSON. RAG geralmente significa: criar um embedding da consulta do usuário, buscar conteúdo semelhante em um índice vetorial ou de pesquisa e inserir esses trechos no prompt. Tudo isso ainda é tráfego em formato JSON. Nenhum token do modelo foi criado até o momento.
2. O servidor de inferência analisa o JSON e tokeniza o texto nos tokens do modelo, verifica o contexto e as cotas, agrupa solicitações compatíveis em lotes, executa o modelo e, em seguida, decodifica os tokens de saída novamente em texto. Retorna uma resposta JSON ao solicitante. Se houver streaming, os tokens são decodificados e enviados à medida que são gerados. A maioria das APIs também inclui um bloco de uso com as contagens de tokens de entrada e saída.

Isso é inferência. Apenas um novo tipo de carga de trabalho de aplicações que recompensa a mesma disciplina operacional que sempre valorizamos, agora expressa em tokens, contexto e fluxos, em vez de sessões, cookies e consultas.

Afinal, onde estão os tokens?

É geralmente aqui que as pessoas se confundem e usam palavras de maneiras que violam a Primeira Diretriz da terminologia. Tokens são unidades de palavras processadas por um LLM. Eles são oficialmente gerados por um tokenizador no servidor de inferência.

Você pode incluir um tokenizador no seu aplicativo para contar os tokens antecipadamente, a fim de estimar custos e aplicar limites locais de uso, mas a contagem definitiva de tokens ocorre na infraestrutura de inferência. Os tokens são uma representação do modelo, não tráfego de rede; o que é transmitido pela rede é texto JSON. Você só verá os IDs dos tokens se a API os retornar explicitamente.

Por padrão, a infraestrutura não vê tokens. Ela vê JSON. Os tokens não trafegam pela rede. Se você quiser que a infraestrutura opere com base em tokens, deverá contá-los no gateway usando o mesmo tokenizador ou utilizar as contagens emitidas pelo servidor do modelo. Os tokens são a moeda da IA, mas permanecem, em sua maioria, dentro da pilha de inferência, a menos que você os exponha.

A implicação da inferência na infraestrutura

A inferência não é algo místico. É uma carga de trabalho de aplicação com novos parâmetros. O tráfego é JSON. Tokens são unidades do modelo. Embeddings são vetores. Confundir esses conceitos fará com que você projete controles inadequados, precifique a coisa errada e depure a camada errada. Por exemplo, o roteamento baseado no tamanho do JSON, em vez da quantidade de tokens, pode sobrecarregar um modelo com solicitações de contexto longo.

Se você quiser que a infraestrutura opere com base em tokens, ensine-a a fazer isso. Coloque um tokenizador no gateway ou use as contagens emitidas pelo servidor do modelo. Caso contrário, seus roteadores verão texto, não tokens, e tomarão decisões no nível do texto, enquanto seus custos serão acumulados no nível dos tokens. Observe que os tokenizadores devem corresponder ao modelo (por exemplo, o tokenizador do GPT-4 é diferente do usado pelo LLaMA) para garantir contagens precisas. Tokenizadores incompatíveis podem levar a cálculos incorretos de custos ou limites.

Considere disponibilidade como algo utilizável e correto, não apenas como estar no ar. Monitore tokens por segundo, tempo até o primeiro token e falhas de contexto (como exceder os limites da janela de contexto ou gerar saídas incoerentes devido a um contexto saturado) da mesma forma que você costumava monitorar consultas por segundo e acertos de cache. Leve os logs a sério. O tráfego de inferência não é dado de treinamento, a menos que você determine que seja. Se você armazenar prompts e saídas, proteja-os.

Dê os nomes certos às coisas. Meça a camada correta. Imponha limites onde eles realmente importam, como cotas baseadas em tokens no gateway para evitar estouros de custos. Faça isso e a inferência se comportará como o restante da sua stack: previsível, acessível e sem surpresas, no melhor sentido possível. Tokens compram decisões dentro do modelo, não largura de banda na sua rede. Chame cada coisa pelo nome e você manterá seus usuários satisfeitos e suas faturas enxutas.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie