Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models

Il paper presenta Cornserve, un sistema di serving distribuito open-source basato su Kubernetes che ottimizza l'esecuzione dei modelli multimodali "Any-to-Any" attraverso la disaggregazione dei componenti e un modello di esecuzione record-and-replay, ottenendo un aumento significativo del throughput e una riduzione della latenza.

L'essenziale

Immagina di dover organizzare un grande ristorante dove i clienti non ordinano solo un piatto, ma possono richiedere combinazioni incredibilmente complesse: "Voglio vedere un video, ascoltarne la colonna sonora, leggere una recensione scritta e poi farvi generare una nuova immagine basata su tutto questo".

Nel mondo dell'intelligenza artificiale, questi sono i modelli "Any-to-Any" (Qualsiasi-a-Qualsiasi). Possono leggere, vedere, ascoltare e creare qualsiasi cosa.

Il problema? I sistemi attuali per far funzionare questi modelli sono come cucine tradizionali: un unico grande chef (il modello) che deve fare tutto da solo. Se il cliente chiede solo un testo, lo chef spreca tempo a preparare gli ingredienti per un video che non serve. Se chiede un video, lo chef si blocca perché non ha abbastanza mani per fare tutto contemporaneamente.

Cornserve è la soluzione proposta in questo paper. È un nuovo sistema per gestire questi modelli, e funziona come un ristorante a gestione intelligente e modulare. Ecco come funziona, spiegato con parole semplici:

1. La Cucina a Stazioni (Scomposizione del Modello)

Invece di avere un unico chef gigante, Cornserve divide il modello in piccole stazioni specializzate:

• Una stazione per leggere le immagini (Encoder Immagini).
• Una per ascoltare l'audio (Encoder Audio).
• Una per pensare e scrivere (Il "Cervello" o LLM).
• Una per creare nuovi video o suoni (Generatore).

Ogni stazione ha il suo cuoco specializzato (una GPU dedicata) che fa solo quel lavoro. Se un cliente chiede solo un testo, la stazione video rimane a riposo, risparmiando energia e risorse. Se chiede un video, la stazione video lavora al massimo, mentre il cervello pensa velocemente.

2. Il "Menu" Flessibile (Task Abstraction)

I creatori di questi modelli possono scrivere le istruzioni per il ristorante in un linguaggio semplice (Python), come se stessero scrivendo una ricetta. Possono dire: "Se l'utente carica una foto, mandala alla stazione foto, poi al cervello. Se l'utente chiede anche un audio, manda il risultato al generatore audio".
È come se il ristorante potesse adattare il suo flusso di lavoro istantaneamente in base a ciò che il cliente ordina, senza dover ricostruire l'intera cucina ogni volta.

3. Il Corriere Segreto (Record-and-Replay)

Qui c'è la parte più magica. Quando arriva un ordine complesso, il sistema fa due cose velocissime:

1. Registra (Record): Simula l'ordine per capire esattamente quali stazioni devono lavorare e in quale ordine, senza cucinare davvero nulla. È come se il cameriere scrivesse sul taccuino: "Ok, prima la foto, poi il testo, poi l'audio".
2. Riproduce (Replay): Una volta capito il percorso, lancia tutti i cuochi specializzati contemporaneamente.

Invece di passare i piatti da una stanza all'altra attraverso un corridoio lento (la rete di controllo), i cuochi si passano gli ingredienti direttamente tramite un tunnel segreto ad alta velocità (memoria condivisa e RDMA). È come se avessero un tubo pneumatico tra le stazioni: il dato vola da un cuoco all'altro in un batter d'occhio.

4. Il Risultato: Più Veloce e Più Efficiente

Grazie a questo sistema, il paper dimostra che:

• Velocità: Il ristorante serve fino a 3,8 volte più clienti nello stesso tempo rispetto ai metodi vecchi.
• Tempi di attesa: I clienti aspettano fino a 5,8 volte meno per ricevere il loro piatto (riduzione della latenza).
• Risparmio: Se due ristoranti diversi usano lo stesso "cuoco per le foto", Cornserve fa in modo che usino lo stesso cuoco, risparmiando spazio e soldi.

In Sintesi

Cornserve è come trasformare un'autostrada a una sola corsia (dove tutti i modelli devono passare uno alla volta) in un sistema di trasporto pubblico intelligente, dove ogni passeggero (ogni richiesta) prende il treno, l'autobus o l'aereo giusto in base alla sua destinazione, e tutti viaggiano in parallelo senza intasarsi a vicenda.

È un sistema che rende possibile far funzionare i modelli di intelligenza artificiale più complessi e futuristici, rendendoli veloci, economici e pronti per il mondo reale.

Sommario tecnico

Ecco un riepilogo tecnico dettagliato del paper "Cornserve: A Distributed Serving System for Any-to-Any Multimodal Models", strutturato secondo le richieste.

1. Il Problema: Eterogeneità dei Modelli Any-to-Any

I modelli Any-to-Any rappresentano una nuova classe di modelli multimodali in grado di accettare combinazioni di dati (testo, immagine, video, audio) come input e generare output multimodali. Il servizio (serving) di questi modelli presenta sfide uniche rispetto ai tradizionali LLM testuali:

• Eterogeneità dei Percorsi di Calcolo: A differenza dei modelli monolitici, i modelli Any-to-Any sono grafi computazionali eterogenei. A seconda della combinazione di input e output richiesta (es. testo+immagine in ingresso, audio in uscita), il modello percorre percorsi diversi, attivando componenti specifici (encoder, LLM, generatori) in sequenze variabili.
• Eterogeneità delle Caratteristiche di Scalabilità: I diversi componenti dello stesso modello hanno requisiti di risorse e caratteristiche di scalabilità drasticamente diverse. Ad esempio, nel modello Qwen 2.5 Omni, il componente di generazione del testo può avere una throughput 4 volte superiore rispetto al generatore audio sulla stessa GPU.
• Limitazioni delle Soluzioni Esistenti: I sistemi attuali (come vLLM per i LLM o xDiT per la diffusione di immagini) offrono soluzioni puntuali per casi specifici. Non esistono sistemi distribuiti generici capaci di gestire grafi computazionali arbitrari con componenti disaggregati e scalabili indipendentemente.

2. Metodologia: Architettura di Cornserve

Cornserve è un sistema di serving distribuito progettato per gestire modelli Any-to-Any generici. È costruito su Kubernetes e scritto in circa 23.000 righe di Python. L'architettura si basa su tre pilastri fondamentali:

A. Astrazione del Task Flessibile

Cornserve introduce un modello di programmazione a tre livelli per esprimere grafi computazionali complessi in Python puro:

1. Unit Task: Rappresenta un componente atomico (es. EncoderTask, LLMTask, GeneratorTask).
2. Composite Task: Una classe che compone i task unitari e definisce la logica di calcolo nel metodo invoke.
3. App: Un modulo Python che istanzia i task e definisce il punto di ingresso asincrono (serve).
   Questa astrazione permette agli sviluppatori di definire la logica di inferenza (inclusi cicli e ramificazioni) senza preoccuparsi dell'infrastruttura sottostante.

B. Fissione del Modello (Model Fission)

Il sistema permette di "fissionare" (spezzare) un modello ai confini dei suoi componenti. Ogni componente può essere distribuito su GPU dedicate ed eseguito da executor specializzati:

• Eric: Per encoder multimodali (immagine, video, audio).
• vLLM modificato: Per l'inferenza LLM.
• Geri: Per generatori multimodali (vocoder audio, DiT per immagini).
  Inoltre, Cornserve supporta la condivisione automatica dei componenti: se più app utilizzano lo stesso encoder (es. un encoder visivo condiviso), il sistema ne deploya un'unica istanza condivisa, riducendo l'uso delle GPU.

C. Runtime Distribuito con Record-and-Replay

Per gestire la complessità dei percorsi di calcolo dinamici, Cornserve utilizza un modello di esecuzione a due fasi:

1. Fase di Registrazione (Record): Il task composito viene eseguito con i dati di input, ma i task unitari restituiscono risultati segnaposto (placeholder). Durante questa fase, il sistema traccia le dipendenze dei dati e ricostruisce il sottografo di esecuzione specifico per quella richiesta. Non viene eseguita alcuna computazione reale del modello.
2. Fase di Riproduzione (Replay): Il sistema invia il grafo registrato al dispatcher, che invia le chiamate ai Task Executor appropriati. Durante la seconda esecuzione del task composito, i task unitari restituiscono i risultati reali ottenuti dal dispatcher.

D. Trasferimento Dati Efficiente

Per evitare colli di bottiglia nella comunicazione tra componenti disaggregati:

• Intra-nodo: Utilizza memoria condivisa Linux (/dev/shm) per trasferire tensori direttamente dalla memoria GPU del produttore a quella del consumatore, bypassando la CPU e minimizzando l'interferenza con NVLink.
• Inter-nodo: Utilizza RDMA tramite la libreria UCX per trasferimenti ad alta velocità tra nodi.
  Un processo Sidecar per GPU gestisce il forwarding dei dati, permettendo ai componenti di attendere i tensori intermedi senza bloccare il piano di controllo.

3. Risultati Sperimentali

Gli autori hanno valutato Cornserve utilizzando modelli Qwen Omni (2.5 e 3) su nodi con GPU NVIDIA A100-80GB, confrontandoli con un deployment monolitico basato su Hugging Face Transformers.

• Throughput:
  • Per Qwen 2.5 Omni, Cornserve ha migliorato il throughput fino a 3,81× rispetto al deployment monolitico (su configurazioni a 16 GPU).
  • Per Qwen 3 Omni, il deployment monolitico ha fallito per mancanza di memoria GPU (OOM), mentre Cornserve ha permesso il servizio grazie alla fissione del modello e alla scalabilità indipendente dei componenti.
  • Lo scaling da 8 a 16 GPU ha portato a un miglioramento del throughput di 2,68×, superando la scalabilità lineare attesa (2×) grazie a un migliore bilanciamento del carico tra i componenti eterogenei.
• Latenza:
  • La latenza tail (P99) è stata ridotta fino a 5,79×.
  • I benefici derivano dalla rimozione dell'interferenza tra componenti (in un modello monolitico, quando un componente è attivo, gli altri sono fermi) e dall'abilitazione del continuous batching per i generatori audio, cosa difficile da implementare in architetture monolitiche.
• Overhead: L'overhead introdotto dai Sidecar per il trasferimento dati è minimo (5-27 ms per tensori da 8-32 MB), non costituendo un collo di bottiglia significativo.

4. Contributi Chiave

1. Primo Sistema Generico: Cornserve è il primo sistema di serving distribuito progettato specificamente per modelli Any-to-Any generici, supportando grafi computazionali arbitrari.
2. Astrazione e Fissione: Introduce un'astrazione del task in Python che permette la fissione del modello in componenti indipendentemente scalabili, ottimizzando l'uso delle risorse hardware.
3. Esecuzione Record-and-Replay: Un meccanismo innovativo per gestire la dinamica dei percorsi di inferenza senza sacrificare l'efficienza o la semplicità di sviluppo.
4. Open Source: Il sistema è open-source e include un piano di osservabilità basato su OpenTelemetry per il tracciamento end-to-end delle richieste.

5. Significato

Cornserve rappresenta un passo fondamentale verso l'adozione pratica di modelli multimodali complessi. Risolvendo il problema dell'eterogeneità dei percorsi di calcolo e delle risorse, permette di:

• Sfruttare al meglio l'hardware GPU, adattando la scalabilità a ogni singolo componente del modello.
• Abilitare lo sviluppo di modelli Any-to-Any più potenti ed efficienti, che altrimenti sarebbero intrattabili con le infrastrutture di serving attuali.
• Fornire una base solida per la ricerca futura nell'ottimizzazione del serving di modelli multimodali, spostando il focus dall'ottimizzazione monolitica a quella distribuita e modulare.