MLOps складывается из трёх треков: ML, разработка и эксплуатация. Матанализ и архитектуру трансформеров знать не нужно. Но надо понимать, как работает дата-сайентист: он твой заказчик, и ему нужны правильные инструменты. Платформу для него собирают из готовых кубиков, как LEGO.
Кружки - это то, с чем я сталкиваюсь каждый день, а не обязательный список: у каждого набор будет свой. Пройдись по всем, даже если пришёл из соседней области, и честно оцени себя. У каждого кружка есть подсказка, какой уровень достаточен для MLOps: глубже нырять стоит, только когда появится задача. В конце выгрузи план: в него попадут пробелы, задания и источники.
С чего начать
С нуля: сети (вспоминаются за вечер) → Fit/Predict на Titanic → трекинг экспериментов → инференс на GPU и LLM.
Из DevOps или админства: сначала закрой DevOps-часть, это уже профессия. Параллельно Fit/Predict: ML не стоит откладывать, лучше сразу понять, интересно ли тебе. Distributed training оставь на потом.
Из дата-инженерии: данные уже понятны, начни с Kubernetes и проекта «Полный цикл на MLflow».
Из бэкенда: железо можно пропустить, начни с упаковки модели: проект «Первая модель без 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 сидит рядом с дата-сайентистом и строит конвейер от данных до прода.
На собеседовании концепции важнее конкретных инструментов: если в компании другой инструмент, тебя переучат.
не оценено 42
не оцененоне знаюесть пробелызнаюесть мои статьи или посты
Сквозные проекты
двигай карту пальцем, нажми на кружок
Карта навыков
ML
Fit/Predict
Хотя бы пару раз побыть дата-сайентистом. Матан учить не обязательно: берёшь готовый код, fit обучает, predict прогнозирует. Так начинаешь понимать своих заказчиков.
Достаточно для MLOps: прошёл базовый DS-процесс: данные, обучение, подбор гиперпараметров, модель как артефакт.
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: от версии модели до деплоя туториал ↗
Где живёт дата-сайентист: 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
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
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
Optimization
Как DevOps ужимает Dockerfile разработчика, так MLOps из неоптимальной модели делает артефакт, который быстро работает и мало весит. Цепочка форматов: PyTorch или TensorFlow → ONNX → TensorRT.
Достаточно для MLOps: понимаешь форматы и точности (bf16, fp8, int4). Квантизацию проверяешь на своём наборе эталонных ответов, а не по бенчмаркам: int4 занимает около 30% памяти.
Попробовать руками
экспортировать модель в ONNX и запустить в ONNX Runtime туториал ↗
Inference-сервер берёт модель как артефакт и отдаёт endpoint. Свой сервис на Flask упрётся в версии фреймворков, форматы и обновление без даунтайма. Инференс бывает онлайн (HTTP, gRPC) и офлайн (джоба по расписанию).
Достаточно для MLOps: поднимал Triton или KServe и понимаешь разницу между форматом модели и сервером. Для пары простых моделей хватит ONNX Runtime в Docker, Triton там избыточен.
Выбирать железо по метрикам, а не по чуйке: 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
Monitoring
Чтобы не следить за сервисами 24/7: пришёл алерт, пошёл починил. Экспортеры у сервисов, Prometheus забирает метрики, Grafana рисует, алерты уходят в Telegram. Важны концепции, а не конкретный инструмент.
Достаточно для MLOps: сам собрал Prometheus, Grafana и алерт.
книгаDesigning Data-Intensive Applications, Martin Kleppmann
OPS
IaC
Сервер-снежинка: зашёл по SSH, сделал руками, документации нет, у следующего квест. Сервер-феникс восстанавливается из кода. 40 ВМ в облаке накликивать долго, Terraform сделает за минуту.
Достаточно для MLOps: Terraform поднимает ВМ, Ansible её настраивает. В облаке и небольших компаниях это база, в бигтехе инфраструктура обычно уже развёрнута.
Попробовать руками
Terraform поднимает ВМ, Ansible её конфигурирует туториал ↗
MLOps строит инфраструктуру из тех же компонентов: S3, базы, балансировщики. Для инфраструктурщика ML-сервис на схеме просто квадрат. GPU - ещё один ресурс, где лежат веса.
Достаточно для MLOps: проходишь мок-собес: требования, расчёт нагрузки, API, базы, компоненты. Понимаешь, что отказоустойчивость дают реплики в разных зонах за балансировщиком, а не веса на нескольких GPU.
Попробовать руками
мок-собес: спроектировать сервис по шагам туториал ↗
Без тестов на реальных GPU нет ответа, какая конфигурация оптимальна. Воспроизводишь сценарий клиента (50 чатов, запрос раз в 30 секунд) и сравниваешь TTFT и задержку. Один запрос из Python-скрипта - не нагрузка.
Достаточно для MLOps: умеешь подать параллельную нагрузку и снять TTFT, latency, throughput. Понимаешь разницу между request rate и concurrency.
Глубже, если понадобится: если T4 и A100 дают одинаковый результат, скорее всего в конфиге батч равен единице.
DEV
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 инференс-платформу туториал ↗