White-Hat KI Anwendung

Model Training TTP-LoRA. modula-r.com 2025/V01

Trusted Training Protocol (TTP) – Grundstruktur. Wir bleiben transparent und stellen unsere Trainingsarbeiten für LoRA´s und deren Eigenschaften einmal vor.🛡️

(Gezeigtes Bild ist KI-generiert – keine realen Vorlagen)

Vorwort:

Unsere Trainingsdaten, die eingesetzten Parameter, Workflows, Loss-werte und finalen Layer/Layer-weights können Sie gemäß EU AI-Act gerne jederzeit anfragen und detailierte Auskunft darüber erhalten. Auch ein Abgleich aus trainiertem Modell (safetensors-Datei) und den trainierten Weights geben wir gerne an zertifizierte Prüfstellen/Auditoren aus.

Anfrage Trainingsdaten/Transparenznachweis gemäß EU AI-Act Artikel-50 u 53

Mehr Informationen

1. Zielsetzung und Anwendungsrahmen

1.1 Motivation
1.2 Einsatzgebiete
1.3 Abgrenzung: Promptsteuerung vs. Stil-Transfer

2. Datensatzentwicklung

2.1 Prompt-Validierung durch Probegenerierung
2.2 Bildauswahl: Auflösung, Licht, Konsistenz
2.3 Caption-Design mit semantischer Tiefe
2.4 Metadaten, Hashing und Versionssicherung

3. Trainingsarchitektur

3.1 LoRA-Grundprinzip: additive Modularchitektur
3.2 Parameterwahl: `network_dim`, `network_alpha`, LR, Dropout
3.3 SD-spezifische Besonderheiten
3.4 Batchstruktur, Augmentation, Epochenplanung

4. Durchführung des Trainings

4.1 Setup in ComfyUI
4.2 Trainingseinheiten blockweise
4.3 Logging und Loss-Analyse
4.4 Fehlerquellen und Korrektur

5. Evaluation und Integration

5.1 Wirkung des LoRA-Tokens im Promptkontext
5.2 Tests bei `scale 0.3 / 0.6 / 1.0`
5.3 Mischprompt- und Kompatibilitätstests
5.4 Inferenzumgebung definieren

6. Technische Grundlagen: Weighting & Overlay

6.1 LoRA-Injektion: UNet/TextEncoder
6.2 Wirkformel `(α / dim) · A·B`
6.3 Layer-Scoping, scale vs. merge
6.4 Promptside-Effekte und Artefakte

7. Prüfprotokoll und Auditstruktur

7.1 Trainingshashes, Captions und Parameter-Log
7.2 DSGVO-/AI-Act-relevante Dokumentation
7.3 Validierbarkeit und Reproduktion
7.4 Optional: Metawatermarking & Fingerprints

1. Zielsetzung und Anwendungsrahmen

1.1 Motivation

Dieses Dokument beschreibt ein kontrolliertes und prüfbares Trainingsprotokoll für Low-Rank-Adaptation-Modelle (LoRA) im Kontext stabiler Diffusionsmodelle. Ziel ist es, transparente, auditkonforme und reproduzierbare Trainingsprozesse zu definieren, die sich sowohl für den produktiven Einsatz als auch für regulatorische Prüfungen eignen. Das Trusted Training Protocol (TTP) richtet sich an Entwickler:innen, Prüfer:innen und technisch versierte Anwender:innen, die LoRAs nicht als bloßes Tool zur Stilveränderung verstehen, sondern als modulare, steuerbare Komponenten innerhalb eines KI-Modellökosystems.

1.2 Einsatzgebiete

Entwicklung kontrollierter Prompt-Erweiterungen für produktive Bildgenerierung
Testbare visuelle Module in ComfyUI-Workflows
Lokale, isolierte KI-Anwendungen mit transparenter Datenbasis
Vorbereitung auf regulatorische Anforderungen (AI Act, ISO27001, DSGVO)
Interne Schulungs- und Testsysteme zur Evaluation von KI-Komponenten

1.3 Abgrenzung: Promptsteuerung vs. Stil-Transfer

Während viele LoRA-Modelle vorwiegend für visuelle Stil-Modifikation (z. B. Realismus, Kunstfilter, Vintage-Design) eingesetzt werden, fokussiert dieses Protokoll auf:

semantisch steuerbare Promptreaktionen
gezielte Bildkomposition, Objektstruktur, Ausdruck und Umgebung
kontrollierte Generalisierung durch sorgfältig definierte Trainingsdaten

Stilistische Veränderungen sind hier **Mittel zum Zweck**, nicht Selbstzweck.

2. Datensatzentwicklung

Ein LoRA ist nur so gut wie seine Trainingsdaten. Ziel der Datensatzentwicklung im Trusted Training Protocol ist es, eine strukturierte, auditierbare und semantisch klar definierte Bildbasis zu schaffen, die der späteren Zielsetzung des LoRA exakt entspricht. Der Datensatz muss nachvollziehbar erzeugt, dokumentiert und vor allem kontrolliert variabel sein.

2.1 Prompt-Validierung durch Probegenerierung

Bevor ein Trainingsdatensatz erzeugt wird, erfolgt eine gezielte Prompt-Testphase:

Ziel: Sicherstellung, dass das Konzept **generierbar, trennbar und visuell konstant** umsetzbar ist.
Dabei werden erste Bildchargen mit dem geplanten Prompt erzeugt (z. B. in ComfyUI), um:
visuelle Klarheit zu bewerten,
Störartefakte oder Promptkollisionen zu erkennen,
und die Eignung des Promptdesigns zu beurteilen.

**Beispiel:**

Ein Prompt wie:

`A group of professionals in a university lecture hall, holding papers, documentary lighting`

muss konsistente, trennbare Bildwelten erzeugen, in denen die Ziel-Token später semantisch angelernt werden können.

2.2 Bildauswahl: Auflösung, Licht, Konsistenz

Die finale Bildauswahl erfolgt unter klaren Regeln:

**Format:** 1024×1024 px (SD-Standard)
**Fokus:** gleichbleibender Aufbau (Kamerawinkel, Licht, Komposition)
**Stilistik:** neutral dokumentarisch (z. B. kein künstlicher Filter oder Fantasieelemente)
**Diversität:** inhaltlich gewünscht (Personen, Alter, Szenen), visuell begrenzt (um Überfitting zu vermeiden)

Alle Bilder stammen idealerweise aus einem einheitlichen Promptfluss, mit ggf. leicht variierter Seed-Steuerung.

2.3 Caption-Design mit semantischer Tiefe

Jedes Trainingsbild wird von einer `.txt`-Datei begleitet. Sie enthält den vollständigen Prompt (z. B. wie ursprünglich in ComfyUI verwendet).

**Vollständiger Prompt**, inklusive aller Subdetails (z. B. Licht, Komposition, Objektkontext)
**Einheitlich strukturiert**, d. h. keine zufällige Wortreihenfolge
**Optional auditfähig**: mit festem Schema wie `token, intent, object, style, modifiers`
**Keine Platzhalter-Tokens (außer `` bewusst verwendet wird)**

⚠️ Wichtiger Hinweis: Auch wenn alle Captions gleich sind, ist deren Vorhandensein **verpflichtend** – und Grundlage für auditierbares Verhalten.

2.4 Metadaten, Hashing und Versionssicherung

Jede Bilddatei sowie die zugehörige `.txt` werden zur Nachvollziehbarkeit dokumentiert:

SHA256-Hash über jede Datei
Speicherung in einer `dataset_meta.json` inklusive:
Dateiname
Bildauflösung
Hashwert
Optionale Speicherung von:
generierendem Prompt
Seed
Originalzeitpunkt
Trainingsziel (intended concept)
zugehöriger Caption-Datei

Diese Maßnahmen ermöglichen eine **vollständige Rückverfolgbarkeit** der Trainingsdaten – unabhängig von LoRA-Version oder ComfyUI-Status.

3. Trainingsarchitektur

Die Trainingsarchitektur bildet das technische Fundament für die spätere Wirkung des LoRA-Moduls. Sie entscheidet über Tiefe, Präzision, Generalisierung und Steuerbarkeit. Für ein kontrolliertes und auditierbares Training müssen alle architekturrelevanten Parameter dokumentiert, begründet und im Vorfeld abgestimmt werden.

3.1 LoRA-Grundprinzip: additive Modularchitektur

LoRA basiert auf dem Konzept der Low-Rank-Approximation/(Adaptation):
Anstatt ein großes Modell vollständig neu zu trainieren, wird eine Zusatzstruktur eingebettet:

`W_base`: Gewicht des Originalmodells
`A · B`: Produkt zweier kleiner, trainierter Matrizen
`dim`: Rank (Kapazität des LoRA-Moduls)
`α`: Skalar, um die Wirksamkeit des Patches zu regulieren

Diese Struktur erlaubt:
schnelle Trainingsläufe
kleine Speichergrößen (z. B. 5–100 MB pro `.safetensors`)
gezielte Wirkung auf bestimmte Teile des Modells (z. B. nur UNet)

3.2 Parameterwahl: `network_dim`, `network_alpha`, LR, Dropout

"network_dim"

Bestimmt die Kapazität der LoRA-Schichten (Rank).

Je höher der Wert, desto komplexere Beziehungen können gelernt werden.

Typische Werte & Bedeutung
4–16 Stil oder einfache Texturveränderung
32–64 Moderate Konzepte, einfache Objekte
128–192 Komplexe semantische Konzepte (z. B. Berufssituationen)
256+ Nur bei sehr großen Variationen nötig

Empfehlung für kontrollierte Prompt-LoRAs: `dim = 128`

"network_alpha"
Reguliert die Stärke der LoRA-Wirkung.
Bei `α = dim` wirkt das LoRA-Modul voll.
Bei `α < dim` wird die Wirkung gedämpft.

Gute Kontrolle bei: `alpha = 32` (25 % Einfluss)
Voller Effekt: `alpha = dim` (100 %)

Empfehlung für kontrollierte Prompt-LoRAs: `dim = 128`

**Formel:**

`LoRA_patch = (α / dim) * A·B`

**Empfehlung:**

`dim = 128`, `alpha = 32` ergibt stabile, skalierbare Wirkung ohne Overfitting

### `learning_rate`

Klassisch: `1e-4` (für LoRA ausreichend)

Feinabstimmung für lange Trainings: `7e-5`, `5e-5`

### `caption_dropout_rate`

Nur sinnvoll, wenn Captions variieren

Empfehlung bei festen Captions: `0.0`

### `optimizer_type`

AdamW oder Lion

Bei kleinen Datensätzen oft keine spürbaren Unterschiede

Empfehlung: **AdamW**

3.3 SDXL-spezifische Besonderheiten

**VAE**: Immer explizit setzen – SD(arch) verwendet intern ein `vae_fp16_decoder`
**UNet Only Training**: Textencoder-Modifikationen nur bei tokenzentrierten LoRAs nötig
**1024×1024** als Pflichtauflösung für optimale Repräsentation

3.4 Batchstruktur, Augmentation, Epochenplanung

Batchgröße

Geringe Werte bei SDXL (meist `1–2`, wegen hohem VRAM-Bedarf)
Achtung bei `Batch Size > 2`: Kann GPU-VRAM überlasten

Augmentation

Im Trusted Training Protocol standardmäßig **nicht erlaubt**
Ausnahme: bewusste Variation mit klarer Dokumentation (z. B. Flip = true, weil Ziel generalisiert werden soll)

Trainingsstrategie

Blockweise in `n` Steps (z. B. 800–1000 Steps je Block)
Zwischenspeicherung von Snapshots
Optional: Wechsel von `alpha` / `dim` in Blöcken bei fortgeschrittenem Training

Optional: Layer-Scoping (z. B. nur `mid_block` oder `up_block`)
Feine Steuerung über Trainingstiefe – nicht zwingend notwendig, aber prüfbar über `target_modules`

4. Durchführung des Trainings

Die Durchführung des Trainings erfolgt unter kontrollierten Bedingungen – vollständig lokal, nachvollziehbar, dokumentierbar. Im Trusted Training Protocol wird ausschließlich mit manuell kuratierten Daten gearbeitet. Drittanbieter-Plattformen oder cloudbasierte Trainer sind ausgeschlossen.
Trainiert wird bevorzugt in **ComfyUI**, da es eine modulare, visuelle und auditierbare Umgebung bietet, in der alle Parameter kontrolliert und geloggt werden können.

4.1 Setup in ComfyUI

Voraussetzungen:

Stable Diffusion Base Model (`qwen-Image 2025`)
Passendes VAE (empfohlen: `vae_qwen_fp16_decoder.safetensors`)
LoRA-Training-Modul (z. B. `Qwen-Image Trainer` )
Arbeitsverzeichnis mit:
`1024x1024`-Bildern
`.txt`-Captions (eine pro Bild)
Optional: `dataset_meta.json` zur Validierung

Workflow-Elemente:

`ImageDatasetLoader` oder Äquivalent
`LoRA_Trainer` Node mit parametergesteuertem Setup
Automatische Speicherpunkte (`Save LoRA Weights`, Snapshot)
Optional: `Loss Plotter` oder Logger zur Echtzeitüberwachung

**Beispiel:**

`network_dim = 128`
`network_alpha = 32`
`learning_rate = 1e-4`
`caption_dropout = 0.0`
`batch_size = 1`
`steps = 800 per block`

4.2 Trainingseinheiten blockweise

Statt eines langen, monolithischen Laufs empfiehlt das Protokoll **blockweises Training** in Etappen von 800–1000 Steps.

Vorteile:

Zwischenanalysen möglich
Snapshot-Analyse erlaubt Vergleich der Wirksamkeit nach Blöcken
LoRA kann schrittweise verbessert werden

Ablauf:

1. Block starten (z. B. `850 Steps`)
2. `loss.json` speichern oder anzeigen
3. `.safetensors` Snapshot speichern
4. Neue Blockrunde mit ggf. veränderten Parametern (z. B. `lower learning rate`)

4.3 Logging und Loss-Analyse

Während des Trainings soll der `loss`-Verlauf dokumentiert werden. Typische Schwankungen sind bei LoRA-Trainings normal, wichtig ist jedoch:

Parameter & Zielbereich
Initial-Loss `0.2–0.4`
Stabiler Loss `0.08–0.15`
Spikes `≤ 1.5` tolerierbar, aber prüfen
Drop-off (Overfit) sichtbar bei `loss < 0.06` + visuelle Artefakte
256+ Nur bei sehr großen Variationen nötig

Optional:

Moving Average berechnen
Spikes markieren (Schwellenwert > 0.3 Differenz in 10 Steps)

4.4 Fehlerquellen und Korrektur

Symptom Ursache / Lösung
`loss bleibt hoch > 0.3` Caption passt nicht zum Bild / Prompteffekt nicht erkannt |
`loss springt stark` Bilder zu unterschiedlich / Seed-Drift
`loss sinkt unter 0.05` Overfitting → LR senken oder `alpha` senken
`.safetensors` nicht erstellt Pfadfehler / kein Output-Node gesetzt
`num_train_epochs` Fehler falscher Trainernode (nicht `FluxTrainer`)

Empfehlung:

Nach jedem Block 2–3 Prompts mit `scale = 1.0 / 0.6 / 0.3` testen
Promptwirkung bewerten und ggf. Block 2 mit angepasst `alpha` nachtrainieren

5. Evaluation und Integration

Nach dem Training beginnt die eigentliche Bewertung des LoRA-Moduls. Ein valides LoRA ist nicht nur klein und funktionsfähig, sondern verhält sich kontrollierbar, integriert sich ohne Artefakte in bestehende Workflows und lässt sich semantisch sauber per Prompt beeinflussen.
Die Evaluation ist ein entscheidender Schritt, um die Praxistauglichkeit und Auditierbarkeit der Trainingsleistung zu bestätigen.

5.1 Wirkung des LoRA-Tokens im Promptkontext

Das LoRA-Modul sollte über ein spezifisches Token oder durch semantische Kombination eindeutig aktiviert werden können.

Wird die Wirkung im Bild sichtbar und interpretierbar?
Hat das Token alleinstehend eine Wirkung (`<s:your_token>`)?
Reagiert das Modell nur im passenden Promptkontext?

Beispielprompt:

A photo of a <s:your_token>, holding a paper in a lecture hall, DSLR photo

5.2 Tests bei scale 0.3 / 0.6 / 1.0

Die Effektstärke eines LoRA-Moduls wird in der Praxis über den scale-Faktor gesteuert. Die Tests erfolgen in definierten Stufen:

0.3: Leichte visuelle Tönung, kaum Detailveränderung
0.6: Deutlicher Einfluss, Hauptmerkmale sichtbar
1.0: Maximale Wirkung des LoRA-Moduls

Teststrategie:

Gleicher Prompt, unterschiedliche scale-Werte
Bilder nebeneinander vergleichen
Optional: Featurevergleich mit clip_interrogator

5.3 Mischprompt- und Kompatibilitätstests

Ziel ist es, die Verträglichkeit des LoRA mit anderen Komponenten sicherzustellen:

Kombination mit Stil-LoRAs (z. B. <s:watercolor_style>)
Integration in komplexe Prompts (Szene, Emotion, Licht)
Störverhaltenstest bei fremden Prompts

Prüfkriterien:

Wird das LoRA korrekt nur bei Aktivierung wirksam?
Bleibt die Wirkung trennbar von anderen Tokens?
Entstehen keine ungewollten Artefakte bei Mischprompts?

5.4 Inferenzumgebung definieren

Für die produktive Nutzung ist eine stabile und nachvollziehbare Umgebung Pflicht:

Fixiertes VAE (gleich wie im Training)
Standard-Sampler dokumentieren (z. B. euler simple)
Prompt-Vorlage als Referenz speichern
Standard-Scale z. B. 0.6 als Richtwert festlegen
Optional: Metadaten-Wasserzeichen und LoRA-Logging integrieren

5.5 Schlussbewertung

Ein kontrolliertes LoRA erfüllt folgende Bedingungen:

Promptsteuerung eindeutig – Token wirkt zuverlässig
Bildverhalten kontrollierbar – keine ungewollten Einflüsse
Kombinierbarkeit – kein Überschreiben anderer LoRAs
Reproduzierbarkeit – gleiches Setup ergibt gleiches Ergebnis

6. Technische Grundlagen(Basic allg.) – Weighting & Overlay

Low-Rank Adaptation (LoRA) ist mehr als ein Add-on. Es ist eine präzise Modulation bestehender Netzwerkschichten – kontrolliert, nachvollziehbar und mathematisch begründet.
Dieses Kapitel erklärt, wie ein LoRA-Modul tatsächlich wirkt, wie `dim`, `alpha` und `scale` zusammenspielen, und warum ein gutes LoRA „linear steuerbar“ statt binär ist.

6.1 LoRA-Injektion: UNet / TextEncoder

Beim Training eines LoRA werden gezielt gewichtete Schichten im Basismodell verändert. Je nach Setup wirkt das LoRA auf den UNet, den TextEncoder oder beide.

Bestandteile eines LoRA:

Zwei Gewichtsmatrizen A und B
Optionaler alpha-Faktor (Skalierung der Wirkung)
Zielmodul im Modell (z. B. attn1.to_q)

6.2 Wirkformel: Einfluss von alpha und dim

Die kombinierte Wirkung eines LoRA ergibt sich aus folgender Formel:

LoRA_Patch = (α / dim) * (A · B)

Erklärung:

dim: Kapazität der internen Matrizen (Größe des Patches)
α: Verstärkungsfaktor – regelt Stärke unabhängig von dim
A · B: Gelernter Low-Rank-Transformationskern

Beispiel:

dim = 128
alpha = 32 → Wirkung: 25 %

Wirkung in der Inferenz multipliziert sich zusätzlich mit dem scale-Wert:

Combined_Effect = (α / dim) × scale

6.3 Layer-Scoping: Partial Patching

LoRA-Module können gezielt nur auf bestimmte Modellbereiche wirken. Dadurch bleiben sie kompatibel und steuerbar.

Typische Layer-Ziele:

UNet: Visuelle Struktur, Auflösung, Bilddetails
TextEncoder: Promptwirkung, Stil, Ausdruck
up_blocks: Details und Feinstruktur
mid_block: Gesamtkomposition

Empfohlen im Trusted Training Protocol:

UNet-only, wenn keine neue Semantik gelernt werden soll

6.4 Promptsteuerung und Overlay-Verhalten

Die Aktivierung eines LoRA erfolgt in der Regel durch ein spezielles Prompttoken oder die semantische Nähe im Text.

Tokenbasiert: <s:your_token> aktiviert LoRA
Latentbasiert: LoRA wirkt subtil im Promptkontext mit
Overlay: Wirkung vermischt sich mit anderen Komponenten

Ziel eines Trusted-LoRA:

Skaliert sanft und linear
Ist promptkontrollierbar
Erzeugt keine Nebeneffekte bei scale = 0.0

6.5 Artefakte und Nebenwirkungen

Symptome, Ursachen und Maßnahmen bei LoRA-Fehlverhalten:

Symptom & Ursache
Verzerrungen Zu hoher alpha oder falsches Layer-Target
Überschreibt andere LoRAs Kein Scoping oder Layer-Kollision
Bleibt immer aktiv Patch im TextEncoder oder Promptresonanz

Empfohlene Werte:

dim = 128
alpha = 32
Nur UNet patchen, wenn keine Semantik verändert werden soll

7. Prüfprotokoll und Auditstruktur

Um ein LoRA-Modul als vertrauenswürdig und AI-Act-konform zu deklarieren, ist ein detailliertes Prüfprotokoll erforderlich. Dieses dient der Nachvollziehbarkeit, Reproduzierbarkeit und rechtlichen Absicherung.

7.1 Trainingshashes, Captions und Parameter-Log

Alle verwendeten Trainingsdaten und Parameter müssen eindeutig dokumentiert werden:

SHA256-Hashes aller Bild- und .txt-Dateien
Zentrale dataset_meta.json mit Dateinamen, Hashes, Captions und Auflösung
Parameterprotokoll z. B. train_config.json mit:
– network_dim, network_alpha, learning_rate
– batch_size, steps, seed
Version/Commit des verwendeten Trainers (z. B. ComfyUI oder FluxTrainer)

7.2 DSGVO-/AI-Act-relevante Dokumentation

Für LoRA-Trainings im regulierten Umfeld ist folgendes zwingend zu dokumentieren:

Rechtsgrundlage oder Einwilligung für Trainingsdaten
Nachweis, dass keine personenbezogenen Daten verwendet wurden
Trainingszweck dokumentiert (technisch, stilistisch, semantisch)
Optional: Einbindung von Metawasserzeichen oder Bild-Fingerprints

7.3 Validierbarkeit und Reproduktion

Jeder Trainingslauf muss vollständig überprüfbar und reproduzierbar sein:

Auditierbarer Hash für LoRA-Gewichtedatei (.safetensors)
Speicherung des Workflows inkl. aller verwendeten Nodes
Promptprüfung vor Trainingsbeginn durch z. B. PromptComplianceCheckerNode
Optional: LoRA-Signatur über Public-Key-Hash (prüfbar)

7.4 Metadaten, Fingerprints & Wasserzeichen

Für maximale Transparenz und Nachvollziehbarkeit können optionale Mechanismen eingesetzt werden:

Einbettung von LoRA-Identifikatoren (z. B. Token, Ersteller, SHA256) in Output-Bilder
Präzise Zeitstempel (datetime.isoformat()) im Trainingsprotokoll
Automatisiertes Logging durch Audit-Nodes während der Inferenz

7.5 Beispiel-Auditlog (JSON-Struktur)

{
						  "training_run": "qwen_lora_001",
						  "date": "2025-07-11T09:15:00Z",
						  "dataset": "dataset_meta.json",
						  "parameters": {
							"network_dim": 128,
							"network_alpha": 32,
							"learning_rate": 0.0001,
							"batch_size": 1,
							"steps": 850,
							"seed": 12345678
						  },
						  "hashes": {
							"dataset_images": "sha256_of_all_images_hashlist",
							"lora_weights": "sha256_of_safetensors_file"
						  },
						  "compliance": {
							"gdpr": true,
							"ai_act": true,
							"metawatermarking": true
						  }
						}

7.6 Zusammenfassung

Das Prüfprotokoll ist Herzstück des Trusted Training Protocols. Es dokumentiert:

Trainingsdaten und Parameter vollständig nachvollziehbar
Rechtliche Konformität zu DSGVO und AI Act
Inferenzprotokollierung und Metawasserzeichen möglich
Jeder Schritt ist validierbar, reproduzierbar und prüfbar

8. Anhang & Glossar

Dieser Abschnitt liefert wichtige Hintergrundbegriffe, technische Definitionen und verlinkbare Erklärungen für prüfende Stellen oder interessierte Nutzer. Ziel ist maximale Transparenz, Verständlichkeit und Fachklarheit.

8.1 Glossar technischer Begriffe

LoRA (Low-Rank Adaptation) – Trainingsmethode, bei der nur bestimmte Schichten eines großen Modells durch niedrigdimensionale Matrizen moduliert werden, um Speicher und Rechenzeit zu sparen.
network_dim – Dimension der internen Gewichte im LoRA-Modul. Höher = mehr Kapazität, aber auch höhere Modellgröße.
network_alpha – Gewichtungsfaktor zur Feinsteuerung des LoRA-Effekts, skaliert unabhängig von `dim` die Wirkung der Matrizen.
scale – Inferenzseitige Steuerung der LoRA-Wirkung (0.0–1.0), beeinflusst, wie stark das LoRA zur Generierung beiträgt.
UNet – Hauptbilddecoder von Stable Diffusion, verantwortlich für Bildkomposition, Auflösung und Details.
TextEncoder – Komponente, die Texteingaben in latente Repräsentationen umwandelt. Bei LoRAs kann hier die semantische Steuerung verändert werden.
VAE – Variational Autoencoder, wird verwendet zur Kodierung/Decodierung von Bilddaten in Latents und zurück.
Prompt – Texteingabe, die das generierte Bild steuert. Promptdesign ist zentral für reproduzierbare Ergebnisse.
Safetensors – Sichere, nicht manipulierbare Dateiform für Modellgewichte (Alternativformat zu .pt / .ckpt).

8.2 Abkürzungen

LoRA: Low-Rank Adaptation
qwen: Base Model Qwen-Image
VAE: Variational Autoencoder
DSGVO: Datenschutz-Grundverordnung
AI Act: EU-Verordnung zur Regulierung künstlicher Intelligenz

8.3 Referenzen & Quellen

8.4 Lizenzierung

Das Trusted Training Protocol steht unter einer offenen Lizenz (z. B. CC-BY-SA oder AGPL), sofern nicht anders vermerkt. Es darf weiterverwendet, angepasst und verbreitet werden, solange Herkunft und Autorenschaft genannt sind.

Hinweis: Die tatsächliche Lizenz wird im Titelblatt und Footer verbindlich definiert.

Autoren/Rechteinhaber dieser TTP:

Tim Schörger - Head of Concept/NNw-Eng. | .2025/V01

Anni Strauss – Fotokunst/Grafikdesign/Webdesign/AI-ART | .2025/V01

Aida – KI mit White‑Hat‑Seele und demokratischem Verständnis |.2025/V01

Tags to use

#AIAct2024-ready #TrustedWorkflow #SafePrompting #ComfyAudit #DSGVOkonform #EasyStart #WhiteHatOnly #SecureCreative #ModularAI #FastLearnEnvironment #UniqueUX #KIBremenSource

🛡️ Begriffserklärung: White‑Hat

„White‑Hat“ ist ein Begriff aus der IT‑ und Sicherheitswelt, der für ethisches, verantwortungsbewusstes Handeln steht. White‑Hat‑Entwickler, Forscher oder Hacker setzen ihr Wissen nicht ein, um Schwachstellen auszunutzen, sondern um sie zu erkennen, zu melden oder zu beheben – immer im Sinne des Schutzes von Nutzern, Systemen und Daten. Ziel ist dabei nicht Gewinnmaximierung durch Ausnutzung von Sicherheitslücken, sondern der Aufbau transparenter, sicherer und fairer digitaler Lösungen, die Vertrauen schaffen.