Skip to content

arm PR104.x: mixed-quant row sharding arm series (PR104.0 roofline / PR104.1 spike / PR104.2 production) - #113

Open
ddvnguyen wants to merge 8 commits into
baselinefrom
fork/pr104-mixed-quant-arm
Open

ddvnguyen wants to merge 8 commits into
baselinefrom
fork/pr104-mixed-quant-arm

Conversation

@ddvnguyen

Copy link
Copy Markdown
Owner

Arm series spec for per-device quantization of row-split weight slices: Q4_K rows on the 3060, Q5/Q6_K rows on the 5060 Ti. Row ratios unchanged; bytes-per-token rebalanced onto bandwidth-proportional lines. Attacks the rig's actual wall (3060 bandwidth x VRAM-forced share) instead of porting htsglang-style asymmetric TP.

What this PR contains

Docs only (docs/arms/pr104-mixed-quant-row-sharding.md):

  • Roofline: current ~41.5/58.5 VRAM-pinned split -> ~31 ms/token (~32 t/s raw); balanced mixed-quant -> ~21 ms (~47 t/s raw ceiling, +30-45%), plus 3-4 GB freed VRAM
  • PR104.0: paper roofline from measured per-device BW (no code) — go/no-go >= 45 t/s predicted, else kill-switch
  • PR104.1: spike via LLAMA_ARG_SPLIT_ROW_QUANT=q4_k,q6_k (default = model type, rebuild-free A/B); bars >= 43 ship-min / >= 45 target
  • PR104.2: production — imatrix-aware requant, llama-perplexity KL quality gate vs unsharded baseline, CLI + docs, MATRIX_ROW_PADDING per slice type
  • Implementation spec: per-device slice type in ggml_tensor_extra_gpu, init_tensor/set_tensor changes (ggml-cuda.cu:929/979), mul_mat dispatch from slice_type[id]; no graph/kernel/ggml-core changes

Test plan

  • PR104.0 roofline measured and go/no-go decided in writing
  • PR104.1 spike A/B on PR105.0 topology, bars checked
  • PR104.2 quality gate (KL) agreed threshold pass
  • Results into arm report

Sequencing: PR104.0 can run in parallel with PR103.0 coding; PR104.1/2 build on PR103.0's landed base.

AI usage disclosure: YES — arm spec drafted by AI (opencode) from local row-split source verification (split buffer single-type limitation at ggml-cuda.cu:929/950/979); implementation code to be human-authored/owned.

Hydra Engineering added 8 commits September 10, 2026 00:39
Measured per-device bandwidth via llama-bench single-device probes
(5060 Ti Q4 27B tg 25.95 => 427 GB/s, 3060 9B proxy 60.74 => 345 GB/s,
not spec sheets). Q5 27B does not fit single 5060 Ti (spills to CPU,
pp collapses 978->70), so 3060 uses 9B/4B proxies. Roofline predicts
37.0 t/s raw (ts-pinned) and 41.4 t/s raw balanced, both >=48 t/s with
conservative 1.3x MTP, so GO for PR104.1.

Assisted-by: opencode/muse-spark-1.2-contributor
- per-device slice_type[] on ggml_tensor_extra_gpu (common.cuh:1222)
- LLAMA_ARG_SPLIT_ROW_QUANT=q4_k,q6_k helper with call_once parsing,
  lower-case ggml_type_name matching, default/fallback, quantized guard,
  GGML_LOG_INFO active log + static init to make rebuild-free A/B observable
- build verified with CUDACXX 13.2.2 arch 86;120a FA all quants (ggml-cuda
  417s, llama-server link ok)
- live single-GPU verification: env active log, VRAM 14137 MiB, health ok,
  no bytes change yet (split buffer not yet reintroduced; cuda split
  only in sycl). Comparison real 25.9 vs projection 53.8-78.7 pending
  full split buffer wiring for PR104.2 (get_row_rounding/get_row_split/
  ggml_nbytes_split + init/set/mul_mat dispatch from slice_type)
- docs: append PR104.1 Spike Results
Storage/rebalancing proven via VRAM (9B 2747/2929, 27B 8283/9001 vs stub 14137 flat) from ported CUDA split buffer (get_row_rounding/split, nbytes_split, split_buffer_type, init/set/get, contiguous_data). Compute path blocked: illegal access at common.cuh:1641 cudaFuncGetAttributes during graph capture, reproduces even vanilla row-split (isolated to split-src MUL_MAT -> scale), needs compute-sanitizer + MMQ peer-async port. Recommendation defer; rig clean 1/1, not restarting production for PR105.0.

Updates PR #113 on fork/pr104-mixed-quant-arm.
- gate CUDA graph capture off for graph nodes with split-buffer srcs
  (mid-capture false returns were silently skipped in release builds,
  leaving malformed captured graphs)
- harden the contiguous-gather guard: abort on contiguous copy on the
  wrong compute device instead of reading across devices without peer
  access
- gate fusion windows in try_fuse so fused kernels (which bypass the
  per-op gather and read split tensor->data directly) never dispatch
  with split-backed srcs
- document why split get_base must stay a pseudo pointer
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