Análise aprofundada · Cerca de 6 min de leitura
Cloudflare detalha o incidente de isolamento de cache do GLM-5.3 e os limites de respostas bem-sucedidas
A divulgação de 26 de outubro distingue a exposição de agosto e setembro das correções e do trabalho de integridade ainda incompleto.
- Publicado aqui
- Data da fonte
- Fonte verificada
Em 26 de outubro, a Cloudflare publicou um relato de exposição de dados entre solicitações no GLM-5.3 do Workers AI. A empresa atribui o incidente a uma diferença de capacidade e a uma falha de rejeição no SGLang. O serviço foi corrigido em 9 de setembro; o texto não descreve uma nova interrupção nem comprova um defeito em todas as implantações do modelo.
Ouça as notícias
Ouça este artigo ou continue ouvindo as notícias.
Preparando a leitura…
Voz do dispositivo
O navegador ou dispositivo processa a voz. O AISubHub não envia o texto a uma API de áudio. As vozes e a reprodução com a tela bloqueada variam conforme o dispositivo.
Ao continuar, uma frase curta pode se repetir.
Resumo
- A Cloudflare relata 155 respostas afetadas de 27 de agosto a 9 de setembro, todas para prompts acima de 681 280 tokens. O número é de respostas, não de clientes.
- O contexto anunciado era de 1 048 576 tokens, mas o pool de prefill comportava 681 280. Após a correção, comporta cerca de 2,04 milhões; a rejeição do motor também foi reparada.
- A recomendação para operadores desagregados é SGLang v0.5.22 ou posterior. A cobertura da detecção depende da arquitetura e as medidas futuras não são uma garantia universal.
Divulgação e janela do incidente têm datas distintas
A Cloudflare situa a exposição entre o lançamento no Workers AI em 27 de agosto e 9 de setembro. Gadi Evron, da Knostic, reportou o problema em 8 de setembro. No dia 9, a empresa declarou o incidente às 13:22 UTC, restringiu o modelo às 14:00 e restaurou o acesso público às 19:40, após alterações e validação. A publicação coordenada ocorreu em 26 de outubro.
Foram identificadas 155 respostas com dados de solicitações recentes de outros clientes ao mesmo modelo. Excluindo seus próprios testes e os do pesquisador, a empresa considera os horários e volumes compatíveis com uso normal de contexto longo, sem indícios de exploração deliberada. Isso não prova que jamais houve abuso. A empresa também afirma que os outros modelos do Workers AI não foram afetados.
O contexto anunciado excedia o pool físico
Nessa implantação, GPUs de prefill processavam o prompt e enviavam o cache de chaves e valores por Mooncake sobre RDMA para GPUs de decode. O SGLang calculava o pool com a memória restante após carregar os pesos. O contexto era configurado separadamente: uma janela de 1 048 576 tokens coexistia com capacidade para somente 681 280.
A Cloudflare admite conhecer a diferença antes do lançamento, mas presumiu que solicitações excessivas falhariam com segurança porque os testes devolviam sucesso. O relatório reconhece que verificou status HTTP e desempenho sem validar adequadamente a saída. Trata-se da interação entre configuração e motor; o relato não fornece evidência de uma porta dos fundos nos pesos do modelo.
Uma rejeição pendente continuou sendo admitida
O escalonador marcava a solicitação grande demais para rejeição e substituía o prompt por um marcador de um token. Na implantação desagregada, a admissão verificava se a solicitação havia terminado, não se fora rejeitada. O erro pendente não tornava essa condição verdadeira. Prefill e decode aceitavam uma solicitação que deveria encerrar com erro.
O diagrama usa oito páginas reservadas para explicar o problema: a solicitação escrevia uma página, mas decode podia ler também sete páginas antigas. Esses números são ilustrativos, não totais observados do incidente. O cliente podia receber HTTP 200, contagem plausível e texto coerente contendo dados anteriores. Uma entrega bem-sucedida não comprovava isolamento correto.
A correção imediata teve duas camadas
A Cloudflare diz ter ajustado a configuração para que o pool de prefill comportasse aproximadamente 2,04 milhões de tokens, acima do contexto de 1 048 576. Também encerrou rejeições pendentes na admissão, antes de alocação ou transferência, validando ambas as mudanças antes da reabertura. Aumentar apenas o pool manteria uma dependência frágil de futuras configurações de memória.
A tabela separa a correção inicial em v0.5.20, a rejeição antecipada em v0.5.21 e os reforços até v0.5.22. A empresa recomenda v0.5.22 ou posterior, ou a aplicação dos patches correspondentes, aos operadores desagregados. A orientação se refere a esse modo de serviço, não é comparação de desempenho nem prova de segurança automática ao instalar uma versão.
Escritas em trânsito tornam a liberação distribuída
O relato explica outra classe de falha: abortar uma solicitação não recolhe escritas RDMA já enviadas. Reutilizar páginas cedo demais permite que escritas atrasadas corrompam outra solicitação. Diferentemente dessa corrida temporal, a rejeição deste incidente seguia deterministicamente o caminho errado. Ambos os casos exigem conservar a propriedade até o fim das operações participantes.
A Cloudflare descreve liberação adiada nos dois papéis, lotes Mooncake limitados, mudanças de desconexão no balanceador e verificações de implantação. Recomenda medir os pools reais após mudanças de pesos, quantização ou paralelismo. Checksum e KV Canary ainda não cobrem toda arquitetura; a cobertura deve ser confirmada, sem presumir que ativar uma opção verifica todas as solicitações.
O trabalho de integridade continua incompleto
Um protótipo de etiquetas de página foi testado em GLM-5.2 em agosto. A Cloudflare informa custo inferior a 1% em vazão e latência de cauda, mas o desativou pouco depois por problemas de confiabilidade. O número descreve um experimento limitado, não uma proteção atual ou custo universal. Zerar páginas na liberação ainda aparece como proposta preliminar.
Checksums validam a transferência; verificar a propriedade das páginas estenderia a proteção às leituras seguintes. A Cloudflare também pretende modelar formalmente o protocolo distribuído, reconhecendo limites das provas. Análise do AISubHub: isolamento, rejeição e ciclo de vida devem ser validados separadamente, distinguindo controles implantados, protótipos e garantias futuras.
Por que importa
Análise do AISubHub: o isolamento entre clientes precisa de critérios próprios de aceitação. Status HTTP, contagem de tokens e velocidade podem parecer normais quando a propriedade da memória está errada; testar configuração e caminhos de falha é diferente de medir desempenho.
Limites e disponibilidade
O alcance, a correção e a ausência de indícios de exploração deliberada são declarações da Cloudflare. O AISubHub não auditou o serviço ou os patches. O relato não comprova que toda implantação GLM foi afetada nem que qualquer configuração SGLang esteja imune a falhas no ciclo de vida do cache.
Fontes e evidências
Data da fonte: · Fonte verificada:
Conteúdo editorial com apoio de IA, verificado em fontes primárias. Alegações dos fornecedores são atribuídas; inclusão não é recomendação.