Ein Schritt je Stück — der fotoechte sprechende Kopf neben unserem gerechneten

Im Juli haben wir einen sprechenden Kopf gebaut, der im Browser rechnet: ein parametrisches Modell, 815 Kilobyte, 0,28 Millisekunden je Bild, ohne Server und ohne Grafikkarte. Er sieht aus wie Computergrafik, weil er Computergrafik ist.

LeapTalk geht den anderen Weg. Eingabe ist ein Foto und eine Tonspur, Ausgabe ist Video von diesem Gesicht, wie es den Ton spricht. Fotoecht, 512 mal 512 Bildpunkte, 25 Bilder je Sekunde. Und — das ist die eigentliche Leistung — in einem einzigen Rechenschritt je Videostück, ohne dass das Gesicht dabei über die Zeit wegdriftet.

Warum ein Schritt technisch schwer ist

Videomodelle rechnen normalerweise in vielen Schritten aus Rauschen ein Bild heraus. Das ist gut, aber langsam, und es verbietet fortlaufende Erzeugung — man kann kein Gespräch führen, wenn jede Antwort erst gerendert werden muss. Die schnellen Verfahren erzeugen stattdessen Stück für Stück, jeweils aufbauend auf dem vorigen. Dann tritt der andere Fehler auf: Der Fehler jedes Stücks wandert ins nächste, und nach ein paar Minuten sieht man einem anderen Menschen zu. Zwischen diesen beiden Enden liegt die Sache fest, und genau das meint der Titel des Papers.

LeapTalk löst es, indem es die Aufgabe umformuliert. Statt von Rauschen zu Bild wird von Daten zu Daten transportiert, entlang einer sogenannten brownschen Brücke: einem Zufallspfad, dessen Anfang und Ende festliegen. Das Ende ist dabei nicht irgendein Bild, sondern das Referenzfoto selbst — dauerhaft, bei jedem Stück neu. Damit hat das Modell an jedem Punkt der Kette einen Anker, der nicht mitdriften kann. Dazu kommt eine Führung, die sich am Ton orientiert, damit die Lippen bei nur einem Schritt nicht einschlafen.

Der Aufsatz selbst ist klein. Das eigentliche Modell ist SoulX-FlashHead mit 1,3 Milliarden Parametern, das wiederum auf dem offenen Videomodell Wan 2.1 aufsetzt; LeapTalk liefert Zusatzgewichte, eine Ton-Projektion und einen schlanken Bild-Umsetzer. Trainiert wurde auf einer einzigen H200 mit Stapelgröße eins — auch das ist bemerkenswert und spricht dafür, dass hier gerechnet und nicht gerastert wurde.

Was der erste eigene Lauf ergeben hat

Wir haben es am 9. August auf unserer RTX 3090 laufen lassen — mit dem Ton, den unser eigener Erzähler ohnehin schon gebacken hat: sechs Folien über den Verein, 142 Sekunden, unsere eigene Stimme. Damit unterscheiden sich die beiden Fassungen in nichts außer dem Kopf.

Es funktioniert. 512 mal 512 Bildpunkte, 25 Bilder je Sekunde, 3.500 Bilder in einem einzigen Lauf. Als Vorlage diente ein Porträt aus unserem eigenen Bildmodell — kein realer Mensch, und damit auch keine Einwilligungsfrage.

Die Kernbehauptung des Papers hält. Nach 142 Sekunden ununterbrochener Erzeugung sieht man immer noch denselben Menschen — genau das, woran die schnellen Verfahren sonst scheitern. Nebeneinandergelegt zeigt sich trotzdem eine Drift: Das Gesicht wird über die Länge etwas schmaler, der Kopf minimal größer im Bild, die Haut eine Spur glatter als in der Vorlage.

Die Zahl, die wir nicht erwartet hatten, steht quer zur Erzählung des Papers. Ein Videostück kostet warm 2,875 Sekunden, und zwar so gleichmäßig, dass die schlechteste Runde nur ein Prozent über der besten liegt. Aufgeteilt:

Der Teil, den die Arbeit von zwanzig Schritten auf einen verkürzt hat, ist auf unserer Karte der billigere — der Umsetzer kostet das 2,6-fache. Das dreht unsere eigene Vorplanung um: Wir wollten für gebackene Videos die schwere Fassung nehmen, weil Geschwindigkeit kein Kriterium ist. Aber die schlanke Fassung ersetzt genau den teuersten Teil.

Also nachgemessen: die schlanke Fassung

Derselbe Ton, dieselbe Vorlage, nur der Umsetzer getauscht:

Der Rechenschritt ist auf die dritte Nachkommastelle identisch — es ist dasselbe Modell, nur ein anderer Ausgang. Der Umsetzer wird 19,5-mal billiger, das Ganze dreimal schneller, und der Anlauf schrumpft von anderthalb Minuten auf vier Sekunden, weil ohne den schweren Umsetzer nichts übersetzt werden muss. Bei 25 Bildern je Sekunde Ausgabe heißt 29,65 gerechnete: Es läuft schneller als Echtzeit — auf einer Karte der vorletzten Generation, neben laufender Produktion.

Und der Preis? Die Autoren warnen, die schlanke Fassung werde „an Lippen und feinen Regionen leicht unscharf“. Das stimmt, ist aber schwächer als erwartet: An den Zähnen verschmelzen die Einzelzähne, die Lippenkante wird weicher, die Haut um den Mund glatter. Verwischt ist nichts. Für einen Erzähler, der in einem Präsentationsvideo 300 Pixel breit ist, sieht das niemand; für eine Großaufnahme schon.

⚠️ Ein Vorbehalt gehört dazu: Beide Läufe laufen auseinander. Ein anderer Umsetzer erzeugt andere Latents, also zeigt derselbe Bildindex nicht denselben Laut. Der Bildvergleich ist damit ein Eindruck aus vier Stichproben, keine Messung — anders als die Zeiten daneben.

Macht in Summe 9,74 Bilder je Sekunde, also rund zweieinhalbmal so lange rechnen wie das Video dauert. Veröffentlicht sind 96 für eine RTX 4090 und bis zu 200 für eine H200. Wer diese Zahlen auf eine Karte der vorletzten Generation überträgt, liegt um das Zehnfache daneben.

Und dann kam der Beleg dafür, warum eine Zahl ohne ihre Umstände nichts wert ist. Im zweiten Lauf — 142 Sekunden am Stück — sprang die Zeit je Videostück ab Stück 94 von 2,9 auf 13,5 Sekunden, das Vierteinhalbfache. Nicht das Modell, nicht die Länge: Um 22:09:17 startete auf derselben Karte ein Sprachmodell-Prozess und belegte 8 Gigabyte. Die Karte stand bei 24 018 von 24 576 Megabyte, und LeapTalk schob seine Gewichte fortan über den Bus. Kurios am Rande: Der Sprachmodell-Dienst meldete auf Nachfrage kein geladenes Modell, während sein Prozess die acht Gigabyte hielt.

Als der fremde Prozess seinen Speicher wieder freigab, fiel die Zeit auf 2,9 Sekunden zurück. Dieselbe Arbeit, dieselben Daten: 2,9 — 13,5 — 2,9.

Beide Zahlen gehören deshalb zusammen genannt: 2,9 Sekunden je Stück auf ruhiger Karte, 13,5 auf belegter. Über den ganzen Lauf gemittelt — und darin steckt die Störung — meldet das Programm 3,81 Sekunden je Stück und 7,35 Bilder je Sekunde für 3.500 Bilder in 476 Sekunden. Das ist der Wert, mit dem zu rechnen ist, solange die Karte nebenbei anderes tut: rund dreieinhalbmal so lange rechnen wie das Video dauert. Wer nur die 2,9 zitiert, verkauft einen Sonderfall als Eigenschaft.

Was LeapTalk eigentlich beiträgt — isoliert gemessen

Der Steckbrief hatte bis hierher nur „mit Aufsatz“ gemessen. Also haben wir das Basismodell mit seinem eigenen Code laufen lassen: SoulX-FlashHead, dieselben Gewichte, dieselbe Vorlage, derselbe Ton, dieselbe Karte. Nur eben ohne LeapTalks Destillation.

Das Ergebnis ist eine glatte Zahl. Die Basis rechnet 72 Schritte auf 18 Stücke — also genau vier je Stück. LeapTalk kommt mit einem aus. Und weil der Schritt selbst gleich viel kostet (0,709 gegen 0,736 Sekunden, es ist dasselbe Modell), ist LeapTalks Beitrag damit exakt beziffert: vier Schritte auf einen.

Und was kosten die drei gesparten Schritte? Sichtbar fast nichts. Die Basis zeichnet die Lippen eine Spur satter und klarer, die beiden destillierten Fassungen liegen dicht beieinander und nur wenig darunter. Für ein Präsentationsvideo ist der Abstand zwischen 464 und 62 Sekunden das erheblich größere Argument.

⚠️ Auch hier laufen die Fassungen auseinander, es sind also keine gleichen Laute — vier Stichproben, ein Eindruck. Die Zeiten daneben sind gemessen.

🟢 Nebenbefund zur Lizenzfrage weiter oben: Das Basisprojekt hat eine LICENSE-Datei, Apache-2.0. Genau die, die LeapTalks Code-Repo fehlt. Wer den Bildteil ohne diese Lücke braucht, kann also beim Basismodell bleiben — er bezahlt es mit dem Faktor sieben in der Rechenzeit.

Drei Stolpersteine, die in keiner Anleitung stehen

Der Vollständigkeit halber, weil sie alle drei Zeit gekostet haben und keiner davon dokumentiert ist.

Der schwere Pfad kompiliert, der schlanke nicht. COMPILE_VAE hängt am Lite-Schalter: Wer die gute Fassung will, schickt den Bild-Umsetzer durch torchs Übersetzer — und der braucht die Python-Kopfdateien. Fehlen sie, bricht der Lauf nach 45 Sekunden mit einer Meldung ab, in der -lcuda steht. Das sieht nach einem Treiber- oder CUDA-Problem aus und ist eine fehlende Python.h.

Ohne ffmpeg rechnet er erst alles und scheitert dann. 228 Sekunden liefen durch, alle 18 Stücke fertig — und im letzten Schritt, beim Zusammenlegen von Bild und Ton, endet es mit „No such file or directory: ‘ffmpeg’“. Das fertige Bildmaterial liegt als Zwischendatei da und ist zu retten; die Reihenfolge im Programm ist trotzdem die denkbar teuerste.

Das Projekt legt eine Bibliotheksfassung fest, mit der sein eigener Code nicht läuft. Die Gesichtserkennung, die das mitgelieferte Trainingsskript aufruft, gibt es in genau der Fassung nicht mehr, die die Abhängigkeitsliste vorschreibt — die alte Schnittstelle ist dort entfallen. Für die Ableitung ohne Belang, für das Training nicht.

Angenehm dagegen: kein flash_attn nötig. Der Bau fällt sauber auf PyTorchs eigene Aufmerksamkeit zurück, und damit entfällt die Übersetzung, die auf dieser Box üblicherweise der schwierigste Teil ist.

Was im Quelltext steht und in keiner Beschreibung

Zwei Dinge wollten wir wissen, bevor wir das einordnen.

Erstens: Wie groß ist ein Stück? 33 Bilder, zwei davon als Vorgeschichte aus dem vorigen Stück, bei 25 Bildern je Sekunde. Ein Stück ist also 1,32 Sekunden lang, und der Ton dazu muss vorliegen, bevor das erste Bild erscheinen kann. Das ist eine Grenze der Bauweise: Auch mit 200 Bildern je Sekunde beginnt eine Antwort im Gespräch nicht früher als nach gut anderthalb Sekunden. Wer „Echtzeit“ liest und Sofortigkeit erwartet, wird das merken.

Zweitens: Was macht die Gesprächs-Oberfläche? Sie öffnet eine WebSocket-Verbindung zum Echtzeit-Dialogdienst eines chinesischen Konzerns — Zugangsdaten, Stimme, Systemanweisung und der gesamte Gesprächstext laufen dort hindurch. Das steht in der Beispiel-Umgebungsdatei, nicht in der Beschreibung. Der Bildteil bleibt lokal; der Gesprächsteil ist eine Fremdleistung, die niemand bestellt hat, der nur „sprechender Kopf, läuft im Haus“ gelesen hat.

Die Datei, die fehlt

Die Gewichte stehen unter Apache-2.0, das Basismodell ebenfalls, das Paper unter CC BY 4.0. Das klingt nach einer sauberen Lage — und wäre es auch, wenn nicht der Code fehlte. Das Repo enthält keine Lizenzdatei. Die GitHub-API meldet das Lizenzfeld leer, im Wurzelverzeichnis liegt keine.

Ohne Lizenz gilt nicht Großzügigkeit, sondern Urheberrecht: keine Weitergabe, keine Veränderung, keine Einbindung. Für einen Versuch auf der eigenen Maschine ist das folgenlos. Für alles, was danach käme, ist es der erste Schritt, und er ist wahrscheinlich mit einer freundlichen Nachfrage erledigt. Wir schreiben es hierhin, weil das Etikett auf der Modellkarte diese Lücke verdeckt — und weil uns dieselbe Prüfung schon beim Gesangsmodell die entscheidende Auskunft gegeben hat.

Wo wir stehen

Es läuft, es ist gemessen, und die Messung hat unsere Vorplanung an einer Stelle umgeworfen. Was nicht gemessen ist: die Lippen. Unser eigener Kopf trägt dazu eine Zahl — 95,2 Prozent Treffer bei Reden gegen Schweigen —, und für LeapTalk haben wir keine. Der Prüfer dafür liest unsere vorhergesagte Mundspur, kein Video; ihn auf beide Köpfe anzuwenden ist eigene Arbeit, die noch aussteht. Bis dahin gilt für die Lippen ein Augenschein und kein Wert, und ein Augenschein ist keine Zusage.

Praktisch entscheidet ohnehin nicht die Karte, sondern der Kalender: Sie ist im Regelbetrieb belegt: Für diesen Lauf musste der Video-Beiwagen weichen.

Bemerkenswert ist, was von der Sache übrig bleibt, wenn man sie an unserem Zweck misst. Wir wollen keinen Avatar, der antwortet. Wir wollen einen Erzähler, der einmal gebacken wird und danach in einem Präsentationsvideo seine Folien erklärt. Damit verfällt genau das, wofür LeapTalk gebaut ist: Ein Schritt statt zwanzig ist eine Antwort auf eine Frage, die wir nicht stellen. Übrig bleibt ein offenes Modell, das aus einem Bild und einer Tonspur ein Gesicht macht — und die Messung weiter unten sagt, welche Fassung dafür die richtige ist.

Deshalb ist der Vergleich, den wir gebaut haben, kein Wettbewerb. Unser eigener Erzähler hat einen fertig gebackenen Foliensatz über den Verein liegen: sechs Folien, Ton in unserer eigenen Stimme, wortgenaue Marken. Derselbe Ton geht unverändert in LeapTalk, und dann stehen zwei Fassungen nebeneinander, die sich in nichts unterscheiden außer dem Kopf.

Das soll die beiden Wege kenntlich machen, nicht gegeneinander ausspielen. Ein gerechneter Kopf wiegt 1,5 Megabyte, läuft im Browser ohne Netz weiter und zeigt niemanden, den es gibt — das kann kein Diffusionsmodell. Ein fotoechter Kopf trägt Nuancen, die aus 253 Achsen nicht herauskommen — das kann keine Matrixmultiplikation. Beides sind eigenständige Wege, beide bleiben, beide werden weitergebaut. Die Frage ist nicht „welcher gewinnt“, sondern welcher zu welchem Stück passt.

Eine Sache steht schon vor dem ersten Lauf fest, und sie löst den scheinbaren Widerspruch zu unserer eigenen Grenze auf: Das Referenzgesicht kommt aus unserem eigenen Bildmodell. LeapTalk verlangt ein Gesicht, nicht das eines realen Menschen. Ein erzeugtes Porträt bedeutet keine biometrischen Daten, keine Einwilligung, kein Mensch, dem etwas in den Mund gelegt werden kann — und ein Ergebnis, das veröffentlicht werden darf. Der Satz aus dem ersten Bericht bleibt damit auch auf diesem Weg wahr: Wir erzeugen Gesichter, wir vermessen keine.