Перейти к основному содержимому

Критический анализ стратегий доступа к данным (Data Access Strategy)

1. Контекст задачи​

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

  1. Single-Node / Single-GPU: 1 модель, локальный запуск.
  2. Multi-Node / Multi-GPU (Cluster): 8+ контейнеров параллельно обрабатывают один датасет.

2. Анализ вариантов​

Вариант А: Локальная файловая система (Volume Mounts)​

Классический подход для Docker/HPC.

  • Механизм: Монтирование папки с датасетом (-v /host/data:/container/data) во все контейнеры.
  • Плюсы:
    • Максимальная скорость чтения (NVMe/SSD).
    • Нулевой оверхед на сеть.
    • Простота реализации для Single-Node.
  • Минусы:
    • Сложность масштабирования на кластер (требуется NFS/Ceph/GlusterFS).
    • Проблемы с блокировками при одновременной записи (хотя для чтения ок).

Вариант Б: S3 + Message Broker (Pull-based)​

Архитектура "Очередь задач".

  • Механизм:
    • Оркестратор кладет задачи (URL на S3 + промпт) в очередь (RabbitMQ/Redis).
    • Воркеры (контейнеры) читают очередь, скачивают картинку из S3, процессит.
  • Плюсы:
    • Идеальная масштабируемость.
    • Отказоустойчивость (если воркер упал, задача вернется в очередь).
    • S3 — стандарт де-факто для хранения блобов.
  • Минусы:
    • Network Overhead: Постоянное скачивание картинок каждым воркером.
    • Latency: Задержки на взаимодействие с брокером и S3.
    • Сложность инфраструктуры (нужно поднимать MinIO + RabbitMQ).

Вариант В: API-based (Push-based / HTTP)​

Воркеры как сервисы.

  • Механизм:
    • Воркеры поднимают HTTP API (например, vLLM server).
    • Оркестратор шлет запросы с URL картинки (S3) и текстом.
  • Плюсы:
    • Использование готовых решений (vLLM, SGLang уже имеют API).
    • Простота интеграции.
  • Минусы:
    • Оркестратор становится узким местом (должен менеджить нагрузку).
    • Те же проблемы с Network Overhead, что и в Варианте Б.

3. Критика и Рекомендация​

Проблема S3 в High-Performance Inference: Для задач OCR/VQA картинки могут быть тяжелыми. Если 8 GPU будут одновременно тянуть данные из S3 по сети, мы можем упереться в пропускную способность сети, и GPU будут простаивать (IO-bound).

Гибридное решение (Рекомендация):

  1. Для Single-Node (Локально): Использовать Volume Mounts (Bind Mount). Это быстрее и проще всего. Нет смысла поднимать S3 локально ради 1 машины.

  2. Для Cluster (Multi-Node): Использовать S3 + Caching.

    • Воркеры получают ссылки на S3.
    • Важно: Реализовать локальное кэширование на узле воркера. Если несколько воркеров на одной ноде обрабатывают один датасет, они должны читать с диска, а не тянуть из S3 каждый раз.
    • Или использовать Shared File System (NFS) если сеть позволяет (10GbE+).

4. Стратегия удаленного доступа (Remote Access)​

Для удаленных воркеров (RunPod, Cluster) возникает проблема доставки данных.

Вариант 1: Прямой доступ к S3 (Streaming)​

Воркеры получают URL (presigned) и скачивают картинки "на лету" во время инференса.

  • Плюс: Не нужно предварительно скачивать весь датасет.
  • Минус: Высокая нагрузка на сеть, задержки при каждом запросе.

Вариант 2: Предварительная загрузка (Pre-download / Sync)​

Перед запуском задачи EnvManager скачивает нужный кусок датасета (или весь) на локальный диск воркера.

  • Механизм: rclone / aws s3 sync в начале жизненного цикла задачи.
  • Плюс: Локальное чтение во время инференса (быстро).
  • Минус: Время старта задачи увеличивается на время скачивания.

Рекомендация: "Smart Sync"​

Использовать S3 как единый источник правды (Single Source of Truth).

  1. Локальный запуск: EnvManager проверяет наличие данных в локальном кэше. Если нет — скачивает из S3. Монтирует папку в контейнер.
  2. Удаленный запуск: EnvManager (на удаленной машине) синхронизирует нужный датасет из S3 в локальное хранилище пода/узла перед запуском контейнера.

Вердикт для Прототипа: Реализовать абстракцию DatasetProvider с поддержкой S3.

  • Все датасеты хранятся в S3-совместимом хранилище (MinIO локально или AWS/Cloud в продакшене).
  • Воркеры (локальные и удаленные) используют стратегию Sync-before-Run: сначала синхронизируют данные, потом запускают инференс с локального диска. Это обеспечивает единство архитектуры и высокую производительность инференса.