diff --git a/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.en.md b/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.en.md
new file mode 100644
index 000000000..2802e9a41
--- /dev/null
+++ b/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.en.md
@@ -0,0 +1,159 @@
+# Technical Report: PR #2218 - Recalibrating the Joint Top-k + Top-p Rejection Vocab Cap on ROCm
+
+**Date**: 2026-10-08
+
+**Status**: Implemented and verified on the gfx1151 host (ROCm/HIP); code head `7d737d49` rebased on main `ae343d84`, PR open, pending merge. Closes #2157, part of #1801.
+
+**Languages**: C++ (`mlx_cxx_bridge.cpp`, `mlx_cxx_bridge.h`), Rust (`lib.rs`, `sampling_rejection_tests.rs`, `examples/rejection_sampling_microbench.rs`, `src/bin/bench_decode.rs`), shell (`scripts/bench_decode.sh`), Markdown (benchmark page, `installation.md`, `environment-variables.md`)
+
+**Risk Level**: Low. Only the value of one routing constant changes, and only in ROCm builds: a ROCm build now sends top-k together with top-p to the rejection kernel up to vocab 152064 instead of 32768. `MLXCEL_SAMPLING_REJECTION=0` restores the stock chain. Metal and CUDA builds keep 32768, but that arm was not run on this host.
+
+## Executive Summary
+
+The rejection sampler routes top-k together with top-p only up to `REJECTION_JOINT_VOCAB_MAX`, which was 32768. That number was measured on M1 Ultra, where joint top-k + top-p won 1.27x to 1.64x at 32K and lost (0.71x to 0.83x) at 152K. The HIP port (#2064) inherited it without a measurement. On ROCm, `--top-k 40 --top-p 0.95` on a vocab-128256 model such as Llama 3.1 therefore never reached the kernel.
+
+On gfx1151 the microbenchmark alone would have kept 32768. Its batch 4 and 8 cells win at every vocabulary (pipelined 1.05x to 2.02x), but the synthetic batch-1 cell reads 0.90x to 0.98x pipelined above 32768. The end-to-end decode run, which the issue names as the confirmation at 128256 and above, disagrees with that cell. With the joint case routed, Meta-Llama-3.1-8B-Instruct-4bit (128256) goes from 32.67 to 37.57 tok/s (1.15x) and Qwen2.5-7B-Instruct-4bit (152064) from 41.91 to 46.92 tok/s (1.12x), medians of three interleaved guarded pairs, with every kernel run faster than every chain run. On the final branch build, on the engine decode path, Llama goes from 33.15 to 37.73 tok/s (1.14x).
+
+The ROCm value is now 152064, the largest vocabulary measured both ways, chosen by a build flag with no runtime backend branch. A new bridge accessor reports the active value and a test pins it per build. Why the synthetic batch-1 cell does not predict real decode was not isolated. Vocabularies above 152064 were not measured and are unchanged. Metal and CUDA were not verified. The orchestrator's `make verify-rocm` on the rebased head passes (161 suites, 12,189 passed, 0 failed, 398 ignored).
+
+## 1. Problem Statement
+
+### 1.1 A cap calibrated on another GPU
+
+`REJECTION_JOINT_VOCAB_MAX` in `src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp` is read by `sampling_rejection_routes` once top-p is active: a top-k that can bind routes only if `vocab <= REJECTION_JOINT_VOCAB_MAX`. The reason top-k loses at large vocabularies on M1 Ultra is that it needs more rejection rounds as the vocabulary grows, and each round is a full-row sweep on one threadgroup. gfx1151 has a different per-threadgroup bandwidth and launch cost, so the crossover can sit elsewhere. Nobody had measured it: `rocm-samplers-gfx1151-2026-10-05.md` noted that `--top-k 40 --top-p 0.95` on a vocab-128256 model never reaches the kernel and that whether the cap is right on ROCm was not measured.
+
+### 1.2 The microbenchmark could not run on ROCm
+
+The tool that measures the matrix, `examples/rejection_sampling_microbench.rs`, gated on `custom_kernels_available()`. That function is true on Metal or CUDA by definition, so on a ROCm build the benchmark refused to run. The port that made the kernel run on ROCm never had its crossover measured because the measuring tool was not ported with it. Its vocabulary list also lacked 128256 (Llama 3) and 151936 (Qwen3).
+
+### 1.3 No way to benchmark the joint filter end to end
+
+`mlxcel-bench-decode` and `scripts/bench_decode.sh` had no `--top-k` option, so the case the issue was opened for could not be timed through the normal decode benchmark.
+
+## 2. Change Summary
+
+| Area | Change |
+|---|---|
+| `mlx_cxx_bridge.cpp` | `REJECTION_JOINT_VOCAB_MAX` is 152064 under `#ifdef MLXCEL_BRIDGE_ROCM_BACKEND` and 32768 otherwise. The gfx1151 tables are in the comment above it. The not-routed message names the build's cap. |
+| `mlx_cxx_bridge.h`, `lib.rs` | New accessor `sampling_rejection_joint_vocab_max()`. |
+| `sampling_rejection_tests.rs` | The cap is pinned per build; the routing matrix covers 65536, 128256, 151936 and 152064 per build; the large-vocabulary decline test picks a vocabulary above the build's cap. |
+| `examples/rejection_sampling_microbench.rs` | Vocabularies 128256 and 151936 added; `--dtype f32\|bf16\|f16` and `--config <label>` options; prints the build's cap; port gate fixed. |
+| `src/bin/bench_decode.rs`, `scripts/bench_decode.sh` | New `--top-k` option (filename tag `_k<K>`, validated). |
+| Docs | New results page `docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md`, linked from `rocm-samplers-gfx1151-2026-10-05.md`. The ROCm sampled-decode row in `installation.md` lists which filter combinations route at the Llama 3 and Qwen vocabularies. The `MLXCEL_SAMPLING_REJECTION` row in `environment-variables.md` is updated. |
+| `benchmarks/` | Raw CSVs: three f32 microbenchmark runs, three bf16 runs, the end-to-end pairs of the measurement build, and the before/after pairs of the final build. |
+
+## 3. Design
+
+### 3.1 The per-build constant
+
+```cpp
+#ifdef MLXCEL_BRIDGE_ROCM_BACKEND
+constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 152064;
+#else
+constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 32768;
+#endif
+
+int32_t sampling_rejection_joint_vocab_max() {
+    return REJECTION_JOINT_VOCAB_MAX;
+}
+```
+
+This is the build-flag pattern of the fused-MoE SGY default (#2098) and the `cfg!(feature = "rocm")` defaults of #2189. A ROCm build has no Metal or CUDA backend, so no runtime backend comparison is needed and `verify-kernel-port-dispatch` stays satisfied. The constant has one reader, `sampling_rejection_routes`, and the accessor exposes the same value, so a unified per-row sampling step (epic #2166 Phase 2) should call `sampling_rejection_routes` or the accessor instead of copying the number.
+
+### 3.2 The test that pins it
+
+`the_joint_vocab_cap_is_the_measured_crossover` in `sampling_rejection_tests.rs` expects 152064 when built with `feature = "rocm"` and 32768 otherwise, so the constant cannot move without a new measurement. It then checks that the policy turns exactly at the cap (routes at `cap`, declines at `cap + 1`, with and without min-p), that top-p alone still routes above the cap, and that a top-k that cannot bind (`top_k >= vocab`) does not bring the cap in.
+
+### 3.3 The microbenchmark port gate
+
+The gate now checks `sampling_rejection_backend_supported()`, the predicate production routing uses, instead of `custom_kernels_available()`. The harness measures what `fused_sample` does, so it must agree with `fused_sample` on which backends it applies to.
+
+### 3.4 Rejected
+
+- **Keep 32768 on ROCm.** It follows the issue's literal rule (section 7) but leaves the configuration the issue was opened for 12% to 15% slower.
+- **A runtime backend comparison for the cap.** The build flag is enough and keeps the kernel-port-dispatch check passing.
+- **A cap above 152064.** Larger vocabularies (gpt-oss 201088, Gemma 262144) were not measured, and the existing comment requires that unmeasured vocabularies never be included.
+
+## 4. Risks Specific to the Change
+
+- On ROCm, decode for top-k + top-p at vocab 65536 up to 152064 changes path. The rejection kernel is distribution-equivalent to the stock chain but uses a different random stream, so sampled tokens at a fixed seed differ from before.
+- The synthetic batch-1 cell says the kernel is slower than the chain on a single row at 128256 and up. Real decode says the opposite, and the reason is not known. A different model, batch size or GPU could land on the other side of that cell.
+- The cap is a single number per build, not per GPU. Another ROCm part (for example a discrete GPU) may have a different crossover.
+
+## 5. Verification
+
+### 5.1 Gates
+
+- Orchestrator gate, `make verify-rocm` on the rebased head `7d737d49`: 161 suites, 12,189 passed, 0 failed, 398 ignored.
+- From the PR body, on the earlier rebase onto `ad844354`: `sampling_rejection_tests` and `sampling_fixed_key_tests` (34 passed, covering support, distribution and fixed-key tests), the `sampling_gumbel_kill_switch` and `sampling_rejection_kill_switch` tests, and `cargo test --test dead_doc_pointers` pass.
+- Dispatch logs on the final build: `mlxcel generate` logs `rejection kernel (batch 1, vocab 128256, ... top_k 40, top_p 0.95 ...)` by default and `argpartition chain: pinned by MLXCEL_SAMPLING_REJECTION` with the switch set, so each arm of the before/after pairs ran the path it is labelled with.
+- Every benchmark ran through `scripts/rocm_gpu_guard.sh`.
+
+Not verified: Metal and CUDA are not available on this host. Their value (32768) is unchanged and the routing code is shared, but the non-ROCm arm of the per-build tests was not run here.
+
+## 6. Results
+
+### 6.1 Environment
+
+AMD Ryzen AI MAX+ 395 with Radeon 8060S (`gfx1151`), 96 GiB VRAM carve-out, ROCm 10.0.0 (HIP 7.15.26333), MLX pin `81ba1c6a`, ROCm overlay `75915908`, `cargo build --release --features rocm`. The measurement build is `main` at `84d3a7bc` plus this change with the ROCm cap raised to `INT32_MAX`, so `fused_sample` routes every joint cell. Its CSVs record `mlxcel_commit` as `unknown` because the binaries were copied out before the source moved on. The final-build CSVs record `79ea5814`. Checkpoints are `mlx-community/Meta-Llama-3.1-8B-Instruct-4bit` (128256) and `mlx-community/Qwen2.5-7B-Instruct-4bit` (152064).
+
+### 6.2 Microbenchmark grid
+
+`rejection_sampling_microbench`, 200 timed and 30 warmup iterations per cell, three runs, batch 1/4/8, vocabularies 32768, 65536, 128256, 151936 and 152064, top-k 40 + top-p 0.9, f32 logits (every configuration) and bf16 logits (joint only, because both checkpoints are bf16). Every joint cell reads `routed=yes`. The pipelined arm goes through `fused_sample`, so on a cell production does not route it would time the chain against itself, which is why the measurement build lifted the cap. `pipe_x` is the pipelined speedup (stock chain time over kernel time), the number the issue says to read, not the isolated `iso_x`. Medians of three, f32:
+
+| vocab | batch 1 pipe_x | batch 4 pipe_x | batch 8 pipe_x | batch 1 iso_x |
+|---|---|---|---|---|
+| 32768 | 1.00 (0.96-1.04) | 1.17 | 1.44 | 2.23 |
+| 65536 | 0.98 (0.95-1.05) | 1.18 | 1.64 | 1.59 |
+| 128256 | 0.98 (0.96-0.99) | 1.28 | 1.80 | 0.96 |
+| 151936 | 0.90 (0.88-0.92) | 1.36 | 1.90 | 0.92 |
+| 152064 | 0.93 (0.88-0.97) | 1.29 | 2.02 | 0.92 |
+
+Batches 4 and 8 win at every vocabulary. Batch 1 is the only losing cell, and from 128256 up the isolated cell is also below 1.0 (0.92 to 0.96). The bf16 rerun reads the same way: batch 1 pipe_x is 0.98 at 128256, 0.89 at 151936 and 0.86 at 152064, batch 4 is 1.05 to 1.23 and batch 8 is 1.38 to 1.54. The dtype is therefore not the cause of the disagreement with real decode. The full tables with `rounds` and times are in the benchmark page.
+
+How much the batch-1 pipelined cells can say is limited. Rows that production does not route (top-k alone and min-p alone, chain against chain) scatter between 0.90x and 1.11x by median, so a batch-1 `pipe_x` between 0.95 and 1.05 is inside the noise either way. The synthetic forward measured 2110 to 2659 us per step, and the cap-overflow counter stayed at 0.
+
+### 6.3 End-to-end decode
+
+`scripts/bench_decode.sh` at pp512/tg128 with `--temperature 0.8 --top-k 40 --top-p 0.95`, kernel arm against the same binaries with `MLXCEL_SAMPLING_REJECTION=0`. Each pair ran inside one guard attempt, alternating which arm went first. Medians of three pairs:
+
+| Model (vocab) | Stock chain tok/s | Rejection kernel tok/s | Ratio |
+|---|---|---|---|
+| Meta-Llama-3.1-8B-Instruct-4bit (128256), measurement build | 33.94 / 31.64 / 32.67, median 32.67 | 37.70 / 37.37 / 37.57, median 37.57 | 1.15x |
+| Qwen2.5-7B-Instruct-4bit (152064), measurement build | 42.68 / 41.91 / 40.79, median 41.91 | 46.92 / 46.40 / 47.18, median 46.92 | 1.12x |
+| Meta-Llama-3.1-8B-Instruct-4bit (128256), final build, engine path | 33.15 / 35.76 / 33.09, median 33.15 | 37.61 / 38.45 / 37.73, median 37.73 | 1.14x |
+
+Every kernel run is faster than every chain run on every model. Within each pair the gain is 11% to 18% on Llama (measurement build), 10% to 16% on Qwen and 8% to 14% on the final Llama build. The chain arm spreads more than the kernel arm, as the top-p chain did on Llama 3.1 in #2064. The final build is the branch rebased on main, where `mlxcel-bench-decode` decodes through the engine (#2224, #2225; the CSV's `decode_path` column reads `engine`). Its "before" arm is `MLXCEL_SAMPLING_REJECTION=0`, which is the path main takes for this configuration. Qwen2.5-7B was not re-run on the final build because the shared GPU was contended for hours at a time.
+
+## 7. The Decision Rule and Why It Was Not Applied Literally
+
+The issue's rule takes the largest measured vocabulary V such that every batch cell at V and at every measured vocabulary below V has `pipe_x >= 1.0`, confirmed end to end when V is 128256 or more. Read literally, the synthetic batch-1 cells stop it at 32768: the batch-1 cell reads 0.90x to 0.98x pipelined above 32768 (and 0.98x already at 65536), while 32768 itself sits at 1.00x. The rule would keep the old cap.
+
+The end-to-end run is the confirmation the same rule asks for, and it contradicts the cell by a wide margin: 1.15x on Llama 3.1 and 1.12x on Qwen 2.5, with no overlap between arms. The microbenchmark's own batch 4 and 8 cells also win everywhere. Keeping the configuration the issue was opened for on the slower path because of a synthetic cell would be the wrong call, so the ROCm value is 152064, the largest vocabulary measured both ways. The deviation is stated in the PR body and the benchmark page.
+
+## 8. Technical Decisions
+
+- **Decide on decode, not on the synthetic cell.** Real decode is what users run. The synthetic batch-1 cell is inside the noise at several vocabularies and disagrees with the measured end-to-end result.
+- **152064, not a round number.** It is the largest vocabulary measured both ways, so the cap never covers an unmeasured size.
+- **Build flag, not runtime branch.** It matches the existing per-build defaults and passes the kernel-port-dispatch check.
+- **Fix the tool with the port.** The microbenchmark gate now follows the production predicate, so a future backend port does not hide behind the same bug.
+- **Add `--top-k` to the decode benchmark.** The joint filter can now be benchmarked end to end without a custom harness.
+
+## 9. Residual Risks
+
+- **Cause not isolated.** Why the synthetic batch-1 cell does not predict real decode on this GPU is unknown. The bf16 rerun ruled out the logits dtype only.
+- **Vocabularies above 152064 are unmeasured and unchanged.** gpt-oss (201088) and Gemma 3 (262144) stay on the stock chain.
+- **Metal and CUDA are unchanged and not verified here.** The non-ROCm arm of the per-build tests was not run.
+- **Qwen2.5-7B was measured on the measurement build only.** The final build was checked on Llama 3.1.
+- **One GPU.** The cap is calibrated on gfx1151 only.
+
+## 10. Learning Points
+
+- **A constant measured on one GPU is not a property of the algorithm.** A port that inherits a calibrated cap needs its own measurement, and the harness has to be able to run on the port.
+- **A measuring tool with its own backend gate can silently exclude a backend.** The gate should reuse the production predicate.
+- **A synthetic cell is a proxy.** When the proxy and the end-to-end run disagree, the end-to-end run decides, and the disagreement is recorded as unexplained.
+- **Interleaved guarded pairs make small differences readable.** The chain arm's wider spread would have hidden a 5% difference in sequential runs.
+
+## 11. Follow-up
+
+The stock chain's `top_k_filter` calls `argpartition` without checking `top_k` against the vocabulary size. This is pre-existing and not changed here; it affects the chain arm when `top_k` is at or above the vocabulary.
diff --git a/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.ko.md b/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.ko.md
new file mode 100644
index 000000000..6f311259b
--- /dev/null
+++ b/TECHNICAL_REPORTS/2218-rocm-joint-rejection-cap-20261008.ko.md
@@ -0,0 +1,159 @@
+# 기술 보고서: PR #2218 - ROCm에서 top-k + top-p 결합 rejection 어휘 상한 재보정
+
+**날짜**: 2026-10-08
+
+**상태**: gfx1151 호스트(ROCm/HIP)에서 구현 및 검증 완료. 코드 head `7d737d49`, main `ae343d84` 기준으로 리베이스, PR 열림, 머지 대기. #2157 종료, #1801의 일부.
+
+**언어**: C++(`mlx_cxx_bridge.cpp`, `mlx_cxx_bridge.h`), Rust(`lib.rs`, `sampling_rejection_tests.rs`, `examples/rejection_sampling_microbench.rs`, `src/bin/bench_decode.rs`), 셸(`scripts/bench_decode.sh`), Markdown(벤치마크 페이지, `installation.md`, `environment-variables.md`)
+
+**위험도**: 낮음. 상수 하나의 값만 바뀌고, 그것도 ROCm 빌드에서만 바뀐다. ROCm 빌드는 이제 top-k와 top-p를 함께 쓰는 경우를 어휘 크기 32768 대신 152064까지 rejection 커널로 보낸다. `MLXCEL_SAMPLING_REJECTION=0`으로 기존 체인으로 돌아간다. Metal과 CUDA 빌드는 32768을 유지하지만, 이 호스트에서는 그 경로를 실행하지 못했다.
+
+## 요약
+
+rejection 샘플러는 `REJECTION_JOINT_VOCAB_MAX`(32768)까지만 top-k와 top-p를 함께 쓰는 경우를 커널로 보낸다. 이 값은 M1 Ultra에서 측정한 것이다. 거기서 결합 top-k + top-p는 32K에서 1.27배에서 1.64배 빨랐고 152K에서는 0.71배에서 0.83배로 느렸다. HIP 포트(#2064)는 이 값을 측정 없이 물려받았다. 그래서 ROCm에서 Llama 3.1처럼 어휘 크기가 128256인 모델에 `--top-k 40 --top-p 0.95`를 주면 커널에 도달하지 않았다.
+
+gfx1151에서 마이크로벤치마크만 보면 32768을 유지하게 된다. 배치 4와 8 셀은 모든 어휘에서 이기지만(파이프라인 1.05배에서 2.02배), 합성 배치 1 셀은 32768 초과에서 파이프라인 기준 0.90배에서 0.98배다. 128256 이상에서 확인용으로 요구되는 종단간 디코드는 이 셀과 다른 결과를 낸다. 결합 경로를 켜면 Meta-Llama-3.1-8B-Instruct-4bit(128256)는 32.67에서 37.57 tok/s(1.15배), Qwen2.5-7B-Instruct-4bit(152064)는 41.91에서 46.92 tok/s(1.12배)로 빨라진다. 인터리브한 가드 쌍 3회의 중앙값이고, 모든 커널 실행이 모든 체인 실행보다 빨랐다. 최종 브랜치 빌드의 엔진 경로에서 Llama는 33.15에서 37.73 tok/s(1.14배)다.
+
+ROCm 값은 이제 152064이고, 양쪽 모두 측정한 가장 큰 어휘 크기다. 런타임 백엔드 분기 없이 빌드 플래그로 정한다. 새 브리지 접근자가 현재 값을 알려주고, 테스트가 빌드별로 값을 고정한다. 합성 배치 1 셀이 실제 디코드를 예측하지 못하는 원인은 분리하지 못했다. 152064보다 큰 어휘는 측정하지 않았고 바뀌지 않는다. Metal과 CUDA는 검증하지 못했다. 오케스트레이터의 리베이스된 head `make verify-rocm`은 통과한다(161개 스위트, 12,189 통과, 0 실패, 398 무시).
+
+## 1. 문제 정의
+
+### 1.1 다른 GPU에서 보정된 상한
+
+`src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp`의 `REJECTION_JOINT_VOCAB_MAX`는 top-p가 켜진 경우 `sampling_rejection_routes`가 읽는다. 값이 제한을 거는 top-k는 `vocab <= REJECTION_JOINT_VOCAB_MAX`일 때만 커널로 간다. M1 Ultra에서 큰 어휘의 top-k가 지는 이유는 어휘가 커질수록 rejection 라운드가 더 필요하고 각 라운드가 스레드그룹 하나의 전체 행 훑기이기 때문이다. gfx1151은 스레드그룹당 대역폭과 실행 비용이 달라 교차점이 다른 곳에 있을 수 있다. 아무도 측정하지 않았다. `rocm-samplers-gfx1151-2026-10-05.md`는 어휘 128256 모델의 `--top-k 40 --top-p 0.95`가 커널에 도달하지 않으며 ROCm에서 상한이 맞는지는 측정하지 않았다고 적고 있다.
+
+### 1.2 마이크로벤치마크가 ROCm에서 실행되지 않았다
+
+행렬을 측정하는 도구인 `examples/rejection_sampling_microbench.rs`는 `custom_kernels_available()`로 게이트되어 있었다. 이 함수는 정의상 Metal 또는 CUDA에서만 참이므로, ROCm 빌드에서 벤치마크는 실행을 거부했다. 커널을 ROCm에서 돌게 한 포트에서 측정 도구는 같이 포팅되지 않았기 때문에 교차점이 측정되지 않았다. 어휘 목록에도 128256(Llama 3)과 151936(Qwen3)이 없었다.
+
+### 1.3 결합 필터를 종단간으로 벤치마크할 방법이 없었다
+
+`mlxcel-bench-decode`와 `scripts/bench_decode.sh`에 `--top-k` 옵션이 없어서, 이슈가 열린 바로 그 경우를 일반 디코드 벤치마크로 잴 수 없었다.
+
+## 2. 변경 요약
+
+| 영역 | 변경 |
+|---|---|
+| `mlx_cxx_bridge.cpp` | `REJECTION_JOINT_VOCAB_MAX`는 `#ifdef MLXCEL_BRIDGE_ROCM_BACKEND`에서 152064, 그 외에는 32768. gfx1151 표는 상수 위 주석에 있다. 커널로 가지 않는 경우의 메시지가 빌드의 상한을 알려준다. |
+| `mlx_cxx_bridge.h`, `lib.rs` | 새 접근자 `sampling_rejection_joint_vocab_max()`. |
+| `sampling_rejection_tests.rs` | 상한을 빌드별로 고정. 라우팅 행렬이 빌드별로 65536, 128256, 151936, 152064를 다룬다. 큰 어휘 거절 테스트는 빌드의 상한보다 큰 어휘를 고른다. |
+| `examples/rejection_sampling_microbench.rs` | 어휘 128256, 151936 추가. `--dtype f32\|bf16\|f16`, `--config <label>` 옵션. 빌드의 상한을 출력. 포트 게이트 수정. |
+| `src/bin/bench_decode.rs`, `scripts/bench_decode.sh` | 새 `--top-k` 옵션(파일 이름 태그 `_k<K>`, 값 검증). |
+| 문서 | 새 결과 페이지 `docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md`, `rocm-samplers-gfx1151-2026-10-05.md`에서 링크. `installation.md`의 ROCm 샘플링 디코드 행이 Llama 3와 Qwen 어휘에서 어떤 필터 조합이 커널로 가는지 나열. `environment-variables.md`의 `MLXCEL_SAMPLING_REJECTION` 행 갱신. |
+| `benchmarks/` | 원시 CSV: f32 마이크로벤치마크 3회, bf16 3회, 측정 빌드의 종단간 쌍, 최종 빌드의 전후 쌍. |
+
+## 3. 설계
+
+### 3.1 빌드별 상수
+
+```cpp
+#ifdef MLXCEL_BRIDGE_ROCM_BACKEND
+constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 152064;
+#else
+constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 32768;
+#endif
+
+int32_t sampling_rejection_joint_vocab_max() {
+    return REJECTION_JOINT_VOCAB_MAX;
+}
+```
+
+fused-MoE SGY 기본값(#2098)과 #2189의 `cfg!(feature = "rocm")` 기본값이 쓰는 빌드 플래그 패턴이다. ROCm 빌드에는 Metal이나 CUDA 백엔드가 없으므로 런타임 백엔드 비교가 필요 없고, `verify-kernel-port-dispatch`도 만족한다. 이 상수를 읽는 곳은 `sampling_rejection_routes` 하나이고 접근자는 같은 값을 알려준다. 따라서 행 단위 샘플링을 통합하는 단계(에픽 #2166 Phase 2)는 숫자를 복사하지 말고 `sampling_rejection_routes`나 접근자를 호출해야 한다.
+
+### 3.2 값을 고정하는 테스트
+
+`sampling_rejection_tests.rs`의 `the_joint_vocab_cap_is_the_measured_crossover`는 `feature = "rocm"`로 빌드하면 152064, 아니면 32768을 기대한다. 그래서 새 측정 없이는 상수를 바꿀 수 없다. 이어서 정책이 상한에서 정확히 바뀌는지(`cap`에서는 커널로, `cap + 1`에서는 거절. min-p 유무 모두), top-p 단독은 상한을 넘어도 커널로 가는지, 제한이 걸리지 않는 top-k(`top_k >= vocab`)가 상한을 끌어들이지 않는지 확인한다.
+
+### 3.3 마이크로벤치마크 포트 게이트
+
+게이트는 이제 `custom_kernels_available()` 대신 프로덕션 라우팅이 쓰는 술어인 `sampling_rejection_backend_supported()`를 확인한다. 하니스는 `fused_sample`이 하는 일을 측정하므로, 어떤 백엔드에 적용되는지에 대해 `fused_sample`과 같은 판단을 해야 한다.
+
+### 3.4 채택하지 않은 안
+
+- **ROCm에서 32768 유지.** 이슈의 문자 그대로의 규칙(7절)을 따르지만, 이슈가 열린 바로 그 경우가 12%에서 15% 느린 채로 남는다.
+- **상한을 위한 런타임 백엔드 비교.** 빌드 플래그로 충분하고 kernel-port-dispatch 검사도 통과한다.
+- **152064보다 큰 상한.** 더 큰 어휘(gpt-oss 201088, Gemma 262144)는 측정하지 않았고, 기존 주석은 측정하지 않은 어휘를 포함하지 말라고 요구한다.
+
+## 4. 이 변경에 특유한 위험
+
+- ROCm에서 어휘 65536부터 152064까지의 top-k + top-p 디코드가 경로를 바꾼다. rejection 커널은 기존 체인과 분포가 같지만 난수 스트림이 달라서, 고정 시드에서 샘플된 토큰이 이전과 다르다.
+- 합성 배치 1 셀은 128256 이상에서 단일 행은 커널이 체인보다 느리다고 말한다. 실제 디코드는 반대이고 이유는 모른다. 다른 모델, 배치 크기, GPU에서는 그 셀 쪽으로 기울 수 있다.
+- 상한은 GPU별이 아니라 빌드별 숫자 하나다. 다른 ROCm 제품(예: 외장 GPU)은 교차점이 다를 수 있다.
+
+## 5. 검증
+
+### 5.1 게이트
+
+- 오케스트레이터 게이트, 리베이스된 head `7d737d49`의 `make verify-rocm`: 161개 스위트, 12,189 통과, 0 실패, 398 무시.
+- 이전 `ad844354` 리베이스에서 PR 본문이 기록한 것: `sampling_rejection_tests`와 `sampling_fixed_key_tests`(34개 통과, 지원, 분포, 고정 키 테스트 포함), `sampling_gumbel_kill_switch`와 `sampling_rejection_kill_switch` 테스트, `cargo test --test dead_doc_pointers` 통과.
+- 최종 빌드의 디스패치 로그: `mlxcel generate`는 기본으로 `rejection kernel (batch 1, vocab 128256, ... top_k 40, top_p 0.95 ...)`을 기록하고, 스위치를 켜면 `argpartition chain: pinned by MLXCEL_SAMPLING_REJECTION`을 기록한다. 따라서 전후 쌍의 각 쪽은 표기된 경로로 실행되었다.
+- 모든 벤치마크는 `scripts/rocm_gpu_guard.sh`를 거쳤다.
+
+검증하지 못한 것: 이 호스트에는 Metal과 CUDA가 없다. 그 값(32768)은 바뀌지 않았고 라우팅 코드는 공유되지만, 빌드별 테스트의 비 ROCm 쪽은 여기서 실행하지 못했다.
+
+## 6. 결과
+
+### 6.1 환경
+
+AMD Ryzen AI MAX+ 395와 Radeon 8060S(`gfx1151`), 96 GiB VRAM 할당, ROCm 10.0.0(HIP 7.15.26333), MLX 핀 `81ba1c6a`, ROCm 오버레이 `75915908`, `cargo build --release --features rocm`. 측정 빌드는 `main`의 `84d3a7bc`에 이 변경을 얹고 ROCm 상한을 `INT32_MAX`로 올린 것이어서 `fused_sample`이 모든 결합 셀을 커널로 보낸다. 소스가 바뀌기 전에 바이너리를 복사해 두었기 때문에 이 빌드의 CSV는 `mlxcel_commit`을 `unknown`으로 기록한다. 최종 빌드의 CSV는 `79ea5814`를 기록한다. 체크포인트는 `mlx-community/Meta-Llama-3.1-8B-Instruct-4bit`(128256)와 `mlx-community/Qwen2.5-7B-Instruct-4bit`(152064)다.
+
+### 6.2 마이크로벤치마크 격자
+
+`rejection_sampling_microbench`, 셀당 측정 200회와 워밍업 30회, 3회 실행, 배치 1/4/8, 어휘 32768, 65536, 128256, 151936, 152064, top-k 40 + top-p 0.9, f32 로짓(모든 구성)과 bf16 로짓(결합만, 두 체크포인트 모두 bf16이므로). 모든 결합 셀이 `routed=yes`다. 파이프라인 쪽은 `fused_sample`을 거치므로, 프로덕션이 커널로 보내지 않는 셀에서는 체인을 체인과 비교하게 된다. 그래서 측정 빌드는 상한을 풀었다. `pipe_x`는 파이프라인 속도 향상(체인 시간을 커널 시간으로 나눈 값)이고, 이슈가 읽으라고 한 값이며 격리 `iso_x`가 아니다. f32, 3회 중앙값:
+
+| 어휘 | 배치 1 pipe_x | 배치 4 pipe_x | 배치 8 pipe_x | 배치 1 iso_x |
+|---|---|---|---|---|
+| 32768 | 1.00 (0.96-1.04) | 1.17 | 1.44 | 2.23 |
+| 65536 | 0.98 (0.95-1.05) | 1.18 | 1.64 | 1.59 |
+| 128256 | 0.98 (0.96-0.99) | 1.28 | 1.80 | 0.96 |
+| 151936 | 0.90 (0.88-0.92) | 1.36 | 1.90 | 0.92 |
+| 152064 | 0.93 (0.88-0.97) | 1.29 | 2.02 | 0.92 |
+
+배치 4와 8은 모든 어휘에서 이긴다. 지는 셀은 배치 1뿐이고, 128256 이상에서는 격리 셀도 1.0 미만(0.92에서 0.96)이다. bf16 재실행도 같다. 배치 1 pipe_x는 128256에서 0.98, 151936에서 0.89, 152064에서 0.86이고, 배치 4는 1.05에서 1.23, 배치 8은 1.38에서 1.54다. 따라서 dtype은 실제 디코드와 결과가 다른 원인이 아니다. `rounds`와 시간을 포함한 전체 표는 벤치마크 페이지에 있다.
+
+배치 1 파이프라인 셀이 말해줄 수 있는 것은 제한적이다. 프로덕션이 커널로 보내지 않는 행(top-k 단독, min-p 단독, 체인 대 체인)도 중앙값 기준 0.90배에서 1.11배 사이로 흩어지므로, 0.95에서 1.05 사이의 배치 1 `pipe_x`는 어느 쪽이든 잡음 범위 안이다. 합성 순전파는 스텝당 2110에서 2659 us였고, 상한 초과 카운터는 0이었다.
+
+### 6.3 종단간 디코드
+
+`scripts/bench_decode.sh`, pp512/tg128, `--temperature 0.8 --top-k 40 --top-p 0.95`. 커널 쪽과, 같은 바이너리에 `MLXCEL_SAMPLING_REJECTION=0`을 준 쪽을 비교한다. 각 쌍은 가드 시도 한 번 안에서 실행했고 먼저 도는 쪽을 번갈아 바꿨다. 쌍 3회의 중앙값:
+
+| 모델(어휘) | 기존 체인 tok/s | rejection 커널 tok/s | 비율 |
+|---|---|---|---|
+| Meta-Llama-3.1-8B-Instruct-4bit (128256), 측정 빌드 | 33.94 / 31.64 / 32.67, 중앙값 32.67 | 37.70 / 37.37 / 37.57, 중앙값 37.57 | 1.15배 |
+| Qwen2.5-7B-Instruct-4bit (152064), 측정 빌드 | 42.68 / 41.91 / 40.79, 중앙값 41.91 | 46.92 / 46.40 / 47.18, 중앙값 46.92 | 1.12배 |
+| Meta-Llama-3.1-8B-Instruct-4bit (128256), 최종 빌드, 엔진 경로 | 33.15 / 35.76 / 33.09, 중앙값 33.15 | 37.61 / 38.45 / 37.73, 중앙값 37.73 | 1.14배 |
+
+모든 모델에서 모든 커널 실행이 모든 체인 실행보다 빠르다. 각 쌍 안에서 향상폭은 Llama(측정 빌드) 11%에서 18%, Qwen 10%에서 16%, 최종 Llama 빌드 8%에서 14%다. 체인 쪽이 커널 쪽보다 더 흩어지며, 이는 #2064에서 Llama 3.1의 top-p 체인이 그랬던 것과 같다. 최종 빌드는 main으로 리베이스한 브랜치이고, 거기서 `mlxcel-bench-decode`는 엔진을 거쳐 디코드한다(#2224, #2225. CSV의 `decode_path` 열이 `engine`). 이 빌드의 "이전" 쪽은 `MLXCEL_SAMPLING_REJECTION=0`이며, 이 구성에서 main이 택하는 경로다. 공유 GPU가 몇 시간씩 경합 상태여서 Qwen2.5-7B는 최종 빌드에서 다시 돌리지 않았다.
+
+## 7. 결정 규칙과 문자 그대로 적용하지 않은 이유
+
+이슈의 규칙은, 해당 어휘와 그보다 작은 모든 측정 어휘의 모든 배치 셀이 `pipe_x >= 1.0`인 가장 큰 측정 어휘 V를 택하고, V가 128256 이상이면 종단간으로 확인하라는 것이다. 문자 그대로 읽으면 합성 배치 1 셀 때문에 32768에서 멈춘다. 배치 1 셀은 32768 초과에서 파이프라인 기준 0.90배에서 0.98배이고(65536에서 이미 0.98배), 32768 자체는 1.00배다. 이 규칙은 기존 상한을 유지하게 한다.
+
+같은 규칙이 요구하는 확인용 종단간 실행은 이 셀과 큰 차이로 어긋난다. Llama 3.1은 1.15배, Qwen 2.5는 1.12배이고 두 쪽의 범위가 겹치지 않는다. 마이크로벤치마크 자체의 배치 4와 8 셀도 모든 곳에서 이긴다. 합성 셀 하나 때문에 이슈가 열린 바로 그 구성을 더 느린 경로에 두는 것은 잘못된 선택이므로, ROCm 값은 양쪽 모두 측정한 가장 큰 어휘인 152064로 했다. 이 이탈은 PR 본문과 벤치마크 페이지에 명시되어 있다.
+
+## 8. 기술적 결정
+
+- **합성 셀이 아니라 디코드로 결정한다.** 사용자가 실행하는 것은 실제 디코드다. 합성 배치 1 셀은 여러 어휘에서 잡음 범위 안이고 측정된 종단간 결과와 어긋난다.
+- **둥근 숫자가 아니라 152064.** 양쪽 모두 측정한 가장 큰 어휘이므로, 상한이 측정하지 않은 크기를 포함하지 않는다.
+- **런타임 분기가 아니라 빌드 플래그.** 기존 빌드별 기본값과 같은 방식이고 kernel-port-dispatch 검사를 통과한다.
+- **포트와 함께 도구도 고친다.** 마이크로벤치마크 게이트가 프로덕션 술어를 따르므로, 이후 백엔드 포트가 같은 버그 뒤에 숨지 않는다.
+- **디코드 벤치마크에 `--top-k`를 추가한다.** 결합 필터를 별도 하니스 없이 종단간으로 벤치마크할 수 있다.
+
+## 9. 남은 위험
+
+- **원인을 분리하지 못했다.** 이 GPU에서 합성 배치 1 셀이 실제 디코드를 예측하지 못하는 이유는 모른다. bf16 재실행은 로짓 dtype만 배제했다.
+- **152064보다 큰 어휘는 측정하지 않았고 바뀌지 않는다.** gpt-oss(201088)와 Gemma 3(262144)는 기존 체인에 남는다.
+- **Metal과 CUDA는 바뀌지 않았고 여기서 검증하지 못했다.** 빌드별 테스트의 비 ROCm 쪽은 실행하지 못했다.
+- **Qwen2.5-7B는 측정 빌드에서만 측정했다.** 최종 빌드는 Llama 3.1로 확인했다.
+- **GPU 한 종류.** 상한은 gfx1151에서만 보정되었다.
+
+## 10. 배운 점
+
+- **한 GPU에서 측정한 상수는 알고리즘의 속성이 아니다.** 보정된 상한을 물려받은 포트는 자체 측정이 필요하고, 하니스가 그 포트에서 실행될 수 있어야 한다.
+- **자체 백엔드 게이트가 있는 측정 도구는 조용히 한 백엔드를 제외할 수 있다.** 게이트는 프로덕션 술어를 재사용해야 한다.
+- **합성 셀은 대리 지표다.** 대리 지표와 종단간 실행이 어긋나면 종단간 실행이 결정하고, 어긋남은 설명되지 않은 것으로 기록한다.
+- **인터리브한 가드 쌍은 작은 차이를 읽게 해 준다.** 체인 쪽의 큰 흩어짐은 순차 실행에서는 5% 차이를 가렸을 것이다.
+
+## 11. 후속 작업
+
+기존 체인의 `top_k_filter`는 `top_k`를 어휘 크기와 비교하지 않고 `argpartition`을 호출한다. 이는 기존부터 있던 문제이고 여기서는 바꾸지 않았다. `top_k`가 어휘 크기 이상일 때 체인 쪽에 영향을 준다.
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_chain.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_chain.csv
new file mode 100644
index 000000000..3d426b626
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_chain.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,498.01,1028.10,3771.24,33.94,2026-10-07,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,483.72,1058.47,4045.77,31.64,2026-10-07,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,482.66,1060.78,3918.44,32.67,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_kern.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_kern.csv
new file mode 100644
index 000000000..c864d1d7e
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Meta-Llama-3.1-8B-Instruct-4bit_kern.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,500.57,1022.84,3394.82,37.70,2026-10-07,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,650.88,786.63,3425.41,37.37,2026-10-07,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,537.25,953.00,3406.74,37.57,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_chain.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_chain.csv
new file mode 100644
index 000000000..4d3ef5a6f
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_chain.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,337.03,1519.14,2999.31,42.68,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,341.74,1498.22,3053.81,41.91,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,312.67,1637.52,3137.77,40.79,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_kern.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_kern.csv
new file mode 100644
index 000000000..ab8cdb0ba
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_Qwen2.5-7B-Instruct-4bit_kern.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,331.26,1545.60,2727.84,46.92,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,311.42,1644.08,2758.81,46.40,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
+Qwen2.5-7B-Instruct-4bit,models/mlx/Qwen2.5-7B-Instruct-4bit,512,128,337.93,1515.13,2712.76,47.18,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,unknown,81ba1c6a,75915908,7.15.26333
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run1.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run1.csv
new file mode 100644
index 000000000..b40a621a3
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run1.csv
@@ -0,0 +1,16 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k+top-p,32768,1,3,yes,327.975,142.507,2.3015,2454.112,2458.252,0.9983
+top-k+top-p,32768,4,3,yes,682.168,178.404,3.8237,2822.154,2334.184,1.2091
+top-k+top-p,32768,8,4,yes,1203.143,207.859,5.7883,3383.396,2395.225,1.4126
+top-k+top-p,65536,1,3,yes,422.401,260.298,1.6228,2537.508,2383.962,1.0644
+top-k+top-p,65536,4,4,yes,979.855,348.653,2.8104,3117.398,2505.644,1.2442
+top-k+top-p,65536,8,4,yes,1753.104,381.064,4.6006,4025.660,2572.882,1.5647
+top-k+top-p,128256,1,4,yes,502.521,582.100,0.8633,2640.052,2695.320,0.9795
+top-k+top-p,128256,4,5,yes,1244.100,708.777,1.7553,3476.782,2930.128,1.1866
+top-k+top-p,128256,8,5,yes,2220.800,1034.898,2.1459,4608.584,3403.746,1.3540
+top-k+top-p,151936,1,4,yes,548.878,705.622,0.7779,2682.686,3052.557,0.8788
+top-k+top-p,151936,4,4,yes,1386.055,1021.623,1.3567,3662.984,3146.239,1.1642
+top-k+top-p,151936,8,6,yes,2494.282,1237.497,2.0156,4861.197,3671.416,1.3241
+top-k+top-p,152064,1,4,yes,551.132,682.980,0.8070,2692.299,3134.895,0.8588
+top-k+top-p,152064,4,6,yes,1404.741,1036.582,1.3552,3576.230,4609.010,0.7759
+top-k+top-p,152064,8,6,yes,2500.754,1247.978,2.0038,5208.904,3524.281,1.4780
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run2.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run2.csv
new file mode 100644
index 000000000..aed0b8e4a
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run2.csv
@@ -0,0 +1,16 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k+top-p,32768,1,1,yes,328.906,143.569,2.2909,2463.712,2275.236,1.0828
+top-k+top-p,32768,4,3,yes,687.177,179.245,3.8337,2846.841,2438.311,1.1675
+top-k+top-p,32768,8,4,yes,1212.792,205.365,5.9055,3363.185,2397.552,1.4028
+top-k+top-p,65536,1,3,yes,416.901,248.626,1.6768,2555.937,2593.810,0.9854
+top-k+top-p,65536,4,4,yes,966.040,342.251,2.8226,3139.172,2651.746,1.1838
+top-k+top-p,65536,8,4,yes,1834.488,378.779,4.8432,4001.949,2590.475,1.5449
+top-k+top-p,128256,1,4,yes,501.629,563.266,0.8906,2640.637,2706.174,0.9758
+top-k+top-p,128256,4,5,yes,1240.464,717.825,1.7281,3439.454,3011.923,1.1419
+top-k+top-p,128256,8,5,yes,2220.490,1021.955,2.1728,4751.470,3226.474,1.4727
+top-k+top-p,151936,1,4,yes,549.108,722.464,0.7600,2670.391,2909.111,0.9179
+top-k+top-p,151936,4,4,yes,1387.250,1036.662,1.3382,3623.478,3320.014,1.0914
+top-k+top-p,151936,8,6,yes,2497.680,1235.315,2.0219,5616.204,3430.575,1.6371
+top-k+top-p,152064,1,4,yes,549.690,706.734,0.7778,2700.940,2901.890,0.9308
+top-k+top-p,152064,4,6,yes,1405.784,1051.781,1.3366,3632.372,3463.004,1.0489
+top-k+top-p,152064,8,6,yes,2492.961,1247.878,1.9978,5335.337,3627.819,1.4707
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run3.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run3.csv
new file mode 100644
index 000000000..a02687cd6
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-bf16-run3.csv
@@ -0,0 +1,16 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k+top-p,32768,1,3,yes,327.924,144.561,2.2684,2465.583,2258.334,1.0918
+top-k+top-p,32768,4,3,yes,685.735,179.316,3.8242,2841.379,2332.311,1.2183
+top-k+top-p,32768,8,4,yes,1199.698,208.932,5.7421,3376.305,2320.789,1.4548
+top-k+top-p,65536,1,3,yes,421.921,252.012,1.6742,2555.728,2513.352,1.0169
+top-k+top-p,65536,4,4,yes,965.429,350.016,2.7582,3115.666,2542.227,1.2256
+top-k+top-p,65536,8,4,yes,1749.950,374.682,4.6705,4163.998,2764.785,1.5061
+top-k+top-p,128256,1,4,yes,501.930,578.854,0.8671,2618.892,2887.600,0.9069
+top-k+top-p,128256,4,5,yes,1251.134,709.530,1.7633,3481.594,3136.815,1.1099
+top-k+top-p,128256,8,5,yes,2232.122,1027.906,2.1715,4896.524,3273.284,1.4959
+top-k+top-p,151936,1,4,yes,548.598,725.941,0.7557,2679.838,3006.282,0.8914
+top-k+top-p,151936,4,4,yes,1383.081,1044.898,1.3237,4211.532,3319.862,1.2686
+top-k+top-p,151936,8,6,yes,2484.165,1233.601,2.0138,5106.730,3695.511,1.3819
+top-k+top-p,152064,1,4,yes,549.871,679.483,0.8092,2683.269,3126.610,0.8582
+top-k+top-p,152064,4,6,yes,1382.550,1041.211,1.3278,3624.309,3157.829,1.1477
+top-k+top-p,152064,8,6,yes,2496.538,1253.699,1.9913,5073.006,3586.617,1.4144
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run1.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run1.csv
new file mode 100644
index 000000000..56a555733
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run1.csv
@@ -0,0 +1,61 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k=40,32768,1,3,no,171.311,142.878,1.1990,2297.219,2275.268,1.0096
+top-k=40,32768,4,5,no,309.951,172.904,1.7926,2720.903,2603.081,1.0453
+top-k=40,32768,8,5,no,528.310,212.468,2.4865,2884.019,2820.762,1.0224
+top-k=40,65536,1,4,no,199.824,255.980,0.7806,2348.446,2338.409,1.0043
+top-k=40,65536,4,4,no,440.736,357.249,1.2337,2590.720,2930.243,0.8841
+top-k=40,65536,8,4,no,796.563,413.184,1.9279,3123.871,3454.500,0.9043
+top-k=40,128256,1,4,no,270.587,615.493,0.4396,2386.920,2398.130,0.9953
+top-k=40,128256,4,5,no,765.604,807.803,0.9478,2974.457,3301.237,0.9010
+top-k=40,128256,8,6,no,1455.808,1117.313,1.3030,4404.197,3815.505,1.1543
+top-k=40,151936,1,5,no,298.278,737.772,0.4043,2423.657,2413.410,1.0042
+top-k=40,151936,4,5,no,893.464,1106.713,0.8073,3292.167,3231.556,1.0188
+top-k=40,151936,8,5,no,1871.235,1381.879,1.3541,4404.679,4148.407,1.0618
+top-k=40,152064,1,4,no,298.991,717.253,0.4169,2570.369,2418.310,1.0629
+top-k=40,152064,4,6,no,918.351,1158.069,0.7930,3410.429,3095.319,1.1018
+top-k=40,152064,8,6,no,1829.677,1685.768,1.0854,4146.764,4427.966,0.9365
+top-p=0.9,32768,1,1,yes,261.039,90.089,2.8976,2387.337,2519.492,0.9475
+top-p=0.9,32768,4,1,yes,533.970,101.370,5.2675,2671.543,2535.623,1.0536
+top-p=0.9,32768,8,1,yes,964.567,112.751,8.5548,3133.880,2576.102,1.2165
+top-p=0.9,65536,1,1,yes,328.004,142.558,2.3008,2435.007,2544.924,0.9568
+top-p=0.9,65536,4,1,yes,788.898,174.757,4.5143,2960.303,2542.743,1.1642
+top-p=0.9,65536,8,1,yes,1490.953,203.221,7.3366,3816.788,2640.611,1.4454
+top-p=0.9,128256,1,1,yes,478.106,261.200,1.8304,2617.199,2722.363,0.9614
+top-p=0.9,128256,4,1,yes,1425.852,326.351,4.3691,3715.653,2854.136,1.3018
+top-p=0.9,128256,8,1,yes,2819.883,433.021,6.5121,5823.425,2760.483,2.1096
+top-p=0.9,151936,1,1,yes,539.440,302.607,1.7826,2663.842,2562.448,1.0396
+top-p=0.9,151936,4,1,yes,1619.394,413.465,3.9166,4013.248,2916.051,1.3763
+top-p=0.9,151936,8,1,yes,3356.067,497.462,6.7464,6333.787,2933.176,2.1594
+top-p=0.9,152064,1,1,yes,539.942,307.045,1.7585,2670.848,2708.192,0.9862
+top-p=0.9,152064,4,2,yes,1660.701,416.460,3.9877,3965.481,2866.641,1.3833
+top-p=0.9,152064,8,2,yes,3285.304,500.919,6.5586,6157.874,2920.476,2.1085
+min-p=0.05,32768,1,1,no,129.672,94.016,1.3793,2332.037,2310.464,1.0093
+min-p=0.05,32768,4,1,no,145.863,100.318,1.4540,2597.627,2269.229,1.1447
+min-p=0.05,32768,8,1,no,207.459,109.626,1.8924,2671.266,2545.728,1.0493
+min-p=0.05,65536,1,1,no,153.017,144.571,1.0584,2419.112,2643.729,0.9150
+min-p=0.05,65536,4,1,no,220.193,170.920,1.2883,2353.177,2598.079,0.9057
+min-p=0.05,65536,8,1,no,323.356,192.140,1.6829,2675.724,2578.940,1.0375
+min-p=0.05,128256,1,1,no,200.656,263.474,0.7616,2699.910,2329.791,1.1589
+min-p=0.05,128256,4,1,no,345.818,317.345,1.0897,2890.726,2573.234,1.1234
+min-p=0.05,128256,8,1,no,548.347,383.559,1.4296,2975.195,2763.692,1.0765
+min-p=0.05,151936,1,1,no,218.129,306.284,0.7122,2619.914,2590.178,1.0115
+min-p=0.05,151936,4,1,no,391.072,420.157,0.9308,2795.915,2852.701,0.9801
+min-p=0.05,151936,8,1,no,623.638,465.422,1.3399,2968.231,2964.502,1.0013
+min-p=0.05,152064,1,1,no,247.834,307.056,0.8071,2536.950,2618.273,0.9689
+min-p=0.05,152064,4,1,no,390.832,419.826,0.9309,2603.126,2887.939,0.9014
+min-p=0.05,152064,8,1,no,619.000,464.170,1.3336,2859.053,3055.026,0.9359
+top-k+top-p,32768,1,5,yes,318.316,142.998,2.2260,2446.353,2552.673,0.9583
+top-k+top-p,32768,4,5,yes,699.050,173.596,4.0269,2857.738,2596.751,1.1005
+top-k+top-p,32768,8,5,yes,1253.578,206.757,6.0630,3452.845,2679.836,1.2885
+top-k+top-p,65536,1,4,yes,407.834,257.262,1.5853,2532.517,2673.282,0.9473
+top-k+top-p,65536,4,4,yes,1013.118,366.828,2.7618,3158.163,2900.133,1.0890
+top-k+top-p,65536,8,4,yes,1865.154,415.719,4.4866,4394.993,2537.038,1.7323
+top-k+top-p,128256,1,4,yes,592.099,617.457,0.9589,2730.808,2763.908,0.9880
+top-k+top-p,128256,4,5,yes,1794.241,810.629,2.2134,4123.493,3246.141,1.2703
+top-k+top-p,128256,8,6,yes,3595.666,1135.728,3.1660,6290.603,3517.863,1.7882
+top-k+top-p,151936,1,5,yes,666.468,728.986,0.9142,2808.607,3124.410,0.8989
+top-k+top-p,151936,4,5,yes,2077.833,1105.511,1.8795,4666.655,3427.800,1.3614
+top-k+top-p,151936,8,5,yes,4019.160,1357.182,2.9614,7083.431,3560.242,1.9896
+top-k+top-p,152064,1,4,yes,666.188,721.792,0.9230,2816.758,2909.179,0.9682
+top-k+top-p,152064,4,6,yes,2060.220,1136.119,1.8134,4415.835,3420.163,1.2911
+top-k+top-p,152064,8,6,yes,4350.641,1344.479,3.2359,7073.620,3505.835,2.0177
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run2.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run2.csv
new file mode 100644
index 000000000..396b61652
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run2.csv
@@ -0,0 +1,61 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k=40,32768,1,4,no,194.855,155.631,1.2520,2316.586,2282.083,1.0151
+top-k=40,32768,4,5,no,313.207,174.076,1.7993,2463.867,2492.067,0.9887
+top-k=40,32768,8,5,no,526.407,208.130,2.5292,2894.568,2855.281,1.0138
+top-k=40,65536,1,4,no,200.285,255.719,0.7832,2331.357,2333.729,0.9990
+top-k=40,65536,4,4,no,440.074,361.156,1.2185,2579.994,2825.502,0.9131
+top-k=40,65536,8,4,no,806.661,409.047,1.9720,3125.784,3353.719,0.9320
+top-k=40,128256,1,4,no,271.389,608.059,0.4463,2396.637,2409.131,0.9948
+top-k=40,128256,4,5,no,763.571,789.148,0.9676,3000.533,3355.683,0.8942
+top-k=40,128256,8,6,no,1427.925,1115.350,1.2802,4225.194,3882.334,1.0883
+top-k=40,151936,1,5,no,298.689,737.041,0.4053,2454.542,2397.814,1.0237
+top-k=40,151936,4,5,no,925.825,1091.686,0.8481,3209.739,5005.202,0.6413
+top-k=40,151936,8,5,no,1689.556,1336.183,1.2645,4596.320,4128.620,1.1133
+top-k=40,152064,1,4,no,299.001,725.089,0.4124,2432.858,2414.907,1.0074
+top-k=40,152064,4,6,no,865.903,1133.504,0.7639,3241.396,3224.991,1.0051
+top-k=40,152064,8,6,no,1841.220,1345.842,1.3681,4342.417,4190.104,1.0364
+top-p=0.9,32768,1,1,yes,261.119,90.139,2.8968,2387.469,2425.044,0.9845
+top-p=0.9,32768,4,1,yes,529.132,101.110,5.2332,2682.513,2437.353,1.1006
+top-p=0.9,32768,8,1,yes,962.673,112.761,8.5373,3130.454,2501.676,1.2513
+top-p=0.9,65536,1,1,yes,327.874,140.202,2.3386,2449.749,2474.769,0.9899
+top-p=0.9,65536,4,1,yes,788.217,175.519,4.4908,2966.360,2508.918,1.1823
+top-p=0.9,65536,8,1,yes,1490.153,203.191,7.3338,3790.613,2713.445,1.3970
+top-p=0.9,128256,1,1,yes,477.354,263.744,1.8099,2632.350,2639.868,0.9972
+top-p=0.9,128256,4,1,yes,1438.706,324.358,4.4355,3728.364,2787.397,1.3376
+top-p=0.9,128256,8,1,yes,2780.580,430.957,6.4521,5844.044,2679.123,2.1813
+top-p=0.9,151936,1,1,yes,549.410,312.686,1.7571,2687.215,2427.424,1.1070
+top-p=0.9,151936,4,1,yes,1616.188,412.853,3.9147,4052.039,2758.947,1.4687
+top-p=0.9,151936,8,1,yes,3491.813,484.978,7.1999,6557.189,2753.828,2.3811
+top-p=0.9,152064,1,1,yes,540.663,305.162,1.7717,2673.215,2523.989,1.0591
+top-p=0.9,152064,4,2,yes,1697.671,418.444,4.0571,4037.144,2905.288,1.3896
+top-p=0.9,152064,8,2,yes,3316.194,529.742,6.2600,6595.178,2922.574,2.2566
+min-p=0.05,32768,1,1,no,129.032,94.017,1.3724,2424.980,2300.522,1.0541
+min-p=0.05,32768,4,1,no,148.598,101.260,1.4675,2599.954,2360.187,1.1016
+min-p=0.05,32768,8,1,no,207.679,111.158,1.8683,2535.399,2630.421,0.9639
+min-p=0.05,65536,1,1,no,152.646,143.860,1.0611,2274.325,2618.808,0.8685
+min-p=0.05,65536,4,1,no,220.403,171.140,1.2879,2385.734,2435.989,0.9794
+min-p=0.05,65536,8,1,no,323.967,192.220,1.6854,2720.023,2456.728,1.1072
+min-p=0.05,128256,1,1,no,200.246,265.327,0.7547,2578.774,2331.214,1.1062
+min-p=0.05,128256,4,1,no,345.868,316.443,1.0930,2694.607,2781.147,0.9689
+min-p=0.05,128256,8,1,no,544.360,384.390,1.4162,2807.679,2978.426,0.9427
+min-p=0.05,151936,1,1,no,217.107,303.459,0.7154,2369.442,2667.904,0.8881
+min-p=0.05,151936,4,1,no,390.542,418.715,0.9327,2532.346,2879.557,0.8794
+min-p=0.05,151936,8,1,no,618.890,466.344,1.3271,2774.828,3027.817,0.9164
+min-p=0.05,152064,1,1,no,215.193,311.143,0.6916,2460.846,2500.088,0.9843
+min-p=0.05,152064,4,1,no,391.183,418.985,0.9336,2772.078,2563.971,1.0812
+min-p=0.05,152064,8,1,no,626.434,465.573,1.3455,3001.080,2793.679,1.0742
+top-k+top-p,32768,1,5,yes,319.749,143.399,2.2298,2458.518,2358.849,1.0423
+top-k+top-p,32768,4,5,yes,701.535,173.625,4.0405,2860.542,2440.091,1.1723
+top-k+top-p,32768,8,5,yes,1251.936,204.783,6.1135,3472.702,2403.626,1.4448
+top-k+top-p,65536,1,4,yes,402.033,253.355,1.5868,2538.053,2591.252,0.9795
+top-k+top-p,65536,4,4,yes,1001.306,361.207,2.7721,3165.131,2675.332,1.1831
+top-k+top-p,65536,8,4,yes,1871.717,424.425,4.4100,4401.561,2697.870,1.6315
+top-k+top-p,128256,1,4,yes,590.847,619.080,0.9544,2747.959,2848.315,0.9648
+top-k+top-p,128256,4,5,yes,1802.527,809.357,2.2271,4122.277,3215.262,1.2821
+top-k+top-p,128256,8,6,yes,3511.961,1127.082,3.1160,6426.126,3503.563,1.8342
+top-k+top-p,151936,1,5,yes,665.868,724.197,0.9195,2809.915,3054.265,0.9200
+top-k+top-p,151936,4,5,yes,2069.397,1100.502,1.8804,4663.215,3552.715,1.3126
+top-k+top-p,151936,8,5,yes,4028.228,1345.020,2.9949,6978.657,3728.141,1.8719
+top-k+top-p,152064,1,4,yes,667.571,717.525,0.9304,2814.908,3024.097,0.9308
+top-k+top-p,152064,4,6,yes,2097.140,1147.320,1.8279,4452.282,3485.748,1.2773
+top-k+top-p,152064,8,6,yes,3967.494,1343.798,2.9524,6977.370,3715.382,1.8780
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run3.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run3.csv
new file mode 100644
index 000000000..40a1fea4b
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run3.csv
@@ -0,0 +1,61 @@
+config,vocab,batch,worst_rounds,routed,iso_baseline_us,iso_rejection_us,iso_speedup,pipe_baseline_us,pipe_rejection_us,pipe_speedup
+top-k=40,32768,1,2,no,170.950,143.679,1.1898,2294.693,2288.752,1.0026
+top-k=40,32768,4,5,no,309.319,171.782,1.8006,2459.947,2450.723,1.0038
+top-k=40,32768,8,5,no,526.896,206.156,2.5558,2721.921,3009.113,0.9046
+top-k=40,65536,1,4,no,199.934,256.610,0.7791,2314.765,2328.719,0.9940
+top-k=40,65536,4,4,no,440.955,365.904,1.2051,2623.156,2589.769,1.0129
+top-k=40,65536,8,4,no,809.465,413.063,1.9597,3239.431,3163.020,1.0242
+top-k=40,128256,1,4,no,271.368,607.377,0.4468,3762.702,2398.273,1.5689
+top-k=40,128256,4,5,no,766.695,818.152,0.9371,2989.657,3215.509,0.9298
+top-k=40,128256,8,6,no,1451.136,1106.812,1.3111,4125.309,3915.942,1.0535
+top-k=40,151936,1,5,no,297.947,733.894,0.4060,2421.912,2411.251,1.0044
+top-k=40,151936,4,5,no,873.996,1096.172,0.7973,3414.780,3113.003,1.0969
+top-k=40,151936,8,5,no,1702.486,1334.408,1.2758,4088.169,4772.442,0.8566
+top-k=40,152064,1,4,no,298.389,718.365,0.4154,2417.822,2421.577,0.9984
+top-k=40,152064,4,6,no,989.993,1130.596,0.8756,3150.637,3469.884,0.9080
+top-k=40,152064,8,6,no,1670.126,1344.987,1.2417,4629.015,4288.458,1.0794
+top-p=0.9,32768,1,1,yes,261.510,90.209,2.8989,2387.579,2190.058,1.0902
+top-p=0.9,32768,4,1,yes,534.650,101.821,5.2509,2680.371,2333.089,1.1489
+top-p=0.9,32768,8,1,yes,954.527,114.554,8.3326,3134.935,2405.981,1.3030
+top-p=0.9,65536,1,1,yes,328.054,141.265,2.3223,2451.458,2586.147,0.9479
+top-p=0.9,65536,4,1,yes,788.736,173.435,4.5477,2978.402,2651.971,1.1231
+top-p=0.9,65536,8,1,yes,1479.680,200.295,7.3875,3862.451,2695.804,1.4328
+top-p=0.9,128256,1,1,yes,477.313,256.390,1.8617,2622.634,2710.103,0.9677
+top-p=0.9,128256,4,1,yes,1436.329,323.426,4.4410,3843.349,2730.637,1.4075
+top-p=0.9,128256,8,1,yes,2864.601,433.431,6.6091,5703.852,2802.515,2.0353
+top-p=0.9,151936,1,1,yes,539.380,303.048,1.7799,2818.789,2608.131,1.0808
+top-p=0.9,151936,4,1,yes,1606.817,412.071,3.8994,4000.264,2896.712,1.3810
+top-p=0.9,151936,8,1,yes,3224.636,489.225,6.5913,6537.294,2813.503,2.3235
+top-p=0.9,152064,1,1,yes,550.790,316.562,1.7399,2686.068,2524.062,1.0642
+top-p=0.9,152064,4,2,yes,1612.989,416.399,3.8737,4053.961,2872.634,1.4112
+top-p=0.9,152064,8,2,yes,3283.937,508.281,6.4609,6855.854,2754.633,2.4888
+min-p=0.05,32768,1,1,no,129.954,94.447,1.3759,2602.128,2250.880,1.1560
+min-p=0.05,32768,4,1,no,149.309,100.438,1.4866,2537.905,2602.266,0.9753
+min-p=0.05,32768,8,1,no,207.569,111.098,1.8683,2333.135,2671.868,0.8732
+min-p=0.05,65536,1,1,no,152.766,145.262,1.0517,2438.613,2284.853,1.0673
+min-p=0.05,65536,4,1,no,220.843,171.340,1.2889,2712.412,2413.131,1.1240
+min-p=0.05,65536,8,1,no,324.377,190.206,1.7054,2772.814,2723.590,1.0181
+min-p=0.05,128256,1,1,no,199.915,262.060,0.7629,2396.604,2653.362,0.9032
+min-p=0.05,128256,4,1,no,345.487,318.226,1.0857,2481.329,2757.078,0.9000
+min-p=0.05,128256,8,1,no,544.219,384.941,1.4138,2797.072,2803.083,0.9979
+min-p=0.05,151936,1,1,no,218.369,309.419,0.7057,2644.290,2335.217,1.1324
+min-p=0.05,151936,4,1,no,392.334,421.669,0.9304,2899.790,2622.720,1.1056
+min-p=0.05,151936,8,1,no,626.723,467.565,1.3404,3047.596,2875.953,1.0597
+min-p=0.05,152064,1,1,no,218.189,305.352,0.7145,2491.238,2658.502,0.9371
+min-p=0.05,152064,4,1,no,400.830,419.134,0.9563,2569.444,2907.620,0.8837
+min-p=0.05,152064,8,1,no,627.234,462.246,1.3569,2756.899,3039.121,0.9071
+top-k+top-p,32768,1,5,yes,318.035,144.931,2.1944,2465.675,2462.436,1.0013
+top-k+top-p,32768,4,5,yes,704.319,175.138,4.0215,2847.715,2336.639,1.2187
+top-k+top-p,32768,8,5,yes,1265.910,207.258,6.1079,3447.103,2389.737,1.4425
+top-k+top-p,65536,1,4,yes,404.658,256.790,1.5758,2536.644,2408.197,1.0533
+top-k+top-p,65536,4,4,yes,1001.715,367.669,2.7245,3167.871,2567.082,1.2340
+top-k+top-p,65536,8,4,yes,1869.499,420.437,4.4466,4435.371,2705.567,1.6393
+top-k+top-p,128256,1,4,yes,591.487,610.463,0.9689,2722.167,2788.956,0.9761
+top-k+top-p,128256,4,5,yes,1771.837,795.850,2.2263,4110.167,3222.185,1.2756
+top-k+top-p,128256,8,6,yes,3478.190,1130.185,3.0775,6345.482,3525.236,1.8000
+top-k+top-p,151936,1,5,yes,666.658,717.113,0.9296,2796.689,3178.207,0.8800
+top-k+top-p,151936,4,5,yes,2091.084,1095.710,1.9084,4771.112,3235.942,1.4744
+top-k+top-p,151936,8,5,yes,4672.095,1348.784,3.4639,7234.906,3798.051,1.9049
+top-k+top-p,152064,1,4,yes,666.307,727.081,0.9164,2802.422,3167.796,0.8847
+top-k+top-p,152064,4,6,yes,2060.286,1119.927,1.8397,4497.015,3249.169,1.3841
+top-k+top-p,152064,8,6,yes,4633.733,1342.432,3.4517,7302.108,3548.742,2.0577
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-after_Meta-Llama-3.1-8B-Instruct-4bit.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-after_Meta-Llama-3.1-8B-Instruct-4bit.csv
new file mode 100644
index 000000000..9979a75eb
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-after_Meta-Llama-3.1-8B-Instruct-4bit.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version,decode_path
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,490.91,1042.97,3403.79,37.61,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,504.65,1014.57,3328.88,38.45,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,493.04,1038.47,3392.18,37.73,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
diff --git a/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-before_Meta-Llama-3.1-8B-Instruct-4bit.csv b/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-before_Meta-Llama-3.1-8B-Instruct-4bit.csv
new file mode 100644
index 000000000..a578389ba
--- /dev/null
+++ b/benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-before_Meta-Llama-3.1-8B-Instruct-4bit.csv
@@ -0,0 +1,4 @@
+model,model_path,prompt_tokens,generated_tokens,prefill_ms,prefill_tok_s,decode_ms,decode_tok_s,date,hardware,mlxcel_version,build_type,max_tokens,prompt,prompt_target_len,mlxcel_commit,mlx_commit,mlx_rocm_overlay_commit,hip_version,decode_path
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,513.04,997.97,3861.60,33.15,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,482.83,1060.40,3579.70,35.76,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
+Meta-Llama-3.1-8B-Instruct-4bit,models/mlx/Meta-Llama-3.1-8B-Instruct-4bit,512,128,484.05,1057.74,3868.39,33.09,2026-10-08,AMD_Radeon_8060S_Graphics_gfx1151_ROCm10.0.0_96GB,0.7.0,release,128,"Hello, how are you today?",512,79ea5814,81ba1c6a,75915908,7.15.26333,engine
diff --git a/docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md b/docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md
new file mode 100644
index 000000000..e2242ee3c
--- /dev/null
+++ b/docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md
@@ -0,0 +1,104 @@
+# Joint top-k + top-p rejection cap on gfx1151 (2026-10-07)
+
+lablup/mlxcel#2157, part of #1801. The rejection sampler (#901) routes top-k together with top-p only up to a vocabulary cap, `REJECTION_JOINT_VOCAB_MAX` in `src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp`. Its value, 32768, was measured on M1 Ultra ([rejection-sampling-m1ultra-2026-08-02.md](rejection-sampling-m1ultra-2026-08-02.md)). The HIP port (#2064) inherited it unmeasured, so `--top-k 40 --top-p 0.95` on a Llama 3 checkpoint (vocab 128256) never reached the kernel ([rocm-samplers-gfx1151-2026-10-05.md](rocm-samplers-gfx1151-2026-10-05.md)). This page re-measures the crossover on gfx1151.
+
+**Outcome: a ROCm build routes top-k with top-p up to vocab 152064; Metal and CUDA keep 32768.** The microbenchmark alone would have kept 32768: its batch 4 and 8 cells win at every vocabulary, but its synthetic batch-1 cell does not clear 1.0 above 32768. End-to-end decode, which the issue's rule names as the confirmation at 128256 and above, disagrees with that cell by a wide margin: with the joint case routed, decode is 1.15x faster on Meta-Llama-3.1-8B-Instruct-4bit (vocab 128256) and 1.12x on Qwen2.5-7B-Instruct-4bit (152064), and every kernel run was faster than every chain run; on the final build rebased onto current `main` the Llama 3.1 pairs read 1.14x. The cap is set to 152064, the largest vocabulary measured both ways. Why the synthetic batch-1 cell does not predict real decode on this GPU was not isolated; a bf16 rerun ruled out the logits dtype.
+
+## Environment
+
+AMD Ryzen AI MAX+ 395 with Radeon 8060S (`gfx1151`, RDNA 3.5), 96 GiB VRAM carve-out, Debian 13, ROCm 10.0.0 (HIP 7.15.26333), MLX pin `81ba1c6a`, ROCm overlay `75915908`, `cargo build --release --features rocm`. Measurement build: `main` at `84d3a7bc` plus this change with the ROCm cap raised to `INT32_MAX`, so `fused_sample` routes every joint cell; its binaries were copied out of the tree before the source moved on, so its CSVs record `mlxcel_commit` as `unknown`. Final verification: this branch rebased on `main` at `ad844354` (after #2224 and #2225 moved `mlxcel generate` onto the engine). Checkpoints `mlx-community/Meta-Llama-3.1-8B-Instruct-4bit` (vocab 128256) and `mlx-community/Qwen2.5-7B-Instruct-4bit` (152064).
+
+## Microbenchmark
+
+`examples/rejection_sampling_microbench.rs`, 200 timed and 30 warmup iterations per cell, three runs, each under `scripts/rocm_gpu_guard.sh` (main's copy, host-wide lock from #2146). Of the f32 runs, 1 and 3 were clean on the first attempt; the guard rejected run 2's first attempt for contention and its second was clean. All three bf16 runs were clean on the first attempt. This change adds 128256 (Llama 3) and 151936 (Qwen3) to the harness's vocabularies, adds `--dtype` and `--config` options, and fixes its port gate: it refused to run on ROCm because it checked `custom_kernels_available()`, which is Metal-or-CUDA by definition; it now checks `sampling_rejection_backend_supported()`.
+
+The pipelined arm samples through `fused_sample`, the production entry point, so on a cell production does not route it measures the stock chain against itself; that is why the measurement build lifted the cap. Every joint cell reads `routed=yes` in the raw CSVs. Read `pipe_x`, not `iso_x` (the harness header explains why). The synthetic forward measured 2110 to 2659 us per step, and the cap-overflow counter stayed at 0 in every run. Raw rows: `benchmarks/rocm_strixhalo-gfx1151_2026-10-07_rejection-microbench-run{1,2,3}.csv` (f32, every configuration) and `..._rejection-microbench-bf16-run{1,2,3}.csv` (bf16, joint only).
+
+### top-k 40 + top-p 0.9, f32 logits
+
+Medians of three runs (min to max in brackets). Times are microseconds, stock chain / kernel.
+
+| vocab | batch | worst rounds | iso us | iso_x | pipe us | pipe_x |
+|---|---|---|---|---|---|---|
+| 32768 | 1 | 5 | 318 / 143 | 2.23x (2.19-2.23) | 2459 / 2462 | 1.00x (0.96-1.04) |
+| 32768 | 4 | 5 | 702 / 174 | 4.03x (4.02-4.04) | 2858 / 2440 | 1.17x (1.10-1.22) |
+| 32768 | 8 | 5 | 1254 / 207 | 6.11x (6.06-6.11) | 3453 / 2404 | 1.44x (1.29-1.44) |
+| 65536 | 1 | 4 | 405 / 257 | 1.59x (1.58-1.59) | 2537 / 2591 | 0.98x (0.95-1.05) |
+| 65536 | 4 | 4 | 1002 / 367 | 2.76x (2.72-2.77) | 3165 / 2675 | 1.18x (1.09-1.23) |
+| 65536 | 8 | 4 | 1869 / 420 | 4.45x (4.41-4.49) | 4402 / 2698 | 1.64x (1.63-1.73) |
+| 128256 | 1 | 4 | 591 / 617 | 0.96x (0.95-0.97) | 2731 / 2789 | 0.98x (0.96-0.99) |
+| 128256 | 4 | 5 | 1794 / 809 | 2.23x (2.21-2.23) | 4122 / 3222 | 1.28x (1.27-1.28) |
+| 128256 | 8 | 6 | 3512 / 1130 | 3.12x (3.08-3.17) | 6345 / 3518 | 1.80x (1.79-1.83) |
+| 151936 | 1 | 5 | 666 / 724 | 0.92x (0.91-0.93) | 2809 / 3124 | 0.90x (0.88-0.92) |
+| 151936 | 4 | 5 | 2078 / 1101 | 1.88x (1.88-1.91) | 4667 / 3428 | 1.36x (1.31-1.47) |
+| 151936 | 8 | 5 | 4028 / 1349 | 2.99x (2.96-3.46) | 7083 / 3728 | 1.90x (1.87-1.99) |
+| 152064 | 1 | 4 | 666 / 722 | 0.92x (0.92-0.93) | 2815 / 3024 | 0.93x (0.88-0.97) |
+| 152064 | 4 | 6 | 2060 / 1136 | 1.83x (1.81-1.84) | 4452 / 3420 | 1.29x (1.28-1.38) |
+| 152064 | 8 | 6 | 4351 / 1344 | 3.24x (2.95-3.45) | 7074 / 3549 | 2.02x (1.88-2.06) |
+
+### top-k 40 + top-p 0.9, bf16 logits
+
+Both checkpoints are bf16, so the sampler sees bf16 logits in decode. The same matrix with the synthetic logits cast to bf16 (`--dtype bf16 --config top-k+top-p`):
+
+| vocab | batch | worst rounds | iso us | iso_x | pipe us | pipe_x |
+|---|---|---|---|---|---|---|
+| 32768 | 1 | 3 | 328 / 144 | 2.29x (2.27-2.30) | 2464 / 2275 | 1.08x (1.00-1.09) |
+| 32768 | 4 | 3 | 686 / 179 | 3.82x (3.82-3.83) | 2841 / 2334 | 1.21x (1.17-1.22) |
+| 32768 | 8 | 4 | 1203 / 208 | 5.79x (5.74-5.91) | 3376 / 2395 | 1.41x (1.40-1.45) |
+| 65536 | 1 | 3 | 422 / 252 | 1.67x (1.62-1.68) | 2556 / 2513 | 1.02x (0.99-1.06) |
+| 65536 | 4 | 4 | 966 / 349 | 2.81x (2.76-2.82) | 3117 / 2542 | 1.23x (1.18-1.24) |
+| 65536 | 8 | 4 | 1753 / 379 | 4.67x (4.60-4.84) | 4026 / 2590 | 1.54x (1.51-1.56) |
+| 128256 | 1 | 4 | 502 / 579 | 0.87x (0.86-0.89) | 2640 / 2706 | 0.98x (0.91-0.98) |
+| 128256 | 4 | 5 | 1244 / 710 | 1.76x (1.73-1.76) | 3477 / 3012 | 1.14x (1.11-1.19) |
+| 128256 | 8 | 5 | 2221 / 1028 | 2.17x (2.15-2.17) | 4751 / 3273 | 1.47x (1.35-1.50) |
+| 151936 | 1 | 4 | 549 / 722 | 0.76x (0.76-0.78) | 2680 / 3006 | 0.89x (0.88-0.92) |
+| 151936 | 4 | 4 | 1386 / 1037 | 1.34x (1.32-1.36) | 3663 / 3320 | 1.16x (1.09-1.27) |
+| 151936 | 8 | 6 | 2494 / 1235 | 2.02x (2.01-2.02) | 5107 / 3671 | 1.38x (1.32-1.64) |
+| 152064 | 1 | 4 | 550 / 683 | 0.81x (0.78-0.81) | 2692 / 3127 | 0.86x (0.86-0.93) |
+| 152064 | 4 | 6 | 1405 / 1041 | 1.34x (1.33-1.36) | 3624 / 3463 | 1.05x (0.78-1.15) |
+| 152064 | 8 | 6 | 2497 / 1248 | 2.00x (1.99-2.00) | 5209 / 3587 | 1.47x (1.41-1.48) |
+
+The dtype does not change the picture: batch 1 still reads below 1.0 from 128256 up, so the dtype is not why the microbenchmark and end-to-end decode disagree.
+
+How much the batch-1 pipelined cells can say is limited. Rows that production does not route (top-k alone and min-p alone in the f32 CSVs, chain against chain in the pipelined arm) scatter between 0.90x and 1.11x by median, so a batch-1 `pipe_x` between 0.95 and 1.05 is inside the noise either way. The batch-1 isolated cells are tight (spread under 3%) and show the kernel slower from 128256 up on these synthetic rows, which sample in four to six rounds.
+
+## End-to-end decode
+
+`scripts/bench_decode.sh` at its default pp512/tg128 shape with `--temperature 0.8 --top-k 40 --top-p 0.95` (the `--top-k` option is new in this change), the measurement build against the same binaries with `MLXCEL_SAMPLING_REJECTION=0`. Each pair ran inside one `scripts/rocm_gpu_guard.sh` attempt, alternating which arm went first, and all six pairs were clean on their first attempt. A short `mlxcel generate` run on the same build logged `sampling dispatch: rejection kernel (batch 1, vocab 128256, temperature 0.8, top_k 40, top_p 0.95, ...)`, so the kernel arm reached the kernel at the Llama 3 vocabulary. Raw rows: `benchmarks/rocm_strixhalo-gfx1151_2026-10-07_joint-cap-measurement_<model>_{kern,chain}.csv`.
+
+| Model (vocab) | Stock chain tok/s | Rejection kernel tok/s | Medians |
+|---|---|---|---|
+| Meta-Llama-3.1-8B-Instruct-4bit (128256) | 33.94 / 31.64 / 32.67, median 32.67 | 37.70 / 37.37 / 37.57, median 37.57 | 1.15x |
+| Qwen2.5-7B-Instruct-4bit (152064) | 42.68 / 41.91 / 40.79, median 41.91 | 46.92 / 46.40 / 47.18, median 46.92 | 1.12x |
+
+Every kernel run is faster than every chain run on both models, by 10% to 18% within each pair. The chain arm also spreads more (4.5 to 7.0% of its median, against 0.9 to 1.7% for the kernel), as the top-p chain did on Llama 3.1 in #2064.
+
+### Final build, rebased on current main
+
+The same pairs on this branch's own build after rebasing onto `main` at `ad844354`, where `mlxcel-bench-decode` now decodes through the engine (#2224, #2225; the CSV's last column reads `engine`). The arms are the shipped default, which now routes the joint case at 128256, and `MLXCEL_SAMPLING_REJECTION=0`, which is the path `main` takes for this configuration (it never routed the joint case above 32768). An `mlxcel generate` run in the first pair logged `sampling dispatch: rejection kernel (batch 1, vocab 128256, temperature 0.8, top_k 40, top_p 0.95, ...)` by default and `sampling dispatch: argpartition chain: pinned by MLXCEL_SAMPLING_REJECTION` with the switch. All three pairs were clean on their first guard attempt. Raw rows: `benchmarks/rocm_strixhalo-gfx1151_2026-10-08_joint-cap-{after,before}_Meta-Llama-3.1-8B-Instruct-4bit.csv` (`mlxcel_commit` `79ea5814`).
+
+| Model (vocab) | Before (stock chain) tok/s | After (rejection kernel) tok/s | Medians |
+|---|---|---|---|
+| Meta-Llama-3.1-8B-Instruct-4bit (128256) | 33.15 / 35.76 / 33.09, median 33.15 | 37.61 / 38.45 / 37.73, median 37.73 | 1.14x |
+
+Every after run is faster than every before run, by 1.08x to 1.14x within each pair. Qwen2.5-7B was not re-run on the rebased build: the shared GPU was contended for hours at a time, and the measurement-build pairs above already separate cleanly.
+
+## Decision
+
+The issue's rule takes the largest measured vocabulary V where every microbenchmark batch cell at V and below has `pipe_x >= 1.0`, confirmed end to end when V is 128256 or more. Read literally, the synthetic batch-1 cells stop it at 32768. The end-to-end confirmation at 128256 and 152064 contradicts them: the configuration the issue was opened for is 15% faster on Llama 3.1 and 12% faster on Qwen 2.5 when routed, beyond the run-to-run spread, and the microbenchmark's own batch 4 and 8 cells win at every vocabulary. Keeping that configuration on the slower path in production because of a synthetic cell would be the wrong call, so the ROCm value is 152064, the largest vocabulary measured both ways.
+
+- Vocabularies above 152064 (gpt-oss 201088, Gemma 3 262144) are unmeasured and stay on the stock chain.
+- The value is a build flag, `#ifdef MLXCEL_BRIDGE_ROCM_BACKEND` around `REJECTION_JOINT_VOCAB_MAX`, the same pattern as the fused-MoE SGY default in `mlx_cxx_kernels.cpp`. A ROCm build has no Metal or CUDA backend, so there is no runtime backend comparison, and `make verify-kernel-port-dispatch` passes. Metal and CUDA builds keep 32768.
+- `sampling_rejection_joint_vocab_max()` reports the active value. `the_joint_vocab_cap_is_the_measured_crossover` pins it per build (`cfg!(feature = "rocm")`) and checks that the policy turns exactly there, and the not-routed message names it. Anything that unifies the per-row sampling step (epic #2166 Phase 2) carries the policy forward by calling `sampling_rejection_routes`, or this accessor, rather than copying the number.
+
+## Reproducing
+
+```bash
+# Measurement build only: set the ROCm REJECTION_JOINT_VOCAB_MAX to 2147483647 first.
+cargo build --release --features rocm --example rejection_sampling_microbench --bin mlxcel-bench-decode
+scripts/rocm_gpu_guard.sh -- ./target/release/examples/rejection_sampling_microbench --csv /tmp/rejection-gfx1151.csv
+scripts/rocm_gpu_guard.sh -- ./target/release/examples/rejection_sampling_microbench --dtype bf16 --config top-k+top-p --csv /tmp/rejection-gfx1151-bf16.csv
+scripts/rocm_gpu_guard.sh -- scripts/bench_decode.sh models/mlx/Meta-Llama-3.1-8B-Instruct-4bit --temperature 0.8 --top-k 40 --top-p 0.95 --output /tmp/joint-kern.csv
+MLXCEL_SAMPLING_REJECTION=0 scripts/rocm_gpu_guard.sh -- scripts/bench_decode.sh models/mlx/Meta-Llama-3.1-8B-Instruct-4bit --temperature 0.8 --top-k 40 --top-p 0.95 --output /tmp/joint-chain.csv
+cargo test --release --features rocm -p mlxcel-core --lib -- --test-threads=1 sampling_rejection_tests sampling_fixed_key_tests
+```
diff --git a/docs/benchmark_results/rocm-samplers-gfx1151-2026-10-05.md b/docs/benchmark_results/rocm-samplers-gfx1151-2026-10-05.md
index a7d8c5ec3..0e2e48227 100644
--- a/docs/benchmark_results/rocm-samplers-gfx1151-2026-10-05.md
+++ b/docs/benchmark_results/rocm-samplers-gfx1151-2026-10-05.md
@@ -23,7 +23,7 @@ AMD Ryzen AI MAX+ 395 with Radeon 8060S (`gfx1151`, RDNA 3.5), 96 GiB VRAM carve
 
 The Gumbel-max row is not a measurable change: the arms overlap and the medians differ by 0.9%, against a spread of 1.7% before and 4.4% after. The top-p row is: every after run is faster than every before run, by 1.04x, 1.11x and 1.13x in the three interleaved pairs. The before arm also drifted down across its three runs (36.3 to 32.8), which the after arm did not. The cause was not isolated; the chain runs an `argsort` over all 128256 entries per token for top-p, which is what the rejection kernel replaces. Greedy decode reaches neither kernel and was not rerun.
 
-The issue's second command (`--top-k 40 --top-p 0.95`) does not reach the rejection kernel at this vocabulary: the routing policy sends top-k with top-p to the kernel only up to vocab 32768 (`REJECTION_JOINT_VOCAB_MAX`, measured on M1 Ultra), so that configuration runs the stock chain before and after. Top-p alone is the routed configuration and is the one measured. Whether the joint cap is right on ROCm was not measured.
+The issue's second command (`--top-k 40 --top-p 0.95`) does not reach the rejection kernel at this vocabulary: the routing policy sends top-k with top-p to the kernel only up to vocab 32768 (`REJECTION_JOINT_VOCAB_MAX`, measured on M1 Ultra), so that configuration runs the stock chain before and after. Top-p alone is the routed configuration and is the one measured. The joint cap was re-measured on gfx1151 afterwards (lablup/mlxcel#2157, [rocm-rejection-joint-cap-gfx1151-2026-10-07.md](rocm-rejection-joint-cap-gfx1151-2026-10-07.md)): a ROCm build now routes top-k with top-p up to vocab 152064, so this configuration reaches the rejection kernel at vocab 128256 (37.73 against 33.15 tok/s with the kernel forced off).
 
 ## Correctness
 
diff --git a/docs/environment-variables.md b/docs/environment-variables.md
index b82f780a4..ec1dfa7a3 100644
--- a/docs/environment-variables.md
+++ b/docs/environment-variables.md
@@ -750,7 +750,7 @@ recommended as normal deployment settings.
 | `MLXCEL_ONE_BIT_KERNEL` | `0`/`false`/`off`/`no` (case-insensitive) disable; unset or any other value keeps the kernels | on (Metal) | Affine 1-bit checkpoints (`quantization.bits == 1`, issue #1370). MLX has no 1-bit kernel, so the `quantized_matmul`, `quantized_linear_forward`, `dequantize` and `quantized_embedding` bridge primitives route a 1-bit affine triple to mlxcel's own fused Metal qmv (fewer than 16 rows) or tiled qmm kernel. Set to `0` to force the dequantize graph (`x @ dequant(W)^T`) instead, which is the parity oracle for the kernels and the path CUDA and ROCm always take. Read once in C++ at first use and cached for the process lifetime. |
 | `MLXCEL_FUSED_XIELU` | `0`/`false`/`off`/`no` disable; any other value or unset enables | on | Fused single-launch xIELU kernel (Metal, ROCm) for the Apertus MLP activation (#409), on by default since the M5 Max validation. `MLP::forward` routes through one Metal dispatch covering the ~11 elementwise ops in `apertus_xielu` (square, minimum, expm1, where, and neighbors) instead of the per-op graph. Greedy temp-0 decode is byte-identical to the elementwise path on Apple Silicon: every intermediate stays in the input dtype (bf16) and the kernel reproduces MLX's `expm1f` exactly. Measured decode speedup on M1 Ultra (+2.7%, Apertus-8B 83.4 to 85.7 tok/s) and M5 Max (+1.9%, 112.0 to 114.2 tok/s), with no regression. Set to `0` to force the elementwise path. ROCm has a HIP port (lablup/mlxcel#2069) that rounds each intermediate where the ROCm graph's elementwise kernels round and calls the same device `expm1f`, byte-identical to the elementwise path on gfx1151 in f32, f16 and bf16 (`fused_xielu_kernel_matches_graph_every_dtype`); no Apertus checkpoint was available there to measure decode. On CUDA and CPU the FFI falls back to an equivalent elementwise graph, so the flag is safe to set everywhere. Apertus only; no other model family is affected. |
 | `MLXCEL_SAMPLING_GUMBEL` | `0`/`false`/`off`/`no` disable (case-insensitive); any other value or unset enables | on | Softmax-free Gumbel-max categorical sampling kernel (issue #900), on by default on Metal, CUDA and ROCm (the HIP port is lablup/mlxcel#2064). On the no-filter stochastic path (`temperature > 0` with no top-k, top-p, or min-p) the fused sampler replaces `mlx::core::random::categorical` with one index-carrying max reduction over the vocabulary: adding i.i.d. Gumbel(0,1) noise to `logits / temperature` and taking the argmax draws exactly from `softmax(logits / temperature)`, so the normalization pass over 32K-152K entries disappears. Noise comes from a stateless in-kernel Philox-4x32-10 counter keyed on `(row, element)`, so the sampled id is a pure function of the launch key and the logits and does not move when the launcher splits a row across threadgroups to keep a small batch wide. One launch covers the whole `[B, vocab]` batch. **This changes the RNG stream**: at an equal seed the sampled tokens differ from the pre-#900 `categorical` streams, because the two consume the shared MLX key sequence differently. The distribution is identical (chi-square goodness of fit against exact softmax is a committed test), and greedy (`temperature == 0`) output is byte-identical either way. Set to a falsy value to restore `categorical` exactly, which is the way to reproduce a token stream recorded before this landed. Filtered configurations (top-k / top-p / min-p) never reach the kernel and are bit-identical with the switch either way; token bias is an upstream `-inf` logit mask that the kernel reproduces exactly, and XTC-active requests never reach this kernel (XTC lives inside the stock filter chain). Read once per process, so set it before starting `mlxcel` or `mlxcel-server`. Inert on CPU-only builds and under `MLXCEL_DEVICE=cpu`. A/B with `examples/gumbel_sampling_microbench.rs`. |
-| `MLXCEL_SAMPLING_REJECTION` | `0`/`false`/`off`/`no` disable (case-insensitive); any other value or unset enables | on | Sorting-free top-k / top-p / min-p sampling by dual-pivot rejection (issue #901), on by default on Metal, CUDA and ROCm (the HIP port is lablup/mlxcel#2064). On the filtered stochastic path the fused sampler replaces the `argpartition` top-k, the `argsort` + `cumsum` top-p and the min-p mask, plus the trailing `random::categorical`, with the softmax passes and one custom kernel; since the untempered-chain fix the kernel reads two probability rows (the untempered row resolves every filter, the tempered row weights the draw), which coincide at `temperature 1`. **Routing is restricted to the configurations measured faster.** The kernel replaces a *sort*, so it is routed only where the stock chain sorts, which is when top-p is active; and when top-k is active as well, only at vocabularies up to 32768. Measured on M1 Ultra over three repetitions of vocab {32K, 64K, 152K} x batch {1, 4, 8}: top-p alone 1.28x to 2.35x at every cell, top-k alone 0.31x to 0.97x at every cell, min-p alone 0.47x to 0.88x at 152K, top-k with top-p 1.27x to 1.64x at 32K but 0.71x to 0.83x at 152K. The mechanism is the kernel's round count, which the microbenchmark reports: top-p accepts in one or two rounds because a probability-weighted draw lands in the high-mass head, while top-k needs the draw to land in the top forty of the whole vocabulary and takes two to seven rounds, growing with the vocabulary. Every round is another full-row sweep, and the loop runs on one threadgroup per row because the shrinking interval is carried across sweeps and MLX custom kernels have no grid-wide barrier, so the kernel pays single-core bandwidth per round while `argpartition` and the stock min-p mask run across the whole GPU. top-k alone, min-p alone, top-k with min-p, and top-k with top-p above vocab 32768 therefore stay on the stock chain and are bit-identical to before; the decline is announced once at INFO with the numbers behind it. Vocab 65536 has not been measured for the top-k plus top-p combination and is excluded rather than interpolated. All three filters are threshold filters on the probability value, so the filtered support is `{p > low}` for a single scalar per row; the kernel finds that scalar without sorting, by rejection sampling on a shrinking interval. Each round draws a candidate from the current proposal with a fixed-order block scan, takes the candidate's probability as one pivot and the midpoint of the bracket as the other, reduces `(count, mass)` above both in one vocabulary sweep, and accepts the candidate as soon as it passes every active filter test. The bisection pivot is the midpoint of the IEEE-754 **bit patterns**, not the arithmetic mean: pure integer arithmetic that a fast-math backend with flush-to-zero cannot corrupt for subnormal probabilities, and it isolates a single float in at most 32 rounds at any magnitude. min-p is folded into the initial interval and costs no round at all. One launch covers the whole `[B, vocab]` batch, and the kernel reads `{top_k, top_p, min_p}` per row so rows with different values need no second launch. **This changes the RNG stream**: at an equal seed the sampled tokens differ from the pre-#901 streams, because the kernel consumes the shared MLX key sequence differently from `random::categorical`. **One semantic difference is intentional.** When top-k AND top-p are both active, the stock chain masks to the top-k set and *renormalises* before applying top-p, so its mass target is `top_p * Z_k` with `Z_k` the top-k mass; the kernel applies both tests to the untruncated distribution, so its target is `top_p * total` and its support is a superset. The two agree unless some token's exclusive cumulative mass falls in `(top_p * Z_k, top_p * total]`. Every other configuration (top-k alone, top-p alone, min-p alone, top-k+min-p, top-p+min-p) is exact, and support equality against the `argpartition` mask including ties, plus chi-square goodness of fit against the renormalised truncated distribution, are committed tests. Greedy (`temperature == 0` or `top_k == 1`) is byte-identical either way, and the no-filter path is unaffected (it belongs to `MLXCEL_SAMPLING_GUMBEL`). **The routed path never synchronizes.** Both decode drivers are software pipelines that build step n+1 and `async_eval` it before reading step n, so a sampler that evaluates anything internally drains the queue inside the caller's build phase and collapses the pipeline. The first cut of this kernel read the per-row converged flags back to host inside `fused_sample` and measured 1.7x slower end to end on Qwen3-0.6B, against an op-level matrix that scored the same configuration 1.14x to 1.17x faster. The production path therefore evaluates nothing: the round cap is unreachable by construction (the bit-space bracket bounds the loop at 31 rounds), and the converged flags are stashed and inspected on a later call once `array::is_available()` reports the launch has landed, which in a decode loop is by the next token. A row that somehow exhausted the cap returns its own argmax, which is always inside the filtered support, so the degradation would be one greedy draw rather than an invalid token; the event is counted in `mlxcel_core::rejection_cap_overflow_rows()` and announced once at INFO. Which path a run took is announced at INFO, once per distinct outcome kind, so a benchmark arm can be proven from a log. Set to a falsy value to restore the `argpartition` chain exactly, which is the way to reproduce a token stream recorded before this landed. Read once per process, so set it before starting `mlxcel` or `mlxcel-server`. Inert on CPU-only builds and under `MLXCEL_DEVICE=cpu`. A/B with `examples/rejection_sampling_microbench.rs`. |
+| `MLXCEL_SAMPLING_REJECTION` | `0`/`false`/`off`/`no` disable (case-insensitive); any other value or unset enables | on | Sorting-free top-k / top-p / min-p sampling by dual-pivot rejection (issue #901), on by default on Metal, CUDA and ROCm (the HIP port is lablup/mlxcel#2064). On the filtered stochastic path the fused sampler replaces the `argpartition` top-k, the `argsort` + `cumsum` top-p and the min-p mask, plus the trailing `random::categorical`, with the softmax passes and one custom kernel; since the untempered-chain fix the kernel reads two probability rows (the untempered row resolves every filter, the tempered row weights the draw), which coincide at `temperature 1`. **Routing is restricted to the configurations measured faster.** The kernel replaces a *sort*, so it is routed only where the stock chain sorts, which is when top-p is active; and when top-k is active as well, only at vocabularies up to 32768 (152064 on a ROCm build). Measured on M1 Ultra over three repetitions of vocab {32K, 64K, 152K} x batch {1, 4, 8}: top-p alone 1.28x to 2.35x at every cell, top-k alone 0.31x to 0.97x at every cell, min-p alone 0.47x to 0.88x at 152K, top-k with top-p 1.27x to 1.64x at 32K but 0.71x to 0.83x at 152K. gfx1151 re-measured the top-k plus top-p row at vocab {32K, 64K, 128256, 151936, 152064} (lablup/mlxcel#2157, [results](benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md)): the microbenchmark's batches 4 and 8 win at every vocabulary while its synthetic batch-1 cell does not clear 1.0 above 32768, but end-to-end decode with `--temperature 0.8 --top-k 40 --top-p 0.95` measured the kernel 1.15x faster on Meta-Llama-3.1-8B-Instruct-4bit (vocab 128256) and 1.12x on Qwen2.5-7B-Instruct-4bit (152064), so a ROCm build routes the combination up to 152064 (a build-flag value, not a runtime backend check). Metal and CUDA keep 32768. The mechanism is the kernel's round count, which the microbenchmark reports: top-p accepts in one or two rounds because a probability-weighted draw lands in the high-mass head, while top-k needs the draw to land in the top forty of the whole vocabulary and takes two to seven rounds, growing with the vocabulary. Every round is another full-row sweep, and the loop runs on one threadgroup per row because the shrinking interval is carried across sweeps and MLX custom kernels have no grid-wide barrier, so the kernel pays single-core bandwidth per round while `argpartition` and the stock min-p mask run across the whole GPU. top-k alone, min-p alone, top-k with min-p, and top-k with top-p above the cap therefore stay on the stock chain and are bit-identical to before; the decline is announced once at INFO with the numbers behind it. On M1 Ultra vocab 65536 has not been measured for the top-k plus top-p combination and is excluded rather than interpolated; on gfx1151 it was measured and routes. All three filters are threshold filters on the probability value, so the filtered support is `{p > low}` for a single scalar per row; the kernel finds that scalar without sorting, by rejection sampling on a shrinking interval. Each round draws a candidate from the current proposal with a fixed-order block scan, takes the candidate's probability as one pivot and the midpoint of the bracket as the other, reduces `(count, mass)` above both in one vocabulary sweep, and accepts the candidate as soon as it passes every active filter test. The bisection pivot is the midpoint of the IEEE-754 **bit patterns**, not the arithmetic mean: pure integer arithmetic that a fast-math backend with flush-to-zero cannot corrupt for subnormal probabilities, and it isolates a single float in at most 32 rounds at any magnitude. min-p is folded into the initial interval and costs no round at all. One launch covers the whole `[B, vocab]` batch, and the kernel reads `{top_k, top_p, min_p}` per row so rows with different values need no second launch. **This changes the RNG stream**: at an equal seed the sampled tokens differ from the pre-#901 streams, because the kernel consumes the shared MLX key sequence differently from `random::categorical`. **One semantic difference is intentional.** When top-k AND top-p are both active, the stock chain masks to the top-k set and *renormalises* before applying top-p, so its mass target is `top_p * Z_k` with `Z_k` the top-k mass; the kernel applies both tests to the untruncated distribution, so its target is `top_p * total` and its support is a superset. The two agree unless some token's exclusive cumulative mass falls in `(top_p * Z_k, top_p * total]`. Every other configuration (top-k alone, top-p alone, min-p alone, top-k+min-p, top-p+min-p) is exact, and support equality against the `argpartition` mask including ties, plus chi-square goodness of fit against the renormalised truncated distribution, are committed tests. Greedy (`temperature == 0` or `top_k == 1`) is byte-identical either way, and the no-filter path is unaffected (it belongs to `MLXCEL_SAMPLING_GUMBEL`). **The routed path never synchronizes.** Both decode drivers are software pipelines that build step n+1 and `async_eval` it before reading step n, so a sampler that evaluates anything internally drains the queue inside the caller's build phase and collapses the pipeline. The first cut of this kernel read the per-row converged flags back to host inside `fused_sample` and measured 1.7x slower end to end on Qwen3-0.6B, against an op-level matrix that scored the same configuration 1.14x to 1.17x faster. The production path therefore evaluates nothing: the round cap is unreachable by construction (the bit-space bracket bounds the loop at 31 rounds), and the converged flags are stashed and inspected on a later call once `array::is_available()` reports the launch has landed, which in a decode loop is by the next token. A row that somehow exhausted the cap returns its own argmax, which is always inside the filtered support, so the degradation would be one greedy draw rather than an invalid token; the event is counted in `mlxcel_core::rejection_cap_overflow_rows()` and announced once at INFO. Which path a run took is announced at INFO, once per distinct outcome kind, so a benchmark arm can be proven from a log. Set to a falsy value to restore the `argpartition` chain exactly, which is the way to reproduce a token stream recorded before this landed. Read once per process, so set it before starting `mlxcel` or `mlxcel-server`. Inert on CPU-only builds and under `MLXCEL_DEVICE=cpu`. A/B with `examples/rejection_sampling_microbench.rs`. |
 | `MLXCEL_CUDA_F16_NORMALIZE` | `1`/`true`/`on`/`yes` enable; `0`/`false`/`off`/`no` disable | **on** below sm_80, off (opt-in) at sm_80 and later | **CUDA only.** Load-time bf16 -> f16 normalization of weights for the single-dtype decode graph (issue #636). The default is split by compute capability because the hardware is. **Ampere and later (sm_80+)**: off, unchanged from #636. bf16 has native ALUs there, the merged `patches-cuda/dtype.cpp` promotion patch already yields a 0-AsType single-dtype bf16 decode graph, and f16 offers no measured throughput gain (qwen2.5-0.5b-bf16 decode 208 vs 207 tok/s on GB10) while narrowing dynamic range. **Volta and Turing (sm_70, sm_75)**: on, and quantized checkpoints are included. Those parts have no bf16 ALU, no bf16 tensor-core MMA atom, and no cuBLAS bf16 GEMM, so every bf16 operand is converted before it can execute. Measured on a Tesla V100 with qwen3.8-27B-4bit: prefill 85.3 s to 4.8 s and decode 118.1 to 49.2 ms per token, with `qmm_naive` spending 199.1 s against 11.4 s over an identical 994 launches. On a quantized checkpoint the packed planes stay u32 and only the bf16 side-data moves, which is why quantized models are in scope here and out of scope above. Set to `0` to opt out on pre-Ampere and keep bf16. The f16-fragile exception differs by architecture. At sm_80 and later it is the full conservative list from #732 (gemma, cohere/command-r, apertus, gpt-oss, and any config with a nonzero softcap or `logit_scale`). Below sm_80 every entry on that list was measured on a V100 and only **apertus** stays excluded: its xIELU squares its input, and f16 produces NaN at all 508 scored positions from the first token where bf16 scores 24.27. Gemma (+0.09% perplexity over 10208 tokens, decode 6.12 to 9.79 tok/s), gpt-oss (token-weighted -0.02%, with the two window sizes disagreeing in sign) and Cohere (which ships F16 weights already and so runs in f16 regardless, scoring 20.25 and 13.15) all measured clean, as did the generic softcap and `logit_scale` triggers, which is what a cap bounding a value rather than growing it predicts. Metal / Apple Silicon is governed by the separate always-on policy and is untouched. Drafter checkpoints loaded through `mlxcel-core` (DFlash, Muse Glimmer, Inkling MTP, Qwen 3.5 MTP) follow the same rule (issue #1782): before that, every drafter was converted to f16 unconditionally, and on Ampere and later CUDA, where the target keeps bf16, MLX promoted the bf16 residual stream times the f16 drafter weights to float32, so the whole drafter forward ran in f32 and re-upcast all of its weights on every round (about 240 launches and 30 to 38 ms of device time per verify round on GB10 with `qwen3.5-4b-4bit` and its DFlash drafter, the largest fixed term in the round). |
 | `MLXCEL_CUDA_F16_FRAGILE` | `1`/`true`/`on`/`yes` enable; unset keeps the exclusion | off (opt-in) | **CUDA below sm_80 only.** Converts a family on the f16-fragile exception list anyway. That list is inherited from #732, which adopted it for Ampere and later where f16 gave, in that commit's words, "no AsType reduction and no throughput gain": with no upside, excluding a family on a suspicion costs nothing, and that PR's test plan ran no fragile family in f16. Below sm_80 the list is down to apertus, which is the one entry measurement supported, so this flag now means converting a family that produced NaN at every scored position on this hardware. It remains for a checkpoint whose activations you have reason to believe differ, and for taking the measurement on a family this list does not yet know. |
 | `MLXCEL_KEEP_BF16` | set to any value to enable; unset disables | off | **Measurement instrument, not a supported configuration.** Skips load-time bf16 -> f16 conversion for every checkpoint, on every backend, so a bf16 model loads uniformly bf16. It exists to A/B a dtype policy against the mixture it replaces, and it is what established the Gemma3n result below. Gemma3n used to keep only its language MLP bf16 and convert the rest to f16, leaving one checkpoint holding both dtypes; MLX promotes f16 with bf16 to f32, so every boundary between the kept MLP and its f16 neighbours promoted and the decode path read promoted weights the whole way down. Loading uniformly bf16 measured, on M5 Max with `gemma3n-e4b-bf16` at a 273-token prompt with an image and 128 generated, decode 38.02 to 47.48 tok/s and prefill 2143 to 2371 tok/s, against mlx-vlm 0.6.17 at 48.72 and 1207: decode moves from 78% of the reference to 97% while prefill stays about 1.95x ahead. Gemma3n now loads uniformly bf16 by default (see `gemma3n_bf16_key`), so this flag no longer changes that family. **It is not evidence that bf16 beats f16.** The control run is the point: on families with no forced-bf16 subset the two dtypes land within noise of each other on the same hardware, `qwen2.5-0.5b-bf16` at 401.8 against 397.3 tok/s and `llama-3.1-8b-bf16` at 33.07 against 33.02. What costs is the mixture, not the dtype, so every other family keeps converting to f16 and setting this flag for them buys nothing while narrowing nothing. Drafter checkpoints loaded through `mlxcel-core` honor it the same way (issue #1782). Read per load. |
diff --git a/docs/installation.md b/docs/installation.md
index ff69344fe..45a0f9103 100644
--- a/docs/installation.md
+++ b/docs/installation.md
@@ -580,7 +580,7 @@ the 1.20 headroom factor alone fell short for the dense models.
 | Model-specific fused kernels (Apertus xIELU, Cohere2 add3 + LayerNorm, Mamba1 selective scan, Nemotron-H's opt-in `MLXCEL_FUSED_MOE_RELU2`) | Run as HIP ports (lablup/mlxcel#2069). xIELU and the add3 LayerNorm are byte-identical to ROCm's own unfused graph; the Mamba1 scan keeps its state in f32 as on Metal; the relu2 path is performance-neutral on Nemotron-H and stays opt-in. Apertus, Cohere2 and the Mamba1 families have no checkpoint on the tested host, so they are covered by kernel tests only ([results](benchmark_results/rocm-metal-only-ports-gfx1151-2026-10-05.md)). |
 | Fused residual-add RMSNorm and RoPE + KV append (`MLXCEL_FUSED_ADD_RMSNORM`, `MLXCEL_FUSED_ROPE_APPEND`) | On by default on ROCm (lablup/mlxcel#2145), off on Metal and CUDA. Both run as HIP ports (lablup/mlxcel#2063) whose output is byte-identical to the graph they replace, so they change no logits; decode on `gfx1151` was never slower with them (+0.3% on Llama 3.1 8B, +1.7% on Qwen2.5 7B, inside run-to-run drift). Set either variable to `0` to fall back to the graph. Llama 3.1 keeps the graph RoPE because of its `rope_scaling` table; Gemma and IQuest Loop Coder also take the norm port but have no checkpoint measured on ROCm ([results](benchmark_results/rocm-fused-norm-rope-gfx1151-2026-10-05.md)). |
 | Paged attention (the server's batched paged decode, MLA split-KV, sparse paged decode) | The v1 decode, v2 partial and merge kernels run as HIP ports (lablup/mlxcel#2068), so these paths take the fused kernels instead of gather-then-SDPA, as on Metal and CUDA; the kernels' tests match the gather and host references on `gfx1151`. Server decode on `gfx1151` with Meta-Llama-3.1-8B-Instruct-4bit, against the gather path on the same binary: 1.28x per-request decode at batch 4 and ~16K tokens, 1.40x and 1.77x for one sequence at ~16K and ~32K, no measurable change at batch 4 and ~4K ([results](benchmark_results/rocm-paged-attention-gfx1151-2026-10-05.md)). `MLXCEL_PAGED_ATTENTION_NATIVE=0` forces the gather path. |
-| Sampled decode (`temperature > 0`) | The fused Gumbel-max sampler (no filter) and the dual-pivot rejection sampler (top-p, and the other filter combinations its routing admits) run as HIP kernels, as on Metal and CUDA (lablup/mlxcel#2064). On `gfx1151` with Meta-Llama-3.1-8B-Instruct-4bit, decode at `--temperature 0.8 --top-p 0.95` went from 33.98 to 37.56 tok/s (medians of three; the before runs drifted from 36.26 down to 32.81, the after runs held 37.06 to 37.82); at `--temperature 0.8` alone the change is inside the noise ([results](benchmark_results/rocm-samplers-gfx1151-2026-10-05.md)). `MLXCEL_SAMPLING_GUMBEL=0` and `MLXCEL_SAMPLING_REJECTION=0` force the graph. |
+| Sampled decode (`temperature > 0`) | The fused Gumbel-max sampler (no filter) and the dual-pivot rejection sampler (top-p, and the other filter combinations its routing admits) run as HIP kernels, as on Metal and CUDA (lablup/mlxcel#2064). On `gfx1151` with Meta-Llama-3.1-8B-Instruct-4bit, decode at `--temperature 0.8 --top-p 0.95` went from 33.98 to 37.56 tok/s (medians of three; the before runs drifted from 36.26 down to 32.81, the after runs held 37.06 to 37.82); at `--temperature 0.8` alone the change is inside the noise ([results](benchmark_results/rocm-samplers-gfx1151-2026-10-05.md)). At the Llama 3 vocabulary (128256) and at Qwen's 151936 and 152064, top-p alone, top-p with min-p, and top-k with top-p (for example `--top-k 40 --top-p 0.95`) take the rejection kernel; top-k alone, min-p alone, and top-k with min-p take the stock chain. A ROCm build routes top-k with top-p up to vocab 152064 (32768 on Metal and CUDA): with it, `--temperature 0.8 --top-k 40 --top-p 0.95` decode went from 33.15 to 37.73 tok/s on Meta-Llama-3.1-8B-Instruct-4bit and from 41.91 to 46.92 tok/s on Qwen2.5-7B-Instruct-4bit (medians of three interleaved pairs, [joint-cap results](benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md), lablup/mlxcel#2157). `MLXCEL_SAMPLING_GUMBEL=0` and `MLXCEL_SAMPLING_REJECTION=0` force the graph. |
 | Hybrid SSM decode (granite-4.0-h, falcon-h1, plamo-2, Nemotron-H) | The single-token Mamba2 SSM update runs the fused HIP kernel instead of the ~55-op SSD graph (lablup/mlxcel#2067): decode on `gfx1151` went from 60.4 to 88.4 tok/s on granite-4.0-h-tiny-4bit and from 51.4 to 74.4 tok/s on Nemotron-3-Nano-30B-A3B-4bit, with model logits matching the graph and Metal's kernel at every decided position ([results](benchmark_results/rocm-ssm-update-kernel-gfx1151-2026-10-04.md)). Measured on granite and Nemotron-H; falcon-h1 and plamo-2 take the same gate but have not been run on ROCm. `MLXCEL_SSM_KERNEL=0` forces the graph. |
 | GPU faults | Reported as errors (lablup/mlxcel#1804). A launch HIP rejects (an oversized block, no code object for the device) fails the evaluation that issued it and the device stays usable. An asynchronous fault (an out-of-bounds access) fails the evaluation waiting on it within about a second instead of hanging or returning NaN; the server fails that request and answers later ones with the same error, because after a queue fault the HIP runtime rejects every call for the rest of the process, so the process has to restart, and its shutdown may need a SIGKILL (HIP's teardown waits on callbacks the faulted queue never runs). A kernel that never finishes is not detected; `MLX_ROCM_GPU_WATCHDOG_SECS` (default off) fails any single host wait that outlives it. |
 | Memory estimation on UMA hosts | Correct. Measured on the tested configuration: the ROCm allocator reports a nonzero cap (76.80 GiB of the 96 GiB carve-out), which the estimator reads before it would ever reach host RAM, so nothing that fits the carve-out is refused for that reason (lablup/mlxcel#1805). |
diff --git a/examples/rejection_sampling_microbench.rs b/examples/rejection_sampling_microbench.rs
index d55554b3d..2da2e09ee 100644
--- a/examples/rejection_sampling_microbench.rs
+++ b/examples/rejection_sampling_microbench.rs
@@ -92,11 +92,18 @@
 //!     --example rejection_sampling_microbench
 //! Run (CUDA):
 //!   cargo run --release --features cuda --example rejection_sampling_microbench
+//! Run (ROCm):
+//!   cargo run --release --features rocm --example rejection_sampling_microbench
 //!
 //! Options:
 //!   --iters N     timed repetitions per point (default 200)
 //!   --warmup N    discarded repetitions per point (default 30)
 //!   --csv PATH    also write the table as CSV
+//!   --dtype T     logits dtype: f32 (default), bf16 or f16. A bf16 checkpoint
+//!                 hands the sampler bf16 logits, and the stock chain's sort
+//!                 cost depends on the dtype (#2157)
+//!   --config L    run only the filter configuration labelled L (for example
+//!                 `top-k+top-p`)
 //!
 //! On Apple Silicon run under `caffeinate -i` and let the machine cool between
 //! sweeps; it down-clocks under sustained load.
@@ -105,12 +112,13 @@ use std::fmt::Write as _;
 use std::time::{Duration, Instant};
 
 use mlxcel_core::{
-    MlxArray, UniquePtr, array_to_raw_bytes, async_eval_pair, custom_kernels_available, eval,
-    from_slice_f32, fused_sample, fused_sample_categorical, fused_sample_rejection,
-    gpu_backend_available, matmul, random_seed, rejection_cap_overflow_launches,
-    rejection_cap_overflow_rows, reset_sampling_dispatch, sampling_dispatch_drain_pending,
-    sampling_dispatch_recorded_report, sampling_rejection_available, sampling_rejection_max_rounds,
-    sampling_rejection_probe, sampling_rejection_routes, synchronize_default,
+    MlxArray, UniquePtr, array_to_raw_bytes, astype, async_eval_pair, dtype, eval, from_slice_f32,
+    fused_sample, fused_sample_categorical, fused_sample_rejection, gpu_backend_available, matmul,
+    random_seed, rejection_cap_overflow_launches, rejection_cap_overflow_rows,
+    reset_sampling_dispatch, sampling_dispatch_drain_pending, sampling_dispatch_recorded_report,
+    sampling_rejection_available, sampling_rejection_backend_supported,
+    sampling_rejection_joint_vocab_max, sampling_rejection_max_rounds, sampling_rejection_probe,
+    sampling_rejection_routes, synchronize_default,
 };
 
 /// Target duration for the synthetic forward in the pipelined mode. Roughly a
@@ -121,7 +129,9 @@ const PIPELINE_FORWARD_TARGET_US: f64 = 2000.0;
 /// Side length of the synthetic forward's square matmul.
 const FORWARD_DIM: i32 = 1024;
 
-const VOCABS: [i32; 3] = [32_768, 65_536, 152_064];
+/// 128256 (Llama 3) and 151936 (Qwen3) were added for the ROCm joint-cap
+/// measurement (#2157); 152064 is Qwen 2.5's.
+const VOCABS: [i32; 5] = [32_768, 65_536, 128_256, 151_936, 152_064];
 const BATCHES: [i32; 3] = [1, 4, 8];
 const TEMPERATURE: f32 = 1.0;
 
@@ -137,6 +147,9 @@ struct Options {
     iters: usize,
     warmup: usize,
     csv: Option<String>,
+    dtype: i32,
+    dtype_label: &'static str,
+    config: Option<String>,
 }
 
 fn parse_options() -> Options {
@@ -144,6 +157,9 @@ fn parse_options() -> Options {
         iters: 200,
         warmup: 30,
         csv: None,
+        dtype: dtype::FLOAT32,
+        dtype_label: "f32",
+        config: None,
     };
     let mut args = std::env::args().skip(1);
     while let Some(arg) = args.next() {
@@ -163,6 +179,23 @@ fn parse_options() -> Options {
             "--csv" => {
                 opts.csv = Some(args.next().expect("--csv needs a path"));
             }
+            "--dtype" => {
+                let value = args.next().expect("--dtype needs f32, bf16 or f16");
+                (opts.dtype, opts.dtype_label) = match value.as_str() {
+                    "f32" => (dtype::FLOAT32, "f32"),
+                    "bf16" => (dtype::BFLOAT16, "bf16"),
+                    "f16" => (dtype::FLOAT16, "f16"),
+                    other => panic!("--dtype takes f32, bf16 or f16, got {other}"),
+                };
+            }
+            "--config" => {
+                let label = args.next().expect("--config needs a label");
+                assert!(
+                    CONFIGS.iter().any(|(l, ..)| *l == label),
+                    "--config {label} is not one of the configurations"
+                );
+                opts.config = Some(label);
+            }
             other => panic!("unknown argument {other}"),
         }
     }
@@ -355,7 +388,9 @@ fn main() {
     // port predicate alone, deliberately not `sampling_rejection_available()`,
     // because the whole point of the isolated arm is to measure the kernel with
     // routing switched off, and that predicate folds in the routing kill switch.
-    if !custom_kernels_available() {
+    // `custom_kernels_available()` is Metal-or-CUDA by definition, so it must
+    // not be the gate: the ROCm port (#2064) would never be measured (#2157).
+    if !sampling_rejection_backend_supported() {
         eprintln!(
             "This GPU backend has no rejection-sampling kernel port; there is nothing to measure."
         );
@@ -364,15 +399,16 @@ fn main() {
     let cap = sampling_rejection_max_rounds();
     println!(
         "Dual-pivot rejection sampling microbenchmark (#901)  iters={} warmup={}  \
-         routing_enabled={}  round_cap={cap}",
+         routing_enabled={}  round_cap={cap}  logits={}",
         opts.iters,
         opts.warmup,
-        sampling_rejection_available()
+        sampling_rejection_available(),
+        opts.dtype_label
     );
 
     // Prove the two arms take different paths before timing anything.
     reset_sampling_dispatch();
-    let probe_logits = synthetic_logits(4, 32_768);
+    let probe_logits = astype(&synthetic_logits(4, 32_768), opts.dtype);
     let _ = fused_sample_categorical(&probe_logits, TEMPERATURE, 40, 0.9, 0.0);
     print_dispatch("  baseline arm  -> ");
     reset_sampling_dispatch();
@@ -411,9 +447,13 @@ fn main() {
          pipe_baseline_us,pipe_rejection_us,pipe_speedup\n",
     );
     for (label, top_k, top_p, min_p) in CONFIGS {
+        if opts.config.as_deref().is_some_and(|wanted| wanted != label) {
+            continue;
+        }
         for vocab in VOCABS {
             for batch in BATCHES {
-                let logits = synthetic_logits(batch, vocab);
+                let logits = astype(&synthetic_logits(batch, vocab), opts.dtype);
+                eval(&logits);
                 let rounds = worst_rounds(&logits, batch, top_k, top_p, min_p, cap);
 
                 // Reseed before each arm so both consume the same RNG stream
@@ -479,8 +519,9 @@ fn main() {
     );
     println!(
         "routing policy: the kernel replaces a sort, so it is routed only where the stock chain \
-         sorts (top-p active), and top-k + top-p only at vocab <= 32768. A routed=no row is a \
-         path production does not take."
+         sorts (top-p active), and top-k + top-p only at vocab <= {} on this build. A routed=no \
+         row is a path production does not take.",
+        sampling_rejection_joint_vocab_max()
     );
     println!(
         "read pipe_x, not iso_x: iso synchronizes around every iteration and is structurally \
diff --git a/scripts/bench_decode.sh b/scripts/bench_decode.sh
index 44c8de839..30660a274 100755
--- a/scripts/bench_decode.sh
+++ b/scripts/bench_decode.sh
@@ -158,12 +158,14 @@ NO_CHAT_TEMPLATE=0
 NO_DEDUP=0
 OUTPUT=""
 SUFFIX=""
-# Sampling for both passes (issue #2064). Empty means the runner's default,
-# greedy argmax, which never dispatches a sampler kernel; a sampled run is how
-# the Gumbel-max and rejection kernels are measured. The CSV schema does not
-# record either, so a non-greedy run also tags the auto-generated filename.
+# Sampling for both passes (issue #2064; --top-k from #2157). Empty means the
+# runner's default, greedy argmax, which never dispatches a sampler kernel; a
+# sampled run is how the Gumbel-max and rejection kernels are measured. The CSV
+# schema records none of them, so a non-greedy run also tags the
+# auto-generated filename.
 TEMPERATURE=""
 TOP_P=""
+TOP_K=""
 DATE=$(date '+%Y-%m-%d')
 # Version recorded in the CSV `mlxcel_version` column. This is the mlxcel
 # version from Cargo.toml (the /update-benchmarks staleness check compares
@@ -866,6 +868,9 @@ Options:
   --top-p P           Nucleus threshold, effective with a positive
                       --temperature (default: the runner's 1.0, off). Tags
                       the filename with `_p<P>`.
+  --top-k K           Top-k cutoff, effective with a positive --temperature
+                      (default: the runner's 0, off). Tags the filename with
+                      `_k<K>`.
   --cooldown N        Sleep N seconds after every model to let the GPU cool
                       down (default: 0). Use on thermally constrained
                       hardware such as the MacBook Pro M5 Max where back-to-
@@ -959,6 +964,7 @@ default_output_path() {
   name="${name}_${DATE}"
   [[ -n "$TEMPERATURE" ]] && name="${name}_t${TEMPERATURE}"
   [[ -n "$TOP_P" ]] && name="${name}_p${TOP_P}"
+  [[ -n "$TOP_K" ]] && name="${name}_k${TOP_K}"
   if [[ -n "$SUFFIX" ]]; then
     name="${name}_${SUFFIX}"
   fi
@@ -1084,6 +1090,7 @@ bench_one() {
   fi
   [[ -n "$TEMPERATURE" ]] && extra_args+=(--temperature "$TEMPERATURE")
   [[ -n "$TOP_P" ]] && extra_args+=(--top-p "$TOP_P")
+  [[ -n "$TOP_K" ]] && extra_args+=(--top-k "$TOP_K")
 
   >&2 printf '>>> [bench]  %s (same-process warmup=%s) ...\n' "$model_name" "$WARMUP_TOKENS"
   local raw rc=0
@@ -1175,6 +1182,7 @@ while [[ $# -gt 0 ]]; do
     --suffix)         SUFFIX="$2"; shift 2 ;;
     --temperature)    TEMPERATURE="$2"; shift 2 ;;
     --top-p)          TOP_P="$2"; shift 2 ;;
+    --top-k)          TOP_K="$2"; shift 2 ;;
     --cooldown)       COOLDOWN_SECS="$2"; shift 2 ;;
     --big-cooldown)   BIG_MODEL_COOLDOWN_SECS="$2"; shift 2 ;;
     --big-threshold-gb)
@@ -1199,6 +1207,12 @@ for _sampling_opt in "--temperature:$TEMPERATURE" "--top-p:$TOP_P"; do
     exit 1
   fi
 done
+# No leading zeros (the filename tag would not match the value) and at most
+# nine digits (the runner takes an i32).
+if [[ -n "$TOP_K" && ! "$TOP_K" =~ ^(0|[1-9][0-9]{0,8})$ ]]; then
+  echo "Error: --top-k takes a non-negative integer, got '$TOP_K'" >&2
+  exit 1
+fi
 
 if [[ -z "$MODEL_ARG" ]]; then
   echo "Error: model path or 'all' required" >&2
diff --git a/src/bin/bench_decode.rs b/src/bin/bench_decode.rs
index 35dce8e02..f583decaf 100644
--- a/src/bin/bench_decode.rs
+++ b/src/bin/bench_decode.rs
@@ -93,6 +93,12 @@ struct Args {
     #[arg(long, default_value_t = 1.0)]
     top_p: f32,
 
+    /// Top-k cutoff for both passes. 0 disables it. Only has an effect with a
+    /// positive `--temperature`; with `--top-p` it measures the joint filter,
+    /// whose rejection-kernel routing is capped by vocabulary (#2157).
+    #[arg(long, default_value_t = 0, value_parser = clap::value_parser!(i32).range(0..))]
+    top_k: i32,
+
     /// Generated tokens in the warmup pass.
     #[arg(long, default_value_t = 20)]
     warmup_tokens: usize,
@@ -284,11 +290,12 @@ fn sampling_config(
     model: &LoadedModel,
     ignore_eos: bool,
     temperature: f32,
+    top_k: i32,
     top_p: f32,
 ) -> SamplingConfig {
     let mut config = build_sampling_config(ResolvedSamplingParams {
         temperature,
-        top_k: 0,
+        top_k,
         top_p,
         min_p: 0.0,
         seed: None,
@@ -517,6 +524,7 @@ fn main() -> Result<()> {
         &model,
         args.ignore_eos,
         args.temperature,
+        args.top_k,
         args.top_p,
     );
 
diff --git a/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp b/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp
index 905e26298..7ff6bc679 100644
--- a/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp
+++ b/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.cpp
@@ -5790,11 +5790,50 @@ static bool gumbel_sample_applies(
 
 // Vocabulary ceiling for routing top-k and top-p together.
 //
-// 32768 is measured (1.27x - 1.64x across three repetitions); 152064 is measured
-// as a loss (0.71x - 0.83x); 65536 has not been measured for this combination and
-// is therefore excluded rather than interpolated. Raise it only against a
-// measurement, never to widen coverage.
+// M1 Ultra (#901): 32768 is measured (1.27x - 1.64x across three repetitions);
+// 152064 is measured as a loss (0.71x - 0.83x); 65536 has not been measured for
+// this combination and is therefore excluded rather than interpolated.
+//
+// gfx1151 (#2157, docs/benchmark_results/rocm-rejection-joint-cap-gfx1151-2026-10-07.md):
+// re-measured with the cap lifted on a measurement build, so `fused_sample`
+// routed every cell. Medians of three runs, top-k 40 + top-p 0.9, pipe_x by
+// batch {1, 4, 8} (iso_x for batch 1 in brackets):
+//
+//   vocab  32768   1.00  1.17  1.44   [2.23]
+//   vocab  65536   0.98  1.18  1.64   [1.59]
+//   vocab 128256   0.98  1.28  1.80   [0.96]
+//   vocab 151936   0.90  1.36  1.90   [0.92]
+//   vocab 152064   0.93  1.29  2.02   [0.92]
+//
+// Batches 4 and 8 win at every vocabulary. Batch 1, the single-stream decode
+// shape, does not clear 1.0 above 32768 on these synthetic logits (bf16 logits
+// read the same: 0.98 at 128256, 0.86 at 152064), so by the microbenchmark
+// alone the cap would stay 32768. End-to-end decode says otherwise, and it is
+// the measurement the issue's rule defers to at 128256 and above: with
+// `--temperature 0.8 --top-k 40 --top-p 0.95`, a measurement build that routes
+// the joint case against `MLXCEL_SAMPLING_REJECTION=0` (medians of three
+// interleaved pairs, every pair clean under `scripts/rocm_gpu_guard.sh`):
+//
+//   Meta-Llama-3.1-8B-Instruct-4bit (128256)  37.57 vs 32.67 tok/s, 1.15x
+//   Qwen2.5-7B-Instruct-4bit        (152064)  46.92 vs 41.91 tok/s, 1.12x
+//
+// with every kernel run faster than every chain run. Why the synthetic batch-1
+// cell does not predict real decode on this GPU was not isolated. On ROCm the
+// cap is therefore 152064, the largest vocabulary measured both ways; larger
+// vocabularies (gpt-oss 201088, Gemma 262144) are unmeasured and stay on the
+// chain. A ROCm build has no Metal or CUDA backend, so the build flag is the
+// backend here, as for the SGY default in `mlx_cxx_kernels.cpp`; there is no
+// runtime backend comparison. Raise either value only against a measurement,
+// never to widen coverage.
+#ifdef MLXCEL_BRIDGE_ROCM_BACKEND
+constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 152064;
+#else
 constexpr int32_t REJECTION_JOINT_VOCAB_MAX = 32768;
+#endif
+
+int32_t sampling_rejection_joint_vocab_max() {
+    return REJECTION_JOINT_VOCAB_MAX;
+}
 
 // Pure routing policy: would `fused_sample` send this configuration to the
 // rejection kernel, ignoring backend support and the env switch? Exposed so a
@@ -5829,8 +5868,12 @@ static std::string rejection_not_routed_reason(
               "measured slower: top-k alone 0.31x-0.97x, min-p alone "
               "0.47x-0.88x";
     } else {
-        os << "top-k and top-p together measured 0.71x-0.83x above vocab "
-           << REJECTION_JOINT_VOCAB_MAX << ", and this row has vocab " << vocab;
+        os << "top-k and top-p together route only up to vocab "
+           << REJECTION_JOINT_VOCAB_MAX
+           << " on this build, the largest vocabulary where the combination "
+              "measured a win (above it, M1 Ultra measured 0.71x-0.83x at "
+              "152064 and gfx1151 is unmeasured), and this row has vocab "
+           << vocab;
     }
     os << "; top_k " << top_k << ", top_p " << top_p << ", min_p " << min_p
        << ")";
diff --git a/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.h b/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.h
index 68385fb5f..8f1122b3c 100644
--- a/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.h
+++ b/src/lib/mlxcel-core/cpp/mlx_cxx_bridge.h
@@ -1630,6 +1630,10 @@ bool sampling_rejection_routes(
     float min_p
 );
 
+// The vocabulary ceiling `sampling_rejection_routes` applies to top-k and
+// top-p together on this build (`REJECTION_JOINT_VOCAB_MAX`, #2157).
+int32_t sampling_rejection_joint_vocab_max();
+
 // Threads per threadgroup the rejection kernel launches with.
 int32_t sampling_rejection_threadgroup_size();
 
diff --git a/src/lib/mlxcel-core/src/lib.rs b/src/lib/mlxcel-core/src/lib.rs
index dfc5f06be..51454685f 100644
--- a/src/lib/mlxcel-core/src/lib.rs
+++ b/src/lib/mlxcel-core/src/lib.rs
@@ -2666,6 +2666,14 @@ mod ffi {
         /// Pure host arithmetic, so it answers on a CPU-only build too.
         fn sampling_rejection_routes(vocab: i32, top_k: i32, top_p: f32, min_p: f32) -> bool;
 
+        /// The vocabulary ceiling [`sampling_rejection_routes`] applies to
+        /// top-k and top-p together on this build: the compile-time
+        /// `REJECTION_JOINT_VOCAB_MAX` in `mlx_cxx_bridge.cpp`, 152064 on a
+        /// ROCm build (gfx1151, #2157) and 32768 on every other build (M1
+        /// Ultra, #901). It is chosen by build flag, never by a runtime
+        /// backend check.
+        fn sampling_rejection_joint_vocab_max() -> i32;
+
         /// Threads per threadgroup the rejection kernel launches with. The
         /// determinism argument rests on this being fixed, so it is exposed.
         fn sampling_rejection_threadgroup_size() -> i32;
diff --git a/src/lib/mlxcel-core/src/sampling_rejection_tests.rs b/src/lib/mlxcel-core/src/sampling_rejection_tests.rs
index d2744a881..349e46953 100644
--- a/src/lib/mlxcel-core/src/sampling_rejection_tests.rs
+++ b/src/lib/mlxcel-core/src/sampling_rejection_tests.rs
@@ -983,6 +983,12 @@ fn a_starved_round_cap_falls_back_and_the_event_is_counted() {
 /// | min-p alone | 0.47x - 0.88x at 152K | no |
 /// | top-k + top-p | 1.27x - 1.64x at 32K, 0.71x - 0.83x at 152K | only at vocab <= 32768 |
 ///
+/// gfx1151 re-measured the joint row (#2157, vocab {32K, 64K, 128256, 151936,
+/// 152064}): batches 4 and 8 win everywhere, and end-to-end decode with the
+/// joint case routed measured 1.15x on Llama 3.1 8B (128256) and 1.12x on
+/// Qwen2.5-7B (152064), so a ROCm build caps it at 152064 instead.
+/// [`the_joint_vocab_cap_is_the_measured_crossover`] pins the per-build value.
+///
 /// The kernel replaces a sort, so it wins exactly where the stock chain sorts,
 /// which is when top-p is active. The `rounds` column of the microbenchmark
 /// shows why the joint case degrades with vocabulary: top-p accepts in one or
@@ -1020,15 +1026,31 @@ fn the_routing_policy_matches_the_measured_matrix() {
         );
     }
 
-    // The joint case is capped at the vocabulary where it was measured to win.
-    // 65536 is excluded because it has not been measured for this combination,
-    // not because it was measured to lose.
+    // The joint case is capped at the vocabulary where it was measured to win,
+    // which is per build (#2157). On M1 Ultra 65536 is excluded because it has
+    // not been measured for this combination. On gfx1151 every vocabulary up
+    // to 152064 routes; 128256 is the Llama 3 vocabulary that prompted the
+    // re-measurement, 151936 Qwen3's, 152064 Qwen 2.5's.
+    let rocm = cfg!(feature = "rocm");
     assert!(sampling_rejection_routes(4096, 40, 0.9, 0.0));
     assert!(sampling_rejection_routes(32_768, 40, 0.9, 0.0));
-    assert!(!sampling_rejection_routes(65_536, 40, 0.9, 0.0));
-    assert!(!sampling_rejection_routes(152_064, 40, 0.9, 0.0));
     assert!(sampling_rejection_routes(32_768, 40, 0.9, 0.05));
-    assert!(!sampling_rejection_routes(152_064, 40, 0.9, 0.05));
+    for vocab in [65_536, 128_256, 151_936, 152_064] {
+        assert_eq!(
+            sampling_rejection_routes(vocab, 40, 0.9, 0.0),
+            rocm,
+            "top-k + top-p at vocab {vocab}"
+        );
+        assert_eq!(
+            sampling_rejection_routes(vocab, 40, 0.95, 0.05),
+            rocm,
+            "top-k + top-p + min-p at vocab {vocab}"
+        );
+    }
+    // Above every measured vocabulary the joint case stays on the chain on
+    // every build (gpt-oss 201088, Gemma 262144).
+    assert!(!sampling_rejection_routes(201_088, 40, 0.9, 0.0));
+    assert!(!sampling_rejection_routes(262_144, 40, 0.95, 0.0));
 
     // A top-k that cannot bind is not a top-k: it leaves the chain's cost
     // profile at top-p alone, so it does not drag the joint ceiling in.
@@ -1038,6 +1060,42 @@ fn the_routing_policy_matches_the_measured_matrix() {
     assert!(sampling_rejection_routes(152_064, 1, 0.9, 0.0));
 }
 
+/// The joint top-k + top-p cap is the measured crossover on this build, and the
+/// routing policy turns exactly at it (#2157).
+///
+/// M1 Ultra (#901) measured the crossover at 32768, which every non-ROCm build
+/// keeps. gfx1151 measured end-to-end wins at 128256 and 152064 and nothing
+/// above, so a ROCm build (`#ifdef MLXCEL_BRIDGE_ROCM_BACKEND`, which build.rs
+/// defines exactly when the `rocm` feature is on) caps at 152064. The value is
+/// a compile-time constant; this test is where each build's value is pinned.
+/// Pure host arithmetic, so it runs on a CPU-only build too.
+#[test]
+fn the_joint_vocab_cap_is_the_measured_crossover() {
+    const MEASURED_CAP: i32 = if cfg!(feature = "rocm") {
+        152_064
+    } else {
+        32_768
+    };
+    let cap = sampling_rejection_joint_vocab_max();
+    assert_eq!(
+        cap,
+        MEASURED_CAP,
+        "REJECTION_JOINT_VOCAB_MAX moved without a measurement (rocm build: {})",
+        cfg!(feature = "rocm")
+    );
+
+    // The policy reads the same constant the accessor reports: the cells on
+    // either side of it decide differently.
+    assert!(sampling_rejection_routes(cap, 40, 0.9, 0.0));
+    assert!(!sampling_rejection_routes(cap + 1, 40, 0.9, 0.0));
+    assert!(sampling_rejection_routes(cap, 40, 0.95, 0.02));
+    assert!(!sampling_rejection_routes(cap + 1, 40, 0.95, 0.02));
+    // Above the cap top-p alone still routes, and a top-k that cannot bind
+    // does not bring the cap in.
+    assert!(sampling_rejection_routes(cap + 1, 0, 0.9, 0.0));
+    assert!(sampling_rejection_routes(cap + 1, cap + 1, 0.9, 0.0));
+}
+
 /// Which path `fused_sample` took for one configuration, decided by comparing
 /// its stream against both arms at one seed.
 ///
@@ -1111,24 +1169,33 @@ fn a_large_vocabulary_sends_the_joint_config_back_to_the_stock_chain() {
         return;
     }
     // The llama-server default (top-k 40 + top-p 0.9) above the measured
-    // ceiling. This is the cell that measured 0.71x-0.83x, so it must decline,
-    // and it must say the vocabulary is the reason.
-    let logits = spread_logits(65_536, 0x90F);
+    // ceiling, which is per build (#2157): 65536 on a build capped at 32768
+    // (M1 Ultra measured the joint case losing above it), and gpt-oss's
+    // 201088 on a ROCm build capped at 152064 (unmeasured above the cap). It
+    // must decline, and it must say the vocabulary is the reason.
+    let vocab: usize = if sampling_rejection_joint_vocab_max() < 65_536 {
+        65_536
+    } else {
+        201_088
+    };
+    assert!(vocab as i32 > sampling_rejection_joint_vocab_max());
+    let logits = spread_logits(vocab, 0x90F);
     let batched = tiled(&logits, 4);
 
     assert!(
         !took_the_kernel(&batched, 40, 0.9, 0.0),
-        "a 65536-vocabulary top-k + top-p launch reached the kernel"
+        "a {vocab}-vocabulary top-k + top-p launch reached the kernel"
     );
 
     reset_sampling_dispatch();
     let tokens = u32_values(&fused_sample(&batched, 1.0, 40, 0.9, 0.0));
     assert_eq!(tokens.len(), 4);
     let lines = recorded_dispatch();
+    let vocab_text = vocab.to_string();
     assert!(
         lines
             .iter()
-            .any(|l| l.contains("not routed") && l.contains("65536")),
+            .any(|l| l.contains("not routed") && l.contains(&vocab_text)),
         "the decline did not name the vocabulary that caused it: {lines:?}"
     );
 
@@ -1136,7 +1203,7 @@ fn a_large_vocabulary_sends_the_joint_config_back_to_the_stock_chain() {
     // of splitting the policy by filter rather than by vocabulary alone.
     assert!(
         took_the_kernel(&batched, 0, 0.9, 0.0),
-        "top-p alone at vocab 65536 measured a win at every batch and must still route"
+        "top-p alone at vocab {vocab} must still route"
     );
 }