Conversation
…a decode-speed LOSS vs the mixed pin
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.
Config-only arm. Doc:
docs/arms/arm-uniform-q8-kv.md(in this branch).Question
Does
-ctv q8_0 -ctvd q8_0(all-main KV q8_0, K already q8_0) decode faster than the production mixed pin (-ctv q5_1 -ctvd q5_1)?Answer: NO — uniform q8_0 is a measured LOSS
Mechanism: q5_1 V = 7.5 bit/elem vs q8_0 = 8.25 bit/elem ⇒ uniform q8_0 packs ~+10% more V bytes (+17% KV buffer bytes measured: main KV 2176 vs 1856 MiB @ 65k/np1); FA kernels dequantize V to f16 in-kernel either way, so uniformity buys no speed and the extra bytes tax every attention step, amplified with depth (per the strict per-turn decode-latency table in the doc).
Production-shape fit
Uniform q8_0 BOOTS at
-c 262144 -np 2 -ts 27,38: no OOM, KV 8704 MiB main + 544 draft; VRAM at the same 15847/11910 ceiling via UM net. Fit is NOT the blocker — speed is."40 tok/s for the production pin" provenance (requested grep)
No single documented figure exists. Closest sources:
docs/investigations/740-results-report.md(arms 102/103/104, 146176×3 ctx, kv_unified OFF): single-request 150-token eval band 40.5–49.7 tok/s ("arm102's 46.2–46.3 class"); 2-concurrent 17.6 tok/s/slot.PROJECT_STATUS.mdDoesn't compile due to missing headers for memcpy and assert ggml-org/llama.cpp#381 timeline: Arm 017 "36–39 tok/s decode" (multiturn, 98K ctx shape), older Doesn't compile due to missing headers for memcpy and assert ggml-org/llama.cpp#381 ~31 tok/s sustained.CLAUDE.mdhardware table "~200 tok/s" = single-GPU ceiling (different class).A "reproduce 40 tok/s" request needs to pin the protocol — the 740 single-shot eval at its 146k shape is the closest documented band (note: that shape is NOT the current 747.4 262k production pin).
Rig protocol honored both bounds: stop pod → drain (1 MiB/1 MiB) → fit boot → kill → boot/bench → kill → drain →
pod start→ health 200 ×2 → 15847/11911 verified.