Хранение датасетов и checkpoint в AI-кластере: Как спроектировать СХД

СХД для AI-кластера нельзя корректно рассчитать только по объёму датасета или паспортной скорости массива.

Dataset размером 100 ТБ может создавать совершенно разную нагрузку: последовательно читаться крупными shards, многократно перечитываться между эпохами, состоять из миллионов небольших файлов или значительной частью попадать в local cache.

Checkpoint создаёт уже другой I/O-профиль: большой burst записи от множества ranks. Restore — третий: чтение training state для возврата job к работе после interruption.

Поэтому storage sizing лучше строить по полной цепочке:

Главный вопрос не:

Сколько GB/s нужно AI-кластеру?

А:

Какие I/O-потоки создаёт реальный training workload, сколько данных каждый из них перемещает и за какое время операция должна завершиться?

Почему AI-кластер нельзя рассчитывать только по TB

Ёмкость и производительность — разные характеристики.

Два проекта могут иметь одинаковый dataset в 100 ТБ, но совершенно разные требования к storage.

В одном случае:

• крупные sequential shards;

• несколько параллельных readers;

• высокая потребность в aggregate bandwidth.

В другом:

• множество небольших files или objects;

• частые open/read operations;

• высокая concurrency;

• заметная metadata/IOPS-нагрузка.

Поэтому первый шаг — не выбор дисков, RAID или протокола.

Сначала нужно описать Data Flow.

Сначала нарисуйте полный Data Flow

Упрощённо AI-training может выглядеть так:

Authoritative data source

↓

Shared storage

↓

Active working set

↓

RAM / local NVMe cache

↓

Training

↓

Checkpoint staging

↓

Persistent checkpoint tier

↓

Restore

↓

Training resumed

Для каждой стрелки полезно определить:

• bytes;

• operations;

• concurrency;

• frequency;

• допустимое время;

• может ли поток пересекаться с другими.

AI-training создаёт несколько разных storage workloads

Минимум нужно разделять следующие потоки.

Dataset ingest

Поступление или обновление данных из:

• data lake;

• object storage;

• корпоративных систем;

• внешних источников.

Здесь важны:

• объём изменений;

• peak ingest rate;

• frequency обновлений.

Training dataset reads

Compute nodes получают данные для очередных batches.

Здесь важны:

• aggregate read throughput;

• количество readers;

• file/object profile;

• concurrency;

• cache behaviour.

Cache fill

Первичное наполнение RAM или local NVMe данными рабочего набора.

Cold-cache traffic может сильно отличаться от последующих warm reads.

Checkpoint write

Training state периодически сохраняется — часто одновременно с большого числа ranks.

Это отдельный burst workload.

Restore

Checkpoint читается обратно после restart или другого recovery scenario.

Archive и retention

Исторические checkpoints, model artifacts и datasets могут перемещаться в другой storage tier с иными требованиями к performance.

Эти потоки нельзя описать одной средней скоростью СХД.

Dataset feed: главный вопрос — ждёт ли training данные

Для training важно не само паспортное значение GB/s, а способность data path стабильно выдавать batches с требуемой скоростью.

Практический критерий:

storage path не должен создавать неприемлемые stalls в representative training workload.

Но низкая GPU utilization ещё не доказывает проблему СХД.

Почему GPU idle не означает автоматически storage bottleneck

Между storage и accelerator находятся:

• network;

• client NIC;

• host memory;

• dataloader;

• decompression;

• tokenizer;

• CPU preprocessing;

• application queues.

Поэтому ситуацию:

GPU ждёт очередной batch

нужно разбирать end-to-end.

Total dataset и active working set — разные вещи

Допустим, полный dataset занимает 300 ТБ.

Из этого не следует, что рядом с compute нужно разместить 300 ТБ local NVMe.

Полезно разделять:

Total dataset

Полный набор данных проекта.

Active working set

Данные, реально используемые workload в рассматриваемом временном окне и потенциально пригодные для кэширования.

Именно working set помогает определить:

• разумный объём local cache;

• количество повторных чтений;

• нагрузку на shared storage после прогрева cache.

Почему размер файлов важен не меньше общего GB/s

Условно можно выделить два профиля.

Large-file workload

Небольшое число крупных shards и много последовательного чтения.

Здесь storage чаще ограничен aggregate bandwidth.

Small-file workload

Большое число небольших files или objects.

Здесь существенными становятся:

• metadata;

• file opens;

• IOPS;

• request rate;

• tail latency.

Поэтому высокий sequential throughput массива ещё не гарантирует хороший результат на dataset с миллионами небольших файлов.

Dataset format — часть workload identity

Для sizing полезно фиксировать:

• формат;

• compression;

• sharding;

• file/object count;

• size distribution;

• access pattern.

Даже один logical dataset после другого packing может создавать заметно другой I/O profile.

Local NVMe: cache или staging tier, а не автоматическая замена shared storage

Local NVMe рядом с compute может использоваться для:

• dataset cache;

• temporary staging;

• local recovery state;

• промежуточных artifacts.

Но роль local storage нужно описывать явно.

Authoritative tier

Хранит данные, которые должны пережить согласованный failure scenario.

Cache/staging tier

Ускоряет access, но данные могут быть rebuildable или replicated в другом месте.

Поэтому local NVMe нельзя автоматически прибавлять к durable capacity shared storage.

Cache hit rate нужно измерять, а не назначать

Нельзя заранее считать:

local cache даст 80% hits.

Результат зависит от:

• размера working set;

• cache capacity;

• epochs;

• shuffling;

• параллельных jobs;

• eviction policy.

Нужно сравнивать реальные cache states.

Cold-cache test

Нужные data blocks отсутствуют в рассматриваемом cache tier.

Warm-cache test

Relevant working set уже присутствует в этом tier.

При этом необходимо фиксировать, какие именно caches считаются cold или warm:

• application cache;

• OS page cache;

• local NVMe;

• client cache;

• storage-controller cache.

Иначе результаты могут быть несопоставимы.

Как получить shared-storage read demand

Лучший input — реальные bytes на границе sizing-уемого storage tier.

Например:

Shared read rate = bytes, пришедшие с shared tier / observation window

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

Read rate ≈ Samples/s × Mean stored bytes/sample

Но только если явно известны assumptions.

Реальный traffic может отличаться из-за:

• compression;

• packing;

• multiple samples/object;

• caching;

• readahead;

• read amplification.

Поэтому measured I/O trace надёжнее арифметической оценки.

Aggregate throughput может скрывать медленный client

В multi-node cluster важна не только общая сумма GB/s.

Полезно смотреть:

• aggregate throughput;

• per-node throughput;

• распределение между clients;

• tail behaviour.

Ingest и training reads нужно считать раздельно

Обновление dataset может происходить одновременно с training.

Если ingest и training используют один storage tier или одну fabric, между ними появляется конкуренция.

Правильная последовательность benchmark:

isolated flows

→ application-like replay

→ representative concurrent mix.

При этом peak всех потоков не нужно складывать механически. Нужен реальный timeline их пересечения.

Checkpoint — отдельный burst workload

Checkpoint принципиально отличается от dataset feed.

Distributed training может одновременно сохранять state со множества ranks, создавая:

• большой write burst;

• много parallel writers;

• множество shards/files;

• metadata activity.

Поэтому хороший training-read benchmark ещё не означает хороший checkpoint result.

Что входит в checkpoint

Checkpoint не обязательно равен model weights.

В зависимости от конкретного stack в него могут входить:

• model state;

• optimizer state;

• distributed shards;

• metadata;

• другие states, необходимые приложению для recovery.

Parameter count модели для этого недостаточно.

Почему один большой файл не заменяет checkpoint benchmark

Одни и те же 5 ТБ можно записать:

• одним writer;

• сотнями parallel writers;

• тысячами shards.

Storage увидит совершенно разную concurrency и metadata workload.

Поэтому checkpoint profile должен включать:

• total bytes;

• writer count;

• file/object count;

• completion time.

First-order sizing checkpoint write

Для первичной оценки можно использовать:

Required write rate ≈ Checkpoint bytes / Persistence target

или:

Persistence time ≈ Checkpoint bytes / Effective write rate

Но это только first-order sizing.

Формула не учитывает:

• metadata;

• writer topology;

• serialization;

• tail writer;

• client limitations;

• commit semantics.

Финальный результат нужно измерять на реальном checkpoint path.

Средний write throughput может скрывать tail

Если checkpoint считается завершённым только после последнего required writer, один медленный rank способен определять полное wall-clock время операции.

Поэтому полезно хранить отдельно:

• aggregate GB/s;

• total completion time;

• tail behaviour writers.

У checkpoint есть разные временные метрики

Как минимум нужно различать три события.

1. Blocking/staging time

Сколько checkpoint находится на critical path training.

2. Persistence completion

Когда данные полностью записаны в выбранный storage tier.

3. Usable recovery point

Когда checkpoint считается пригодным для восстановления в согласованном failure scenario.

Последние два события могут совпадать, но это нельзя предполагать автоматически.

Что значит durable checkpoint

Слово durable имеет смысл только вместе с failure domain.

Например, проект может требовать пережить:

• restart процесса;

• потерю compute node;

• потерю local NVMe;

• отказ storage component;

• более широкий инфраструктурный сбой.

Поэтому событие вроде завершившегося локального write или fsync само по себе не является универсальным доказательством защиты от любого failure scenario.

Проект должен определить:

Async checkpoint: training resumed ещё не означает новый recovery point

При asynchronous checkpoint workflow может выглядеть так:

training

↓

checkpoint requested

↓

staging

↓

training resumed

↓

background persistence

↓

durability condition reached

↓

recovery point advanced

Это одна из важнейших границ storage sizing.

Возобновление GPU compute ещё не означает, что новый checkpoint уже пригоден для восстановления после требуемого failure scenario.

Async checkpoint не устраняет storage requirement

После staging background process всё ещё должен записать checkpoint.

Если persistent tier не успевает за generation rate, в зависимости от implementation это может проявиться как:

• очередь;

• ожидание следующего save;

• дополнительное RAM pressure;

• resource contention.

Поэтому async save уменьшает critical-path blocking, но не отменяет requirement к storage throughput.

Async checkpoint также использует host resources

Staging state в host memory может требовать значительного объёма RAM.

Background processing также способно потреблять CPU.

Поэтому checkpoint architecture влияет не только на СХД, но и на compute-node host sizing.

Как проверить, успевает ли storage за checkpoint generation

Для объёмной оценки:

Checkpoint bytes/hour = Checkpoint size × Checkpoints/hour

Это полезный average volume metric.

Но checkpoint генерируется bursts.

Следовательно, storage должен пройти две разные проверки:

Average sustainability

Background persistence не отстаёт систематически от generation rate.

Burst completion

Отдельный checkpoint укладывается в требуемое persistence window.

Нет универсального правила, что каждый save обязательно должен завершаться до следующего checkpoint. Поведение зависит от implementation.

Важно другое:

persistence pipeline не должен устойчиво накапливать backlog или resource pressure.

Local и shared checkpoints имеют разные failure domains

Local checkpoint может дать быстрый recovery в некоторых scenarios.

Shared или другой persistent tier может покрывать более широкий failure domain.

Но нельзя автоматически утверждать:

local storage ненадёжный, shared — надёжный.

Нужно явно определить, какие failures переживает каждый tier.

Полезная архитектурная модель:

Fast recovery tier

Оптимизирован под быстрый restart в ограниченном failure domain.

Broader durable tier

Сохраняет recovery point для более серьёзного сценария отказа.

Restore нужно benchmark отдельно

Система, которая быстро принимает checkpoints, не обязана столь же быстро читать их обратно.

Поэтому:

Checkpoint Write PASS ≠ Restore PASS.

Для restore нужно измерить:

• checkpoint bytes;

• reader topology;

• storage read duration;

• recovery topology.

First-order sizing restore

Для первичной оценки:

Required restore read rate ≈ Checkpoint read bytes / Storage load target

или:

Но storage load — только один этап полного recovery.

Storage load time не равно RTO

После interruption могут потребоваться:

• replacement или allocation compute resources;

• process startup;

• checkpoint discovery;

• storage read;

• resharding;

• state reconstruction;

• dataloader initialization.

Поэтому:

RTO ≠ CheckpointBytes / ReadBandwidth.

Storage отвечает только за часть restart timeline.

Recovery topology тоже важна

Distributed checkpoint может загружаться не обязательно на ту же topology, на которой был создан.

Если при recovery меняется число ranks или layout, может потребоваться resharding и дополнительная работа.

Поэтому representative restore test должен воспроизводить реальный recovery scenario.

Что означает RPO для AI-training

RPO — Recovery Point Objective.

В контексте training удобно сформулировать его как:

сколько уже выполненного полезного training progress допустимо потерять после interruption.

Важно: RPO нельзя приравнять к расписанию checkpoint.

Если save запускается каждые десять минут, но новый usable checkpoint появляется позже, фактическая recovery point может отставать.

RPO нужно оценивать по последнему checkpoint, который действительно соответствует принятой recoverability/durability policy.

Что означает RTO

RTO — время, за которое workload должен восстановиться после interruption.

Для AI-training практический критерий:

через какое время система снова делает полезный training progress.

То есть не просто:

процессы снова запущены.

А:

training реально продолжился.

Checkpoint frequency — компромисс

Частые saves:

• уменьшают потенциальную потерю progress;

• увеличивают storage traffic и operational overhead.

Редкие:

• уменьшают checkpoint workload;

• увеличивают потенциальный lost work.

Поэтому универсального checkpoint interval не существует.

Он определяется совместно через:

• workload;

• save duration;

• interruption assumptions;

• RPO;

• training economics.

POSIX или S3: сравнивайте workload и semantics

Нельзя универсально утверждать:

POSIX всегда быстрее S3.

или:

object storage лучше для AI.

Нужно сравнивать:

• application compatibility;

• access pattern;

• object/file sizes;

• concurrency;

• required semantics;

• throughput;

• metadata/request behaviour.

Storage semantics тоже важны

Distributed applications зависят не только от скорости transfer.

Могут быть важны:

• consistency;

• shared namespace;

• atomicity;

• metadata behaviour;

• commit semantics.

Поэтому synthetic bandwidth benchmark — полезный subsystem test, но он не заменяет application-like checkpoint replay.

Storage fabric — часть end-to-end path

Путь данных может выглядеть так:

media

→ storage controllers

→ fabric

→ compute-node NIC

→ host

→ dataloader

→ accelerator

Bottleneck может находиться на любом участке.

Поэтому паспортный bandwidth backend-массива нельзя приравнивать к production throughput compute nodes.

Почему benchmark нужно запускать с compute-side clients

Production-like test должен включать:

• representative client count;

• production protocol;

• реальные NIC;

• actual file/object profile;

• production-like concurrency.

Хорошая последовательность:

synthetic subsystem qualification

→ application-like dataset/checkpoint replay

→ representative concurrent mix.

Synthetic benchmark полезен — просто он отвечает не на все вопросы.

Capacity budget тоже нужно разделять по ролям

Storage capacity проекта может включать:

• authoritative datasets;

• transformed copies;

• checkpoints;

• historical retained checkpoints;

• model artifacts;

• staging;

• temporary copies;

• projected growth.

Local cache считается отдельно.

Например:

8 compute nodes × 15 ТБ local NVMe

не означают автоматически:

120 ТБ durable capacity.

Physical и usable capacity — разные величины

Replication, erasure coding, snapshots и reserved space могут уменьшать объём, доступный workload.

Поэтому для sizing нужно запрашивать:

usable capacity после согласованной resilience policy.

Не достаточно сложить nominal capacity всех drives.

Checkpoint frequency и retention — разные параметры

Frequency

Как часто создаётся новый checkpoint.

Retention

Сколько versions сохраняется и как долго.

Первое в первую очередь влияет на write workload.

Второе — на capacity.

Их нужно учитывать независимо.

AI Storage I/O Budget

Перед выбором СХД полезно заполнить общую карту потоков.

Dataset

Cache

Checkpoint

Restore

Flow overlap

Как провести qualification

1. Зафиксировать stack

Сохранить:

• training framework;

• dataset version;

• file/object format;

• dataloader;

• checkpoint implementation;

• cache policy.

2. Снять representative I/O trace

Нужны:

• bytes;

• operations;

• timing;

• concurrency;

• file/object sizes.

3. Разделить flows

Отдельно:

• ingest;

• training reads;

• cache fill;

• checkpoint;

• restore.

4. Определить authoritative tiers

Зафиксировать, где должны сохраняться:

• datasets;

• checkpoints;

• model artifacts.

И какой failure domain должен переживать каждый tier.

5. Проверить cache states

Выполнить controlled tests с зафиксированным состоянием relevant cache tiers.

6. Проверить dataset reads

Измерить production-like:

• throughput;

• operations;

• per-client behaviour.

7. Проверить metadata-heavy path

Если production dataset действительно содержит большое число небольших files/objects.

8. Измерить exact checkpoint

Сохранить:

• bytes;

• writers;

• shards/files;

• frequency.

9. Измерить blocking/staging

Не смешивать его с background persistence.

10. Определить recovery-point condition

Зафиксировать событие, после которого checkpoint считается пригодным для восстановления в выбранном failure scenario.

11. Измерить persistence completion

Проверить, что storage устойчиво обслуживает generation rate без нежелательного backlog.

12. Выполнить representative restore

В том числе с нужной recovery topology.

13. Отделить storage load от полного RTO

Проверить полный путь до useful training resumed.

14. Проверить compute-side path

С реальными clients, NIC, protocol и fabric.

15. Проверить concurrent workload mix

Только те потоки, которые действительно пересекаются в production.

16. Проверить capacity и retention

На usable, а не nominal capacity.

17. Проверить RPO/RTO

По полной recovery timeline и согласованному failure domain.

Когда storage действительно может быть bottleneck

Что считать PASS

Dataset Feed PASS

Representative training pipeline не получает неприемлемых storage-induced stalls.

Metadata PASS

Система выдерживает реальный file/object profile при требуемой concurrency.

Cache PASS

Cache benefit подтверждён measurement, а роль cache не смешана с durability.

Checkpoint Blocking PASS

Critical-path staging/save укладывается в target.

Checkpoint Persistence PASS

Checkpoint достигает согласованного recovery-point condition в требуемое окно без устойчивого backlog.

Restore PASS

Storage-компонент recovery укладывается в target.

RPO/RTO PASS

Допустимая потеря training progress и полный recovery соответствуют требованиям проекта.

Capacity PASS

Usable capacity покрывает datasets, checkpoints, retention и рост.

Resilience PASS

Authoritative data и recovery points переживают согласованный failure domain.

Какие данные нужны для подбора СХД

Перед выбором storage platform полезно подготовить:

После этого вопрос:

Какая СХД нужна AI-кластеру?

можно заменить технически проверяемым требованием:

Storage architecture должна обслуживать такой dataset-read profile, такой working-set/cache pattern, такой checkpoint write burst и persistence window, а restore path — такой recovery target и failure domain.

Главное

AI-storage нельзя рассчитывать одной цифрой:

TB

или:

GB/s.

Сначала нужно разделить I/O-потоки:

dataset reads → cache → checkpoint staging → persistence → restore.

Для dataset важны:

• working set;

• file/object profile;

• concurrency;

• фактический traffic нужного tier.

Для cache:

• конкретное состояние cache tiers;

• measured reuse;

• failure domain.

Для checkpoint:

• exact artifact size;

• writer topology;

• blocking/staging time;

• persistence completion;

• условие появления нового usable recovery point.

При async save особенно важно помнить:

training resumed ≠ recovery point ready.

Для restore:

storage load time ≠ полный RTO.

А паспортная скорость backend-массива не является production result: финальный qualification проходит через compute-side clients на representative I/O mix и с реальным пересечением потоков.

Именно поэтому проектирование СХД для AI-кластера начинается не с RAID, протокола или накопителя, а с полного Data Flow и AI Storage I/O Budget.