Pavel Zloi@efreelancer
Software Developer
Информация
- В рейтинге
- Не участвует
- Откуда
- Москва, Москва и Московская обл., Россия
- Зарегистрирован
- Активность
Специализация
Бэкенд разработчик, ML разработчик
Ведущий
Linux
PHP
Python
Многопоточность
Нейронные сети
Машинное обучение
Kubernetes
Golang
Высоконагруженные системы
Выбор датасета влияет на то как будет вести себя квантованная модель, а для публикации взял датасет wiki лишь в качестве простого и понятного примера.
Можно попробовать поэксперементировать с количеством слоёв, но в целом да, для создания imatrix чтобы было быстро нужно хорошее железо и порядочно памяти.
Привет! Рад, что статья понравилась.
Время генерации сильно зависит от видеокарты, от того, сколько слоёв загружено на неё, и от размера обучающего датасета. В примере, описанном мною в данной публикации, использовался RTX 4090 на 24 ГБ, в которую было загружено 10 слоёв модели.
Подготовка imatrix происходила на 500 сэмплах из датасета русской Википедии (один сэмпл - одна страница). На это ушло примерно 2 часа. Квантование GGUF, используя полученный imatrix, заняло ещё пару минут - процесс очень быстрый, долго только imatrix файл создать, но всё равно это в разы быстрее, чем обучать адаптер через LoRA, например.
Рад, что пригодилось, сам давно хотел разобраться с этой темой.
Не рекламы ради, но я как-раз задачу специфического обучения маленьких моделей на разных наборах датасетов решил в проекте impruver.
В нём можно найти множество конфигураций для обучения малюток семейства rugpt3 {small, medium, large} под датасеты saiga2 и некоторые другие, даже модели навроде nanoGPT from-scratch обучать можно, но в целом мой проект позволяет дообучить какую угодно модель доступную через
transformers.Полагаю имеется ввиду то как это делают на сайтах морфемного анализа, пожалуй это можно было бы через рендер картинки, скажем какой-нибудь canvas или типа того, реализовать
Хорошая идейка, подумаю, спасибо!
Занятный проект, судя по коду поддерживается ограниченное количество моделей и предполагается использовать оригинальные веса, без квантизации GGUF или какой бы то ни было ещё, docker-образов нет, плюс смотрю там нет автоматики и все конфигурации будет необходимо прописывать вручную.
Cпасибо за ссылочку, проект пощупаю и сравню с аналогами.
Если я правильно понял в формате RPC схемы все низовые работы по инференсу происходят на стороне бэкенда, следовательно если мы имеем систему из нескольких серверов работа будет распределена между ними равномерно (с учётом доступной
rpc-serverRAM или VRAM), следовательно можно предположить, что вся работа с кешем и его хранение будет происходить на бэкенде.Косвенно для меня это подтверждается в этой issue на гитхабе, если в двух словах, то пользователь жалуется на сегфолты когда он отключает кеширование на стороне бэкенда.
А вот как это всё синхронизируется мне пока что непонятно.
Серъёзных замеров ещё не проводил, поэтому точных цифр дать не смогу, производительность замерял на следующих схемах: 1x RTX 3050, 1x RTX 4090 и пара из этих видекарт соединённых по RPC (сеть 1Гбит), вот gist с замерами.
Это кажется странным, но в режиме RPC инференс либо чуть быстрее, либо такой же как на самой быстрой карте.
UPD. Добавлю, что основная моя цель была не в том, чтобы ускорить инференс (хотя это было бы приятным бонусом), а в том чтобы выпонять его на кластере из маломощных микрокомпьютеров, которые по отдельности не способны на инференс больших моделей, скажем на жмене RaspberryPi CM3.
Думаю это нужно для того чтобы запустить инференс можно было быстрее, так как инференс выполняет только после того как все слои будут выгружены на бэкенды. Иными словами если у есть модель скажем 13B и чекпоинты которой весят кажется 9Гб и есть два бэкенда нужно залить на каждый бэкенд 4.5Гб данных.
Следовательно моя гипотезав в том, что чем быстрее сеть, тем быстрее запустится инференс.
Добавил чуть больше букв в том месте где была цитата, чтобы было понятно, что там модель нагенерила.
У MTS была публикация про детоксикатор, в этой работе они как-раз создали модель, которая удаляет из сообщений "токсичность". А ещё есть метрика MERA под названием ruDetox, которая оценивает насколько хорошо русскоязычные модели справляются с задачами удаления ругательств из текста.
Так что в контексте языковых моделей под токсичностью имеют ввиду именно нецензурные выражения.
Ну а шуточная модель которую я обучил делает строго противоположную работу, отсюда и название "токсикатор" :)
Правильного ответа на данный вопрос к сожалению не знаю. Мне кажется, что различить подобное крайне сложно, лично у меня градация во время сборки датасета была простая: есть мат - токсичное, нет - обычное. Насколько это оптимальная градация думаю лучше у специалистов из области психологии или лингвистики уточнить.
Конечно можно, если соединить токсикатор и детоксикатор то может получиться неплохой бенчмарк, сейчас попробую собрать нечто подобное.
Вот результаты тестов на 100 образцах текста из сплита dev датасета toxicator-ru.
Примеры тут.
Отличное замечание, сейчас займусь скриптиком.
Приветствую! Уточните пожалуйста ошибку, если получится то ссылочкой на Gist, чтобы не писать много текста.
В корне проекта будет файл test_gigasaiga.py, он как-раз демонстрирует то как можно запустить дообученный мною слой LoRA адаптера. У Вас получилось его запустить? Заработало ли?
Покопался в исходных кодах проекта rulm, нашёл в скрипте train одну любопытную незадокументированную переменную окружения WORLD_SIZE, по умолчанию она равна 1, а если сделать больше 1, то включается режим DataParallel.
И дальше эти параметры передаются модели.
Пример использования:
У меня сегодня тоже возникла задача решить проблему с нехваткой памяти (уже правда в рамках обучения другой нейросети), поэтому полез настраивать device_map и max_memory опции, чтобы тренировка, если места мало, могла залезать в системную оперативную память, вот как сделал:
Попробуйте Mistral дообученную на датасетах rulm (есть демка на HuggingFace).