b70-optimization-lab

TP4 ring/MHC consumer overlap feasibility

Date: 2026-07-15

Outcome

The two-stream hardware upper bound passes twice. Across 87 TP4 BF16 [4096] rings and 85 independent MHC post/pre kernels, serial execution measured 5.706 and 5.655 ms. Submitting the MHC stream first reduced this to 5.063 and 5.043 ms, hiding 0.642 and 0.612 ms. All reduced tensors and all four MHC outputs were bitwise identical.

Submitting the communication stream first was neutral (5.708 and 5.654 ms). The viable implementation is therefore not two ordinary commands: it is a persistent MHC consumer submitted first, waiting on per-wire readiness while the unchanged LL256 ring progresses.

This is a feasibility result, not a model speed result. The current screen uses independent work to measure Xe2 concurrency; the real consumer must preserve the dependency on the reduced output.

Hard implementation gate

The test-only implementation must:

Anything below that closes the lane before model integration. A component pass still requires at least 0.50 ms/token in the complete decode graph, then the strict quality suite.

The dependent implementation subsequently failed the forward-progress gate: a polling workgroup prevented the ring queue from advancing, and low queue priority did not permit safe preemption. See 2026-07-15-resident-mhc-consumer-forward-progress-failure.md.

Zero-code protocol checks

Two cheaper protocols were screened before starting source work:

Keep threshold 4096 and ARC disabled.

Evidence: