Сервер для машинного обучения: требования

MAATRIX

Прежде чем заказывать сервер под машинное обучение, стоит честно ответить на один вопрос: вы собираетесь обучать модель или запускать уже готовую? Это два разных сценария с разными требованиями к железу, и если перепутать конфигурацию, либо переплатите за простаивающий GPU, либо упрётесь в нехватку памяти на середине обучения. Разберём, как считать требования под каждый сценарий, не выдумывая точных цифр там, где их нет.

Обучение и инференс — считайте раздельно

Обучение (training) — это процесс, в котором модель настраивает свои веса на данных: прямой проход, обратное распространение ошибки, обновление параметров оптимизатором. Это самая тяжёлая нагрузка на GPU: память тратится не только на веса модели, но и на градиенты, состояния оптимизатора и активации, которые нужно хранить для обратного прохода. Отсюда и высокие требования к VRAM, оперативной памяти и скорости диска.

Инференс (использование обученной модели) — намного легче. Нужен только прямой проход: загрузить веса в память и посчитать выход для входных данных. Градиенты и оптимизатор не нужны вообще, поэтому требования к VRAM падают в несколько раз по сравнению с обучением той же модели. Здесь же появляется вопрос, обязателен ли GPU — иногда достаточно процессора, если модель небольшая или скорость ответа не критична; подробнее о том, когда CPU оправдан, а когда нет, — в статье CPU или GPU для локальной LLM — что выгоднее.

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

VRAM для обучения: откуда берутся цифры

Грубая прикидка для полного дообучения (full fine-tuning) с оптимизатором Adam: на каждый параметр модели в памяти держат вес, градиент и два состояния оптимизатора. При весах в 16-битном формате (fp16/bf16) и состояниях оптимизатора в fp32 это ориентировочно 16–20 байт на параметр, плюс память под активации, которая растёт с длиной последовательности и размером батча. Это именно ориентир для прикидки порядка величины, а не точная формула — реальное потребление зависит от фреймворка, техник экономии памяти (gradient checkpointing, offloading) и конкретной архитектуры.

Отсюда практический вывод: модель на 7 млрд параметров при полном дообучении может потребовать несколько десятков гигабайт VRAM, модель на 13–14 млрд — уже заметно больше, а полное дообучение моделей на 30+ млрд параметров на одной карте практически нереально — нужны несколько GPU с быстрой связью (NVLink) и техники распределённого обучения.

Здесь на помощь приходит LoRA и другие методы parameter-efficient fine-tuning: вместо обновления всех весов модели дообучают небольшие дополнительные матрицы, а сама модель держится в памяти в замороженном виде (часто ещё и квантованной). Это на порядок снижает требования к VRAM и делает дообучение моделей в 7–13 млрд параметров доступным на одной потребительской карте с 24 ГБ памяти. Подробнее о самом методе — в статье про LoRA-дообучение своей модели на сервере.

Цифры в таблице — грубый ориентир для планирования, а не гарантия: у вас может выйти иначе в зависимости от длины контекста, батча и настроек фреймворка. Перед покупкой или арендой сервера прогоните короткий тест на меньшей конфигурации и посмотрите фактическое потребление памяти.

Инференс: сколько VRAM и когда хватит CPU

Для инференса ориентир проще: в первом приближении веса модели в памяти занимают примерно столько байт на параметр, в каком формате она загружена. Fp16/bf16 — около 2 байт на параметр, 8-битное квантование — около 1 байта, 4-битное — около 0,5 байта. К этому добавляется память под KV-кэш контекста, которая растёт с длиной диалога и числом одновременных запросов, — на неё стоит закладывать запас сверх веса самой модели.

Практически это означает, что модель на 7 млрд параметров в 4-битном квантовании помещается в 6–8 ГБ VRAM, та же модель в fp16 — уже в 14–16 ГБ, а модель на 70 млрд параметров даже в квантованном виде требует десятки гигабайт. Если карты с таким объёмом памяти нет, модель либо не запустится, либо часть слоёв уйдёт на CPU и сильно просядет по скорости.

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

Оперативная память и процессор

Оперативная память в ML-сервере решает две задачи: держит датасет (или его активную часть) для быстрой подачи в GPU и служит буфером при загрузке весов модели. Для инференса ориентируйтесь на объём, сопоставимый с размером модели в выбранном формате плюс запас на систему и сопутствующие процессы — то есть от 16–32 ГБ для небольших моделей до 64+ ГБ для крупных. Для обучения запас должен быть больше — от 64 ГБ, а при работе с объёмными датасетами, которые не помещаются целиком на GPU, 128–256 ГБ и выше избавляют от постоянного чтения с диска.

Процессор в связке с GPU редко становится узким местом сам по себе, но у него своя роль — предобработка данных, аугментация, формирование батчей, а на инференсе ещё и токенизация запросов. Если конвейер подготовки данных на CPU не успевает за GPU, дорогая видеокарта простаивает в ожидании следующего батча. Обычно достаточно 8–16 современных ядер, больше — если предобработка тяжёлая (например, декодирование видео или сложная аугментация изображений на лету).

NVMe: почему медленный диск убивает обучение

Обучение читает датасет циклами, эпоха за эпохой, и если данные не помещаются целиком в оперативную память, диск становится постоянным источником ввода-вывода. На классическом SSD или тем более HDD скорость случайного чтения мелких файлов (а датасеты часто состоят именно из множества небольших файлов — изображений, аудиофрагментов, текстовых сэмплов) может не поспевать за GPU, и вы платите за простаивающую видеокарту, которая ждёт данные вместо того, чтобы считать. Разница между SATA SSD и NVMe здесь не абстрактная — это разница в задержке и параллелизме операций ввода-вывода, которая прямо влияет на то, как часто GPU остаётся без работы; сравнение параметров — в статье SSD против NVMe в VPS.

Практический совет: под сам датасет и контрольные точки (чекпоинты) обучения закладывайте NVMe с запасом минимум в 2–3 раза больше объёма исходных данных — с учётом промежуточных копий, кэшей предобработки и версий чекпоинтов место кончается быстрее, чем кажется на старте проекта. Если датасет обновляется или растёт в процессе работы, это тоже нужно учитывать в объёме диска заранее, а не докупать место в последний момент.

Свой сервер или почасовая аренда GPU

Если вы экспериментируете, учитесь, дообучаете небольшие модели время от времени или тестируете гипотезу перед тем, как вкладываться в постоянную инфраструктуру, — честно говоря, покупать или арендовать мощный выделенный сервер на постоянной основе не нужно. Облачный GPU-инстанс на почасовой основе даёт доступ к серьёзному железу ровно на время расчётов, а простой между запусками ничего не стоит. Это почти всегда дешевле для нерегулярной нагрузки: подробнее в статье про GPU-сервер на арендованном GPU по часам.

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

Частые вопросы