flag-truth live A/B -- box 206, one RTX 4090, 2026-09-08
========================================================

Qwen3.6-27B-AWQ-INT4 on registry.arbi.work/arbi-serve:test-4a2f15c. The two
arms differ ONLY in which arbi_serve tree is bind-mounted over the image's
-- a pure-Python change, so a source mount is behaviour-identical to a
rebuild. Same card, same warm compile cache, arms back to back, nothing
else on the GPU. --max-context=8192 --max-batch=8 --gpu-memory-utilization
0.90, no calibration.

  arm A = origin/main            (counter.fire())
  arm B = perf/2308 (this PR)    (counter.fired = 1)


1. THE MARK CENSUS
------------------
/v1/admin/flag_truth read either side of ONE 2000-token completion, engine
otherwise idle. Arm B is read with counting ARMED, which is what makes the
two comparable at all -- a bit counter has no total to diff.

    arm A (main)                     arm B (this PR, counting armed)
    counters moved   21              counters moved   21
    total marks   16068              total marks   16068
    marks/token    8.03              marks/token    8.03

Identical, name for name and count for count:

    2002 mtp_spec_disable_threshold_read      2000 cudagraph_decode_replay
    2001 async_output_copy                    2000 fwd_step_captured
    2001 batch_materialized                   1999 decode_input_pipeline
    1999 persistent_input_batch                 48 gdn_chunk_indices_step_memo_hit
    1999 persistent_recurrent_index_reuse        7 savepoint_decode_write

That is the null control for the mechanical pass: 400 rewritten call sites
moved no mark, added none and dropped none. (It also reproduces the 16,461
/ 8.2 / 21 recorded on this config in arbicity/arbi-serve#2308.)

The same request on arm B with counting OFF -- the shipped default:

    counters moved   19       total marks   4018     marks/token   2.01
       2001 batch_materialized      (counted=True)
       2000 fwd_step_captured       (counted=True)
          1 async_output_copy       (counted=False)
          1 cudagraph_decode_replay (counted=False)
          ... 15 more at 1, all counted=False

Which is the design working: the counters someone reads a TOTAL from still
carry one; every other path says "I ran" and nothing more; and `counted`
travels with each so a 1 can never be misread as a rate. Arming and
disarming are live -- `{"counting":true,"promoted":306}` on a running
server, no restart.


2. END TO END
-------------
vllm bench serve, ISL 2048 / OSL 256, 10 prompts, concurrency 1,
--ignore-eos, fresh random seed per pass (cache-busted), 3 passes per arm.

                  TTFT ms                 TPOT ms                out tok/s
    pass      arm A     arm B        arm A     arm B        arm A     arm B
      1      491.01    491.54        21.72     21.72        42.29     42.54
      2      482.16    501.88        21.71     21.71        42.56     42.45
      3      495.95    494.78        21.73     21.73        42.43     42.48
    median   491.01    494.78        21.72     21.72        42.43     42.48

TPOT is identical to the last digit the harness prints, in every pass. That
is the correct result, and it was the predictable one: 8.03 marks per token
at ~28.6 ns saved each is 0.23 us/token against a 21.7 ms TPOT --

    0.0011% of decode, against a 3-pass TTFT spread of ~2%.

The end-to-end A/B can only ever say "no regression" here; it cannot
resolve the saving, and a run that claimed to would be measuring drift.
The saving is resolved by the microbenchmark instead (see
flag-truth-mark-cost-2026-09-08.txt: 34.57 -> 6.00 ns per mark, 5.76x), and
by the census above fixing how many marks a request actually pays for.

WHY BOTHER, THEN
----------------
Two reasons the 0.0011% is not the number that decided this.

Marks/token is not a constant. It is 8.03 at c=1 on this config because the
dominant counters are per-STEP; a config that marks per ROW or per LAYER
pays it per row or per layer, and the gdn commit witnesses alone are 48
layers x every rejection. The cost of the mark is what bounds where a
counter can be put, and this is the difference between "instrument that
path" and "we cannot afford to know".

And the mark is no longer the reason not to add one. That was the actual
constraint: a machinery whose whole value is that a MustFire contract is
evaluable on a production boot has to be cheap enough to leave armed, or
the first thing anyone does under load is switch it off -- which is the
failure mode it exists to prevent.
