Le GPU più veloci non possono da sole superare i colli di bottiglia dell'infrastruttura AI
La Newsroom di SK hynix ha pubblicato il 31 agosto 2026 una critica diretta al pensiero incentrato sulle GPU: gli acceleratori più veloci continuano ad attendere quando i dati arrivano troppo lentamente. La sua argomentazione sposta l'attenzione dalle specifiche di picco dei chip all'infrastruttura che circonda ogni processore.
L'analisi dell'infrastruttura afferma che l'AI in produzione dipende dal coordinamento tra calcolo, memoria, networking, storage, alimentazione e raffreddamento. Una debolezza in qualsiasi livello può impedire a costosi acceleratori di offrire le prestazioni dichiarate.
Questa posizione mette la corsa agli acceleratori di fronte a una realtà meno visibile. NVIDIA, AMD, Google, operatori cloud, fornitori di memoria e costruttori di data center devono ottimizzare interi sistemi, non componenti isolati. Acquistare la GPU più veloce disponibile non garantisce il job di addestramento o il servizio AI più rapido.
La newsroom di hynix sposta l'attenzione dai chip al flusso dei dati
L'affermazione centrale è semplice: un acceleratore non può calcolare con dati che non ha ancora ricevuto.
L'articolo di SK hynix è la seconda puntata di una serie in quattro parti sui cambiamenti nei data center per l'AI. Segue una panoramica delle trasformazioni infrastrutturali e precede articoli su alimentazione, raffreddamento e progettazione dei sistemi futuri.
Questa puntata si chiede se una GPU più veloce produca automaticamente operazioni AI più rapide. SK hynix risponde con un no qualificato. Il calcolo rimane essenziale, ma la distribuzione dei dati determina quanta potenza di calcolo si traduca in prestazioni utilizzabili.
Una GPU è un processore parallelo capace di eseguire molte operazioni matematiche contemporaneamente. Gli acceleratori AI includono GPU, unità di elaborazione neurale e unità di elaborazione tensoriale progettate per i calcoli di machine learning.
Questi processori dipendono da una catena di sistemi di supporto. I parametri del modello devono passare dalla memoria alle unità di calcolo. I dati di addestramento devono arrivare dallo storage. I risultati devono attraversare le interconnessioni quando un carico di lavoro si estende su più processori.
L'acceleratore può rimanere inattivo quando una qualsiasi parte di quella catena rallenta. Questo tempo inattivo conta perché gli operatori pagano capacità installata, alimentazione, raffreddamento, networking e spazio fisico anche quando l'utilizzo diminuisce.
SK hynix sostiene la propria tesi con un paper del 2024 di ricercatori associati a UC Berkeley, ICSI e Lawrence Berkeley National Laboratory. Lo studio sul memory wall ha esaminato l'evoluzione del calcolo dei server e del movimento dei dati nell'arco di due decenni.
Secondo il paper, i FLOPS di picco dei server sono aumentati di circa tre volte ogni due anni. La larghezza di banda DRAM è aumentata di circa 1,6 volte, mentre la larghezza di banda delle interconnessioni è aumentata di circa 1,4 volte nello stesso intervallo.
I FLOPS misurano il numero teorico di operazioni in virgola mobile che un sistema può eseguire ogni secondo. La larghezza di banda misura la quantità di dati che può transitare attraverso la memoria o una connessione in un dato periodo.
I diversi tassi di crescita creano il memory wall. La capacità di calcolo aumenta più rapidamente dei percorsi che la alimentano, quindi un numero crescente di carichi di lavoro viene limitato dal movimento dei dati anziché dall'aritmetica.
Questo non significa che ogni carico di lavoro AI affronti lo stesso collo di bottiglia. Architettura del modello, dimensione del batch, precisione numerica, efficienza software e scala di deployment modificano tutti l'equilibrio.
Tuttavia, il divario di lungo periodo spiega perché processori più veloci da soli producono miglioramenti disomogenei. Un carico di lavoro già vincolato dalla memoria o dal networking non può sfruttare pienamente ulteriore potenza di calcolo senza cambiamenti altrove.
La newsroom di hynix sta quindi formulando più di un'osservazione tecnica. Sostiene che l'unità della competizione si sia ampliata dal semiconduttore all'intero sistema operativo che lo circonda.
Gli acquirenti di infrastrutture AI affrontano ora un problema di equilibrio
La pressione ricade su chiunque acquisti acceleratori senza misurare i carichi di lavoro e i sistemi che dovranno alimentarli.
Gli acquirenti aziendali spesso iniziano la pianificazione dell'infrastruttura con un numero di GPU. È un dato facile da confrontare, ma non descrive la capacità di memoria, l'efficienza della comunicazione, il throughput dello storage o la latenza del servizio.
L'addestramento illustra chiaramente il problema. I modelli di grandi dimensioni distribuiscono il lavoro su molti acceleratori perché un singolo dispositivo non può contenere ogni parametro, attivazione e stato dell'ottimizzatore.
Questi acceleratori scambiano ripetutamente informazioni. Se la rete si congestiona, i processori attendono la sincronizzazione. Aggiungere più GPU può quindi aumentare l'overhead di coordinamento senza produrre guadagni di addestramento proporzionali.
L'inferenza crea un modello diverso. Un servizio in produzione deve caricare i pesi del modello, elaborare il contesto dell'utente, recuperare informazioni di supporto e restituire risposte entro un obiettivo di latenza prevedibile.
Prompt più lunghi aumentano inoltre la pressione sulla cache chiave-valore, una struttura di memoria che conserva dati di attenzione intermedi per le richieste in corso. Se questa cache supera la memoria ad alta larghezza di banda disponibile, il sistema deve spostare i dati attraverso livelli più lenti.
I servizi con retrieval-augmented aggiungono un ulteriore percorso. Cercano documenti, immagini, log, cronologie o record di database prima che un modello generi una risposta. Storage o recupero lenti possono dominare il tempo di risposta.
Il collo di bottiglia può quindi trovarsi lontano dall'acceleratore. Un'applicazione può sembrare limitata dalla GPU mentre in realtà attende un database, una connessione di rete, un array di storage o una coda di richieste pianificata male.
Il lavoro infrastrutturale di Meta mostra cosa comporta l'ottimizzazione a livello di sistema. La sua descrizione di grandi cluster di addestramento comprende 24.576 GPU H100 in ciascuno di due design di cluster.
Meta non ha presentato queste GPU come autosufficienti. Le ha abbinate a fabric di rete specializzati, storage distribuito ottimizzato per flash, modifiche al checkpointing, lavoro di scheduling e miglioramenti software.
Il checkpointing salva lo stato di addestramento di un modello affinché il lavoro possa riprendere dopo un'interruzione. Su larga scala, la scrittura di questi stati può generare improvvisi picchi di traffico di storage e rete.
Meta ha riferito che l'ottimizzazione dell'intero sistema ha riportato le prestazioni dei grandi cluster verso un intervallo ideale superiore al 90 percento. Questa cifra è la misurazione di Meta nel proprio ambiente, non un benchmark universale di utilizzo.
L'esempio dimostra comunque la sfida degli acquisti. Le prestazioni dell'infrastruttura emergono dal lavoro congiunto di collocazione dei carichi di lavoro, software, storage, topologia, gestione dei guasti e hardware.
I provider cloud affrontano una pressione simile perché i clienti valutano sempre più spesso l'output anziché i chip installati. Misure utili includono token al secondo, latenza di risposta, tempo di completamento dell'addestramento, disponibilità e prestazioni per watt.
Una GPU più veloce aiuta solo quando il resto del sistema preserva questi guadagni. Altrimenti, i clienti ricevono una costosa lezione sulla differenza tra specifiche di picco e servizio effettivamente erogato.
Questo problema di equilibrio riguarda anche gli sviluppatori. Le scelte di progettazione del modello influenzano la pressione sulla memoria, la frequenza delle comunicazioni, la dimensione della cache, la domanda di storage e il numero di processori necessari per ogni richiesta.
Gli sviluppatori non possono risolvere da soli i vincoli della struttura fisica. Tuttavia, il profiling di un carico di lavoro reale può rivelare se il prossimo investimento debba riguardare calcolo, capacità di memoria, larghezza di banda di rete, storage o ottimizzazione software.
Le GPU più veloci incontrano il muro della memoria e delle interconnessioni
La competizione principale non è più tra una GPU e un'altra; è tra il calcolo di picco e la capacità del sistema di mantenere quel calcolo occupato.
La memoria ad alta larghezza di banda, o HBM, si trova vicino a un acceleratore e sposta dati molto più rapidamente della memoria server convenzionale. La sua larghezza di banda e capacità determinano ora quali modelli possono essere ospitati e quanto velocemente vengono eseguiti.
La capacità HBM determina quanta parte di un modello e dei suoi dati di lavoro possa restare vicino al processore. La larghezza di banda determina quanto rapidamente l'acceleratore possa leggere tali informazioni durante il calcolo.
Un acceleratore con maggiore capacità aritmetica può comunque offrire prestazioni inferiori quando la larghezza di banda della memoria non cresce insieme a essa. Le unità di calcolo aggiuntive trascorrono più tempo in attesa anziché completare operazioni utili.
La stessa relazione appare tra i processori. L'addestramento distribuito richiede frequenti operazioni collettive, che combinano o ridistribuiscono dati tra molti dispositivi.
Un'operazione collettiva può essere veloce solo quanto la rete partecipante e il suo percorso più lento. Latenza, congestione, topologia e componenti guasti possono tutti ridurre il throughput effettivo.
L'approccio di Google offre un esempio indipendente dello stesso principio. Il suo co-design TPU considera un pod di acceleratori come un unico supercomputer interconnesso.
Google afferma che il suo TPU Ironwood include 192 GiB di HBM per chip e una larghezza di banda HBM di picco pari a 7,4 terabyte al secondo. Il sistema utilizza un'interconnessione personalizzata per lo scambio diretto di dati tra chip.
Le specifiche sono dichiarazioni dell'azienda legate all'architettura di Google. Non devono essere considerate confronti neutrali con ogni sistema GPU o carico di lavoro.
La direzione progettuale conta più dei numeri in evidenza. Google sta aumentando insieme calcolo, memoria e comunicazione perché ogni livello vincola gli altri.
AMD segue un percorso comparabile. Il suo hardware MI350 combina le prestazioni dell'acceleratore con fino a 288 GB di HBM3E e fino a 8 TB/s di larghezza di banda teorica di picco.
Una piattaforma MI350 con otto acceleratori raggiunge 2,3 TB di capacità HBM3E totale e 64 TB/s di larghezza di banda di memoria teorica aggregata. AMD collega inoltre i dispositivi tramite la propria architettura Infinity Fabric.
Anche in questo caso si tratta di specifiche del fornitore, non della prova delle prestazioni applicative. Maturità del software, modelli di comunicazione, formati numerici e ottimizzazione del carico di lavoro influenzano i risultati effettivi.
Ciò che conta è che i fornitori concorrenti di acceleratori ora promuovono capacità di memoria e interconnessione accanto al calcolo. Sarebbe inutile se la sola velocità di calcolo grezza determinasse le prestazioni dell'AI.
Il meccanismo si estende oltre l'addestramento dei modelli. I sistemi di inferenza devono leggere i pesi, mantenere i dati della cache, raggruppare le richieste e distribuire il lavoro tra i processori.
Un server di inferenza mal bilanciato può mostrare un basso utilizzo dell'acceleratore durante una domanda elevata. Le richieste potrebbero essere in coda altrove mentre la GPU attende memoria, comunicazione o pre-elaborazione.
Il collo di bottiglia della memoria GPU diventa più visibile man mano che i modelli gestiscono contesti più lunghi e input multimodali. Testo, audio, immagini e video creano flussi di dati più grandi e meno prevedibili.
Le applicazioni basate su agenti aggiungono chiamate ripetute al modello, output degli strumenti, risultati di ricerca e cronologie di contesto in crescita. Il loro carico di lavoro non è un singolo calcolo pulito, ma una sequenza di operazioni dipendenti.
Per questo la newsroom di hynix presenta il flusso dei dati come la prossima questione infrastrutturale. Un'aritmetica più veloce rimane preziosa, ma il percorso in entrata e in uscita dal processore decide quanto di quel valore sopravviva.
Storage, alimentazione e raffreddamento possono annullare i guadagni di calcolo
Anche un server bilanciato non può offrire prestazioni AI stabili quando il suo storage o la struttura fisica rimangono indietro.
Lo storage entra nel percorso critico sia durante l'addestramento sia durante l'inferenza. I sistemi di addestramento leggono continuamente i dataset e scrivono periodicamente checkpoint, log e risultati di valutazione.
Un checkpoint può essere estremamente prezioso dopo un guasto hardware o software. Impedisce a un team di addestramento di riavviare dall'inizio un'esecuzione costosa.
Tuttavia, il traffico dei checkpoint può interrompere il lavoro produttivo quando lo storage non riesce ad assorbirlo rapidamente. Il cluster può fermarsi mentre i processori attendono il completamento della scrittura dei dati di stato.
I modelli multimodali aumentano ulteriormente la pressione perché immagini, audio e video consumano più spazio di archiviazione e banda rispetto al semplice testo. La preparazione dei dati può diventare un carico di lavoro significativo prima ancora che inizi l’addestramento.
I servizi di inferenza recuperano inoltre i pesi dei modelli durante l’avvio e gli eventi di scalabilità. Una nuova replica non può gestire traffico finché i file necessari non arrivano e l’inizializzazione non è completata.
I sistemi di retrieval possono accedere a indici vettoriali, documenti, cronologie degli utenti e database applicativi a ogni richiesta. La latenza dello storage diventa quindi parte del tempo di risposta percepito dall’utente.
La stessa guida alla progettazione di fabbriche di NVIDIA rafforza questa visione sistemica. Richiede capacità di accelerazione, reti ad alta velocità, storage scalabile, alimentazione e raffreddamento.
La guida descrive fabric a bassa latenza per operazioni distribuite e storage parallelo per dataset, checkpoint, embedding e modelli. Raccomanda inoltre storage a livelli per esigenze prestazionali differenti.
Queste indicazioni provengono dal principale fornitore di GPU, rendendo l’inversione particolarmente evidente. Persino NVIDIA presenta il deployment dell’AI come un problema di infrastruttura integrata, anziché come un acquisto basato esclusivamente sui processori.
L’alimentazione impone un limite più rigido al sistema. Un data center non può installare né utilizzare acceleratori aggiuntivi quando la capacità della rete elettrica, la distribuzione dell’elettricità o i sistemi di backup non sono in grado di supportarli.
Il raffreddamento determina se l’hardware ad alta densità possa mantenere le prestazioni in sicurezza. Il calore che non può essere rimosso può costringere le apparecchiature a ridurre la velocità operativa, interrompere i carichi di lavoro o limitare la densità dei rack.
Il raffreddamento a liquido trasferisce il calore attraverso un fluido anziché affidarsi interamente all’aria. Sta diventando più rilevante con l’aumento della densità di potenza a livello di rack e la minore praticità dei sistemi di raffreddamento tradizionali.
Tuttavia, il raffreddamento non è un componente che i team possono aggiungere alla fine. Layout della struttura, sistemi idrici, smaltimento del calore, progettazione elettrica, controlli e procedure di manutenzione devono essere coordinati fin dalle fasi iniziali.
Questo crea uno sfasamento temporale. Le generazioni di chip possono avanzare più rapidamente di quanto utility, sottostazioni, sale dati e impianti di raffreddamento possano essere pianificati e costruiti.
Un operatore potrebbe quindi avere accesso ad acceleratori più recenti, ma non disporre di un luogo adatto in cui utilizzarli. Il vincolo si sposta dalla fornitura di semiconduttori alla prontezza del deployment.
L’affermazione richiede un’importante precisazione. Non tutte le organizzazioni dovrebbero costruire la struttura AI più integrata o più densa possibile.
Servizi di inferenza più piccoli possono operare in modo efficiente su cluster modesti. Alcuni carichi di lavoro traggono maggior beneficio dalla compressione dei modelli, dal batching delle richieste, dalla cache o da modifiche applicative che dall’espansione dell’infrastruttura.
Anche i servizi cloud possono nascondere ai clienti molti dettagli fisici. Tuttavia, gli operatori cloud affrontano comunque i vincoli sottostanti e ne trasferiscono gli effetti tramite disponibilità, quote, prestazioni e condizioni commerciali.
La domanda scettica non è se l’equilibrio del sistema conti. È se i fornitori possano dimostrare che le loro architetture specifiche migliorano l’output utile con carichi di produzione comparabili.
La larghezza di banda di picco e la potenza di calcolo di picco sono limiti teorici. I sistemi reali incontrano guasti, traffico irregolare, overhead di comunicazione, bug software e richieste applicative in evoluzione.
Gli acquirenti dovrebbero quindi chiedere misurazioni a livello di carico di lavoro. Token al secondo, tempo di addestramento, latenza di coda, utilizzo, recupero dai guasti ed energia per attività forniscono un quadro più completo.
I fornitori di memoria si avvicinano alla progettazione dei sistemi
SK hynix utilizza l’argomento del collo di bottiglia per ampliare il ruolo della memoria, da componente acquistato a parte co-progettata dell’infrastruttura AI.
Questo interesse strategico merita un esame attento. SK hynix vende memoria, compresa l’HBM utilizzata accanto ai principali acceleratori AI.
Un articolo della newsroom che enfatizza la larghezza di banda della memoria sostiene naturalmente la posizione di mercato dell’azienda. Le sue conclusioni dovrebbero essere valutate con la stessa cautela applicata alle affermazioni dei fornitori di GPU.
Tuttavia, l’argomentazione è in linea con i progetti pubblici di NVIDIA, AMD, Google e Meta. Ciascuna organizzazione sta investendo in modi per spostare i dati più efficacemente attraverso sistemi sempre più grandi.
La domanda più difficile riguarda la responsabilità. Tradizionalmente, un’azienda di memoria fornisce componenti conformi a una specifica di interfaccia e prestazioni.
L’ottimizzazione a livello di sistema richiede una collaborazione più precoce con progettisti di acceleratori, produttori di server, fornitori di networking, piattaforme cloud e team software. Può inoltre richiedere visibilità sui carichi di lavoro dei clienti.
SK hynix afferma che i fornitori di memoria devono sempre più contribuire a progettare i flussi di dati e a identificare architetture appropriate. Ciò avvicinerebbe il loro lavoro all’ingegneria di piattaforma.
Questo cambiamento è già visibile nel modo in cui l’HBM viene integrata nel packaging. Gli stack di memoria si trovano vicino ai processori grazie al packaging avanzato, poiché distanza fisica, ampiezza delle connessioni e consumo energetico influenzano il movimento dei dati.
Anche la capacità modifica la fattibilità del prodotto. Un modello che entra nella HBM locale evita parte dei trasferimenti attraverso livelli di memoria o storage più lenti.
Tuttavia, installare semplicemente più HBM non elimina ogni collo di bottiglia nella memoria GPU. Le applicazioni possono sprecare capacità a causa di allocazioni inefficienti, frammentazione, cache eccessive o parallelizzazione inadeguata.
Il software deve comprendere la gerarchia. Deve decidere quali informazioni restano nella memoria veloce, quali passano a pool più ampi e quando avvengono i trasferimenti.
Questo apre la concorrenza oltre i prodotti HBM convenzionali. Sistemi di cache, pooling della memoria, Compute Express Link, storage a stato solido ad alta velocità, connessioni ottiche e compressione possono affrontare parti diverse del problema.
Compute Express Link, comunemente chiamato CXL, è uno standard di interconnessione che consente ai processori di condividere o espandere la memoria con accesso coerente. La sua latenza differisce da quella dell’HBM direttamente collegata.
Nessun singolo livello di memoria offre la migliore combinazione di velocità, capacità, consumo energetico e flessibilità. L’infrastruttura AI continuerà a utilizzare gerarchie perché la memoria veloce resta limitata e costosa da produrre.
Il risultato è un mercato più ampio per il coordinamento. I fornitori di hardware desiderano un’integrazione più stretta, mentre i clienti vogliono flessibilità e protezione dal vendor lock-in.
Un sistema proprietario altamente ottimizzato può offrire prestazioni elevate per i carichi di lavoro supportati. Può anche rendere più difficili la sostituzione dei componenti, la migrazione del software e il benchmarking indipendente.
Gli standard aperti possono ampliare la scelta dei fornitori, ma non eguagliano automaticamente le prestazioni dei progetti strettamente integrati. Gli operatori devono scegliere dove l’integrazione produce valore misurabile.
SK hynix affronta anche un test di credibilità. Deve collegare l’argomento generale del muro della memoria a prodotti, progetti di riferimento e risultati ripetibili sui carichi di lavoro.
Una spiegazione della newsroom stabilisce la narrazione, non la prova. I benchmark indipendenti saranno importanti quando i clienti confronteranno diverse capacità di memoria, interconnessioni, percorsi di storage e piattaforme di accelerazione.
L’opportunità dell’azienda resta comunque evidente. Man mano che il calcolo diventa uno strato all’interno di un sistema più ampio, i fornitori di memoria acquisiscono influenza su architettura, roadmap, packaging e decisioni di deployment.
Tre segnali metteranno alla prova l’argomentazione della newsroom di hynix
La prossima fase sarà giudicata in base alle prestazioni dei carichi di lavoro erogati, non da un’altra serie di numeri di picco più elevati.
Il primo segnale è il benchmarking indipendente di sistemi completi. I test devono esaminare gli acceleratori insieme a memoria, networking, storage, software e consumo energetico.
Un benchmark utile dovrebbe indicare dimensione del modello, formato numerico, configurazione del batch, obiettivo di latenza, topologia hardware e condizioni di guasto. Senza questo contesto, un singolo numero può nascondere il vincolo reale.
I risultati dell’addestramento dovrebbero riportare il lavoro completato nel tempo, non solo le operazioni teoriche. I test di inferenza dovrebbero includere throughput e latenza di coda, che cattura le esperienze utente più lente.
Se i sistemi equilibrati mostrano un utilizzo costantemente più elevato e un output superiore per watt, la tesi di SK hynix guadagna supporto. Se gli aggiornamenti del calcolo dominano indipendentemente dalla progettazione circostante, l’argomentazione si indebolisce.
Il secondo segnale riguarda il modo in cui le piattaforme imminenti distribuiscono i miglioramenti tra calcolo e movimento dei dati. NVIDIA, AMD, Google e gli sviluppatori di chip personalizzati stanno tutti integrando funzionalità infrastrutturali più ampie.
Osservate se i nuovi sistemi aumentano capacità HBM, larghezza di banda della memoria, collegamenti scale-up, networking scale-out, accesso allo storage ed efficienza della struttura insieme alle prestazioni aritmetiche.
Un progetto che aumenta il calcolo molto più rapidamente di ogni livello di supporto rischia di riprodurre lo stesso collo di bottiglia su una scala più grande. Un progetto equilibrato dovrebbe mostrare miglioramenti nei carichi di lavoro reali.
Il terzo segnale è l’evidenza operativa da fornitori cloud e aziende. I loro risultati possono rivelare se una migliore infrastruttura riduce tempi di inattività, esecuzioni fallite, ritardi di avvio e latenza di risposta.
Le divulgazioni più utili collegheranno i cambiamenti tecnici ai risultati del servizio. Gli esempi includono un recupero più rapido dai checkpoint, un maggiore utilizzo degli acceleratori o una latenza di inferenza più prevedibile.
Gli operatori dovrebbero inoltre rendere noti i compromessi. Un sistema potrebbe migliorare il throughput consumando però più energia, richiedendo un raffreddamento più denso o limitando la portabilità del software.
Questi segnali contano perché il problema dell’infrastruttura non ha una soluzione permanente. La rimozione di un collo di bottiglia ne espone spesso un altro, prima nascosto.
Uno storage più veloce può spostare la pressione sul networking. Più memoria può aumentare le esigenze di sincronizzazione. Un calcolo più denso può creare un problema per la struttura anche quando il server offre buone prestazioni.
La lezione pratica non è smettere di acquistare acceleratori più veloci. È considerarli un investimento all’interno di un percorso dati misurato.
Gli sviluppatori dovrebbero profilare dove le richieste trascorrono il tempo. I team infrastrutturali dovrebbero monitorare utilizzo, larghezza di banda, latenza dello storage, alimentazione, condizioni termiche e guasti con carichi di lavoro rappresentativi.
Gli acquirenti aziendali dovrebbero richiedere risultati dalle proprie applicazioni anziché accettare specifiche generiche di picco. I clienti cloud dovrebbero confrontare latenza e throughput effettivamente erogati su modelli di traffico realistici.
La newsroom di hynix ha identificato il test giusto per la prossima fase dell’infrastruttura AI: con quale efficienza i dati raggiungono il processore e poi lo lasciano?
Prima del prossimo acquisto di GPU, tracciate un carico di lavoro rappresentativo dallo storage alla memoria, alla rete, all’acceleratore e alla risposta. Quale livello è in attesa e l’aggiornamento proposto eliminerà davvero tale attesa?
