Нейросети на базе Keras, Tensorflow, Torch и другие. Теория и практика применения. Pyhton/C++/Pascal (20 стр)

Добил до конца потоковый режим: сделал запись с микрофона в реальном времени.

Всё работает, правда речь англофицируется жёстко, что придаёт дополнительного ржача при прослушивании.

Также пропадают индивидуальные признаки говорящего, говорит другой голос, сохраняется только смысл сообщения.

Важные моменты:

1) WavLM подавляет шумы и фон 50 Гц.  С микрофона у меня идёт сильная наводка 50 Гц, а в раскодированном варианте её нет.

2) Большая задержка: почти 4 секунды. Это при условии, если подавать на кодек по 64 фрейма (каждый фрейм по 20 мс). Такова расплата  за поток и реальное время: пришлось делать кольцевые буфера на нескольких уровнях:

- на этапе получения порции входного аудио

- на этапе приёма кодированных векторов с шагом 50% от размера сжатого по времени сегмента

- на этапе интерполяции латентного пространства с шагом окна 50% от размера разжатого сегмента

- на этапе воспроизведения звука шаг окна 50%

3) Англофикация речи. Установил, что связка WavLM + Vocos НЕ зависит от языка,  а FocalNET зависит.

Следующими шагами будут:

- попробовать укоротить сегмент до 32 фреймов вместо 64.  Нужно будет переобучить FocalNET.

- обучить FocalNET на русской речи

Gradius
> Большая задержка: почти 4 секунды.

Спец-ухищрениями удалось уменьшить задержку до 1,3 секунды.  При этом длина сегмента (64 фрейма) осталась прежней.

Gradius
> обучить FocalNET на русской речи

Обучил. Стало лучше.

1) Вариант с весами FocalNet, предоставленных автором кодека (обучен на английской речи, на полных высказываниях):

2) Мой вариант весов FocalNet (обучен на русской речи, на фиксированный сегмент):

Это 163 бит/c.

Список фраз для проверки:

Класс!

Затащил программу кодека и модели в окружение C++ на ПК.  Работает.

Теперь самое мучительное: заставить это работать на голом железе.  И тут я чешу репу:

либо портировать громоздкий Torch, либо конвертить в ONNX и искать полностью открытый фреймворк, который может инференс ONNX.

Либо радикальный метод: переписать все слои с нуля и разобраться с форматом весов сети.

Посмотрел, как это сделано в STM32 + STMCube:  эти засранцы предлагают цеплять либу, которая умеет запускать ONNX, скомпиленную в GCC.  Открыты только хедеры, сама либа естественно закрытая.

Gradius

.
Думаю это не просто.

Gradius
> Либо радикальный метод: переписать все слои с нуля и разобраться с форматом весов сети.
Если нету готовой библиотеки, этот вариант выглядит наиболее реальным, особенно если не пытаться сразу изобретать швейцарский нож, а решать одну конкретную задачу.

Пока не определился, как именно буду загонять нейросеть на голое железо.  Хочется простых и гениальных решений, как frugally deep для Keras, который я уже перенёс на C++/ARM под голое железо.

Сконвертировал модели в ONNX с помощью либы onnx на Питоне. На этом этапе можно забыть про динамический размер входных тензоров для нейросеток: требуется указывать фиксированный размер:

LEN=320*64

onnx_program=torch.onnx.export(coder,torch.rand(1,LEN),dynamo=True)
onnx_program.save("coder.onnx")

onnx_model=onnx.load("coder.onnx")
onnx.checker.check_model(onnx_model)

Ну и фиг бы с ним: для потоковой/каузальной версии кодека все размеры тензоров строго фиксированы.

Без ошибок и предупреждений:

Далее попробовал запустить модели ONNX с помощью либы onnxruntime.  Из подводных камней следует отметить, что ONNX модели возвращают тензоры, обёрнутые в лист(list). Так как у меня модели возвращают только один тензор, пришлось "снимать шелуху" - конвертить лист в тензор (индексация - нулевой элемент листа - это и есть первый тензор):

lats=compressor.run(None,{"input_1":feats[0]})

Плюс ещё нужно явно указывать имя входного слоя (в строке выше имя слоя - input_1).

Посмотреть имена слоёв (и многое другое) можно в программе Netron:

Следует понимать, что при конвертировании моделей из Torch в ONNX, мы лишаемся всей мощи Торча, и наши модели "застывают" - все размеры тензоров фиксируются.

А также имеем статический проход - сильно сложные условия внутри модели куролесить не выйдет: нужен детерминизм в работе. К счастью, пришлось проверить и подправить в FocalNET пару мест, связанных с вычислением падов - пады не понадобились, так как размерность по оси времени подбрана так, что вычисление пада =0.

Ну и конечно, пришлось переписывать программу на Питоне:  менять torch на numpy. К счастью, все взаимозаменяемые аналоги есть (у большинства число, порядок и формат аргументов совпадают, но опять же - не везде!) :

torch.bartlett_window() => numpy.bartlett()
torch.hann_window() => numpy.hanning()

torchaudio.load() => scipy.io.wavfile.read()
torchaudio.save() => scipy.io.wavfile.write()

torch.zeros() => numpy.zeros()

torch.unsqueeze() => numpy.expand_dims()

torch.cat() => numpy.concatenate()
torch.transpose() => numpy.transpose()

По началу пришлось гонять тензоры из numpy в torch и наоборот (во время адаптации запуска моделей ONNX):

device="cpu" #"cuda"
torch_tensor = torch.from_numpy(numpy_array).to(device)
numpy_tensor = torch_tensor.numpy().cpu()

Плюс следить за форматом входных и выходных данных: иногда приходится конвертить аудиоданные в диапазон [-1..+1] и обратно в [-32768..+32767] - torch это делает сам, а для numpy приходится делить и умножать на 32768.

Ну и размеры тензоров пришлось подправить - там где загружается аудио и сохраняется: добавить/убрать одно измерение:

load_audio.shape=(1,LEN)
save_audio.shape=(LEN,)

В итоге, полностью исключил torch, остались numpy и onnxruntime. Проверил кодек: ONNX модели работают на слух идентично, как и Torch модели.

Прорверил на бит-экзактность. Всё-же выходные звуковые волны для Torch и ONNX версий немного отличаются - отличия почти не заметны:

Возможно, из-за ошибки округления:

Дальше надо искать легковесный рантайм для ONNX, наподобие frugally deep.

Правда, кастомные слои не обойти - в модели вокодера(Vocos) есть слой обратного преобразования Фурье, а в кодере - Трансформеры.

Пробежался по моделям.  Нужны вот такие кирпичики:

Unsqueeze Transpose Conv LayerNormalization Div Erf Add Mul Slice Reshape
Abs Cast MatMul ReduceSum Less Clip Split Gather Softmax Sigmoid Sub
Sin Cos Exp Concat DFT Pow Expand Col2lm ScatterND ScatterElements Reciprocal

Как я понял, лесапеды из Гитхаба тут не прокатят - слишком много всего нужно.  Поэтому остаются только промышленные поделия. Как вариант  ONNX Runtime от Микрософта. Но он сильно громоздкий - Dll-ки под сотню мегабайт )))

Переписал кодек под ONNXruntime от Микрософта.  Добился одинакового результата работы с PyTorch: формы звуковой волны на выходе совпадают.

Код на ONNXruntime(C++) получился немного громоздким. На Питоне код смотрится компактнее.

Некоторые вещи пришлось сделать самостоятельно: транспонирование, объединение, фильтрация, нормирование вектора, бинарное квантование. Массивы, циклы, степени, корни...

Быстро вьехать в API ONNXruntime помогла китайская дока (c++ inference):

https://blog.csdn.net/juluwangriyue/article/details/118230181

Инит модели, загрузка входного тензора, выполнение, выгрузка из выходного тензора. Более ничего не надо. Остальное - логика.

Корень зла был в этой фигне (не компилировалось): имя файла модели - строка из двух-байтных символов:

#ifdef _WIN32
 const wchar_t *coder_file=L"coder.onnx";
#else
 const char *coder_file="coder.onnx";
#endif

На счёт "кирпичиков": кодеку нужна поддержка opset версии 18, не ниже. 

Поэтому только портирование микрософтовского кода, без вариантов :)))

Gradius

Очень круто!
Я наверное совсем отстал (старость не радость), кроме кода вообще ничего не воспринимаю. Но есть догадка, что это переводится.
))

Слово "портирование" почему то не вызывает отторжения.

Gradius
> Но он сильно громоздкий - Dll-ки под сотню мегабайт )))

Нагнал с размером. На самом деле нужна только onnxruntime.dll - её размер чуть больше 12 МБ.

Задача: получить статическую либу onnxruntime для ARM Cortex-A7/A8 под голое железо. Что-то мне подсказывает, что T113-s3 с его 128 МБ памяти не хватит. Придётся использовать доску Olinuxino A13, там внешняя память до 2 ГБ.

Интересно, что и какой размер кода/данных выхватит кодек из этой либы?  Вот за что я не люблю эти DLL и SO, так это за то, что эти тонны груза надо постоянно таскать вместе с целевой программой. Статические либы в этом плане смотрятся выигрышнее, особенно на платформах с ограниченной памятью и одним активным приложением.

flint2
> кроме кода вообще ничего не воспринимаю. Но есть догадка, что это переводится.

Там ничего переводить не нужно. Достаточно того кода, который приведён на картинке. Ну и есть встроенный переводчик в Firefox - очень удобно:

Gradius

Сжал что ли?
Gradius

Какая разница?
Разница в объёмах только в заголовок COFF, а там байты, ка не кило.
Gradius

Но почти тютелька в тютельку.
Есть программы, и сам писал dll2OBJ, или можно перевести dll в двоичный массив в программе и сделать загрузчик, но это лишний мусорный код примерно килобайт 300.
Но это... не знаю зачем... если есть готовые dlll.
Другое дело от операционки отказаться и 'тупо сделать автомат' - 'загрузочный сектор', как на винте, установки, если нужны, и entry point. но тогда нужен двоичный снимок памяти твоей программы, а не файлы и операционка.
Которая только нужна в виде загрузщика COFF.
Наверное нужно быдет reloc`и сделать и для dll и для твоего exe - адреса будут отличатся.
Но это просто и не накладно. Берёшь все адлеса из заголовка и прибавляешь\вычитаешь смещение.
Нримерно 250 байт скомпилированнвй код. Если что - сделаю.
Короче, ето всё можно из ПЗУ запустить переписав часть в ОЗУ. Есть нюансы в пользу улучшения, но пока не суть.

flint2
> Сжал что ли?

Нет. Просто быстро глянул на PDB, а показалось что DLL.

Вот для сравнения Torch для C++:

Кодек работает, если onnxruntime вообще сбилдить на самых минимальных условиях:

Gradius

Понятно.
Я и сам хотел потом сказать про абстракции винды,но сервер висел.
Так и не дождался пока заработает...

Если что, тему не закрывай.
Есть вопрос, вернее мысль, хочу посоветоваться.
Пока я её думаю. ))

Удалось собрать onnxruntime последней версии в полностью статическом варианте. Использовал ключи, котрые собирают с минимально необходимым функционалом:

При этом, я ещё не начал редактировать сами сорцы. Полагаю, можно будет отсечь ещё больше, если переправить сорцы и установить дефайны, влияющие на сборку уже в пределах каждой либы.

Gradius

Ахренеть.