Fourteen changes ready to open: could you raise the open-PR cap for a couple of days?

[MichaelDementii]

Hello, and thank you for the reviews on #99, #106 and the rest — the feedback shaped how we measure.

We have fourteen changes finished and waiting. Two of our PRs are open (#160, #167), which is the
cap, so we cannot open anything new. Both are in your court: every question on #160 was answered on
Sep 2 (including the T=1024 table you asked for, +5.99% end-to-end at the shipped default chunk),
and #167 has had no review yet.

Could you raise the cap for a day or two, or tell us the order you would prefer? We are happy to
open them one at a time and wait for each to land — we only want to stop sitting on finished work.

Everything below is measured on a single RTX 5090, end-to-end through ninfer-serve or
ninfer_bench unless the row says "operator". Each PR carries its own raw data, a bit-exactness
gate with a sabotage control, and a full ctest on both arms from one build directory.

Prefill — Qwen3.6-35B-A3B

change	effect
GDN input projection through an integer activation fold (W8G32)	+3.0…3.5%
output projections linear_add through the same fold	+2.19…2.51%
attention input projection through the same fold	+0.97…1.45%
routed gate/up: pipeline depth chosen by route, grid over work units	−2.25% server time, all 23 length buckets
Full flag split so a ragged token count stops taking the slow weight path	recovers 14…32% of the ragged-length operator penalty

The first three are one family and must land in that order — the second and third do not apply
without the first.

Decode — Qwen3.6-35B-A3B

change	effect
small-T expert selection: one CTA per token, and a 5-exchange merge network instead of 8 dependent warp rounds	+1.598%, bit-exact
sigmoid gate folded into the causal-attention reduction epilogue	+0.9…2.3% (and exactly zero on 27B)
SwiGLU activation plate held in half precision at small T	+0.940% at mtp0; operation workspace halves, 74 240 → 37 376 B
deeper k-group staging where the schedule holds one CTA per SM	+0.673%, bit-exact
two Q4 group quads in flight in the routed gate/up dot product	+0.57%, bit-exact (−2.75% on the round's most expensive kernel)
linear-attention state pinned in L2 across the decode graph	+0.778%, at the cost of −0.709% prefill; zero on 27B, where a guard disables it
Rows2 window of routed down held at eleven tokens for the Q5 codec	+1.5% at --mtp-draft-tokens 5, zero at any smaller draft window

Host and 27B

change	model	effect
NFC normalization skipped for pure-ASCII text	any	×62…71 on normalize_nfc, 4.9…14.8% of TTFT on a prefix-cache hit
flat BPE merge table instead of the hash map	any	−20…25% of Tokenizer::encode, −1.5 MiB live heap, output bit-exact
guarded slow expf path removed from the fused NVFP4 SwiGLU epilogue	27B NVFP4	epilogue is 162.8 µs of a 2842.6 µs kernel, 53.3 µs of it exact expf and exact division

What we are not claiming

The decode figures are not additive: stacking everything measures +4.71…4.78% decode and
+7.81…7.90% prefill against master, less than the sum of the parts, and we say so in each body.
Where a change gives nothing on the second model, the body says that too — three of these are dead
on 27B by construction, and one of them ships with a guard so it costs nothing there.

Thanks either way, and no rush if the timing is bad.

[Neroued]

ok, remember do a rebase to master

[MichaelDementii]

A correction to one sentence in the opening post, before it misleads anyone reading the list.

I wrote that every one of these carries a bit-exactness gate with a sabotage control. That is
true of nine of them and not of the other five: the three W8-A8 projections, the half
precision SwiGLU plate, and the fast expf epilogue all change the output by construction —
they move work onto a different numeric route — and each of their bodies says so in its opening
lines. They are backed by a naive-FP64 oracle and by ΔNLL rather than by a bit-exact gate, and
each body shows the oracle separating the two routes rather than asserting that it would.

I would rather flag that myself than have it read as a blanket claim it is not. The per-change
rows above are unaffected: where a row says "bit-exact" it is, and where it does not, it is not.