now I'm insulted...

[ghost]

why we don't have a 4090 club?

[noonghunna]

@Regen-dev — fair, the name is a bit of a 3090-supremacy flex. But for the practical question (will this work on a 4090?) — almost certainly yes, with one caveat:

What carries over to 4090 directly

• Same 24 GB VRAM — every memory budget calculation we ship is identical
• TQ3 KV / Genesis patches / spec-decode / tool calls — all hardware-class agnostic, work identically
• Most of the verify-stress probes — same shapes, same bug surfaces

The one caveat — kernels tuned for SM86

4090 is Ada Lovelace SM 8.9, 3090 is Ampere consumer SM 8.6. Our shipped configs include:

• PN26b sparse-V Triton kernel with BLOCK_KV=8 num_warps=4 threshold=0.01 — 27B-tuned for SM86. Will run on SM89 but probably not at peak; Sander's PROD A5000 (also SM86) tuning is close to 4090 SM89, but exact optimal block sizes may differ.
• PN12 / PN17 / PN30 — generic Python text-patches, no SM-specific code
• No FA3/FA4 path in our composes (Hopper-only). 4090 can run FA3 but vLLM doesn't auto-enable it on SM89; that's an upstream vLLM optimization we haven't pursued because it's irrelevant to our 3090 target

Practical answer

It should boot and work. Performance probably within ±5% of 3090 numbers. If anyone with a 4090 wants to run verify-stress.sh and post results, we'll happily add a 4090 row to the docs and rename club-3090 to something more inclusive (only half-joking).

Alternative we've considered: a club-ampere umbrella that covers 3090 / A5000 / 3080-modded / A4000 (all SM86), with 4090 / 4080 / A4500 / etc. as a sister club-ada repo when someone wants to build it. The architectural fork is real — SM86 needs PN26b sparse-V (we shipped the first one); SM89 doesn't (FA3 covers it).

For now, give it a shot:

git clone https://github.com/noonghunna/club-3090
cd club-3090
bash scripts/setup.sh qwen3.6-27b
bash scripts/launch.sh    # interactive wizard

If you hit anything that doesn't transfer cleanly, open an issue. 4090-specific data points we don't have are exactly the kind of thing that justifies expanding this beyond the 3090 family.

[Sandermage]

The reality is much more straightforward for me... I currently only have A5000 cards available, which is why I built my project around them.

Since GPU prices have skyrocketed, I have neither the desire nor the budget to buy them at 5x their actual value. That’s why my focus has been entirely on the Ampere architecture — to squeeze the absolute maximum out of it.

Adding patches and optimizations for Ada and Blackwell isn't a problem. The main issue is simply that I don't have that hardware. Once I actually get my hands on those cards, I'll be able to move beyond theory. Through practical testing and debugging, I'll be able to identify all the inaccuracies and bugs specific to those generations and make the patch much more universal

[clort81]

You are a legit hero to me.

[noonghunna]

@Sandermage — thank you. That framing is exactly the reality of small-team open-source kernel work, and worth saying out loud.

A5000-only, no budget to chase 5×-overpriced cards, full focus on squeezing the absolute maximum out of Ampere — that's not a limitation, it's the discipline that makes this stack actually exist. The SM86 (Ampere consumer + workstation) class is the largest still-affordable, still-getting-cards-into-hands tier in 2026. PN26b sparse-V is the first sparse-V kernel for SM86 in any public tree. That happened because you focused.

The cross-rig data we got just this week, on the back of that focus

In the last 48 hours alone, on the back of the v7.66 announcement:

• @Whamp #25 — 4× 3090 PCIe (will unlock TP=4 testing for Cliff 2 single-prompt 100K+, MoE-class 235B, ~8× concurrent KV)
• @troymroberts #26 — 2× modded 3080 20GB (40 GB combined SM86, first publicly-tested config in this VRAM class)
• @JusefPol #29 — 2× 3090 with NVLink, posted +57% TPS over our PCIe baseline (107 narr / 138 code). First clean NVLink data point we have, with concrete config diff.
• @Regen-dev (this thread) — 4090 (SM89 Ada Lovelace)

Without owning any of that hardware, you've shipped patches that all 4 of these users are validating within days of pulling. That's the cross-rig contribution loop working as intended.

The ask — more volunteers, more hardware classes

For anyone reading this thread who has hardware we haven't characterized, we want your data:

SM86 family (where Genesis is most mature):

• 1× / 2× / 4× 3090 (PCIe-only OR NVLink — both wanted, our maintainer rig is PCIe-only by choice, JusefPol just opened the NVLink lane)
• 1× / 2× A5000 (Sander's PROD class — but cross-validation from non-Sander rigs is still valuable)
• 1× / 2× A4000 / A4500 (lower VRAM, would tighten our memory-budget docs)
• Modded 3080 20GB (troymroberts is opening this; more would help)
• 3090 Ti (rare but in the wild)

SM89 family (Ada Lovelace) — we want a sister tree:

• 4090 (regen-dev, others — would be the first SM89 sparse-V tuning row)
• 4080 Super / 4070 Ti Super (24/16 GB respectively — different VRAM regimes)
• L40 / L4 (datacenter Ada — would be the first datacenter SM89 row)

SM90+ (Hopper / Blackwell) — niche but valuable:

• H100 / H200 (would surface FA3/FA4 paths we currently don't exercise)
• 5090 / 6000 Ada (whenever someone has one)

What "volunteering" actually means

Low-effort: just run bash scripts/verify-stress.sh after bash scripts/setup.sh qwen3.6-27b and post the results in a discussion. ~15 min. We turn the data into:

• BENCHMARKS.md rows (with credit)
• HARDWARE.md guidance (e.g. NVLink config diffs from JusefPol)
• Genesis bug reports back to Sander when something doesn't transfer

Higher-effort: bench a dual-turbo.yml / dual-dflash.yml variant on your rig, share boot logs + dispatcher matrix, and we'll co-author the per-config tuning row.

Highest-effort: open a PR with a tested compose variant for your topology (dual-nvlink.yml, quad-3090.yml, 4090.yml).

The whole reason this stack ships with the breadth it does — TQ3 KV, MTP K=3, sparse-V SM86, structured-CoT, DFlash, vLLM v0.20 + v0.21 dual-pin, Cliff 1 + Cliff 2 closures — is because Sander writes patches against his A5000 PROD, we cross-validate on 3090, and bugs surface that pure-A5000 testing would never catch (TP=1 worker-spawn registration, single-card prefill cliffs at 50K, NVLink vs PCIe collective paths). More hardware classes = more bugs surfaced = better stack for everyone, including the eventual SM89/SM90 users who haven't shown up yet.

If you have a card we haven't characterized — even if it's "just a 3090 with a different motherboard" — please open a discussion. The cross-rig contribution loop is the model that's making this stack honest, and it scales directly with how many of you opt in.