DevOps_ru за 17.06.2026: Инфраструктура для LLM, тонкости…

Ключевые события и тренды

Дискуссия о вычислительной инфраструктуре для LLM и проблемах с производительностью

В сообществе DevOps_ru развернулась активная дискуссия о локальном запуске больших языковых моделей (LLM) и необходимой для этого инфраструктуре. Обсуждение началось с шутливого сравнения запуска ОС с флешки и развертывания Kubernetes, быстро переключившись на будущее с инференсами для LLM.

• Аппаратные требования для LLM: Участники обсуждали высокие требования к GPU для запуска моделей объемом в сотни гигабайт.
  • Эксперт по GPU и Эксперт по GPU сравнивали видеокарты H200 (141 ГБ VRAM) и B200 (180 ГБ VRAM), отдавая предпочтение последней, несмотря на двойную стоимость.
  • Скептик по требованиям к железу выразил удивление объемами моделей в 200 ГБ для локального запуска и иронизировал о покупке "компудацкера в ипотеку с парочкой H100".
  • Эксперт по бенчмаркам упомянул, что для игр ему хватает 256 ГБ, намекая на избыточность таких мощностей для большинства задач.
• Производительность распределенных систем и MLOps: Обсуждались узкие места при работе с большими данными и кластерами.
  • Эксперт по RDMA и Эксперт по сетевым узким местам поделились опытом, что RDMA, хорошо показывающая себя на синтетических тестах, упирается в сеть при работе с реальными данными.
  • Эксперт по Spark рассказал об использовании DeepSeek-V4-Flash на "парочке спарков" и отметил, что она работает "на удивление неплохо", в то время как последние версии GPT "жестко тупят".

Вызовы в Kubernetes-ингрессе и Service Mesh

В чате Kubernetes_ru активно обсуждались сложности выбора и настройки Ingress-контроллеров и Service Mesh.

• Istio vs. Ingress-Nginx: Участники столкнулись с дилеммой использования тяжеловесного Istio только для Ingress-функционала.
  • Эксперт по Istio выразил желание использовать Istio Ingress без Service Mesh, на что Эксперт по Nginx отметил, что "он же один хуй с остальным истио ставится", имея в виду множество CRD и оператор, даже если сайдкары не используются.
  • Эксперт по Istio пытался использовать ingress-nginx, но столкнулся с проблемами, включая "кучу cve новых" и отсутствие Lua для балансировки в вендорной версии.
  • Эксперт по Nginx предположил, что проблемы с релоадами в nginx nginx могли быть исправлены, но не был уверен. Эксперт по Ingress подтвердил, что "всё по прежнему убого, особенно по части метрик".
• Сравнение с EnvoyGateway: Эксперт по EnvoyGateway отметил, что Istio Ingress "по идее не умеет ничего нового, что уже есть в EnvoyGateway".

Интеграция Netbird и Keycloak для управления доступом

Возникла серьезная дискуссия о правильной интеграции Netbird с Keycloak (и другими SSO-провайдерами) для управления группами и доступом.

• Проблемы с группами и полиси: Эксперт по интеграции SSO и Эксперт по интеграции SSO обсуждали сложности с передачей кастомных групп из Keycloak в Netbird и применением политик к еще не существующим группам. Эксперт по интеграции SSO отметил, что в последних версиях убрали возможность определения кастомного claim под группы, и теперь только дефолтные group поддерживаются, что приводит к появлению ненужных групп в Netbird.
• Синхронизация сессий: Эксперт по интеграции SSO также поднял вопрос о неразлогинивании пользователя из Netbird после завершения его сессии в Keycloak. Эксперт по валидности токенов пояснил, что это происходит из-за проверки валидности JWT-токена в Netbird, который сам по себе остается валидным до истечения срока, независимо от статуса сессии в Keycloak. Эксперт по интеграции SSO уточнил, что для такой синхронизации требуется "тырпрайз фича" – IDP Sync, где Netbird периодически опрашивает IDP.
• Workarounds: Эксперт по интеграции SSO упомянул использование кастомного flow в Authentik для переопределения групп или управление группами/пользователями через Terraform с использованием встроенного DEX.

Финальная аналитика

День 17 июня 2026 года в русскоязычных DevOps и Kubernetes сообществах был насыщен глубокими техническими дискуссиями. Основными темами стали быстрорастущие потребности в аппаратном обеспечении для MLOps, сложности конфигурирования сетевых решений в Kubernetes и детали интеграции систем управления доступом.

Эмоциональный тон обсуждений был преимущественно профессиональным и ориентированным на решение проблем, хотя в DevOps_ru проскальзывали нотки юмора и иронии по поводу стоимости и доступности мощных GPU. В Kubernetes_ru фокус был строго на технических аспектах и поиске обходных путей.

Были выявлены несколько информационных пробелов и нерешенных вопросов. В частности, отсутствие однозначных рекомендаций по выбору Ingress-контроллера при специфических требованиях (например, желание использовать только часть Istio), а также отсутствие простых и надежных решений для синхронизации групп и сессий между Netbird и внешними IdP без использования платных функций или сложных костылей.

Потенциальные последствия этих обсуждений указывают на продолжающийся рост сложности в области DevOps. Компании будут сталкиваться с высокими затратами на инфраструктуру для AI/ML, необходимостью глубокого понимания сетевых протоколов и Service Mesh, а также с вызовами в создании бесшовных и безопасных систем управления доступом. Тренд на локальный запуск LLM подчеркивает важность производительной и доступной инфраструктуры, что может привести к увеличению спроса на специалистов, способных оптимизировать распределенные вычисления и сетевые взаимодействия.