vLLM + Triton + TensorRT – Инференс-сервинг Для Видео-ИИ

Кратко

Инференс-сервинг – это слой, который превращает обученную модель в быстрый, всегда доступный сервис, к которому обращается ваш видео-продукт, и выбор серверного софта решает, сколько вы платите за каждое резюме, субтитр и детекцию, – нередко в два и более раза на одном и том же железе. Открытый дефолт 2026 года – это vLLM, чьи две ключевые идеи (PagedAttention, который не даёт модели впустую тратить память видеокарты, и continuous batching, который держит карту занятой) дают примерно в 2–4 раза больше пропускной способности, чем серверы прошлого поколения, и большой отрыв от «ноутбучных» инструментов вроде Ollama под реальной нагрузкой. Чтобы выжать последние проценты скорости из карт NVIDIA, есть TensorRT-LLM, заново собранный вокруг PyTorch-процесса, который убирает медленный шаг компиляции движка, а чтобы запускать много разных моделей на одном парке карт, есть Triton Inference Server – чей датацентровый преемник, NVIDIA Dynamo, вышел в 2025 году. Для видео это важно особенно потому, что видео-ИИ функция почти никогда не одна модель: это конвейер – декодировать, детектировать, транскрибировать, описать, резюмировать – и каждому этапу нужен свой сервер, поэтому работа инженера в том, чтобы подобрать каждой модели подходящий.

Почему это важно

Каждая ИИ-функция в видео-продукте – авто-резюме записи, живые субтитры, проверка «можно ли это публиковать», поисковая строка, отвечающая на вопросы об архиве, – запускает модель, а модель надо обслуживать: обернуть в софт, который грузит её на видеокарту и быстро отвечает на запросы, сразу для многих пользователей, не падая. Ошибитесь со слоем обслуживания – и вы либо жжёте деньги на простаивающем железе, либо смотрите, как задержка взлетает в тот момент, когда появляется второй пользователь. Этот урок написан для продакт-менеджера, основателя или техлида, которому надо утвердить план инфраструктуры, прочитать счёт за облако или спросить у подрядчика, почему инференс стоит столько, сколько стоит, – и кому нужно понимать, что на самом деле делают vLLM, SGLang, TensorRT-LLM, Triton и serverless-GPU, где каждый выигрывает и какие вопросы отделяют серьёзный план обслуживания от общих слов. Это операционный спутник урока про стенды оценки: когда вы уже умеете доказать, что видео-ИИ функция хороша, вот как запустить её в масштабе так, чтобы счёт не запустил вас.

Что такое «инференс-сервинг» на самом деле

Начнём со слов, потому что три из них употребляют небрежно. Модель – это обученный файл, несколько гигабайт чисел, превращающий вход в выход: кадры – в найденные объекты, аудио – в текст, видео-плюс-вопрос – в ответ. Инференс – это акт прогона модели на одном входе ради одного выхода, в отличие от обучения, куда более дорогого акта создания самой модели. Модель обучают один раз; инференс на ней гоняют миллионы раз. Инференс – это та часть, за которую вы платите всегда.

Обслуживание (serving) – это софт, который сидит между вашим продуктом и моделью и делает инференс по требованию. Без него модель – инертный файл на диске. Слой обслуживания грузит модель на GPU (graphics processing unit – специализированный чип, выполняющий ИИ-математику в сотни раз быстрее обычного процессора), открывает сетевую точку, куда приложение шлёт запросы, и управляет неудобной реальностью: GPU дорогой, памяти у него мало, и за раз он может немного. Считайте модель поваром, а GPU – единственной очень быстрой плитой: обслуживание – это управление кухней, система, которая решает, какие заказы поставить на плиту, в каком порядке и как готовить несколько сразу, чтобы плита не простаивала.

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

Почему видео-ИИ – трудный случай: это конвейер

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

Возьмём «резюмировать запись вебинара с поиском по ключевым моментам». За этой одной кнопкой – последовательность. Сначала видео декодируется в кадры и аудиодорожку. Аудио идёт в модель распознавания речи (из урока про потоковый ASR), которая превращает его в транскрипт. Выбранные кадры идут в vision-language модель, которая описывает, что на экране, – тот же класс моделей, что в уроке про видео-VLM. Затем большая языковая модель читает транскрипт и описания и пишет резюме. Если функция ещё и распознаёт лица или объекты, на кадрах работает модель компьютерного зрения вроде YOLO (из урока про YOLO). Пять типов моделей, одна функция.

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

Нажмите, чтобы увеличить

Две идеи, которые делают сервер быстрым

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

Первая идея решает проблему памяти. Когда языковая модель генерирует текст, она держит бегущий черновик всего, что прочитала и написала, – он называется KV-cache (на аббревиатуру можно не смотреть; считайте это краткосрочной памятью модели для текущего разговора). Этот черновик растёт с каждым токеном и должен жить в ограниченной памяти GPU. Старые серверы резервировали под него большой фиксированный блок памяти заранее – с запасом на самый длинный возможный ответ, – хотя большинство ответов коротки. Результат – потери: опубликованное исследование показало, что старые системы выбрасывали 60–80% памяти KV-cache на это избыточное резервирование и фрагментацию, а потерянная память значит, что на карту одновременно влезает меньше запросов, а это значит меньше пропускной способности.

PagedAttention – это исправление, и его идея взята прямо из того, как операционная система управляет памятью компьютера. Вместо одного большого зарезервированного блока на запрос он нарезает черновик на маленькие страницы фиксированного размера и выдаёт их только тогда, когда запросу они реально нужны, – как библиотека, выдающая полки по одной, а не бронирующая целое крыло под каждого читателя. Опубликованный результат впечатляет: потери падают с 60–80% до менее 4%, и возвращённая память позволяет куда большему числу запросов делить карту. Это техника, запустившая vLLM, и названа она в честь статьи, которая её представила.

Вторая идея решает проблему планирования. Наивные серверы делают static batching: они собирают фиксированный набор запросов, прогоняют их вместе и ждут самого медленного, прежде чем начать следующую группу, – так один длинный ответ задерживает всех позади, и GPU простаивает наполовину. Continuous batching это чинит, относясь к пачке как к движущейся очереди: как только любой запрос в пачке завершается, на его место тут же встаёт новый, и GPU не ждёт. На практике это поднимает загрузку GPU с типичных 30–40% при static batching до 75–90% при continuous batching – разница между наполовину остывшей плитой и той, что всегда готовит.

Эти две идеи важны для видео сильнее, чем для чата, потому что видео-входы тяжелы по токенам. Когда vision-language модель смотрит на кадр, она видит не немного текста – она превращает картинку в большой блок токенов. Один выбранный кадр может стать несколькими сотнями токенов, так что судья или резюматор, берущий шестнадцать кадров, несёт тысячи токенов-картинок в своём KV-cache ещё до того, как прочитает первое слово промпта:

16 кадров  ×  256 токенов на кадр  =  4 096 токенов-картинок контекста

Четыре тысячи токенов черновика на запрос – только ради картинок, и это та память, которую возвращает PagedAttention. Чем сильнее ваша видео-функция опирается на кадры, тем больше управление памятью в слое обслуживания решает, влезет ли на карту восемь запросов или восемьдесят.

Нажмите, чтобы увеличить

vLLM – открытый дефолт

vLLM – это открытый inference-сервер, который построили те две идеи, и в 2026 году это разумная отправная точка для обслуживания почти любой языковой или vision-language модели. Он вышел из UC Berkeley как система при статье про PagedAttention и с тех пор стал самым используемым открытым сервером – с самой широкой поддержкой моделей и самым большим сообществом контрибьюторов среди всех вариантов здесь.

Дефолтом его делают три вещи. Первое – широта: он гоняет длинный хвост открытых моделей – семейство LLaMA, Qwen, Mistral и vision-language модели, которые реально нужны видео-команде, включая Qwen2.5-VL, LLaVA, InternVL и MiniCPM-V, – и работает не только на NVIDIA, но и на AMD, Google TPU, AWS Trainium и ускорителях Intel. Второе – знакомая входная дверь: vLLM выставляет OpenAI-совместимый API, то есть тот же формат запроса, что говорит с облаком OpenAI, говорит и с вашим self-hosted vLLM – меняется одна настройка, адрес сервера. Код, написанный под OpenAI SDK, переключается на вашу модель правкой в одну строку, поэтому уход с платного API на self-hosting обычно небольшая работа. Третье – он готов к запуску из коробки: есть официальные Docker-образы, Helm-чарты для Kubernetes и переработанный внутренний движок (V1 engine, дефолт с 2025 года), сделавший планировщик и поддержку мультимодальности быстрее и чище.

Для видео-продукта практический паттерн прост. Вы тянете Docker-образ vLLM, наводите его на модель – и получаете работающую точку, которая обслуживает вашего VLM-судью, ваш субтитратор или резюматор с PagedAttention и continuous batching, включёнными по умолчанию. Путь vllm docker – контейнер, который одинаково запускается на ноутбуке, арендованном GPU или в собственном датацентре, – самый частый способ развёртывания именно потому, что один и тот же образ ведёт себя одинаково везде.

vLLM против Ollama – раздел «продакшен против ноутбука»

Вопрос, который встаёт первым, потому что оба инструмента повсюду, – это vLLM против Ollama, и честный ответ в том, что они созданы для разных задач, и сравнение на самом деле про то, где модель работает, а не какой инструмент «лучше».

Ollama – инструмент для запуска модели на одной машине для одного пользователя: ваш ноутбук, рабочая станция, Mac на Apple Silicon. Для этого он прекрасен: установите, потяните модель – и через минуту уже общаетесь с ней, без GPU-кластера и без конфигурации. Он оборачивает эффективный одномашинный движок и оптимизирован под случай «один человек, одна модель, сам с ней говорит». Для прототипирования, локальной разработки и демо это самый быстрый путь.

Раздел появляется в тот момент, когда пользователей больше одного. Под реальной конкуренцией запросов батчинг и управление памятью vLLM уходят далеко вперёд: в бенчмарках 2026 года vLLM отдавал примерно в 2,3 раза больше токенов в секунду, чем Ollama, при восьми одновременных пользователях, и разрыв рос с нагрузкой – при пятидесяти одновременных пользователях один опубликованный тест намерил около 920 токенов в секунду у vLLM против примерно 155 у Ollama, причём хвостовая задержка vLLM была долей от Ollama. Причина структурная, а не случай настройки: Ollama не создан паковать много одновременных запросов на карту, а vLLM почти ни для чего другого и не создан.

«Частая ошибка. Тащить Ollama в продакшен потому, что его было легко поднять в разработке. Он отработает на демо с одним тестировщиком, а затем рухнет при первом реальном трафике – задержка лезет вверх, пропускная способность встаёт на полку, а счёт за GPU бессмыслен, потому что карта между запросами в основном простаивает. Ollama – правильный инструмент для стола и неправильный для парка. Зрелый паттерн – прототипировать на Ollama и переводить нагрузку на vLLM (или один из серверов ниже) за балансировщиком, как только карту делят больше пары пользователей. Используйте каждый там, где его место; не давайте инструменту разработки стать продакшен-архитектурой по инерции.»

Нажмите, чтобы увеличить

SGLang – претендент на префикс-кэшировании

vLLM – дефолт, но не единственный серьёзный открытый сервер. SGLang – ближайший конкурент в 2026 году, и его стоит знать из-за одного приёма, особенно ценного для видео-работы. Фирменная черта SGLang – агрессивное кэширование префиксов: когда у многих запросов одинаковое начало – тот же длинный системный промпт, та же рубрика, тот же подгруженный контекст – SGLang переиспользует уже посчитанный черновик для этого общего префикса, вместо того чтобы пересчитывать его для каждого запроса.

Этот паттерн в видео-ИИ повсюду. VLM-судья оценивает каждый выход по той же длинной рубрике. Митинг-копилот отвечает на множество вопросов по тому же подгруженному транскрипту. Проход модерации гоняет тот же промпт-политику по тысячам клипов. Всякий раз, когда дорогое начало промпта общее, кэширование префиксов у SGLang уходит далеко вперёд: опубликованные бенчмарки 2026 года ставят SGLang примерно на 29% выше vLLM на H100 на общих нагрузках, доходя до 6,4× на префикс-тяжёлых нагрузках вроде retrieval-augmented вопросов-ответов и многоходового чата. Расплата – зрелость экосистемы: у vLLM по-прежнему шире охват моделей и железа и больше сообщество, так что совет стандартен – начинайте на vLLM и тянитесь к SGLang, когда нагрузка действительно префикс-тяжёлая и вы измерили, что это окупается.

TensorRT-LLM – максимальная скорость NVIDIA и новости 2026 года

Когда цель – абсолютно наименьшая задержка и наибольшая пропускная способность на железе NVIDIA и нигде больше, ответ – TensorRT-LLM, собственная inference-библиотека NVIDIA. Она выигрывает на чистой скорости – опубликованные бенчмарки 2026 года ставят её на 15–30% выше vLLM по пропускной способности на картах H100, и она поддерживает speculative decoding (приём, который набрасывает несколько токенов вперёд и проверяет их пачкой) ради ускорения генерации в несколько раз на подходящих моделях. Если вы привязаны к NVIDIA и последние 20% производительности стоят реальных инженерных усилий, это потолок.

Исторической ловушкой была цена настройки. TensorRT-LLM традиционно требовал компиляции модели в специфичный под железо «движок» (engine) – шаг сборки, который мог занимать десятки минут и который приходилось повторять всякий раз, когда менялись модель, тип GPU или настройки. Для команды, меняющей модели ежемесячно, этот налог на компиляцию был болезненным, и именно поэтому TensorRT-LLM долго считался экспертным вариантом.

Вот это и меняют tensorrt-llm news 2025–2026 годов, и это стоит знать, потому что большинство старых сравнительных статей всё ещё описывают болезненную версию. NVIDIA пересобрала TensorRT-LLM вокруг PyTorch-нативного бэкенда, который вообще не требует сборки движка – стандартную PyTorch-модель можно прогнать напрямую через высокоуровневый Python-интерфейс (LLM API), что сворачивает старую многошаговую сборку во что-то близкое к «навёл vLLM на модель и поехал». Сопутствующая функция AutoDeploy берёт готовую PyTorch-модель и применяет инференс-оптимизации автоматически. Практический эффект: TensorRT-LLM в 2026 году куда менее экспертный инструмент, чем подсказывает его репутация, и разрыв в усилиях на настройку против vLLM резко сузился. Реальной расплатой остаётся вендор-лок на NVIDIA – TensorRT-LLM не работает на AMD, TPU или чём-то ещё, – поэтому решение теперь меньше про «вытерпим ли мы шаг компиляции» и больше про «мы NVIDIA-only по выбору или нет».

Triton и NVIDIA Dynamo – много моделей на одном парке

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

Работа Triton – гонять много разных моделей, многих видов, на одном общем парке GPU, за одной точкой. Он говорит сразу на нескольких бэкендах – может держать рядом в одном серверном процессе движок TensorRT, PyTorch-модель, ONNX-модель, OpenVINO-модель и даже экземпляр vLLM – и выполняет их параллельно на тех же картах. Его самая релевантная для видео функция – ensemble: конвейер, заданный внутри Triton, так что один клиентский запрос проходит через несколько моделей последовательно – декодировать, затем детектировать, затем описать – без возврата в ваше приложение между шагами. Для многомодельной видео-функции это родная форма: ensemble в Triton и есть конвейер с Рисунка 1, выраженный конфигурацией сервера. Triton активно поддерживается в 2026 году (релиз декабря 2025 добавил, среди прочего, улучшения vLLM-бэкенда и конфигурации ensemble), и он остаётся продакшен-стандартом, когда парк должен одновременно обслуживать LLM, embedding-модель и vision-энкодер.

Более крупное развитие 2026 года сидит даже над Triton. На своей конференции GTC 2025 NVIDIA анонсировала Dynamo – открытый, датацентрового масштаба фреймворк распределённого инференса, который она описывает как преемника Triton. Dynamo создан под крупнейшие развёртывания – тысячи GPU, – и его ключевые идеи это disaggregated serving (разделение двух фаз модели – начального «прочитать промпт» prefill и пословного «писать ответ» decode – на разные GPU, чтобы каждую можно было настраивать и масштабировать отдельно) и KV-aware routing (отправка каждого запроса на тот GPU, что уже держит нужный черновик). NVIDIA сообщила о росте до 30× обслуженных запросов на reasoning-модели на новейшем железе Blackwell – и, что важно для всех остальных, Dynamo создан оркестрировать vLLM, SGLang и TensorRT-LLM под собой, а не заменять их. Для большинства видео-команд Dynamo за горизонтом – это инструмент на «парк из тысяч», – но это направление, куда движется мир обслуживания, и оно говорит, куда идут одноузловые серверы выше.

Обслуживание моделей, которые не LLM

Серверы для LLM и VLM получают всё внимание, но два этапа видео-конвейера работают на совсем других движках, и план обслуживания, который их игнорирует, неполон.

Распознавание речи – первый. Этап транскрипции обычно вообще не работает на vLLM – он работает на специализированном движке. Самый частый продакшен-выбор – faster-whisper, переписанная реализация модели Whisper от OpenAI поверх CTranslate2, высокопроизводительного inference-движка с собственным GPU-кодом и встроенным 8-битным сжатием. Ускорения большие и очень релевантны всем, кто транскрибирует архивы видео: faster-whisper примерно в 4 раза быстрее оригинального Whisper при той же точности, а батчевая версия достигает примерно 12,5× быстрее, обрабатывая длинные файлы в сотни раз быстрее реального времени. Одна опубликованная цифра 2026 года: одна карта среднего класса L40S тянет 100+ одновременных потоков транскрипции; банк потребительских карт транскрибирует тысячу часов аудио примерно за полчаса. Для продукта, которому надо субтитрировать или транскрибировать в объёме, выбор ASR-движка двигает счёт не меньше, чем выбор LLM-сервера.

Модели компьютерного зрения – второй. Модели детекции и сегментации – YOLO, SAM, оценщики позы – берут картинку фиксированного размера и за один проход возвращают результат фиксированного размера, без растущего черновика. Их узкое место – чистая матричная пропускная способность, и стандартный способ обслуживать их быстро – конвертировать в движок TensorRT (тот самый оптимизатор под TensorRT-LLM) и хостить, часто через Triton, рядом с остальным конвейером. Здесь домой возвращаются решения о форматах моделей из урока про форматы артефактов моделей: экспорт детектора в ONNX и компиляция в TensorRT – рутинный путь к реальному времени в CV-обслуживании. Урок для плана обслуживания в том, что у вопроса «какой сервер мы используем» в одной видео-функции есть как минимум три ответа – сервер генерации текста для языковых моделей, ASR-движок для речи и CV-рантайм для зрения, – а архитектура это то, как они соединяются.

Serverless-GPU – когда сервер вообще не нужно держать

Есть ещё один вариант, и для многих видео-продуктов это правильный первый шаг: не управлять GPU-сервером самому. Платформы serverless-GPU – Modal, Replicate, RunPod и другие – сдают вам инференс посекундно и масштабируются до нуля: GPU поднимается, когда приходит запрос, выполняет его и выключается, так что при отсутствии трафика вы не платите ничего. Для всплесковой, непредсказуемой нагрузки, которая описывает большинство ранних видео-функций – функция резюме, используемая рывками, редкая проверка модерации, – это куда дешевле и проще, чем держать GPU арендованным и простаивающим круглые сутки.

Цена масштаба-до-нуля – это cold start: ожидание, пока GPU включится и загрузит модель. Опубликованные цифры 2026 года ставят его в несколько секунд для маленьких моделей и 15–30 секунд для моделей от 7 миллиардов параметров – нормально для фоновой задачи, гибельно для живого взаимодействия. Платформы по-разному с этим борются. Снапшоты GPU-памяти у Modal (захват состояния загруженной модели ради быстрого восстановления) резко сократили часть cold start'ов; RunPod жёстче всех конкурирует по цене (H100 около $7 в час на момент написания); Replicate держит популярные модели «тёплыми», так что у стандартных cold start фактически нет. Правило выбора – про форму трафика, подробнее в уроке про задержку и развёртывание: стабильный высокообъёмный трафик оправдывает выделенный «тёплый» кластер vLLM; всплесковый, малообъёмный или непредсказуемый обычно живёт на serverless, пока цифры не скажут иначе.

Решение – какой сервер под какую работу

Поставим варианты рядом. Единого победителя нет; есть правильный инструмент под каждый этап и под каждую форму трафика. Таблица ниже – это решение в одном месте.

Скоропись, к которой сходится большинство команд: начинайте на vLLM для всего, что генерирует текст или читает кадры; обслуживайте речь на faster-whisper, а детекцию на TensorRT; тянитесь к SGLang, когда нагрузка префикс-тяжёлая, к TensorRT-LLM, когда вы NVIDIA-only и гонитесь за последней задержкой, и к Triton, когда один парк должен обслуживать несколько моделей как конвейер. Запускайте всё на serverless, пока трафик мал и всплесков, и переходите на «тёплый» выделенный кластер, когда объём перевернёт математику.

Нажмите, чтобы увеличить

Разбор на цифрах – чего стоит continuous batching

Сделаем деньги конкретными, потому что весь довод в пользу заботы о слое обслуживания – это счёт. Допустим, вы обслуживаете модель резюмирования на одной арендованной GPU, которая стоит, ради чистой арифметики, $3,00 в час. При наивном static batching карта простаивает большую часть времени, ожидая медленные запросы, и работает примерно на 35% загрузки. Переключитесь на сервер с PagedAttention и continuous batching – и та же карта работает примерно на 85% загрузки.

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

85% занят  ÷  35% занят  =  2,4×  больше токенов с того же GPU

Теперь превратим это в стоимость единицы работы. Скажем, медленная установка выдаёт 1,0 миллиона токенов в час. Стоимость миллиона токенов – это просто часовая аренда, делённая на выданные токены:

медленно:  $3,00 / ч  ÷  1,0M токенов/ч  =  $3,00 за миллион токенов
быстро:    $3,00 / ч  ÷  2,4M токенов/ч  =  $1,25 за миллион токенов

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

Где здесь Фора Софт

Мы строим видео-продукты в конференц-связи, стриминге и OTT, e-learning, телемедицине и видеонаблюдении, и ИИ-функции в них – это конвейеры, а не одиночные модели: запись становится транскриптом, набором описаний кадров, резюме и решением модерации, каждое от своей модели. Наша практика обслуживания следует форме этого конвейера: языковые и vision-language этапы – на vLLM за OpenAI-совместимой точкой, чтобы код продукта не заботило, чья модель – наша или вендора; речь – на Whisper-движке на CTranslate2, размеренном под объём транскрипции; детекция и сегментация – экспортированы в TensorRT для реального времени; и вся цепочка сшита так, чтобы один запрос проходил через неё без расточительных возвратов. Мы стартуем функции на serverless-GPU, пока трафик мал и всплесков, и переводим их на «тёплую» выделенную ёмкость, когда объём делает это дешевле, и относимся к стоимости за токен, а не только к задержке, как к числу, которое стоит инженерно снижать. Вертикали меняют модели и цели по задержке; метод – подобрать каждому этапу свой сервер и держать GPU занятым – не меняется.

Ключевые выводы

• Инференс-сервинг превращает обученную модель в быстрый сервис; выбор может вдвое срезать стоимость токена на той же GPU.
• vLLM – открытый дефолт 2026: PagedAttention режет потери памяти ниже 4%, continuous batching держит GPU на 75–90%.
• Ollama – для одного пользователя на одной машине; vLLM – для многих на парке – не тащите Ollama в продакшен.
• TensorRT-LLM даёт максимум скорости NVIDIA и, с PyTorch-бэкендом, больше не требует медленной компиляции движка.
• Triton обслуживает много моделей как конвейер; NVIDIA Dynamo (2025) – его датацентровый преемник.
• Видео-ИИ – многомодельный конвейер: речь на faster-whisper, зрение на TensorRT, язык на vLLM – и соединить.

Что почитать дальше

• Дистилляция и квантизация для edge видео-ИИ
• Оптимизация затрат – 25 рычагов для видео-ИИ в масштабе
• Задержка, развёртывание и реальное время против батча – edge против cloud