A Atenção Esparsa do GLM-5.3 Reduz a Computação, mas a Demanda por HBM Persiste
A atenção esparsa do GLM-5.3 reduz quanto contexto cada operação de atenção lê, mas não elimina automaticamente o problema de capacidade de HBM do modelo. Uma análise de 28 de setembro constatou que selecionar tokens relevantes ainda pode exigir acesso ao histórico completo do contexto. O resultado desafia uma suposição sedutora: menos tokens atendidos necessariamente significam proporcionalmente menos memória de GPU.
Essa distinção importa porque o GLM-5.3 é voltado a tarefas prolongadas de programação e agentes, nas quais o contexto se acumula entre chamadas de ferramentas, arquivos, resultados de testes e revisões. A atenção esparsa reduz o trabalho dentro do cálculo principal de atenção. O cache KV, que armazena representações reutilizáveis de chaves e valores de tokens anteriores, pode continuar crescendo com a sequência completa.
DeepSeek Sparse Attention fornece o ponto de referência arquitetural. Seu indexador identifica um conjunto limitado de tokens úteis antes de o modelo realizar seu cálculo principal de atenção. O GLM-5.3 combina esse método com representações de cache comprimidas, reutilização de índices entre camadas e software de serving capaz de mover entradas inativas de cache para a memória do host.
A disputa central, portanto, não é apenas entre atenção esparsa e atenção densa. É entre a esparsidade algorítmica e a exigência física de manter uma conversa longa disponível. Essa disputa determina se as economias de memória aparecem como menor capacidade de HBM, menor demanda por largura de banda, maior concorrência ou simplesmente um equilíbrio diferente entre GPUs e memória do sistema.
O Que a Atenção Esparsa do GLM-5.3 Realmente Muda
O GLM-5.3 reduz a quantidade de trabalho dispendioso de atenção por token, mas o modelo ainda precisa de uma forma de localizar informações relevantes em todo o seu histórico.
O GLM-5.3 faz parte da família GLM-5 da Z.ai, que utiliza uma arquitetura mixture-of-experts. Um modelo mixture-of-experts ativa apenas parte de seu conjunto total de parâmetros para cada token. Segundo o relatório GLM-5, a família combina essa computação roteada com um design de atenção para contextos longos derivado do trabalho da DeepSeek.
A Z.ai afirma que o GLM-5.3 usa o mesmo modelo-base do GLM-5.2. Seus ganhos de capacidade relatados vêm de pós-treinamento, e não de outra rodada de pré-treinamento do modelo-base. Essa distinção significa que a discussão atual sobre memória diz respeito a como a arquitetura existente se comporta sob cargas reais de serving, não a uma camada de atenção GLM-5.3 recém-inventada.
O mecanismo relevante é DeepSeek Sparse Attention, ou DSA. A atenção esparsa limita a atenção completa a um subconjunto selecionado de tokens anteriores, em vez de processar cada token prévio com o mesmo custo. A DeepSeek introduziu o design voltado à produção em sua pesquisa V3.2.
A DSA primeiro executa um componente leve chamado lightning indexer. O indexador pontua posições anteriores e escolhe os tokens top-k, isto é, o conjunto limitado considerado mais relevante para a consulta atual. O cálculo principal de Multi-Head Latent Attention então opera sobre essas posições selecionadas.
Multi-Head Latent Attention, ou MLA, armazena representações latentes comprimidas em vez de um vetor completo separado de chave e valor para cada cabeça de atenção. Essa compressão reduz o cache armazenado por token. A seleção esparsa então reduz quanto desse cache a operação principal de atenção lê.
Essas são duas economias diferentes. A MLA reduz o tamanho do estado em cache de cada token. A DSA reduz o número de posições em cache consumidas pelo cálculo dispendioso de atenção.
A combinação altera substancialmente o perfil de computação e largura de banda. A atenção central pode deixar de processar relações em todo o contexto para processar uma seleção top-k fixa. Em sequências longas, isso limita o crescimento da carga de trabalho principal de atenção.
No entanto, o lightning indexer ainda precisa de informações suficientes para pontuar candidatos em todo o histórico retido. O modelo não pode selecionar um token antigo se o sistema de serving descartou toda representação utilizável desse token.
A análise da SemiAnalysis identifica isso como a limitação crucial. A atenção esparsa reduz o tráfego de memória durante a operação central de atenção scaled dot-product. Ela não reduz necessariamente a capacidade total de memória necessária para preservar o contexto selecionável.
Esse limite fica mais claro abaixo do limiar de esparsidade. A DSA usa uma configuração top-k de 2.048 posições na configuração discutida pela SemiAnalysis. Uma sequência com menos posições não possui um conjunto maior a ser podado, portanto a atenção permanece densa.
Os mecanismos de serving também escolhem diferentes modos de execução conforme o comprimento da sequência e a topologia de implantação. Uma implementação pode privilegiar um modo de menor computação para contextos mais curtos e, depois, migrar para um modo de menor uso de memória à medida que o tráfego de memória se torna dominante. Portanto, a atenção esparsa não representa um único ganho fixo de velocidade em todas as solicitações.
A mudança significativa é mais específica e mais útil. A atenção esparsa do GLM-5.3 reduz o custo recorrente de consultar um histórico longo. Ela não faz esse histórico deixar de existir.
Por Que Menor Tráfego de Atenção Não Equivale a Menor Capacidade de HBM
A pressão sobre a HBM vem do contexto retido, enquanto a atenção esparsa altera principalmente quais entradas retidas a GPU lê durante cada operação.
A memória de alta largura de banda, ou HBM, é a memória rápida conectada diretamente a um acelerador. Sua largura de banda ajuda as GPUs a alimentar grandes operações matriciais, enquanto sua capacidade limitada restringe quantos modelos e solicitações ativas cabem em cada dispositivo.
Durante a geração autorregressiva, um modelo produz um token após o outro. Ele reutiliza as chaves e os valores calculados para tokens anteriores por meio do cache KV. Sem esse cache, o servidor recalcularia repetidamente toda a sequência precedente.
Cada solicitação ativa, portanto, reserva memória para seu contexto. Uma longa sessão de programação pode incluir arquivos de repositório, saída de comandos, tentativas de patches, logs de testes e raciocínios anteriores. Um agente pode produzir muito mais tokens do que uma interação comum de perguntas e respostas.
A atenção esparsa altera o padrão de leitura. Em vez de carregar todas as posições históricas para a operação principal de atenção, o modelo carrega o conjunto top-k selecionado. Isso pode reduzir o consumo de largura de banda de memória e a computação realizada após a seleção.
A capacidade segue uma regra diferente. Se qualquer posição anterior continuar elegível para seleção, sua representação deve permanecer acessível em algum lugar. Um design convencional de serving mantém todo o histórico de KV na HBM, mesmo quando o kernel principal de atenção lê apenas um pequeno subconjunto.
O sistema resultante pode ficar limitado por capacidade antes de ficar limitado por computação. Cada solicitação pode realizar menos trabalho de atenção, mas ainda ocupar memória proporcional ao comprimento de seu contexto. Aumentar a concorrência então coloca mais históricos completos no mesmo dispositivo.
Isso explica por que a atenção esparsa não se traduz diretamente em uma redução equivalente na demanda por HBM. O sistema economiza tráfego ativo sem necessariamente reduzir o estado residente. A visão lógica do modelo sobre seu histórico permanece completa, mesmo quando cada etapa de atenção é seletiva.
A diferença se assemelha a um grande arquivo com um sistema rápido de recuperação. Uma recuperação mais rápida reduz quantos documentos alguém lê para cada pergunta. Ela não reduz o arquivo, a menos que documentos antigos sejam movidos para outro lugar ou desapareçam.
A compressão do cache KV do GLM-5.3 continua importante. Representações menores por token permitem que mais contexto caiba em um determinado orçamento de memória. Elas também reduzem os bytes transferidos quando entradas selecionadas entram em uma operação de atenção.
No entanto, o estado comprimido continua se acumulando com o comprimento da sequência. Uma curva linear de memória menor ainda é uma curva linear de memória. Contextos longos e muitas solicitações simultâneas podem, eventualmente, consumir a capacidade economizada.
A concorrência expõe rapidamente essa compensação. A SemiAnalysis relatou resultados em que aumentar as solicitações simultâneas de oito para dezesseis reduziu a reutilização de tokens de prompt a partir da memória da GPU. A participação de reutilização na GPU caiu de 90,3% para 54,8%.
A reutilização da memória do host subiu de 6,0% para 40,3% na mesma comparação. A taxa combinada de acertos de cache permaneceu acima de 95% em todos os níveis de concorrência relatados. Esses resultados mostram que a capacidade útil de cache pode se estender além do acelerador.
Eles não significam que a memória do host iguale a latência da HBM. Mover dados pela conexão CPU-GPU cria um custo de I/O, e falhas de cache podem interromper um caminho de decodificação que, de outra forma, seria eficiente. O sistema de serving precisa prever, buscar e desalojar dados sem deixar que as transferências dominem o tempo de geração.
A implicação para o mercado de memória também é mais sutil do que uma simples queda na demanda. A atenção esparsa pode reduzir o tráfego de HBM por etapa de atenção. Ao mesmo tempo, uma inferência de contexto longo mais barata pode incentivar sessões mais longas e maior concorrência de solicitações.
Esse efeito rebote importa para o planejamento de infraestrutura. Quando cada solicitação se torna menos dispendiosa de processar, os operadores frequentemente admitem mais trabalho simultâneo. A largura de banda de memória economizada pode se tornar capacidade adicional em vez de hardware ocioso.
A demanda por HBM pode, portanto, persistir mesmo à medida que a atenção se torna mais seletiva. A demanda por DRAM do host também pode aumentar porque históricos completos são movidos para uma camada de memória maior e mais lenta. Em escalas ainda maiores, os sistemas de armazenamento podem absorver prefixos reutilizáveis ou dados de cache inativos.
A questão prática já não é se a atenção esparsa economiza memória em abstrato. É qual camada de memória mantém cada parte do cache KV do GLM-5.3 e com que frequência o mecanismo de serving a move.
HiSparse Move o Histórico Completo para Fora da GPU
O HiSparse converte as leituras seletivas da atenção esparsa em economias reais de capacidade de HBM ao separar a disponibilidade lógica do cache da residência física na GPU.
A equipe do SGLang projetou o HiSparse como um cache KV hierárquico para serving com atenção esparsa. Ele mantém um pequeno conjunto de trabalho na GPU enquanto armazena o histórico completo de KV em memória do host fixada. A memória fixada é memória de CPU preparada para transferências previsíveis a um acelerador.
Nesse design, entradas antigas de cache permanecem logicamente disponíveis para o GLM-5.3. Elas não permanecem todas fisicamente residentes na HBM. O indexador pode selecionar uma posição, e o sistema de serving pode recuperar essa posição quando a GPU não a tiver.
O HiSparse usa uma política least-recently-used para seu cache de dispositivo. Quando tokens selecionados estão ausentes da HBM, o sistema os carrega da memória do host. Ele remove entradas menos usadas recentemente para manter limitado o conjunto de trabalho da GPU.
Essa arquitetura transforma uma propriedade do modelo em uma economia no nível do sistema. A atenção esparsa identifica o pequeno conjunto exigido pela operação atual. O HiSparse garante que apenas uma seleção limitada e um buffer de trabalho precisem ocupar a HBM durante a decodificação.
O artigo do HiSparse descreve o sistema como exato e independente de indexador. Exato significa que a colocação do cache muda sem aproximar intencionalmente a saída de atenção selecionada pelo modelo. Independente de indexador significa que o gerenciador de memória não depende de um único algoritmo de seleção.
Suas avaliações abrangem DSA, Native Sparse Attention e Quest em plataformas H200, B200 e GH200. Os autores relatam até 4,7 vezes mais throughput máximo de geração em cargas de trabalho de contexto longo.
Esse é um resultado de sistema sob configurações testadas, não um multiplicador de velocidade garantido para o GLM-5.3. Comprimento da carga de trabalho, concorrência de solicitações, largura de banda de interconexão, localidade de seleção e taxas de falha de cache afetam o resultado.
HiSparse também sobrepõe transferências à computação útil. Enquanto uma camada é executada, o sistema pode preparar entradas de cache selecionadas para uma camada posterior. Essa sobreposição por camada oculta parte da latência criada pela movimentação do host para o dispositivo.
A reutilização entre camadas facilita esse agendamento. Se camadas adjacentes selecionam muitas das mesmas posições, o sistema tem conhecimento antecipado da provável demanda de cache. Entradas buscadas para uma camada podem continuar úteis nas camadas seguintes.
O custo restante é a E/S. Uma falha de seleção exige que os dados viagem da memória da CPU para a HBM. Falhas frequentes, seleções dispersas ou largura de banda limitada entre host e dispositivo podem eliminar parte do ganho de throughput.
Esse risco separa a esparsidade teórica da eficiência em produção. Um kernel esparso pode ler menos entradas depois que elas chegam. O sistema completo ainda precisa localizar essas entradas, transferi-las, mapeá-las em páginas utilizáveis e coordenar seu ciclo de vida.
O tempo até o primeiro token cria outra restrição. O prefill, que processa o prompt inicial, tem características diferentes da decodificação token por token. O HiSparse mira principalmente o lado da decodificação, em que o cache já existe e cresce à medida que a geração continua.
A implementação do SGLang combina HiSparse com a desagregação entre prefill e decodificação. Essa arquitetura atribui o processamento de prompts e a geração de tokens a trabalhadores diferentes. Cada fase pode então usar um layout de memória e uma alocação de hardware adequados à sua carga de trabalho.
O design também altera a demanda de infraestrutura. A HBM se torna um cache ativo, em vez de ser o único armazenamento da conversa ativa. A DRAM do host mantém o histórico maior, enquanto a interconexão passa a integrar o caminho crítico.
Isso pode reduzir a capacidade de HBM necessária para cada solicitação de decodificação. Não elimina os bytes que representam a conversa. Reposiciona muitos deles e adiciona software responsável por manter o subconjunto certo próximo à GPU.
Para operadores, portanto, a métrica relevante não é apenas o tamanho do modelo ou o comprimento máximo de contexto. Eles precisam avaliar a ocupação de HBM por solicitação, a alocação de memória do host, a taxa de falhas, o volume de transferência e a latência de tokens de saída em concorrência realista.
A atenção esparsa viabiliza esse design em camadas. O HiSparse o torna operacional. Nenhum dos dois torna o gerenciamento de memória gratuito.
IndexShare Reduz o Custo de Encontrar Tokens Relevantes
Quando a atenção completa se torna esparsa, o próprio indexador se torna um gargalo visível; por isso, a próxima otimização do GLM reutiliza decisões de seleção entre camadas.
Uma camada DSA padrão possui seu próprio indexador lightning. Esse componente pontua tokens históricos antes que o cálculo principal de atenção selecione seu conjunto top-k. O indexador é mais leve que a atenção completa, mas ainda examina o contexto.
À medida que o contexto cresce, pontuar repetidamente cada posição histórica em todas as camadas se torna caro. O caminho principal de atenção foi reduzido, então um trabalho antes considerado secundário passa a representar uma parcela maior da latência total.
A Z.ai aborda esse problema com o IndexShare, também descrito publicamente como IndexCache. Em vez de executar um indexador independente em cada camada de atenção esparsa, grupos de camadas reutilizam uma seleção compartilhada.
A abordagem se baseia em um padrão observado: camadas vizinhas frequentemente escolhem muitos dos mesmos tokens históricos. O estudo IndexCache relata sobreposição de 70 a 100 por cento entre seleções top-k de camadas adjacentes em sua análise.
Essa sobreposição cria redundância. Uma camada completa designada pode calcular um índice, enquanto as camadas compartilhadas seguintes reutilizam as posições selecionadas. O padrão de produção discutido para o GLM atribui um indexador a grupos de quatro camadas DSA.
Em um modelo DSA de 30 bilhões de parâmetros, os pesquisadores eliminaram até 75 por cento dos cálculos do indexador, com degradação de qualidade relatada como negligenciável. Eles mediram prefill até 1,82 vez mais rápido e decodificação até 1,48 vez mais rápida em comparação com DSA padrão.
O artigo também relata resultados preliminares em escala de produção para o GLM-5. Esses achados sustentam o mecanismo, mas não substituem testes independentes amplos em cargas de trabalho e pilhas de serving do GLM-5.3.
A reutilização de seleção introduz sua própria exigência de treinamento. Um indexador compartilhado precisa identificar tokens que atendam a várias camadas, e não apenas corresponder à distribuição de atenção de uma camada. O IndexCache treina indexadores retidos em relação a uma média das distribuições de atenção que eles atendem.
Esse ajuste importa porque camadas consecutivas são relacionadas, mas não idênticas. Uma camada inicial pode priorizar detalhes lexicais, enquanto uma camada posterior pode favorecer uma dependência formada durante o processamento intermediário. A reutilização se torna prejudicial se eliminar um token necessário apenas para um membro do grupo.
Assim, o método expõe uma segunda troca. Mais compartilhamento elimina trabalho adicional do indexador. Menos compartilhamento preserva mais comportamento de seleção específico de cada camada.
O IndexShare também interage com o HiSparse. Quando as camadas compartilham um índice, o mecanismo de serving pode reutilizar entradas de cache recuperadas entre elas. Seleções compartilhadas reduzem o cálculo top-k repetido e podem tornar a busca do host para o dispositivo mais previsível.
Essa combinação ataca três custos diferentes:
MLA comprime a representação armazenada para cada token.
DSA restringe a atenção completa a posições históricas selecionadas.
IndexShare evita recalcular seleções semelhantes em todas as camadas.
HiSparse move entradas KV inativas da HBM para a memória do host.
Esses componentes não devem ser condensados em uma única alegação sobre memória. A compressão afeta bytes por token. A atenção esparsa afeta leituras ativas. O compartilhamento de índices afeta a sobrecarga de seleção. O offloading afeta o posicionamento físico.
Cada camada de otimização pode deslocar o gargalo para outro lugar. Caches menores podem expor a sobrecarga de computação. Uma atenção principal mais barata pode expor a latência do indexador. O offloading pode expor a largura de banda de transferência. Maior concorrência pode expor a capacidade de memória do host.
As características do hardware determinam qual gargalo aparece primeiro. A SemiAnalysis estimou um perfil de intensidade aritmética que sugere que a configuração de atenção do GLM difere do equilíbrio orientado ao H800 da DeepSeek. A análise também conectou o design do GLM ao suporte da fornecedora chinesa de aceleradores Moore Threads.
Essa interpretação de hardware continua sendo uma inferência, e não um objetivo de design divulgado pela Z.ai. O GLM-5.3 oferece suporte a vários frameworks de serving e plataformas de aceleradores, portanto operadores devem medir o modelo em seu próprio caminho de implantação.
A lição mais ampla é que a atenção esparsa do GLM-5.3 não pode ser avaliada por meio de uma única contagem de FLOPs. O desempenho de serving decorre do comportamento conjunto de seu indexador, cache comprimido, hierarquia de memória, kernels e carga de trabalho.
O Teste Real É a Eficiência de Memória em Produção
O GLM-5.3 só validará seu design de memória se os operadores conseguirem sustentar longas sessões de agentes sem transferir custos inaceitáveis para a latência, a DRAM ou a complexidade operacional.
O primeiro sinal a observar são benchmarks independentes do GLM-5.3 em contextos longos e alta concorrência. A velocidade máxima de uma única solicitação revela pouco sobre um serviço que lida com muitos agentes persistentes. Os testes devem relatar conjuntamente o uso de HBM, o uso de DRAM do host, falhas de cache e distribuições de latência.
Um resultado convincente mostraria que o offloading de cache KV do GLM-5.3 admite mais solicitações simultâneas enquanto mantém estável a latência por token. Se o throughput aumentar apenas após aceitar grandes picos de latência, a economia de memória terá valor limitado para agentes interativos de programação.
O segundo sinal é um suporte de implantação mais amplo para HiSparse e gerenciadores de memória semelhantes. O SGLang integrou o HiSparse, e o vLLM também documentou trabalho em torno da arquitetura. Um comportamento consistente entre mecanismos fortaleceria o argumento de que modelos esparsos podem usar residência limitada em HBM em produção.
Suporte fragmentado a kernels enfraqueceria esse argumento. A atenção esparsa depende de seleção especializada, gerenciamento de páginas, formatos de cache e kernels de atenção. Um modelo pode ter pesos abertos e ainda ser difícil de servir com eficiência fora de uma pilha de software restrita.
O terceiro sinal é evidência sobre a qualidade de agentes em horizontes longos. A otimização de memória só importa se o modelo recuperar de forma confiável requisitos anteriores, decisões de código e resultados de ferramentas. Erros de seleção que aparecem tardiamente em uma sessão podem ser difíceis de diagnosticar.
A estratégia de pós-treinamento do GLM-5.3 torna isso especialmente relevante. A Z.ai afirma que o modelo melhorou a capacidade de programação em 50 por cento em relação ao GLM-5.2 no seu benchmark interno Z.ai Code Bench. Isso continua sendo uma comparação relatada pela empresa.
A Z.ai também relata um resultado de 84,5 por cento no CyberGym, em comparação com 77,2 por cento para o GLM-5.2. O CyberGym mede se um modelo consegue encontrar e validar vulnerabilidades de software a partir do código-fonte. O lançamento do GLM-5.3 apresenta esses ganhos como evidência de capacidades mais fortes em agentes e cibersegurança.
Essas capacidades ampliam tanto a utilidade quanto o risco. Sessões mais longas e orientadas por ferramentas podem apoiar análise de repositórios, testes e pesquisa de vulnerabilidades. A mesma persistência pode ajudar a automatizar etapas de exploração ou preservar material sensível dentro de um cache de serving.
Consequentemente, o posicionamento da memória tem uma dimensão de segurança. DRAM do host, caches de prefixos compartilhados e camadas de cache distribuídas ampliam os locais onde o estado da conversa pode residir. Operadores precisam de isolamento, remoção, controle de acesso e observabilidade em todas as camadas.
O trabalho de Single-Rollout Asynchronous Optimization do modelo pertence a esse contexto, embora não reduza diretamente a memória de inferência. O SAO treina com um rollout por prompt e usa um modelo de valor separado para estimar retornos em nível de token.
O artigo sobre SAO afirma que o método aborda instabilidade e efeitos off-policy no treinamento assíncrono de agentes. Ele foi implantado no pipeline de treinamento de agentes do GLM-5.2 e informa a linhagem de pós-treinamento por trás do GLM-5.3.
O SAO pode melhorar a eficiência do treinamento para trajetórias longas e irregulares de agentes. Também traz sobrecarga adicional de treinamento porque o modelo de valor é executado junto ao modelo de política. Esse é outro exemplo de redução de um gargalo ao aceitar custos em outro ponto.
Para equipes empresariais, a tarefa imediata é uma avaliação disciplinada. Acompanhe o prompt completo, o contexto selecionado, o posicionamento do cache, o comportamento de falhas, a latência de saída e o sucesso da tarefa sob a mesma carga de trabalho. Números agregados de tokens por segundo escondem informação demais.
As equipes também precisam de registros duráveis de configurações de modelos e experimentos de serving. Uma base de conhecimento pesquisável pode conectar resultados de benchmark a versões de kernel, configurações de cache e incidentes de implantação.
A atenção esparsa do GLM-5.3 altera a economia de leitura de contextos longos. Ela não elimina a necessidade de preservá-los. A arquitetura reduz o tráfego de atenção ativa, enquanto o IndexShare reduz a sobrecarga de seleção e o HiSparse limita a residência na GPU.
A pergunta para a próxima onda de benchmarks é concreta: o GLM-5.3 consegue transformar essas economias em concorrência sustentada sem deslocar o gargalo para transferências do host ou qualidade de recuperação? Observe a ocupação medida de HBM, a latência de falhas de cache e a precisão em agentes de longa duração. Juntos, esses sinais mostrarão se a atenção esparsa oferece um sistema de serving melhor, em vez de apenas um kernel melhor isoladamente.
