Інфраструктура версіонування моделей: управління ML-артефактами у масштабі

Оновлено 11 грудня 2025 року

Оновлення грудня 2025: MLflow 3.0 розширює реєстр для генеративного ШІ та ШІ-агентів — з'єднуючи моделі з версіями коду, промптами, запусками оцінювання та метаданими розгортання. Версіонування моделей тепер відстежує не лише ваги, але й дофайнтюнені адаптери, шаблони промптів та конфігурації отримання даних. LLM з вагами у сотні ГБ потребують спеціалізованої інфраструктури, що виходить за межі Git.

MLflow 3.0 розширив свій реєстр моделей для роботи з генеративними ШІ-додатками та ШІ-агентами, з'єднуючи моделі з точними версіями коду, конфігураціями промптів, запусками оцінювання та метаданими розгортання.¹ Ця еволюція відображає фундаментальний зсув у розумінні того, що означає «версіонування моделей» — від відстеження простих pickle-файлів до управління складними системами з багатьма дофайнтюненими адаптерами, шаблонами промптів та конфігураціями отримання даних. Організаціям, що експлуатують production-системи ШІ, потрібна інфраструктура, яка версіонує не лише ваги, але й весь контекст, необхідний для надійного відтворення та розгортання моделей.

На відміну від традиційного версіонування програмного забезпечення, версіонування ML-моделей передбачає відстеження масивних бінарних файлів, складних конфігурацій навчання, версій датасетів та метрик оцінювання — і все це при дотриманні вимог відтворюваності та відповідності стандартам.² Виклик ускладнюється для LLM, де дофайнтюнені моделі стрімко розмножуються, а prompt engineering додає ще один шар артефактів, що потребують контролю версій.

Чому версіонування моделей має значення

Production ML-системи виходять з ладу непомітно. Моделі деградують з часом, дофайнтюнені версії несподівано показують гірші результати, і без належного версіонування команди не можуть визначити, що змінилося, або відкотитися до перевіреного стабільного стану.

Виклик версіонування

Бінарні артефакти: Ваги моделей варіюються від мегабайтів для класичного ML до сотень гігабайтів для великих мовних моделей. Git не може ефективно працювати з такими файлами; спеціалізована інфраструктура стає необхідною.

Вибух конфігурацій: Одна модель включає код навчання, гіперпараметри, попередню обробку даних, feature engineering та конфігурацію розгортання. Будь-яка зміна потенційно впливає на поведінку моделі.

Залежність від датасету: Якість моделі залежить від даних для навчання. Без версіонування датасетів відтворення моделі стає неможливим навіть при ідентичному коді.

Зв'язок з оцінюванням: Метрики продуктивності на конкретних тестових наборах визначають рішення про розгортання. Ці метрики мають бути постійно пов'язані з версіями моделей.

Бізнес-вимоги

Відтворюваність: Регуляторні вимоги у фінансах та охороні здоров'я вимагають можливості відтворити точні версії моделей, розгорнутих у будь-який момент часу.³

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

Можливість відкату: Інциденти у production вимагають повернення до попередніх версій моделей за хвилини, а не години.

Співпраця: Декільком data scientist'ам, що працюють над однією моделлю, потрібне чітке визначення власності та вирішення конфліктів для артефактів моделей.

Архітектура реєстру моделей

Реєстр моделей слугує центральним репозиторієм, що управляє життєвим циклом ML-моделей від розробки до production:⁴

Основні компоненти

Контроль версій: Кожна версія моделі отримує унікальний ідентифікатор, зазвичай поєднуючи назву моделі із семантичною версією (v1.2.3) або ідентифікаторами на основі хешу.

Сховище метаданих: Параметри навчання, метрики оцінювання, походження даних та історія розгортання зберігаються разом з артефактами моделі.

Сховище артефактів: Ваги моделі, файли конфігурації та пов'язані ресурси зберігаються у масштабованому об'єктному сховищі (S3, GCS, Azure Blob).

Управління життєвим циклом: Моделі проходять через етапи — розробка, staging, production, архів — з контролем управління на кожному переході.

Робочий процес реєстру

Завдання навчання → Реєстрація моделі → Перевірка у staging → Розгортання у production
        ↓                  ↓                    ↓                       ↓
    Метрики           ID версії            Погодження           Маршрутизація
   записуються       генерується           записуються           трафіку
                                                                моніториться

Реєстрація: Пайплайни навчання автоматично реєструють успішні моделі з пов'язаними метаданими: - ID запуску навчання та контекст експерименту - Гіперпараметри та конфігурація - Метрики оцінювання на відкладених даних - Посилання на версію даних - Хеш коміту коду

Staging: Моделі-кандидати проходять валідацію перед production: - Автоматизоване тестування проти бенчмарків - Людська перевірка для чутливих застосунків - A/B тестування проти поточної production-моделі - Профілювання продуктивності для затримки інференсу

Просування: Погоджені моделі розгортаються у production: - Трафік поступово перемикається на нову версію - Моніторинг виявляє деградацію - Відкат запускається при погіршенні метрик

Порівняння платформ

MLflow

MLflow надає найбільш комплексний open-source реєстр моделей:⁵

Функції Model Registry: - Централізоване сховище моделей з версіонуванням та псевдонімами - Відстеження походження (experiment → run → model) - Переходи етапів (Staging, Production, Archived) - Анотації та тегування метаданих - REST API для програмного доступу

Покращення MLflow 3.0: - Сутність LoggedModel з'єднує моделі з кодом, промптами та оцінюванням - Покращене трасування для генеративних ШІ-додатків - Підтримка агентів для складних ШІ-систем - Databricks надає керовану enterprise-версію

Приклад робочого процесу:

import mlflow

# Логування моделі під час навчання
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 0.001, "epochs": 10})
    mlflow.log_metrics({"accuracy": 0.95, "f1": 0.92})
    mlflow.pyfunc.log_model("model", python_model=trained_model)

# Реєстрація в реєстрі моделей
model_uri = f"runs:/{run_id}/model"
mlflow.register_model(model_uri, "fraud-detection-model")

# Просування до production
client = mlflow.tracking.MlflowClient()
client.transition_model_version_stage(
    name="fraud-detection-model",
    version=3,
    stage="Production"
)

Найкраще для: Організацій, що хочуть комплексні MLOps-можливості з гнучкістю open-source.

Weights & Biases

W&B робить акцент на відстеженні експериментів із сильним версіонуванням артефактів:⁶

Ключові можливості: - Відстеження експериментів з багатою візуалізацією - Версіонування артефактів з графами походження - Реєстр моделей з псевдонімами (@champion, @production) - Функції співпраці для командних робочих процесів - Інтеграція з основними ML-фреймворками

Версіонування артефактів:

import wandb

run = wandb.init(project="nlp-models")

# Логування моделі як артефакту
artifact = wandb.Artifact("bert-classifier", type="model")
artifact.add_file("model.pt")
run.log_artifact(artifact)

# Прив'язка до реєстру з псевдонімом
run.link_artifact(artifact, "model-registry/bert-classifier",
                  aliases=["latest", "production"])

Застереження: Cloud-first архітектура вимагає надсилання даних на зовнішні сервери, що може конфліктувати зі строгими вимогами конфіденційності даних.

Найкраще для: Команд, що надають пріоритет відстеженню експериментів та співпраці з мінімальними накладними витратами на налаштування.

DVC (Data Version Control)

DVC розширює Git для великих файлів та датасетів:⁷

Архітектура: - Git-подібні команди (dvc add, dvc push, dvc pull) - Файли метаданих відстежуються у Git, великі файли — у віддаленому сховищі - Визначення пайплайнів для відтворюваних експериментів - Кілька бекендів сховищ (S3, GCS, Azure, SSH)

Нещодавній розвиток: DVC приєднався до сім'ї lakeFS, де lakeFS слугує enterprise-стандартом для версіонування даних петабайтного масштабу.

Приклад робочого процесу:

# Додавання великого файлу моделі до DVC
dvc add models/bert-finetuned.pt

# Коміт метаданих у Git
git add models/bert-finetuned.pt.dvc .gitignore
git commit -m "Add fine-tuned BERT model v1.0"

# Push до віддаленого сховища
dvc push

# Відтворення з будь-якого коміту
git checkout v1.0
dvc checkout

Найкраще для: Команд з існуючими Git-робочими процесами, що хочуть легковагове версіонування даних та моделей.

Cloud-native реєстри

Vertex AI Model Registry (Google Cloud):⁸ - Нативна інтеграція з GCP - Пряме розгортання на endpoints - Автоматичне відстеження походження - Інтеграція з Vertex AI Pipelines

Amazon SageMaker Model Registry: - Інтеграція з екосистемою AWS - Робочі процеси погодження - Спільне використання моделей між акаунтами - Інтеграція з SageMaker Pipelines

Azure ML Model Registry: - Інтеграція з Azure - Сумісність з MLflow - Розгортання на керовані endpoints

Найкраще для: Організацій, прив'язаних до конкретних хмарних провайдерів, що хочуть нативну інтеграцію.

Особливості для LLM

Великі мовні моделі представляють унікальні виклики версіонування, що виходять за межі традиційного ML:⁹

Що версіонувати

Базові моделі: Відстежуйте, яка foundation-модель (Llama 3.1-8B, GPT-4, Claude) слугує відправною точкою.

Дофайнтюнені ваги: Повний fine-tuning створює повністю нові файли ваг; LoRA-адаптери створюють невеликі дельта-файли з посиланням на базові моделі.

Шаблони промптів: System prompts, few-shot приклади та формати інструкцій суттєво впливають на поведінку моделі.

Конфігурації отримання даних: RAG-системи вимагають версіонування моделей ембедингів, стратегій розбиття на чанки та параметрів отримання.

Семантичне версіонування для LLM

Застосовуйте семантичне версіонування для комунікації значущості змін:¹⁰

Мажорна версія (v2.0.0): - Інша базова модель - Зміни архітектури - Breaking-зміни API

Мінорна версія (v1.3.0): - Fine-tuning на нових даних - Суттєві покращення продуктивності - Додані нові можливості

Патч-версія (v1.2.1): - Виправлення помилок - Незначні оптимізації - Оновлення конфігурації

Управління адаптерами

LoRA та QLoRA створюють файли адаптерів, що множаться та потребують систематичної організації:

base-model/
├── llama-3.1-8b/
│   └── v1.0.0/
│       ├── weights/
│       └── config.json
└── adapters/
    ├── customer-support-v1/
    │   ├── adapter_model.bin
    │   └── adapter_config.json
    ├── code-generation-v2/
    └── summarization-v1/

Стратегія версіонування адаптерів: - Версіонуйте адаптери незалежно від базових моделей - Документуйте сумісні версії базових моделей - Відстежуйте дані навчання та гіперпараметри для кожного адаптера - Забезпечте швидке перемикання між адаптерами при обслуговуванні

Стратегії розгортання

Canary-розгортання

Направляйте невеликий відсоток трафіку на нову версію моделі перед повним розгортанням:¹¹

# Конфігурація canary для Kubernetes
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: model-service
        subset: v1
      weight: 90
    - destination:
        host: model-service
        subset: v2
      weight: 10

Процес: 1. Розгорніть нову версію поруч з production 2. Направте 5-10% трафіку на нову версію 3. Моніторте метрики (затримка, частота помилок, бізнес-метрики) 4. Поступово збільшуйте трафік, якщо метрики тримаються 5. Завершіть розгортання або відкотіться на основі результатів

Інструменти: Istio, Argo Rollouts та Flagger автоматизують прогресивну доставку з автоматичним відкатом при погіршенні метрик.

A/B тестування

Порівнюйте версії моделей для вимірювання бізнес-впливу:¹²

Ключові відмінності від canary: - Canary виявляє проблеми (хвилини-години) - A/B тестування вимірює вплив (дні-тижні) - Для висновків A/B потрібна статистична значущість

Імплементація: - Хешуйте ID користувачів для консистентної маршрутизації - Відстежуйте метрики конверсії для кожного варіанту - Запускайте до досягнення статистичної значущості - Документуйте результати для майбутніх референсів

Shadow-розгортання

Направляйте production-трафік на нову модель без обслуговування відповідей:

Переваги: - Тестування з реальними патернами трафіку - Порівняння результатів без впливу на користувачів - Виявлення edge cases до розгортання

Імплементація: - Production-модель обслуговує відповіді - Shadow-модель обробляє ті ж запити - Результати порівнюються, але не повертаються користувачам - Розбіжності ініціюють розслідування

Процедури відкату

Кожне розгортання потребує можливості відкату:

Негайний відкат:

# Відкат маршрутизації трафіку
kubectl set image deployment/model-service model=model:v1.2.0

# Відкат через feature flag
feature_flags.disable("new_model_v2")

Відкат на основі реєстру: ```py

[Content truncated for translation]