Ricercatori dell’Università di Pechino presentano FastServe un sistema di servizio di inferenza distribuita per grandi modelli di linguaggio (LLM).

Researchers from the University of Beijing present FastServe, a distributed inference serving system for large language models (LLMs).

Le migliorie ai modelli di linguaggio (LLM) creano opportunità in diversi campi e ispirano una nuova ondata di applicazioni AI interattive. La più importante è ChatGPT, che consente alle persone di comunicare informalmente con un agente di intelligenza artificiale per risolvere problemi che vanno dall’ingegneria del software alla traduzione del linguaggio. ChatGPT è uno dei programmi in più rapida crescita nella storia, grazie alle sue straordinarie capacità. Molte aziende seguono la tendenza di rilasciare LLM e prodotti simili a ChatGPT, tra cui New Bing di Microsoft, Bard di Google, LLaMa di Meta, Alpaca di Stanford, Dolly di Databricks e Vicuna dell’UC Berkeley.

L’inferenza LLM differisce dall’inferenza di un altro modello di rete neurale profonda (DNN), come ResNet, perché ha caratteristiche speciali. Le applicazioni AI interattive basate su LLM devono fornire inferenze per funzionare. Il design interattivo di queste app richiede tempi di completamento rapidi (JCT) per l’inferenza LLM al fine di offrire esperienze utente coinvolgenti. Ad esempio, i consumatori si aspettano una risposta immediata quando inviano dati a ChatGPT. Tuttavia, l’infrastruttura di servizio delle inferenze è sotto grande stress a causa del numero e della complessità dei LLM. Le aziende creano costose cluster con acceleratori come GPU e TPU per gestire le operazioni di inferenza LLM.

I lavori di inferenza DNN sono spesso deterministici e altamente prevedibili, ossia il modello e l’hardware determinano in gran parte il tempo di esecuzione del lavoro di inferenza. Ad esempio, il tempo di esecuzione di varie foto di input varia leggermente utilizzando lo stesso modello ResNet su una determinata GPU. Le posizioni di inferenza LLM, al contrario, presentano un unico modello autoregressivo. Il lavoro di inferenza LLM passa attraverso diverse iterazioni. Ogni iterazione produce un token di output, che viene quindi aggiunto all’input per generare il token successivo nell’iterazione successiva. La lunghezza dell’output, che non è nota all’inizio, influisce sia sul tempo di esecuzione che sulla lunghezza dell’input. La maggior parte dei compiti di inferenza del modello deterministico, come quelli eseguiti da ResNet, è gestita dai sistemi di servizio delle inferenze esistenti come Clockwork e Shepherd.

• Suggerimenti e trucchi per integrare l’IA in un team ben connesso
• I 6 utilizzi principali dell’IA nel settore dei trasporti
• Espandi la tua attività con 3 suggerimenti di ChatGPT (Il metodo di Alex Hormozi)

Questi basano le loro decisioni di pianificazione su una profilazione precisa del tempo di esecuzione, che è inefficace per l’inferenza LLM con tempi di esecuzione variabili. Il metodo più avanzato per l’inferenza LLM è Orca. Suggerisce la pianificazione a livello di iterazione, consentendo di aggiungere nuovi lavori o eliminare lavori completati dal batch di elaborazione corrente dopo ogni iterazione. Tuttavia, elabora i lavori di inferenza utilizzando il principio “primo arrivato, primo servito” (FCFS). Un compito pianificato viene eseguito continuamente fino al completamento. Il batch di elaborazione non può essere aumentato con un numero arbitrario di funzioni in arrivo a causa della capacità di memoria GPU limitata e dei bassi requisiti di JCT dei lavori di inferenza. Il blocco in testa alla linea nel processo di esecuzione completa è ben noto.

Poiché i LLM sono di dimensioni considerevoli e richiedono molto tempo per essere eseguiti in termini assoluti, il problema è particolarmente grave per le operazioni di inferenza LLM. I grandi lavori di inferenza LLM, specialmente quelli con lunghezze di output estese, richiederebbero molto tempo per essere completati e ostacolerebbero i successivi lavori brevi. I ricercatori dell’Università di Pechino hanno sviluppato una soluzione di servizio di inferenza distribuita per i LLM chiamata FastServe. Per consentire la preemption al livello di ogni token di output, FastServe utilizza la pianificazione a livello di iterazione e il modello autoregressivo dell’inferenza LLM. FastServe può decidere se continuare un compito pianificato dopo aver generato un token di output o preemptionarlo con un altro lavoro nella coda. Ciò consente a FastServe di ridurre JCT e il blocco in testa alla linea tramite la pianificazione preemptive.

Un unico scheduler Multi-Level Feedback Queue (MLFQ) con skip-join serve come base per FastServe. MLFQ è un metodo ben noto per minimizzare il JCT medio in ambienti privi di informazioni. Ogni lavoro inizia nella coda di priorità più alta e, se non viene completato entro un certo tempo, viene retrocesso alla coda di priorità successiva. L’inferenza LLM è semi-agnostica alle informazioni, il che significa che mentre la lunghezza dell’output non è nota a priori, la lunghezza dell’input è nota. Questa è la principale distinzione tra l’inferenza LLM e la situazione convenzionale. La lunghezza dell’input determina il tempo di esecuzione per creare il token di output iniziale, che potrebbe richiedere molto più tempo rispetto ai token successivi a causa del modello autoregressivo dell’inferenza LLM.

Il tempo di esecuzione del token di output iniziale occupa la maggior parte del lavoro quando l’input è lungo e l’output è breve. Utilizzano questa caratteristica per aggiungere la funzionalità skip-join al tradizionale MLFQ. Ogni compito di arrivo si unisce a una coda appropriata confrontando il tempo di esecuzione del primo token di output con le soglie di retrocessione delle code, anziché entrare sempre nella coda di priorità più alta. Le code di priorità superiore rispetto alla coda congiunta vengono evitate per minimizzare le retrocessioni. La pianificazione preemptive con MLFQ aggiunge un overhead di memoria aggiuntivo per mantenere i lavori avviati ma incompleti in uno stato intermedio. I LLM mantengono una cache chiave-valore per ogni livello di trasformatore per memorizzare lo stato intermedio. Finché la dimensione del batch non viene superata, la cache FCFS deve memorizzare gli stati intermedi dei lavori pianificati. Tuttavia, possono essere stati avviati ulteriori lavori in MLFQ, ma vengono retrocessi in code con priorità inferiore. Tutti i lavori avviati ma incompleti in MLFQ devono avere lo stato intermedio mantenuto dalla cache. Date le dimensioni dei LLM e lo spazio di memoria limitato delle GPU, la cache potrebbe traboccare. Quando la cache è piena, lo scheduler può in modo ingenuo ritardare l’avvio di nuovi lavori, ma ciò crea nuovamente il blocco in testa alla linea.

Invece, sviluppano un sistema produttivo di gestione della memoria della GPU che carica in modo proattivo lo stato dei processi nelle code a bassa priorità quando vengono pianificati e scarica lo stato quando la cache è quasi piena. Per aumentare l’efficienza, utilizzano tecniche di pipelining e operazioni di memoria asincrone. FastServe utilizza tecniche di parallelizzazione come il parallelismo dei tensori e delle pipeline per fornire un servizio di inferenza distribuito con molte GPU per modelli enormi che non entrano in una sola GPU. Per ridurre le bolle delle pipeline, lo scheduler esegue numerosi batch di lavori contemporaneamente. Una cache chiave-valore distribuita è organizzata dal gestore della cache chiave-valore, che distribuisce anche la gestione della swap della memoria tra GPU e memoria dell’host. Mettono in pratica un prototipo di sistema FastServe basato su NVIDIA FasterTransformer. I risultati rivelano che FastServe migliora il tempo medio e il tail JCT fino al 5,1 e al 6,4 rispettivamente, rispetto alla soluzione all’avanguardia Orca.