LLM-инференс с TGI: снижаем latency и экономим VRAM

Почему TGI инференс упирается в задержки и видеопамять

В TGI инференсе одиночный запрос отвечает быстро — узкое место проявляется, когда рядом встают десятки одновременных обращений. Очередь на вывод модели растёт быстрее, чем пропускная способность, и время ответа увеличивается нелинейно: при удвоении нагрузки ожидание может вырасти втрое. Для сервиса это выглядит как «модель тормозит», хотя на деле упёрлись именно в пропускную способность вывода.

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

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

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

Три узкие места — пропускная способность вывода, лимит видеопамяти и хрупкость длинных генераций — связаны между собой, поэтому лечатся не по отдельности. Разбираем, как это закрывается.

Что даёт управляемый конвейер обслуживания языковых моделей

Конвейер обслуживания начинается с профиля нагрузки: длины входов и ответов, доля параллельных обращений, целевой 95-й процентиль времени ответа. Под него настраивается динамическое объединение запросов в пакет — обращения собираются в пределах заданного окна, а не ждут поодиночке. Под пиком время ответа растёт с замедлением, а не кратно числу обращений.

Плотность размещения моделей — второй эффект конвейера. Страничная организация кэша внимания снимает фрагментацию памяти, веса приводятся к пониженной точности там, где качество ответов это выдерживает. На том же парке ускорителей умещается несколько моделей вместо одной, и разделение портфеля задач не требует новых закупок. В Hugging Face TGI это штатные режимы — наши инженеры настраивают их под профиль нагрузки, а не оставляют значения по умолчанию.

Третий слой — управляемая деградация. Пределы на размер пакета, длину очереди и время выполнения отдельного запроса ставятся так, чтобы под перегрузкой сервис возвращал часть обращений с явной ошибкой, а не замедлялся для всех сразу. Пропускная способность измеряется серией прогонов с растущим числом параллельных обращений: видно точку, после которой время ответа выходит за согласованные границы.

Итог выражается в числах. 95-й процентиль времени ответа перестаёт «плавать» от релиза к релизу, плотность размещения моделей растёт в 2–3 раза, а поведение под пиком описывается заранее известной кривой. Это и есть предсказуемость сервиса — нагрузка растёт по понятному сценарию, а не в ночной разбор инцидента.

Режимы запуска модели: что выбрать под вашу нагрузку

Режим запуска определяет, как узел делит видеопамять между весами модели, кэшем и очередью запросов. Отсюда две разные метрики: задержка отклика для одного пользователя и пропускная способность под пиком. Одновременно улучшить обе почти не получается, поэтому режимы запуска модели в TGI выбирают под профиль нагрузки, а не «на вырост».

Решение упирается в запас памяти — укладывается ли рабочая модель вместе с пакетом и кэшем. Если да, выгоднее один процесс на модель и общий поток запросов. Если нет — модели разносят по узлам, и изоляция моделей на узле гарантирует, что вытеснение одной не уронит соседнюю.

Сравнение вариантов

Рабочим обычно оказывается гибрид: узел с одной моделью под сценарии, чувствительные к задержке, и отдельный узел с пакетной обработкой под фоновые задачи. Подбираем конфигурацию по реальному профилю запросов — доля коротких, длина ответов, суточные пики.

Как мы разворачиваем TGI инференс: этапы работ

Работу начинаем с аудита контура модели: смотрим, какие модели и веса уже используются, как устроен доступ к ним, какие требования к задержке отклика и пропускной способности заявлены. На этом этапе фиксируем целевую схему — один узел вывода или несколько, нужна ли очередь запросов, как делится память между копиями модели и что происходит при отказе узла. Без этого настройка превращается в подбор параметров наугад: конфигурация работает на тестовом запросе и рассыпается на реальном трафике.

1. Аудит контура модели. Инвентаризация моделей и весов, замер текущих задержек и пропускной способности, проверка ограничений оборудования, сети и прав доступа.
2. Проектирование схемы развёртывания. Определяем топологию: число копий модели, распределение запросов, хранение весов и кэша, изоляцию окружений, безопасный доступ к API.
3. Настройка вывода. Подбираем размер пакета запросов, глубину очереди, режим квантизации и лимиты памяти так, чтобы задержка оставалась предсказуемой под пиком.
4. Автоматизация развёртывания. Описываем конфигурации как код, добавляем сборку образов, проверки совместимости версий и откат на предыдущий релиз одной командой.
5. Проверка под нагрузкой. Прогоняем профиль, близкий к реальному трафику: длинные и короткие запросы, всплески, отказ одного узла. Смотрим, где растёт очередь и во сколько раз падает пропускная способность.
6. Передача в эксплуатацию. Отдаём дашборды с метриками вывода, алерты на деградацию, регламент обновления моделей и инструкции для дежурной смены.

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

Артефакты внедрения: конфигурации, схемы и регламенты

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

• Передача конфигураций инференса — версионированные файлы запуска TGI: лимиты батча и очереди запросов, параметры квантования, профили под разные модели и режимы нагрузки.
• Схема архитектуры вывода — путь запроса от шлюза до реплик модели, правила маршрутизации, поведение при отказе узла и при перегрузке очереди.
• Политики доступа к моделям — ключи и роли, разграничение сред, лимиты по частоте и объёму запросов, журнал обращений для разбора инцидентов.
• Регламент обновления моделей — порядок выката новых весов, поэтапный прогон на части трафика, критерии отката и окно переключения.
• Документация для эксплуатации — метрики и пороги оповещений, типовые отказы и порядок действий, прогрев реплик после перезапуска.
• Инфраструктурные манифесты — описание окружения как кода, чтобы стенд поднимался воспроизводимо, а не по памяти инженера.
• Приёмочный отчёт с замерами — задержка на целевом профиле нагрузки, потребление памяти, доля ошибок до и после оптимизации.

Такой комплект снимает зависимость от подрядчика: новый инженер вводится в проект по документации за считанные дни, обновление модели становится плановой операцией с предсказуемым откатом, а инциденты разбираются по схеме, а не по переписке.

Кейс: ускорили отклик и снизили расход видеопамяти

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

Что перестроили

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

Медианный отклик после переезда — 1,1 секунды при том же профиле нагрузки, доля оборванных запросов — 0,3%. Резерв памяти сократился примерно вдвое: на узле работают четыре модели вместо одной, включая резервную, на которую переключаемся при выкатке. Класс отказов «память кончилась на нештатно длинном запросе» закрыт настройками — такой запрос получает внятную ошибку и не роняет соседние. Отдельно зафиксировали порог: при превышении лимита запросы встают в очередь, а не деградирует весь узел.

Что делать, если модель уже развёрнута на своём оборудовании

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

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

Интеграции сохраняются за счёт промежуточного слоя: приложения продолжают обращаться по тому же адресу и получать тот же ответ, меняется только движок за ним, а не код потребителей. Это и позволяет перестроить контур, не переписывая всё, что к нему привязано.

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

Технические сомнения: отвечаем на частые вопросы

Сомнения по выводу моделей почти всегда сводятся к одному: выдержит ли контур пиковую нагрузку и кто останется рядом после запуска. Ниже — короткие ответы на то, что чаще всего спрашивают до старта.

Как разграничивается доступ к модели и к данным, которые через неё проходят?

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

У нас уже работает другая модель — переезд будет болезненным?

Интерфейс совместим с распространёнными клиентскими библиотеками, поэтому приложение переключается сменой адреса сервиса. Перенос идёт через теневой трафик: новая модель отвечает параллельно, расхождения разбираем до переключения, а откат на прежнюю версию занимает минуты.

Кто отвечает за эксплуатацию после внедрения?

Передаём регламенты обновления моделей, настройки мониторинга и разбор типовых сбоев, обучаем вашу команду. Дальше — либо самообслуживание с документацией, либо наше дежурство и плановые обновления по согласованному уровню поддержки.

Обсудим вашу задачу и вернёмся с оценкой и планом

Чтобы оценка внедрения опиралась на инженерные факты, а не на общие пожелания, разбор начинаем с входных данных: профиль нагрузки, конфигурация стенда и метрики, которые вы уже снимаете. Ниже — что прислать, чтобы мы вернулись с планом работ, а не с уточняющими вопросами.

• описание сценария: какие запросы уходят в модель, средняя длина контекста, суточный и пиковый поток;
• конфигурация ускорителей: сколько их, какой объём памяти свободен под модель, как ресурсы делятся между сервисами;
• снятые метрики: время до первого токена, скорость генерации, доля оборванных запросов и повторов;
• примеры реальных обращений и требования к качеству ответов, включая недопустимые формулировки;
• ограничения: доступы, регламенты по хранению логов, окна, в которые допустимы изменения;
• уже случавшиеся сбои и их последствия — обычно это самый быстрый путь к узкому месту.

Дальше уточняем то, что не видно из описания: остаётся ли запас по памяти на пике, где теряется время — на подготовке запроса или на самом TGI-инференсе, нужна ли квантизация и не стоит ли она уже, какие изменения можно внести без перерыва в обслуживании.

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