NVIDIA's Blackwell Ultra deprioritized INT8 to a 30:1 throughput disadvantage against FP8, and the spec sheet does not name that number. A paper by Teng-Ruei Chen traces the withdrawal through four layers: the PTX ISA never exposes the fifth-generation integer tensor-core path on sm_103a; CUTLASS explicitly skips INT8 UMMA generation for that target while generating FP8 unconditionally; vLLM ships no INT8 GEMM for Blackwell and fails at runtime after the model loads; SGLang's ahead-of-time INT8 GEMM stops at Sm90. The consistent, layered withdrawal is not a documentation gap. It is a design choice that none of NVIDIA's own-brand channels described plainly.
The practical problem for builders: teams running INT8-quantized models who upgrade to B300 hit a hard runtime error in vLLM only after the model has already been loaded into memory. The failure point is as late in the pipeline as possible. There is an escape hatch (an environment variable routes vLLM's INT8 path to a JIT-compiled Triton backend), but it was not documented before this audit. Chen also identifies a profiler trap: the obvious method for detecting "native INT8" on sm_103 produces a false negative, so teams probing experimentally get the wrong answer.
Quantization format availability is a property of the full stack, not of the silicon spec. B300 nominally supports INT8 by some readings of the datasheet. By the measure that matters (can you deploy a production inference workload without workarounds), it does not. Teams evaluating whether to migrate INT8 inference workloads to B300 should treat this audit as the starting point. FP8 is the actual first-class citizen on this silicon. INT8 optimization dollars belong on FP4 and FP8 toolchain work, or on holding at Sm90 hardware until the INT8 story changes.