MLOps складывается из трёх треков: ML, разработка и эксплуатация. Матанализ и архитектуру трансформеров знать не нужно. Но надо понимать, как работает дата-сайентист: он твой заказчик, и ему нужны правильные инструменты. Платформу для него собирают из готовых кубиков, как LEGO.
Кружки - это то, с чем я сталкиваюсь каждый день, а не обязательный список: у каждого набор будет свой. Пройдись по всем, даже если пришёл из соседней области, и честно оцени себя. Своя вертикаль (бэкенд, DevOps или данные) обычно уже в «знаю», а остальное закрываешь до уровня достаточно: подсказка есть у каждого кружка, глубже нырять стоит, только когда появится задача. В конце выгрузи план: в него попадут пробелы, задания и источники.
С чего начать
С нуля: сети (вспоминаются за вечер) → Fit/Predict на Titanic → трекинг экспериментов → инференс на GPU и LLM.
Из DevOps или админства: типичный вход - DS-команда не может вывести модель в прод, и задача прилетает тебе. Сначала закрой DevOps-часть, это уже профессия. Параллельно Fit/Predict: ML не стоит откладывать, лучше сразу понять, интересно ли тебе. Дальше DVC, MLflow и разница между онлайн- и батч-инференсом. Distributed training оставь на потом.
Из дата-инженерии: данные уже понятны, начни с Kubernetes и проекта «Полный цикл на MLflow».
Из бэкенда: железо можно пропустить, начни с упаковки модели: проект «Первая модель без GPU». Модель для тебя - капризный компонент со своими требованиями к задержке, памяти, обновлениям и A/B. Доучи ONNX и кэширование признаков.
Из Data Science: математика и фреймворки уже есть, а модели ломаются по дороге в прод. Доучи ООП, тесты, логирование, Docker, базовый CI/CD и API на FastAPI: кружки docker, API, Testing, CI/CD и проект «Первая модель без GPU». Цель - упаковать исследование в воспроизводимый артефакт.
Где практиковаться, если на работе нет задач
На ноутбуке без GPU: Docker, minikube, MLflow, ONNX Runtime, Triton на CPU. Kubernetes можно потрогать в браузере на Killercoda.
Дешёвые ВМ и облако: пара ВМ на недорогом хостинге или managed Kubernetes на бонусе, который облака дают новым аккаунтам.
GPU: арендовать ВМ с картой на час-другой. Для LLM без реальной GPU ответа, какой конфиг лучше, не получить.
Что спрашивают на собеседовании
В бигтехе отдельного MLOps-трека обычно нет. Инфраструктурщики идут по SRE-треку: Linux, Kubernetes, System Design. Про GPU спросят разве что на финале, и там важнее, как ты подходишь к задачам. ML-специфику спрашивают в средних и небольших компаниях. System Design часто встречается на сеньорных позициях: тут помогают мок-собесы.
Специализации: дата-платформа упрощает работу с данными, ML-платформа ускоряет проверку гипотез, inference-платформа отвечает за ресурсы и надёжность в проде. Это вертикали. Есть и горизонталь: как DevOps сидит рядом с разработчиком, так MLOps сидит рядом с дата-сайентистом и строит конвейер от данных до прода.
На собеседовании концепции важнее конкретных инструментов: если в компании другой инструмент, тебя переучат.
Частая задача: «внедри трекер экспериментов». Проверяют не знание MLflow, а ход мысли: сначала выясни, какую проблему решаем, собери критерии и только потом выбирай инструмент. «Все пользуются» и «у соседней команды так» - не аргументы.
Чем MLOps не занимается
MLOps сам по себе не поднимает точность модели и не отменяет A/B-тесты. Он делает проверку гипотез быстрее и дешевле.
Глубокий тюнинг базы (индексы, планы запросов) - работа DBA или бэкенда: ты находишь проблему по мониторингу и отдаёшь её дальше. Почему модель не дала бизнес-эффекта, разбирают продакт, аналитик или DS. От тебя - логи предсказаний и метрики, по которым это видно.
не оцененоне знаюесть пробелызнаюесть мои статьи или посты
Уровеньлычки в углу кружка - уровень навыка: одна Junior, две Middle, три Senior. С Shift можно выбрать два уровня
Порядок изученияпока пустодвойной клик по кружку ставит его в конец очереди его уровня, повторный убирает. На «Все» очереди склеиваются в один трек: Junior → Middle → Senior
Сквозные проекты
двигай карту пальцем, нажми на кружок
Карта навыков
ML · Junior
Fit/Predict
Хотя бы пару раз побыть дата-сайентистом. Матан учить не обязательно: берёшь готовый код, fit обучает, predict прогнозирует. Так начинаешь понимать своих заказчиков.
Достаточно для MLOps: прошёл базовый DS-процесс: данные, обучение, подбор гиперпараметров, модель как артефакт.
Модель работает, а потом по метрикам видно, что она теряет качество. Это дрифт. Если модель переобучают раз в неделю, она часто не успевает просесть. А перед выкатом новую версию сравнивают с текущей, иначе «стала лучше» ничего не значит.
Достаточно для MLOps: знаешь основные метрики качества и что такое дрифт. Сравниваешь модели в одинаковых условиях: те же тестовые выборки, несколько срезов, нетипичные сценарии вроде всплеска спроса или странного входа.
Попробовать руками
посчитать precision, recall и ROC-AUC для модели из Fit/Predict туториал ↗
добавить в CI ворота: новая модель едет дальше, только если не хуже текущей на тех же тестовых наборах туториал ↗
LLM - отдельный трек, не похожий на классический fit/predict. Главные вопросы: влезет ли модель в карту, какую квантизацию выбрать, как проверить качество.
Достаточно для MLOps: считаешь VRAM: параметры × байты (70B в bf16 ≈ 140 ГБ) плюс KV-кэш и активации. Знаешь квантизацию, fine-tuning, OpenAI-протокол и стриминг через SSE.
Попробовать руками
подобрать GPU под Qwen3 32B и сравнить с DeepSeek туториал ↗
посчитать RPS из суточного трафика: 200 000 запросов в сутки это ≈ 2,5 RPS туториал ↗
Дата-сайентист постоянно запускает код с чуть другими параметрами. Раньше это были ноутбуки v1, v2 в папочке. Трекер пишет вместе с метриками код, параметры, версию данных и окружение, чтобы любой запуск можно было повторить. Лучшая модель уезжает в реестр со ссылкой на свой запуск, и инференс берёт её оттуда. А MLOps разворачивает всё это на сотню человек с гарантированными ресурсами.
Достаточно для MLOps: поднимал MLflow или ClearML, сам залогировал пару экспериментов и зарегистрировал модель в реестре с версией данных, параметрами и метриками.
Попробовать руками
поднять MLflow и залогировать обучение из Fit/Predict туториал ↗
Model Registry: от версии модели до деплоя туториал ↗
В ML версионируют не только код, но и данные с моделями, и связывают их между собой. Иначе не ответишь, почему на новой версии датасета точность упала с 90% до 85%. DVC хранит большие файлы во внешнем хранилище, а в Git кладёт только ссылки на них.
Достаточно для MLOps: версионировал датасет через DVC и можешь сказать, на какой версии данных обучена модель в проде. Глубоко не нырять, пока нет задачи.
Глубже, если понадобится: lineage: откуда пришли данные и через какие шаги прошли, плюс каталог данных. Так от модели в проде можно дойти до исходной таблицы.
ML + DEV · Middle
ML pipelines
CI/CD для моделей. Оркестратор собирает шаги в DAG (очистка, обучение, тест) и запускает его по расписанию или по событию. Параллельно идут эксперименты с разными гиперпараметрами, лучшая модель уезжает в прод. В Kubernetes логичен Kubeflow Pipelines: каждый шаг там отдельный контейнер.
Достаточно для MLOps: собирал пайплайн: несколько обучений, выбор лучшей модели, деплой.
Попробовать руками
пайплайн в ClearML Pipelines или Kubeflow Pipelines туториал ↗
Глубже, если понадобится: continuous training: переобучение запускает мониторинг, который увидел дрифт, а не человек.
ML + DEV · Middle
Data eng
ETL, DAG в оркестраторах и Feature Store. Пример: в скоринг приходит только ID клиента, а Feature Store достаёт по нему историю и доход. Заодно он следит, чтобы признак считался одинаково на обучении и на инференсе. Многие поломки «нестабильной модели» на деле растут из данных.
Достаточно для MLOps: понимаешь ETL, DAG и зачем Feature Store (онлайн в Redis, холодное в S3). Тема сложная, глубоко не сразу.
Попробовать руками
разобраться, чем data lake отличается от warehouse туториал ↗
поднять Kafka в Docker и прогнать поток событий туториал ↗
Глубже, если понадобится: как устроена дата-платформа: источники (базы, логи, Kafka) → lake на S3 в Parquet → DWH вроде ClickHouse или Greenplum → Spark для трансформаций, а сверху каталог, lineage и доступы.
ML + DEV · Middle
Data validation
Модель учится на том, что ей дали. Сломался источник: колонка опустела, цены пришли в копейках вместо рублей, и модель честно обучилась на мусоре. Поэтому до обучения данные проверяют: схема, диапазоны, пропуски, аномалии. Не прошли - пайплайн останавливается и шлёт алерт.
Достаточно для MLOps: добавлял в пайплайн шаг проверки данных, который валит запуск и шлёт алерт, если схема или распределение поехали.
Попробовать руками
описать схему датафрейма в Pandera и уронить пайплайн на битых данных туториал ↗
сравнить два датасета пресетом Data Drift в Evidently туториал ↗
Где живёт дата-сайентист: Jupyter, JupyterHub, DevBox. В Jupyter каждая ячейка хранит состояние, поэтому код DS выглядит не как у разработчика: это инструмент для экспериментов.
Достаточно для MLOps: понимаешь, как устроен Jupyter, и разворачивал JupyterHub с профилями под разные окружения.
ML по сути сложение матриц, а у GPU таких ядер в тысячи раз больше, чем у CPU. Главное ограничение - видеопамять. От архитектуры карты зависит, что доступно: MIG и bf16 с Ampere, FP8 с Hopper, FP4 с Blackwell.
Достаточно для MLOps: знаешь поколения, VRAM и терафлопсы, дата-центровые и игровые карты. Драйвер ставишь последний, но смотришь нижнюю границу по архитектуре и совместимость с ядром ОС. CUDA живёт в образе.
Глубже, если понадобится: версия CUDA в nvidia-smi - совместимая, а не установленная. Если разворачиваешь у заказчика, повтори его окружение вплоть до драйвера.
ML + OPS · Middle
GPU in K8s
GPU Operator ставит драйверы и device plugin, поды просят ресурс nvidia.com/gpu. Подготовка GPU-ноды может занимать до 5 минут, и это бьёт по автоскейлингу.
Достаточно для MLOps: ставил GPU Operator и запускал под с GPU.
В нативном Kubernetes контейнер получает целую карту: сервис на 500 МБ съедает H100. Частый запрос компаний: несколько дата-сайентистов на одной GPU в JupyterHub.
Достаточно для MLOps: знаешь MIG (до 7 изолированных частей), MPS, time-slicing и HAMi и выбираешь под архитектуру карты и нагрузку.
Попробовать руками
нарезать A100 на MIG и запустить два пода туториал ↗
Глубже, если понадобится: fair share между командами, gang scheduling для распределённого обучения.
ML + OPS · Senior
Distributed training
Как склеиваются GPU: PCIe (через CPU и RAM), NVLink (мостик между картами), NVSwitch (коммутатор на 8 карт), InfiniBand между узлами. Кластер иногда собирают люди, которые не знают, что это.
Достаточно для MLOps: понимаешь, что это есть и когда нужно. NVLink важен для обучения и моделей, которые не влезают в одну карту. Для инференса небольших моделей хватит PCIe.
Попробовать руками
NVLink, NVSwitch, PCIe, InfiniBand: что чем соединено туториал ↗
Ollama для дома. vLLM сейчас выигрывает по соотношению усилий и результата: TensorRT-LLM быстрее на бумаге, но его сборка работа не на 5 минут. Для отказоустойчивости и маршрутизации смотри vLLM Production Stack.
Достаточно для MLOps: запускал vLLM в Docker и крутил конфиг: max-num-seqs, контекст, tensor parallel. Понимаешь выбор между минимальной задержкой и максимальной пропускной способностью.
Попробовать руками
запустить одну модель в Ollama, vLLM, SGLang и Triton туториал ↗
Глубже, если понадобится: KV-кэш между репликами (LMCache), CUDA graphs, выгрузка весов на CPU, автотюнинг конфига.
ML + OPS · Senior
Distributed LLM inference
Когда модель не влезает в одну GPU или реплик становится много, одного vLLM мало. Нужен слой над движком: разнести prefill и decode по разным GPU, передавать KV-кеш между репликами и собирать мультинодовый инференс в Kubernetes. Главные варианты сейчас - llm-d (CNCF Sandbox, на его архитектуре сделан LLMInferenceService в KServe) и NVIDIA Dynamo.
Достаточно для MLOps: понимаешь, зачем разделять prefill и decode и чем мультинодовый инференс отличается от нескольких реплик. Поднимал llm-d или LLMInferenceService в KServe хотя бы на стенде.
Глубже, если понадобится: wide expert parallelism для MoE, LeaderWorkerSet, передача KV-кеша между нодами, асинхронный инференс через llm-d async.
OPS + DEV · Senior
LLM gateway
Перед репликами LLM обычный балансировщик не справляется: он не знает, где лежит KV-кеш и у какой реплики очередь. Gateway API Inference Extension добавляет InferencePool и EPP (Endpoint Picker), который выбирает реплику по префиксам в кеше и загрузке. В моих тестах EPP дал +23% токенов в секунду, а на multi-turn чатах TTFT p95 561 мс против 3 с у sticky-сессий. Отдельный класс - шлюзы к внешним API моделей: ключи, лимиты и учёт токенов в одном месте.
Достаточно для MLOps: понимаешь, чем inference-aware роутинг отличается от round-robin и sticky-сессий, и знаешь, где в схеме Gateway, InferencePool и EPP. Начинать стоит с approximate prefix-cache routing: precise сложнее настроить, а выигрыша в моих тестах не дал.
Попробовать руками
сравнить round-robin, sticky и EPP на нескольких репликах vLLM туториал ↗
поднять шлюз к нескольким провайдерам моделей с лимитами и учётом токенов туториал ↗
Как DevOps ужимает Dockerfile разработчика, так MLOps из неоптимальной модели делает артефакт, который быстро работает и мало весит. Цепочка форматов: PyTorch или TensorFlow → ONNX → TensorRT.
Достаточно для MLOps: понимаешь форматы и точности (bf16, fp8, int4). Квантизацию проверяешь на своём наборе эталонных ответов, а не по бенчмаркам: int4 занимает около 30% памяти.
Попробовать руками
экспортировать модель в ONNX и запустить в ONNX Runtime туториал ↗
Inference-сервер берёт модель как артефакт и отдаёт endpoint. На старте хватает модели в контейнере с FastAPI, но когда моделей много и они часто обновляются, свой сервис упрётся в версии фреймворков, форматы и обновление без даунтайма. Инференс бывает онлайн (HTTP, gRPC) и офлайн (джоба по расписанию).
Достаточно для MLOps: поднимал Triton или KServe и понимаешь разницу между форматом модели и сервером. Знаешь два подхода: сервис на каждую модель или общий сервер, который подгружает модель по имени. Для пары простых моделей хватит ONNX Runtime или BentoML в Docker, Triton там избыточен.
Глубже, если понадобится: заранее подготовленные ноды, кэш весов по NFS, Tensorizer, скейлинг в ноль.
ML + OPS + DEV · Middle
Rollout & A/B
Новую модель не выкатывают сразу на всех. Canary: сначала малая доля трафика, смотришь на ошибки и бизнес-метрики, потом добавляешь. Blue-green держит старую версию рядом, чтобы откатиться за секунды. A/B показывает, лучше ли новая модель на живых пользователях, а не на тестовой выборке.
Достаточно для MLOps: понимаешь canary, blue-green и A/B, выкатывал модель на долю трафика и откатывал её, когда метрики просели.
Попробовать руками
canary в KServe: 10% трафика на новую версию модели, потом продвинуть или откатить туториал ↗
Argo Rollouts: canary с анализом метрик из Prometheus и автооткатом туториал ↗
Глубже, если понадобится: автооткат по SLO и бизнес-метрикам через Argo Rollouts или Flagger. Для A/B нужен не только выкат, но и честный замер: сколько трафика и времени нужно, чтобы разница была не шумом.
ML + OPS + DEV · Senior
ML platform
Платформа появляется, когда каждая команда строит свой маленький MLOps и решения расходятся. Платформенная команда выносит общую рутину в горизонтальный слой, а модели и бизнес-логика остаются у продуктовых команд. Собирают её из кубиков, как LEGO: IDE, трекинг экспериментов, S3, пайплайны, инференс. В Kubernetes почти всё это ставится Helm-чартами.
Достаточно для MLOps: можешь нарисовать платформу из кубиков по трём слоям (data, ML, inference), выбрать по инструменту на слой для небольшой компании и поднять пару из них.
Глубже, если понадобится: платформа как внутренний продукт. Риски: vendor lock у managed-облаков, долгие интеграции, спор скорости продукта со стандартами платформы и переинжиниринг «как у бигтеха» без бигтеховского масштаба.
ML + OPS + DEV · Middle
ML monitoring
Метрики те же, что в Ops-части: инференс - обычный сервис. Но сервис может отвечать 200 OK, а модель при этом завышать цены. Поэтому сверху смотришь сигналы самой модели: дрифт входа, расхождение прогноза и факта, и бизнес-метрики.
Достаточно для MLOps: метрики инференса в Prometheus (RPS, задержка, очередь, GPU), бизнес-метрики и алерт на дрифт.
Попробовать руками
повесить Evidently на модель и сдвинуть данные туториал ↗
разобрать observability в vLLM Production Stack туториал ↗
Глубже, если понадобится: логи предсказаний, чтобы продакт и аналитик сами разбирали эффект модели. Автоматическая реакция на дрифт: переобучение или откат. Arize и WhyLabs - managed-аналоги Evidently: стартуют быстрее, но переезжать с них потом дорого.
ML + OPS + DEV · Senior
Cost
Выбирать железо по метрикам, а не по чуйке: GPU или CPU, игровая или дата-центровая карта, с NVLink или без. Клиенту говоришь: за эту цену такие метрики, за другую такие.
Достаточно для MLOps: сравниваешь конфигурации по цене и метрикам (TTFT, throughput) и знаешь, что маленькие модели и рекомендашки часто выгоднее на CPU.
Отсюда проще всего начать трек: базу можно вспомнить за вечер. На практике: дата-сайентист хочет открыть сервис в браузере, а ты настраиваешь ingress и HTTPS с автоперевыпуском сертификата.
Достаточно для MLOps: OSI, IP, DNS, TLS, как связаны виртуалки, ingress в Kubernetes.
Попробовать руками
рассказать, что происходит, когда вводишь google.com туториал ↗
Почитать и посмотреть
книгаОлифер: «Компьютерные сети» (целиком читать не нужно)
Почти все ML-платформы строятся на Kubernetes: оркестрация, изоляция, обновление без даунтайма. Все MLOps-инструменты ставятся Helm-чартами, а Helm-чарт - почти Docker Compose для Kubernetes.
Достаточно для MLOps: ставишь Helm-чарт и знаешь сущности от пода до ingress. Если нет автоскейлинга, обновлений без даунтайма и изоляции окружений, небольшому проекту хватит ВМ с Docker Compose.
Попробовать руками
minikube на ноутбуке: те же сущности без облака туториал ↗
Глубже, если понадобится: писать Helm-чарты, Kustomize, политики безопасности.
OPS · Junior
Monitoring
Чтобы не следить за сервисами 24/7: пришёл алерт, пошёл починил. Экспортеры у сервисов, Prometheus забирает метрики, Grafana рисует, алерты уходят в Telegram. Важны концепции, а не конкретный инструмент.
Достаточно для MLOps: сам собрал Prometheus, Grafana и алерт.
Глубже, если понадобится: VictoriaMetrics быстрее Prometheus. Рядом с метриками живут логи (Loki или тяжёлый ELK для полнотекстового поиска) и трейсы на OpenTelemetry. Высший пилотаж - единая система, где метрики, логи и трейсы связаны.
OPS · Middle
Security
Обычная Ops-задача, не MLOps-специфика: креды не храним в репозитории, код проверяем, инференс закрываем авторизацией. Типичная дыра LLM-сервисов: запросы не логируются, доступ никак не ограничен и непонятно, откуда сервис берёт данные.
Достаточно для MLOps: токены в Vault или маскированных переменных CI, линтеры и SAST в пайплайне, авторизация перед инференсом.
книгаDesigning Data-Intensive Applications, Martin Kleppmann
OPS · Junior
IaC
Сервер-снежинка: зашёл по SSH, сделал руками, документации нет, у следующего квест. Сервер-феникс восстанавливается из кода. 40 ВМ в облаке накликивать долго, Terraform сделает за минуту.
Достаточно для MLOps: Terraform поднимает ВМ, Ansible её настраивает. В облаке и небольших компаниях это база, в бигтехе инфраструктура обычно уже развёрнута.
Попробовать руками
Terraform поднимает ВМ, Ansible её конфигурирует туториал ↗
MLOps строит инфраструктуру из тех же компонентов: S3, базы, балансировщики. Для инфраструктурщика ML-сервис на схеме просто квадрат. GPU - ещё один ресурс, где лежат веса.
Достаточно для MLOps: проходишь мок-собес: требования, расчёт нагрузки, API, базы, компоненты. Понимаешь, что отказоустойчивость дают реплики в разных зонах за балансировщиком, а не веса на нескольких GPU.
Попробовать руками
мок-собес: спроектировать сервис по шагам туториал ↗
Глубже, если понадобится: большие ML-образы: только CUDA весит ~6 ГБ. Lazy loading, zstd, P2P-раздача. Сканирование образов на уязвимости, например Trivy.
OPS + DEV · Junior
CI/CD
То же, что в DevOps: из репозитория через пайплайн в прод. Но в ML пайплайн запускается не только на новый код, но и на новые данные, и возит артефакты: датасеты и модели. CI/CD доставляет код и образ, а запросы обслуживает serving: это разные процессы.
Достаточно для MLOps: написал пару пайплайнов в GitLab CI или GitHub Actions.
Глубже, если понадобится: CI/CD связан с реестром моделей и проверяет модель перед выкатом, а у команд есть общие шаблоны пайплайнов под типовые проекты.
OPS + DEV · Junior
Git
Ветки, ревью, GitOps. Это фундамент: на Git стоит всё остальное, от CI до версий данных.
Достаточно для MLOps: ветки, rebase, ревью, поиск регрессий.
Попробовать руками
найти коммит, который сломал тест, через git bisect туториал ↗
Без тестов на реальных GPU нет ответа, какая конфигурация оптимальна. Воспроизводишь сценарий клиента (50 чатов, запрос раз в 30 секунд) и сравниваешь TTFT и задержку. Один запрос из Python-скрипта - не нагрузка.
Достаточно для MLOps: умеешь подать параллельную нагрузку и снять TTFT, latency, throughput. Понимаешь разницу между request rate и concurrency.
Глубже, если понадобится: если T4 и A100 дают одинаковый результат, скорее всего в конфиге батч равен единице.
DEV · Junior
Python/Go
Инструменты меняются так быстро, что документация отстаёт. Бывает, запускаешь фичу из доки, а в issues мейнтейнер пишет, что её больше не поддерживают. Узнаёшь, только если полез в код.
Достаточно для MLOps: уверенно читаешь код Python (язык ML) или Go (язык сервисов).
Попробовать руками
написать скрипт, который параллельно дёргает API модели туториал ↗
У дата-сайентистов всё разваливается при смене версии PyTorch или CUDA. А в CI зависимости ставятся на каждый прогон, и если пакеты тянутся полчаса, это долго: тут выручает uv.
Достаточно для MLOps: понимаешь conda, venv, poetry, uv и собираешь воспроизводимое окружение.
Инференс - это веб-сервис, внутри которого модель как чёрный ящик. С него собирают такие же метрики: RPS, задержку.
Достаточно для MLOps: HTTP и REST, OpenAI-протокол и V2 (KServe, Triton). gRPC пока можно отложить. Если не поднимал сервис на FastAPI, сделай мини-прототип.
Всё, чем пользуется MLOps, лежит на GitHub. В бигтехе MLOps берут open source и патчат под свою платформу. Оценивать проект помогают звёзды, статус в CNCF и то, кто его делает.
Достаточно для MLOps: читаешь код open source, ищешь по issues, открывал PR.
Попробовать руками
разобрать open source инференс-платформу туториал ↗