BurstEngine: Engineering Burst Phenomena

• BurstEngine is a term for various systems that generate, detect, or optimize burst phenomena in diverse technical domains.
• It spans applications from burst memory transactions in RISC-V clusters and ultrashort pulse generation in optics to spatiotemporal mining, RF beam extraction, matching engines, and Transformer training.
• Each implementation tailors burst handling through specialized engineering methods such as hierarchical arbitration, optical delay tuning, efficient data structures, and communication optimizations.

BurstEngine is a reused designation in the technical literature for several unrelated systems whose common concern is the engineering of burst phenomena: burst memory transactions in shared-L1 RISC-V vector clusters, ultrashort laser-pulse burst generation, spatiotemporal burst mining in document streams, RF-driven millisecond beam extraction from synchrotrons, micro-burst-tolerant order-book matching, and distributed Transformer training on contexts exceeding $10^6$ tokens (Shen et al., 24 Jan 2025, Tanaka et al., 27 Jan 2025, Lappas et al., 2012, Sota et al., 2022, Yoon, 31 May 2026, Sun et al., 24 Sep 2025). The term therefore does not denote a single standardized platform. Rather, the published record shows repeated adoption of the name for systems that either generate bursts, detect bursts, or maintain high efficiency under burst-dominated operating conditions.

1. Terminological scope and recurrent design motif

The literature suggests that “BurstEngine” functions primarily as a project- or component-level label rather than as a stable cross-domain technical standard. In one instance it is the code name of a TCDM Burst Manager for many-core RVV clusters; in another it is a four-mirror femtosecond burst-pulse generator; elsewhere it names a burst-aware retrieval engine, an RF extraction scheme, a low-latency matching-engine architecture, and a long-context Transformer training framework (Shen et al., 24 Jan 2025, Tanaka et al., 27 Jan 2025, Lappas et al., 2012, Sota et al., 2022, Yoon, 31 May 2026, Sun et al., 24 Sep 2025).

Usage of “BurstEngine”	Domain	Source
Burst Manager in code	Shared-L1 RVV cluster memory system	(Shen et al., 24 Jan 2025)
Four-mirror burst generator	Ultrafast optics	(Tanaka et al., 27 Jan 2025)
Burst-aware document-search engine	Spatiotemporal IR and data mining	(Lappas et al., 2012)
RF phase-displacement extraction scheme	Synchrotron beam delivery	(Sota et al., 2022)
Matching-engine architecture	Electronic trading systems	(Yoon, 31 May 2026)
Distributed training framework	Long-sequence Transformer training	(Sun et al., 24 Sep 2025)

Across these usages, a common design pattern is explicit accommodation of burst structure. In hardware and distributed systems, this appears as bandwidth concentration, communication overlap, or constant-time operations under burst load. In optics and accelerator physics, it appears as controlled generation of pulse or beam bursts. In information retrieval, it appears as formal detection of temporal, spatial, or spatiotemporal anomalies.

2. Shared-L1 vector-cluster BurstEngine

In "TCDM Burst Access: Breaking the Bandwidth Barrier in Shared-L1 RVV Clusters Beyond 1000 FPUs," the BurstEngine is the code-level name of the TCDM Burst Manager introduced for clusters of vector cores sharing multi-banked L1 memory over hierarchical intra-cluster networks (Shen et al., 24 Jan 2025). The motivating problem is that flat all-to-all interconnects become physically impractical as core count rises, while hierarchical topologies incur internal contention that interacts poorly with bursty SIMD or vector memory traffic.

The datapath is organized around a Burst Sender, Request Queue + Arbiter, Dispatch Logic, and Response Collector. On a vector load, the $K$ parallel LSU ports emit a compact burst request consisting of start address and length $=K$, rather than $K$ separate 32-bit transactions. The Burst Manager then arbitrates incoming bursts, splits each into $K$ sub-requests of 32 bits, dispatches them across the hierarchical crossbar while maintaining per-bank FIFO ordering, and collects responses from groups of banks into widened return transfers of $GF \times 32$ bits. The VLSU reorder buffer then unwraps the grouped return and retires words into vector lanes. The Burst Sender also doubles the ROB depth to maintain the same number of outstanding transactions (Shen et al., 24 Jan 2025).

The formal bandwidth model is parameterized by the number of vector PEs $N$, the number of FPUs or vector lanes per PE $K$, the narrow word width $W_0=4$ Bytes, and a return-channel width factor $GF$. With $K$0 and $K$1, the achieved bandwidth per PE with burst support is

$K$2

while the serialized baseline is

$K$3

Normalized utilization is defined as $K$4 (Shen et al., 24 Jan 2025).

The reported implementation results emphasize bandwidth, energy efficiency, and modest area cost. The abstract states bandwidth improvements over the baseline of 118% for a 16-FPU cluster, 226% for a 256-FPU cluster, and 77% for a 1024-FPU cluster, with peak utilization reaching up to 80% of cores-memory peak bandwidth and logic overhead below 8% (Shen et al., 24 Jan 2025). The consolidated design guide reports utilization improvements of $K$5 for 16 FPU, $K$6 for 256 FPU, and $K$7 for 1024 FPU, which it expresses as $K$8, $K$9, and $=K$0, respectively; it also reports area overheads of $=K$1 for MP$=K$2Spatz$=K$3 with GF4, $=K$4 for MP$=K$5Spatz$=K$6 with GF4, and $=K$7 for MP$=K$8Spatz$=K$9 with GF2 (Shen et al., 24 Jan 2025). For real kernels, the guide lists speedups including DOTP at $K$0, $K$1, and $K$2 on 16-, 256-, and 1024-FPU clusters; FFT at $K$3, $K$4, and $K$5; and selected MATMUL gains up to $K$6 (Shen et al., 24 Jan 2025).

Energy efficiency is defined as

$K$7

In 12 nm FinFET post-PNR results, the MP$K$8Spatz$K$9 dotp example moves from 56.19 GFLOPS at 1.30 W, or 43.2 GFLOPS/W, to 155.10 GFLOPS at 1.91 W, or 81.2 GFLOPS/W, corresponding to an $K$0 ratio of approximately $K$1; the paper summarizes memory-bound tests as reaching up to $K$2 improvement in GFLOPS/W and up to $K$3 performance over a serialized-access baseline (Shen et al., 24 Jan 2025).

The main trade-off is width-factor scaling. The guide states that $K$4 can increase up to $K$5, at which point remote latency vanishes, but further growth yields diminishing returns. Wider trunks also increase routing congestion, and in the 1024-FPU design the chosen configuration was $K$6 to meet timing. As $K$7 becomes very large, $K$8, so $K$9, implying a utilization ceiling of $GF \times 32$0. A plausible implication is that the architecture is highly effective for large but still wire-feasible cluster scales, while truly extreme scaling becomes constrained by physical interconnect width, ROB depth, and FIFO growth rather than by the burst-dispatch abstraction alone (Shen et al., 24 Jan 2025).

3. Four-mirror ultrashort burst-pulse BurstEngine

In "Compact, widely tunable ultrashort burst pulse generator using four mirrors," BurstEngine denotes a compact free-space optical system that shapes a single ultrashort pulse into a burst with controllable pulse interval, pulse count, and pulse energies (Tanaka et al., 27 Jan 2025). The layout uses four mirrors: Mirror 1 is a high-reflectance planar mirror; Mirror 2 is a partially reflective planar mirror with designed transmittance profile $GF \times 32$1; Mirrors 3 and 4 are a second parallel pair of high-reflectance mirrors. Set 1, formed by Mirrors 1 and 2, is separated by $GF \times 32$2, while Set 2 is separated by $GF \times 32$3. Successive reflections create horizontal displacement $GF \times 32$4 in Set 1 and vertical displacement $GF \times 32$5 in Set 2, so that after $GF \times 32$6 reflections in Set 1 and $GF \times 32$7 reflections in Set 2 the output forms an $GF \times 32$8 array of beamlets (Tanaka et al., 27 Jan 2025).

The inter-pulse delay is derived from the optical-path differences per bounce, $GF \times 32$9 and $N$0, with

$N$1

Using the geometrical expressions

$N$2

the delay becomes

$N$3

Under the stated approximation $N$4 and small $N$5 incidence, the paper gives the linear tuning law

$N$6

A more general vector derivation retains the incidence angles $N$7 and $N$8, giving $N$9, $K$0, and hence $K$1. The report further states that phase or second-order dispersion from the mirror coatings is negligible on $K$2-fs pulses at 800 nm (Tanaka et al., 27 Jan 2025).

Pulse-count and energy programming are governed by transmission at the partially reflective mirror. If $K$3 is the input pulse energy, $K$4 the reflectance of the high-reflectance mirrors, and $K$5 the backside reflectance of Mirror 2, then the $K$6-th pulse energy is

$K$7

with $K$8. Conversely, the desired $K$9 can be used to solve for $W_0=4$0,

$W_0=4$1

The paper states that spatial patterning of the dielectric coating on Mirror 2 enables linear-ramp, Gaussian-shaped, or arbitrary energy envelopes across the burst (Tanaka et al., 27 Jan 2025).

The demonstrated tunability extends from femtoseconds to nanoseconds. By varying $W_0=4$2 from a few millimeters up to approximately 200 mm, the system tunes $W_0=4$3 from $W_0=4$4 fs up to $W_0=4$5 ns. The reported experimental configuration used $W_0=4$6 mm, $W_0=4$7 mm, $W_0=4$8 mm, and $W_0=4$9, with measured delays in close agreement with theory: for $GF$0, 20, 50, and 100 mm, the measured values were $GF$1, $GF$2, $GF$3, and $GF$4 ps, respectively, against theoretical values of 0.07, 0.28, 0.67, and 1.33 ps (Tanaka et al., 27 Jan 2025).

Performance figures emphasize preservation of pulse quality and compactness. The input pulse duration was 35 fs at 803 nm with 35 nm bandwidth, while the output was reported as $GF$5 fs with no measurable broadening. Shot-to-shot timing jitter among six pulses was measured as $GF$6 fs for sub-ps bursts and $GF$7 fs for intervals exceeding 10 ps. For a six-pulse Gaussian envelope, the energy standard deviation was $GF$8 over 60,000 shots. The physical footprint was given as a 100 mm $GF$9 500 mm bench using only four mirrors plus one beam block (Tanaka et al., 27 Jan 2025).

The comparison to conventional schemes is framed against Fabry–Pérot-shuttle and “Deathstar” arrangements. The paper states that BurstEngine uses $K$00 the free-space path, specifically at least $K$01 shorter, and only four elements rather than large relay optics, while providing continuous inter-pulse tuning over five decades, $K$02 to $K$03 s, without changing vacuum chambers or fiber loops (Tanaka et al., 27 Jan 2025). Applications identified in the paper include ultrafast spectroscopy, laser micromachining, and high-speed multiphoton microscopy.

4. Spatiotemporal burstiness mining and retrieval

In "On The Spatiotemporal Burstiness of Terms," Lappas et al. use BurstEngine to denote an information-retrieval architecture that mines temporal, spatial, and spatiotemporal bursts and uses them to rank documents about influential events (Lappas et al., 2012). The core mathematical object is a deviation from expected frequency mass. For a term $K$04 with time series $K$05, the temporal burstiness of an interval $K$06 is

$K$07

with $K$08. Spatial burstiness at time $K$09 for stream $K$10 is defined relative to a baseline $K$11 as

$K$12

For a rectangular region $K$13, the snapshot rectangle score is

$K$14

and for a spatiotemporal window $K$15, the total burstiness is

$K$16

The target objects are maximal windows that cannot be extended in space or time without decreasing $K$17 (Lappas et al., 2012).

Two mining algorithms support this formulation. STComb searches for combinatorial patterns without geographic proximity constraints. It first extracts temporal bursts independently on each stream, then builds an interval graph whose nodes are burst intervals weighted by $K$18, with edges connecting overlapping intervals; the desired pattern is a maximum-weight clique, solvable on interval graphs in $K$19, where $K$20 is the total number of intervals. STLocal enforces regional locality and operates online: at each timestamp it computes $K$21, runs R-Bursty to extract non-overlapping axis-aligned rectangles with positive $K$22, appends rectangle scores to per-rectangle time series, applies the linear-time GetMax algorithm to maintain maximal-scoring contiguous subsequences, and discards a rectangle if the cumulative sum of its score sequence drops below zero (Lappas et al., 2012).

The BurstEngine architecture combines this mining layer with standard inverted indexing. Documents arrive with a timestamp and geostamp that identify a stream $K$23; term frequencies update $K$24. STLocal and/or STComb then produce mined patterns stored in a side index keyed by term. Query processing joins posting lists with pattern lists. For a multi-term query $K$25, each candidate document $K$26 receives, for each query term, a relevance score $K$27 and a burstiness score equal to the maximum score of any pattern overlapped by the document in space and time. The final ranking function is

$K$28

Top-$K$29 evaluation uses the Threshold Algorithm (Lappas et al., 2012).

The reported empirical evaluation uses 305 K Topix.com news articles from September 2008 to July 2009, organized into 181 country streams, together with a major-events set of 18 influential events and two synthetic generators, DISTGEN and RANDGEN (Lappas et al., 2012). On the synthetic task with 1000 injected patterns, STLocal achieved Jaccard similarity 0.88 and start/end error of approximately 6 days on DISTGEN, while STComb obtained Jaccard 0.91 on RANDGEN. On bursty document retrieval for the 18 real queries, STLocal achieved 100% precision on all queries, STComb achieved 100% except one event at 80%, and a temporal-only baseline dropped to 70–90% on localized events (Lappas et al., 2012).

Performance and scalability claims are similarly explicit. On Topix data with $K$30 streams, STLocal required approximately 1 ms per term per timestamp in online mode, while STComb required approximately 20 ms per term per timestamp offline. Synthetic experiments up to 128,000 streams showed near-linear scaling, with STLocal consistently faster. The paper nonetheless identifies several limitations: STLocal is restricted to axis-aligned rectangles, STComb is inherently offline, bursts may include a few non-bursty streams that require post-filtering, and future work is suggested on arbitrary regional shapes, online combinatorial mining, and ensemble ranking (Lappas et al., 2012).

5. RF phase-displacement BurstEngine for synchrotron extraction

In "Millisecond burst extractions from synchrotrons using RF phase displacement acceleration," BurstEngine denotes an extraction scheme for producing short, high-intensity particle bursts required by FLASH radiotherapy and certain particle-physics applications (Sota et al., 2022). The method combines third-integer resonant slow extraction with RF phase-displacement acceleration. Empty RF buckets are swept through a coasting beam; the resulting coherent momentum kicks produce tune shifts through chromaticity, driving particles across the separatrix in controlled bursts.

The transverse dynamics are formulated around the third-integer resonance condition $K$31, $K$32. With tune shift $K$33 and sextupole driving term $K$34, the single-turn Hamiltonian is

$K$35

whose level sets define a triangular separatrix. In normalized phase space, the separatrix is

$K$36

Chromaticity links momentum deviation $K$37 to tune shift via

$K$38

Thus coherent RF-induced changes in $K$39 transport particles toward resonance (Sota et al., 2022).

The longitudinal control law is derived from the RF cavity energy gain

$K$40

which yields relative momentum change per turn

$K$41

For empty-bucket sweeping, the analysis uses mean shift $K$42 and RMS blow-up $K$43,

$K$44

with

$K$45

Normalized to initial momentum spread $K$46, the design variables become $K$47 and $K$48, where $K$49. The paper further defines a longitudinal sweep time $K$50 and a transverse transit time $K$51, and states that extraction should satisfy $K$52 turn while remaining comparable to $K$53 (Sota et al., 2022).

Two machines are modeled: the CERN Proton Synchrotron and a PIMMS-type medical synchrotron. For the PS, the report uses $K$54 m, kinetic energy 24 GeV, $K$55, $K$56, $K$57, $K$58, harmonic $K$59 or 16, $K$60 kV, sextupole strength $K$61, $K$62, and $K$63. For the PIMMS-type machine, it uses $K$64 m, kinetic energy $K$65 MeV, $K$66, $K$67, $K$68, $K$69, $K$70 kV, $K$71, $K$72, and $K$73 (Sota et al., 2022).

The principal simulation result is that 80–90% of the total beam intensity can be extracted in a single burst of 40–60 ms in the PS, corresponding to approximately 10 ms in a typical medical synchrotron, with a set of three consecutive bursts also simulated under optimized parameters (Sota et al., 2022). The detailed report uses a 4-element Henon-track model with 10$K$74 macro-particles and states that overall 80–90% extraction is achieved for $K$75 and $K$76–0.2. For a three-burst example with $K$77 turns per burst, Py-BOBYQA optimization found $K$78 kV, $K$79; $K$80 kV, $K$81; and $K$82 kV, $K$83, reducing the relative error in burst length from 37% to 12% over 50 runs and keeping extracted fraction within 9% of the target 30% (Sota et al., 2022).

The report extends beyond theory into implementation and specifications. It proposes a digital phase-lock loop, programmable frequency sweep profile $K$84 with rise/fall times below 1 ms, synchronous phase control $K$85, real-time beam-current feedback, fast RF hardware, and septum synchronization with $K$86 ns jitter. The design specification given for a BurstEngine includes 40–60 ms bursts in the PS or 8–12 ms in PIMMS, 80–90% extracted fraction, duty cycle $K$87, spill intensity stable within $K$88 over 98% of the burst length, and 99% probability of achieving target burst length and intensity (Sota et al., 2022).

6. BurstEngine as a micro-burst-tolerant matching engine

In "The World's Fastest Matching Engine Algorithm," BurstEngine denotes an order-book architecture optimized for tail-latency resilience under micro-bursts (Yoon, 31 May 2026). The design is built on two data-structure contributions: the Priority-Indicated Node, or PIN, and neighbor-aware tree maintenance. The stated goal is to eliminate two recurrent costs in conventional matching engines: pointer-chased traversal through linked structures and repeated root-to-leaf searches for price-level insertion and deletion.

A PIN is a fixed-capacity container of $K$89 slots stored in contiguous arrays. Each node maintains a free-slot mask $K$90 and a head mask $K$91, both $K$92-bit masks encoded in machine words. The best-priority order is located by a hardware-assisted count-leading-zeros or count-trailing-zeros operation:

$K$93

Insertion finds a free slot by $K$94 and updates masks in $K$95; deletion marks the slot free and clears its head bit. If a PIN is full, the system performs a bounded relocation cascade of at most $K$96 hops to adjacent PINs, each hop comprising a single-slot move and single-bit update, so worst-case work remains $K$97. The paper formalizes this as

$K$98

in contrast to

$K$99

The design therefore decouples logical price-time priority from pointer-heavy physical storage (Yoon, 31 May 2026).

Neighbor-aware tree maintenance addresses the fact that in matching engines the in-order predecessor and successor of an inserted price are often already known. Given a price $=K$00 and neighbors $=K$01, insertion writes to the unique null child pointer of $=K$02 or $=K$03 in $=K$04, fixes predecessor/successor links in $=K$05, and then performs the standard single-path red-black, AVL, or B/B$=K$06-tree fix-up. Deletion similarly transplants the in-order successor obtained in $=K$07 via $=K$08. The rebalancing cost remains $=K$09, but the search-phase pointer-chasing is eliminated. The paper’s comparison table states that child-pointer writes and rotations are unchanged from conventional approaches, whereas pointer reads drop from $=K$10 to $=K$11 in the splice-location phase (Yoon, 31 May 2026).

Performance claims are centered on high-rate burst ingestion. The abstract states that a single CPU core sustains 32 million order messages per second with sub-microsecond tail latency under multi-million-message-per-second micro-bursts and is 5–11$=K$12 faster than the best available open-source matching engines on the same hardware; a single 96-core instance sustains 640 million messages per second across 10,000 symbols (Yoon, 31 May 2026). The detailed evaluation reports 30–32 M msg/s under a routine 2% mid-price swing and 33 M msg/s under a controlled zero-drift static price, corresponding to roughly 31 ns/order and 30 ns/order, respectively (Yoon, 31 May 2026).

The full-pipeline ingress-to-egress latency measurements, using 301,162 samples with OS outliers removed, are $=K$13 ns, $=K$14 ns, $=K$15 ns, $=K$16 ns, $=K$17 ns, $=K$18 ns, and maximum 626 ns. The histogram is described as multi-modal in a manner aligned with L1/L2/L3 cache-hit tiers. Multi-symbol single-core throughput decreases as the symbol count rises from 1 to 10,000, moving from 31.95 M msg/s to 9.89 M msg/s, or from 31.2 ns/order to 101.1 ns/order. At the instance level, one 96-core node with 10,000 symbols and a Zipf($=K$19) mix reaches 643.6 M msg/s median (Yoon, 31 May 2026).

Implementation details emphasize memory layout and hardware locality. Each slot stores an order descriptor of approximately 32–40 B; freeMask and headMask are 64-bit words aligned to 64 B cache lines; the base pointer and masks are co-located on the same cache line; and all integer arithmetic is unrolled and branch-free. The paper also introduces depth-aware node capacity $=K$20, with an analytical trade-off

$=K$21

leading to

$=K$22

rounded for the hottest levels and reduced toward minimal capacities of approximately 4–8 in colder nodes. The conclusion identifies shard-per-core shared-nothing deployment, L1-resident hot prefixes, and removal of external stateful checks from the critical path as architectural principles of burst tolerance (Yoon, 31 May 2026).

7. BurstEngine for training Transformers on sequences beyond $=K$23 tokens

In "BurstEngine: an Efficient Distributed Framework for Training Transformers on Extremely Long Sequences of over 1M Tokens," BurstEngine is a distributed long-context training framework for LLMs and related Transformer models (Sun et al., 24 Sep 2025). Its stated purpose is to address low Model FLOPs Utilization and large memory overheads that arise when sequence lengths and GPU counts increase, particularly beyond 1M tokens. The system is organized around four techniques: BurstAttention, sequence-level selective checkpointing, fused language-model head with loss, and workload-balance optimization for sparse attention masks (Sun et al., 24 Sep 2025).

BurstAttention replaces RingAttention-style context parallelism with a ring-based distributed attention whose main contribution is lower backward communication. With $=K$24 total tokens, embedding dimension $=K$25, and $=K$26 GPUs, queries, keys, and values are partitioned into local blocks of size $=K$27. A naïve backward ring circulates $=K$28 and their gradients, costing $=K$29 tokens of communication per GPU. BurstAttention algebraically rewrites the softmax-gradient computation so that the circulating objects are instead $=K$30, $=K$31, $=K$32, $=K$33, and $=K$34, producing total backward communication

$=K$35

which the paper describes as about 25% less than $=K$36 (Sun et al., 24 Sep 2025).

The framework also makes communication topology explicit. On multi-node systems, BurstAttention splits the global ring into intra-node and inter-node sub-rings, with per-message times

$=K$37

The paper compares total forward-plus-backward ring times for RingAttention, DoubleRingAttention, and BurstAttention, and states that BurstAttention achieves lower latency overall because it both reduces one full backward circulation and exploits separate intra-/inter-node overlap. Its runtime implementation uses three buffers on separate CUDA and NCCL streams to overlap compute, intra-node communication, and inter-node communication; the paper states that this hides more than 90% of ring latency when $=K$38 is sufficiently large and compute bandwidth is comparable to network bandwidth (Sun et al., 24 Sep 2025).

Memory reduction is addressed first by sequence-level selective checkpointing. Instead of storing or recomputing entire sequence-level activations uniformly, the method splits a length-$=K$39 sequence into two halves, stores the second half’s layerwise activations, and recomputes only the first half on the backward pass. The summary states that this yields memory

$=K$40

with empirical memory about 50% below SelectiveCheckpointing++ and only 5–10% FLOP overhead (Sun et al., 24 Sep 2025). Second, the fused LM head avoids materializing an $=K$41 logits matrix. Instead, hidden states and vocabulary weights are tiled, log-sum-exp is accumulated online, cross-entropy is computed immediately, and gradients are propagated tilewise. The paper states that memory then scales with tile sizes rather than $=K$42, saving up to 30–40 GB on large vocabularies at zero extra end-to-end cost (Sun et al., 24 Sep 2025).

Sparse attention introduces a separate load-balancing problem. With a binary mask $=K$43, BurstEngine seeks a partition of queries into $=K$44 groups that minimizes the maximum per-GPU attended-token product,

$=K$45

subject to covering all tokens with approximately equal group sizes. The paper mentions striped and zigzag assignments for causal attention and states that the general optimization can be cast as an integer program and solved greedily in $=K$46 (Sun et al., 24 Sep 2025).

The performance evaluation uses 7B and 14B LLaMA-style models on A800 GPUs with PyTorch FSDP and BMTrain-related infrastructure (Sun et al., 24 Sep 2025). On 32$=K$47A800 with 1M-token sequences, the framework reports $=K$48 end-to-end speedup on 7B and $=K$49 on 14B relative to the best baseline, LoongTrain-USP. Memory savings are reported as up to 26.4% on 7B/1M and 24.2% on 14B/1M. Attention micro-benchmarks on 32$=K$50A100 with 40 heads at 1M tokens show BurstAttention outperforming USP by $=K$51 and DoubleRing by $=K$52. An ablation reports that removing backward-communication optimization loses 5% throughput, removing the topology-aware ring loses another 8%, removing LM-head fusion costs 15 GB with no speed loss, and removing selective checkpointing doubles activation memory; full BurstEngine is reported as giving $=K$53 net speed relative to a version without these optimizations and reducing peak memory by 15% (Sun et al., 24 Sep 2025).

The implementation is described as approximately 35 K lines of Python, C++, and CUDA, built on PyTorch FSDP, a BMTrain fork, and NCCL multi-stream, with support for flags such as --burst_attention, --seq_select_ckpt, --fuse_lm_head, and --topo_ring, and dependencies including PyTorch 2.1+, NCCL 2.18+, BMTrain 0.4, and CUDA 11.8/12.1 (Sun et al., 24 Sep 2025). In this usage, BurstEngine is not a burst generator but a system for sustaining efficiency under the bursty communication, memory, and imbalance structure induced by extreme sequence lengths.