[EPIC][SIMD][P0] Implementação física SIMD/AVX no Simplicio Local

[wesleysimplicio]

Objetivo

Transformar o suporte SIMD/ISA do simplicio-local em execução física real no hot path de inferência, cobrindo AVX2, AVX-512/VNNI, AMX quando disponível e os caminhos ARM já existentes, sempre com fallback escalar seguro e promoção baseada em medição.

Esta épica complementa o contrato fechado em #247. O PR #287 adicionou o planner local_data_plane/kernel_dispatch.py e testes de seleção/cache, mas ainda falta conectar essa decisão aos kernels realmente executados. Hoje também existem implementações físicas fragmentadas entre runtime/cpu, runtime/neon e engine/c, sem uma autoridade única de dispatch e sem cobertura AVX2 canônica no runtime C++.

Princípios obrigatórios

1. Execução real, não somente planner/metadata/mock.
2. O artefato universal deve iniciar em CPUs sem AVX e nunca causar illegal instruction.
3. O caminho escalar/reference permanece sempre disponível.
4. Reutilizar kernels maduros de engine/c, llama.cpp ou upstream compatível antes de criar forks paralelos.
5. Kernel otimizado só vira padrão após correção diferencial e ganho medido no workload aplicável.
6. SIMD e multithreading são dimensões separadas; o planner deve controlar ambas sem oversubscription.
7. Toda seleção deve registrar kernel solicitado, kernel efetivo, ISA detectada, fallback e motivo.
8. Nenhum ganho será declarado com benchmark sintético isolado apenas; deve existir validação end-to-end com modelo real.
9. O trabalho deve ser reproduzível localmente, sem depender de GitHub Actions pago.
10. 1 issue = 1 slot de implementação.

Relações existentes

• Estende [INFERENCE-FIRST][07][P0] SIMD/quant kernel dispatch por ISA com fallback portátil e autotuning #247 — dispatch por ISA e cache de tuning.
• Integra [INFERENCE-FIRST][02][P0] Detectar topologia L1/L2/L3, ISA, bandwidth, NUMA e classes de core #242 — descoberta de topologia/ISA.
• Reaproveita [#116.11] M4 — Otimização de kernels CPU (sem GPU): NEON-SDOT, AVX-512-VNNI, threading e prefetch, guiada por medição #128 — kernels CPU do engine, threading e prefetch.
• Preserva Sprint 04: NEON Hot Paths #16 — caminhos NEON.
• Complementa DoD layer 4: AFL++ for the quantization kernels, seeded with a real-weight corpus #145 — fuzzing de kernels quantizados.
• Deve alimentar [INFERENCE-FIRST][10][P0] Unified ExecutionPlan v2: compute/memory/KV/cache/device placement in one deterministic planner #250 — ExecutionPlan v2.

Entregas

As issues filhas desta épica devem cobrir:

• registry e dispatch físico único;
• detecção ISA e fat binary portátil;
• kernels AVX2 quantizados;
• especializações AVX-512/VNNI/AMX;
• kernels FP32/BF16/FP16;
• operações auxiliares do Transformer;
• layout, packing, tiling e batching que alimentem SIMD;
• autotuning real e cache persistente;
• correctness, benchmarks, telemetria e release gates.

Issues filhas — 1 issue = 1 slot

• [SIMD][01][P0] Unificar registry de kernels e conectar o planner ao hot path real #305 — Registry único e ligação planner → hot path físico.
• [SIMD][02][P0] Detecção ISA portátil e fat binary seguro em Linux, Windows e macOS #306 — Detecção ISA portátil e fat binary seguro.
• [SIMD][03][P0] Implementar kernels AVX2 Q8/Q4 para matvec, matmul e dequantização #307 — Kernels AVX2 Q8/Q4 para matvec, matmul e dequantização.
• [SIMD][04][P1] Especializar AVX-512/VNNI e AMX com gating por shape, clock e temperatura #308 — Especializações AVX-512/VNNI e AMX com gating medido.
• [SIMD][05][P0] Implementar kernels SIMD FP32/BF16/FP16 para matvec e matmul #309 — Kernels SIMD FP32/BF16/FP16.
• [SIMD][06][P0] Vetorizar hot paths auxiliares: RMSNorm, RoPE, softmax, ativações e KV #310 — RMSNorm, RoPE, softmax, ativações e KV vetorizados.
• [SIMD][07][P0] Layout, packing, tiling e batching para alimentar os vetores #311 — Layout, packing, tiling e batching para alimentar SIMD.
• [SIMD][08][P0] Autotuning real bounded e cache persistente por hardware, modelo e kernel #312 — Autotuning físico bounded e cache persistente completo.
• [SIMD][09][P0] Gates de correctness, benchmark, telemetria e release para SIMD #313 — Correctness, benchmark, telemetria e release gates.

Ordem recomendada

1. [SIMD][01][P0] Unificar registry de kernels e conectar o planner ao hot path real #305 e [SIMD][02][P0] Detecção ISA portátil e fat binary seguro em Linux, Windows e macOS #306 estabelecem a autoridade e a segurança do dispatch.
2. [SIMD][03][P0] Implementar kernels AVX2 Q8/Q4 para matvec, matmul e dequantização #307 e [SIMD][05][P0] Implementar kernels SIMD FP32/BF16/FP16 para matvec e matmul #309 entregam os kernels base; [SIMD][04][P1] Especializar AVX-512/VNNI e AMX com gating por shape, clock e temperatura #308 especializa hardware avançado.
3. [SIMD][06][P0] Vetorizar hot paths auxiliares: RMSNorm, RoPE, softmax, ativações e KV #310 e [SIMD][07][P0] Layout, packing, tiling e batching para alimentar os vetores #311 completam o hot path e a alimentação dos vetores.
4. [SIMD][08][P0] Autotuning real bounded e cache persistente por hardware, modelo e kernel #312 mede e seleciona fisicamente as variantes.
5. [SIMD][09][P0] Gates de correctness, benchmark, telemetria e release para SIMD #313 consolida as provas e o release gate.

Definition of Done

• Todas as issues filhas concluídas com PR/commit vinculado.
• O ExecutionPlan altera comprovadamente o kernel físico executado.
• AVX2 funciona em x86-64 compatível sem exigir AVX-512.
• AVX-512/VNNI/AMX são opcionais e nunca quebram hosts incompatíveis.
• Linux, Windows e macOS possuem detecção/fallback documentados; ARM preserva NEON e extensões disponíveis.
• Scalar vs SIMD passa por testes diferenciais, tails, desalinhamento, overflow e entradas especiais.
• Benchmark de kernel e benchmark end-to-end com modelo real publicam metodologia, hardware, quantização e resultados.
• Kernel sem ganho, com regressão numérica ou com pressão térmica inadequada é desativado automaticamente.
• Receipts mostram ISA, kernel, tuning, fallback, wall time, CPU time e métricas disponíveis.
• Existe kill switch para desligar SIMD/autotuning sem recompilar.

Regra de encerramento

Não fechar esta épica por existência de interfaces ou testes de contrato. O encerramento exige execução nativa observável e evidência de correção/desempenho em artefato instalado.

[wesleysimplicio]

Implementação consolidada no PR #323, mesclado na main. PRs filhos mesclados: #314–#322. Validações locais: 192 testes Python, make -C engine/c test-c, compilação C++ com -Wall -Wextra -Wpedantic -Werror, smoke do int8 pelo KernelRegistry e simplicio 3.8.35 contracts/runtime smoke. A issue permanece aberta porque a própria regra de encerramento exige artefato instalado + modelo real + evidência de desempenho em hardware aplicável; esta imagem não possui CMake/GTest nem host ARM/AVX-512/AMX.