DreamActor-M2: Architektur und Evidenzgrenzen
Was das DreamActor-M2-Paper tatsächlich belegt, was offenbleibt und wie eine reproduzierbare Prüfung ohne erfundene Hardwarewerte aufgebaut wird.
Der veröffentlichte Beitrag
DreamActor-M2 behandelt die Animation eines Charakters aus einem einzelnen Referenzbild und einem Bewegungsvideo. Das Paper benennt zwei Schwächen früherer Verfahren: Explizite Posendarstellungen verlieren Details, die ein menschliches Skelett nicht ausdrückt, und die Bewegungseinspeisung kann Identitätserhalt und Bewegungstreue gegeneinander ausspielen.
Die Autoren formulieren die Bewegungssteuerung als raumzeitliches In-Context Learning. Erscheinungsbild und Bewegung werden in einem gemeinsamen latenten Raum zusammengeführt. Präziser als die pauschale Bezeichnung „skelettfrei“ ist daher die publizierte Aussage, dass das Verfahren von poseabhängiger Steuerung zu direkter, RGB-basierter Animation übergeht.
Zweistufige Trainingsstrategie
In der ersten Stufe wird die Modalitätslücke zwischen Standbild und Bewegungssequenz überbrückt. In der zweiten Stufe erzeugt eine selbstgestützte Datensynthese pseudo-übergreifende Identitätspaare. Laut Paper verbessert das die Generalisierung auf Menschen, Tiere und stilisierte Figuren.
Mit AW Bench führen die Autoren außerdem einen Benchmark für verschiedene Figurtypen und Bewegungsszenarien ein. Resultate müssen aus den aktuellen Tabellen des Papers mit ihrem Protokoll gelesen werden; losgelöste Prozentwerte oder Ranglisten sind keine belastbare Wiedergabe.
Nicht belegte Aussagen
Kein fester VRAM-Mindestwert
Abstract und Projektseite nennen keine universelle Verbraucher-GPU. Speicherbedarf hängt von Implementierung, Präzision, Auflösung, Bildzahl und Offloading ab.
Kein offizieller ComfyUI-Workflow
Die Quellen belegen keine gepflegte ComfyUI-Integration. Konzeptcode oder erfundene Workflow-JSON-Dateien sind keine ausführbare Evidenz.
Keine universelle Qualitätsquote
Eine Zahl wie „90 Prozent Identität“ benötigt Metrik, Datensatz, Split und reproduzierbares Auswertungsprotokoll.
Keine Produktionsgarantie
Demonstrationen und Benchmarks belegen nicht automatisch Latenz, Zuverlässigkeit, Sicherheit oder Support.
Reproduzierbare Prüfung
Eine unabhängige Prüfung beginnt erst mit veröffentlichtem Code oder Gewichten und zulässigen Nutzungsbedingungen. Zu protokollieren sind Repository-Commit, Checkpoint-Hash, Python- und Beschleuniger-Stack, Referenzbild, Bewegungsvideo sowie jede Vorverarbeitung. Zuerst wird die dokumentierte Standardkonfiguration ausgeführt; danach wird jeweils nur eine Variable geändert.
- Maximal belegten und reservierten Beschleunigerspeicher messen, nicht aus Diagrammen schätzen.
- Auflösung, Framezahl, Präzision und Offloading neben jedem Lauf festhalten.
- Originalausgaben und Auswertungsskripte archivieren.
- Autorenwerte von unabhängigen 42-UK-Messungen sichtbar trennen.
Bezug zu ComfyUI
ComfyUI kann mehrstufige Inferenz als Graph darstellen. Das beweist jedoch nicht, dass ein gepflegter DreamActor-M2-Node existiert. Vor einer Veröffentlichung müssen Repository, Revision, Modellpfade und Abhängigkeiten jedes Custom Nodes verifiziert werden.
Aktuelle, belegte Setup-Hinweise stehen in der Installationsmatrix; die Messmethode erläutert das Low-VRAM-Benchmarkregister.