gemma4-search-doc-sm8650-a8w8-int4embed

gemma4-search-doc · SM8650 · A8W8 + 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

Nenhum — o modelo principal (a parte que roda na NPU) é byte-a-byte o mesmo grafo do baseline A8W8 já validado em produção. Só as tabelas de embedding mudam.

Velocidade esperada

Idêntica ao baseline — o grafo que roda na NPU não muda.

Recomendação

Primeira opção a testar. Menor risco possível: se isolar o ganho de comprimir os embedders já resolve o estouro de RAM, nem vale a pena arriscar qualidade com as outras duas.

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.