holy sh*t… REA now runs as a team on Opus 5.5.
Stop asking AI how an app works, make it open the binary and show the evidence
→ Opus 5.5 leads and reads every evidence ID
→ Sonnet 5.5 workers take one question each
→ REA returns the function, file and line
Sonnet probes, opus judges, the oracle doubts.
paste this into Opus 5.5 with REA installed:
"Use REA to investigate how {{FEATURE}} works in {{APP}}.
Sonnet workers probe, you judge. Tag every claim observation, inference or unknown"
A tricky LLM interview question:
You move your LLM to a faster GPU.
Profiling confirms its kernels now finish sooner, but the time between generated tokens barely changes.
The model, precision, and batch size are identical.
Where did the expected speedup go?
(answer below)
An LLM forward pass is not one giant GPU operation.
It launches a sequence of operations for attention, matmul, normalization, sampling, data movement, and other work.
Without CUDA Graphs, the CPU prepares and submits these operations individually.
Each launch adds only a small amount of overhead, but token-by-token decoding repeats a similar sequence for every generated token.
This creates a strange bottleneck.
Some kernels finish in only a few microseconds. The GPU can complete one kernel before the CPU has submitted the next one.
That leaves empty spaces in a profiler trace. These gaps are not model computation. They show the GPU waiting for its next operation.
CUDA Graphs change how this work reaches the GPU.
The runtime captures a repeatable sequence of operations once, including their dependencies. Later iterations replay the captured sequence through one graph launch instead of submitting every operation separately.
To be clear, the kernels themselves do not become substantially faster.
Also, the model does not get smaller, and the forward pass performs almost the same computation.
Most of the gain comes from removing CPU launch work between kernels.
This is especially useful during LLM decoding.
Each decoding step processes one new token per sequence. This produces many short, repeated GPU operations where launch overhead can become a meaningful part of total latency.
Prefill often behaves differently.
A large prompt gives the GPU more parallel work, producing longer-running kernels. When those kernels already keep the GPU busy, reducing launch overhead matters less.
There is also a tradeoff.
A captured graph expects the same kernel sequence, stable arguments, fixed memory addresses, and a compatible execution structure on every replay.
Inference servers handle varying batch sizes and different prefill, mixed, and decode workloads. One captured graph cannot cover every execution path efficiently.
Engines such as vLLM and TensorRT-LLM therefore capture graphs for several common execution cases and batch sizes.
When a live batch does not match a captured size, the engine may use eager execution or pad the batch to a captured size.
Capturing more sizes improves graph coverage, but it also consumes more GPU memory and increases startup time.
So CUDA Graphs are not a universal inference speed switch.
They trade flexibility and setup cost for lower steady-state launch overhead.
The visual below shows the core mechanism.
- Without a graph, the CPU submits each kernel independently and may leave idle gaps on the GPU timeline.
- With a graph, the sequence is captured once and replayed as a unit.
CUDA Graphs are one example of why LLM inference needs a specialized serving engine rather than a standard prediction API.
The post quoted below explains five architectural differences between traditional ML inference and LLM inference.
Read it below.