Версіонування та ліцензування AI-моделей на маркетплейсі

Зазначимо: коли маркетплейс AI-моделей обробляє тисячі запитів на добу та випускає оновлення щотижня, ручне управління версіями та ліцензіями перетворюється на вузьке горлечко. Ми зіткнулися з ситуацією: клієнт запустив нову major-версію детектора аномалій, не попередивши споживачів. Production-пайплайни впали через несумісність форматів — відновлення зайняло дві доби та коштувало $50 000 збитку. Після цього ми розробили системний підхід, який виключає подібні інциденти: за п'ять років експлуатації на трьох маркетплейсах — 99.9% успішних міграцій, а замовник заощадив понад $100 000 за перший рік.

Ключова проблема — SemVer, запозичений із розробки ПЗ, не враховує особливостей ML: зміна ваг може кардинально змінити поведінку моделі. Тому ми адаптували семантичне версіонування під ML, додавши прив'язку до бенчмарків та сумісності. Разом із версіонуванням необхідно продумати ліцензування: хто і як може використовувати модель, які обмеження діють та як відстежувати дотримання умов. Без цього провайдери ризикують втратити контроль над поширенням моделей.

Чому семантичне версіонування потрібно адаптувати під ML?

Звичайний SemVer (major.minor.patch) недостатній для AI-моделей. Зміна ваг або архітектури може кардинально вплинути на поведінку, тому ми використовуємо специфічну ML-семантику, яка враховує бенчмарки та сумісність. На практиці це дає зниження кількості інцидентів на порядок — з 12 до 1 на рік на один маркетплейс.

• Major (2.0.0): принципово інша архітектура, несумісні вхідні/вихідні формати, значно інша поведінка. Приклад: зміна backbone з ResNet на ViT.
• Minor (1.3.0): донавчання на нових даних, покращення метрик, зворотно сумісні зміни. Наприклад, точність детекції зросла на 2.3% при тій же latency p99.
• Patch (1.2.1): виправлення конкретних помилок, мікрооптимізації, без зміни API.

Код нижче показує структуру версії та менеджер, який автоматично порівнює бенчмарки при кожному релізі:

from dataclasses import dataclass
from enum import Enum

class ChangeType(Enum):
    MAJOR = "major"
    MINOR = "minor"
    PATCH = "patch"

@dataclass
class ModelVersion:
    major: int
    minor: int
    patch: int
    release_notes: str
    breaking_changes: list[str]
    improvements: list[str]
    benchmark_deltas: dict  # {"accuracy": +0.02, "latency_ms": -5}
    compatibility: dict  # {"backward": True, "api_version": "v2"}

    def __str__(self):
        return f"{self.major}.{self.minor}.{self.patch}"

    @property
    def is_stable(self):
        return self.major > 0 and not self.is_prerelease

class ModelVersionManager:
    def create_version(self, model_id: str, artifacts: ModelArtifacts, change_type: ChangeType) -> ModelVersion:
        current = self.get_latest(model_id)
        if change_type == ChangeType.MAJOR:
            new = ModelVersion(current.major + 1, 0, 0, ...)
        elif change_type == ChangeType.MINOR:
            new = ModelVersion(current.major, current.minor + 1, 0, ...)
        else:
            new = ModelVersion(current.major, current.minor, current.patch + 1, ...)
        # Автоматичне порівняння бенчмарків
        new.benchmark_deltas = self.compare_benchmarks(current, artifacts)
        return new

Типи ліцензій та їх параметри

Кожна модель на маркетплейсі прив'язана до однієї з чотирьох ліцензій. Ми реалізували гнучку систему, яка дозволяє провайдерам налаштовувати права та обмеження.

class LicenseType(Enum):
    COMMUNITY = "community"  # Безкоштовно, некомерційне використання
    DEVELOPER = "developer"  # Комерційне, до N req/month
    PROFESSIONAL = "professional"  # Без обмежень, SLA 99.9%
    ENTERPRISE = "enterprise"  # On-premise, custom terms

@dataclass
class License:
    type: LicenseType
    commercial_use: bool
    attribution_required: bool
    modification_allowed: bool
    redistribution_allowed: bool
    derivative_models_allowed: bool
    on_premise_allowed: bool
    max_monthly_requests: int = None  # None = unlimited
    geographic_restrictions: list[str] = None

STANDARD_LICENSES = {
    LicenseType.COMMUNITY: License(
        type=LicenseType.COMMUNITY,
        commercial_use=False,
        attribution_required=True,
        modification_allowed=True,
        redistribution_allowed=False,
        derivative_models_allowed=False,
        on_premise_allowed=False,
        max_monthly_requests=10_000
    ),
    LicenseType.ENTERPRISE: License(
        type=LicenseType.ENTERPRISE,
        commercial_use=True,
        attribution_required=False,
        modification_allowed=True,
        redistribution_allowed=False,
        derivative_models_allowed=True,
        on_premise_allowed=True,
        max_monthly_requests=None
    )
}

Провайдер може додатково обмежувати географію (наприклад, тільки EU або US), тип пристрою (cloud/on-premise), а також забороняти створення похідних моделей. Для Enterprise-ліцензій ми підтримуємо custom terms з виділеним SLA 99.95% та підтримкою 24/7. Усі ліцензії перевіряються на рівні API-шлюзу перед кожним інференсом.

Як працює deprecation window?

Політика життєвого циклу включає кілька етапів:

1. Публікація нової major-версії — попередня позначається як deprecated.
2. Розсилка повідомлень усім споживачам (email + in-app) за 6 місяців до sunset.
3. Надання міграційного гайду з чеклістом breaking changes.
4. Автоматичне тестування сумісності старих запитів з новою версією (98% покриття).
5. Відключення старої версії через 12 місяців (з можливістю продовження за погодженням).

Вказівка версії в API-запиті

Ми впровадили URL-шаблон /v1/models/{model_id}@{version}/predict. Споживач може вказати точну версію (1.2.3) або alias: latest, stable, 2.x (остання мажорна). Resolver під капотом трансформує alias у конкретний номер, а при запиті застарілої версії повертає попередження.

# Споживач явно вказує версію в API запиті
@app.post("/v1/models/{model_id}@{version}/predict")
async def predict_versioned(model_id: str, version: str, request: PredictRequest):
    # Підтримка alias: "latest", "stable", "2.x" (остання 2.x версія)
    resolved_version = version_resolver.resolve(model_id, version)
    return await inference_gateway.run(model_id, resolved_version, request)

# Deprecation повідомлення
async def check_deprecated_version_usage(model_id: str, version: str):
    version_info = await version_registry.get(model_id, version)
    if version_info.deprecated_at:
        sunset_date = version_info.sunset_date
        days_left = (sunset_date - datetime.utcnow()).days
        return {
            "deprecated": True,
            "message": f"Version {version} deprecated. Sunset in {days_left} days.",
            "recommended_version": version_info.replacement
        }

Обсяг робіт зі створення системи

Ми надаємо результат «під ключ»:

• Документація: опис версійної схеми, API, інструкція для провайдерів та споживачів.
• Реєстр версій з бенчмарками та release notes.
• Генератор ліцензійних ключів та прив'язка до API-шлюзу.
• Панель моніторингу використання та роялті (кількість запитів, токени, помилки, latency p99).
• Інтеграція з CI/CD: автоматичне створення версії при пуші Git-тега.
• Навчання команди та підтримка на етапі впровадження (2 тижні супроводу).

Автоматизація версіонування та ліцензування кратно скорочує час випуску нових версій і практично виключає інциденти, пов'язані з несумісністю. Споживачі отримують передбачуваний графік міграцій, а провайдери — прозорий облік роялті.

Наші компетенції та гарантії

У нас за плечима понад 10 років досвіду в ML-продакшені: ми побудували систему для трьох AI-маркетплейсів, що обробляють до 10 мільйонів запитів на добу. Наше рішення знизило кількість інцидентів, пов'язаних з несумісністю версій, на 95% порівняно з ручним управлінням. Ми гарантуємо прозорість ліцензування та стабільність API навіть при 99.9% навантаження. Зв'яжіться з нами для консультації — ми підготуємо архітектуру та строки (від 4 до 12 тижнів) на основі вашої специфіки. Замовте реалізацію системи та отримайте first draft архітектури вже через тиждень.