MoE — это архитектура, где большая нейросеть разделяется на несколько специализированных подсетей (экспертов), а гейтинг-сеть (маршрутизатор) решает, кто лучше справится с конкретным запросом. Это позволяет экономить вычислительные ресурсы.

Как работает MoE:

⚪️ Эксперты: подсети (например, feed-forward сети), каждая из которых специализируется на определённой части данных. Например, в языковых моделях один эксперт может понимать синтаксис, другой — семантику.
⚪️ Гейтинг-сеть: решает, какие эксперты будут задействованы для конкретного запроса, присваивая каждому эксперту вес. Например, в Mixtral 8x7B для каждого токена выбираются два эксперта из восьми.
⚪️ Селективность: в отличие от классических моделей, где вся сеть работает всегда, MoE активирует только нужные части, что ускоряет обучение и инференс.

Плюсы MoE:

⚪️ Экономия ресурсов: увеличивает размер модели (больше параметров), но не увеличивает вычислительные затраты.
⚪️ Гибкость: эксперты могут специализироваться на разных задачах, что улучшает качество обработки сложных данных.
⚪️ Масштабируемость: MoE позволяет создавать модели с триллионами параметров, как в случае с GLaM или Switch Transformers.

Минусы и сложности:

⚪️ Балансировка нагрузки: если гейтинг-сеть плохо распределяет задачи, некоторые эксперты могут быть перегружены, а другие — простаивать. Для этого добавляют вспомогательные функции потерь (auxiliary loss).
⚪️ Обучение: требует тонкой настройки, так как гейтинг-сеть и эксперты обучаются одновременно. Нужны большие батчи данных, чтобы маршрутизация была эффективной.
⚪️ Специализация: эксперты не всегда учатся понимать конкретные домены (например, биологию), а скорее фокусируются на низкоуровневых аспектах, таких как синтаксис.

Примеры применения:

➖ В языковых моделях (NLP): Switch Transformers, Mixtral 8x7B, GLaM — для обработки текстов с высокой эффективностью.
➖ В компьютерном зрении: MoE помогает справляться с большими наборами данных, где разные эксперты могут фокусироваться на разном.
➖ В системах рекомендаций: MoE улучшает персонализацию, разделяя пользователей на кластеры и подбирая для каждого подходящего эксперта.

👉 Посмотреть тест-драйв технологии

@DevOpsKaz 😛

🔥 CPU Limits в Kubernetes: Как избежать троттлинга и ускорить приложения

Статья по докладу о CPU Limits в Kubernetes объясняет их влияние на производительность контейнеров. Автор разбирает концепцию CPU Requests и Limits, их связь с cgroups v2 и даёт рекомендации по использованию.

Самое главное ниже 👇

CPU Requests задают минимально гарантированное процессорное время для контейнера, а CPU Limits — максимальное.

Limits ограничивают использование процессора в "окне" 100 мс (например, при лимите 0.4 ядра контейнер получит 40 мс из 100 мс). Это реализуется через cgroups v2 в Linux, которые управляют распределением ресурсов.

Проблемы с CPU Limits:

Для приложений, чувствительных к задержкам, throttling критичен: могут не сработать liveness probes, пропуститься heartbeat-события, увеличиться задержка ответа.

Даже при низкой загрузке процессора (например, 50%) контейнер может троттлиться из-за многопоточности или ошибок в ядре Linux.

Как работает throttling:

Если задаче нужно 200 мс процессорного времени, но у вас лимит 0.4 (40 мс на 100 мс), то 160 мс придётся ждать новых "окон". Итог: задача займёт 440 мс вместо 200 мс, так как 60 мс в каждом окне — это простой. Throttling (замедление) возникает, даже если у узла есть свободные ресурсы.

Когда использовать CPU Limits:

⚪️ Нужно: в редких случаях, например, для пакетных задач (batch jobs), где задержки некритичны, или если есть баг в приложении, из-за которого оно потребляет слишком много CPU.
⚪️ Не нужно: для большинства приложений, особенно чувствительных к задержкам (веб-серверы, базы данных). Лучше полагаться на CPU Requests, чтобы гарантировать минимум ресурсов без искусственного замедления.

Рекомендации:

➖ Устанавливайте только CPU Requests, чтобы гарантировать минимум ресурсов без троттлинга.
➖ Если Limits всё же нужны, делайте их значительно выше Requests (например, в 2–3 раза), чтобы учесть пиковые нагрузки.
➖ Регулярно мониторьте метрики и корректируйте настройки, особенно при росте нагрузки.
➖ Проверяйте логи приложений на увеличение времени обработки запросов.
➖ Обновляйте ядро Linux до версий без багов CFS (Completely Fair Scheduler), которые могут вызывать лишний троттлинг.

@DevOpsKaz 😛

🔥 Участвуйте в AppSecFest 2025 — выигрывайте 4 Macbook-а и другие призы

Уже в эту пятницу 25 апреля мы встретимся на важном событии в мире IT, разработки и безопасности — AppSecFest 2025.
В программе:

⚪️ 2 конференц-зоны: App — инновации в разработке ПО, Sec — все о безопасности приложений
⚪️ 20+ ведущих спикеров: топовые эксперты поделятся своими знаниями и опытом
⚪️ 2+ панельные сессии: обсуждения горячих тем и трендов отрасли
⚪️ 1000+ участников — возможность для нетворкинга и обмена опытом
⚪️ Лидеры индустрии — познакомьтесь с ключевыми игроками и партнерами
⚪️ Игровая зона и дрон-футбол
⚪️ Подарки и розыгрыши
⚪️ OpenCTF

➡️ Регистрируйтесь здесь

Ждем вас на AppSecFest 2025 в Алматы!

#партнерский_пост

@DevOpsKaz 😛

🔥 Новости мира DevOps и не только

⚪️ Oracle Critical Patch Update

Oracle исправила 378 уязвимостей в MySQL, Java SE, VirtualBox и других продуктах в апрельском обновлении безопасности.

⚪️ Freedom Cloud в Казахстане

В Алматы началось строительство дата-центра Freedom Cloud с инвестициями 175 млрд тенге от Freedom Holding Corp. Проект усилит цифровую инфраструктуру, создаст рабочие места и будет соответствовать стандартам NVIDIA.

⚪️ Almaty Hub: трансформация инноваций

«Парк инновационных технологий» переименован в Almaty Hub (by Astana Hub). Новый гендиректор Ержан Тасмухан займётся развитием стартапов и привлечением инвестиций.

⚪️ Казахстанские стартапы в StartX

Наш клиент — Parqour (управление парковками), Aidentis (AI-диагностика в стоматологии) и TrustExam.ai (честность онлайн-обучения) прошли в летнюю программу акселератора StartX при Стэнфорде.

@DevOpsKaz 😛

🔥 Как Amazon справилась с нехваткой GPU

В 2024 году Amazon столкнулась с глобальной нехваткой GPU из-за бума ИИ-технологий и дефицита чипов NVIDIA. Это сильно ударило по ретейл-подразделению, где внутренние проекты начали тормозить из-за недостатка вычислительных ресурсов.

Если инфраструктура не справляется с нагрузкой, это напрямую влияет на скорость разработки, доставку продуктов и, в конечном счёте, на прибыль компании.

💡 Решение: Project Greenland и новые правила распределения

Компания ввела строгие правила, основанные на следующих принципах:

⚪️ Приоритет по ROI: мощности GPU распределяются по проектам, которые приносят наибольшую финансовую выгоду или снижают затраты. Если проект не оправдывает ожиданий, выделенные ресурсы могут быть отозваны.
⚪️ Централизованное управление: все запросы на GPU теперь проходят через Project Greenland, что позволяет отслеживать использование ресурсов и перераспределять их между командами.
⚪️ Максимальная утилизация: платформа следит за простаивающими серверами и перераспределяет их на более приоритетные задачи.
⚪️ Долгосрочный рост: распределение ресурсов должно способствовать увеличению свободного денежного потока компании в будущем.

Результат:

К 2025 году ситуация улучшилась. Дефицит GPU устранён, а их собственный чип Trainium начал удовлетворять потребности ретейл-подразделения к концу года.

Project Greenland показывает, как централизованное управление и приоритизация по бизнес-целям помогают справляться с ограничениями ресурсов. DevOps-команды могут адаптировать этот подход, особенно если работают с ресурсоемкими ИИ.

@DevOpsKaz 😛

🔥 Устройство файловых систем контейнеров

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

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

👉 Читайте в блоге

@DevOpsKaz 😛

🔥 CORE 24/7 приглашает на вакансию DevOps-инженера

Алматы/Астана, офис
Опыт работы: 2-3 года
Полная занятость
ЗП: 450 000 — 1 000 000 тг.

Задачи:
— Поддерживать production так, чтобы бизнес был спокоен
— Спасать клиентов в случае аварий
— Выстраивать процессы CI/CD
— Переносить приложения в Kubernetes. Запускать и настраивать их
— Конфигурировать СУБД, серверы очередей и прочий софт. Делать более надежными и быстрыми.
— Разрушать стену между разработкой и администрированием

С кем вы будете работать:
— С клиентом, тимлидом и ПМом
— С командой разработки инструментов, сервисов и технологий для упрощения работы (автоматизация наше все)

Требования:
— Отличные знания Linux-систем - ежедневная эксплуатация от 3 лет, опыт в DevOps - от 1 года
— Понимание работы веб-приложений и опыт их эксплуатации - от 3 лет
— Понимание веб-стека (HTTP, TCP/IP), устройства и работы сетей, базовые навыки с iptables
— Понимание принципов СУБД, построения и эксплуатации распределенных систем
— Умение сформулировать алгоритм и писать скрипты

Что мы предлагаем:
— Погружение в передовые cloud-native-технологии и участие в разработке Open Source / AI продуктов.
— Уникальная открытая корпоративная культура: отсутствие строгой субординации, самостоятельность и доверие.
— Постоянное обучение у крутых коллег, которые готовы делиться опытом: у нас есть все необходимое для роста и развития.
— Курсы английского языка, отраслевую сертификацию, компенсацию тренажерного зала и прочие бонусы.

Писать сюда:
👉 aissabekova@core247.io
👉 @issaika

Полное описание вакансии

@DevOpsKaz 😛

🔥 Оптимизация ресурсов для инференса LLM без лишних сложностей

Если хотите не только обучить LLM, но и приручить ее (а выходные для этого само то 😂), мы поможем подобрать инфраструктуру.

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

⚪️ Модели и их документация

• Карточка модели Qwen2.5-32B-Instruct-AWQ на Hugging Face — содержит описание модели, параметры и инструкции по использованию.
• Документация по квантованию: GGUF, AWQ и GPTQ — полезно для понимания методов оптимизации памяти.

⚪️ Оценка и расчёт ресурсов

• Статья NVIDIA, как оценить требования к VRAM при выборе GPU для инференса.
• Онлайн-калькулятор VRAM LLM Calc — удобный инструмент для расчёта необходимой памяти в зависимости от параметров модели и квантования.

⚪️ Фреймворки для инференса

• Ollama — простой инструмент для локального инференса LLM.
• SGLang — фреймворк для ускорения инференса, с открытым кодом.
• VLLM — высокопроизводительный фреймворк для серверного инференса.
• Документация по настройке VLLM Engine Args — подробное описание параметров для оптимизации работы VLLM.

⚪️ Инструменты нагрузочного тестирования

Универсальные инструменты: Locust, k6, Gatling, Apache JMeter, Яндекс.Танк — подходят для тестирования производительности бэкендов.

⚪️ Инструменты NVIDIA для инференса:

• Perf Analyzer — утилита для анализа производительности инференса.
• Gen AI Perf — специализированный инструмент для LLM.
• Режимы Gen AI Perf: Analyze и Sessions — помогают анализировать производительность в различных сценариях.

⚪️ Бэкенды Triton для LLM

• VLLM Backend — интеграция VLLM с Triton Inference Server.
• TensorRT LLM Backend — бэкенд для ускорения инференса с использованием TensorRT.
• Triton CLI — упрощает импорт конфигураций и запуск инференса на Triton.

⚪️ Бенчмарки и сравнения

• TensorRT LLM Performance Overview — бенчмарки производительности TensorRT LLM от NVIDIA.
• Статья BentoML — сравнение различных бэкендов для инференса LLM.

Эта подборка охватывает все этапы работы с LLM: от выбора модели до тестирования производительности.

Пользуйтесь и делитесь с коллегами 🫡

@DevOpsKaz 😛