L’attenzione sparsa di GLM-5.3 riduce il calcolo, ma la domanda di HBM persiste

L’attenzione sparsa di GLM-5.3 riduce la quantità di contesto letta da ciascuna operazione di attenzione, ma non elimina automaticamente il problema della capacità HBM del modello. Un’analisi del 28 settembre ha rilevato che la selezione dei token rilevanti può richiedere comunque l’accesso alla cronologia completa del contesto. Il risultato mette in discussione un’ipotesi allettante: meno token considerati dall’attenzione devono necessariamente significare una quantità proporzionalmente inferiore di memoria GPU.

Questa distinzione conta perché GLM-5.3 punta a task di coding e agent di lunga durata, nei quali il contesto si accumula tra chiamate agli strumenti, file, risultati dei test e revisioni. L’attenzione sparsa riduce il lavoro all’interno del principale calcolo di attenzione. La KV cache, che conserva rappresentazioni di chiavi e valori riutilizzabili dai token precedenti, può continuare a crescere con l’intera sequenza.

DeepSeek Sparse Attention fornisce il riferimento architetturale. Il suo indicizzatore identifica un insieme limitato di token utili prima che il modello esegua il principale calcolo di attenzione. GLM-5.3 combina questo metodo con rappresentazioni compresse della cache, riutilizzo degli indici tra i livelli e software di serving in grado di spostare le voci inattive della cache nella memoria host.

La questione centrale non è quindi soltanto attenzione sparsa contro attenzione densa. È la contrapposizione tra sparsità algoritmica e requisito fisico di mantenere disponibile una lunga conversazione. Questa dinamica determina se i risparmi di memoria si traducano in minore capacità HBM, minore domanda di banda, maggiore concorrenza o semplicemente in un diverso equilibrio tra GPU e memoria di sistema.

Cosa cambia davvero con l’attenzione sparsa di GLM-5.3

GLM-5.3 riduce la quantità di costoso lavoro di attenzione per token, ma il modello necessita comunque di un modo per localizzare le informazioni rilevanti nella propria cronologia.

GLM-5.3 appartiene alla famiglia GLM-5 di Z.ai, che utilizza un’architettura mixture-of-experts. Un modello mixture-of-experts attiva soltanto una parte del proprio insieme totale di parametri per ciascun token. Secondo il report su GLM-5, la famiglia combina questo calcolo instradato con un design di attenzione per contesti lunghi derivato dal lavoro di DeepSeek.

Z.ai afferma che GLM-5.3 utilizza lo stesso modello di base di GLM-5.2. I miglioramenti di capacità riportati derivano dal post-training, anziché da un ulteriore ciclo di pretraining del modello di base. Questa distinzione implica che l’attuale discussione sulla memoria riguarda il comportamento dell’architettura esistente sotto carichi di serving reali, non un nuovo livello di attenzione GLM-5.3 appena inventato.

Il meccanismo rilevante è DeepSeek Sparse Attention, o DSA. L’attenzione sparsa limita l’attenzione completa a un sottoinsieme selezionato di token precedenti invece di elaborare ogni token precedente allo stesso costo. DeepSeek ha introdotto questo design orientato alla produzione nella sua ricerca su V3.2.

DSA esegue prima un componente leggero chiamato lightning indexer. L’indicizzatore assegna un punteggio alle posizioni precedenti e sceglie i token top-k, ovvero l’insieme limitato ritenuto più rilevante per la query corrente. Il principale calcolo Multi-Head Latent Attention opera quindi su queste posizioni selezionate.

Multi-Head Latent Attention, o MLA, memorizza rappresentazioni latenti compresse invece di un vettore completo distinto di chiavi e valori per ogni testa di attenzione. Questa compressione riduce la cache memorizzata per token. La selezione sparsa riduce quindi la quantità di tale cache letta dall’operazione principale di attenzione.

Si tratta di due risparmi diversi. MLA interviene sulla dimensione dello stato memorizzato nella cache per ciascun token. DSA interviene sul numero di posizioni in cache consumate dal costoso calcolo di attenzione.

La combinazione modifica sostanzialmente il profilo di calcolo e banda. L’attenzione centrale può passare dall’elaborazione delle relazioni sull’intero contesto all’elaborazione di una selezione top-k fissa. A lunghe sequenze, questo limita la crescita del carico di lavoro dell’attenzione principale.

Tuttavia, il lightning indexer necessita comunque di informazioni sufficienti per valutare i candidati nell’intera cronologia conservata. Il modello non può selezionare un vecchio token se il sistema di serving ha eliminato ogni rappresentazione utilizzabile di quel token.

L’analisi di SemiAnalysis identifica questo come il limite cruciale. L’attenzione sparsa riduce il traffico di memoria durante l’operazione principale di attenzione scaled dot-product. Non riduce necessariamente la capacità totale di memoria necessaria per preservare il contesto selezionabile.

Questo limite diventa più evidente sotto la soglia di sparsità. DSA utilizza un’impostazione top-k di 2.048 posizioni nella configurazione discussa da SemiAnalysis. Una sequenza che contiene meno posizioni non ha un bacino più ampio da sfoltire, quindi l’attenzione rimane densa.

I motori di serving scelgono inoltre modalità di esecuzione differenti in base alla lunghezza della sequenza e alla topologia di deployment. Un’implementazione può privilegiare una modalità a minor calcolo per contesti più brevi, quindi passare a una modalità a minor memoria quando il traffico di memoria diventa predominante. L’attenzione sparsa non è quindi un singolo incremento di velocità fisso per ogni richiesta.

Il cambiamento significativo è più circoscritto e più utile. L’attenzione sparsa di GLM-5.3 riduce il costo ricorrente della consultazione di una lunga cronologia. Non fa cessare l’esistenza di quella cronologia.

Perché un minore traffico di attenzione non equivale a una minore capacità HBM

La pressione sull’HBM deriva dal contesto conservato, mentre l’attenzione sparsa modifica soprattutto quali voci conservate la GPU legge durante ciascuna operazione.

La memoria ad alta larghezza di banda, o HBM, è la memoria veloce collegata direttamente a un acceleratore. La sua banda aiuta le GPU ad alimentare grandi operazioni matriciali, mentre la sua capacità limitata vincola quanti modelli e richieste attive possono essere ospitati su ciascun dispositivo.

Durante la generazione autoregressiva, un modello produce un token dopo l’altro. Riutilizza le chiavi e i valori calcolati per i token precedenti tramite la KV cache. Senza quella cache, il server ricalcolerebbe ripetutamente l’intera sequenza precedente.

Ogni richiesta attiva riserva quindi memoria per il proprio contesto. Una lunga sessione di coding potrebbe includere file del repository, output dei comandi, tentativi di patch, log dei test e ragionamenti precedenti. Un agent può produrre molti più token rispetto a un normale scambio di domande e risposte.

L’attenzione sparsa modifica il modello di lettura. Invece di caricare ogni posizione storica nell’operazione principale di attenzione, il modello carica l’insieme top-k selezionato. Ciò può ridurre il consumo di banda di memoria e il calcolo eseguito dopo la selezione.

La capacità segue una regola diversa. Se una posizione precedente rimane idonea alla selezione, la sua rappresentazione deve restare accessibile da qualche parte. Un design di serving convenzionale mantiene l’intera cronologia KV in HBM, anche quando il kernel principale di attenzione legge soltanto un piccolo sottoinsieme.

Il sistema risultante può diventare vincolato dalla capacità prima di esserlo dal calcolo. Ogni richiesta può eseguire meno lavoro di attenzione, ma continuare a occupare memoria proporzionale alla lunghezza del proprio contesto. L’aumento della concorrenza colloca quindi più cronologie complete sullo stesso dispositivo.

Questo spiega perché l’attenzione sparsa non si traduce direttamente in una riduzione equivalente della domanda di HBM. Il sistema risparmia traffico attivo senza necessariamente ridurre lo stato residente. La visione logica che il modello ha della propria cronologia resta completa, anche quando ogni passaggio di attenzione è selettivo.

La differenza ricorda un grande archivio con un sistema di recupero rapido. Un recupero più veloce riduce il numero di documenti letti per ciascuna domanda. Non riduce l’archivio, a meno che i documenti più vecchi non vengano spostati altrove o eliminati.

Anche la compressione della KV cache di GLM-5.3 resta importante. Rappresentazioni più piccole per token permettono di inserire più contesto in un dato budget di memoria. Riducono inoltre i byte trasferiti quando le voci selezionate entrano in un’operazione di attenzione.

Tuttavia, lo stato compresso continua ad accumularsi con la lunghezza della sequenza. Una curva di memoria lineare più piccola resta comunque una curva di memoria lineare. Contesti lunghi e molte richieste simultanee possono alla fine consumare la capacità risparmiata.

La concorrenza rende rapidamente evidente questo compromesso. SemiAnalysis ha riportato risultati nei quali l’aumento delle richieste concorrenti da otto a sedici ha ridotto il riutilizzo dei prompt token dalla memoria GPU. La quota di riutilizzo della GPU è scesa dal 90,3% al 54,8%.

Nello stesso confronto, il riutilizzo della memoria host è salito dal 6,0% al 40,3%. Il tasso di cache hit combinato è rimasto sopra il 95% a ogni livello di concorrenza riportato. Questi risultati mostrano che la capacità utile della cache può estendersi oltre l’acceleratore.

Non significano che la memoria host equivalga alla latenza dell’HBM. Lo spostamento dei dati attraverso la connessione CPU-GPU comporta un costo di I/O e i cache miss possono interrompere un percorso di decodifica altrimenti efficiente. Il sistema di serving deve prevedere, recuperare ed espellere dati senza lasciare che i trasferimenti dominino il tempo di generazione.

Anche l’implicazione per il mercato della memoria è più sfumata di un semplice calo della domanda. L’attenzione sparsa può ridurre il traffico HBM per passaggio di attenzione. Allo stesso tempo, un’inferenza su contesti lunghi meno costosa può incoraggiare sessioni più lunghe e una maggiore concorrenza delle richieste.

Questo effetto di rimbalzo conta per la pianificazione dell’infrastruttura. Quando ogni richiesta diventa meno costosa da elaborare, gli operatori spesso ammettono più lavoro simultaneo. La banda di memoria risparmiata può trasformarsi in throughput aggiuntivo anziché in hardware inutilizzato.

La domanda di HBM può quindi persistere anche mentre l’attenzione diventa più selettiva. Anche la domanda di DRAM host può aumentare, perché le cronologie complete si spostano in un livello di memoria più ampio e più lento. Su scala ancora maggiore, i sistemi di storage possono assorbire prefissi riutilizzabili o dati inattivi della cache.

La domanda pratica non è più se l’attenzione sparsa risparmi memoria in astratto. È quale livello di memoria ospiti ciascuna parte della KV cache di GLM-5.3 e con quale frequenza il motore di serving la sposti.

HiSparse sposta la cronologia completa fuori dalla GPU

HiSparse trasforma le letture selettive dell’attenzione sparsa in effettivi risparmi di capacità HBM separando la disponibilità logica della cache dalla residenza fisica sulla GPU.

Il team di SGLang ha progettato HiSparse come una KV cache gerarchica per il serving con attenzione sparsa. Mantiene un piccolo insieme di lavoro sulla GPU, mentre memorizza l’intera cronologia KV nella memoria host pinned. La memoria pinned è memoria CPU preparata per trasferimenti prevedibili verso un acceleratore.

Con questo design, le vecchie voci della cache restano logicamente disponibili a GLM-5.3. Non rimangono tutte fisicamente residenti in HBM. L’indicizzatore può selezionare una posizione e il sistema di serving può recuperarla quando la GPU non la possiede.

HiSparse utilizza una policy least-recently-used per la cache del dispositivo. Quando i token selezionati sono assenti dall’HBM, il sistema li carica dalla memoria host. Espelle le voci usate meno di recente per mantenere delimitato l’insieme di lavoro della GPU.

Questa architettura trasforma una proprietà a livello di modello in un risparmio a livello di sistema. L’attenzione sparsa identifica il piccolo insieme necessario per l’operazione corrente. HiSparse garantisce che soltanto una selezione limitata e un buffer di lavoro debbano occupare HBM durante la decodifica.

L’articolo su HiSparse descrive il sistema come esatto e indipendente dall’indicizzatore. Esatto significa che il posizionamento della cache cambia senza approssimare intenzionalmente l’output di attenzione selezionato dal modello. Indipendente dall’indicizzatore significa che il gestore della memoria non dipende da un singolo algoritmo di selezione.

Le sue valutazioni coprono DSA, Native Sparse Attention e Quest su piattaforme H200, B200 e GH200. Gli autori riportano fino a 4,7 volte un throughput massimo di generazione superiore su carichi di lavoro a contesto lungo.

Si tratta di un risultato di sistema nelle configurazioni testate, non di un moltiplicatore di velocità garantito per GLM-5.3. La lunghezza del carico di lavoro, la concorrenza delle richieste, la banda dell’interconnessione, la località della selezione e i tassi di cache miss influenzano tutti il risultato.

HiSparse sovrappone inoltre i trasferimenti al calcolo utile. Mentre un layer viene eseguito, il sistema può preparare voci della cache selezionate per un layer successivo. Questa sovrapposizione tra layer nasconde parte della latenza generata dal trasferimento dall'host al dispositivo.

Il riuso tra layer rende questa pianificazione più semplice. Se layer adiacenti selezionano molte delle stesse posizioni, il sistema sa in anticipo quale sarà probabilmente la domanda di cache. Le voci recuperate per un layer possono restare utili per quelli successivi.

Il costo residuo è l'I/O. Un miss di selezione richiede che i dati viaggino dalla memoria della CPU all'HBM. Miss frequenti, selezioni disperse o una larghezza di banda limitata tra host e dispositivo possono annullare parte del guadagno di throughput.

Questo rischio distingue la sparsità teorica dall'efficienza in produzione. Un kernel sparse può leggere meno voci una volta che queste sono arrivate. Il sistema completo deve comunque trovare tali voci, trasferirle, mapparle in pagine utilizzabili e coordinarne il ciclo di vita.

Il tempo al primo token introduce un ulteriore vincolo. Il prefill, che elabora il prompt iniziale, ha caratteristiche diverse dalla decodifica token per token. HiSparse si rivolge principalmente alla fase di decode, in cui la cache esiste già e cresce con il proseguire della generazione.

L'implementazione di SGLang abbina HiSparse alla disaggregazione prefill-decode. Questa architettura assegna l'elaborazione del prompt e la generazione dei token a worker diversi. Ogni fase può quindi usare un layout di memoria e un'allocazione hardware adatti al proprio carico di lavoro.

Il design modifica anche la domanda infrastrutturale. L'HBM diventa una cache calda anziché l'unico archivio della conversazione attiva. La DRAM dell'host conserva la cronologia più ampia, mentre l'interconnessione entra nel percorso critico.

Ciò può ridurre la capacità HBM necessaria per ogni richiesta di decodifica. Non elimina i byte che rappresentano la conversazione. Ne ricolloca molti e aggiunge software responsabile di mantenere vicino alla GPU il sottoinsieme corretto.

Per gli operatori, la metrica rilevante non è quindi solo la dimensione del modello o la lunghezza massima del contesto. Devono misurare l'occupazione HBM per richiesta, l'allocazione della memoria host, il tasso di miss, il volume dei trasferimenti e la latenza dei token di output a livelli di concorrenza realistici.

L'attenzione sparse rende possibile questo design a livelli. HiSparse lo rende operativo. Nessuno dei due rende gratuita la gestione della memoria.

IndexShare riduce il costo di individuare i token rilevanti

Quando l'attenzione completa diventa sparse, l'indicizzatore stesso diventa un collo di bottiglia evidente; la successiva ottimizzazione di GLM riutilizza quindi le decisioni di selezione tra i layer.

Un layer DSA standard dispone di un proprio lightning indexer. Questo componente assegna un punteggio ai token storici prima che il calcolo principale dell'attenzione selezioni il relativo insieme top-k. L'indicizzatore è più leggero dell'attenzione completa, ma esamina comunque il contesto.

Con la crescita del contesto, assegnare ripetutamente un punteggio a ogni posizione storica in ciascun layer diventa costoso. Il percorso principale dell'attenzione è stato ridotto, quindi un lavoro che prima sembrava marginale rappresenta una quota maggiore della latenza totale.

Z.ai affronta questo problema con IndexShare, descritto pubblicamente anche come IndexCache. Invece di eseguire un indicizzatore indipendente in ogni layer di attenzione sparse, gruppi di layer riutilizzano una selezione condivisa.

L'approccio si basa su uno schema osservato: i layer vicini scelgono spesso molti degli stessi token storici. Lo studio su IndexCache riporta, nella propria analisi, una sovrapposizione dal 70 al 100 percento tra le selezioni top-k di layer adiacenti.

Questa sovrapposizione crea ridondanza. Un layer completo designato può calcolare un indice, mentre i layer condivisi successivi riutilizzano le posizioni selezionate. Il modello di produzione discusso per GLM assegna un indicizzatore a gruppi di quattro layer DSA.

Su un modello DSA da 30 miliardi di parametri, i ricercatori hanno eliminato fino al 75 percento dei calcoli dell'indicizzatore con un degrado della qualità riportato come trascurabile. Hanno misurato un prefill fino a 1,82 volte più veloce e una decodifica fino a 1,48 volte più veloce rispetto al DSA standard.

L'articolo riporta anche risultati preliminari su GLM-5 in scala di produzione. Questi risultati supportano il meccanismo, ma non sostituiscono test indipendenti e ampi sui carichi di lavoro e sugli stack di serving di GLM-5.3.

Il riuso della selezione introduce un proprio requisito di addestramento. Un indicizzatore condiviso deve identificare token utili a più layer, non limitarsi a corrispondere alla distribuzione dell'attenzione di un singolo layer. IndexCache addestra gli indicizzatori mantenuti rispetto a una media delle distribuzioni di attenzione che supportano.

Questo adeguamento è importante perché i layer consecutivi sono correlati ma non identici. Un layer iniziale potrebbe dare priorità ai dettagli lessicali, mentre uno successivo potrebbe preferire una dipendenza formata durante l'elaborazione intermedia. Il riuso diventa dannoso se elimina un token necessario solo a un membro del gruppo.

Il metodo espone quindi un secondo compromesso. Una maggiore condivisione elimina ulteriore lavoro dell'indicizzatore. Una minore condivisione preserva un comportamento di selezione più specifico per layer.

IndexShare interagisce anche con HiSparse. Quando i layer condividono un indice, il motore di serving può riutilizzare le voci della cache recuperate tra tali layer. Le selezioni condivise riducono il calcolo top-k ripetuto e possono rendere più prevedibile il recupero dall'host al dispositivo.

Questa combinazione agisce su quattro costi distinti:

• MLA comprime la rappresentazione memorizzata per ciascun token.

• DSA limita l'attenzione completa alle posizioni storiche selezionate.

• IndexShare evita di ricalcolare selezioni simili in ogni layer.

• HiSparse sposta le voci KV inattive dall'HBM alla memoria host.

Questi componenti non dovrebbero essere condensati in un'unica affermazione sulla memoria. La compressione influisce sui byte per token. L'attenzione sparse influisce sulle letture attive. La condivisione dell'indice influisce sull'overhead di selezione. L'offloading influisce sulla collocazione fisica.

Ogni livello di ottimizzazione può spostare il collo di bottiglia altrove. Cache più piccole possono far emergere l'overhead di calcolo. Un'attenzione principale più economica può far emergere la latenza dell'indicizzatore. L'offloading può far emergere la larghezza di banda di trasferimento. Una maggiore concorrenza può far emergere la capacità della memoria host.

Le caratteristiche hardware determinano quale collo di bottiglia compare per primo. SemiAnalysis ha stimato un profilo di intensità aritmetica che suggerisce come la configurazione dell'attenzione di GLM differisca dal bilanciamento di DeepSeek orientato a H800. Ha inoltre collegato il design di GLM al supporto del fornitore cinese di acceleratori Moore Threads.

Questa interpretazione hardware resta un'inferenza, non un obiettivo di progettazione divulgato da Z.ai. GLM-5.3 supporta più framework di serving e piattaforme di accelerazione, quindi gli operatori dovrebbero misurare il modello sul proprio percorso di deployment.

La lezione più ampia è che l'attenzione sparse di GLM-5.3 non può essere valutata tramite un singolo conteggio di FLOP. Le prestazioni di serving derivano dal comportamento congiunto dell'indicizzatore, della cache compressa, della gerarchia di memoria, dei kernel e del carico di lavoro.

Il vero test è l'efficienza della memoria in produzione

GLM-5.3 convaliderà il proprio design della memoria solo se gli operatori potranno sostenere lunghe sessioni agent senza trasferire costi inaccettabili su latenza, DRAM o complessità operativa.

Il primo segnale da osservare è il benchmarking indipendente di GLM-5.3 con contesti lunghi e alta concorrenza. La velocità di picco di una singola richiesta rivela poco su un servizio che gestisce molti agent persistenti. I test dovrebbero riportare insieme l'uso dell'HBM, l'uso della DRAM host, i miss della cache e le distribuzioni della latenza.

Un risultato convincente mostrerebbe che l'offloading della cache KV di GLM-5.3 consente più richieste simultanee mantenendo stabile la latenza per token. Se il throughput aumenta solo accettando forti picchi di latenza, il risparmio di memoria ha un valore limitato per gli agent di coding interattivi.

Il secondo segnale è un supporto di deployment più ampio per HiSparse e gestori di memoria simili. SGLang ha integrato HiSparse e anche vLLM ha documentato lavori relativi all'architettura. Un comportamento coerente tra i motori rafforzerebbe l'ipotesi che i modelli sparse possano usare una permanenza HBM limitata in produzione.

Un supporto frammentato dei kernel indebolirebbe questa ipotesi. L'attenzione sparse dipende da selezione specializzata, gestione delle pagine, formati di cache e kernel di attenzione. Un modello può avere pesi aperti pur restando difficile da servire in modo efficiente al di fuori di uno stack software ristretto.

Il terzo segnale è l'evidenza sulla qualità degli agent nel lungo periodo. L'ottimizzazione della memoria conta solo se il modello recupera in modo affidabile requisiti precedenti, decisioni sul codice e risultati degli strumenti. Gli errori di selezione che emergono tardi in una sessione possono essere difficili da diagnosticare.

La strategia di post-addestramento di GLM-5.3 rende questo aspetto particolarmente rilevante. Z.ai afferma che il modello ha migliorato del 50 percento le capacità di coding rispetto a GLM-5.2 sul proprio benchmark interno Z.ai Code Bench. Resta un confronto riportato dall'azienda.

Z.ai riporta inoltre un risultato dell'84,5 percento su CyberGym, contro il 77,2 percento di GLM-5.2. CyberGym misura se un modello riesce a individuare e convalidare vulnerabilità software a partire dal codice sorgente. Il rilascio di GLM-5.3 presenta questi miglioramenti come prova di capacità agentiche e di cybersecurity più solide.

Queste capacità aumentano sia l'utilità sia il rischio. Sessioni più lunghe, guidate dagli strumenti, possono supportare l'analisi di repository, i test e la ricerca sulle vulnerabilità. La stessa persistenza può contribuire ad automatizzare fasi di sfruttamento o a conservare materiale sensibile all'interno di una cache di serving.

La collocazione della memoria presenta di conseguenza una dimensione di sicurezza. La DRAM host, le cache di prefissi condivise e i layer di cache distribuiti ampliano le posizioni in cui può risiedere lo stato della conversazione. Gli operatori necessitano di isolamento, eliminazione, controllo degli accessi e osservabilità su ogni livello.

Il lavoro del modello sulla Single-Rollout Asynchronous Optimization appartiene a questo contesto, sebbene non riduca direttamente la memoria di inferenza. SAO si addestra su un rollout per prompt e usa un modello di valore separato per stimare i ritorni a livello di token.

L'articolo su SAO afferma che il metodo affronta l'instabilità e gli effetti off-policy nell'addestramento asincrono degli agent. È stato impiegato nella pipeline di addestramento agentico di GLM-5.2 e informa la linea di post-addestramento alla base di GLM-5.3.

SAO può migliorare l'efficienza dell'addestramento per traiettorie agent lunghe e irregolari. Comporta inoltre un overhead aggiuntivo in addestramento, poiché il modello di valore viene eseguito insieme al modello di policy. È un altro esempio di riduzione di un collo di bottiglia accettando un costo altrove.

Per i team aziendali, il compito immediato è una valutazione rigorosa. Monitorate il prompt completo, il contesto selezionato, la collocazione della cache, il comportamento dei miss, la latenza di output e il successo delle attività con lo stesso carico di lavoro. I numeri aggregati di token al secondo nascondono troppo.

I team hanno inoltre bisogno di registri durevoli delle configurazioni dei modelli e degli esperimenti di serving. Una base di conoscenza ricercabile può collegare i risultati dei benchmark alle versioni dei kernel, alle impostazioni della cache e agli incidenti di deployment.

L'attenzione sparse di GLM-5.3 modifica l'economia della lettura di contesti lunghi. Non annulla il requisito di conservarli. L'architettura riduce il traffico di attenzione attiva, mentre IndexShare riduce l'overhead di selezione e HiSparse limita la permanenza sulla GPU.

La domanda per la prossima ondata di benchmark è concreta: GLM-5.3 può trasformare questi risparmi in concorrenza sostenuta senza spostare il collo di bottiglia nei trasferimenti host o nella qualità del recupero? Osservate l'occupazione HBM misurata, la latenza dei miss della cache e l'accuratezza degli agent di lunga durata. Insieme, questi segnali mostreranno se l'attenzione sparse offre un sistema di serving migliore anziché un kernel migliore considerato isolatamente.