LTX-2 auf LTX-2.3 Upgrade: Kompatibilität, LoRA-Probleme & Migration (2026)

Hey, ich bin Dora. Ich hatte keine Upgrade-Woche geplant. Ich wollte nur einen alten Prompt aus einem Kunden-Deck erneut ausführen. Gleicher Seed, gleiche Einstellungen, angeblich „dasselbe” Modell – aber das war es nicht. LTX-2.3 landete in meinem Ordner, und die Bilder wirkten eine Spur klarer, etwas wörtlicher … und mein LoRA-optimierter Stil war weg. Diese kleine Diskrepanz trieb mich in den Kaninchenbau. Über einige Tage im März 2026 testete ich das ltx-2 auf ltx-2.3-Upgrade in meinen üblichen ComfyUI-Pipelines und der verwalteten API, auf die ich für Batch-Arbeit setze. Hier ist, was sich tatsächlich verändert hat, was stabil geblieben ist und wo die Reibung entsteht, wenn man echte Arbeit macht – und keine Demos.

Was sich zwischen LTX-2 und 2.3 wirklich geändert hat

Ich überspringe die Marketing-Aussagen und bleibe bei den Teilen, die meine bestehenden Workflows berührt haben.

Prompts werden wörtlicher aufgelöst. Ich bemerkte, dass 2.3 Positionshinweise („links/rechts”, „Vordergrund/Hintergrund”) konsistenter befolgt. Praktisch für Produktlayouts: etwas starr für künstlerische Prompts, die auf der Lockerheit von LTX-2 basierten.
Kontrast und Sättigung sind standardmäßig höher. Meine neutralen Lichtpresets wirkten in 2.3 knackiger. Ich reduzierte die Guidance um ~0,5–1,0 und senkte den Kontrast in der Nachbearbeitung seltener.
Seeds sind nicht 1:1 zwischen den Versionen. Auch mit demselben Seed divergierte LTX-2.3 in meinen Tests nach ~10–12 Schritten. Wenn man pixelstabile Re-Renders alter Jobs benötigt, sollte man sich darauf nicht verlassen.
Die Seitenverhältnis-Behandlung ist vernünftiger. 2.3 respektierte nicht-quadratische Größen (z. B. 1024×1536) mit weniger verzerrten Elementen. Ich konnte einige der Canvas-Hacks weglassen, die ich bei LTX-2 verwendet hatte.
Sampler-Standardwerte haben sich geändert. Der empfohlene Scheduler in 2.3 (und seine Step-Kurve) brachte mich dazu, für dasselbe Detailniveau weniger Schritte zu verwenden. Mein Sweet Spot verschob sich von ~28–32 Schritten auf ~22–26. Der Durchsatz verbesserte sich etwas auf derselben GPU.

Nichts davon ist dramatisch. Aber es reicht aus, um eine Pipeline auf kleine, manchmal willkommene Weise zu biegen … und um alles zu brechen, das auf exakter Reproduzierbarkeit basiert, besonders LoRAs.

Realitätscheck Modellgröße: Implikationen für lokale Deployments

Ich lief beide Versionen auf einer 24-GB-4090 und einer Laptop-GPU mit 8 GB. Das ist der Teil, den ich mir in den Release Notes mehr gewünscht hätte: die praktische Grenze dessen, was die Karte halten kann und dabei noch Spielraum lässt.

VRAM- und Speichervergleich (dev / fp8 / distilled für beide Versionen)

Folgendes habe ich beobachtet und was in der Praxis wichtig war:

Dev/vollständige Checkpoints: Auf der 4090 wurden sowohl LTX-2 als auch LTX-2.3 „dev”-Builds geladen, aber 2.3 belegte zur Laufzeit etwas mehr VRAM (in meinen Tests mit demselben Sampler/Schritten grob +0,5–1,2 GB). Wenn man bei hochauflösenden Generierungen wenig Spielraum hat, zählt diese Marge. Auf der 8-GB-Karte waren vollständige Dev-Builds ohne Offloading nicht realistisch.
FP8/quantisierte Varianten: Der fp8-2.3-Build sparte in meinen Tests ~25–35% VRAM gegenüber voller Präzision, auf Kosten von etwas anfälligeren Feinheiten bei sehr wenigen Schritten. Für alltägliche 1K-Ausgaben störte mich das nicht. Wer aggressiv compositet oder zuschneidet, könnte es bemerken. Für die praktischen Vorteile der FP8-Quantisierung im Deployment verwies ich auf NVIDIAs offiziellen Leitfaden zum effizienten KI-Training mit niedrigerer Präzision.
Distilled: Der distillierte 2.3-Checkpoint verhielt sich wie ein praktischer Mittelweg. Kleinerer Speicher-Footprint, merklich schnellere Warm-Starts, kleiner Kompromiss bei Kanten-Mikrodetails. Für Social-ready-Images und interne Docs würde ich distilled 2.3 dem vollen 2.0 vorziehen.
Festplatten-Footprint: Für 2.3-Varianten gegenüber 2.0 ist ein leichter Anstieg zu erwarten. Nicht riesig, aber ich musste alte experimentelle LoRAs bereinigen, um das Scratch-Laufwerk sauber zu halten.

Eine kleine Anmerkung aus der Praxis: Sobald der VRAM-Spielraum unter ~2 GB Restkapazität fiel, sah ich bei gekachelten Hochauflösungs-Passes mit 2.3 gelegentlich OOMs. Das Reduzieren des Tiling-Overlaps oder die Verwendung von fp8 stabilisierte das.

ComfyUI-Workflow-Kompatibilität: Was noch funktioniert, was aktualisiert werden muss

Ich ließ mein ComfyUI-Setup größtenteils intakt und tauschte nur die Checkpoints aus. Ich verwies hauptsächlich auf das offizielle ComfyUI-Repository, um die Workflow-Kompatibilität während meiner Tests sicherzustellen.

Was noch reibungslos funktionierte:

Grundlegende Text-zu-Bild-Graphen mit Conditioning → Sampler → VAE-Decode. Ich konnte den 2.3-Loader eintauschen und rendern, ohne den Graphen neu aufzubauen.
Gängige Sampler (z. B. DPM++-Familien) liefen einwandfrei. Ich passte nur Schritte und Guidance an die neue Kurve an.
Hochauflösungs-Workflows mit latenten Upscalern funktionierten weiterhin, wobei ich die Schritte der zweiten Stufe um ~20% kürzte, ohne Details zu verlieren.

Was aktualisiert werden musste:

LoRA-Injection-Nodes: Meine LTX-2-LoRAs ließen sich nicht sauber an 2.3 anbinden. Auch wenn der Node die Verbindung zuließ, waren die Ergebnisse falsch – der Stil driftete oder kollabierte. Mehr dazu weiter unten.
Checkpoint-Pfade und -Formate: Die 2.3-Checkpoints, die ich testete, wurden mit anderen Ordnernamen und einer leicht anderen Config-Referenz ausgeliefert. Ich musste die Checkpoint-Loader-Node-Pfade aktualisieren und die VAE-Kopplung bestätigen.
Parameter-Standardwerte: Meine alten „House”-Presets (CFG 6,5, Schritte ~30) produzierten auf 2.3 härteren Kontrast. Das Absenken von CFG auf ~5,5 und der Schritte auf ~24 brachte die gewünschte Balance zurück.
Negative Prompts: Ich verließ mich weniger auf lange Negativlisten. 2.3 schien bestimmte Artefakte von Natur aus zu vermeiden (Hände verbesserten sich etwas bei meinen Produktposen). Ich kürzte die Negatives, um den Prompt-Overhead zu reduzieren.

Node-Änderungen, Checkpoint-Pfade und Parameter-Unterschiede

Node-Änderungen: Ich brauchte keine neuen Custom Nodes für die Kerngenerierung, aber ich aktualisierte meinen Model-Loader-Node auf einen neueren ComfyUI-Build, um Metadaten-Fehlanpassungen zu vermeiden. Wenn man mit ComfyUI einige Monate hinterherhinkt, sollte man zuerst updaten – das erspart seltsame Fehler.
Checkpoint-Pfade: 2.0- und 2.3-Ordner getrennt halten. Ich verwende ein klares Benennungsschema (model_name/version/precision), damit Batch-Jobs nicht die falsche Datei erwischen.
Parameter-Unterschiede: 2.3 schien empfindlicher auf CFG-Schwankungen zu reagieren. Kleine Änderungen (~0,5) hatten einen größeren visuellen Einfluss als bei 2.0. Außerdem lieferten weniger Schritte ähnliche Details: Bei 1K-Bildern brachten mehr als ~26 Schritte in meinen Tests kaum noch Mehrwert.

LoRA-Kompatibilität: Warum bestehende LoRAs sich nicht direkt übertragen lassen

Das war die größte Überraschung – und die kostspieligste, wenn man eine Stilbibliothek auf LTX-2 aufgebaut hat.

Meine LTX-2-LoRAs ließen sich nicht sinnvoll übertragen. Die Kurzversion: Basismodell-Änderungen (Embedding-Raum, Attention-Blöcke, manchmal Normalisierung und VAE-Änderungen) bedeuten, dass die gelernten Deltas nicht sauber mappen. Man kann es erzwingen, aber dann kämpft man mit merkwürdigen Farbstichen, Form-Drifts oder dem gefürchteten „alles wird zu beige-farbenem Plastik”. Wenn der eigene Stil stark auf LoRAs basiert, wird empfohlen, LTX-2.3 als neues Basismodell zu behandeln und anhand des offiziellen Hugging Face LoRA-Trainings-Leitfadens neu zu trainieren.

Aus praktischer Sicht: Wenn der Look von LoRAs abhängt, sollte man LTX-2.3 als neue Basis behandeln und neu trainieren.

Was neu trainiert werden muss und geschätzte Kosten

Was ich beibehielt:

Datensatz: Ich verwendete mein bereinigtes, mit Captions versehenes Set erneut (je nach Vielfalt rund 300–800 Bilder pro Stil). Bessere Captions halfen bei 2.3 mehr als rohes Volumen.
Einstellungen: Niedrigere Lernraten als bei 2.0, um eine übergesättigte Sättigung zu vermeiden. Rank/Dim blieb ähnlich, aber ich reduzierte die Trainingsschritte um ~10–15%.
Validierung: Ich validierte alle paar hundert Schritte mit den neuen Basis-Prompts, nicht den Legacy-Prompts. Alte Prompts beeinflussten mich in Richtung falscher Ziele.

Kosten, in groben, menschlichen Begriffen:

Zeit: Etwa 3–5 Stunden pro LoRA auf einer einzelnen 4090 für mittelgroße Sets, inklusive Validierung und kleinen Neustarts. Distilled-2.3-Basen trainierten etwas schneller.
Cloud: Wer mietet, sollte Stand März 2026 mit $0,80–$1,60/Stunde für eine 24-GB-GPU-Klasse rechnen. Das bringt ein einzelnes sauberes Retrain in die Größenordnung von $3–$10, plus die eigene Zeit. Größere Sets und mehr Experimente treiben das natürlich nach oben.

Es hat mir anfangs keine Zeit gespart. Aber nach zwei oder drei Durchläufen benötigten meine 2.3-LoRAs weniger Leitplanken in Prompts, was den mentalen Aufwand für zukünftige Batches reduzierte.

API-Nutzer: Zu beachtende Endpunkt- und Parameter-Unterschiede

Bei verwalteten APIs waren die Unterschiede zwischen ltx-2.3 und ltx-2 klein, aber folgenreich:

Versionierte Modelle: 2.3 steckt oft hinter einem expliziten Modell- oder Versionsparameter. Wer auf „latest” setzt, sollte es auf 2.0 festsetzen, bis die Tests abgeschlossen sind.
Standardwerte haben sich verschoben: Guidance, Step-Counts und Safety-Level veränderten sich bei meinem Anbieter. Meine LTX-2-Presets produzierten auf 2.3 kontraststärkere Bilder, bis ich CFG um ~10–15% absenkte.
Seed-Typen: Eine API wechselte mit 2.3 von 32-Bit- auf 64-Bit-Ints bei Seeds. Harmlos – außer dass mein alter Wrapper Seeds als Strings typisierte. Sie wurden stillschweigend ignoriert.
Negative Prompts und Weight-Syntax: Tokenizer/Weight-Formatierung prüfen.Ein Anbieter verschärfte das Parsing: Meine alte „(keyword:1.2)“-Syntax benötigte Abstände, um zu registrieren.
Rate-Limits und Batching: 2.3 lief in meinen Queues pro Request etwas schneller, aber die Batch-Concurrency-Caps änderten sich nicht. Ich staffelte Jobs, um kurze Spitzen zu vermeiden.

Im Zweifelsfall die Release Notes des Anbieters überfliegen und denselben Prompt/Seed über die Versionen hinweg testen. Ähnliche Komposition erwarten, nicht identische Pixel.

Wann es noch sinnvoll ist, bei LTX-2 zu bleiben

Ich mag neue Spielzeuge genauso wie jeder andere, aber ich baue funktionierende Systeme nicht ohne Grund um. Ich blieb bei einigen Projekten auf LTX-2, weil:

Man strikte Reproduzierbarkeit benötigt. Gleicher Seed, gleiche Pixel, für Audits, regulierte Workflows oder Kunden-Freigaben, die an eine vergangene Modellversion gebunden sind.
Man umfangreiche LoRA-Investitionen hat. Wenn die Bibliothek groß und vielfältig ist, summieren sich die Retrain-Kosten (Zeit, Aufmerksamkeit, nicht nur Dollars).
Edge- oder Low-VRAM-Einschränkungen bestehen. Wenn die 8-GB-Karte den 2.0-Stack kaum hält, können die zusätzlichen Headroom-Anforderungen von 2.3 zum Offloading zwingen.
Team-Trainingskosten anfallen. Wenn Prompts und Presets in Dokumentationen und Tutorials eingebettet sind, erzwingt 2.3 kleine, aber kumulative Änderungen. Death by a thousand cuts ist real.

Auf der anderen Seite: Wer frisch anfängt oder eine engere Prompt-Befolgung schätzt, findet 2.3 leichter zu steuern.

Upgrade-Entscheidungs-Checkliste (ComfyUI / verwaltete API)

Das ist, was ich tatsächlich durchging, bevor ich eine Pipeline umstellte.

ComfyUI

Den Graphen duplizieren und LTX-2.3 mit einem sauberen Loader-Node eintauschen. Den 2.0-Pfad nicht überschreiben.
Das eigene Step-/CFG-Paar neu finden. Mit ~80% der alten Schritte beginnen und CFG um 0,5–1,0 absenken.
Seeds über 5–10 Prompts validieren, die einem wichtig sind. Kompositions-Ähnlichkeit akzeptieren, nicht Pixel-Identität.
Hochauflösungs-/Tiling-Stufen auf OOMs prüfen. Bei Engpässen fp8 oder geringeren Overlap versuchen.
LoRAs deaktivieren, dann einzeln wieder aktivieren. Wenn sich etwas falsch verhält, ein Retrain planen statt Gewichte zu hacken.
Alle negativen Prompt-Templates aktualisieren. Kürzen, wenn die Ergebnisse sauberer aussehen: kein unnötiges Gepäck mitschleppen.

Verwaltete API

Die Modellversion während des Testens explizit festsetzen.
Das Preset mit abgesenktem CFG und weniger Schritten neu erstellen, dann Output/Latenz vergleichen.
Seed-Handling (Bit-Breite, Typen) in der Dokumentation bestätigen.
Safety-Flags und Content-Filter prüfen: Schwellenwerte müssen möglicherweise angepasst werden.
Einen kleinen Batch nebeneinander ausführen (2.0 vs. 2.3) und einen Menschen die Gewinner für den eigenen Anwendungsfall auswählen lassen. Hier den Augen mehr vertrauen als Metriken.

Wenn die meisten Punkte nach einem Tag leichter Tests grün bleiben, führe ich das Upgrade durch. Wenn zwei oder mehr Klebeband brauchen, warte ich.

FAQ

Funktionieren LTX-2-LoRAs auf LTX-2.3 ohne Retraining?

In meinen Tests nicht zuverlässig. Das Basismodell ändert sich genug, dass Stile driften oder kollabieren. Mit sehr sanften Gewichten sind akzeptable Ergebnisse möglich, aber es ist fragil. 2.3 als neue Basis behandeln und einen frischen LoRA-Durchlauf einplanen.

Können LTX-2- und LTX-2.3-Checkpoints im selben ComfyUI-Setup koexistieren?

Ja. In separaten Ordnern halten, die Checkpoint-Loader-Node-Pfade aktualisieren und die Presets mit Versionsnamen versehen. Ich taggiere Ausgaben auch mit dem Modell im Dateinamen, damit alte Bilder nicht vermischt werden. Unspektakulär, aber es erspart einem die Zukunft.

Ich schließe mit einer kleinen Anmerkung: Das erste 2.3-Bild, das mich innehalten ließ, war ein simpler Produkt-im-Regal-Shot. Die Regallinien waren endlich gerade. Nicht dramatisch – einfach eine Sache weniger, die später behoben werden muss. So fühlen sich gute Upgrades meistens an.