DevOps Deflope News

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

55 — DevOps и AI: личный опыт
56 — Свой или готовый K8s?
57 — Не выпускай пет-проекты из дома
58 — Никому не нужное Observability
59 — Что такое DevOps: человек-пароход или культура и подход?
60 — Зачем нам безопасная разработка

А вообще все-все выпуски подкаста доступны на сайте, там же можно выбрать удобную для прослушивания площадку.

На всякий случай оставим ссылку на наш ВК.

Ревью книги "Solution Architect: архитектура и проектирование ИТ-решений" — взгляд DevOps Deflope

Привет! Меня зовут Анатолий, я инженер архитектурных решений из Фланта и часть редакции DevOps Deflope. Прочитал "Solution Architect" и хочу поделиться мыслями.

Общее впечатление
Книга производит смешанное впечатление: она хорошо структурирована и читается легко, но местами страдает от обобщённости и неравномерной проработки глав.
Адресована для широкого круга, джун узнает много нового, мидл и сеньор причешут свои знания.
Главная фишка в том, что у неё уклон в сторону облачных архитектур, хотя по названию это не скажешь. Первые главы лучше читать последовательно, потом можно нелинейно. Язык вполне простой и читаемый для российской айти-аудитории.

Что зашло
• Раздел о паттернах облачной архитектуры — один из лучших. Системное описание подходов к надёжным и масштабируемым системам, понятные схемы и пояснения дают хорошую базу для начинающих архитекторов.
• Глава о миграции в облако также сильная. Этапы перехода, риски и способы их минимизации изложены чётко, как практическое руководство. Ссылка на репозиторий с готовыми чек-листами была бы очень полезна.

Что не зашло
• В части о безопасности автор ссылается на европейские документы, регулирующие проектирование приложений. Ссылки на российские федеральные законы или отраслевые нормативные документы сделали бы материал более полезным даже в виде сносок.
• Большинство примеров построено вокруг AWS, что удобно для пользователей этой платформы, но ограничивает аудиторию. В главах с AWS-сервисами на схемах часто не хватает понятных примеров по внедрению, не привязанных к этой экосистеме.
• Раздел про архитектуру DevOps слабоват — привычной перевёрнутой восьмёрки (DevOps lifecycle) нигде не увидел.
• Ещё момент. "Архитектура решения" звучит как-то не по-русски везде в первых главах.

Если сравнивать, есть книжка System Design — там уклон в сторону прохождения интервью и дизайна именно программных решений. В части проработки этой темы она выигрывает, в части архитектурных решений в облаке конечно "Solution Architect" выглядит интереснее.

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

Итого
"Solution Architect" вполне подойдёт для упорядочивания знаний по облачной архитектуре, но не является ни Библией, ни источником в последней инстанции. Для глубокого погружения лучше дополнить другими материалами. Физическую версию нам прислало издательство «Питер» :)

в начало обзора ↑

AI-инференс станет новым двигателем cloud-native. Так считает глава CNCF

На мероприятии в честь 10-летия CNCF Джонатан Брайс, исполнительный директор фонда, заявил, что AI-инференс превратит Kubernetes-кластеры в центр притяжения для всей AI-инфраструктуры.

Давайте разберём, почему это не просто красивые слова.

Логика такая: открытые фундаментальные модели становятся лучше → компании начинают делать на их основе маленькие специализированные модели, заточенные под более узкий круг задач → эти модели нужно где-то запускать → и вот они уже крутятся на инференс-движках поверх Kubernetes-кластеров. То есть куб из «штуки для деплоя микросервисов» превращается в «штуку, на которой живёт AI».

И тут начинается самое интересное.

Это меняет всю картину для cloud-native проектов. Брайс считает, что AI-агенты постепенно станут основным способом вызова бэкенд-сервисов вместо привычных графических интерфейсов. То есть CNCF-проекты превращаются в headless-сервисы, которые вызывают агенты, а не люди через UI.

Но есть нюанс (куда без него). Существующие CI/CD-пайплайны и процессы code review уже не справляются с темпом, который задают AI-инструменты для написания кода. При этом качество этого кода оставляет желать лучшего, что только увеличивает нагрузку на мейнтейнеров Open Source-проектов. Брайс использовал термин «Eternal September» — как поток первокурсников, которые каждую осень приходят в универ и не знают вообще ничего о процессах. Только здесь этот поток не заканчивается.

В итоге получается, что AI генерирует больше кода, чем люди успевают ревьюить, а качество этого кода... ну, скажем так, оставляет простор для роста.

При этом роль инженера никуда не исчезает, а трансформируется в сторону platform engineering. Люди будут отвечать за архитектуру и качество, а агенты возьмут на себя рутину.

CNCF сейчас курирует больше 240 проектов. Какие из них останутся актуальными в эпоху AI — пока открытый вопрос.

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

Источник: cloudnativenow.com

Ну что, с возвращением!

Мы в январе притворялись, что отдыхаем (спойлер: не получилось), и запилили вам сайт:
devopsdeflope.ru

Внутри — новый сезон подкаста и архив старых выпусков (да-да, те самые легендарные). Можно выбрать площадку для прослушивания, которая вам удобна, — «Яндекс Музыка», Spotify, Apple Podcasts, VK.

Всё в одном месте. Заходите, смотрите. И да, если найдёте баги — пишите, допилим.

2025 год был... интересным. AI прилетел во все возможные продукты (и невозможные тоже), Kubernetes продолжал внедряться в работу с завидной настойчивостью, а количество инструментов для мониторинга выросло настолько, что теперь нужен мониторинг для мониторинга мониторинга.

Вы весь год тушили пожары в production, разбирались с упавшими подами в 3 часа ночи, оптимизировали то, что «и так работает», и объясняли разработчикам, почему нельзя просто «добавить больше памяти». И знаете что? Вы молодцы. Серьёзно.

Что мы вам желаем на 2026 год:
• Чтобы ваши дашборды всегда были зелёными. Ну или хотя бы желтыми. Красный — только для новогодних украшений.
• Чтобы CI/CD pipeline не падал, ни до merge, ни после. Потому что находить баги в production — это не та адреналиновая активность, которую мы выбирали.
• Чтобы документация была актуальной. Комментарий здесь мы даже не смогли придумать.
• Чтобы технический долг рос медленнее, чем зарплата. Хотя бы процентов на 10.

Желаем вам классных проектов, где можно применить то, что давно хотелось попробовать. Спасибо, что читаете нас.

P.S. Не забудьте проверить бэкапы перед праздниками. Нет, серьёзно. Проверьте.

— Редакция

Когда игровой планировщик оказался лучше для серверов Meta*

Meta запустила на своих production-серверах планировщик SCX-LAVD. Казалось бы, ну планировщик и планировщик. Но фишка в том, что его изначально разрабатывали для портативной игровой консоли Valve Steam Deck. То есть штука для карманного девайса теперь управляет дата-центрами одной из крупнейших IT-компаний мира.

SCX-LAVD — планировщик с учётом критичности задержек. Его создала консалтинговая компания Igalia по контракту с Valve специально для Steam Deck.

Инженеры Meta решили протестировать его на больших серверах. Результат оказался настолько хорошим, что Meta сделала SCX_LAVD планировщиком по умолчанию для своего парка серверов, который работает с различным оборудованием и сценариями использования. Оказалось, что даже на серверах с большим количеством CPU и памяти, LAVD прекрасно справляется с балансировкой нагрузки между CCX/LLC.

На конференции Linux Plumbers Conference в Токио инженеры Meta выступили с презентацией «Как заставить планировщик Steam Deck работать на больших серверах».

История показывает важный принцип в инфраструктурной разработке — не стоит сразу отметать решения из-за их происхождения. То, что планировщик создавался для игровой консоли, не делает его автоматически непригодным для серверов :)

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

Иногда лучший инструмент приходит оттуда, откуда его совсем не ждали.

Источник: phoronix.com
*Meta признана экстремистской организацией и запрещена в РФ.

Kuber Conf уже завтра, но вы успеваете запрыгнуть.

Смотрите, программа там реально насыщенная. Мы пробежались по докладам и выбрали то, что зашло:

• Как мы строили платформу деплоя в Т.
Послушаем про опыт построения универсальной платформы деплоя на базе OAM и KubeVela. Основная идея — вынести сложность конфигурации инфраструктуры и взаимодействия с Kubernetes на сторону платформы, а разработчикам дать простой и удобный интерфейс для описания приложений. Отдельный плюс: платформа берёт на себя вопросы EoL и миграций, снижая необходимость в бесконечных согласованиях и ручных договорённостях с командами.

• Vitastor и Kubernetes: есть ли жизнь на Марсе. Посмотрим, как интегрировать распределённую СХД через CSI и что там с производительностью в реальных условиях.

• Обучаем LLM по клику: платформа распределённого обучения на HGX. Доклад про то, как в Avito строили MLOps-инфраструктуру для обучения LLM на множестве узлов в рамках платформы Aviflow. Нам расскажут, чем обучение LLM отличается от «обычного» ML, какие технологии нужны для распределённого обучения, и как обернуть это в удобный сценарий. А также и о самом железе (HGX), и его нюансах эксплуатации.

Ещё два доклада будут от нас:
• А вы точно уверены в SLA своего кластера Kubernetes? Владимир Гурьянов из Deckhouse Observability разберёт, почему метрики в состоянии покоя не показывают реальную картину и как правильно тестировать доступность кластера. Плюс практический чеклист для измерения SLA.

• Не Talos единым: как ограничения научили нас ставить Kubernetes поверх любой операционной системы. Денис Романенко из Deckhouse Core покажет, как автоматизировать развёртывание Kubernetes поверх любой ОС, когда современные K8s-дистрибутивы недоступны или не подходят.

Днём слушаем доклады, вечером общаемся на афтерпати. Конфа уже послезавтра, наша редакция тоже там будет.

Нельзя так просто взять и спарсить 150 тысяч вакансий… Или можно?

Можно. Именно это сделал автор проекта TrueIndex, чтобы составить альтернативный TIOBE рейтинг, который показывал бы картину спроса на технологии в России.

Проблема того же TIOBE в том, что он считает поисковые запросы в Google. Люди могут искать что угодно из любопытства, для учёбы, для решения legacy-проблем. Но это не показывает, что реально нужно работодателям прямо сейчас.

TrueIndex пошёл от обратного и взял не запросы, а вакансии. Парсер собирает данные с HeadHunter и Habr Career, анализируя сотни тысяч объявлений. На их основе он считает статистику по языкам, фреймворкам, базам данных и другим технологиям, которые упоминаются в требованиях.

Первый же срез данных показал неожиданную картину. Технологии, специфичные для российского рынка (например, 1С), оказываются в топе по спросу, хотя в TIOBE их вообще нет, потому что за границей о них не знают. Языки, которые все считают устаревшими, спокойно держатся в топ-10 по количеству вакансий. А что-то вроде Fortran и Assembly из международных рейтингов в массовом найме практически не встречается.

Сейчас TrueIndex собирает данные с HeadHunter и Habr Career, ежемесячно обновляет рейтинг и постепенно расширяет набор метрик.

Зачем это всё? Если ты джун, рейтинг помогает увидеть, какие технологии дают больше всего «входных билетов» в профессию и где спрос не ограничивается одиночными вакансиями. Если ты мидл или сеньор — это удобный способ понять, в какой стек имеет смысл вкладываться, чтобы оставаться востребованным на российском рынке.

Ну а дальше можно просто зайти на trueindex.ru и посмотреть на актуальный рейтинг своими глазами.

ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.

Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.

ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.

Продукт уже работает для пользователей Kubernetes, Helm и GitOps.

Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.

Источник — пост Alexis Richardson на LinkedIn.

4 декабря в Москве пройдёт Kuber Conf от Ассоциации облачно-ориентированных технологий.

Флант, Yandex Cloud и VK Cloud создают АОТ, первую в России некоммерческую организацию для развития Cloud Native-технологий вне вендоров. И сразу делают конференцию, чтобы собрать всех, кто работает с Kubernetes и облаками.

На конфе представители ассоциации расскажут о проекте. Зачем всё это нужно и что хочется делать: стандартизировать компетенции, поддерживать Open Source, объединить сообщество.

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

Хотите стать спикером? Если работали с чем-то новым в Kubernetes, внедряли интересные решения в облаках или решали нетривиальные задачи — расскажите об этом. Рабочий опыт, сложные проблемы, даже провалы (они самые интересные и полезные). CFP ещё открыт.

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

Приходите, будет классно. Давно пора собраться и сделать что-то большое вместе.

До встречи 4 декабря!

Быстро потестировать etcd или поковырять containerd без поднятия локального кластера? Собрали браузерные песочницы, где можно экспериментировать с инфраструктурным софтом без танцев вокруг Docker Desktop и minikube.

1. Etcd Playground — для тех, кто хочет понять мозг Kubernetes
Интерактивная песочница с полноценным (но, ясное дело, учебным) кластером etcd из трёх нод.

2. Kubernetes Playground — браузерная площадка с готовым многоузловым кластером Kubernetes
Кластер развёрнут через kubeadm с возможностью выбора контейнерного рантайма и сетевого плагина. Можно экспериментировать с настройками, отлаживать манифесты и тренироваться в администрировании.

3. Nerdctl Playground — containerd с человеческим лицом
Площадка позволяет работать с containerd через Docker‑совместимый CLI, который упрощает работу по сравнению с нативным ctr. Можно изучать namespaces, snapshotter’ы и жизненный цикл контейнеров без установки локального рантайма.

4. KodeKloud Playgrounds — готовые среды под задачу
Предварительно настроенные среды под конкретные курсы (Terraform, Docker, K8s, Ansible). Не нужно ничего поднимать, остаётся только выполнять задания.

5. LabEx — тренажёр с дорожной картой
Пошаговое обучение с автоматической проверкой заданий. Много практических сценариев от базового Linux до сложных тем в K8s и Cloud.

6. Helm Playground — песочница для Helm-чартов
Позволяет экспериментировать с шаблонами, values и структурой чарта, сразу видя итоговые YAML-манифесты. Удобно для быстрой проверки идей и отладки шаблонов.

Эти площадки не заменят продакшен-кластеры со всеми их перформанс-проблемами, конечно же. Но будут весьма полезны для обучения.

Используете что‑то интересное для экспериментов с Kubernetes и containerd? Пишите в комментариях :)

Наткнулись на kubesec-diagram — интерактивную карту угроз Kubernetes, созданную внутри Telenor Norway. И знаете что? Она реально хорошая :)

Это интерактивная SVG-схема, визуализирующая поверхность атаки Kubernetes-кластера. Всё заточено под on-prem, так что для облачных K8s-кластеров и managed-сервисов может быть не так актуальна. Но, в целом, диаграмма может помочь, когда нужно быстро разобраться в security-контексте K8s или объяснить джуну, почему RBAC — это не просто галочка в чек-листе.

Внутри живая схема с кликабельными элементами. Тыкаете на "Container Process", получаете детали про PodSecurityContext, syscall restrictions и runtime enforcement. В разделе RBAC наглядно показана работа role bindings и опасность группы “system:masters”.

Думаем, что инструмент может быть полезен для DevOps/SRE-инженеров как минимум в двух основных сценариях: обучение новичков и быстрый аудит во время инцидентов. Да, большинство информации можно найти в CIS Benchmark или официальной документации K8s, но когда нужно быстро освежить тему или показать коллеге связь между компонентами — почему нет?

Диаграмма местами перегружена деталями, и для продакшена все равно придется изучать каждый компонент отдельно. Но как starting point для понимания attack surface в кластере — вполне годится. Ещё можно сесть, покопаться и найти что-то новое.

Проект активен, последнее обновление — v9 от августа 2025 года. Это полезный вспомогательный инструмент, но не истина в последней инстанции.

Сохраните в закладки для командных обсуждений архитектуры, но, всё же, для полноценного аудита полагаться на специализированные средства, такие как kube-bench, kubeaudit или Falco.

Проект на GitHub: github.com/kubesec-diagram/kubesec-diagram.github.io

Новый выпуск — и он про безопасность!

В нём эксперт по Application Security из Positive Technologies Владимир Кочетков рассказывает:

• что будет, если вообще забить на безопасность;
• почему от уязвимостей бизнес-логики «никогда в жизни не защитит» даже самый крутой AF;
• правда ли, что хакеры теперь умнее нас из-за ИИ;
• как внедрить безопасность, чтобы тебя не возненавидели все разработчики.

Слушать →
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

«Хилы, танки и дамагеры DevOps» — каждый понимает DevOps по-своему. В новом выпуске DevOps Deflope узнаете:

• Почему DevOps-инженеры сравнивают себя с героями WoW?
• Как пайплайны помогают печь круассаны?
• Зачем DevOps’у лезть в архитектуру приложений?
• Чему учат в магистратуре по DevOps и можно ли его считать методологией?

Гость выпуска Константин Дипеж — создатель магистратуры по DevOps, доцент МФТИ и автор канала DeusOps.

Слушайте:
на удобной площадке
на YouTube
на Яндекс Музыке
в Вконтакте

Книги от Google по SRE весьма полезны, но не у всех есть время прочесывать 1000+ страниц принципов и философии. Автор с Medium, Magsther, решил эту проблему — он прочитал всю трилогию и превратил массив теории в 100 практических уроков.

Каждый урок рассчитан на самостоятельное изучение. Есть и про философию, например, “Error budgets are the reliability currency”; и про практические правила — “No SLO? No reliability”.

Нет регистрации, рекламы или paywall. Ну круто же :)

Тем не менее, делимся и книгами, по которым и сделаны 100 уроков:

• Site Reliability Engineering (2016),
• The Site Reliability Workbook (2018),
• Building Secure & Reliable Systems (2020)

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

DevOps Deflope теперь и на Spotify.
А все (реально все, даже RSS-фид для олдскульных) другие сервисы найдёте на Mave.
Будем рады вашим звёздам, сердечкам и отзывам. Stay tuned!

Помните, Apple представила открытые проекты container и containerization для нативной контейнеризации на macOS? Написано на Swift, оптимизировано для Apple Silicon и вызывает больше вопросов, чем восторга.

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

Вместо привычной модели с shared kernel, Apple создают отдельную ВМ для каждого контейнера через Virtualization.framework. Обещают sub-second startup и hypervisor-level изоляцию, но на практике работает только на Apple Silicon с macOS 26. Экосистемы никакой, ни сompose, ни оркестрации.

Оба проекта  находятся в активной разработке. macOS 26 выйдет только в сентябре-октябре, так что сейчас это скорее preview для энтузиастов.

Мы так и не смогли понять, зачем нужен эппловский container, если уже есть docker-desktop и lima с привычным докером. Непонятно, будет ли работать в docker/containerd то, что сделано в container.

Возможно, это заготовка под будущие задачи Apple в области cloud/edge computing. А может, просто очередной эксперимент, который останется нишевым инструментом для узкого круга задач на macOS.

«Observability никому не нужно»

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

В этом выпуске Виталий Лихачёв, автор канала «Kubernetes и кот Лихачева», и Евгений Бастрыков, тимлид команды разработки Prom++, разберут:
- почему 90 % ваших алертов — мусор;
- как eBPF и OpenTelemetry пытаются спасти мир;
- можно ли получать метрики из… чего угодно (спойлер: да);
- почему «наблюдаемость» — это не про слежку, а про то, чтобы не сойти с ума.

И главное: кому вообще нужно это Observability, если Чак Норрис пишет код без багов?

Слушать:
на удобной площадке
YouTube
Яндекс Музыка

Традиционные WAF эффективны против классических веб-атак, но плохо справляются с современными угрозами API. Рассмотрим различия между WAF и WAAP подходами к защите.

В I квартале 2025 г. количество DDoS-атак на API в России выросло на 74% по сравнению с аналогичным периодом 2024 г. (данные StormWall), а традиционные WAF их попросту не видят. Хакеры больше не ломают двери, они используют правильные ключи в неправильном порядке.

Ваш WAF работает как охранник 90-х: проверяет документы по списку «плохих слов», но не понимает, зачем посетитель пришёл. Атакующий делает 1000 валидных запросов к /api/user/profile за секунду? WAF молчит, ведь каждый запрос синтаксически корректен. И атакующий спокойно вытаскивает персональные данные миллионов пользователей через некорректно защищенный эндпойнт.

Современные API-атаки выглядят совершенно легально: скрейпинг данных через легитимные GET-запросы в больших объёмах, обход бизнес-логики через неожиданную последовательность API-вызовов, злоупотребление функциональностью через комбинирование разрешённых операций. Все эти атаки возможны потому, что злоумышленники понимают бизнес-логику приложения лучше команды, которая её создала.

Web Application and API Protection не ищет «вредоносные» запросы. Вместо этого он изучает нормальные паттерны каждого API и детектирует аномалии поведения:

• ML-анализ в реальном времени.

Система знает, что пользователь обычно делает 3-5 запросов в минуту, а не 300

• Контекстное понимание workflow.

WAAP видит последовательности вызовов API и выявляет попытки обойти предполагаемые рабочие процессы.

• Автоматическое обнаружение API.

Мониторинг сетевого трафика находит «теневые» эндпоинты, о которых забыли документировать.

WAAP решает главную болевую точку CI/CD. С ним больше не нужно вручную настраивать правила для каждого нового эндпоинта. Выкатили новую версию API? WAAP автоматически анализирует трафик и настраивает защиту.

Есть и бонус для разработчиков. Вместо "security review" на две недели получаете автоматическую защиту с первого деплоя. Команда безопасности видит реальное поведение API, а не гадает на кофейной гуще по коду.

Как начать
• Аудит API-ландшафта. Соберите все эндпоинты в единый каталог с OpenAPI-спецификациями
• Стандартизация. Унифицируйте аутентификацию и error handling (WAAP лучше работает с консистентной архитектурой)
• Correlation ID. Добавьте во все запросы для отслеживания многоступенчатых атак
• Безопасность как код. Внедрите этот подход в API-фреймворки и CI/CD пайплайны

WAF защищал веб-сайты 15 лет назад, но сегодня у вас сотни микросервисов с тысячами API-эндпоинтов. WAF остается актуальным для защиты веб-интерфейсов, но API-инфраструктура требует дополнительных решений. Поэтому WAAP дополняет, а не заменяет существующую защиту, решая специфические задачи API-безопасности.

Внедряйте сейчас, пока атакующие не обошли ваши текущие «правила безопасности».

В начало поста ←

Чтобы каждая реплика LLM приходила за миллисекунды и не разоряла бюджет на GPU, инфраструктура должна быть столь же умной, как сама модель.

Сегодня для этого есть два зрелых Open Source-движка — vLLM и SGLang. Оба уже служат базой для корпоративных продуктов Red Hat и LMSYS, поэтому технологический риск минимален. Ниже — как каждый из них помогает бизнесу экономить и в каких сценариях их применять.

Почему это важно прямо сейчас? Стоимость GPU-минут растёт, а объём запросов к моделям увеличивается экспоненциально, что напрямую бьёт по TCO AI-инициатив.

vLLM — максимум пропускной способности

• PagedAttention устраняет 60-80% фрагментации памяти через блочные таблицы (как виртуальная память в ОС), давая до ×24 больше throughput, чем Hugging Face Transformers.
• Continuous Batching обрабатывает запросы по шагам генерации. Таким образом быстрые не ждут медленных, снижается latency и пропадает простой GPU (〜x23 прирост пропускной способности).
• Совместимость с OpenAI API позволяет мигрировать SaaS-сервисы без переписывания клиентского кода.

Именно vLLM лежит в основе Red Hat AI Inference Server для OpenShift, так что решение готово к production-кластерам. А ещё LMSYS сократил

парк

GPU на 50 %, одновременно увеличив число обслуживаемых запросов в 2–3 раза после миграции на vLLM.

SGLang — это экономия на связанных запросах

• RadixAttention строит древовидную структуру для переиспользования KV-кеша между запросами с общими префиксами. Если пользователь ведёт диалог, SGLang автоматически переиспользует уже вычисленные части контекста, ускоряя цепочки вызовов до ×5 и снижая вычислительные затраты.
• Строго заданный вывод: можно жёстко задать JSON-схему или грамматику, избегая дорогой поствалидации.
• Оптимальный выбор для диалоговых агентов, RAG-конвейеров и других сценариев, где соседние запросы делят контекст и важна точная структура ответа.

Как выбрать
Если ваша нагрузка — множество независимых коротких запросов и вы заменяете коммерческий API, ставьте vLLM: он максимально нагружает GPU и обеспечивает низкую задержку. Когда же важны длинные диалоги, строгий формат ответа или повторное использование контекста, применяйте SGLang, который экономит вычисления там, где другие их дублируют.

Итого
Разверните оба движка в одной инфраструктуре: vLLM — на «горячем» пути API для массовых запросов, SGLang — в сервисах с многошаговыми генерациями. Так вы получите быстрые ответы при минимальной стоимости GPU; именно то, что нужно бизнесу здесь и сейчас.