LLM Требования к серверу: GPU VRAM, RAM и хранение по размеру модели

LLM требования к серверу начинаются с точной рабочей нагрузки вывода: количества параметров, точности веса, формата квантования, длины контекста, поведения пакета, одновременных запросов и целевой задержки. Веса моделей являются лишь первым VRAM потребителем. Кэш KV, рабочие области времени выполнения, ядра и фрагментация могут определить, подходит ли модель и сколько запросов она может обслужить.

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

Используйте требования к серверу LLM в качестве рабочего процесса планирования: определите рабочую нагрузку, соберите нормальный и пиковый базовый уровень, определите первый ограничивающий ресурс, составьте список двух жизнеспособных проектов и протестируйте их с использованием производственных данных. Сохраняйте предположения видимыми, чтобы будущий обзор мог обновить модель без повторного открытия.

Коммерческие варианты, упомянутые в этом руководстве: серверы AI (https://unihost.com/dedicated/ai-servers/); Серверы GPU (https://unihost.com/dedicated/gpu/); выделенные серверы (https://unihost.com/dedicated/)

Связанное чтение Unihost: руководство по аппаратному обеспечению сервера AI (https://unihost.com/blog/ai-servers-2025-hardware/); CPU против GPU против RAM для ИИ (https://unihost.com/blog/choosing-server-specs-ai/); GPU серверы для искусственного интеллекта и машинного обучения (https://unihost.com/blog/gpu-dedicated-servers-for-ai-machine-learning/)

LLM требования к серверу для вывода и обучения

Обучение сохраняет веса, градиенты, состояние оптимизатора и активации, поэтому его требования к памяти и коммуникации намного больше, чем логические выводы. Вывод в первую очередь содержит веса и состояние времени выполнения, но длинные контексты и высокий уровень параллелизма могут сделать кэш KV существенным. Сервер, рассчитанный на один интерактивный запрос, может выйти из строя как общий API.

Собирайте формат модели, токены на запрос, длину контекста, размер пакета, параллельные последовательности, время до первого токена, токены в секунду и использование GPU во время обычного трафика и во время репрезентативного пика. Совместите временные метки инфраструктуры с трассировками приложений, чтобы команда могла связать медленный запрос или неудачное задание с ресурсом, который был ограничен. Средние значения полезны для планирования затрат, но p95, p99 и рост очереди показывают, наносят ли уже короткие всплески вреда службе.

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

Возможности также должны охватывать техническое обслуживание и поведение при отказах. Зарезервируйте достаточно места для мониторинга, ротации журналов, сканирования безопасности, резервного копирования и временной потери узла, когда архитектура обещает непрерывность. Этот резерв не является фиксированным процентом: извлеките его из сценария отказа и явно отобразите на рабочем листе.

Как параметры, точность и квантование влияют на VRAM для LLM

Вес памяти равен примерно количеству параметров, умноженному на байты на каждый параметр. FP16 или BF16 использует около двух байтов на параметр, 8-битный – около одного, а 4-битный – около половины байта без учета служебных данных формата. Квантование уменьшает вес памяти, но качество, поддержку ядра и скорость необходимо тестировать с выбранной средой выполнения.

Создайте базовый уровень на основе количества параметров, формата хранения, веса нагрузки, рабочей области времени выполнения, KV-кэша на последовательность и фрагментации. Записывайте одни и те же сигналы до и после каждой настройки или изменения инфраструктуры. Если пропускная способность возрастает, а задержка и ошибки остаются под контролем, это изменение создает полезную емкость. Если очереди растут или задержка увеличивается, значит, система достигла предела, даже если один из основных показателей использования все еще выглядит удовлетворительным.

Рассчитайте теоретический минимальный вес, добавьте измеренные издержки времени выполнения, а затем зарезервируйте VRAM для целевого контекста и параллелизма. Следите за тем, чтобы размер файла модели рассматривался как общее требование VRAM или предполагалось, что каждый 4-битный формат имеет одинаковые накладные расходы. Перед заказом или миграцией используйте загрузку точного квантованного артефакта в производственный механизм и выполнение самых длинных ожидаемых запросов. Документированный критерий отклонения так же важен, как и критерий успеха, поскольку он сообщает команде, когда следует остановить развертывание или перейти на следующий уровень мощности.

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

Таблица размеров AI-серверов по классам моделей

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

Используйте фактическое распределение VRAM при простое и под нагрузкой, рост кэша KV, пакетную занятость и события нехватки памяти в качестве модели небольшой емкости, а не снимка информационной панели. Разделите устойчивый спрос, плановую работу и исключительные пики. Модель должна объяснять, какой ресурс насыщается первым, как долго длится это насыщение и какой клиентский или операционный результат меняется в этот момент.

Выберите наименьший класс GPU с задержкой и параллелизмом после проверки, затем сохраните проверенный путь к более крупному или множественному профилю GPU. Проект по-прежнему может потерпеть неудачу, если вы купите VRAM только для загрузки модели без места для производственных запросов. Докажите предполагаемое поведение с помощью линейного уровня параллелизма с максимальными ограничениями контекста и вывода. Включите в тест мониторинг, резервное копирование и средства контроля безопасности, поскольку производственные издержки не должны появляться в первый раз после запуска.

Стоимость должна быть привязана к единице успешной работы, такой как заказ, запрос, завершенное задание, восстановленный терабайт или принятый ответ модели. Такое представление не позволяет дешевой конфигурации выиграть, когда она не достигает целевого показателя задержки или восстановления, а также не позволяет рассматривать неиспользованный запас мощности как бесплатный.

Диапазоны планирования для квантованного LLM VRAM

Просмотр серверов GPU с поддержкой искусственного интеллекта

CPU, системные RAM, NVMe и сетевые требования

GPU не устраняет необходимость в сбалансированном хосте. CPU занимается токенизацией, маршрутизацией запросов и предварительной обработкой. Система RAM содержит файлы моделей, страничный кэш, разгрузку CPU и несколько рабочих процессов. NVMe для ИИ сокращает загрузку модели и поддерживает векторные индексы или наборы данных. Сеть имеет значение для трафика API, распределения моделей и связи между несколькими узлами.

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

Предотвратите хост от голодания вывода GPU путем сопоставления CPU дорожек, RAM каналов, PCIe топологии и хранилища со счетом ускорителя. Не игнорируйте сочетание дорогого GPU со слишком маленькой системой [[[ZTT000090]]), медленным хранилищем или недостаточной возможностью подключения PCIe. Подтвердите рекомендацию с помощью холодного запуска, перезагрузки модели, одновременного запроса и тестов приема данных. Запишите, какое предположение имеет наименьшую достоверность, и сначала повторно проверьте это предположение при изменении трафика, данных или программного обеспечения.

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

Одиночный GPU против нескольких GPU и параллелизма

Одиночный GPU проще и часто обеспечивает наилучшую задержку, когда модель подходит. Multi-GPU необходим, когда веса и состояние времени выполнения превышают одно устройство или когда пропускная способность требует большего количества реплик. Тензорный параллелизм, конвейерный параллелизм и независимые реплики имеют разные затраты на межсоединение и планирование.

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

Предпочитайте независимые реплики для обеспечения пропускной способности, когда модель соответствует одной GPU; используйте параллелизм моделей, когда этого требует объем памяти. Самой дорогостоящей ошибкой было бы добавление графических процессоров без механизма, который эффективно масштабируется, или без достаточной CPU и пропускной способности сети для их питания. Уменьшите эту неопределенность с помощью одного GPU и нескольких GPU тестов с одинаковым качеством, контекстом и параллелизмом. Сохраняйте путь обновления или отката, который не зависит от уже ограниченного компонента.

Возможности также должны охватывать техническое обслуживание и поведение при отказах. Зарезервируйте достаточно места для мониторинга, ротации журналов, сканирования безопасности, резервного копирования и временной потери узла, когда архитектура обещает непрерывность. Этот резерв не является фиксированным процентом: извлеките его из сценария отказа и явно отобразите на рабочем листе.

Примеры профилей для разработки, производства API и высокого параллелизма

Профиль разработки благоприятствует гибкости и достаточному количеству VRAM для выбранной квантовой модели. В рабочей версии API добавляется ECC, где это возможно, запас мощности, мониторинг и определенная стратегия репликации. Вывод с высоким параллелизмом отдает приоритет агрегату VRAM, пропускной способности памяти, эффективной пакетной обработке, управлению очередями и изоляции сбоев. Сервер GPU для вывода следует выбирать с учетом измеренного количества токенов в секунду, времени до первого токена и параллелизма в предполагаемом формате модели.

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

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

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

Эталонные профили вывода

Сравните серверы AI (https://unihost.com/dedicated/ai-servers/) и серверы GPU (https://unihost.com/dedicated/gpu/).

Контрольный список затрат, конфиденциальности данных и управления

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

Собирайте стоимость за принятый ответ, использование GPU, часы простоя, инцидентную нагрузку, возраст исправлений, события доступа и сохранение данных во время обычного трафика и во время типичного пика. Совместите временные метки инфраструктуры с трассировками приложений, чтобы команда могла связать медленный запрос или неудачное задание с ресурсом, который был ограничен. Средние значения полезны для планирования затрат, но p95, p99 и рост очереди показывают, наносят ли уже короткие всплески вреда службе.

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

Стоимость должна быть привязана к единице успешной работы, такой как заказ, запрос, завершенное задание, восстановленный терабайт или принятый ответ модели. Такое представление не позволяет дешевой конфигурации выиграть, когда она не достигает целевого показателя задержки или восстановления, а также не позволяет рассматривать неиспользованный запас мощности как бесплатный.

Запросить конфигурацию рабочей нагрузки AI

Часто задаваемые вопросы

Сколько VRAM нужно для LLM?

Начните с количества параметров, умноженного на байты на каждый параметр, затем добавьте рабочую область среды выполнения и кэш KV для контекста и параллелизма. 4-битная модель использует примерно полбайта на каждый параметр без учета служебных данных формата. Проверьте точную модель и двигатель, поскольку практическое распределение может отличаться.

Может ли LLM работать только на CPU?

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

Сколько RAM требуется для самостоятельного вывода?

Система RAM должна охватывать OS, файлы модели, страничный кэш, разгрузку CPU, предварительную обработку и рабочие процессы. Многие проекты с одним GPU начинаются с 64-128 ГБ, тогда как для более крупных или многоGPU систем может потребоваться 256 ГБ или больше. Измерьте пиковое распределение хостов во время реалистичного параллелизма.

Когда необходим мульти-GPU сервер?

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