Skip to content

[backlog] perf(rdna): retune the 6 TunableOp rows slower than the heuristic - #74

Draft
BlivionIaG wants to merge 1 commit into
rdna_extrasfrom
backlog/tunableop-slow-rows
Draft

BlivionIaG wants to merge 1 commit into
rdna_extrasfrom
backlog/tunableop-slow-rows

Conversation

@BlivionIaG

Copy link
Copy Markdown

Backlog item, draft until the work lands on this branch.

Why
The coverage campaign kept 6 Flash-Next rows measured 3-10 % slower than the rocBLAS heuristic (listed in tunableop/rocm7.14-rocblas5.5/provenance.json).

Plan
Re-tune or drop those rows; regenerate the profile.

Validation
lookup hit check + affected cells.

Tracking branch for a backlog item; the plan is in the draft PR.
wsantos added a commit to wsantos/vllm-rdna that referenced this pull request Oct 12, 2026
The row set currently in service on this box resolves through the *fallback*
path: the loaded /opt/rocm/core-10.0/lib/librocblas.so.5.6 hashes to
sha256[:12] = d05939967b5f, and no profile registered in profiles.json matches
that hash, so configure_tunableop falls back to the directory named after it.
Until now that directory was untracked, so the tables actually serving traffic
were not in version control.

296 GemmTunableOp_Half_TN rows across the four TP ranks (74/rank), captured for
librocblas.so.5.6 @ d05939967b5f, torch 2.13.0+gitc1d415f, hip 7.15.26333,
float16, seed 620, batch_tokens [800..8192]. QUALIFIED records that all 70 FP16
TN shapes matched independent FP32 calculations on all four V620s.

Deliberately NOT done here, because it needs a human owner:
 - no profiles.json registry entry and no profile README.md, so this is still
   the per-user fallback rather than a first-class named profile
 - no lookup-hit proof (the README requires it per profile); the hit rate for
   these rows has not been measured
 - no capture/tune/curate campaign notes; these rows are a raw capture, not
   curated against the heuristic the way rocm7.14-rocblas5.5 was in opengfx1030#81

Refs: opengfx1030/vllm-rdna tunableop/README.md (profile requirements),
PR opengfx1030#81 (the curate-and-measure protocol), opengfx1030#74 (open retune backlog).

Co-authored-by: Pi <noreply@pi.dev>
wsantos added a commit to wsantos/vllm-rdna that referenced this pull request Oct 12, 2026
The row set currently in service on this box resolves through the *fallback*
path: the loaded /opt/rocm/core-10.0/lib/librocblas.so.5.6 hashes to
sha256[:12] = d05939967b5f, and no profile registered in profiles.json matches
that hash, so configure_tunableop falls back to the directory named after it.
Until now that directory was untracked, so the tables actually serving traffic
were not in version control.

296 GemmTunableOp_Half_TN rows across the four TP ranks (74/rank), captured for
librocblas.so.5.6 @ d05939967b5f, torch 2.13.0+gitc1d415f, hip 7.15.26333,
float16, seed 620, batch_tokens [800..8192]. QUALIFIED records that all 70 FP16
TN shapes matched independent FP32 calculations on all four V620s.

Deliberately NOT done here, because it needs a human owner:
 - no profiles.json registry entry and no profile README.md, so this is still
   the per-user fallback rather than a first-class named profile
 - no lookup-hit proof (the README requires it per profile); the hit rate for
   these rows has not been measured
 - no capture/tune/curate campaign notes; these rows are a raw capture, not
   curated against the heuristic the way rocm7.14-rocblas5.5 was in opengfx1030#81

Refs: opengfx1030/vllm-rdna tunableop/README.md (profile requirements),
PR opengfx1030#81 (the curate-and-measure protocol), opengfx1030#74 (open retune backlog).
@wsantos

wsantos commented Oct 14, 2026

Copy link
Copy Markdown

Measured, and partly refuted: the whole 168-shape grid was re-tuned and compared heuristic / current / new in one session on build d05939967b5f — see #92.

  • The prefill side is done: 2 shipped rows replaced by a different faster solver, 11 rows added at M=256/512/800 (the dynamic-prefill chunk-cap family), 2 further "adopt" decisions rejected because they carried the same solver id as the shipped row (same-session noise).
  • The decode side is where your premise is not yet provable: 18 rows at M=2..8 measure 10–77 % slower than the heuristic, but that region is launch-bound — identical shape families flip sign between M=1 (row 22–58 % faster) and M=2..8, on ~14 MFLOP GEMMs timed at 80–240 µs. The decode grid is left byte-identical and those 18 need a small-M measurement (no per-call sync, larger reps) before deletion.

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.

2 participants