fix: verificação dos kernels L2-L5 + investigação de performance CPU - #1
Merged
Conversation
…completa) - fwht: remove normalização 1/n² de acdc_forward_f32 — convenção era inconsistente com acdc_forward_i8 (unnormalized per spec CLAUDE.md); blocos empilhados em acdc_gemv produziam saída ~n² fora de escala - fwht: corrige comentário do bound de erro ACDC: "→ 0 as n→∞" era invertido; energia capturada ≈ 1/n → 0, erro relativo ≈ 1 - 1/n → 1 - tropical: corrige fórmula de escala em tropical_attn_scores: dividia por head_dim em vez de sqrtf(head_dim), tornando os pesos softmax incorretos (seleção Top-K não afetada, era escala monotônica) - hrr: remove acumulação incorreta em hrr_cleanup_iter — modo residual somava entradas do codebook a cada iteração em vez de retornar a entrada convergida - wht: corrige loop em unpack_i2s_block: col < 32 → col < QK_WHT/4, eliminando leitura além do bloco em ARM (QK=64, bloco=16 bytes) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…real Verificação algébrica e de desempenho dos kernels da "álgebra esquecida": - L2 (wht): corrige unpack_i2s_block (passo *32 -> QK_WHT/4) que escrevia fora dos limites no build escalar (QK_WHT=32). Remove narrativa falsa de Walsh-Hadamard (é máscara ternária, não WHT) e a alegação de "~5x mais rápido": medido ~3-6x MAIS LENTO que o maddubs do L1. - L3 (fwht): corrige acdc_error que ainda aplicava 1/n² após o fix anterior em acdc_forward_f32, descasando de acdc_project por n² e reportando ~100% de erro até para W perfeitamente ACDC. Roteado pelo próprio kernel de inferência para nunca mais divergir. - docs: mathematical-foundations.md alinhado à realidade medida (L2 lento, L3/L5 exigem re-treino, L4 com premissa quebrada, nada integrado ao llama.cpp). wht_benchmark.py marcado como medição NumPy, não do kernel C. - novo: utils/l2_vs_maddubs_microbench.cpp mede os dois kernels reais nos mesmos dados, confirma igualdade bit-a-bit e a lentidão do L2. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- baseline I2_S AVX2 medido; build já usa -march=native (sem ganho grátis) - achado prático: usar -t 4 (núcleos físicos); -t 8 colapsa (~0.4 t/s) - autotune do gemm-config: "vencedor" R8 era ruído térmico, refutado por A-B-A controlado (o baseline oscila mais que a diferença). Default mantido. - evidências: stats/tune_quick.csv, stats/ab_verify.txt Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Verificação dos kernels L2–L5 (correções de bugs + afirmações falsas) e investigação de performance CPU do BitNet-2B-4T. Motor já é SOTA (I2_S AVX2); L2–L5 não aceleram o modelo pré-treinado; autotune do gemm-config não bate o default além do ruído. Achado prático: usar -t 4 (–t 8 colapsa). Detalhes em docs/relatorio-cpu-bitnet.md.
🤖 Generated with Claude Code