Anton Alekseev | Инфраструктура для AI и ML

Конишуа ребята! Ну что, попробуем с вами немного кликбейтную историю. 50 лайков на пост и если набираем к концу июля 1000 подписчиков - лечу в Японию на KubeConf делать обзор на зарубежные конференции. Узнаем че там с DRA, инференсом в k8s, как контрибьютят…

Друзья, моя первая папочка 📂 в телеге, да еще и с такими классными каналами про инфраструктуру для ML и LLM, а также про агентский кодинг и GPU. Актуальные ресерчи, практика на k8s, бенчи с новых моделях (и не просто репосты и ссылки на существующие, а прогоны на личных домашних мини датацентрах) Коротко по остальным ребятам: - Александр - пишет про агентский Кодинг, продукты, Go и инженерную практику, еще и со статьями на Хабр - Леха - не побоюсь - лучший ллмопс всея РФ по мнению всея меня и мой хороший товарищ, бенчит хайповые модели на своем звере из 4 rtx4090, гоняет агентов для за самыми хайповыми твитами по агентам и сотамоделями - Эдгар - рассказывает как работать с AI-агентами в разработке без хаоса и нейрослопа - Аня - пишет про Ruby, архитектуру, Go, и про агентскую разработку Алгоритм простой 1. Подписываетесь на папку 2. Читаете 2-5 постов в каждом канале 3. Оставляете тех, кто зашел, навсегда

Всем привет! У моего товарища будет воркшоп про AI-агентов в разработке - будет полезно всем, кто хочет не утонуть в нейрослопе, который потом самому же поддерживать. Сам тоже загляну, для меня актуальная проблема вычищать нейрослоп из агентов, но времени не хватает постоянно новые подходы самому ресерчить - а тут за часик все расскажут, покажут) Будут разбирать не просто вайбкодинг, а как этим нормально управлять: дать агенту контекст, написать task brief, посмотреть diff, тесты и побочки, и довести всё до PR - и даже покажут на реальном проекте. Регаемся тут, а сам пост Эдгара здесь.

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

#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.

#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.

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 клиентов.

Мне тут дали 3 Cowork invites в Claude на недельку, так что налетайте на промик В целом норм история для задач не связанных с кодом. Например - заполнить доки для визы в Японию)))

Конишуа ребята! Ну что, попробуем с вами немного кликбейтную историю. 50 лайков на пост и если набираем к концу июля 1000 подписчиков - лечу в Японию на KubeConf делать обзор на зарубежные конференции. Узнаем че там с DRA, инференсом в k8s, как контрибьютят в kubeflow и kserve непосредственно от контрибьютеров)

Спасибо всем, кто послушал доклад 🙌 Как и обещал, оставляю ссылки на наши 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

Доклад на infra.conf 2026! Привет! 4 июня в Москве на infra.conf 2026 буду рассказывать как в avito строим ML платформу на базе kubeflow. Режиссерская расширенная версия моего доклада про ml платформы. Расскажу подробно технические реализации всех компонент • очереди задач на Kueue • что мы патчили в пайплайнах kubeflow и сократили в 2 раза использование ресурсов k8s • как настроили observability и добавили интеграцию с секретами • как делаем инференс на kserve и свой model registry. Стоит ли делать отдельную платформу инференса или запускать их в PaaS. Регистрируйтесь, мероприятие бесплатное) Жду вас на конфе!

Собрал ссылки по темам из моего доклада, чтобы можно было не только посмотреть презентацию, но и пойти дальше в детали. А также запись выступления. 1. Три подхода к построению MLOps-платформы Когда мы проектировали курс по MLOps для Яндекс Практикума, отдельно разобрали три варианта архитектуры MLOps-платформ на примерах известных западных компаний. Если хочется посмотреть на разные платформенные подходы не абстрактно, а через реальные архитектурные паттерны, начать можно отсюда. https://habr.com/ru/companies/yandex_praktikum/articles/1014322/ 2. Kubeflow: профили и enterprise-расширение Если вам интересен multi-tenancy в Kubeflow, советую посмотреть, как устроены профили в Kubeflow, а затем заглянуть в пример enterprise-плагина для автоматического добавления профилей и интеграции с корпоративной моделью доступа. Профили: https://www.kubeflow.org/docs/components/central-dash/profiles/ Пример IAM-плагина: https://github.com/kubeflow/kubeflow/blob/v1.10-branch/components/profile-controller/controllers/plugin_iam.go 3. Kueue Мы используем Kueue как основной scheduler для AI workloads. Если вам интересны очереди задач, квоты, fair sharing и базовые принципы платформенного планирования ML-нагрузки в Kubernetes, здесь можно посмотреть основные концепции. https://github.com/kubernetes-sigs/kueue https://kueue.sigs.k8s.io/docs/concepts/ 4. Istio Sidecar Если вы используете Istio как service mesh, советую присмотреться к настройкам Sidecar. Это помогает сократить лишнюю нагрузку на Envoy и заметно экономить оперативную память. https://istio.io/latest/docs/reference/config/networking/sidecar/ 5. Распределённое обучение в Kubeflow Если вы делаете distributed training в Kubeflow, рекомендую обратить внимание на trainer-operator. Это одна из базовых точек входа в платформенный слой для распределённого обучения. https://github.com/kubeflow/trainer 6. Секреты и доступы В этой статье хорошо разобраны варианты интеграции Kubernetes-кластера с корпоративным Vault, включая практическую сторону работы с секретами и доступами. https://habr.com/ru/companies/oleg-bunin/articles/919234/ 7. KServe и LLM inference Если смотреть на то, как сегодня выглядит LLM inference в KServe, то вот хорошая точка входа в LLMInferenceService и текущую модель generative inference в платформе. https://kserve.github.io/website/docs/model-serving/generative-inference/llmisvc/llmisvc-overview 8. Таймлайн про MLOps до 2035 года И отдельно оставлю доклад с размышлениями о том, куда вообще движутся MLOps-платформы и почему со временем платформенный слой будет появляться практически везде. https://www.youtube.com/watch?v=kWBpQZIGmik Спасибо что слушали доклад! Вопросы можно задавать в комментариях)

Хеллоу! #mlinfra_digest Сегодня дайджест выходит на денек раньше. А знаете почему? Конечно знаете, завтра буду уже традиционно выступать на MLечный путь 2026, обязательно приходите или подключайтесь онлайн) А пока ждем это событие, предлагаю посмотреть на следующие интересные статьи за последнее время. 1️⃣ State of the Model Serving Communities Хорошая сводка последних апдейтов по open source serving/inference-проектам. Удобно, когда хочется быстро сверить, что происходит вокруг KServe, Gateway API Inference Extension, llm-d и соседних инициатив, не вычитывая десятки отдельных анонсов. https://inferenceops.substack.com/p/state-of-the-model-serving-communities-b93 2️⃣ Unifying real-time and async inference with GKE Inference Gateway Интересный практический разбор того, как делать асинхронный inference и при этом не разводить отдельные serving-контуры под каждый тип нагрузки. И что особенно приятно, async inference тут уже можно не только читать как идею, но и реально трогать руками, например через llm-d async и Async Processor. Статья - https://cloud.google.com/blog/products/containers-kubernetes/unifying-real-time-and-async-inference-with-gke-inference-gateway Репозиторий - https://github.com/llm-d-incubation/llm-d-async/blob/main/README.md Дока - https://llm-d.ai/docs/guide/Installation/asynchronous-processing 3️⃣ Optimizing RDMA performance for AI workloads on AKS with DRANET А вот это уже более low-level infra история, и снова про DRA! Тут речь про RDMA, топологию деплоя ворклоудов (чтобы они были поближе друг-к-другу и соеденены каким-нибудь nvlink). Вещи, которые реально начинают влиять на latency и throughput, когда выходишь за рамки простого single-node serving. DRA расматривается как решение не только для GPU - это общий стандарт, сетевая топология тоже будет имплементироваться через ResourceClaim'ы. https://blog.aks.azure.com/2026/04/01/dranet-rdma-optimization-for-ai-on-aks

Всем привет! #mlinfra_digest Пока смотрю свежие материалы по инфраструктуре для AI/ML, всё сильнее ощущение, что основная сложность уже давно не в том, как поднять модель, а в том, как потом всем этим нормально управлять в production. 1️⃣ Experimenting with GPUs: GKE managed DRANET and Inference Gateway AI Deployment Хороший материал от Google про DRANET и inference gateway как отдельный слой платформы для AI-нагрузок. Плюс inference gateway уже можно смотреть не только как идею из вендорских постов, но и как расширение Kubernetes Gateway API, которое уже хочется руками тестировать. https://cloud.google.com/blog/topics/developers-practitioners/experimenting-with-gpus-gke-managed-dranet-and-inference-gateway-ai-deployment https://github.com/kubernetes-sigs/gateway-api-inference-extension 2️⃣ Unlock efficient model deployment: Simplified Inference Operator setup on Amazon SageMaker HyperPod У AWS понравился сам подход к inference operator. Если хочется писать свой оператор для inference platform, полезно посмотреть, как это разложено у них: lifecycle, rollout и platform-style управление serving-слоем. Особенно если KServe вам по каким-то причинам не подходит и хочется собирать более кастомный control plane. https://aws.amazon.com/blogs/architecture/unlock-efficient-model-deployment-simplified-inference-operator-setup-on-amazon-sagemaker-hyperpod/ 3️⃣ Overcoming inference challenges У Red Hat понравилась простая и очень жизненная мысль: первый успешный ответ от модели это не победа, а только старт. Дальше начинается Day 2, где нужно разруливать hardware-model Tetris, latency/throughput trade-offs, стоимость и утилизацию GPU. И именно там быстро становится видно, есть ли у тебя inference platform, или пока просто набор YAML’ов. https://www.redhat.com/en/blog/overcoming-inference-challenges

Мы написали курс по MLOps! Хочу поделиться проектом, в который я вложил реально много сил за последний год - курсом «MLOps для разработки и мониторинга моделей» в Яндекс Практикуме.🚀🚀🚀 Для меня это была не просто работа "поучаствовать в курсе" - Я составлял ядро программы в соответствии с текущим рынком (и моим опытом), формировал ТЗ для авторов, проектировал инфраструктуру курса. Это были сотни часов работы, пересборка программы, рефакторинг модулей, дедлайны, согласования — в общем, вполне настоящая продуктовая разработка, а не просто набор лекций. И лично мне этот опыт тоже много дал - нетворкинг и знакомство с сильными авторами (спасибо ребятам за их вклад и особенно Кате Цаплиной за dev и ml практики на курсе и что позвала меня поучавствовать в проекте!), опыт создания большого образовательного продукта, возможность упаковать свой практический взгляд на MLOps в нормальную учебную траекторию, и, если честно, просто приятное чувство, что год назад я обещал написать курс — и в итоге реально это сделал😅 Что важно про сам курс: мне хотелось сделать его не просто "ещё одной программой про MLOps от датасайнтистов", а курсом с хорошим упором на инфраструктурную часть. На рынке много курсов, где MLOps подаётся скорее со стороны Data Science и использования готовых инструментов. А мне хотелось показать, как это выглядит со стороны инженера, который строит и эксплуатирует платформу. Что в итоге получит студент: - понимание полного MLOps-цикла (вспоминаем раз и два) - Навыки для Dev, ML и OPS трека MLOPS специалиста (согласно схеме) - практику с ClearML, Kubernetes, MLflow, Airflow - Inference в K8S и в Kserve - Observability моделей и инфраструктуры - Data quality и контроль качества пайплайнов То есть идея курса в том, чтобы после него разработчик / DevOps / Data Scientist мог гораздо увереннее зайти в сторону junior MLOps и понимать не только модели, но и весь production-контур вокруг них. Единственное предупрежу сразу - в курсе нет работы с GPU. Не поместилось + считаю что это следующий уровень (либо больше к llmops актуально). Для меня тут ещё есть личный момент: когда-то я сам проходил курс Практикума по DevOps, и он в своё время сильно повлиял на мой трек, помог найти работу где я стал уже MLOps инженером. Поэтому особенно круто, что теперь я сам оказался с другой стороны и разрабатывал уже свой курс. Если хотите записаться, напишите мне в личку - поделюсь промокодом на 15%. А тем, кто купит курс по этому промокоду, готов подарить полчаса менторской сессии со мной на getMentor: обсудим карьерный трек в MLOps, что качать в первую очередь и как туда заходить - оставляйте заявки с пометкой что с курса по mlops ❤️

Скедулинг AI ворклоудов в k8s В прошлом посту в статье Kubernetes goes AI-First: Unpacking the new AI conformance program явно упоминается проблема скедулинга AI ворклоудов. Что уже сейчас можно посмотреть на рынке opensource? 1️⃣ Reclaiming underutilized GPUs in Kubernetes using scheduler plugins Нативный скедулер k8s смотрит на CPU, RAM и ничего не знает про утилизацию GPU. Плагины к скедулеру k8s могут помочь в этом - можно задавать правила по которым происходит фильтрация доступных нод по метрикам Prometheus, например от DCGM exporter. Статья - https://www.cncf.io/blog/2026/01/20/reclaiming-underutilized-gpus-in-kubernetes-using-scheduler-plugins Репозиторий - https://github.com/kubernetes-sigs/scheduler-plugins 2️⃣ Running AI Workloads on Rack-Scale Supercomputers: From Hardware to Topology-Aware Scheduling Nvidia рекомендует переходить к подходам, осведомленным о топологии сети (topology-aware scheduling), используя расширения DRA (тонкое API для работы с вендорным железом), продвинутые мета-планировщики (Run:ai/KAI скедулер) и автоматические инструменты обнаружения железа (Topograph). Статья - https://developer.nvidia.com/blog/running-ai-workloads-on-rack-scale-supercomputers-from-hardware-to-topology-aware-scheduling/ Репозиторий - https://github.com/NVIDIA/topograph

Всем привет! #mlinfra_digest Настроил для себя ресерч материалов по инфраструктуре для AI/ML. Самые интересные статьи и посты хочу иногда выкладывать на канале. Тут не будет новостей про новые SOTA модели, как агенты научились вышивать или что очередная голливудская звезда завела репозиторий на гитхабе (привет Милла Йовович)- только инфраструктурная выжимка про готовку ai платформ (в том числе для ваших агентов). 1️⃣ The weight of AI models: Why infrastructure always arrives slowly Очень хороший текст про то, что bottleneck в AI infra часто не в самой модели, а в доставке, хранении и rollout больших весов. Как то я уже делал посты про DragonFly p2p, но для оптимизации пуллинга образов. Посмотрим как он может помочь с весами моделей - веса делятся на слои как докер образ и скачиваются с разных нод. Модельки через торрент)) https://www.cncf.io/blog/2026/03/27/the-weight-of-ai-models-why-infrastructure-always-arrives-slowly/ 2️⃣ Kubernetes goes AI-First: Unpacking the new AI conformance program Один из самых сильных сигналов про то, какие capability скоро станут baseline для AI-ready Kubernetes: DRA, AI-aware autoscaling, observability, scheduling. DRA на западе становится стандартом, в любом KibeConf про это доклад (а еще он уже в бете и динамический MIG подвезли). Скейлинг по утилизации GPU кажется необходимой частью таких платформ. https://opensource.googleblog.com/2026/04/kubernetes-goes-ai-first-unpacking-the-new-ai-conformance-program.html 3️⃣ The platform under the model: How cloud native powers AI engineering in production Хороший обзорный материал, который собирает в одну картину cloud-native substrate под AI workloads. Особенно нравится видеть там Kueue, Kubeflow - ну в целом проекты cncf так что ничего удивительного Удобно, если хочется быстро сверить свою roadmap и понять, из каких примитивов вообще сейчас складывается production AI platform. https://www.cncf.io/blog/2026/03/26/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production/ 4️⃣ How NVIDIA Dynamo 1.0 Powers Multi-Node Inference at Production Scale А здесь будет две статьи про распределенный инференс. Делимся на два лагеря - кто за dynamo AI пишите в комментах насколько вам помогает disaggregated inference, стабильны ли ваши TPOT. https://developer.nvidia.com/blog/nvidia-dynamo-1-production-ready/ 5️⃣ llm-d officially a CNCF Sandbox project А я лично больше присматриваюсь к llm-d - cncf sandbox это хороший знак, но что еще важнее он поддержан в Kserve) https://cloud.google.com/blog/products/containers-kubernetes/llm-d-officially-a-cncf-sandbox-project

MLечный путь 2026 Друзья, всем привет! Рад вам сообщить что уже третий раз подряд буду выступать на ранее митапе, а теперь уже полноценной конференции MLечный путь от Selectel. Мне особенно приятно, что родной митап про MLOps, с которого я начинал когда-то, перешел в статус конференции и растет каждый год нетолько по масштабу, но и по качеству! Когда? - 22 апреля Где? - Москва, Connect Space, 5-й Донской проезд 17 О чем я буду рассказывать? Прошлые года я рассказывал про узкие горлышки в ML системах и как подбирать инфраструктуру для LLM, темы которые до сих пор актуальны! В этом году решил построить трек на платформизацию ИИ-систем, поэтому поделюсь своим опытом разработки ML и Инференс платформ, их эволюции и подводных камнях на каждой стадии. Разберем с вами путь от DevBox с jupyterlab до централизованной платформы с 500 активными пользователями в неделю, а также заглянем в будущее агентных платформ. Из практических примеров покажу, как менеджить десятки команд с помощью квотирования и очередей в kueue, сделать свой jupyterlab с удаленными kernel без простоев gpu, построить распределенное обучение на пайплайнах Kubeflow и многое другое) Приходите и смотрите онлайн! Также планирую несколько постов про текущие исследования инфры и пару анонсов, так что не теряйте!

🌱 Весна в Петербурге начинается с данных 6 марта в большом зале БКЗ (офис Ozon Банка) пройдет традиционный митап Women in Data Science. Что ждет на митапе: 🔹 Технический трек: - Микросервисы автоматизации разметки в агропроме - Управление роботами через VLM - Персонализация кешбэка в финтехе - Когда асессоры и LLM не справляются с разметкой - Вредные советы по автоматизации нетехнических команд 🔹 Карьерный трек — круглый стол «Карьера в DS: от джуна до C-level в эпоху ИИ» 🔹 Нетворкинг — после официальной части: напитки, конкурсы и живая музыка от рок-группы коллег по ИТ-цеху Кто выступает: Анна Илюшина (Русагро), Полина Федотова (Центр робототехники Сбера), Полина Шпинева (Ozon банк), Светлана Астафьева (Точка Банк), Александра Мурзина (Яндекс) Для кого: Профессионалы, студенты и все, кто интересуется миром данных 📍 6 марта, Приморский просп., 70 👥 400 мест — обычно разлетаются быстро Регистрация: ods.ai/events/wids-meetup-2026

Мои друзья из ODS подготовили самый красивый старт этой весны - WIDS 2026! Рекомендую посетить, если вы в СПБ 6 марта! Сам тоже подойду понетворкать)