Wichtigste Erkenntnisse
- Kontextfenster-Realität: 128K Token auf dem Papier, 32K Token in der Praxis. Die Aufmerksamkeitsqualität der meisten lokalen Modelle nimmt nach 32.000 Token (~24.000 Wörter) merklich ab. Nicht das vollständige Manuskript in das Kontextfenster laden — stattdessen die Session-Dokument-Technik verwenden.
- Die Session-Dokument-Technik ist die Kernkompetenz. Eine komprimierte Textdatei pflegen: aktive Charakterbögen (150 Wörter pro Charakter), Kapitelzusammenfassungen (100–200 Wörter pro Kapitel) und das Setup der aktuellen Szene. Zu Beginn jeder Sitzung injizieren.
- Eine Szene pro Sitzung generieren. Das Modell eine Szene (200–600 Wörter) schreiben lassen, statt es zu bitten, ein wachsendes Dokument fortzusetzen. Eine Szene pro Sitzung eliminiert Kontextdrift und liefert konsistente Stimme.
- Beat-Sheet-First beim Drehbuchschreiben. Vor dem Generieren von Skriptseiten zunächst ein szenenweises Beat Sheet generieren. Das Beat Sheet als Gerüst für jede Seitengenerierung nutzen.
- Llama 3.3 70B ist das beste Modell für Langformarbeiten. Starke Kontextadhärenz, beste Instruktionsbefolgung bei längeren Generierungslängen und zuverlässige Charakterstimmkonsistenz.
- Ollama + ein Nur-Text-Schreibtool ist die zuverlässigste Integration. Scrivener, Obsidian und VS Code funktionieren als Manuskriptebene; Ollama stellt das Modell über eine API bereit.
- Uncensored Modelle (Hermes 3) fügen sich ohne Setup-Änderungen ein. Für reife Fiktion das Ollama-Modell auf Hermes 3 umstellen; Session-Dokument- und Szenengenerierungs-Techniken bleiben identisch.
Schnellfakten
- Bestes Modell für Langformfiktion: Llama 3.3 70B (stärkste Kontextadhärenz und Instruktionsbefolgung).
- Praktisches Kontextfensterlimit: ~32.000 Token (~24.000 Wörter) für zuverlässige Aufmerksamkeitsqualität; 128K ist die technische Obergrenze.
- Größe des Session-Dokuments: Ziel unter 4.000 Token (Charakterbögen + Kapitelzusammenfassungen + aktuelles Szenen-Setup).
- Szenengenerierungsziel: 200–600 Wörter pro Generierungsaufruf; längere Szenen über mehrere sequenzielle Prompts.
- Drehbuchformat: Ollama mit Fountain-Format-Ausgabeanweisungen kombinieren für Skript-formatierten Text.
- Schreibtools, die mit Ollama funktionieren: Scrivener (über API-Begleitskripte), Obsidian (über lokales Plugin oder Skripte), VS Code (über Continue.dev oder direkte API-Aufrufe), reines Terminal.
- Uncensored-Option: Hermes 3 Llama 3.3 für reife Fiktion; gleicher Workflow, gleiche Session-Dokument-Technik.
Das Kontextfensterproblem beim Langformschreiben
Das praktische Kontextlimit der meisten lokalen Modelle beträgt 32.000 Token — nicht die beworbenen 128K. Die Aufmerksamkeitsqualität nimmt bei den meisten Modellen nach 32.000 Token ab. Bei 128K Token verlieren viele Modelle die korrekte Referenz auf Inhalte aus dem ersten Viertel des Kontextfensters. Bei einem Roman bedeutet das: Der bisherige Entwurf kann nicht einfach eingefügt und nach dem nächsten Kapitel gefragt werden.
Kimi-K2.6 von Moonshot AI bietet ein echtes 1-Millionen-Token-Kontextfenster mit stärkerer Aufmerksamkeitsqualitätserhaltung. Kimi-K2.6 lokal auszuführen ist für die meisten Autoren unpraktisch — es erfordert etwa 480 GB VRAM bei Q4-Quantisierung. Für Autoren, die tatsächlich 1M Kontext benötigen, ist Moonshots gehostete API die praktische Zugangsmöglichkeit. Für lokal ausführbare Modelle (Llama 3.3 70B, Qwen3 32B, Mistral Large) ist die 32K-Praxisgrenze die relevante Einschränkung.
📍 In einem Satz
Die praktische Qualitätsgrenze für Kontextadhärenz bei den meisten lokalen LLMs liegt bei etwa 32.000 Token (~24.000 Wörter) — darüber hinaus verlieren Modelle die genaue Referenz auf früheren Inhalt, was zu Stimmungsdrift und Plotwidersprüchen führt.
💬 In einfachen Worten
Man kann einen 90.000-Wörter-Roman nicht in ein 128K-Kontextfenster laden und erwarten, dass das Modell sich daran erinnert, was in Kapitel 3 passiert ist, während es Kapitel 20 schreibt. Stattdessen: alles, was das Modell wissen muss — Charakterbögen, Kapitelzusammenfassungen, aktuelles Szenen-Setup — in ein Session-Dokument mit unter 4.000 Token komprimieren und dieses zu Beginn jeder Schreibsitzung injizieren.
- Token-zu-Wort-Umrechnung: 1 Token ≈ 0,75 Wörter auf Englisch. 32K Token ≈ 24.000 Wörter. 128K Token ≈ 96.000 Wörter (ein vollständiger Roman).
- Aufmerksamkeitsdegradation: Modelle verlieren die zuverlässige Referenz auf Inhalte aus dem frühen Teil eines langen Kontextfensters — Charakternamensfehler, vergessene Handlungspunkte und Stimmungsdrift.
- Die Asymmetrie: Modelle beachten den Anfang (System-Prompt) und das Ende des Kontextfensters am besten. Inhalte in der Mitte werden am wenigsten zuverlässig berücksichtigt.
- Session-Dokument als Lösung: Alles komprimieren, was das Modell benötigt. Zu Beginn injizieren. Szene generieren. Sitzung beenden. Zurücksetzen. Mit aktualisiertem Session-Dokument neu beginnen.
⚠️Warning: Nicht das vollständige Manuskript in den Kontext einfügen. Über 10.000 Wörter entsteht Kontextdrift — das Modell vergisst frühe Charakterdetails, widerspricht Handlungspunkten und kehrt zu einem generischen Register zurück. Stattdessen die Session-Dokument-Technik verwenden.
Session-Dokument-Technik
Die Session-Dokument-Technik in diesem Abschnitt wurde in Entwurfsarbeiten für mehrere Langformprojekte erprobt (ein literarischer Roman mit 90.000 Wörtern, zwei Drehbuchentwürfe). Die 4.000-Token-Größe, der szene-für-szene Generierungsrhythmus und der Zeitpunkt der Kontinuitätsprüfungen basieren auf beobachteten Fehlermustern.
Das Session-Dokument ist eine Nur-Text-Datei neben dem Manuskript — der komprimierte Zustand des Romans, den das Modell kennen muss. Es hat drei Abschnitte: aktive Charakterbögen, Kapitelzusammenfassungen und das aktuelle Szenen-Setup.
Session-Dokument-Vorlage
“# SESSION DOCUMENT — [NOVEL TITLE] ## ACTIVE CHARACTERS **[Character Name]** Dominant trait: [one trait] Contradicting behaviour: [one behaviour] Speech register: [formal/casual/specific verbal tics] Relationship to [other character]: [brief] **[Character Name 2]** [same structure] ## CHAPTER SUMMARIES (completed) Chapter 1: [100–150 words — what happened, what changed, where it ended] Chapter 2: [100–150 words] [continue for all completed chapters] ## CURRENT SCENE SETUP Chapter: [N] Scene: [brief description of what this scene needs to accomplish] POV: [character name] Opening state: [where we are at the start of this scene — 1 sentence] Emotional beat to land on: [what the POV character feels at the end — do not state it directly in the scene] Word ceiling: [200–500 words]”
- Charakterbögen — Ziel: 150 Wörter pro aktivem Charakter. Dominantes Merkmal, widersprüchliches Verhalten, Sprachregister und Schlüsselbeziehungen einbeziehen. Charaktere hinzufügen oder entfernen, wenn sie aktiv werden oder das Manuskript verlassen.
- Kapitelzusammenfassungen — Ziel: 100–150 Wörter pro abgeschlossenem Kapitel. Fokus auf: was passiert ist, was sich verändert hat, welche Informationen der Leser nun kennt, wo das Kapitel räumlich und emotional endete.
- Aktuelles Szenen-Setup — spezifisch und kurz. POV, Zweck der Szene, emotionalen Beat und Wörtergrenze angeben. Das ist die Aktion des Modells; Charakterbögen und Kapitelzusammenfassungen sind der Kontext.
- Größe des Session-Dokuments — Ziel: unter 4.000 Token (~3.000 Wörter). Ein Session-Dokument, das diesen Wert überschreitet, beansprucht Kontextraum für die Generierung. Aggressiv komprimieren.
- Nach jeder Sitzung aktualisieren. 1–2 Sätze zur Kapitelzusammenfassung hinzufügen und geänderte Charakterbogeneinträge aktualisieren. Das Session-Dokument ist eine lebendige Datei.
💡Tip: Das Session-Dokument in einer Nur-Text-Datei neben dem Manuskript aufbewahren. In Ollama kann ein Modelfile mit dem Session-Dokument im SYSTEM-Block erstellt und vor jeder Sitzung aktualisiert werden. In SillyTavern das Dokument zu Beginn jeder Romansitzung in das System-Prompt-Feld einfügen.
Roman-Drafting-Workflow
Der Roman-Drafting-Workflow mit einem lokalen LLM hat vier Phasen: Outline, Kapitel-Beat-Sheets, Szenengenerierung und Überarbeitungsdurchläufe. Jede Phase verwendet eine andere Prompt-Struktur.
- Phase 1 — Outline: Kapitelweises Outline generieren (10–30 Kapitel, ein Satz pro Kapitel: was passiert, was sich ändert). Prompt: „Genre: [Genre]. Protagonist: [Name + Kernwunde]. Zentraler Konflikt: [in einem Satz]. Schreibe ein 20-Kapitel-Outline — ein Satz pro Kapitel, jeder Satz benennt die Szene und die Änderung." Outline vor dem Fortfahren überprüfen und bearbeiten.
- Phase 2 — Beat Sheets: Jeden Kapiteleintrag in ein szenenweises Beat Sheet erweitern (3–8 Szenen pro Kapitel). Prompt: „Kapitel-[N]-Zusammenfassung: [Einzeiler einfügen]. Erweitern zu einem szenenweisen Beat Sheet: 4–6 Szenen, jede in einem Satz mit Ort, Beteiligten und der einzigen Änderung beschrieben. Noch keine Prosa."
- Phase 3 — Szenengenerierung: Session-Dokument + aktuellen Szenen-Beat verwenden, um eine Szene nach der anderen zu generieren. Generieren, überprüfen, in das Manuskript einfügen, Session-Dokument aktualisieren. Wiederholen.
- Phase 4 — Überarbeitungsdurchläufe: Nach Abschluss eines Kapitels gezielte Überarbeitungs-Prompts auf bestimmte Szenen anwenden. Siehe Lokale LLM-Prompts für Romanautoren für Überarbeitungs-Prompt-Strukturen. Nie mehr als eine Szene pro Generierungsaufruf überarbeiten.
💡Tip: Outline und Beat Sheets in separaten Dateien vom Manuskript aufbewahren. Sie sind das Skelett — das Manuskript ist das Fleisch. Getrennte Dateien ermöglichen die Regenerierung jedes Teils, ohne den anderen zu überschreiben.
Drehbuch-Workflow
Das Drehbuchschreiben mit einem lokalen LLM verwendet dieselben Session-Dokument- und Beat-Sheet-Techniken, mit zwei Ergänzungen: Formatanweisungen im System-Prompt und Szenenheader (Slug Lines) als separater Schritt von der Seitengenerierung.
Drehbuch-System-Prompt
“You are a screenplay formatting assistant. All prose you generate is formatted in standard US screenplay format: - Scene headers: INT./EXT. LOCATION — DAY/NIGHT - Action lines: present tense, concrete, maximum 3 lines per block - Character names: ALL CAPS above dialogue - Dialogue: centred, no dialogue tags - Parentheticals: sparingly, only for delivery or action mid-dialogue Generate in Fountain-compatible plain text.”
Szenen-Beat zu Skriptseiten-Prompt
“Beat: [paste the one-sentence scene beat from the beat sheet] POV character: [Name] Page target: [1–3 pages] Generate the script pages for this beat. Use standard screenplay format. Begin with the slug line. No narration — action lines and dialogue only.”
- Format im System-Prompt, nicht im User-Turn. Formatanweisungen in der Systemnachricht bedeuten, dass jede Generierung der Sitzung dem Format folgt, ohne die Anweisung zu wiederholen.
- Fountain-kompatibler Output: Fountain ist ein Nur-Text-Markup-Format für Drehbücher, das von Final Draft, Highland, WriterDuet und anderen Tools unterstützt wird. Output kann direkt in Drehbuchsoftware importiert werden.
- Slug Lines zuerst: Die Slug Line als separaten Einzeiler-Prompt generieren, bevor der Szeneninhalt generiert wird. Dies verankert den physischen Ort.
- Dialogdurchläufe: Nach Action Lines einen separaten Dialogdurchlauf: „Die Action Lines sind gesetzt. Schreibe den Dialog für [Charakter A] und [Charakter B]. Charakter A will [X]. Charakter B will [Y]. Keine Dialognachführer. 5–8 Austausche."
- Seitenanzahlverwaltung: Eine Standard-Drehbuchseite umfasst etwa 55–60 Wörter. Wörterobergrenzen kalibrieren: 1 Seite ≈ 60 Wörter, 2 Seiten ≈ 120 Wörter, 3 Seiten ≈ 180 Wörter.
💡Tip: Die Beat-Sheet-First-Disziplin ist beim Drehbuchschreiben wichtiger als beim Romandrafting. Seiten ohne Beat Sheet produzieren Szenen, die in Länge und strukturellem Zweck abdriften. Immer wissen, was eine Szene leisten soll, bevor die Seiten generiert werden.
Szenengenerierungs-Templates für Langformarbeiten
Die Langform-Szenengenerierung erfordert das Session-Dokument als Präfix und einen einzelnen Szenen-Prompt als Aktion. Die Templates setzen voraus, dass das Session-Dokument bereits in der Systemnachricht oder im ersten User-Turn vorhanden ist.
📍 In einem Satz
Das zuverlässigste Generierungsmuster für Langformfiktion: Session-Dokument im System-Prompt → einzelner Szenen-Prompt im User-Turn → überprüfen → Session-Dokument aktualisieren → wiederholen, eine Szene pro Sitzung.
💬 In einfachen Worten
Das Modell muss drei Dinge wissen: wer diese Charaktere sind (Charakterbögen), was bereits passiert ist (Kapitelzusammenfassungen) und was diese Szene leisten muss (Szenen-Setup). Genau diese drei Dinge angeben, nicht mehr. Szene generieren, in das Manuskript einfügen, Session-Dokument aktualisieren. Wiederholen.
Roman-Szenengenerierungs-Prompt
“[SESSION DOCUMENT ALREADY IN SYSTEM PROMPT] Current scene: Chapter: [N] Beat: [one sentence from the beat sheet] POV: [character name] Opening: [one sentence — where we are, who is present] Emotional landing: [what the POV character feels at the end — show, don't state] Word ceiling: [300–500 words] Write this scene. No summarising. Every sentence renders a moment.”
Kontinuitätsprüfungs-Prompt
“Before writing the next scene, check for continuity. The session document says: - [Character A] is [trait/state] - The last scene ended with [brief description] The next scene opens with [brief description]. Does this transition make sense? If not, what needs to change in the transition? One paragraph answer only.”
💡Tip: Den Kontinuitätsprüfungs-Prompt bei Kapitelübergängen verwenden — nicht bei jeder Szene. Kapitelübergänge (wo sich Ort, Zeit oder POV-Charakter ändern) sind die Stellen, an denen Kontinuitätsbrüche am häufigsten auftreten.
Tool-Integrationen für Autoren
Ollama stellt eine OpenAI-kompatible API auf localhost bereit, mit der eine wachsende Zahl von autorenseitigen Tools verbindet. Die folgenden Integrationen stellen die etabliertesten Optionen dar.
| Tool | Integration | Ideal für |
|---|---|---|
| Obsidian | Copilot-Plugin oder Smart Connections-Plugin → Ollama API. Siehe Obsidian + Lokale LLM-Plugins für den ausführlichen Leitfaden. | Autoren, die Obsidian bereits für Notizen + Manuskript verwenden; nahtlose Generierung in derselben App |
| Scrivener | Externes Skript über Ollama API → in Dokument einfügen | Autoren, die Romane in Scrivener strukturieren; KI-Entwürfe in bestehende Projektstruktur einfügen |
| VS Code | Continue.dev-Erweiterung → Ollama-Backend | Technische Autoren und Game-Narrative-Designer im Code-Editor |
| SillyTavern | OpenAI-kompatible API → Ollama | Roleplay-Fiktion und charakterkarten-gesteuertes Drafting; persistentes Charaktergedächtnis |
| Reines Terminal | `ollama run [model]` oder curl zur Ollama API | Skriptierbare Workflows; maximale Kontrolle mit minimalem UI-Overhead |
| LM Studio | Integrierte Chat-Benutzeroberfläche + lokale Server-API | Autoren, die einen GUI-Modellmanager ohne separaten Ollama-Install wünschen |
| NovelCrafter | Integrierte KI-Integration; unterstützt OpenAI-kompatible Endpunkte (auf Ollama zeigen) | Autoren, die kapitelebene KI-Unterstützung in einer einzigen roman-fokussierten App wünschen |
| Plottr | Manueller Workflow: Romane in Plottr strukturieren, Szenen/Beats extern in Ollama einfügen | Plot-intensive Genrefiktion (Krimi, Thriller, Fantasy) mit strukturellem Plotten als Workflow-Mittelpunkt |
💡Tip: Die einfachste Integration für die meisten Autoren: Obsidian + das Copilot-Plugin, das auf Ollama zeigt. Session-Dokument und Manuskriptkapitel im selben Vault, Generierung direkt in derselben App ohne Kontextwechsel. Siehe Obsidian + Lokale LLM-Plugins für den ausführlichen Leitfaden.
Modellempfehlungen für Langformarbeiten
Langform-Drafting hat andere Modellanforderungen als Kurzformfiktion. Kontextadhärenz, konsistente Instruktionsbefolgung und die Fähigkeit, die Stimme über mehrere Generierungsaufrufe beizubehalten, sind die entscheidenden Faktoren. Für das breitere Modellspektrum über alle Anwendungsfälle, siehe Beste lokale LLMs 2026.
| Aufgabe | Empfohlenes Modell | Warum |
|---|---|---|
| Roman-Drafting (primär) | Llama 3.3 70B | Beste Kontextadhärenz und Instruktionsbefolgung für sitzungsübergreifende Langformarbeiten; konsistenteste Stimme |
| Drehbuchschreiben | Llama 3.3 70B oder Mistral Large | Llama 3.3 für komplexe Charakterdynamiken; Mistral Large für konsistente Formatadhärenz im Fountain-Output |
| Beat Sheet / Outline-Generierung | Qwen3 32B | Starke strukturelle Generierung; folgt constraint-schweren Outline-Prompts zuverlässig |
| Dialogdurchläufe | Command R+ 104B | Bestes naturalistisches Sprachregister und Charakterstimmdifferenzierung über ausgedehnte Austausche |
| Überarbeitung (strukturell) | Llama 3.3 70B | Am besten darin, spezifische strukturelle Einschränkungen in Umschreibanweisungen zu befolgen |
| Reife / dunkle Fiktion | Hermes 3 Llama 3.3 70B | Gleiche Basis wie Llama 3.3 70B; uncensored Fine-Tune; identische Kontextadhärenz für Langformarbeiten |
Häufige Fehler
- Das vollständige Manuskript in den Kontext einfügen. Auch mit einem 128K-Kontextfenster nimmt die Aufmerksamkeitsqualität nach 32.000 Token deutlich ab. Die Session-Dokument-Technik verwenden.
- Das Modell bitten, ein offenes Dokument „fortzusetzen". „Setze den Roman fort" führt zu Drift. „Schreibe die nächste Szene: [spezifisches Setup, POV, Wörtergrenze]" produziert einen konsistenten, begrenzten Output.
- Keine Beat Sheets beim Drehbuchschreiben. Skriptseiten ohne einen Szenen-Beat produzieren Seiten, die in Länge und struktureller Funktion abdriften. Das Beat Sheet immer zuerst generieren.
- Session-Dokument-Aktualisierungen ignorieren. Ein veraltetes Session-Dokument produziert innerhalb weniger Sitzungen Inkonsistenzen.
- Mehr als eine Szene pro Sitzung generieren. Mehrere Szenen in einem Kontextfenster produzieren die erste gut und jede weitere mit geringerer Konsistenz. Eine Szene pro Sitzung; zurücksetzen und neu injizieren.
Quellen
- Llama 3.3 70B Langkontext-Benchmarks — Meta AI Research
- Qwen3 32B technischer Bericht inkl. Kontextfenster-Benchmarks — Alibaba Cloud / Qwen Team
- Lost in the Middle: How Language Models Use Long Contexts — Stanford NLP Research
- Fountain-Drehbuchformat-Spezifikation — Fountain.io
- Ollama API-Dokumentation — Ollama
Häufig gestellte Fragen
Kann ein lokales LLM einen vollständigen Roman schreiben?
Ein lokales LLM kann die Prosa für einen vollständigen Roman generieren — aber die strukturelle und redaktionelle Intelligenz muss vom Autor kommen. Das Modell generiert Szenen, wenn es mit spezifischen Setups aufgefordert wird; es plant, bewertet oder trifft thematische Entscheidungen nicht autonom. Autoren beschreiben es als „sehr schnellen Erstenhtwurf-Generator für Szenen, die ich bereits weiß, wie ich schreiben soll."
Was ist das maximale Kontextfenster, das ich zuverlässig verwenden kann?
In der Praxis bis zu etwa 32.000 Token (~24.000 Wörter) mit den meisten lokalen Modellen. Darüber verlieren Modelle genaue Referenzen auf frühe Kontextinhalte. Die Session-Dokument-Technik hält den Arbeitskontext unter 4.000–6.000 Token.
Wie verhindere ich, dass das Modell die Stimme meines Charakters ändert?
Stimmungsdrift hat zwei Ursachen: ein veraltetes Session-Dokument und Kontextverdünnung. Lösung: Charakterbogen in der Systemnachricht platzieren, nach bedeutsamen Szenen aktualisieren und kurz genug halten, um im obersten Abschnitt jedes Sitzungskontexts Platz zu finden.
Kann ich Scrivener mit einem lokalen LLM verwenden?
Nicht nativ — Scrivener hat kein Plugin-System für externe API-Aufrufe. Der gebräuchlichste Workflow: in Ollama generieren, Output kopieren, in das relevante Scrivener-Dokument einfügen. Manche Autoren verwenden Obsidian als KI-Drafting-Ebene und importieren abgeschlossene Kapitel zur finalen Strukturierung in Scrivener.
Was ist besser fürs Drehbuchschreiben: Ollama oder eine Cloud-KI?
Für reife Inhalte (Gewalt, dunkle Psychologie, moralisch komplexe Charaktere) ist lokales Ollama mit Llama 3.3 70B oder Hermes 3 zuverlässiger — Cloud-Modelle verweigern Inhalte, die in dramatischen Skripten häufig vorkommen. Für Formatkonsistenz liefern beide äquivalente Ergebnisse mit Formatanweisungen im System-Prompt.
Wie generiere ich Dialog, der wie ein bestimmter Charakter klingt?
Drei Schritte: (1) Sprachregister des Charakters zum Session-Dokument hinzufügen. (2) 3–5 Beispieldialogzeilen als Kalibrierungsschritt zu Sitzungsbeginn generieren. (3) Diese Beispiele im Dialog-Prompt verwenden: „Schreibe Dialog im selben Register wie diese Beispiele: [einfügen]."
Brauche ich eine GPU für ein lokales LLM beim Roman-Drafting?
Eine GPU beschleunigt erheblich, ist aber nicht zwingend erforderlich. Auf Apple Silicon (M3 oder später) kann selbst ein MacBook Pro 16 GB Qwen3 14B für Drafting-Arbeiten ausführen — langsamer als ein 24-GB-GPU-Rig, aber akzeptabel. Eine dedizierte NVIDIA GPU mit 24 GB VRAM führt 70B-Modelle mit nutzbaren Geschwindigkeiten aus.
Kann ich lokale LLMs mit Final Draft oder anderer professioneller Drehbuchsoftware verwenden?
Nicht direkt. Final Draft hat keine externe API-Integration. Workflow: Skriptseiten im Fountain-Nur-Text-Format über Ollama generieren, dann mit Final Drafts integriertem Importer importieren (Datei → Importieren → Fountain). Highland, WriterDuet und Fade In unterstützen Fountain-Import nativ.
Kann ich Kimi-K2.6 lokal für Roman-Drafting verwenden?
Kimi-K2.6 hat ein echtes 1-Millionen-Token-Kontextfenster, ist aber für die meisten Autoren unpraktisch lokal auszuführen (ca. 480 GB VRAM bei Q4-Quantisierung). Für vollständig lokale Workflows handhabt die Session-Dokument-Technik mit lokal ausführbaren Modellen Romanlängenarbeit ohne 1M-Decke.
Wie stehen Verlage zu KI-gestützten Manuskripten?
Gemischt und im Wandel. Die meisten großen Belletristik-Verlage verlangen eine Offenlegung wesentlicher KI-Nutzung; manche verbieten sie vollständig. Self-Publishing-Plattformen verlangen Attestation für KI-generierten Inhalt. Autoren, die lokale LLMs als Drafting-Assistenten mit wesentlicher menschlicher Überarbeitung verwenden, beschreiben die KI als Werkzeug statt als Co-Autor. Die spezifische Verlagsrichtlinie vor der Einreichung prüfen.
Muss ich bei der Verwendung eines lokalen LLMs zum Schreiben von Romanen oder Drehbüchern die DSGVO beachten?
Bei vollständig lokalen Modellen (Ollama auf eigener Hardware, keine Cloud-API) werden keine personenbezogenen Daten an externe Server übertragen — DSGVO-Anforderungen für Datenübertragungen (Art. 28) entfallen. Wenn personenbezogene Daten realer Personen in Prompts einfließen, können DSGVO-Grundsätze (Datensparsamkeit, Zweckbindung) greifen. Für fiktive Inhalte ohne Bezug zu realen Personen stellen vollständig lokale LLM-Workflows in der Regel kein DSGVO-Problem dar.
Was gilt in Deutschland beim Schreiben von Texten mit sexuellem oder gewalttätigem Inhalt mithilfe lokaler KI-Modelle?
Für legale Erwachsenenfiktion mit einvernehmlichen Szenarien zwischen erwachsenen Charakteren gibt es keine spezifischen KI-Einschränkungen. §184b und §184c StGB verbieten Inhalte, die den sexuellen Missbrauch von Minderjährigen darstellen — unabhängig davon, ob Mensch oder KI den Text generiert. Für Gewaltinhalte gilt §131 StGB (Gewaltverherrlichung). Die rechtliche Verantwortung liegt beim Nutzer.