Спасибо всем, кто послушал доклад 🙌

Как и обещал, оставляю ссылки на наши proposal / PR / issue в Kubeflow Pipelines. Пулреквесты делал мой коллега Антон Печенин — Антон, тебе большое спасибо!

• proposal for central driver implementation — proposal по переводу KFP с driver pod на более лёгкую central driver архитектуру, чтобы уменьшить overhead запуска задач.
• central driver implementation — практическая реализация central driver подхода через Argo plugin flow вместо отдельного driver pod на каждую task.
• recurring runs queue throughput optimization — оптимизация scheduled/recurring runs, которая уменьшает лишние reconciliations и повышает throughput очереди регулярных запусков.
• gRPC metrics to api-server / optimize execution spec reporting — добавляет метрики в api-server и улучшает observability и эффективность backend-части KFP.
• pod lifecycle failure visualization — улучшает отображение и диагностику pod lifecycle ошибок в UI, чтобы такие сбои не приходилось искать только через kubectl.

Отдельно:

• Kubeflow ML Hub
• Kubeflow Manifests — для тех, кто хочет попробовать развернуть платформу у себя: манифесты и чарты можно брать оттуда.

Остальные источники, которые тоже могут помочь при построении ML-платформы, собрал здесь:
https://t.me/mlops_infra/114

Конишуа ребята!

Ну что, попробуем с вами немного кликбейтную историю.

50 лайков на пост и если набираем к концу июля 1000 подписчиков - лечу в Японию на KubeConf делать обзор на зарубежные конференции.

Узнаем че там с DRA, инференсом в k8s, как контрибьютят в kubeflow и kserve непосредственно от контрибьютеров)

Мне тут дали 3 Cowork invites в Claude на недельку, так что налетайте на промик

В целом норм история для задач не связанных с кодом. Например - заполнить доки для визы в Японию)))

GPU-шеринг как у Яндекса, но на open source: Kueue

Яндекс недавно рассказал про Dev Cluster, и также в каналах подозрительно много выложили постов про это (например раз и два) — самописную систему шеринга GPU между ML-инженерами: бери карту, когда нужна, отдавай, когда нет, простаивающее железо достаётся другим. Решение классное, разработчики большие молодцы - но хотелось бы и у себя потрогать это руками, а не только позавидовать и восхититься.

Похожий механизм мы собрали в Kubeflow на ванильном Kubernetes + Kueue. Вот из каких сущностей это состоит:

ResourceFlavor — типы железа. Каждый flavor привязан к нодам через nodeLabels/tolerations: standart (CPU), a100-80g, a100-40g, h100, hgx-h100, плюс MIG-слайсы (`a100-80-10/20/40gb`, `h100-10/20/40gb`) — одна A100/H100 нарезается на куски, и слайс тоже квотируемый ресурс.

Cohort (иерархические) — основа шеринга. Корневой кохорт root, под ним кохорт каждой команды. Гарантии команды (nominalQuota) объявлены на её кохорте, и через общего родителя команды могут занимать (borrow) простаивающие ресурсы друг друга.

ClusterQueue — на команду генерим две очереди:

• regular — нулевая собственная квота, живёт заимствованием из кохорта. Может брать чужой простой сверх гарантий команды;
• prod — гарантированный кусок (`prodResources`), borrowWithinCohort: Never — ничего не занимает, зато reclaimWithinCohort: Any — мгновенно вытесняет чужие borrowed-джобы, когда ресурс нужен проду.

Это и есть аналог «отдавай, когда владелец вернулся»: исследовательская джоба бежит на чужих простаивающих GPU, но при появлении prod-нагрузки владельца её вытеснят и поставят обратно в очередь.

WorkloadPriorityClass (`prod-workload`, value 1000) — приоритет вытеснения внутри очереди: withinClusterQueue: LowerPriority.

LocalQueue — точка входа для пользователей: в каждом team/user namespace автоматически создаются default и prod (через namespace-configuration-operator), пользователь просто указывает имя очереди в джобе.

Topology (TAS) — topology-aware scheduling: обычные флейворы паком по zone/hostname, а для HGX H100 — по InfiniBand scalable unit, чтобы multi-node training не размазывало по фабрике.

Итого: гарантии командам + утилизация простоя + честное вытеснение — без собственного шедулера, декларативно, в GitOps на MAU 1000 клиентов.

#mlinfra_digest

Всем привет!

Openclaw принес мне свежую порцию интересных статей про инфраструктуру платформ, выделил наиболее актуальные.

1️⃣ Cloud native is now AI-native: Engineering production-ready AI
Cloud native трансформируется в AI native.

На первый план выходят отдельные primitives: DRA, Pod Groups / Workload API, Inference Gateway, плюс разговор уже идёт про AI Conformance и security для agentic flows.

А вы уже во всю тестируете переход на DRA? Или продовый куб отстает на 10 версий от апстрима?)

2️⃣ Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support
Microsoft в Foundry Local на Azure Local добавили multi-node inference, vLLM runtime и planner, который сам подбирает memory-safe конфиг под модель и железо.

Меня здесь заинтересовал именно planner - как в azure подбирают параметры для vllm. Там еще отличная табличка какие параметры тюнить. Приложил к посту.

3️⃣ Reliable LLM Inference at Scale
У Databricks понравился акцент на том, что в проде проблема не в абстрактных benchmark’ах, а в том, как система ведёт себя под spiky demand.

Они пишут про:

• model-aware capacity planning,
• cost-aware routing,
• autoscaling по реальной стоимости нагрузки,
• recovery от silent failures и деградации latency.

4️⃣ How we achieved truly serverless GPUs
У Modal сильный инженерный разбор того, почему truly serverless GPUs — это сложно.
Ключевая проблема — startup latency, и решают они её через warm GPU buffers, lazy filesystem/image loading, checkpoint/restore и даже CUDA checkpoint/restore.

Я бы добавил еще тензерирование моделек, чтобы быстрее в GPU залетали и RDMA.

#mlinfra_digest

Снова подборочка от моего разнорабочего.

1️⃣ Speculation Is All You Need
🔎 О чём: Modal показывает, что speculative decoding даёт 2–3x прирост интерактивного inference и выпускает новые DFlash draft models для Qwen.

2️⃣ GKE Inference Gateway prefix caching accelerates AI inference
🔎 О чём: Google описывает prefix-cache-aware routing в GKE Inference Gateway и приводит бенчмарки по throughput, wait time и inter-token latency.

3️⃣ What’s New in the AI Platform: Agents for ML Engineering, Our Deep Learning Platform, and New Capabilities for Real-Time ML
🔎 О чём: Databricks анонсировал serverless GPU AI Runtime, усиление real-time serving и ML-агента, встроенного в feature/training/serving/monitoring контур.

4️⃣ Anyscale on Azure: Powering Enterprise AI at Massive Scale on Azure Kubernetes Service
🔎 О чём: Microsoft и Anyscale продвигают Ray как единый runtime для data prep, training, fine-tuning, inference и agentic execution поверх AKS.

5️⃣ Portable vLLM Model Inference Kernels in Helion
🔎 О чём: PyTorch/Red Hat интегрировали Helion kernels в vLLM для FP8-serving на Qwen3 и показали прирост throughput в fusion-heavy inference path.

ML для больших компаний.

Вышла моя статья про ML-платформу на Kubeflow. Это текстовый пересказ доклада на infra.conf2026, так что кто не успел посмотреть - теперь можно ознакомиться и в текстовом виде)

Также там удобно расставил ссылки на источники, например какие PR мы делали в community, где взять манифесты чтобы воспроизвести у себя платформу и другие полезные материалы

Всем привет!

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

Будут разбирать не просто вайбкодинг, а как этим нормально управлять: дать агенту контекст, написать task brief, посмотреть diff, тесты и побочки, и довести всё до PR - и даже покажут на реальном проекте.

Регаемся тут, а сам пост Эдгара здесь.

Друзья, моя первая папочка 📂 в телеге, да еще и с такими классными каналами про инфраструктуру для ML и LLM, а также про агентский кодинг и GPU.

Актуальные ресерчи, практика на k8s, бенчи с новых моделях (и не просто репосты и ссылки на существующие, а прогоны на личных домашних мини датацентрах)

Коротко по остальным ребятам:

- Александр - пишет про агентский Кодинг, продукты, Go и инженерную практику, еще и со статьями на Хабр
- Леха - не побоюсь - лучший ллмопс всея РФ по мнению всея меня и мой хороший товарищ, бенчит хайповые модели на своем звере из 4 rtx4090, гоняет агентов для за самыми хайповыми твитами по агентам и сотамоделями
- Эдгар - рассказывает как работать с AI-агентами в разработке без хаоса и нейрослопа
- Аня - пишет про Ruby, архитектуру, Go, и про агентскую разработку

Алгоритм простой
1. Подписываетесь на папку
2. Читаете 2-5 постов в каждом канале
3. Оставляете тех, кто зашел, навсегда

Сайт ml-infra.pro и личный роадмап

Всем привет!
Выложил свой сайт-визитку, где можно найти не только информацию обо мне, проектах и выступлениях, но и кое-что полезное для вас, начинающие MLOps-инженеры)

Представляю вам интерактивный роадмап для MLOps-инженера!

На менторских сессиях, посвящённых карьерному треку в MLOps, я всегда начинал с разбора бэкграунда менти и подбирал материалы для дальнейшего изучения. Изначально это была небольшая схема в Excalidraw (в комментах к посту в скриншотах можно увидеть пример).


Я её доработал, и теперь вы можете самостоятельно заполнять такую форму, находить материалы по каждому навыку, а также выбирать проект для закрепления навыков и самопроверки. Результаты заполнения можно экспортировать в JSON и Markdown, так что забирайте)

В качестве материалов использовал общедоступные статьи и туториалы, в том числе свои собственные. Также я всегда открыт к вашим запросам на индивидуальные разборы карьерного трека через платформу getMentor, где помог уже более чем 20 ребятам🔥

На сайте доступен ещё один роадмап - для оценки уровня зрелости вашей ML-платформы. Собрал в нём свой опыт построения продакшен-платформ за эти годы. Роадмап можно использовать для самопроверки и поиска материалов, которые помогут перейти на новый уровень. По построению таких платформ я также провожу консультации и не только🚀

В планах дальше наполнять сайт базой знаний по инфраструктуре для ML и AI - хочу сделать единую точку входа для таких материалов. Скоро выйдут две статьи: про мою поездку на KubeCon и про инференс-платформу, так что не теряйте)

Зачем своя Inference-платформа, если есть PaaS?

Всем привет! Вышла моя новая статья о том, почему мы не стали допиливать PaaS под ML/LLM, а строим отдельную Inference-платформу на KServe.

Для контекста: PaaS в Авито - это внутренняя платформа, где разработчик выкатывает микросервис в один клик, а CI/CD, базы, логи, метрики и автоскейлинг уже есть из коробки. Заточена она под stateless-сервисы на Go, которым нужны только CPU и RAM. Подробнее про неё - в этой статье.

Коротко о главном:

1️⃣ Модель - это не «ещё один микросервис». Динамический батчинг (разница в утилизации GPU до 5-10x), очередь с backpressure, привязка к железу и FP8 - всё это не должно жить в бизнес-логике рядом с HTTP-роутингом.

2️⃣ GPU плохо дробится и стоит дорого. HPA по CPU/RAM для LLM бесполезен, скейлиться надо по очереди и KV-кэшу. А холодный старт с образом на 15-20 ГБ и весами в десятки ГБ может растянуться на десятки минут.

3️⃣ Допилить PaaS = кварталы разработки и риск для платформы, на которой живёт весь бэкенд. По факту внутри PaaS выросла бы та же отдельная платформа, только запутаннее.

4️⃣ Почему KServe. Сравнили с Seldon (LLM-фичи только в enterprise), Ray Serve и BentoML («k8s внутри k8s»), vLLM Production Stack (завязан на один движок). KServe оказался самым функциональным и для ML, и для LLM, плюс свежий LLMInferenceService на архитектуре llm-d.

5️⃣ Своя абстракция. Берём готовое ядро и добавляем обертку в виде сервиса контроллера: таким образом не завязываемся на конкретный open source и в случае смены ядра пользователи этого не заметят.

Платформа уже крутится на реальном трафике у нескольких команд, а цифры по экономии GPU-часов будут в следующих сериях, так что stay tuned)

Налетайте читать🔥 и пишите в комментах, как у вас: инференс живёт в общем PaaS или отдельно?

Рекомендую посмотреть подкаст от Контура про то как они делают продакшен инференс LLM. Не часто в рф рынке об этом рассказывают, можно многое подчерпнуть про опыт эксплуатации vllm/sglang, почему не triton и как оптимизировать инференс на большой поток трафика.

Сам активно использую суммарайзеры в толке - годная вещь, рад за отечественный продукт. С Азиком знаком лично, он большой молодец)

Обещал обзор с KubeCon - держите)

Помните, в июне я обещал: наберём 1000 подписчиков - лечу в Японию на KubeCon?
Набрали, слетал, и вот вышла статья на Хабре🔥

Ко второму дню я понял, что у всех одни и те же слайды: квоты, изоляция тенантов, bin packing и «GPU дорогие - давайте делить». Так что разобрал шесть докладов про то, как утилизируют GPU, и сравнил с тем, что делаем мы.
Также небольшое самари из статьи:

1️⃣ Инференс стал главным потребителем GPU. Две трети AI-compute уходит на инференс, и экосистема CNCF разворачивается к сервингу.

2️⃣ Все делят GPU, и слайды у всех одинаковые. Мультитенантность, квоты и плотная упаковка стали главным трендом конференции. Kueue, HAMi, vCluster и HNC — разные точки одной шкалы.

3️⃣ llm-d становится стандартом LLM-инференса. KV-aware routing почти даром даёт кратный выигрыш, а P/D без настройки легко делает только хуже.

4️⃣DRA стал фундаментом для новых проектов. На нём уже строят топологию GPU + NIC и composable-железо, так что миграцию стоит закладывать уже сейчас.

5️⃣На KubeCon едут за open source. Почти всё из докладов можно забрать к себе, а также поговорить с реальными мейнтейнерами проектов.

А в конце - впечатления, чем KubeCon отличается от наших конференций, и немного Японии: рамен, конбини и Фудзи, которая так и не вышла из облаков 😅

Налевайте что-нибудь крепкое (например, чай) и налетайте читать!

Роадмап MLOps: уровни и свой трек

Всем привет!
Недавно на консультации расписывали с менти интерактивный роадмап для MLOps-инженера. Понял, что он получился достаточно громоздким и не очень понятно в какой последовательности изучать материал)

Теперь там можно не только отметить, что уже знаешь, но и собрать свой трек изучения:

- у каждого навыка появился уровень Junior, Middle или Senior (лычки в углу кружка). Фильтром оставляешь нужный уровень, с Shift - сразу два
- двойной клик по кружку ставит навык в очередь его уровня. На «Все» очереди склеиваются в один трек Junior → Middle → Senior с номерами и стрелками
- «только трек» приглушает остальную карту, чтобы не рябило)
- порядок изучения уезжает в выгрузку JSON и Markdown вместе с проектом, который закроет больше всего пробелов

Ещё добавил два сеньорных навыка - Distributed LLM inference и LLM gateway.

Как это выглядит - в видео.

Соберите свой трек и пишите в комментах, каких навыков или проектов не хватает на карте🔥