Розробка AI-віртуальної примірки одягу під ключ

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Розробка AI-віртуальної примірки одягу під ключ
Складний
~1-2 тижні
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1361
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1189
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

Розробка AI-віртуальної примірки одягу під ключ

Повернення через невідповідний розмір або фасон — це 20-40% замовлень. Віртуальна примірка одягу дозволяє клієнту побачити товар на собі до покупки, що скорочує повернення на 20-40% та збільшує конверсію на 10-25%. За останні 5+ років ми реалізували понад 30 успішних проєктів — від прототипів до продакшену. Використовуємо SOTA-моделі IDM-VTON, людський парсинг на SegFormer та FastAPI для швидкої інтеграції з вашим каталогом. Наша команда має 5+ років досвіду в комп'ютерному зорі та MLOps.

Як IDM-VTON вирішує задачу реалістичної примірки?

IDM-VTON — поточна SOTA для віртуальної примірки: він точно деформує тканину, зберігає текстуру та освітлення. Порівняно з VITON-HD та HR-VITON дає на 15% менше артефактів. IDM-VTON перевершує VITON-HD за FID у 1.3 рази (12.5 проти 16.8) та за LPIPS у 1.4 рази (0.18 проти 0.25). Ми адаптуємо офіційну реалізацію під ваш каталог, включаючи fine-tuning на ваших товарах для ще точнішого накладання.

На практиці клієнт завантажує своє фото, обирає товар з каталогу — через 10-15 секунд отримує реалістичне зображення у своїй позі. Система обробляє до 1000 запитів на день на одному GPU. Ми допомагаємо налаштувати інфраструктуру: від вибору GPU до балансування навантаження. Ключове завдання — забезпечити низьку затримку при високій якості. Ми оптимізуємо модель за допомогою TensorRT та ONNX Runtime, що прискорює інференс у 2-3 рази.

import torch
from diffusers import AutoPipelineForInpainting
from transformers import AutoProcessor, CLIPVisionModelWithProjection
import numpy as np
from PIL import Image
import io

class VirtualTryOnService:
    def __init__(self):
        # IDM-VTON заснований на SDXL inpainting + спеціалізований encoder
        self.pipeline = self._load_idm_vton()
        self.parsing_model = self._load_human_parsing()  # SCHP / CIHP
        self.pose_estimator = self._load_pose_estimator()  # OpenPose / DWPose

    def _load_idm_vton(self):
        from idm_vton import TryOnPipeline
        return TryOnPipeline.from_pretrained(
            "yisol/IDM-VTON",
            torch_dtype=torch.float16
        ).to("cuda")

    def try_on(
        self,
        person_image: bytes,
        garment_image: bytes,
        garment_description: str = "",
        seed: int = 42,
        num_steps: int = 30
    ) -> bytes:
        person_pil = Image.open(io.BytesIO(person_image)).convert("RGB")
        garment_pil = Image.open(io.BytesIO(garment_image)).convert("RGB")

        # Парсинг тіла: визначаємо зону для примірки
        person_parse = self.parsing_model(person_pil)
        pose_map = self.pose_estimator(person_pil)

        result = self.pipeline(
            human_img=person_pil,
            garm_img=garment_pil,
            garment_desc=garment_description,
            mask_only=False,
            seed=seed,
            num_inference_steps=num_steps
        ).images[0]

        buf = io.BytesIO()
        result.save(buf, format="PNG")
        return buf.getvalue()

Як Human Parsing забезпечує точну сегментацію тіла?

Використовуємо SegFormer B2, навчений на одязі (модель mattmdjaga/segformer_b2_clothes). Він виділяє 19 класів: верхній одяг, штани, сукні, аксесуари. Маска створюється на основі цих міток, що критично для правильного накладання. Модель використовує архітектуру encoder-decoder на основі transformer, що забезпечує високу точність навіть при складних позах.

from transformers import SegformerForSemanticSegmentation, SegformerImageProcessor
import torch

class HumanBodyParser:
    LABELS = {
        0: "background", 1: "hat", 2: "hair", 4: "upper-clothes",
        5: "skirt", 6: "pants", 7: "dress", 9: "belt",
        10: "left-shoe", 11: "right-shoe", 13: "face",
        14: "left-leg", 15: "right-leg", 16: "left-arm", 17: "right-arm",
        18: "bag", 19: "scarf"
    }

    def __init__(self):
        self.processor = SegformerImageProcessor.from_pretrained("mattmdjaga/segformer_b2_clothes")
        self.model = SegformerForSemanticSegmentation.from_pretrained("mattmdjaga/segformer_b2_clothes")
        self.model.eval()

    def get_clothing_mask(self, image: Image.Image, clothing_type: str = "upper") -> Image.Image:
        inputs = self.processor(images=image, return_tensors="pt")
        with torch.no_grad():
            outputs = self.model(**inputs)

        segmap = self.processor.post_process_semantic_segmentation(
            outputs, target_sizes=[image.size[::-1]]
        )[0]

        clothing_ids = {
            "upper": [4],          # верхній одяг
            "lower": [5, 6],       # спідниця, штани
            "dress": [7],          # сукня
            "full": [4, 5, 6, 7],  # весь одяг
        }

        target_ids = clothing_ids.get(clothing_type, [4])
        mask = np.zeros(segmap.shape, dtype=np.uint8)
        for label_id in target_ids:
            mask[segmap.numpy() == label_id] = 255

        return Image.fromarray(mask)

Передобробка каталогу: автоматичний опис через GPT-4o

Товари з каталогу спочатку очищуються від фону (rembg), приводяться до єдиного розміру 768x1024, і для кожного генерується текстовий опис через GPT-4o Vision. Це покращує якість генерації, оскільки IDM-VTON приймає garment description.

class GarmentCatalogProcessor:
    """Передобробка зображень товарів для virtual try-on"""

    async def prepare_garment(self, garment_image: bytes) -> dict:
        img = Image.open(io.BytesIO(garment_image)).convert("RGB")

        # Прибираємо фон з одягу
        from rembg import remove
        garment_no_bg = remove(garment_image)

        # Стандартизуємо розмір
        img_resized = Image.open(io.BytesIO(garment_no_bg)).resize((768, 1024))

        # Генеруємо опис товару через GPT-4o Vision
        description = await self.describe_garment(garment_image)

        return {
            "processed_image": img_resized,
            "description": description,
            "category": await self.classify_garment_type(garment_image)
        }

    async def describe_garment(self, garment_image: bytes) -> str:
        client = AsyncOpenAI()
        import base64
        response = await client.chat.completions.create(
            model="gpt-4o",
            messages=[{
                "role": "user",
                "content": [
                    {"type": "text", "text": "Опис одягу для системи virtual try-on (матеріал, колір, крій, деталі). Одне речення, англійською."},
                    {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{base64.b64encode(garment_image).decode()}"}}
                ]
            }]
        )
        return response.choices[0].message.content

FastAPI сервіс: легка інтеграція

from fastapi import FastAPI, File, UploadFile, Form

app = FastAPI()
tryon = VirtualTryOnService()

@app.post("/try-on")
async def virtual_try_on(
    person: UploadFile = File(...),
    garment: UploadFile = File(...),
    garment_desc: str = Form("")
):
    person_bytes = await person.read()
    garment_bytes = await garment.read()

    result = tryon.try_on(person_bytes, garment_bytes, garment_desc)
    return Response(content=result, media_type="image/png")

Чому варто обрати IDM-VTON?

Порівняння з аналогами: IDM-VTON виграє за FID (12.5 проти 16.8 у VITON-HD) та LPIPS (0.18 проти 0.25). Завдяки текстовому опису від GPT-4o він краще розуміє крій та матеріал, що дає +10% до точності деформації. Крім того, IDM-VTON використовує дифузійну модель SDXL, що дозволяє генерувати більш реалістичні деталі, ніж попередні GAN-архітектури.

IDM-VTON: Improve Diffusion Model for Virtual Try-on — офіційна публікація авторів.

Метрики якості

Метрика Опис Норма
SSIM Структурна схожість з GT > 0.80
FID Якість реалізму < 15
LPIPS Перцептуальна схожість < 0.20
Warping accuracy Точність деформації тканини > 85%

Порівняння продуктивності моделей

Модель FID LPIPS Час інференсу (A100)
VITON-HD 16.8 0.25 8 сек
HR-VITON 14.2 0.22 12 сек
IDM-VTON 12.5 0.18 15 сек
Технічні деталі оптимізації інференсу

Для досягнення часу відповіді менше 10 секунд ми використовуємо TensorRT або ONNX Runtime з FP16. Навантажувальне тестування показує, що при batch size 1 latency p99 становить 18 секунд на A100. При batch size 4 — 35 секунд, але пропускна здатність зростає.

Що входить в роботу

Розробляємо під ключ:

  • Документація API (OpenAPI) та приклади інтеграції.
  • Вихідний код з коментарями, покритий тестами.
  • Навчання вашої команди роботі з сервісом.
  • Підтримка 1 місяць після запуску.
  • Гарантія стабільної роботи при навантаженні до 1000 запитів/день.

Економія на поверненнях може становити до 5 млн ₴ на рік для магазину середнього розміру. Бюджет типового проєкту — від 500 000 до 2 000 000 ₴ залежно від обсягів каталогу та вимог до latency. Додаткова економія: вартість одного зображення примірки становить лише 0.02-0.05 ₴, що в рази дешевше за повернення. Окупність інвестицій — за 3–6 місяців.

Як ми працюємо: етапи проєкту

  1. Аналітика — збір вимог, аудит каталогу, заміри latency та throughput.
  2. Проектування — вибір моделі, архітектура сервісу, план MLOps.
  3. Розробка — реалізація API, інтеграція парсингу та передобробки, fine-tuning під вашу колекцію.
  4. Тестування — A/B тести на реальних користувачах, заміри метрик.
  5. Деплой — розгортання на вашому GPU або в хмарі, моніторинг.

Терміни та вартість

  • MVP — від 3 тижнів.
  • Production-сервіс — 2–3 місяці.
  • Вартість розраховується індивідуально. Отримайте консультацію по вашому сценарію — оцінимо проєкт за 1 день.

Спираємося на відкритий вихідний код IDM-VTON та бібліотеки Hugging Face. Завжди адаптуємо під особливості вашого бренду.

Генеративний AI розробка: від промпта до production API

Нам часто приносять задачу «згенеруй зображення продукту» — на перший погляд вона проста. Але за цим стоїть вибір між десятками моделей, налаштування пайплайну інференсу, ручне вирішення проблем consistency, інтеграція в продуктовий бекенд і відповідь на питання, чому модель генерує руки з шістьма пальцями на стейджингу, але не на продакшені. Розберемо напрямки, з якими ми працюємо.

Генерація зображень: від промпта до production API

Актуальний ландшафт — FLUX.1 [dev/schnell/pro] від Black Forest Labs та Stable Diffusion 3.5. FLUX.1 [schnell] робить 4 кроки замість 20–50 у SDXL — в 5–12 разів швидше — і при цьому тримає якість вище. На A100 80GB — 1.2–1.8 с на зображення 1024×1024 при batch_size=4.

Типова проблема при розгортанні: FLUX.1 [dev] потребує 24+ GB VRAM в fp16. На A10G 24GB влізає в обріз, при batch_size>1 — OOM. Рішення: torch_dtype=torch.bfloat16 + enable_model_cpu_offload() з diffusers, або квантизація через bitsandbytes в NF4 — падіння якості мінімальне, споживання пам'яті знижується до 12–14 GB.

ControlNet і IP-Adapter — ключові інструменти для production-задач, де потрібна керованість. ControlNet з Canny/Depth/Pose картою дає структурний контроль. IP-Adapter (особливо IP-Adapter-FaceID) дозволяє переносити identity персонажа на генерації — це основа для персоналізованого контенту.

Кейс: e-commerce фото-зйомка. Рітейлер з 8000 SKU потребував lifestyle-фото для кожного продукту. Пайплайн: сегментація продукту (Segment Anything Model 2) → видалення фону → inpainting FLUX.1 [dev] з product image як IP-Adapter reference → upscale через RealESRGAN_x4plus. Вартість генерації на орендованих A100 значно нижча порівняно з професійною зйомкою, економія багатократна. Throughput — 200 зображень/год на 2× A100. Багаторічний досвід 30+ проектів гарантує, що ми оберемо оптимальну модель під ваше завдання — оцінку можна отримати на старті.

Чому вибір моделі — лише половина успіху?

Fine-tuning під конкретний стиль або персонаж

Dreambooth і LoRA — стандарт для адаптації під конкретний візуальний стиль або об'єкт. LoRA навчається за 2–4 години на 20–30 референсних зображеннях на одному A100. Rank 16–32 зазвичай достатньо для стилю, rank 64+ потрібен для точного відтворення облич.

Часта помилка: навчати LoRA занадто довго — модель перенавчається на референси, втрачає здатність до варіативності. Ознака: на cfg_scale=7 всі зображення схожі на copy-paste референсу. Лікується ранньою зупинкою (зазвичай 1500–2000 кроків для 20 зображень) та prior_preservation_loss.

Для більш глибокої кастомізації — full fine-tuning через diffusers + accelerate з FSDP на декількох GPU. Але це вже 40–80 годин навчання і потрібен дійсно великий датасет (1000+ зображень).

Порівняння підходів до генерації зображень

Модель Швидкість (1024×1024, A100) Якість (CLIP score) Керованість (ControlNet, IP-Adapter) VRAM (fp16)
Stable Diffusion 3.5 2.0–3.5 с 0.28–0.31 через ControlNet (дозволено) 16–20 GB
FLUX.1 [schnell] 0.8–1.2 с 0.30–0.33 обмежена (без ControlNet) 12–14 GB (4‑кроковий)
FLUX.1 [dev] 3–5 с (50 кроків) 0.32–0.34 через IP-Adapter, ControlNet (адаптер) 24+ GB
Midjourney (API) 5–10 с (черга) 0.31–0.33 промпт + style reference не потрібно

Які моделі кращі для генерації відео?

Модель Доступність Довжина Роздільна здатність Керованість
Sora (OpenAI) API (обмежений) до 60 с 1080p промпт, image-to-video
Wan2.1 (Alibaba) open weights до 81 кадр 720p промпт, I2V, V2V
CogVideoX-5B open weights 6 с 720p промпт, I2V
Kling 1.6 API до 30 с 1080p промпт, I2V
Mochi-1 open weights 5.4 с 480p промпт

Open-weight відеомоделі поки відстають від комерційних за стабільністю та довжиною. Wan2.1 — найкращий вибір для self-hosted: 14B параметрів, працює на 2× A100, дає прийнятну якість для коротких кліпів.

Головний біль відеогенерації — temporal consistency: персонаж змінює колір одягу на третій секунді, об'єкт «пливе». Часткове рішення — генерація з motion_bucket_id і noise_aug_strength в Stable Video Diffusion, або використання I2V (image-to-video) замість чистого text-to-video. Як зазначається в дослідженні VideoPoet, consistency досягається за рахунок навчання на довгих послідовностях.

AnimateDiff залишається робочим інструментом для коротких петель та motion-ефектів поверх SD/FLUX. Не Sora, але деплоїться локально і передбачуваний.

Генерація музики та аудіо

AudioCraft від Meta (MusicGen + AudioGen) — production-готовий стек для музичної генерації. musicgen-large (3.3B) генерує 30 с музики за ~8 с на A100. Керування через текстовий промпт та melody conditioning — можна задати мелодію наспівуванням.

Stable Audio Open від Stability AI — альтернатива з довжиною до 47 с, краща керованість структурою (intro/verse/chorus). Деплой аналогічний: diffusers + FastAPI.

Для voice-over та озвучки — ElevenLabs API або self-hosted XTTS v2 (див. послугу Speech AI). Для sound design та foley — AudioGen.

3D-генерація: практичний стан

3D-генерація все ще не дісталася тієї ж зрілості, що 2D. Але для конкретних задач інструменти вже робочі:

TripoSG та Shap-E — text/image-to-3D. Shap-E від OpenAI генерує прості 3D-меші за секунди, але геометрія грубувата. TripoSG дає більш детальні результати, але потребує постпроцесінгу (ремешинг, UV-розгортка).

Wonder3D та Zero123++ — реконструкція 3D з одного зображення. Працюють через генерацію multi-view (6–8 видів) та подальше 3D-відновлення через NeuS або instant-ngp.

Gaussian Splatting (3DGS) — не генерація, а реконструкція з серії фото/відео. Для товарних карток та нерухомості це вже production: 50–200 фото → 3DGS модель за 15–30 хв на RTX 4090 → інтерактивний 3D-в'ювер в браузері.

Інфраструктура та деплой

Для генеративних моделей критично:

  • Черга задач — Celery + Redis або Ray Serve. Синхронний HTTP для генерації зображень неприйнятний при >5 конкурентних запитах.
  • Кешування — схожі промпти дають схожі результати. Семантичний кеш через ембеддінги (faiss + sentence-transformers) може знизити навантаження на GPU на 20–40%.
  • Моніторинг якості — CLIP score для text-image alignment, FID для оцінки розподілу генерацій. Інтеграція в MLflow або Weights & Biases.
  • Зберігання — згенеровані зображення одразу в S3/MinIO, не на диску сервера інференсу.

Що входить в роботу (deliverables)

Ми беремо проект під ключ — від вибору моделі до деплою та моніторингу. В результат входить:

  • Модель (або API-інтеграція) з бенчмарками продуктивності (latency p99, throughput).
  • Документація пайплайну (prompt engineering guide, model card, версії залежностей).
  • Інтеграція з вашим бекендом (REST/gRPC, черги).
  • Налаштований моніторинг (дашборди, алерти по дрейфу якості).
  • Навчальний воркшоп для команди (2–4 години).
  • Гарантійна підтримка 3 місяці після запуску — в рамках сертифікату якості на нашу роботу.

Історично ми виконали 30+ проектів в генеративному AI — це дає нам право гарантувати результат.

Як будується процес розробки генеративного AI?

  1. Аналітика (1–2 дні): аудит поточної архітектури, уточнення use case, вибір моделей та метрик успіху. Оцінюємо проект безкоштовно.
  2. Proof of Concept (1–3 тижні): швидкий прототип на ваших даних — щоб бачити реальну якість, а не демо з блогу.
  3. Проектування (1–2 тижні): архітектура пайплайну, інфраструктура (GPU-кластер/API), план A/B-тестування.
  4. Реалізація та fine-tuning (4–12 тижнів): розробка, навчання LoRA/full fine-tuning, інтеграція з чергою та кешем.
  5. Тестування (1–2 тижні): навантажувальні тести, валідація метрик, перевірка на edge-case (негативні сценарії).
  6. Деплой та моніторинг (1–2 тижні): розгортання на production, налаштування моніторингу, документування.
Що ми перевіряємо на етапі Proof of Concept
  • Відповідність очікувань та реальної якості генерації (CLIP score, user study).
  • Швидкість інференсу при різних batch_size та типах GPU.
  • Ймовірність токсичних/некоректних генерацій — перевірка safety filters.
  • Можливість масштабування: чи буде модель вивозити пікове навантаження.

Строки орієнтовно

Інтеграція готового API (DALL‑E 3, Midjourney API, Stability API) — 1–2 тижні. Self-hosted пайплайн з fine-tuning — 6–12 тижнів. Повна платформа з UI, чергами та моніторингом — 3–6 місяців. Конкретна вартість розраховується індивідуально після аналізу вашого сценарію.

Зв'яжіться з нами — замовте консультацію, і ми підберемо оптимальну архітектуру для вашого проекту. Отримайте попередню оцінку термінів безкоштовно.