pub enum OpClass {
Ffn = 0,
Matvec = 1,
Matmat = 2,
Batch = 3,
MatmatWide = 4,
MatvecHead = 5,
GemmNt = 6,
}Expand description
GPU-eligible op classes, each with an independent probe.
Variants§
Ffn = 0
Whole FFN chain in one submission (dense / MoE block).
Matvec = 1
Large hybrid CPU∥GPU matvec (lm_head class).
Matmat = 2
Prefill GEMM (matmat).
Batch = 3
Batched matvecs of one input (QKV).
MatmatWide = 4
Prefill GEMM at image-diffusion widths (b ≥ 128). Probed apart
from Matmat: one imagegen process runs BOTH populations
(prompt encode b≈40 where the GPU wins big, DiT b≥256 where
the CPU AMX arm is competitive) — a single shared verdict locks
the wrong arm for whichever population samples second.
MatvecHead = 5
The lm_head itself, apart from the merely-large matvecs. Same
reasoning as MatmatWide, and DeepSeek-V4 is where it bit: its
attention projections are 37M weights and its head is 529M, so
the projections’ verdict — CPU, honestly measured at 0.19 ms —
decided for a matvec fourteen times their size that took 11 ms
a token on the host.
GemmNt = 6
The blocked f32 GEMM (fcd_ops::gemm_nt): attention’s QKᵀ and
AV, and the VAE decoders’ projections. It used to take every job
over 4 M MACs on sight, with no CPU arm to lose to — which on
the MiniMax-H3 video decoder was three times SLOWER than the
host it displaced. Its population is per-head slices, nothing
like the weight GEMMs above, so it probes on its own.