Continuous Batching

A serving system that keeps an active decode set refilled as requests finish or become compatible, so accelerators spend less time waiting for a whole batch to turn over.

Opening summary

Continuous batching is a serving technique for decode-heavy workloads. Instead of waiting for one fixed request batch to finish before starting another, the runtime keeps admitting new compatible work as slots open, which can keep the active decode set denser and reduce GPU idle time.

At a glance

Released

July 2022

System type

Serving

Related models

No related models listed yet.

Related modules

No related modules listed yet.

What It Is

Continuous batching is a serving system, not a model architecture change. Its job is to keep a decode batch alive over many turns by refilling open slots with new compatible requests instead of treating every batch as a sealed unit that must finish all together.

Where It Sits

It sits inside the inference-serving runtime alongside request queues, batching policy, routing, inference-engine execution, and key-value cache management. The underlying model still computes the same layers. Continuous batching changes how the serving stack schedules decode work around those layers so active slots stay occupied between request completions.

How It Works

Static request batching usually waits for one chosen batch to turn over before the scheduler admits more work. Continuous batching keeps a queue nearby, runs a decode step for the active set, removes requests that finish, and immediately refills those open slots with queued requests that can join the next compatible turn. The important behavior is incremental refill: the runtime does not rebuild service only at one fixed batch boundary, so decode work can stay denser across many turns.
Continuous Batching System Flow
Request and weight flow
Control flow
Continuous batching keeps decode slots occupied by refilling compatible work between turns rather than rebuilding service only when one fixed batch fully turns over.

Practical Impact

This technique helps most when many decode-heavy requests are active at once and the accelerator would otherwise spend time on half-empty turns after some requests finish early. By refilling open slots, the system can raise throughput and reduce obvious idle gaps. The tradeoffs are scheduler complexity, fairness pressure, and the risk that long or expensive requests crowd out short ones if queue policy is weak. It can help less when traffic is sparse, highly incompatible, or already underutilized, because then the refill machinery adds coordination without much density gain.
textthroughputgainapproxfractextactivedecodeslotskeptbusytextidleslotsafterrequestcompletion,quadtextlatencyriskapproxtextqueuepolicy+textfairnessoverhead\\text{throughput gain} \\approx \\frac{\\text{active decode slots kept busy}}{\\text{idle slots after request completion}}, \\quad \\text{latency risk} \\approx \\text{queue policy} + \\text{fairness overhead}

Tags

References

  1. Yu, Gyeong-In, et al. "Orca: A Distributed Serving System for Transformer-Based Generative Models." 16th USENIX Symposium on Operating Systems Design and Implementation (OSDI 22), 2022, https://www.usenix.org/conference/osdi22/presentation/yu.