HTTP 200 não prova isolamento: a lição do cache de inferência da Cloudflare

A Cloudflare relatou 155 respostas com dados de requisições de outros clientes em um incidente que afetou exclusivamente o GLM 5.3 no Workers AI, entre 27 de agosto e 9 de setembro de 2026.[3] As ocorrências identificadas estavam associadas a prompts acima de 681.280 tokens, e a empresa afirmou não ter encontrado evidência de exploração deliberada.[3] A divulgação é posterior à correção e restauração do serviço em setembro.[3]

O que muda para quem desenvolve

A janela anunciada aceitava 1.048.576 tokens, mas o pool de cache KV das GPUs de prefill comportava menos.[3] Na arquitetura com prefill e decode separados, uma rejeição interna ainda permitia encaminhar um processamento substituto, levando o decode a consultar páginas com conteúdo de requisições anteriores.[3] Respostas HTTP bem-sucedidas mascararam o problema nos testes iniciais.[3]

A leitura arquitetural é que uma validação no gateway não demonstra isolamento no motor de inferência. O contrato precisa atravessar alocação, transferência, cancelamento e reutilização de memória. A pergunta útil não é apenas se cada conta tem uma chave diferente, mas se uma requisição rejeitada pode deixar estado utilizável pela próxima.

Para quem integra um serviço compartilhado, a disponibilidade de uma janela de contexto não deveria ser a única condição de aceitação. Peça também evidências sobre tratamento de excesso de capacidade, abortos e separação entre clientes.

Como aplicar

Prepare duas contas de teste independentes e use somente dados sintéticos. Na primeira, inclua marcadores únicos em prompts de diferentes tamanhos. Na segunda, execute solicitações que não contenham esses marcadores. Inspecione o conteúdo das respostas, além dos códigos HTTP e da latência.

Repita o roteiro perto do limite configurado e em cenários de cancelamento. Defina previamente o que constitui falha: aparecimento de um marcador alheio, resposta após rejeição ou comportamento incompatível com o contrato da API. Um resultado negativo nesse conjunto não prova segurança universal, mas produz uma evidência mais relevante que contar respostas bem-sucedidas.

Para operadores de SGLang desagregado, o relato recomenda a versão 0.5.22 ou posterior e a conferência da capacidade real do cache após mudanças de pesos, paralelismo ou quantização.[3] Inclua essa conferência no procedimento de alteração do serviço, não apenas na instalação inicial.

Cuidados e limites

A correção relatada envolveu bloquear requisições rejeitadas antes da alocação e transferência, além de reforçar o ciclo de vida das páginas e o tratamento de abortos.[3] Aumentar memória, isoladamente, não representa todo esse trabalho.

Checksums e mecanismos de detecção variam conforme a arquitetura, e as iniciativas de identificação de propriedade das páginas e verificação formal ainda estavam em desenvolvimento.[3] Não transforme um plano de endurecimento em garantia já entregue. O caso pede contratos verificáveis entre componentes, não uma promessa genérica de isolamento.

Fonte

[3] Fonte: Cloudflare Blog