RTX 4070 Ti SUPER + MSI B650M + Ryzen 7 9700X (Win11): 1.69x BF16 measured, 2.0-2.2x end-to-end on a real 3D-generation pipeline

[CYXyouzhi]

RTX 4070 Ti SUPER + MSI B650M + Ryzen 7 9700X (Win11): 1.69× BF16 measured, 2.0–2.2× end-to-end on a real 3D-generation pipeline

Status: working, reproducible, no VBIOS flash. Unlock survives reboots-from-UEFI; every cold boot through the U-disk transaction keeps it. Power settled at the stock 285 W limit with no thermal ceiling hit.

Posting because the compatibility matrix has thin Ada 4070-class coverage and because synthetic microbenchmarks undersell what this does to a real multi-stage generative workload — the pipeline I run got 2.0–2.2× wall-clock, not 1.7×.

---

TL;DR

Metric	Before	After	Gain
BF16 matmul (8192³)	~88 TFLOPS (spec)	149.1 TFLOPS	1.69×
FP16 matmul (8192³)	~88 TFLOPS (spec)	140.0 TFLOPS	1.59×
FP32 matmul (8192³)	27.4 TFLOPS	27.4 TFLOPS	1.00× (expected — no PLM effect on non-tensor)
UltraShape 512 refine (reconstruction net)	27 min 24 s	13 min 36 s	2.01×
UltraTex 4K / 18 views (texture baking)	~20 min	13 min 39 s	1.46×
Full asset pipeline (geometry → refine → UV → texture)	~55 min	~25 min	2.0–2.2×
GPU power draw under load	—	285 W (100 % of stock limit)	—
GPU temp under load	—	71–76 °C (throttle gate 83 °C)	—

The interesting part: the pipeline gain exceeds the BF16 matmul gain. Reason below.

---

Hardware

Part	Detail
GPU	NVIDIA GeForce RTX 4070 Ti SUPER, 16376 MiB
VBIOS	95.03.45.40.cb (stock, unflashed)
Driver	616.92 (Windows)
PCIe	Gen 4 ×16 (pcie.link.gen.max 4, width.max 16)
Power limit	285 W (max 285 W — default already at ceiling)
Max clocks	Graphics 3105 MHz, Memory 10501 MHz
CPU	AMD Ryzen 7 9700X, 8C/16T
Board	MSI MAG B650M MORTAR WIFI (MS-7D76)
RAM	32 GB DDR5
OS	Windows 11 Pro, build 28000
Tool version	nv-uefi-unlocker 2.1.8 / 2.1.9

Ada AD103, major.minor = 8.9. No GSP registry prerequisite needed (that's Turing-only).

---

Unlock procedure — what actually mattered

The happy path is make-usbroot.ps1 → boot from the FAT32 USB → let it run → it hands off to Windows automatically. The friction was all in preconditions:

1. Secure Boot must be off (or self-sign the EFI). On the MSI B650M this is under Settings → Security → Secure Boot. Forgetting it gives a boot loop with no useful error.
2. Boot overrides are firmware-enumerated only. Do not try to create a Windows Boot Loader entry pointing at a drive letter — it silently won't appear in {fwbootmgr}. F12 one-shot boot menu is the reliable path on this board.
3. USB must be FAT32. A 64 GB exFAT stick was rejected outright by the maker's check.
4. Antivirus kernel filter drivers break ssdiag. If you get MAP_PHYS win32 error 5, the tool now prints a pre-flight gate list (HVCI runtime / kernel AV filter driver / driver load refused). Suspending AV protection is not enough — its kernel hook stays loaded. Desktop machine here had no AV conflict, but this was the single most-reported failure mode in the issues.
5. Sleep clears it. S3 and S0ix both drop the GPU rail, and the selector gets re-derived to factory on wake. On desktop, either disable modern standby or accept re-running the transaction. For Ampere/Ada specifically, if the FEAT gate stays open but SS reverts, ssdiag --reapply rewrites SS0/SS1 without the whole U-disk dance — worth trying before a full re-run.

Certification path that worked: UEFI pre-driver run → automatic handoff to Windows → verify with nvidia-smi (no Code 43, no TDR) → benchmark. No black screens, no resets, single attempt.

---

Synthetic benchmarks

Measured with torch.matmul on 8192×8192 tensors, warm-up ×3, 20 iterations averaged, torch.cuda.synchronize() around the loop. RTX 4070 Ti SUPER stock spec is ~44.1 TFLOPS FP32 and ~88 TFLOPS dense BF16/FP16 tensor.

float32    27.4 TFLOPS
bfloat16  149.1 TFLOPS   ← 1.69× over the 88 TFLOPS dense spec
float16   140.0 TFLOPS   ← 1.59× over spec

Two notes for anyone reproducing:

• FP32 shows no gain, and that's correct. PLM affects the tensor-core datapath, not the CUDA-core FP32 path. A "no change on FP32" result is a sanity check, not a failure.
• BF16 > FP16 here. Worth reporting: the driver stacks report BF16 ahead of FP16 on Ada. If you only benchmark FP16 you'll under-report the unlock by ~6 %.

---

Real-world workload — and why the gain is >2×

This box runs a local image → 3D game-asset pipeline in ComfyUI (Trellis2 geometry backbone → UltraShape refinement → pymeshlab/xatlas remesh+unwrap → UltraTex 4K PBR baking). These are all diffusion/transformer inference at BF16.

Stage	Workload	Before	After	Gain
Geometry	Trellis2 2K + quad reconstruct	—	—	(not separately timed)
Refine	UltraShape, 512 res, 50 steps	27:24	13:36	2.01×
Remesh/UV	pymeshlab + xatlas + Blender	seconds	seconds	CPU-bound, N/A
Texture	UltraTex 4K, 18 views	~20:00	13:39	1.46×

Two mechanisms explain the >1.7× numbers:

1. The workload is a long chain of small attention/GEMM ops, not one big matmul. A large fraction of each step is memory-bound rather than compute-bound, and the unlocked tensor path shortens the dependency chains between them, so latency per step drops more than raw throughput suggests.
2. Bigger effective batch per unit time → less idle GPU during host-side Python/VAE/texture stages, so the wall-clock ratio is worse than the FLOPs ratio would predict... except here it's better, which means the idle-gap savings dominate. Concretely: at 27 min/step-phase the GPU sat idle waiting on host code a noticeable fraction of the time; at 13 min the same host overhead is a much smaller share.

Caveat worth stating plainly: I only measured BF16 inference. FP8 paths (some nodes here can use them) report ~2.0× on other Ada cards; I didn't isolate FP8 because the pipeline doesn't use it end-to-end.

---

Thermals & power

Under full pipeline load:
  power.draw       285 W   (100 % of stock limit — the card is power-limited, not thermally limited)
  temperature.gpu  71–76 °C  (throttle gate 83 °C)
  PSU load         ~58 %

This is the part that surprised me. Doubling tensor throughput at a fixed 285 W power ceiling means the card got roughly 2× more work done for the same energy — i.e. the unlock is not "overclocking harder," it's removing a rate limiter while power draw stays pinned at the same wall. Temps rose by only a few degrees because the limit is wattage, not clocks.

If your card is thermally limited rather than power limited (small dual-fan AIB models), expect the gain to compress. On a 285 W-capped triple-slot model it doesn't.

---

Gotchas / small things that cost time

• ssdiag needs an elevated prompt. A non-admin shell gives OpenSCManager failed: win32 5. Easy to misread as "unlock broke."
• Verify with a matmul, not with a UI number. nvidia-smi clocks look normal either way; only the tensor throughput actually changes.
• BF16, not FP16, for the headline number on Ada.
• The gain is per-precision-path. Tools that fall back to FP32 (some post-processing, most mesh/CPU stages) see zero gain and will drag your end-to-end ratio down. Isolate GPU stages when reporting.

---

Verification one-liner

import torch, time
a = torch.randn(8192, 8192, device='cuda', dtype=torch.bfloat16)
b = torch.randn(8192, 8192, device='cuda', dtype=torch.bfloat16)
for _ in range(3): a @ b
torch.cuda.synchronize(); t = time.time()
for _ in range(20): a @ b
torch.cuda.synchronize()
print(20 * 2 * 8192**3 / (time.time() - t) / 1e12, 'TFLOPS')
# stock ~88 · unlocked 140–150 on this card

Thanks to the author — this turned a 55-minute iteration loop into 25 minutes, which is the difference between "prototype twice a day" and "prototype six times a day" for anyone doing local generative 3D work.

[physicsdolphin]

@CYXyouzhi Thank you for this one — it's recorded in three places now: the compat matrix 2705 row (AM5/B650M data point, quoted your 285 W analysis verbatim: "removing a rate limiter, not overclocking" is exactly our framing), the community-reports table, and — where your report did the most work — two doc upgrades:

1. Your "BF16 > FP16 on Ada" observation is now anchored to the per-precision forensics. Across the three independent 2684 datasets (#69 both reporters + #80), TF32 is the only directly measured clamp (ships ×0.5, releases to full rate); the FP16/BF16·FP32acc cuBLAS rows are library routing — they track ≡ the FP8 row ÷ 2 across all datasets, which is why your FP16 (1.59×) trailed BF16 (1.69×). BF16-as-headline on Ada is the right call and is now the documented convention (theoretical-uplift §5/§7).

2. Your end-to-end > microbenchmark case closes a two-sided question. A 3060/X99 report in D#131 independently derived the lower bound shape (end-to-end 1.43× < tensor 1.79×, via an Amdahl inversion putting ~68% of sampling time in matmul/attention). Your case is the upper bound (2.0–2.2× > 1.69×, idle-gap + dependency-chain mechanisms). The pair is now a documented note — the end-to-end/microbenchmark ratio is bidirectional, and Amdahl share decides the direction. Your two-mechanism explanation matched ours, so we adopted it as-is.

3. The AV kernel-filter note went straight to work. It's the third same-shape observation for #118 (MAP_PHYS win32 error 5), and your "suspending AV protection is not enough — the kernel hook stays loaded" nuance is now part of the cure guidance there (the second case was cured by uninstalling Kaspersky, matching your observation). The standing reference for why that kernel-driver gate exists: FAQ · pmxdrv.sys security model.

One sharpening your S3/S0ix + --reapply note motivated: the FAQ sleep section now states explicitly that S4/whole-power-removal paths always lock the gate (the AON island doesn't survive power loss), so --reapply will answer REFUSED: gate closed — correct verdict, not a tool failure; only a USB re-run recovers. The --reapply path applies to the gate-open SS-reverted shape (your case).

FP32 flat at 27.4 was the control we'd expect — it's the sanity check that separates "rate limiter removed" from "clocks bumped", and your report already treated it that way. Good box, good writeup.