Helios: Ein Echtzeit-Modell zur Generierung langer Videos, das auf alle Abkürzungen verzichtet

Ich führe eine mentale Liste mit Dingen, die ich bei Videogenerierungsmodellen für selbstverständlich halte: KV-Cache für Geschwindigkeit, Sparse Attention für den Speicher, Keyframe-Sampling gegen Drift. Helios von PKU-YuanGroup wirft all das über Bord – und erreicht trotzdem 19,5 FPS auf einer einzelnen H100. Dieser Widerspruch ließ mich innehalten.

Ich bin Dora. Ich habe die letzten Tage damit verbracht, das Helios-Paper und das Repository zu lesen, alles lokal auszuprobieren, was möglich war, und zu verstehen, warum dieser Ansatz funktioniert, obwohl die gängige Meinung das Gegenteil sagt. Das hier ist keine Benchmark-Auswertung. Es sind eher Notizen von jemandem, der oft genug von „revolutionären” Behauptungen enttäuscht wurde und Belege sehen möchte.

Was Helios eigentlich ist

Helios ist ein autoregressives Videogenerierungsmodell, das 33 Frames pro Chunk erzeugt und diese Chunks aneinanderreiht, um minutenlange Videos zu erstellen – bis zu 1.452 Frames bei 24 FPS, was etwa 60 Sekunden kontinuierliches Videomaterial ergibt.

Das allein ist nicht überraschend. Ungewöhnlich ist die Liste der Dinge, die es nicht verwendet:

• Kein KV-Cache
• Kein Causal Masking
• Keine Sparse oder lineare Attention
• Kein TinyVAE
• Keine progressiven Rauschpläne
• Keine Quantisierung
• Kein Self-Forcing, keine Error-Banks oder Keyframe-Sampling (das übliche Anti-Drift-Toolkit)

Diese Liste zu lesen fühlte sich an, als würde jemand ein Auto beschreiben, das ohne Motor fährt. Jede dieser Techniken existiert, weil Videogenerierung teuer, speicherhungrig und anfällig für Qualitätsdegradation bei langen Sequenzen ist. Helios umgeht all das und schafft trotzdem Echtzeit-Inferenz. Die Frage ist nicht, ob es funktioniert – die Demos sind da draußen –, sondern wie.

Die dreistufige Trainings-Pipeline

Helios liefert drei Modellvarianten, die jeweils einer Trainingsstufe entsprechen. Das Verständnis dieser Stufen erklärt die Designlogik.

Stufe 1: Helios-Base

Das Fundament. Hier landen die kernarchitektonischen Innovationen:

• Unified History Injection — das Modell konditioniert auf vorherigen Chunks ohne die üblichen Fehlerakkumulationsstrafen
• Easy Anti-Drifting — eine Trainingszeitstrategie, die die Inferenzzeitkompromisse (Self-Forcing, Error-Banks) ersetzt, auf die die meisten autoregressiven Videomodelle angewiesen sind
• Multi-Term Memory Patchification — ein speichereffizienter Ansatz zur Verarbeitung langer temporaler Kontexte

Helios-Base verwendet v-Prediction mit standardmäßigem Classifier-Free Guidance. Es liefert die höchste Rohqualität der drei Varianten, ist aber bei der Inferenz mit 50 Diffusionsschritten pro Chunk auch am schwersten.

Stufe 2: Helios-Mid

Ein Zwischencheckpoint, der Pyramid Unified Predictor Corrector für die Token-Komprimierung einführt. Hier beginnt das Modell, marginale Qualität gegen bedeutende Geschwindigkeitsgewinne zu tauschen. Es verwendet CFG-Zero*, wodurch keine unbedingten Modellauswertungen während der Inferenz mehr nötig sind.

Wer mit Diffusionsmodellen gearbeitet hat, weiß, dass CFG den Rechenaufwand typischerweise verdoppelt, da das Modell pro Schritt zweimal ausgeführt wird – einmal mit dem Prompt, einmal ohne. Diesen Bedarf zu eliminieren ist ein erheblicher Effizienzgewinn.

Stufe 3: Helios-Distilled

Die finale Variante verwendet Adversarial Hierarchical Distillation, um 50 Diffusionsschritte auf 3 zu reduzieren. Sie wechselt von v-Prediction zu x0-Prediction mit einem eigenen Scheduler (HeliosDMDScheduler) und verzichtet vollständig auf CFG.

Das ist die Variante, die 19,5 FPS erreicht. Drei Schritte, kein CFG, keine Beschleunigungstricks – nur ein Modell, das darauf trainiert wurde, es beim ersten Versuch richtig zu machen.

Warum der „Keine Abkürzungen”-Ansatz wichtig ist

Die meisten Beschleunigungsarbeiten bei der Videogenerierung sind additiv. Man baut ein Modell, es ist zu langsam, also bolzt man KV-Cache dran. Immer noch zu viel Speicher, also fügt man Sparse Attention hinzu. Qualität driftet bei langen Sequenzen, also fügt man Keyframe-Sampling hinzu. Jede Lösung bringt ihre eigenen Fehlermodi und Komplexität mit.

Helios geht den entgegengesetzten Weg: Das Basismodell so effizient machen, dass man die Nachbesserungen nicht braucht. Die Trainings-Pipeline erledigt die schwere Arbeit, die sonst Inferenzzeitkompromisse übernehmen.

Es gibt eine praktische Konsequenz, die leicht zu übersehen ist. Weniger bewegliche Teile bedeuten weniger Dinge, die kaputt gehen können. Wer schon einmal ein KV-Cache-Korruptionsproblem debuggt oder beobachtet hat, wie Sparse Attention Artefakte an bestimmten Frame-Grenzen erzeugt, kennt die Kosten, die diese Systeme verursachen. Helios zahlt diese Kosten nicht.

Die Speichergeschichte ist ebenso bemerkenswert. Das Paper behauptet, dass vier 14B-Parameter-Modelle in 80 GB GPU-Speicher während des Trainings passen, unter Verwendung von Batch-Größen im Bildverarbeitungsmaßstab. Das ist eine aggressive Komprimierung eines normalerweise ausufernden Ressourcenbedarfs.

Was es kann

Helios unterstützt vier Generierungsmodi in allen drei Varianten:

• Text-to-Video — Prompt rein, Video raus
• Image-to-Video — erstes Frame plus Prompt
• Video-to-Video — Stilübertragung, Re-Timing, Modifikation
• Interaktiver Modus — iterative Verfeinerung

Die Frame-Mathematik ist spezifisch: Man arbeitet in Vielfachen von 33 Frames pro Chunk. Ungefähr 30 Sekunden gewünscht? Das sind 22 Chunks = 726 Frames. Eine volle Minute? 44 Chunks = 1.452 Frames. Die Chunk-Grenze ist der Ort, an dem autoregressive Übergaben stattfinden, und nach den Demos, die ich gesehen habe, sind die Nähte bemerkenswert sauber.

Dieser letzte Punkt verdient Betonung. Autoregressive Videomodelle zeigen ihr schlechtestes Verhalten typischerweise an Chunk-Grenzen – Bewegungsruckler, Farbverschiebungen, Objektdrift. Die „Easy Anti-Drifting”-Trainingsstrategie scheint das tatsächlich anzugehen, obwohl ich mehr unterschiedliche Testfälle sehen möchte, bevor ich das Problem für gelöst erkläre.

Integration und Ökosystem

Helios unterstützt bereits mehrere Inferenz-Backends:

• Hugging Face Diffusers — ModularPipeline-Integration
• vLLM-Omni — disaggregiertes Serving mit stufenbasierter Graph-Architektur
• SGLang-Diffusion — einheitliche Pipeline mit optimierten Kernels
• Ascend NPU — Day-0-Hardwareunterstützung (~10 FPS auf Ascend)

Die Diffusers-Integration ist am zugänglichsten. Der vLLM-Omni-Pfad ist interessant für Produktionsbereitstellungen, bei denen Prefill- und Decode-Phasen auf unterschiedlicher Hardware getrennt werden sollen. SGLang-Diffusion wirkt wie die zukunftsweisende Option – sie ist für die Art von gebündeltem, pipeliningbasiertem Serving ausgelegt, das Echtzeit-Anwendungen praktikabel macht.

Die Ascend-NPU-Unterstützung ist ein strategisches Signal. Day-0-Unterstützung für Nicht-NVIDIA-Hardware deutet darauf hin, dass dies kein Nachgedanke war. Mit ~10 FPS auf Ascend ist es langsamer als der H100-Pfad, aber für viele Anwendungen noch nutzbar.

HeliosBench

Das Team entwickelte seinen eigenen Benchmark – HeliosBench – speziell zur Bewertung der Echtzeit-Langvideogenerierung. Das ist erwähnenswert, weil die meisten bestehenden Videobenchmarks auf kurze Clips (4–16 Sekunden) ausgerichtet sind und die Fehlermodi nicht erfassen, die bei minutenlanger Länge auftreten: temporaler Drift, Bewegungsdegradation, Objektpersistenzfehler.

Ein eigens entwickelter Benchmark garantiert keine Objektivität, bedeutet aber zumindest, dass die richtigen Dinge gemessen werden. Ich würde gerne unabhängige Bewertungen mit HeliosBench sehen, um die Methodik zu validieren.

Was mich noch beschäftigt

Qualität an den Extremen. Das 33-Frame-Chunk-Design ist elegant, aber 44 aufeinanderfolgende autoregressive Schritte bieten viele Möglichkeiten für akkumulierten Fehler. Die Demos sehen sauber aus, aber Demos sehen immer sauber aus. Ich möchte adversarielle Prompts sehen – komplexe Kamerabewegung, viele interagierende Objekte, dramatische Lichtveränderungen über eine volle Minute.

Der Destillationskompromiss. Von 50 Schritten auf 3 zu gehen ist aggressiv. Destillierte Modelle opfern generell Diversität und Feindetails für Geschwindigkeit. Die Helios-Base-Variante existiert aus einem Grund – wenn Qualität wichtiger als Geschwindigkeit ist, zahlt man das 17-fache des Rechenaufwands. Das ist eine große Lücke zwischen den zwei Betriebspunkten.

Ökosystemreife. Das Modell ist Open Source (Apache 2.0), was großartig ist. Aber Open-Source-Videomodelle brauchen Community-Tooling, um praktisch zu werden – ComfyUI-Knoten, Trainingsscripts für Finetuning, LoRA-Unterstützung. Dieses Ökosystem braucht Zeit zur Entwicklung, und im Moment ist Helios brandneu.

Hardwareanforderungen. Echtzeit auf einer H100 ist beeindruckend. Aber H100s liegen nicht bei den meisten Menschen ungenutzt auf dem Schreibtisch. Die für viele Nutzer relevantere Frage lautet: Wie ist die Erfahrung auf einer 4090? Auf einer A100? Das Paper ist klar über H100- und Ascend-Leistung – weniger klar über das breite Spektrum der Hardware.

Warum das heraussticht

Ich habe im vergangenen Jahr viele Ankündigungen von Videogenerierungsmodellen verfolgt. Die meisten sind inkrementell: bessere FID-Werte, etwas längere Clips, marginal schnellere Inferenz. Helios fühlt sich anders an, weil es eine Annahme herausfordert, die ich unbewusst verinnerlicht hatte – dass Echtzeit-Langvideogenerierung einen Turm von Inferenzoptimierungen übereinander erfordert.

Die Antwort, die Helios vorschlägt, lautet: Was, wenn man das Modell einfach besser trainiert? Die Komplexität in die Trainings-Pipeline schieben, nicht in den Inferenz-Stack. Das Modell von Natur aus effizient machen, anstatt Effizienz nachträglich dranzubolzen.

Ob dieser Ansatz skaliert, sich verallgemeinert und den Kontakt mit Produktions-Workloads übersteht, ist eine offene Frage. Aber die Richtung ist überzeugend. Weniger bewegliche Teile, sauberere Architektur und Leistungszahlen, die für sich sprechen.

Der Code und die Gewichte sind auf GitHub. Apache 2.0. Wer eine H100 und einen freien Nachmittag hat, sollte einen Blick riskieren.