Deepgrams Nova-3 auf AWS Trainium2 verarbeitet 11, 70 % mehr Audio pro Dollar

Warum Deepgram auf Inferenz-Effizienz setzt

Laut AWS decken die Modelle von Deepgram Speech-to-Text, Text-to-Speech und Voice Agents ab. Sie verarbeiten inzwischen jährlich Billiarden von Audio-Token für mehr als 200.000 Entwickler und 1.400 Organisationen. Kunden nutzen sie über die Deepgram-API oder betreiben sie in eigenen Umgebungen, darunter auf Amazon SageMaker AI.

Für Deepgram entscheidet die Effizienz beim Betrieb darüber, wie viel Audio das System bei einem gegebenen Infrastrukturbudget bewältigen kann. Batch-Workloads mit hohem Volumen belasten dieses Budget stark: Je effizienter jede Beschleunigerstunde genutzt wird, desto mehr Audio lässt sich auf derselben Flotte verarbeiten. Die Unternehmen konzentrierten sich auf Offline-Batch-Anwendungen wie Contact-Center-Analysen und medizinische Transkription.

Die finale Konfiguration betreibt acht Modell-Replikate auf einer einzelnen Amazon-EC2-Instanz vom Typ trn2.3xlarge. AWS gibt an, das Preis-Leistungs-Verhältnis sei anhand der Instanzpreise zum Zeitpunkt der Evaluierung gemessen worden.

Von PyTorch zu optimierten Kernels

Ausgangspunkt des Projekts war Nova-3 als Standard-PyTorch-Code. Über mehrere Monate portierten die Teams das Modell mit TorchNeuron, der nativen PyTorch-Integration des Neuron Compilers, auf Trainium2. Zunächst lief das Modell im Eager-Modus, um Operationen zu finden, die auf die CPU ausweichen. Nach der Kompilierung mit torch.compile lief jede Modelloperation auf Trainium2, ohne dass CPU-Fallbacks festgestellt wurden. Encoder und Decoder wurden als getrennte Graphen mit statischen Shapes kompiliert. Die Genauigkeit wurde auf Layer-Ebene gegen die CPU sowie über die Wortfehlerrate (Word Error Rate) von Ende zu Ende geprüft, die mit den Referenzwerten von Deepgram übereinstimmen musste.

Anschließend tauschte das Team Fused Kernels aus der öffentlichen NKI Library ein, unter anderem für fusionierte QKV-Projektionen, fusionierte Feed-forward-Layer und Depthwise-1D-Faltung. Profiling mit Neuron Explorer und dem Neuron Agentic Development Toolkit zeigte, wo handgeschriebene Kernels besser abschneiden:

• FFN: Ein handoptimierter Kernel lädt jede Gewichtskachel nur einmal und verwendet sie wieder. Bei Batchgröße 96 ergibt das eine 2,0-fach geringere Latenz als beim Referenz-Kernel.
• Depthwise conv1d: Auf der Vector Engine als Multiply-Accumulate-Schleife neu geschrieben, mit 1,5-facher Beschleunigung gegenüber dem Referenz-Kernel bei Batchgröße 96.
• Conv2d: Ein von Grund auf neu geschriebener Kernel beseitigte einen Kompilierungsengpass jenseits von Batchgröße 32, mit bis zu 50-facher Beschleunigung des Faltungsmoduls bei Batchgrößen von 32 oder weniger.

Eine Rust-Laufzeit für den Produktivbetrieb

Der Produktiv-Serving-Stack von Deepgram ist in Rust geschrieben, deshalb musste das Modell ohne Python oder PyTorch im Serving-Pfad laufen. Die Teams bauten eine schlanke Laufzeitumgebung, in der Rust die Modell-Replikate über eine gemeinsame Work-Stealing-Queue koordiniert, mit einem Thread pro Replikat. Eine C-Schicht lädt vorab kompilierte NEFF-Dateien und führt sie über die Neuron-Runtime-API aus.

Jedes Trainium2-Gerät verfügt über acht physische NeuronCores, die standardmäßig als vier logische Kerne bereitgestellt werden. Da eine Nova-3-Instanz auf einen einzelnen physischen Kern passt, legte das Team einen physischen Kern pro logischem Kern fest, was acht Replikate pro Gerät ermöglicht. Laut AWS reproduzierte die Laufzeit bei jeder getesteten Batchgröße exakt die Referenz-Token-Sequenzen.

Gegenüber Python-Baselines mit Multiprocessing und Multithreading vermeidet die Rust-Laufzeit den Interpreter-Overhead und Konflikte um den Global Interpreter Lock. Das ist wichtig, weil Nova-3 pro Audio-Chunk viele kleine Decoder-Aufrufe macht, sodass der hostseitige Dispatch den Durchsatz bei kleinen Batchgrößen begrenzt. Bei der durchsatzmaximierenden Batchgröße erzielte die Rust-Laufzeit einen um 7,5 % höheren Durchsatz als die Python-Baseline mit Multiprocessing.

Was das für Kunden bedeutet

Laut AWS helfen die Einsparungen Deepgram, effizient zu skalieren, weiterhin bessere Modelle auszuliefern und diese zu niedrigeren Preisen anzubieten. Auch Kunden, die Deepgram-Modelle in ihrer eigenen VPC auf Amazon SageMaker AI selbst betreiben, könnten profitieren; die beiden Unternehmen arbeiten dort weiter an Einrichtung, Zuverlässigkeit und Observability. Die berichteten Zugewinne gelten speziell für Offline-Batch-Workloads, und die Durchsatzergebnisse werden als relative Zugewinne angegeben, nicht als absolut verarbeitetes Audio pro Sekunde.