Что нужно сделать

Ниже - основные задачи по ТЗ как я их прочитала. Документ построен так: сначала ваши цели (проверить что я всё услышала правильно), потом мои размышления о том, как это сделать (архитектура, pipeline, железо), в конце - объём работ, сроки и опыт по похожим задачам.

• → Замена окружения на фото автомобиля - пол, стены, потолок, вид за стёклами салона
• → Замена номерных знаков на брендированные рамки автоцентра
• → Опционально - генерация описаний для карточек объявлений
• → Целевой поток - 3 500 фото в сутки, работа потоком без длинных очередей
• → On-premise деплой - система работает локально на железе клиента
• → Интеграция с CRM автоцентра - конкретный стек и объём уточняем в открытых вопросах

Если что-то из этого списка не соответствует вашему видению, скажите на первом созвоне - тогда поправлю остальной документ под правильный scope.

01 Краткое резюме

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

Документ построен по шагам. Сначала - 6 открытых вопросов в разделе 2, ответы на которые сужают архитектуру и бюджет с диапазонов до конкретных цифр. Дальше - техническое решение: архитектура, пайплайн обработки, GPU, обучение моделей, хранилище. В конце - объём работ, стоимость и сроки, мой опыт по похожим задачам.

Стоимость работы и порядок оплаты - в разделе 9. Бюджет на железо (справочно) - в разделе 5.6. Эти цифры - после закрытия открытых вопросов следующего раздела, сейчас это диапазоны.

02 Открытые вопросы - требуют ответа до старта

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

2.1 Качество входных фото

• Есть ли «шакальные» фото с разрешением <1000 px? Если да - нужен отдельный путь pipeline (апскейл + restoration перед заменой фона).
• Есть ли большие фото >4000 px? Тогда нужен даунскейл + апскейл + подмешивание деталей оригинала в зону кузова.
• Отдаём клиенту фиксированный формат 1920×1080, или сохраняем исходное разрешение? Сохранение исходного - это +2-3 недели разработки.

2.2 Интеграция с CRM и использование API

• Какая CRM? Битрикс24 / amoCRM / Salesforce / самописная?
• Есть ли документированный API, webhook, тестовая среда?
• API отдаётся на сторону или только внутренний? От этого зависит SLA, сколько GPU в резерве и реализация очередей.

2.3 Объём библиотеки фонов и датасет автомобилей

Количество фонов на запуск. Сколько уникальных фоновых сцен нужно подготовить - 5, 20, 50? Один набор на весь автоцентр или разные под разные бренды?

Статичная библиотека или встроенный генератор? Это две разные архитектурные модели управления фонами:

• Вариант «библиотека» - на старте готовится 30-50 студийных фонов, дальше вы пользуетесь ими как закрытым набором. Подходит, если стиль фонов меняется редко.
• Вариант «встроенный генератор» - менеджер или дизайнер создаёт новые фоны по референсам прямо в системе, выбирает понравившийся и сразу применяет в работу. Подходит, если стиль меняется часто или нужна гибкость под кампании.

Условно: менеджер внезапно захотел, чтобы все фото машин на сайте стояли на одной и той же траве. Как часто такое может быть? От ответа на этот вопрос зависит, какую модель выбираем - библиотеку для редких смен или генератор для частых.

Датасеты автомобилей. Вы предоставите свой архив или нужно собирать? Ориентировочно нужно порядка 100 фото на каждую связку бренд + модель. Фото хорошего качества, с разнообразием по цвету кузова и условиям съёмки.

2.4 Retention и персональные данные

• Сколько храним результаты - 7 дней / 30 дней / 1 год / бессрочно? От этого объём MinIO-хранилища.
• ФЗ-152 / GDPR требования к фото с номерами?

2.5 Генерация описаний карточек - API или локальные модели?

Опциональная часть ТЗ. Есть два технических пути, с разной гибкостью, стоимостью и требованиями к инфраструктуре:

• Вариант А - API внешних LLM (OpenAI, Claude, Yandex GPT, GigaChat и т.д.). Лучшее качество текстов, нет дополнительной нагрузки на GPU-железо системы обработки фото. Клиент самостоятельно покупает API-ключи и несёт операционные расходы по факту использования - от долей цента до нескольких центов за описание, зависит от модели и объёма текста. Минусы - зависимость от внешнего сервиса, в случае OpenAI/Claude возможны сложности с оплатой и доступом из РФ.
• Вариант Б - локальные LLM-модели (Qwen 2.5, DeepSeek, GigaChat Lite, Vikhr и аналоги). Нет операционных расходов на токены, данные не покидают ваш контур. Минусы - требуется дополнительная GPU-мощность для инференса LLM (либо выделить отдельную карту, либо делить с image-пайплайном и получить замедление обработки фото). Качество обычно ниже топовых API-моделей, но для задачи «описание авто по параметрам» разница часто в пределах разумного.

Оба варианта реализуемы. В зависимости от выбора меняется и бюджет железа, и объём интеграционной работы, и операционные расходы. Для финальной оценки нужно сначала понять, как вы хотите чтобы это работало.

2.6 Генерация новых изображений автомобилей - как это работает на стороне менеджера?

Система работает на обучаемой базе моделей. Каждая модель авто представлена отдельной LoRA, обученной на ваших фото (~100 фото на связку бренд + модель). Менеджер в интерфейсе выбирает из списка «BMW X5 2023», пишет свободный промпт про сцену («стоит в лесу осенью, золотой час»), система генерирует именно эту модель в заданной сцене. Результат стабильно узнаваем - форма, пропорции, фирменные детали на месте.

Расширение базы силами вашей команды. В рамках проекта встраивается собственная система обучения моделей - ваш сотрудник через интерфейс:

• Загружает фото новой модели автомобиля (~100 снимков)
• Запускает тренинг LoRA (автоматизированный процесс)
• После завершения модель появляется в общем списке, доступна для генерации

Моё участие на этапе добавления новых моделей - не требуется. Базовая инфраструктура обучения и интерфейс её управления входят в проект, дальше база расширяется самостоятельно.

Вопросы к вам:

• Сколько моделей автомобилей должно быть в базе на старте - пилотный минимум (3-5) или более широкий набор?
• Есть ли у вас готовый архив фото по каждой модели, или датасеты будете собирать в процессе?

03 Архитектура системы

Система собирается из трёх слоёв, которые можно разворачивать и масштабировать независимо.

3.1 Слой оркестрации (без GPU)

Живёт на одной management-ноде - отдельный небольшой сервер без GPU, на стороне клиента. Три контейнера в Docker Compose:

• PostgreSQL - source of truth. Хранит все задачи с жизненным циклом (pending / in_progress / done / failed), метаданные, логи. Задача сначала пишется в Postgres, потом в очередь. Если Redis упадёт - перезаливаем очередь из Postgres по статусам, ни одна задача не теряется.
• Redis как hot queue поверх Postgres. Быстрый доступ для воркеров (RQ или Celery), кэш, pub/sub для push-статусов. Не source of truth, а ускоритель. Упал - восстанавливаемся из Postgres.
• FastAPI - API-слой. Приём задач (пишет в Postgres → enqueue в Redis), выдача статусов и результатов, health-чеки воркеров.

3.2 GPU-воркеры

Каждая GPU-нода - независимый воркер, забирает задачи из очереди. При падении одной ноды остальные продолжают, падающие задачи уходят на retry. Scale horizontal: добавление ноды = регистрация в очереди, без остановки системы.

3.3 Storage

MinIO как S3-compatible хранилище + NFS для шаринга весов моделей между нодами (см. раздел 7).

3.4 API поверхности

Конкретный набор endpoints определится в процессе работы - после закрытия вопроса 2.2 (какая CRM, какой источник задач) и итерации с вашей командой по пользовательскому сценарию. Минимальный функциональный набор: приём задачи → статус обработки → выдача результата → управление библиотекой фонов и логотипов → webhook на готовность. Детализация - на этапе ТЗ.

04 Pipeline обработки

Каждое фото проходит 8 этапов - каждый использует специализированную модель. Одна большая диффузия на весь пайплайн работает на демках, на базе в 2 500 объявлений с разными ракурсами разваливается.

Композиция, релайтинг и апскейл встроены в соответствующие этапы: композиция + релайтинг - часть edit-модели (06), апскейл - часть router'а (01) для Pipeline B.

4.1 Router качества входа

По метрикам качества исходника (разрешение, шум, blur, compression artifacts) выбирает один из двух путей:

• Pipeline A: шакал → красивый. Сначала апскейл + restoration (SwinIR / Real-ESRGAN / SUPIR), только потом замена фона. Diffusion не «улучшает» плохой input - он честно обрабатывает то, что есть.
• Pipeline B: большой → большой качественный. Даунскейл до 2048 px → замена фона → апскейл обратно → подмешивание верхней частоты с оригинала в car region. Без последнего шага крупные фото после диффузии теряют микродетали, кузов становится «пластиковым».

4.2 Классификация

Определяет тип фото. Базовый стек: zero-shot SigLIP. Дальше - fine-tuned классификатор после сбора 200-500 размеченных кейсов. Альтернатива с one-shot на базе SAM 3 рассматривается, если SigLIP недостаточно для ваших кадров.

4.3 Сегментация

• SAM 3 - основная модель, даёт лучшие маски и хорошо тюнится под домен. Для авто - связка SAM 3 + дообучение на выборке из базы клиента. Вопрос: есть ли бюджет под разметку хорошего датасета?
• YOLOv8-plate - специализированный детектор номерных знаков, быстрее SAM на мелких объектах. Дообучение под российский формат номера обязательно.
• Rembg / BiRefNet в лоб не используем - на reflective surfaces и детализированном фоне разваливаются: со стеклом проблемы и детали фона тянут в маску.

4.4 Оценка геометрии сцены

Depth estimation (Depth Anything V2 / MoGe) + normal estimation → camera pose. Это нужно чтобы фон «смотрел в ту же камеру» что и авто. Без этого шага получается «красивый фон + красивое авто», но неестественная картинка.

4.5 Подстановка фона

Два режима:

• Подстановка из библиотеки - основной режим. Скорее всего будут небольшие LoRA для стабилизации фона или зафиксированные промты. LoRA дают больше стабильности между генерациями.
• Генерация нового фона по промту - делается один раз на фон. FLUX.2 / Qwen-Image-Edit с depth-conditioning. Фон сохраняется в библиотеку. 10-30 секунд, не критично. Дальше фон стабилизируется через LoRA.

4.6 Выбор edit-модели

Для замены окружения используются edit-модели, а не классический inpainting. Разница принципиальна: inpainting-модель заполняет жёстко замаскированную область, а edit-модель принимает исходник + текстовую инструкцию и меняет целевые свойства (фон, освещение) с учётом всего контекста изображения. Для фото автомобилей edit-подход даёт более естественные переходы на стыках и правильные отражения, так как модель "видит" весь кадр, а не работает в изоляции с маской.

Финальный выбор после A/B-теста на данных клиента, разница между моделями может быть заметной:

• Qwen-Image-Edit 2511 - хорошая instruction-following, Apache 2.0, сильна в комплексных изменениях сцены.
• FLUX.2 Klein 9B - сильна в сохранении структуры.

4.7 Замена номерного знака

YOLOv8-plate детект → estimation 4 углов номера → гомографическая проекция брендированной рамки → подстройка освещения под сцену → лёгкий diffusion-pass для финального сглаживания. ~1 секунда. Модель детекта потребуется затюнить под российские номера.

4.8 Финальный quality-score

BRISQUE + CLIP-scoring автоматически помечает сомнительные результаты на ручное ревью. В пилоте настраиваются пороги: какие фото уходят оператору, какие одобряются автоматически.

05 GPU и производительность

5.1 Почему задача требовательна к железу

Обработка изображений diffusion-моделями - вычислительно тяжёлая задача. Один прогон полного пайплайна по одной фотографии включает несколько нейросетевых моделей: сегментация (SAM 3), depth-estimation, edit-модель (Flux или Qwen), апскейл, quality-check. Каждая требует GPU-памяти и времени.

Для потокового режима 3 500 фото/сутки нужна серьёзная GPU-инфраструктура с резервом на пики и отказы отдельных карт. Экономия на железе на этом этапе приводит либо к очередям (пользователь ждёт результат часами), либо к компромиссам по качеству (режется разрешение, упрощаются модели).

Подходящее железо - от RTX 5090 (consumer-grade карта с архитектурой Blackwell и поддержкой 4-битного формата NVFP4) до серверных NVIDIA A100 / H100 / H200. Разные карты дают разные компромиссы по скорости, объёму VRAM, цене и готовности к multi-GPU режиму - на серверных H100/H200 обработка идёт в разы быстрее, но и стоимость единицы существенно выше. Подробные варианты с комплектующими под каждый класс - в разделе 5.6.

5.2 Честный расчёт времени обработки

5.3 Сколько карт нужно под 3 500 фото/сутки

Расчёт зависит от финальной скорости на одну карту. Логика: при 50 сек/фото нужно меньше карт, при 300 сек/фото - больше. Грубая прикидка от допущения "одна карта обрабатывает одно фото за X секунд":

Для RTX 5090 под такой объём - ориентировочно от 10-12 карт. Для H200 - от 2-3 карт. К любому числу добавляем +1-2 карты в резерв на пики и отказы. Без резерва при любой неполадке накапливается очередь.

5.4 Моя рекомендация

5.5 Чего НЕ берём

• RTX 4090 - предыдущее поколение без NVFP4. 2-3× потеря скорости на diffusion.
• Консьюмерские <20 GB VRAM (3080, 3090, 4080) - не хватит на FLUX / Qwen-Image-Edit в BF16, придётся работать в ухудшенной точности.
• Офисные ПК без промышленного охлаждения - перегрев через 20-30 минут пиковой нагрузки, троттлинг.
• Mining-риги на б/у картах - ~50% с скрытыми дефектами, быстро выходят из строя под inference-нагрузкой.

5.6 Минимальные требования к обвязке на одну карту

Ниже - не готовые сборки, а минимум комплектующих на одну GPU по классам. В production-ноде карт будет несколько - CPU, RAM и БП масштабируются пропорционально количеству установленных карт (см. заметку после таблицы). Названия даны ориентировочно, приемлемо заменять на аналоги с похожими характеристиками. Стоимости в этот документ не включаю - зависят от текущих цен поставщиков и страны закупки.

Server-grade GPU · production-нода

06 Обучение моделей

Под training - однозначно аренда H200, на продакшен-карты 5090 это не вешается. Рабочая схема: prod на 5090 (инференс), training периодически на арендуемом железе. По мере накопления данных от клиента.

6.1 Актуальный стек обучения diffusion-моделей

Под всё, что должно быть стандартизировано и что модель должна "знать" (бренды, модели авто, характерные ракурсы, стили фонов), обучаются LoRA. Если в итоге качества окажется недостаточно - дотюниваем новый домен на базовом чекпоинте при наличии достаточного датасета.

• LoRA с rank/alpha-тюнингом и выбором конкретных блоков. В Flux часто дообучение только double_blocks даёт лучше, чем all blocks. Стандарт под быстрые концепты - новая модель авто, стиль. Датасет 10-1000 картинок, 1-8 часов на H200.
• DoRA (Weight-Decomposed LoRA, 2024) - улучшенная LoRA с декомпозицией на magnitude и direction. Использую когда LoRA не вытягивает.
• Multi-concept / block-specific LoRA - под задачу «много моделей авто в одной системе» это основной путь.
• Full fine-tuning небольших моделей - Klein 4B (Apache 2.0), SANA 1.6B, Z-Image-Edit 6B. Дни на 4-8× H100/H200 с FSDP, 8-bit Adam, gradient checkpointing. Даёт качество которое LoRA физически не достать на edit-моделях под специфический домен.
• Instruct-tuning edit-моделей на paired данных (источник + edit prompt + target) - именно такая схема для обученной «под вас» модели замены фона.
• DPO / SPO (preference optimization) - если есть датасет с фидбеком «хорошо/плохо» по реальной приёмке.

6.2 Дорожная карта обучения под проект

1. Пилот - минимальные LoRA на тестовые модели. Например, берём 3 самых популярных модели автомобилей и 1-5 фонов, которые вы хотите видеть на сайте. Проверяем что pipeline в принципе работает на ваших данных.
2. Первый месяц production. Пока вы покупаете оборудование, я получаю от вас дизайн интерфейса, который вы ожидаете, и собираю куски процессов пайплайна. В конце месяца сдаётся MVP, работающий в вашем интерфейсе. Второй месяц - расширение модельного ряда автомобилей за счёт обучения моделей знаниям о них, генераторы фонов, исправления и коррекция результатов под требования.
3. Третий месяц / continuous - обучение ваших специалистов использованию системы, мелкие консультации и починки в случае поломок. Параллельно - DPO на реальной приёмке: какие результаты приняли, какие вернули на переделку.

07 Storage и инфраструктура

Раз всё on-premise, S3 тоже локальный - значит падать будет на своё железо. Закладываем избыточность и бэкапы с первого дня.

7.1 MinIO как S3-compatible хранилище

Open source, полноценный S3 API. Single-node на старте, distributed-кластер под нагрузкой. Надёжность через erasure coding - EC:4 держит отказ до 4 дисков без потери данных.

7.2 Shared FS для чекпоинтов моделей

Чтобы не дублировать 20 GB Flux-веса на каждой GPU-ноде:

• До 5-10 нод - обычный NFS. Linux-стандарт, настраивается за час, любой админ умеет.
• 10-50 нод - CephFS. Сложнее NFS, но заодно даёт block-storage для будущего K8s.

7.3 Hot cache на NVMe management-ноды

Postgres data, Redis AOF-лог, свежие результаты последних часов - чтобы клиент забирал без похода в MinIO.

7.4 Бэкапы

7.5 Retention policy

Типичная схема, финальное решение - за клиентом:

• Hot на NVMe - 7-30 дней свежих результатов.
• Warm в MinIO с erasure coding - 1-3 месяца.
• Cold - архив или удаление по SLA.

7.6 Ориентир по объёму

Формула: генераций/день × средний размер × копий × дни retention.

Пример под вашу нагрузку: 3 500 × 10 MB × 2 копии × 90 дней = ~6.3 TB. Цифра считается как worst-case суммарного retention (hot + warm, см. 7.5), не только hot-слоя. При retention 1 год - ~25 TB плюс бэкапы.

08 Объём работ

Проект разделён на блоки. Каждый может приниматься и оплачиваться отдельно.

Блок A - ML-пайплайн (ядро системы)

• Router качества входа (шакал vs большой vs базовый)
• Классификатор фото
• Сегментация - базовый SAM 3, подготовка к дообучению на данных клиента, разметка
• Edit-пайплайн - замена фона, пола, потолка на Qwen-Image-Edit 2511 или FLUX.2 Klein 9B (финальный выбор по A/B)
• Контроль перспективы и геометрии
• Релайтинг и обновление отражений на glossy surfaces
• Детекция и замена номерных знаков
• Quality-score для авто-фильтрации на ручное ревью
• Оптимизации под ускорение инференса (подбираются под финальное железо)
• Генерация фонов по промтам с указанием автомобиля. Система автоматического добавления новых моделей автомобилей в базу знаний генератора

Блок B - Серверная инфраструктура

• Установка ОС (Ubuntu Server 24.04), драйверов, CUDA, базовой сети на железе клиента
• PostgreSQL + модель данных + миграции + стратегия бэкапа
• Redis как hot-queue поверх Postgres
• FastAPI backend + аутентификация
• Celery/RQ воркеры
• MinIO + NFS + erasure coding
• Мониторинг (Prometheus + Grafana), логи (Loki), алерты
• Docker Compose на management-ноде, Docker для GPU-воркеров
• Бэкапы + тестирование восстановления

Блок C - Web UI

Вы передаёте дизайн нужных экранов - я реализую их и подключаю к backend. В проект входит реализация ключевых экранов, необходимых для работы системы:

• Интерфейс ревью с mask-editor - для операторов, которые проверяют результаты обработки
• Список моделей автомобилей с их LoRA - для выбора при генерации / добавления новой модели
• Управление библиотекой фонов - просмотр, загрузка, генерация по референсу (если выбран вариант "встроенный генератор" в вопросе 2.3)
• Админ-интерфейс - управление логотипами, настройка порогов quality-gate, просмотр логов

Отдаю документацию, чтобы дальше вы могли подключать новые экраны и дорабатывать существующие без моего участия. Не входит в проект: отрисовка дизайна (на вашей стороне), а также интеграция системы в публичный сайт / мобильное приложение - отдельные соглашения.

Блок D - Публичный REST API

• OpenAPI 3.0 спецификация + автогенерация Swagger
• API-ключи, rate limiting, логирование
• Эндпоинты: создание задачи, проверка статуса, получение результата, управление фонами
• Webhooks на готовность результата
• Примеры на Python, Node.js, curl

Блок E - Интеграции

• Адаптер под CRM клиента (ключевой открытый вопрос 2.2)
• Интеграция с таск-менеджером (уведомления о ревью / сбоях)
• Генератор текстов для карточек авто через Claude / GPT-4o с промт-инжинирингом под разные стили

Блок F - Тестирование, деплой, обучение

• Unit + интеграционные тесты ключевых компонентов
• Нагрузочное тестирование на целевой поток
• Runbook для администратора (что делать при сбоях Redis / заполнении диска / падении GPU-ноды)
• Руководство пользователя и видеоинструкции для операторов
• Обучение 2-3 операторов ревью, дизайнера фонов, сисадмина клиента
• Финальный production-деплой

09 Стоимость и сроки

9.1 Почему такая стоимость

Я - senior ML-инженер с узкоспециализированным опытом именно в этом типе задач (замена фона в массовой фотографии, on-premise деплой, fine-tune diffusion-моделей). Работаю одна, без «команды из трёх человек, собирающих решение с нуля». Готовые паттерны адаптирую под вашу специфику. Это и позволяет держать такую стоимость.

500 тыс ₽ / месяц - это моя рабочая ставка как senior ML-инженера. За 2 месяца = 1 млн ₽. 200 тыс - буфер на правки по итогам приёмки, адаптацию под edge cases, мелкие доработки в пилоте.

Если нужен отдельный фронтенд-разработчик под Web UI или dedicated DevOps под инфру - это подключается как сабконтракт и оценивается отдельно, но по вашей задаче core pipeline и оркестрация - одни руки.

9.2 Сроки

9.3 Порядок оплаты

Основная разработка - 1 000 000 ₽:

• ~1 000 USD (≈ 100 000 ₽) - аванс на старте проекта. Полностью идёт на оплату аренды GPU для обучения начального набора моделей (см. раздел 6). Разработчик не берёт эти средства в оплату работы - это инфраструктурный бюджет.
• 500 000 ₽ - в конце первого месяца работы (первая половина разработки).
• 500 000 ₽ - в конце второго месяца работы (вторая половина разработки, приёмка MVP).

Резерв на правки - 200 000 ₽, выплачивается в конце третьего месяца (по итогам пилотной фазы и гарантийного периода).

Итого по договору: 1 000 000 ₽ разработки + 200 000 ₽ резерва = 1 200 000 ₽. Плюс отдельно ~1 000 USD на аренду GPU под обучение (авансом на инфраструктуру, не на разработчика).

9.4 Что НЕ входит

• Стоимость железа (GPU, серверы, хранилище, UPS, сеть) - клиент несёт отдельно, см. раздел 5.6.
• Доработки на стороне CRM клиента - если нужны, отдельный контракт.
• Поддержка после 1-месячного гарантийного периода - отдельный договор на ежемесячной основе. Гарантийный период начинается после выхода на полную нагрузку (после пилотной фазы).
• Создание библиотеки фонов сверх 30-50 базовых сцен - дополнительные фоны по запросу.
• Юридическое сопровождение вопросов персональных данных (ФЗ-152).
• Мобильные приложения.
• Подключение системы к внешним местам использования - например, кнопка обработки фото на публичном сайте для клиентов автосалона.

10 Мой опыт по похожим задачам

Чтобы было понятно, на чём основаны конкретные рекомендации выше.

Примеры работ - по запросу (часть под NDA, обезличенные кейсы доступны для просмотра).

11 Следующие шаги

1. Вы передаёте 200-500 реальных фото из базы для анализа качества входа.
2. 2-3 дня на детальный анализ - после этого диапазоны в документе сужаются до конкретных цифр.
3. Подписание договора и ТЗ.
4. Старт работ - аванс 10%, параллельно заказ железа, первая неделя на арендуемых GPU пока железо приходит.
5. 2 месяца разработки + 4 недели пилот - полная готовность к эксплуатации.