Сервер для нейросети: как рассчитать мощность под одновременные запросы сотрудников

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

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

Как определить нагрузку на сервер нейросети?

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

Рассмотрим помощника, который отвечает сотрудникам по внутренним инструкциям. Обстоятельства вымышлены; это не кейс клиента. Доступ получат 200 человек. Для испытания запланированы уровни 1, 4, 8 и 16 одновременных запросов. Это точки теста, а не заявленная производительность сервера.

В учебном паспорте зафиксируем исходные условия:

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

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

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

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

Назначьте владельца каждой неизвестной величины. ИТ-команда может подготовить журнал запросов, предметный специалист — эталоны ответов, а владелец процесса — допустимое ожидание и условия ручной обработки. Если сервис ещё не запущен, отметьте частоту обращений как предположение и проверьте её на ограниченном пилоте. Такой паспорт позволяет понять, какую часть оценки придётся пересмотреть после появления реального потока.

Из чего складывается память для локальной модели?

Составьте отдельные бюджеты видеопамяти GPU — VRAM — и оперативной памяти сервера — RAM. Не переносите объём из одного бюджета в другой без проверки выбранного способа исполнения.

Для предварительной оценки VRAM удобно выделить несколько составляющих:

Для учебного бюджета примите условие: каждый из P параметров хранится в плотном массиве и занимает bits бит, упаковочные расходы пока не учитываются. Посчитайте биты как P × bits, затем разделите на 8, чтобы получить байты: W = P × bits / 8. На следующем шаге отдельно добавьте кэш и прочие расходы. Так получится предварительная оценка выбранного массива, а не измерение полной памяти сервера.

В учебных вычислениях ниже будем переводить байты в GiB делением на 2³⁰. Например, промежуточные 16 × 10⁹ байт дадут 16 × 10⁹ / 2³⁰ ≈ 14,90 GiB. Для сопоставления с оборудованием сначала уточните единицы в его спецификации: десятичное обозначение GB и используемое в расчёте GiB нельзя сравнивать по числу без пересчёта. Приведите обе величины к байтам, затем к одной выбранной единице.

KV-кэш хранит промежуточные состояния внимания. В документации Transformers описано, что DynamicCache растёт по мере генерации. Для слоёв с оконным вниманием рост ограничивается размером окна; поэтому одну формулу нельзя без проверки применять к любой архитектуре.

Для однородного полного KV-кэша оценку можно вывести из числа элементов тензоров K и V. Hugging Face описывает их размерности и послойное кэширование. В упрощённом расчёте:

KV = 2 × L × Hkv × D × T × B × s.

L — число слоёв; Hkv — число голов ключей и значений; D — размерность одной головы; T — число сохраняемых токенов на последовательность; B — число одновременно хранимых последовательностей; s — байты на элемент кэша. Множитель 2 учитывает отдельно ключи и значения.

Не подставляйте вместо Hkv число query-голов. В T учитывайте накопленный вход и выход, а не только вопрос пользователя. Если длины последовательностей различаются, оценку следует вести по их фактическим бюджетам, а не без объяснения умножать среднее значение.

Эта схема не универсальна для sliding window, гибридных архитектур, MLA, переноса кэша в RAM, распределения модели между устройствами или квантизованного KV. Сверяйте расчёт с конфигурацией модели и среды исполнения. В частности, уменьшение разрядности весов не даёт основания автоматически уменьшить разрядность кэша.

Как выполнить предварительный расчёт памяти?

Продолжим учебный пример помощника. Для него зададим условную модель и обычный полный KV-кэш. Все числа в следующем расчёте — учебные допущения; результаты не являются замером оборудования.

Данные весов займут 8 × 10⁹ × 16 / 8 = 16 × 10⁹ байт, или приблизительно 14,90 GiB. Для полного KV-кэша используем описанную выше модель послойного хранения K и V, сохраняя её ограничения.

При T = 4096 получим:

2 × 32 × 8 × 128 × 4096 × 8 × 2 = 4 294 967 296 байт = 4 GiB.

Веса и кэш вместе дают около 18,90 GiB. Добавим учебный бюджет прочих расходов и резерва — 4 GiB. Это произвольно заданное условие примера: в реальном проекте его нужно заменить измерением и обоснованным запасом. Общая оценка составит 22,90 GiB.

Теперь увеличим T до 8192 при тех же остальных параметрах. Кэш займёт 8 GiB, а общий бюджет с тем же условным дополнением составит 26,90 GiB.

Округление выполнено до сотых GiB. При условной доступной ёмкости 24 GiB первый профиль проходит только эту предварительную проверку памяти, а второй превышает принятый бюджет. Вывод для первого профиля — перейти к испытанию; для второго — пересмотреть конфигурацию или допущения.

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

Какие показатели скорости нужно согласовать?

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

В документации vLLM по метрикам задержки TTFT определяется как время от отправки запроса до первого потокового вывода. TPOT рассчитывается для отдельного запроса без первого токена:

TPOT = (E2E − TTFT) / (Nout − 1), при Nout > 1.

E2E — полное время запроса, Nout — число выходных токенов: эти обозначения используются в описании расчёта TPOT в vLLM. При сопоставлении инструментов сохраняйте определения и точки измерения: одинаковые названия метрик сами по себе не гарантируют одинаковый расчёт.

Для приёмки можно заполнить такую таблицу:

Для задержек покажите медиану и согласованные перцентили p95 или p99. Укажите число наблюдений и окно теста, чтобы читатель отчёта видел основу расчёта. Пороги утверждает владелец процесса: значения из чужого примера не становятся SLA компании.

Не подменяйте скорость отдельного ответа общим числом токенов в секунду. И различайте TPOT и ITL: vLLM описывает ITL как интервалы между потоковыми выдачами. Когда одна выдача содержит несколько токенов, ITL и усреднённое время на токен могут различаться. В отчёте сохраняйте формулу, а не только сокращение.

Как провести нагрузочные испытания до закупки?

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

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

Отделите прогрев от измерений. В протоколе обозначьте начало учётного периода. Запишите состояние кэша и условия его очистки или сохранения. Документация vLLM предупреждает о влиянии повторных префиксов на throughput: повторение одних заданий может использовать оставшийся prefix cache. Если повторное использование соответствует рабочему потоку, измерьте и опишите его отдельно.

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

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

В отчёте vLLM для планирования ёмкости максимальная допустимая параллельность сопоставляется одновременно с порогами TTFT и TPOT. Для своего проекта дополните это проверкой качества, отказов и полного времени операции.

Ниже — шаблон будущего протокола, а не результаты проведённых испытаний:

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

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

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

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

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

Что выбрать, если конфигурация не проходит испытания?

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

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

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

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

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

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

Что передать DYNAMICSUN для оценки инфраструктуры?

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

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

DYNAMICSUN предлагает инфраструктуру для работы с ИИ: подбор серверного оборудования, расчёт необходимой мощности, развёртывание моделей и настройку доступа. Конкретный состав настройки, интеграции и испытаний определяется для проекта.

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

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