В первых версиях Voice Pro использовался ONNX Runtime вместе с официальными экспортными данными модели распознавания речи Qwen в формате ONNX. Это работало, но реализация этой схемы сопровождалась множеством проблем. Вот с чем мы столкнулись и почему теперь приложение работает на llama.cpp с моделями, квантованными в формате GGUF.
Проблема 1: размер установки
Вышла версия Voice Pro для Windows с ONNX Runtime + провайдером DirectML + провайдером CUDA + весами модели. 430 MB. С Linux было аналогично. Это слишком много требовать от человека, чтобы он скачивал инструмент для диктовки, который он еще не пробовал.
Версия GGUF — это 83 МБ в Windows. Компилированный бинарник llama.cpp имеет очень малый размер; квантизированная базовая модель занимает примерно 60 МБ (против примерно 200 МБ для формата FP16 в ONNX). Мы не поставляем отдельные DLL-файлы для выполнения на CPU, CUDA, DirectML и Vulkan — llama.cpp обрабатывает все четыре платформы с помощью одного бинарника.
Проблема 2: холодный старт
ONNX Runtime с DirectML на чистой установке Windows требовал 3–5 секунд для инициализации сессии инференса. Каждый раз, когда пользователь впервые нажимал горячую клавишу после перезагрузки, возникала такая задержка. Это неприемлемо для инструмента диктовки, где главная цель — «говорить сразу».
llama.cpp загружает модель GGUF за ~400 мс в холодном состоянии на том же оборудовании. Веса с отображением в памяти, без этапа компиляции графа, без необходимости инициализации wheel-пакета во время выполнения.
Проблема 3: кошмар упаковки
ONNX Runtime поставляется в виде Python-пакета, что означает разные wheel-пакеты для каждой версии Python, ОС и архитектуры процессора. Добавление ускорения GPU умножает количество вариантов на версию CUDA и версию DirectML. Nuitka (наш упаковщик) продолжал включать неправильный вариант. У нас были скрипты сборки с шестью условными ветвями.
llama.cpp — это единый бинарный файл на C++. Мы компилируем его один раз для каждой платформы (Windows x64, Linux x64) и поставляем как нативный исполняемый файл, который вызывает Voice Pro. Для вывода вообще не требуется среда выполнения Python — Python служит лишь связующим звеном.
Проблема 4: качество при малых размерах
Проблема квантизации — потеря точности. На практике квантизированная модель Qwen3-ASR 0.6B с параметрами Q5_K_M показывает показатель WER в пределах 0,3% от полной версии fp16 ONNX на нашем внутреннем наборе данных. Вариант Q4_0 заметно хуже, поэтому по умолчанию используется Q5_K_M. Пользователи, желающие максимальной точности, могут скачать версию fp16 из менеджера моделей.
От чего мы отказались
Поддержка ASR в llama.cpp новее, чем в ONNX Runtime. Для некоторых экзотических архитектур моделей пока еще нет конвертеров в GGUF. Пока это не имеет значения — Qwen3-ASR конвертируется чисто — но если мы захотим в будущем попробовать радикально другую модель ASR, нам, возможно, придется сохранить путь ONNX в качестве резервного варианта.
Итог: установка в 5 раз меньше, холодный старт примерно в 10 раз быстрее, один бинарный файл для сборки вместо двенадцати. Нам следовало сделать это с первого дня.