Repository navigation
[Scheduler] Fuse fixed-depth decode loops into one submission, keeping the per-loop prefill share - #148
Draft
0z5a wants to merge 1 commit into
Draft
[Scheduler] Fuse fixed-depth decode loops into one submission, keeping the per-loop prefill share#1480z5a wants to merge 1 commit into
0z5a wants to merge 1 commit into
Conversation
…g the per-loop prefill share A fixed-depth decode row runs all its remaining loops in one RECURRENT submission (one graph replay per loop, no host round trip in between) when every row of the batch has a fixed depth on the LAST_EXITED layout; rows with an adaptive exit, trace exits or the SHARED layout keep per-loop boundaries. Fused submissions use the real row count under padded static buffers (the first loop's device KV view and the later loops' host views must agree). A fused step is L loops long, and the refill policy admitted max_prefill_batches_before_decode prompt batches per decode step, so prompt work got 1/L of its share and TTFT grew under load. After a decode submission that fuses L loops the policy now allows L times the configured prompt batches (SchedulerConfig.prefill_share_per_loop, default on). Each row's arithmetic is unchanged; batches can differ from unfused execution (rows no longer stagger across loop phases), so bf16 GEMMs can pick other algorithms at high load. RTX 5090, Ouro-1.4B, 512-token prompts, 128 output tokens, async + graphs: submissions per token: 6.0 -> 3.0 (batch 1); throughput 0.99x at batch 1, 1.09x at 32 and 128 requests; 160/169 requests identical (all at <= 8). Huginn-0125 (32 loops): 33.5 -> 3.0 submissions per token, 1.10-1.12x. GSM8K 87-question subset (serial): 87/87 token sequences and exit depths identical; real-text prompts 41/41 identical. GH200, Ouro-1.4B, prefill share on vs off: burst, 32 requests (2 kept runs): 877 -> 1001 tok/s, TTFT p50 1.11 -> 0.82 s, TPOT p50 25.9 -> 22.8 ms. 64 agent sessions, 6 turns (two pairs of runs): TTFT p50 10.26 -> 2.64 s and 9.69 -> 2.47 s, TPOT p50 0.50 -> 1.19 s and 0.46 -> 1.18 s, throughput 62.8 -> 60.2 and 67.4 -> 56.7 tok/s. For sessions the share trades time per token for time to first token; prefill_share_per_loop=False restores the fused-only behaviour. Signed-off-by: 0z5a <dezhen.lu@student.uni-tuebingen.de> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
A fixed-depth decode row now runs all its remaining loops in one RECURRENT submission (one graph replay per loop, no host round trip between loops) when every row of the batch has a fixed depth on the LAST_EXITED layout. Rows with an adaptive exit, trace exits or the SHARED layout keep per-loop boundaries. Fused submissions use the real row count under padded static buffers (the first loop's device KV view and the later loops' host views must agree; this caused a rotary row mismatch in the static+padded async GPU tests before the fix).
A fused step is L loops long, and the refill policy admitted
max_prefill_batches_before_decodeprompt batches per decode step, so prompt work got 1/L of its share and TTFT grew under load. After a decode submission that fuses L loops the policy now allows L times the configured prompt batches (SchedulerConfig.prefill_share_per_loop, default on).Each row's arithmetic is unchanged. Batches can differ from unfused execution (rows no longer stagger across loop phases), so bf16 GEMMs can pick other algorithms at high load and a few greedy sequences change there.
Measurements
RTX 5090, Ouro-1.4B, 512-token prompts, 128 output tokens, async + graphs, one run per level:
GH200, Ouro-1.4B, prefill share on vs off:
For bursts the share helps on every metric. For sessions it trades time per token for time to first token;
prefill_share_per_loop=Falserestores the fused-only behaviour. Without fusion,mainhad TTFT p50 1.41 s and TPOT p50 1.30 s at 64 sessions (separate run).Platforms. GH200: torch 2.14.0+cu130, Triton 3.8.0, NIXL 1.4.1. RTX 5090: torch 2.13.0+cu130, Triton 3.7.1. Models: Ouro-1.4B (24 layers, 4 loops, fixed depth) and Huginn-0125 (2 prelude + 4 recurrent + 2 coda layers, 32 loops). Burst workloads issue C requests at once with random-token prompts; session workloads replay multi-turn agent traces with the prefix cache on.
Tests
pytest --run-gpu tests/test_engine.py tests/test_async_pipeline.py tests/test_input_preparation.py tests/test_cuda_graph.py): 137 passed. Without FlashAttention installed, the FlashAttention tests failed at import on this branch and onmain(66920da) alike.Notes
The GPU numbers come from a development branch that contains all changes of this series; most cells are single runs, and on the shared GH200 host two runs of
mainat 32 requests differed by up to 16%, so smaller differences are ties. This branch alone was checked with the CPU suite, ruff and the GPU tests above.Series. Draft PRs from one study of serving looped models. They are independent except #152, which is stacked on #147; several touch the same files, so later ones may need a rebase after earlier ones merge.