Continuous Batching

Überblick

Traditionelles Static Batching verarbeitet Batches fester Größe: warte auf N Anfragen, generiere bis alle N fertig sind, starte dann nächsten Batch. Problem: Sequenzen enden zu unterschiedlichen Zeiten, GPU bleibt unterausgelastet. Ein Batch von 32 Sequenzen, wo eine 2000 Tokens und andere bei 100 Tokens enden, verschwendet 95% der GPU-Zyklen beim Warten auf die langsame Sequenz. Continuous Batching löst dies durch: (1) Start der Generierung sobald eine Anfrage eintrifft, (2) Hinzufügen neuer Anfragen zum Batch bei jeder Dekodierungs-Iteration, wenn Slots frei werden, (3) Sofortiges Entfernen abgeschlossener Sequenzen. Ergebnis: GPU bleibt bei maximaler Auslastung (nahe 100% Batch-Belegung). Durchsatzverbesserung: 2-3x für typische Workloads, bis zu 10x für variable Sequenzlängen. Jetzt Standard in vLLM (23x schneller als HuggingFace), TGI, TensorRT-LLM und allen produktiven Serving-Engines.

Wichtige Implementierungen (Oktober 2025)

• vLLM: PagedAttention + Continuous Batching, 24x Durchsatz vs. naives Serving
• TGI (Text Generation Inference): Hugging Faces Serving-Engine mit Continuous Batching
• TensorRT-LLM: NVIDIAs optimierte Engine mit Iteration-Level-Scheduling
• Ray Serve: Anyscales Framework mit Orca-Style-Batching
• DeepSpeed-FastGen: Microsofts Serving mit Dynamic Batching
• OpenAI Triton Inference Server: Continuous Batching für produktive GPT-Modelle
• Ollama: Lokales Serving mit Continuous-Batching-Unterstützung
• Together AI: Cloud-Serving-Plattform mit Continuous Batching

Performance-Verbesserungen

vLLM-Benchmarks (Llama 3 70B, A100 80GB): Static Batching: 12 Tokens/Sek/Anfrage, 40% GPU-Auslastung. Continuous Batching: 35 Tokens/Sek/Anfrage, 85% GPU-Auslastung. Durchsatz: 2,9x Verbesserung. Für variable-Länge-Workloads (50-500 Token-Ausgaben): Static: 8 Anfragen/Sek, Continuous: 42 Anfragen/Sek = 5,2x Verbesserung. Kostenauswirkung: $1/Stunde GPU bedient 8 Anfragen/Sek vs. 42 Anfragen/Sek = 5x Kostenreduktion pro Anfrage. Latenz: Time-to-First-Token unverändert (~50ms), aber Gesamt-Durchsatzerhöhung reduziert Warteschlangen-Wartezeiten. Der zentrale Vorteil: Höhere GPU-Auslastung (60-85% vs. 20-40%) übersetzt sich direkt in Kosteneinsparungen.

Funktionsweise

• Anfrageeingang: Sofort zur Warteschlange hinzufügen
• Bei jedem Decode-Schritt: Prüfe auf freie Batch-Slots (abgeschlossene Sequenzen)
• Dynamisches Einfügen: Füge wartende Anfragen hinzu, um leere Slots zu füllen
• Sequenzabschluss: Entferne aus Batch sofort, gebe Speicher frei
• Batch-Größe: Variiert von 1 bis max (z.B. 128) basierend auf Nachfrage
• Speicherverwaltung: PagedAttention ermöglicht effizientes KV-Cache-Sharing
• Preemption: Kann lange Anfragen pausieren, um kurze zu priorisieren
• Kein Warten: Neue Anfragen starten Generierung innerhalb einer Decode-Iteration

Code-Beispiel

# vLLM with continuous batching (automatic)
from vllm import LLM, SamplingParams

# Initialize LLM - continuous batching enabled by default
llm = LLM(
    model="meta-llama/Meta-Llama-3-70B",
    tensor_parallel_size=4,  # 4 GPUs
    max_num_seqs=128,  # Maximum batch size
    dtype="float16"
)

sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512
)

# Simulate continuous request stream
prompts = [
    "Write a short story:",
    "Explain quantum computing:",
    "Generate Python code for:",
    # ... many more requests
]

# vLLM automatically uses continuous batching
# Requests are processed as they arrive, filling batch slots dynamically
outputs = llm.generate(prompts, sampling_params)

for output in outputs:
    print(f"Prompt: {output.prompt}")
    print(f"Output: {output.outputs[0].text}")
    print(f"Tokens: {len(output.outputs[0].token_ids)}")
    print("-" * 80)

# Online serving with continuous batching
from vllm import AsyncLLMEngine, AsyncEngineArgs
from vllm.sampling_params import SamplingParams
import asyncio

async def generate_stream(engine, prompt):
    """Stream tokens as they're generated"""
    sampling_params = SamplingParams(max_tokens=200, temperature=0.7)
    
    # Request is added to batch immediately
    request_id = f"req_{id(prompt)}"
    results_generator = engine.generate(prompt, sampling_params, request_id)
    
    async for output in results_generator:
        # Tokens stream back while other requests process in parallel
        yield output.outputs[0].text

async def main():
    # Initialize async engine with continuous batching
    engine_args = AsyncEngineArgs(
        model="meta-llama/Meta-Llama-3-8B",
        max_num_seqs=64,  # Up to 64 concurrent requests
    )
    engine = AsyncLLMEngine.from_engine_args(engine_args)
    
    # Simulate multiple concurrent requests
    tasks = [
        generate_stream(engine, f"Request {i}: Explain AI")
        for i in range(10)
    ]
    
    # All requests process concurrently with continuous batching
    for task in asyncio.as_completed(tasks):
        async for token in await task:
            print(token, end="", flush=True)

asyncio.run(main())

# TGI (Text Generation Inference) with continuous batching
# Docker: docker run --gpus all --shm-size 1g -p 8080:80 \
#   ghcr.io/huggingface/text-generation-inference:latest \
#   --model-id meta-llama/Meta-Llama-3-70B --max-batch-total-tokens 32768

# Client code
from huggingface_hub import InferenceClient

client = InferenceClient("http://localhost:8080")

# Requests are batched continuously on server side
response = client.text_generation(
    "Explain machine learning:",
    max_new_tokens=200,
    temperature=0.7
)
print(response)

Continuous vs. Static Batching

Static Batching: Warte auf N Anfragen → Verarbeite Batch → Warte auf langsamste zum Abschluss → Starte nächsten Batch. GPU-Auslastung: 20-40% (Wartezeit dominiert). Durchsatz: Begrenzt durch langsamste Sequenz. Continuous Batching: Verarbeite Anfragen beim Eintreffen → Füge hinzu/entferne aus Batch bei jeder Iteration → GPU immer beschäftigt. GPU-Auslastung: 60-85% (nahezu optimal). Durchsatz: 2-10x höher. Speicher: Beide nutzen ähnlichen Gesamtspeicher, aber Continuous Batching mit PagedAttention ermöglicht bessere Speichereffizienz. Latenz: Static hat hohe Warteschlangen-Wartezeiten; Continuous startet sofort. Für Produktions-Serving: Continuous Batching ist strikt überlegen - gleiche Latenz, dramatisch höherer Durchsatz.

Wann verwenden

• Produktions-LLM-Serving: Essentiell für kosteneffiziente Bereitstellung
• Variable-Länge-Ausgaben: Maximaler Nutzen wenn Sequenzlängen 2-10x variieren
• High-Throughput-Anwendungen: Chatbots, API-Services, Batch-Processing
• Kostenoptimierung: 2-5x Kostenreduktion pro Anfrage vs. Static Batching
• Echtzeit-Serving: Niedrigere Warteschlangen-Wartezeiten für bessere User Experience
• Multi-Tenant-Serving: Effiziente GPU-Teilung über mehrere Nutzer
• Cloud-Deployment: Maximiere Anfragen pro GPU-Stunde
• Jede LLM-Inferenz-Workload: Kein Nachteil vs. Static Batching

Professionelle Integrationsdienste von 21medien

21medien bietet LLM-Serving-Optimierungsdienste an, einschließlich vLLM-Deployment, TGI-Konfiguration, Continuous-Batching-Tuning und Produktions-Infrastruktur-Setup. Unser Team ist spezialisiert auf Durchsatzmaximierung durch optimale Batch-Größen-Auswahl, Speicherkonfiguration und Multi-GPU-Serving-Strategien. Wir helfen Organisationen, Serving-Kosten um 2-5x durch Continuous Batching und verwandte Optimierungen zu reduzieren. Kontaktieren Sie uns für maßgeschneiderte LLM-Serving-Lösungen.

Ressourcen

Orca-Paper (OSDI 2022): https://www.usenix.org/conference/osdi22/presentation/yu | vLLM Blog: https://blog.vllm.ai/2023/06/20/vllm.html | TGI Docs: https://huggingface.co/docs/text-generation-inference | vLLM GitHub: https://github.com/vllm-project/vllm