Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Q4_K/Q6_K parity tests compare the ggml-faithful int8 (block_q8_K) native kernels against exact-float scalar references — divergence is intended activation-quant loss, not a bug

オープン
  • 何か問題がありますか？
#944 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
c, kotlin
領域
machine-learning

調査の方向性

Start by comparing q4k_matmul.c and q6k_matmul.c with the commonMain Kotlin scalar references and llama.cpp’s dequantize_row_q4_K/q6_K ground truth. Run the pinned-pattern reproducers in the FFM/jvmTest and K/N nativeTest parity suites, then audit Q5_K unpacking for the same issue. Done means the correct implementation matches the reference and the regressions are covered by both parity suites.

索引モデルが issue の本文から書いたものです。

説明

Found while validating the Android JNI bridge (#920): with block data whose FP16 scales are pinned to 1.0 AND the packed 6-bit sub-block scale bytes set to a fixed pattern, the C kernels (q4k_matmul.c/q6k_matmul.c, host gcc build via FFM — same archive the K/N tests link) and the commonMain Kotlin scalar references diverge far beyond float noise. The divergence is bit-identical across compilers and flags (with/without -ffast-math, NDK clang x86_64 and host gcc produce the same deltas) — i.e. a deterministic decode disagreement, not reassociation.

Host reproducer (JVM, NativeQ*MatmulKernel FFM vs ScalarQ*_KMatmulKernel), 256×16, kotlin.random.Random(42) block bytes and Random(42+i).nextFloat()-0.5f inputs:

Q4_K — pin d=1.0f16 @0-1, dMin=1.0f16 @2-3, scale bytes 4..15 = 0x21:

row 0 scalar=315.83618 ffm=317.25122 diff=1.415
row 1 scalar=30.482384 ffm=36.86566  diff=6.383   <- 21% relative
row 2 scalar=667.81525 ffm=667.81464 diff=0.0006  <- agrees
row 3 scalar=-152.33876 ffm=-148.93115 diff=3.408

Q6_K — pin int8 sub-block scales @192-207 = 1, d=1.0f16 @208-209:

row 0 scalar=81.53886 ffm=81.18377 diff=0.355
row 1 scalar=118.43294 ffm=117.88452 diff=0.548
row 2 scalar=97.66035 ffm=98.00478 diff=0.344
row 3 scalar=35.540615 ffm=36.182453 diff=0.642

The per-row pattern (some rows agree to 1e-4, others off by units) points at the 6-bit scale/min bit-extraction — Q4_K packs 8 scales + 8 mins across bytes 4..15 with the upper sub-blocks split across high bits, exactly the kind of layout where two implementations can disagree for specific bit patterns while random data averages the error into invisibility.

Why existing tests miss it: the NativeKn*/FFM parity suites randomize the scale bytes, which inflates row sums to thousands — the systematic delta (units) then hides under rel < 1e-4 … and when it doesn't, the absolute tolerances (5e-2..2e0) absorb it. The suites validate statistically typical data, not adversarial scale patterns.

What's needed:

  1. Decide which side is ggml-correct (llama.cpp dequantize_row_q4_K/q6_K is ground truth) — the answer decides whether real Q4_K_M/Q6_K checkpoints decode slightly wrong via the fast path today.
  2. Fix the wrong side; add the pinned-pattern reproducers above to the parity suites (both FFM/jvmTest and K/N nativeTest) so the class of bug stays caught.
  3. Audit Q5_K's unpacking for the same class of issue (same packing scheme as Q4_K).

Happy to help bisect against the llama.cpp reference.

Refs #920

主要言語
Kotlin
スター
52
フォーク
15
平均マージ
1日 8時間
マージ済み PR（30日）
37

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

SKaiNET-developers/SKaiNET のほかの issue

SKaiNET-developers/SKaiNET の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。