LLM-Anfragen: Warum parallele Abfragen schneller und präziser sind

Die effizienteste Methode, mehrere unabhängige Fragen an ein Sprachmodell zu stellen, besteht darin, diese als separate Anfragen parallel zu senden – nicht in einer einzigen, gebündelten Nachricht. Diese Strategie nutzt die inhärenten Mechanismen der Large Language Models (LLMs) optimal aus und führt zu deutlich geringerer Latenz sowie präziseren Antworten.

Die Ursache liegt in der autoregressiven Architektur der Modelle, die jeden einzelnen Ausgabeschritt sequenziell generiert. Während parallele Verarbeitung auf Serverseite die Effizienz steigert, wird diese Stärke durch gebündelte Anfragen systematisch untergraben.

Autoregressive Erzeugung: Warum jede Antwort Zeit kostet

LLMs wie GPT-4 oder Claude erzeugen Text tokenweise – also Wort- oder Zeichenfragment für Wort- oder Zeichenfragment. Jeder neue Token wird sofort in den Kontext eingebunden, bevor der nächste generiert wird. Daraus folgt eine direkte Abhängigkeit:

• Eine Antwort mit 200 Tokens erfordert 200 Vorhersageschritte.
• Zehn Antworten mit je 200 Tokens summieren sich zu 2.000 Vorhersageschritten – wenn sie nacheinander verarbeitet werden.

Diese sequenzielle Natur ist der Hauptgrund, warum gebündelte Anfragen ineffizient sind. Selbst wenn das Modell scheinbar mehrere Fragen auf einmal beantwortet, wird jede Antwort Schritt für Schritt abgearbeitet.

Gebündelte Anfragen: Latenz steigt linear mit der Antwortlänge

Stellen wir uns vor, fünf unabhängige Fragen werden in einer einzigen Nachricht zusammengefasst. Das Modell muss nun:

• Den gesamten Kontext verarbeiten (Fragen + Anweisung zur separaten Beantwortung).
• Eine Antwort generieren, deren Länge der Summe aller Einzelantworten entspricht – inklusive Formatierungszeichen und Übergängen zwischen den Fragen.

Beispiel:

• Fünf Fragen mit je 200 Tokens Antwortlänge → Gesamtantwort ≈ 1.200 Tokens (aufgrund zusätzlicher Struktur).
• Bei einer durchschnittlichen Tokengenerierungszeit von 50 Millisekunden beträgt die Latenz etwa 60 Sekunden.

Hinzu kommen weitere Nachteile:

• Erhöhter Rechenaufwand: Der Key-Value-Cache (KV Cache) wächst mit der Eingabelänge und erhöht die Komplexität der Attention-Mechanismen in jedem Schritt.
• Kontextüberlastung: Das Modell muss zwischen den Fragen wechseln, was zu Inkonsistenzen oder „Lost in the Middle“-Effekten führen kann – ein Phänomen, bei dem wichtige Informationen in langen Eingaben verloren gehen.

Parallele Anfragen: Die GPU-Arbeitsteilung nutzen

Moderne LLM-Server wie vLLM, TensorRT-LLM oder TGI setzen auf Continuous Batching – eine Technik, die parallele Anfragen effizient verarbeitet. Dabei werden:

• Mehrere Anfragen gleichzeitig in einer einzigen Batch-Operation auf der GPU verarbeitet.
• Für jede Anfrage ein Token pro Schritt generiert, sodass die GPU parallel Tokens für alle Anfragen ausgibt.

Beispiel:

• Fünf parallele Anfragen mit je 200 Tokens Antwortlänge → Die GPU generiert in jedem Schritt fünf Tokens (je eines pro Anfrage).
• Die Latenz entspricht der Dauer der längsten Einzelanfrage – bei 200 Tokens und 50 ms pro Token etwa 10 Sekunden.

Dies entspricht einer theoretischen Beschleunigung um bis zu 500% im Vergleich zur gebündelten Variante. Praktisch liegt der Gewinn oft zwischen 300% und 400%, da Overhead (Netzwerk, Scheduling) die volle theoretische Geschwindigkeit leicht reduziert.

Prefill- und Decode-Phase: Warum Aufteilung in beiden Phasen vorteilhaft ist

Die Verarbeitung einer LLM-Anfrage lässt sich in zwei Phasen unterteilen:

1. Prefill-Phase: Der Eingabetext wird analysiert und die Key-Value-Caches für alle Tokens berechnet. Diese Phase profitiert bereits von Parallelisierung – längere Eingaben verlängern die Prefill-Zeit jedoch linear.

• Gebündelte Anfrage: Lange Eingabe → längere Prefill-Zeit.
• Parallele Anfragen: Jede Eingabe ist kürzer → Prefill-Zeit pro Anfrage sinkt.

1. Decode-Phase: Tokens werden sequenziell generiert. Hier skaliert die Latenz direkt mit der Anzahl der Tokens – und ist bei parallelen Anfragen auf die langsamste Einzelantwort begrenzt.

Fazit: Sowohl Prefill als auch Decode profitieren von der Aufteilung in separate Anfragen.

Qualität über Quantität: Warum isolierte Kontexte bessere Antworten liefern

Neben der Geschwindigkeit gibt es weitere Vorteile paralleler Anfragen:

• Fokus auf die Aufgabe: Jede Frage erhält die volle Aufmerksamkeit des Modells, ohne Ablenkung durch irrelevante Inhalte. Studien zeigen, dass längere Eingaben mit vielen Informationen die Antwortqualität verschlechtern können („Lost in the Middle“-Effekt).
• Konsistenz: Bei gebündelten Anfragen kommt es häufiger zu Formatierungsfehlern (z. B. falsche Nummerierung, fehlende Antworten). Parallele Anfragen eliminieren solche Probleme.
• Fehlerisolation: Ein Fehler in einer Antwort beeinflusst nicht die weiteren Generierungen – ein kritischer Vorteil bei komplexen oder sensiblen Anfragen.

Wann die Bündelung doch sinnvoll ist

Trotz der offensichtlichen Vorteile paralleler Anfragen gibt es Ausnahmen, in denen gebündelte Anfragen praktikabel oder sogar notwendig sind:

• Abhängigkeiten zwischen den Fragen: Wenn die Antworten aufeinander aufbauen (z. B. „Erstelle einen Bericht und fasse die wichtigsten Punkte zusammen“), kann ein gemeinsamer Kontext die Konsistenz erhöhen.
• API-Ratenlimits: Einige Dienste begrenzen die Anzahl der Anfragen pro Minute. In solchen Fällen ist die Bündelung eine Notlösung.
• Extrem kurze Antworten: Bei einfachen Ja/Nein-Fragen oder Ein-Wort-Antworten überwiegt der Prefill-Overhead den Nutzen paralleler Anfragen. Hier kann die Bündelung die Effizienz steigern.
• Hohe Netzwerklatenz: Wenn die Netzwerkverzögerung (z. B. 2 Sekunden pro Anfrage) deutlich über der Generierungszeit (z. B. 0,5 Sekunden) liegt, kann die Bündelung die Gesamtzeit reduzieren. Allerdings ist dies in den meisten modernen Cloud-Umgebungen selten der Fall, da die Latenz typischerweise zwischen 100 und 300 Millisekunden liegt.

Praktische Umsetzung: So testen Sie es selbst

Um die Unterschiede empirisch zu überprüfen, können Entwickler ein einfaches Experiment durchführen. Ein Python-Beispiel mit asyncio und einer asynchronen LLM-API zeigt die Latenzunterschiede:

import asyncio
import httpx

async def send_parallel_queries(questions):
    async with httpx.AsyncClient() as client:
        tasks = [client.post(
            "YOUR_LLM_API_ENDPOINT",
            json={"prompt": question},
            timeout=30.0
        ) for question in questions]
        responses = await asyncio.gather(*tasks)
        return responses

async def send_batched_query(questions):
    combined_prompt = "\n".join([f"{i+1}. {q}" for i, q in enumerate(questions)])
    async with httpx.AsyncClient() as client:
        response = await client.post(
            "YOUR_LLM_API_ENDPOINT",
            json={"prompt": combined_prompt},
            timeout=30.0
        )
        return response

questions = [
    "Was ist der Hauptunterschied zwischen Python und JavaScript?",
    "Wie funktioniert ein neuronalen Netz?",
    "Welche Programmiersprache eignet sich für maschinelles Lernen?",
    "Erkläre OOP im Kontext von Python.",
    "Was sind die Vorteile von TypeScript gegenüber JavaScript?"
]

# Zeitmessung und Vergleich

Fazit: Parallele Anfragen als Standardstrategie für LLM-Nutzung

Die technische Architektur moderner Sprachmodelle macht deutlich: Parallele, unabhängige Anfragen sind in den allermeisten Fällen die überlegene Methode, um mehrere Fragen effizient und präzise zu beantworten.

Für Entwickler und Unternehmen, die LLMs in Produktionsumgebungen einsetzen, lohnt es sich, diese Strategie zu standardisieren – insbesondere bei Anwendungen mit hohem Durchsatz oder Echtzeitanforderungen.

Die Zukunft der LLM-Nutzung wird zunehmend von Optimierungen auf Serverseite geprägt sein, doch die Wahl der richtigen Anfragestrategie bleibt eine einfache, aber wirkungsvolle Hebelwirkung für bessere Performance und Qualität.