# RTX 4090 D gpu-unlock measurement data

Measurements taken on 2026-10-24, on one RTX 4090 D (`10de:2685`, 114 SMs, 24 GB), Ubuntu 24.04.4 LTS, kernel `6.17.0-1032-oem`, NVIDIA `595.58.03 open`, and a 425 W power limit. See `environment.json` for the public experiment configuration. Machine-specific paths, credentials, full boot logs, input prompts, and generated prose are omitted from this public subset.

中文说明：这是文章的公开数据子集。补丁保持实验原样，计算日志保留原始数值并去掉设备 UUID；推理记录保留真实计数和计时字段，去掉响应标识及生成文字。启动日志节选只保留解锁消息，rate 查询也去掉设备 UUID；没有打包密钥、完整服务配置、固件或模块二进制。`environment.json` 标明测试条件，`verify_results.py` 从逐条记录重新计算表格，并检查文件清单。

## Files and aggregation

- `rtx4090d.patch`: local device-dispatch changes against [JustAResearcher/gpu-unlock-ada at 491925c1079435e260137b9f3526066e764de830](https://github.com/JustAResearcher/gpu-unlock-ada/tree/491925c1079435e260137b9f3526066e764de830). It adds admission, AD102 firmware/validation dispatch, explicit opt-in, and host tests for `2685`. The 4090 D requires one exact PCI BDF and `ad102d_experimental=1`; `all` and comma-separated lists are rejected for this device. This patch is an experimental change, not a claim of upstream support.
- `gemm_bench.cu`, `gemm-before.log`, `gemm-after.log`: actual cuBLAS runs. The same binary was used before/after with the same power limit; square `n=8192`, five samples of 20 timed iterations, after ten warmup iterations. Throughput uses `2*n^3` operations per GEMM. The headline is the median of the five samples. The benchmark source measures throughput; the separate numerical checks are listed below.
- `mma-before.log`, `mma-after.log`: instruction microbenchmarks; each number is the best throughput of three measurements with the same configuration, rather than a median.
- `numeric-before.log`, `numeric-after.log`: separate FP16/BF16 GEMM correctness checks, 65536 elements per mode.
- `tensor-modes-before.log`, `tensor-modes-after.log`: separate FP16/FP32, TF32 and INT4 cubin measurements and numerical checks, 270336 elements per mode.
- `rates.json`: read-only NVIDIA rate getter output before unlocking and after each trial boot, with the GPU UUID removed. `0=full`, `1=half`, `2=quarter`. Rate labels are those returned by the interface; they do not establish that every integer workload was previously limited.
- `kernel-trial-excerpt.log`, `kernel-repeat-excerpt.log`: selector and post-FLR messages from the two actual trial boots. Hostnames, root UUID, unrelated messages and full boot command lines are omitted.
- `tests.log`: original host unittest output, excluding the shell command containing a machine-specific path. 22 tests ran, 19 passed, and 3 optional offline-decryption tests were skipped because PyCryptodome was absent.
- `inference-runs.json`, `inference-runs.csv`: all 15 successful formal requests, sorted by case and repetition. One 64-token warmup is excluded. JSON retains native timings, API usage, client latency, input/output hashes, and relevant server counters; CSV provides the core numeric fields. No measured result is synthesized.
- `inference-summary.json`: per-metric medians and ranges, three requests per case. Different median columns can come from different requests. Input counts include the chat template. All requests use greedy sampling with thinking disabled, run serially, and end at their configured output-token limit.
- `environment.json`: sanitized environment, pinned source commits, method definitions, and historical-comparison metadata.
- `SHA256SUMS`: hashes of all files in this directory except the manifest itself. Hashes check file integrity; they do not establish independent provenance of the underlying experiment.
- `verify_results.py`: Python standard-library-only aggregation and integrity checks. Run locally after downloading the complete directory. It makes no network or model requests.

KV prefix reuse was zero in every formal request (`cached_tokens=0`, `cache_n=0`). The model was already loaded; the expert cache warmed across requests and was not reset between them. The 2K/8K Chinese inputs were synthetic material generated by the harness, while the 32K case used then-current Strata server source. All requests returned HTTP 200 with complete SSE termination. API output counts, native generated-token counts, and server counts agreed, and the service request counter advanced exactly once per request. Answer correctness or completeness was not evaluated.

Decode throughput is `timings.predicted_per_second` (retained output tokens divided by native decode time); rejected draft tokens and prefill time are excluded. Prefill uses `timings.prompt_per_second` over actually computed prompt tokens. Client `ttft_s` and `wall_s` use a monotonic clock and include HTTP/service overhead. Short-prompt prefill rates include substantial fixed overhead.

The historical reference uses the v0.1.39 comparison batch in [the earlier blog post](https://blog.ferstar.org/posts/qwen38-flash-next-strata-4090/). Its code-workflow decode median and 20K–40K cold-prefill median differ from this experiment's exact inputs, output lengths, sampling and engine version. The observed deltas do not isolate the unlock's contribution. The previous post's earlier 58-request aggregate is a separate batch and is not mixed into this comparison.

## Recalculate the tables

Download the [complete data archive](../rtx4090d-gpu-unlock-data.tar.gz), unpack it, then run from its directory:

```sh
python3 verify_results.py
```

The script checks the checksum manifest, sample counts, token-counter agreement, success fields, zero prefix reuse, CSV/JSON agreement, numerical-check results and stored summary. It then prints the actual GEMM and inference aggregates. It does not rerun CUDA or model inference.

## Apply the patch and inspect it

Use the exact base commit:

```sh
git clone https://github.com/JustAResearcher/gpu-unlock-ada.git gpu-unlock-4090d
cd gpu-unlock-4090d
git checkout --detach 491925c1079435e260137b9f3526066e764de830
git apply --check /path/to/rtx4090d.patch
git apply /path/to/rtx4090d.patch
git diff --check
```

Build and firmware asset retrieval follow that pinned repository's instructions and license terms. The experiment used `make test` and a module build with `KCFLAGS=-Werror`; neither a passed host test nor a successful build establishes compatibility with another GPU or boot setup. Unlock firmware assets were `610.43.03`, while the running NVIDIA driver was `595.58.03 open`.

To rebuild the cuBLAS throughput program on a CUDA-equipped host:

```sh
nvcc -O3 -std=c++17 -arch=sm_89 gemm_bench.cu -lcublas -o gemm_bench
./gemm_bench
```

The reference logs report cuBLAS `120002`. Do not compare a locally rebuilt program against the archived results as a controlled hardware A/B unless the toolchain, library, power limit, clocks and workload are also accounted for.

## Later upstream cross-check (2026-10-25)

中文补充：以上补丁对应实验时固定的旧基线。交叉检查时，社区仓库已在下述提交合入独立的 4090 D 实现，开关名为 `rtx4090d_experimental=1`，并允许多卡选择；本地补丁仍用 `ad102d_experimental=1`，且限定单个 BDF。两套参数按各自源码使用。普通 4090 的原始报告支持相同的 Tensor 指令吞吐变化，4090 D 的八卡结果则来自贡献者文字报告。新代码的固件加载校验与基准测试加固未在本机重新进行硬件验证。

The later inspection was pinned to [JustAResearcher/gpu-unlock-ada at 4e7fefcc4923f9e083d5324dc75a7d2f906af77f](https://github.com/JustAResearcher/gpu-unlock-ada/tree/4e7fefcc4923f9e083d5324dc75a7d2f906af77f), after [PR #7](https://github.com/JustAResearcher/gpu-unlock-ada/pull/7) added a separate RTX 4090 D implementation. Device admission, AD102 asset selection and the architecture check include `2685`. Its switch is `rtx4090d_experimental=1`, and it permits `targets=all` and comma-separated selections. A local host-shim probe exercised no-opt-in rejection, exact-BDF dispatch, all-card dispatch and list dispatch; all four passed. This probe mocked the unlock transaction and used no GPU. The original experiment's patch, module and benchmark results remain pinned to the older baseline above.

[PR #1's matched regular-4090 report](https://github.com/JustAResearcher/gpu-unlock-ada/blob/4e7fefcc4923f9e083d5324dc75a7d2f906af77f/docs/evidence/rtx4090-pr1-matched/README.md) used one `10de:2684` GPU, Linux `7.2.11-arch1-1`, NVIDIA `615.78.08`, CUDA `13.4.92` and a 450 W limit. Recalculating all three stages of its GEMM JSONL from the five recorded timing samples reproduced the reported medians. The original pair's 8192-square gains were +11.99% FP16/FP32 and +15.97% BF16/FP32. After an ordinary warm reboot, the 4096-square BF16 result was 8.21% below that same stock baseline. The instruction probe retained approximately doubled FP32-accumulating Tensor throughput, with stable FP16-accumulating, integer and scalar controls. These are separate hardware/software conditions and different matrix inputs from this experiment; their percentages are not pooled.

The regular-4090 parent and warm-reboot manifests contain 26 entries: 25 match the exact published bytes. The exception is `warm-reboot-repeat/telemetry.csv`: its published LF bytes fail the recorded hash, while conversion to CRLF matches it. GitHub's contents API and the pinned source archive returned identical LF bytes. This identifies a line-ending mismatch in that manifest entry; strict checksum verification of the complete upstream set therefore fails. The GEMM, numerical, MMA and tensor-mode result files all pass their recorded hashes. These upstream files are linked rather than redistributed in this archive.

The [4090 D contributor report](https://github.com/JustAResearcher/gpu-unlock-ada/pull/7#issuecomment-6390126655) describes one card's roughly 148 → 296 TFLOPS result, followed by successful warm-reboot unlocking and numerical checks on eight cards. It also reports about 11% less ComfyUI time and pixel-identical outputs. No raw logs accompany that comment, so it is corroborating reported evidence rather than an independently recalculated dataset.

Later code also adds loaded-firmware hashing before DMA, seeded multi-shape numerical cases, strict full-transaction host testing and MMA repetition-storage/argument fixes. This cross-check inspected those changes without rerunning the newer module on the RTX 4090 D. The original MMA run used three repetitions, whose printed values fit the earlier fixed buffer. Inference remains the separately measured Strata result above; neither community report establishes a controlled locked/unlocked Strata comparison.

## Boot and recovery scope

The tested module was loaded before NVIDIA from an independent initramfs, selected through a dedicated EFI entry using one-shot `BootNext`. Two normal reboots into that entry succeeded. The second restored Strata automatically after removal of the first run's `systemd.mask=strata.service` kernel parameter. The default boot order was preserved; automatic unlock on the default path was not configured.

Before selecting any entry, inspect `efibootmgr -v` and match its actual label and number. To cancel a pending test selection, use `efibootmgr --delete-bootnext` and read back the result. A normal boot then follows the preserved default order. Restoring the original boot path must be followed by rate readback; a power cycle may be required to establish the reset state. Neither a rollback reboot nor a power-cycle validation was performed in this experiment. The EFI image and module were tied to the pinned kernel. No long-duration stability or energy-efficiency claim is made.