vLLM больше не тянет: почему серьёзные ИИ-проекты в 2026 году уходят от одной модели на GPU

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

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

Как устроен обычный ИИ-пайплайн

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

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

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

Почему нельзя просто поставить несколько моделей на один GPU

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

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

vLLM и TEI это два распространённых сервера. TEI от Hugging Face обслуживает эмбеддинги и реранкинг и принимает id модели при запуске. Движок vLLM тоже построен вокруг одной модели. Поэтому чтобы поставить четыре модели на одну карту, придётся запускать на ней четыре отдельных серверных процесса. Ни один из инструментов не координирует эти процессы, и этот труд ложится на вас.

Каждый процесс забирает память заранее и не видит соседей. У vLLM параметр gpu-memory-utilization по умолчанию равен 0,9 и резервирует эту долю карты при старте, а не подстраивает под спрос. Чтобы запустить два экземпляра, значение приходится выставлять вручную, по 0,5 на каждый. Разбиение памяти становится константой, которую вы считаете сами ещё до прихода первого трафика. Если две модели всплеснут одновременно, они уронят всю карту. Когда модель экстракции наткнётся на необычно длинный документ и попросит больше памяти, чем ей отведено, она потянет за собой OCR, эмбеддинг и реранкинг.

Три способа, которыми команды пытаются обойти проблему

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

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

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

Почему стандартные инструменты не тянут мультимодельный пайплайн

Инструменты создавались под другую задачу, и это видно по двум причинам. Во-первых, каждый из них обслуживает одну форму модели. vLLM сделан для больших языковых моделей, TEI для эмбеддингов и реранкинга, и ни один не делает OCR, зрение или парсинг документов. При этом сами модели под эти задачи уже есть и отлично работают: docling и PaddleOCR для документов, SigLIP и Florence для зрения, GLiNER для экстракции. Нет лишь единого сервера, который запускает их все.

Во-вторых, когда агенту нужно распарсить документ, заэмбеддить его, переранжировать и проверить политику, вам нужен vLLM для одной части, TEI для другой и какой-нибудь FastAPI-обёртка для остального. Получаются четыре сервера, четыре API и четыре деплоя за одним агентом. Каждый сервер написан в расчёте, что владеет картой целиком, и ни один не вернёт память другим, потому что не знает о их существовании. Фрагментация инструментов воссоздаёт ровно тот перерасход, от которого мы уходили.

Какой на самом деле нужен сервинг для маленьких моделей

Идеальный движок должен запускать любой тип модели, который нужен агенту, эмбеддинги, реранкинг, OCR, зрение, экстракцию и генерацию, за одним API. Он должен заполнять GPU, а не набивать его впустую, загружать и выгружать модели по мере движения трафика и нести на себе продакшен-слой с роутингом, автомасштабированием и мониторингом. А добавление новой модели должно быть правкой конфига, а не повторным деплоем. Сделать это трудно, потому что разные семейства моделей устроены внутри по-разному.

Открытое решение: Superlinked Inference Engine

Всё это реализовано в открытом Superlinked Inference Engine, или SIE. Он работает как один кластер внутри вашего облака и сделан ровно под такой пайплайн: несколько маленьких моделей разного типа, работающих подряд на общих GPU. Всё идёт через один API с четырьмя вызовами: encode превращает текст или картинки в векторы, score реранжирует запрос по набору документов, extract вытаскивает структурные поля и сущности, а generate запускает открытую LLM на промпте.

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

Модель загружается в память GPU при первом запросе, а самая давно не использованная выгружается, когда памяти начинает не хватать, точно как кэш браузера. Шлюз впереди роутит запросы, при всплеске придерживает их, пока поднимаются новые воркеры, а потом воркеры схлопываются до нуля, когда трафик падает. Каждая из 85 с лишним моделей в каталоге уже несёт конфиг с настроенными значениями, так что вы ссылаетесь на модель по имени, а движок грузит её с настройками, которые точно работают в продакшене. SIE также интегрируется с Chroma, Qdrant, Weaviate и LanceDB.

Маленькие специализированные модели для узких задач это верный подход. Но переход на них сам по себе не делает инференс дешевле, а перекладывает стоимость с потокенного счёта на арендуемые GPU. Экономия появляется только когда модели делят GPU, а для этого нужен единый движок, способный запустить их все. Репозиторий лежит здесь: github.com/superlinked/sie