Struct Fp8BlockScales 

pub struct Fp8BlockScales {
    pub scales: CudaSlice<f32>,
    pub rows: usize,
    pub cols: usize,
}

Device-resident block-128 weight-scale grid for an e4m3 operand (B1b, lane fp8st 2026-08-03).

STORAGE LAYOUT (the canonical device layout every future consumer builds from): a flat f32 buffer in the CHECKPOINT’S on-disk order — row-major [rows = ceil(out_f/128), cols = ceil(in_f/128)], so scales[ob * cols + kb] scales the 128x128 weight tile at output-block ob, input-block kb (uploaded verbatim from memra_gguf::source::F8BlockGrid, no permutation — one host decode, one htod). Rationale: (1) the per-block-dequant mmvq twin (qmatvec_e4m3_mmvq extension, DECISION.md B1) indexes (o >> 7) * cols + (e >> 7) — natural in this order; (2) for cuBLASLt BLK128x128 the weight [out, in] row-major is the TN GEMM’s column-major [k=in, n=out] A operand, and this same linear order IS that view’s column-major block grid with ld = cols(=kblk) — probe P1 (probe/fp8_lt_blk_probe.cu) verifies whether sm_120 accepts it directly; if Lt wants a different order, the reorder happens at the GEMM plan build, NOT here. NO KERNEL CONSUMES THIS YET: the loader keeps every block-128 tensor’s decode/prefill on the Q8_0 re-encode until the consuming kernels land (try_fp8_gemm skips blk operands; the QT_F8_E4M3 one-copy arm rejects them). This struct’s job is bytes+scales resident and correct.

Fields

scales: CudaSlice<f32>

rows: usize

cols: usize