Выделенный сервер для локальной LLM: SPHINX или PYRAMID для инференса и обучения

MAATRIX · Выделенные серверы · Статья 4 из 48

В мечтах собственная нейросеть появляется примерно так: арендуем серьёзный сервер, загружаем модель, даём ей корпоративные документы — и получаем терпеливого сотрудника, который помнит всё и не уходит в отпуск. На практике первый вечер нередко заканчивается долгим ожиданием ответа. Модель уже работает. Просто слово «работает» оказалось гораздо вместительнее, чем хотелось.

Выбирая между SPHINX и PYRAMID, полезно сразу увидеть главное: в описании обоих тарифов видеокарта не указана. Это серверы с центральными процессорами. На них можно запускать языковые модели, готовить данные и строить собственные сервисы, но покупать их для обучения большой LLM без предварительного расчёта — слишком дорогой способ познакомиться с терпением.

Разберём, какую работу этим машинам стоит поручить и за что именно вы платите при переходе со SPHINX на PYRAMID.

Инференс, дообучение и RAG требуют разных ресурсов

За просьбой «нужен сервер для нейросети» могут скрываться совершенно разные проекты.

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

Второй — дообучение. Готовую модель дополнительно настраивают на определённых примерах: учат выдерживать формат, лучше решать узкую задачу, следовать нужному стилю. Методы вроде LoRA уменьшают объём обучаемых параметров, однако вычисления и память всё равно требуются. Само слово «лёгкое» в названии подхода не превращает любую конфигурацию в удобную учебную площадку.

Третий — обучение с нуля или полное дообучение крупной модели. Помимо её весов приходится хранить дополнительные данные, необходимые для изменения этих весов: градиенты, состояния оптимизатора, промежуточные результаты вычислений. Поэтому объём файла модели не описывает потребность в памяти при обучении. Устройство этих расходов разобрано в документации Hugging Face.

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

Есть и четвёртая задача, которую часто ошибочно относят к дообучению: «пусть помощник отвечает по нашим инструкциям». Здесь нередко достаточно поиска по документам с передачей найденных фрагментов в запрос модели. Такой подход называют RAG. Он тоже требует настройки и проверки качества, зато не заставляет переучивать модель после каждого изменения прайс-листа.

SPHINX и PYRAMID: процессоры, память и стоимость аренды

У SPHINX один Xeon Gold 5412U. У PYRAMID два Xeon Silver 4510. Кажется, что вторая машина должна иметь вдвое больше ядер. Но арифметика здесь другая.

Цены и комплектации приведены по рассматриваемым тарифам; перед заказом их стоит сверить с актуальной карточкой.

У Gold 5412U действительно 24 ядра, а у Silver 4510 — 12 на каждый процессор. Это подтверждают спецификации Intel для Gold 5412U и Silver 4510. В обоих случаях аппаратных потоков может быть больше, чем физических ядер, но считать их полноценным удвоением вычислительных ресурсов нельзя.

Доплата за PYRAMID составляет $150 в месяц, или $1800 за год при неизменной цене. Самое очевидное приобретение — дополнительные 64 ГБ памяти. Два процессора также меняют устройство системы, однако сами по себе не обещают более быстрый ответ модели.

Надписи Gold и Silver тоже мало помогают. Это названия семейств, а не места на пьедестале в вашем приложении. Нейросеть не читает наклейку на сервере перед тем, как начать вычисления.

Сколько оперативной памяти нужно для локальной LLM

Память удобно прикидывать с весов — чисел, которые модель использует в вычислениях. Возьмём условную плотную модель с 8 миллиардами параметров. Если каждый параметр хранится в 16 битах, только на веса потребуется примерно 16 миллиардов байт, то есть около 16 ГБ в десятичном счёте. При идеальном четырёхбитном представлении получилось бы около 4 ГБ.

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

Кроме того, во время разговора модель сохраняет часть промежуточных вычислений для уже прочитанного текста. Так устроен KV-кэш: он помогает не пересчитывать всё заново при каждом следующем фрагменте ответа. Длинные запросы и несколько параллельных диалогов увеличивают требования к памяти. Подробности зависят от архитектуры модели и способа хранения кэша, что объясняет руководство Hugging Face по KV-кэшу.

Отсюда важная разница между двумя экспериментами. В первом человек открывает чат и спрашивает: «Привет, как дела?» Во втором сотрудники одновременно отправляют длинные договоры и просят составить подробные заключения. Одна и та же модель на одном и том же сервере получает совершенно разную нагрузку.

На SPHINX 64 ГБ делят между собой модель, её рабочая память, операционная система и остальные сервисы. На PYRAMID пространства вдвое больше, и это может позволить загрузить более крупную модель, увеличить допустимый контекст либо обслуживать дополнительные процессы. Какой именно выигрыш получится, определяет расход памяти всего приложения. Раздавать все 128 ГБ одному процессу заранее — плохой способ обеспечить соседним службам спокойную жизнь.

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

CPU-инференс на Xeon: что дают два процессора и AMX

У многопроцессорного сервера память физически распределена между процессорами. Обращение к памяти рядом со «своим» процессором и обращение через межпроцессорное соединение имеют разную стоимость. Это устройство называется NUMA.

Для владельца LLM практический смысл прост: объём памяти и скорость доступа к ней — разные характеристики. PYRAMID предоставляет больше RAM, но приложение должно разумно использовать её расположение. Иногда стоит проверить один процесс на всю машину, иногда — отдельные экземпляры модели, закреплённые за разными процессорами. Второй вариант потребует памяти под дополнительные копии весов.

У SPHINX один процессор, поэтому нет обмена между двумя физическими сокетами. Это упрощает настройку, хотя конкретное разбиение памяти на NUMA-узлы всё равно зависит от платформы и её настроек. У PYRAMID больше вариантов распределения работы, а вместе с ними больше поводов проверить, что выбранный вариант действительно помогает.

Полезно узнать и то, какими модулями набраны 64 или 128 ГБ. Процессор может поддерживать много каналов памяти, но фактически использоваться будут те, в которых установлены модули. Слово DDR5 в карточке сообщает поколение памяти; оно не раскрывает всю её конфигурацию и не гарантирует одинаковую пропускную способность двух машин.

У обоих рассматриваемых Xeon есть поддержка Intel AMX — инструкций для матричных вычислений. Однако ускорение появляется только тогда, когда выбранные программа, сборка и формат вычислений умеют этой возможностью пользоваться. Проект llama.cpp, например, поддерживает CPU-инференс и ряд оптимизаций для x86, включая AMX. Из наличия инструкции нельзя вывести обещание конкретного количества токенов в секунду.

Строка U.2 у SPHINX тоже требует аккуратного прочтения. Она описывает конструктив накопителя и подключение, а NVMe — протокол; эти обозначения могут относиться к одному и тому же диску. Например, в спецификации Kingston DC1500M они используются вместе. Это пример обозначений, а не подтверждение модели диска в SPHINX. Чтобы судить о ресурсе и устойчивости к сбоям питания, нужны точная модель SSD и её характеристики. Сравнивать «U.2 против NVMe» как хороший и плохой диск по одной строке тарифа невозможно.

Как проверить скорость LLM и качество ответов на своём сервере

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

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

Дальше полезно разделить два ощущения пользователя. Первое — сколько проходит времени до появления начала ответа. Второе — насколько быстро продолжается текст после этого. Длинный исходный документ может увеличить первое ожидание, даже если последующая генерация выглядит привычно. Для технического сравнения в llama.cpp есть llama-bench: он отдельно измеряет обработку запроса и генерацию, позволяет менять число потоков и параметры NUMA. Тест всего приложения понадобится дополнительно: поиск документов, очередь и сеть тоже занимают время.

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

Ещё один обязательный результат испытаний — качество. Быстро извлечь из договора неправильную сумму не лучше, чем медленно извлечь правильную. Для сравнения нужны примеры с известными ответами и понятный критерий приёмки: насколько точно извлекаются сведения, не теряются ли оговорки, ссылается ли помощник на подходящий документ. Подготовить такой набор поможет материал про батарею тестов для своей LLM.

Когда выбрать SPHINX, когда PYRAMID, а когда нужен GPU

SPHINX стоит первым включить в испытания, если нужная модель вместе с рабочими данными уверенно помещается в 64 ГБ, поток обращений умеренный, а задача допускает измеренную на CPU скорость. Это может быть внутренний помощник небольшой команды, экспериментальная площадка или фоновый обработчик документов. Один процессор упрощает начальную настройку, а меньшая арендная плата оставляет бюджет на хранение копий и обслуживание.

PYRAMID имеет смысл проверять, когда 64 ГБ уже ограничивают проект: требуется больше места для модели и контекста, несколько экземпляров сервиса либо сопутствующие задачи, которым тоже нужна память. Доплата становится обоснованной, если испытания подтверждают полезный результат — например, нужная обработка больше не упирается в RAM или очередь укладывается в заданное время. Покупать его только из-за двух процессоров преждевременно.

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

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

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

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

Все материалы о выделенных серверах