Uw eigen LLM-eindpuntbenchmarking uitvoeren

Dit artikel bevat een door Databricks aanbevolen notebookvoorbeeld voor het benchmarken van een LLM-eindpunt. Het bevat ook een korte inleiding tot hoe Databricks LLM-deductie uitvoert en latentie en doorvoer berekent als metrische gegevens over eindpuntprestaties.

LLM-deductie op Databricks meet tokens per seconde voor de ingerichte doorvoermodus voor Foundation Model-API's. Zie Wat betekenen tokens per secondebereik in de ingerichte doorvoer?

Voorbeeldnotitieblok voor benchmarking

U kunt het volgende notebook importeren in uw Databricks-omgeving en de naam van uw LLM-eindpunt opgeven om een belastingtest uit te voeren.

Een LLM-eindpunt benchmarken

Notebook downloaden

Inleiding tot LLM-deductie

LLM's voeren deductie uit in een proces in twee stappen:

• Vooraf doorvoeren, waarbij de tokens in de invoerprompt parallel worden verwerkt.
• Decodering, waarbij tekst één token tegelijk wordt gegenereerd op een automatische regressieve manier. Elk gegenereerd token wordt toegevoegd aan de invoer en wordt teruggegeven aan het model om het volgende token te genereren. Genereren stopt wanneer de LLM een speciaal stoptoken uitvoert of wanneer aan een door de gebruiker gedefinieerde voorwaarde wordt voldaan.

De meeste productietoepassingen hebben een latentiebudget en Databricks raadt u aan om de doorvoer te maximaliseren op basis van dat latentiebudget.

• Het aantal invoertokens heeft een aanzienlijke invloed op het vereiste geheugen voor het verwerken van aanvragen.
• Het aantal uitvoertokens overheerst de totale reactielatentie.

Databricks verdeelt LLM-deductie in de volgende submetrieken:

• Tijd voor het eerste token (TTFT): Dit is hoe snel gebruikers de uitvoer van het model zien nadat ze hun query hebben ingevoerd. Lage wachttijden voor een reactie zijn essentieel in realtime interacties, maar minder belangrijk in offlineworkloads. Deze metrische waarde wordt bepaald door de tijd die nodig is om de prompt te verwerken en vervolgens het eerste uitvoertoken te genereren.
• Tijd per uitvoertoken (TPOT): Tijd voor het genereren van een uitvoertoken voor elke gebruiker die een query op het systeem uitvoert. Deze metrische waarde komt overeen met de manier waarop elke gebruiker de 'snelheid' van het model waarneemt. Een TPOT van 100 milliseconden per token is bijvoorbeeld 10 tokens per seconde of ~450 woorden per minuut, wat sneller is dan een typische persoon kan lezen.

Op basis van deze metrische gegevens kan de totale latentie en doorvoer als volgt worden gedefinieerd:

• Latentie = TTFT + (TPOT) * (het aantal tokens dat moet worden gegenereerd)
• Doorvoer = aantal uitvoertokens per seconde voor alle gelijktijdigheidsaanvragen

Op Databricks kunnen LLM-eindpunten worden geschaald zodat deze overeenkomen met de belasting die door clients met meerdere gelijktijdige aanvragen wordt verzonden. Er is een afweging tussen latentie en doorvoer. Dit komt doordat op LLM-eindpunten gelijktijdige aanvragen kunnen worden verwerkt en tegelijkertijd kunnen worden verwerkt. Bij lage gelijktijdige aanvraagbelastingen is latentie het laagst mogelijk. Als u echter de belasting van de aanvraag verhoogt, kan de latentie stijgen, maar de doorvoer neemt waarschijnlijk ook toe. Dit komt doordat twee aanvragen van tokens per seconde in minder dan twee keer zoveel tijd kunnen worden verwerkt.

Daarom is het beheren van het aantal parallelle aanvragen in uw systeem de kern van het verdelen van latentie met doorvoer. Als u een use-case met lage latentie hebt, wilt u minder gelijktijdige aanvragen naar het eindpunt verzenden om de latentie laag te houden. Als u een use-case voor hoge doorvoer hebt, wilt u het eindpunt overbelasten met veel gelijktijdigheidsaanvragen, omdat een hogere doorvoer het waard is, zelfs ten koste van latentie.

Databricks-benchmarking-harnas

De eerder gedeelde voorbeeldnotebook voor benchmarking van Databricks is het benchmarking-harnas van Databricks. In het notebook worden de metrische gegevens over latentie en doorvoer weergegeven, en wordt de doorvoer versus latentiecurve in verschillende aantallen parallelle aanvragen weergegeven. Automatische schaalaanpassing van Databricks-eindpunten is gebaseerd op een 'evenwichtige' strategie tussen latentie en doorvoer. In het notebook ziet u dat naarmate meer gelijktijdige gebruikers query's uitvoeren op het eindpunt op hetzelfde moment dat de latentie toeneemt en de doorvoer.

Meer informatie over de Databricks-filosofie over LLM-prestatiebenchmarking wordt beschreven in het blog LLM Inference Performance Engineering: Best Practices.