O que realmente acontece quando você aperta enviar

1

Conceito

Apertar “enviar” inicia um workflow de sistemas distribuídos, não uma única chamada de modelo. Os componentes variam, mas um ciclo útil possui sete fronteiras: tratamento da requisição, montagem do prompt, tokenização, admissão e scheduling, execução do modelo, decoding e streaming, seguidos de limpeza. Cada fronteira possui falhas próprias de corretude e latência.

No edge ou API gateway, o serviço autentica quem chama, confere autorização e cota, valida o schema e atribui um request ID. Limites de bytes, mensagens, imagens, ferramentas e geração máxima precisam atuar antes do trabalho caro. Rate limiting fica aqui, não dentro de um prompt. Texto do usuário é dado não confiável; nunca pode ganhar autoridade sobre credenciais ou acesso a outro tenant.

A aplicação constrói a entrada do modelo. Combina instruções de system, histórico, resultados de ferramentas e a nova mensagem usando o chat template do checkpoint. Esse template insere tokens de papéis e fronteiras aprendidos no pós-treinamento. Dois templates visualmente parecidos podem criar sequências e comportamentos diferentes. A gestão do contexto trunca ou resume por uma política explícita; descartar a mensagem de system silenciosamente é bug.

O tokenizer mapeia texto para IDs inteiros. A validação precisa ocorrer antes e depois da tokenização, pois caracteres e tokens têm contagens diferentes. O servidor pode reutilizar um prefixo em cache quando a sequência inicial de tokens é idêntica. Caso contrário, a requisição entra na fila com comprimento do prompt, orçamento de saída, prioridade e necessidade de cache.

O scheduler decide a admissão. Pesos ocupam memória quase fixa; o KV cache cresce com sequências ativas. Uma requisição que cabe sozinha talvez não caiba ao lado do trabalho atual. Servidores modernos formam batches dinâmicos e combinam requisições em posições distintas, sem esperar o batch inteiro terminar. Fairness, deadlines e preemption decidem se uma geração longa bloqueia trabalho interativo curto.

Durante prefill, o modelo processa o prompt e grava keys e values em todas as camadas. A posição final produz logits para o primeiro novo token. O decoder aplica temperature, truncamento, constraints e uma regra de seleção. O token escolhido é anexado, e decode executa outro forward step usando os estados em cache em vez de recalcular o prompt.

O servidor faz detokenization incremental e envia eventos. Fronteiras de tokens não correspondem necessariamente a caracteres, palavras ou chunks UTF-8 válidos, então o buffer segue o decoder do tokenizer. Stop sequences, parsers de tool calls, filtros e structured output podem atrasar ou suprimir bytes. Backpressure importa: um cliente lento não deve reter memória ilimitada.

Cancelamento percorre o caminho inverso. Se a pessoa interrompe, a conexão fecha ou o deadline expira, a geração deve parar, o item deve sair da fila e os blocos voltar ao allocator. Cobrança e logs precisam da contagem real e do motivo final. Vazamentos de limpeza viram incidentes sob carga.

Observabilidade acompanha request IDs por essas etapas sem armazenar prompts sensíveis por padrão. Registre versões do modelo, tokenizer e template; fila; tokens de entrada e saída; cache; batch; TTFT; cadência; finish reason e erros. O modelo mental é um pipeline: a rede neural está no centro, mas scheduling, fronteiras e ownership decidem se ela vira serviço confiável.