Wniosek poza tekstem: dostrojenie VLM-ów, embeddingów, mowy, obrazu i wideo

Sprawne przyspieszenie modelu językowego opartego wyłącznie na tekście to problem już w dużej mierze rozwiązany, przez co ludzie traktują stosowane w nim techniki jako uniwersalne. W rzeczywistości tak nie jest. Gdy wprowadzisz na rynek prawdziwy produkt, generowanie tekstu staje się jednym z kilku etapów, a każdy z nich ma inne ograniczenia. Działanie optymalizacyjne, które podwaja szybkość działania modelu LLM, może okazać się bezużyteczne dla modelu opartego na embeddingach, a generowanie obrazów lub wideo niesie ze sobą własne problemy związane z obliczeniami i zarządzaniem uwagą. Tutaj poznasz modele łączące wizję z językiem, narzędzia do tworzenia embeddingów, systemy ASR i TTS, funkcje przekładu mowy na mowę, generatorzy obrazów i wideo, rozpoczynając od dwóch podstawowych wzorców realizacji, a następnie przyglądając się wskaźnikom, wyborom sprzętowym, mechanizmom cache’owania, kwantyzacji, grupowaniu zadań oraz kompromisom dotyczącym jakości dla każdego z nich. Główna myśl przewodnia: inżynieria inferencji zależy od rodzaju obciążenia.

Dlaczego jeden plan działania nie wystarcza

Rzeczywiste aplikacje łączą ze sobą modele. Asystent głosowy może przyjąć dźwięk, przeprowadzić rozpoznawanie mowy, przeanalizować uzyskany tekst, a następnie wygenerować mowę. System dokumentów może przetworzyć plik PDF za pomocą OCR, modelu wizyjnego oraz technologii embeddings przed wyszukiwaniem informacji, a także za pomocą modelu językowego typu LLM. Narzędzie do przetwarzania wideo może przejść od tekstu do wygenerowanego klipu poprzez iteracyjne usuwanie szumów, a na końcu dokonać dekodowania mediów.

Każdy etap ma swój własny profil kosztów, więc to, co optymalizujemy, zmienia się wraz z nim. To, co sprawia, że model językowy autoregresyjny działa szybko, nie może być po prostu zastosowane w procesach przetwarzania obrazów lub wideo.

Dwa wzorce obejmują większość przypadków

Prawie każdy system generatywny follows jeden z dwóch schematów.

Pierwszym jest generowanie autoregresywne. Model wytwarza wynik krok po kroku, przy czym każdy token jest uzależniony od tego, co pojawiło się wcześniej:

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

To jest znany cykl LLM. Modele wizji i języka, systemy embeddingów oparte na bazach modeli językowych, dekodery ASR oraz wiele modeli TTS mogą czerpać z nich wiele pomysłów dotyczących obsługi transformatorów.

Drugi to iteracyjne oczyszczanie z szumów, czyli podejście difuzyjne, w którym zaczątkowy, szumny punkt jest udoskonalany krok po kroku:

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

Generowanie obrazów i wideo odbywa się głównie tutaj.

To ma znaczenie, ponieważ nie można stosować jednej definicji opóźnienia, przepustowości czy wydajności we wszystkich przypadkach. W przypadku chatbotów kluczową wartością jest czas do pierwszego tokena. W syntezie mowy liczy się czas do uzyskania pierwszego sensownego dźwięku. W długich zadaniach transkrypcyjnych dominuje czynnik czasu rzeczywistego. Przy generowaniu obrazów skrócenie kroków usuwania szumów może być skuteczniejsze niż zmniejszenie opóźnienia procesora. W przypadku wideo uwaga oraz ogromne tensory mogą pochłonąć całe obciążenie.

Modele wizji-języka przekształcają obrazy w tokeny

VLM łączy kodera wizualnego z modelem językowym. Koder przekształca piksele w reprezentacje, które model językowy może odczytać razem z tekstem:

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

Ciekawym skutkiem jest to, że obraz wydłuża sekwencję wejściową. Jeden obraz o wysokiej rozdzielczości może dostarczyć około tysiąca tokenów wizualnych. Im więcej szczegółów wizualnych, tym więcej tokenów, a to z kolei oznacza większy kontekst i większą pamięć KV.

Dlatego dostrojenie VLM przypomina dość mocno dostrojenie modelu LLM z długim kontekstem. Należy rozważyć użycie kwantyzowanych pamięci KV, dekodowanie spekulatywne, cacheowanie prefiksów, paralelizm tensorowy, przenoszenie danych z pamięci cache lub oddzielenie operacji prefill od dekodowania. Ponowne wykorzystywanie prefiksów jest szczególnie korzystne przy powtarzających się obrazach i rozmowach wieloetapowych, a w miarę wydłużania się danych wejściowych zarządzanie pamięcią staje się coraz ważniejsze.

Rozumienie wideo szybko staje się kosztowne

Zdjęcia kosztują coś. Wideo te koszty pomnaża. Przy 24 kadrach na sekundę nawet krótki klip generuje ogromną ilość wizualnych tokenów. Czterosekundowy klip w wysokiej rozdzielczości może w zasadzie osiągnąć 100 000 tokenów wejściowych, zanim zostanie przeprowadzone jakiekolwiek praktyczne obniżenie rozdzielczości.

To sprawia, że obniżanie rozdzielczości stanowi główny kompromis pomiędzy jakością a szybkością w transakcjach. Można obniżyć rozdzielczość, szybkość odświeżania, liczbę kadrów lub liczbę wizualnych tokenów, choć każda z tych modyfikacji usuwa informacje. Dlatego pomijmy pytanie o to, jak przyspieszyć przetwarzanie wideo. Lepiej zapytać, jaka jest najmniejsza możliwa reprezentacja wizualna, która nadal spełnia wymagania jakościowe aplikacji. To właśnie jest prawdziwe podejście inżynierii przetwarzania: dostosowywanie całego obciążenia, a nie tylko samego algorytmu.

Modele Omni-modal nie zawsze są rozwiązaniem

Przemysł zmierza w kierunku modeli, które mogą jednocześnie przyjmować i generować różne rodzaje danych:

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

To brzmi idealnie, ale ogólność ma swoją cenę. Specjalistyczny model OCR może przewyższyć możliwości OCR zawarte w dużym VLM, a model mowy stworzony specjalnie do tego celu może działać efektywniej niż ogólny model multimodalny. Dlatego systemy produkcyjne zazwyczaj przekształcają się w łańcuchy specjalistów:

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

Zasada inżynieryjna, która obowiązuje, polega na tym, aby każdy komponent był niezależnie optymalizowalny i skalowalny.

Modele embedding chcą wysokiej wydajności

Modele embedding różnią się zasadniczo od generatywnych LLM. Przekształcają one treść w wektor o stałej wielkości:

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

Ty wektory napędzają RAG, wyszukiwanie semantyczne, rekomendacje, pamięć agenta oraz odzyskiwanie dokumentów. Najważniejszy jest kształt obciążenia, a dwa takie kształty wyglądają zupełnie inaczej.

Jednym z przykładów jest embedding masowy, np. wprowadzanie dziesięciu milionów dokumentów do bazy danych wektorowej:

10 million documents
       ↓
Embedding pipeline
       ↓
Vector database

Tam przepustowość i koszt są decydujące. Inna opcja to wyszukiwanie online, w którym zapytanie użytkownika jest natychmiast włączane i wyszukiwane:

User query
    ↓
Embedding
    ↓
Vector search

W takich przypadkach decydują milisekundy. Gdy obie wartości są wystarczająco duże, oddzielne implementacje często okazują się korzystniejsze, ponieważ każdą z nich można dostosować do własnego celu.

Rozmiarowość i kompatybilność

Embeddingi dodają kolejny parametr balansujący jakość i szybkość: rozmiar wektora. Wektory mogą zawierać setki lub tysiące wartości. Większe wektory przechowują więcej informacji, ale zwiększają koszty przechowywania, wyszukiwania oraz obliczania podobieństwa. Niektóre nowoczesne metody embeddingów umożliwiają zmienną efektywną rozmiarowość, zaprojektowaną właśnie z myślą o tym kompromisie.

Istnieje również powszechny błąd zrozumienia. Dwa wektory o tej samej długości nie są automatycznie porównywalne, ponieważ każdy model embeddingu tworzy swój własny przestrzeń semantyczną. Zmiana modelu nie jest równoznaczna z zastąpieniem jednej API drugą. Zazwyczaj trzeba przemyśleć od nowa system wyszukiwania w oparciu o ten model.

Pracowanie w partiach to główne narzędzie w przypadku embeddingów

W odróżnieniu od dekodowania autoregresywnego, modele embeddingowe przetwarzają tokeny głównie równolegle, co zmienia strategię. Cacheowanie prefiksów oraz rozdzielenie procesów prefill i dekodowania nie odgrywają tu kluczowej roli. Należy skupić się na dużych partiach danych, szybkiej tokenizacji, kolejkowaniu, skalowaniu poziomym, optymalnych jądrach oraz kwantyzacji. Modele embeddingowe mogą obsługiwać znacznie większe partie danych niż modele generatywne – czasami dziesiątki lub setki wejść jednocześnie.

Rozsądna architektura produkcyjna umieszcza kolejkę i menedżera partii przed kilkoma replikami:

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

Dla zastosowań wymagających dużej ilości obliczeń, jeden GPU na każdą replikę skalowaną poziomo często jest lepszy niż skomplikowana konfiguracja modelu równoległego z wieloma GPU.

Rozpoznawanie mowy: dominuje dekoder

ASR przekształca dźwięk w tekst. Typowy proces obejmuje przetwarzanie wstępne, kodowanie, a następnie dekodowanie:

Audio
  ↓
Audio preprocessing
  ↓
Encoder
  ↓
Autoregressive Decoder
  ↓
Transcript

ASR nie jest modeliem językowym typu LLM, ale jego dekoder funkcjonuje jak taki i pochłania większość czasu potrzebnego na przetwarzanie. Dlatego optymalizacje w stylu LLM są szczególnie skuteczne. W przypadku transkrypcji na żywo kluczowym nie jest surowa szybkość przetwarzania – system musi sprawiać wrażenie natychmiastowej reakcji, a rozsądnym celem jest około 200 ms na cały proces przetwarzania fragmentu audio w czasie rzeczywistym.

Strumieniowanie zmienia doświadczenie

Jedna z największych korzyści wynikających z zastosowania ASR nie wymaga żadnych zmian w modelu, tylko innego podejścia do jego dostarczania. Zamiast schematu pobierania, czekania i odbierania danych:

Upload audio
      ↓
Wait
      ↓
Receive transcript

przejdź na przepływ ciągły:

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

WebSocket utrzymuje strumień otwarty, podczas gdy model wykrywania aktywności głosowej identyfikuje fragmenty zawierające znaczący dźwięk. Wniosek jest taki, że wydajność inferencji nie zawsze stanowi problem w czasie działania. Czasami kluczowym rozwiązaniem jest zorganizowanie procesu w sposób równoległy.

Długie nagrania wymagają paralelizmu

Długie pliki to zupełnie inna sprawa niż interaktywne dyktando. Zamiast przetwarzać je po kolei:

Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4

Możesz stworzyć równoległą ścieżkę przetwarzania:

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

Tracisz nieco możliwości ponownego wykorzystania sekwencyjnego kontekstu, ale zyskujesz znacznie większą wydajność. Czynnik czasu rzeczywistego jest przydatną miarą dla transkrypcji długich tekstów, a równoległa obróbka fragmentów nadaje się do zadań o wysokiej wydajności. Aby chronić jakość, dodaj obróbkę pośrednią, która wykrywa podejrzane powtórzenia i ponownie przetwarza tylko te problematyczne fragmenty.

TTS: celem nie jest większa liczba tokenów na sekundę

Technologia tekst do mowy działa w przeciwnym kierunku niż ASR:

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

Współczesne modele TTS często wykorzystują architektury podobne do LLM, dlatego optymalizowane jądra, przetwarzanie partiami oraz inferencja o niskiej precyzji pochodzą z obsługi LLM. Miara efektywności różni się jednak w subtelny sposób – generowanie 500 tokenów audio na sekundę nie jest lepsze od 100, jeśli dekoder audio wymaga wyłącznie wyniku w czasie rzeczywistym. Gdy szybkość generowania dorówna czasowi rzeczywistemu, kluczowym pytaniem staje się to, ilu użytkowników jednocześnie może obsłużyć jeden GPU. Chodzi tu o optymalizację pod kątem wymagań produktu, a nie wartości z testów.

Generowanie obrazów: porzuć instynkty związane z LLM

Generatorzy obrazów to przede wszystkim narzędzia do iteracyjnego usuwania szumów, a nie programy tworzące obrazy token po tokenie:

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

W odróżnieniu od dekodowania LLM, ten rodzaj obciążenia jest zazwyczaj ograniczony mocą obliczeniową, więc przepustowość pamięci przestaje być głównym problemem. Narzędzia skupiają się wtedy na wyborze jąder, fuzji jąder, efektywnym mechanizmie uwagi, optymalizacji operacji GEMM, kompilacji w Torch, pracy przy niższej precyzji oraz ograniczeniu ilości operacji usuwania szumów.

Jądra odgrywają kluczową rolę

Jądra mechanizmu uwagi są szczególnie ważne przy generowaniu obrazów. W zależności od architektury i implementacji GPU można wybrać zoptymalizowane opcje takie jak FlashAttention, DeepGEMM, CuTe i CUTLASS. Operacje normalizacji, takie jak RMSNorm, również stanowią dobre kandydaty do fuzji.

Główną lekcją jest to, że najlepszy silnik inferencji zależy zarówno od obciążenia pracy, jak i sprzętu. PyTorch oferuje elastyczność, specjalistyczne implementacje dostarczają optymalizowane jądra, a kompilacja może łączyć operacje w ścieżkę specyficzną dla GPU. Prawidłowa odpowiedź pochodzi z przeprowadzenia testów na rzeczywistym modelu i rzeczywistym sprzęcie.

Efektywny trik w procesie dyfuzji

Modele dyfuzyjne wykonywają wiele kroków – te wstępne ustalają ogólną strukturę, a późniejsze dopracowują szczegóły. To stwarza możliwość: można ograniczyć kosztowne operacje kierujące w późniejszych etapach. Jednym z rozwiązań jest pominięcie kierowania bez klasyfikatora na końcu procesu, przy jednoczesnym zachowaniu tej samej liczby kroków. W przykładzie z 50 krokami liczba nieudanych prób spada z 100 do 80, a jakość generalnie pozostaje bez zmian.

Konkretny trik ma mniejsze znaczenie niż zasada. Nie każda iteracja w równym stopniu przyczynia się do ostatecznego rezultatu, a optymalizacja wnioskowania może wykorzystać tę nierównowagę.

Generowanie wideo to inna skala

Generowanie wideo to generowanie obrazów z dodaną wymiarem czasu. Gdzie latent obrazu jest:

Height × Width

wideo latentne staje się:

Height × Width × Time

To sprawia, że problem obliczeniowy staje się znacznie większy. Wideo jest uzależnione od mocy obliczeniowej, a systemy często zajmują całe węzły z wieloma GPU przy małych rozmiarach partii, nawet jednej partii, ponieważ wszystkie GPU współpracują przy obróbce pojedynczego klipu.

To wyznacza wyraźną granicę w porównaniu z generowaniem tekstu. W przypadku tekstu większa partia może zwiększyć przerob, natomiast w przypadku wideo takie podejście może niewiele pomóc, ponieważ już jedna generacja może zużyć większość zasobów obliczeniowych. Dlatego najszybszą drogą do tańszego wideo jest często szybszy model.

Uwaga dominuje w przypadku wideo

Podczas generowania wideo mechanizm uwagi może pochłonąć ogromną część zasobów obliczeniowych – w niektórych zadaniach szacuje się to na 70 do 80 procent. To zmienia priorytety. Zamiast głównie kwantyzować wagi, inżynierowie skupiają się na jądrach uwagi, kwantyzacji mechanizmu uwagi, buforowaniu, paralelizmie kontekstowym oraz równoległej eksploatacji na poziomie GPU.

Buferowanie w przypadku wideo działa inaczej

Generowanie wideo nie wykorzystuje podejścia autoregresywnego z buforem KV. Zamiast tego systemy ponawiają użycie części wcześniejszych obliczeń na dwa główne sposoby. Buforowanie kroków czasowych polega na ponownym wykorzystaniu wyników z określonych kroków oczyszczania sygnału. Buforowanie w transformatorach polega na ponownym wykorzystaniu stanów ukrytych oraz pomijaniu niektórych operacji wewnątrz struktury transformatora. Obie metody mogą znacznie przyspieszyć proces, ale także poważnie obniżyć jakość w zależności od algorytmu. Dlatego traktuj każdą optymalizację jak pętlę:

Optimization
     ↓
Speed ↑
     ↓
Quality ?
     ↓
Evaluate
     ↓
Production

Nigdy nie zakładaj, że optymalizacja cache jest bezpieczna tylko dlatego, że wideo nadal wygląda prawdopodobnie.

Kwantyzacja odpowiada wąskiemu gardłu

Dla modeli LLM kwantyzacja zazwyczaj dotyczy dużych warstw liniowych i wag, ponieważ wykonywanie zadań przez te modele jest często ograniczane przepustowością pamięci. Generowanie wideo jest natomiast ograniczane mocą obliczeniową, szczególnie mechanizmem uwagi, więc sam mechanizm uwagi staje się atrakcyjnym celem kwantyzacji. Jednak mechanizm uwagi jest również bardzo wrażliwy na błędy numeryczne.

Istnieją dwie opcje. Możesz kwantyzować w blokach, używając formatów mikroskalowania takich jak MXFP8, albo możesz kwantyzować selektywnie, zmieniając precyzję krok po kroku:

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

lub warstwami:

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

Zachowaj precyzję tam, gdzie model jest wrażliwy, a optymalizuj intensywnie tam, gdzie nie jest.

Nie istnieje uniwersalna optymalizacja

W tych różnych modalnościach skuteczne strategie w ogóle nie przypominają się nawzajem:

| 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 |

Dlatego inżynieria inferencji jest bliższa pracy z systemami niż po prostu przyspieszaniu modeli LLM.

Główne wnioski

1. Inferencja multimodalna zależy od obciążenia pracy. Najlepsza architektura odpowiada wzorcowi wykonywania zadań oraz wymaganiom produktu.
2. Modele autoregresywne i modely dyfuzyjne mają zasadniczo różne wąskie gardła.
3. VLM-y przekształcają dane wizualne w dodatkowy kontekst, dlatego kluczowe stają się cache KV oraz optymalizacja długiego kontekstu.
4. Systemy embeddingów to głównie problemy z grupowaniem zadań i przepustowością, a nie opóźnieniami przy dekodowaniu.
5. Zyski w ASR pochodzą przede wszystkim z orkiestracji i transmisji strumieniowej, a nie tylko od szybszych jąder.
6. W przypadku TTS, gdy szybkość generowania przewyższa tempo rzeczywistego czasu, optymalizacja staje się kwestią liczby jednoczesnych użytkowników.
7. Generowanie obrazów jest ograniczone zasobami obliczeniowymi, co sprawia, że kluczowe są jądra, fuzja danych, kompilacja oraz redukcja kroków usuwania szumów.

Generowanie wideo posuwa to jeszcze dalej, wymagając ogromnych obciążeń związanych z mechanizmem uwagi oraz wykonywania operacji na kilku kartach GPU.

Kasowanie danych jest specyficzne dla poszczególnych modalności. Kasowanie typu KV napędza generację autoregresywną, natomiast systemy dyfuzyjne wykorzystują obliczenia w inny sposób.

Kwantyzuj tam, gdzie znajduje się wąskie gardło. Wagi są przydatne dla modeli LLM ograniczonych zasobami pamięci, natomiast mechanizm uwagi może odgrywać ważniejszą rolę w przypadku obliczeń związanych z wideo.

Dokąd to prowadzi

Produkty AI stają się domyślnie multimodalne. Tekst, obrazy, dźwięk, wideo oraz wektory embedding są coraz częściej integrowane w tych samych aplikacjach, dzięki czemu zadanie zmienia się z dostrojenia jednego modelu na dostrojenie całego procesu. Pytanie, które należy postawić, to już nie to, jaką technikę optymalizacji zastosować, lecz gdzie znajduje się wąskie gardło w danym obciążeniu oraz jakie kompromisy można bezpiecznie pójść, aby je usunąć.

Taka mentalność obowiązuje zarówno w przypadku jednej karty graficznej służącej do obsługi modelu embeddingowego, jak i klastra z wieloma kartami graficznymi generującego wideo w czasie rzeczywistym. Należy znać obciążenie systemu, zlokalizować wąskie gardło, przetestować kompromisy, które jesteśmy gotowi przyjąć, oraz dostosować cały system, a nie tylko model.