Valutazione delle prestazioni dell'inferenza degli LLM su Red Hat OpenShift AI

Nell'ultimo anno il panorama dell'intelligenza artificiale generativa (IA) ha subito una rapida evoluzione. Le potenzialità dei modelli linguistici generativi di grandi dimensioni (LLM) aumentano e le organizzazioni cercano di utilizzarli per soddisfare le esigenze aziendali. Per l'esecuzione degli LLM è necessaria molta capacità, quindi distribuirli su una piattaforma affidabile ed efficiente è fondamentale per sfruttare a costi contenuti l'hardware alla base, in particolare le GPU.

Questo articolo illustra la metodologia e i risultati dei test delle prestazioni dei modelli Llama-2 distribuiti nello stack di elaborazione dei modelli incluso in Red Hat OpenShift AI. OpenShift AI è una piattaforma MLOps flessibile e scalabile, dotata di strumenti per creare, distribuire e gestire le applicazioni basate sull'intelligenza artificiale. Sviluppata grazie a tecnologie open source, offre ai team funzionalità affidabili e coerenti a livello operativo per mettere alla prova le proprie competenze, fornire modelli ed erogare app innovative.

Lo stack del modello

Il modello che fornisce lo stack software è basato su KServe, OpenShift Serverless e OpenShift Service Mesh. Per eseguire i modelli Llama-2, abbiamo utilizzato anche Caikit e text-generation-inference-service (TGIS), sebbene OpenShift AI supporti anche OpenVINO e offra la possibilità di utilizzare in modo modulare altri runtime personalizzati. NVIDIA GPU Operator gestisce ed espone le GPU in modo che il container Text Generation Inference Server (TGIS) possa utilizzarle.

Figura 1: interazioni tra i componenti e flusso di lavoro dell'utente nello stack KServe/Caikit/TGIS.

Grazie a OpenShift Serverless e OpenShift Service Mesh, KServe offre numerose funzionalità all'avanguardia per l'inferenza dei modelli di IA. Questi componenti racchiudono la complessità legata alla rete, alla configurazione dei servizi, alla scalabilità automatica e al controllo dell'integrità per l'elaborazione dei modelli di produzione.

Il toolkit Caikit consente agli sviluppatori di gestire i modelli tramite una serie di API intuitive: fornisce infatti interfacce standard gRPC (Remote Procedure Call) e HTTP che possono essere utilizzate per eseguire query su vari modelli di base e inoltra le richieste al servizio di inferenza TGIS.

TGIS è uno dei primi fork del toolkit per l'inferenza della generazione di testo di Hugging Face e fornisce diverse funzionalità importanti per ottimizzare le prestazioni degli LLM, come il batch continuo e dinamico, il parallelismo tensoriale (partizionamento del modello), il supporto per la compilazione PyTorch 2 e altro ancora.

NVIDIA GPU Operator automatizza la gestione dei vari componenti software necessari per il provisioning e l'utilizzo delle GPU NVIDIA in OpenShift, come il container dei driver, il plug-in del dispositivo, l'utilità di esportazione delle metriche di Data Center GPU Manager (DCGM) e altri ancora. L'utilità di esportazione delle metriche DCGM ci consente di analizzare le metriche della GPU come l'utilizzo della memoria, l'utilizzo del multiprocessore di streaming (SM) e altre grazie all'istanza Prometheus di monitoraggio di OpenShift.

Metodologia impiegata per testare le prestazioni dei modelli linguistici di grandi dimensioni

Per valutare le prestazioni di un modello linguistico di grandi dimensioni, ci interessa misurare i valori classici di latenza e velocità effettiva. La latenza end-to-end delle richieste a un LLM, tuttavia, può essere notevolmente influenzata da alcuni fattori e può variare. L'aspetto più importante è la lunghezza dell'output, che dipende dal modo in cui gli LLM generano il testo un token alla volta. La latenza viene quindi misurata principalmente in termini di latenza per token o tempo per token di output (time per output token, TPOT).

I token sono unità di testo che rappresentano una stringa di caratteri di una parola o di un frammento di parola. Quando un modello linguistico di grandi dimensioni elabora il testo, prima lo converte in token, utilizzando uno schema che varia da modello a modello. Ai token vengono assegnate rappresentazioni numeriche, sono quindi organizzati in vettori che vengono prima inseriti nel modello e poi generati dal modello stesso.

Un altro fattore che incide sulla latenza delle richieste totale è il tempo di "precompilazione", ovvero il tempo necessario per l'elaborazione dei token delle richieste di input prima che il modello generi il primo nuovo token. Un terzo fattore che contribuisce in modo significativo alla latenza delle richieste totale è il tempo di attesa. Nei casi in cui il servizio di inferenza non è in grado di elaborare le richieste in modo sufficientemente rapido da tenere il passo con il carico in entrata a causa di limitazioni hardware, ad esempio una memoria della GPU insufficiente, alcune richieste dovranno attendere in coda prima di essere elaborate. A causa di questi fattori, il tempo per il primo token (time to first token, TTFT) è una metrica comune per misurare le prestazioni degli LLM. Il TTFT è particolarmente importante per diversi scenari di utilizzo, ad esempio nei chatbot, in cui i token vengono trasmessi in tempo reale e visualizzati mentre vengono generati.

Come la latenza, anche il throughput varia notevolmente se misurato utilizzando le richieste al secondo in base al numero di token generati nelle richieste. Pertanto, il throughput complessivo dovrà essere misurato in termini di token totali generati al secondo da tutti gli utenti che eseguono query sul modello.

Test del carico con llm-load-test

Abbiamo creato uno strumento open source chiamato llm-load-test per caricare i modelli di test in esecuzione sullo stack dei modelli di OpenShift AI. È scritto in Python e in pratica utilizza lo strumento di test del carico gRPC ghz. Abbiamo diviso ghz affinché nell'output del test consentisse di salvare la risposta e l'ID del thread di elaborazione per ogni richiesta.

Oltre alle funzionalità offerte in ghz, llm-load-test consente di eseguire più processi ghz in parallelo, con set di dati di input in ordine casuale in ogni istanza. In questo modo è possibile simulare più utenti che eseguono contemporaneamente query con diversi prompt sul modello. llm-load-test può anche caricare i risultati direttamente in un bucket S3 dopo un esperimento, contrassegnando gli oggetti di output con i metadati corrispondenti per l'esecuzione.

Set di dati di input

Per configurare i prompt di input in llm-load-test per il test del carico è possibile utilizzare un file JSON. Per gli esperimenti che abbiamo eseguito per generare i risultati condivisi in questo articolo abbiamo scelto un set di dati di 32 input dal set di dati OpenOrca con lunghezze di input/output variabili. L'input più lungo era costituito da 1.688 token, l'output da 377. La Figura 2 mostra come erano distribuite le lunghezze di input/output nel set di dati utilizzato per il test.

Figura 2: lunghezza dei token del set di dati utilizzato per il test.

È importante utilizzare dimensioni di input e output diverse per testare le capacità di batching continuo e dinamico di TGIS, per avere uno scenario realistico. I modelli recenti hanno iniziato a supportare lunghezze di contesto oltre i 4.000 token, particolarmente importanti per scenari di utilizzo come la retrieval-augmented generation (RAG). Per questo motivo, intendiamo aumentare le dimensioni del nostro set di dati per i test del carico in modo da includere in futuro lunghezze di input maggiori.

Risultati delle prestazioni di lama-2 su OpenShift AI su AWS

Le seguenti misurazioni delle prestazioni sono state raccolte utilizzando un cluster OpenShift dell'infrastruttura IPI (Installer-Provisioned Infrastructure) installato su AWS. Abbiamo installato l'operatore OpenShift AI e creato gli oggetti ServingRuntime e InferenceService per consentire la distribuzione del modello con Kserve, Caikit e TGIS.

La tabella 1 di seguito riassume i risultati dei test eseguiti su quattro combinazioni di modelli e tipi di istanze AWS:

Tabella 1: riepilogo delle configurazioni utilizzate per i test.

In ciascuna configurazione sono stati eseguiti diversi test del carico della durata di quattro minuti utilizzando llm-load-test con un numero diverso di thread simultanei (il parametro di concorrenza è indicato nelle figure seguenti). In ogni test, ogni thread inviava costantemente una richiesta alla volta non appena riceveva la risposta dalla richiesta precedente.

Come esempio visivo di un esperimento, la Figura 3 di seguito riporta un grafico della latenza totale di ciascuna richiesta per tutta la durata del test. Il colore di ciascun punto rappresenta la lunghezza del token, in modo da poter visualizzare chiaramente la correlazione tra lunghezza del token e output complessivo della richiesta.

Figura 3: latenza totale di tutte le richieste durante un test del carico.

Abbiamo analizzato i log TGIS per ottenere la latenza totale di ogni richiesta e il throughput calcolato dividendo il totale dei token generati durante il test del carico per la durata del test (240 secondi).

La Figura 4 mostra la latenza e il throughput misurati durante il test del carico di llama-2-7b sull'istanza g5.2xlarge con varie impostazioni di simultaneità. In questo caso, il throughput aumenta con l'aumento dei thread simultanei fino a una concomitanza di circa 20 thread. A causa dei limiti di memoria della GPU sull'istanza g5.2xlarge, TGIS non può contenere più di 20 richieste (a seconda della lunghezza di input/output delle richieste) in un batch alla volta.

Figura 4: riepilogo di latenza e throughput per Llama-2-7b su g5.2xlarge.

Il grafico della Figura 5 mostra la latenza e il throughput misurati durante il test del carico di llama-2-13B sull'istanza g5.12xlarge. In questo caso, la latenza minima per token inizia a un valore più basso rispetto al modello 7B su g5.2xlarge e il throughput è scalabile fino ad almeno 30 richieste simultanee, nonostante il modello sia più grande e l'istanza abbia lo stesso tipo di GPU. Questo è dovuto ai notevoli vantaggi in termini di prestazioni derivanti dal parallelismo tensoriale impiegato per distribuire il modello tra le 4 GPU.

Figura 5: riepilogo di latenza e throughput per Llama-2-13b su g5.12xlarge.

La Figura 6 mostra la latenza e il throughput misurati durante il test del carico di llama-2-70b sull'istanza g5.48xlarge. In questo caso, la latenza per token è maggiore rispetto alle configurazioni precedenti. I modelli come llama-2-70B hanno requisiti hardware importanti. Le GPU 8xA10G hanno 192 GB di VRAM combinati, la maggior parte dei quali è necessaria solo per caricare i 70 miliardi di parametri con una precisione a 16 bit nella memoria (70 miliardi x 16 bit = circa 140 GB). A seconda dei requisiti in termini di prestazioni, potrebbe essere necessario un numero maggiore di risorse di elaborazione, come le istanze p4d.24xlarge.

Figura 6: riepilogo di latenza e throughput per Llama-2-70b su g5.48xlarge.

La Figura 7 mostra la latenza e il throughput misurati durante il test del carico di llama-2-70b sull'istanza p4d.24xlarge. Rispetto all'istanza g5.48xlarge, possiamo mantenere una latenza molto più bassa per lo stesso numero di utenti. Anche fino a una concomitanza di 30 thread, il throughput continua a crescere anche quando aumentano i thread.

Figura 7: riepilogo di latenza e throughput per Llama-2-70b su p4d.24xlarge.

Costi previsti

Possiamo stimare il costo necessario per generare un milione di token basandoci sul throughput misurato e sui costi del tipo di istanza. La tabella seguente riassume queste stime utilizzando il throughput misurato per i risultati che abbiamo raccolto con un carico di 10 thread simultanei.

Tabella 2: riepilogo dei risultati per ciascuna configurazione con costo calcolato per milione di token.

Prossimi passi

Questi risultati sono solo una breve sintesi degli obiettivi raggiunti durante i test che stiamo effettuando sul team Performance and Scale for AI Platforms (PSAP) di Red Hat. Oltre ai test delle prestazioni per altri aspetti di OpenShift AI, stiamo continuando ad analizzare attivamente prestazioni e scalabilità dello stack di elaborazione dei modelli. Ci auguriamo di poter condividere i risultati dei test di altri modelli, nonché dati relativi alla la scalabilità automatica delle repliche dei modelli in base al traffico e molto altro in futuro.

Continueremo a lavorare allo sviluppo di llm-load-test e ci auguriamo di poter aggiungere presto diverse funzionalità, come ad esempio:

• La capacità di misurare il tempo per il primo token (TTFT) e il tempo per token di output (TPOT) per le richieste di streaming.
• Interfacce collegabili/modulari per eseguire query su modelli che si trovano alla base di diverse API, incluse le interfacce HTTP e gRPC.
• Fase di warm-up e capacità di verificare che il modello sia caricato e risponda senza errori.
• Modelli di carico più complessi, come una frequenza di arrivo di Poisson casuale.

Conclusioni

Il nostro test delle prestazioni dei modelli Llama-2 su OpenShift AI fornisce una panoramica della latenza, del throughput e dei compromessi in termini di costi associati all'esecuzione degli LLM in diverse configurazioni. Ad esempio, per il modello 7B, l'istanza g5.2xlarge era più conveniente in termini di costi, ma il passaggio a g5.12xlarge può essere vantaggioso per alcuni scenari di utilizzo, grazie ai significativi miglioramenti della latenza e del throughput dovuti al parallelismo tensoriale. L'esecuzione dei modelli più grandi dovrebbe comportare un output di qualità superiore, ma richiede più memoria GPU, il che comporta un costo maggiore.

OpenShift AI offre una soluzione adattabile ed efficiente per le organizzazioni che affrontano le complessità legate al deployment di modelli linguistici generativi di grandi dimensioni. La piattaforma è flessibile e in grado di soddisfare esigenze diverse, a prescindere dalla priorità attribuita a qualità del modello, latenza, velocità effettiva o costo. Per applicare questi vantaggi al tuo specifico scenario di utilizzo, distribuisci il modello che preferisci su OpenShift AI.