Для голосового управления whisper от openai, найти можно здесь: HF: tasks-->automatic-speech-recognition. Есть еще от Герганова
whisper.cpp, который запускается и на телефоне, как и llama.cpp, если еще добавить TTS, то можно общаться голосом, что в связке дает локальную "Алису", только умнее ее в разы. Где-то 6 гигов оперативки надо в телефоне и 7B-4bit модель запустится.
Для видео сетки на HF: tasks-->text-to-video, есть еще вот тут какая-то онлайн-хреновина
https://runwayml.com/Кроме самого популярного
stable-diffusion-webui от AUTOMATIC1111, для картинок есть еще более интересная штуковина
ComfyUI, которая работает сразу из коробки и на картах и на CPU, в отличие от AUTOMATIC1111, где требуется некоторый пердолинг для запуска на CPU. Прикольный интерфейс, который почему-то мне напоминает creately, в котором я когда-то делал всякие схемы, например, вот эту
https://docs.polycat.finance/tokenomics/feeconomicsПочему вообще упоминаю про CPU? Для картинок за глаза хватит 12-гиговой карты 3060 (по крайней мере пока что), но вот для языковых моделей такая карта в общем-то "ни о чем". Там по любому надо гору оперативки, или карту на 80 гигов (в идеале) или хотя бы на 40-48. 24-гиговые позволят запускать не более чем 12 гиговые модели, а это только около 12-13B параметров. Либо запускать до 30B квантованные. Но на квантованных перплексия заметно хуже.
Если же запускать с разгрузкой в оперативку, то так и этак скорость падает, т.к. оперативка медленней видеопамяти, тогда какой толк в дорогой карте на 24 гига. Так что или карта от 40 гигов, или 3060 плюс оперативка по максимому, и CPU само собой помощнее. Такой конфиг и для картинок и для LLM более-менее компромиссный по деньгам в сравнении с картой за сотни тысяч р. Кстати от карты-то требуется только память и тензорные ядра, а все остальные игровые прибамбасы в чипе вообще не нужны. Возможно когда-то будут производить более дешевые решения типа TPU или нейронных процессоров, т.е. игровые чипы и нейронки разделятся на два направления по более доступным ценам.
_____________________
Насчет головоломки. Этот способ опирается на уже известные ключи. Известно, что ключи распределены в диапазонах случайно. А что это значит? Это нормальное распределение, т.е. распределение Гаусса. Кстати, на гитхабе когда-то встретил исследование на тему головоломки, где автор пришел к такому же выводу. Значения ключей "собираются" к середине. Но у нас очень маленькая выборка - всего 160 значений.
Зато в целом распределение ключей подчиняется правилу: каждый следующий лежит в диапазоне, равном всему пространству до него. Получается экспоненциальная зависимость (очень грубо). Таким образом, попробуем создать аппроксимирующую функцию, задав в качестве аргумента, например, начало диапазона, или лучше середину каждого диапазона (чтобы уменьшить среднюю ошибку аппроксимации и чтобы коэфф. корреляции и детерминации были поближе к 1), а значениями функции будут известные ключи. При этом наверное можно откинуть первые штук 10 ключей, т.к. из-за маленьких диапазонов они скорей всего будут только вредить.
Получится что-то вроде показательной функции с чудовищной ошибкой в 20-30% (причем в обе стороны), т.е. получилось гавно. Ну тогда сделаем по-другому. Берем log
2 от каждого ключа (с максимальным кол-вом знаков после запятой, например 20), а у аргументов просто показатели степеней диапазонов (если же задавали середины, то тоже берем log
2). Здесь получается уже другой расклад, причем можно аппроксимировать даже линейной функцией, где коэфф. дет. и корр. с тремя-четырьмя 9 после запятой, что очень близко к 1, а ошибка аппроксимации около 0.9%.
Однако, 0.9% в обе стороны грубо 2%, т.е. сужение диапазона поиска в 50 раз, что эквивалентно снижению битового диапазона где-то на 5 (чуть больше). Это же достигается (типа достигается), например, делением открытого ключа (правда там выходит уже 32 ключа, что и снижает скорость поиска тоже, так что деление такая же херня). Кроме того, на высоких диапазонах расчет аппроксимированного ключа будет давать охрененную ошибку, т.к. даже 20 цифр после запятой в логарифме это мало. Ладно, есть еще способ аппроксимации. Подставляем свои аргументы и значения (не логарифмы, а исходные) в полином Ньютона или Лагранжа и решаем. Для этого можно заставить нейросеть написать например скрипт на питоне (не самому писать, потому что нейросеть это модно) и засунуть в Colab или решить локально.
Готовый ответ полинома, естественно неверный, но допустим, тоже плюс-минус 1%. Таким образом имеем на данном шаге то, до чего и так уже можно догадаться, то есть ничего нового. Можно долбиться внутри этих 2-х % безрезультатно очень долго. Потому как есть лишь вероятность, что ключ там. Наверное это даже хуже, чем поиск по всему битовому диапазону, т.к. в последнем случае точно известно что ключ там. Тогда как повысить еще вероятность? А вот тут применяем новый подход (по крайней мере такой способ не встречал). "Извращенный" метод Монте-Карло. Посмотрим на график аппроксимирующей функции. Если аппроксимацию делали по логарифмам, то это почти прямая. Представим границы средней ошибки как две другие линии сверху и снизу функции. Получится нечто вроде расширяющейся от начала функции полосы, этакая тень конуса. Где каждое новое 2%-ое пространство больше в два раза предыдущего и это очень хреново для поиска.
Допустим эта полоса - это такая речка, если мы будем закидывать туда сачок по всей длине реки, то шанс поймать рыбку увеличится. Т.е. этакий метод Монте-Карло наоборот. На практике это означает такие шаги: вычислить в каждом битовом диапазоне ширину "полосы" и прочесывать каждый диапазон. Всего осталось 84 битовых диапазона. Ну шанс, что в одном из них ключ лежит именно внутри полосы явно имеет место быть. Однако, у этого способа есть масса недостатков, таких как, например, такие: я сам в него не особо верю, временная сложность (О большое) ни хрена не понизилась, на высоких битовых диапазонах с открытым ключем выигрыш в сужении пространства поиска сомнителен в силу вероятностного расчета, в низких диапазонах без открытого ключа тоже самое, т.к. скорость поиска низкая. Тем не менее, может быть кому-то пригодится этот способ. А если уж поможет найти ключ, не премините пожаловать и мне кусочек от найденных битков.
В другой раз опишу более интересный, но еще более "дикий" метод, который с вышеописанным не имеет ничего общего (и не опирается на известные ключи), но пока не совсем представляю как его практически реализовать.
