Как загрузить GPU на максимум. Разбираем узкие места в инфраструктуре для ИИ

Представим, что вы запустили в облаке или на своем оборудованиии обучение модели. Выбрали конфигурацию с A100, H100 или L40S, может, даже с RTX 4090. Запускаете обучение модели, ждете, что процесс пойдет как по маслу. Но вместо э��ого в инструментах мониторинга видите, что GPU загружен на 40–60%, а то и меньше.

Причина не в «кривом коде» и не в том, что GPU «не тянут». Проблема глубже: производительность AI-кластера определяется не пиковыми терафлопсами, а самым слабым звеном в цепочке ввода-вывода. Даже самый быстрый GPU беспомощен, если данные не успевают до него «доехать». Он просто ждет.

В статье разберем, почему для эффективного AI-обучения важны быстрые диски, память и CPU, и расскажем, как спроектировать сбалансированную инфраструктуру — даже в условиях ограниченных ресурсов.

Главные узкие места в AI-инфраструктуре

Вся цепочка доставки от хранилища до GPU состоит из трех ключевых звеньев — и любое из них может стать узким местом:

1. Диски — если подсистема хранения не справляется с чтением данных, особенно при работе с миллионами мелких файлов ^[1], GPU остаются без работы. Они ждут, пока CPU и дисковая подсистема подготовят следующий батч.

2. Сеть — когда вычисления достаточно тяжелые, например обучение LLM или крупной CV-модели, а данные при этом читаются из сетевого хранилища (СХД), одна и та же сеть одновременно передает датасет на узлы и синхронизирует градиенты между GPU. Если ее пропускная способность или задержки не выдерживают двойной нагрузки, узлы начинают ждать ^[2], а эффективность масштабирования резко падает.

3. CPU и оперативная память — именно процессор выполняет всю тяжелую работу по чтению, декодированию (JPEG/PNG), аугментациям и формированию батчей. Если CPU слабый или используется медленная память, он не успевает поддерживать даже одну RTX 4090.

Эти компоненты формируют сквозной I/O-пайплайн, и его производительность определяется самым слабым звеном. Дальше разберем каждую из этих зон подробно.

Хранение данных и преимущества локальных NVMe

Главная проблема при работе с датасетами — неоптимальный формат хранения данных. Если они лежат в виде миллионов мелких файлов (JPEG, TXT, JSON), система будет тратить больше времени на открытие и поиск метаданных, чем на само чтение. Но стоит упаковать их в крупные последовательные архивы, например в формате WebDataset ^[3] (.tar) или TFRecord ^[4], и ситуация кардинально меняется. 

Переход к оптимизированным форматам может ускорить передачу информации в 3–10 раз. Вот как это выглядит на практике:

Такой подход сводит количество системных вызовов к минимуму, включает эффективное кеширование и позволяет использовать потенциал диска на полную.

В реальных AI-проектах данные сначала обычно хранятся в централизованных системах — будь то Ceph, MinIO или даже NAS. Эти решения удобны для совместной работы, резервного копирования и управления большими объемами. Но при запуске обучения их пропускная способность на один клиент редко превышает 1–2 ГБ/с. Этого недостаточно, чтобы полностью загрузить даже одну RTX 4090 или L40S.

Именно поэтому стандартная практика — скопировать датасет локально на NVMe перед стартом обучения. Это не вопрос экономии, а необходимость для достижения высокой скорости подачи данных. Именно так поступают и в крупных облаках: сначала данные лежат в общем хранилище, а перед обучением разворачиваются на быстрых локальных дисках инстанса.

Преимущества локальных NVMe:

• Максимальная скорость на узел. Локальный NVMe дает 5–7 ГБ/с (Gen4) и до 12+ ГБ/с (Gen5). Этого достаточно, чтобы полностью насытить даже мощную RTX 4090 или L40S. А при обучении на топовых картах вроде RTX 6000 Ada или новой RTX 6000 Blackwell с 96 ГБ памяти, требуется еще больше. И это скорость на один диск, если собрать в массив, цифры можно улучшить.

• Простота и предсказуемость. Нет зависимости от сети, нет задержек из-за конкуренции за ресурсы СХД — данные читаются напрямую с диска в память CPU/GPU.

Сеть — не «просто интернет», а канал обмена между инстансами

Если вы работаете с одним облачным инстансом и одной видеокартой, сеть внутри кластера вам вообще не нужна. Весь цикл обучения происходит локально: данные читаются с NVMe, обрабатываются CPU и поступают в GPU. Никакого обмена с другими узлами — и, соответственно, никаких требований к сети между серверами.

Но как только вы решаете масштабировать задачу на 2–4 сервера (например, запустить Data Parallel для ускорения обучения), между ними начинает генерироваться интенсивный трафик: градиенты, веса, иногда активации. И здесь уже недостаточно «обычного» интернета. Эти сервера уже должны быть в локальной сети, и достаточно быстрой, от 10 гбит/с.

Даже при обучении относительно небольшой модели, например на 1 млрд параметров, обмен градиентами может генерировать до 8–10 ГБ/с на инстанс. Если этот трафик идет по той же сети, что и подгрузка датасета или запись чекпойнтов, возникает конкуренция за пропускную способность, и эффективность масштабирования резко падает.

Чтобы было проще понять, какие требования к сети возникают в зависимости от масштаба задачи, мы собрали типичные сценарии в таблице:

Когда CPU и RAM мешают GPU работать на полную

Даже если вы работаете всего с одной видеокартой, ваш GPU может простаивать не из-за нее самой, а потому что CPU и оперативная память не успевают его «кормить».

Вот что происходит на практике:

• Данные считываются с NVMe → попадают в RAM → CPU декодирует изображения (JPEG/PNG), применяет аугментации, формирует батч → только потом данные передаются в память GPU.

• Если CPU слабый (менее 16 ядер или частота ниже 3.5–4 ГГц), он не справляется с этой нагрузкой.

• Если используется медленная DDR4-память с низкой частотой и высокими таймингами, ее пропускная способность становится узким местом — особенно при работе с большими батчами и параллельными воркерами DataLoader.

В итоге GPU ждет следующий батч, а вы платите за простой.

Практические рекомендации для российских команд

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

Для CV и небольших NLP-моделей до 10–20 млрд параметров отлично подойдут GPU от 24GB до 48GB.

Если модель не помещается в 24–48 ГБ — можно собрать кластер или использовать новые 96 ГБ видеокарты, которые появятся в нашем облаке ^[5] уже в ближайшие 2–3 месяца. Это позволит запускать даже 70B-модели в одном инстансе, без сложного распределенного обучения. Либо использовать более дорогие карты A100/H100 с объемом памяти от 80Gb.

Важно:

• Эти конфигурации нужно запускать на локальных NVMe-дисках — только так вы получите 3–12 ГБ/с на инстанс и полностью насытите GPU данными. Плюс возможность получить скорость и выше, при объединенных в массив дисках.

• Если вы используете несколько облачных серверов, они должны обмениваться данными по быстрой локальной сети между ними.

• CPU должен быть топовым: минимум 3.5 ГГц, лучше 4+ ГГц. Процессоры ниже 3 ГГц сильно снижают эффективность даже RTX 4090, так как не успевают готовить данные для GPU. Количество ядер можно выбрать исходя из задачи, но обычно менее 16 ядер - дают меньше эффективности.

Чтобы получить полную производительность GPU, в BIOS сервера:

1. Выставьте оптимальную NUMA-топологию (например, на AMD EPYC — NPS = 1 или 2). Это снизит задержки доступа к оперативной памяти.

2. Отключите IOMMU (если не используете виртуализацию) — это ускорит P2P-обмен между PCIe-устройствами.

3. Убедитесь, что GPU и NVMe-диски подключены к разным PCI-E портам, чтобы не делить пропускную способность.

Как проверить, что система работает на максимуме

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

Чек-лист «что проверить в первую очередь»:

1. Формат данных: переход от мелких файлов к tar /TFRecord / WebDataset дает в 3–10 раз больше скорости даже на том же диске.

2. DataLoader ^[6]: обязательно настройте num_workers (обычно 4–8 на GPU), включите pin_memory=True, используйте prefetch_factor=2–4.

Профилирование: запустите короткий тест сnvidia-smi dmon, iostat -x 1, torch.profiler или Nsight Systems. Если GPU загружены < 85% — ищите узкое место в I/O.

TCO-подход: иногда выгоднее оптимизировать, чем докупать

В условиях, когда бюджет на AI ограничен (до 100–150 тыс. ₽/мес), главный вопрос — не «сколько GPU купить», а «как максимально эффективно использовать то, что уже есть».

Оптимизация I/O-пайплайна часто дает ускорение в 2–3 раза — это эквивалентно получению «бесплатных» GPU. Напротив, покупка еще одного GPU при слабом CPU или медленном диске не даст линейного ускорения — вы просто получите два простаивающих ускорителя вместо одного.

Именно поэтому перед тем, как масштабироваться по железу, всегда проверяйте загрузку GPU. Если она ниже 85% — скорее всего, вы платите за простой, а не за вычисления.

Заключение: сбалансированная инфраструктура — ключ к эффективному AI

Мощные GPU — это лишь одна часть уравнения. Без быстрых дисков, продуманной внутриузловой топологии и высокоскоростной сети они будут простаивать, а ваш бюджет — тратиться впустую. Как показывает практика, часто именно I/O, а не вычисления определяет реальную скорость обучения. И это справедливо как для суперкомпьютеров, так и для «земных» конфигураций на базе RTX 4090 и локальных NVMe.

И да, даже в условиях РФ с ограничениями на бюджеты можно строить эффективные AI-системы. Главное — понимать, где именно появляются узкие места, и фокусироваться на их устранении. Иногда достаточно перейти от миллионов мелких файлов к tar-шардам, правильно настроить RoCE или просто добавить второй NVMe в сервер — и загрузка GPU вырастет с 50 до 90%. А это значит, что модель обучится вдвое быстрее без покупки нового GPU.

А в вашей AI-инфраструктуре что-то тормозит? С какими узкими местами пришлось сталкиваться на практике и как вы их решили? Делитесь опытом и лайфхаками в комментариях ↓