Как выбрать сервер под локальный AI-инференс: CPU, GPU, VRAM, PCIe, питание и охлаждение

Сервер под локальный AI-инференс выбирают не по самой дорогой видеокарте, а по тому, помещаются ли модель, рабочий кэш и параллельные запросы в видеопамять, хватает ли процессора, линий PCIe, питания и охлаждения. Для небольшой модели и нескольких пользователей часто достаточно одного графического ускорителя с 24–48 ГБ видеопамяти. Для крупных языковых моделей, длинного контекста, кодовых ассистентов и десятков сотрудников уже нужен сервер с несколькими ускорителями, запасом по оперативной памяти, правильно подобранными блоками питания и рассчитанным воздушным потоком.

Локальный AI-инференс — это запуск уже обученной модели на собственном сервере. Модель не обучают с нуля, а используют для ответа на вопросы, анализа документов, генерации текста, распознавания речи, классификации заявок, поиска по базе знаний или обработки изображений. Такой подход выбирают, когда данные нельзя отправлять во внешние сервисы, нужна предсказуемая задержка внутри сети, важно контролировать стоимость или требуется независимость от сторонних API.

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

Сначала нужно определить задачу

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

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

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

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

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

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

Почему видеопамять важнее «мощности видеокарты»

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

Память расходуется по нескольким направлениям. Сама модель занимает место в зависимости от количества параметров и точности хранения. Сжатие уменьшает расход памяти, но может повлиять на качество ответов или скорость. Длинный контекст увеличивает кэш. Параллельные пользователи увеличивают общий объем временных данных. Поэтому расчет вида «модель весит 20 ГБ, значит карты на 24 ГБ хватит» часто оказывается слишком оптимистичным.

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

Особенно важно учитывать кэш. При генерации ответа модель хранит промежуточные данные, чтобы не пересчитывать весь контекст заново. В документации vLLM показано, что объем памяти под кэш связан с количеством параллельных запросов и размером батча: при нехватке памяти приходится уменьшать параллельность или менять настройки использования GPU-памяти. Это напрямую влияет на задержку и пропускную способность сервиса.

Эта таблица не заменяет тестирование, но помогает не начинать с неверного класса сервера. Если планируется модель 70B, длинный контекст и несколько сотрудников одновременно, сервер с одной картой на 24 ГБ не станет надежной основой. Если задача — классификация коротких заявок, покупка тяжелой многокарточной платформы может быть избыточной.

Роль CPU: когда процессор важен, а когда нет

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

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

При выборе CPU важны не только ядра. Нужно смотреть на поколение PCIe, число линий, количество каналов памяти, поддержку нужного объема ОЗУ и особенности двухпроцессорной платформы. Для одной GPU обычно достаточно разумного серверного процессора среднего класса. Для нескольких ускорителей, быстрых NVMe-дисков и сетевых карт уже нужна платформа с достаточным числом линий PCIe.

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

Как выбирать GPU под инференс

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

Для умеренного инференса подходят энергоэффективные серверные карты. Например,NVIDIA L4 имеет 24 ГБ видеопамяти, низкопрофильный форм-фактор, подключение PCIe Gen4 x16 и максимальное энергопотребление 72 Вт. Это хороший класс для небольших моделей, видеоаналитики, поиска по документам и внутренних сервисов с умеренной нагрузкой.

Для более тяжелых задач часто смотрят на карты с 48 ГБ видеопамяти.NVIDIA L40S — пример такого класса: 48 ГБ памяти GDDR6 с ECC, PCIe Gen4 x16 и максимальное потребление 350 Вт. Такой ускоритель дает больше запаса для моделей 7–14B, части 30B-сценариев, мультимодальных задач и нескольких сервисов на одном сервере.

Старший класс с 80 ГБ и выше нужен для крупных моделей, длинного контекста, высокой параллельности и жестких требований к задержке. Но здесь уже нельзя выбирать только карту. Нужно смотреть на серверную платформу, внутреннюю связь между ускорителями, питание, стойку, охлаждение и стоимость владения. Чем больше GPU в сервере, тем выше риск, что ограничением станет не сама карта, а корпус, линии PCIe, температура или электропитание.

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

PCIe-линии: скрытое ограничение нескольких GPU

PCIe — это шина подключения, через которую процессор, GPU, NVMe-диски и сетевые карты обмениваются данными. В характеристиках сервера часто указывают физические слоты, но физический слот x16 не всегда означает, что устройство получает все 16 линий. При установке нескольких GPU, быстрых дисков и сетевых адаптеров линии распределяются между устройствами.

Для одной карты это не всегда критично. Когда модель уже загружена в видеопамять, генерация ответа может меньше зависеть от PCIe, чем от самой GPU-памяти и вычислений. Но PCIe становится важен при загрузке модели, работе с несколькими ускорителями, передаче данных, обслуживании множества пользователей, быстрых NVMe-дисках и сетях 25/100 Гбит/с.

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

Перед покупкой нужно проверить четыре вещи: сколько линий PCIe дает процессорная платформа, как они разведены по слотам, какие слоты заняты дисками и сетью, какие ограничения есть у конкретного корпуса. Особенно это важно для серверов, куда одновременно ставятся 2–4 GPU, несколько NVMe-дисков и быстрый сетевой адаптер.

Оперативная память, диски и сеть

Оперативная память нужна не только «для операционной системы». В AI-сервере она используется приложением, контейнерами, очередями, векторной базой, кэшем, документами и возможной выгрузкой части данных из GPU. Для тестового сервера можно начинать со 128–256 ГБ ОЗУ. Для рабочего сервиса с поиском по документам лучше закладывать 256–512 ГБ и больше, если база растет или на сервере запускается несколько компонентов.

Диски тоже нельзя выбирать по остаточному принципу. NVMe-накопители ускоряют загрузку моделей, хранение нескольких версий, работу с индексами, логами и документами. В системах поиска по корпоративным файлам объем данных быстро растет: сначала это несколько инструкций и PDF, затем архивы писем, базы знаний, договоры, презентации и выгрузки из внутренних систем. Медленные диски в такой схеме могут ухудшить не саму генерацию, а подготовку ответа.

Сеть зависит от того, где находится сервер и кто им пользуется. Для одиночного внутреннего чат-бота может хватить обычной сети. Для сервиса, который принимает большие документы, изображения, видео или обслуживает несколько внутренних систем, стоит планировать 10/25 Гбит/с и выше. Если сервер подключен к хранилищу или используется несколькими командами, сеть может стать таким же ограничителем, как GPU.

Питание: считать нужно весь сервер

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

Важно проверить, какие блоки питания поддерживает конкретный сервер, при каком напряжении они отдают полную мощность и какая схема резервирования нужна. Для плотных GPU-серверов может потребоваться 200–240 В, отдельная линия питания, подходящий блок распределения питания в стойке и ИБП. Если сервер ставится не в дата-центр, а в офисную серверную, этот пункт нужно проверять особенно внимательно.

Питание напрямую связано с теплом. Почти вся потребленная электрическая мощность превращается в тепловыделение. Если сервер потребляет 1,5–2 кВт, это уже не «просто шумная машина под столом», а серьезная нагрузка на помещение. Нужно заранее понимать, куда уйдет тепло, выдержит ли кондиционирование и не будет ли сервер постоянно снижать производительность из-за температуры.

Охлаждение: совместимость по слоту еще ничего не гарантирует

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

Обратная ситуация — установка потребительской карты с открытым охлаждением в плотный сервер. Она может выбрасывать горячий воздух внутрь корпуса, мешать соседним картам и нарушать штатный воздушный поток. В 1U, 2U и 4U серверах возможности охлаждения разные. Чем плотнее корпус, тем жестче требования к вентиляторам, кожухам, заглушкам, радиаторам процессоров и допустимой температуре воздуха на входе.

Производители серверов обычно указывают ограничения для GPU не просто по модели карты, а по всей конфигурации. В документации Dell для PowerEdge R750, например, GPU-конфигурации зависят от типа вентиляторов, кожуха, радиатора, дисковой конфигурации и температуры; отдельные варианты с GPU вообще не поддерживаются при определенных корзинах накопителей. Это хороший пример того, почему нельзя выбирать сервер только по числу слотов PCIe.

Для AI-инференса охлаждение нужно считать как часть надежности. Перегрев не всегда приводит к мгновенному отказу. Иногда он проявляется хуже: сервер становится громче, карта снижает частоты, ответы замедляются, летом появляются нестабильные ошибки. Если сервис должен работать постоянно, запас по охлаждению так же важен, как запас по видеопамяти.

Как количество пользователей влияет на конфигурацию

Количество пользователей влияет не линейно. Важны не только «запросы в минуту», но и длина входного текста, длина ответа, число одновременных сессий и допустимая задержка. Один пользователь может отправить большой документ и создать нагрузку выше, чем пять коротких вопросов.

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

Например, модель класса 14B может нормально работать на одной карте с 48 ГБ видеопамяти для нескольких сотрудников. Но если те же сотрудники начнут загружать длинные документы, использовать поиск по базе знаний и ждать длинные ответы одновременно, запас быстро закончится. Сервер останется тем же, модель той же, но реальная нагрузка станет другой.

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

Готовые ориентиры конфигураций

Для прототипа, тестов и одного-двух пользователей можно начинать с одного ускорителя на 16–24 ГБ видеопамяти, 128–256 ГБ оперативной памяти и NVMe-диска. Такой сервер подойдет для небольших моделей, тестового поиска по документам, экспериментов с сжатием и проверки бизнес-сценария. Он не подойдет для тяжелых моделей, длинного контекста и большого числа пользователей.

Для небольшой команды практичнее смотреть на одну серверную GPU с 24–48 ГБ видеопамяти, 256–512 ГБ ОЗУ, быстрые NVMe-диски и сеть 10/25 Гбит/с. Это рабочий класс для внутренних чат-ботов, RAG-систем, анализа документов и умеренного числа пользователей. Лучше иметь запас по видеопамяти, чем постоянно уменьшать длину контекста и параллельность.

Для серьезного внутреннего AI-сервиса нужен сервер с 2–4 ускорителями, достаточным числом PCIe-линий, 512 ГБ–1 ТБ ОЗУ, быстрыми дисками и продуманным питанием. Такая конфигурация нужна, если запускается несколько моделей, есть кодовый ассистент, длинный контекст, параллельные пользователи и требования к стабильной задержке.

Для крупных моделей и высокой нагрузки обычно рассматривают специализированные GPU-серверы с 4–8 ускорителями старшего класса. Здесь уже важна не только покупка железа, но и подготовка стойки, электропитания, охлаждения, мониторинга и обслуживания. Такой сервер нельзя ставить «по остаточному принципу» в обычную комнату.

Стоимость владения: почему дешевый GPU может стать дорогим решением

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

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

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

Частые ошибки при выборе сервера

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

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

Третья ошибка — не учитывать длину контекста. Короткий вопрос и большой документ с длинным ответом создают разную нагрузку на одну и ту же модель. Если пользователи будут загружать договоры, инструкции, код или отчеты, память нужно считать с запасом.

Четвертая ошибка — ставить неподходящую карту в неподходящий корпус. Серверная пассивная GPU требует направленного воздушного потока. Потребительская карта может плохо работать в плотном сервере. Совместимость по слоту не равна совместимости по теплу.

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

Шестая ошибка — недооценивать питание. Блоки питания должны выдерживать не только номинальную нагрузку, но и пики, резервирование и будущие расширения. Отдельно нужно проверять напряжение, PDU и ИБП.

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

Финальный алгоритм выбора

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

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

После GPU проверяется платформа: процессор, количество линий PCIe, слоты, riser-карты, место под NVMe-диски и сетевые адаптеры. Затем подбираются оперативная память, диски и сеть. После этого нужно проверить питание: мощность блоков, резервирование, напряжение, PDU и ИБП. Отдельно проверяется охлаждение: корпус, вентиляторы, кожухи, радиаторы, температура на входе и шум.

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