The Pulse
llm-d 1.0, sostenuto da IBM, punta a un servizio dei modelli pronto per la produzione
Secondo IBM, llm-d 1.0 è progettato per aiutare le organizzazioni a eseguire l’inferenza dell’IA sulla propria infrastruttura, gestendo le richieste di persone e agenti autonomi. In un test su un carico di lavoro di programmazione basato su
AI.info Team · Scritto con l’IA · verificato ·
Chi usa un assistente alla programmazione si aspetta una risposta rapida; un agente autonomo può inviare una raffica di richieste, fermarsi per usare uno strumento e poi tornare con altre richieste. llm-d 1.0, sostenuto da IBM e annunciato il 20 ottobre alla PyTorch Conference North America, è progettato per gestire entrambi i tipi di traffico su un’infrastruttura condivisa. La nuova versione pone l’accento su ciò che accade dopo la distribuzione: mantenere il servizio reattivo mentre cambiano i carichi di lavoro, gli utenti competono per le risorse e gli operatori aggiornano il software.
Persone e agenti competono per le stesse GPU
Secondo IBM, llm-d 1.0 aggiunge il supporto alla qualità del servizio in ambienti multi-tenant, alle operazioni senza interruzioni del servizio e all’erogazione che tiene conto degli agenti. Il controllo dei flussi e la definizione delle priorità delle richieste mirano a impedire che le raffiche prodotte dai carichi di lavoro degli agenti sovraccarichino i servizi che richiedono una bassa latenza. Il framework può inoltre continuare a indirizzare le richieste di una sessione con più scambi verso l’infrastruttura che conserva il contesto pertinente nella cache, anziché inviarle ripetutamente a una replica che deve ricalcolarlo.
La distinzione conta perché gli agenti tornano spesso sugli stessi codici, documenti e istruzioni nel corso di più chiamate al modello. L’instradamento che tiene conto dei prefissi nella cache indirizza le richieste verso repliche che potrebbero già conservare quel contesto; il trasferimento della cache KV sposta le informazioni memorizzate nella cache tra GPU, CPU e risorse di archiviazione quando la memoria delle GPU è limitata. IBM presenta queste tecniche come parte di un sistema di erogazione più ampio, non come nuove funzionalità inventate per la versione 1.0.
La versione 1.0 si concentra sulla gestione operativa del sistema
Il lavoro precedente del progetto comprende l’ottimizzazione dell’inferenza in batch, la disaggregazione di prefill e decode, che separa l’elaborazione dei prompt dalla generazione del testo, e il parallelismo degli esperti su larga scala per distribuire i modelli mixture-of-experts tra gli acceleratori. Secondo IBM, la nuova versione integra questi approcci con controlli operativi per l’uso in produzione. Tra questi figurano un’API stabile e la capacità di mantenere attivo il servizio durante gli aggiornamenti software, i problemi hardware e le variazioni del traffico, senza affidarsi a un unico benchmark delle prestazioni.
«llm-d è pronto per le operazioni del secondo giorno», ha dichiarato Carlos Costa, ingegnere di alto livello presso IBM Research, cofondatore di llm-d e responsabile principale della manutenzione del progetto.
IBM definisce «secondo giorno» il lavoro necessario a gestire un servizio di IA dopo la sua distribuzione iniziale, compresi il bilanciamento delle priorità concorrenti e il mantenimento dell’affidabilità. La versione è destinata alle organizzazioni che gestiscono la propria infrastruttura, con un’architettura indipendente dai fornitori che supporta diversi modelli, acceleratori e cloud.
IBM cita il riutilizzo della cache e la riduzione dei costi di erogazione
Secondo IBM, in un recente test su un carico di lavoro di programmazione basato su agenti, il sistema di instradamento di llm-d che tiene conto dei prefissi ha sfruttato il 97% delle possibilità di riutilizzo della cache. In una dimostrazione separata, IBM e Red Hat hanno eseguito contemporaneamente 3.000 agenti di ingegneria del software su un’installazione gestita sulla propria infrastruttura. Secondo IBM, il costo di quella configurazione era da cinque a 10 volte inferiore al prezzo effettivo dell’erogazione dello stesso modello aperto come servizio.
Queste cifre sono esempi forniti da IBM per carichi di lavoro specifici, non una garanzia generale sui costi per ogni installazione. L’articolo di ricerca non specifica l’hardware usato nei test né una metodologia dettagliata per nessuno dei due confronti. I risultati illustrano comunque la tesi centrale della nuova versione: indirizzare le richieste in modo da riutilizzare il contesto e gestire le risorse di calcolo condivise può incidere sul costo di esecuzione degli agenti, non solo sulla velocità con cui un modello genera una risposta.
llm-d collega i server dei modelli a Kubernetes
llm-d funziona con motori di inferenza tra cui vLLM e SGLang, aggiungendo funzionalità di instradamento distribuito e di gestione operativa ai server che eseguono i modelli. La Cloud Native Computing Foundation ospita il progetto nella propria sandbox, mentre IBM, Red Hat e Google ne sono i principali responsabili della manutenzione. Questo colloca llm-d come livello intermedio tra il software di erogazione dei modelli e l’infrastruttura basata su Kubernetes, dove le organizzazioni possono coordinare le repliche e il traffico di un’installazione.
Per i team che valutano di gestire l’inferenza sulla propria infrastruttura, la promessa della versione 1.0 è più circoscritta di un risparmio automatico: offre un modo più maturo sul piano operativo per gestire carichi di lavoro diversi su un’infrastruttura condivisa. La prova pratica sarà verificare se questi controlli mantengono la reattività e il riutilizzo della cache con il traffico, l’hardware e le priorità di servizio di ciascuna organizzazione.