Ускорение глубоких нейронных сетей

Эта книга представляет собой практическое руководство по ускорению работы глубоких нейронных сетей (DNN) и больших языковых моделей (LLM). Выходя за рамки закрытых методов «черного ящика», она сочетает новейшие техники – такие как FlashAttention, – с работающим кодом и эмпирическими данными и сокращает разрыв между теорией и практикой. Читатели получат как технические инструменты, так и фундаментальные знания, необходимые для эффективной оптимизации моделей.

Ключевые темы:
➖ квантизация и низкая точность – с пояснениями, почему она работает;
➖ прунинг – известные методы, а также случаи, когда их следует применять;
➖ дистилляция – постановка задачи, подходы к дистилляции, выбор модели-ученика, использование генеративных моделей, разбор FitNet;
➖ низкоранговая аппроксимация – основы низкоранговых представлений, их применение к сверточным сетям и механизмам внимания;
➖ быстрые архитектуры – свертки, быстрые трансформеры, архитектуры на основе преобразования Фурье, методы подсетей, поиск нейросетевых архитектур и сравнение быстрых архитектур с методами сжатия;
➖ эффективное обучение – сокращение потребления памяти и арифметика параметров модели.

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

Предзаказ книги со скидкой 20% доступен до ссылке

Где можно заказать книги сейчас?

В связи с сложившейся ситуацией мы продолжаем искать решения, чтобы у вас была возможность продолжать получать знания!

На данный момент доступны несколько альтернативных сайту каналов:

Авито. На этой площадке мы продаём по ценам близким к издательским

Написать на почту dmkpress.help@gmail.com по всем вопросам. Вас проконсультируют и помогут как сделать заказ, так и узнать статус сделанного ранее

Добавили ссылку на наш магазин в Авито в комментариях ⬇️

➡️Что страшнее для сервиса: баг в коде, DDoS или падение инфраструктуры?⬅️

Каждый из этих сценариев может положить сервис. Но последствия и способы спасения совсем разные.

❌ Баг в коде порой годами сидит незаметно, а потом проявляется в самый неподходящий момент. И от него резервные серверы не спасут — ошибочная логика просто запустится везде.

❌ DDoS может оставить сервис полностью рабочим «внутри», но недоступным для пользователей. Здесь уже многое зависит от архитектуры, фильтрации трафика и готовности инфраструктуры к большой нагрузке.

❌ Падение инфраструктуры — отдельный уровень проблем. Недоступность дата-центра, сети, хранилища или другого критичного компонента может одновременно затронуть сразу несколько систем.
А самое неприятное в том, что проблемы вполне могут прийти не по одной.

Предлагаем обсудить в комментариях тему поста. Что из вышеперечисленного вы считаете самым неприятным и опасным?

Выберите только один вариант:
🔵Баг
🔵DDoS
🔵Инфраструктура

И обязательно напишите почему именно он.

🤖 Как бизнес переходит от экспериментов с ИИ к реальным результатам? 📊

22 октября в Москве состоялся форум «Интеллектуальное предприятие — 2026», организованный издательством «Открытые системы». Наше издательство "ДМК Пресс" выступает партнёром организатора мероприятия.

Форум объединил представителей бизнеса, ИТ-специалистов и экспертов по цифровизации, чтобы обсудить переход от отдельных ИИ-проектов к полноценному внедрению искусственного интеллекта в бизнес-процессы.

🔘В центре внимания оказались:

➖Экономическая эффективность внедрения ИИ.
➖Безопасность ИИ-агентов и мультиагентных систем.
➖Взаимодействие человека и искусственного интеллекта.
➖Ответственность за решения автономных систем.
➖Реальные кейсы применения ИИ в различных отраслях.

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

💡 Один из главных выводов форума: сегодня недостаточно просто внедрить искусственный интеллект. Важно выстроить систему, в которой ИИ приносит измеримую пользу, остаётся управляемым и безопасным.

ДМК Пресс поддерживает профессиональные площадки, на которых специалисты обмениваются опытом и обсуждают практическое применение современных технологий.

Подробнее об итогах форума — на сайте организатора

🔒 Что читать разработчику, который хочет лучше понимать кибербезопасность?

Написать приложение, которое работает, — одна задача. Сделать так, чтобы его было сложно взломать, уже совсем другая. Причём разбираться в безопасности полезно не только специалистам по ИБ, но и разработчикам тоже важно понимать, откуда берутся уязвимости, как злоумышленники используют ошибки в коде и что можно сделать, чтобы их предотвратить.

Мы собрали 4 книги, которые помогут посмотреть на разработку с точки зрения безопасности.

🔘1. «Безопасность Java-приложений: Spring, микросервисы и Kubernetes» — Адиб Сайкали, Лауренциу Спилкэ
Для тех, кто разрабатывает серверные приложения на Java и хочет лучше понимать их защиту. Книга объясняет, как возникают уязвимости, как правильно организовать аутентификацию и управление доступом, применять шифрование и защищать приложения на разных этапах разработки.
Особенно полезна тем, кто работает со Spring, микросервисами и Kubernetes.
👉 Купить книгу

🔘2. «Безопасность веб-приложений на Python» — Деннис Бирн
Как защитить приложение от распространённых атак? Что нужно учитывать при работе с пользовательскими данными, API и авторизацией?
Автор разбирает эти вопросы на практических примерах с Python и Django. От основ криптографии до безопасной аутентификации и защиты веб-приложений.
Подойдёт Python-разработчикам, которые хотят научиться замечать потенциальные проблемы безопасности ещё на этапе написания кода.
👉 Купить книгу

🔘3. «Взламываем OWASP Juice Shop. Руководство белого хакера» — Бьёрн Кимминих
Теория — это хорошо, но гораздо интереснее увидеть уязвимости в действии.
OWASP Juice Shop — специально созданное уязвимое веб-приложение, на котором можно безопасно тренироваться в поиске и исследовании ошибок.
Книга помогает освоить практические методы тестирования безопасности и понять, как обнаруженные уязвимости могут использоваться при атаках.
Отличный вариант для разработчиков, которым хочется попробовать себя в роли специалиста по тестированию на проникновение.
👉 Купить книгу


💡 С чего начать?
Если ваша основная задача — писать более безопасный код, выбирайте книгу под свой язык: Java или Python.
Если хочется разобраться, как находят и используют уязвимости, обратите внимание на OWASP Juice Shop.

А теперь вопрос к разработчикам:
Как считаете, насколько глубоко обычный программист должен разбираться в кибербезопасности? Достаточно соблюдать основные правила безопасной разработки или каждому стоит хотя бы раз попробовать взломать собственное приложение?

Делитесь мнением в комментариях! 👇

〰️ Backup есть. А восстановиться сможете?

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

И тут выясняется, что копии есть, а быстро вернуть систему к жизни не получается.
Почему? Потому что backup ≠ disaster recovery.
Резервное копирование помогает сохранить данные. А disaster recovery — это способность восстановить работу всей системы после аварии.
Что может пойти не так?

📌 Backup — это сохранение данных.
Disaster recovery — способность восстановить работу системы после аварии.
И между этими двумя задачами гораздо больше различий, чем может показаться.

🔵Копия есть, но восстановить её невозможно. Архив повреждён, не хватает файлов или никто раньше не проверял процесс восстановления.

🔵Данные восстановлены, а сервис не работает. Ведь нужны ещё серверы, сетевые настройки, конфигурации, доступы и другие компоненты инфраструктуры.

🔵Восстановление занимает слишком много времени. Здесь важны два показателя: RTO — допустимое время восстановления и RPO — допустимая потеря данных, выраженная во времени.

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

💡 Главный вывод
Надёжная инфраструктура — не та, которая никогда не ломается. А та, для которой заранее продуманы сценарии отказа и проверены способы восстановления. Резервные копии — важная часть этой работы, но далеко не единственная.

📚 Что почитать по теме?
Для тех, кто хочет глубже разобраться в Linux, администрировании серверов и работе контейнерной инфраструктуры, рекомендуем:

➖«Rocky Linux 9 для сетевого администрирования. Полное руководство»➖
🔵об управлении серверной инфраструктурой, автоматизации, контейнеризации и развёртывании систем.

➖«Kubernetes изнутри»➖
🔵поможет лучше понять устройство Kubernetes, управление кластерами, сетевое взаимодействие и диагностику неполадок.

➖«Kubernetes в действии»➖
🔵о развёртывании приложений, конфигурации, хранилищах, масштабировании и обслуживании систем на базе Kubernetes.

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

❓А теперь вопрос к вам:
Когда вы в последний раз проверяли не создание бэкапа, а полноценное восстановление из него?
Приходилось ли вам сталкиваться с ситуацией, когда резервная копия была, но восстановить систему оказалось гораздо сложнее, чем ожидалось?

Делитесь опытом в комментариях! ⬇️

💻 Нужно ли сегодня разработчику уметь работать без доступа к внешним сервисам?

Представьте: завтра у вашей команды пропадает доступ к GitHub, Docker Hub, облачному CI/CD и привычным инструментам разработки. Сможете продолжить работу или придётся ждать, пока всё восстановится?

Современная разработка сильно зависит от внешних платформ. Мы скачиваем библиотеки, используем готовые контейнеры, запускаем сборки в облаке и обращаемся к онлайн-документации. Это удобно, но что происходит, когда привычные инструменты становятся недоступны?

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

⚙️ DevOps и локальная инфраструктура
Собственный Git-сервер, локальный реестр контейнеров, зеркала пакетов и CI/CD на своих серверах позволяют уменьшить зависимость от сторонних сервисов. Правда, появляется другая задача: всё это нужно поддерживать, обновлять и администрировать.

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

💡 Получается интересный вопрос: насколько независимым должен быть современный разработчик?
С одной стороны, готовые сервисы экономят огромное количество времени. С другой — чем больше внешних зависимостей, тем больше факторов, которые команда не контролирует.

💬 Давайте обсудим!
Представьте, что завтра ваша команда на неделю потеряет доступ ко всем внешним платформам разработки. Что произойдёт?
1️⃣ Продолжим работать практически без изменений.
2️⃣ Будут сложности, но справимся.
3️⃣ Разработка почти полностью остановится.

Какой вариант ближе к вашей ситуации?

➡️Что важнее для разработчика в 2026 году: глубоко знать один стек или быстро осваивать новые технологии?⬅️

Раньше можно было годами работать с одним языком программирования и постепенно становиться экспертом в своей области.
Сегодня технологии меняются быстро: появляются новые инструменты, AI всё активнее используется в разработке, а задачи всё чаще требуют знаний сразу из нескольких областей. Перед разработчиками возникает вопрос: углубляться в знакомые технологии или постоянно изучать новые?

➖ Глубокая специализация позволяет решать сложные задачи, находить неочевидные ошибки и понимать, как система работает изнутри. Но есть риск слишком сильно привязаться к определённому стеку.
➖ Широкий технический кругозор помогает быстрее адаптироваться, осваивать новые инструменты и находить решения на стыке технологий. Но невозможно одинаково хорошо разбираться во всём.
➖ Комбинированный подход — хорошо знать основное направление и постепенно осваивать смежные области. Звучит разумно, но где взять время на постоянное обучение?

📚 Три книги ДМК Пресс для развития в разных направлениях:

🐍 Python — «Разработка на Python в условиях жестких дедлайнов»
Для тех, кто хочет совершенствовать навыки программирования. Книга посвящена практическим подходам к разработке, отладке, оптимизации и тестированию Python-приложений.

⚙️ DevOps — «Запускаем Ansible. Третье издание»
Для разработчиков, которые хотят выйти за пределы написания кода и разобраться в автоматизации инфраструктуры. Книга поможет освоить Ansible, научиться управлять конфигурациями серверов, автоматизировать рутинные задачи и развёртывание приложений.

🤖 AI — «Искусственный интеллект: современный агентный подход»
Для разработчиков, которым интересно освоить новое направление. Книга знакомит с проектированием интеллектуальных агентов, многоагентными системами и интеграцией больших языковых моделей с внешними инструментами.

💬 А теперь предлагаем подискутировать!
Представьте, что вы выбираете нового разработчика в команду. Кого предпочтёте?

1️⃣ Узкого специалиста, который знает свой стек практически идеально.

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

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

И какой путь выбрали для себя вы? Стараетесь стать экспертом в одном направлении или постоянно изучаете новые технологии?

🔐 Supply chain: когда атакуют не ваше приложение, а то, из чего вы его собираете

Представьте: команда тщательно проверяет код, регулярно проводит тестирование, следит за уязвимостями, однако однажды в приложение всё же попадает вредоносный компонент. И самое интересное - никто из разработчиков не писал этот код, он пришёл вместе с обновлением привычной библиотеки.

Мы описали один из сценариев supply chain attack — атаки на цепочку поставок программного обеспечения.

Современные приложения редко создаются полностью с нуля. Используются библиотеки, фреймворки, контейнерные образы и инструменты автоматической сборки. Каждый из этих компонентов может стать дополнительной точкой входа для атакующих.

Как это работает?
🔵Подмена зависимостей. Злоумышленники публикуют вредоносный пакет под похожим названием или получают доступ к существующему популярному проекту.
🔵Компрометация CI/CD. Если атакующий получает доступ к системе сборки, он может попытаться изменить готовый артефакт или похитить секреты, используемые при развёртывании.
🔵Уязвимости сторонних компонентов. Даже если собственный код безопасен, библиотека с известной уязвимостью способна поставить под угрозу всё приложение.
🔵Заражённые контейнерные образы. Использование непроверенных образов создаёт риск запуска нежелательного кода вместе с приложением.

Как снизить риски?

✅ Контролировать прямые и транзитивные зависимости.
✅ Проверять происхождение пакетов и контейнерных образов.
✅ Использовать инструменты автоматического поиска уязвимостей.
✅ Ограничивать права доступа в CI/CD и защищать секреты.
✅ Контролировать обновления и изменения в процессе сборки.
Полностью исключить риски, конечно, невозможно, но важно понимать, какие компоненты входят в ваше приложение и насколько им можно доверять.

📚 Что почитать по теме?

Подобрали три книги, которые помогут глубже разобраться в безопасности ПО.

➡️Безопасность Java-приложений: Spring, микросервисы и Kubernetes⬅️

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

➡️Безопасность разработки в Agile-проектах⬅️

О том, как встроить практики информационной безопасности в повседневную работу команды. Книга затрагивает моделирование угроз, оценку рисков и безопасность непрерывной поставки ПО.

➡️Алиса и Боб учат безопасному кодированию⬅️

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

💻 Какой технический навык вы считаете самым недооценённым у программистов?

Можно отлично знать язык разбираться во фреймворках и писать качественный код, но порой самые сложные проблемы возникают совсем не там, где их ожидаешь.
Приложение тормозит — а проблема оказывается в сети. Сервис не запускается — дело в настройках Linux. Система перестаёт справляться с нагрузкой — приходится пересматривать архитектуру.
И здесь выясняется, что знания за пределами основного стека могут быть не менее полезными, чем навыки программирования.
Какие направления, на наш взгляд, часто недооценивают?

🌐 Компьютерные сети. Понимание TCP/IP, DNS и HTTP помогает разобраться, почему сервис недоступен, откуда берутся задержки и что происходит между клиентом и сервером.

🐧 Linux и системное администрирование. Умение работать с процессами, логами, правами доступа и системными службами значительно облегчает диагностику проблем.

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

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

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

💬 А теперь вопрос к вам!
Если бы вы могли добавить только один обязательный навык в программу подготовки каждого разработчика, что бы выбрали?

1️⃣ Компьютерные сети
2️⃣ Linux и системное администрирование
3️⃣ Математику и алгоритмы
4️⃣ Архитектуру ПО
5️⃣ Что-то другое

Не ограничивайтесь номером — расскажите, почему выбрали именно этот навык!

Команда готовит релиз, код написан, тесты пройдены - осталось собрать приложение и отправить его в production, но...
❗️внезапно сборка останавливается, нужный пакет не скачивается, Docker Hub недоступен или внешний репозиторий перестал отвечать❗️

Получается, что работоспособность вашего процесса разработки зависит от сервисов, которые вы не контролируете.

Именно поэтому собственные репозитории пакетов и контейнерных образов становятся важной частью инфраструктуры.

Что они дают на практике?

📦 Независимость от внешних репозиториев. Nexus может кэшировать зависимости и контейнерные образы. Если внешний источник временно недоступен, ранее сохранённые компоненты остаются доступными.
🐳 Контроль над Docker-образами. Собственный registry позволяет хранить образы внутри компании, управлять их версиями и не зависеть от доступности внешнего хранилища при развёртывании.
🔄 Более предсказуемые сборки. Команда может использовать проверенные версии зависимостей, а не полагаться исключительно на их доступность во внешних источниках.
🔒 Дополнительный контроль безопасности. Проще организовать проверку компонентов, ограничение доступа и правила использования сторонних пакетов.
〰️ Стабильность Kubernetes-инфраструктуры. Если необходимые образы доступны во внутреннем registry, запуск новых контейнеров меньше зависит от внешних платформ.

Но есть и обратная сторона
Собственный Nexus или registry необходимо администрировать, обновлять, защищать, резервировать и мониторить.
Кроме того, локальный кэш не поможет получить компонент, который никогда в него не загружался. Поэтому речь не о полной независимости от интернета, а о снижении критических внешних зависимостей.

📚 Что почитать по теме?
Чтобы лучше разобраться в инфраструктуре и контейнеризации, рекомендуем следующие книги:

📘 «Rocky Linux 9 для сетевого администрирования. Полное руководство» — об управлении Linux-серверами, настройке сетевых служб и администрировании инфраструктуры.

📘 «Docker Compose для разработчика» — о контейнеризации приложений, настройке окружений и управлении несколькими взаимосвязанными сервисами.

📘 «Kubernetes изнутри» — поможет разобраться в устройстве Kubernetes, администрировании кластеров и диагностике проблем.