Schlussfolgerungen jenseits des Textes: Anpassung von VLMs, Embeddings, Sprache, Bildern und Videos
Jede Modalität weist ihre eigenen Engpässe auf. Erfahren Sie, wie man VLMs, Embedder, ASR-, TTS-Systeme sowie Bild- und Videogeneratoren durch geeignete Batching-Strategien, Kernel, Caching-Verfahren und Quantisierung optimiert.
Die Beschleunigung eines rein textbasierten Sprachmodells ist ein bereits weitgehend gelöstes Problem, weshalb manche dessen Tricks als universell ansehen. Das ist jedoch nicht der Fall. Sobald ein echtes Produkt verfügbar ist, wird die Textgenerierung zu nur einer von mehreren Schritten, und jeder Schritt weist eigene Engpässe auf. Eine Optimierungsmethode, die die Verarbeitungsgeschwindigkeit von LLMs verdoppelt, kann für Embedding-Modelle nutzlos sein, und die Erstellung von Bildern oder Videos bringt wiederum eigene Rechen- sowie Aufmerksamkeitsprobleme mit sich. Hier lernen Sie Vision-Language-Modelle, Embedder, ASR-, TTS-, Sprach-zu-Sprache-Systeme sowie Bild- und Videogeneratoren kennen, wobei zunächst zwei grundlegende Ausführungsmuster erläutert werden und anschließend für jedes Modell Metriken, Hardwareauswahl, Caching, Quantisierung, Batching sowie Qualitätsabwägungen betrachtet werden. Der rote Faden dabei ist: Die Inferenzengineering-Strategien hängen von der jeweiligen Arbeitslast ab.
Warum ein einziges Vorgehen nicht funktioniert
Reale Anwendungen verknüpfen Modelle miteinander. Ein Sprachassistent kann Audio aufnehmen, Spracherkennung durchführen, über den Text nachdenken und anschließend Sprache synthetisieren. Ein Dokumentensystem kann ein PDF durch OCR, ein Vision-Modell sowie Embeddings vor der Suche und schließlich durch ein LLM verarbeiten. Ein Videoutil kann von Text zu einem generierten Clip über iterative Rauschentfernung gelangen und schließlich die Medien decodieren.
Jeder Schritt hat sein eigenes Kostenprofil, weshalb sich das zu Optimierende mit ihm ändert. Was ein autoregressives Sprachmodell schnell macht, kann nicht einfach auf einen Bild- oder Videoprozess übertragen werden.
Zwei Muster decken den Großteil ab
Fast jedes generative System folgt einem von zwei Mustern.
Das erste ist die autoregressive Generierung. Das Modell erzeugt den Ausgang Schritt für Schritt, wobei jeder Token von dem vorherigen abhängt:
Input
↓
Token 1
↓
Token 2
↓
Token 3
↓
...
Das ist der bekannte LLM-Zyklus. Vision-Language-Modelle, in Sprachmodell-Strukturen basierende Embedding-Systeme, ASR-Decoder sowie viele TTS-Modelle können zahlreiche Ideen zur Bereitstellung von Transformern daraus übernehmen.
Die zweite Methode ist das iterative Entstörungsvorgehen, der Diffusionsansatz, bei dem ein störanfälliger Ausgangspunkt Schritt für Schritt verfeinert wird:
Random / noisy latent
↓
Step 1
↓
Step 2
↓
Step 3
↓
...
↓
Final image/video
Die Erstellung von Bildern und Videos findet hauptsächlich hier statt.
Das ist wichtig, weil man keine einzige Definition für Latenz, Durchsatz oder Effizienz für alle Anwendungen verwenden kann. Bei Chatbots ist oft die Zeit bis zum ersten Token der entscheidende Wert. Bei Sprachsynthese zählt die Zeit bis zum ersten sinnvollen Audio-Ausschnitt. Bei langen Transkriptionsaufgaben spielt der Echtzeitfaktor meist die größte Rolle. Bei Bildgenerierung kann das Weglassen von Rauschreduzierungs-Schritten vorteilhafter sein als die Verringerung der Kernel-Latenz. Bei Videos können Aufmerksamkeitsmechanismen sowie riesige Tensor-Strukturen die gesamte Arbeitslast überwältigen.
Vision-Language-Modelle wandeln Bilder in Tokens um
Ein VLM verbindet einen Vision-Encoder mit einem Sprachmodell. Der Encoder wandelt Pixel in Darstellungen um, die das Sprachmodell zusammen mit Text verarbeiten kann:
Image / Video
│
▼
Vision Encoder
│
▼
Visual Tokens
│
▼
Language Model
│
▼
Text Response
Die interessante Folge ist, dass ein Bild die Eingabesequenz verlängert. Ein einzelnes Hochauflösungsbild kann etwa tausend visuelle Token beitragen. Mehr visuelle Details bedeuten mehr Tokens, was wiederum mehr Kontext und einen größeren KV-Cache bedeutet.
Daher sieht die Abstimmung eines VLM sehr ähnlich aus wie die Abstimmung eines LLM mit langem Kontext. Nutzen Sie quantisierte KV-Caches, spekulative Dekodierung, Präfixcaching, Tensorparallelismus, die Auslagerung des Caches oder die Trennung von Vorausfüllung und Dekodierung. Die Wiederverwendung von Präfixen lohnt sich besonders bei wiederholten Bildern und mehrteiligen Chats, und je länger die Eingaben werden, desto wichtiger wird das Speichermanagement.
Das Verstehen von Videos wird schnell teuer
Bilder kosten etwas. Video vervielfacht diesen Betrag. Bei 24 Bildern pro Sekunde erzeugt selbst ein kurzer Clip eine enorme Menge an visuellen Tokenen. Ein vier Sekunden langer Hochauflösungs-Clip könnte grundsätzlich auf bis zu 100.000 Eingabetoken kommen, bevor eine praktische Downsampling-Verarbeitung stattfindet.
Dadurch muss man zwischen Qualität und Geschwindigkeit abwägen. Man kann die Auflösung, die Bildrate, die Anzahl der Bilder oder die Anzahl der visuellen Tokenen verringern – doch jede Kürzung führt zum Verlust von Informationen. Überlegen Sie daher nicht, wie man die Video-Inferenz beschleunigen kann. Fragen Sie stattdessen, welche kleinste visuelle Darstellung dennoch die Qualitätsanforderungen der Anwendung erfüllt. Das ist der eigentliche Ansatz in der Inferenz-Engineerung: Die Arbeitslast anpassen, nicht nur den Kernel.
Omnimodale Modelle sind nicht immer die Lösung
Die Branche bewegt sich in Richtung Modelle, die gleichzeitig mehrere Modalitäten verarbeiten und ausgeben können:
Text ─────┐
Image ────┤
Audio ────┼──► Omni Model ──► Text / Audio / Image
Video ────┘
Das klingt ideal, aber Allgemeingültigkeit hat ihren Preis. Ein speziell entwickeltes OCR-Modell kann die OCR-Fähigkeiten übertrumpfen, die in einem großen VLM verbaut sind, und ein auf bestimmte Aufgaben zugeschnittenes Sprachmodell kann effizienter arbeiten als ein allgemeines multimodales Modell. Produktionsysteme neigen daher dazu, in Pipelines von Spezialisten umzuwandeln:
┌──► OCR
PDF/Image ───┤
├──► Vision Model
└──► Embedding Model
│
▼
LLM
Die folgende ingenieurtechnische Regel besagt, dass jedes Komponente unabhängig optimierbar und skalierbar sein muss.
Eingebettete Modelle benötigen Durchsatz
Eingebettete Modelle unterscheiden sich grundlegend von generativen LLMs. Sie wandeln Inhalte in Vektoren fester Größe um:
Document / Image
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Diese Vektoren treiben RAG, semantische Suche, Empfehlungen, Agentenmemorien sowie die Dokumentabrufung an. Am wichtigsten ist die Struktur der Arbeitslast, und zwei verschiedene Strukturen unterscheiden sich stark voneinander.
Eine solche Struktur ist das Masseneinbetten, beispielsweise wenn zehn Millionen Dokumente in eine Vektordatenbank eingefügt werden:
10 million documents
↓
Embedding pipeline
↓
Vector database
Dort gewinnen Durchsatz und Kosten. Die andere Variante ist die Online-Auswertung, bei der eine Benutzeranfrage direkt eingebettet und durchsucht wird:
User query
↓
Embedding
↓
Vector search
Dort entscheiden Millisekunden über den Erfolg. Wenn beide Faktoren groß genug sind, haben getrennte Implementierungen oft Vorteile, da jede für ihr eigenes Ziel optimiert werden kann.
Dimensionalität und Kompatibilität
Embeddings fügen eine weitere Abwägung zwischen Qualität und Geschwindigkeit hinzu: die Größe der Vektoren. Vektoren können Hunderte oder Tausende von Werten enthalten. Größere Vektoren speichern mehr Informationen, erhöhen aber die Kosten für Speicherung, Abruf und Berechnung der Ähnlichkeit. Einige moderne Embedding-Methoden unterstützen eine variable effektive Dimensionalität, die genau mit diesem Kompromiss berücksichtigt wird.
Es gibt außerdem ein häufiges Missverständnis: Zwei Vektoren mit derselben Länge sind nicht automatisch vergleichbar, denn jedes Embedding-Modell erstellt seinen eigenen semantischen Raum. Das Wechseln des Modells ist nicht dasselbe wie das Austauschen einer API gegen eine andere. In der Regel muss man das darum herum konzipierte Abrufsystem neu überdenken.
Batching ist der wichtigste Hebel für Embeddings
Im Gegensatz zur autoregressiven Dekodierung verarbeiten Embedding-Modelle Tokens größtenteils parallel, was die Strategie verändert. Präfix-Caching sowie die Trennung von Vorausfüllen und Dekodieren spielen hier keine zentrale Rolle. Der Fokus liegt auf großen Datensätzen, schneller Tokenisierung, Queuing, horizontaler Skalierbarkeit, optimierten Kernen und Quantisierung. Embedding-Modelle können viel größere Datensätze verarbeiten als generative Modelle – manchmal Dutzende oder Hunderte von Eingaben gleichzeitig.
Eine sinnvolle Produktionsarchitektur stellt ein Queuing-System sowie einen Datensatzmanager vor mehrere Replikate:
Requests
↓
Queue
↓
Batch Manager
↓
GPU Replica 1
GPU Replica 2
GPU Replica 3
GPU Replica 4
Für die Verarbeitung großer Datenmengen ist in der Regel eine GPU pro horizontal skalierter Replikation vorteilhafter als ein komplexes, modellparalleles Setup mit mehreren GPUs.
Spracherkennung: Der Dekoder spielt die Hauptrolle
ASR wandelt Audio in Text um. Ein typischer Ablauf umfasst die Vorausverarbeitung, einen Encoder sowie anschließend einen Dekoder:
Audio
↓
Audio preprocessing
↓
Encoder
↓
Autoregressive Decoder
↓
Transcript
ASR ist kein LLM, doch sein Dekoder verhält sich wie eines und verbraucht den größten Teil der Berechnungszeit. Deshalb sind Optimierungen im Stil von LLMs besonders wirksam. Bei der Echtzeit-Transkription ist die reine Durchsatzrate nicht das Ziel. Das System muss sofortig reagieren, wobei ein angemessenes Ziel etwa 200 ms für eine Rundreisezeit pro Echtzeit-Audio-Blöck ist.
Streaming verändert das Erlebnis
Einer der größten Vorteile von ASR erfordert keinerlei Änderungen am Modell, lediglich ein anderes Bereitstellungsdesign. Anstelle des Musters „Upload, Warten und Empfangen“:
Upload audio
↓
Wait
↓
Receive transcript
Übergehen auf einen kontinuierlichen Fluss:
Continuous Audio
↓
VAD
↓
Audio Chunks
↓
ASR GPU
↓
Streaming Transcript
Ein WebSocket hält den Stream geöffnet, während ein Modell zur Erkennung von Sprachaktivitäten die Abschnitte auswählt, die bedeutungsvollen Audioinhalt enthalten. Die Botschaft ist: Die Leistung der Inferenz ist nicht immer ein Laufzeitproblem. Manchmal bringt die Orchestrierung den größten Vorteil.
Lange Aufnahmen benötigen Parallelität
Lange Dateien sind etwas anderes als interaktives Diktieren. Anstatt sie nacheinander zu verarbeiten:
Chunk 1 → Chunk 2 → Chunk 3 → Chunk 4
Man kann einen parallelen Pipeline erstellen:
┌──► GPU 1 ──► Chunk 1
Audio → VAD ─────┼──► GPU 2 ──► Chunk 2
├──► GPU 3 ──► Chunk 3
└──► GPU 4 ──► Chunk 4
↓
Stitch by time
Durch diese Vorgehensweise geht zwar etwas an der Wiederverwendung sequenzieller Kontexte verloren, doch es wird eine hohe Durchsatzrate erzielt. Der Echtzeit-Faktor ist eine nützliche Kennzahl für die Transkription langer Texte, und das parallele Verarbeiten von Teilmengen eignet sich für Aufgaben mit hohem Durchsatz. Um die Qualität zu gewährleisten, sollte ein Nachverarbeitungsschritt hinzugefügt werden, der verdächtige Wiederholungen erkennt und nur die betroffenen Teilmengen erneut verarbeitet.
TTS: Mehr Tokens pro Sekunde ist nicht das Ziel
Text-zu-Sprache-Systeme arbeiten in entgegengesetzter Richtung zu ASR:
Text
↓
TTS Model
↓
Audio Tokens
↓
Audio Decoder
↓
Waveform
Moderne TTS-Modelle verwenden oft architektonische Ansätze, die denen von LLMs ähneln, weshalb optimierte Kerne, Batching sowie Inferenz in geringer Präzision aus dem LLM-Dienst übernommen werden. Die Messgrößen unterscheiden sich jedoch auf subtile Weise: Das Erzeugen von 500 Audio-Token pro Sekunde ist nicht besser als 100, wenn der Audio-Decoder lediglich eine annähernd Echtzeit-Ausgabe benötigt. Sobald die Erzeugung mit der Echtzeit Schritt hält, stellt sich die Frage, wie viele gleichzeitige Benutzer eine GPU unterstützen kann. Dabei geht es um die Optimierung nach den Anforderungen des Produkts und nicht nach dem Benchmark-Wert.
Bildgenerierung: Die Instinkte der LLMs beiseite lassen
Bildgeneratoren sind größtenteils iterative Rauschentferner und keine Token-für-Token-Schreiber:
Noise
↓
Denoising Step 1
↓
Denoising Step 2
↓
...
↓
Image
Im Gegensatz zur Dekodierung mit großen Sprachmodellen ist diese Arbeitslast in der Regel rechenintensiv, wodurch die Speicherbreite nicht mehr das Hauptproblem darstellt. Der Fokus verschiebt sich auf die Auswahl von Kernen, die Fusion von Kernen, effizientes Attention-Verhalten, die Anpassung von GEMM-Operationen, die Kompilierung mit Torch, den Einsatz geringerer Präzision sowie weniger Rauschunterdrückung.
Kerne sind von großer Bedeutung
Attention-Kerne spielen insbesondere bei der Bildgenerierung eine entscheidende Rolle. Je nach GPU-Architektur und Implementierung können optimierte Optionen wie FlashAttention, DeepGEMM, CuTe und CUTLASS in Betracht gezogen werden. Normalisierungsoperationen wie RMSNorm eignen sich ebenfalls gut als Kandidaten für die Fusion.
Die wichtigere Lektion ist, dass sich der beste Inferenzmotor sowohl von der Arbeitslast als auch vom Hardware-Setup abhängt. PyTorch bietet Flexibilität, spezialisierte Implementierungen liefern abgestimmte Kernel, und die Kompilierung kann Operationen in einen für GPU spezifischen Ablauf zusammenfassen. Die richtige Lösung ergibt sich aus dem Benchmarken Ihres tatsächlichen Modells auf Ihrer tatsächlichen Hardware.
Ein effektiver Trick für Diffusion
Diffusionsmodelle durchlaufen viele Schritte. Die frühen Schritte legen die allgemeine Struktur fest, während die späteren Schritte Details verfeinern. Das eröffnet eine Möglichkeit: Teure Leitfunktionen in den späteren Schritten wegzulassen. Ein Ansatz umgeht die Verwendung einer klassifizierenden Leitfunktion in den späten Phasen, behält dabei aber die Anzahl der Schritte bei. In einem Beispiel mit 50 Schritten sinkt die Anzahl der fehlerhaften Modellausgaben von 100 auf 80, wobei die Qualität im Allgemeinen erhalten bleibt.
Der spezifische Trick ist weniger wichtig als das Prinzip. Nicht jede Iteration trägt gleich viel zum Endresultat bei, und die Optimierung der Schlussfolgerung kann dieses Ungleichgewicht ausnutzen.
Video-Generierung ist eine andere Ebene
Video-Generierung ist Bild-Generierung mit einer zusätzlichen Zeitdimension. Während bei einem Bild das Latent darstellt:
Height × Width
Ein Video wird latent zu:
Height × Width × Time
Das macht das Rechenaufkommen um ein Vielfaches größer. Video ist rechenintensiv, und Systeme belegen oft ganze Multi-GPU-Node mit sehr kleinen Batch-Größen – sogar einem einzigen Element –, weil alle GPUs an einem einzigen Clip zusammenarbeiten.
Das zieht eine klare Trennlinie zur Textgenerierung. Bei Text kann eine größere Batch-Größe die Durchsatzrate erhöhen. Beim Video hilft das Batching oft wenig, da bereits eine einzige Generierung den größten Teil der Rechenleistung verbrauchen kann. Daher ist der schnellste Weg zu günstigerem Video oft ein schnelleres Modell.
Attention dominiert im Video
Bei der Videogenerierung kann Attention einen großen Teil der Rechenleistung in Anspruch nehmen – schätzungsweise 70 bis 80 Prozent bei einigen Arbeitslasten. Das verschiebt die Prioritäten. Anstatt hauptsächlich Gewichte zu quantisieren, konzentrieren sich Ingenieure auf Attention-Kerne, die Quantisierung von Attention-Strukturen, Caching, Kontextparallelismus sowie parallele Ausführung auf GPU-Ebene.
Caching für Video funktioniert anders
Die Videoerstellung verwendet nicht den autoregressiven KV-Cache-Ansatz. Stattdessen wenden Systeme Teile früherer Berechnungen auf zwei Hauptweisen erneut an. Beim Zeitstempel-Caching werden Ausgaben aus ausgewählten Entstörungsschritten wiederverwendet. Beim Transformer-Caching werden versteckte Zustände genutzt und Arbeit innerhalb bestimmter Teile des Transformers übersprungen. Beide Methoden können eine erhebliche Geschwindigkeitssteigerung bewirken, können aber je nach Algorithmus auch die Qualität stark verschlechtern. Behandeln Sie daher jede Optimierung als einen Schleifenprozess:
Optimization
↓
Speed ↑
↓
Quality ?
↓
Evaluate
↓
Production
Gehen Sie niemals davon aus, dass eine Caching-Optimierung sicher ist, nur weil das Video weiterhin plausibel aussieht.
Quantisierung folgt dem Engpass
Bei LLMs zielt die Quantisierung in der Regel auf große lineare Schichten und Gewichte ab, da die Inferenz von LLMs oft durch die Speicherbreite begrenzt wird. Bei der Videoerstellung hingegen ist die Rechenleistung, insbesondere bei der Attention-Mechanismus-Verarbeitung, der Engpass; daher wird die Attention selbst zu einem verlockenden Ziel für die Quantisierung. Gleichzeitig ist die Attention jedoch auch sehr empfindlich gegenüber numerischen Fehlern.
Es gibt zwei Möglichkeiten. Entweder quantisieren Sie in Blöcken mithilfe von Microscaling-Formaten wie MXFP8 oder Sie quantisieren selektiv und variieren die Präzision Schritt für Schritt:
Early steps → FP16
Middle steps → Lower precision
Late steps → Lower precision
oder schichtweise:
Input layer → FP16
Hidden layers → Lower precision
Output layer → FP16
Bewahren Sie bei anfälligen Modellen die Präzision und optimieren Sie dort, wo dies nicht notwendig ist.
Es gibt keine universelle Optimierung
In diesen verschiedenen Modalitäten unterscheiden sich die erfolgreichen Strategien völlig voneinander:
| 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 |
Deshalb steht die Inferenz-Ingenieurwesen-Technik näher am Systemdesign als daran, einfach nur die Geschwindigkeit eines LLM zu erhöhen.
Ergebnisse
- Die multimodale Inferenz hängt von der Arbeitslast ab. Die beste Architektur orientiert sich am Ausführungsmuster sowie den Anforderungen des Produkts.
- Autoregressive und Diffusionsmodelle weisen grundlegend unterschiedliche Engpässe auf.
- VLMs wandeln visuelle Eingaben in zusätzlichen Kontext um, wodurch die Anpassung von KV-Caches und der Langkontextverarbeitung eine größere Bedeutung erhält.
- Embedding-Systeme sind hauptsächlich Probleme bezüglich der Batchverarbeitung und der Durchsatzrate, nicht Probleme der Dekodierverzögerung.
- Die Vorteile bei ASR ergeben sich größtenteils aus Orchestrierung und Streaming, nicht nur aus schnelleren Kernen.
- Bei TTS wird die Anpassung zur Frage nach gleichzeitigen Benutzern, sobald die Generierung die Echtzeit überschreitet.
- Die Bildgenerierung ist rechenintensiv, wodurch Kerner, Fusion, Kompilierung sowie die Reduzierung der Entstörungsschritte von entscheidender Bedeutung sind.
Wohin das führt
KI-Produkte werden standardmäßig multimodal. Text, Bilder, Audio, Video und Embeddings werden zunehmend in derselben Anwendung integriert, wodurch die Aufgabe von der Optimierung eines einzelnen Modells zur Anpassung ganzer Pipelines wird. Die Frage lautet nicht mehr, welche Optimierungstechnik verwendet werden soll, sondern wo sich das Engpassproblem in dieser spezifischen Aufgabe befindet und welche Kompromisse man sicher eingehen kann, um es zu beseitigen.
Diese Denkweise gilt sowohl für eine GPU, die ein Embedding-Modell betreibt, als auch für einen Multi-GPU-Cluster, der Echtzeit-Videos erzeugt. Kennen Sie die Arbeitslast, identifizieren Sie den Engpass, prüfen Sie die Kompromisse, die Sie eingehen sind bereit, und optimieren Sie das gesamte System – nicht nur das Modell.