Enum DenseBf16 

pub enum DenseBf16 {
    Dev(CudaSlice<u8>),
    Host(Vec<u8>),
}

It5 ledger item 3 — residency of a dense bf16 slab. Dev = device-resident, today’s exact bytes: the only realization when the dense arm is bf16, and always the realization for the drafter/MTP blocks (no fp8 twins this rung). Host = the fp8 dense arm’s STAGED residency: the same host-dequantized bf16 bytes the loader would have uploaded, kept host-side; the fp8 pair owns every device decode/verify read (via [dwsel]) and the prefill pass stages these bytes H2D per consuming call, the transient copy freed stream-ordered when the DenseView drops. This is the engine’s existing staged-residency idiom (hybrid EDGE-1 HostExps / the moe-cache host-resident expert staging) translated to dsv4; dsv4 has no CUDA-graph capture, so the “release after capture” boundary degenerates to “never resident outside a prefill pass”. Prefill’s bf16 path is byte-identical by construction: the staged upload is the SAME f32_to_bf16_exact byte vector the resident slab held.

Variants

Dev(CudaSlice<u8>)

Host(Vec<u8>)

Implementations

impl DenseBf16

pub fn dev(&self) -> &CudaSlice<u8>

The device-resident slab. Host residency here is an ENGINE bug, never an env error: Host exists only when the fp8 arm is on, and every path that reaches this accessor under fp8 (legacy decode combos, bf16-slab probes) is already a boot refusal (hermes a4e3d9a8eab4cf17) or dwsel-routed to the fp8 twin.