Latency vs. Throughput

Hvor afvejningen kommer fra

Tokengenerering er begrænset af hukommelsesbåndbredden: Hvert decode-trin skal hente modellens vægte fra hukommelsen. Med batching indlæser hardwaren vægtene én gang og flytter mange forespørgsler frem sammen. Derfor stiger det samlede antal tokens per sekund stejlt med batch-størrelsen. Men alle forespørgsler i batchen deler den samme båndbredde, så hver brugers tokens ankommer langsommere. Databricks målte det konkret på en A100: En batch-størrelse på 64 gav 14x throughput ved 4x latens per forespørgsel.

Afvejningen har et knækpunkt. Når batches bliver så store, at decode bliver compute-bound, holder throughput op med at stige, mens latensen bliver ved med at blive værre. Med Databricks' ord øger hver fordobling af batch-størrelsen herefter kun latensen. Forskningssystemer som Sarathi-Serve (OSDI 2024) findes netop for at styre denne kurve. Med naiv scheduling kan én brugers prefill nemlig stoppe genereringen for alle andre brugere.

Hvad det betyder, når du vælger udbyder

To udbydere, der kører identiske modeller på identiske GPU'er, kan levere vidt forskellige oplevelser, alt efter hvor aggressivt de batcher. Høj udnyttelse er godt for udbyderens økonomi. Lav latens er godt for dine brugere. Bedre scheduling (continuous batching, chunked prefill) skubber kurven udad. Anden hardware ændrer kurvens form helt: Arkitekturer, der forbliver effektive ved små batch-størrelser, kan give høj hastighed per forespørgsel uden at ofre lige så meget kapacitet. Det er grundtanken bag den dataflow-arkitektur, som vores platform bygger på.

Et praktisk råd: Test udbydere med dit rigtige workload og din rigtige samtidighed, ikke kun med enkelte forespørgsler ved midnat. Hold øje med, hvor stabil inter-token latency er hen over dagen. Det viser, hvor overbooket kapaciteten reelt er.