Проблема

Где сейчас лежат ваши модели

Без реестра веса расходятся по рабочим машинам, сетевым папкам и внешним площадкам. Вопрос «какая версия работает в продакшене и откуда она взялась» становится расследованием.

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

01 Повторные загрузки. Одна и та же модель приезжает из интернета столько раз, сколько в компании команд, и каждый раз занимает внешний канал.
02 Нет ответа аудитору. Показать, кто получал доступ к весам и обучающим данным, нечем - журнала нет.
03 Незаменимый человек. Что именно стоит в продакшене, знает автор модели; увольнение автора - потеря знания.
04 Зависимость от внешней площадки. Условия доступа меняются не вами, а работа команд встает.

Результат

Что меняется после внедрения

a Единый стандарт хранения Все модели и датасеты компании живут в одном реестре - с версиями, владельцами, тегами и метками классификации. Всегда понятно, где актуальная версия и кто за нее отвечает. Структурированное хранение вместо копий по машинам

b Все внутри вашего контура Веса и обучающие наборы остаются в инфраструктуре компании, доступ выдается по роли. Внешний доступ не требуется ни для работы, ни для выдачи модели в продакшен. Работа команд не зависит от внешних площадок

c Полная прослеживаемость За каждой версией закреплен автор, состав файлов и контрольные суммы, каждое действие попадает в журнал. Релизная метка неизменяема - в продакшен едут ровно те файлы, что были помечены. Есть что показать безопасности и аудиторам

d Готово к работе команд Привычные клиенты видят ваш реестр после смены одного адреса. Переучивать людей и переписывать код не нужно. Внедрение не останавливает работу команд

Кому

Что получает каждая сторона

Безопасность и аудит

Артефакты не покидают контур: наружу ходит один узел, в изолированной сети - ни одного
По каждой версии видно, откуда она пришла, кто выложил и когда
Права до отдельного репозитория, неизменяемые релизные метки, SHA-256 на каждый файл
Журнал входов, выдачи доступов и скачиваний с выгрузкой в мониторинг

ИТ и эксплуатация

Повторная загрузка идет из сети компании, внешний канал не нагружается
Два уровня хранения: быстрый диск под горячее, объектное хранилище под холодное
Несколько экземпляров приложения на одной базе; лицензия на контур, а не на узлы
Установка контейнером, системной службой или в кластере

ML-команды

Привычные клиенты работают после смены одного адреса
Модель живет как репозиторий: ветки, метки, история, откат из интерфейса
Большие веса и докачка с места разрыва - без ручных обходных решений
Готовый пример кода под конкретный клиент в карточке репозитория

Сценарии

Где применяется

a Сеть без выхода в интернет Команды работают привычными инструментами: модели и датасеты берутся из реестра, установленного рядом.

b Требования службы безопасности Регламент требует хранить веса и наборы данных внутри организации и показывать, кто получал к ним доступ.

c Шлюз в интернет с ограничениями Внешняя модель заводится зеркалом один раз, дальше раздается из реестра всем командам по расписанию синхронизации.

d Происхождение артефактов Видно, какая ревизия стоит на узлах инференса, зеркало это или локальная разработка, кто ее выложил.

Как это работает

Путь модели - от каталога до продакшена

Через AI-Vault проходят шаги, где модель берут, выкладывают и помечают релизной версией. Обучение остается там, где оно у вас уже есть.

Пунктиром отмечен шаг, который выполняется вашими средствами: обучение идет на ваших видеокартах, реестр в него не вмешивается.

01 Взял модель из каталога или зеркала - через интерфейс либо привычный клиент
02 Обучил на своих данных и своих видеокартах, в вашей же ML-среде
03 Выложил версию новые веса уходят в тот же репозиторий, состав файлов фиксируется
04 Пометил релиз метка закрепляется за версией и не переписывается
05 Вывел в продакшен сервер инференса забирает помеченную ревизию из реестра

Контур

Наружу выходит один узел

Внешняя сеть нужна только для первичного наполнения зеркал, и обращается к ней единственный узел. В сети без интернета он не нужен вовсе.

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

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

Зеркало Выбранные репозитории копируются целиком по расписанию. После прохода внешний доступ не нужен.

Запись о каждом проходе Источник, размер, контрольная сумма и инициатор фиксируются на каждую синхронизацию.

Связь с внешними хабами - отдельный модуль, в базовую лицензию не входит

Контроль

Доступ, журнал и отчетность

a Права до отдельного репозитория Четыре системные роли и свои роли компании. Изоляция подразделений, группы ресурсов, матрица разрешений.

b Журнал событий и действий Кто вошел, кто выдал доступ, кто что забрал. Фильтры по периоду и человеку, выгрузка в мониторинг. Отдельный модуль.

c Ключи с ограниченным сроком У ключа свой набор прав и свой срок, его задает компания. Разовому заданию сборки ключ обменивается на короткоживущий - от одной минуты до суток.

d Единый вход: LDAP и OIDC Учетные записи берутся из корпоративного каталога, второй фактор - одноразовый код. Отдельный модуль: в базовой поставке учетные записи заводятся в самом реестре.

e Статистика потребления Скачивания, трафик и занятое место в разрезе пользователей и команд. По ней разносятся расходы и считается запас емкости.

f Происхождение видно в списке Зеркало или локальная разработка - метка ставится автоматически. Рядом лицензия самой модели.

Облачный хаб и свой контур

Критерий

Облачный хаб

AI-Vault в контуре

Где лежат артефакты

на внешней площадке

на серверах организации

Работа без интернета

невозможна

штатный режим

Условия доступа

меняются внешней стороной

определяются вами

Журнал использования

ограничен платформой

полный, с выгрузкой

Сравнение по классу решений, без названий конкретных площадок.

Внедрение

Варианты установки

01 Kubernetes Поставляется обычный контейнер OCI - разворачивается манифестами кластера. Обновление и откат - штатными средствами кластера.

02 Установка на ОС Установка по документированной инструкции, запуск системной службой systemd.

03 Docker Compose Установка из двух сервисов - приложение и PostgreSQL. Самый быстрый способ поднять и посмотреть.

Требования к инфраструктуре

Хранилище артефактов главный параметр; считается от числа артефактов, их версий и размера весов. Минимально - локальный диск сервера; объектное хранилище берется по объему данных и подключается отдельным модулем

Сервер приложений минимально 8 vCPU и 32 ГБ памяти, рекомендуется 16 vCPU и 64 ГБ

Диск сервера минимально 200 ГБ SSD, рекомендуется 500 ГБ NVMe. Под систему, базу и журналы - артефакты сюда не считаются

Сеть минимально от 100 Мбит/с, рекомендуется от 1 Гбит/с. Определяет скорость раздачи; внешний канал для первичной загрузки считается отдельно

База данных PostgreSQL; видеокарты для работы реестра не нужны

Размер артефакта ограничения на размер одного артефакта нет

Что двигает требования вверх число версий, размер артефактов, одновременность загрузок, сроки хранения и требования к резервированию

Техническая часть

Подробности для инженеров

Разделы свернуты: открывайте то, что нужно вашей команде.

Совместимость: меняется один адрес

// переключение окружения на свой реестр

$ export HF_ENDPOINT=https://ai-vault.example.com/v1

$ huggingface-cli download acme/llama-3-8b

→ Fetching 12 files: 100%

// отдача потоком и докачка с места разрыва

$ curl -sI -r 0-1023 $M/resolve/main/w.bin

→ HTTP/1.1 206 Partial Content

Адрес transformers, huggingface_hub, huggingface-cli, vLLM, LangGraph, Langflow и Ollama видят реестр после смены HF_ENDPOINT

Два протокола репозиторий доступен и по протоколу Hugging Face, и по git - это один и тот же артефакт, а не две копии

Отдача файлов потоком на клиента; целиком в память сервера файл не собирается

Докачка частичные запросы поддержаны: прерванная загрузка продолжается с места разрыва

Готовый сниппет в карточке репозитория вкладка «Примеры использования» - код под конкретный клиент

Модель как обычный репозиторий: git, LFS, неизменяемые метки

// модель как обычный репозиторий

$ git clone $V/git/acme/llama-3-8b.git

$ git add model.safetensors && git commit -m v2

$ git push origin main

→ Uploading LFS objects: 100% (1/1)

→ ревизия зафиксирована, указатель обновлен

// релизная метка закреплена за коммитом

$ git push origin v1.0

→ rejected: tag is immutable

Большие файлы через Git LFS Весовые файлы уходят по LFS; правила ставятся при создании репозитория.

Релизная метка неизменяема Тег закреплен за коммитом и не переписывается. В продакшен едут те же файлы, что были помечены.

Ревизия фиксируется на push Сервер записывает состав файлов и хеши. При ошибке загрузка отклоняется целиком.

Реестр: ревизии, хеши и пины

Типы репозиториев модели и датасеты: общий движок хранения, свои маршруты API и разделы интерфейса

Ревизии за каждой ревизией закреплен коммит; откат - в карточке репозитория, вкладка «История коммитов»

Целостность SHA-256 на каждый файл ревизии; по нему же файл адресуется в хранилище

Пины имя пина закрепляется за конкретным коммитом; тег в реестре неизменяем

Происхождение зеркало или локальная разработка - тег source:mirror либо source:local ставится автоматически; лицензия самой модели - тег license:*

Двухуровневое хранилище: быстрый диск и объектное хранилище

Объектное хранилище подключается отдельным модулем. Без него система работает на локальном диске.

Уровни базовая конфигурация - локальный диск; хранение в S3 подключается отдельным модулем: объектное хранилище становится источником истины, локальный слой - кэшем

Чтение если файла нет на быстром диске, он отдается из объектного хранилища и попутно кладется на диск

Репликация асинхронная, очередью заданий; повтор с нарастающим интервалом, состояние хранится на каждый файл

Запись при нехватке места три режима: сначала на локальный диск, напрямую в объектное хранилище или через буфер

Интерфейс: каталог, карточка, версии, зеркала

Каталог модели и датасеты вместе: поиск по названию и описанию, фильтры по источнику, видимости и тегам

Карточка модели описание, метки, автор и размер на одном экране; рядом файлы, версии, история и примеры использования

Версии и история история по ветке, именованный пин релизной версии, откат на предыдущую ревизию из списка

Зеркала расписание, состояние синхронизации, занятое место и разрешенные префиксы имен

Развитие

Что добавляется к реестру

Три направления в разработке. Каждое опирается на тот же реестр и работает в том же контуре.

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

b Запуск моделей Версия поднимается прямо из реестра, платформа выдает адрес для обращений. Новая версия запускается рядом с текущей, переключение и откат - одно действие.

c Пул видеокарт Машины с GPU собираются в общий ресурс поверх Kubernetes, включая k3s на небольших площадках. Видно загрузку, очередь задач и потребление по командам.

Дорожная карта - ai-vault.ru/roadmap

Регистрация

Свидетельство о государственной регистрации программы для ЭВМ AI-Vault № 2026684209 от 10 августа 2026 года, Роспатент. Правообладатель - ООО «ФОКСОПС», собственная разработка.

Права, поддержка и реквизиты

AI-Vault - дом для AI-моделей