4. Distributed Speech to Text¶
4.1. Einleitung¶
Bei der Transkription von Studieninterviews werden heutzutage häufig KI-Modelle wie beispielsweise OpenAI’s Open-Source-Modell Whisper eingesetzt. Für dieses Modell existieren zahlreiche Implementierungen, jedoch dauert die Transkription insbesondere auf leistungsschwachen CPUs erheblich lange. Da man inzwischen oftmals mehrere Computer zur Verfügung hat und Transkription eine gut parallelisierbare Aufgabe ist, lässt sich dadurch viel Zeit sparen. Genau hier setzt unser Projekt an: eine verteilte Transkription von Audiodateien auf mehrere Rechner. Die Architektur umfasst Worker, die auf den Rechnern laufen und die eigentliche Transkription übernehmen, einen zentralen Broker-Server, bei dem sich die Worker registrieren und der deren IP-Adressen verwaltet, sowie den Initiator, der die Audiodatei entgegennimmt, die Worker-Adressen vom Broker abruft, die Audiodatei aufteilt und schließlich die Teilergebnisse der Worker wieder zusammenführt. Das entwickelte Worker-Modul ist ein Kernstück dieser Architektur und als Docker-Container konzipiert. Seine Hauptaufgabe ist die eigentliche Transkription. Er empfängt Audiodateien über einen REST-Endpunkt, verarbeitet diese mit dem OpenAI Whisper-Modell und sendet den erkannten Text zurück an den Initiator. Ein regelmäßiger Heartbeat-Mechanismus vom Worker an den Broker-Server stellt sicher, dass nur aktive Worker für Aufgaben eingeteilt werden.
4.2. Demo¶
4.3. Grundlagen¶
4.3.1. Shell-Scripting¶
Shell ist die Linux-Kommandozeile. Anstatt Befehle für die Kommandozeile einzeln nacheinander einzugeben, kann man Sie in einem Shell-Script auch nacheinander strukturiert aufrufen. Zudem bietet Shell-Scripting die Möglichkeit, Steuerelemente wie Bedinungen, Schleifen und Methoden einzubauen [GNUBash]. Im Rahmen der Entwicklung des Worker-Moduls wurde beispielsweise ein Shell-Skript erstellt, um dessen Einrichtung zu vereinfachen. Dieses Skript umfasste auch die automatisierte Installation von notwendigen Abhängigkeiten wie FFmpeg, die für das Whisper-Modell auf dem Worker benötigt werden. Der weiter unten beschriebene Abschnitt „Erstellen des Shell Scripts“ bezieht sich hingegen auf ein separates Skript für den Initiator-Prozess.
4.3.2. Broker Pattern¶
Das Broker Pattern ist ein Entwurfsmuster zur Strukturierung verteilter Systeme, bei dem ein zentraler Vermittler, der sogenannte Broker, die Kommunikation zwischen Clients und Servern koordiniert. Anstatt dass Komponenten direkt miteinander kommunizieren, senden sie ihre Anfragen an den Broker, der diese weiterleitet und die Antwort zurückliefert.
4.3.3. Gradle (Kotlin)¶
Als Build-Tool für die Broker-Software wurde dieses Mal, im Vergleich zu Projekt 1, Gradle auf Basis von Kotlin verwendet. Gradle gilt im Vergleich zu Maven aus Projekt 1 als moderner und performanter, weshalb es in einem breiteren Anwendungsbereich eingesetzt werden kann. Innerhalb von Gradle kann man sich zwischen zwei Programmiersprachen entscheiden, auf denen Gradle basieren soll: Groovy und Kotlin. Bei einer kurzen Einschätzung hat sich Kotlin als Gradle-Basis allgemein als sinnvoller herausgestellt. Aufgrund des jüngeren Alters gibt es zwar weniger Online-Ressourcen als bei Groovy und die Lernkurve ist etwas steiler, jedoch bringt Kotlin den bedeutenden Vorteil der statischen Typisierung mit sich, was grobe Fehler schon beim Schreiben des Codes aufdeckt und eine deutlich bessere Unterstützung durch die IDE ermöglicht.
4.3.4. Python und Flask¶
Für die Entwicklung des Worker-Moduls wurde Python 3 als Programmiersprache gewählt. Python ist bekannt für seine klare Syntax und eine umfangreiche Standardbibliothek, was die Entwicklung beschleunigt. Als Web-Framework kam Flask zum Einsatz. Flask ist ein leichtgewichtiges Micro-Framework, das sich gut für die Erstellung von REST-APIs eignet, wie sie für die Kommunikation mit dem Worker-Modul benötigt werden.
4.3.5. OpenAI Whisper¶
OpenAI Whisper ist ein automatisches Spracherkennungssystem (ASR), das von OpenAI trainiert wurde. Es ist in der Lage, Audio in Text zu transkribieren und zeichnet sich durch eine hohe Genauigkeit bei verschiedenen Sprachen und Akzenten aus. Im Projekt „Distributed Speech-to-Text“ ist es das Kernmodell, das im Worker-Modul für die Umwandlung von Sprache in Text verwendet wird. Die Größe des Whisper-Modells (z.B. tiny, base, small) ist im Worker-Modul konfigurierbar, um einen flexiblen Einsatz auf unterschiedlicher Hardware zu ermöglichen.
4.3.6. FFmpeg¶
FFmpeg ist eine freie Software-Sammlung, die Programme und Bibliotheken zum Aufnehmen, Konvertieren und Streamen von Audio- und Videodaten enthält [FFmpeg]. Für das Worker-Modul (entwickelt von Frederik und Adrian) ist FFmpeg eine wichtige Abhängigkeit, da OpenAI Whisper es für die Vorverarbeitung von Audiodateien benötigt, bevor die eigentliche Transkription stattfinden kann. Es wird auch im Initiator-Skript verwendet, um Audiodateien aufzuteilen.
4.4. Vorgehensweise¶
4.4.1. Broker¶
Der Broker nimmt Registrierungen und Heartbeat-Meldungen der Worker entgegen. Auf Anfrage eines Initiators gibt der Broker dann eine gefilterte Liste aller verfügbaren Worker zurück. Für den Broker wurde wieder das Spring-Boot-Framework mit Java verwendet. Aus Gründen der Performanz wurde dieses Mal aber asynchrone Programmierung eingesetzt. Dies ist sinnvoll, da die Daten des Brokers erneut in einer Datenbank gespeichert werden. Eine Abfrage dieser ist grundsätzlich als langsam anzusehen, weshalb der Broker davon profitiert, während der Wartezeit auf die Datenbank weitere Aufgaben ausführen zu können. Außerdem wurde wegen der kurzen Entwicklungszeit wieder Lombok und JpaRepository eingesetzt. Lombok erleichtert das Definieren von Klassen und Methoden, während JpaRepository das Datenmodell der Datenbank auf Grundlage der in Java definierten Klassen erzeugt und CRUD-Operationen bereitstellt.
4.4.2. Worker-Modul¶
Die Entwicklung des Worker-Moduls war ein zentraler Bestandteil des Projekts. Der Fokus lag auf einer stabilen und effizienten Transkriptionslösung.
Technische Umsetzung und Designentscheidungen: Das Worker-Modul basiert, wie unter Grundlagen im Abschnitt „Python und Flask“ erwähnt, auf Python 3 und dem Flask-Framework für die REST-API. Eine wesentliche Designentscheidung zur Performanceoptimierung war, das OpenAI Whisper-Modell direkt beim Start des Workers zu laden und nicht bei jeder einzelnen Transkriptionsanfrage neu zu initialisieren. Dies reduziert die Latenzzeiten erheblich. Eingehende Audiodateien werden im Worker in einem dedizierten input-Verzeichnis verarbeitet. Die Konfigurierbarkeit der Whisper-Modellgröße über eine Umgebungsvariable (siehe Grundlagen „OpenAI Whisper“) erlaubt eine Anpassung an die verfügbare Hardware. Alle notwendigen Python-Abhängigkeiten des Workers sind in einer requirements.txt-Datei spezifiziert, was eine reproduzierbare Installation der Umgebung sicherstellt. Die Einrichtung wird, wie im Abschnitt „Shell-Scripting“ erwähnt, durch ein Shell-Skript vereinfacht.
Entwicklungsbeiträge und Herausforderungen: Die Hauptaufgabe bestand darin, einen robusten REST-Endpunkt für den Empfang von Audiodateien zu implementieren und die zuverlässige Rücksendung der Transkriptionsergebnisse an den Initiator zu gewährleisten. Eine anfängliche Herausforderung war die korrekte Übertragung und Verarbeitung der Audiodateien selbst. Die Containerisierung des Workers (siehe Abschnitt „Containerisierung und Deployment“) war ebenfalls ein wichtiger und herausfordernder Aspekt.
Testergebnisse: Die Leistungsfähigkeit des Worker-Moduls wurde durch Tests validiert. Eine zweiminütige Audiodatei konnte auf einer CPU-Umgebung in etwa zwölf Sekunden transkribiert werden. Stresstests mit mehreren parallel laufenden Workern bestätigten die Stabilität und Skalierbarkeit des Systems.
4.4.3. Erstellen des Shell Scripts¶
Dieser Abschnitt beschreibt das Initiator-Skript, nicht das Setup-Skript des Workers von F&A. Nachdem der Nutzer das Script startet, wird zunächst geprüft, ob die nötigen Abhängigkeiten bereits installiert sind. Es wurde darauf geachtet möglichst wenig externe Abhängigkeiten einzubauen. Konkret betrifft das nur FFmpeg zur Analyse und Aufteilung der Audiodatei sowie „zenity“[zenity] für die grafische Dateiauswahl über einen Dateiexplorer. Wenn eines der beiden Programme nicht vorhanden ist, wird ein Hinweis zur Installation ausgegeben und das Script gestoppt. Wenn alles installiert ist, wird der Nutzer, wie bereits erwähnt mit Hilfe von “zenity”, über einen Dateiexplorer aufgefordert, die zu transkribierende Datei auszuwählen. Dann wird eine Anfrage an die API gestellt, um die Adressen der aktuell registrierten Worker zu bekommen. Basierend auf der Anzahl an verfügbaren Workern wird die Audiodatei dann mit “ffmpeg” in die richtige Anzahl an Segmenten aufgeteilt und dann wieder per API an die Worker gesendet. Falls es bei einem Worker einen Fehler gibt, wird dieser aus der Liste entfernt und es wird nochmal versucht. Wenn alles Erfolgreich ist, geben die Anfragen an die Worker den transkribierten Text als JSON zurück. Dieser wird dann noch vom Script zusammengesetzt und als Fließtext in der Konsole ausgegeben.
4.4.4. Containerisierung und Deployment¶
In diesem Projekt wurden, wie in den vorherigen Projekten, die Komponenten containerisiert. Die einzelnen Komponenten, Worker, Initiator und Broker, wurden als eigene Images entworfen und verfügen über separate Compose-Dateien, sodass sie unabhängig voneinander gestartet werden können. Die Containerisierung des von Frederik und Adrian entwickelten Worker-Moduls mittels Docker war ein Kernaspekt. Dies erforderte eine genaue Abstimmung der Dateipfade und Netzwerkkonfigurationen innerhalb der Docker-Umgebung, die im Dockerfile des Workers und der zugehörigen docker-compose.yml-Datei definiert wurden. Auf dem zentralen Broker-Server soll beispielsweise nur der Broker-Prozess laufen. Dort wurde, wie bereits in den vorherigen Projekten, der Broker-Prozess als Docker-Container gestartet und die Firewall entsprechend konfiguriert. Auf den Rechnern wurden die Worker-Container ausgeführt, auf einem der Rechner lief zusätzlich ein Initiator-Container.
4.5. Fazit & Ausblick¶
Die Arbeit am Projekt „Distributed Speech-to-Text“, insbesondere die Entwicklung des Worker-Moduls durch Frederik und Adrian, war eine wertvolle Erfahrung im Bereich verteilter Systeme und der Implementierung KI-gestützter Anwendungen. Das Projekt demonstriert erfolgreich, wie durch die Parallelisierung von Aufgaben wie der Sprachtranskription signifikante Zeitersparnisse auf Standardhardware erzielt werden können. Die Stabilität und Skalierbarkeit des Worker-Moduls konnten in Tests nachgewiesen werden.
Für die Zukunft sind einige Verbesserungen und Erweiterungen denkbar: Die Implementierung von gRPC anstelle von REST für die Kommunikation zwischen den Diensten (insbesondere zwischen Initiator und Worker) könnte die Latenz weiter reduzieren. Eine automatische Skalierung der Worker-Instanzen, beispielsweise mittels Technologien wie Docker Swarm oder Kubernetes, würde es dem System ermöglichen, flexibel auf unterschiedliche Lastszenarien zu reagieren. Des Weiteren ist die Einführung eines Authentifizierungs-Tokens zwischen den Diensten angedacht, um die Sicherheit der Kommunikation zu erhöhen. Das im Abschnitt „Erstellen des Shell Scripts“ beschriebene Initiator-Skript stellt eine funktionierende Methode zur Nutzung des Systems dar.
4.6. Literaturverzeichnis¶
GNU Project (2025): GNU Bash. Verfügbar unter: https://www.gnu.org/software/bash/ (Zugriff am: 13. Mai 2025).
FFmpeg (2025). Verfügbar unter: https://ffmpeg.org/ (Zugriff am: 13. Mai 2025)
GNOME (2025): Zenity. Verfügbar unter: https://gitlab.gnome.org/GNOME/zenity (Zugriff am: 13. Mai 2025)