macunaima/gemma4-search-doc-sm8650-a8w4-mlponly-int4embed
gemma4-search-doc · SM8650 · A8W4 (MLP-only) + embedders INT4
Quantização derivada do checkpoint gemma4-search-doc, compilada e empacotada especificamente para a NPU (HTP) da Qualcomm Snapdragon SM8650 — o SoC do Samsung Galaxy S24, alvo deste projeto. Sujeito aos Termos de Uso do Gemma.
Compilado via AOT com--soc-model SM8650. Roda através do runtime LiteRT-LM como um único arquivo.litertlm.
Tamanho
Esquema de quantização
Granularidade: per-channel em todos os pesos (o compilador HTP da Qualcomm não suporta blockwise — ver Qualcomm_QNN_Compiler.md no repo LiteRT). Os embedders (embedder.tflite, per_layer_embedder.tflite) nunca passam pelo compilador AOT — são tabelas de lookup puras, então a compressão ali não tem restrição de HTP.
Risco de qualidade
Baixo-médio. Só as camadas de MLP (que dominam a contagem de parâmetros num transformer) vão pra INT4; a atenção — historicamente mais sensível a quantização agressiva — continua em INT8, igual ao baseline.
Velocidade esperada
Neutra a levemente melhor no decode (geração token a token é limitada por banda de memória, não por cálculo — menos bytes de peso lidos por token nas camadas de MLP). Estimativa de engenharia, não medida no S24 ainda.
Recomendação
Meio-termo se a opção A8W8+embedders-INT4 não for suficiente.
Modelos irmãos (mesma base, outras receitas)
- gemma4-search-doc-sm8650-a8w8-int4embed
- gemma4-search-doc-sm8650-a8w4-mlponly-int4embed
- gemma4-search-doc-sm8650-a8w4-full-int4embed
Uma quarta receita (INT4 weight-only com dequantize explícito) foi testada e descartada: o compilador AOT da Qualcomm rejeita esse padrão inteiro (Op Dequantize does not support per-channel quant tensor) — não gerou modelo utilizável, por isso não tem repo.
Aviso
As estimativas de velocidade/qualidade acima são raciocínio de engenharia sobre a arquitetura (decode é limitado por banda de memória; MLP domina os parâmetros), não medições reais no dispositivo. Ainda não foram validadas num Galaxy S24 físico.
