Wie OCRia einen 10-fachen Inference-Speedup auf B200-GPUs erreichte

Das Engineering-Team hinter OCRia-1 hat detailliert beschrieben, wie sie eine nahezu zehnfache Steigerung der Token-Generierungsgeschwindigkeit erzielten, indem sie von etwa 285 Tokens pro Sekunde auf 2800 Tokens pro Sekunde auf einer einzelnen NVIDIA B200 GPU steigerten. Die am 3. November 2026 veröffentlichte technische Analyse zeigt, dass dieser Leistungssprung nicht das Ergebnis eines einzelnen Durchbruchs war, sondern vielmehr einer systematischen Reduzierung von Speicherengpässen und Rechenoverhead über den gesamten Inference-Stack hinweg.

Was geschah

Latenz war lange Zeit eine primäre Einschränkung für Dokumentenanalyse-Workflows, bei denen dichte Seiten umfangreiche strukturierte Ausgaben erfordern. Das OCRia-Team identifizierte, dass ihre Inference-Pipeline eher durch die Speicherbandbreite als durch die Rechenleistung begrenzt war (memory-bandwidth-bound statt compute-bound). Das bedeutet, dass die GPU mehr Zeit damit verbrachte, Modellgewichte und Zustandsdaten zu bewegen, als mathematische Operationen auszuführen. Um dies anzugehen, konzentrierten sie sich auf drei Kernbereiche: die Reduzierung des Datenvolumens, das während jedes Decode-Schritts bewegt wird, die Generierung mehrerer Tokens pro Forward-Pass und die Minimierung des CPU- und GPU-Overheads im Zusammenhang mit jedem Schritt.

Die daraus resultierende Optimierungsstrategie kombinierte etablierte Techniken wie Quantisierung mit neuartigen Implementierungen von spekulativem Decoding und maßgeschneiderter Kernel-Entwicklung. Durch rigoroses Profiling jeder Stufe des Inference-Prozesses eliminierte das Team redundante Speicherkopien und optimierte die Vorbereitung von Metadaten. Diese Änderungen ermöglichen es dem System, gleichzeitige Anfragen effizienter zu bearbeiten, was schnellere Iterationen bei Benchmarks und schnellere Ergebnisse für Endbenutzer ermöglicht, ohne die Genauigkeit zu beeinträchtigen.

Wie es funktioniert

Die Grundlage des Speedups liegt in der arbeitslastbewussten Quantisierung (workload-aware quantization). Anstatt eine einheitliche Präzisionsreduzierung anzuwenden, nutzte das Team Mixed Precision, wobei empfindliche Schichten in höherer Präzision belassen wurden, während andere auf FP8 oder NVFP4 komprimiert wurden. Sie setzten aktivitätsbewusste Quantisierung ein, die Skalierungsfaktoren unter Verwendung von In-Distribution-Daten kalibriert, um sicherzustellen, dass die Kompression für die Zielaufgaben effektiv verlustfrei bleibt. Bemerkenswert ist, dass der Vision Encoder unquantisiert gelassen wurde, um die visuelle Genauigkeit zu erhalten, was einen gezielten Ansatz zur Balance zwischen Größe und Treue demonstriert.

Um die autoregressive Einschränkung zu überwinden, nur ein Token pro Schritt zu generieren, implementierte das Team spekulatives Decoding unter Verwendung eines Drafter-Modells namens DFlash2. Dieses kleinere Modell sagt mehrere zukünftige Tokens parallel voraus, die dann vom größeren Zielmodell in einem einzigen Forward-Pass überprüft werden. DFlash2 nutzt lokale Faltungen und einen Kandidatenselektor, um Akzeptanzraten von über 12 Tokens zu erreichen, was den Durchsatz erheblich steigert. Der Prozess ist mathematisch garantiert verlustfrei, da falsche Spekulationen verworfen werden, ohne die finale Ausgabeverteilung zu beeinflussen.

Weitere Gewinne ergaben sich aus tiefgreifenden Engine-Optimierungen. Das Team passte ReplaySSM an, um das State-Management in Gated Delta Networks zu optimieren, wodurch die Kosten für das Zurückweisen abgelehnter spekulativer Tokens gesenkt wurden. Sie fusionierten auch aufeinanderfolgende Operationen, wie SiLU-Aktivierung und Quantisierung, um Zwischenergebnisse in schnellen GPU-Registern zu halten, anstatt sie in den High-Bandwidth-Speicher zu schreiben. Auf der CPU-Seite refaktorierten sie die Konstruktion von Metadaten, um redundante Berechnungen über verschiedene Cache-Gruppen hinweg zu vermeiden, wodurch die Anzahl der erforderlichen GPU-Launches pro Decode-Schritt von mehreren Hundert auf nur noch eins reduziert wurde.

Wichtige Details

• Leistungssteigerung: Die Token-Generierungsgeschwindigkeit stieg von ~285 Tokens/Sek. auf ~2800 Tokens/Sek. auf einer einzelnen B200 GPU.
• Quantisierungsstrategie: Mixed Precision unter Verwendung von BF16, FP8 und NVFP4, mit aktivitätsbewusster Kalibrierung zur Erhaltung der Genauigkeit.
• Spekulares Decoding: Nutzt DFlash2, ein Block-Diffusion-Drafter-Modell, das Akzeptanzraten von über 12 Tokens pro Pass erreicht.
• Kernel-Optimierung: Maßgeschneiderte CUDA-Kernel reduzierten die ReplaySSM-Verifikationszeit von 72–80 µs auf 23–24 µs pro Layer.
• CPU-Effizienz: Die Erstellung von Metadaten wurde so optimiert, dass nur ein GPU-Launch pro Schritt erforderlich ist, gegenüber zuvor etwa 290.
• Verfügbarkeit: OCRia-1 ist derzeit auf LlamaParse verfügbar, und generalisierbare Optimierungen werden an vLLM zurückgegeben.

Warum es wichtig ist

Für Ingenieure, die Document-AI-Produkte entwickeln, verdeutlicht diese Fallstudie, dass reine Hardware-Leistung ohne sorgfältige Software-Optimierung oft nicht ausreicht. Der Wandel von Compute-bound zu Memory-bound Operationen in großen Modellen bedeutet, dass die Reduzierung von Datenbewegungen häufig wirkungsvoller ist als das Hinzufügen weiterer Recheneinheiten. Das Verständnis des Roofline-Modells und die Identifikation, ob ein Workload durch Bandbreite oder Rechenleistung begrenzt ist, ermöglicht es Teams, die richtigen Optimierungen wie Quantisierung oder Kernel-Fusion zu priorisieren, anstatt Ressourcen blind zu skalieren.

Der Einsatz von spekulativem Decoding zeigt einen praktischen Weg auf, den sequentiellen Engpass der autoregressiven Generierung zu brechen. Durch die parallele Überprüfung mehrerer Tokens können Entwickler die Interaktivität und den Durchsatz für Benutzer, die mit langen Dokumenten arbeiten, erheblich verbessern. Dies erfordert jedoch eine sorgfältige Implementierung, um sicherzustellen, dass das Drafter-Modell gut zum Zielmodell passt, da schlechte Akzeptanzraten die Vorteile zunichtemachen können. Der Erfolg des OCRia-Teams mit DFlash2 zeigt, dass Investitionen in spezialisierte Drafter-Architekturen erhebliche Renditen erzielen können.

Schließlich unterstreicht die Betonung von Profiling und inkrementeller Verbesserung die Bedeutung der Messung im Systems Engineering. Viele der Gewinne stammten aus kleinen, kumulativen Optimierungen wie der Fusion von Operationen oder der Verfeinerung der Metadatenbehandlung. Diese Änderungen trugen zwar einzeln bescheiden bei, leisteten aber kollektiv über 60 % des zusätzlichen Durchsatzes. Dieser Ansatz ermutigt Entwickler, über High-Level-Framework-Einstellungen hinauszuschauen und in die Implementierungsdetails ihrer Inference-Engines einzutauchen, um versteckte Leistungsreserven freizusetzen.

Was Sie tun können

• Profilieren Sie Ihre Inference-Pipeline, um festzustellen, ob sie durch Speicherbandbreite oder Rechenleistung begrenzt ist, bevor Sie Optimierungsstrategien wählen.
• Implementieren Sie Mixed-Precision-Quantisierung mit aktivitätsbewusster Kalibrierung, um den Speicherverbrauch ohne signifikanten Genauigkeitsverlust zu reduzieren.
• Erkunden Sie spekulatives Decoding mit einem leichten Drafter-Modell, um mehrere Tokens pro Forward-Pass zu generieren.
• Fusionieren Sie aufeinanderfolgende Kernel-Operationen, um Schreibzugriffe auf den High-Bandwidth-Speicher zu minimieren und Daten in Registern zu halten.
• Optimieren Sie die CPU-seitige Metadaten-Vorbereitung durch Caching gemeinsamer Strukturen und Reduzierung redundanter GPU-Launches.
• Geben Sie generalisierbare Optimierungen an Open-Source-Inference-Engines wie vLLM zurück, um der breiteren Community zugutezukommen.