Comments 26
RTX 3090 (Gigabyte AORUS BOX)
ооо, как-то эта штука прошла мимо меня! спасибо за наводку, буду тоже экспериментировать
вообще давно существует vgpu, и относительно недавно парни рассказывали что завели пачку рабочих мест для инженеров работающих в CAD'ах при помощи qemu/kvm и vgpu (инструкцию оставили мне эту). но попробовать это дано не каждому ибо гейвидия запрещает сие для geforce (способы обойти конечно существуют, но там сомнительные костыли ломающиеся при апдейтах) а покупать что-то сииииильно дороже для того чтобы потестировать "а зайдёт ли" согласен не любой бизнес (да и говорят стабильность этого решения именно у зелёных хромает), у красных вроде бы это тоже доступно, но с ходу вменяемой инструкции не нагуглилось, так что теми для кого такую игрушку делал я было решено купить не одну супервидюху а пачку "попроще" и выделить каждой виртуалке по одной выделенной видимокарте и поскольку куплены были не квадры и не теслы (жифорсы и купить БУ попроще, и продать если "не зайдёт" не проблема) то пришлось костылять обманку для того чтобы драйвер был не вкурсе что работает в виртуальном окружении (vfio, kvm=off и всё такое, ну тут ничего нового, все кто хотел давно видел такие вот мануалы) и тут конечно красные бы подошли больше ибо их драйвер для любой видюхи не запрещает работу в виртуалке.
в общем решения есть, и их даже несколько, но оставляет желать лучшего.
с другой стороны иногда создаётся впечатление что оно не особо кому-то и надо (к примеру раньше блендер из коробки мог подключаться к пулу серверов с хорошими GPU для удалённого распределённого рендеринга, а пару лет назад я для этого нагуглил только полузаброшенный плагин, да и цены на железо нынче такие что проще арендовать пару часов у тех у кого уже есть чем собирать себе дорогущее железо которое очень может быть не окупится или вообще крякнет через пол годика).
P.S.: всё вышеописанное - личный опыт костыляния "быстрых" решений для относительно небольших компаний, я прекрасно понимаю что крупные "рыбы" навроде яндекса или газпрома могут позволить себе закупить морской контейнер заполненный теслами для работы с самописными ИИ потому что вопервых есть на что, а во вторых давно посчитали окупится или нет, я же говорю про более приземлённые кейсы.
P.P.S.: всё вышеописанное - не самая актуальная информация, "общественными" GPU я не интересовался уже пару лет, вполне возможно что ситуация поменялась (например была новость что зелёные разрешили на geforce некоторые вещи которые ранее позволялись только для quadro, но там же в комментах читал что оно всё равно не работает).
Да, все так.
гейвидия запрещает сие для geforce
С GeForce не получается штатно виртуализовать. Мне кажется, даже если платить "за место" (есть такие лицензии), все равно карточки нужны классом выше.
Даже обычный pci passthrough у меня не прокатил. ESX именно для этой железки отказывался (хотя диски норм прокидывал в TrueNAS)
А вот насчет "каждому по слабенькой карточке" - есть нюанс. Иногда бывают операции, требующие дофига видеопамяти. Условно говоря, на 4 картах по 4GB вы можете худо-бедно что-то генерить. Но вот LoRa натренировать - не получится. Да и если работает один из чевтырех человек, максимум - он использует все ресурсы своей карты. Даже, если другие простаивают. А в режиме "разделения времени" - свои картинки он будет получать за 3 секунды, а не за 15.
Вариантов действительно много, включая облачные. И, кстати, для них я тоже считаю более эффективным делить мощную видеокарту между несколькими пользователями. Ну как я в предыдущем своем посте описывал поднять spot instance с Tesla в Azure. Ибо чаще всего это нужно в режиме "с человеком", когда оборудование простаивает ощутимую часть времени. И максимум его реусрсов требуется кратковременно.
Если идут долгие операции типа тренировки модели, разумеется, таких извращений не требуется.
Иногда бывают операции, требующие дофига видеопамяти. Условно говоря, на 4 картах по 4GB вы можете худо-бедно что-то генерить. Но вот LoRa натренировать - не получится.
К сожалению (хотя наверное к счастью) в том кейсе это были рабочие места для инженеров с CAD а не разрабов с ИИ. А они и работают всегда в один промежуток времени и предпочитают выделенные ресурсы. Так что тут скорее даже лучше что так а не vgpu.
"Жирафа" (GeForce) можно нарезать равными кусками и прокинуть в Hyper-V
https://github.com/jamesstringerparsec/Easy-GPU-PV
Тут встаёт вопрос о том что между hyper-v и qemu/kvm (ну или вмварью или xen) мало кто выберет первое, ибо костыли костылями, а доверять рабочий процесс виндам сцыкотно и где возможно выбрать альтернативу - лучше выбрать альтернативу. Понятно что внутри гостей винда (ибо солидворкс и автокад в вайне не работают и нативных версий не имеют) но вот на хосте.. Нет спасибо, нервы дороже.
Спасибо за ссылку! Там не только про паравиртуализацию, но и Parsec заинтересовал :)
VirtualGL https://virtualgl.org
Позволяет удаленный рендеринг для нескольких рабочих станций на одном сервере с GPU (и наоборот - собрать кластер из серверов с GPU для распределенного рендеринга). Лично я его только для проброса по сети использовал. Для разделения не пробовал.
Кажется, этот подход отличается от Juice. Можете кратенько описать, что вы пробрасывали?
К примеру, "какая-то 3D софтина была установлена на обычном ПК и использовала GPU на удаленном сервере". Или софтина крутилась на сервере, а на ПК только результаты ее труда отображались?
Особенно интересно в свете "на сервере стоит Линукс, а на клиентском ПК может выполняться хоть Linux, хоть Windows приложение"
Сервер (сильный GPU) - только *nix
Клиент (слабый GPU) - *nix/MS Windows/MacOS
3D cофт запускается на сервере (т.е. это приложение под *nix, либо запущенное в Wine).
На клиенте будет картинка.
Если 3D софт под MS Windows, то его можно запустить на *nix сервере внутри Oracle Virtuabox или VMware (нужно, чтобы средство виртуализации поддерживало эмуляцию видеокарты с 3D ускорением). На клиенте будет картинка с виртуальной машины.
Все эти сценарии описаны в документации.
Пробрасывал игрушки типа NFS от EAGames. Но в документации приведен и более серьезный софт типа Matlab, Ansys, pytorch.
Да, подход определенно отличается. Согласно описанию Juice не поддерживает отображение картинки на Linux клиенте (CUDA only (ML/AI/HPC)).
И community версия ограничена только некоммерческим использованием.
Посматриваю на какую нибудь материнку майнерского класса с 6-10 слотами PCIeх16 что бы собирать потихоньку кластер из видеокарт. Выглядит так, будто вполне реально получить домашний сервачёк с порядка 150 ГБ видеопамяти, который будет тихо гудеть куллерами на балконе. А там глядишь и 100В+ модели потянуть можно.
кажется интерфейс от автоматика,
позволяет отправлять последовательные запросы с разных IP ( у него под капотом gradio который на fastapi), без вот этих танцев с бубнами
А что сразу NVIDIA в начале, AMD в общем-то никто не отменял :)
Господи запускать несколько портов, рендерить, вы совсем что ли? Есть Comfy UI, все пользователи с одного порта, а раз видео память больше не тратится на каждый клиент у которого запущена автоматик, то и генерить можно моделями попрожорливей, а значит и качество вырастает.
А вообще пост с тем что надо поставить в батник запуска флажок shared это не контент для хабра, особенно что про этот флажок есть документация в репе и автоматика и comfyui
Особенно не одобряю написание целой статьи про флажок запуска
В SD/AI все настолько быстро меняется, что статьи годичной давности вообще мало ценности представляют.
Comfy UI, безусловно, штука мощная. Сейчас. Но не год с лишним назад.
о, присоединюсь к некропостингу))
стало ли лучше в плане совместной работы у автоматика? Планируем дать доступ к вебморде нескольким пользователям. Ознакомился с Invoke - они строго позиционируют себя как одиночное локальное решение, у автоматика же возможность каждому свою вкладку есть, но там могут быть зависоны/баги
Не тестировал специально, но, мне кажется, новая вкладка подхватывает старые установки. Если после этого что-то поменяете (например, смените модель) и сгенерируете изображение, вы получите ожидаемое.
Если пользователь на исходной вкладке просто нажмет "сгенерировать", он получит странное. Ибо в интерфейсе он будет по-прежнему видеть свою модель, а в бэкенде она поменялась, и его генерация пойдет по другим параметрам, хотя он у себя ничего не менял.
Как минимум такое проверьте. По-моему не полечилось. Боюсь, это by design, ибо смена модели - ресурсоемкая операция, а не просто параметр, отправляемый по кнопке "генерируй".
Спасибо за ответ)
Да, вчера проверил, так и есть, попробую еще завести там юзеров и авторизацию, интересно вдруг изменится поведение.
На самом деле странное поведение не самое страшное, страшнее если оно будет крашиться/зависать.
Беглый ресерч каких-то адекватных решений не нашел, из вашей статьи еще на заметку GPU over IP пока себе оставил, может быть стоит попробовать в этом направлении подумать
если интересно, пока нашли такую опцию sd_model_checkpoint:
https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/8574
она позволяет выбрать модель, которая запушится при нажатии на кнопку generate вместе с остальными параметрами) похоже на решение проблемы смены моделей
Да, должно это решить, спасибо.
Надеюсь, остальное типа вывести выбор Lora в интерфейс, а не в промпте указывать, какой-нибудь Negative Prompt Weight или OpenPose передают свои установки при каждой генерации и не влияют на чужие сессии.
Впрочем, у вас вроде не слишком критично, если какие-то мелочи и взглюкнут слегка. Я бы только отдельный watchdog поставил. Типа если web интерфейс перестал отвечать, перезапусти SD.
Много нас, а GPU один. Как делиться?