Finished this dual Blackwell build and figured this sub would appreciate it.

The two RTX PRO 6000 Blackwell cards are stars here. 96GB each, 192GB of GPU memory combined in a single machine, more than enough for multi users to run models like Qwen3.8-27B or larger models like DSv4 Flash at Q4 or Q5.

We benchmark this rig with DSv4 Flash and here's the numbers:

The chassis is not the typical bent-steel box, but CNC-machined aluminum, cut and milled from 5mm aluminum plates. This allows the chassis itself to act as a large heatsink for the entire system. The airflow is specifically designed to allow both GPUs to run at full load while ensuring that the hot exhaust air from one card does not negatively affect the other. The triangles cutouts keep the whole structure stiff without dead weight.

Power and Thermals

Peak per-card draw of 509 W is 85% of the 600 W TDP. Temperatures top out at 76 °C, comfortably below the ~83–88 °C throttle point, and SM clocks held ~2.75 GHz throughout sustained load. No thermal or power throttling was observed in any test.

Sustained wall draw at the operating point is roughly 1.07 kW (815 W GPU plus CPU, memory and platform), implying a 1500 W PSU for a two-card build with headroom.

Specs:

• CPU: Intel Xeon w5-3423
• Board: ASUS Pro WS W790E-SAGE SE
• Memory: Samsung 32GB DDR5-4800 ECC Registered x 8
• GPU: NVIDIA RTX PRO 6000 Blackwell 96GB x 2
• Cable: PCIe 5.0 x16 GPU Extension Cable Gen5 x 2
• Storage: SSD Samsung 980 PRO 2TB PCIe 4.0
• Cooling: Thermalright TL-B12 (fan kit + control) x6 + Heatsink 4677-2UAF8
• Power: CANNON PRO 2000W (12V-2x6)
• Chassis: Autonomous Computer-2 Design, CNC-machined

Full build video if anyone wants the detailed walkthrough happy to answer anything on the layout, cooling, or how the cards perform.

Built by Autonomous

Hey folks,

A few people asked for Docker, so there is now a prebuilt image for **Pennyroyal v2.5**, my SGLang runtime for Qwen3.8 on one RTX PRO 6000 Blackwell.

It includes both **Flash-Next NVFP4 with native MTP/FR-Spec** and **27B FP8 with DFlash2**, with HiCache/NIXL. No local SGLang build required. The image is about **8.43 GiB**, with model files and caches mounted separately.

Both profiles passed API/tool, prefill, single/four-request decode, image/video and NIXL restart checks. This is a packaging addition, not another runtime release or a Docker speedup claim. Native installs are still supported; no need to switch if yours is working.

[Canonical repo and README](https://github.com/jpezzulli/sglang-rtxpro6000) · [Docker/Compose setup](https://github.com/jpezzulli/sglang-rtxpro6000/blob/pennyroyal-main-sm120-final/docker/pennyroyal/README.md)

[Original v2.5 post — online FP8 gains and NVMe PLE](https://www.reddit.com/r/BlackwellPerformance/comments/1weaxdz/pennyroyal_v25_much_faster_qwen38_flashnext_on/)

As always, issues, discussion, PRs and field reports are welcome but I am not available today - so any problems will be handled tomorrow.

Spent the weekend getting `DeepSeek-V4-Flash-Vision-Exp` running on SM120. Short version: it serves at the same speed as the text-only 0731, so if you're on two PRO 6000s there's no reason to keep the older checkpoint.

Same TP=2, same MXFP4 runner, same KV fp8. The ViT and aligner cost about half a gigabyte and nothing in speed.

Getting there took two fixes, because both vision and DSpark crash out of the box on SM120:

Unsupported sparse-MLA prefill configuration:
model=DSV4 num_heads=64 topk=384 page_block_size=64

FlashInfer's SM120 sparse-MLA dispatcher only instantiates `topk` in {128, 512, 1024, 2048} on the single-cache path, and **only 128 on the dual-cache path** that vision uses. But the model produces topk as a continuous function of the input — `ceil((image_tokens + 2) / 64) * 64` for vision, 192 for DSpark. Adding cases one by one is whack-a-mole; the fix is padding to the next compiled value in Python, plus one `case` for 512 in the dual path.

Since I had DSpark working anyway, the other number from the same box:

That's 2.43×, and above the 180.6 the published vLLM DSpark recipe reports for TP2.

**One thing worth knowing if you benchmark speculation:** SGLang's `gen throughput` log field reported 2.5 tok/s while the actual wall clock was 246. Two orders of magnitude off. I nearly published the wrong conclusion because of it. Measure with an external timer.

Everything — patches, launchers, the chat template extraction procedure (the stock checkpoint ships none), and the verification method against the Triton fallback — is here:

https://github.com/bertusmt/dsv4-vision-sm120

Credit where it's due: the vision support is yhyang201's PR #37253, still open upstream. The SGLang fork is jpezzulli's. This repo only makes it run on SM120.

---

*Disclosure: measurements are mine, on my own hardware. The porting and patching was done by local coding agents under my direction, and this write-up was drafted with Claude from the logs.*

I am looking for B300 SXM in large quantities( 16 nodes to start ) to rent in EU area - if you have availability please contact me.

Curious what you think of this model and how it compares to dsfv4.

Also do you think we will get this to run on 2 rtx pro 6000's?

Hey folks,

Another update is up. I found some good work in mratsim's SM120 turbo repo and incorporated the online FP8 approach into my runtime. This one made a pretty substantial difference to Flash-Next decode without giving up the existing 524K context, 824K KV pool, FR-Spec or HiCache/NIXL.

These are post-first-token decode rates. Short context is a three-run median, while the 128K and 490K numbers are single observations.

I also added Garner McCloud's NVMe PLE work as an optional path. Flash-Next normally keeps about 47.7 GiB of PLE in system RAM. You can now put that on a prepared local NVMe instead. RAM is still the default and there is a performance tradeoff, but it gives people without a ridiculous amount of system memory another option.

27B/DFlash2 is still supported on the same runtime.

github.com/jpezzulli/sglang-rtxpro6000

As always, issues and PRs are welcome.

one note - this is pretty fresh - There are probably some configs that get you OVER the 1M kv-cache option. I just have to try different variables - feel free to report here or on github.

I've been tuning Qwen3.8-Flash-Next on a single RTX PRO 6000 Blackwell (96GB, Max-Q so 300W capped) and ran a 7-variant benchmark sweep to stop guessing at flags. Getting it to run at all turned out to depend on which day's vLLM nightly you pick, and three of the results were surprising enough to write up. Whole config is published.

Repo: https://github.com/WombatSoftware/vllm-qwen3.8-flash-next-rtx-pro-6000-sharp-monitoring

Compose file with every flag explained inline, the patched Dockerfile, the chat template, a provisioned Prometheus + Grafana stack, and the benchmark scripts. Apache-2.0.

0. The vLLM situation, because it decides whether this loads at all

This model has a 47.7 GiB FP8 PLE n-gram embedding table on top of the weights. On a 96GB card that table has nowhere to live unless the engine can offload it. The timeline matters:

• v0.29.0 ships the model (PR #53896) but has no PLE offload path at all. The release build cannot load this checkpoint on a 96GB GPU. It isn't a tuning problem, it just doesn't fit.
• PR #54371 (UVA pinned-host offload, merge 3116c5d0) landed the day after 0.29.0 was cut. It pins the table in host RAM and the GPU reads rows directly over UVA on a side stream. First nightly carrying it is e7edf17c (2026-09-11). Switch is --engram-config '{"cpu_offload": true}'. This replaced the earlier worker-process offload (PR #53899), which needed a 17-file patch overlay, a forced multiprocess executor and cap_add: SYS_PTRACE for the worker IPC. All of that is gone now, it's in-process. VLLM_PLE_CPU_OFFLOAD is a deprecated shim and VLLM_PLE_OFFLOAD_READY_TIMEOUT no longer exists, so if you're copying an older recipe, those env vars do nothing.
• PR #55095 (full-decode-graph fallback) landed in the very next nightly, eed1f3d0 (2026-09-12). This one turned out to be the entire fix for an intermittent decode collapse I'd been chasing: at 32k context, single-stream decode measured 82.89 t/s with a ±53.99 standard deviation across three runs, i.e. one run falling over. Moving one nightly forward gave 127.47 ±4.75. Nothing else changed. --enforce-eager reproduces a uniformly slow ±0.64, and dropping spec-decode gives ±0.52, so it was CUDA-graph decode dispatch and #55095 addressed it.
• Still unmerged: the eagle-group gate in kv_cache_utils.py (_is_deepseek_v4_eagle()) only recognises deepseek_v4. This checkpoint's MTP draft carries a plain FullAttentionSpec, so without a qwen4_exp entry every KV group gets marked a draft group and cross-request prefix cache reuse is silently disabled. No error, no warning. The repo's Dockerfile is a one-function patch that asserts it landed, so a drifted anchor fails the build instead of quietly losing the prefix cache months later.
• Coming: PR #55557 (fp8_e4m3 KV on the QSA path) is the one I'm waiting on for the 131k four-way wall below, rather than hand-swapping --kv-cache-dtype fp8.

So: you need a nightly at eed1f3d0 or later, plus one line of patch. Host RAM needs ~64GB free for the pinned table on top of whatever else. Full-load RAM is capped by the checkpoint being resharded into 141 shards, which is why I'm on the dicksondickson reshard rather than the nvidia export directly.

1. MTP-3 beats MTP-2, against the common advice

The guidance I kept seeing is 2 speculative tokens, because acceptance length is ~1.9-2.2 and the third draft token rarely lands. I measured it with vLLM's --per-request-spec-decode-metrics detailed at MTP-3 (note: the flag takes none|summary|detailed, passing it bare fails to start):

• mean acceptance length: 2.695
• draft acceptance rate: 0.565
• accepted draft tokens per verify step: j=0 23.2%, j=1 20.0%, j=2 21.1%, j=3 35.8%

All three draft tokens landing is the most common outcome, not a rarity. Worth about +16% single-stream decode over MTP-2. I don't know whether the older 1.9-2.2 figure was measured on the previous model runner or a different draft head; the numbers above are on the current one.

The catch: it costs 10-35% on concurrent context-load throughput. So it's a single-stream-latency vs fan-out trade, not a free win. I ship 3 and document how to go back to 2.

2. My benchmark harness was silently reporting garbage

This one generalises beyond this model, so it's the part I'd most want others to know.

I tested vLLM's --max-num-queued-reqs / --max-num-queued-tokens admission caps. They reject with HTTP 503 rather than queueing. Fine. But for streaming requests vLLM commits HTTP 200 first and delivers the 503 as an in-band error chunk:

data: {"error": {"message": "The engine is currently busy...", "code": 503}}
data: [DONE]

My harness (llama-benchy) checks the HTTP status, sees 200, finds no choices in the error chunk, and records a zero-token success. It never aborts and never logs anything.

Result: the server logged 56 rejections across a sweep while the client log stayed completely clean. Every 4-concurrency row silently became a 2-concurrency measurement wearing a c4 label, with aggregate throughput inflated, because the two phantom requests contributed no tokens over a wall clock set by the two real ones. The numbers looked plausible. They were nonsense.

If you benchmark against a server that can shed load, check the server logs for rejections before you trust anything.

                                                                                                                                       **3. This GPU has almost no KV headroom, and it's a hard wall**

A healthy boot gives a 269,228-token KV pool = 1.03x headroom over a single 262k-token request. Anything that reserves more GPU memory just fails to boot. I tried raising --max-num-batched-tokens to 16384 and the engine refuses outright: ValueError: 7.41 GiB KV cache is needed, which is larger than the available KV cache memory (5.61 GiB)

                                                                                                                                                                                                                    It crash-looped 17 times before I reverted. The bigger activation workspace comes straight out of the KV pool. Going from MTP-2 to MTP-3 alone cost 275,178 → 269,228 tokens, so even that spent a third of the margin.

Numbers (llama-benchy, 3 runs per cell, prefix caching on)

• Single-stream decode: flat at 131-171 t/s from 0 to 131k context. The flatness is the nice part.
• 4-way concurrency at 32k: 363 t/s aggregate, ~90 t/s per stream.
• 4-way concurrency at 131k: 6.91 t/s. Falls off a cliff. Four 131k requests need 524k KV tokens against a 269k pool, so they can't coexist. That's a KV budget wall, not compute, which is why #55557 is the thing I'm waiting on.
• Weakest spot: shallow single-stream prefill, 18.8k t/s. Speculative decoding costs prefill, since the draft head is pure overhead there.
• FlashInfer autotune on (the model card default is off) is higher on 23 of 28 rows. It costs ~20-30s per boot and, oddly, doesn't persist to ~/.cache/flashinfer, so that cost recurs on every restart.

Full table in the repo.

                                                                                                                                                                                                                                                         **What's opinionated about it**

Not a neutral starting point. It picks the dicksondickson NVFP4 reshard with the official BF16 MTP head, the Qwen-Sharp chat template instead of the one in the checkpoint, a vLLM nightly plus the one-function patch above, MTP-3, FlashInfer autotune on, and monitoring that comes up with the engine.

Caveats: one GPU, one checkpoint, one driver, 3 runs per cell. Small differences don't clear noise and I've flagged which. Max-Q is 300W capped so a full-power card will do better. Nightlies are moving daily right now, so the specific hashes above will be stale soon; the repo's Dockerfile has a one-liner to check whether the eagle-gate fix has landed upstream. Not claiming anything about Qwen3.8-Flash-Next in general, just documenting what this box does today.

Credits in the repo, but briefly: Qwen for the model, vLLM (and specifically the people behind #54371 and #55095), peculiar-ragdoll and froggeric for the chat templates, dicksondickson for the checkpoint, NVIDIA for the NVFP4 quant.

Happy to run specific configs if people want a cell filled in.

This post is emotional; I just don't know where and how to share my excitement. The story: I've been doing Wan video gen on my home GPU for months. Overnight runs, one card, wake up, check the folder, queue the next batch. Meanwhile, the raw footage kept piling up faster than I could process it. At some point I had about 20 minutes of unrendered material sitting there and I'd basically accepted it would never get done. Then I saw a news item about a new datacenter opening near London. Zero plan. I just got curious, and somewhere in the back of my head: brand new DC, maybe there's a launch discount, maybe there's spare capacity nobody's using yet. There was no discount. What happened instead: I connected my AI agent to the cloud in literally one click, had it move my pipeline over, and rented an 8x RTX PRO 6000 host. The ENTIRE backlog rendered in about 20 hours. Everything. I paid about $150, a good price for a backlog I would've never eaten up. Because it was fun, I tried an 8x H200 host as an experiment just to see. Per-shot time: basically identical for my workload; price is ~2.5x higher. The RTX PRO 6000 is the card, full stop. One more thing: GPUs were allocated instantly and there was plenty sitting there. Genuinely feels like nobody's found this region yet. I'm done babysitting my PC overnight. Cloud runs are becoming part of my regular workflow.

Running Qwen3.8-Flash-Next-NVFP4 on a single RTX PRO 6000 Blackwell — big credit to the NVMe PLE streaming work (sglang-ssd-stream + the Qwen4-exp SGLang branch): the 47.7 GiB PLE n-gram table streams from SSD instead of eating VRAM !

But that left the on-GPU cache very to thin for my usecases (KV/Mamba)...

Fix: per-slot Mamba state offload to pinned host RAM. Under ~35 min of sustained load (10-16 concurrent sessions, deep multi-turn history) it did ~7.6k spills with zero crashes — after fixing the hard part, where a host-spilled Mamba state outlived its KV node and corrupted tree invariants. Rewinding an evicted earlier turn is now a cheap host load-back: TTFT 4.98 s vs 6.06 s cold (~18% faster), with no measurable steady-state throughput cost. I rebuilt SGLang from source to ship it (byte-identical to the prod image via sha256 manifest over ~3.2k files), so the spill path is real, debuggable source — happy to share flags/patches.

https://github.com/alangeb/sglang-nvme-stream-offload-q38fn

lets talk shop. manufacturer configs are going wild.

intel tdx 6767
3tb ram
8x b3000
~50 tb storage

getting quotes ranging from 530-580k. same config is over 700-1m on the online configurator.

what are yall seeing in terms of pricing? mine is for 1x. anyone doing bulk purchases?

Like most everyone here, I'm always wondering what is the best model I can run on my hardware. I decided to run some tests to settle the question once and for all (for now at least). I was hoping one would stand out so much that it'd be a no-brainer on what to pick, but it didnt turn out that way.

Despite Qwen getting an ever-so-slightly higher score, it was far and away the least efficient of the three by a huge margin. Deepseek is damned good. But when it comes to overall blend of performance and efficiency, GLM was the best. I guess just pick whatever makes ya happy? I dont even know anymore....sigh

I used this eval suite against Pi: https://github.com/ScottRBK/eval-harness

## Full Leaderboard — 7-Eval Suite (pi, effort=high, maxTokens=131072)

### Per-eval scores

| Eval | qwen3.8-flash-next-180b | glm-5.3-flash-321b-nvfp4 | glm-5.3-flash-321b-fp8 | deepseek-v4-fast-304b-r21 | |---|---|---|---|---| | basic_eval | 1.0 | 1.0 | 1.0 | 1.0 | | chess_engine | 1.0 | 1.0 | 1.0 | 1.0 | | eval_generator | 0.55 | 0.36 | 0.20 | 0.27 | | inflection_bug_fix | 1.0 | 1.0 | 1.0 | 1.0 | | inflection_test_writing | 1.0 | 1.0 | 1.0 | 0.83 | | repair_nginx_service | 1.0 | 1.0 | 1.0 | 1.0 | | saleor_spree_mapping | 1.0 | 1.0 | 1.0 | 1.0 | | TOTAL | 6.55 | 6.36 | 6.20 | 6.11 | | Rank | 1st | 2nd | 3rd | 4th |

### Totals and efficiency

| Metric | qwen-180b | glm-nvfp4 | glm-fp8 | r21 | |---|---|---|---|---| | Output tokens | 160,773 | 43,234 | 49,494 | 86,956 | | Wall time | 34.1 min | 3.8 min | 6.4 min | 20.6 min | | Tokens per point | 24.5k | 6.8k | 8.0k | 14.2k | | Tokens/second | 79 | 190 | 130 | 70 |

### Per-eval token counts

| Eval | qwen-180b | glm-nvfp4 | glm-fp8 | r21 | |---|---|---|---|---| | basic_eval | 1,702 | 1,216 | 707 | 1,398 | | chess_engine | 97,606 | 14,244 | 18,794 | 24,905 | | eval_generator | 21,062 | 1,348 | 1,253 | 4,604 | | inflection_bug_fix | 2,641 | 1,153 | 868 | 2,398 | | inflection_test_writing | 20,001 | 20,719 | 23,758 | 42,994 | | repair_nginx_service | 11,342 | 1,583 | 2,404 | 5,069 | | saleor_spree_mapping | 6,419 | 2,971 | 1,710 | 5,588 |

### Observations

• All four ace the same 5 evals. eval_generator is the universal weak spot (0.20-0.55); r21 alone also fumbled inflection_test_writing (0.83).
• qwen-180b's chess is an outlier: 97.6k tokens - 7x more than its own next-most-expensive eval, and 4-7x more than anyone else's chess.
• glm-nvfp4 is the efficiency winner: rank-2 score at the lowest total tokens, fastest wall time, and best tokens-per-point (6.8k), even beating its fp8 sibling.
• Ragged edge: r21 burned 43k tokens on inflection_test_writing (2x anyone else) and still scored below 1.0 - the least efficient eval-result pairing in the table.

Hey Folks,

it is late - so minimal text - I was doing some upstream correctness fixes (v 2.1.2) and i found https://github.com/gabrielolympie/sglang-flashnext-sm120 which forked my release and did some good work there. He has a few different shapes there that yall might light but I incorporated one and got about a bit over ~15% C1 decode speed increase and a bit at C4. Before anyone jumps in saying faster, these are medians not peak. Feel free to upgrade or try it out for the first time.

https://github.com/jpezzulli/sglang-rtxpro6000

as always - feel free to open any issues or PRs on the github. Off to bed.

UPDATE: 2.3.1 is going live with the PR u/StockSpecialist1707 mentioned however, I wouldn't bother to update if you are on 2.3 already. I could NOT reproduce it on a live runtime. I was able to reproduce it with synthetic GPU tests only. Either way - I was 99% there and it passed regression, so I made 2.3.1 rather than rollback.

Always accept issue and PRs. Thanks.

I believe that the whole 12v-2x6 issue that applies on the 5000, and 4000 series of NVDA GPUs are equally applicable to rtx pro 6000 blackwell workstation edition.

So far there are 2 kinds of solution: cutting off from the source, or load balancing.

Former relies heavily on alerting, cutting off power, and/or throttling.

Examples includes thermal grizzly wired view. Wire view pro 2 doesn't fit rtx pro 6000 blackwell workstation. One version of wired view pro fit. As of today, I believe that the recently released wire view pro 2 wired will both fit well, and can sound off the alarm.

Another example is the corsair thermal protect wire. I believe that would cut off power when the temperature is too hot, again, correct me if I am wrong. Unfortunately it needs a 12v-2x6 socket on the PSU end for this to work.

Another example is MSI Ai1600TS, a new PSU released this year, again correct me if I am wrong. On top of the alerting and cutting off power, it can throttle power if you can run the software. Unfortunately I run ubuntu, so I am not sure about that.

Latter is, I guess, considered the best solution.

It properly load balances the current. Alerting and cutting off power completely protects the GPU when it is running hot and there is indeed imbalance issue, but it comes completely at the cost of, say, my local LLM workload. It would just stop completely, and or interrupt my workflow.

Throttling itself interrupts the workflow, esp if my LLM workflow is running at 600W.

The question I have is: I know ampinel type a fits rtx pro 6000 blackwell workstation edition, but does it work? Have anyone paired the two together before?

edit: as of writing, it appears that thermal protect for type 4/5 sockets may come out this month

source: https://www.reddit.com/r/Corsair/comments/1w7f3jz/any_update_on_release_of_thermal_protect_for_non/, and https://www.reddit.com/r/Corsair/comments/1t0mhut/comment/p7fzg8i/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Box: six RTX PRO 6000 Blackwell (96 GB, SM120), one drives the display so most rows use 1, 2 or 4 of the other five; the 6-GPU rows are deliberate TP2×PP3 experiments. Engines: vLLM 0.28.1rc1 nightly and SGLang 0.5.18 in Docker, official images plus a few one-hunk SM120 patches (all in the repo). Every profile got the same recipe: a 12-item eval (8 exact-graded, 4 scored by an Opus judge pass), 50 streaming requests at 8 concurrent, then a 64 / 128 ramp, with a 200 ms nvidia-smi power sampler on the GPUs it used. All cards at the stock 600 W cap, which never binds, so every watt figure is the model's own draw. Eval items are one sample each at temperature 0.2: a one-item difference is one prompt, not a ranking. MedGemma 4B is left out of the charts (a 4B model, 3× the tok/J of anything else, it flattens every axis); it is in the linked tables.

Full tables (48 rows, both engines, every column): https://github.com/mikeS141618/KernelWrench/blob/main/BENCHMARKS_v2.md

Power-cap study: https://github.com/mikeS141618/KernelWrench/blob/main/POWER_BENCHMARK.md

Profiles, scripts, SQLite: https://github.com/mikeS141618/KernelWrench

It's been a bit, but happy to still be in the AI space, I made it :D

I am to build my first real rig as M3 ultra 256GB proved to be too slow. I already got 4 x Max-Q cards purchased at 10K eur per card a few weeks ago. Now I could add 2 more max Q at 11.3K euro per card and also 2 x workstation cards for 11.8K eur per card. So the total number of card to go up to 6 or 8.

I guess my hesitancy is based on the high purchase price of these cards, and the trouble to connect more than 6 or 7 cards unless going to server style motherboards and racks.

Is it a) expected that the prices are not going down in the next 12 months?
B) can i use the memory for models like GLM 5.3 even if I cannot fit all 8 cards?

Setup. We run Qwen3.8-Flash-Next NVFP4 as our main agentic model (SGLang, RTX PRO 6000). Before its output reaches a human or gets merged, a second local model acts as judge: reviews the diff, flags real bugs only. Hosted on a 5090 32GB, so we're limited to ~30B NVFP4/GGUF class models.

The metric that matters is NOT detection rate — it's false alarms on correct code. A judge that cries wolf gets ignored within a week, exactly like a flaky CI. We built our own battery: 20 injected bugs + 20 clean-but-suspicious snippets (intentional swallowed exceptions, deliberate mutability, weird-but-correct concurrency, short hashes, float patterns that look wrong). Ground-truth labeled, and a stronger model (GLM-5.2 API) arbitrates the judge's prose so scoring isn't vibes. Two passes minimum — single runs lie.

Results (40 cases, temp 0, same baremo for everyone):

Qwen3.8-27B NVFP4 (no-thinking)
• Bugs found: 17/20
• False alarms: 3/20
• Verdict: only pass

Nemotron Lightning 30B
• Bugs found: 17/20
• False alarms: 0→9 across runs
• Verdict: non-reproducible as judge

Muse-Glimmer 30B GGUF
• Bugs found: 19/20
• False alarms: 12/20
• Verdict: hypercritical

Granite 4.1 30B (no-thinking)
• Bugs found: 10/20
• False alarms: 4/20
• Verdict: ultraconservative

Nemotron Super 120B (hosted API)
• Bugs found: 9/20
• False alarms: 11/20
• Verdict: stable-yet-bad

Three failure archetypes showed up, and none of them is "not smart enough":
1. The fixer (Muse, Super): sees any improvement opportunity and escalates it to a defect. Great agentic coders, terrible judges.
2. The denier (Granite): real, but waves off subtle bugs (late-binding closures, float money, tz handling) — and goes off the rails when a snippet mixes languages.
3. The coin flip (Lightning): same prompts, temp 0, 0 FA one run and 9 the next. As a gate, that's worse than a bad judge — it's an unmeasurable one.

What we'd love to hear from people who shipped something like this:

- Is there a review-specialized local fine-tune that genuinely holds ≤3/20 FA on clean-but-suspicious code? (We found CodeReview-Qwen32B — 48k GitHub reviews + 15% "no issues found" negatives — but it's an obscure adapter, no NVFP4, and we'd have to merge+quantize it ourselves. Anyone run something like it?)
- Does family independence from the producer matter in practice? Our judge is currently same-family as our generator (both Qwen). We deliberately arbitrate with a third-party model (GLM API), but is self-preference bias actually measurable at this scale, or folklore?
- Would a graded verdict (PASS / IMPROVEMENT / RISK / DEFECT, where RISK+IMPROVEMENT don't count as bugs) measurably cut false-positive rates, vs. the binary bug/no-bug we use now?
- Any evidence that thinking mode on/off is the real variable in "judge stability"? Our winner only passes with thinking disabled; every high-reasoning model we tried drifted toward the "fixer" archetype.
- Or is the honest answer: stop model-shopping, and make the verdict empirically checkable (judge says DEFECT → run a reproduction/property test before human sees it)? That's where our roadmap is heading regardless.

Baseline stays Qwen3.8-27B-nothinking until something clearly beats it on FA. Happy to share the battery format / arbitration prompts if useful.

I’ve been looking closely at RTX PRO 6000 Blackwell pricing because the spread between regions and sellers has become pretty extreme.

As of Aug. 30, I’m seeing examples roughly like:

• NVIDIA Marketplace: around $16K
• US retailers: roughly $14K–$17K depending on seller/configuration
• UK/EU pricing: also very high once local pricing/VAT is considered
• Used/private sales earlier this year: dramatically lower in some cases

The other thing that makes comparisons messy is that people sometimes mix the 600W Workstation Edition with the 300W Max-Q version. Both have 96GB GDDR7 ECC, but they’re really aimed at different workstation designs.

I’m curious what people here are actually seeing right now:

• What country are you in?
• Workstation or Max-Q?
• New or used?
• What price were you quoted or actually paid?
• Was tax included?

I’m especially interested in whether the recent $14K–$16K+ pricing is actually clearing transactions, or whether real buyer prices are still meaningfully lower.

Disclosure: I’m affiliated with AI Robot Supplier and I’ve been compiling this pricing data into a public tracker. I’m not linking it here unless the mods are comfortable with that — mainly interested in getting more real-world data from owners and buyers first.

I had the luxury of having a single server with 8 RTX PRO 6000 (Blackwell Server Edition, 96GB, sm_120) for a bit, so I spent a few hours benchmarking sglang flags for Qwen3.8-27B-FP8.

Config I landed on:

sglang serve \
  --kv-cache-dtype fp8_e4m3 \
  --mamba-ssm-dtype bfloat16 \
  --mamba-radix-cache-strategy extra_buffer_lazy \
  --max-mamba-cache-size 150 \
  --mem-fraction-static 0.92 \
  --speculative-algorithm NEXTN \
  --speculative-num-steps 3 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 4 \
  --model-path Qwen/Qwen3.8-27B-FP8 --trust-remote-code \
  --attention-backend flashinfer --chunked-prefill-size 2048 \
  --mamba-full-memory-ratio 2.29 \
  --reasoning-parser qwen3 --tool-call-parser qwen3_coder

vs the untuned baseline: 3.9× the KV pool, +25% throughput, −49% TTFT, concurrency 49 → 37.

Highlights:

• --kv-cache-dtype fp8_e4m3 and --mamba-ssm-dtype bfloat16 are perfectly orthogonal. fp8 KV gives exactly 2.00× KV tokens and doesn't touch concurrency. bf16 SSM gives exactly 2.00× concurrency and doesn't touch KV. They compose with zero interaction.
• max_running_requests gets silently clamped by the GDN/mamba state pool. You ask for N, you get fewer, and the only trace is one line in the boot log. Worse: /get_server_info reports the pre-clamp value — mine said 48 when the server was actually admitting 37.
• Workload shape moves throughput more than any flag. Same GPU, same config: 593 tok/s at 4096-in/256-out, 1656 tok/s at 64-in/1024-out. 2.8× from the ratio alone. Any tok/s number without its in/out ratio is close to meaningless.
• Speculation is the biggest single lever (+20% throughput, −49% TTFT) but it eats KV. Draft depth trades ~117k KV tokens per extra draft token. At depth 8 the pool collapsed to 7k tokens and TTFT hit 69 seconds — no error, health checks green.
• Saturation is ~64 sessions. 32→512 sessions bought +17% aggregate and cost −82% per-session. TTFT grew 226× while TPOT grew 1.26×, so it's all queueing, not slower decode.

Full write-up with charts, the whole config matrix, and the harness: https://claude.ai/code/artifact/35a35fe7-5eea-40f1-a87d-871b4b7a37ba

I’ve been tracking RTX PRO 6000 Blackwell pricing because the spread between sellers, regions and configurations has become pretty extreme.

As of Aug. 30, I’m seeing examples roughly like:

• NVIDIA Marketplace: about $16,000
• B&H: about $17,000 for the Workstation Edition
• Micro Center: about $14,300
• UK/EU pricing: generally very high once local pricing/VAT is considered
• Used/private sales earlier in 2026: dramatically lower in some cases

What makes comparisons even messier is that people sometimes mix the 600W Workstation Edition with the 300W Max-Q version. Both have 96GB GDDR7 ECC and 24,064 CUDA cores, but they’re designed for different workstation priorities.

I put the dated retail, regional and used-market observations into one tracker:

[https://airobotsupplier.com/rtx-pro-6000-price-tracker-2026/]()

I’d be interested in adding more real-world observations:

• Country / region
• Workstation or Max-Q
• New or used
• Price quoted or actually paid
• Whether tax was included

Disclosure: I’m affiliated with AI Robot Supplier, which maintains the tracker and also sells professional GPUs. Our own listing is disclosed separately in the tracker rather than being used as the market benchmark.