Latency vs. Throughput

Hvor trade-offet kommer fra

Token-generering er bundet af hukommelsesbåndbredde: hvert decode-trin skal streame modelvægtene fra hukommelsen. Batching lader hardwaren indlæse vægtene én gang og rykke mange forespørgsler frem sammen, så den samlede tokens per sekund stiger 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: batch-størrelse 64 leverede 14x throughput ved 4x per-request latens.

Trade-offet har en hård kant: når batches bliver store nok til, at decode bliver compute-bound, holder throughput op med at forbedres, mens latensen fortsætter med at forværres - med Databricks' ord øger hver fordobling af batch-størrelsen ud over det punkt blot latensen. Forskningssystemer som Sarathi-Serve (OSDI 2024) eksisterer specifikt for at styre denne kurve, fordi naiv scheduling lader én brugers prefill blokere alle andre brugeres generering.

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

To udbydere, der kører identiske modeller på identiske GPU'er, kan levere fuldstændig forskellige oplevelser afhængigt af, 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) flytter fronten udad - og anden hardware ændrer kurvens form fuldstændigt: arkitekturer, der forbliver effektive ved lave batch-størrelser, kan tilbyde høj per-request hastighed uden at ofre lige så meget kapacitet, hvilket er præmissen for den dataflow-arkitektur, der ligger bag vores platform.

Praktisk råd: benchmark udbydere under dit reelle workload og din reelle samtidighed, ikke kun enkeltforespørgsler ved midnat. Hold øje med stabiliteten af inter-token latency hen over dagen - den afslører, hvor overtegnet kapaciteten faktisk er.

Relaterede begreber