Hertz-dev: das erste Open-Source-basierte Modell für dialogorientiertes Audio

 (si.inc)
2 Punkte von GN⁺ 2024-11-04 | 1 Kommentare | Auf WhatsApp teilen
  • hertz-dev wurde als 8,5B-Parameter-Full-Duplex-Basismodell nur für Audio veröffentlicht, das sogar Situationen abdeckt, in denen zwei Personen gleichzeitig sprechen, und dient damit als Ausgangspunkt für die Forschung an Echtzeit-Sprachagenten
  • Die Architektur ist in hertz-codec und hertz-ar unterteilt: 16-kHz-Sprache wird in eine latente Darstellung mit 8 Hz umgewandelt, anschließend werden auf Basis früherer latenter Werte autoregressiv die nächsten Audio-Latents vorhergesagt
  • Die reale durchschnittliche Latenz wurde auf einer einzelnen RTX 4090 mit 120 ms gemessen; die theoretische durchschnittliche Latenz wird mit 80 ms angegeben und liegt damit laut Darstellung 2-mal niedriger als der bisherige Bestwert
  • hertz-codec erzeugt pro 125-ms-Frame einen 32-dimensionalen latenten Wert; hertz-ar nutzt einen 40-schichtigen Decoder-only Transformer mit 8,4B Parametern und rund 4,5 Minuten Kontext
  • Es handelt sich nicht um ein produktorientiertes Modell, dessen Antwortverteilung per Reinforcement-Learning-Tuning verengt wurde, sondern um ein Basismodell, das die Verteilung der Trainingsdaten vorhersagt; Forschende können es daher leichter für dialogorientierte Audio-Aufgaben feinabstimmen

Das Problem dialogorientierten Audios, auf das Hertz-dev abzielt

  • Für natürliche interaktive Agenten ist eine unmittelbare Audio-Modalität wichtiger als Text
  • Generative Audio-Ansätze lassen sich grob in diffusionsbasierte und autoregressive Verfahren einteilen; Diffusionsmodelle sind stark bei Musikgenerierung oder kurzen Samples, für echtes dialogorientiertes Audio eignet sich jedoch die autoregressive Methode besser
  • Die zentralen Herausforderungen, die ein Dialogmodell lösen muss, sind zwei Punkte
    • Audio erzeugen, das menschlich klingt, und natürliche Unterbrechungen verarbeiten
    • Situationen handhaben, in denen wie in gewöhnlichen menschlichen Gesprächen zwei Echtzeitkanäle gleichzeitig Informationen erzeugen

Veröffentlichtes Modell und Latenz

  • hertz-dev ist ein 8,5B-Parameter, Full-Duplex-Basismodell nur für Audio
  • Es ist auf ein Zwei-Sprecher-Format ausgelegt und kann überlappendes Audio zweier Sprecher parsen und erzeugen
  • Es arbeitet in einem latenten Raum mit quantisierten phonetischen Bits und sampelt pro Zeitschritt nur einen latenten Wert
  • Die Latenz wird wie folgt angegeben
    • Theoretische durchschnittliche Latenz: 80 ms
    • Reales Benchmark auf einer einzelnen RTX 4090: 120 ms
    • 2-mal niedriger als der bisherige Bestwert

Modellarchitektur: hertz-codec und hertz-ar

  • hertz-dev ist in zwei Komponenten unterteilt
    • hertz-codec: encodiert Audio in latente Werte und rekonstruiert daraus wieder Audio
    • hertz-ar: sagt künftige latente Werte bedingt auf frühere latente Werte vorher
  • Audio-Latents werden als reichhaltige Vorabrepräsentationen behandelt, die für verschiedene Downstream-Aufgaben genutzt werden können

  • hertz-codec

    • hertz-codec ist ein konvolutionaler Audio-VAE, der Mono-Sprache mit 16 kHz entgegennimmt und in eine latente Darstellung mit 8 Hz encodiert
    • Er verwendet eine KL-regularisierte Bitrate von 1 kbps
    • Für Streaming-Inferenz nutzt er Causal Convolution und fügt funktional Padding auf der linken Seite der Sequenz hinzu
    • Der Codec gibt Gauß-Parameter für Mittelwert und Varianz aus und sampelt pro 125-ms-Frame einen einzelnen 32-dimensionalen latenten Wert
    • In subjektiven Bewertungen übertrifft hertz-codec Soundstream und Encodec mit 6 kbps und wird etwa auf dem Niveau von DAC mit 8 kbps bewertet
    • Da er weniger Tokens pro Sekunde erzeugt als populäre Tokenizer, ist er für Language Modeling vorteilhaft
    • Parameterkonfiguration
      • Encoder: 5M Parameter
      • Decoder: 95M Parameter
    • Veröffentlichte Checkpoints

  • hertz-ar

    • hertz-ar ist ein 40-schichtiger Decoder-only Transformer mit 8,4B Parametern
    • Der Eingabekontext umfasst 2048 Tokens und entspricht etwa 4,5 Minuten
    • Die ausgegebenen latenten Werte können an hertz-codec übergeben werden
    • Die ersten 32 Schichten nehmen die latente Historie als Eingabe und sagen die 15-Bit-Quantisierungsprojektion des nächsten Audio-Latent-Tokens vorher
    • Dieser 32-schichtige Teil wird hertz-lm genannt und kann unabhängig trainiert oder aus Language-Model-Gewichten initialisiert werden
    • Die letzten 8 Schichten nutzen die latente Historie und den 15-Bit-quantisierten latenten Wert, um das künftige Audio-Latent-Token vorherzusagen
    • Duplex-Audio wird als Post-Training-Aufgabe behandelt
      • Zwei Projection Heads werden aneinandergehängt und anschließend getrennt
      • Die Verarbeitung erfolgt über zwei quantisierte Projection Pipelines, die jeweils auf das eigene Residual konditioniert sind
    • Veröffentlichte Checkpoints

Sample-Generierung und Trainingsentscheidungen

  • Um die Audio-Modellierungsfähigkeiten zu zeigen, werden Samples für Einkanal-Generierung, Zweikanal-Generierung und Live-Gespräche zwischen Mensch und Modell bereitgestellt
  • Interaktive Samples enthalten einen 9-Sekunden-Prompt
  • Die wichtigsten Trainingsentscheidungen sind folgende
    • Für hertz-codec werden Causal ConvNets eingesetzt, um paralleles Decoding und feinere Kontrolle über die Latent-Generierung zu ermöglichen
    • Die 15-Bit-quantisierten latenten Werte werden vortrainiert, um phonetische Informationen zu enthalten, und sollen das Modell dazu bringen, syntaktisch korrekte Äußerungen zu erzeugen
    • Die Quantisierung erfolgt, indem eine MLP Projection in eine Finite Scalar Quantization Layer eingespeist wird
    • Für hertz-lm wurden zwei Initialisierungsstrategien in Ablationsexperimenten untersucht; angegeben wird, dass es Linguistik unabhängig davon effektiv gelernt hat, ob eine Textmodell-Initialisierung verwendet wurde oder nicht

Echtzeit-Inferenz

  • Während der Live-Inferenz führt das Modell 8 Forward Passes pro Sekunde aus und setzt die autoregressive Generierung kontinuierlich fort
  • Die Eingabe besteht aus zwei separaten Kanälen, im Gespräch wird jedoch nur ein Kanal zurückgegeben
  • In jedem Schritt wird das Audio des Menschen in latente Werte tokenisiert und mit dem zuletzt vom Modell erzeugten latenten Wert kombiniert, bevor es in hertz-ar eingespeist wird
  • Die Latenz wird als durchschnittliche Zeit zwischen Nutzeräußerung und Modellantwort gemessen
  • Die rechnerische durchschnittliche Latenz beträgt 62,5 ms und umfasst die durchschnittliche Zeit zwischen einer beliebigen Äußerung und dem Ende eines Tokens, die Forward-Pass-Zeit sowie die Roundtrip-Internetlatenz
  • Bei Ausführung lokal auf einer RTX 4090 liegt die reale durchschnittliche Latenz üblicherweise bei 120 ms
  • Niedrige Latenz ist eine Voraussetzung, um ein Modell zu schaffen, das sich nicht wie ein verzögertes, abgehacktes Telefonat anfühlt, sondern menschenähnlich interagiert

Veröffentlichungscharakter und Einsatzbereich

  • hertz-dev wird als erstes öffentliches Basismodell für dialogorientiertes Audio vorgestellt
  • Mit Basismodell ist hier kein Modell gemeint, dessen Generierungsverteilung durch Reinforcement-Learning-Tuning stark verengt wurde, sondern ein Modell, das die Verteilung der Trainingsdaten präzise vorhersagt
  • Aufgrund dieses Charakters eignet es sich gut als Ausgangspunkt für Fine-Tuning auf verschiedene Downstream-Aufgaben
  • Zugehörige Ressourcen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-04
Hacker-News-Kommentare

  • Das ist wirklich cool. Zur Einordnung: Die bestehenden Open-Source-Sprachsynthese-Engines sind im Vergleich zu dem, was hier gezeigt wird, ziemlich schwach. Wenn das Ganze, auch wenn es derzeit Speech-to-Speech ist, zu einer multimodalen Form erweitert wird, die auch Text annehmen kann, dürfte die Nachfrage groß sein.
    Im Grunde wäre es zusätzlich zu einem hervorragenden Speech-to-Speech-Modell auch ein sehr gutes TTS-Modell. Jemand könnte zwar einen Workaround bauen, indem er etwas wie Piper so fine-tuned, dass dessen Ausgabe mit natürlicherer Prosodie und Intonation wiedergegeben wird, aber Text nativ entgegenzunehmen wäre wohl deutlich nützlicher, als eine Pipeline Text-LLM → Piper → Hertz-dev zu bauen.

    • Wenn das Team aus 4 Personen besteht, halte ich es für besser, sich auf eine Sache zu konzentrieren, statt sich in viele Richtungen zu verzetteln.
    • Genau, das ist es. Piper ist schon ziemlich ordentlich, und es wäre schön, wenn dieses Modell noch dazukäme.
      Allerdings muss das nicht unbedingt dieses Team selbst machen.

  • Hertz behauptet, das erste zu sein, aber Moshi, das Anfang dieses Jahres erschienen ist, ist ebenfalls ein bidirektionales Sprachmodell, das ähnlich funktioniert und sogar auf einem MacBook läuft: https://github.com/kyutai-labs/moshi

    • Moshi hat das Basismodell nicht veröffentlicht, sondern nur zwei für Dialoge fine-getunte Modelle. Abgesehen vom Codec wurde auch der Trainingscode nicht veröffentlicht.
      Bei Hertz sehe ich ebenfalls nur drei Inference-Notebooks und Modellcode voller no_grad, aber keinen Trainingscode. Es gibt auch kein Paper, sodass schwer nachzuvollziehen ist, wie es trainiert wurde und wie die Architektur aussieht. Wenn ich also nichts übersehen habe, ist es fraglich, ob man das forschungsfreundlich nennen kann.
    • LLaMA-Omni https://github.com/ictnlp/LLaMA-Omni ist ein Sprach-Sprachmodell auf Basis von Llama-3.1-8B-Instruct, das Text und Audio gleichzeitig erzeugt.
      moshi https://github.com/kyutai-labs/moshi ist ein Speech-Text-basiertes Modell, das den modernen Streaming-Neural-Audio-Codec Mimi nutzt, und Mini-Omni https://github.com/gpt-omni/mini-omni ist ein multimodales LLM auf Qwen2-Basis mit Spracheingabe und -ausgabe. Ichigo https://github.com/homebrewltd/ichigo ist ein offenes Forschungsprojekt, das über frühe Fusion native Hörfähigkeiten auf textbasierte LLMs erweitert.
    • Moshi ist ein gutes Modell, um eine Chat-App zu bauen, aber dieses hier scheint eher als ein echtes Basismodell konzipiert zu sein, mit der Eigenartigkeit, Natürlichkeit und Forschungsfreundlichkeit, die man von Basismodellierung kennt.

  • Dass Tesla Lidar und andere Sensoren zunächst ausschließt und sich auf rein visionbasiertes autonomes Fahren konzentriert, wirkt wie eine Strategie, um die Technologie zugänglicher und besser skalierbar zu machen.
    Wenn man sich auf reine Vision-Modelle konzentriert, kann die Einführung schneller gehen, große Datenmengen lassen sich sammeln und iterative Verbesserungen werden beschleunigt. Sobald visionbasierte Systeme ausreichend ausgereift sind, könnte Tesla Sensordaten wie Lidar oder Radar wieder integrieren, um seine Produktpalette für autonomes Fahren robuster und ausgereifter zu machen.
    Eine ähnliche Idee hatte ich auch zu Sprachinteraktionssystemen. Derzeit wird Sprache meist in Text umgewandelt, daraus eine Textantwort erzeugt und diese dann wieder in Sprache konvertiert. Wenn man ein System aber darauf trainieren könnte, ohne den Umweg über Text direkt mit Sprache zu antworten, wären natürlichere und spontanere Reaktionen möglich. Natürliche Sprache hat ihre eigene Syntax und ihren eigenen Rhythmus sowie Unterschiede in Dialekt und Tonfall; ein rein sprachlich trainiertes System wäre daher wohl menschlicher und interessanter.
    Ich frage mich, ob aktuelle Sprachinteraktionsmodelle dem Standardprozess Sprache→Text→Sprache folgen oder ob sie Speech-to-Speech-Verarbeitung erkunden.

    • Ich bin einer der Entwickler. Unser Modell ist vollständig Speech-to-Speech, und genau aus diesem Grund haben wir beim Bau von hertz-dev überhaupt keinen Text verwendet.
    • Der zweite Absatz klingt, als würde er ChatGPT Advanced Voice Mode oder die Realtime API beschreiben.

  • Wirklich cool. Ich schaue mir gerade VUI (Voice User Interface) an, das könnte also nützlich sein.
    Ich bin vielleicht etwas voreingenommen, weil ich über die Art promoviert habe, wie VUIs Menschen überzeugen, aber ich halte VUIs für die Zukunft der Computerinteraktion. Wenn nicht die Zukunft, dann können sie zumindest neue Nutzergruppen wie Kinder und ältere Menschen erschließen.

    • Ich interessiere mich sehr für Voice User Interfaces. Was baust du, und gibt es einen Link?
    • Stimmt, sehbehinderte Menschen auch.

  • Falls die Autoren von Sprachmodellen oder Leute, die an verwandten Dingen arbeiten, hier sind: Ich frage mich, ob ihr schon einmal das Gefühl hattet, dass die vom System erzeugten Klänge unheimlich wirken oder physiologische Auswirkungen haben.

  • Kann man sich das als eine Art LLM vorstellen, nur dass sowohl der Prompt als auch die generierte Ausgabe Audio sind, also als Audio-LLM?

    • Ja. Meiner Ansicht nach funktioniert es genau so.

  • Ich frage mich, ob die Idee des „Kollapses der generativen Verteilung“ ein erforschtes Thema ist. Falls ja, wüsste ich gern, unter welchem Namen es läuft.
    Interessant finde ich die Aussage, dass ein Basismodell die Verteilung der Trainingsdaten genau modelliert, während bei einem Modell mit starkem Reinforcement-Learning-Tuning die generative Verteilung eingeklappt wird, weshalb ein Basismodell ein besserer Ausgangspunkt für das Fine-Tuning auf verschiedene Aufgaben ist. Das scheint auch mit continual learning oder der richtigen Art des Fine-Tunings zusammenzuhängen.

  • Wie kann man das hertz-dev-Basismodell für andere Sprachen vortrainieren? Ich frage mich, wo man dazu Informationen findet.

  • Die Stimme klingt leicht verzerrt, und im Hintergrund ist häufig Rauschen zu hören. Besonders deutlich merkt man, dass dieses Rauschen verschwindet, wenn die Stimme stoppt.
    Ich frage mich, ob das eine Modellgrenze ist oder ein Problem mit der Qualität der Trainingsdaten.

  • Kann einer der Autoren erklären, was dieser Satz aus dem Beitrag tatsächlich bedeutet?
    hertz-vae: Ein Transformer-Decoder mit 1,8 Milliarden Parametern, der als gelernte Prior-Verteilung für das Audio-VAE dient. Er verwendet 8192 gesampelte latente Repräsentationen, also 17 Minuten Kontext, und sagt den nächsten encodierten Audio-Frame als Gaußsche Mischung voraus. Die 15-Bit-Quantisierungsinformation des nächsten Tokens dient dabei auf streamingfähige Weise als semantisches Gerüst, das die Generierung steuert.

    • Meine Vermutung ist folgende: Zuerst komprimiert der codec Audio mit 16 kHz Samplerate per Faltung auf 8 Samples pro Sekunde und führt dann eine Vektorquantisierung auf 128 Bit durch, um den Codec zu erhalten.
      Diese Bitzahl reicht bei Weitem nicht aus, um echtes Audio darzustellen, und ist vermutlich eher dazu gedacht, Dinge wie Phoneme zu repräsentieren. vae wirkt wie ein VAE-basiertes Diffusionsmodell, das den Codec als Prompt verwendet, und dev scheint ein Modell zu sein, das den nächsten Codec vorhersagt.
      Der gesamte Ablauf besteht wahrscheinlich darin, den Prompt mit codec zu tokenisieren, wenn weitere s Sekunden Audio benötigt werden, mit dev weitere 8 * s Tokens vorherzusagen und diese dann mit dem vae-Diffusionsmodell wieder in Audio umzuwandeln.