b70-optimization-lab

DeepSeek V4 Flash on 4x B70 — Frontier Closeout & Lessons

Date: 2026-07-21 · Status: lane paused at a fully-characterized frontier; record intact; all assets preserved

This consolidates a multi-day push to move DeepSeek V4 Flash REAP K160 past its 80.82 tok/s target-verified record on four Intel Arc Pro B70s. Every lever is now characterized with evidence. The record is unchanged and LocalMaxxing-approved.

Promoted publication: closed result packet, standalone fail-closed repro, and exact source archive.

Records (unchanged)

Corrected roofline (a real result of this push)

The core finding: M=1 decode is occupancy-starved, and only speculation fixes it

At M=1, decode fires ~200 tiny kernels/token, most launch/latency-bound — the MXFP4 GEMV runs at 288 GB/s (EU 40% idle), shared-down FP8 at 150 GB/s (EU 83% idle). A single token simply doesn’t have enough independent work to fill the EUs. Neither precision, layout, nor workgroup-splitting manufactures parallelism that isn’t there. The only thing that fills the starved EUs is more work per launch — which is exactly what speculation’s M=8 batching does. This is why the spec record (80.82) is ~2× the nonspec record (43.77).

Closed lanes (all with evidence — do not re-run without a new mechanism)

  1. Config/versions: VTune/unitrace confirmed already optimal — async scheduling on, FULL_AND_PIECEWISE graph (NOT eager), custom fused kernels, versions pinned. notes/2026-07-20-nospec-unitrace-attribution-crosscheck.md.
  2. Exact kernel tuning: 3 iterations recovered ~0.1 ms/token total (GRF128 regressed; prefetch +0.026; oneDNN retunes regressed/inexact). notes/2026-07-20-nospec-m1-kernel-efficiency-iteration{1,2,3-mhc}.md.
  3. Fixed-geometry decoder (Option 4): substrate proven feasible — a raw Level-Zero command list records mixed Triton+oneDNN into ONE boundary, bitwise-exact, 0 host syncs (Phase 0/0b). M1AttentionBoundaryV1 collapses 14 submissions→1, bitwise-exact on 43 layers, nests in PIECEWISE with no eager break. But the endpoint is −0.18 ms/token: submission-collapse doesn’t recover device-kernel execution time (that’s the 9.4 ms), only host-submission overhead (already graph-amortized). This is the 5th independent confirmation (native-K2 +0.9, persistent-K-step ~0, M2 chain +0.11, M1-attention −0.18) that submission collapse caps at ≤0.9 ms. notes/2026-07-20-option4-phase1-m1-attention-debug-to-done.md and the option4-decoder/ substrate.
  4. Occupancy exploits: MXFP4 tile-major prepack fragmented coalescing (−1.3 ms) and dense FP8 more-workgroups lowered occupancy (~0 ms). The M=1 occupancy limit is not kernel-tunable. notes/2026-07-21-dense-fp8-split-n-occupancy-rejection.md, notes/2026-07-20-mxfp4-tile-major-prepack-rejection.md.
  5. Inexact fusion: fast MHC fusion changes ~50% of greedy tokens — MHC arithmetic is load-bearing to quality. notes/2026-07-20-nospec-m1-kernel-efficiency-iteration3-mhc.md.

Speculation lane (the only lever with headroom — and it’s data-gated)

Honest ceiling

80.82 is at or very near the true frontier for this exact model on these four B70s. The only remaining real gain is the ~90 tok/s hybrid, gated on a 10-20M-token capture + multi-day training. 160/230 is not reachable on this hardware/model — it would need the hybrid (~90) and a leaner target cycle (which the decoder proved submission-collapse can’t deliver) and deeper speculation, a combination this silicon doesn’t support.

Reusable assets (preserved, checksummed)

Reopen conditions

Resume this lane only for: (a) a 10-20M-token EAGLE re-capture + training run aiming at ~90 tok/s via the validated hybrid; or (b) a genuinely new device-kernel mechanism that reduces device execution time (not submissions) — e.g. a fused multi-kernel that does more work per launch. Everything else is a preserved closure.