У меня противоположный опыт. Про 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 изображения становятся немного "мультяшными". Или можно что-то без дообучения потюнить?
А она может и не решиться. Шумы измерений не позволят. можно решить ту же задачу с помощью МНК.
Да, я это и имел ввиду, систему уравнений составить с применением МНК.
Единственно, точек будет много и решать такую систему довольно затратно.
На 100K уравнений за разумное время (минуты) решается. А у вас очень сильно разреженная система будет, так что ещё быстрее.
Фильтр же позволяет делать корректировку прямо во время движения объекта.
Это его достоинство и он же недостаток. Когда мы решаем задачу как систему уравнений, то мы видим все измерения сразу, а фильтр только по очереди и в одну сторону. Поэтому, на мой взгляд, решая систему мы получим более точное решение.
У меня противоположный опыт. Про 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 изображения становятся немного "мультяшными". Или можно что-то без дообучения потюнить?
Возможно ли дообучение на своих данных?
Трубка с капилляром очень напоминает устройство гелий-неонового или аргонового лазера. Лазер будет в следующих постах?
Удивительно, это же те самые Barnes и Hut, которые занимались моделированием поведения галактик. Как, оказывается, недалеко от астрономии до ML.
Для нелинейного МНК есть хорошие реализации, например http://ceres-solver.org/, там производные можно автоматом посчитать.
Да, я это и имел ввиду, систему уравнений составить с применением МНК.
На 100K уравнений за разумное время (минуты) решается. А у вас очень сильно разреженная система будет, так что ещё быстрее.
Это его достоинство и он же недостаток. Когда мы решаем задачу как систему уравнений, то мы видим все измерения сразу, а фильтр только по очереди и в одну сторону. Поэтому, на мой взгляд, решая систему мы получим более точное решение.
А зачем фильтр Калмана? Можно же просто составить систему уравнений и решить её...
Какая-то странная арифметика. Сборка только в рабочее время идёт?