Frontier

NVIDIA, CUDA, Hopper and Blackwell

Streaming multiprocessors, tensor cores, HBM capacity and the FP8 and FP4 fast paths, applied to fitting Qwen3.8-27B on a tight 80 GB Hopper part versus a roomy 192 GB-class Blackwell one.

Updated

01 · Concept

Concept

A procurement question arrives with a deadline: the company will serve Qwen3.8-27B, and the choice is between renting 80 GB Hopper-generation accelerators and paying substantially more for 192 GB-class Blackwell-generation ones. The vendor material compares them on arithmetic throughput, which lesson 9.1 established is the currency single-stream decoding does not spend. The decision turns instead on two lines from lesson 9.3, capacity and bandwidth, and this lesson works both out.

First, the shape of the machine, because the vocabulary recurs in every profiling report. A CUDA-programmable GPU is a grid of streaming multiprocessors, each a scheduler over many arithmetic lanes plus a slab of software-managed shared memory and a register file. An H100 SXM part carries on the order of 130 of them, a vendor figure as of Aug 2026 that varies by SKU and binning. Inside each SM sit tensor cores, fixed-function units that consume small matrix tiles and emit accumulated products, and essentially all of a transformer’s arithmetic lands there. Around the SMs sits the memory hierarchy that the roofline of lesson 9.2 is drawn against: registers, shared memory and L1, a shared L2, and then high-bandwidth memory stacked beside the die. Hopper added a fourth generation of tensor cores with an FP8 path and per-tensor scaling logic, and Blackwell added a fifth generation extending that to FP4. The engine builders of lesson 8.6 exist largely to select which of these paths each layer takes.

Now the arithmetic that decides the purchase. Take the Hopper part first, reusing the budget from lesson 9.3 without re-deriving it. An 80 GB part reports roughly 79.6 GiB usable; the bf16 weights of Qwen3.8-27B are about 54 GB, which is 50.3 GiB; a runtime reserve near 6 GiB covers context, activations, and fragmentation. The pool is about 23.3 GiB, which at 656 MiB per 8,192-token sequence, cache plus the constant DeltaNet state, supports about 36 concurrent conversations, and holds exactly one sequence at the full 262,144-token native context. That is a tight fit, and it is why deployments on this part reach for FP8 weights or split the model across two cards, which drags in the interconnect costs of lesson 9.9.

Now the Blackwell-class part, at a vendor-reported 192 GB of HBM3e. Usable capacity is about 178.8 GiB. The weights cost the same 50.3 GiB, because weights are a fixed charge that does not scale with the card, and a slightly larger reserve of 8 GiB leaves

178.8 GiB50.3 GiB8 GiB = 120.5 GiB = 123,392 MiB178.8\ \text{GiB} - 50.3\ \text{GiB} - 8\ \text{GiB} \ =\ 120.5\ \text{GiB} \ =\ 123{,}392\ \text{MiB}

for the pool. At 656 MiB per 8,192-token sequence that is about 188 concurrent conversations, and at 16,528 MiB per full-native-context sequence it is about seven. Concurrency rose roughly fivefold from a capacity increase of about 2.4 times, and the leverage is entirely because the fixed weight charge is paid once on either card. Every additional gibibyte on the larger part goes to users. This non-linearity is the single most important fact in accelerator selection for a model of this size, and it is invisible in any comparison built on arithmetic throughput.

Bandwidth is the second axis and answers a different question: not how many users, but how fast each one reads. Applying the lesson 9.1 bound to a vendor-reported figure near 8 TB/s,

tcheckpoint estimate 54×109 B8×1012 B/s 6.75 ms148 tokens per second,t_{\text{checkpoint estimate}} \approx\ \frac{54\times10^{9}\ \text{B}}{8\times10^{12}\ \text{B/s}} \approx\ 6.75\ \text{ms} \quad\Longrightarrow\quad \approx 148\ \text{tokens per second},

against about 62 on the Hopper part. For an unchanged active-byte workload, roughly 2.4 times the bandwidth raises the bandwidth roof by roughly 2.4 times. The 54 GB quotients above are checkpoint-size heuristics from vendor claims, not measured throughput or hard limits.

Here is the classic wrong turn, and it usually appears in the same meeting. Someone notes that the newer part supports FP4 and concludes that inference will therefore be twice as fast again, for free. Separate the two effects. A validated FP4 representation may reduce active weight traffic far below bf16, but its exact active-byte reduction depends on the representation and runtime. That can improve bandwidth-limited decode, but the pinned 17.1 GB Q4_K_M GGUF is not evidence for a server FP4 layout. FP4 tensor cores also raise the flat compute roof, which accelerates prefill and time to first token. That is an arithmetic effect and it is also real, but it helps a different phase. Neither is free: the format must have a validated quantization recipe for this model, and Qwen3.8-27B is a hybrid architecture whose 48 Gated DeltaNet layers are newer than most kernel libraries, so FP4 coverage for them should be verified in the specific stack version rather than assumed from a marketing table. Quality regression testing against the model card’s own benchmark set is the minimum before a format change ships.

The habit worth keeping is to price a part on the two lines that decide your workload: how much pool remains after a fixed weight charge, and how many bytes per second cross the threshold. Lesson 9.5 takes the same two lines to a vendor whose entire pitch is the first one.

02 · Analogy

Analogy

Two workshops share a trade. The older one has a modest floor and a narrow loading bay, so large jobs are split between two buildings and half the day goes to carting parts across the yard. The newer one has more floor, a wider bay, and a jig that handles a coarser stock. The trade did not change; what changed is how much of a job fits under one roof, and how fast material crosses the threshold. Capacity decides how many jobs run at once, and the bay decides how fast each one moves.

03 · Teach it back

Teach it back

Compare an 80 GB Hopper part with a 192 GB-class Blackwell part for serving Qwen3.8-27B, in both concurrency and single-stream latency, and explain why FP4 affects two different limits.

Minimum: 80 characters and 15 words. Your writing stays only in this browser.

Waiting for your explanation.

Compare with a model answer

Capacity and bandwidth are separate purchases. On an 80 GB part, the bf16 weights take about 50.3 GiB of roughly 79.6 GiB usable, leaving a key-value pool near 23.3 GiB after runtime reserve, which lesson 9.3 turned into about 36 concurrent 8,192-token conversations and exactly one full 262,144-token sequence. A 192 GB-class part reports about 178.8 GiB, so the same weights and a slightly larger reserve leave roughly 120 GiB of pool, around 188 concurrent 8,192-token conversations and about seven full-context sequences. Bandwidth is the other axis: dividing the 54 GB checkpoint by vendor-reported bandwidth gives planning heuristics near 16 milliseconds (about 60 tok/s) at 3.35 TB/s and 6.75 milliseconds (about 148 tok/s) at 8 TB/s. These are not hard bounds because active bytes differ from checkpoint size. FP4 acts on both roofs of lesson 9.2 but through different mechanisms: it can cut active weight bytes in bandwidth-bound decode, and it raises the arithmetic ceiling that limits compute-bound prefill, so its benefit depends entirely on which phase you are measuring.

04 · Check your understanding

Check your understanding

01Moving Qwen3.8-27B from an 80 GB Hopper part to a 192 GB-class Blackwell part raises concurrency at 8,192 tokens from about 36 to about 188 sequences. What produced most of that gain?
Answer and explanation

Capacity, because the weights are a fixed cost and every additional gibibyte goes entirely to the key-value pool — The 50.3 GiB of weights is paid once on either part, so the pool grows by nearly the whole capacity difference and concurrency scales with the pool, not with bandwidth.

02Lesson 9.2 placed batch-1 decode far to the left of the ridge point. On a part with roughly 2.4 times the memory bandwidth, what happens to that placement?
Answer and explanation

The point stays at the same arithmetic intensity but the bandwidth roof rises, so attainable performance and the tokens-per-second ceiling both rise proportionally — Intensity is a property of the workload, not the machine; changing bandwidth tilts the slanted roof and moves the ridge point, but batch-1 decode remains bandwidth-bound.

Complete the teach-back and answer the quiz correctly to finish this lesson.

◎ · Evidence marker

Sources

  1. NVIDIA Corporation (2026). CUDA C++ Programming Guide.
  2. NVIDIA Corporation (2026). NVIDIA Data Center Technologies.
  3. NVIDIA Corporation (2026). NVIDIA H100 Tensor Core GPU.
  4. Qwen Team (2026). Qwen3.8-27B Model Card.