Инференс за пределами текста: настройка VLM, эмбеддингов, речи, изображений и видео

Ускорение модели, работающей только с текстом, — это уже решённая проблема, из-за чего люди считают её приёмы универсальными. На самом деле это не так. Как только вы выпускаете реальный продукт, генерация текста становится лишь одним из этапов среди многих других, и у каждого этапа свои узкие места. Метод настройки, который вдвое ускоряет работу LLM, может оказаться бесполезным для модели эмбеддингов, а генерация изображений или видео создаёт собственные проблемы с вычислениями и обработкой внимания. Здесь вы познакомитесь с моделями видео- и текстового анализа, генераторами эмбеддингов, системами ASR и TTS, а также генераторами изображений и видео; мы рассмотрим два основных способа их работы, а затем — показатели эффективности, варианты аппаратного обеспечения, техники кэширования, квантизацию, группировку задач и компромиссы в качестве для каждого из них. Основная идея: инженерия интерпретации зависит от характера задачи.

Почему один подход не срабатывает

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

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

Два основных подхода охватывают большинство случаев

Почти все генеративные системы следуют одному из двух подходов.

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

Input
  ↓
Token 1
  ↓
Token 2
  ↓
Token 3
  ↓
...

Это знакомый цикл больших языковых моделей. Модели визуального понимания и обработки языка, системы эмбеддингов, построенные на основе языковых моделей, декодеры ASR и многие модели голосового синтеза могут заимствовать из него множество идей, связанных с работой трансформеров.

Второй подход — итеративная деноизация, метод диффузии, при котором шумный исходный материал совершенствуется шаг за шагом:

Random / noisy latent
        ↓
      Step 1
        ↓
      Step 2
        ↓
      Step 3
        ↓
       ...
        ↓
Final image/video

Генерация изображений и видео в основном происходит здесь.

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

Модели визуального и языкового анализа преобразуют изображения в токены

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

Image / Video
      │
      ▼
Vision Encoder
      │
      ▼
Visual Tokens
      │
      ▼
Language Model
      │
      ▼
Text Response

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

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

Работа с видео быстро становится ресурсоемкой

Изображения стоят денег. Видео увеличивает эти затраты. При 24 кадрах в секунду даже короткий клип генерирует огромное количество визуальных токенов. Четырехсекундный клип высокой четкости в принципе может содержать около 100 000 входных токенов до любого практического снижения разрешения.

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

Омни-модальные модели не всегда являются решением

Индустрия движется в направлении моделей, которые могут одновременно принимать и генерировать данные нескольких типов:

Text ─────┐
Image ────┤
Audio ────┼──► Omni Model ──► Text / Audio / Image
Video ────┘

Это звучит идеально, но у общности есть своя цена. Специализированная модель OCR может превзойти функции OCR, встроенные в крупную VLM, а специально разработанная модель речи может работать эффективнее, чем универсальная мультимодальная модель. Поэтому производственные системы часто превращаются в цепочки специалистов:

┌──► OCR
PDF/Image ───┤
             ├──► Vision Model
             └──► Embedding Model
                       │
                       ▼
                     LLM

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

Модели эмбеддингов нуждаются в высокой пропускной способности

Модели эмбеддингов принципиально отличаются от генеративных LLM. Они преобразуют содержимое в вектор фиксированного размера:

Document / Image
       ↓
Embedding Model
       ↓
[0.12, -0.43, 0.87, ...]

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

Одной из таких форм является массовое встраивание данных, например, загрузка десяти миллионов документов в базу данных векторов:

10 million documents
       ↓
Embedding pipeline
       ↓
Vector database

В этом случае преимущества дает пропускная способность и низкая стоимость. Другой вариант — онлайн-поиск, при котором запрос пользователя сразу же обрабатывается и ищется:

User query
    ↓
Embedding
    ↓
Vector search

Здесь решающую роль играют миллисекунды. Когда оба параметра достаточно велики, отдельные реализации часто оказываются преимущественнее, поскольку каждую из них можно настроить под собственную цель.

Размерность и совместимость

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

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

Пакетная обработка — основной инструмент для эмбеддингов

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

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

Requests
   ↓
Queue
   ↓
Batch Manager
   ↓
GPU Replica 1
GPU Replica 2
GPU Replica 3
GPU Replica 4

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

Распознавание речи: доминирует декодер

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

Audio
  ↓
Audio preprocessing
  ↓
Encoder
  ↓
Autoregressive Decoder
  ↓
Transcript

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

Стриминг меняет подход

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

Upload audio
      ↓
Wait
      ↓
Receive transcript

Перейти на непрерывный режим работы:

Continuous Audio
       ↓
     VAD
       ↓
Audio Chunks
       ↓
    ASR GPU
       ↓
Streaming Transcript

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

Для длинных записей необходим параллелизм

Длинные файлы — это нечто совершенно иное, чем интерактивная диктовка. Вместо того чтобы обрабатывать их по порядку:

Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4

Вы можете создать параллельную систему обработки:

┌──► GPU 1 ──► Chunk 1
Audio → VAD ─────┼──► GPU 2 ──► Chunk 2
                 ├──► GPU 3 ──► Chunk 3
                 └──► GPU 4 ──► Chunk 4
                              ↓
                         Stitch by time

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

TTS: цель не в большем количестве токенов в секунду

Функция текста в речь работает в противоположном направлении, чем ASR:

Text
 ↓
TTS Model
 ↓
Audio Tokens
 ↓
Audio Decoder
 ↓
Waveform

Современные модели TTS часто используют архитектуры, похожие на LLM, поэтому оптимизированные ядра, обработка данных пакетами и работа с низкой точностью заимствуются из систем обслуживания LLM. Однако метрики отличаются небольшими деталями. Генерация 500 аудиотокенов в секунду не лучше, чем 100, если декодер аудио требует результатов примерно в реальном времени. Как только скорость генерации сравнивается с реальным временем, вопрос сводится к тому, сколько один GPU может обслуживать одновременных пользователей. Речь идет об оптимизации под требования продукта, а не под значения тестовых показателей.

Генерация изображений: откажитесь от привычек, свойственных LLM

Инструменты генерации изображений в основном представляют собой итеративные фильтры шума, а не устройства для создания изображений по токенам:

Noise
 ↓
Denoising Step 1
 ↓
Denoising Step 2
 ↓
...
 ↓
Image

В отличие от декодирования с использованием LLM, этот тип задач обычно ограничен вычислительными возможностями, поэтому пропускная способность памяти больше не является главной проблемой. Акцент смещается на выбор ядер, их объединение, эффективное использование механизма внимания, настройку операций типа GEMM, компиляцию с помощью Torch, снижение точности и уменьшение объема работ по удалению шумов.

Ядра играют огромную роль

Ядра механизма внимания особенно важны при генерации изображений. В зависимости от архитектуры GPU и способа реализации можно использовать оптимизированные варианты, такие как FlashAttention, DeepGEMM, CuTe и CUTLASS. Операции нормализации, например RMSNorm, также могут служить хорошими кандидатами для объединения с другими операциями.

Главный урок заключается в том, что оптимальный движок вывода зависит как от объема работы, так и от аппаратного обеспечения. PyTorch обеспечивает гибкость, специализированные реализации поставляют настроенные ядра, а компиляция позволяет объединять операции в специфичный для GPU путь выполнения. Правильный ответ получается путем тестирования вашей реальной модели на вашем реальном оборудовании.

Эффективный трюк для процесса диффузии

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

Конкретный трюк имеет меньшее значение, чем принцип. Не каждая итерация в равной степени влияет на конечный результат, и оптимизация вывода может использовать это неравенство.

Генерация видео — это другой масштаб

Генерация видео — это генерация изображений с добавленной временной размерностью. Если скрытый представитель изображения — это:

Height × Width

Видео в скрытом виде становится:

Height × Width × Time

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

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

Механизм внимания доминирует в обработке видео

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

Кэширование в обработке видео работает иначе

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

Optimization
     ↓
Speed ↑
     ↓
Quality ?
     ↓
Evaluate
     ↓
Production

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

Квантизация ориентируется на узкие места

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

Существует два варианта. Вы можете квантизировать по блокам с использованием форматов микромасштабирования, таких как MXFP8, или же квантизировать выборочно, изменяя точность на каждом этапе:

Early steps   → FP16
Middle steps  → Lower precision
Late steps    → Lower precision

или по слоям:

Input layer   → FP16
Hidden layers → Lower precision
Output layer  → FP16

Сохраняйте точность там, где модель уязвима, и оптимизируйте интенсивно там, где это не требуется.

Универсальной оптимизации не существует

У стратегий, эффективных в разных форматах данных, совершенно разные подходы:

| Modality         | Dominant Concern            | High-Value Techniques                                 |
| ---------------- | --------------------------- | ----------------------------------------------------- |
| VLM              | Long visual context         | KV optimization, caching, parallelism                 |
| Embeddings       | High request volume         | Batching, queueing, horizontal scaling                |
| ASR              | Decoder latency             | Optimized decoder, streaming, parallel chunks         |
| TTS              | Real-time concurrency       | Streaming, batching, efficient decoding               |
| Image generation | Compute                     | Kernel fusion, compilation, fewer expensive passes    |
| Video generation | Massive compute + attention | Attention kernels, caching, quantization, parallelism |

Именно поэтому инжиниринг выводов ближе к работе с системами, чем к простому ускорению LLM.

Выводы

1. Мультимодальные процессы вывода зависят от объема работы. Оптимальная архитектура соответствует шаблону выполнения и требованиям продукта.
2. Авторегрессивные и диффузионные модели имеют совершенно разные узкие места.
3. VLM преобразуют визуальный ввод в дополнительный контекст, поэтому настройка KV-кэша и обработки длинного контекста имеет большее значение.
4. Системы эмбеддингов в основном сталкиваются с проблемами группировки данных и пропускной способности, а не с задержками декодирования.
5. Улучшения в ASR во многом достигаются за счет оркестрации и потоковой обработки, а не только более быстрых ядер.
6. Для TTS, когда скорость генерации превышает скорость реального времени, настройка сводится к вопросу одновременно работающих пользователей.
7. Генерация изображений ограничена вычислительными ресурсами, поэтому критически важны ядра, процессы слияния данных, компиляция и сокращение количества шагов деноизинга.

Генерация видео усугубляет эти проблемы из-за огромной нагрузки на механизм внимания и необходимости использования нескольких GPU.

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

Квантизируйте там, где находится узкое место. Веса подходят для моделей LLM с ограниченной памятью, в то время как для видео с ограниченными вычислительными ресурсами важнее оптимизация механизма внимания.

К чему это приводит

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

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