Repository navigation
ggml-hrx: avoid duplicate Qwen weights with shared row64 layouts - #181
Draft
AaronStGeorge wants to merge 11 commits into
Draft
AaronStGeorge wants to merge 11 commits into
AaronStGeorge wants to merge 11 commits into
Conversation
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
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.
Overview
Qwen3.8-27B can fail while materializing duplicate HRX weight representations. This change shares eligible Q4_K/Q6_K row64 weights across consumers and restores the short-prefill kernels from #171. In the tested cold runs, the candidate completes both pp66+tg16 and pp512+tg16 with zero duplicate-weight warnings; the parent fails pp66+tg16. Completed pp512 live-weight counters fall from 22,300,747,776 to 17,522,558,976 bytes (-21.43%). These counters measure live weights, not total VRAM.
Draft only: source acceptance remains held for the unresolved 128-token Q/K activation-format mismatch described below. This replaces the earlier combined experimental PR #171 as the first source entry in the serial model rollout. Further implementation changes belong in separate stacked PRs.
The implementation:
Metadata reuse also works with standard layout, but this source adds it only for row64 format 44. The later native-layout ablation implementation is not included here. Llama and Mistral coverage uses this same source rather than additional model implementations.
Additional information
Exact validation pins: candidate
5d4d8981b837bb5270265b3e94b24ec69f001bac, parent373507afc8764340d1265d0445ee5a9e54104a92, HRX82214dfb029975205d1c3a59164b678e2e21fc41, Radeon RX 7900 XTX / gfx1100. The targethrx-graph-develop-v2has since advanced three commits to62eb8dc18998e1c5a044cf3cf35f8f2967f2caa3; the combined result has not been validated. Publication preserves the tested source without rebasing.Completed validation and remaining regressions
--spec-type draft-mtppasses 12 measured requests plus four warmups, with positive acceptance counters and matching parent/candidate outputs. Lemonade's requested-on HRX launch omitted that flag, so automatic integration enablement is not established. Short responses reach their token cap inside reasoning; this is execution evidence, not a complete-answer quality or speed claim.Correctness hold
A subsequent Llama3.1-8B diagnostic found NaNs in both cold and warm 128-token serial traces. Independent inspection of the frozen source confirms that the legacy Q/K core selects a dense F32 reader while receiving packed Q8 activations: a 589,824-byte binding versus a 2,097,152-byte F32 span at 128 x 4096. The first Q/K projections produce NaNs; Q6 V remains finite. Tracing forces serial execution, so ordinary graph output was not directly checked. Resolve this contract mismatch before acceptance; prior 128-token timing gains are withheld as correctness-qualified performance claims.
Separately, two original paired-Q4 fixtures retain four failing observations across replays. Constant-fixture relative L2 is 0.016664 (limit 0.01; maximum absolute error about 7.47e-8); the varied fixture passes scalar L2 at 0.006352 but fails CPU pointwise comparisons. The path uses F16 WMMA accumulators and the CPU reference quantizes activations. Outputs match the earlier control byte-for-byte, establishing no restoration delta, not absolute correctness. Tolerances, references, and accumulators are unchanged.
Separating layout from metadata reuse
A separate controlled Llama3.1-8B Q4_K_M experiment at 66 tokens measured standard-layout throughput of 1,185 -> 1,382 tok/s with reuse and row64 throughput of 1,120 -> 1,379 tok/s. Paired-block gains were +16.68% and +23.13%, respectively. This supports an interaction between layout and reuse, but the larger row64 gain closes its initial deficit: with reuse enabled, row64's measured model throughput is 0.28% lower. Row64 helps the paired FFN kernel (+18.29% versus standard with reuse) while six single-matrix kernels are 7.5-12.2% slower. These results do not establish overall equivalence or partition the original combined gain, because residency and Q6 routes were controlled. All samples were retained; 28 finite captured-output checks matched bitwise. The experimental source remains separate from this PR.
Requirements