Не рекомендовал бы использовать совсем модели ниже 12b в фактологии, арифметике и других точных задачах. Сам когда-то тестировал несколько 8b моделей, они все ошибались в банальных вопросах даже про самых известных людей или других моментах, кстати приведенная здесь Мистраль 8b в их числе. Вероятно модели с параметрами выше 20b в этом плане сколько-то лучше, но лично я их бы не использовал для точных вопросов тоже.
А вообще небольшие современные модельки на 4-8-12b очень даже хороши для некоторых задач. Я например использую их для не сложных Function Calling (часто через промпты), для переводов простых текстов (например новостей), для суммаризации, оценки материалов на разные вещи (например сложность чтения), для практики английского (об этом хочу написать статью) и тд тд, много применений можно найти.
Из последних нравятся модельки gemma3-12b, gemma3-4b, qwen3-8b и много других, даже относительно старые gemma2-9b и qwen2-7b тоже хороши и влезают в GPU 12Gb (кванты 6/8).
Когда давно еще тестировал (из малых) например wizardlm2-7b и openchat3.6-8b, поболтать на русском было очень неплохо (тогда еще было не много моделей умеющих нормально в русский), правда модельки уже старые, ну и не для фактологии 100%.
Использую для некоторых локальных задач квантованные НЕ function calling модели, например Gemma2 7b, функции описываю своими словами в промпте, ответ прошу предоставить в формате json-like. Все работает очень хорошо, если не работает сразу, правим промпт. Для разных групп запросов/задач разные промпты. Ваша реализация показалась странной, зачем-то какой фреймворк, который даже между 3мя простейшими функциями не смог выбрать нужную, ну это совсем не серьезно. Простые функции в состоянии определить модель уровня Gemma2 2b (2 млрд параметров), даже прилично квантованная.
Позже хочу написать статью, как я реализовал свой function calling на локальных моделях, можете подписаться на меня здесь.
Может будет интересно, писал здесь небольшой пост по теме: Сколько стоит «Спасибо» для Сэма Альтмана. Там про то, сколько могут стоить простые, фактически бессмысленные, финальные сообщения от пользователя вроде "спасибо", "ок", "пока" и тп (вероятно дорого)
Для расчета глубины используется DepthAnythingV2 (можно и другие аналогичные применять). Для параллакса NumPy и OpenCV, в скриптах же все очевидно вроде
Наверное это будет очень долго. В текущей реализации на нескольких потоках один фильм обрабатывается в районе суток на модели Large. То что вы описали это добавочно еще один ресурсозатратный стек обработки. Да и ни к чему это, по большому счету.
переделал на чтение видео по кадрам из python, инференс, покадровая запись. Никаких 500 гб не понадобилось
Разобрался что вы имели в виду, вероятно речь про промежуточный сервер на VapourSynth. Возможно позже я включу такую опцию, но придется много чего переделать. Да и настораживает, что в процессе где-то что-то зависнет (да хоть свет выключат), а время на обработку фильма от 8 часов и выше, вплоть до 2х суток (в зависимости от продолжительности фильма), и тогда все по новой запускать. Ну и вопрос с потоками, я еще не сравнивал, может покадрово в потоках быстрее будет, но это не точно. Зато место на диске не требует, это да, большой плюс. Аудио-дорожки можно после подключить.
Там я увеличивал фильм с помощью модели SwinIR, которую вы здесь также вскользь упомянули. Получилось вполне прилично, и самое главное - без артефактов, вроде появления лица вместо глаза )
До этого пробовал делать то же самое через Real-ESRGAN, не понравилось, очень заметна синтетичность, особенно на сильно замыленных видео/изображениях. Но Real-ESRGAN позволяет легко дотренировать модель, хотя руки так и не дошли (муторно собирать и подготавливать датасет). Зато базовый SwinIR вполне прилично скейлит из коробки, хоть и не идеально.
Какие косяки сразу бросились в глаза - часто деревья и траву сильно меняет, прямо видно как рисует отсебятину. Там в статье есть несколько скриншотов. Но в целом, для апскейла видео, очень неплохо.
Я использовал модель SwinIR, а до неё описываемый здесь Real-ESRGAN. SwinIR качественнее, меньше пластилиновости, которая очень заметна у Real-ESRGAN. Пока не идеально, но вполне годно, уже несколько фильмов восстановил, смотреть приятно, очень близко к реальному HD
с помощью фреймсервера (avisynth или питоновский vapoursynth), это стандартный способ для "видео-в-видео". ffmpeg принимает на вход скрипты этих фреймсерверов (они открывают видео, на лету обрабатывают его и отдают ffmpeg'у, он кодирует)
Один кадр обрабатывается в несколько секунд, все кадры этого фильма в районе 5 суток. Разве тут как-то поможет фреймсервер? Основной потребитель ресурсов - именно работа модели с кадром, все прочие вещи, такие как загрузка и сохранение фреймов, их подготовка - там доли секунд.
Кадр на самом деле 720x480 (Storage AR = 720/480 = 3/2), но с вытянутыми вверх пикселями (Pixel AR = 8/9) и физически на экране он должен иметь соотношение сторон Display AR = Storage AR Pixel AR = 3/2 8/9 = 4/3 = 640/480 = 720/540. Лучше оквадрачивать кадр до 720x540 вместо 640x480, чтобы 11% горизонтального разрешения не терять.
Вот тут я не уверен точно. Несколькими способами я получил фактическое разрешение 640x480. Тут получается, что оба 640x480 и 720x540 нестандартные разрешения, поэтому тем более сложно понять какое оно на самом деле.
И, опять таки, если брать 720x540, тогда в фреймах будут вытянутые по вертикали пиксели + в теории точные по горизонтали (я бы вообще не верил прописанным параметрам диска). Нужно ли это, если мы затем передаем кадр на апскейл?
В общем, еще раз спасибо за полезную информацию. Я все-таки надеюсь этот диск был редким... редчайшим исключением, и в дальнейшем не придется заниматься подобной эквилибристикой (я с ним намучался изрядно).
Нет, я проверял отдельные вобы также, причем каждый отдельно, в том числе смотрел их в hex-редакторе, там была прописана не верная информация в служебных битах.
Нет никаких проблем в склейке вобов, мы ведь затем просто распаковываем их на кадры, не более. С другими дисками проблем не было.
Есть возможность обрабатывать напрямую видео-в-видео
А вы не описывали это? Например, в этой статье я написал какие грабли могут встретиться с DVD VOB (MPEG-2), там и FPS может сбиться и ширина кадра. Интересно какое решение вы нашли исходя из этого.
Сколько ж оно денег скушает за один консилиум?
Не рекомендовал бы использовать совсем модели ниже 12b в фактологии, арифметике и других точных задачах. Сам когда-то тестировал несколько 8b моделей, они все ошибались в банальных вопросах даже про самых известных людей или других моментах, кстати приведенная здесь Мистраль 8b в их числе. Вероятно модели с параметрами выше 20b в этом плане сколько-то лучше, но лично я их бы не использовал для точных вопросов тоже.
А вообще небольшие современные модельки на 4-8-12b очень даже хороши для некоторых задач. Я например использую их для не сложных Function Calling (часто через промпты), для переводов простых текстов (например новостей), для суммаризации, оценки материалов на разные вещи (например сложность чтения), для практики английского (об этом хочу написать статью) и тд тд, много применений можно найти.
Из последних нравятся модельки gemma3-12b, gemma3-4b, qwen3-8b и много других, даже относительно старые gemma2-9b и qwen2-7b тоже хороши и влезают в GPU 12Gb (кванты 6/8).
Когда давно еще тестировал (из малых) например wizardlm2-7b и openchat3.6-8b, поболтать на русском было очень неплохо (тогда еще было не много моделей умеющих нормально в русский), правда модельки уже старые, ну и не для фактологии 100%.
Спасибо за статью, сэкономили часть времени.
Писал статью по этой теме, внизу там есть ссылки на оригинал и апскейлнутое видео:
https://habr.com/ru/articles/904784/
Спасибо большое! Удивительно, что до сих пор применяются такие относительно старые модели как Tacotron и Tortoise.
Если получится уточнить:
Как происходит тюн через sft, это специально записанные отрывки текстов с нужной интонацией?
Цитата:
модель отлично читала вслух научпоп, а художественная литература давалась ей с трудом. Но в итоге мы научили её читать одинаково хорошо.Тот же вопрос.
И есть ли где посмотреть больше технических деталей?
Использую для некоторых локальных задач квантованные НЕ function calling модели, например Gemma2 7b, функции описываю своими словами в промпте, ответ прошу предоставить в формате json-like. Все работает очень хорошо, если не работает сразу, правим промпт. Для разных групп запросов/задач разные промпты. Ваша реализация показалась странной, зачем-то какой фреймворк, который даже между 3мя простейшими функциями не смог выбрать нужную, ну это совсем не серьезно. Простые функции в состоянии определить модель уровня Gemma2 2b (2 млрд параметров), даже прилично квантованная.
Позже хочу написать статью, как я реализовал свой function calling на локальных моделях, можете подписаться на меня здесь.
Может будет интересно, писал здесь небольшой пост по теме: Сколько стоит «Спасибо» для Сэма Альтмана. Там про то, сколько могут стоить простые, фактически бессмысленные, финальные сообщения от пользователя вроде "спасибо", "ок", "пока" и тп (вероятно дорого)
Библиотека чего? Не вполне понятен вопрос.
Для расчета глубины используется DepthAnythingV2 (можно и другие аналогичные применять). Для параллакса NumPy и OpenCV, в скриптах же все очевидно вроде
Наверное это будет очень долго. В текущей реализации на нескольких потоках один фильм обрабатывается в районе суток на модели Large. То что вы описали это добавочно еще один ресурсозатратный стек обработки. Да и ни к чему это, по большому счету.
В статье же написано про VapourSynth, как один из вариантов для связки с Python.
Разобрался что вы имели в виду, вероятно речь про промежуточный сервер на VapourSynth. Возможно позже я включу такую опцию, но придется много чего переделать. Да и настораживает, что в процессе где-то что-то зависнет (да хоть свет выключат), а время на обработку фильма от 8 часов и выше, вплоть до 2х суток (в зависимости от продолжительности фильма), и тогда все по новой запускать. Ну и вопрос с потоками, я еще не сравнивал, может покадрово в потоках быстрее будет, но это не точно. Зато место на диске не требует, это да, большой плюс. Аудио-дорожки можно после подключить.
Все таки наверное могут, раз каждый квартал выходят бенчи, где LLM решают задачи лучше стольки-то процентов людей, задачи, которые раньше не видели.
Прямо сейчас посмотрел ifo и затем vob. Первый все наврал, и даже vob наврал меньше.
В данном случае диск кривой, я к этому склоняюсь. До этого скейлил другой диск, никаких проблем не было.
Прикрепил ваши комментарии к статье, может быть кому-то еще будут полезны. Спасибо большое.
Добрый день! Чуть дополню материал своей недавней статьей здесь.
Там я увеличивал фильм с помощью модели SwinIR, которую вы здесь также вскользь упомянули. Получилось вполне прилично, и самое главное - без артефактов, вроде появления лица вместо глаза )
До этого пробовал делать то же самое через Real-ESRGAN, не понравилось, очень заметна синтетичность, особенно на сильно замыленных видео/изображениях. Но Real-ESRGAN позволяет легко дотренировать модель, хотя руки так и не дошли (муторно собирать и подготавливать датасет). Зато базовый SwinIR вполне прилично скейлит из коробки, хоть и не идеально.
Какие косяки сразу бросились в глаза - часто деревья и траву сильно меняет, прямо видно как рисует отсебятину. Там в статье есть несколько скриншотов. Но в целом, для апскейла видео, очень неплохо.
В общем, если будет интересно, можете заглянуть )
НЛО это скорее исключение из опытных лабораторий ) Но сама возможность их появления на "улучшенных" изображениях конечно же настрораживает.
Насчет видео, можете почитать мою статью здесь:
Апскейл видео из SD (DVD) в FullHD/4K современными нейросетями
Там я апскейлил фильм, получилось вполне годно, и никаких приведений и пришельцев )
Написал статью по теме, может будет интересно:
Апскейл видео из SD (DVD) в FullHD/4K современными нейросетями
Я использовал модель SwinIR, а до неё описываемый здесь Real-ESRGAN. SwinIR качественнее, меньше пластилиновости, которая очень заметна у Real-ESRGAN. Пока не идеально, но вполне годно, уже несколько фильмов восстановил, смотреть приятно, очень близко к реальному HD
Спасибо большое!
Один кадр обрабатывается в несколько секунд, все кадры этого фильма в районе 5 суток. Разве тут как-то поможет фреймсервер? Основной потребитель ресурсов - именно работа модели с кадром, все прочие вещи, такие как загрузка и сохранение фреймов, их подготовка - там доли секунд.
Вот тут я не уверен точно. Несколькими способами я получил фактическое разрешение 640x480. Тут получается, что оба 640x480 и 720x540 нестандартные разрешения, поэтому тем более сложно понять какое оно на самом деле.
И, опять таки, если брать 720x540, тогда в фреймах будут вытянутые по вертикали пиксели + в теории точные по горизонтали (я бы вообще не верил прописанным параметрам диска). Нужно ли это, если мы затем передаем кадр на апскейл?
В общем, еще раз спасибо за полезную информацию. Я все-таки надеюсь этот диск был редким... редчайшим исключением, и в дальнейшем не придется заниматься подобной эквилибристикой (я с ним намучался изрядно).
По отдельным, да, никаких существенных проблем здесь не вижу
Нет, я проверял отдельные вобы также, причем каждый отдельно, в том числе смотрел их в hex-редакторе, там была прописана не верная информация в служебных битах.
Нет никаких проблем в склейке вобов, мы ведь затем просто распаковываем их на кадры, не более. С другими дисками проблем не было.
Спасибо большое, надо будет ознакомиться.
А вы не описывали это? Например, в этой статье я написал какие грабли могут встретиться с DVD VOB (MPEG-2), там и FPS может сбиться и ширина кадра. Интересно какое решение вы нашли исходя из этого.