--- title: "Warum eine fertige Antwort noch warten muss" source: https://bitvaria.com/continuous-batching --- 31\. Aug. 2026 · Daniel Schleipfer · [KI](https://bitvaria.com/category/ki/)  · 6 min read # Warum eine fertige Antwort noch warten muss Acht Anfragen starten gleichzeitig auf demselben Server. Die kürzeste ist nach drei Tokens fertig. Trotzdem kommt ihre Antwort erst an, wenn die längste der acht ihr letztes Wort geschrieben hat. ![Acht Anfragen starten gleichzeitig auf demselben Server. Die kürzeste ist nach drei Tokens fertig. Trotzdem kommt ihre Antwort erst an, wenn die längste der acht ihr letztes Wort geschrieben hat.](https://bitvaria.com/_astro/continuous-batching.BYEIgzcb.jpg) > **Was ist Continuous Batching?** > > Ein Scheduling-Verfahren für LLM-Inferenz, das nach jedem Generierungsschritt prüft, welche Anfragen fertig sind, deren Plätze freigibt und sofort neue Anfragen hineinlässt, statt auf das Ende des gesamten Batches zu warten. Acht Chat-Anfragen starten zur gleichen Zeit auf demselben Server. Eine davon ist eine einfache Ja-Nein-Frage. Nach drei Tokens ist sie fertig gerechnet. Eine andere ist eine lange Zusammenfassung. Sie braucht insgesamt zweihundert Tokens. Trotzdem kommt die kurze Antwort nicht früher an. Sie wartet, bis die lange fertig ist. Der Platz der kurzen Anfrage bleibt bis dahin einfach ungenutzt. ## Ein Platz, der frei wird, aber leer bleibt Ein Server verarbeitet mehrere Anfragen gemeinsam in einem Batch. Das soll die GPU auslasten. Bei jedem Generierungsschritt rechnet er für alle Anfragen im Batch ein weiteres Token, gleichzeitig. Läuft der Batch als feste Gruppe, endet er erst, wenn jede Anfrage fertig ist. Ist die kurze Anfrage nach drei Schritten am Ziel, laufen für die lange Anfrage die restlichen 197 Schritte trotzdem weiter. Der Platz der kurzen Anfrage rechnet in diesen Schritten nichts mehr. Er ist frei. Er bleibt aber leer, weil der Server erst am Ende der ganzen Gruppe neu einteilt. Diese feste Gruppe hat einen Namen: statisches Batching. Die Alternative füllt einen frei werdenden Platz sofort mit einer wartenden Anfrage. Das passiert, noch bevor der nächste Schritt beginnt. Dieses Nachfüllen mitten im Lauf hat einen eigenen Namen: Continuous Batching, manchmal auch in-flight batching. Hier sitzt dieser Begriff in der Serie: Die Serie, und wo dieser Begriff sitzt Dieser Begriff sitzt bei "Inference" in der Gruppe "Die Maschine". ## Für die Technik-Tiefe Ein statischer Scheduler trifft seine Entscheidung einmal pro Batch: welche Anfragen starten zusammen. Ein Continuous-Batching-Scheduler trifft sie einmal pro Generierungsschritt. Nach jedem Schritt prüft er, welche Sequenzen ein Ende-Token erzeugt oder ihr Längenlimit erreicht haben, entfernt sie aus dem Batch und zieht wartende Anfragen aus der Warteschlange in die frei gewordenen Plätze. Der nächste Schritt läuft dann mit einer teilweise anderen Zusammensetzung als der vorherige. Diese Entscheidung auf Ebene jedes einzelnen Schritts, statt auf Ebene der ganzen Anfrage, heißt iteration-level scheduling. Der Begriff stammt aus dem Orca-Paper (OSDI 2022), das diese Technik zusammen mit einer zweiten, selective batching, einführte: Anfragen unterschiedlicher Länge lassen sich in den linearen Rechenschritten gemeinsam batchen, weil dort jedes Token gleich behandelt wird, aber nicht in der Aufmerksamkeitsberechnung, die für jede Sequenz einen eigenen KV-Cache liest. Selective batching trennt beide Rechenarten, statt alle Anfragen auf eine gemeinsame Länge aufzufüllen. Unter gleichem Latenzziel maß das Paper bis zu 36,9-fachen Durchsatz gegenüber dem damaligen FasterTransformer, einem System mit statischem Batching. Die Zahl vergleicht zwei Serving-Systeme unter derselben Latenzvorgabe, nicht “Batching gegen kein Batching”. *Dieser Begriff baut auf dem KV-Cache auf: [Warum ein Modell teurer wird, je länger es spricht](https://bitvaria.com/kv-cache), und auf [Prefill und Decode](https://bitvaria.com/prefill-decode), den beiden Phasen, für die jeder Schritt neu eingeteilt wird.* ## Wenn die Serving-Software das Nachfüllen nicht beherrscht Continuous Batching ist eine Eigenschaft der Serving-Software, nicht der GPU-Hardware. Eine einfache Anbindung, die für jede eingehende Anfrage einmal die Modellfunktion aufruft und auf deren komplettes Ende wartet, kennt gar keinen Batch. Sie verarbeitet Anfragen strikt nacheinander, egal wie viele parallel eintreffen. Die GPU rechnet dann immer nur für eine einzige Anfrage und bleibt weit unter ihrer Kapazität, unabhängig davon, wie leistungsfähig die Karte ist. Für ein mittelständisches Unternehmen, das [ein offenes Modell selbst hostet statt es zu mieten](https://bitvaria.com/ki-modelle-hosten-oder-mieten), entscheidet genau diese Eigenschaft der Serving-Software, ob die Rechnung aus jenem Vergleich aufgeht. Kosten pro Token sinken dort, wo die Maschine wirklich mehrere Anfragen gleichzeitig rechnet, nicht automatisch mit mehr Rechenleistung. Wer prüft, ob sich eigene Hardware lohnt, prüft zuerst, ob die eingesetzte Serving-Software (etwa vLLM, TGI oder eine vergleichbare Engine) Continuous Batching beherrscht, bevor er über größere GPUs nachdenkt. Und selbst mit der richtigen Software bleibt der Effekt an Auslastung gebunden: Ein internes Werkzeug mit wenigen gleichzeitigen Nutzern hat selten eine Warteschlange, aus der ein frei gewordener Platz neu gefüllt werden könnte. * * * **Continuous Batching lässt keinen frei gewordenen Platz brachliegen. Sobald eine Anfrage fertig ist, rutscht die nächste wartende hinein. Sie wartet nicht auf das Ende der langsamsten.** Nächster Begriff: **Paged Attention**. Wie ein Server den KV-Cache vieler gleichzeitiger Anfragen verwaltet, ohne Speicher an Fragmentierung zu verlieren. ## Häufige Fragen **Was ist Continuous Batching?** Ein Scheduling-Verfahren, bei dem der Server nach jedem Generierungsschritt prüft, welche Anfragen fertig sind, deren Plätze freigibt und sofort neue wartende Anfragen hineinlässt. **Was ist der Unterschied zwischen Continuous Batching und statischem Batching?** Bei statischem Batching läuft eine feste Gruppe zusammen los und endet erst, wenn alle fertig sind. Bei Continuous Batching wird jeder frei werdende Platz sofort neu vergeben. **Was ist iteration-level scheduling?** Scheduling-Entscheidungen auf Ebene jedes einzelnen Generierungsschritts statt auf Ebene der gesamten Anfrage. Der Begriff stammt aus dem Orca-Paper (OSDI 2022). **Reicht mehr GPU-Leistung, wenn die Serving-Software kein Continuous Batching beherrscht?** Nein. Eine Anbindung, die Anfragen einzeln nacheinander verarbeitet, rechnet immer nur für eine einzige Anfrage und lastet die GPU nicht aus, unabhängig von der Leistungsfähigkeit der Karte. * * * *Teil der Serie [AI-Engineering-Begriffe erklärt](https://bitvaria.com/ai-engineering-begriffe). Verwandt: [Warum ein Modell teurer wird, je länger es spricht](https://bitvaria.com/kv-cache) (KV-Cache), [Warum dieselbe KI-Anfrage zwei Geschwindigkeiten hat](https://bitvaria.com/prefill-decode) (Prefill/Decode) und [Eigene KI-Modelle selbst hosten oder mieten?](https://bitvaria.com/ki-modelle-hosten-oder-mieten)* - [ki](https://bitvaria.com/tag/ki/) - [ai-engineering](https://bitvaria.com/tag/ai-engineering/) - [continuous-batching](https://bitvaria.com/tag/continuous-batching/) - [inference](https://bitvaria.com/tag/inference/) - [llm](https://bitvaria.com/tag/llm/) Share: [Back to Blog](https://bitvaria.com/blog/)