La guida pratica all’hosting autonomo di sistemi LLM composti
Ospitato durante la SF #TechWeek, il meetup mensile di Zilliz “Unstructured Data Meetup” ha attirato oltre 800 builder, founder e VC per discutere gli ultimi sviluppi nell’ecosistema dell’AI. Il secondo intervento, tenuto da Chaoyu Yang (Founder/CEO di BentoML), ha fornito consigli pratici per chi preferisce il controllo e la personalizzazione del self-hosting dei large language models (LLMs) cercando al contempo di ottenere le prestazioni del semplice utilizzo di un’API gestita. BentoML condivide i propri insight di ricerca nell’orchestrazione dell’AI, dimostrando soluzioni sviluppate per ottimizzare i problemi di prestazioni comuni quando si ospitano modelli in self-hosting.
In questo post, riepilogheremo i punti chiave dell’intervento di Chaoyu e discuteremo le principali sfide, considerazioni e pratiche per ospitare i tuoi LLM in self-hosting. Esploreremo anche come integrare BentoML e Milvus per creare applicazioni GenAI più potenti.
Il LLM Doom Stack
Essendo relativamente nuovo all’AI, ho trovato più semplice comprendere BentoML e Milvus nel contesto del moderno stack LLM. Senza un ordine particolare—solo perché suona bene—esploriamo quello che chiamo lo 'LLM DOOM Stack.'
Dati: Preparazione, archiviazione ed elaborazione di set di dati su larga scala per training e inferenza di alta qualità. Tali tecnologie includono pipeline di dati, embedding models e vector databases (come Zilliz/Milvus, woo!)
Operazioni: Monitoraggio, scalabilità e mantenimento dello stato e delle prestazioni dei modelli distribuiti. Osservabilità in tempo reale per il debugging attivo e per mantenere l’affidabilità.
Orchestrazione: Distribuzione e scalabilità dei modelli attraverso l’infrastruttura, gestendo il flusso tra LLM, sistemi esterni e utenti. (Qui è dove BentoML svolge un ruolo chiave.)
Modelli AI: Il cuore delle app LLM—training, fine-tuning e ottimizzazione dei modelli per compiti specifici, che si usino API, modelli open-source o pre-addestrati.
Figura- The LLM Doom Stack.png
Figura: The LLM Doom Stack (adattato da questa immagine.)
Ogni startup di infrastrutture AI rientra in questo framework DOOM. Milvus e il suo servizio cloud gestito, Zilliz Cloud, sono database vettoriali costruiti per archiviare, indicizzare e recuperare dati non strutturati in rappresentazioni numeriche chiamate embedding vettoriali in uno spazio ad alta dimensionalità. Sono componenti fondamentali di vari sistemi basati su LLM, in particolare la retrieval augmented generation (RAG). BentoML fornisce ottimizzazioni operative per gli attuali flussi di lavoro LLM. Prendendo in prestito concetti che si sono dimostrati efficaci nei sistemi operativi e combinandoli con ricerche supportate dai dati, BentoML ha dimostrato di offrire prestazioni superiori per la creazione e la distribuzione di LLM—e il suo Founder, Chaoyu, ne ha condiviso i segreti in questo intervento.
Il dilemma degli LLM: self-hosting o semplicemente chiamare l’API?
Una delle decisioni più critiche quando si distribuiscono LLM è se ospitarli in self-hosting o affidarsi ad API gestite. Entrambe le opzioni comportano i propri compromessi, rendendo essenziale soppesare la comodità rispetto al controllo. Le API gestite sono interessanti per la loro facilità d’uso, il minore onere di manutenzione e la rapida capacità di scalare, mentre il self-hosting offre pieno controllo e flessibilità, consentendo una personalizzazione più profonda. In definitiva, per la maggior parte dei team la decisione si riduce al bilanciamento tra velocità di deployment nel breve termine e obiettivi di scalabilità e prestazioni nel lungo termine.
Figura- Vantaggi e sfide del self-hosting degli LLM.png
Figura: Vantaggi e sfide del self-hosting degli LLM
Chi dovrebbe ospitare autonomamente gli LLM?
Chaoyu ha iniziato il suo intervento con un rapido sondaggio sugli LLM gestiti rispetto a quelli self-hosted. La maggior parte dei partecipanti ha alzato la mano per le API gestite, e comprensibilmente—Costruire, scalare e mantenere l’infrastruttura mentre si sviluppa contemporaneamente la propria applicazione non è un compito facile.
Chaoyu ha sottolineato che i servizi gestiti, pur essendo comodi, spesso danno priorità al throughput rispetto all’ottimizzazione per casi d’uso specifici. Il self-hosting, invece, consente il fine-tuning personalizzato dei modelli, strategie di inferenza avanzate e qualità e latenza prevedibili.
Tuttavia, il self-hosting non è la scelta giusta per tutti. Quindi, chi dovrebbe esattamente prendere in considerazione il self-hosting degli LLM? Ecco i motivi principali per esplorare questo approccio:
Figura- Chi dovrebbe ospitare autonomamente gli LLM? .png
Figura: Chi dovrebbe ospitare autonomamente gli LLM?
Controllo: Il self-hosting consente di eseguire gli LLM secondo le proprie condizioni, rispettando la sicurezza dei dati, le normative sulla privacy e le esigenze organizzative specifiche. Questo è particolarmente vero per i settori con requisiti rigorosi di protezione dei dati, dove i dati sensibili non possono lasciare la tua infrastruttura.
Personalizzazione: Con il self-hosting, puoi eseguire il fine-tuning dei modelli e ottimizzare le strategie di inferenza per il tuo caso d’uso specifico, ottenendo prestazioni, velocità e accuratezza migliori rispetto a quanto possano offrire le API gestite. Ottieni anche la flessibilità di sperimentare tecniche di inferenza avanzate come la decodifica Chain of Thought (CoT) o Equilibrium Search, possibili solo con il pieno controllo del livello di inferenza.
Vantaggi di costo a lungo termine: Sebbene il self-hosting possa comportare costi iniziali più elevati in termini di infrastruttura e manutenzione, può offrire risparmi sui costi nel lungo periodo. Puoi ottimizzare i costi nel tempo e scalare sfruttando piattaforme open-source come BentoML e OpenLLM senza rimanere vincolato ai modelli di prezzo dei fornitori.
Sfide chiave e ottimizzazioni per il self-hosting degli LLM
Il self-hosting degli LLM offre un maggiore controllo, ma comporta una serie di sfide tecniche, in particolare per quanto riguarda la scalabilità, l’ottimizzazione dell’inferenza e il problema del cold start. BentoML offre una suite di soluzioni per affrontare questi problemi, consentendo ai team di ottimizzare le proprie distribuzioni in modo efficiente. Chaoyu ha condiviso gli approcci principali che hanno utilizzato per affrontare tali sfide.
Ottimizzazione dell’inferenza
Quando si ospitano autonomamente gli LLM, ottimizzare l’inferenza è fondamentale per migliorare le prestazioni e ridurre i costi. Chaoyu ha evidenziato diverse tecniche chiave:
Figura- Ottimizzazione dell’inferenza degli LLM- Gli stack della tabella.png
Figura: Ottimizzazione dell’inferenza degli LLM: Gli stack della tabella
Batching delle richieste
Come una delle strategie più incisive, il batching delle richieste può aumentare il throughput fino a 23 volte. Elaborando più richieste in parallelo anziché in sequenza, puoi massimizzare l’utilizzo delle risorse GPU, riducendo i tempi di inattività e migliorando l’efficienza, soprattutto per applicazioni ad alto traffico.
Streaming dei token
Un’altra ottimizzazione essenziale è lo streaming dei token, che restituisce i token in modo incrementale man mano che vengono generati. Questo approccio migliora significativamente la latenza percepita, in particolare nelle applicazioni in tempo reale come i chatbot, dove tempi di risposta più rapidi migliorano l’esperienza utente.
Quantizzazione
Inoltre, la quantizzazione riduce l’utilizzo della memoria e la latenza dell’inferenza riducendo la precisione del modello (ad esempio, da 32 bit a 8 bit). Sebbene questo approccio possa causare una lieve riduzione della qualità dell’output per determinate attività, il compromesso vale la pena per i guadagni in termini di prestazioni.
Ottimizzazioni del kernel
L'ottimizzazione a livello di kernel consente ottimizzazioni GPU di basso livello adattate ai carichi di lavoro degli LLM, garantendo che le attività computazionali siano gestite nel modo più efficiente possibile. Tuttavia, queste ottimizzazioni possono ridurre la portabilità tra diverse piattaforme hardware.
Parallelismo del modello
Per modelli estremamente grandi (oltre 70B parametri), distribuire il carico di lavoro su più GPU consente un'inferenza più efficiente. Sebbene ciò migliori il throughput, introduce un certo overhead di comunicazione tra le GPU.
Scalare l'inferenza degli LLM: autoscaling basato sulla concorrenza
Una sfida comune negli ambienti self-hosted è la gestione della scalabilità. Le metriche di scaling tradizionali come l'utilizzo di CPU/GPU e le query al secondo (QPS) sono insufficienti per gli LLM, che hanno richieste di risorse variabili a seconda della complessità dell'input.
Chaoyu ha spiegato che lo scaling basato sulla concorrenza è un approccio più efficace. Questo metodo monitora il numero di richieste concorrenti per determinare il carico del sistema e regola dinamicamente le risorse in base alla dimensione del batch. Questo metodo garantisce che il sistema scali esattamente quando necessario, prevenendo l'over-provisioning e riducendo i costi, mantenendo al contempo prestazioni elevate durante i picchi di traffico.
Caching dei prefissi per risparmiare sui costi
Uno dei modi più efficaci per ridurre i costi e migliorare le prestazioni negli ambienti self-hosting è tramite il caching dei prefissi, che può portare a risparmi sui costi superiori al 90%. Questa strategia funziona memorizzando nella cache le parti comuni dei prompt, come le istruzioni di sistema o i contenuti statici, per evitare calcoli ridondanti.
Caricando anticipatamente le informazioni statiche all'inizio delle richieste, aumenti la probabilità di cache hit, riducendo il carico computazionale per le richieste successive con strutture simili. Questo è particolarmente utile per applicazioni che gestiscono query frequenti e ripetute, in cui la maggior parte del prompt rimane invariata. Il caching dei prefissi riduce la latenza e diminuisce l'utilizzo delle risorse, ottimizzando in modo significativo prestazioni e costi per l'inferenza degli LLM.
Il problema del cold start
Un'altra grande sfida nel self-hosting è il problema del cold start: il ritardo che si verifica quando nuove istanze impiegano tempo per essere pronte a gestire il traffico. Chaoyu ha discusso due strategie chiave per superare questo problema.
Una soluzione consiste nell'avere modelli pre-riscaldati in standby. Questo garantisce che i modelli siano immediatamente pronti a gestire le richieste quando si verifica un picco, riducendo al minimo i ritardi di avvio.
Un'altra ottimizzazione fondamentale è snellire le immagini dei container. Riducendo le dipendenze non necessarie, puoi diminuire drasticamente il tempo richiesto per scaricare le immagini quando si scalano dinamicamente i servizi. Ad esempio, un'immagine da 154MB verrà caricata molto più rapidamente di un'immagine ingombrante da 6.7GB, riducendo significativamente il tempo di avvio.
Inoltre, lo streaming progressivo dei pesi del modello nella memoria GPU, invece di caricarli sequenzialmente, riduce ulteriormente il tempo di inizializzazione. Questo garantisce che il tuo sistema possa gestire improvvisi picchi di traffico senza lunghi ritardi di avvio, migliorando la reattività complessiva dei tuoi modelli self-hosted.
Integrare BentoML e Milvus per applicazioni LLM più potenti
BentoML ottimizza i sistemi di serving online per applicazioni AI e inferenza dei modelli. Il suo servizio gestito, BentoCloud, offre una gamma di modelli AI open-source all'avanguardia, tra cui Llama 3, Stable Diffusion, CLIP e Sentence Transformers. Questi modelli predefiniti possono essere distribuiti con un solo clic sulla piattaforma.
Milvus è un database vettoriale open-source creato per archiviare, indicizzare e cercare dati non strutturati su scala di miliardi utilizzando embedding vettoriali ad alta dimensionalità. È ideale per applicazioni AI moderne come RAG, ricerca semantica, ricerca multimodale e sistemi di raccomandazione.
BentoCloud si integra perfettamente con Milvus e il suo servizio gestito, Zilliz Cloud, consentendo lo sviluppo semplice di potenti applicazioni basate su LLM, in particolare la Retrieval Augmented Generation (RAG). La RAG è una tecnica per migliorare l'output degli LLM fornendo al modello conoscenze esterne a cui non aveva accesso.
Puoi usare BentoCloud per servire modelli di embedding e convertire dati non strutturati in embedding vettoriali, che possono poi essere archiviati e recuperati in Milvus (o Zilliz Cloud). Milus quindi recupera i risultati più pertinenti e li fornisce come contesto all'LLM per generare risultati più accurati.
Figura- flusso di lavoro RAG.png
Per maggiori informazioni su come creare RAG o altri tipi di app GenAI, consulta i tutorial e i blog qui sotto:
Tutorial: Retrieval-Augmented Generation (RAG) con Milvus e BentoML | Documentazione Milvus
Blog | Sfide infrastrutturali nello scaling della RAG con modelli AI personalizzati
Video | RAG come servizio con BentoML
Riepilogo
Il deployment degli LLM comporta decisioni e sfide critiche, dalla scelta tra self-hosting e API gestite all'ottimizzazione delle prestazioni e dello scaling. Mentre le API gestite offrono comodità e semplicità, il self-hosting fornisce maggiore controllo, flessibilità ed efficienza dei costi a lungo termine per i team che necessitano di soluzioni personalizzate. La piattaforma di BentoML affronta molte delle complessità del self-hosting, offrendo strumenti potenti per ottimizzare l'inferenza, scalare in modo efficiente e superare ostacoli tecnici come il problema del cold start.
Sfruttando BentoML, Milvus o i loro servizi gestiti, i team possono integrare perfettamente i livelli Data e Operations delle loro applicazioni LLM, creando sistemi ad alte prestazioni che soddisfano le loro esigenze specifiche.
Se sei pronto a immergerti nel self-hosting degli LLM e a creare applicazioni LLM, strumenti come BentoML, OpenLLM e Milvus rendono più facile iniziare e ottimizzare per il tuo caso d'uso specifico.
Collabora con persone dedicate a ottimizzare il proprio livello dello stack DOOM. Sali sulle spalle dei giganti, sfrutta il mondo come Archimede e mantieni lo slancio.
Continua a leggere
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.
How to Build an Enterprise-Ready RAG Pipeline on AWS with Bedrock, Zilliz Cloud, and LangChain
Build production-ready enterprise RAG with AWS Bedrock, Nova models, Zilliz Cloud, and LangChain. Complete tutorial with deployable code.