Las primeras versiones de Voice Pro utilizaban ONNX Runtime con las exportaciones oficiales de Qwen ASR en formato ONNX. Funcionaba, pero su implementación era complicada. He aquí los problemas con los que nos topamos y por qué ahora la aplicación funciona en llama.cpp con modelos cuantizados en GGUF.
Problema 1: tamaño de instalación
Una compilación de Windows de Voice Pro con ONNX Runtime, el proveedor DirectML, el proveedor CUDA y los pesos del modelo ascendió a 430 MB. Linux era similar. Es mucho pedirle a alguien que descargue una herramienta de dictado que aún no ha probado.
La compilación GGUF es 83 MB en Windows. El binario compilado de llama.cpp es diminuto, el modelo base cuantizado es de ~60 MB (frente a ~200 MB como ONNX fp16), y no enviamos DLLs de proveedor de ejecución separadas para CPU, CUDA, DirectML y Vulkan — llama.cpp maneja las cuatro con un solo binario.
Problema 2: arranque en frío
ONNX Runtime con DirectML en una instalación de Windows sin servicios en ejecución tardó entre 3 y 5 segundos en inicializar la sesión de inferencia. Cada vez que el usuario pulsaba la tecla de acceso rápido por primera vez tras un reinicio, experimentaba ese retraso. Inaceptable para una herramienta de dictado cuyo objetivo principal es «hablar de inmediato».
llama.cpp carga el modelo GGUF en ~400 ms en frío en el mismo hardware. Pesos mapeados en memoria, sin paso de compilación de gráficos, sin wheel de tiempo de ejecución que inicializar.
Problema 3: el infierno del empaquetado
ONNX Runtime se distribuye como un paquete Python wheel, lo que significa wheels diferentes por versión de Python, SO y arquitectura de CPU. Al agregar aceleración por GPU, se multiplica por la versión de CUDA y la versión de DirectML. Nuitka (nuestro empaquetador) seguía incluyendo la variante incorrecta. Teníamos scripts de compilación con seis ramas condicionales.
llama.cpp es un único binario en C++. Lo compilamos una vez por plataforma (Windows x64, Linux x64) y lo enviamos como un ejecutable nativo que Voice Pro llama. Sin dependencia de entorno de ejecución de Python para la inferencia en absoluto; Python es solo el pegamento.
Problema 4: calidad en tamaños pequeños
La preocupación con la cuantización es la pérdida de precisión. En la práctica, Qwen3-ASR 0.6B cuantizado con Q5_K_M (nuestro modelo base) mide dentro del 0,3% de WER de la versión completa ONNX fp16 en nuestro conjunto de evaluación interno. Q4_0 es notablemente peor, así que enviamos Q5_K_M como predeterminado. Los usuarios que quieran máxima precisión pueden descargar el nivel fp16 desde el gestor de modelos.
Lo que renunciamos
El soporte ASR de llama.cpp es más reciente que el de ONNX Runtime. Algunas arquitecturas de modelos exóticas aún no tienen conversores GGUF. Por ahora eso no importa, ya que Qwen3-ASR se convierte limpiamente; pero si queremos probar un modelo ASR radicalmente diferente en el futuro, quizás necesitemos mantener la ruta ONNX como fallback.
Resultado neto: una instalación 5 veces más pequeña, inicio en frío ~10 veces más rápido, un único binario para construir en lugar de doce. Deberíamos haberlo hecho desde el primer día.