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

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

• Два шлюза на объекте принимают RTSP-сессии, нормализуют время и держат 30-минутный кольцевой буфер на NVMe, рассчитанный по измеренному битрейту с запасом на восстановление.
• Кольцевой буфер переживает пятисекундный сбой WAN, только пока исправны шлюз и его локальный диск; при потере шлюза камеры переподключаются к парному, а не полагаются на этот буфер.
• При перегрузке анализ сначала снижается с 15 до 5 FPS, а подтверждённые клипы получают резерв места и приоритет выгрузки; если резерв заполнен, сервис сообщает самое раннее восстановимое время вместо обещания нулевых потерь.
• Метаданные Kafka реплицируются в трёх зонах; месячная доступность приёма должна достигать 99,95%, а контрольные суммы клипов и p95 поисковой индексации ниже 2 секунд измеряются отдельно.

Я бы планировал штатный конвейер на 80 мс, оставив 20 мс на джиттер и температурные колебания.

• Захват и синхронизация получают 8 мс, предобработка 12 мс, параллельный инференс камер и лидара 45 мс, фузия 10 мс, трекинг и публикация 5 мс, всего 80 мс.
• CUDA streams перекрывают передачу и ядра, очереди держат не более одного цикла, а устаревшая работа отменяется и не задерживает следующее управляющее обновление.
• Релизная кампания покрывает весь ODD, температуры, отказы сенсоров и достаточно часов движения, чтобы верхняя односторонняя 95-процентная граница вероятности пропуска дедлайна уложилась в цель; одной 60-минутной поездки недостаточно.
• После заданного числа последовательных пропусков стек публикует состояние деградации, а планировщик переходит к ограниченному режиму или состоянию минимального риска вместо бесконечного молчаливого отбрасывания кадров.

Я бы объединил контролируемую съёмку с двухступенчатым детектором и рассчитывал приёмку по положительным примерам с дефектами, а не по общему объёму линии.

• Четыре камеры с глобальным затвором и импульсным светом держат смаз ниже 0,2 мм, а PLC-триггер связывает все ракурсы одним ID детали.
• Для каждого критичного типа дефекта и линии заранее задаётся число положительных примеров; recall проходит только тогда, когда его нижняя односторонняя 95-процентная граница не ниже 99,5% в обязательных срезах.
• Нормальные детали образуют отдельный репрезентативный знаменатель для ложного брака, а несколько ракурсов одной детали считаются одним решением, а не независимыми примерами.
• Сомнительные детали отводятся на проверку, а пропускная способность подтверждается на 600 деталях в минуту без ослабления статистических тестов.

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

• Из 576 GPU-часов каждое семейство получает 192 с одинаковыми train split, декодером кадров, корпусом предобучения, бюджетом поиска оптимизатора и числом просмотренных кадров; seeds и неудачные запуски тоже расходуют лимит.
• Временная свёрточная модель проверяет сильный локальный motion bias, transformer с оконным или разреженным attention проверяет дальние связи при контролируемом росте токенов, а state-space модель проверяет потоковый 10-минутный контекст с линейным состоянием и памятью.
• Все модели проходят одинаковые срезы коротких, средних и 10-минутных событий, а плотность выборки меняется только как объявленная ablation, а не как скрытый дополнительный compute.
• Я выбираю по границе Парето качества, калибровки, пиковой памяти, потокового состояния и задержки на целевом GPU, а не по названию архитектуры или image top-1 accuracy.

Я бы хранил неизменяемые медиа в объектном хранилище, а поисковые манифесты в версионируемых таблицах Iceberg.

• Объекты получают хеши содержимого, а Parquet-манифесты несут камеру, правовое основание, метку, контрольную сумму и предобработку без листинга bucket.
• Каждый обучающий запрос фиксирует snapshot ID Iceberg, а архивный tier всё равно хранит исходные медиа полные пять лет.
• Контрольные суммы проверяются при записи, выборочно при чтении и во время ремонта реплик; приёмка требует ноль необнаруженных повреждений в заданном аудите, а не непроверяемую гарантию на миллиард чтений.
• Проверка восстановления собирает закреплённый датасет из архивной реплики по манифесту и за 30 минут проверяет дайджест каждого объекта.

Я бы считал правку надёжно сохранённой только после подтверждения сервера, а неподтверждённые операции держал в клиентском write-ahead log.

• Каждая операция с рамкой записывается в IndexedDB с ключом идемпотентности до появления статуса pending; autosave раз в 10 секунд пакетирует отправку, но не задаёт границу надёжности.
• PostgreSQL фиксирует операцию относительно монотонной ревизии задания и возвращает принятую ревизию, после чего клиент удаляет запись из локального журнала.
• После переподключения или перезапуска браузера pending-операции повторяются идемпотентно; устаревшая базовая ревизия создаёт ветку для проверки вместо перезаписи чужой работы.
• Тесты отказов требуют отсутствия потерь подтверждённых правок, а нагрузочные тесты держат 250 сессий, p95 загрузки задания ниже 2 секунд и 120 000 принятых рамок в день; UI честно показывает риск локальных правок при уничтожении устройства.

Я бы объединил скрытые gold-задания, контролируемое перекрытие и арбитраж, но оценивал классы и рамки метриками, которые показывают случайное согласие и пропущенные аннотации.

• Пять процентов заданий составляют обновляемые скрытые gold-примеры, а 10% независимо размечаются дважды.
• Для классов сохраняется требуемое сырое согласие 0,95, но приёмка также показывает Cohen's kappa и поклассовые precision и recall, потому что доминирующий класс может завысить agreement.
• Рамки один раз сопоставляются по объявленному class-aware IoU assignment; требуемое перекрытие 0,85 дополняется распределением IoU, recall несопоставленных эталонов и precision лишних рамок вместо одной медианы.
• Провал в скользящем окне приостанавливает аннотатора для калибровки, а часто оспариваемые gold-примеры уходят старшему арбитру и не штрафуют команду автоматически.

Я бы сделал оценку версионируемым batch-заданием по дайджесту модели, snapshot датасета, пакету метрик и коммиту срезов.

• Воркеры Ray один раз записывают предсказания по стабильным ID примеров, поэтому 300 срезов используют один inference pass.
• Агрегация метрик использует фиксированный порядок и стабильное суммирование; одинаковые дайджесты должны давать точные значения отчёта, если только неизбежное недетерминированное ядро не описано явно.
• Допустимый численный диапазон задаётся отдельно для метрики, например 0,01 процентного пункта recall вместо неопределённого 0,01, а релизные срезы содержат доверительные интервалы.
• CI повторяет фиксированное подмножество при разном числе воркеров, чтобы до полного двухчасового прогона находить изменения порядка редукции и границ шардов.

Я бы использовал MLflow-совместимый реестр над неизменяемыми артефактами и требовал подписанный lineage-манифест каждой версии.

• Манифест связывает Git-коммит, дайджест контейнера, конфигурацию, snapshots датасетов, контракт предобработки, отчёт и родительский checkpoint.
• Переход candidate, validated и production требует сервисной идентичности и двух одобрений; артефакты никогда не перезаписываются.
• По prediction_id точная модель и lineage данных возвращаются за пять минут, а ежедневный аудит подтверждает 100% покрытия.

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

• Каждая команда получает квоту и не более одного интерактивного задания на два GPU в защищённом классе; лишние заявки видят оценку очереди и не наследуют гарантию старта.
• Остальные 56 GPU выполняют batch-задания с gang scheduling, fair-share и backfill, а свободную batch-мощность интерактивные задания могут занимать с вытеснением после сохранения контрольной точки.
• Манифесты датасетов размещаются на локальных NVMe, а topology-aware placement не разносит multi-GPU задание по медленным связям.
• Принятые задания должны держать p95 старта ниже 10 минут и месячную полезную загрузку выше 75%; отказы и ожидание квоты не дают высокой загрузке скрыть неудовлетворённый спрос.

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

• Каждый rank пишет временный шард, а rank zero публикует поколение только после всех контрольных сумм, поэтому отказ теряет не более одного интервала checkpoint.
• Checkpoint содержит global step, optimizer, RNG, эпоху и курсор sampler в dataloader и манифест датасета, предотвращая пропуски и повторы после перемешивания.
• Замена планировщиком может добавить около 10 минут простоя, но не меняет 15-минутный recovery point objective; в отчётах эти величины показываются отдельно.
• Chaos-прогоны сравнивают validation curve после возобновления и без отказа на одинаковых global steps с допуском и доверительным интервалом конкретной метрики, а не с общим расхождением 0,1%.

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

• Региональный ingest записывает изображение по хешу содержимого и версии объекта, затем ставит в очередь регион, tenant, модель, дайджест предобработки и неизменяемую ссылку вместо копирования байтов через глобальную шину.
• Глобальный control plane может маршрутизировать метаданные, но policy допускает работу только в разрешённую региональную очередь; воркер получает короткоживущее право чтения точной версии, поэтому европейские медиа нельзя получить из США.
• Ключ идемпотентности по tenant, версии объекта, модели и предобработке делает at-least-once доставку безопасной, а переход состояния с арендой и условная запись публикуют только один финальный результат.
• При отказе регионального пула задания ждут или переходят в другой пул внутри той же правовой границы; возраст очереди, истёкшие задания, dead letters и отмена являются видимыми исходами, а не маскируются синхронной ошибкой.

Я бы использовал pull-агент подписанных обновлений, аппаратно-зависимые манифесты и A/B-разделы моделей.

• Устройства опрашивают CDN через случайно разнесённые интервалы, проверяют подписи модели и runtime, свободное место, устанавливают в неактивный раздел и проходят аппаратный self-test до переключения.
• Rollout проходит лабораторию, 1%, 10%, 50% и 100% только пока ошибки установки, подписи, места, self-test, crashes и задержки остаются в объявленных бюджетах.
• Завершение считается среди устройств, которые были online и доступны в 24-часовом окне; offline, заблокированные политикой и неподдерживаемые когорты показываются отдельно и не записываются в успех.
• Цель составляет 99% завершения среди eligible-устройств за 24 часа и менее 0,5% неудачных установок; сбойное устройство локально возвращается назад и согласует desired и observed версии после подключения.

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

• Edge-encoder обрабатывает сырой кадр и выдаёт сжатый feature tensor; слой разделения выбирается измерениями, потому что ранние признаки крупнее и легче инвертируются, а поздние могут потерять детали для cloud-head.
• Privacy review проверяет восстановление изображения, membership leakage и связывание tenants, затем фиксирует шифрование, retention, доступ, дайджест encoder, tensor schema и разрешённое сжатие.
• Облако принимает только совместимую пару encoder и head, а edge меняет квантование признаков или sampling под bandwidth-бюджет магазина без скрытого изменения контракта.
• При потере канала или совместимости полная локальная модель возвращает помеченный degraded-результат; сырые пиксели не загружаются, а признаки в очереди истекают и не порождают устаревшие решения.

Я бы поставил первым откалиброванный CPU-фильтр или малую GPU-модель, а неоднозначные примеры направлял в дорогой детектор.

• Первая ступень настраивается на 99,7% recall и убирает только явные отрицательные примеры ниже confidence 0,05, завершая 70% запросов.
• Вторая ступень обрабатывает положительные примеры и зону неопределённости, а пороги выбираются по срезам реального трафика.
• Релиз требует 98% сквозного recall, потери критичного среза не более 0,3 пункта, p99 ниже 100 мс и снижения GPU-часов минимум на 50%.

В стандартном Triton я бы использовал ограниченный dynamic batching и изоляцию классов трафика, а не приписывал ему отсутствующий EDF scheduler.

• Интерактивный deployment задаёт max_batch_size 32, preferred_batch_size 8, 16 и 32 и max_queue_delay_microseconds 4000; preferred-размеры являются подсказками, а реальный максимум ограничивает max_batch_size.
• Уровни приоритета Triton и queue timeout policy могут отклонять слишком долго ожидающий запрос, но штатный dynamic batcher не отправляет batch по абсолютным дедлайнам запросов или ровно за 8 мс до дедлайна старейшего.
• Bulk-трафик использует отдельно названный deployment модели со своими model config, очередью и проверенным max batch 64; добавление instance groups к одной модели не создаёт очереди для классов трафика.
• Если нужен EDF, я явно ставлю custom scheduler или backend перед Triton и тестирую его на 1 000, 6 000 и 12 000 FPS с требованием сквозного p99 ниже 100 мс.

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

• При 300 FPS на L4 пик 60 000 FPS требует 200 GPU при 100% измеренной мощности.
• Ограничение загрузки после отказа до 80% требует 60 000 разделить на 300 и на 0,8, то есть 250 оставшихся GPU.
• При трёх равных зонах каждая держит 125 GPU, всего 375; после потери одной остаются требуемые 250, а не пул, уже загруженный на 100%.
• Forecast autoscaling может сокращать активные replicas, только если резерв и время старта сохраняют этот контур отказа; иначе перегрузка переходит в явный admission или load-shed режим.

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

• Например, на 16 A100 40 GB критичная модель с измеренным пиком 14 ГБ помещается с запасом в профиль 3g.20gb; модель, которая не помещается, получает полный GPU.
• NVIDIA Kubernetes device plugin публикует MIG-ресурсы, планировщик закрепляет один критичный экземпляр Triton за MIG-сегментом, а контроль допуска не разрешает запускать больше экземпляров, чем допускает профиль памяти.
• Long-tail модели используют отдельные полные GPU или совместимые меньшие профили с weighted queues и выгрузкой после простоя.
• Noisy-neighbor тесты покрывают точную MIG-раскладку, формы входа, Triton instance groups и конкурентный пик памяти, требуя p99 критичных моделей ниже 80 мс и long-tail ниже 500 мс.

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

• Семантика decoder, EXIF orientation, порядок цветов, геометрия resize, padding, нормализация, layout, dtype и округление фиксируются дайджестом.
• Метаданные и преобразования координат должны совпадать точно, а FP32-тензоры используют строгий численный допуск из golden fixtures вместо универсальной константы.
• FP16 и INT8 runtimes получают допуски тензоров с учётом dtype и decision-level parity для рамок, масок, классов и NMS около рабочего порога.
• Изменение контракта создаёт новую версию и требует либо переобучения, либо явного доказательства совместимости для каждого целевого runtime.

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

• Для INT8 в TensorRT 10 экспортированный граф содержит явные Q/DQ nodes; quantization scales или calibration artifact получают на репрезентативном датасете и фиксируют дайджестами датасета и графа, а не перекалибруют только из-за смены SKU GPU.
• Движки собираются и измеряются для точного целевого стека: compute capability T4, L4, A10 или Orin, OS либо JetPack, CUDA, TensorRT, plugins, tactic policy и разрешённые формы.
• Один сериализованный движок может содержать несколько optimization profiles; я выбираю три для ожидаемых малых, средних и больших диапазонов форм и разделяю движки только при обосновании по старту, памяти или производительности tactics.
• Валидация покрывает границы каждого профиля, качество соответствующей точности, десериализацию на цели, пик памяти и задержку вместо обещания переносимости между стеками.