EAGLE CORP

15 min readEagle Team

Introducing EAGLE-4: One Flexible Drafter for All Batch Sizes and Hardware

From single requests to busy servers, on GPUs and local CPUs. One trained EAGLE-4 drafter per target model reaches 2.74× vanilla throughput on Nemotron 3.5 Super VL for one request and 1.69× at 512 concurrent requests.

  • EAGLE-4
  • Speculative Decoding
  • Source Available
  • Benchmarks
  • NVIDIA
  • AMD
EAGLE-4 is here. Inference, at full speed.

Today we're launching EAGLE-4: One Flexible Drafter for All Batch Sizes and Hardware. One trained drafter per target model adapts from single requests to busy servers, across GPUs and local CPUs.

EAGLE-4 builds on EAGLE-1, EAGLE-2 and EAGLE-3 with hardware-aware control over drafting and a more efficient LM head. One trained drafter per target model adapts its speculation budget to the hardware and workload, from a single request to a server handling hundreds at once.

On NVIDIA Nemotron 3.5 Super VL, EAGLE-4 reaches 647 tokens/s for one request and 33,480 aggregate tokens/s at 512 concurrent requests: 2.74× and 1.69× vanilla throughput, respectively. Both measurements use four NVIDIA B300 GPUs, TP4, at temperature 0.

EAGLE-4 Is Here. GitHub (opens in a new tab) · Paper (opens in a new tab) · eagle.ai (opens in a new tab)

Addressing AI's infrastructure bottleneck

One of AI's biggest bottlenecks is the gap between demand for inference and the compute and electrical power available to deliver it. Reasoning models and multi-step agents raise the work required per task, while operators face long lead times for new hardware, power equipment and grid connections.

The scale is measured in trillions: at Dell Technologies World 2026, Michael Dell projected that worldwide AI infrastructure spending could reach $3–4 trillion by 2030 (opens in a new tab). The IEA's 2026 analysis (opens in a new tab) describes tightening bottlenecks in energy supply chains and advanced chip manufacturing, alongside slow grid connections that constrain new data centre capacity.

Meanwhile, the installed base faces a moving performance target. Each new model generation and more demanding workload raises expectations for hardware already in service. Operators need to keep that investment productive as newer accelerators arrive.

EAGLE-4 addresses the software side of this capacity problem. It reduces repeated target-model execution and adapts drafting to the hardware and workload, helping supported deployments produce more useful output from available compute. Our goal is to extend the productive life of existing infrastructure and improve the return on new systems, with gains measured in throughput, response time and, in the phone evaluation, energy per token.

Qwen: one drafter from 1 to 512 requests

The paper evaluates the same trained Qwen3.8-27B drafter at concurrency 1 and 512. EAGLE-4 reaches 863.8 tokens/s for a single request and 28,340 aggregate tokens/s at 512 concurrent requests. The four-way comparison below uses the same inference engine with MegaKernel disabled for every method.

Table 1. Matched Qwen3.8-27B comparison

Method1 request (tokens/s)512 requests (aggregate tokens/s)
Vanilla240.521,203
DSpark618.614,229
DFlash 2672.616,641
EAGLE-4863.828,340

SPEED-Bench qualitative; 4× NVIDIA B300, TP4, T=0, same engine, MegaKernel disabled. The 512-request column reports aggregate tokens/s. Source: paper, Table 2.

Grouped bar chart of throughput relative to vanilla at concurrency 1 and 512. Vanilla: 1.00× and 1.00×. DSpark: 2.57× and 0.67×. DFlash 2: 2.80× and 0.78×. EAGLE-4: 3.59× and 1.34×.
Figure 1. Vanilla, DSpark, DFlash 2 and EAGLE-4 at concurrency 1 and 512. Throughput is relative to vanilla at the same concurrency. Qwen3.8-27B on SPEED-Bench qualitative; 4× NVIDIA B300, TP4, T=0, 4,096-token output limit. Same engine, MegaKernel disabled. Source: paper, Table 2.

At concurrency 1, EAGLE-4 delivers 3.59× vanilla, 1.28× DFlash 2 and 1.40× DSpark throughput. At concurrency 512, those gains are 1.34×, 1.70× and 1.99×, respectively. The high-concurrency rates measure total output across all requests.

Both settings use the same trained drafter. EAGLE-Harness changes the runtime drafting configuration as the cost of speculation changes with load.

Accelerating NVIDIA Nemotron

On NVIDIA Nemotron 3.5 Super VL, the 120B-A12B target model, EAGLE-4 reaches 2.74× vanilla throughput for a single request. At 512 concurrent requests, it sustains 33,480 aggregate tokens/s, a 1.69× gain over vanilla decoding.

Table 2. Nemotron 3.5 Super VL throughput

Concurrent requestsVanilla tokens/sEAGLE-4 tokens/sSpeedup
12366472.74×
51219,82333,4801.69×

SPEED-Bench qualitative, four NVIDIA B300 GPUs, TP4, temperature 0 and a 4,096-token output limit. Rates are end-to-end; the 512-request row reports aggregate throughput. Source: paper, Table 3.

The throughput gains extend beyond Qwen to a large mixture-of-experts target. EAGLE-4 adjusts the amount of speculative work while keeping the target-model weights unchanged.

Day-0 acceleration on AMD Instinct MI350X

The AMD team provided day-0 support and evaluated EAGLE-4 on a single AMD Instinct MI350X GPU with tensor parallelism 1. On a 117-turn SPEED-Bench workload, single-request throughput rises from 75.27 to 262.89 tokens/s, a 3.49× speedup over vanilla decoding.

The gains persist across every tested concurrency from 1 to 32. At 16 concurrent requests, EAGLE-4 delivers 2.30× vanilla throughput. At 32, it reaches 2,360.83 aggregate tokens/s versus 1,390.52 for vanilla, a 1.70× improvement. The evaluation caps each request at 4,096 newly generated tokens.

Bar chart of end-to-end tokens per second for vanilla and EAGLE-4 at 1, 2, 4, 8, 16 and 32 concurrent requests on an AMD MI350X. EAGLE-4 speedups: 3.49×, 3.32×, 2.90×, 2.54×, 2.30× and 1.70×.
Figure 2. Throughput on one AMD Instinct MI350X, TP1, using 117 SPEED-Bench turns selected with every=10. Labels show speedup over vanilla at the same concurrency. The output limit is 4,096 new tokens per request. Source: paper, Table 4 and Section 4.2.

EAGLE-4 on TokenSpeed

SPEED-Bench performance versus the SGLang reference

The benchmark reported in PR #3 (opens in a new tab) reaches 961.6 tokens/s for a single request at temperature 0, versus 837.6 tokens/s for the bundled SGLang reference: a 1.15× speedup. Both implementations run EAGLE-4 with the same EAGLE-Harness dynamic tree. TokenSpeed is faster in all three reported configurations, with similar mean accepted lengths.

The comparison uses the same machine, day, client and data: four NVIDIA B300 GPUs, TP4, Qwen3.8-27B in BF16, and the same EAGLE-4 drafter. Both runs use a 12/4/16 dynamic tree, execution mode 0, the high_intensity setting and shared profiled cost data.

Table 3. TokenSpeed versus the bundled SGLang reference

SettingTokenSpeed tok/s (accept)SGLang ref. tok/s (accept)Speedup
T=0, C=1961.6 (4.745)837.6 (4.784)1.15×
T=0, C=83,935.7 (4.231)3,615.7 (4.248)1.09×
T=1, C=1734.2 (3.598)608.8 (3.653)1.21×

Both using EAGLE-4. Parentheses show mean accepted length per verification round; C is request concurrency. At C=8, throughput is aggregate. Source: PR #3 benchmark.

Three bar-chart panels comparing the SGLang reference with TokenSpeed in tokens per second. T=0, C=1: 837.6 vs 961.6 (1.15×). T=0, C=8: 3,615.7 vs 3,935.7 (1.09×). T=1, C=1: 608.8 vs 734.2 (1.21×).
Figure 3. EAGLE-4 throughput on TokenSpeed and the bundled SGLang reference. Same-machine Qwen3.8-27B BF16 tests on 4× NVIDIA B300, TP4; 88 SPEED-Bench conversations, 117 turns. The panels use separate scales; C=8 rates are aggregate. Source: PR #3.

The multi-turn SPEED-Bench test uses 88 conversations and 117 turns, thinking enabled with xhigh reasoning effort, up to 4,096 tokens per turn and seed 721. Throughput is generated tokens divided by wall-clock time. The PR reports bitwise regression checks against TokenSpeed before the changes on the tested prompts, plus matching host/device EAGLE-Harness policy outputs at temperatures 0 and 1.

Long-context results

The TokenSpeed team completed day-0 integration and measured Qwen3.8-27B in BF16 with an EAGLE-4 drafter on four NVIDIA B300 GPUs, TP4, using one request at a time.

Single-request decode throughput stays between 759 and 822 tokens/s across contexts from 32K to 250K tokens: 759 at 32K, 822 at 128K and 761 at 250K. Time to first token is 0.55, 2.1 and 5.7 seconds, respectively.

Two bar-chart panels by context length. Decode throughput: 759 tokens/s at 32K, 822 at 128K and 761 at 250K. Time to first token: 0.55 s at 32K, 2.1 s at 128K and 5.7 s at 250K.
Figure 4. Long-context measurements by the TokenSpeed team. Qwen3.8-27B in BF16 with an EAGLE-4 drafter; 4× NVIDIA B300, TP4, single request. The panels show decode throughput and time to first token in separate units. Source: paper, Table 7 and Section 4.5.

Useful speedups on a 4-vCPU server

For local inference, we evaluated 4-bit Gemma-4-E2B-it on an AWS c5.xlarge instance with 4 vCPUs and 8 GB RAM, using llama.cpp. EAGLE-4 improves throughput across coding, mathematical reasoning and open-ended conversation.

Table 4. CPU throughput, single request

BenchmarkVanilla tokens/sEAGLE-4 tokens/sSpeedup
GSM8K17.249.32.87×
MATH-50016.748.82.92×
HumanEval16.645.82.76×
MT-Bench17.239.32.28×

Single request at temperature 0. The target-model weights and hardware are the same for both methods. Source: paper, Table 5.

The mean of the four benchmark speedups is 2.71×. In the same evaluation, EAGLE-3 delivers 1.25×–1.65× vanilla throughput; EAGLE-4 raises that range to 2.28×–2.92×.

Grouped bar chart of output tokens per second for vanilla, EAGLE-3 and EAGLE-4. GSM8K: 17.2, 27.6, 49.3. MATH-500: 16.7, 27.5, 48.8. HumanEval: 16.6, 25.3, 45.8. MT-Bench: 17.2, 21.5, 39.3.
Figure 5. Throughput across four benchmarks for 4-bit Gemma-4-E2B-it. AWS c5.xlarge with 4 vCPUs and 8 GB RAM; llama.cpp, single request, T=0. Values are output tokens per second. Source: paper, Table 5.

Fast inference on a phone CPU

We then ran the same Gemma target and drafter on an unmodified, non-rooted Motorola Razr 70 Ultra. The device has a Snapdragon 8 Elite, eight CPU cores and 16 GB RAM. The full inference stack runs on the CPU through llama.cpp using six threads.

Left: generation throughput in tokens per second, HumanEval 82.6 with EAGLE-4 vs 22.8 vanilla, long form 74.7 vs 23.3. Right: long-form energy at the USB input, 356 mJ per generated token for vanilla vs 166 for EAGLE-4.
Figure 6. 4-bit Gemma-4-E2B-it on the Motorola Razr 70 Ultra CPU, single request, temperature 0 and a cool device. Energy is measured at the USB input during the long-form test. Source: paper, Table 6 and Section 4.4.

On HumanEval, throughput rises from 22.8 to 82.6 tokens/s, a 3.62× speedup. Long-form generation rises from 23.3 to 74.7 tokens/s, or 3.21× vanilla. Time to first token on HumanEval falls from 1.2 seconds to 0.8 seconds.

In the long-form test, energy per generated token drops from 356 to 166 mJ, a 53.4% reduction measured at the USB input. The generation completes in 14 seconds instead of 43, finishing before thermal throttling begins. These throughput measurements start with a cool device; the paper discusses throttling during longer continuous runs.

Left: HumanEval time to first token, 1.2 s vanilla vs 0.8 s EAGLE-4. Right: long-form generation time, 43 s vanilla vs 14 s EAGLE-4.
Figure 7. Response latency for 4-bit Gemma-4-E2B-it on the Motorola Razr 70 Ultra CPU; single request, T=0, cool device. Time to first token uses HumanEval; generation time uses the long-form test. Panels use separate scales. Source: paper, Table 6 and Section 4.4.

A small memory footprint

The Gemma EAGLE-4 drafter occupies 134 MB. Total additional resident memory during generation, including its KV cache and computation buffers, is 0.27 GB on the CPU server and 0.26 GB on the phone.

The Qwen drafter also uses a single Transformer layer. The paper's Table 1 reports 0.44B Transformer-layer parameters for EAGLE-4, compared with 1.66B for DFlash 2 and 1.65B for DSpark, each with five layers. These counts exclude feature fusion, token embeddings and output-vocabulary layers.

The phone implementation also optimizes the ARM CPU path with a persistent thread pool, vector arithmetic and a small-batch verification attention kernel. Together with the output-head changes, the reported optimizations reduce draft-step latency from 8.7 ms to 3.9 ms.

What changed in EAGLE-4

EAGLE-Harness adapts speculation to its cost

A draft tree that is useful at low concurrency can become expensive under load. Wider or deeper trees may accept more tokens, but they also add drafting and verification work. EAGLE-Harness accounts for both costs when deciding how far to speculate.

A warm-up profiles the draft and target models across batch sizes, context lengths and speculative token counts. Those measurements are cached in lookup tables. During generation, EAGLE-Harness combines the cost estimates with draft confidence to choose tree depth, width and verification budget.

Autoregressive drafting makes these decisions possible before the next draft step is executed. Each branch can use its own drafted prefix to decide whether further work is worthwhile. The objective is the expected number of useful tokens advanced per unit of drafting and verification cost.

EAGLE Efficient LM Head reduces drafting overhead

In the paper's profiled configuration, computing full-vocabulary logits accounts for 65.4% of a 574 μs draft forward pass. EAGLE Efficient LM Head reduces that cost in two stages: a low-rank head retrieves candidates across the full vocabulary, then the original full-rank head computes exact logits for the shortlisted tokens.

The candidate set changes with the hidden state, allowing retrieval across the full vocabulary at each step. The full LM head is retained, and its selected rows supply the final candidate scores.

Left: total draft-forward latency, 574 μs with the full head, 326 μs at rank 512 and 255 μs at rank 128. Right: LM-head share of draft time, 65.4%, 37.9% and 17.9%.
Figure 8. Total draft-forward latency and LM-head share in the paper's profiled configuration. Rank 512 reduces total draft-forward latency by 43.2%; rank 128 reduces it by 55.6%. Source: paper, Figure 2 and Section 3.2.

Attention and cache management for long contexts

The design also addresses long-context drafting costs. It considers sparse and sliding-window attention to limit how much history each draft step processes, and uses append-only cache updates within each drafting phase. The drafter's feed-forward architecture is aligned with the target model, balancing generalization, memory and training cost.

The evolution from EAGLE-1 to EAGLE-4

EAGLE-4 is the next step in a research programme that began with EAGLE-1 in January 2024. As documented on eagle.ai (opens in a new tab) and in the linked papers, each generation has addressed a different constraint on inference acceleration.

EAGLE-1 (January 2024): drafting from model features

The original EAGLE introduced feature-level autoregression: a lightweight drafter predicted the target model's internal features, then used its LM head to propose tokens. A token sequence shifted one step ahead helped resolve uncertainty in feature prediction. This established the foundation for efficient drafting with target-model verification.

EAGLE-2 (June 2024): context-aware draft trees

EAGLE-2 made the draft tree adaptive. It used draft confidence to estimate which tokens were likely to be accepted, then adjusted the tree structure to the current context. This increased accepted work per verification pass without training a separate model to predict the tree.

EAGLE-3 (March 2025): scaling draft quality with data

EAGLE-3 moved from feature prediction to direct token prediction and combined features from multiple target-model layers. Its training-time test procedure exposed the drafter to its own multi-step predictions during training. These changes let the drafter benefit more from larger training datasets, with evaluation across both chat and reasoning models.

EAGLE-4: adapting to execution cost

EAGLE-4 carries this progression into serving conditions. EAGLE-Harness chooses drafting depth, width and verification budget using profiled costs and draft confidence, while EAGLE Efficient LM Head reduces vocabulary-scoring overhead. The focus is useful acceleration across request loads and hardware with one trained drafter per target model.

The EAGLE family already appears in inference work from NVIDIA, Meta and Perplexity. With EAGLE-4, we're extending that research toward a wider range of serving loads and devices, while keeping a lightweight, single-layer Transformer drafter.

Benchmark setup

The paper's NVIDIA GPU comparisons use the SPEED-Bench qualitative split, four NVIDIA B300 GPUs, tensor parallelism 4 and a maximum output length of 4,096 tokens. The Qwen comparison uses the same inference engine with MegaKernel disabled. Its concurrency-512 evaluation repeats the dataset four times, producing 3,520 conversations to keep the batch full. EAGLE-4 uses a 12-4-16 tree at concurrency 1 and a 15-1-16 chain at concurrency 512.

The paper's headline NVIDIA GPU comparisons, CPU tests and phone tests use temperature 0. At temperature 1, its Qwen comparisons reach 2.59× vanilla at concurrency 1 and 1.03× at concurrency 512; Nemotron reaches 2.40× and 1.51×, respectively. The newer TokenSpeed integration table includes both T=0 and T=1; its SGLang reference also uses EAGLE-4. Speedup depends on the model, workload and sampling configuration.

The CPU and phone evaluations use 4-bit Gemma-4-E2B-it, llama.cpp and a single request at temperature 0. Phone throughput is measured on a cool device. Energy figures refer specifically to the long-form test and are measured at the USB input.

The target-model weights stay unchanged. With exact greedy verification at temperature 0, the accepted draft prefix matches the target model's greedy predictions, preserving its output.

Thank you to our collaborators

Thank you to our partners NVIDIA, AMD, GMI Cloud, LightSeek, fal, Fireworks, vLLM, SGLang, and others, and to the researchers, engineers and contributors helping bring EAGLE-4 to developers.

Explore the release

EAGLE-4 Is Here. Read the paper, explore the implementation and evaluate it on your own models, hardware and request loads.

If you're building an inference platform or an on-device application, we'd like to hear what you're running and what you build with EAGLE-4.