Skip to content

docs(rdna2): how to reproduce the MonoKernel (#94) numbers - #120

Draft
BlivionIaG wants to merge 3 commits into
rdna_extrasfrom
docs/monokernel-reproduce
Draft

BlivionIaG wants to merge 3 commits into
rdna_extrasfrom
docs/monokernel-reproduce

Conversation

@BlivionIaG

@BlivionIaG BlivionIaG commented Oct 16, 2026 •

Copy link
Copy Markdown

Adds docs/rdna2/monokernel-reproduce.md, a step-by-step guide to rerunning the same-session --monokernel off/on A/B from #94 (merged as 1c1426d585).

Docs only. No code change.

Refresh 2026-11-11 (merged origin/rdna_extras 1136bb952b into the branch, no force)

The branch was 2,306 commits behind, and #94's tree is 2,332 commits behind the tip. The merge was clean. The procedure itself is unchanged: it pins 1c1426d585 (an ancestor of the tip) and must not be run on a newer tip. What was stale was the doc's claim about how far behind it is and its silence on what the tip does differently. New section "What this pins, and what it does not" (commit acc1697114) says:

  • Pinned: tree 1c1426d585, the two recipes as they were at that commit, venv venv-7.14.0_0.31.0-final, TunableOp profile rocm7.14-rocblas5.5, model snapshot 0939125b..., PLE snapshot 4f861b63..., and the recorded table (one serve per arm).
  • Checked on 2026-11-11 and still true:
    • every path the procedure names exists at the pin and at the tip;
    • ab_table.py (pin and tip versions) rebuilds ab_table.md byte for byte from the recorded serve-* directories with the four-directory command in the doc (the doc used to say the command line was "not recorded"; it is now verified);
    • PRINT=1 EXTRA_ARGS="--monokernel" tools/rdna/serve_rdna.sh RECIPE=flashnext-mtp{0,2} exits 0 at the pin and at the tip on the bench box and prints --monokernel and the rocm7.14-rocblas5.5 TunableOp line;
    • the venv and both snapshots exist on the box;
    • all 17 bench serve flags of step 4 are accepted by bench serve --help=all at the tip, and all 11 serve flags, --monokernel included, appear in serve --help=all (CPU-only runs). At the pin the CLI aborts in torch._C._cuda_init on a CPU-only run, so the pin was read, not run.
  • Not re-run: the serves, the build and the unit tests (they need a GPU). The table was not reproduced again after the 2026-11-08 case move.
  • What differs on the tip, so the table does not describe it: flashnext-mtp2.env (one-shot AR 256 KiB, W4A8_SDOT4=1, W4A8_BLOCK_M=8, W4A8_KBLOCK=-1, SMALLM_GEMM_MAX_BYTES), both recipes VLLM_GDN_HIP_PREFILL=1, serve_validate.sh quiet windows, boot lock, KFD-eviction check and REFUSED_GPUS (the old HIP 0/1 case block), serve_2a.sh GMEM=0.92, and the MonoKernel itself (K2 dense MTP FFN, MTP routing, fail-stop, quantized-KV refusal, W4A8 coexistence, expert offload).
  • A later A/B disagrees in sign: docs/rdna2/mono-w4a8-2026-11-05.md (tree 5b8d1e5570, HIP 2-5) found mono + W4A8 slower than production at an equal GPU_MAX_HW_QUEUES=4. The reproduce doc records what [RDNA2] MonoKernel decode for Qwen3.8-Flash-Next on gfx1030 (--monokernel) #94 measured at its pin and says it does not resolve that.

pre-commit (markdownlint, typos, ...) passes. Nothing was run on a GPU.

Original description

The guide comes from the #94 description and the raw run in the infrastructure repo, bench_results/2026-10-16_mono-layout/ (ab.sh, ab.out, ab2.out, ab_table.md, build.sh, pytest*.log, serve-*/). It covers:

  • The final A/B table, verbatim from ab_table.md. It matches the PR table except for rounding. It also says which serves each row comes from: the MTP2 rows come from the ab2 rerun.
  • The software state: tree 1c1426d585 (the run logged no SHA; the evidence is in the doc), venv name, TunableOp profile rocm7.14-rocblas5.5 / rocBLAS f30bb442e9b5, the in-place native build, model and PLE snapshots.
  • The hardware, the recipe environment (GPU_MAX_HW_QUEUES=4, HSA_FORCE_FINE_GRAIN_PCIE=1, ROCPROFILER_REGISTER_ENABLED=0, ...) and the serve shape.
  • Host-neutral commands for each arm (off, --monokernel, VLLM_ROCM_MONO_DECODE=1), the bench cells, and how bench_metrics.py computes the four metrics.
  • The validation gates (pytest 142 passed, the probes, the engagement log lines) and the gotchas recorded in the artifacts (MTP2 acceptance swing, noise at c=8, the pre-33892a9af4 MTP2 boot refusal, host-specific driver guards).

Items that the sources do not record are marked not recorded.

Validation status

  • Every number and command is traced to the PR or to a file in bench_results/2026-10-16_mono-layout/
  • Fork file links checked against this branch and, on 2026-11-11, against the tip
  • The table rebuilds byte for byte from the recorded run directories
  • Someone follows the guide on a second host (the serves themselves have not been repeated)

…t on the current tip

The procedure stays pinned to 1c1426d. Add what was verified against
rdna_extras 1136bb9 (paths, ab_table.py rebuilds ab_table.md byte for
byte, PRINT=1 dry runs at the pin and the tip, bench and serve flags) and
what the tip does differently (recipes, serve_validate.sh, REFUSED_GPUS, the
MonoKernel itself, the 2026-11-05 mono + W4A8 A/B that disagrees in sign).

Signed-off-by: BlivionIaG <kev29lt@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant