Ring Attention: Blockwise Transformers for Near-Infinite Context
Prior memory-efficient Transformers still store per-layer activations linear in the full sequence length on one device. Ring Attention keeps the same attention math but makes max activation depend on block size, not total s.
Transformers win on quality, then trip on context. Self-attention is an -to- interaction: even after you stop materializing the full score matrix, each layer still wants the prior layer’s full-length activations. Put a hundred million tokens through a modest hidden size and you need more HBM than a single GPU or TPU slice has — not because the math is approximate, but because one device is being asked to own the whole sequence.
Ring Attention keeps the original Transformer equations. It reorganizes where the work lives. The sequence is cut into blocks and spread across a ring of hosts. Each host holds one query block. Key/value blocks circulate around the ring while each host runs blockwise attention and feedforward. When the block is large enough that compute hides the transfer, you get longer context without approximate attention and without an extra communication tax.
What this paper explains
Ring Attention (Liu, Zaharia, Abbeel) is a systems recipe for exact long-context Transformers:
- Start from blockwise parallel transformers (BPT). Prior work already computes attention and FFN block-by-block so you do not materialize the full score matrix. That cuts activation pressure, but the layer output is still length on the device that owns it.
- Shard the sequence across hosts. Host owns query block (the outer loop of blockwise attention) and the FFN for that block — no all-to-all required for those steps.
- Circulate KV blocks on a ring. The inner loop needs every KV block. Instead of gathering them (delay + memory), each host sends its current KV block to the next host and receives from the previous host, overlapping transfer with blockwise compute.
- Scale context with device count. The abstract’s claim: sequences up to device-count times longer than prior memory-efficient Transformers, without approximation or added communication/compute overheads when the arithmetic-intensity condition holds.
This is not another KV-cache eviction story (StreamingLLM sinks, H₂O heavy hitters) and not a serving batching story (Orca, DistServe, Sarathi). It is sequence-parallel exact attention for training and inference.
From the paper’s Table 1 (bfloat16 bytes). Here c is block size, independent of sequence length s. Teaching view of the published expressions — not a re-measure.
Prior limits
- Vanilla attention stores scores — dead on arrival for million-token contexts.
- Memory-efficient attention (FlashAttention-style online softmax / tiling) and BPT remove the score-matrix wall and shrink FFN peaks, but Table 1 in the paper still lists prior SOTA activations as — linear in full sequence length .
- Why that still fails. The next layer’s attention needs every prior-layer token. The paper’s concrete illustration: ~100M tokens, batch 1, hidden 1024 → >1000GB of activation footprint for storing layer outputs — while modern HBM is typically <100GB per device.
- Naive multi-host fetch of remote KV blocks either stalls on receives or accumulates KV copies until memory savings vanish. Sequence-parallel attention in prior ring topologies still left non-overlapped communication that BPT-scale memory did not fix.
The mechanism
Blockwise outer/inner loops. Write queries, keys, values as sequences of blocks. For a fixed query block , you walk KV blocks , accumulate online-softmax statistics, then run the FFN on that query block’s attention output. Host runs the outer iteration for .
Permutation invariance of the KV walk. For a fixed query block, the order of KV blocks does not matter as long as you combine block statistics correctly when rescaling. That is what licenses a ring schedule instead of a gather.
Ring schedule. Hosts form a circle. While host attends its query block against the KV block it currently holds, it concurrently:
- sends that KV block to host ,
- receives the next KV block from host .
After steps, every query block has seen every KV block — exact attention — and no host ever needed the full sequence in HBM.
Arithmetic intensity (overlap condition). Let be device FLOPs/s and host-to-neighbor bandwidth. For block size and head/hidden width , the paper’s simplified attention-only bound is
If clears that bar, KV transfer hides under compute (forward and backward). Table 2 in the paper lists device-specific thresholds.
Memory on one host. Store: current query block, current KV, incoming KV buffer, attention/FFN output for the query block → six blocks → bytes (bfloat16 accounting in Table 1), with independent of . Contrast prior BPT total .
A one-line mental model: sequence length across hosts, while each host’s activation ceiling tracks , not — provided the ring is fed and .
Algorithm / figure walkthrough
- Partition the length- sequence into blocks of size (plus the usual head/batch axes).
- Place block on host ; form queries/keys/values locally for that block.
- For step : each host runs blockwise attention (and eventually FFN) between its fixed query block and the KV block currently in hand, while
ppermute-style neighbor exchange rotates KV one hop along the ring. - Combine online-softmax numerators/denominators across KV visits so the result matches full attention.
- Stack layers the same way — the architecture is unchanged; only the execution topology is a ring.
The opening visual is the same arc: ENTER with one device drowning in length- activations; RUN with query cubes fixed and KV tokens circulating; LEAVE with context that grows when you add hosts.
What to notice when reading
- Exactness. Softmax is still global over the sequence; they are not sparsifying or compressing attention (contrast Infini-attention / sinks).
- Independence from tensor parallel. Context-length tables use FSDP-style sharding for the model; Ring Attention is an extra axis for sequence.
- Block size is a systems dial. Too small → communication shows; large enough → overlap. Memory is , so you still pick deliberately.
- Training-first narrative, inference-ready. Autoregressive decode is lighter (few queries), but Appendix C sketches circulating the KV cache on a ring for larger served contexts.
- Jax
ppermute. Appendix A’s sketch matches the story: collective permute aroundaxis_name, not a full all-gather of KV.
Results and evidence
Numbers below are from the paper’s tables/figures (arXiv:2310.01889) — not re-measured here.
Table 1 — activation sizes (bytes/layer, bfloat16). Ring Attention’s total is vs memory-efficient attn+FFN . The decisive difference is vs .
Context-length table (paper §5.1; tokens ). Ring Attention vs prior memory-efficient attn+FFN, same FSDP-style setup:
| Setup | Model | Prior attn+FFN | Ring Attention | vs SOTA |
|---|---|---|---|---|
| 8× A100 NVLink | 7B | 32 | 256 | 8× |
| 8× A100 | 13B | 16 | 128 | 8× |
| 32× A100 InfiniBand | 7B | 128 | 4096 | 32× |
| 32× A100 | 13B | 64 | 2048 | 32× |
| TPUv4-1024 | 7B | 16 | 8192 | 512× |
| TPUv4-1024 | 30B | 8 | 2048 | 256× |
| TPUv5e-256 | 7B | 16 | 2048 | 128× |
The “vs SOTA” column tracks device count on the GPU rows (8× / 32×) — matching the abstract’s “device count times longer” slogan when the ring is fully used for sequence.
MFU (Table 4 / §5.2). Ring Attention pushes much longer contexts (e.g. 7B on 8× A100: prior 32K vs Ring 256K; 13B on 32× A100: prior 64K vs Ring 2048K) while the authors report MFU staying in line with BPT expectations despite more attention FLOPs.
In-context RL (Table 5). On ExoRL, Action Transformers with Ring Attention train 128 trajectories where BPT hits OOM at that width; average return 113.66 vs BPT’s 111.13 at 32 trajectories (authors’ runs; BC/DT baselines lower).
LLM line retrieval (§5.4 / Figure 3). LLaMA-13B finetuned with Ring Attention to 512K context on 32× A100 (ShareGPT-derived data; compute-budget limited vs their “millions of tokens” capability claim) maintains high retrieval accuracy out to long contexts where 16K–100K chat baselines cannot continue.
Appendix C inference sketch. Example: LLaMA-7B on 32× TPUv5e — conventional head-parallel serve ~256K KV; Ring Attention can circulate KV for 32× larger context when bandwidth/FLOPs satisfy the overlap inequality (they illustrate under an assumed 40% MFU).
Limitations
- Needs a fast ring. Overlap assumes neighbor bandwidth high enough relative to FLOPs; weak interconnects reintroduce stalls.
- Block-size engineering. Memory is ; picking is not free — too small fails overlap, too large pressures HBM.
- FLOPs still grow with . Appendix D shows per-dataset FLOPs ratios vs 4K context; small models pay larger relative attention cost when context balloons.
- Finetune context capped in the LLM experiment. 512K is a budget choice, not the method’s ceiling; do not read it as a hard max.
- Complementary, not a replacement for FlashAttention kernels, FSDP/tensor parallel, or serving schedulers — you still compose those tools.
- Venue. Treat claims as the arXiv tech report’s reported measurements; no conference camera-ready is asserted in the abs comments.
How to read the paper
- Figure 1 — max context under end-to-end training on TPUv4-1024 (motivation).
- §2 — why still loses to HBM.
- Figure 2 + §3 — the ring cartoon and the derivation.
- Table 1 — vs .
- §5.1 context table — device-count scaling in practice.
- Table 4 / Table 5 / Figure 3 — MFU, RL, line retrieval.
- Appendix A + C — Jax
ppermutesketch and inference KV circulation.
Knowledge check
What does Ring Attention change relative to a standard Transformer layer?
In the paper’s Table 1, what does Ring Attention’s activation footprint scale with?
When does KV circulation add no extra wall-clock overhead?
How is this different from DistServe or Sarathi-Serve?
Keep reading / Sources
- Paper: Ring Attention with Blockwise Transformers for Near-Infinite Context (arXiv:2310.01889)
- Code named in-paper: llm_large_context
- Prior blockwise parallel transformers (cited as BPT in §2–3)
- Contrast in Daily: FlashAttention, StreamingLLM, H₂O
- Serving (different problem): DistServe, Sarathi-Serve
- Sharding cousin: ZeRO