Skip to content

qwen3_5 cuda: mixed-width MLX checkpoints, 2 to 8 bits in groups of 64 - #849

Open
BobClawblaw wants to merge 28 commits into
ashhart:mainfrom
BobClawblaw:cuda-mixed-width
Open

BobClawblaw wants to merge 28 commits into
ashhart:mainfrom
BobClawblaw:cuda-mixed-width

Conversation

@BobClawblaw

@BobClawblaw BobClawblaw commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

Stacked on #836 (Windows native CUDA server). Until #836 merges, this PR shows its commits too. The change here is ee54aba5 and 9b843c10, which puts its comments on one line each. It is rebased onto #836's current head, 5e1c3fea.

What this changes

The Qwen3.5 CUDA engine loads MLX checkpoints whose quantization table gives each module its own width: 2 to 8 bits, in groups of 64. This is the format of mlx-lm's mixed recipes and of the OptiQ and oQ conversions.

  • 2 to 4-bit codes are packed onto the existing affine-4 tiles. 5 to 8-bit codes go onto new 8-bit tiles. Each code keeps its value, scale and bias, so nothing is rounded.
  • zig/kernels/cuda/affine8.cu adds:
    • a lane GEMV for the 8-bit tiles, with lane_gemv's arithmetic one byte wide (each byte is exact in bf16);
    • its split-K form;
    • the width-aware packers and a row widener.
  • An embedding at an odd width is widened at load. 8-bit rows have their own embed kernel (tf_q35_embed8).
  • Geometry reads each module's width through core.quant.mlx. Groups other than 64, and non-affine modes, are still refused.
  • The engine's projections are a 4-bit/8-bit union (Proj). The drafter reads the target's embedding and head through the same calls.
  • The rope config's older "type" key is read as "rope_type", because mlx-community's OptiQ conversions write it.

A uniform 4-bit checkpoint takes exactly the same packs and kernels as before.

Receipt

  • Environment:

    • Builds: Windows: the native CUDA server, and Qwen3.5-2B and Qwen3.8-27B on CUDA #836 at 5e1c3fea (before) and this PR at 9b843c10 (after), each built from its head.
    • Machine: RTX 4080 SUPER 16 GB (sm_89), Windows 11, CUDA 13.3, Zig 0.17.0, built with -Dsm=89.
    • Checkpoints:
      • mlx-community/Qwen3.5-2B-MLX-4bit @ 93760be4
      • lmstudio-community/Qwen3.5-9B-MLX-4bit @ b455506b
      • lmstudio-community/Qwen3.5-9B-MLX-8bit @ 950e0459
      • mlx-community/Qwen3.5-4B-OptiQ-4bit and mlx-community/Qwen3.5-9B-OptiQ-4bit
    • Serving: --context 40960.
  • Exactness:

    • 9B 4-bit and 9B 8-bit: bench_concurrent --alone --serial (levels 1 and 4, 4 cells) gave 48/48 equal alone and 10/10 equal to "draft": false on each.
    • OptiQ 4B and 9B: window and tree equal step, and bench_concurrent --alone --serial at 1 and 4 streams gave 0 unequal.
    • Linux runs: the RTX 5090 run in the comments below has 60/60 equal on both OptiQ checkpoints.
  • Decode speed (bench_openai, one stream, medians over 5 reps; fibonacci-raw and gpu-chat-no-think at T=0 and T=1):

    Checkpoint Windows: the native CUDA server, and Qwen3.5-2B and Qwen3.8-27B on CUDA #836 This PR
    Qwen3.5-9B 4-bit 99.9–101.0 tok/s 99.7–100.8 tok/s
    Qwen3.5-9B 8-bit refused (UnsupportedQwenQuantization) 60.2–61.4 tok/s
  • Prompt speed: the cold first request's ttft_s from bench_cache --require-cold, on a 16,000-token prompt of the repo's docs (all rows report 0 cached tokens):

    Checkpoint Windows: the native CUDA server, and Qwen3.5-2B and Qwen3.8-27B on CUDA #836 This PR
    Qwen3.5-9B 4-bit 8.89 s (1,800 tok/s) 8.89 s (1,800 tok/s)
    Qwen3.5-9B 8-bit refused 11.47 s (1,395 tok/s)
  • Tests:

    • zig build test: 48/48 steps; 745 of 759 tests pass, 14 skipped, 0 fail.
    • tf-cuda-test affine8 (new): 24 cases over 2, 3, 4, 5, 6 and 8 bits at 4 shapes pass.
      • Tiles equal the host-widened codes' tiles.
      • Products are within 0.320 of the float64 bound.
      • 1, 3, 9 and 16-row calls and split-K are byte-equal.
    • tf-cuda-test smoke, glue, quant-ref, modelopt and exlr8 pass.
    • tf-qwen35-cuda over 300 ids, step, window, tree and prompt:
    • CI is green.
  • Not run, and why:

Checklist

  • Every token still goes through the lane rounds. No serial path, and nothing that needs drafts off.
  • Drafted output equals "draft": false, a resumed prompt equals a fresh one, and concurrent equals solo. This engine keeps no prompt cache on CUDA, so a resumed prompt is a fresh one.
  • No precision traded for speed. Every code keeps its value, scale and bias. 8-bit products run lane_gemv's fma chain one byte wide.
  • Prompt processing is no slower than the last release. On the 9B 4-bit it is 8.89 s on both.
  • The description says which platforms I ran: CUDA sm_89 on Windows. sm_120 and sm_121 on Linux are in the comments. Metal was not run.
  • New tests fail before the change, pass after it, and skip cleanly without their dependency. affine8 cannot build without the new kernels. It is a GPU test in tf-cuda-test, outside zig build test.
  • Comments and docstrings are one line. No measurements or history in the source. The CI lean check reports 0 new problems.
  • No personal data, machine names, internal hosts or local paths. No AI attribution lines.

Limits

- zig/src/platform: `sys`, imported by every module (zig/build/sys.zig wires
  it). On POSIX it is std.c, std.posix and std.DynLib unchanged; on Windows
  win_c.zig gives libc's surface over the UCRT and Win32 (integer
  descriptors, directory descriptors, readdir, pread/pwrite, high-resolution
  sleep, monotonic clock, /tmp and /proc/self/exe mapped), win_posix.zig the
  server's sockets over Winsock, console events as SIGINT/SIGTERM, and
  LoadLibraryW for DynLib.
- std.c and std.DynLib calls go through `platform` (mechanical).
- build.zig routes Windows targets to the CUDA build.
- Server: socket closes and writes are explicit, the key file's mode check
  is skipped on NTFS (ACLs), descriptor limits are a no-op.
- shard_edit: the shard's map is released before the rename, since Windows
  refuses to replace a mapped file.
- Tests that need symlink privilege or mode bits skip on Windows.

zig build test-cuda-host passes on x86_64-windows.
- Kernel fatbins build with nvcc and cl.exe: MSVC's conforming
  preprocessor is passed on Windows hosts (CUDA 13's headers need it),
  and explicit kernel instantiations carry the __restrict__ qualifiers
  their templates have (MSVC counts them in the function type; the
  generated code is unchanged).
- Nemotron's checkpoint source keeps io_uring to Linux; elsewhere its
  existing thread reads run.
- pull_exlr8 raises no descriptor limit on Windows.
- modelopt test: the lane's slice partials are allocated. GPUs without
  clusters (before sm_90) reduce split K through them; the test passed
  none, so it wrote through a null pointer on Ampere and Ada.

zig build native and install build with -Dnvcc=... -Dsm=89, and
tf-cuda-test's synthetic suites pass on an RTX 4090.
- pull: where Windows refuses the snapshot's symlink, the snapshot path
  becomes a hard link to its blob (CreateHardLinkW through `sys.c.link`):
  no extra space, and learning already refuses linked shards. Link
  failures are logged with their reason.
- HOME falls back to USERPROFILE (Windows sets no HOME) for the hub cache
  and every libc getenv("HOME").
- Tests read optional fixture variables through `platform.getenv`;
  std.process.Environ.getPosix does not build on Windows.
- The learned-state symlink tests skip on Windows (symlinks need
  privilege); `sys.c.symlink` asks for an unprivileged one.

zig build test passes on x86_64-windows.
- docs/WINDOWS.md: requirements, build, run, how the port works and how it
  differs from Linux; the README points to it.
- -Dstrip reaches tensorfold-native before its install step is made, so
  the step no longer expects a .pdb the stripped build does not write.
- zig fmt on the platform files.
8080 and 8000 are taken by too many other servers; serve listens on 8888
unless --port says otherwise, and the docs and bench scripts follow.
The MLX affine 4-bit checkpoint on the native CUDA server, beside Nemotron:
qwen35.cu holds the Metal engine's glue at its bf16 rounding points (gated
delta rule, causal convolution, gated attention), cuda.qlinear's affine-4
kernels do the projections, sample.cu draws on the device.

Windows of up to 16 rows record each row's recurrence and convolution tail,
so the lane core shares rounds across streams and keeps partial copies; a
window's rows equal one-row steps bit for bit. draw.zig is the host draw
both backends now share.

On an RTX 4090: 210 tok/s for one stream, 1250 tok/s across eight; logits
agree with an fp32 reference at every position of a 36-token check.
…mory

The 2B's CUDA engine now reads its widths from config.json (cuda_geometry.zig):
linear value heads over fewer key heads, more query heads a key/value head,
an untied head, an A_log stored as bf16. The 27B's logits agree with an fp32
reference at every position of a 36-token check, and its windows equal
one-row steps bit for bit; the 2B's output is unchanged.

Two Windows driver costs shaped the rest. Each kernel launch grew with the
process's allocation count (1.2 ms a launch over 1,900 weight buffers), so a
model's weights and scratch now live in one arena (cuda_weights.zig packs
each projection through a reused staging buffer: the 27B loads in 25 s, not
200). And a process's first forwards through a buffer stall for seconds, so
the engine warms every request path at load and the backend keeps a pool of
stream caches that `reserve` allocates and runs a row through once the
server knows its stream count.

On an RTX 4090: the 27B decodes at 37 tok/s in the runner, 31 to 35 tok/s
served, 210 tok/s across eight streams; the 2B stays at 210 and 1,250.
A forward's launches (the embedding to the kept rows' logits) are captured
the first time a shape (rows, windows, recording) is seen and replayed after;
the attention chunk count moves into the per-forward table so a graph stays
valid as caches grow. Prompt chunks stay uncaptured: their GEMMs dwarf the
launches, and each length would be a graph of its own.

A new graph's first run pays the Windows driver's stall (about a second on a
wide model), so `reserve` also captures the shared rounds' shapes, a row of
each of 1 to n streams, at load.

Bit for bit the same logits; on an RTX 4090 the 2B steps in 2.8 ms instead of
5.3 (served: 324 tok/s, 1,560 across eight streams) and the 27B in 23.8 ms
instead of 26.9 (served: 40 tok/s, 243 across eight).
--drafter loads z-lab's DFlash2 draft model behind the lane core's Drafted
wrapper: the target writes each row's residual after the drafter's five
tapped layers into a ring a stream, the drafter folds those rows into a
context of keys and values, and after every verify it drafts a block of
seven tokens past the pending one (the target's own embedding and head at
its ends, a codebook selector tracing one path through each row's best
sixteen). Its projections are quantized to affine-4 on the host at load and
run through the target's kernels; its glue is qwen35_draft.cu.

The Windows driver stalls a buffer's first kernel and a new graph's first
run for seconds, so the drafter pools its contexts and a captured forward
now serves every verify shape: its launches cover a bucket of rows and
every window, and the kernels read the true counts from the device.

On an RTX 4090 the 27B serves 52 to 58 tok/s greedy with drafts against 40
plain, about 100 tok/s on long replies, the same tokens either way; plain
decoding keeps its 24 ms step. The 2B is unchanged.
A verify window's rows may form a tree (each row's parent given): the
convolution taps, the delta rule and attention follow each row's own
branch, and the DFlash2 drafter fills the lane core's planned lanes
(each lane its parent's rank-r choice by the codebook selector), so a
lone stream verifies up to 12 lanes a round and the planner learns
which shapes land.

A verify no longer snapshots every row's state (1.3 GB shared, which
capped the 27B at 8 rows): each stream logs its rows' decay, write and
key, and keep replays the kept path onto the recurrence in one pass
(and moves a tree's kept keys down), so any window width fits. One-row
steps and prompts update in place as before. The lane host times the
target's windows at load, which the depth rule had lacked (it had been
capping chains at 3 drafts).

The runner's new tree mode verifies tree windows with junk branches
against step logits (bit-exact on both models).
What the port serves beyond Nemotron: Qwen3.5-2B and Qwen3.8-27B with
its DFlash2 drafter, the speeds measured on an RTX 4090, the load time
and why, the timing and chain-only switches, and what is not there.
The lean rule (tools/zig/lean_check.py) counts a comment that runs on
to a second line; the Windows port's new files had a hundred such runs.
Each is one line of at most 120 columns now, and the checker reports
the same 539 problems as main.
direct_io opened files with O_DIRECT on Linux alone. On Windows the
same open now asks for FILE_FLAG_NO_BUFFERING (which win_c maps O_DIRECT
to), and the 4 KiB-aligned spans it already reads satisfy the sector
alignment that needs; a file system that refuses it still falls back to
buffered reads. The direct-read test runs on Windows too, checking the
executable's bytes against buffered reads of it.
SIG.IGN is a function pointer made from 1, as std.posix has it. aarch64
requires function pointers to be aligned unless the type says align(1),
so the cross-build for aarch64-windows refused it. With align(1), as
std's own handler type has, tensorfold-native cross-compiles for
aarch64-windows with the GB10 (sm_121) fatbins; no hardware has run it.
The Windows page opens with what the build is, what it is tested on and
that it cross-compiles for aarch64-windows; the README's model table
and the CUDA paragraph say Windows where they said unofficial port.
The no-GPU workflow runs zig build test on windows-latest beside
ubuntu-latest, so the platform layer is built and tested on every pull
request.
Every other module calls libc through `sys`; the drafter's four getenv
calls were the last direct std.c calls in a file the Windows build
compiles.
After a prompt the lane core hands the drafter every prompt row's
features; the CUDA backend refused any request wider than its tap ring
(2,176 rows), so a 27B request with --drafter and a prompt past that
ended with RowsNotHeld, where the same prompt without the drafter ran.
The ring keeps the newest tap_rows rows, which hold the drafter's whole
context window, and absorb already reads only that window of what it is
handed; the backend now refuses only rows not yet written or all gone.

On an RTX 4090 the 27B with its drafter takes a 6,041-token prompt in
7.4 s, and its reply equals the one with "draft": false.
… attention cuts chunks at logical positions

- rowanc held a window's rows as bits of a u32, but prompt chunks run up to
  128 rows: rows from 32 on rotated at the wrong positions and attended the
  wrong keys. A chain row (no parents) now carries its index in its window
  under the top bit; tree windows (at most 16 rows) keep their bits.
- tf_q35_attn_partial cut its 128-key chunks at a key's cache row, so a kept
  tree path whose window crossed a chunk boundary summed in other chunks than
  one-row steps and changed bits. Chunks are now cut at the key's logical
  position (the stream's length plus the ancestors before it).

Checked on an RTX 5090 (Linux, sm_120), tf-qwen35-cuda over 300 ids on
Qwen3.5-2B and Qwen3.8-27B: step bits unchanged, window and tree equal step
byte for byte (tree differed from row 126 on the 2B and 254 on the 27B
before). Prompt mode's last row against step's at 16 to 300 ids: KL at most
0.003 and the same argmax in 20 of 20 (before: 27B at 40 ids KL 2.3 with a
different argmax, at 128 ids KL 1.35).
zig build test-golden and zig build fuzz-cortheon exist on every non-macOS
host since the golden step moved into zig/build/golden.zig, so the golden
check compiles against the platform layer on Windows:

- the platform's posix gains sockaddr.in, timeval, connect and kill for a
  child's handle (TerminateProcess; HUP has no equivalent), setsockopt turns
  a timeval for SO_RCVTIMEO or SO_SNDTIMEO into Winsock's milliseconds, and a
  socket read that times out is WouldBlock, as std.posix reports it.
- the check carries SystemRoot into the spawned server's environment, which
  Winsock needs to start, and drains the server's stdout after the port line
  on every host: the fake server logs each request there, and a full pipe
  (4 KiB on Windows) blocked it after sixteen cases.
- on Windows the check cannot send SIGTERM or SIGHUP, so the sigterm-exit-0
  outcome and the cases after a key rewrite are skipped and printed as such.

On Windows the goldens give 306 of 315 equal with the same nine known
differences as Linux, and the fuzz step passes its eight tests; the no-GPU
workflow's Windows job runs both.
The loader tried only libcublasLt.so.13 and libcublasLt.so, so the
cublaslt suite of tf-cuda-test reported LibraryUnavailable on Windows;
there it opens cublasLt64_13.dll from the toolkit's bin folder.
The platform handed O_APPEND to the C runtime as _O_APPEND, whose write
seeks to the end and then writes, so two threads appending at once could
overwrite each other's bytes: the request log lost lines under concurrent
requests, which the server goldens' request-log case caught on a slow
runner. A descriptor opened with O_APPEND now writes through WriteFile at
the end-of-file offset, which the kernel places whole, as POSIX does; the
file keeps its write access, so ftruncate on such a descriptor still works
(prompt_imprint repairs a torn index that way).

A request_log test appends 200 lines from each of 8 threads and expects
every line whole; it lost lines on Windows before this change.
The lifecycle/request-log outcome said only that the lines differ; it now
gives both logs' line counts and the first line that differs, cut to 100
bytes each, so a mismatch seen on a CI runner can be read from its log.
A checkout with core.autocrlf, as GitHub's Windows runners make, gives the
frozen request log CRLF line endings while the server writes LF, so the
lifecycle/request-log case differed at its first line's end on windows-latest
and nowhere else. Both logs compare with CRLF read as LF; the other goldens
are parsed as JSON and never saw the endings.
@BobClawblaw

Copy link
Copy Markdown
Contributor Author

One more check: a uniform 8-bit checkpoint, lmstudio-community/Qwen3.5-9B-MLX-8bit (9.7 GiB on disk). Every module goes onto the 8-bit tiles. The #836 build refuses this checkpoint, and this branch loads it.

Same machine (RTX 4080 SUPER 16 GB, sm_89, Windows), commit 53da83ca, served with --context 32768.

Check Result
tf-qwen35-cuda window and tree against step, 300 ids byte-equal
bench_concurrent --alone --serial at 1 and 4 streams (sampled and greedy, with and without draft) 0 unequal, 0 failed
Spot replies (bat-and-ball, a bash one-liner) correct
Decode, one request about 60 tok/s (about 73% of memory bandwidth at this size)
Decode, four requests about 112 tok/s total. Only 3 slots fit at 32k context, so this is 3 running plus 1 queued
Prompt about 1.5k tok/s (a 7.1k-token prompt in 4.7 s)

Weights take 10.05 GiB on the card, which leaves about 3.6 GiB for KV after the reserve. A smaller --context gives more slots.

@BobClawblaw

Copy link
Copy Markdown
Contributor Author

For comparison, the uniform 4-bit lmstudio-community/Qwen3.5-9B-MLX-4bit on the same build and machine (53da83ca, RTX 4080 SUPER 16 GB, --context 32768). It takes the existing 4-bit path, so this is mainly a baseline for the 8-bit numbers above.

9B 4-bit 9B 8-bit
Weights on the card 5.40 GiB 10.05 GiB
Slots at 32k context 7 3
tf-qwen35-cuda window and tree against step, 300 ids byte-equal byte-equal
bench_concurrent --alone --serial, 1 and 4 streams 0 unequal, 0 failed 0 unequal, 0 failed
Decode, one request about 98 tok/s about 60 tok/s
Decode, four requests about 305 to 336 tok/s total (about 345 steady) about 112 tok/s total (3 running, 1 queued)
Prompt, 7.1k tokens about 2.0k tok/s (3.5 s) about 1.5k tok/s (4.7 s)

The 8-bit path runs at about 0.6x the 4-bit speed while reading about 1.9x the bytes, which is about what memory bandwidth allows.

A quality note that is not about this change: with thinking on, the 4-bit checkpoint looped greedily on a short bash question until the 4k-token cap ("Wait, find ..." repeated), and at temperature 0.6 it was still deliberating at the cap. With thinking off it answered correctly. The 8-bit answered the same question correctly.

@BobClawblaw

Copy link
Copy Markdown
Contributor Author

Ran this on Linux with an RTX 5090 (sm_120). That covers the "Linux" item in Not run. #859 carries the DFlash2-with-a-mixed-target run, since it's stacked on this branch.

First, a CI fix. zig was failing on the lean check's new-problems step, with 13 new problems: multi-line comments and one comment past 120 columns, in affine8.cu, qlinear.zig, the qwen3_5/cuda_* files and affine8_tests.zig. d6bbfbe6 puts each of those comments on one line, and only comment lines change. lean_new.py reports 0 new, zig fmt --check is clean, and CI is green. The test binary's "failed command" line in the old log isn't a failure: Zig 0.17 prints it whenever a passing test writes to stderr, and here that's the width warning's std.log.warn.

Setup: d6bbfbe6, built with -Dsm=120. Ubuntu, kernel 7.0, driver 615.71.09, CUDA 13.3, Zig 0.17.0. The "base" build is #836 at 153d6b43. Neither is merged with main, which is 2 commits ahead.

tf-cuda-test: affine8 (24 cases over 2, 3, 4, 5, 6 and 8 bits: tiles equal the widened codes', products within 0.320 of the float64 bound, every row count and path byte-equal), smoke, glue (1,242 of 1,242), quant-ref, modelopt and exlr8 all pass.

tf-qwen35-cuda, 300 README ids:

  • Qwen3.5-2B (uniform 4-bit): all four modes byte-equal to the base build.
  • A 2B requantized at 2, 3, 5, 6 and 8 bits, with a 6-bit tied embedding, against the same codes stored widened to 4/8: byte-equal in all four modes. The requantization is my own script, per-group min/max affine from the 4-bit weights; it isn't yours.
  • Qwen3.5-4B-OptiQ-4bit and 9B-OptiQ-4bit: window and tree equal step.
  • TensorFold/Qwen3.8-27B-oQ2: window and tree equal step.

Served, bench_concurrent --tokens 128 --reps 2 --alone --serial, levels 1,4, --parallel 4, no drafter: 60 of 60 checks equal for the 4B and 60 of 60 for the 9B. These served runs used #859's build, which contains this commit. The 4B and 9B give byte-equal logits on both builds in all four modes. Without a drafter, the --serial half of the check is trivial. One stream, greedy, bench_openai: about 220 tok/s for the 4B and 151 for the 9B.

Long context, this build: 9B OptiQ, --parallel 1. One chat prompt fills the window, made of the repo's docs and Zig sources, with a random 10-character code placed 5% in. The question at the end asks for the code. Greedy, 64 tokens.

Context Prompt tokens Code retrieved Time to first token GPU memory after load
65,536 64,526 yes 38.1 s 10.6 GB
131,072 130,061 yes 120.8 s 12.7 GB
262,144 261,134 yes 470 s 16.8 GB

The replies' token_sha at each length equal those from #859's build on the same prompts. Decode speed over 64-token replies at these lengths was too noisy to report.

Not run: reply quality or perplexity, GB10, Ampere. These speeds come from one card and aren't a comparison against the 4080 SUPER's.

@BobClawblaw

Copy link
Copy Markdown
Contributor Author

Test run on a GB10 (sm_121, aarch64 Linux)

Head d6bbfbe6.

Setup. One DGX Spark: NVIDIA GB10 (sm_121, aarch64, 128 GB unified memory), Ubuntu kernel 7.0.0-1019-nvidia, driver 580.178.04, nvcc 13.3, Zig 0.17.0. Built with -Dsm=121 -Doptimize=ReleaseFast.

  • Build, native and zig build test: clean, 48/48 steps, 0 failures.
  • tf-cuda-test: affine8 passes 24 cases over 2, 3, 4, 5, 6 and 8 bits. smoke, glue (1,242 of 1,242), quant-ref, modelopt and exlr8 all pass.
  • Qwen3.5-2B, uniform 4-bit. Its tf-qwen35-cuda step logits over 300 ids equal Windows: the native CUDA server, and Qwen3.5-2B and Qwen3.8-27B on CUDA #836's byte for byte, so the 4-bit path is unchanged. window and tree equal step.
  • mlx-community/Qwen3.5-9B-OptiQ-4bit. window and tree equal step over 300 ids. bench_concurrent --alone --serial at 1 and 4 streams: 40 of 40 equal alone, 20 of 20 equal undrafted, nothing failed.
--context 32768 --parallel 4 Qwen3.5-2B Qwen3.5-9B OptiQ
weights on the device 1.61 GiB 7.80 GiB
one stream, code / chat, greedy 137 / 135 32 / 32
4 streams, aggregate 449-466 112-114
cold prompt (2,571 tokens) 0.42 s 2.57 s

…'s widest stream

The chunk width came from the longest stream or window in the forward, so a 201-key row cut its keys into 128-key
chunks alone and 256-key chunks beside a stream past 8192, and a window crossing 8192 recut its earlier rows; either
changed the fp32 sums. Each row now takes chunk_keys(its logical keys), the width its one-row step uses, in both the
partial and the merge kernels, and the partials sit at a fixed max_chunks stride.

tf-qwen35-cuda takes TF_Q35_PREFILL=N (start after N cycled ids) and TF_Q35_BESIDE=N (step an N-token stream in each
forward), which cover both cases: before this change, windows from 8151 keys kept 36 of 120 rows and trees 35, and a
151-key stream beside one from 8189 kept 4 to 11 of 120; after it all of them equal one-row steps on the 2B and 27B.
…fits its selector rank

The integer reader accepted zero, so a conv_group_size or num_key_value_heads of 0 reached a remainder at
admission; sizes and divisors are now positive (mask_token_id alone may be 0). The host staging area held 16 rows at
rank 256, so a larger selector_rank overran it; it is now sized for the admitted rank. Config.parse takes the bytes,
so a host test covers both.
Each module loads at the width the config's quantization table names it. Codes
of 2 to 4 bits pack onto the affine-4 tiles and codes of 5 to 8 bits onto new
8-bit tiles, every code keeping its value, scale and bias, so nothing is
rounded. affine8.cu's lane GEMV is lane_gemv's arithmetic a byte wide (each
byte exact in bf16), with its split-K form; an odd-width embedding is widened
at load and 8-bit rows have their own embed kernel. A uniform 4-bit checkpoint
takes the same packs and kernels as before: the 2B's step, window, tree and
prompt logits are byte-equal to the previous build's.

The rope config's older "type" key is read as "rope_type" (mlx-community's
OptiQ conversions write it).

Checked on an RTX 4080 SUPER (sm_89):
- tf-cuda-test affine8: 24 cases over 2, 3, 4, 5, 6 and 8 bits; tiles equal
  the host-widened codes' tiles, 8-bit products within 0.32 of the float64
  bound, 1/3/9/16-row calls and split-K byte-equal.
- A 2B requantized at 2, 3, 5, 6 and 8 bits (and a 6-bit embedding) gives the
  same logits as the same codes stored widened, in step, window, tree and
  prompt modes.
- Qwen3.5-4B-OptiQ-4bit and Qwen3.5-9B-OptiQ-4bit: window and tree equal step
  over 300 ids; bench_concurrent --alone --serial at 1 and 4 streams all equal;
  about 130 and 78 tokens/s for one request.

8-bit modules have no prompt GEMM yet; prompt chunks run them on the decode
tiles, 16 rows at a time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant