The post has been translated automatically. Original language: Russian
In the last two years, the vLLM engine has become the de facto standard for running large language models (LLM) in production. It is used by startups, corporations, and research teams because it is stable, fast, and relatively easy to use. But in 2024-2025, a new serious competitor appeared - SGLang. It quickly attracted the attention of developers, because in some cases it works even faster and more efficiently. Sonyman, is it worth switching to SGLang then?
Yes, I am a teacher. We read the analogy and delve into it.
Imagine that the language model is a teacher who answers students' questions.
vLLM is a teacher who is well organized: he knows how to quickly respond to many students at the same time, does not get confused and works steadily all day.
SGLang is a teacher who is not only organized, but also knows how to memorize student conversations and use them to respond faster. The longer and more difficult the conversation, the more advantages the second teacher has.
The result of the SGLang, LMDeploy, and vLLM benchmarks. Source: AIMultipleWhen the user asks a question to the model, the GPU starts generating an answer based on a single word or token. The rate of this generation is measured in tokens per second. The higher this indicator, the faster the system works and the more users it can serve at the same time. In an independent test on the NVIDIA H100 GPU, the SGLang engine showed a speed of about 16,215 tokens per second, while vLLM showed about 12,553 tokens per second on the same model. This means that SGLang was about 29% faster in this scenario. In practice, this can mean either faster responses to users, or saving server resources.
And why does it happen this way?
The reason for this difference is how the engines use GPU memory. When the user conducts a dialogue with the model, the system saves previous messages in order to understand the context. This mechanism, by the way, is called a KV cache! vLLM uses an efficient cache management system, while SGLang uses more aggressive optimization, which makes it faster to find and reuse already saved parts of the dialog. Now see what the joke is - this is especially important for chatbots, where users ask a lot of consecutive questions.
In short, in other words, vLLM carefully removes the necessary documents from the archive each time, and SGLang pre-arranges the documents so that they can be found instantly. And the larger the archive, the greater the difference in speed.
It is important to understand that the difference in speed depends on the conditions. If the system handles short queries, the difference may be small. But if the system serves many users at the same time or works with long dialogues, the advantage of SGLang becomes more noticeable. In tests with long conversations and active cache usage, SGLang acceleration is usually about 10-20% compared to vLLM (source: Runpod). This means that the server can serve more users on the same hardware.
And now from the point of view of an IT specialist
From the point of view of a developer or technical manager, the fact that it is possible to serve more users on the same server directly affects the cost of all its implementation. If one server can serve more users, fewer servers are needed. If the responses arrive faster, the user experience improves. If the GPU is used more efficiently, the cost of operation is reduced.
Well, from the point of view of the Project Manager, this means increasing scalability without increasing the budget. And "since there was such a drunkenness," from the designer's point of view, this means a faster interface response and a sense of "live" interaction. From the point of view of a web developer, this means reducing API delays and reducing the number of timeout errors. Finally, I will end by saying that from a business point of view, this means the opportunity to serve more customers on the same infrastructure.
Speed tests. Which was to be expected
I tested SGLang in one of my projects, replacing vLLM without changing the model and hardware. After the transition, the average generation rate increased by about 18%. For example, if the system used to generate about 11,800 tokens per second, after the transition, the indicator increased to about 13,900 tokens per second. This corresponds to values close to those shown in independent tests.
The response time to the user has also decreased. The average response time decreased by about 12%. This means that users started getting responses faster, and the interface began to feel more responsive. A particularly noticeable effect appeared with long dialogues: the system began to work more stably under high load.
Another important observation was the reduction of GPU load. With the same number of users, GPU usage decreased by about 7-10%. This means that the system can serve more users without increasing server resources. In fact, this means a reduction in the cost of maintenance while maintaining the same quality of work. Perhaps I would have been able to achieve more high performance here (no, really, GPU changes are far different from other people's achievements in benchmarks) if I had understood more about the intricacies of the SGLang configuration.
Who should stay on vLLM?
Switching to SGLang doesn't always make sense, because if your system is already running stably on vLLM and there are no problems (hence needs) with speed or cost. Also, if your infrastructure is complex and different types of GPUs are used, or models change frequently for reasons of project specification, vLLM remains a more versatile solution. And it seemed to me that vLLM is easier to install and maintain, especially for small teams.
Of course, SGLang shows the best results, but why do we need this vLLM? It shows such results when using a modern GPU with a stable infrastructure (I'm talking about the lack of constant modifications) and high loads. Well, in such conditions, it allows you to get maximum productivity and reduce the cost of operation. In all other cases, leave it. Simplicity, stability and versatility - here vLLM was and remains an excellent choice.
The main conclusion is that SGLang is not just an experimental tool, but a full-fledged alternative to vLLM, which is already showing higher performance in real conditions. It is especially useful for systems with high load and long conversations, where GPU efficiency plays a key role. If implemented correctly, SGLang can increase system speed by 10-30% and reduce infrastructure costs without compromising quality.
В последние два года движок vLLM стал фактическим стандартом для запуска больших языковых моделей (LLM) в продакшене. Его используют стартапы, корпорации и исследовательские команды, потому что он стабильный, быстрый и относительно простой в использовании. Но в 2024–2025 годах появился новый серьёзный конкурент - SGLang. Он быстро привлёк внимание разработчиков, потому что в ряде случаев работает ещё быстрее и эффективнее. Сонымен, стоит ли переходить на SGLang то?
Да, я препод. Читаем аналогию и вникаем.
Представьте, что языковая модель - это преподаватель, который отвечает на вопросы учеников.
vLLM - это преподаватель, который хорошо организован: он умеет быстро отвечать многим ученикам одновременно, не путается и стабильно работает весь день.
SGLang - это преподаватель, который не просто организован, но ещё и умеет запоминать разговоры учеников и использовать их, чтобы отвечать быстрее. Чем дольше и сложнее разговор, тем больше преимуществ у второго преподавателя.
Результат бенчмарка SGLang, LMDeploy, vLLM. Источник: AIMultipleКогда пользователь задаёт вопрос модели, GPU начинает генерировать ответ по одному слову или токену. Скорость этой генерации измеряется в токенах в секунду. Чем выше этот показатель, тем быстрее работает система и тем больше пользователей она может обслужить одновременно. В независимом тесте на GPU NVIDIA H100 движок SGLang показал скорость около 16 215 токенов в секунду, тогда как vLLM показал около 12 553 токенов в секунду на той же модели. Это означает, что SGLang работал примерно на 29 % быстрее в этом сценарии. На практике это может означать либо более быстрые ответы пользователям, либо экономию серверных ресурсов.
И почему же оно так происходит?
Причина такой разницы заключается в том, как движки используют память GPU. Когда пользователь ведёт диалог с моделью, система сохраняет предыдущие сообщения, чтобы понимать контекст. Этот механизм, кстати, называется KV-кэш! vLLM использует эффективную систему управления этим самым кэшем, а SGLang использует более агрессивную оптимизацию, которая позволяет быстрее находить и повторно использовать уже сохранённые части диалога. Теперь смотрите в чём прикол - это особенно важно для чат-ботов, где пользователи задают много последовательных вопросов.
Короче, другими словами, vLLM каждый раз аккуратно достаёт нужные документы из архива, а SGLang заранее раскладывает документы так, чтобы находить их мгновенно. И чем больше архив, тем больше разница в скорости.
Важно понимать, что разница в скорости зависит от условий. Если система обрабатывает короткие запросы, разница может быть небольшой. Но если система обслуживает много пользователей одновременно или работает с длинными диалогами, преимущество SGLang становится более заметным. В тестах с длинными диалогами и активным использованием кэша ускорение SGLang обычно составляет около 10–20 % по сравнению с vLLM (источник: Runpod). Это означает, что сервер может обслуживать больше пользователей на том же оборудовании.
А теперь с точки зрения айтишника
С точки зрения разработчика или технического менеджера, факт возможности обслуживать больше юзеров на том же серваке напрямую влияет на стоимость всееей реализации. Если один сервер может обслуживать больше пользователей, нужно меньше серверов. Если ответы приходят быстрее, улучшается пользовательский опыт. Если GPU используется эффективнее, снижается стоимость эксплуатации.
Ну а с точки зрения Project Manager это означает увеличение масштабируемости без увеличения бюджета. И "раз пошла такая пьянка", то с точки зрения дизайнера это означает более быстрый отклик интерфейса и ощущение «живого» взаимодействия. С точки зрения веб-разработчика это означает снижение задержек API и уменьшение количества тайм-аут ошибок. Наконец, закончу тем, что с точки зрения бизнеса это означает возможность обслуживать больше клиентов на той же инфраструктуре.
Тесты скорости. Что и требовалось ожидать
Я протестировал SGLang в одном из своих проектов, заменив vLLM без изменения модели и оборудования. После перехода средняя скорость генерации увеличилась примерно на 18 %. Например, если раньше система генерировала около 11 800 токенов в секунду, после перехода показатель вырос примерно до 13 900 токенов в секунду. Это соответствует значениям, близким к тем, что показаны в независимых тестах.
Также уменьшилось время ответа пользователю. Среднее время до начала ответа сократилось примерно на 12 %. Это означает, что пользователи начали получать ответы быстрее, и интерфейс стал ощущаться более отзывчивым. Особенно заметный эффект появился при длинных диалогах: система стала работать стабильнее под высокой нагрузкой.
Ещё одним важным наблюдением стало снижение нагрузки на GPU. При том же количестве пользователей использование GPU уменьшилось примерно на 7–10 %. Это означает, что система может обслуживать больше пользователей без увеличения серверных ресурсов. Фактически это означает снижение стоимости обслуживания при том же качестве работы. Возможно, я бы смог добиться больше высоких показателей тут (нет, ну правда, изменения GPU далековато отличаются от чужих достижений в бенчмарках), если бы разбирался сильнее в тонкостях конфигурации SGLang.
Кому лучше остаться на vLLM
Переход на SGLang имеет смысл не всегда, ведь если ваша система уже стабильно работает на vLLM и нет проблем (следовательно, нужд) со скоростью или стоимостью. Также если инфраструктура у вас сложная и используются разные типы GPU или часто меняются модели из соображений ТЗ проекта, vLLM остаётся более универсальным решением. И как мне показалось, vLLM проще установить и поддерживать, особенно для небольших команд.
Конееечно, SGLang показывает лучшие результаты же, да зачем нам этот vLLM нужен? Он показывает такие результаты когда используется современное GPU при стабильной инфраструктуре (я про отсутствие постоянных модификаций) и высоких нагрузках. Вот ну в таких условиях он позволяет получить максимальную производительность и снизить стоимость эксплуатации. В остальных случаях, оставьте это. Простота, стабильность и универсальность - тут vLLM был и остаётся отличным выбором.
Главный вывод заключается в том, что SGLang - это не просто экспериментальный инструмент, а полноценная альтернатива vLLM, которая уже сейчас показывает более высокую производительность в реальных условиях. Он особенно полезен для систем с высокой нагрузкой и длинными диалогами, где эффективность использования GPU играет ключевую роль. При правильном внедрении SGLang может увеличить скорость работы системы на 10–30 % и снизить стоимость инфраструктуры без ухудшения качества.
Share
