Сравнение серверов инференции: решения с открытым исходным кодом для моделей ИИ

Что делает сервер инференции

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

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

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

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

Проверить модель, аппаратное обеспечение и права

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

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

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

Формат также может ограничивать выбор: согласно документации по проекту, файл llama.cpp требует модели в формате Формат GGUF. Для других форматов в рамках проекта описан процесс конвертации; однако из этого не следует, что каждая архитектура или каждый вариант модели будет работать без изменений. Исходный код находится в ветке разработки. Поэтому перед развертыванием тебе следует сверить указанные данные с выбранным релизом.

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

Как запросы к LLM потребляют ресурсы

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

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

Метод «Continuous Batching» гибко объединяет текущие запросы на генерацию, вместо того чтобы просто дожидаться формирования фиксированного общего пакета. «PagedAttention» организует хранение кэша «ключ-значение» (KV-cache) блоками. Оба метода описаны для vLLM и могут повысить эффективность использования ресурсов. Однако степень их эффективности зависит, в частности, от размера запросов, степени параллелизма и аппаратного обеспечения; на этом основании невозможно сделать вывод о преимуществе для любой рабочей нагрузки.

Triton, напротив, описывает общую архитектуру сервера: планировщик, основанный на модели, принимает запросы и передает их соответствующему бэкенду. Для модели можно настроить динамическую пакетную обработку. Это не означает, что каждый бэкенд одинаково обрабатывает запросы LLM внутри системы или использует те же методы хранения, что и vLLM. Поэтому для сравнения важна конкретная комбинация бэкенда и модели.

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

Оценить четыре решения, отметить SGLang в качестве альтернативы

В приведенном ниже обзоре vLLM, llama.cpp, Triton и TGI классифицируются в соответствии с их задокументированными подходами. Данный обзор не является сравнением функциональности или производительности конкретных версий. SGLang остаётся неоцененным альтернативным вариантом: Hugging Face рекомендует его наряду с vLLM в качестве преемника TGI, однако из этого невозможно сделать выводы ни о форматах моделей, ни об интерфейсах, ни об аппаратной поддержке конкретного выпуска SGLang.

База исходных кодов содержит изменяющиеся страницы документации, а в llama.cpp — ветку разработки. Таким образом, отсутствуют данные о завершенном тестировании для vLLM 0.10.2, llama.cpp b6000, Triton 25.10 или TGI 3.3.7. Поэтому эти сопоставления версий не используются в качестве основы для сравнения. Перед развертыванием необходимо проверить необходимые характеристики для фактически выбранной версии сервера и ревизии модели.

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

Hugging Face возглавляет рейтинг TGI в Режим обслуживания и называет vLLM и SGLang в качестве альтернатив. Существующую установку не обязательно сразу заменять. Однако при планировании новых проектов следует учитывать ограниченность дальнейшего развития; перед миграцией необходимо отдельно сравнить поведение API и качество моделей.

Triton и vLLM не являются принципиально несовместимыми: Triton может использовать бэкэнд vLLM. Тем не менее, необходимо проверить, будет ли конкретная модель работать с выбранными версиями и имеющейся платформой в данной комбинации. Общая архитектура Triton сама по себе не гарантирует поддержку любого бэкенда на любой платформе.

Подготовка локального прототипа

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

Файл llama.cpp использует формат GGUF. Найдите подходящий вариант GGUF или проверьте, можно ли преобразовать исходную модель с помощью задокументированных инструментов. В документации по проекту описываются такие преобразования в рамках ветки разработки; она не является подтверждением того, что каждый старый выпуск поддерживает любую архитектуру или любой вариант преобразования.

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

Выберите для прототипа конкретную сборку и сверьте параметры установки и сервера с соответствующей документацией. Для упомянутой выше сборки b6000 здесь не указано, что была проведена проверка, связанная с конкретной версией; поэтому она не рекомендуется в качестве проверенной отправной точки. Имеющаяся документация по модели в ветке разработки не заменяет ни документацию по серверу выбранной сборки, ни проверку её совместимости.

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

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

Планирование нагрузки и потребностей в памяти

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

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

Continuous Batching и PagedAttention — это описанные в контексте vLLM подходы к управлению текущими запросами и кэш-памятью соответственно. Они не избавляют вас от необходимости планирования ресурсов: то, какая комбинация параллелизма и длины контекста является приемлемой, зависит от модели, аппаратного обеспечения и выбранной конфигурации. На этом основании невозможно сделать вывод об общем приросте производительности для любой рабочей нагрузки.

Простой расчет объемов поможет в подготовке: 100 гипотетических запросов по 200 токенов выдачи каждый в сумме дают 20 000 токенов выдачи. Это измерение пропускной способности не производится. Без указания временного интервала, длины ввода, параллелизма и других эксплуатационных данных из этого невозможно сделать выводы ни о количестве токенов в секунду, ни о затратах.

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

Безопасная и контролируемая эксплуатация API

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

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

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

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

Для обеспечения работы базовых хостов инструменты администрирования могут объединять задачи и полномочия. Для отдельного выбора этого уровня управления предоставляется Сравнение ISPConfig и Froxlor дополнительный контекст. Выбор серверной панели — это отдельное инфраструктурное решение; такая панель не заменяет ни обеспечение безопасности API модели, ни мониторинг службы инференса.

Определение источника ошибки и миграция TGI

Если модель не запускается, сначала проверь версию модели и формат на соответствие выбранной среде выполнения. Для файла llama.cpp требуемый формат — GGUF; однако само по себе преобразование ещё не гарантирует, что конкретная архитектура и задача будут работать. Затем необходимо проверить, поддерживаются ли выбранный бэкенд и данная комбинация аппаратного обеспечения, а также достаточно ли доступной памяти.

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

В случае существующего сервиса TGI миграция начинается с анализа текущего состояния: в него входят проверка модели, используемые вызовы API, настройки выборки и требования к качеству ответа. Hugging Face переводит TGI в режим обслуживания и в качестве альтернатив называет, в частности, vLLM и SGLang. Это делает переход на альтернативные решения достойным рассмотрения, но не означает немедленного выхода из строя существующих установок.

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

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

Выбор подходящей архитектуры

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

В качестве кандидата для тестирования в качестве внутреннего чат-сервиса можно рассмотреть vLLM: в динамической документации описан интерфейс чата, совместимый с OpenAI, с необходимым шаблоном чата. Таким образом, тестирование версии 0.10.2 не подтверждено. SGLang остаётся здесь неоцененным альтернативным вариантом из документации TGI; без технической проверки релиза его невозможно сравнивать наравне с другими решениями.

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

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