Skip to content

docs(research): GPTQ max-exactness fix -- partial, closes ~35% of the RTN gap - #554

Open
gHashTag wants to merge 1 commit into
mainfrom
research/gptq-maxexact-fix-2026-08-11
Open

docs(research): GPTQ max-exactness fix -- partial, closes ~35% of the RTN gap#554
gHashTag wants to merge 1 commit into
mainfrom
research/gptq-maxexact-fix-2026-08-11

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Runs the fix proposed but not executed in THEOREM_2026-08-09.md: protect each group's per-row maximal element from GPTQ's sequential compensation (equivalent to processing it first, since an exactly-quantised column propagates zero error).

  • max-exactness restored: 95.3% -> 0.4% blocks with an inexact row-max
  • perplexity: GPTQ-original 17.7047 -> GPTQ-fixed 17.5860 (-0.1186, same run)
  • still worse than RTN 4-bit (17.3667) by +0.2194 -- gptq_gate.py's pass condition remains unmet
  • reproduction note: this environment's GPTQ-original (17.7047) differs from THEOREM's (17.7846) by 0.08; all comparisons here are within-run to control for that

Conclusion: max-exactness destruction explains part (~35%) of GPTQ's gap to RTN under block-max scaling, not all of it. Residual mechanism unidentified -- open question, not run further (5-bit / promote-only / cross-model out of scope for this PR).

Adds research/block/gptq_maxexact_fix.py, research/block/GPTQ_MAXEXACT_FIX_2026-08-11.md.

… RTN gap, does not clear the gate

Runs the fix proposed but not executed in THEOREM_2026-08-09.md: protect each group's
per-row maximal element from GPTQ's sequential compensation (equivalent to processing it
first, since an exactly-quantised column propagates zero error).

- max-exactness restored: 95.3% -> 0.4% blocks with an inexact row-max
- perplexity: GPTQ-original 17.7047 -> GPTQ-fixed 17.5860 (-0.1186, same run)
- still worse than RTN 4-bit (17.3667) by +0.2194 -- gptq_gate.py's pass condition remains unmet
- reproduction note: this environment's GPTQ-original (17.7047) differs from THEOREM's
  (17.7846) by 0.08; all comparisons here are within-run to control for that

Conclusion: max-exactness destruction explains part (~35%) of GPTQ's gap to RTN under
block-max scaling, not all of it. Residual mechanism unidentified -- open question.

Adds: research/block/gptq_maxexact_fix.py, research/block/GPTQ_MAXEXACT_FIX_2026-08-11.md
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