Tracker für offene Gewichte · 10.08.2026
Flux 3 Dev: Die offenen Gewichte sind nicht veröffentlicht.
Es gibt heute keinen offiziellen FLUX 3 Dev-Checkpoint zum Herunterladen. Hier steht, was dieses Fehlen bedeutet, welche Belege zählen und was Entwickler ohne Raten vorbereiten können.
Was „Dev“ üblicherweise bedeutet — und was nicht bestätigt ist
Wer nach Flux 3 Dev sucht, sucht in der Regel ein herunterladbares oder entwicklerorientiertes Modell, das sich prüfen, feinabstimmen, lokal betreiben oder auf eigener Infrastruktur ausrollen lässt. Diese Erwartung speist sich aus früheren Namensmustern, ersetzt aber keine FLUX 3 Modellkarte. Black Forest Labs hat für ein FLUX 3 Dev-Release weder Checkpoint noch Parameterzahl, Architekturdetails, Lizenz, Genauigkeit, Speicherbedarf oder Referenz-Inferenzcode veröffentlicht.
Diese Unbekannten sollten in technischer Dokumentation unbekannt bleiben. Es ist verlockend, sie aus älteren Modellfamilien zu füllen, doch eine neue multimodale Familie kann Architektur, Tokenizer, latente Repräsentation, Konditionierung oder Verteilungsstrategie ändern. Selbst wenn eine geratene Zahl später zufällig passt, erzeugt es unnötiges Migrationsrisiko, vor der Veröffentlichung dagegen zu bauen.
Der genaue öffentliche Stand ist: Es ist kein Dev-Artefakt gelistet. Das heißt nicht abgesagt, verschoben oder für einen bestimmten Monat zugesagt. Es heißt, dass derzeit kein offizielles Paket einen Betrieb ermöglicht.
Gehosteter Zugang ist nicht dasselbe wie offene Gewichte
FLUX 3 Video wurde am 4. August 2026 über eine produktive API allgemein verfügbar. Gehosteter Zugang erlaubt einem Entwickler, Anfragen zu senden, während der Anbieter das Modell betreibt. Er liefert keine Checkpoint-Dateien, keine Trainingsdetails, keine Lizenz für offene Gewichte und keine Möglichkeit, Inferenz auf eigener Hardware auszuführen.
Ebenso wäre eine künftige FLUX 3 Image-API nicht automatisch ein Dev-Release. Der Status-Tracker führt API-Zugang für Image und offene Dev-Gewichte als getrennte Zeilen, weil sie verschiedene Fragen beantworten. Ein Produktteam braucht vielleicht einen gehosteten Endpunkt für die schnelle Integration; ein Forschungs- oder Infrastrukturteam braucht Gewichte für Kontrolle über Betrieb, Latenz, Datenschutz, Anpassung oder Stückkosten.
Achten Sie beim Lesen von Ankündigungen auf ausdrückliche Formulierungen wie herunterladbare Gewichte, ein Repository im Besitz des Anbieters, eine Lizenzdatei, eine Modellkarte, Prüfsummen und funktionierende Inferenzbeispiele. Eine Demo, eine Warteliste, eine API-Dokumentationsseite oder ein Wrapper eines Dritten erfüllt diesen Maßstab nicht.
Was ein vollständiges Release beantworten sollte
Ein nutzbares Paket mit offenen Gewichten beginnt bei der Identität: genauer Modellname, Version, Herausgeber und unveränderliche Dateien. Es braucht eine Lizenz, die die erlaubte kommerzielle Nutzung, Änderung, Weiterverbreitung, Nutzung in gehosteten Diensten und eingeschränkte Anwendungen benennt. Eine Modellkarte sollte vorgesehene Aufgaben, bekannte Grenzen, Sicherheitsüberlegungen, Angaben zu Training oder Daten, soweit verfügbar, und Evaluationsergebnisse beschreiben.
Entwickler brauchen außerdem einen Inferenzvertrag. Dazu gehören unterstützte Framework-Versionen, Anforderungen an Tokenizer und Text-Encoder, Bild- oder Video-Autoencoder, Standardwerte für Scheduler oder Sampling, akzeptierte Maße, Genauigkeit und die erwartete Ausgabe. Die Hardwareangaben sollten den Speicherbedarf bei repräsentativen Auflösungen benennen und angeben, ob Quantisierung oder Auslagerung unterstützt werden.
Bei einer multimodalen Familie sollte das Release klarstellen, ob ein Checkpoint mehrere Ausgabearten bedient oder ob Dev eine bestimmte Modalität bezeichnet. Einen Video-Checkpoint als Bild-Checkpoint zu behandeln — oder umgekehrt — führt zur falschen Serving-Architektur.
Infrastruktur ohne erfundenen Checkpoint vorbereiten
Sie können die modellunabhängigen Teile vorbereiten. Definieren Sie eine Anbieterschnittstelle rund um Prompt, Seitenverhältnis, optionale Eingabemedien, Modellschlüssel und zurückgegebene Daten. Halten Sie Modellfähigkeiten in einem Register, statt sie in Routenbedingungen zu kodieren. Entwerfen Sie Auftragsstatus, Idempotenz, Abrechnung, Speicherung, Abbruch und Beobachtbarkeit um Arbeitseinheiten herum, die eine HTTP-Anfrage überdauern können.
Erstellen Sie für Self-Hosting-Experimente ein Betriebsblatt statt eines Container-Images für ein erdachtes Modell. Halten Sie Zielhardware, akzeptable Wartezeit, Nebenläufigkeit, Ausgabegröße, Speicherstrategie, Beobachtbarkeit und Kostenobergrenze fest. Wenn die offiziellen Anforderungen kommen, macht das Betriebsblatt die Machbarkeitsentscheidung schneller.
Bereiten Sie ein kleines Bewertungsset aus echten Aufgaben vor: räumliche Prompts, Typografie, wiederholte Objekte, schwierige Materialien, Porträts, Architekturgeometrie und referenzgeführte Bearbeitungen. Halten Sie erwartete Vorgaben und Fehlerkriterien fest. Dieses Set sagt Ihnen mehr als Schaubilder aus der Community, sobald ein Checkpoint endlich verfügbar ist.
Wie sich das Release überprüfen lässt
Beginnen Sie bei der offiziellen Organisation und Dokumentation des Herausgebers. Bestätigen Sie, dass das Repository Black Forest Labs gehört, das Modell ausdrücklich FLUX 3 heißt und Dateien verfügbar sind statt hinter einer Ankündigung zu stehen. Lesen Sie die Lizenz, bevor Sie große Artefakte herunterladen oder einen kommerziellen Betrieb planen.
Prüfen Sie, ob Modellkarte und Inferenzbeispiel bei den benötigten Komponenten übereinstimmen. Verifizieren Sie Dateigrößen und Hashes, soweit veröffentlicht. Führen Sie den Referenzweg aus, bevor Sie Quantisierungen oder Wrapper Dritter einführen; sonst lässt sich ein Modellproblem kaum von einem Konvertierungsproblem der Community trennen. Behandeln Sie nicht verifizierte Spiegel mit Vorsicht.
Ein legitimes Release kann trotzdem an Zugangsbedingungen gebunden sein. Zugangsbeschränkte Gewichte sind in einem Sinn veröffentlicht, aber nicht allgemein zugänglich; diese Seite wird diesen Zustand genau benennen, falls er eintritt. Preview-Zugang, Bedingungen nur für Forschung und kommerziell nutzbare offene Gewichte sind unterschiedliche Betriebszustände.
API, offene Gewichte oder beides?
Eine gehostete API minimiert den anfänglichen Betriebsaufwand. Sie ist angebracht, wenn ein Team schnellen Zugang, elastische Kapazität, verwaltete Updates und einen klaren Preis pro Ausgabe schätzt. Sie erzeugt auch Anbieterabhängigkeit, externe Verarbeitung und nutzungsabhängige Margen. Offene Gewichte bieten mehr Kontrolle über Datenfluss, Version, Latenz und Optimierung, verlangen aber Hardware, Inferenz-Engineering, Monitoring, Sicherheit und Kapazitätsplanung.
Die beste Antwort kann hybrid sein. Ein Produkt kann über einen gehosteten Endpunkt starten, echte Lastdaten sammeln und später Self-Hosting bewerten, sobald ein lizenzierter Checkpoint verfügbar ist. Ein anbieterneutrales Register macht diesen Übergang möglich, ohne Infrastrukturentscheidungen an Endnutzer durchzureichen.
Heute gibt es kein FLUX 3 Dev-Artefakt, auf dem sich die Self-Hosting-Rechnung aufbauen ließe. Nutzen Sie veröffentlichte Forschungsmodelle für Infrastrukturexperimente, kennzeichnen Sie Annahmen als solche und prüfen Sie die Entscheidung erneut, sobald verifizierte Dateien und Bedingungen vorliegen.
Was dieser Tracker aktualisieren wird
Sobald Black Forest Labs offizielle Gewichte veröffentlicht, hält diese Seite Datum, Zugangsstatus, Repository, Lizenzkategorie, Modalität, wesentliche Hardwareangaben und den Referenz-Inferenzweg fest. Sie wird keine spekulativen Parameterzahlen aus Social-Posts übernehmen und aus dem Wort „offen“ keine kommerzielle Erlaubnis ableiten.
Die Vergleichsseite ergänzt dann bestätigte technische Parameter, und die API-Seite bleibt davon getrennt, sofern sich der gehostete Zugang nicht ebenfalls ändert. So aktualisiert eine einzelne Ankündigung nicht fälschlich jeden Produktstatus.
Bis dahin ist Vorbereitung die nützliche Entwicklerarbeit: Anbieter kapseln, Bewertungs-Prompts aufbewahren, Infrastrukturvorgaben festlegen und auf das Artefakt warten, das aus dem Namen FLUX 3 Dev etwas Betreibbares macht.