TLDR — это не готовое решение, это попытка самостоятельно разобраться, подобрать архитектуру и обучить генеративно-состязательную модель (GAN) для увеличения картинок в 2 или 4 раза. Я не претендую на то, что моя модель или путь рассуждений лучше каких-то других. Кроме того, относительно недавно стали популярны трансформеры и diffusion модели — заметки не про них.

С заметками не получилось линейной структуры повествования — есть отступления "в сторону" и уточнения. Можно пропускать нерелевантные заметки. Например, описание подготовки данных нужно, если вы хотите воспроизвести эксперименты — а в остальных случаях можно пропустить. Я написал каждую отдельную заметку по-возможности цельной и независимой от других.

Я уже был знаком со свёрточными сетками, но мне хотелось попробовать генеративно-состязательные сети. Понять, почему используют те или иные подходы. Попробовать свои идеи. Посмотреть, насколько быстро можно научить модель и насколько хорошо она будет работать.

Для обучения оказалось достаточно возможностей моего ПК. Какие-то простые эксперименты занимали десятки минут или несколько часов, самый длинный с обучением финальной большой модели — трое суток.

Не всегда черные лебеди приходят извне и прямо связаны с негативом. В моем случае черный лебедь пришел в виде успеха. Да, можно сказать в виде полного триумфа нашего IT-стартапа. Как грандиозный успех может привести к банкротству промышленно-торгового холдинга? Об этом и будет данная публикация.

Привет, сегодня будет объёмная и обстоятельная статья о низкоуровневом профилировании и дигностике производительности. Многократно в комментариях к докладам и статьям пользователи высказывали пожелание увидеть не просто перечисление шаблонов "как нужно" и "как не нужно", а целостную историю. Поэтому вот вам статья про конкретный кейс и его историю :). Не удивляйтесь, что начнём мы с JPA, хотя казалось бы где оно и где ассемблер. По ходу дела вы всё поймёте.

Для начало придется забыть слово заставить. Задача помочь сотрудникам полюбить зарабатывать вам деньги.

Меня зовут Слава. Я создал и развалил сеть ночных клубов, прошел 300 собеседований на маркетолога, проработал как подрядчик и сотрудник в более 50 компаниях. Сейчас занимаюсь системным маркетингом.

Там, где я работал, были разные системы управления, но всегда работал один и тот же принцип.

Уверен, что большинство тех, кто читает и пишет на хабре, постоянно чему-нибудь да обучаются. Современный мир таков, что знания, особенно в областях, где развитие идёт с большой скоростью, если не устаревают окончательно, то становятся менее актуальными. И сразу появляются новые знания, который также нужно освоить. Впрочем, это же интересно!

Но есть один нюанс - чтобы усваивать новые знания и навыки, одного желания часто мало, нужны ещё основы, базовые знания, которые были получены в школе, вузе, самостоятельно, но желательно, чтобы они складывались в систему. Собственно, поэтому образование в тех же вузах часто и называют системным. Да, оно не всегда таким бывает, но всё-таки бывает.

К чему длительное вступление? Сейчас поясню.

Статья объясняет внутреннюю архитектуру виртуальной машины Java (JVM). Диаграмма отображает ключевые внутренние компоненты типичной JVM, которая соответствует спецификации The Java Virtual Machine Specification Java SE 7 Edition

Этот обзор посвящен открытому проекту компьютера My4TH по информации от разработчика: Авторский сайт проекта:

My4TH (произносится как "мой четвертый") - это четвертый домашний компьютер без процессора после MyCPU, MyNOR и TraNOR. Автор хотел и построил максимально простой компьютер с дискретным процессором, использующим как можно меньше элементов и компонентов, под управлением операционной системы Forth.

В предыдущей статье я рассказал, как организовать систему распределенного машинного обучения на GPU NVidia, используя язык Java с фреймворками Spring, Spark ML, XGBoost, DJL в standalone кластере Spark. Особенностью поставленной задачи являлось организация системы под управлением ОС Windows 10 Pro, в Docker‑контейнерах. Эксперимент оказался не вполне успешным. В данной статье я покажу, как воспользоваться имеющимися наработками и запустить Spark Jobs в Kubernetes в режимах client и cluster, опишу особенности работы с Cassandra в Spark, покажу пример обучения модели и ее дальнейшего использования. В этот раз буду использовать язык Kotlin. Репозиторий с кодом доступен на GitLab.

Данная статья представляет интерес для тех, кто интересуется системами Big Data и стремится создать систему, позволяющую, в том числе, выполнять задачи распределенного машинного обучения на Spark в Kubernetes, используя GPU NVidia и Cassandra для хранения данных.

В данной статье рассматривается способ использования GPU nVidia с технологией CUDA в Docker-контейнерах для распределенной тренировки моделей машинного обучения на нескольких машинах. Цель статьи - показать вариант использования Big Data Tool Apache Spark в Docker-контейнерах, совместно с акселератором GPU вычислений Rapids на устройствах nVidia CUDA, с применением библиотек DJL, Spark ML, XGBoost, в приложении Spring Boot на Java 8 (требование Rapids), на нескольких машинах под управлением ОС Windows 10 Pro для решения задачи тренировки моделей машинного обучения в распределенной системе.

Приведу несколько распространённых стратегий развертывания приложений/сервисов, а также разберу пять популярных стратегий «жонглирования» данными между системами кеширования и базами данных.

В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.

Моя Родина – АСУ ТП — смертельно больна

Если вы отправитесь на любой тематический АСУ ТП-форум или группу, вы к сожалению не найдете обсуждения стандартов, архитектуры РСУ, лучших практик для ISA101, ISA88, ISA95.

В лучшем случае вы найдете дискуссии на тему «являются ли АСУ-шники настоящими программистами когда пишут код на LAD/FBD» или «обязан ли монтажник/программист знать технологический процесс объекта на котором работает» и т.п.

Проще говоря – сообщество и особенно ИТ-сообщество разработчиков в сфере АСУ ТП отсутствует в принципе.

Нет, этот пост не про то, как на простом ноуте без NVIDIA гонять Stable Diffusion с вполне вменяемой скоростью.

Да, этот пост про то, как на простом ноуте без NVIDIA гонять Stable Diffusion с вполне вменяемой скоростью.

Но только если карточка у вас все-таки где-то есть. Пост не про халяву :)

Часто задают вопрос: «У нас маленькое агентство, как бы сделать, чтобы 4 человека работали на одной видеокарте?». То же самое относится и к «мама-папа-я – дружная семья, и все мы любим Stable Diffusion».

Это становится еще более актуальным в связи с появившимися сложностями при попытках бесплатно гонять SD в Google Colab (а Kaggle и другие заменители не такие щедрые).

В этом посте я опишу несколько вариантов «совместной работы с одним GPU», их плюсы и минусы. В основном, на примере Stable Diffusion, хотя Vicuna я тоже гонял параллельно.

Всем привет! Меня зовут Данила, я выполняю роль SR-инженера в Usetech. В этой статье я бы хотел рассказать о 4-х способах, которые помогут сократить объём ваших индексов в Elasticsearch.

Прежде всего статья будет полезна начинающим специалистам по администрированию ELK стека, администраторам систем мониторинга, разработчикам, внедряющим ELK стек у себя на проекте. 

Работая над мониторингом в одном из проектов мы столкнулись с тем, что временной промежуток, за который мы имеем возможность хранить данные, для нас недостаточен, т.к. хотелось иметь возможность сравнивать работу системы за больший период времени.

Мы видели 2 пути решения проблемы:

Добрый день, меня зовут Рустам Ахметов, я архитектор ГК Юзтех и интеграционной шины данных UseBus. В этой статье я расскажу о нашем опыте разработки продукта и выборе технического стэка. Хочу добавить, что я буду давать лишь поверхностный Helicopter view на продукты и их аналоги.

Из статьи вы узнаете:

При работе в разных компаниях, чаще всего встречалось раздражающее отсутствие актуальной документации или «документационная мусорная куча», где было сложно найти требуемое. Нередко проблемы были в стиле «это знал уволившийся Петя, но его не спросить». Или в наличии деталей, которые были незначимы по мнению разработчика, но которые оказывались критическим знанием «переоткрываемым» последователями (нередко и самим разработчиком, вернувшемуся к проекту). Для облегчения жизни, был сделан специальный инструмент, позволяющий держать записи по проекту прямо среди исходных текстов.

Модульный монолит — это подход к проектированию приложений, который позволяет, с одной стороны, отложить во времени операционную сложность использования микросервисов, а с другой — избежать превращения монолитной системы в большой комок грязи. Сама идея модульности не нова и основана на давно известных принципах Separation of Concerns и Information Hiding. Но не так-то просто перейти от абстрактных принципов к пониманию, как их реально использовать на практике.

На Хабре не так много информации о модульных монолитах в целом и практически ничего о конкретных вариантах их реализации. Но об этом есть серия статей у Камиля Гржибека. Сегодня поделюсь переводом первой из них.

Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.

Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!

Но помимо восхваления их здравого смысла, я думаю, что здесь есть более важный момент, который применим ко всей нашей отрасли...