Seu prompt com mais de 700 mil tokens volta com um trecho de código que você nunca enviou, com nomes de variáveis, comentários internos e até uma chave que parece privada. Foi exatamente isso que aconteceu com o GLM-5.3 na Workers AI. O modelo voltado para coding agents com janela de 1 milhão de tokens começou a cuspir dados de outras sessões, de outros clientes, na mesma infraestrutura. Não foi alucinação, foi vazamento de memória real entre tenants.

Para quem opera LLM em produção, esse é o pesadelo clássico do multi-tenant. Você otimiza para throughput, ativa prefill e decode separados, empilha requisições longas na mesma GPU para economizar VRAM e, de repente, o isolamento lógico que deveria separar cada cliente falha na camada mais baixa possível, o KV cache. O caso do GLM-5.3 mostra como um detalhe de configuração mais um bug de engine podem transformar contexto longo em exposição cruzada.

PublicidadeAnuncie aqui336x280 / responsivo

O fato

Entre 27 de agosto e 9 de setembro de 2026, um pequeno grupo de clientes usando o modelo identificado como @cf/zai-org/glm-5.3 na Workers AI recebeu respostas contaminadas com dados de requisições anteriores feitas por outros clientes ao mesmo modelo. No total, foram 155 respostas afetadas, todas com prompts acima de 681.280 tokens. O alerta veio em 8 de setembro por meio de um pesquisador de segurança via programa de bug bounty, a Cloudflare reproduziu no dia seguinte e tirou o modelo do ar em cerca de 40 minutos após declarar o incidente.

Após investigação, a empresa afirmou que não encontrou evidência de exploração deliberada. Os padrões de tempo e volume eram compatíveis com uso normal de contexto longo, não com alguém forçando o bug repetidamente, além dos testes do próprio pesquisador e da equipe interna. O serviço foi restaurado no dia 9 com configuração corrigida e engine com patch. Nenhum outro modelo hospedado na Workers AI foi afetado, segundo a apuração interna.

Como funciona na visão de operador

Para entender o bug, pense em como funciona a inferência moderna para economizar custo. Em modo desagregado, você separa prefill e decode em GPUs diferentes. O prefill lê o prompt inteiro, calcula as chaves e valores de atenção, o famoso KV cache, e transfere esse bloco de memória para o nó de decode, que gera token por token olhando para esse cache. É eficiente porque permite escalar cada etapa separadamente, mas cria uma dependência crítica. O decode precisa confiar que o cache que recebeu é 100 por cento daquela requisição.

Aqui entraram dois problemas sobrepostos. Primeiro, uma má configuração. O GLM-5.3 foi publicado com janela anunciada de 1.048.576 tokens, mas o pool de KV cache nas GPUs de prefill só tinha espaço para cerca de 681.280 tokens. A equipe sabia do descompasso antes do lançamento e esperava que a engine retornasse erro para prompts que não coubessem. Como os testes de contexto longo retornaram respostas com sucesso, a hipótese era de que estava tudo bem. Não estava.

Segundo, um bug no SGLang, a engine open source usada na produção. Quando um prompt não cabia no pool, ele era marcado internamente como rejeitado e trocado por um placeholder de um único token. Em vez de abortar e devolver erro ao cliente, o prefill gerava o KV daquele placeholder minúsculo e mandava um sinal de 'transfer complete' para o decode. O decode assumia que o prefill tinha sobrescrito todo o cache anterior com o prompt atual, quando na prática a maior parte das páginas antigas continuava intacta. Resultado, o decode gerava a resposta atendendo a páginas velhas, com dados de sessões anteriores. É plausível que, sem limpeza explícita por requisição, qualquer slot reutilizado rapidamente herde resíduos, e com prompts gigantescos a janela para colisão aumenta muito.

O que isso muda na prática

Quem usa Workers AI ou qualquer API serverless para agentes com repositórios inteiros no prompt precisa mudar o checklist agora. Contexto de 1 milhão de tokens parece mágica para coding workflows, mas cada 100 mil tokens extras aumentam pressão sobre VRAM, latência de prefill e superfície para bugs de isolamento. Quem ganha com a correção são os times que dependem de contexto longo real, porque agora o pool de prefill tem cerca de 2,04 milhões de tokens, quase o dobro da janela, o que elimina o caminho de rejeição para requisições válidas. Quem perde é quem assumia que isolamento multi-tenant era garantido por padrão sem validar.

  • Ação prática imediata: se você envia segredos, código proprietário ou dados de clientes para APIs compartilhadas, crie uma política de sanitização e limite operacional, por exemplo travar em 500 mil tokens e quebrar repositórios em retrieval em vez de colar tudo no prompt, além de rodar canários com strings únicas para detectar contaminação cruzada nos logs.
  • Para builders: monitore taxa de erro em prompts longos, p99 de time to first token e respostas com perplexidade estranha ou trechos fora do contexto, e prefira deploys dedicados ou com isolamento físico para workloads sensíveis até o provedor provar limpeza de KV por requisição.
  • Para provedores: esse caso vira referência, pool precisa sempre ser maior que o contexto anunciado, caminho de rejeição precisa abortar de verdade e testes precisam incluir prompts no limite, não só casos felizes.

Isso escala ou só move o gargalo

A correção aplicada resolve o sintoma direto, sobrar memória para que o pool nunca estoure. Mas ela escancara a tensão real. Para suportar 1 milhão de tokens com folga, foi preciso ajustar a configuração para algo parecido com a do GLM 5.2 e liberar VRAM suficiente para 2 milhões de tokens no prefill. Isso tem custo. Memória de GPU é o recurso mais caro da pilha, e dobrar o pool significa menos concorrência, menos throughput ou GPUs maiores. Em outras palavras, contexto longo barato em infra compartilhada cobra seu preço em outro lugar, seja em custo, latência ou risco.

E fica a dúvida de operador que importa. Se um placeholder de um token consegue enganar o handshake entre prefill e decode, quantos outros caminhos de falha silenciosa existem em engines otimizadas para velocidade. O fix pontual mais a promessa de hardening no SGLang ajudam, mas isolamento forte exige prova contínua, com fuzzing de prompts gigantes, reutilização agressiva de slots e auditoria de limpeza de cache. Sem isso, a gente só trocou um erro visível por uma suposição nova de que agora há memória suficiente.

Conclusão

O vazamento do GLM-5.3 foi contido, afetou 155 respostas em contexto extremo e já foi corrigido com mais memória e patch na engine. Mas deixa o recado para quem constrói com IA. Você confiaria seu código mais sensível a um pool de memória compartilhado que você nunca auditou.