"Blackwell" Was Never One Compute Capability. Making Sense of NVIDIA's Compute Capability Numbers

"Blackwell" Was Never One Compute Capability. Making Sense of NVIDIA's Compute Capability Numbers

Hello!

If you work with NVIDIA GPUs, you run into numbers like sm_120 and sm_100 all the time. They are called Compute Capability numbers.

They look like they map onto the product generation names. They do not.

What sent us digging was TensorRT-LLM v1.3.0rc28, released on September 23, 2026. The release notes mention "SM107", in the context of support for the next generation, Rubin.

That is where it stops adding up. Blackwell GeForce cards are sm_120. Why would Rubin, the generation after that, get a smaller number like 107?

Once we started checking, it turned out the odd one was not Rubin. "Blackwell" was never a single Compute Capability.

This post sorts out how to read these numbers. In our earlier post on migrating to TensorRT 10 on Blackwell we showed that the same Compute Capability does not guarantee compatibility. This time the split happens one level above that. The same product name can carry different numbers.

Every number here comes from NVIDIA's own documentation. What we could not confirm is in Part 4.

Contents

  1. "Blackwell" is not one Compute Capability
  2. What the split means in practice
  3. How this connects to our earlier posts
  4. What we still do not know
  5. Summary

Part 1 "Blackwell" is not one Compute Capability

Start with NVIDIA's own definition. Section 2.6, Compute Capability, of the CUDA C++ Programming Guide 12.8 puts it like this.

Devices with the same major revision number are of the same core architecture.

Devices that share a major number share a core architecture.

The minor number is defined this way.

The minor revision number corresponds to an incremental improvement to the core architecture, possibly including new features.

It stands for a smaller improvement on top of that core architecture.

The current 13.4 guide rewrote this section. It now says the compute capability corresponds directly to the version number of the SM, so a 12.0 GPU has SM version sm_120. A different major number means a different SM version, and as shown below, that is also where cubin compatibility stops.

The official list shows Blackwell scattered

With that definition in hand, look at the list NVIDIA publishes.

Products with a Blackwell GPU are spread across five Compute Capabilities
Figure 1 Generations and their Compute Capability numbers (source NVIDIA CUDA GPU Compute Capability list. Chart by Qualiteg)

Ampere's A100 is 8.0, Ada's RTX 4090 is 8.9, Hopper's H100 is 9.0. Up to here, one generation name maps onto one major number.

Blackwell is the one that breaks the pattern.

Products built on a Blackwell GPU are spread across five numbers, 10.0, 10.3, 11.0, 12.0 and 12.1.

B200 and GB200 are 10.0. B300 and GB300 are 10.3. Jetson T5000 and T4000 are 11.0. GeForce RTX 5090 down to 5050 and the RTX PRO products are 12.0. GB10 (DGX Spark) is 12.1.

Jetson T5000 and T4000 are listed on the NVIDIA product page with a "Blackwell architecture GPU".

Counting major numbers alone, that is three of them, 10, 11 and 12. Different major numbers mark separate CUDA binary compatibility classes.

This is not a split by target market

Let us clear out a common misreading first.

You will see it explained as "the 10 series is for data centers and the 12 series is for GeForce". That does not hold up.

The Data Center column of the official list contains the 12.0 RTX PRO 6000 Blackwell Server Edition and RTX PRO 4500 Blackwell Server Edition. They sit in the same column as B200 and B300.

What splits the numbers is not the market they ship into. It is a different SM version, and the cubin compatibility boundary sits there.

Put another way, the marketing generation name "Blackwell" and the compatibility boundary inside CUDA do not line up.

Rubin's number is 10.7

With that settled, the question from the top of this post answers itself.

The CUDA 13.4 release notes say it outright.

Added support for the NVIDIA Rubin (compute capability 10.7) GPU architecture.

Rubin is 10.7. It lands in the 10 series, the same major number as B200 and B300. The wording above is from the CUDA Toolkit release notes.

The TensorRT-LLM release notes treat it the same way.

Align isSM100Family() with its SM100-109 C++ namesake
Run legacy fmha_v2 on the SM100 family (incl. SM107)

isSM100Family() covers SM100 through SM109, and SM107 sits inside that range.

So 107 and 120 are numbers from two different series. Lining them up and reading "107 must be the older one" does not work.

Part 2 What the split means in practice

Now that the split is clear, here is how it bites in real work.

Section 1.3.4.1, Binary Compatibility, of the current CUDA Programming Guide states the rule.

NVIDIA GPUs guarantee binary compatibility in certain circumstances. Specifically, within a major version of compute capability, GPUs with minor compute capability greater than or equal to the targeted version of cubin can load and execute that cubin.

Same major number and an equal or higher minor number, and the GPU can load and run the cubin. The same section gives the example that a cubin built for 8.6 runs on 8.9 but not on 8.0.

A cubin needs the same major number and a minor number that is equal or higher
Figure 2 When a regular cubin is compatible (source NVIDIA CUDA Programming Guide, section 1.3.4.1. Chart by Qualiteg)

There is a line drawn inside Blackwell

Apply that rule to the spread above.

A cubin built for the regular sm_100 target runs on a 10.3 B300. Same major, higher minor.

A cubin built for 10.3 does not run on a 10.0 B200, because the minor number goes down.

That rule only covers regular targets. Code built for an architecture-specific target such as compute_100a runs on 10.0 and nothing else. A family-specific target such as compute_100f runs on 10.0, 10.3 and 10.7 (section 5.1.2 of the current guide).

And between the 10 series and the 12 series the major number differs, so neither direction works.

A cubin built for B200 does not run on an RTX 5090. The reverse is also true.

Same "Blackwell" name, but nothing crosses this line.

What happens when you target the wrong one

This is the part to watch.

Target the wrong one and it may refuse to start, or it may run anyway because the PTX gets JIT compiled at load time.

Which of the two you get depends on whether you embedded PTX at build time. It comes down to how you wrote -gencode.

PTX is not a guarantee either. Architecture-specific targets such as compute_100a have no forward compatibility.

And the fact that it started says nothing about whether the output is correct. We have written up a case where the build passed, the speed was there, and the output was still broken. Check startup time, performance and output on the actual hardware.

TensorRT engines are a separate matter

One thing to add here.

Everything above is about CUDA cubins. The "engine" that TensorRT produces is a different artifact, and its compatibility conditions are stricter.

A TensorRT engine is tightly bound to the TensorRT version and the GPU of the machine that built it. The same Compute Capability does not mean you can move it around.

Part 3 How this connects to our earlier posts

We have written around this topic several times. With the numbering sorted out, here is where each of those posts now stands.

The per-model rule still holds

In our TensorRT 10 on Blackwell migration guide we described corrupted output in production when an engine was reused across GPU models that were both sm_120. In the small reproduction reported there, the warnings appeared but the outputs matched.

The conclusion there was to manage engines per GPU model, not per Compute Capability.

What we learned this time is that the same thing happens one level up.

Same Compute Capability, different model, different thing. And the same architecture name can carry different Compute Capability numbers. The split happens twice over.

The posts that carry the number tables

Our list of NVIDIA GPU Compute Capability levels got rows for Rubin and for Jetson T5000 / T4000, and its note now says that Blackwell does not sit on a single number.

Which GPUs PyTorch supports got a row for SM_107. The CUDA 13.4 release notes state that the new features and newly enabled platforms in 13.4 need an R615 or later driver.

Our 2026 NVIDIA GPU Quick Search Tool had seven SM_120 products filed under SM_100, which we fixed, and Rubin was added.

That last one was a lesson while writing this. Our own tool was making exactly the mistake this post is about. RTX PRO 6000 Blackwell and GeForce RTX 5090 were sitting under SM_100, next to B200.

Part 4 What we still do not know

Being straight about the gaps.

We do not have Rubin hardware. The number 10.7 is stated in the CUDA 13.4 release notes, so it is confirmed against a primary source. What we have not checked is how it behaves on a real machine.

The per-product list still has no Rubin row. As of September 23, 2026, the architecture number is in the release notes, but which products land on 10.7 is not settled until the per-product list is updated.

B100's Compute Capability is not in the official list. B200 and GB200 are stated as 10.0.

We do not know why the Jetson Blackwell alone is 11. The official list puts 11.0 on Jetson T5000 and T4000, and the product page says they carry a Blackwell architecture GPU. We found no primary source explaining why it sits between 10 and 12.

We are not covering the hardware differences between the 10 series and the 12 series. Plenty of write-ups claim differences in tensor core instructions and memory layout, but we could not confirm them against primary sources, so this post stays on numbering and compatibility.

Summary

In one line, the major Compute Capability number is the compatibility boundary inside CUDA, and it does not line up with the product generation name.

Three things to take away.

By NVIDIA's definition, devices that share a major number share a core architecture. Yet the products built on a GPU with the single name "Blackwell" are spread across 10.0, 10.3, 11.0, 12.0 and 12.1. The generation name does not line up with the compatibility boundary inside CUDA.

The numbers are not split by the market they ship into. The 12.0 RTX PRO 6000 Blackwell Server Edition sits in the same data center column of the official list as B200.

A regular cubin needs the same major number and a minor number that is equal or higher. Between the 10 series and the 12 series, nothing crosses in either direction.

Pick your build target by Compute Capability number, not by architecture name. Saying "we built it for Blackwell" does not tell anyone whether you mean the 10, 11 or 12 series.

Coming next

When Rubin's official Compute Capability lands in NVIDIA's list, we will follow up. We will also write up which instructions are available on the data center side and on the GeForce side, once the primary sources are there.

See you next time!

References

Read more