Condurre il benchmarking dell'endpoint LLM

Questo articolo presenta un esempio di notebook consigliato di Databricks per il benchmarking di un endpoint LLM. Comprende anche una breve introduzioni su come Databricks esegue l'inferenza LLM e calcola la latenza e velocità effettiva come metriche delle prestazioni degli endpoint.

L'inferenza LLM in Databricks misura i token al secondo per la modalità di velocità effettiva con provisioning per le API del modello di base. Si veda Che cosa significano i token al secondo nella velocità effettiva con provisioning?.

Notebook di esempio di benchmarking

È possibile importare il notebook seguente nell'ambiente Databricks e specificare il nome dell'endpoint LLM per eseguire un test di carico.

Benchmarking di un endpoint LLM

Ottenere il notebook

Introduzione all'inferenza LLM

LLM esegue l'inferenza in un processo in due passaggi:

• Precompila: i token nella richiesta di input vengono elaborati in parallelo.
• Decodifica: il testo viene generato un token alla volta in modo autoregressivo. Ogni token generato viene aggiunto all'input e restituito al modello per generare il token successivo. La generazione si arresta quando l'LLM restituisce un token di arresto speciale o quando viene soddisfatta una condizione definita dall'utente.

La maggior parte delle applicazioni di produzione ha un budget di latenza e Databricks consiglia di ottimizzare la velocità effettiva in base al budget di latenza.

• Il numero di token di input ha un impatto significativo sulla memoria necessaria per elaborare le richieste.
• Il numero di token di output domina la latenza complessiva della risposta.

Databricks divide l'inferenza LLM nelle metriche secondarie seguenti:

• Tempo per il primo token (TTFT): questo è il modo in cui gli utenti iniziano a visualizzare l'output del modello dopo aver immesso la query. I tempi di attesa ridotti per una risposta sono essenziali nelle interazioni in tempo reale, ma meno importanti nei carichi di lavoro offline. Questa metrica è basata sul tempo necessario per elaborare la richiesta e poi generare il primo token di output.
• Ora per token di output (TPOT): tempo per generare un token di output per ogni utente che esegue query sul sistema. Questa metrica corrisponde al modo in cui ogni utente percepisce la "velocità" del modello. Ad esempio, un TPOT di 100 millisecondi per token sarà di 10 token al secondo o circa 450 parole al minuto, più veloce di una persona tipica può leggere.

In base a queste metriche, la latenza totale e la velocità effettiva possono essere definite come segue:

• Latenza = TTFT + (TPOT) * (numero di token da generare)
• Velocità effettiva = numero di token di output al secondo in tutte le richieste di concorrenza

In Databricks gli endpoint di gestione LLM sono in grado di ridimensionare in modo che corrisponda al carico inviato dai client con più richieste simultanee. Esiste un compromesso tra latenza e velocità effettiva. Ciò è dovuto al fatto che, in LLM che gestisce gli endpoint, le richieste simultanee possono essere e vengono elaborate contemporaneamente. In caso di caricamenti simultanei bassi, la latenza è la più bassa possibile. Tuttavia, se si aumenta il carico della richiesta, la latenza potrebbe aumentare, ma anche la velocità effettiva aumenta. Ciò è dovuto al fatto che due richieste vale la pena di token al secondo possono essere elaborate in meno del doppio tempo.

Di conseguenza, il controllo del numero di richieste parallele nel sistema è fondamentale per bilanciare la latenza con la velocità effettiva. Se si ha un caso d'uso a bassa latenza, si vuole inviare meno richieste simultanee all'endpoint per mantenere bassa la latenza. Se si ha un caso d'uso con velocità effettiva elevata, si vuole saturare l'endpoint con molte richieste di concorrenza, poiché vale la pena una velocità effettiva più elevata anche a scapito della latenza.

Harness per il benchmarking di Databricks

Il notebook di esempio di benchmarking condiviso in precedenza è l’harness per il benchmarking di Databricks. Il notebook visualizza le metriche di latenza e velocità effettiva e traccia la curva di velocità effettiva rispetto alla curva di latenza in numeri diversi di richieste parallele. La scalabilità automatica degli endpoint di Databricks si basa su una strategia "bilanciata" tra latenza e velocità effettiva. Nel notebook si osserva che più utenti simultanei eseguono query sull'endpoint contemporaneamente aumentano la latenza e la velocità effettiva.

Altri dettagli sulla filosofia databricks sul benchmarking delle prestazioni LLM sono descritti nel blog Ingegneria delle prestazioni dell'inferenza di LLM: procedura consigliata.