Performance

This run was captured in user mode: the app recorded the request as it saw it, and the trace levels beneath it — phases, model anatomy, transformer block, runtime graph, kernels and GPU timeline — are absent by depth, each with the bundle's reason.

This is a guide through the recorded stack, not a measurement. Its arrows show the conceptual path a request takes; they do not assert a measured dependency or a timing join, and the moving dot shows direction, never speed. Every value in a step is read from the bundle with its label; open a step for its lens.

No scenario description is included with this page for this capture. Its identity and measurements are shown from the selected bundle.

Everything this run could not measure, with the bundle's own reason. Entries that share a reason and a pointer pattern are grouped; open a group for its full list of pointers. The same reasons appear again in the lens where each value would have been.

Request timing

The first token separates the wait to begin from the time spent generating. The timeline below uses the request clock; runtime counters and trace timings remain distinct.

The request as the application saw it, on the request clock, whose origin is the request's start — so the first token's time is the time to first token. The bar splits the request into the hand-off to the runner, the runner's first encode to the first token, and the first token to the end of generation; a segment the bundle has no duration for shows its endpoints only. The prompt token counter is reported by the runtime and includes the cached prefix tokens served from the cache.

Prefill and decode passes

Each column is a pass. Select one to carry it into the GPU timeline. Chunk-arrival ticks use the request clock; the alignment details explain the join.

The rhythm of the passes: one prefill pass, then one decode pass per generated token, each drawn to its period. The streamed chunks sit on the request clock beneath them, and the clock join says how the trace clock was aligned to the request clock.

Read the model from its recorded tensors: the structure, projection dimensions and weight storage. Select a layer in the byte stack to explore its runtime block, or a tensor to inspect its evidence.

• The arrows explain the structure. They are conceptual connections, not captured dependency edges.
• The output dimension of each recorded projection tensor, drawn on the same scale.
• Select a decoder block to open its runtime nodes. Each width follows that layer's recorded bytes, including differences in quantization.

Where one token's bytes are: each layer's weight tensors, by their size in the model file. The structure, the projection widths and the stack are drawings; every value they draw is shown with its label beside them, in their hover text, and in the tensor byte map and its source table, which hold the totals and the byte shares. The byte shares are shares of the model file, never shares of kernel time.

Follow attention and the feed-forward network through one decoder layer. Select an operation group to inspect its recorded nodes, tensor shapes and kernels.

• Each box groups recorded nodes. The connections are schematic: this bundle records the encode order, not dependency edges, and a group does not imply that the runtime fused its operations.
• Select a box to list its recorded nodes in the inspector below, each with its kernel mapping and its own provenance. Tensor dimensions describe stored weight tensors.
• These nodes are kept apart because the schematic does not establish their connections.

One layer's nodes in execution order, by op family, each with its kernel and, where it reads a weight tensor, that tensor's shape and type from the model file. Nodes that belong to no layer are listed on their own, with the bundle's reason.

The schematic is drawn only when the layer's recorded operations match a decoder block's pattern, read from each node's operation and the weight tensor it reads; a layer that does not match shows its recorded nodes instead. Each node card is one recorded node in encode order, its edge marking its family: a matrix multiplication, a normalization, or another operation.

Runtime graph nodes

Filter the graph by layer, operation, kernel or provenance. A node's kernel mapping may be inferred even when its name and operation were measured.

Every node of the runtime graph and the kernel it maps to, with the label of that mapping. The runtime numbers its nodes inside each subgraph, counting fused ops; the page derives that index from the bundle's own node list.

Shader interval counts

Bars compare recorded shader-interval counts. They do not represent kernel duration or time share. Select a kernel to see its candidate nodes and intervals.

The kernels the trace recorded, with the number of intervals the instrument counted for each over the whole run, and the graph nodes each kernel joins. A kernel no node names is reported as unjoined. The timeline is sparse, so the page shows no kernel share and no per-kernel sum.

CPU and GPU timeline

Select an encode interval, GPU segment or shader tick to inspect its associated evidence. Hatched regions are unrecorded shader time; missing GPU intervals keep their stated reason.

The selected pass's command buffers: each one's CPU encode and its GPU execution, segment by segment, with the shader rows the timeline recorded drawn inside the buffer that holds them. The GPU time the timeline did not record is marked as not recorded.

• Projection widths do not identify the number of attention heads or the width of each head. Those values are not explicit in this bundle.
• Attention and FFN are subtotals within the decoder blocks. These are stored tensor bytes; CPU and GPU residency and the KV-cache allocation are not supplied here.
• Only the selected bundle supplies this view. Tokenizer details and the vocabulary size are unavailable here; no external model file is opened.

A proportional stack needs a recorded byte count for the token embedding, every decoder layer and the output head. These bytes are missing, so no stack is drawn; the recorded values remain in the source table.

The listed components add up to more than the recorded model total, so the bytes in no listed component are negative. The stack scales the listed components only.

This layer's recorded operations do not match the decoder block's pattern, so no schematic is drawn. Its recorded nodes follow in encode order, each with its kernel and the tensor it reads.

Derived from the bundle, beneath the lenses: the weight bytes one decode token streams, the mean decode period, and the effective weight bandwidth the two imply. Bytes are in decimal units, a gigabyte being a thousand million bytes. The page carries no published bandwidth of the hardware and no operation rate; the bundle carries neither.

This instrument records no hardware counters, no launch geometry, no per-dispatch timing and no kernel shares, so none appears on the page, as a value or as an absence. This is a statement about every lab capture on this instrument, not an entry of the run's absent list. What it does record is sparse: the shader timeline's coverage of the token under test and of the run is shown below. The reference capture's graph is the decode pass's and its prefill pass recorded no shader row, so no prefill-versus-decode kernel comparison is drawn.

The traversal climbs from one interval on the GPU timeline through its token, its command buffer, its node set, its kernel and its candidate nodes, to their tensors, components and layers, and descends again from a component to the kernels and intervals it ran. Every hop reads a relation the bundle stores and carries that relation's own label. A terminal is a hop the bundle answers by ending the chain; a gap is a hop it does not supply. The table is the token under test, one row per interval.

The token passes when every interval of its pass resolves: no hop of any chain, for any candidate, is a gap.

The trace's count of decode passes disagrees with the runtime's token count: some passes may be misclassified as prefill or decode (spec 03 §5.1). The disagreement is stated, never repaired.

The last pass has no period to divide by, so its GPU busy share is not shown.

Not applicable — the trace levels are absent (capture_mode = user). This is neither a pass nor a gap.

This verdict was computed by the page's script from the bundle loaded from a file, not by the generator from a committed run.