Il model caching di Amazon SageMaker HyperPod riduce i cold start dell'inferenza da minuti a secondi

Amazon afferma che il model caching di SageMaker HyperPod può ridurre alcuni cold start dell'inferenza da decine di minuti a pochi secondi. La nuova funzionalità precarica i pesi dei modelli e le immagini container sui nodi del cluster prima che i pod di inferenza ne abbiano bisogno. In questo modo, l'avvio passa dall'essere un problema di trasferimento in rete a un'operazione sullo storage locale.

Il cambiamento importante non è un altro server per modelli più veloce. AWS sposta una fase di preparazione lenta al di fuori del percorso critico per l'avvio di un carico di lavoro. Quando viene avviato un pod, può leggere gli artefatti necessari dallo storage NVMe locale anziché scaricarli attraverso la rete.

Questo approccio mette sotto pressione il tradizionale metodo pull-on-start usato da molte implementazioni di inferenza Kubernetes. Segue inoltre tecniche consolidate come il pre-pulling delle immagini container e il cache warming. La differenza è che SageMaker HyperPod ora coordina il caching di grandi artefatti dei modelli all'interno del proprio ambiente di inferenza gestito.

AWS presenta un risultato convincente, ma il messaggio principale richiede contesto. Un nodo caldo non equivale a una flotta calda garantita. Gli operatori devono comunque gestire capacità, copertura della cache, versioni dei modelli, guasti e il primo caricamento sui nuovi nodi.

Il model caching di SageMaker HyperPod sposta i download fuori dal percorso di avvio

AWS ha modificato il momento in cui i nodi di inferenza ricevono i file necessari per servire un modello.

Secondo il post sul model caching di settembre 2026, HyperPod può precaricare pesi dei modelli e immagini container sui nodi del cluster. Questi artefatti rimangono disponibili sullo storage NVMe locale per i successivi avvii dei pod.

I pesi del modello sono i parametri appresi che un server di inferenza carica nella memoria dell'acceleratore. Un'immagine container racchiude il software del server, le librerie e le dipendenze di runtime. Entrambi possono essere abbastanza grandi da dominare il tempo di avvio quando vengono recuperati dopo l'inizio della pianificazione.

Senza caching, un pod appena pianificato può attivare diverse operazioni sequenziali. Il nodo potrebbe dover scaricare l'immagine container, recuperare i file del modello, preparare il runtime e caricare i pesi in memoria. Il throughput di rete, le prestazioni del servizio di storage e i download simultanei possono prolungare questo processo.

Il caching modifica la sequenza. HyperPod prepara il nodo prima che un pod di inferenza entri nel percorso di avvio sensibile alla latenza. Una volta iniziata la pianificazione, il pod può utilizzare copie locali anziché attendere trasferimenti remoti.

Questa distinzione conta durante deployment pianificati e picchi di domanda imprevisti. Un modello che viene riavviato raramente può tollerare un lungo download iniziale. Un servizio con autoscaling non può nascondere lo stesso ritardo quando il traffico cresce più rapidamente di quanto le nuove repliche siano pronte.

La funzionalità affronta inoltre una parte specifica della latenza di cold start. Non elimina la pianificazione dei pod, l'inizializzazione del container, la deserializzazione del modello, la configurazione dell'acceleratore, i controlli di integrità o il warm-up dell'applicazione. Queste fasi rimangono necessarie dopo che gli artefatti hanno raggiunto il nodo.

Le piattaforme container riconoscono già il valore delle immagini locali. Kubernetes spiega che `imagePullPolicy` controlla se un nodo utilizza un'immagine esistente o verifica un registry. HyperPod estende l'idea della copia locale agli artefatti dei modelli, molto più grandi, richiesti dai moderni carichi di inferenza.

AWS afferma che il miglioramento risultante può trasformare attese misurate in decine di minuti in attese misurate in secondi. Il confronto riflette la differenza tra l'acquisizione remota degli artefatti e le letture locali. Non va interpretato come una garanzia universale sui tempi di avvio per ogni modello o cluster.

Il vantaggio dipende da un cache hit. La versione del modello e l'immagine richieste devono già esistere sul nodo selezionato. In caso contrario, torna in gioco una parte o l'intero percorso di trasferimento originale.

Questa condizione crea la tensione centrale dell'articolo. Il model caching offre un importante vantaggio di latenza svolgendo in anticipo il lavoro lento. Richiede però agli operatori di prevedere ciò di cui avrà bisogno ciascun nodo.

I cold start diventano un problema di capacità, non solo di rete

La funzionalità sposta la pressione operativa dalla velocità di download al posizionamento, alla preparazione e alla copertura della cache.

I cold start dell'inferenza diventano problematici quando le repliche devono rispondere alla domanda reale. Un servizio può disporre sulla carta di capacità sufficiente di acceleratori e rimanere comunque indisponibile perché i suoi nodi stanno ancora raccogliendo gli artefatti.

I modelli di grandi dimensioni rendono questa discrepanza più evidente. Il modello non è pronto semplicemente perché Kubernetes ha assegnato un pod a un nodo GPU. Il nodo necessita ancora del software e dei pesi corretti prima che il server possa accettare richieste.

Anche i download di rete competono tra loro. Un rollout che avvia più repliche può far sì che diversi nodi recuperino simultaneamente gli stessi dati. Questo schema consuma banda condivisa e può rendere i tempi di avvio meno prevedibili.

Il caching locale elimina i trasferimenti di rete ripetuti quando sono presenti gli artefatti necessari. Può quindi aiutare in diversi eventi operativi:

• Scalare automaticamente un endpoint dopo un aumento della domanda

• Ripristinare repliche dopo un guasto di processo o di nodo

• Distribuire una nuova configurazione del server di inferenza

• Riprogrammare carichi di lavoro durante la manutenzione del cluster

• Spostare il traffico tra versioni di modello preparate

• Avviare carichi batch o di valutazione su infrastruttura condivisa

Il beneficio maggiore emerge quando lo stesso modello viene avviato ripetutamente su un gruppo stabile di nodi preparati. Ogni cache hit riutilizza il lavoro di trasferimento svolto in precedenza. Il valore diminuisce quando i modelli cambiano continuamente o la pianificazione distribuisce i carichi su capacità non preparata.

I team di piattaforma sono il primo gruppo sottoposto a pressione. Devono decidere quali artefatti meritano il limitato storage locale e quali nodi dovrebbero contenerli. Queste decisioni diventano parte della capacità di serving, anche se in precedenza erano considerate preparazione del deployment.

Anche i team applicativi ereditano una nuova aspettativa. Se la piattaforma supporta artefatti caldi, un lungo ritardo nello scale-out diventa più difficile da liquidare come inevitabile. I responsabili dei servizi si aspetteranno che le policy della cache corrispondano ai loro obiettivi di latenza.

L'alternativa convenzionale è il download reattivo. È operativamente semplice perché ogni pod dichiara ciò di cui ha bisogno e recupera quei file quando necessario. Tuttavia, questa semplicità colloca trasferimenti grandi e variabili direttamente nel percorso di ripristino rivolto agli utenti.

AWS sta di fatto chiedendo ai team di riservare risorse prima che arrivi la domanda. La risorsa riservata non è soltanto il calcolo. Include spazio sullo storage locale, tempo di trasferimento e la certezza che l'artefatto riscaldato corrisponda al prossimo carico di lavoro.

Questo approccio ricorda il mantenimento di capacità di standby. Un nodo preparato comporta un costo opportunità mentre resta in attesa. Eppure un nodo non preparato può lasciare acceleratori costosi inattivi durante un download prolungato.

Il cambiamento è particolarmente rilevante per i cluster multi-tenant. HyperPod è progettato per coordinare carichi di lavoro di machine learning su infrastruttura condivisa, come descritto nella documentazione HyperPod. I cluster condivisi migliorano l'utilizzo, ma rendono più complessi anche il posizionamento e l'allocazione della cache.

Un team che esegue un solo modello può riscaldare ogni nodo idoneo. Una piattaforma che ospita molti modelli deve scegliere. Può duplicare ampiamente gli artefatti più popolari, mantenere pool specializzati oppure accettare cache miss per i carichi meno frequenti.

Queste policy determinano se il model caching si comporta come un miglioramento della latenza per l'intera flotta o come un'ottimizzazione selettiva. La nuova funzionalità rimuove un collo di bottiglia solo quando la pianificazione della capacità colloca i byte corretti vicino all'acceleratore corretto.

Come l'NVMe locale trasforma l'avvio del modello in un cache hit

Il meccanismo funziona perché lo storage locale offre un percorso dati più breve dopo che HyperPod ha completato la preparazione iniziale.

L'NVMe locale è storage collegato strettamente a un nodo di calcolo tramite l'interfaccia PCI Express. In genere evita il salto di rete remoto richiesto per scaricare artefatti dall'object storage o da un container registry.

La distinzione è importante perché l'avvio di un modello sposta dati attraverso diversi livelli. Un artefatto può viaggiare dallo storage remoto a un nodo, dal filesystem del nodo alla memoria di sistema e quindi verso la memoria dell'acceleratore. Il caching elimina il primo tragitto ripetuto.

HyperPod deve prima popolare la cache. Questa operazione iniziale usa comunque banda di rete e richiede tempo. La funzionalità riduce i cold start successivi anziché eliminare la necessità di distribuire i dati del modello.

Una volta memorizzati nella cache, i pesi del modello e l'immagine container possono sopravvivere alla sostituzione di singoli pod finché il nodo rimane disponibile. Un nuovo pod può riutilizzare la copia a livello di nodo anziché trattare ogni avvio come un deployment completamente nuovo.

Questa è una forma di riutilizzo temporale. Gli operatori investono tempo una sola volta, quindi recuperano quell'investimento negli avvii successivi. L'economia migliora quanto più spesso viene riutilizzato lo stesso artefatto.

Il design offre anche riutilizzo spaziale quando più carichi compatibili utilizzano una copia memorizzata nella cache condivisa. Questa possibilità dipende da come HyperPod identifica artefatti, versioni e requisiti di posizionamento. I team dovrebbero verificare questi dettagli rispetto alla configurazione supportata dalla funzionalità prima di definire gli obiettivi del servizio.

Le immagini container e i pesi dei modelli richiedono una gestione differente. Un'immagine entra nello store locale del runtime container. I file del modello devono rimanere accessibili nella posizione prevista del filesystem e nel formato richiesto dal server di inferenza.

Un cache hit non significa che il modello sia già caricato nella memoria GPU. Il server potrebbe comunque dover mappare, leggere, deserializzare, suddividere o trasformare i pesi. I modelli distribuiti potrebbero inoltre richiedere coordinamento tra più acceleratori o nodi.

Questo confine spiega perché il miglioramento più marcato di AWS dovrebbe emergere nelle implementazioni in cui i download pesano maggiormente. Se l'acquisizione in rete consuma la maggior parte del tempo di avvio, rimuoverla produce una riduzione significativa. Se predomina l'inizializzazione del runtime, il ritardo rimanente sarà più visibile.

Gli operatori possono stimare l'opportunità misurando l'avvio come fasi separate:

1. Tempo di attesa per un nodo pianificabile

2. Tempo per il pull dell'immagine container

3. Tempo per il recupero dei pesi del modello

4. Tempo per l'inizializzazione del runtime di inferenza

5. Tempo per il caricamento o lo sharding dei pesi

6. Tempo per il completamento dei controlli di integrità

7. Tempo per servire la prima richiesta riuscita

Il model caching mira direttamente alla seconda e alla terza fase. Un accesso locale più rapido può migliorare indirettamente le fasi successive, ma non ne elimina i requisiti di calcolo.

La funzionalità premia quindi una telemetria dettagliata. Una singola misura del “tempo di avvio del pod” non può mostrare se una regressione è stata causata da un miss, dall'inizializzazione del runtime o da un ritardo di pianificazione.

I team dovrebbero registrare lo stato di cache hit insieme alla latenza di readiness. Dovrebbero inoltre separare gli eventi relativi a nuovi nodi dai semplici riavvii dei pod. Senza queste etichette, una mediana impressionante può nascondere miss lenti proprio nelle situazioni più importanti.

La conoscenza operativa conta quanto le metriche. I team di engineering hanno bisogno di policy della cache, procedure di rollout e istruzioni di ripristino facilmente accessibili. Una base di conoscenza ricercabile può mantenere queste decisioni collegate ai record di deployment e ai risultati degli incidenti.

L’abilitazione della funzionalità dovrebbe iniziare con un servizio rappresentativo, non con l’intero parco modelli. Selezionate un modello il cui avvio sia dimostrabilmente vincolato al trasferimento. Preparate gli artefatti tramite la configurazione HyperPod supportata, quindi confrontate il comportamento in caso di hit e miss con avvii controllati.

Il test dovrebbe includere la sostituzione dei nodi. Una cache che offre buone prestazioni durante i riavvii dei pod può comunque deludere quando l’autoscaling introduce macchine nuove. Questo scenario rivela se la preparazione termina prima che il traffico raggiunga la nuova capacità.

Il preloading mette in discussione il modello pull-on-start

Il confronto principale è tra preparazione proattiva e semplicità reattiva.

I deployment pull-on-start hanno una proprietà interessante. La specifica del pod identifica un’immagine e la posizione del modello, mentre il runtime risolve queste dipendenze all’avvio. I team evitano di dover mantenere una previsione separata della domanda futura.

Questo modello diventa costoso quando gli artefatti crescono. Ogni evento di ripristino o scale-out può ripetere lo stesso trasferimento. L’architettura tratta una dipendenza nota come se fosse un’informazione nuova.

La cache dei modelli di SageMaker HyperPod ribalta questa ipotesi. Se un operatore sa già quale modello servirà un nodo, attendere l’avvio offre pochi vantaggi. La distribuzione anticipata trasforma la domanda prevista in capacità preparata.

I due approcci commettono errori diversi. Il download reattivo rischia di arrivare troppo tardi. La cache proattiva rischia di preparare l’artefatto sbagliato o troppe copie.

Questo compromesso distingue la cache dei modelli da un semplice interruttore delle prestazioni. I team devono collegare le decisioni di caching alle previsioni di traffico, ai programmi di deployment, ai domini di errore e alla popolarità dei modelli.

Considerate un endpoint di produzione stabile che serve un unico modello di grandi dimensioni. Il suo working set è prevedibile e i ripetuti cache hit possono giustificare una replica estesa. Un riavvio progressivo può riutilizzare artefatti locali tra pod sostitutivi.

Ora considerate una piattaforma interna che ospita centinaia di modelli sperimentali. La maggior parte potrebbe essere eseguita brevemente o una sola volta. Riempire i dischi locali con ogni artefatto può generare churn senza produrre un riutilizzo sufficiente.

La stessa distinzione vale per le versioni. Un servizio di produzione potrebbe mantenere disponibili la versione corrente e quella successiva durante un rollout. Conservare molte versioni più vecchie consuma spazio di archiviazione e complica l’eviction.

I sistemi reattivi gestiscono naturalmente le modifiche di versione perché ogni pod recupera la versione dichiarata. Una cache proattiva necessita di un processo che scaldi la nuova versione, la verifichi, reindirizzi lo scheduling e in seguito rimuova la vecchia copia.

Questo crea una questione di coerenza. L’accesso rapido è utile solo se l’artefatto locale corrisponde esattamente alla versione prevista dal deployment. Chiavi della cache, identificatori immutabili e controlli di deployment diventano parte della correttezza.

I tag mutabili sono particolarmente rischiosi. Se un tag del container o un percorso del modello può puntare a contenuti diversi nel tempo, la cache potrebbe contenere qualcosa che non corrisponde più all’intento dell’operatore. Gli artefatti versionati riducono questa ambiguità.

Gli aggiornamenti di sicurezza aggiungono un’altra sfida. Un’immagine container memorizzata in cache può avviarsi rapidamente, ma la velocità non può giustificare il mantenimento di layer di runtime vulnerabili. I team hanno bisogno di un percorso di invalidazione definito quando cambia un’immagine di base o una dipendenza.

L’approccio proattivo mantiene comunque un forte vantaggio durante eventi prevedibili. Avvii pianificati, rollout di versione e aumenti di traffico programmati lasciano il tempo di scaldare i nodi prima che ricevano richieste.

Aiuta inoltre a separare i fallimenti di preparazione da quelli di servizio. Se un nodo non riesce a ottenere un artefatto durante il preloading, la piattaforma può rilevare il problema prima di instradare traffico reale verso quella capacità.

Altre piattaforme cloud e Kubernetes possono implementare schemi simili tramite pre-pulling, processi daemon, volumi locali o orchestrazione personalizzata. La differenziazione di AWS risiede nell’integrare il flusso di lavoro con HyperPod, non nell’inventare il caching in sé.

Ciò significa che i concorrenti non sono esclusi dal meccanismo. La pressione ricade sulle piattaforme di inferenza gestite affinché rendano il warming affidabile, osservabile e più semplice da usare rispetto alla manutenzione di script personalizzati.

AWS deve quindi competere sui risultati operativi. Le domande cruciali riguardano il posizionamento della cache, la visibilità dello stato, il recupero dagli errori e la compatibilità. La velocità pura dello storage locale è solo una parte del prodotto.

I secondi su un nodo caldo non garantiscono secondi sull’intera flotta

Il risultato di AWS descrive il potenziale di un percorso preparato, mentre i deployment reali devono considerare miss e turnover dei nodi.

La limitazione centrale è semplice. Una cache accelera solo i dati che contiene. Nuovi nodi, artefatti rimossi, versioni di modello modificate o un posizionamento imprevisto possono ricreare il ritardo originario.

Anche NVMe locale ha capacità finita. Ogni modello, immagine e versione memorizzati in cache competono per lo spazio. Gli operatori necessitano di una policy di eviction o di un processo di ciclo di vita intenzionale prima che i dischi si riempiano.

Una policy automatica least-recently-used può favorire gli artefatti popolari. Tuttavia, l’utilizzo recente non è sempre il miglior segnale per un avvio imminente. Deployment programmati ed eventi di traffico noti possono richiedere una priorità esplicita.

Una policy manuale offre controllo, ma aggiunge lavoro. Qualcuno deve decidere cosa posizionare, dove posizionarlo e quando rimuoverlo. Queste decisioni diventano più difficili quando i team condividono il cluster.

Il guasto di un nodo crea un altro confine. Lo storage collegato a un nodo guasto o terminato non può scaldare da solo il suo sostituto. La piattaforma deve ripopolare la nuova macchina prima che offra lo stesso comportamento di avvio.

L’autoscaling presenta un problema analogo. Una flotta può registrare riavvii rapidi dei pod sui nodi esistenti, ma impiegare molto più tempo per aggiungere capacità completamente nuova. Entrambe le misurazioni sono importanti, ma rispondono a domande operative diverse.

Le medie possono nascondere questa differenza. Supponiamo che la maggior parte degli avvii trovi la cache, mentre un piccolo numero di miss richieda molto più tempo. La mediana appare eccellente, ma un picco che richiede nuovi nodi può comunque esporre gli utenti a ritardi.

I team dovrebbero monitorare percentili e classi di eventi. Categorie utili includono riavvio di pod caldo, pod freddo su nodo caldo, pod su nuovo nodo, nuova versione del modello e ripristino dopo la perdita di un nodo.

L’affermazione pubblicata necessita anche di una validazione indipendente. AWS fornisce l’architettura e il confronto riportato, ma le prestazioni dipendono dalle dimensioni dell’artefatto, dal tipo di nodo, dalle condizioni di rete, dal runtime e dalla progettazione del test. I lettori dovrebbero considerare i “secondi” un risultato dimostrato, non una promessa universale di livello di servizio.

Il caricamento del modello resta un’altra variabile. Alcuni runtime eseguono un’inizializzazione estesa dopo che i file diventano locali. Quantizzazione, conversione dei tensori, compilazione o coordinamento distribuito possono comunque allungare il percorso verso la disponibilità.

I controlli di integrità possono aggiungere ulteriore ritardo se fanno più che confermare la disponibilità del processo. Un endpoint di produzione potrebbe richiedere che il server carichi ogni shard e completi una richiesta di test prima di ricevere traffico.

Il caching consuma anche larghezza di banda per la preparazione. Scaldare molti nodi contemporaneamente può spostare il carico di rete a un momento precedente senza ridurne il volume totale. Pianificare il lavoro fuori dai periodi di picco diventa parte del vantaggio.

Sicurezza e governance meritano pari attenzione. Gli artefatti memorizzati in cache dovrebbero rispettare gli stessi requisiti di autorizzazione, crittografia, provenienza e vulnerabilità delle rispettive fonti remote. Una copia locale resta una dipendenza di produzione.

I team devono inoltre comprendere la persistenza dei dati. NVMe locale segue spesso il ciclo di vita dell’host. Gli operatori non dovrebbero confondere una cache delle prestazioni con storage durevole o con la fonte autorevole degli artefatti del modello.

Il criterio di adozione più sicuro è misurabile. Confrontate la distribuzione della disponibilità prima e dopo il caching, includendo cache miss e nodi nuovi. Quindi verificate se la capacità reale di scale-out diventa disponibile entro la finestra obiettivo del servizio.

Se migliorano soltanto i riavvii sui nodi caldi, la funzionalità conserva comunque valore. Risolve semplicemente un problema più ristretto di quanto suggerisca il titolo.

Tre segnali mostreranno se la cache dei modelli cambia l’inferenza in produzione

Il prossimo test consiste nel verificare se cache hit prevedibili resistono ai cambiamenti reali della flotta, agli aggiornamenti dei modelli e alla domanda di cluster condivisi.

Il primo segnale è l’osservabilità della cache. Gli operatori hanno bisogno di dati chiari che mostrino quali artefatti esistono su ciascun nodo, se un avvio ha trovato la cache e perché un preload non è riuscito.

Questo segnale rafforza la tesi di AWS se i team possono collegare i singoli tempi di avvio allo stato della cache senza sviluppare strumentazione personalizzata. La indebolisce se il caching si comporta come un processo di background invisibile.

Una buona visibilità dovrebbe anche esporre la capacità. I team devono sapere quanto storage locale rimane, quali artefatti lo consumano e cosa sarà rimosso successivamente. Questi elementi determinano se un piano di deployment è credibile.

Il secondo segnale riguarda le prestazioni durante la sostituzione dei nodi e l’autoscaling. I nodi esistenti rappresentano lo scenario più semplice perché hanno già avuto tempo per prepararsi.

Un test più rigoroso aggiunge nuova capacità durante un picco di traffico. Il servizio deve ottenere nodi, scaldare gli artefatti corretti, inizializzare il runtime e superare i controlli di integrità prima che arrivino le richieste.

Il modello di AWS diventa più convincente se l’intero processo resta prevedibile. La tesi si indebolisce se gli avvii in pochi secondi si applicano solo dopo che gli operatori hanno mantenuto manualmente un grande pool caldo.

Osservate le misurazioni che separano il trasferimento dell’artefatto dalla disponibilità totale. Entrambi sono utili, ma non possono sostituirsi l’uno all’altra. Gli utenti sperimentano il percorso completo.

Il terzo segnale è il comportamento in caso di cambio versione. I team di inferenza in produzione aggiornano regolarmente pesi, immagini container, dipendenze e configurazioni.

Un sistema di caching maturo dovrebbe preparare la versione successiva senza interrompere quella corrente. Dovrebbe verificare l’identità dell’artefatto, coordinare il posizionamento, supportare il rollback e rimuovere in sicurezza le copie obsolete.

Questo flusso di lavoro determina se il caching aiuta le operazioni quotidiane o soltanto le dimostrazioni benchmark. Mostra anche quanto bene HyperPod gestisca la tensione tra velocità e correttezza.

Le risposte dei concorrenti forniranno contesto aggiuntivo. Altre piattaforme gestite possiedono già gli ingredienti tecnici per il caching a livello di nodo. AWS alza l’aspettativa che tali ingredienti diventino un flusso di lavoro di inferenza supportato.

La direzione più ampia è chiara. Con la crescita degli artefatti dei modelli, le piattaforme cloud non possono trattare ogni avvio di pod come un download pulito da storage remoto. Devono anticipare una maggiore preparazione rispetto alla domanda.

La cache dei modelli di SageMaker HyperPod è un’implementazione importante di questa idea. Attacca una fonte concreta di latenza da cold start senza affermare di sostituire il resto dello stack di inferenza.

Per gli sviluppatori, l’azione immediata è misurare dove viene impiegato il tempo di avvio. Se dominano i trasferimenti di immagini e pesi, la cache dei modelli merita una sperimentazione controllata in produzione. Se domina l’inizializzazione, i team dovrebbero prima ottimizzare il percorso del server.

Gli acquirenti enterprise dovrebbero chiedere metriche di hit rate, risultati sui nodi nuovi, controlli del ciclo di vita della cache e comportamento documentato in caso di errore. Un valore nel caso migliore conta meno di una distribuzione affidabile della disponibilità durante gli incidenti.

La domanda finale è operativa: il vostro team può identificare abbastanza presto i modelli necessari domani da preparare oggi i nodi corretti? Se può farlo, la cache di Amazon trasforma quella conoscenza in ripristino e scaling più rapidi. Se non può, il download di rete è stato semplicemente spostato in un momento diverso.