Запуск искусственного интеллекта требует не только вычислительного ускорителя. Для обучения и работы современных моделей нужна целая инфраструктура: серверы, GPU, оперативная память, хранилище, сеть и программное окружение.
При этом универсальной конфигурации для ИИ не существует. Сервер для запуска локальной LLM, инфраструктура для RAG-системы, платформа для дообучения модели и кластер для распределенного обучения предъявляют совершенно разные требования к оборудованию.
Для небольших моделей может быть достаточно одного GPU-сервера. При работе с крупными моделями и распределённым обучением используются многокарточные серверы и GPU-кластеры, связанные высокоскоростной сетью.
Поэтому инфраструктуру для ИИ правильнее подбирать не от характеристик конкретной видеокарты, а от задачи: что нужно обучать или запускать, какого размера модель, сколько пользователей будет работать с ней и какой производительности требуется достичь.
Инфраструктура для искусственного интеллекта (AI infrastructure) - это совокупность вычислительных, сетевых, дисковых и программных ресурсов, необходимых для разработки, обучения, запуска и масштабирования моделей машинного обучения.
В типичную инфраструктуру входят:
Упрощенно архитектуру можно представить следующим образом:
AI-инфраструктура → Compute → GPU → CPU/RAM → Storage → Network → Software → Orchestration
Каждый компонент отвечает за свою часть нагрузки. Быстрый GPU не компенсирует недостаток VRAM, медленное хранилище или узкую сеть. Аналогично, большой объём оперативной памяти не заменяет память GPU, если модель и вычисления должны выполняться на ускорителе.
Перед выбором сервера необходимо определить, для какой задачи он будет использоваться.
Во время обучения модель многократно обрабатывает данные и изменяет свои параметры. Для больших моделей это одна из наиболее ресурсоёмких задач.
Здесь особенно важны:
При распределенном обучении вычисления могут выполняться одновременно на нескольких GPU и серверах. PyTorch поддерживает распределенное обучение через различные механизмы, включая DistributedDataParallel, FSDP и Tensor Parallelism. Для CUDA GPU в распределенных сценариях широко используется NCCL.
Fine-tuning позволяет адаптировать уже существующую модель под конкретную задачу или набор данных.
Требования к инфраструктуре обычно ниже, чем при обучении большой модели с нуля, особенно при использовании методов параметрически эффективного дообучения, например LoRA.
Но GPU все равно остается ключевым ресурсом, а объём необходимой VRAM зависит от размера модели, выбранного метода обучения, precision, batch size и других параметров.
Inference (инференс) — выполнение уже обученной модели для получения результата.
Например:
Для инференса не обязательно использовать такую же инфраструктуру, как для обучения. Если обучение может потребовать большое количество GPU, для работы готовой модели иногда достаточно одного или нескольких ускорителей.
Здесь важны не только вычислительная мощность, но и:
Большие языковые модели предъявляют особые требования к памяти.
При запуске LLM в памяти должны находиться веса модели, а во время генерации дополнительно используется память для промежуточных данных, в том числе KV cache.
Поэтому при выборе GPU для LLM важно смотреть не только на вычислительную производительность, но и на объём доступной VRAM.
RAG (Retrieval-Augmented Generation) объединяет языковую модель с поиском по внешним данным.
Типичная RAG-система может включать:
Документы → обработка → embeddings → векторная база → поиск → LLM → ответ пользователю
Поэтому для RAG нужна не только GPU.
В зависимости от архитектуры используются:
GPU-сервер это не просто обычный сервер с установленной видеокартой.
При проектировании инфраструктуры необходимо учитывать сразу несколько компонентов.
GPU является основным вычислительным ускорителем для многих задач глубокого обучения.
Архитектура GPU рассчитана на выполнение большого количества параллельных операций, что хорошо соответствует вычислениям, характерным для нейронных сетей. CUDA, например, предоставляет платформу и модель программирования для выполнения вычислений на GPU и широко используется для глубокого обучения.
CPU отвечает за задачи, которые не выполняются непосредственно на GPU:
Поэтому сервер с мощными GPU, но слабой или неправильно подобранной CPU-подсистемой может не раскрывать возможности ускорителей.
Оперативная память используется для:
RAM и VRAM — разные ресурсы.
RAM находится в системе и используется CPU, а VRAM — непосредственно память GPU.
Если модели или промежуточные данные не помещаются в VRAM, простое наличие большого объёма RAM не означает, что GPU сможет эффективно работать с ними без дополнительных операций обмена данными.
VRAM — один из наиболее важных параметров GPU для ИИ.
В ней могут находиться:
Именно поэтому две видеокарты с близкой вычислительной производительностью могут иметь совершенно разную пригодность для конкретной модели.
Если веса модели занимают больше памяти, чем доступно на одном ускорителе, просто запустить ее в обычном режиме не получится. Потребуется другая GPU, квантование или распределение модели между несколькими ускорителями.
Универсального ответа в формате «для модели определенного размера нужна GPU с X ГБ» нет.
Потребление памяти зависит как минимум от:
Для инференса основными компонентами потребления VRAM становятся:
веса модели + KV cache + служебная память + промежуточные данные.
Для обучения добавляются:
веса + активации + градиенты + состояние оптимизатора + служебные данные.
Поэтому обучение модели требует значительно больше памяти, чем простой запуск той же модели на инференс.
Варианты зависят от задачи:
В распределенных сценариях несколько ускорителей могут работать совместно. Однако это уже требует правильно спроектированной аппаратной и сетевой инфраструктуры.
Сосредоточенность на GPU часто приводит к ошибке: остальные компоненты сервера выбираются по остаточному принципу.
На практике CPU и RAM могут существенно влиять на производительность всей системы.
Перед тем как данные попадут на GPU, они могут пройти несколько этапов:
Storage → RAM → CPU → подготовка данных → GPU
Если CPU не успевает подготовить данные, ускоритель может простаивать.
Большие наборы данных, индексы, кэши и приложения могут потреблять значительный объем оперативной памяти.
Для RAG CPU и RAM также могут иметь большое значение, поскольку сама генерация текста только часть системы. Поиск документов, обработка запросов, embeddings, базы данных и сервисная логика тоже требуют ресурсов.
Для GPU-сервера важна не только сама видеокарта, но и способ ее подключения.
GPU взаимодействует с CPU и другими устройствами через высокоскоростную шину, в современных серверах обычно PCI Express.
При конфигурации с несколькими ускорителями необходимо учитывать:
Если в сервер устанавливается несколько мощных GPU, конфигурация материнской платы и CPU должна поддерживать такую плотность устройств.
Высокопроизводительные GPU потребляют значительно больше энергии, чем обычные компоненты серверной системы.
Поэтому при проектировании необходимо учитывать:
Конфигурация с несколькими GPU может потребовать значительно больше электрической мощности и охлаждения, чем обычный двухпроцессорный сервер.
Это одна из причин, почему GPU-инфраструктура должна проектироваться как единая система, а не как набор отдельных комплектующих.
Хранилище в AI-инфраструктуре выполняет сразу несколько функций.
На нем могут находиться:
При этом для разных данных оптимальны разные типы хранения.
Высокопроизводительные NVMe-накопители подходят для задач, где важны скорость доступа и высокая пропускная способность.
Например:
Особенно важна скорость хранения, когда GPU постоянно получает большие объёмы данных.
Если хранилище не успевает отдавать данные, часть вычислительного потенциала ускорителей может простаивать.
Объектное хранилище удобно использовать для больших объемов данных:
S3-совместимые хранилища часто используются как отдельный слой AI-инфраструктуры, отделённый от локального быстрого storage.
Такую архитектуру можно представить следующим образом:
GPU-сервер → быстрый NVMe → рабочие данные
GPU-сервер → Object Storage → datasets / модели / архивы / backup
Это позволяет не хранить весь объем данных непосредственно на локальных дисках каждого GPU-сервера.
Для AI-инфраструктуры не обязательно хранить абсолютно все данные на NVMe.
HDD может использоваться для:
Поэтому оптимальная архитектура часто состоит из нескольких уровней:
NVMe → быстрые рабочие данные
SSD/HDD → основной объем
Object Storage → централизованные datasets и архивы
На одном сервере сеть может казаться второстепенным компонентом.
В GPU-кластере ситуация меняется.
Если несколько серверов одновременно обучают одну модель, им необходимо постоянно обмениваться данными. В результате сеть становится частью вычислительной инфраструктуры.
При распределенном обучении используются коллективные операции, например all-reduce, all-gather и reduce-scatter. PyTorch поддерживает такие операции через torch.distributed, а для CUDA GPU рекомендует NCCL.
Ethernet может использоваться для:
Скорость сети выбирается исходя из нагрузки.
В небольших конфигурациях может быть достаточно 10 или 25 GbE. В более производительных системах используются 100 GbE и выше.
Но сама цифра скорости не является универсальным требованием. Необходимо учитывать объём передаваемых данных, количество GPU, архитектуру приложения и характер нагрузки.
InfiniBand применяется в высокопроизводительных вычислительных системах и GPU-кластерах, где требуется очень быстрая связь между узлами.
Для распределённого обучения PyTorch поддерживает работу NCCL с InfiniBand и GPUDirect, что позволяет строить высокопроизводительные коммуникационные схемы между GPU-серверами.
Однако InfiniBand нужен не каждому AI-серверу.
Для одного GPU-сервера или небольшой системы инференса обычного Ethernet может быть вполне достаточно.
Высокоскоростная специализированная сеть становится особенно актуальной при масштабировании распределённых вычислений.
Аппаратного сервера недостаточно.
Между GPU и приложением находится программный стек.
Упрощенно он выглядит так:
Linux → драйвер GPU → CUDA → библиотеки → Docker → AI framework → модель → приложение
Большинство серверных AI-систем работают на Linux благодаря поддержке GPU, контейнеров, драйверов и инструментов машинного обучения.
CUDA предоставляет программную платформу для разработки и запуска GPU-ускоренных приложений. В экосистему входят библиотеки, инструменты разработки, профилирования и другие компоненты, необходимые для работы GPU-приложений.
Для приложений на базе NVIDIA GPU совместимость версий драйвера, CUDA и используемого фреймворка является важной частью инфраструктуры.
Контейнеры позволяют упаковать приложение вместе с зависимостями и сделать окружение воспроизводимым.
Для AI это особенно полезно, поскольку конкретное приложение может зависеть от:
Фреймворк предоставляет разработчику инструменты для создания и запуска моделей.
В инфраструктуре могут использоваться:
При этом конкретный стек зависит от модели и приложения.
Если компании нужно запустить одну LLM на одном GPU-сервере, Kubernetes может быть избыточным.
Но при увеличении инфраструктуры он становится полезнее.
Например, когда появляются:
Kubernetes имеет механизм device plugins, который позволяет подключать специализированные ресурсы, включая GPU, высокопроизводительные сетевые устройства и другие аппаратные ускорители. Поддержка GPU в Kubernetes является стабильной функцией.
Таким образом:
один GPU-сервер → Kubernetes обычно не обязателен
GPU-кластер → Kubernetes может существенно упростить управление ресурсами и сервисами
Обучение модели предъявляет максимальные требования к вычислительной части.
Типовая архитектура может выглядеть так:
В небольшой системе все GPU могут находиться в одном сервере.
При увеличении нагрузки используются несколько узлов. PyTorch поддерживает как многокарточное обучение внутри одного узла, так и распределённое обучение между несколькими узлами.
В такой архитектуре критичны:
Инфраструктура для inference устроена иначе.
Задача здесь не в том, чтобы обучить модель, а в том, чтобы быстро и стабильно обслуживать запросы.
Упрощенная архитектура:
Для inference важны:
Для внутреннего AI-ассистента с десятком пользователей и для публичного сервиса с тысячами одновременных запросов потребуются совершенно разные архитектуры.
Требования лучше всего оценивать не по названию модели, а по сценарию использования.
|
Задача |
Вычисления |
Хранилище |
Сеть |
|
Запуск небольшой LLM |
1 GPU или несколько GPU |
NVMe |
10/25 GbE |
|
RAG-система |
GPU + CPU |
NVMe + Object Storage |
10/25 GbE |
|
Fine-tuning |
1 или несколько GPU |
быстрый NVMe |
25/100 GbE |
|
Распределенное обучение |
GPU-кластер |
NVMe + Object Storage |
100 GbE и выше / специализированная сеть |
|
Массовый inference |
несколько GPU-серверов |
NVMe + централизованное storage |
25/100 GbE и выше |
Это не универсальные требования к оборудованию, а ориентир для первоначального проектирования. Реальная конфигурация зависит от размера модели, precision, batch size, количества пользователей, объема данных и архитектуры приложения.
Не каждому AI-проекту нужен GPU-сервер.
GPU может не потребоваться, если:
Например, AI-агент может использовать внешний API модели, а на собственном сервере запускать:
В таком случае достаточно CPU, RAM и NVMe.
Если же необходимо самостоятельно запускать требовательную локальную модель, стоит рассматривать GPU-сервер.
Выбор зависит от масштаба задачи.
| Сценарий | Один GPU-сервер | GPU-кластер |
|---|---|---|
| Разработка AI | ✓ | |
| Эксперименты | ✓ | |
| Небольшая LLM | ✓ | |
| RAG | ✓ | |
| Небольшой inference | ✓ | |
| Большое количество запросов | возможно | ✓ |
| Большая модель | возможно | ✓ |
| Распределённое обучение | ✓ | |
| Большие вычислительные задачи | ✓ | |
| Высокая отказоустойчивость | возможно | ✓ |
Для небольшой команды один хорошо подобранный GPU-сервер часто оказывается проще и рациональнее полноценного кластера.
Подбор оборудования удобно выполнять последовательно.
Training, fine-tuning, inference, RAG или другая AI-нагрузка.
Нужно знать:
Учитываются:
веса модели + KV cache + runtime + промежуточные данные
Для обучения дополнительно:
активации + градиенты + состояние оптимизатора
После оценки памяти и производительности становится понятно, достаточно ли одной GPU или требуется несколько ускорителей.
CPU должен успевать обрабатывать данные и обслуживать GPU, а RAM — обеспечивать работу приложений, datasets, баз данных и кэшей.
Разделить данные на:
Для одного сервера достаточно обычной серверной сети.
Для GPU-кластера необходимо отдельно оценить межсерверный трафик, storage traffic и пользовательские подключения.
Необходимо заранее понять:
Перед развертыванием необходимо проверить связку:
GPU → драйвер → CUDA → framework → библиотеки → модель → приложение
Одна из распространенных ошибок - выбирать сервер только по GPU.
На практике проблемы могут возникнуть из-за:
Поэтому AI-инфраструктуру нужно рассматривать как единую систему.
Для корпоративного AI-сервиса инфраструктура может выглядеть следующим образом:
Для небольшой компании несколько компонентов могут находиться на одном сервере.
По мере роста нагрузки инфраструктуру можно разделить:
AI-инфраструктура это не один мощный сервер, а набор взаимосвязанных компонентов.
GPU обеспечивает основную вычислительную мощность, VRAM определяет, какие модели и задачи можно разместить на ускорителе, CPU и RAM обеспечивают работу приложений и подготовку данных, NVMe и объектное хранилище отвечают за данные и модели, а сеть связывает вычислительные узлы и системы хранения.
