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

Кратко

Инференс-сервинг – это слой, превращающий обученную модель в быстрый и постоянно доступный сервис, к которому обращается ваш видео-продукт. Выбор серверного софта напрямую влияет на стоимость обработки каждого резюме, субтитра или детекции – нередко в два и более раза на одном и том же железе. Открытый стандарт по умолчанию в 2026 году – это vLLM, чьи две ключевые идеи – PagedAttention, не дающий модели впустую тратить память видеокарты, и continuous batching, обеспечивающий постоянную загрузку GPU, – позволяют достичь пропускной способности в 2–4 раза выше, чем у серверов предыдущего поколения, и значительно опережают «ноутбучные» инструменты вроде Ollama при реальной нагрузке. Чтобы максимально использовать производительность карт NVIDIA, применяется TensorRT-LLM, переработанный вокруг PyTorch-процесса и устраняющий медленный этап компиляции движка. А для запуска множества разных моделей на одном парке GPU предназначен 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 – разница между плитой, которая наполовину остыла, и той, что постоянно работает.

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

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 при общих нагрузках, а при префикс-интенсивных задачах – таких как retrieval-augmented вопросы-ответы и многоходовый чат – преимущество достигает 6,4×. Единственная плата – уровень зрелости экосистемы: у vLLM по-прежнему шире поддержка моделей и аппаратного обеспечения, а также больше сообщество, поэтому стандартный совет остаётся прежним – начинайте с vLLM и переходите на SGLang, только когда нагрузка действительно префикс-интенсивна и вы точно убедились, что это окупается.

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

Когда цель – минимальная задержка и максимальная пропускная способность на железе NVIDIA, и нигде больше, правильный выбор – TensorRT-LLM, собственная библиотека для инференса от NVIDIA. Она выигрывает по чистой скорости: опубликованные бенчмарки 2026 года показывают, что она обеспечивает на 15–30% большую пропускную способность на картах H100, чем vLLM. Кроме того, она поддерживает 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-модель и автоматически применяет оптимизации для инференса. Практический эффект: в 2026 году TensorRT-LLM стал гораздо менее «экспертным» инструментом, чем подсказывает его репутация, и разрыв в трудозатратах на настройку по сравнению с vLLM резко сократился. Единственная реальная плата – вендорская привязка к NVIDIA: TensorRT-LLM не работает на AMD, TPU или других платформах. Поэтому теперь выбор сводится не к тому, готовы ли мы пройти этап компиляции, а к тому, используем ли мы NVIDIA исключительно по собственному выбору или нет.

Triton и NVIDIA Dynamo – запуск множества моделей на одном вычислительном парке

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

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

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

Обслуживание моделей, не являющихся LLM

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

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

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

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

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

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

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

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

Скоропись, к которой приходят большинство команд: начинайте с vLLM для генерации текста и обработки кадров; используйте faster-whisper для речи, TensorRT для детекции; переходите на SGLang, если нагрузка префикс-ёмкая, на TensorRT-LLM, если работаете только на NVIDIA и стремитесь к минимальной задержке, и на 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