Локальный Hugging Face на NAS: кэширование моделей для AI-рига

Зачем нужен локальный репозиторий моделей на NAS

Загрузка модели Llama-2-70B через интернет со скоростью 100 Мбит/с занимает около 1 часа 40 минут. При повторной инициализации, смене версии или восстановлении после сбоя вы снова ждёте те же 100 минут. Это узкое место, которое разработчики часто игнорируют, оптимизируя инференс или тонкую настройку, хотя реальные потери времени происходят на этапе передачи весов. Ситуация напоминает specification gaming в AI-системах: формально задача решается, но ресурсы расходуются не на то, что действительно важно.

Локальный репозиторий на NAS решает проблему радикально. Модель загружается из интернета один раз, кэшируется на сетевом хранилище и передаётся на AI-риг по локальной сети. При гигабитном подключении та же Llama-2-70B подгружается за 10 минут. При 10GbE - за 1 минуту. Разница в скорости между интернет-загрузкой и передачей с NAS по 10GbE достигает 100-кратного выигрыша на повторных операциях.

Централизованное хранение даёт ещё два преимущества: независимость от доступности Hugging Face Hub и единое управление версиями для всех рабочих станций. Если вы экспериментируете с несколькими моделями и фреймворками, единый кэш на NAS устраняет дублирование десятков гигабайт весов на каждом устройстве.

Архитектура: как связать NAS и AI-риг

Топология проста: AI-риг с GPU и NAS находятся в одной локальной сети, соединённые через коммутатор с поддержкой 10GbE. AI-риг монтирует директорию с моделями как сетевую файловую систему. Никаких прокси-серверов или промежуточных API - прямой доступ к файлам весов и конфигов.

Выбор протокола влияет на производительность. NFS показывает наилучшие результаты для последовательного чтения больших файлов - именно такой паттерн возникает при загрузке safetensors-весов. SMB удобнее для смешанных окружений с Windows-клиентами, но даёт на 15-20% меньшую пропускную способность на тех же дисках. iSCSI предоставляет блочный доступ и может быть быстрее на специализированных массивах, но требует настройки кластерной файловой системы, что избыточно для задачи кэширования. Практический выбор - NFS v4 с jumbo-кадрами (MTU 9000).

Конфигурация монтирования на AI-риге через fstab:

192.168.10.50:/volume1/models /mnt/models nfs4 rw,hard,intr,rsize=1048576,wsize=1048576,timeo=600 0 0

Параметры rsize и wsize в 1 МБ критичны для пропускной способности: значения по умолчанию часто ограничены 64 КБ, что режет скорость в 3-5 раз.

Выбор NAS: готовое решение или самосбор

Для задачи кэширования моделей не нужен enterprise-массив за $5000. Ключевые требования: слот для 10GbE-карты или встроенный порт, поддержка Docker для сервисных контейнеров, минимальный объём 4 ТБ с возможностью расширения. RAID 5 на трёх-четырёх дисках даёт приемлемый баланс отказоустойчивости и полезного объёма. RAID 1 избыточен по стоимости гигабайта, RAID 0 неприемлем из-за риска потери данных.

Готовые варианты: Synology DS923+ с 4 слотами под NVMe-кэш и опциональной 10GbE-картой E10G22-T1-Mini, QNAP TS-464 с двумя портами 2.5GbE и слотом PCIe для апгрейда. Самосбор на TrueNAS SCALE с корпусом Fractal Design Node 304 и материнской платой с интегрированным 10GbE обойдётся на 30-40% дешевле при сопоставимой производительности. Бюджетный сценарий: старый ПК с двухпортовой Mellanox ConnectX-3 за $30 с AliExpress - для кэша моделей хватит с запасом.

Сетевое хранилище моделей нейросетей: настройка NFS

На стороне NAS создаётся общая папка и экспортируется через NFS. Пример для Synology DSM: в File Station создаётся shared folder «models», в настройках NFS-прав указывается IP-адрес AI-рига, опции «rw,async,no_subtree_check,anonuid=0,anongid=0». Параметр async важен: синхронный режим снижает скорость записи в 5-10 раз, а для кэша моделей целостность при внезапном отключении питания некритична - данные всегда можно перекачать.

На AI-риге проверка скорости после монтирования:

# Тест последовательного чтения
dd if=/mnt/models/testfile of=/dev/null bs=1M count=1024
# Тест случайного чтения блоками 4K
fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/mnt/models/fiotest

Ожидаемые результаты на 10GbE: последовательное чтение 800-1100 МБ/с, случайное чтение 4K - 200-300 МБ/с. Модели загружаются последовательно, поэтому именно первый показатель определяет скорость инициализации.

Индексирование и синхронизация с Hugging Face

Ядро системы - скрипт-синхронизатор, который отслеживает изменения в удалённых репозиториях и подтягивает только изменившиеся файлы. Подход «скачать всё» неработоспособен: полное зеркало Hugging Face занимает десятки терабайт. Вместо этого синхронизируются конкретные модели по списку.

Инструментарий: библиотека huggingface_hub с методом snapshot_download, утилита git-lfs для эффективной работы с большими файлами, hf_transfer для ускорения загрузки через многопоточность. Базовый скрипт синхронизации:

from huggingface_hub import snapshot_download, list_repo_files
import json, os, hashlib

MODELS = ["meta-llama/Llama-2-7b-hf", "stabilityai/stable-diffusion-xl-base-1.0"]
CACHE_ROOT = "/mnt/models"

def sync_model(model_id):
    local_path = os.path.join(CACHE_ROOT, model_id)
    snapshot_download(repo_id=model_id, local_dir=local_path,
                      local_dir_use_symlinks=False, resume_download=True)
    
    # Генерация манифеста
    manifest = {"model": model_id, "files": []}
    for root, _, files in os.walk(local_path):
        for f in files:
            fpath = os.path.join(root, f)
            with open(fpath, "rb") as fh:
                sha = hashlib.sha256(fh.read()).hexdigest()
            manifest["files"].append({"path": fpath, "size": os.path.getsize(fpath), "sha256": sha})
    
    with open(os.path.join(local_path, "manifest.json"), "w") as f:
        json.dump(manifest, f, indent=2)

for m in MODELS:
    sync_model(m)

Манифест с SHA256-хешами решает задачу индексирования: перед запуском AI-риг может проверить целостность кэша без повторной загрузки. Это аналог того, как Hugging Face оптимизировал datasets через кеширование списка файлов между воркерами - только на уровне всей модели.

Автоматизация синхронизации через cron и systemd

Скрипт синхронизации запускается ежедневно в 3:00 по cron. Этого достаточно: новые версии моделей выходят не каждый час, а ночная синхронизация не мешает дневной работе. Пример crontab:

0 3 * * * /usr/bin/python3 /opt/scripts/sync_models.py >> /var/log/model_sync.log 2>&1

Для более гибкого расписания - systemd-таймер с рандомизированной задержкой, чтобы не создавать пиковую нагрузку на сеть в крупных командах:

[Timer]
OnCalendar=daily
RandomizedDelaySec=1800
Persistent=true

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /opt/scripts/sync_models.py

Оповещения об ошибках через Telegram-бота: скрипт дёргает Bot API при непустом stderr. Десяток строк на Python с библиотекой requests - и вы узнаете о проблеме раньше, чем она заблокирует работу.

Кэширование моделей AI на NAS: стратегии выбора версий

Структура каталогов на NAS строится по схеме /models/{org}/{model_name}/{revision}/. Revision - это ветка (main, fp16, gguf) или конкретный коммит. Такая иерархия позволяет держать несколько вариантов одной модели и переключаться между ними симлинком:

/models/
  meta-llama/
    Llama-2-7b-hf/
      main/          ← полная копия
      gguf/           ← квантованная версия
      latest -> main/  ← симлинк

Политика хранения: keep last 2 версии для стабильных моделей, keep last 5 для активно разрабатываемых. Очистка старых ревизий - отдельный скрипт, запускаемый раз в неделю. Он проверяет дату последнего обращения через atime и удаляет ревизии, не использовавшиеся более 30 дней. Это предотвращает распухание кэша до состояния «диск забит, непонятно чем».

Интеграция с AI-ригом: ускорение загрузки весов

На AI-риге достаточно выставить переменные окружения, указывающие на смонтированный NAS:

export HF_HOME=/mnt/models/hf_cache
export TRANSFORMERS_CACHE=/mnt/models/transformers
export DIFFUSERS_CACHE=/mnt/models/diffusers

Фреймворки Hugging Face автоматически подхватывают эти переменные. PyTorch-загрузка через from_pretrained() сначала проверяет локальный кэш, и только при отсутствии модели обращается к HF Hub. Для Diffusers тот же механизм работает с StableDiffusionPipeline.from_pretrained().

Нюанс: библиотека huggingface_hub v1.0 перешла на HTTP/Xet протокол, что изменило поведение кэширования. Детальный разбор архитектурного сдвига показывает, что новые версии эффективнее работают с частичными загрузками, но требуют обновления скриптов синхронизации - старые методы могут не подхватывать Xet-блоки.

Бенчмарки: скорость загрузки модели с NAS vs Hugging Face Hub

Тестовый стенд: AI-риг с RTX 4090, 64 ГБ RAM, Ubuntu 22.04. NAS: Synology DS923+ с 4x Seagate IronWolf Pro 8 ТБ в RAID 5, 10GbE через E10G22-T1-Mini. Интернет: 100 Мбит/с оптоволокно. Измерялось время от вызова from_pretrained() до готовности модели к инференсу.

Холодный кэш на NAS (первая загрузка) занимает столько же времени, сколько прямая загрузка из интернета - данные физически проходят через интернет-канал. Горячий кэш даёт кратный выигрыш на всех моделях. Для рабочих процессов с частой сменой версий или экспериментов на нескольких машинах экономия времени становится критической.

Безопасность и управление доступом

NFS-шара ограничивается по IP на уровне экспорта: только AI-риг и рабочая станция администратора имеют доступ. В многомашинных сетапах используется отдельный VLAN для AI-трафика - это изолирует интенсивный сетевой обмен от основного офисного трафика и предотвращает случайный доступ.

Для сценариев, где модели содержат проприетарные доработки, между NAS и AI-ригом поднимается WireGuard-туннель с шифрованием. Накладные расходы на 10GbE: падение пропускной способности до 6-7 Гбит/с из-за CPU-bound шифрования. Приемлемо, если конфиденциальность критичнее скорости.

Аудит доступа ведётся через стандартные логи NFS-сервера. На Synology они доступны в Log Center с фильтрацией по IP клиента. Для TrueNAS - /var/log/messages с grep по mountd. Этого достаточно, чтобы отследить, кто и когда обращался к конкретной модели.

Заключение: ваш персональный Hugging Face всегда под рукой

Локальный кэш моделей на NAS даёт три измеримых результата: 70-100x ускорение повторных загрузок, полную независимость от доступности Hugging Face Hub и единое управление версиями для всей команды. Затраты на реализацию - от $300 за самосборный NAS с 10GbE до $1000 за готовое решение с гарантией. Окупаемость наступает после первой же недели активной работы с моделями уровня 70B.

Развитие идеи: проксирование запросов к HF Hub через NAS с прозрачным кэшированием, распределённый кэш для географически разнесённых команд через Syncthing, интеграция с CI/CD-пайплайнами для автоматического тестирования новых версий моделей. Базовый сетап, описанный в статье, закрывает 90% потребностей и собирается за вечер. Остальное - оптимизации под конкретный воркфлоу.

Подписаться на канал