Современная архитектура хранения данных для крупномасштабного ИИ

Введение

В кругах, занимающихся искусственным интеллектом, долгое время господствовал миф о том, что обучение передовых крупномасштабных моделей ИИ — это прерогатива исключительно монолитных, дорогостоящих параллельных файловых систем (PFS), унаследованных от мира высокопроизводительных вычислений (HPC). Однако этот текст призван развеять это заблуждение. Более интеллектуальная, дезагрегированная и экономически выгодная архитектура не просто появилась, а стала новым стандартом для крупнейших в мире «фабрик ИИ».

Центральный тезис этого анализа заключается в том, что объектное хранилище, некогда низведенное до роли «дешевого и глубокого» архива, эволюционировало в единый уровень данных для всего жизненного цикла ИИ. Эта трансформация стала возможной благодаря его оркестрации в тандеме с локальными флеш-накопителями на узлах и передовыми сетевыми технологиями. Современная архитектура целиком и полностью сфокусирована на максимизации утилизации самого дорогого актива — графического процессора (GPU), оптимизируя таким образом общую стоимость владения (TCO) и ускоряя получение ценных результатов. Этот взгляд подтверждается ведущими отраслевыми экспертами, работающими на крупнейших суперкомпьютерах мира, которые утверждают, что массивные параллельные файловые системы не являются обязательным условием для обучения самых современных моделей.

1. Современный конвейер данных ИИ

1.1 Сбор данных

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

• Технический анализ: Традиционные файловые системы плохо подходят для этой задачи. Сканирование иерархии каталогов с миллиардами файлов невероятно медленно. Вместо этого оптимальная архитектура, применяемая гиперскейлерами, реализует контейнеры данных поверх объектного хранилища (такого как Amazon S3, Google Cloud Storage или локальных решений типа Cloudian) и использует распределенное хранилище «ключ-значение» для индекса. Такая конструкция идеально подходит для паттернов однократной записи и многократного чтения (WORM), поскольку устраняет необходимость в дорогостоящих функциях файловых систем, таких как блокировки файлов и операции чтения-модификации-записи. Объектное хранилище обеспечивает фундаментальное «озеро данных» (data lake) с практически неограниченной масштабируемостью и экономической эффективностью.
• Лучшие практики: На этом этапе первостепенное значение имеют принципы хорошо спроектированного озера данных. Данные должны поступать в своем исходном, необработанном формате, чтобы сохранить все потенциальные сигналы. Управление (governance) должно быть внедрено с самого начала, включая надежный контроль доступа, шифрование данных в состоянии покоя и при передаче, а также четкие политики хранения. Использование каталога данных и тегирования объектов становится критически важным для управления и обнаружения активов в озере данных петабайтного масштаба.

1.2 Подготовка и курирование данных

Преобразование необработанных данных в очищенные, токенизированные наборы для обучения — это масштабная задача по анализу данных, а не задача высокопроизводительных вычислений (HPC). Этот этап, интенсивно использующий ввод-вывод, должен быть отделен от дорогостоящего кластера GPU для максимизации эффективности.

• Технический анализ: Этот этап включает конвейеры ETL (Extract, Transform, Load) и обработки данных, часто с использованием фреймворков, таких как Apache Spark. Эти фреймворки спроектированы для эффективной работы с объектными хранилищами, считывая и записывая данные большими последовательными блоками (сотни мегабайт за раз).1 Наиболее экономически эффективная архитектура предполагает использование.
  отдельного, выделенного кластера CPU, расположенного рядом с объектным хранилищем. Это предотвращает простои дорогостоящих GPU в ожидании операций ввода-вывода и позволяет избежать траты их вычислительных циклов на простые задачи обработки текста.1 Результат этого этапа — курированный, токенизированный набор данных — записывается обратно в объектное хранилище, готовый к фазе обучения.

1.3 Обучение модели

Этот подраздел рассматривает наиболее спорный и неправильно понимаемый этап в стеке хранения данных для ИИ, разделяя его на две отдельные проблемы ввода-вывода: чтение данных для обучения и запись контрольных точек (чекпойнтов) модели.

1.3.1 Подача данных

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

• Технический анализ: важной частью современных суперкомпьютеров для ИИ — это использование локальных NVMe SSD-накопителей в каждом узле с GPU.1 В начале процесса обучения весь токенизированный набор данных (который на удивление компактен; например, 60 ТБ датасет для Llama-3 405b может быть реплицирован всего на три узла NVIDIA DGX H100)
  однократно передается из центрального объектного хранилища на локальные NVMe-накопители узлов GPU. Во время обучения каждый GPU считывает свои батчи напрямую с локального SSD. Эта архитектура предоставляет несколько глубоких преимуществ:

1. Устранение сетевых конфликтов: Путь чтения данных ограничен локальной шиной PCIe, что исключает проблему «шумных соседей» и обеспечивает предсказуемый доступ с ультранизкой задержкой.
2. Линейная масштабируемость: Производительность и емкость хранилища идеально масштабируются с количеством GPU. Добавление новых узлов добавляет больше локальной производительности ввода-вывода.
3. Отказоустойчивость: В случае сбоя узла необходимые фрагменты данных могут быть быстро восстановлены с уцелевших соседних узлов через высокоскоростную фабрику RDMA (например, InfiniBand), вместо того чтобы заново считывать их с более медленного общего хранилища. Эту концепцию использования локальных NVMe как высокопроизводительного, неразделяемого, но глобально доступного уровня некоторые производители называют хранилищем «Уровня 0» (Tier 0).

1.3.2 Архитектура для отказоустойчивости с многоуровневым асинхронным созданием чекпойнтов

При масштабе в десятки тысяч GPU сбои — это не исключение, а неизбежность. Синхронное создание чекпойнтов, когда обучение приостанавливается для сохранения состояния модели, является основной причиной потери полезных циклов GPU («goodput»). Для обеспечения отказоустойчивости без ущерба для производительности необходим продвинутый, многоуровневый асинхронный подход.

• Технический анализ: Наиболее эффективным решением является иерархическая, асинхронная схема создания чекпойнтов, которая использует несколько уровней хранения.1 Эта стратегия теперь является основной функцией в таких фреймворках, как PyTorch, и предлагается как управляемое решение облачными провайдерами, например, Google Cloud.11 Уровни выглядят следующим образом:

1. Уровень 1 (Наивысшая скорость, наименьшая отказоустойчивость): Память GPU -> DRAM хоста. После каждого шага обучения состояние модели копируется из памяти HBM GPU в основную оперативную память (RAM) узла. Это происходит чрезвычайно быстро (например, ~1 секунда для чекпойнта размером 500 ГБ) и позволяет GPU немедленно перейти к следующему шагу.
2. Уровень 2 (Высокая скорость, отказоустойчивость на уровне узла): DRAM хоста -> NVMe соседнего узла. Асинхронно чекпойнт из оперативной памяти CPU копируется через RDMA на локальный NVMe SSD соседнего узла. Это занимает немного больше времени (~10 секунд), но защищает от сбоя одного узла.
3. Уровень 3 (Умеренная скорость, отказоустойчивость на уровне кластера): NVMe узла -> Общее, долговременное хранилище. Периодически (например, каждые 10 минут) чекпойнт переносится с локального NVMe в систему долговременного хранения. Паттерн ввода-вывода здесь — простая, последовательная запись большими блоками, что идеально подходит для экономичного объектного хранилища. Требования к пропускной способности для этого уровня скромны (например, всего ~1 ГБ/с для переноса чекпойнта размером 500 ГБ каждые 10 минут), что делает дорогие all-flash параллельные файловые системы ненужными для этой критически важной задачи.

• Пример реализации в облаке: Решение Google Cloud Multi-Tier Checkpointing реализует именно эту архитектуру, предоставляя для ML-задачи «магический» локальный файловый том, который обеспечивает скорость на уровне RAM-диска с надежностью Google Cloud Storage, прозрачно управляя репликацией и восстановлением.11 AWS также продвигает асинхронное создание чекпойнтов в Amazon S3 для повышения эффективности обучения.

1.4 Инференс и поддержка RAG из озера данных

Требования к хранилищу для развертывания и инференса снова отличаются и характеризуются операциями чтения в режиме «только для чтения» целых файлов, что является естественным применением для объектного хранилища.

• Технический анализ: При обслуживании модели основная операция ввода-вывода — это загрузка весов модели, представляющая собой массовое копирование в режиме «только для чтения», которое идеально соответствует запросу GET объектного хранилища.1 Для продвинутых приложений, таких как генерация с дополненной реальностью (Retrieval-Augmented Generation, RAG), архитектура включает извлечение релевантных документов из базы знаний для дополнения промпта LLM. Эта база знаний, часто содержащая миллионы или миллиарды документов, идеально хранится в объектном хранилище. Сам процесс извлечения выполняется векторной базой данных (такой как Pinecone или Milvus), которая хранит векторные представления (эмбеддинги) документов, обеспечивая быстрый семантический поиск. Таким образом, общая архитектура RAG представляет собой синергетическое сочетание масштабируемого объектного хранилища (репозиторий документов) и высокопроизводительной векторной базы данных (индекс для поиска).

Современная архитектура хранения для ИИ — это не единый продукт, а стратегия, которая ставит во главу угла минимизацию времени простоя GPU. Каждое архитектурное решение — от использования отдельного кластера CPU для подготовки данных до многоуровневого асинхронного создания чекпойнтов — можно проследить до этого единственного экономического драйвера. При оценке любого решения для хранения данных в ИИ основной метрикой должны быть не пиковые IOPS или пропускная способность в изоляции. Ключевой вопрос: «Как эта архитектура способствует максимизации утилизации GPU на протяжении всего сквозного рабочего процесса?» Это смещает анализ TCO с метрик, ориентированных на хранилище, на бизнес-результаты, ориентированные на вычисления.

Таблица 1: Характеристики и роли хранилищ на разных этапах жизненного цикла ИИ

2. Восход платформ данных для ИИ

2.1 Появление мультипротокольных, унифицированных хранилищ

Архитектурные сложности, связанные с управлением и перемещением данных между разрозненными хранилищами (например, объектным хранилищем для сбора данных и PFS для обучения), создали рыночный спрос на унифицированные платформы. Эти современные системы обеспечивают высокопроизводительный доступ к одному и тому же пулу данных через несколько протоколов (например, NFS, SMB, S3).

• Технический анализ: Современные платформы часто используют дезагрегированную архитектуру с полным разделением ресурсов (disaggregated, shared-everything architecture, DASE, как ее называет VAST), построенную на all-flash носителях. Они предоставляют стандартные интерфейсы NFS и S3 со сравнимым уровнем производительности, устраняя компромиссы. Это позволяет организации загружать данные через S3, обрабатывать их с помощью Spark через S3, обучать модель с использованием NFS-over-RDMA и обслуживать данные для инференса из того же репозитория, что значительно упрощает управление данными.

2.2 Архитектурный анализ: сравнительный обзор ведущих платформ данных для ИИ

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

• VAST Data: Фокусируется на архитектуре DASE (Disaggregated, Shared-Everything), которая отделяет логику вычислений (C-узлы) от носителей данных (D-узлы), обеспечивая независимое масштабирование производительности и емкости. Они делают акцент на радикальном сокращении данных и использовании более дешевой QLC-флеш-памяти, чтобы сделать экономику all-flash жизнеспособной для всего озера данных. Их платформа спроектирована как единая система для файлов, объектов и нативной базы данных, стремясь консолидировать весь стек данных.
• Pure Storage: Подчеркивает простоту и модель подписки «Evergreen». Их платформа FlashBlade — это унифицированная система для файлов и объектов (UFO). Недавние решения, такие как FlashBlade//EXA, демонстрируют движение в сторону дезагрегированной архитектуры с разделением узлов метаданных и данных для лучшей обработки массовой параллельности и операций с метаданными в рабочих нагрузках ИИ. Они конкурируют, предлагая тесно интегрированный аппаратно-программный комплекс с мощными возможностями AIOps и управления.

2.3 Парадигма Data Lakehouse: обеспечение надежности и управления данными ИИ с помощью Delta Lake на S3

Для организаций, создающих свои платформы ИИ на базе стандартных облачных объектных хранилищ (таких как AWS S3), критически важна парадигма Data Lakehouse, реализуемая с помощью открытых табличных форматов, таких как Delta Lake. Она привносит в озеро данных надежность и управляемость, свойственные хранилищам данных.

• Технический анализ: Delta Lake — это открытый слой хранения, который располагается поверх файлов Parquet в объектном хранилище, таком как S3. Его основной компонент — это журнал транзакций, который обеспечивает ACID-транзакции, принудительное применение схемы (schema enforcement) и «путешествие во времени» (версионирование данных) для озера данных. Это решает основные проблемы сырых объектных хранилищ:

1. Надежность: ACID-транзакции гарантируют, что одновременные записи из заданий по подготовке данных или потоковых источников не повредят данные.
2. Производительность: Журнал транзакций содержит список файлов данных, что позволяет избежать медленных и дорогостоящих операций LIST в объектном хранилище, которые являются основным узким местом для движков запросов, таких как Spark.
3. Управление: Принудительное применение схемы обеспечивает качество данных, а «путешествие во времени» позволяет проводить аудит и воспроизводить эксперименты, давая пользователям возможность запрашивать точную версию набора данных, использованную для конкретного цикла обучения. Это краеугольный камень ответственного, ориентированного на данные ИИ. Архитектура предполагает использование таких инструментов, как Spark, для чтения и записи таблиц Delta непосредственно на S3.

Существует фундаментальное напряжение и в то же время сближение между двумя подходами: моделью «все в одном» (от поставщиков, таких как Pure/VAST) и «компонуемой моделью на основе открытого исходного кода» (Delta Lake на S3). Первая предлагает простоту, единую точку поддержки и потенциально более высокую производительность «из коробки» за счет тесной интеграции аппаратного и программного обеспечения. Вторая предлагает гибкость, позволяет избежать привязки к поставщику и использует обширную экосистему открытого исходного кода. Будущее, вероятно, увидит их сближение: поставщики комплексных решений будут продолжать внедрять и интегрировать открытые стандарты, а стек открытого исходного кода станет более интегрированным и простым в развертывании через управляемые облачные сервисы. Выбор для предприятия зависит от его внутренней экспертизы, толерантности к риску привязки к поставщику и потребности в кастомизации.

3. Ключевые технологические драйверы

3.1 NVIDIA GPUDirect Storage

Традиционный путь данных от хранилища к GPU, включающий «промежуточный буфер» в системной памяти CPU, является серьезным узким местом. GPUDirect Storage (GDS) создает прямой путь, значительно повышая производительность.

• Технический анализ: GDS обеспечивает прямой путь передачи данных между хранилищем (локальным или удаленным) и памятью GPU.43 Он использует механизм прямого доступа к памяти (DMA) на контроллере хранилища или сетевом адаптере (или рядом с ними) для перемещения данных непосредственно в память GPU, полностью минуя CPU. Это снижает задержку, увеличивает эффективную пропускную способность и, что критически важно, освобождает циклы CPU, которые в противном случае были бы потрачены на копирование памяти. GDS является фундаментальной технологией для любого высокопроизводительного конвейера данных ИИ.

3.2 GPUDirect для S3 и перспектива единого, производительного уровня данных

Недавнее расширение GPUDirect на протокол S3, возможно, является самым значительным последним событием в области хранения данных для ИИ. Оно фактически устраняет преимущество в производительности параллельных файловых систем для многих рабочих нагрузок ИИ.

• Технический анализ: Исторически GDS был ориентирован на файловые протоколы и блочные хранилища (NVMe/NVMe-oF). Однако поставщики, такие как
  Cloudian и MinIO, в сотрудничестве с NVIDIA, теперь реализовали GPUDirect для S3 с использованием RDMA. Эта архитектура работает следующим образом:

1. Приложение делает стандартный запрос по API S3.
2. Система хранения, используя сетевой адаптер с поддержкой RDMA (например, NVIDIA ConnectX), устанавливает прямой путь к памяти GPU на клиенте.
3. Данные передаются параллельно с нескольких узлов хранения непосредственно в память GPU, минуя CPU клиента и накладные расходы традиционного стека TCP/IP.

• Влияние: Это смена парадигмы. Это означает, что объектное хранилище теперь может доставлять данные в GPU с низкой задержкой и высокой пропускной способностью, которые ранее ассоциировались только со специализированными файловыми системами HPC. Cloudian, например, заявляет о стабильной пропускной способности более 200 ГБ/с при снижении загрузки CPU клиента на 45%. Это делает возможным создание всего конвейера ИИ, от сбора данных до обучения и инференса, на единой, масштабируемой и экономически эффективной платформе объектного хранения, совместимой с S3. Это устраняет необходимость в дорогостоящем, сложном промежуточном уровне на основе файлов и связанных с ним миграциях данных.

3.3 Data-centric AI

Отрасль переходит от «модельно-ориентированного» к «данно-ориентированному» подходу, где улучшение качества данных признается более эффективным, чем настройка архитектуры модели. Это предъявляет новые и строгие требования к платформе хранения в части управления, версионирования и отслеживания происхождения данных (lineage).

• Технический анализ: ИИ, ориентированный на данные (data-centric AI), требует систематического улучшения набора данных. Это означает, что система хранения должна функционировать не просто как хранилище битов; она должна быть активной частью жизненного цикла MLOps/LLMOps. Ключевые требования включают:

1. Версионирование данных: Возможность отслеживать каждую версию набора данных и связывать ее с конкретным циклом обучения модели имеет решающее значение для воспроизводимости и отладки. Инструменты, такие как Delta Lake (через «путешествие во времени»), и платформы, такие как DVC и WandB, предоставляют эту возможность, часто используя объектное хранилище в качестве бэкенда.
2. Происхождение данных (Data Lineage): Организации должны иметь возможность отслеживать весь жизненный цикл данных — от источника, через все преобразования, до их использования в обучении — для обеспечения аудита, объяснимости и соответствия требованиям. Это требует автоматического сбора метаданных и надежного каталога данных — функций систем активного управления метаданными и унифицированных платформ данных.
3. Унифицированное управление: Централизованная платформа хранения упрощает управление. Применение последовательных политик контроля доступа, безопасности и стандартов качества данных гораздо проще на едином озере данных, чем на нескольких разрозненных системах.

Появление data-centric AI превращает систему хранения из пассивного репозитория в активный, проверяемый компонент системы управления ИИ. Хранилище теперь неразрывно связано с модельными рисками, соответствием требованиям и этикой. Выбор платформы хранения — это уже не просто решение в области ИТ-инфраструктуры. Это основной компонент стратегии управления рисками и соответствия требованиям компании. Технические директора теперь должны оценивать хранилища по их способности поддерживать надежную, проверяемую систему управления данными.

4. Взгляд через призму TCO

4.1 Основы анализа общей стоимости владения (TCO) инфраструктуры хранения данных для ИИ

Упрощенный подход, сфокусированный на цене покупки хранилища (стоимость за терабайт), вводит в заблуждение. Комплексный анализ TCO должен учитывать все прямые и косвенные затраты за период 3-5 лет.

• Компоненты TCO: Мы подробно рассмотрим ключевые статьи расходов, которые должны быть включены в любую реалистичную модель TCO:
• Капитальные затраты (CapEx): Приобретение оборудования (серверы, GPU, хранилища, сетевое оборудование).
• Операционные затраты (OpEx): Электроэнергия и охлаждение (основной фактор для локальных развертываний), площадь в дата-центре, плата за использование облачных сервисов (за токен, за час, за передачу данных), лицензии на программное обеспечение и контракты на поддержку.
• Обслуживание данных и моделей: Повторяющиеся затраты на очистку, разметку данных и переобучение моделей, которые могут составлять 15-25% от первоначальной стоимости разработки ежегодно.
• Персонал: Значительные затраты на специализированных специалистов по данным, инженеров MLOps и архитекторов инфраструктуры, необходимых для создания и поддержки системы.64
• Скрытые затраты: Стоимость простоя GPU, сложность миграции данных и риск привязки к поставщику.

4.2 Как архитектура хранения напрямую влияет на рентабельность инвестиций (ROI)

Единственным наиболее важным фактором в TCO крупномасштабного кластера для обучения ИИ является утилизация GPU. Улучшение «полезной производительности» (goodput) на 1% может привести к экономии миллионов долларов при выполнении крупного задания по обучению.

• Связь хранения с ROI: Этот подраздел напрямую связывает архитектурные решения, обсуждавшиеся в отчете, с этой ключевой метрикой.

• Быстрое создание чекпойнтов: Асинхронное, многоуровневое создание чекпойнтов напрямую сокращает время простоя GPU, повышая их утилизацию.
• Загрузка данных с низкой задержкой: Использование локальных NVMe или высокопроизводительной унифицированной платформы данных предотвращает ожидание GPU данных, устраняя простои, вызванные вводом-выводом.
• Упрощенные конвейеры: Унифицированная платформа данных, устраняющая перемещение данных между уровнями, сокращает «время до обучения», укорачивая общий цикл подготовки и загрузки данных, что позволяет проводить больше экспериментов на том же оборудовании.
• TCO локального развертывания против облачного: Мы проанализируем точку безубыточности между локальными и облачными развертываниями. Локальное развертывание имеет высокие капитальные затраты, но более низкие операционные, в то время как в облаке все наоборот. Для рабочих нагрузок с высокой, постоянной утилизацией (например, > 5-9 часов в день) локальное развертывание может обеспечить значительную экономию в течение 3-5 лет, но это требует обязательства по максимизации использования приобретенного оборудования.

Таблица 2: Контрольный список компонентов TCO для инфраструктуры хранения данных ИИ

4.3 Архитектура будущего. Рекомендации по созданию масштабируемой и экономичной платформы данных для ИИ

Этот раздел предоставляет действенные рекомендации для архитекторов и технических руководителей.

• Примите объектное хранилище как основу: Проектируйте свою архитектуру вокруг масштабируемого, S3-совместимого объектного хранилища как центрального озера данных и системы записи.
• Приоритезируйте утилизацию GPU: Оценивайте каждое решение в области хранения данных с точки зрения его влияния на «полезную производительность» GPU. Инвестируйте в технологии, такие как локальные NVMe и асинхронное создание чекпойнтов.
• Унифицируйте, где это возможно: Активно стремитесь к устранению изолированных хранилищ данных и сложных конвейеров перемещения данных. Отдавайте предпочтение унифицированным платформам данных или хорошо спроектированному озеру данных (Delta Lake на S3) для создания единого источника истины.
• Требуйте открытых стандартов: Настаивайте на использовании стандартных протоколов, таких как S3, NFS и pNFS, чтобы избежать привязки к поставщику и обеспечить совместимость с широкой экосистемой ИИ (например, Spark, PyTorch, TensorFlow).
• Интегрируйте управление с первого дня: Ваша платформа хранения является краеугольным камнем вашей стратегии управления ИИ. Убедитесь, что она поддерживает надежное версионирование, отслеживание происхождения данных и контроль безопасности.

Заключение

Отчет завершается повторением центрального тезиса: эпоха принудительного использования устаревших архитектур хранения для рабочих нагрузок ИИ закончилась. Современная платформа данных для ИИ, характеризующаяся единой основой на базе объектного хранилища, локальной флеш-памятью для производительности и неустанным фокусом на максимизации утилизации GPU, представляет собой фундаментальную смену парадигмы. Технологии, такие как GPUDirect для S3, — это не просто постепенные улучшения; это архитектурные прорывы, которые сворачивают стек хранения и упрощают весь жизненный цикл данных ИИ.

Для организаций, стремящихся построить устойчивую, масштабируемую и экономически жизнеспособную фабрику ИИ, путь вперед ясен: необходимо спроектировать платформу данных, где хранилище — это не узкое место, которое нужно преодолеть, а стратегический драйвер инноваций. Конечной мерой успеха будет общая стоимость владения, определяемая не стоимостью за терабайт, а продуктивной отдачей от каждого GPU.

Источники

1. LLM training without a parallel file system — Glenn K. Lockwood, дата последнего обращения: июля 9, 2025, https://blog.glennklockwood.com/2025/02/llm-training-without-parallel-file.html
2. Very large AI model training uses object storage — Blocks and Files, дата последнего обращения: июля 9, 2025, https://blocksandfiles.com/2025/02/04/very-large-ai-model-training-uses-object-storage/
3. S3 Object Storage: The Ultimate Solution For AI/ML Data Lakes — StoneFly, Inc., дата последнего обращения: июля 9, 2025, https://stonefly.com/blog/s3-object-storage-the-ultimate-solution-for-ai-ml-data-lakes/
4. How to Build a Scalable Cloud Data Lake in 4 steps — FirstEigen, дата последнего обращения: июля 9, 2025, https://firsteigen.com/blog/building-cloud-data-lake-key-steps/
5. Design storage for AI and ML workloads in Google Cloud | Cloud Architecture Center, дата последнего обращения: июля 9, 2025, https://cloud.google.com/architecture/ai-ml/storage-for-ai-ml
6. Data lake best practices | Databricks, дата последнего обращения: июля 9, 2025, https://www.databricks.com/discover/data-lakes/best-practices
7. 10 Data Lake Best Practices When Using AWS S3 — ChaosSearch, дата последнего обращения: июля 9, 2025, https://www.chaossearch.io/blog/data-lake-best-practices
8. 8 Data Lake Best Practices: Make the Most of Your Data Lake — Cloudian, дата последнего обращения: июля 9, 2025, https://cloudian.com/guides/data-lake/8-data-lake-best-practices-make-the-most-of-your-data-lake/
9. Mastering Cloud Data Lakes: Best Practices for Building Reliable and Scalable Data Lakes in 2025 — Everyday IT, дата последнего обращения: июля 9, 2025, https://www.ai-infra-link.com/mastering-cloud-data-lakes-best-practices-for-building-reliable-and-scalable-data-lakes-in-2025/
10. AI Storage: Transforming How You Manage Data for AI Workloads — Hammerspace, дата последнего обращения: июля 9, 2025, https://hammerspace.com/ai-storage-transforming-how-you-manage-data-for-ai-workloads/
11. Using multi-tier checkpointing for large AI training jobs | Google Cloud Blog, дата последнего обращения: июля 9, 2025, https://cloud.google.com/blog/products/ai-machine-learning/using-multi-tier-checkpointing-for-large-ai-training-jobs
12. Pure Storage FlashBlade and PyTorch Asynchronous Checkpointing: Accelerating Training for Large AI Models, дата последнего обращения: июля 9, 2025, https://blog.purestorage.com/purely-technical/pure-storage-flashblade-and-pytorch-asynchronous-checkpointing/
13. Elastic training and optimized checkpointing improve ML Goodput | Google Cloud Blog, дата последнего обращения: июля 9, 2025, https://cloud.google.com/blog/products/ai-machine-learning/elastic-training-and-optimized-checkpointing-improve-ml-goodput
14. Train large-scale machine learning models on GKE with Multi-Tier Checkpointing, дата последнего обращения: июля 9, 2025, https://cloud.google.com/kubernetes-engine/docs/how-to/machine-learning/training/multi-tier-checkpointing
15. More-efficient recovery from failures during large-ML-model training — Amazon Science, дата последнего обращения: июля 9, 2025, https://www.amazon.science/blog/more-efficient-recovery-from-failures-during-large-ml-model-training
16. Architecting scalable checkpoint storage for large-scale ML training on AWS, дата последнего обращения: июля 9, 2025, https://aws.amazon.com/blogs/storage/architecting-scalable-checkpoint-storage-for-large-scale-ml-training-on-aws/
17. End-to-end LLM training on instance clusters with over 100 nodes using AWS Trainium, дата последнего обращения: июля 9, 2025, https://aws.amazon.com/blogs/machine-learning/end-to-end-llm-training-on-instance-clusters-with-over-100-nodes-using-aws-trainium/
18. How Data Centric AI is Transforming Storage Requirements — Cloudian, дата последнего обращения: июля 9, 2025, https://cloudian.com/blog/how-data-centric-ai-is-transforming-storage-requirements/
19. What is Retrieval-Augmented Generation (RAG)? — Google Cloud, дата последнего обращения: июля 9, 2025, https://cloud.google.com/use-cases/retrieval-augmented-generation
20. Retrieval-Augmented Generation (RAG) with Atlas Vector Search — MongoDB, дата последнего обращения: июля 9, 2025, https://www.mongodb.com/docs/atlas/atlas-vector-search/rag/
21. Building Applications with Vector Databases — DeepLearning.AI, дата последнего обращения: июля 9, 2025, https://www.deeplearning.ai/short-courses/building-applications-vector-databases/
22. milvus.io, дата последнего обращения: июля 9, 2025, https://milvus.io/ai-quick-reference/how-do-you-design-a-multimodal-vector-database#:~:text=Designing%20a%20multimodal%20vector%20database,while%20maintaining%20efficient%20query%20performance.
23. Comparing GPU Costs for AI Workloads: Factors Beyond Hardware Price | OpenMetal IaaS, дата последнего обращения: июля 9, 2025, https://openmetal.io/resources/blog/gpu-comparison-ai-cost-access-performance/
24. 5 Reasons Why Parallel File Systems Are Not a Silver Bullet for AI — VAST Data, дата последнего обращения: июля 9, 2025, https://www.vastdata.com/blog/five-reasons-why-parallel-file-systems-are-not-silver-bullet-for-ai
25. The 13 Best Distributed File Systems and Object Storage Solutions for 2025, дата последнего обращения: июля 9, 2025, https://solutionsreview.com/data-storage/the-best-distributed-file-systems/
26. VAST Data Platform: AI-Powered Discovery Engine, дата последнего обращения: июля 9, 2025, https://www.vastdata.com/platform/overview
27. All-Flash Data Storage for Artificial Intelligence — VAST Data, дата последнего обращения: июля 9, 2025, https://www.vastdata.com/usecase/artificial-intelligence
28. AI & Data Efficiency: The Power of Disaggregated Shared Everything Architecture — YouTube, дата последнего обращения: июля 9, 2025, https://www.youtube.com/watch?v=6qFwSCw1Qe8
29. AI Data Pipeline Architecture: How AI Models are Built and Deployed | VAST Data, дата последнего обращения: июля 9, 2025, https://www.vastdata.com/blog/ai-data-pipeline-architecture
30. Comparing Storage Platforms for Big Data Applications — Allbound, дата последнего обращения: июля 9, 2025, https://cdn.allbound.com/vastdata-ab/2023/02/23230226/VAST-Big-Data-Comparison-Guide-R5.pdf
31. Vast Data vs. Pure Storage: Comparison, дата последнего обращения: июля 9, 2025, https://www.purestorage.com/products/others-comparison.html
32. Meet FlashBlade//EXA. More AI. Less Waiting. — Pure Storage, дата последнего обращения: июля 9, 2025, https://www.purestorage.com/uk/demos/platform/powering-ai-at-scale/meet-flashblade-exa/6369735568112.html
33. Legacy systems fade as arrays shift to extreme scale and parallelism for AI, дата последнего обращения: июля 9, 2025, https://blocksandfiles.com/2025/03/17/foundational-storage-array-pivot-to-ai/
34. Powering AI at Scale — Pure Storage, дата последнего обращения: июля 9, 2025, https://www.purestorage.com/demos/platform/powering-ai-at-scale/powering-ai-at-scale/6370477557112.html
35. Pure Storage FlashBlade vs VAST Data comparison — PeerSpot, дата последнего обращения: июля 9, 2025, https://www.peerspot.com/products/comparisons/pure-storage-flashblade_vs_vast-data
36. Pure Storage FlashArray vs VAST Data comparison — PeerSpot, дата последнего обращения: июля 9, 2025, https://www.peerspot.com/products/comparisons/pure-storage-flasharray_vs_vast-data
37. Pure Storage Elevates Management and Automation — Futuriom, дата последнего обращения: июля 9, 2025, https://www.futuriom.com/articles/news/pure-storage-elevates-management-and-automation/2025/06
38. What is Delta Lake? Benefits and Architecture — Qlik, дата последнего обращения: июля 9, 2025, https://www.qlik.com/us/data-lake/delta-lake
39. What is Delta Lake? — IBM, дата последнего обращения: июля 9, 2025, https://www.ibm.com/think/topics/delta-lake
40. Delta Lake on S3, дата последнего обращения: июля 9, 2025, https://delta.io/blog/delta-lake-s3/
41. Lakehouse reference architectures (download) — Databricks Documentation, дата последнего обращения: июля 9, 2025, https://docs.databricks.com/aws/en/lakehouse-architecture/reference
42. Databricks Delta Lake 101: A Comprehensive Guide (2025) — Chaos Genius, дата последнего обращения: июля 9, 2025, https://www.chaosgenius.io/blog/databricks-delta-lake/
43. Magnum IO GPUDirect Storage — NVIDIA Developer, дата последнего обращения: июля 9, 2025, https://developer.nvidia.com/gpudirect-storage
44. What is GPUDirect Storage? | WEKA, дата последнего обращения: июля 9, 2025, https://www.weka.io/learn/glossary/gpu/what-is-gpudirect-storage/
45. NVIDIA GPUDirect — NVIDIA Developer, дата последнего обращения: июля 9, 2025, https://developer.nvidia.com/gpudirect
46. 1. Overview Guide — GPUDirect Storage Overview Guide — NVIDIA Docs, дата последнего обращения: июля 9, 2025, https://docs.nvidia.com/gpudirect-storage/overview-guide/index.html
47. GPUDirect Storage: A Direct Path Between Storage and GPU Memory — NVIDIA Developer, дата последнего обращения: июля 9, 2025, https://developer.nvidia.com/blog/gpudirect-storage/
48. NVIDIA Magnum IO GPUDirect Storage Overview Guide, дата последнего обращения: июля 9, 2025, https://docs.nvidia.com/gpudirect-storage/pdf/overview-guide.pdf
49. NVIDIA GPUDirect Storage: 4 Key Features, Ecosystem & Use Cases — Cloudian, дата последнего обращения: июля 9, 2025, https://cloudian.com/guides/data-security/nvidia-gpudirect-storage-4-key-features-ecosystem-use-cases/
50. Cloudian integrates Nvidia GPUDirect acceleration for object storage — Blocks and Files, дата последнего обращения: июля 9, 2025, https://blocksandfiles.com/2024/11/18/cloudian-supporting-nvidia-gpudirect-acceleration-for-object-storage/
51. NVIDIA GPUDirect Storage and MinIO AIStor: Unlocking Efficiency for GPU-Powered AI Workloads, дата последнего обращения: июля 9, 2025, https://blog.min.io/nvidia-gpudirect-storage-and-aistor/
52. Cloudian Shatters AI Storage Barriers with Direct GPU-to-Object Storage Access, дата последнего обращения: июля 9, 2025, https://cloudian.com/blog/cloudian-delivers-groundbreaking-performance-with-nvidia-gpudirect-support/
53. Opportunities and Challenges in Data-Centric AI — ResearchGate, дата последнего обращения: июля 9, 2025, https://www.researchgate.net/publication/378449783_Opportunities_and_Challenges_in_Data-Centric_AI
54. Data-Centric Artificial Intelligence — arXiv, дата последнего обращения: июля 9, 2025, https://arxiv.org/html/2212.11854v4
55. Data-Centric Approach vs Model-Centric Approach in Machine Learning — neptune.ai, дата последнего обращения: июля 9, 2025, https://neptune.ai/blog/data-centric-vs-model-centric-machine-learning
56. AI Data Governance — Key Aspects and Best Practices — Nexla, дата последнего обращения: июля 9, 2025, https://nexla.com/ai-readiness/ai-data-governance/
57. Using AI Data Governance for Data Integrity — Boomi, дата последнего обращения: июля 9, 2025, https://boomi.com/blog/ai-data-governance-integrity/
58. Explore Data-Centric MLOps and LLMOps in Modern Machine Learning — Ideas2IT, дата последнего обращения: июля 9, 2025, https://www.ideas2it.com/blogs/data-centric-mlops-and-llmops
59. Active Metadata Management — ChainSys, дата последнего обращения: июля 9, 2025, https://www.chainsys.com/active-metadata-management
60. What are the best practices for modeling data lineage? — Secoda, дата последнего обращения: июля 9, 2025, https://www.secoda.co/blog/best-practices-for-modeling-data-lineage
61. AI Data Governance: Challenges and Best Practices for Businesses — Digital Guardian, дата последнего обращения: июля 9, 2025, https://www.digitalguardian.com/blog/ai-data-governance-challenges-and-best-practices-businesses
62. On-Premise vs Cloud: Generative AI Total Cost of Ownership — Lenovo Press, дата последнего обращения: июля 9, 2025, https://lenovopress.lenovo.com/lp2225-on-premise-vs-cloud-generative-ai-total-cost-of-ownership
63. On-Premise vs Cloud: Generative AI Total Cost of Ownership — Lenovo Press, дата последнего обращения: июля 9, 2025, https://lenovopress.lenovo.com/lp2225.pdf
64. Cost to Build an AI Feedback Analytics Platform — Thematic, дата последнего обращения: июля 9, 2025, https://getthematic.com/insights/cost-to-build-an-ai-feedback-analytics-platform/
65. Understanding the cost to setup an AI data center (updated 2025) — Lumenalta, дата последнего обращения: июля 9, 2025, https://lumenalta.com/insights/understanding-the-cost-to-setup-an-ai-data-center-updated-2025
66. AI TCO Framework: Frequently Asked Questions About the True Cost of Enterprise AI, дата последнего обращения: июля 9, 2025, https://www.phenx.io/post/ai-tco-framework-frequently-asked-questions-about-the-true-cost-of-enterprise-ai

Автор: Андрей Гантимуров