Certo, pessoal, parem agora. Tenho ouvido termos como "tokens" e "modelos" circulando como gírias da Geração Z em vídeo de TikTok, e na maioria das vezes são usados de forma errada.
Eu disse o que tinha para dizer.
Já passou da hora de explicar como construímos aplicações baseadas em inferência, onde criamos e consumimos tokens, e como encaixamos todas as peças do quebra-cabeça. Então pegue um café e vamos começar.
Eu não precisaria começar por aqui, mas vou começar. Quando falamos em “inferência”, estamos nos referindo à forma como um grande modelo de linguagem (LLM) processa seu imenso volume de dados. Você não acessa um LLM diretamente. Na verdade, não existe uma “API LLM”, e vou te lançar aquele olhar sério se você disser isso.
As APIs usadas para invocar a inferência passam, acredite, por um servidor de inferência.
Servidores de inferência são ambientes para executar modelos de IA, assim como servidores de aplicativos são para Java e várias outras linguagens de desenvolvimento. Você normalmente não roda um modelo localmente sem um servidor de inferência. Entre as opções populares estão Ollama, vLLM, NVIDIA Triton e HuggingFace Text Generation Interface (TGI).
Agora, assim como você normalmente implanta um pacote de aplicação em servidores de aplicativos, você implanta um “pacote de IA” (um modelo) em um servidor de inferência. Esse servidor oferece os recursos do modelo de IA via uma API com um conjunto mínimo de endpoints (por exemplo, /generate, /completions ou /embeddings em REST ou gRPC) focados em tarefas de inferência do modelo, como geração de texto, tokenização ou embeddings.
Para interagir com um servidor de inferência, você desenvolve uma aplicação. Sim, uma aplicação tradicional (que pode ser moderna, claro) e ela se comunicará com o servidor de inferência.
Os usuários também usam um app, seja no navegador ou no celular, que normalmente se comunica com o app que você criou por meio de uma API simples. E pronto! Você garante o fluxo completo de mensagens do cliente para o app, pelo servidor de inferência, e de volta.
Sim, trata-se basicamente de uma nova versão da aplicação web em três camadas, onde a camada de dados foi trocada pela camada de inferência. Eu sei, bem frustrante, não é?
A forma mais simples de uma aplicação de IA é uma aplicação web de três camadas em que a camada de dados é substituída por um servidor de inferência.
Isso é inferência. É apenas um novo tipo de carga de trabalho das aplicações que valoriza a mesma disciplina operacional que sempre praticamos, agora representada por tokens, contexto e fluxos, em vez de sessões, cookies e consultas.
É comum as pessoas se confundirem e usarem termos de forma a contrariar a Diretriz Principal da terminologia. Tokens são unidades de palavras que um LLM processa. Um tokenizador os gera oficialmente no servidor de inferência.
Você pode incluir um tokenizador no seu aplicativo para contar tokens antecipadamente e prever custos ou impor limites locais de uso, mas a contagem definitiva de tokens ocorre na pilha de inferência. Tokens representam o modelo, não o tráfego de rede; o tráfego sob demanda é transportado em texto JSON. Você só verá IDs de tokens se a API retorná-los explicitamente.
Por padrão, a infraestrutura não reconhece tokens. Ela reconhece JSON. Os tokens não circulam na rede. Se você quer que a infraestrutura lide com tokens, deve contá-los no gateway usando o mesmo tokenizador ou realizar a contagem que o servidor do modelo fornece. Tokens são a moeda da IA, mas ficam concentrados na pilha de inferência, a menos que você os exponha.
Inferência não é mística. Ela é uma carga de trabalho de aplicação com novos ajustes. O tráfego é JSON. Tokens são unidades do modelo. Embeddings são vetores. Se você confundir esses conceitos, vai criar controles errados, definir preços inadequados e resolver problemas na camada incorreta. Por exemplo, rotear com base no tamanho do JSON ao invés da contagem de tokens pode sobrecarregar um modelo com solicitações de contexto longo.
Se você quer que a infraestrutura aja sobre tokens, ensine-a a fazer isso. Coloque um tokenizador no gateway ou use as contagens que o servidor do modelo gera. Caso contrário, seus roteadores vão enxergar texto, não tokens, e tomarão decisões baseadas no texto enquanto seus custos são registrados no nível dos tokens. Lembre-se de que os tokenizadores precisam ser compatíveis com os do modelo (por exemplo, o tokenizador do GPT-4 é diferente do LLaMA) para garantir contagens precisas. Tokenizadores incompatíveis podem causar erros nos cálculos de custos ou limites.
Considere a disponibilidade como utilizável e precisa, não apenas ativa. Monitore tokens por segundo, tempo até o primeiro token e falhas de contexto (como ultrapassar limites da janela de contexto ou resultados incoerentes devido a saturação do contexto) do mesmo jeito que você monitorava consultas por segundo e acertos no cache. Armazene logs com responsabilidade. Tráfego de inferência não se torna dado de treinamento a menos que você defina assim. Se guardar prompts e respostas, proteja-os.
Dê nomes corretos às coisas. Meça a camada certa. Estabeleça limites onde realmente importam, como cotas baseadas em tokens no gateway para evitar estouros de custo. Ao fazer isso, a inferência se comportará como o restante da sua infraestrutura: previsível, econômica e segura de modo eficiente. Tokens controlam decisões dentro do modelo, não o uso de largura de banda na sua rede. Dê o nome correto e você manterá seus usuários satisfeitos e suas contas sob controle.