I Deep Learning Containers AWS Ray Serve subentrano dove termina il supporto di TorchServe

AWS ha pubblicato un percorso di migrazione a GPU singola che utilizza AWS Ray Serve Deep Learning Containers, mentre TorchServe entra in una sospensione della manutenzione a tempo indeterminato. Il cambiamento è rilevante perché gli utenti di TorchServe non dispongono più di un framework di serving gestito attivamente alla base dei loro modelli PyTorch in produzione. AWS propone invece uno stack di container collaudato, ma i team devono comunque riscrivere le proprie applicazioni di serving e gestire l'infrastruttura circostante.

Il nuovo tutorial di migrazione distribuisce il modello vision-language Qwen3-VL-2B su Amazon Elastic Kubernetes Service, o Amazon EKS. Viene eseguito all'interno di un pod su un'istanza g5.xlarge, con una GPU NVIDIA A10G e 24 GB di memoria GPU. L'esempio espone il modello tramite un endpoint HTTP sulla porta 8000.

Questa distribuzione contenuta mette in luce il conflitto più ampio. TorchServe in passato riuniva archiviazione dei modelli, handler, configurazione e serving in un flusso di lavoro incentrato su PyTorch. AWS Ray Serve Deep Learning Containers sostituisce quel framework con un'immagine gestita, codice applicativo Ray Serve e risorse Kubernetes standard. La responsabilità operativa cambia forma, anziché scomparire.

AWS trasforma una lacuna nel supporto di TorchServe in un percorso di migrazione basato su container

AWS risponde al blocco della manutenzione di TorchServe con uno stack di inferenza collaudato, non con una sostituzione immediata.

La documentazione ufficiale di TorchServe mostra ora un avviso di manutenzione limitata. Indica che il progetto non è più gestito attivamente. Le release esistenti restano disponibili, ma non sono previsti aggiornamenti, correzioni di bug, funzionalità o patch di sicurezza.

Questo avviso modifica la valutazione del rischio per gli utenti in produzione. Un'applicazione stabile può continuare a funzionare su una release TorchServe esistente. Tuttavia, ogni nuovo requisito relativo a framework, sistema operativo, CUDA o sicurezza introduce un'altra decisione di compatibilità per il proprietario dell'applicazione.

La sicurezza è l'aspetto più difficile da rimandare. L'avviso di TorchServe avverte esplicitamente che le vulnerabilità potrebbero non essere risolte. Le organizzazioni possono isolare le distribuzioni e aggiornare i livelli circostanti, ma non possono fare affidamento su future correzioni upstream del framework di serving.

AWS posiziona il proprio Ray Serve Deep Learning Container, comunemente chiamato DLC, come base supportata per questi carichi di lavoro. Un DLC è un'immagine container con un framework selezionato e le relative dipendenze installate e testate insieme. AWS pubblica immagini Ray Serve separate per Amazon EC2 ed EKS, nonché per Amazon SageMaker.

L'immagine GPU parte da una base NVIDIA Amazon Linux 2023. Questa base include il sistema operativo e le librerie runtime CUDA. AWS aggiunge quindi PyTorch, Ray Serve, FastAPI, Uvicorn, Hugging Face Transformers e utilità per l'elaborazione di visione, audio e contenuti multimodali.

L'immagine include anche una build di FFmpeg con accelerazione hardware NVIDIA per il pre-elaborazione dei video. Questo dettaglio è importante per i team che servono modelli che combinano fotogrammi video, immagini, audio e testo. Questi carichi di lavoro richiedono spesso più di un framework per modelli e di un server HTTP.

AWS afferma di validare insieme i componenti inclusi prima di ogni release dell'immagine. Le patch di sicurezza vengono applicate durante la creazione dell'immagine. Questo approccio riduce la deriva di versione tra il runtime CUDA, PyTorch, Ray Serve e il livello di web serving.

Questa promessa ha un confine ben definito. AWS supporta e testa la combinazione container, mentre gli utenti restano responsabili del proprio codice modello, della configurazione del cluster, dei controlli di rete, delle policy di scalabilità e del processo di aggiornamento. Un'immagine gestita restringe la superficie che i team devono assemblare autonomamente.

L'esempio evita inoltre di presentare Ray Serve come una modalità di compatibilità trasparente con TorchServe. Gli ingegneri scrivono una nuova classe Python di serving e la distribuiscono tramite Ray Serve. Non importano un archivio TorchServe né riutilizzano l'intera interfaccia di gestione.

Questa distinzione mantiene l'annuncio ancorato alla realtà. AWS Ray Serve Deep Learning Containers offre una destinazione supportata per i carichi di lavoro interessati. Non rende automatica una migrazione in produzione e non elimina la necessità di testare la distribuzione.

Perché i team TorchServe ora gestiscono una parte maggiore dello stack GPU

La fine della manutenzione attiva di TorchServe trasferisce direttamente l'incertezza upstream ai team di platform engineering e machine learning.

Un servizio di inferenza GPU dipende da vari livelli che evolvono in modo indipendente. Questi includono il sistema operativo, il runtime NVIDIA, le librerie CUDA, PyTorch, le dipendenze del modello, il server delle richieste e l'ambiente di orchestrazione. I problemi di compatibilità possono comparire anche quando il codice del modello non cambia.

TorchServe offriva in precedenza ai team PyTorch un percorso riconoscibile per il packaging e il serving. Gli sviluppatori potevano creare un archivio di modelli con torch-model-archiver, fornire un handler personalizzato e controllare il comportamento tramite config.properties. Questo flusso di lavoro introduceva la propria complessità, ma forniva anche una convenzione operativa condivisa.

Il blocco della manutenzione elimina la certezza che questa convenzione continui a tenere il passo con il software adiacente. I team possono fissare ogni dipendenza a una versione specifica, ma tale scelta rimanda soltanto la decisione successiva. Una patch del sistema operativo, una modifica della GPU o un aggiornamento del framework impongono prima o poi una validazione dell'intero stack.

Continuare a usare TorchServe resta possibile. Il progetto non è scomparso e le release esistenti funzionano ancora per molte distribuzioni. Il problema è che rimanervi diventa una scelta deliberata di responsabilità interna, anziché un'impostazione predefinita supportata.

Le organizzazioni che seguono questa strada necessitano di un processo di sicurezza chiaro. Devono monitorare le dipendenze pertinenti, valutare le interfacce esposte, ricreare le immagini e testare le correzioni senza aspettarsi nuove release di TorchServe. Devono inoltre disporre di un piano per le vulnerabilità all'interno di TorchServe stesso.

L'alternativa è la migrazione, che crea lavoro tecnico immediato. Gli handler TorchServe e gli archivi di modelli non diventano automaticamente deployment Ray Serve. Il parsing delle richieste, il comportamento di health check, le metriche, il caricamento dei modelli, il batching e la gestione degli errori richiedono tutti un confronto.

Ray Serve modifica il modello di programmazione principale. Uno sviluppatore contrassegna una classe Python con @serve.deployment, inizializza il modello all'interno di quella classe e gestisce le richieste HTTP in ingresso tramite __call__. La chiamata a .bind() registra l'applicazione per Ray Serve.

Questo modello può sembrare più semplice della struttura di archivi e handler di TorchServe. Offre inoltre agli sviluppatori una normale composizione Python e accesso diretto alle dichiarazioni di risorse di Ray. Per esempio, il deployment AWS richiede una GPU tramite ray_actor_options={"num_gpus": 1}.

Tuttavia, un codice applicativo più semplice non significa operazioni di produzione più semplici. I team hanno ancora bisogno di controlli di readiness, autenticazione, gestione del traffico, telemetria, controlli di deployment e procedure di rollback. Devono decidere come i pesi del modello entrano nell'ambiente e come le repliche si comportano durante gli aggiornamenti.

Il container AWS sposta a monte diverse scelte di compatibilità. AWS seleziona e testa il sistema operativo di base, il runtime CUDA, il framework e le dipendenze di serving. Questo può ridurre il lavoro di integrazione ripetuto richiesto da un'immagine assemblata internamente.

Crea inoltre una nuova dipendenza dalle release delle immagini AWS. I team della piattaforma devono tenere traccia dei tag delle immagini, rivedere le modifiche, analizzare i livelli aggiunti e qualificare le nuove versioni nei propri ambienti. Una base collaudata è una prova utile, ma non è una certificazione a livello applicativo.

I team con requisiti di conformità necessitano di una validazione ancora maggiore. Devono confermare che il contenuto dell'immagine soddisfi le policy interne e che gli aggiornamenti arrivino entro le tempistiche richieste. Hanno inoltre bisogno di software bill of materials e registri di gestione delle vulnerabilità per l'immagine completa.

La pressione ricade quindi soprattutto sui team con ecosistemi TorchServe maturi. Hanno accumulato handler, passaggi di packaging, dashboard e conoscenze operative attorno a un unico framework. Passare a Ray Serve significa investire tale esperienza mentre il vecchio sistema può ancora apparire stabile.

Le distribuzioni più piccole affrontano un calcolo diverso. Se un servizio ha un solo modello e traffico prevedibile, uno stack completo Ray e Kubernetes può introdurre complessità non necessaria. Il valore dipende dal fatto che l'organizzazione gestisca già EKS e preveda esigenze di scalabilità più ampie.

Come AWS Ray Serve Deep Learning Containers modifica il modello di serving

Il meccanismo centrale è la pre-integrazione: AWS fissa lo stack di base, mentre Ray Serve sostituisce il packaging e il ciclo di vita delle richieste di TorchServe.

L'esempio AWS serve Qwen/Qwen3-VL-2B-Instruct, un modello vision-language che elabora immagini e testo. Accetta un URL dell'immagine e un prompt, quindi restituisce una descrizione o una risposta generata. Il modello si adatta all'esempio perché esercita sia l'inferenza GPU sia il pre-elaborazione multimodale.

AWS carica il modello tramite Hugging Face Transformers. Un AutoProcessor prepara l'input multimodale, mentre AutoModelForImageTextToText carica il modello con pesi a mezza precisione. L'applicazione sposta quindi tali pesi sul dispositivo CUDA.

La classe di serving riceve direttamente la richiesta HTTP. Estrae l'URL dell'immagine e il prompt dal JSON, prepara gli input del modello, esegue la generazione e restituisce il risultato. FastAPI e Uvicorn forniscono la base di web serving inclusa nel DLC.

Questo design rimuove tre artefatti familiari di TorchServe. Non esistono un archivio di modelli TorchServe, una gerarchia di handler TorchServe o un file config.properties. Il contratto di serving risiede nell'applicazione Ray Serve e nella sua configurazione di deployment.

AWS inserisce questa applicazione Python tramite una ConfigMap Kubernetes. Una ConfigMap archivia configurazioni o file non segreti che un pod può montare in fase di esecuzione. Questo consente agli ingegneri di modificare il codice dimostrativo senza ricreare l'immagine container.

Questa flessibilità è utile durante la valutazione. Separa la logica di serving dall'immagine di base collaudata e riduce il ciclo modifica-distribuzione-test. Tuttavia, i team di produzione dovrebbero decidere se una configurazione modificabile sia compatibile con i propri requisiti di release e audit.

Alcune organizzazioni creeranno invece l'applicazione in un'immagine derivata. Questo approccio produce un artefatto immutabile che contiene sia la base AWS sia il codice di serving approvato. Può migliorare la riproducibilità, anche se ogni modifica dell'applicazione richiede una nuova build.

Il deployment riserva una GPU tramite la risorsa Kubernetes nvidia.com/gpu. Seleziona inoltre il nodo GPU utilizzando l'etichetta role=gpu-worker. Queste impostazioni aiutano Kubernetes a collocare il pod di inferenza sull'istanza prevista.

Ray riceve l'allocazione GPU tramite l'ambiente del container e la dichiarazione dell'applicazione. La classe del modello richiede una GPU, corrispondente alla singola GPU esposta al pod. In configurazioni più grandi, Ray può pianificare i deployment su un pool di risorse dichiarate.

AWS fornisce tre script attorno all'esempio. Il primo crea il cluster EKS con eksctl, la configurazione di rete, un provider OpenID Connect e gli add-on principali. Il secondo aggiunge il gruppo di nodi GPU gestito.

Il terzo script applica la ConfigMap e il deployment Kubernetes. Pianifica il pod Ray Serve sul nodo GPU e avvia il servizio sulla porta 8000. Il repository di esempio associato rende disponibili per l'ispezione tali artefatti di deployment.

Dopo il deployment, gli utenti possono ispezionare il pod e verificare l'allocazione della GPU. Possono quindi inoltrare la porta locale 8000 al deployment in esecuzione e inviare una richiesta HTTP contenente un URL dell'immagine e un prompt. L'esecuzione di nvidia-smi all'interno del pod conferma l'uso della GPU.

La sequenza di avvio rivela un dettaglio operativo che le architetture di produzione devono gestire. AWS osserva che Kubernetes può segnalare il pod come pronto prima che Ray Serve risponda alle richieste. Il modello potrebbe essere ancora in caricamento dopo che il pod ha raggiunto quello stato.

Una prima richiesta rifiutata è accettabile in una dimostrazione, ma è rischiosa dietro traffico di produzione. I team dovrebbero collegare la readiness alla disponibilità dell'applicazione, non solo allo stato del container. La probe dovrebbe continuare a non avere successo finché il modello e l'endpoint non sono in grado di servire richieste reali.

I download dei modelli aggiungono un'altra variabile. La dimostrazione scarica il modello quando l'applicazione si inizializza, operazione che dipende dalla disponibilità esterna e dalla velocità di rete. I team di produzione possono usare storage locale, object storage o un layer dell'immagine per controllare il comportamento di avvio.

Anche i segreti richiedono una gestione separata. Una ConfigMap non dovrebbe contenere token di accesso o credenziali private. Kubernetes Secrets, EKS Pod Identity o un altro sistema di gestione dei segreti approvato dovrebbero fornire l'autenticazione necessaria.

Queste decisioni mostrano ciò che il DLC semplifica davvero. Standardizza la base software e fornisce un ambiente di esecuzione testato. Non decide come un'organizzazione gestisca modelli, segreti, artefatti di rilascio o esposizione del servizio.

La demo su una singola GPU è un punto di partenza, non un verdetto sulla produzione

Un pod su una GPU dimostra il percorso di deployment, ma non stabilisce affidabilità, efficienza o scalabilità in produzione.

AWS mantiene deliberatamente ridotta l'architettura di riferimento. Il cluster EKS dispone di un nodo GPU gestito basato su un'istanza g5.xlarge. Un pod utilizza la GPU NVIDIA A10G del nodo e un processo Ray Serve espone l'endpoint del modello.

Questa configurazione è utile per i test di migrazione. Un team può tradurre un handler, verificare il comportamento delle risposte, confrontare gli output e confermare l'accesso alla GPU senza dover prima progettare un cluster distribuito. Inoltre, rende i guasti più facili da isolare.

La stessa semplicità limita le conclusioni che i lettori dovrebbero trarre. L'esempio non mostra repliche ridondanti, parallelismo del modello su più nodi, autoscaling guidato dal traffico o ripristino dai guasti tra zone di disponibilità. Non pubblica neppure risultati comparativi di latenza o throughput.

Senza queste misurazioni, il post non può dimostrare che Ray Serve supererà uno specifico deployment TorchServe. Le prestazioni dipendono dal modello, dalla forma dell'input, dalla concorrenza, dal batching, dalla GPU, dal percorso di pre-elaborazione e dalle impostazioni di generazione. I team di migrazione hanno bisogno di test rappresentativi propri.

L'architettura contiene inoltre un singolo punto di guasto del servizio. Se il pod si riavvia o il nodo GPU diventa indisponibile, l'endpoint smette di rispondere finché Kubernetes non lo ripristina. Un servizio di produzione richiede normalmente repliche aggiuntive o un obiettivo di ripristino definito.

La scalabilità del design introduce KubeRay, l'operatore Kubernetes consigliato per la gestione dei cluster Ray. Le linee guida per il deployment su Kubernetes di Ray descrivono una risorsa personalizzata RayService che combina una configurazione di cluster Ray con un'applicazione Serve.

KubeRay può gestire pod head e worker, aggiornamenti dell'applicazione e ciclo di vita del cluster. Supporta inoltre risorse di calcolo eterogenee e autoscaling. Queste funzionalità rendono Ray Serve più rilevante per pipeline multi-modello o servizi che devono espandersi su più nodi.

Aggiungono però anche concetti operativi. I team devono comprendere il Ray head, i worker, il controller Serve, le dichiarazioni delle risorse, le risorse personalizzate Kubernetes e più livelli di log. Il troubleshooting può attraversare sia i control plane di Kubernetes sia quelli di Ray.

Questo compromesso conta nel confronto tra alternative. Un team che serve un singolo modello transformer potrebbe valutare un endpoint vLLM standalone. Un'organizzazione con più formati di modello potrebbe prendere in considerazione NVIDIA Triton Inference Server. I team centrati su Kubernetes potrebbero valutare KServe per risorse di inferenza standardizzate.

Queste opzioni risolvono problemi sovrapposti, ma le loro priorità differiscono. Ray Serve pone l'accento sulla composizione di applicazioni Python, l'esecuzione distribuita, le repliche, il routing e la scalabilità. TorchServe ha incentrato la propria esperienza sul packaging e sul serving di modelli PyTorch.

La stessa AWS documenta altri percorsi di serving. Le sue attuali linee guida di inferenza per EKS utilizzano un Deep Learning Container vLLM per un deployment LLM. Ciò conferma che il DLC Ray Serve è uno schema supportato, non un sostituto universale.

La scelta giusta dipende dal carico di lavoro. Un servizio vision-language con pre-elaborazione personalizzata può trarre vantaggio dalla composizione nativa in Python di Ray Serve. Un endpoint standardizzato per la generazione di testo potrebbe privilegiare un motore ottimizzato specificamente per i modelli linguistici di grandi dimensioni.

La valutazione della migrazione dovrebbe iniziare dalla parità dell'interfaccia. I team devono confrontare schemi delle richieste, risposte di errore, endpoint di health, autenticazione e timeout dei client. Dovrebbero poi convalidare gli output del modello rispetto a un set di test controllato.

I test di carico devono seguire. Gli ingegneri dovrebbero misurare il tempo di cold start, il tempo alla prima risposta, la latenza a regime, il throughput, la memoria GPU e il comportamento sotto picchi di traffico. I test dovrebbero includere la stessa configurazione di pre-elaborazione e generazione usata in produzione.

I test dei guasti sono altrettanto importanti. I team dovrebbero terminare il pod, drenare il nodo, interrompere l'accesso al modello e distribuire una revisione dell'applicazione non valida. Questi test rivelano se il sostituto soddisfa le aspettative di ripristino e rollback.

L'osservabilità richiede una mappatura diretta. Le metriche e le dashboard TorchServe esistenti non verranno trasferite inalterate. Gli operatori devono decidere quali metriche di Ray, dell'applicazione, di Kubernetes e della GPU definiscono salute, saturazione e degrado percepito dagli utenti.

Infine, i team hanno bisogno di un esperimento di aggiornamento. Dovrebbero passare tra due versioni DLC in un ambiente di staging e registrare le modifiche necessarie a codice, configurazione e modello. Il supporto ha valore limitato se gli aggiornamenti di routine restano troppo rischiosi da distribuire.

Cosa dovrebbero monitorare ora gli utenti TorchServe

Il prossimo test è capire se AWS può trasformare un chiaro esempio di migrazione in un percorso affidabile per release e scalabilità.

Il primo segnale è la cadenza di rilascio del DLC Ray Serve. I team dovrebbero monitorare tag delle immagini documentati, versioni dei framework, combinazioni CUDA, aggiornamenti di sicurezza e policy di ritiro. Release prevedibili rafforzerebbero la tesi di AWS secondo cui l'immagine riduce il lavoro di manutenzione a lungo termine.

Le note di rilascio contano quanto la frequenza delle release. Gli operatori devono sapere quali dipendenze sono cambiate e se un aggiornamento introduce comportamenti incompatibili. Hanno inoltre bisogno di una sovrapposizione sufficiente tra i tag supportati per effettuare i test prima di adottare una nuova immagine.

Il secondo segnale riguarda le linee guida di produzione per readiness, caricamento dei modelli e ripristino dai guasti. L'esempio attuale riconosce che il pod può apparire pronto prima che Ray Serve risponda. Un riferimento più solido dovrebbe allineare la readiness di Kubernetes a un modello caricato e a un endpoint reattivo.

Queste linee guida dovrebbero coprire anche lo storage dei modelli e il comportamento di avvio. Scaricare i pesi durante l'inizializzazione funziona per una piccola dimostrazione. Deployment più grandi richiedono caricamenti ripetibili, credenziali controllate, storage adatto e probe di avvio dimensionate per il warmup reale del modello.

Il terzo segnale è un percorso supportato da una GPU a più repliche o nodi. AWS indirizza i lettori verso KubeRay per serving distribuito e scalabilità orizzontale. Gli esempi futuri dovrebbero mostrare come il DLC si comporta all'interno di un deployment RayService.

Un riferimento con più repliche dovrebbe documentare routing del traffico, aggiornamenti progressivi, segnali di autoscaling e ripristino quando un worker GPU scompare. Dovrebbe inoltre separare i carichi di lavoro Ray head dai worker di inferenza GPU, preservando la costosa capacità degli acceleratori per i modelli.

I team non dovrebbero attendere ogni riferimento prima di iniziare una valutazione. Possono già inventariare i servizi TorchServe e ordinarli per esposizione, importanza per il business e difficoltà di migrazione. Gli endpoint esposti a Internet meritano attenzione prima dei sistemi batch isolati.

Per ciascun servizio, gli ingegneri possono elencare le funzionalità TorchServe attualmente in uso. Ciò include archivi di modelli, handler personalizzati, workflow, batching, metriche, API di gestione e file di configurazione. L'inventario diventa una checklist concreta per la migrazione a Ray Serve.

Una piccola proof of concept dovrebbe preservare l'attuale contratto di richieste e risposte. Mantenere invariati i client isola la migrazione del layer di serving da una più ampia riscrittura dell'applicazione. Consente inoltre un confronto controllato del traffico tra i vecchi e i nuovi endpoint.

La valutazione dovrebbe utilizzare gli stessi pesi del modello e input rappresentativi. I team possono confrontare coerenza degli output, latenza, throughput, utilizzo della GPU e comportamento degli errori. Dovrebbero inoltre registrare quanto tempo impiega ciascun servizio a riprendersi dopo un riavvio.

I team di sicurezza dovrebbero esaminare l'immagine risultante come artefatto completo. La base AWS può ricevere dipendenze testate e patch applicate in fase di build, ma i pacchetti aggiunti localmente possono reintrodurre vulnerabilità. La scansione deve continuare dopo la personalizzazione.

I responsabili della piattaforma dovrebbero inoltre definire le responsabilità prima della migrazione. AWS mantiene il DLC, Ray mantiene Ray Serve e l'organizzazione gestisce la propria applicazione e il deployment EKS. Confini chiari impediscono che un componente supportato venga scambiato per un servizio end-to-end supportato.

La lezione più ampia non è che ogni utente TorchServe debba adottare Ray Serve. È che un layer di serving non più mantenuto richiede ora una decisione esplicita. Restare dove si è, migrare a Ray Serve o scegliere un altro server crea ogni volta un diverso modello di supporto.

I Deep Learning Containers Ray Serve di AWS rendono una di queste scelte più concreta. Il nuovo esempio fornisce una base testata, un modello di programmazione diretto e un deployment EKS funzionante su una singola GPU. Rende inoltre visibili le responsabilità rimanenti.

Iniziate con un servizio TorchServe rappresentativo e testate la migrazione con schemi di traffico reali. Se il DLC riduce il lavoro sulle dipendenze senza indebolire la disponibilità, merita un rollout più ampio. Se il layer operativo di Ray supera questo vantaggio, il test lo rivelerà tempestivamente.