Board-validated on RK3588 (10.3.0.236, governors=performance, DDR 2112 MHz / A76 2.4 GHz). Shape: Qwen2.5-7B ffn_down, K=18944, N=3584, M=228 — the widest-K matmul in the 7B, and the one that forces the K-slice accumulate path (K > kmax=4096, so it cannot ride the full-K Bf envelope). Probe: mc_prof 228 18944 3584 <iters> with ORK_KTILE=<KS> (per-core copy/submit/ accumulate breakdown, blocking mcworker). Throughput reported as GMAC/s = 15.48e6 / (µs/matmul) (228·18944·3584 = 15.48 G MAC).

The K-slice size KS (default 1024) is a sharp, provable optimum at 1024 — every other value is 30–60 % slower. The cause is not the slice count or the "cube K": it is a single code flag, sched = (Kp==1024 || Kp==512), that gates two coupled effects at once, and only Kp∈{512,1024} turns it on:

1. The M-tile size (mcworker, src/npu.c:3890): sched=1 → chunk = mg_max*64 (=320 rows at Kp=1024); sched=0 → chunk = (RB/2)/Kp (≈54 rows). The int8 matmul is weight-DMA-bound (each M-tile submit re-streams the whole Kp×Ncore weight slice from DRAM regardless of row count — see Weight-DMA Amortization), so a 320-row tile streams the slice once for M=228 while a 54-row tile streams it ~5×. This is the dominant term.
2. The 0x1040 K-reduction schedule (synth_i8, src/npu.c:854): sched=1 writes a K-tuned value (base = 177 − 15·(Kp/512 − 1), stepped per 64-row group); sched=0 leaves the template default. This is the same register behind the small-K zero-output boundary (Exp-2026-07-12 Matmul Shape Boundaries); the formula is bit-exact-validated only at Kp∈{512,1024} for int8.

The two are inseparable: the big weight-amortizing M-tile (mg_max*64) is only bit-exact when the matching 0x1040 schedule is programmed, and that schedule is validated only at Kp∈{512,1024}. So you cannot buy the big M-tile at an arbitrary Kp — leaving 1024 forces sched=0, which forces the small (RB/2)/Kp M-tile, which forces the ~5× weight re-stream.

(RB = 2·CBUF = 114688, CBUF = cbuf_elems = 57344 int8; RB/2 = 57344, so (RB/2)/Kp at Kp=1056 → 54.)

512 gives an even bigger M-tile (704 rows) but 37 K-slices vs 1024's 19. Each K-slice carries fixed per-slice overhead independent of the compute: a chained PC submit, an A re-tile gather ([mco][Kp] host memcpy — mcworker, src/npu.c:3924-3928), and a host int32 partial-accumulate. 512 doubles that fixed cost, so despite the larger tile it measures slower (486 vs 764). 1024 is the larger of the two validated sched=1 points → the fewest K-slices while its 320-row tile still covers M=228 in a single pass. That balance is the peak.

An intermediate "17/19-slice bracket" (KS 1056/1120 vs 1024) was described as "holds the M-tile at 320, so it isolates the schedule reg." That was wrong. sched=0 forces the (RB/2)/Kp M-tile (54/51 rows), so the bracket varied the M-tile (320→54) and the schedule together — it does not isolate either. The honest reading of the data: the M-tile / weight-DMA is the dominant term, and sched is the gate that grants access to the big tile. (A clean isolation would require programming the big M-tile with sched=0, which miscomputes — the coupling is exactly the point.)

Kp=1024's 320-row M-tile covers M ≤ 320 in one pass. For larger prefill batches (M > 320) it needs ≥2 M-tiles and the balance point could shift; for the M ≤ 320 regime (our 228-token ubatch) 1024 is ideal. This is the roofline/M-tile interplay — arithmetic intensity ≈ M-tile rows, ridge ≈ 128 rows for this shape (see Prefill NPU Utilization).

The K-slice axis is exhausted. Every Kp is either {512, 1024} (sched=1, fast) or not (sched=0, ~5× weight re-stream). 1024 is the provable optimum; the KS default is correct; finer values (768/896) and the "even-split" multiples-of-8 (all sched=0) are all slower. KS is not a lever.

Two remaining levers for the wide-K path, in priority order:

1. Pipeline the host int32 partial-accumulate against the NPU (the live lever). mc_prof @ M=228 measured ~94 ms/core serial accumulate vs ~235 ms NPU ioctl → a 1.69× ceiling if the accumulate overlaps the next slice's submit. No schedule change, wedge-safe. This is the one that can still move the 7B ffn_down.
2. Extend the sched=1 band to larger Kp (HW-RE, uncertain). Validating the 0x1040 formula + mg_max*64 M-tile at Kp=2048/4096 would let the deep-K matmul use fewer efficient slices — but mg_max shrinks as Kp grows (Kp=4096 → M-tile 64 < 228 → 4 tiles), so even a validated sched=1 at 4096 would not beat 1024 at M=228; the win, if any, is at much larger M. Wedge-prone (Kp=2048 wedged core0 in this sweep). Lower priority.

# governors=performance first
for KS in 512 768 896 1024 1056 1120 1184 2368 4736; do
  sudo env ORK_KTILE=$KS ORK_MM_TIMEOUT=3000 timeout 90 ./mc_prof 228 18944 3584 10
done   # GMAC/s = 15.48e6 / (µs/matmul); single-stream; sudo reboot on any wedge

Related: PC-chaining M-tiles & the rkllm schedule · Weight-DMA Amortization · Matmul Shape Boundaries (the 0x1040 boundary) · Optimization Roadmap.