ML-инженер доводит модели машинного обучения до рабочих продуктовых решений: от данных, baseline и обучения до API, batch pipeline, мониторинга, версий, отката и проверки качества после релиза. Его задача — сделать так, чтобы модель не просто хорошо выглядела в ноутбуке, а стабильно работала в реальном сценарии.
По данным SkillStat на 24.06.26, в Москве и МО открыто 199 вакансий ML-инженера. спрос — 68/100, статус — средний. Зарплата и карта навыков показаны кратко, подробные срезы вынесены на отдельные страницы SkillStat.
Автор·Мурадов Юрий·Аналитик SkillStatКак ещё называют ML-инженера
В вакансиях ML-инженера называют по-разному. Часть названий — прямые синонимы, часть относится к соседним ролям: они пересекаются по стеку, но отвечают за другой результат.
Свежие данные рынка: 208 активных вакансий, медиана зарплаты 280 000 ₽, спрос 68/100. Срез по Москве и МО от 12.08.2026.
Для ML-инженера сейчас используется расчётная оценка по 60-дневному окну: SkillStat считает медиану по вакансиям с раскрытой зарплатной вилкой и не привязывает нишевую роль к одной шумной дневной точке. Выборка профессии за окно — n=67.
Спрос средний: текущая точка выше значений за 7 и 30 дней, но месячные средние показывают волнообразный рынок. ML-инженерия усиливается там, где компании переходят от экспериментов к рабочим AI/ML-функциям, которые нужно запускать, наблюдать, обновлять и ограничивать в реальном продукте.
Кто это: инженер, который превращает ML-модель в рабочую функцию продукта.
Как ещё называют: Machine Learning Engineer, ML Engineer, инженер машинного обучения, инженер ML-систем.
Что делает: готовит данные, строит baseline, обучает модель, упаковывает артефакт, запускает API или batch pipeline, следит за drift и качеством.
Рынок: 199 вакансий в Москве и МО, спрос 61/100.
Оплата: медиана 280 000 ₽, выборка n=51. Подробная статистика — <a href="/it/professions/ml-engineer/salary/">Зарплата ML-инженера →</a>
Стек: Python, SQL, LLM, PyTorch, Docker. Полная карта — <a href="/it/professions/ml-engineer/skills/">Навыки ML-инженера →</a>
Вход: junior-вакансий около 8%, нужен production-like ML-проект, а не только notebook.
По зарплате у профессии нет достаточной собственной актуальной выборки. Поэтому на странице показана оценка с явной маркировкой источника, а не точная медиана только по текущим активным вакансиям.
Числовые метрики показывают вакансии Москвы и Московской области. Описание роли, задач и навыков относится к профессии в целом.
Актуальный срез по вакансиям, зарплате, спросу и динамике найма для ML-инженера в Москве и МО.
ML-инженер — это инженер, который доводит модель машинного обучения до использования в продукте или внутреннем процессе. Он работает не только с обучением, но и с данными, признаками, артефактами модели, API, batch inference, версиями, мониторингом качества, обновлениями и откатом.
Главная граница роли проходит между экспериментом и рабочей функцией. Ноутбук может доказать, что подход перспективен. ML-инженер должен сделать так, чтобы этот подход можно было воспроизвести, запустить, проверить на новых данных, встроить в сервис или пайплайн и сопровождать после релиза.
Поэтому сильный ML-инженер думает сразу о нескольких вещах: где взять данные, как избежать leakage, какой baseline честный, как сохранить модель и preprocessing, как быстро отвечает inference, какие ошибки возможны, как заметить drift и что делать, если новая версия стала хуже.
Путь модели от данных до ответа в продукте
Модель работает, обновляется и контролируется после запуска
Берёт модельный подход и превращает его в сопровождаемое решение: готовит данные, сохраняет артефакты, поднимает сервисный слой, проверяет качество и помогает команде обновлять модель.
Дополнительно отвечает за договор между моделью и продуктом: какие данные допустимы, какие ответы возможны, что считается ошибкой и когда решение нужно отключить.
В случаях, где эксперимент уже работает, но продуктовая жизнь сложнее: данные приходят иначе, ответ задерживается, качество меняется, а соседние команды ждут понятный контракт.
Мастерство видно там, где модель перестаёт быть идеальной: пришли странные данные, ответ стал медленным, качество просело, а продукт всё равно должен работать безопасно.
С исследователем моделей и с обычным серверным разработчиком. ML-инженер работает между ними и отвечает за то, чтобы модель стала устойчивой частью продукта.
Если человек только обучает модель, он ближе к исследованию. Если только поднимает сервис, он ближе к бэкенду. ML-инженер связывает эти части в один рабочий путь.
сценарии, критерии и постановка задачи
данные, api, статусы и интеграции
согласование и работа с разработкой
В реальной задаче ML-инженер постоянно проверяет, не потерялся ли смысл модели при переносе в продукт. Техническая обвязка должна сохранять качество, а не только запускать код.
Уточняет, кто вызовет модель, какие данные придут, как быстро нужен ответ и что делать при ошибке. Уточняет не только вход и ответ, но и цену задержки, допустимый отказ и действие команды при сомнительном результате.
Настраивает повторяемую подготовку данных, обучение, сохранение версии и проверку результата. Фиксирует версии, параметры и признаки, чтобы результат можно было повторить и сравнить после изменений.
Оборачивает модель в сервис, задачу по расписанию или другой способ использования в продукте. Выбирает форму запуска под задачу: быстрый ответ, пакетная обработка, асинхронная очередь или ручная проверка перед действием.
Настраивает сигналы деградации, ошибки, задержки и ограничения, которые важны для команды. Разделяет технические сбои и ухудшение модели, потому что лечатся они по-разному.
Помогает выкатывать новую версию, откатываться при проблемах и документировать изменения. Планирует выпуск новой версии так, чтобы команда могла сравнить поведение и вернуться назад при проблеме.
Эти роли часто пересекаются по Python, данным и инфраструктуре, но отвечают за разные результаты. ML-инженер ближе всего к конкретной модели и её работе в продукте.
Довести модель до сервиса, batch pipeline или другой рабочей функции.
Отвечает за model serving, артефакты, качество, мониторинг, обновление и откат конкретной ML-функции.
Поставить ML-задачу, исследовать данные, построить модель и доказать качество вывода.
Чаще отвечает за исследование и валидацию; ML-инженер забирает модель в production-контур.
Платформа и процесс для многих моделей.
Строит registry, CI/CD, мониторинг, оркестрацию и стандарты; ML-инженер ближе к конкретной модели и продуктовой задаче.
Чаще интегрирует готовые модели и LLM-сервисы; ML-инженер глубже отвечает за обучение, inference and model quality.
Данные, пайплайны, хранилища, качество и доступность источников.
Готовит слой данных; ML-инженер использует его для признаков, обучения and inference.
API, сервисы, бизнес-логика, базы and reliability приложения.
Может запускать модель как часть сервиса, но обычно не отвечает за ML-метрики, drift and training lifecycle.
Новые методы, архитектуры, эксперименты and публикационная или исследовательская глубина.
Ближе к исследованию; ML-инженер отвечает за прикладной запуск и сопровождение решения.
Текст, embeddings, classification, extraction, search, LLM and evaluation.
Это специализация ML-инженера или Data Scientist по NLP-стеку.
Изображения, видео, detection, segmentation, OCR and visual quality.
Это специализация ML-инженера по CV-моделям, данным и inference.
Частный AI/ML production слой; ML-инженер может закрывать его, если отвечает за качество, deployment and monitoring.
Обе роли помогают моделям жить после эксперимента, но фокус разный. ML-инженер ближе к конкретной модели и продуктовой задаче, MLOps-инженер — к платформе и повторяемому процессу для многих моделей.
Конкретная модель, данные, сервисный слой и качество в продукте.
Платформа, процессы, автоматизация, наблюдение и стандарты для команды.
Модель становится рабочей функцией продукта.
Команда получает повторяемый путь для запуска и сопровождения моделей.
Модель не выдержит реальные данные или продуктовые ограничения.
Каждый запуск будет ручным, хрупким и плохо наблюдаемым.
Исследователи, продукт, бэкенд, аналитика.
Инфраструктура, данные, эксплуатация, несколько ML-команд.
Работодателю нужен инженер, который понимает ML и умеет довести его до работающего контура. В вакансиях поэтому рядом встречаются Python, SQL, PyTorch, Docker, FastAPI, Kubernetes, Airflow, MLflow, Git, CI/CD, LLM, RAG, PostgreSQL and Kafka. Это не случайный набор слов: он показывает путь модели от данных до эксплуатации.
От junior-кандидата ждут не энциклопедического знания всех инструментов, а одного законченного production-like проекта. В нём должны быть данные, baseline, обучение, артефакт модели, сервис или batch pipeline, Docker, тесты, README и хотя бы простое наблюдение за качеством.
На middle и senior уровнях важнее масштаб ответственности. Специалист должен объяснить, как воспроизвести обучение, где хранится версия модели, как безопасно выкатить обновление, как заметить деградацию и что делать, если offline-метрика хорошая, а продуктовый результат стал хуже.
Рынок ориентирован на опытных специалистов.
Столько требований работодатели обычно собирают в одной позиции по этой роли.
Соответствие рассчитано по стеку из 208 вакансий — это не реклама, а совпадение со спросом работодателей.
ML-инженеру нужен не список модных инструментов, а понимание полного пути модели. Ниже — рабочие группы знаний, которые отделяют production ML от хорошего ноутбука.
Supervised and unsupervised learning, baseline, feature engineering, train/test split, cross-validation, overfitting, leakage and metrics. Это слой, без которого невозможно честно оценить модель.
SQL, pandas, NumPy, data quality, пропуски, дубли, temporal split and feature store на базовом уровне. ML-инженер должен понимать, откуда берутся признаки и где они ломаются.
Scikit-learn, PyTorch, CatBoost, LightGBM, XGBoost, embeddings and LLM/RAG по необходимости. Важен не бренд библиотеки, а выбор подхода под задачу и ограничения.
FastAPI, REST API, batch inference, online inference, validation, error handling, timeout and response schema. Модель должна отвечать предсказуемо и понятно для соседнего продукта.
Model artifact, preprocessing pipeline, feature schema, config, dataset version, model version and model registry. Без версий невозможно понять, какая модель дала какой результат.
Offline metrics, online metrics, drift, деградация, A/B, shadow deployment, canary release and rollback. После релиза качество не становится постоянным.
Docker, CI/CD, Kubernetes basics, logs, monitoring, health checks, secrets and configs. Этот слой делает модель сопровождаемой, а не ручным запуском на машине автора.
MLflow, Airflow, pipelines, experiment tracking, reproducibility, retraining and scheduled jobs. ML-инженер не всегда строит платформу, но обязан понимать процесс.
Retrieval, embeddings, evals, hallucination checks, cost/latency, fallback and human-in-the-loop. LLM-функция без оценки качества быстро превращается в риск.
Границы модели, ограничения, цена ошибки, когда модель нельзя использовать, handoff с Data Scientist, backend, product and MLOps. Production ML всегда межкомандная работа.
Для расчётной оценки грейдовые зарплаты не показываются, чтобы не создавать ложную точность.
На доход влияет не само знание PyTorch, MLflow или Docker, а ответственность за production lifecycle модели. Дороже оплачиваются задачи, где модель влияет на деньги, риск, пользовательский опыт или операционные решения, а ошибка может долго оставаться незаметной.
Сильнее ценятся специалисты, которые умеют соединить качество модели и инженерную надёжность: reproducible training, model registry, FastAPI serving, batch inference, monitoring, drift, rollback, cost/latency and incident response. Чем меньше ручного хаоса нужно для следующего релиза модели, тем выше уровень ML-инженера.
Спрос на ML-инженера лучше читать как сочетание объёма найма, ранга профессии в общей выборке и устойчивости вакансий во времени. Виджеты выше дают быстрый срез рынка, а график ниже помогает понять, насколько этот спрос поддерживается от месяца к месяцу.
На 12.08.2026 SkillStat видит 208 активных вакансий ML-инженера в Москве и МО. 7 дней назад было 188, 30 дней назад — 141. спрос — 68/100, ранг — #11 из 71, статус — средний. ML-инженерия усиливается там, где компании уже не довольствуются экспериментом и хотят рабочую AI/ML-функцию с запуском, наблюдением, обновлением и ограничениями.
Вакансии стоит читать аккуратно. В незрелых командах ML Engineer может выглядеть как Data Scientist с Docker или backend-разработчик с моделью. В зрелой команде роль видна по полному контуру: данные, обучение, registry, API или batch, мониторинг, drift, rollback and ownership after release.
Этот срез показывает, в каком формате работодатели чаще всего открывают вакансии по профессии: удалённо, гибридно или с полной привязкой к офису.
Грейдовые медианы не показаны: для ML-инженера зарплата сейчас показана как расчётная оценка, поэтому SkillStat не выводит отдельные зарплаты по уровням, чтобы не создавать ложную точность.
Начальный уровень помогает с подготовкой данных, простыми моделями, скриптами, проверками и небольшими сервисными задачами. Главная цель — понять, почему модель может работать в исследовании и сбоить после запуска.
Средний уровень самостоятельно ведёт прикладную задачу: данные, обучение, проверка, сервисный слой, релиз и базовое наблюдение за качеством.
Опытный ML-инженер проектирует путь модели в продукте, отвечает за деградацию, обновления, договоры с соседними сервисами и техническую цену сопровождения.
Ведущий трек связан с практикой ML-направления: стандарты качества, повторяемые запуски, развитие команды и выбор границ между исследованием, продуктом и инфраструктурой.
Здесь модель влияет на порядок выдачи, персонализацию и пользовательский выбор, поэтому важны скорость, качество и проверка эффекта. Помимо качества выдачи важны задержка ответа, устойчивость признаков и проверка того, что изменение не ухудшило ключевой путь.
Модель помогает принимать решения с высокой ценой ошибки. Нужны контроль качества, объяснимость и аккуратное обновление. Даже полезная модель должна иметь ограничения, журнал решений и способ ручной проверки в спорных случаях.
Обработка текста, изображений и сценарии с LLM требуют ограничений, проверки ответов, управления стоимостью и безопасного поведения при сбоях. В сценариях с LLM инженер следит за контекстом, безопасностью данных, стоимостью вызовов и предсказуемостью ответа.
Практический путь входа в профессию: что освоить сначала, как собрать рабочую базу и на чём быстрее всего набирается прикладная уверенность.
Scikit-learn для классического ML и PyTorch на прикладном уровне для deep learning, embeddings, NLP, CV or LLM-related задач.
Monitoring, drift signals, latency, error rate, quality checks, rollout, rollback and README.
Сопоставили программы с реальным стеком из 208 вакансий — оценка соответствия рассчитана автоматически, это не реклама.
Соответствие — доля ключевых навыков из вакансий, которые охватывает программа курса
Самая частая ошибка — начать с громких инструментов и пропустить проверку модели. Для ML-инженера это опасно: production только усиливает ошибки, которые были в данных и метрике.
Сначала нужно понять данные, метрику и простую модель. Нейросеть без честного baseline не доказывает качество.
Ноутбук показывает исследование, но не доказывает, что модель можно запустить, обновить, проверить и откатить.
Если модель нигде не работает вне эксперимента, это пока Data Science-проект, а не ML engineering.
Сначала сервис, конфигурация, логи, ошибки и тесты. Kubernetes нужен позже, когда понятен сам runtime модели.
Retrieval, hallucination, cost and fallback нужно проверять. Один удачный demo-запрос не равен качеству продукта.
Feature leakage, неверный split и срезы могут дать сильную offline-метрику и провал после релиза.
Новая версия может быть хуже старой. Нужен план возврата, критерии остановки и понятные release notes.
Data Scientist, ML Engineer and MLOps могут использовать Python, MLflow и Docker, но отвечают за разные результаты.
Портфолио ML-инженера должно доказывать не только качество модели, но и способность запустить её в рабочем контуре. В README важны данные, baseline, запуск, ошибки, мониторинг и откат.
Данные, preprocessing, model artifact, scheduled job, output table, error handling and logs. Такой проект показывает, что вы понимаете не только online API.
Config, dataset version, experiment tracking, MLflow, metrics, model registry and comparison report. Работодатель должен увидеть, как повторить обучение и выбрать версию.
Input distribution, prediction distribution, drift signal, latency, error rate, dashboard and alert. Важно показать, что происходит после релиза.
Old/new model, shadow или canary, quality comparison, rollback plan and release notes. Это доказывает понимание риска обновления модели.
Retrieval, embeddings, evals, hallucination checks, cost/latency, fallback and human review. В README объясните, где модель может ошибиться и как ограничен риск.
На интервью проверяют не только ML-термины. Работодатель хочет понять, умеете ли вы довести модель до эксплуатации и что сделаете, когда качество или сервис начнут ломаться.
Baseline, features, train/test split, cross-validation, overfitting, leakage and metrics. Частые вопросы: что такое feature leakage, как выбрать метрику и как проверить переобучение.
Scikit-learn, PyTorch, model selection, hyperparameters and calibration. Важно объяснить, почему выбранная модель подходит, а не просто назвать библиотеку.
Drift, деградация, latency, error rate, online metrics and alerting. Нужно объяснить, как понять, что качество модели изменилось.
Docker, CI/CD, Kubernetes basics, configs, secrets and rollback. Вопросы часто касаются safe rollout, canary release and shadow deployment.
Retrieval, embeddings, evals, hallucinations, cost and fallback. Спрашивают, как проверить RAG-ответы и когда нужен human review.
Когда модель не нужна, как оценить пользу, как ограничить риск и что делать, если offline-качество хорошее, а продуктовый результат хуже.
Качество просело после релиза, новые данные другого формата, API отвечает слишком долго, модель даёт уверенный неправильный ответ или rollback не подготовлен.
Профессия усиливается там, где модели нужно не показывать, а надёжно использовать в продукте.
ИИ ускорит прототипы и часть кода, но не заменит ответственность за качество, интеграцию, деградацию и сопровождение модели.
ML-инженерия смещается от отдельных экспериментов к устойчивым интеллектуальным функциям внутри продукта. Бизнес ждёт не красивую модель как таковую, а понятный механизм, который можно включить в сценарий, измерять, обновлять и ограничивать там, где ошибка особенно дорога.
Растёт внимание к качеству данных, воспроизводимости, наблюдаемости и контролю за поведением модели после запуска. Появление больших языковых моделей не отменило этих требований, а только усилило их: теперь нужно думать не только о точности, но и о цене ответа, времени отклика, источниках ошибок и надёжности интеграции.
ИИ-инструменты ускоряют часть инженерной работы, но не убирают главное. Сильнее всего будут цениться специалисты, которые умеют соединить алгоритмическое понимание с нормальной продуктовой эксплуатацией и не теряют контроль над системой, когда она выходит в живую среду.
Подходит тем, кому интересно доводить модель до реальной работы, а не останавливаться на красивом эксперименте. Здесь помогают инженерная аккуратность, интерес к данным, терпение к итерациям и спокойное отношение к проблемам, которые появляются только после запуска.
Это инженер, который делает так, чтобы модель машинного обучения не оставалась экспериментом, а работала в продукте: принимала данные, возвращала ответ, обновлялась и контролировалась после релиза.
Он готовит данные и признаки, обучает или дорабатывает модель, сохраняет артефакты, поднимает inference, настраивает проверки качества, мониторинг, обновление и rollback.
AI ускорит код, черновые пайплайны и эксперименты, но не заменит ответственность за данные, качество, deployment, monitoring, drift, rollback, cost and product risk.
Airflow используют для оркестрации задач: подготовка данных, обучение, batch inference, проверки, отчёты и регулярное обновление пайплайнов.
Это обучение, которое можно повторить: известны код, данные, конфиги, признаки, зависимости, параметры и версия модели.
Частотность навыков по вакансиям и требования по грейдам — <a href="/it/professions/ml-engineer/skills/">на странице навыков ML-инженера</a>.
Нужна прикладная база: вероятность, статистика, метрики, ошибки, переобучение, регуляризация и интерпретация результата. Глубина зависит от типа задач.
Да, если работа связана с production AI. Важно понимать retrieval, embeddings, evals, hallucination checks, cost, latency, fallback and access control.
Backend-разработчик отвечает за сервис и бизнес-логику. ML-инженер дополнительно отвечает за качество модели, признаки, версии, drift, inference and model rollout.
Data Scientist чаще доказывает качество модели и вывода, а ML-инженер отвечает за то, чтобы модель стала рабочей, наблюдаемой и сопровождаемой функцией продукта.
ML-инженер ближе к конкретной модели и продуктовой задаче. MLOps-инженер чаще строит платформу, стандарты и автоматизацию для многих моделей и команд.
Batch inference считает предсказания пачкой по расписанию или выгрузке. Online inference отвечает на запрос почти сразу, поэтому важны latency, timeout and reliability.
Canary release отдаёт новую модель небольшой доле трафика. Shadow deployment запускает новую модель параллельно без влияния на пользователя, чтобы сравнить поведение.
Это утечка информации из будущего или целевой переменной в признаки. Такая модель выглядит сильной offline, но ломается в реальном использовании.
MLflow помогает вести experiment tracking, хранить параметры, метрики, артефакты и версии моделей. В работе ML-инженера он полезен для воспроизводимости и model registry.
Это изменение данных или связи между признаками и целевой переменной, из-за которого модель со временем теряет качество.
Это хранилище версий моделей и связанных артефактов, где команда понимает, какая версия обучена, проверена, одобрена и запущена.
Это запуск модели как части рабочего контура: API, batch job, очередь или другой механизм, который принимает вход, возвращает предсказание и обрабатывает ошибки.