Висновки за межами тексту: налаштування VLM, ембеддингів, мовлення, зображень та відео
Кожна модальність має свою вузьку місце. Дізнайтеся, як налаштувати VLM, ембеддери, ASR, TTS, генератори зображень та відео за допомогою правильного батчингу, ядер, кешування та квантації.
Прискорення мовної моделі, яка працює лише з текстом, — це вже достатньо розв’язана проблема, тож люди вважають її прийоми універсальними. Це не так. Як тільки ви випускаєте справжній продукт, генерація тексту стає лише одним з кількох етапів, і кожен етап має свою проблему з обмеженнями продуктивності. Прийом налаштувань, який подвоює швидкість роботи LLM, може бути марним для моделі ембеддингів, а генерація зображень чи відео створює власні проблеми з обчисленнями та увагою. Тут ви познайомитеся з моделями зору та мови, ембеддерами, ASR, TTS, системами перекладу мови в мову, генераторами зображень та відео, починаючи з двох основних шаблонів виконання, а потім розглянете показники ефективності, вибір обладнання, кешування, квантовання, групування даних та компроміси щодо якості для кожного з них. Основна ідея: інженерія інференсу залежить від обсягу роботи.
Чому один підхід не спрацьовує
Реальні додатки поєднують моделі між собою. Голосовий асистент може прийняти аудіо, виконати розпізнавання мовлення, проаналізувати отриманий текст, а потім синтезувати мовлення. Система для роботи з документами може обробити PDF за допомогою OCR, моделі розпізнавання зображень та ембеддингів перед пошуком інформації, а також за допомогою LLM. Відеоінструмент може перетворити текст на створений кліп шляхом ітеративного усунення шуму, а потім декодувати медіафайл.
Кожен етап має свою власну структуру витрат, тому те, що оптимізують, змінюється разом із ним. Те, що робить авторегресивну мовну модель швидкою, не можна просто застосувати до процесів обробки зображень чи відео.
Два патерни охоплюють більшу частину випадків
Майже кожна генеративна система підпорядковується одному з двох патернів.
Перший — це авторегресивна генерація. Модель створює результат поступово, кожен токен формується на основі попередніх даних:
Input
↓
Token 1
↓
Token 2
↓
Token 3
↓
...
Це знайомий цикл LLM. Моделі візуалізації та мови, системи ембеддингу, побудовані на основі мовних моделей, декодери ASR та багато моделей TTS можуть запозичити багато ідей щодо роботи з трансформерами з цього підходу.
Другий — це ітеративне видалення шуму, а саме метод дифузії, при якому початкова шумна точка поступово удосконалюється крок за кроком:
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 — це не ШІ, але його декодер функціонує як такий та займає більшу частину часу обробки. Це робить оптимізації у стилі ШІ особливо ефективними. Для прямої транскрипції ключовим показником не є проста продуктивність. Система має діяти миттєво, і розумною метою є час обробки близько 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
Ніколи не вважайте, що оптимізація кешування є безпечною лише тому, що відео все ще виглядає правдоподібним.
Квантування відповідає «вузькому місцю»
Для моделей LLM квантування зазвичай стосується великих лінійних шарів та ваг, оскільки обробка даних у цих моделях часто обмежується пропускною здатністю пам’яті. Генерація відео обмежується потужністю обчислень, особливо механізмом уваги, тому саме цей механізм стає привабливою метою для квантування. Однак механізм уваги також дуже чутливий до числових похибок.
Існують два варіанти. Ви можете квантувати даних у блоках, використовуючи формати з мікромасштабуванням, такі як 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.
Висновки
- Багатомодальні висновки залежать від обсягу роботи. Найкраща архітектура відповідає шаблону виконання та вимогам продукту.
- Авторегресивні та дифузійні моделі мають принципово різні узких місця.
- VLM перетворюють візуальний вхід на додатковий контекст, тому налаштування KV-cache та роботи з довгим контекстом мають більше значення.
- Системи ембеддингів — це переважно проблеми батчування та пропускної здатності, а не проблеми затримки декодування.
- Покращення в ASR досягаються переважно завдяки оркестрації та стрімінгу, а не лише швидшим кернам.
- У випадку TTS, коли швидкість генерації перевищує швидкість реального часу, налаштування стають проблемою кількості одночасних користувачів.
- Генерація зображень залежить від обчислювальних ресурсів, тому керни, процеси фузії, компіляція та скорочення кількості кроків деноїзингу мають вирішальне значення.
До чого це призводить
Продукти ШІ за замовчуванням стають багатомодальними. Текст, зображення, аудіо, відео та ембеддинги все більше інтегруються в одне застосування, тож завдання змінюється з налаштування однієї моделі на налаштування всього потоку обробки даних. Питання вже не в тому, яку техніку оптимізації використати, а в тому, де знаходиться вузьке місце у конкретному завданні та який компроміс можна безпечно здійснити, щоб його усунути.
Такий підхід застосовується як у випадку однієї GPU, що обробляє модель ембеддингів, так і у випадку кластера з кількох GPU, який генерує відео в реальному часі. Потрібно знати обсяг роботи, визначити «вузьке місце», протестувати компроміси, які ви готові прийняти, та налаштувати всю систему, а не лише модель.