As versões iniciais do Voice Pro utilizavam o ONNX Runtime com as exportações oficiais de Qwen ASR em formato ONNX. Funcionava, mas tornava-se difícil colocá-lo em produção. Eis os problemas que encontramos e por que o aplicativo agora roda em llama.cpp com modelos quantizados em GGUF.
Problema 1: tamanho da instalação
Uma versão para Windows do Voice Pro com ONNX Runtime + o provedor DirectML + o provedor CUDA + os pesos do modelo foi lançada 430 MB. O Linux era semelhante. É pedir demais que alguém baixe uma ferramenta de ditado que ainda não experimentou.
A compilação GGUF é 83 MB no Windows. O binário compilado do llama.cpp é minúsculo, o modelo base quantizado tem ~60 MB (vs ~200 MB como ONNX fp16), e não enviamos DLLs de provedor de execução separadas para CPU, CUDA, DirectML e Vulkan — o llama.cpp lida com todos os quatro com um único binário.
Problema 2: inicialização a frio
O ONNX Runtime com DirectML, em uma instalação do Windows sem serviços em execução, levou de 3 a 5 segundos para inicializar a sessão de inferência. Toda vez que o usuário pressionava a tecla de atalho pela primeira vez após um reinício, enfrentava esse atraso. Isso é inaceitável para uma ferramenta de ditado, cujo objetivo principal é permitir que as pessoas falem imediatamente.
O llama.cpp carrega o modelo GGUF em ~400 ms a frio no mesmo hardware. Pesos com memory-mapped, sem etapa de compilação de grafo, sem wheel de runtime para inicializar.
Problema 3: o inferno da embalagem
O ONNX Runtime é fornecido como um arquivo Python wheel, o que significa wheels diferentes para cada versão do Python, sistema operacional e arquitetura de CPU. Adicione aceleração por GPU e você multiplica pela versão do CUDA e pela versão do DirectML. O Nuitka (nosso empacotador) continuava a incluir a variante errada. Tínhamos scripts de compilação com seis ramificações condicionais.
O llama.cpp é um único binário C++. Ele é compilado uma vez por plataforma (Windows x64, Linux x64) e enviado como um executável nativo que o Voice Pro chama. Nenhuma dependência de runtime Python para inferência — o Python é apenas a cola.
Problema 4: qualidade em tamanhos pequenos
A preocupação com a quantização é a perda de precisão. Na prática, o Qwen3-ASR 0.6B quantizado Q5_K_M (nosso modelo base) mede dentro de 0,3% de WER da versão completa ONNX fp16 no nosso conjunto de avaliação interno. Q4_0 é visivelmente pior, então enviamos Q5_K_M como padrão. Usuários que querem precisão máxima podem baixar o nível fp16 pelo gerenciador de modelos.
O que desistimos
O suporte a ASR do llama.cpp é mais recente que o do ONNX Runtime. Algumas arquiteturas de modelos exóticas ainda não têm conversores GGUF. Por enquanto isso não importa — o Qwen3-ASR converte limamente — mas se quisermos testar um modelo de ASR radicalmente diferente no futuro, talvez precisemos manter o caminho do ONNX como fallback.
Resultado líquido: instalação 5 vezes mais pequena, arranque a frio ~10 vezes mais rápido, um único binário para compilar em vez de doze. Devíamos ter feito isto desde o primeiro dia.