Вопросы на собеседовании: MLOps-инженер

Я бы присоединял каждую метку к значениям признаков, доступным в момент исходного прогноза, а не в момент запуска обучения.

• Feast historical retrieval должен сопоставлять ключи сущностей и время событий, а окно метки начинаться через 14 дней после прогноза, чтобы будущие транзакции не попали в строку.
• Я бы хранил время события и время загрузки, принимал данные до watermark в 48 часов и версионировал исправления уже опубликованных разделов.
• Тест воспроизводит 10 000 пар сущность-время в BigQuery и падает, если время любого выбранного признака позже времени прогноза.

Я бы требовал версионированный контракт FeatureView, в котором можно проверить смысл, владельца, свежесть и совместимость.

• Определение должно содержать ключ сущности, тип, единицу измерения, правило для null, значение по умолчанию, владельца, источник и цель свежести, например 15 минут.
• Изменение типа или смысла создаёт новую версию с 30-дневным dual-read окном; совместимые добавления метаданных могут остаться в текущей версии.
• CI сравнивает 10 000 типичных строк из хранилища и Redis, затем блокирует публикацию при несовпадении схемы или выходе значений за заданный допуск.

Я бы хранил историю в аналитическом хранилище, а в распределённый online store материализовал только текущие значения.

• BigQuery или Snowflake хранит 50 ТБ истории и выполняет point-in-time join, не заставляя оперативный слой держать старые версии.
• Kafka и Flink материализуют обновления в Redis Cluster, рассчитанный на 130 000 чтений в секунду с запасом 30% над пиком.
• Feast связывает оба пути одним определением, а проверки свежести каждые пять минут и сверка контрольных сумм по 1 млн ключей выявляют неполную материализацию.

Я бы измерял свежесть при чтении по времени исходного события и явно задал поведение для устаревшего значения.

• Flink записывает время события вместе со значением в Redis, а клиент отдельно измеряет задержку источника, обработки и возраст при выдаче.
• Prometheus считает долю чтений старше 60 секунд в скользящих окнах по 10 минут и вызывает дежурного только после двух нарушений подряд.
• После 120 секунд модель использует версионированное резервное значение или отказывается от прогноза; незаметно выдавать устаревшее значение нельзя.

Я бы изолировал исторический расчёт от онлайн-публикации и после проверки продвигал только последнее допустимое значение.

• Spark пишет месячные offline-разделы в теневые таблицы с зафиксированными снимками источников и возобновляемыми идентификаторами разделов.
• Пересчёт использует отдельную очередь, а запись в Redis ограничена 5 000 операциями в секунду при измеренном свободном бюджете 20 000.
• При переключении выбирается самое новое событие для сущности и применяются проверки времени, поэтому старая строка не перезапишет более новое потоковое значение.

Я бы опубликовал новую версию признака и переносил каждую модель отдельно, не меняя старое значение на месте.

• Feast публикует average_order_value_v2, а v1 остаётся доступной минимум 30 дней с отдельными lineage и владельцем.
• Обе версии материализуются в Redis, а Evidently семь дней сравнивает покрытие, долю null и PSI с порогом проверки 0,10.
• Три модели переходят отдельными релизами Argo CD; v1 удаляется, только когда registry lineage показывает ноль потребителей в обучении и serving.

Я бы сократил сетевые вызовы и заранее сформировал группы для запроса вместо 40 отдельных чтений.

• Feast feature service задаёт точный вектор из 40 признаков, а Redis хранит совместно читаемые значения под двумя или тремя ключами сущности вместо 12 удалённых вызовов.
• Бюджет выделяет 3 мс клиенту и сети, 8 мс Redis и 4 мс хвостового запаса при жёстком клиентском deadline 12 мс.
• Нагрузочный тест на 60 000 RPS измеряет задержку команд Redis, размер ответа, ожидание пула соединений и долю горячих ключей до принятия схемы.

Я бы использовал одобренные моделью резервные значения с явным возрастом и признаком пропуска, а не превращал каждую ошибку чтения в ноль.

• Клиент держит ограниченный локальный кеш для низкокардинальных признаков и принимает значения не старше 10 минут только там, где это разрешает контракт.
• Пропуски online-значений заменяются версионированными defaults из обучающего датасета и выставляют индикаторы, которые модель видела при оценке.
• Deadline 20 мс и circuit breaker останавливают шторм повторов; доля деградированных прогнозов измеряется отдельно и должна быть ниже 0,5% за месяц.

Я бы развернул 116 реплик: измеренный пик покрывают 89, а запас мощности 30% повышает число до 116.

• Сквозной бюджет выделяет 8 мс маршрутизации, 32 мс инференсу и 10 мс очереди и хвостовым колебаниям.
• Реплики распределены по трём зонам с topology constraints, и каждая зона может потерять 10 реплик без превышения безопасной конкурентности.
• Admission control отклоняет работу после достижения возраста очереди 8 мс, потому что неограниченная очередь сохранит throughput, но нарушит p99.

Я бы перебрал размеры батча и задержки очереди на трафике production-формы и выбрал самый быстрый вариант внутри p99 35 мс.

• Triton Model Analyzer тестирует батчи 4, 8, 16 и 32 с задержкой очереди от 0,5 до 4 мс, записывая время ожидания, выполнения и фактическое распределение батчей.
• Входы группируются по форме, потому что padding смешанного батча до крупнейшего изображения может съесть выигрыш throughput и поднять расход памяти.
• Я сохраняю 20% запаса throughput и отклоняю настройку, если очередь превышает 8 мс при 7 200 прогнозах в секунду, даже при хорошей средней задержке.

Я бы настраивал планирование токенов и tensor parallelism по реальным распределениям prompt и output, а не по фиксированному числу запросов в батче.

• Нужно сравнить схемы tensor parallel на 4 и 8 H100 с production p50 и p95 длины prompt, измеряя TTFT, время output token, занятость KV-cache и tokens per second.
• max_num_batched_tokens ограничивается так, чтобы prefill не блокировал decode, а интерактивные и batch-запросы получают разные очереди и лимиты конкурентности.
• На пике KV-cache остаётся ниже 90%, а низкоприоритетная работа сбрасывается при возрасте очереди 1,2 секунды, оставляя 600 мс на prefill и сетевой хвост.

Я бы изолировал конкурентность, очереди и масштабирование по моделям, сохранив общий контракт маршрутизации.

• Популярные модели получают выделенные прогретые instance groups Triton; редкие делят пул, только если их суммарные нагрузка и память укладываются в проверенный лимит.
• Маршрутизатор применяет deadline, лимит конкурентности и ограниченную очередь для каждой модели, затем выбирает неизменяемую версию, а не изменяемый тег latest.
• Дашборды разделяют RPS, p99, возраст очереди, память GPU и долю отказов по моделям, а шумная модель сначала исчерпывает только собственную мощность.

Я бы масштабировал по спросу в очереди и заранее держал прогретую мощность на четырёхминутный запуск.

• Две прогретые GPU покрывают 300 RPS, а новая реплика добавляется на каждые измеренные 150 RPS, если возраст очереди выше 20 мс две минуты.
• Прогноз повышает минимум за 10 минут до ежедневного пика; уменьшение ждёт 15 минут, чтобы не выгружать модель перед быстрым возвратом трафика.
• Парк ограничен 20 GPU, а низкоприоритетный трафик сбрасывается выше 2 700 RPS; p99 и стоимость миллиона запросов сравниваются с постоянной мощностью.

Я бы развернул полный serving-стек в каждом регионе и оставил чтение модели и признаков внутри выбранного региона.

• Обычно каждый регион обслуживает около 13 300 RPS, но рассчитан на 24 000, чтобы оставшиеся два приняли весь трафик после отключения одного.
• Бюджет 60 мс выделяет 15 мс глобальной маршрутизации и сети, 15 мс признакам, 20 мс инференсу и 10 мс сериализации и хвостовому запасу.
• Глобальный балансировщик удаляет нездоровый регион за 10 секунд, а квартальные тесты подтверждают 40 000 RPS без синхронных межрегиональных вызовов.

Я бы использовал детерминированные когорты и повышал трафик только после прохождения сервисных и модельных метрик за фиксированное окно.

• Трафик идёт через 1%, 5%, 20% и 50% по 30 минут, а пользователи закрепляются по account ID, чтобы сравнение не смешивало версии.
• Откат срабатывает, если p99 вырос более чем на 10 мс, ошибки превысили baseline на 0,2 процентного пункта или главная ranking-метрика упала более чем на 1%.
• Argo Rollouts двигает неизменяемые digest модели и образа, а MLflow хранит baseline, candidate, пороги и решение как доказательства релиза.

Я бы асинхронно зеркалировал допустимые запросы и изолировал shadow-мощность от пути production-ответа.

• После production-ответа gateway публикует ссылки на выбранные запросы в Kafka, а отдельный consumer вызывает candidate с отключёнными побочными эффектами.
• Correlation ID связывает baseline и candidate для 3 000 RPS парного анализа, а чувствительные поля удаляются до mirror topic.
• Shadow-воркеры имеют отдельную GPU-квоту и сбрасывают работу при отставании больше пяти минут, потому что полнота replay менее важна, чем production p99.

Я бы размещал неизменяемые веса рядом с GPU-узлами и не включал readiness до реального прогрева runtime.

• DaemonSet или image pre-puller кеширует digest модели на локальном NVMe, заменяя 90-секундную сетевую передачу измеренной загрузкой с локального диска.
• Triton явно загружает модель и выполняет 20 типичных прогревочных запросов до допуска трафика readiness probe.
• В каждой зоне остаётся минимум один прогретый резервный узел; это стоит простаивающей мощности, но cold download не выполнит цель 25 секунд.

Для endpoint с 70 мс я бы выбрал RawDeployment, если измеренные очередь Knative и cold start не помещаются в бюджет.

• RawDeployment даёт прямое управление pod, сигналами HPA, disruption budget и прогретыми репликами, что подходит стабильному GPU-трафику.
• Serverless полезен редким CPU-моделям со scale-to-zero, но cold start модели в 20 секунд несовместим с синхронным запросом на 70 мс.
• Оба режима тестируются на одном профиле 1 000 RPS со сравнением proxy overhead, p99, времени масштабирования и стоимости.

Я бы объявил оба варианта проверенными целями и маршрутизировал по запасу очереди, а не использовал CPU как непроверенный аварийный путь.

• GPU обслуживает стабильный пик, где batching снижает цену; CPU принимает малый трафик, если полный путь сохраняет p99 ниже 100 мс.
• Маршрутизатор отправляет работу только в пулы с возрастом очереди ниже 15 мс и оставляет 20 мс на признаки и сеть.
• До выбора порога сравнивается стоимость миллиона успешных прогнозов при 100, 1 000 и 10 000 RPS с учётом простоя GPU.

Она верна, только если $18 000 включает всю относимую работу, а знаменатель определён как успешные production-прогнозы.

• В числитель входят GPU, CPU, gateway, storage, сеть, лицензии и телеметрия, а простой и нераспределённые расходы показываются отдельно.
• Неуспешные, повторные, shadow и прогревочные вызовы остаются в числителе, но не в знаменателе успешных прогнозов, и имеют отдельные показатели.
• При разных размерах запросов также нужна стоимость токена или элемента, иначе дешёвое среднее скроет когорту, потребляющую большинство GPU-времени.