Если вы просто усредните, то вы уберёте шумы, но не повысите разрешение изображения.
Эти формы известны только в момент "до прилунения", а что в ними в момент падения стало никто не знает. Более того, для звёзд эта форма является точкой, и хорошо математически описывается и просчитывается. А для произвольной формы - увы.
Для получения изображения поверхности Луны нас интересует именно оптическое угловое разрешение. Интерферометрия изображение поверхности не даст. Угловое разрешение в радианах: θ =1.22λ/D (λ - длина волны, D - диаметр апертуры). Для зеркала VLT диаметром 8.2 метра и зелёного света 550нм получим 0.017". При этом, по википедии у него разрешение с адаптивной оптикой 0.05", немного не дотянули до дифракционного предела.
З.Ы. Посмотрел, действительно, по цене небольшой квартиры сейчас можно купить телескоп с апертурой 400мм, что в теории даст разрешение 0.3", а как по факту никто не знает.
На пальцах: Диаметр Луны = 3 474 км; Угловой размер Луны = 31' (это 1860"); Разрешение лучших наземных телескопов около 1"; Разрешение телескопа Джеймс Уэбб около 0.1".
Делим одно на другое, получаем что для наземных телескопов линейное разрешение будет около 2 км, и около 200 м для Джеймса Уэбба. При этом обратите внимание, что наземные телескопы по размеру апертуры больше Уэбба, т.е. они сильно не дотягивают до физического предела.
В теории можно сделать много плохих снимков, из из большого массива построить один хороший.
Для звёзд это делают. Но там главное допущение, что звезда это точечный источник. Т.е. известно какую "форму" надо восстановить. Плюс в атмосфере лазером "зажигают" искусственную звезду для калибровки.
Кто-нибудь из хабражителей знает сервис, аналогичный JLCPCB в России? Я как-то хотел резку металла на ЧПУ заказать для DIY, но так и не нашёл, кто готов одиночное изделие вырезать.
Парадокса пока нет. Ещё нет ни одной системы, созданной одним человеком с применением ИИ, сопоставимой по масштабам тем системам, которые созданы "человеческими" коллективами, пусть и с гигантским оверхедом на коммуникации. Зато в противовес вашему случаю есть примеры создания одним человеком сложнейшего ПО, в том числе ОС, да и не одной. Именно одним человеком без ИИ. И как раз это обусловлено отсутствием лишних коммуникаций. Конечно, хочется надеяться, что тут ИИ сильно поможет таким людям. Но пока ИИ не готов к созданию сложного ПО. Лично мне, проще сразу написать код, чем на естественном языке описывать то, что я хочу от программы, хотя с удовольствием отдаю в ИИ рутинные задачи, или предварительные исследования.
Спасибо! Относительно недавно тоже делал коммуникации, но не в обучении, а моделировании. Интересно, куда тема движется, хотел ваши видео посмотреть, на 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.
Зачем это на ревью перекладывать? Настройте автоформатирование, которое всех устроит, а в CI добавьте задачу, которая проверит.
Если что-то не так с форматированием, или другими тривиальными вещами, то до ревью человеком не должно доходить.
Если вы просто усредните, то вы уберёте шумы, но не повысите разрешение изображения.
Эти формы известны только в момент "до прилунения", а что в ними в момент падения стало никто не знает. Более того, для звёзд эта форма является точкой, и хорошо математически описывается и просчитывается. А для произвольной формы - увы.
Для получения изображения поверхности Луны нас интересует именно оптическое угловое разрешение. Интерферометрия изображение поверхности не даст.
Угловое разрешение в радианах: θ =1.22λ/D (λ - длина волны, D - диаметр апертуры).
Для зеркала VLT диаметром 8.2 метра и зелёного света 550нм получим 0.017".
При этом, по википедии у него разрешение с адаптивной оптикой 0.05", немного не дотянули до дифракционного предела.
З.Ы. Посмотрел, действительно, по цене небольшой квартиры сейчас можно купить телескоп с апертурой 400мм, что в теории даст разрешение 0.3", а как по факту никто не знает.
На пальцах:
Диаметр Луны = 3 474 км;
Угловой размер Луны = 31' (это 1860");
Разрешение лучших наземных телескопов около 1";
Разрешение телескопа Джеймс Уэбб около 0.1".
Делим одно на другое, получаем что для наземных телескопов линейное разрешение будет около 2 км, и около 200 м для Джеймса Уэбба. При этом обратите внимание, что наземные телескопы по размеру апертуры больше Уэбба, т.е. они сильно не дотягивают до физического предела.
Для звёзд это делают. Но там главное допущение, что звезда это точечный источник. Т.е. известно какую "форму" надо восстановить. Плюс в атмосфере лазером "зажигают" искусственную звезду для калибровки.
Да, только четверостишие из этой статьи.
Попробовал озвучить ваше стихотворение. Интересно, похоже?
https://suno.com/s/k2MqCiXurI37dfkW
В голове, а компьютер нужен только для того, что бы результат записать.
Кто-нибудь из хабражителей знает сервис, аналогичный JLCPCB в России? Я как-то хотел резку металла на ЧПУ заказать для DIY, но так и не нашёл, кто готов одиночное изделие вырезать.
Парадокса пока нет. Ещё нет ни одной системы, созданной одним человеком с применением ИИ, сопоставимой по масштабам тем системам, которые созданы "человеческими" коллективами, пусть и с гигантским оверхедом на коммуникации.
Зато в противовес вашему случаю есть примеры создания одним человеком сложнейшего ПО, в том числе ОС, да и не одной. Именно одним человеком без ИИ. И как раз это обусловлено отсутствием лишних коммуникаций.
Конечно, хочется надеяться, что тут ИИ сильно поможет таким людям. Но пока ИИ не готов к созданию сложного ПО.
Лично мне, проще сразу написать код, чем на естественном языке описывать то, что я хочу от программы, хотя с удовольствием отдаю в ИИ рутинные задачи, или предварительные исследования.
Интересно, на одноимённом языке они у себя не пишут совсем? Или это другое?
Промышленное решение на 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.
Этому хакеру попалась очень крутая солонка. Но в целом, печально как-то.