Riepilogo Tecnico: STREAM – Middleware di Inferenza LLM Multi-Tier con Streaming di Token Dual-Channel per HPC

Definizione del Problema

Ricercatori e professionisti si trovano di fronte a un panorama frammentato per l'implementazione di Large Language Models (LLM), costretti a scegliere tra tre opzioni imperfette:

1. Inferenza Locale: Gratuita e privata, ma limitata dai vincoli hardware dell'utente (modelli più piccoli, finestre di contesto limitate).
2. HPC Istituzionale: Offre potenti risorse GPU a costo marginale nullo e mantiene i dati entro i confini istituzionali, ma opera dietro firewall che bloccano gli approcci di streaming standard e si affida a modelli di esecuzione batch privi di meccanismi per la consegna incrementale dell'output.
3. API Cloud Commerciali: Forniscono la qualità dei modelli di frontiera su richiesta, ma impongono costi significativi per token e politiche di conservazione dei dati non adatte alla ricerca sensibile.

Nessun sistema esistente unifica questi tre livelli, portando a uno spreco di budget cloud, a un sottoutilizzo delle risorse GPU istituzionali e a flussi di lavoro frammentati. Inoltre, le architetture di streaming standard falliscono negli ambienti HPC perché i nodi di calcolo si trovano dietro firewall istituzionali che bloccano tutte le connessioni in entrata, e le macchine client sono spesso dietro NAT, rendendole irraggiungibili senza VPN o modifiche alle regole del firewall.

Metodologia e Architettura del Sistema

STREAM (Smart Tiered Routing Engine for AI Models) agisce come uno strato middleware che unifica l'inferenza locale, HPC e cloud in un unico servizio a più livelli. Il sistema elabora ogni query attraverso una pipeline standardizzata:

1. Architettura di Routing a Tre Livelli

Le query vengono classificate da un Complexity Judge (un LLM locale, specificamente Llama 3.2 3B) in tre livelli:

• LOW (Basso): Instradata verso modelli locali (es. Llama 3.2 3B, Gemma 3 4B-VL) in esecuzione su dispositivi utente o server co-localizzati tramite Ollama.
• MEDIUM (Medio): Instradata verso risorse HPC istituzionali (es. Qwen 2.5-VL-72B-AWQ su GPU H100 NVL).
• HIGH (Alto): Instradata verso API cloud commerciali (es. tramite OpenRouter).
  Il sistema include un meccanismo di fallback in cui le query scalano o scendono di livello in base alla disponibilità e agli stati di errore, garantendo la continuità.

2. Streaming di Token HPC Dual-Channel

Per risolvere il problema dello streaming in HPC, STREAM introduce un'architettura innovativa che separa il Piano di Controllo dal Piano dei Dati:

• Piano di Controllo (Globus Compute): Gestisce l'autenticazione federata e il dispatch dei job. Invia un task contenente la query e i metadati, ma non trasporta i payload dei token.
• Piano dei Dati (WebSocket Relay): Un server relay basato su cloud funge da punto di incontro (rendezvous).
  • Producer: Il worker HPC (in esecuzione all'interno di un task Globus Compute) si connette in uscita al relay, legge lo stream SSE HTTP di vLLM token per token e li inoltra.
  • Consumer: Il client (o il proxy) si connette in uscita allo stesso canale con UUID unico sul relay per ricevere i token.
• Attraversamento del Firewall: Poiché entrambi gli endpoint avviano connessioni in uscita (wss:// sulla porta 443), l'architettura attraversa i firewall istituzionali e il NAT senza richiedere porte in entrata, VPN o modifiche alle regole del firewall.
• Sicurezza: Il sistema impiega la crittografia end-to-end AES-256-GCM. Le chiavi di crittografia e i segreti del canale sono pre-caricati nell'ambiente del worker e non vengono mai trasmessi come argomenti del task, garantendo che l'operatore del relay non possa leggere i payload dei token.

3. Riassunto del Contesto Consapevole del Livello (Tier-Aware)

Per evitare che le lunghe cronologie di conversazione costringano le query semplici a passare a livelli più costosi a causa dei limiti della finestra di contesto, STREAM implementa una compressione differenziale. Quando una conversazione si avvicina all'80% del limite di contesto di un livello, i messaggi più vecchi vengono compressi in un riassunto (usando il modello locale gratuito) mentre i turni recenti vengono mantenuti letteralmente. Ciò consente alle query semplici di rimanere sul livello locale anche dopo 40+ turni.

4. Modalità Proxy HPC-as-API

STREAM espone il livello HPC come un endpoint compatibile con OpenAI (/v1/chat/completions). Ciò consente alle applicazioni esterne di accedere all'inferenza HPC istituzionale senza richiedere agli utenti di gestire le credenziali Globus o implementare direttamente il protocollo di relay. Questa modalità è praticabile solo grazie alla riduzione della latenza a livelli sub-secondo fornita dallo streaming dual-channel.

Risultati Chiave

Il sistema è stato valutato su un benchmark di 1.200 query che copre dieci domini (HPC, matematica, fisica, ecc.) e misurato attraverso i livelli locale, HPC e cloud.

• Accuratezza del Routing: Il Complexity Judge Llama 3.2 3B ha raggiunto un'accuratezza complessiva del 49,0% (1,5× superiore al caso casuale) e una ritenzione del free-tier dell'85,1%, mantenendo con successo l'85% delle query sui livelli gratuiti locali o HPC. Il limite principale è stato la bassa recall per le query di complessità "LOW", che venivano spesso dirottate verso il livello "MEDIUM" (un errore conservativo, poiché entrambi sono gratuiti).
• Latenza (TTFT):
  • Locale: Mediana di 0,26 s per il Time-to-First-Token (TTFT).
  • HPC (Streaming): 0,54 s di TTFT mediano. Questo rappresenta un miglioramento di 21,1× rispetto alla modalità fallback batch (11,40 s), dove il TTFT equivale al tempo totale di generazione.
  • Cloud: 1,68 s di TTFT mediano.
• Throughput: Sia la modalità streaming HPC che quella batch hanno ottenuto lo stesso throughput di generazione (26,9 tok/s), confermando che il relay non aggiunge alcun overhead per token.
• Riassunto del Contesto: Nei test sintetici, la sintesi ha impedito l'upgrade forzato di livello per query semplici ("Quanto fa 2+2?") anche quando il contesto grezzo superava i 41K token (turno 40), mantenendo la query sul livello locale.

Significato e Rivendicazioni

Il paper afferma che STREAM è il primo sistema che unifica l'inferenza LLM locale, istituzionale (HPC) e cloud con un routing automatico basato sulla complessità. La sua importanza primaria risiede nella risoluzione del problema dello streaming HPC, consentendo la consegna dei token in tempo reale da dietro i firewall istituzionali senza necessità di VPN o modifiche ai firewall.

Riducendo il TTFT dell'HPC da 11,40 s a 0,54 s, STREAM rende pratico il pattern di deployment "HPC-as-API" per applicazioni interattive, un caso d'uso precedentemente impossibile a causa della latenza batch. Il sistema dimostra che le risorse GPU istituzionali possono essere rese accessibili quanto le API cloud, mantenendo al contempo la privacy dei dati e riducendo i costi. Gli autori osservano che STREAM è attualmente un prototipo di ricerca; il lavoro futuro prevede la sostituzione del judge basato su LLM con un classificatore di testo fine-tuned e la raccolta di tracce di routing da utenti reali. I componenti core (relay e proxy) sono rilasciati come librerie PyPI domain-agnostic (streamrelay e hpc-as-api).