Спасибо! Относительно недавно тоже делал коммуникации, но не в обучении, а моделировании. Интересно, куда тема движется, хотел ваши видео посмотреть, на VK плейлист есть, но пустой. На YouTube всё на месте. В MPI почему-то тоже до сих пор нет возможности агрегации в разных типах. Хотя довольно часто в моделировании встречается кейс что-то посчитать во float, а потом со всех нод в double собрать.
Коммуникации в NCCL кольцевидные, что обеспечивает минимальную нагрузку на сеть, но при увеличении размера кольца начинает быстро копиться задержка коммуникаций.
Коммуникации в NCCL не только кольцевидные. Тут можно посмотреть NVIDIA/nccl. Рассматривались ли другие виды коммуникаций, или были какие-то ограничения на их применение?
Если в большинстве трафика ботнета реальные адреса устройств то, что мешает записать хотя бы 0.001% и уведомить владельцев и производителей? А может даже и выехать и починить утюг?
У меня противоположный опыт. Про Kubernetes читаю, а SLURM использую, но смотрю, не пора ли на что-то новое переходить.
Kubernetes в свою очередь уже cloud-native унифицированная экосистема, в котором удобно запускать смешенные нагрузки тренировка + инференс + API + data pipelines в одном кластере.
В SLURM с такими нагрузками нет проблем. Каждой задаче определяются ресурсы, сколько узлов, CPU, GPU, памяти. Можно поставить в очередь задачи в виде ациклического графа, каждой задаче назначить различные ресурсы и зависимости от других задач, а SLURM это "упакует" в кластер оптимальным образом, и задачи будут выполнены в нужном порядке, и для разных нагрузок будут выбраны соответствующие узлы.
Даже ещё интереснее, можно ставить задачи с разным приоритетом, и, например, "продуктовые" задачи будут всегда вытеснять "исследовательские", при этом кластер будет всегда нагружен на 100%, только будет меняться пропорция между задачами.
Инференс, вообще веб-сервис с автоскейлингом и хелс-чеками.
С инференсом тоже проблем нет, дал задаче 1 GPU, очередной ускоритель освободился, на него задача встанет. Почти автоскейл на фиксированном кластере. Будет много запросов на инференс, значит этих задач будет много в кластере. Но если захочется веб-сервис с хелс-чеками, то это придётся ручками уже делать вокруг. В принципе, в нём можно и что-то типа тритона запустить.
Дополнительные инструменты прямо из коробки интегрируются с кубером, например prometheus, vault, argo-cd.
Это для SLURM из другой вселенной. Хотя с prometheus тоже можно связь делать, но это уже более индивидуально для каждого приложения.
Ну и сам кубер, как инструмент мне кажется знаком, гораздо большему количеству разрабов, не приходиться учить новую технологию.
Вот интересно, в мире HPC применяется планировщик SLURM. И на маленьких кластерах применяется, и на громадных. Он большинство озвученных тут кейсов может решить, и по мне, он намного проще в настройке и обслуживании.
Почему переходят на Kubernetes и пытаются ввернуть в него планировщик?
Меня поражает как компании при этом умудряются монетизировать генерацию видео. Я у себя запустил генерацию по первому кадру и промпту через WAN2.1, результат поражает, но это 40 минут работы А100.
Так в этом и соль, что ваш объём данных небольшой, и Postgres полностью загрузит их в ОЗУ при разумной конфигурации. А хранить данные на диске вам в любом случае где-то надо.
Кстати под капотом в GiST индексе также используются R-Tree
Я про то и написал, что там это из коробки работает.
Полученный механизм весьма удобен, если вы, скажем, пользуетесь Continuous Integration. Когда какой‑то тест проваливается, из него вылетает исключение, попробуй разберись, откуда оно вылетело и почему так произошло.
Но ведь проще в CI тесты под GDB запустить, а ему передать команду печатать stacktrace в случае падения. Никаких грязных трюков.
Полное обучение было бы слишком накладно. Как раз на днях попробовал на картинках "реального мира", мне показалось, что SR изображения становятся немного "мультяшными". Или можно что-то без дообучения потюнить?
Интересно, на одноимённом языке они у себя не пишут совсем? Или это другое?
Промышленное решение на Ollama, это как-то не серьёзно. Поставили бы vLLM, она лучше масштабируемая.
Спасибо!
Относительно недавно тоже делал коммуникации, но не в обучении, а моделировании. Интересно, куда тема движется, хотел ваши видео посмотреть, на VK плейлист есть, но пустой. На YouTube всё на месте.
В MPI почему-то тоже до сих пор нет возможности агрегации в разных типах. Хотя довольно часто в моделировании встречается кейс что-то посчитать во float, а потом со всех нод в double собрать.
Спасибо за статью, интересно.
Есть ли мысли выложить веса для общего доступа?
Коммуникации в NCCL не только кольцевидные. Тут можно посмотреть NVIDIA/nccl. Рассматривались ли другие виды коммуникаций, или были какие-то ограничения на их применение?
Если в большинстве трафика ботнета реальные адреса устройств то, что мешает записать хотя бы 0.001% и уведомить владельцев и производителей? А может даже и выехать и починить утюг?
У меня противоположный опыт. Про Kubernetes читаю, а SLURM использую, но смотрю, не пора ли на что-то новое переходить.
В SLURM с такими нагрузками нет проблем. Каждой задаче определяются ресурсы, сколько узлов, CPU, GPU, памяти. Можно поставить в очередь задачи в виде ациклического графа, каждой задаче назначить различные ресурсы и зависимости от других задач, а SLURM это "упакует" в кластер оптимальным образом, и задачи будут выполнены в нужном порядке, и для разных нагрузок будут выбраны соответствующие узлы.
Даже ещё интереснее, можно ставить задачи с разным приоритетом, и, например, "продуктовые" задачи будут всегда вытеснять "исследовательские", при этом кластер будет всегда нагружен на 100%, только будет меняться пропорция между задачами.
С инференсом тоже проблем нет, дал задаче 1 GPU, очередной ускоритель освободился, на него задача встанет. Почти автоскейл на фиксированном кластере. Будет много запросов на инференс, значит этих задач будет много в кластере. Но если захочется веб-сервис с хелс-чеками, то это придётся ручками уже делать вокруг. В принципе, в нём можно и что-то типа тритона запустить.
Это для SLURM из другой вселенной. Хотя с prometheus тоже можно связь делать, но это уже более индивидуально для каждого приложения.
Возможно, но не так оно и сложно:
Вот и запустили задачу на чётырёх узлах по 8 GPU на каждом, аналогично и через API можно.
З.Ы. Пишите ещё, переманивайте в свой лагерь.
Вот интересно, в мире HPC применяется планировщик SLURM. И на маленьких кластерах применяется, и на громадных. Он большинство озвученных тут кейсов может решить, и по мне, он намного проще в настройке и обслуживании.
Почему переходят на Kubernetes и пытаются ввернуть в него планировщик?
Вы избалованы общением с хорошо образованными людьми:)
Очевидно, надо обсчитать коттедж гномов.
Меня поражает как компании при этом умудряются монетизировать генерацию видео. Я у себя запустил генерацию по первому кадру и промпту через WAN2.1, результат поражает, но это 40 минут работы А100.
Этому хакеру попалась очень крутая солонка. Но в целом, печально как-то.
Так в этом и соль, что ваш объём данных небольшой, и Postgres полностью загрузит их в ОЗУ при разумной конфигурации. А хранить данные на диске вам в любом случае где-то надо.
Я про то и написал, что там это
из коробкиработает.Тут интересно сравнить с PostGIS. Он прекрасно будет хранить 3M полигонов и R-tree индекс по ним построит. Такое решение рассматривали?
Да у парня нормальная мастерская.
Скорее, в процессе использования внутренних ИИ инструментов продолжает наращиваться обучающая выборка.
Интересно, а удалённое отключение тоже добавят?
Но ведь проще в
CIтесты подGDBзапустить, а ему передать команду печататьstacktraceв случае падения. Никаких грязных трюков.Полное обучение было бы слишком накладно. Как раз на днях попробовал на картинках "реального мира", мне показалось, что SR изображения становятся немного "мультяшными". Или можно что-то без дообучения потюнить?
Возможно ли дообучение на своих данных?
Трубка с капилляром очень напоминает устройство гелий-неонового или аргонового лазера. Лазер будет в следующих постах?