The benchmark harnesses in both repos

Start with the concrete symptom. Run Llama-3-8B on an H100 with EAGLE-style speculative decoding at an acceptance length of 3.5. The engine completes one verify iteration roughly every 7.5 ms and emits integer token counts whose long-run mean is 3.5 per frame. The 7.5/3.5 calculation below is a fluid average, not the median of an actual frame sequence. Now ask the two client harnesses what the inter-token latency was.

Those are derived, not measured: 7.5 ms is an illustrative Llama-3-8B verify step against this book's 4.48 ms batch-1 decode floor plus draft cost, and 2.14 = 7.5 ÷ 3.5 is arithmetic. The point is the ratio, and it comes entirely from a one-line difference in two Python files.

This is not an isolated quirk. The two harnesses also disagree about where the end-to-end clock stops, what counts as a token, whether arrivals are Gamma or exponential, whether failed requests are reported at all, whether the connection is reused, what --random-range-ratio 0.5 means, and which dataset random even is. Every one changes a published number. §1.2 established the metric definitions and the two most damaging divergences; this chapter audits the machinery around them, plus the offline harnesses, the loaders, and the exact commands.

import warnings

from sglang.benchmark.serving import *  # noqa: F401,F403
from sglang.benchmark.serving import cli_main

warnings.warn(
    "`sglang.bench_serving` is deprecated and will be removed in a future "
    "release; use `sglang.benchmark.serving` instead "
    "(e.g. `python -m sglang.benchmark.serving`).",
    FutureWarning,
    stacklevel=1,
)

if __name__ == "__main__":

Every serving benchmark harness is the same four-stage pipeline, and every disagreement between two harnesses is a disagreement inside one of the four stages. A loader turns a dataset plus flags into a list of (prompt, prompt_len, expected_output_len). A load generator decides when each of those is released. A request driver issues the HTTP call, consumes the SSE stream, and stamps timestamps as bytes arrive. An aggregator folds the per-request records into scalars. Nothing else happens.

Stage 1 decides the workload. Stage 2 decides whether you are measuring a queueing system or a batch job. Stage 3 decides how much of the queue is on your laptop instead of on the GPU. Stage 4 decides what a "token" is. Two harnesses that agree on the model, the hardware and the prompts can still disagree on all four, and that is exactly what these two do.

The single most consequential choice a harness makes is whether request $n+1$'s send time depends on request $n$'s completion. It does not, in an open-loop harness: arrivals come from an exogenous process and the queue is allowed to grow without bound. It does, in a closed-loop harness: a fixed population of $C$ virtual clients each sends, waits, and sends again, so offered load is throttled by the system itself.

Neither harness implements a true closed loop. Both are open loop with an optional semaphore, which produces a third thing: an open-loop arrival process feeding a client-side queue. The semaphore is acquired before the request function runs and therefore before st = time.perf_counter(), so the wait is invisible to every reported metric — the failure mode §1.2 spells out. §10.3 owns the methodology argument for which regime to report.

vLLM: an absolute Gamma schedule, normalised

vLLM precomputes the entire arrival schedule before sending anything, samples from a Gamma distribution whose shape parameter is --burstiness, accumulates it into absolute offsets, and then rescales so the last arrival lands exactly at $N/\lambda$:

            else:
                theta = 1.0 / (current_request_rate * burstiness)

                # Sample the request interval from the gamma distribution.
                # If burstiness is 1, it follows exponential distribution.
                delay_ts.append(np.random.gamma(shape=burstiness, scale=theta))

        # Calculate the cumulative delay time from the first sent out requests.
        for i in range(1, len(delay_ts)):
            delay_ts[i] += delay_ts[i - 1]
        if ramp_up_strategy is None and delay_ts[-1] != 0:
# ...
            # NOTE: If we simply accumulate the random delta values
            # from the gamma distribution, their sum would have 1-2% gap
            # from target_total_delay_s. The purpose of the following logic is to
            # close the gap for stabilizing the throughput data
            # from different random seeds.
            target_total_delay_s = total_requests / request_rate
            normalize_factor = target_total_delay_s / delay_ts[-1]
            delay_ts = [delay * normalize_factor for delay in delay_ts]

The generator then sleeps to an absolute deadline measured from a single start_ts:

    start_ts = time.time()
    for request_index, request in enumerate(input_requests):
        if delay_ts[request_index] > 0:
            current_ts = time.time()
            sleep_interval_s = start_ts + delay_ts[request_index] - current_ts
            if sleep_interval_s > 0:
                await asyncio.sleep(sleep_interval_s)
        yield request, request_rates[request_index]

SGLang: yield, then sleep a fresh exponential

    else:
        input_requests_iter = iter(input_requests)
        for request in input_requests_iter:
            yield request

            if request_rate == float("inf"):
                # If the request rate is infinity, then we don't need to wait.
                continue

            # Sample the request interval from the exponential distribution.
            interval = np.random.exponential(1.0 / request_rate)
            # The next request will be sent after the interval.
            await asyncio.sleep(interval)

Three differences fall out of those two blocks. Shape: SGLang is Poisson only; vLLM's $C_a^2 = 1/\text{burstiness}$ is tunable, and Kingman's formula says queueing scales with $C_a^2$, so --burstiness 0.3 triples the arrival-variability term at an unchanged mean rate. Drift: vLLM sleeps to an absolute deadline, so a slow event-loop iteration does not push every later arrival back; SGLang's sleep starts when the consumer resumes, so scheduling jitter and the cost of building each RequestFuncInput accumulate into the realised rate. At 6 req/s over 1,000 requests the target duration is 166.7 s; a systematic 1 ms per-iteration overhead adds 1 s to SGLang's wall clock and nothing to vLLM's. Total duration: vLLM's normalisation removes the 1–2% seed-to-seed variation in $N/\lambda$ the source comment describes; SGLang does not normalise, so its request_throughput — a division by wall-clock duration — carries that variance.

The transport layer: one session versus one session per request

vLLM builds exactly one aiohttp.ClientSession for the whole run and sizes the connection pool to --max-concurrency:

    # Reuses connections across requests to reduce TLS handshake overhead.
    # Use ssl_context if provided, otherwise default to True for https URLs
    ssl_setting = ssl_context if ssl_context is not None else ("https://" in api_url)
    connector = aiohttp.TCPConnector(
        limit=max_concurrency or 0,
        limit_per_host=max_concurrency or 0,
        ttl_dns_cache=300,
        use_dns_cache=True,
        keepalive_timeout=60,
        enable_cleanup_closed=True,
        force_close=False,
        ssl=ssl_setting,
    )

    session = aiohttp.ClientSession(
        connector=connector,
        trust_env=True,
        timeout=aiohttp.ClientTimeout(total=6 * 60 * 60),

SGLang's request functions each open their own session, inside the coroutine, for the lifetime of one request:

def _create_bench_client_session():
    # When the pressure is big, the read buffer could be full before aio thread read
    # the content. We increase the read_bufsize from 64K to 10M.
    # Define constants for timeout and buffer size for clarity and maintainability
    BENCH_AIOHTTP_TIMEOUT_SECONDS = 6 * 60 * 60  # 6 hours
    BENCH_AIOHTTP_READ_BUFSIZE_BYTES = 10 * 1024**2  # 10 MB

    aiohttp_timeout = aiohttp.ClientTimeout(total=BENCH_AIOHTTP_TIMEOUT_SECONDS)
    return aiohttp.ClientSession(
        timeout=aiohttp_timeout, read_bufsize=BENCH_AIOHTTP_READ_BUFSIZE_BYTES
    )

That helper is invoked per request — async with _create_bench_client_session() as session: opens each of async_request_openai_completions (python/sglang/benchmark/serving.py:L269) and async_request_sglang_generate (:L664), immediately after the argument unpacking and URL assertion that precede it. The consequence is a fresh TCP connect (and over HTTPS a fresh TLS handshake) inside every request's TTFT window, because st = time.perf_counter() is taken before the connect happens on session.post. On loopback that is tens of microseconds. Across a datacentre network at 0.5 ms RTT it is a floor of roughly 0.5 ms on TTFT that vLLM does not pay, and about 1.0 ms over TLS 1.3, whose handshake adds a second round trip (1.5 ms on TLS 1.2, which needs three). It also burns an ephemeral port per request: at 1,000 req/s with a 60-second TIME_WAIT, 60,000 sockets against a default Linux ip_local_port_range of about 28,000 — outright exhaustion, not merely pressure.

What counts as a token: three different answers in two repos

vLLM stamps one ITL sample per SSE frame that carries a choices field — including frames whose text is empty:

                            # NOTE: Some completion API might have a last
                            # usage summary response without a token so we
                            # want to check a token was generated
                            if choices := data.get("choices"):
                                # Note that text could be empty here
                                # e.g. for special tokens
                                text = choices[0].get("text")
                                timestamp = time.perf_counter()
                                # First token
                                if not first_chunk_received:
                                    first_chunk_received = True
                                    ttft = time.perf_counter() - st
                                    output.ttft = ttft

                                # Decoding phase
                                else:
                                    output.itl.append(timestamp - most_recent_timestamp)

                                most_recent_timestamp = timestamp
                                generated_text += text or ""
                            elif usage := data.get("usage"):
                                output.output_tokens = usage.get("completion_tokens")
                                if (pt := usage.get("prompt_tokens")) is not None:
                                    output.prompt_len = pt

SGLang's OpenAI-compatible backend gates on the text being truthy, so an empty-text frame produces no sample and does not even start the TTFT clock:

                            # NOTE: Some completion API might have a last
                            # usage summary response without a token so we
                            # want to check a token was generated
                            if data["choices"][0]["text"]:
                                timestamp = time.perf_counter()
                                # First token
                                if ttft == 0.0:
                                    ttft = time.perf_counter() - st
                                    output.ttft = ttft

                                # Decoding phase
                                else:
                                    output.text_chunks.append(
                                        data["choices"][0]["text"]
                                    )
                                    output.itl.append(timestamp - most_recent_timestamp)

SGLang's native backend, reached with --backend sglang or sglang-native, does something different again: it reads the server's cumulative meta_info["completion_tokens"] and spreads the chunk gap over however many tokens arrived.

                                if ttft == 0.0:
                                    ttft = time.perf_counter() - st
                                    output.ttft = ttft

                                # Decoding phase
                                else:
                                    num_new_tokens = output_len - last_output_len
                                    if num_new_tokens == 0:
                                        continue
                                    chunk_gap = timestamp - most_recent_timestamp
                                    adjust_itl = chunk_gap / num_new_tokens
                                    output.itl.extend([adjust_itl] * num_new_tokens)

So SGLang's own ITL semantics depend on which backend flag you pass: --backend sglang gives per-token amortised ITL, --backend sglang-oai gives per-chunk ITL like vLLM. The aggregator then applies a third correction, but only in a narrow case — when the server reported a speculative acceptance length and the backend is one of the two OpenAI ones:

    use_retokenized_itl = (
        accept_length is not None
        and accept_length > 0
        and backend in ("sglang-oai", "sglang-oai-chat")
    )
# ...
            if use_retokenized_itl:
                for k, itl in enumerate(outputs[i].itl):
                    num_tokens = len(
                        tokenizer.encode(
                            outputs[i].text_chunks[k], add_special_tokens=False
                        )
                    )
                    adjusted_itl = itl / num_tokens
                    retokenized_itls.extend([adjusted_itl] * num_tokens)
            else:
                itls += outputs[i].itl

accept_length comes from a GET on /server_info, reading internal_states[0]["avg_spec_accept_length"], and is only attempted when "sglang" in backend (python/sglang/benchmark/serving.py:L1581-L1600). Benchmark a vLLM server through SGLang's harness with --backend vllm and the correction never fires: you get raw per-chunk ITL, matching vLLM's harness. So the flag combination that makes SGLang's numbers comparable to vLLM's is the one that makes them incomparable to SGLang's own defaults.

The incomparability table

This is the chapter's deliverable. Every row is something one harness computes differently from the other, read from source this session. A reader who has this table can look at two published numbers and say precisely why they do not compare.

    num_special_tokens = int(tokenizer.num_special_tokens_to_add())
    real_input_len = max(0, int(input_len) - num_special_tokens)
    input_low = math.floor(real_input_len * (1 - input_range_ratio))
    input_high = math.ceil(real_input_len * (1 + input_range_ratio))
    output_low = math.floor(output_len * (1 - output_range_ratio))
    output_high = math.ceil(output_len * (1 + output_range_ratio))
    # Ensure the lower bound for output length is at least 1 to
    # prevent sampling 0 tokens.
    output_low = max(output_low, 1)
    output_high = max(output_high, 1)

def compute_random_lens(full_len: int, range_ratio: float, num: int) -> List[int]:
    # full_len=0 is valid for embedding benchmarks where no output tokens are generated
    if full_len <= 0:
        return [0] * num
    return np.random.randint(
        max(int(full_len * range_ratio), 1),
        full_len + 1,
        size=num,
    ).tolist()

The loaders also differ in what they put in the prompt. vLLM's RandomDataset generates (offset + index + arange(input_len)) % vocab_size with special ids removed, then decodes, re-encodes, and warns if the round trip changed the length (vllm/benchmarks/datasets/datasets.py:L559-L572, L680-L689). SGLang's random downloads ShareGPT, takes real first-turn prompts, and repeats a short prompt to reach the target length: ratio = (input_lens[i] + prompt_len - 1) // prompt_len; input_ids = (prompt_token_ids * ratio)[: input_lens[i]] (python/sglang/benchmark/datasets/random.py:L128-L134). That is emphatically not vLLM's uniform-noise distribution, and the source flags the synthetic alternative as risky: the random-ids branch is commented "Sample token ids from random integers. This can cause some NaN issues."

The offline harnesses: a different question entirely

The serving harnesses answer "what does a user see under this offered load". They cannot isolate a kernel, because every number they produce is contaminated by scheduling, admission, HTTP, and the arrival process. For a kernel-level change you want a harness with no server, no network, and a fixed batch. Both projects ship one, and they are structured differently.

        tic = time.perf_counter()
        next_token_ids, _ = model_runner.decode(next_token_ids, batch)
        model_runner.synchronize()
        latency = time.perf_counter() - tic
# ...
    # Record decode timing from 2nd output
    if output_len > 1:
        med_decode_latency = np.median(decode_latencies)
        med_decode_throughput = batch_size / med_decode_latency
        rank_print(
            f"Decode.  median latency: {med_decode_latency:6.5f} s, median throughput: {med_decode_throughput:9.2f} token/s"
        )

That model_runner.synchronize() on both sides of the timed region is the whole reason this harness exists: without it CUDA's asynchrony lets the CPU race ahead and every per-step number is a launch time, not an execution time. It is also why one_batch is a worse throughput benchmark than the serving harness — syncing every step destroys the CPU/GPU overlap a real server relies on. Use it to answer "did my kernel get faster", never "how fast is this engine".

vLLM's latency.py makes one configuration decision worth copying:

    parser = EngineArgs.add_cli_args(parser)
    # V1 enables prefix caching by default which skews the latency
    # numbers. We need to disable prefix caching by default.
    parser.set_defaults(enable_prefix_caching=False)

Thirty iterations over the same dummy_prompts with prefix caching on would make iterations 2–30 nearly free of prefill, and the reported average would be a decode-only number wearing a prefill-plus-decode label. Neither serving harness makes this correction — which is why SGLang's post-warmup cache flush matters, and why vLLM's lack of one matters.

Follow request #417 of a 1,000-prompt run at --request-rate 6.0.

vLLM. (1) main_async loads the dataset with get_samples(args, tokenizer), then — for random and prefix_repetition only — calls _align_prompts_to_server_tokenizer, which POSTs prompt 0 to the server's /tokenize and compares the length (vllm/benchmarks/serve.py:L2125-L2128). (2) benchmark() builds the shared session; the wait_for_endpoint ready check is gated on --ready-check-timeout-sec, which defaults to 0 (:L1899-L1905, :L858-L874), and --num-warmups also defaults to 0 — so at stock defaults no request is sent before the clock starts. (3) get_request has already precomputed delay_ts[417]; it sleeps until start_ts + delay_ts[417] and yields. (4) The main loop builds a RequestFuncInput and wraps limited_request_func in an asyncio.Task; the task is created immediately, so the semaphore wait happens inside it. (5) async_request_openai_completions takes st, POSTs with stream_options: {include_usage: True}, and feeds every socket read into StreamedResponseHandler.add_chunk, which splits on \n\n and emits only complete SSE messages (vllm/benchmarks/lib/endpoint_request_func.py:L31-L61). (6) The first message with choices sets ttft; each later one appends to output.itl; the trailing usage-only message sets output_tokens and overwrites prompt_len. (7) output.latency = most_recent_timestamp - st. (8) calculate_metrics pools every request's itl list into one flat array and takes np.percentile over the pool.

SGLang. (1) run_benchmark loads the dataset and builds the tokenizer. (2) benchmark() fires --warmup-requests tasks (default 1) with output_len=min(test_request.output_len, 32), checks at least one succeeded, conditionally flushes the server cache, and sleeps 1 s. (3) get_request yields request 417 and only then sleeps np.random.exponential(1/6.0). (4) limited_request_func acquires the semaphore if one exists. (5) async_request_openai_completions opens a new ClientSession, takes st, POSTs, and iterates response.content line by line — aiohttp's StreamReader.__aiter__, so each iteration is one SSE line. (6) latency is recomputed on every non-empty line including [DONE]. (7) A frame with truthy text sets ttft or appends an ITL sample and a text chunk. (8) output.latency = latency — the [DONE] timestamp. (9) The session closes and the TCP connection is torn down. (10) After gather, the harness GETs /server_info for avg_spec_accept_length, then calculate_metrics optionally re-tokenizes every chunk.

Step 8 in vLLM and step 8 in SGLang are the same line of intent and different lines of code, and that is the entire E2EL divergence. Step 5 in vLLM and step 5 in SGLang are the same intent and produce a TTFT that differs by one TCP handshake.

The vLLM entry point is the CLI subcommand registered by BenchmarkServingSubcommand in vllm/entrypoints/cli/benchmark/serve.py:L11-L22, which simply forwards to vllm.benchmarks.serve.add_cli_args and main — unless VLLM_USE_RUST_BENCH=1, in which case maybe_exec_rust_bench() os.execvs a Rust binary instead and none of this Python runs at all (vllm/entrypoints/cli/main.py:L57, vllm/entrypoints/cli/benchmark/main.py:L23-L35; the variable defaults to False). The sibling subcommands are latency, throughput, startup, sweep and mm-processor — the names come from each class's name attribute, not from the module names imported at vllm/entrypoints/cli/benchmark/main.py:L38-L46.

vllm bench serve \
  --backend vllm --model meta-llama/Meta-Llama-3-8B-Instruct \
  --dataset-name random --random-input-len 1024 --random-output-len 256 \
  --random-range-ratio 0.0 \
  --num-prompts 1000 --request-rate 6.0 --burstiness 1.0 \
  --num-warmups 50 \
  --percentile-metrics ttft,tpot,itl,e2el --metric-percentiles 50,90,99 \
  --goodput ttft:900 e2el:14100 \
  --ignore-eos \
  --save-result --result-filename run-vllm.json

# offline, for a kernel change:
vllm bench latency --model meta-llama/Meta-Llama-3-8B-Instruct \
  --input-len 1024 --output-len 128 --batch-size 32 \
  --num-iters-warmup 10 --num-iters 30 --output-json lat.json

# offline, for peak sustainable throughput:
vllm bench throughput --model meta-llama/Meta-Llama-3-8B-Instruct \
  --dataset-name random --input-len 1024 --output-len 256 --num-prompts 1000

python -m sglang.benchmark.serving \
  --backend sglang \
  --model meta-llama/Meta-Llama-3-8B-Instruct \
  --dataset-name random --random-input-len 1024 --random-output-len 256 \
  --random-range-ratio 1.0 \
  --num-prompts 1000 --request-rate 6.0 \
  --warmup-requests 50 --flush-cache \
  --output-file run-sgl.jsonl --output-details

# offline, per-decode-step latency:
python -m sglang.benchmark.one_batch \
  --model-path meta-llama/Meta-Llama-3-8B-Instruct \
  --batch-size 1 8 32 --input-len 1024 --output-len 128 \
  --run-name roofline --result-filename one_batch.jsonl

--random-range-ratio 1.0 on the SGLang side is what reproduces vLLM's 0.0: SGLang's lower bound is $\lfloor L \cdot r \rfloor$, so $r = 1$ pins every length to $L$. That single substitution is the difference between comparing the same workload and comparing workloads whose input token counts differ 2×.

Both print a fixed-width block to stdout. The labels below are the literal format strings from the print statements, with values elided — I have no GPU, so there are no numbers here and you should be suspicious of anyone who publishes a table without saying which harness and which flags produced it.

============ Serving Benchmark Result ============
Successful requests:                     ...
Failed requests:                         ...
Maximum request concurrency:             ...        # only if --max-concurrency
Request rate configured (RPS):           ...        # only if not inf
Benchmark duration (s):                  ...
Total input tokens:                      ...
Total generated tokens:                  ...
Request throughput (req/s):              ...
Request goodput (req/s):                 ...        # only if --goodput
Output token throughput (tok/s):         ...
Peak output token throughput (tok/s):    ...
Peak concurrent requests:                ...
Total token throughput (tok/s):          ...
--------------- Time to First Token --------------
Mean TTFT (ms): / Median / P50 / P90 / P99 ...      # percentiles from --metric-percentiles
------ Time per Output Token (excl. 1st token) ----
Mean TPOT (ms): / Median / P... ...
--------------- Inter-token Latency --------------
Mean ITL (ms): / Median / P... ...
----------- Speculative Decoding -----------------  # only if the server exposes the counters
Acceptance rate (%): / Acceptance length: / Drafts: / Draft tokens: / Accepted tokens:
==================================================

============ Serving Benchmark Result ============
Backend: / Traffic request rate: / Max request concurrency:
Successful requests:                     ...        # NO failure line
Benchmark duration (s):                  ...
Total input tokens: / Total input text tokens:
Total generated tokens: / Total generated tokens (retokenized):
Request throughput (req/s): / Input token throughput (tok/s):
Output token throughput (tok/s): / Peak output token throughput (tok/s):
Peak concurrent requests: / Total token throughput (tok/s):
Concurrency:                             ...        # sum(E2EL)/duration, Little's Law
Accept length:                           ...        # from /server_info, sglang backends only
----------------- End-to-End Latency -------------
Mean / Median / P90 / P95 / P99 E2E Latency (ms)    # percentiles are HARD-CODED
--------------- Time to First Token --------------
Mean / Median / P90 / P95 / P99 TTFT (ms)
------ Time per Output Token (excl. 1st token) ----
Mean / Median / P90 / P95 / P99 TPOT (ms)
--------------- Inter-Token Latency --------------
Mean / Median / P90 / P95 / P99 / Max ITL (ms)      # Max ITL exists only here
==================================================

Three checks to run on any output before you believe it. (1) Divide mean_itl_ms by mean_tpot_ms. Do not interpret that ratio alone as acceptance: pooled ITL weights intervals while mean TPOT may weight requests equally. Different output lengths and latencies can make the ratio differ from one even with one token per frame and no speculation. Inspect per-request event counts and matching denominators. (2) In SGLang, compare Total generated tokens with Total generated tokens (retokenized). On the native backend a gap means the harness's tokenizer disagrees with the server's, and every token-throughput number is off by that ratio; on an OAI backend the first figure is the requested length, so the gap measures how often generation stopped early instead. (3) Compute --num-prompts minus Successful requests. If it is not zero, the percentiles are conditioned on survival.

• The provenance header. python/sglang/benchmark/serving.py:L1-L4 records that the file was adapted from vLLM's benchmark_serving.py and backend_request_func.py at vLLM commit 6366efc. Everything in the incomparability table is drift since that fork. Reading the two files side by side is the fastest way to see which project changed which decision.
• vLLM PR #9390, vllm-project/vllm#9390 — the --max-concurrency semaphore. SGLang's copy still carries the comment # From https://github.com/vllm-project/vllm/pull/9390 at python/sglang/benchmark/serving.py:L1378-L1379.
• DistServe, Zhong et al., arXiv:2401.09670 — the goodput definition vLLM's --goodput help text points at, and the reason ITL is excluded from VALID_NAMES.
• vLLM issue #9778, vllm-project/vllm#9778 — multi-modal token counting in throughput.py; the harness prints a red WARNING pointing at it whenever a multi-modal request runs on a non-chat backend (vllm/benchmarks/throughput.py:L1116-L1124).
• Open versus closed loop. Schroeder, Wierman and Harchol-Balter, Open Versus Closed: A Cautionary Tale, NSDI '06 — the paper that explains why the two regimes give different answers and why closed-loop harnesses cannot find the tail. §10.3 applies it.
• Neighbours: §1.2 for the metric definitions and the Prometheus surface, §10.1 for what the shipped datasets are biased toward, §10.3 for warmup and saturation methodology, §10.4 for why two identical runs do not produce identical tokens, and §10.5 for turning a decode step into a roofline point and then into money.