vLLM или Ollama команда выбирает по замеру, оставляя репутацию в стороне: оба сервера отдают модель по адресу, совместимому с OpenAI, и различаются поведением под нагрузкой, настройкой и затратами на обслуживание. Честное сравнение требует одной модели, одного железа и одного сценария запросов. Подход нужен командам, которые переходят от личного эксперимента к общему серверу и хотят опереться на цифры.
Два сервера
Оба сервера предоставляют OpenAI-совместимые адреса для чата, продолжения текста и эмбеддингов, а различаются устройством нагрузки и настройкой. Выбор делают замером на одной модели, одном железе и одном наборе запросов.
Заранее решите, кто будет пользоваться сервером: один разработчик, команда из нескольких человек или приложение с десятками одновременных обращений. Эти три сценария дают разные требования, и замер под один из них мало говорит о другом. Запишите сценарий в протокол, прежде чем открывать консоль.
Спор о том, какой сервер лучше, быстро заходит в тупик, потому что у участников разные задачи. Один запускает модель для себя на ноутбуке, другой строит общий сервис для отдела. Для первого важна простота, для второго предсказуемость под нагрузкой. Поэтому сравнение начинают с вопроса о сценарии, а уже потом переходят к замерам.
Установку и контейнер для каждого из серверов мы разбирали в статьях Ollama в Docker и vLLM в Docker, а общий обзор — в материалах про Ollama для компании и vLLM для компании. Здесь только сравнение: условия честного замера и критерии решения.
По документации, Ollama реализует адреса chat completions, completions, embeddings и models под путём /v1, а vLLM предоставляет аналогичный набор, включая транскрипцию для моделей распознавания речи. Приложению достаточно сменить адрес и имя модели, поэтому переход между серверами обходится дёшево, и это снижает цену ошибки при выборе.
Условия замера
Сравнивать серверы на разных моделях и разном железе бессмысленно: разница в цифрах будет объясняться чем угодно, кроме самого сервера. Зафиксируйте условия заранее.
- Выберите одну модель, доступную в обоих серверах, и один размер, который помещается в память с запасом.
- Запустите оба сервера на одном и том же оборудовании по очереди, чтобы видеопамять целиком принадлежала одному серверу.
- Подготовьте набор запросов, близкий к вашей работе: короткие вопросы, длинные документы, запросы на русском.
- Прогоните набор сначала по одному запросу, затем с растущим числом одновременных, записывая время до первого слова и общую длительность.
- Повторите прогон несколько раз и после перезапуска сервера, чтобы убрать влияние случайных пиков и холодного старта.
Холодный старт стоит замерить отдельно. Первый запрос после загрузки модели обычно медленнее остальных, а для команды, где сервер простаивает ночью, именно этот запрос встречает первого пользователя утром. Проверьте, как каждый сервер ведёт себя после простоя, и как настраивается время хранения модели в памяти.
Отдельно зафиксируйте параметры запуска: контекст, число параллельных запросов, формат весов. Эти настройки сильно влияют на результат, и сравнение с настройками по умолчанию у одного сервера и тонкой настройкой у другого окажется нечестным. Ориентируйтесь на документацию каждого сервера и описывайте выбор в протоколе.
Формат весов бывает разным: серверам нужны разные файлы одной и той же модели. Проверьте, что вы сравниваете одну и ту же модель без подмены похожими, иначе различия в качестве ответов припишут серверу. Подробности о форматах разобраны в статьях про GGUF и safetensors.
Что сравнивать
Сравнивают по нескольким осям. Скорость одного запроса только первая из них, а для команды чаще важнее остальные.
| Критерий | Что измерить | Что проверить в документации |
|---|---|---|
| Время до первого слова | Отзывчивость при одиночном запросе | Влияет ли холодная загрузка модели |
| Параллельность | Как растёт задержка при нескольких запросах | Параметры параллельности и очереди |
| Память | Сколько занимает модель с контекстом и параллельностью | Как контекст растёт при параллельных запросах |
| Метрики | Видно ли очередь и занятость | Наличие метрик и формат их выдачи |
| Качество ответов | Совпадение на вашем наборе задач | Формат и квантование весов |
| Простота запуска | Время от чистой машины до первого ответа | Установка, обновление, откат |
По справке Ollama, параллельная обработка запросов к одной модели увеличивает размер контекста пропорционально числу параллельных запросов, а при нехватке памяти запросы встают в очередь. У vLLM метрики в формате Prometheus отдаются на отдельном адресе, и очередь видна напрямую. Эти различия проверяйте замером вместо пересказа.
Сколько человек одновременно будут пользоваться вашим сервером?
Обслуживание
Скорость измеряется за вечер, а обслуживание длится месяцы. Часть выбора определяется тем, сколько усилий команда готова вкладывать после запуска.
- Установка: насколько быстро приходит первый ответ у человека без опыта.
- Модели: как загружаются новые, где хранятся веса и как освободить место.
- Доступ по сети: по документации Ollama слушает только локальный адрес, и для общего доступа нужна явная настройка.
- Ключи и права: у какого сервера есть встроенный ключ доступа и как разделить приложения.
- Обновления: что ломается при смене версии и как откатиться.
- Наблюдаемость: есть ли метрики и журнал, которые поймёт дежурный.
Спросите и про безопасность. Сервер в общей сети без ключа доступа открыт каждому, кто знает адрес. Проверьте, как в каждом варианте включается авторизация, и закройте порт от внешней сети, оставив доступ только приложениям, которым он нужен.
Простота и контроль тянут в разные стороны. Сервер, который запускается одной командой, обычно даёт меньше рычагов для тонкой настройки нагрузки. Сервер с богатой настройкой требует знаний, и без человека, который за него отвечает, превращается в обузу. Честно оцените, есть ли такой человек в команде.
Обратите внимание на сценарии, где различия сглаживаются: личный эксперимент, небольшой отдел, нагрузка из единичных запросов. Там замер часто показывает, что разница мала, и решающим становится удобство. Различия становятся ощутимыми при десятках одновременных пользователей и длинных запросах.
Решение для команды
По итогам замеров у вас складывается таблица, и из неё следует решение. Запишите его вместе с условиями, чтобы через полгода можно было пересмотреть.
Для личных задач и небольших команд берите то, что быстрее запускается и обслуживается. Для общего сервиса с нагрузкой выбирайте по замеру параллельности и метрикам. Если сомневаетесь, начните с простого сервера: переход на другой обходится дёшево, потому что адреса совместимы.
Предусмотрите путь отхода. Если выбранный сервер перестал справляться, вы должны суметь переключиться на другой без переписывания приложений. Держите настройки в одном месте: адрес и имя модели в конфигурации, а в коде их нет, и тогда замена сервера превращается в изменение двух строк.
Зафиксируйте в регламенте версию сервера, модель, параметры запуска, дату замера и результаты. Когда выйдет новая версия или модель, вы повторите замер на том же наборе и увидите, изменилось ли решение. Иначе спор вернётся в виде мнений.
Сравнение серверов, оценку нагрузки и обучение команды включают в проекты по автоматизации бизнес-процессов с ИИ. А для данных, которые можно отдавать вовне, сервис вендора напрямую остаётся отдельным вариантом, который сравнивают по тем же осям.