Repository navigation
q4nx: document the two Q8 code layouts behind one chunk size - #55
Merged
Merged
Conversation
Measured against GGUF ground truth on lm_head tile (0, 0): Qwen3.5-4B-NPU2 (tied lm_head) stores code (r, k) at k*32 + r, which dequant_tile implements (corr 0.9998, the other layout 0.014); Qwen3.6-35B-A3B-NPU2 (untied lm_head, q8 projections) at (r/16)*4096 + (k/32)*512 + (k%32)*16 + r%16 (corr 0.9998, k*32 + r 0.011). Same chunk size, same flm_version, no metadata: document it and warn against decoding Q8 of an unverified model. No code change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Docs7 for 1bit-monster/engine
Commit |
bong-water-water-bong
marked this pull request as ready for review
September 25, 2026 02:54
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 1, 2026
… --mtp and --mmproj (#271) Follow-up to #270. auto_gguf_device() returned hrx for every .gguf, but registry/architectures.json maps 17 GGUF architectures (23 HF classes) to the Vulkan build and not HRX, among them Qwen3.8-Flash-Next (qwen4exp) and Zyphra Zamba, Zamba2 and BlackMamba. auto now keeps those on Vulkan (hrx_missing_arch), and keeps --mtp (HRX drafts at 65-78% of Vulkan) and --mmproj (an open RFC #213 gate) on Vulkan too. tests/device_route.sh: auto keeps a qwen4exp file, --mtp and --mmproj on Vulkan0, and serve.cpp's list matches the registry. It passes on this build (no HRX) and on one compiled with ONEBIT_HRX_SERVER defined (plain file -> HRX0, the rest -> Vulkan0). ctest -LE gpu: 19/19. docs/serve.md states the auto exceptions and the HRX prompt speed until llama.cpp fork #55 is pinned. Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
bong-water-water-bong
pushed a commit
that referenced
this pull request
Oct 1, 2026
…3.8-27B pp512 98 -> 335 llama.cpp fork #55 routes Q4_K/Q5_K/IQ4_XS prompt matmuls to the existing q8_1 x4 prefill kernel: - Q5_K and IQ4_XS get Q4_K's activation/GLU policy. - The generic fused SwiGLU (priority 290) leaves 256-2048-token chunks to it. On Qwen3.8-27B UD-Q4_K_XL those projections had gone to the generic F32 WMMA kernels, 94% of HRX prompt time. Measured on this pin (6e42b51, which also carries #53/#54): - llama-bench -b 512 -ub 512: pp512 98.5 -> 334.6, pp2048 98.1 -> 309.5 tok/s. - 1bit serve --device hrx, 14,435-token prompt: 90.7 -> 264.7 tok/s, same text. - KLD vs the BF16 logits (wikitext-2, 20 x 512): 0.00712, same top token 96.27%. - test-backend-ops MUL_MAT on HRX0: 287/287. GGML_HRX_Q8_PREFILL_RELAX=0 restores the old routing. Docs: a docs/hrx.md section and "Our patches" entry. The docs/serve.md auto-routing note ("97-99 tok/s until fork #55 is pinned") and the docs/laya.md policy note now carry the measured numbers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 1, 2026
…3.8-27B pp512 98 -> 335 (#273) * Pin llama.cpp 6e42b51: HRX prompt matmuls on the q8_1 x4 kernel, Qwen3.8-27B pp512 98 -> 335 llama.cpp fork #55 routes Q4_K/Q5_K/IQ4_XS prompt matmuls to the existing q8_1 x4 prefill kernel: - Q5_K and IQ4_XS get Q4_K's activation/GLU policy. - The generic fused SwiGLU (priority 290) leaves 256-2048-token chunks to it. On Qwen3.8-27B UD-Q4_K_XL those projections had gone to the generic F32 WMMA kernels, 94% of HRX prompt time. Measured on this pin (6e42b51, which also carries #53/#54): - llama-bench -b 512 -ub 512: pp512 98.5 -> 334.6, pp2048 98.1 -> 309.5 tok/s. - 1bit serve --device hrx, 14,435-token prompt: 90.7 -> 264.7 tok/s, same text. - KLD vs the BF16 logits (wikitext-2, 20 x 512): 0.00712, same top token 96.27%. - test-backend-ops MUL_MAT on HRX0: 287/287. GGML_HRX_Q8_PREFILL_RELAX=0 restores the old routing. Docs: a docs/hrx.md section and "Our patches" entry. The docs/serve.md auto-routing note ("97-99 tok/s until fork #55 is pinned") and the docs/laya.md policy note now carry the measured numbers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * registry: record llama.cpp (hrx) pin 6e42b51 (tools/registry_build.py; no mapping changes) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 2, 2026
…mat SwiGLU, Hadamard Q4_0 (#278) * Pin llama.cpp bd5b297: HRX remainder prefill, 32K+ prompts, mixed-format SwiGLU, Hadamard Q4_0 llama.cpp fork commits since 6e42b51 (figures from each PR, Qwen3.8-27B on HRX0, balanced mode): - #61: q8_1 x4 prefill takes the 256-aligned head of a Q5_K/IQ4_XS remainder chunk. UD-Q4_K_XL pp400 67.4 -> 103.4, pp1862 172.1 -> 234.6 tok/s; KLD vs 6e42b51 0.00215, same top token 97.19%; MUL_MAT HRX0 287/287. - #59: V stays row-major past copy_transpose_f16's 32768-row range. pp512 @ d32768 failed before, 227.4 tok/s now; a 34,816-token wikitext chunk gives PPL 6.2150. - #60: K-quant SwiGLU decode stages separate gate/up codebooks. UD-IQ2_S tg128 3.12 -> 8.32; UD-Q4_K_XL unchanged; KLD 0.00013; test-backend-ops HRX0 996/996. - #58: llama loads onebit.hadamard_q4_0 files through llama-hadamard (needed by #277). Q4_0-H32 vs BF16: PPL 6.021, KLD 0.0292, same top token 92.5%. Docs: docs/hrx.md #55 section (remainders now covered for Q5_K/IQ4_XS) and "Our patches". Registry regenerated (tools/registry_build.py; no mapping changes). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * docs/hrx.md: the #61 figures were measured on 6e42b51 + #61 (a36d547) (review) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
bong-water-water-bong
added a commit
that referenced
this pull request
Oct 2, 2026
The engine's GPU route is HRX only since 2026-10-01. Long documents went to the lean ROCm build while HRX prefilled Qwen3.8-27B at 97-99 tok/s; since the HRX prompt-matmul routing (fork #55, engine #273) it prefills 335 tok/s pp512 and a 14,435-token prompt through serve at 265 tok/s. Every Laya class now routes to HRX. Past 32K of context HRX needs fork #59 (pinned separately). Co-authored-by: bong-water-water-bong <bong-water-water-bong@1bit.gg> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two Q4NX containers use different Q8 code layouts under the same 8704-byte chunk. Nothing in the chunk or the container tells them apart: both report
flm_version1.0.3 and neither has metadata.Measured on tile (0, 0) of
lm_head.weight, against a GGUF of the same model:k*32 + r, whichnpu/q4nximplements(r/16)*4096 + (k/32)*512 + (k%32)*16 + r%16This PR is documentation only: a comment in
npu/q4nx.hand a note indocs/npu.md. There is no code change. The 35B's Q8 tensors are read bynpu/lax_pack(#52), which uses the second layout.Open: a rule to detect the layout. Two samples suggest tied (embedding) vs GEMV-oriented tensors, but that is not proven. Until there is one, don't decode Q8 for a model that hasn't been verified.
🤖 Generated with Claude Code