Richtlinien

Sie verfassen einen vagen Prompt (z. B. 'Erstellen Sie eine Analyse von X') und erhalten eine generische Antwort, die Sie erneut umschreiben müssen.

Geben Sie dem Modell: (1) eine konkrete Rolle/der Kontext, (2) das exakte Ausgabeformat, (3) 1–2 Beispiele für Richtig und Falsch. Die drei Modelle reagieren besser auf strukturierte Anweisungen als auf lose Prosa.

Statt „fasse diesen Vertrag zusammen": „Sie sind ein Anwalt, der diesen Mietvertrag überprüft. Erstellen Sie eine Liste von maximal 5 risikobehafteten Klauseln, jede in einer Zeile: [Klausel] — [warum sie riskant ist] — [was Sie stattdessen fordern]."

Sie haben Zugriff auf verschiedene Modelle, wissen aber nicht, welches wofür geeignet ist — Sie nutzen aus Gewohnheit immer das gleiche Modell, nicht aufgrund einer bewussten Entscheidung.

Stellen Sie sich drei Fragen in der Reihenfolge: (1) Ist die Daten empfindlich? → Ja, lokal zuerst. (2) Ist die Aufgabe langformatiger Code oder agentisch? → Claude Opus/GPT-5.3-Codex. (3) Benötigen Sie riesigen Kontext (lange Dokumente)? → Gemini. Alles andere (Chat, Zusammenfassungen, kurze Aufgaben) → das günstigste lokale Modell, das die Aufgabe gut löst.

Prüfen Sie einen Vertrag mit Kundendaten: lokales Modell (verlässt niemals Ihren Server). Große Refaktorisierung eines Repositories: Claude Opus oder GPT-5.3-Codex-Max. Zusammenfassung von 300 Seiten eines Berichts: Gemini über den Kontextfenster.

Sie möchten ein lokales Modell testen, wissen aber nicht, welche Hardware erforderlich ist, und haben keine Ahnung, wo Sie anfangen sollen.

Für Qwen3.6 27B (dicht, der Sweet Spot derzeit): mindestens eine GPU mit 16–24 GB VRAM in Q4. Installieren Sie llama.cpp oder Ollama, laden Sie das quantisierte GGUF-Modell (Q4_K_M ist der Standard für das beste Qualitäts-/Größen-Verhältnis), starten Sie den lokalen Server und richten Sie jeden kompatiblen OpenAI-Client auf `http://127.0.0.1:8080/v1` aus.

`ollama pull qwen3.6:27b` → `ollama run qwen3.6:27b 'erkläre mir, was RAG in 3 Zeilen ist'`. Erstes Output in Minuten, nicht Stunden.

Beide sind Chat-Gateways zu KI-Agenten — welche wählt ihr und warum?

Die eigentliche Frage ist nicht „was ist besser", sondern „wo soll das Modell laufen". OpenClaw ist Open-Source, aber BYO-API-Key – standardmäßig werden Ihre Nachrichten über die Cloud eines Dritten (Claude/GPT/Gemini) geleitet, obwohl das Gateway auf Ihrem Gerät läuft. ImaginClaw läuft standardmäßig auf lokalen Modellen (Hera); die Cloud dient nur als explizites Fallback.

Falls Datenschutz (Recht, Gesundheit, Kundendaten) eine Rolle spielt: Imaginclaw oder ein OpenClaw, das ausschließlich mit lokalem Ollama konfiguriert ist. Wenn Sie Frontier-Kapazität ohne eigene Infrastruktur benötigen: OpenClaw mit Claude-/GPT-API.

Es ist nicht offensichtlich, wann der Unterschied zwischen 'lokal' und 'Cloud' nur eine technische Präferenz und wann eine echte Risikoentscheidung ist.

Fragen Sie sich: Wenn diese Konversation morgen auslief, wem würde sie schaden? Persönliche Daten Dritter (Kunden, Patienten, Mitarbeiter), Geschäftsgeheimnisse oder alles, was einer rechtlichen Vertraulichkeitspflicht unterliegt → lokal ist die richtige Antwort, keine Präferenz. Für alles andere ist die Cloud einfacher und reicht in der Regel aus.

Ein Anwaltsbüro bearbeitet Akten von Mandanten: lokal, ohne Diskussion (und in Kolumbien mit tatsächlicher Relevanz gemäß dem Datenschutzgesetz 1581 von 2012). Entwurf für einen Blog-Post verfassen: einer der beiden.

Jede neue Release-Version behauptet 'übertrifft X in Benchmarks' – und ist fast nie Information, die Ihnen hilft zu entscheiden, ob es sich für Sie lohnt.

Ignorieren Sie den Vendor-Benchmark. Erstellen Sie 5–10 echte Aufgaben aus Ihrer Arbeit (nicht generisch), führen Sie diese gegen das aktuelle und das neue Modell durch und vergleichen Sie diese blind. Wenn Sie keinen echten Unterschied in Ihren Aufgaben feststellen, migrieren Sie nicht nur aufgrund der Benchmark-Zahl.

Bevor Sie von einem Modell zum anderen für die Vertragsprüfung migrieren: Nehmen Sie 10 bereits von einem Menschen überprüfte Verträge, führen Sie beide Modelle durch und zählen Sie, wie viele echte Fehler (keine Stilfehler) jedes macht.

Der KI-Jargon ist voller Begriffe, die wichtig klingen, aber niemand in einem nützlichen Satz erklärt.

20 Begriffe, je eine Zeile: **Token** — die kleinste Texteinheit, die ein Modell verarbeitet (kein exaktes Wort). **Kontext** — wie viel Text das Modell gleichzeitig „sehen" kann. **Quantisierung (Q4/Q8)** — Komprimieren eines Modells, um weniger VRAM zu verbrauchen, mit geringem Qualitätsverlust. **VRAM** — Grafikspeicher, das eigentliche Flaschenhals für das lokale Ausführen von Modellen. **MoE (Mixture of Experts)** — ein großes Modell, das pro Token nur einen Teil aktiviert (schneller als ein gleich großes dichtes Modell). **Fine-tuning** — Nachtrainieren eines Modells mit eigenen Daten. **RAG** — Abrufen echter Informationen vor der Antwort, statt auf das „Gedächtnis" des Modells zu vertrauen. **Agent** — ein Modell, das Werkzeuge (Suchen, Codeausführung, Navigation) in einem Loop nutzen kann, nicht nur Text antwortet. **Halluzination** — das Modell erfindet Fakten mit voller Überzeugung. **Temperatur** — wie viel Zufälligkeit die Antwort hat (0 = deterministisch, höher = variabler). **Systemprompt** — die unsichtbare Anweisung, die das Modellverhalten vor deinem Nachrichteneingang festlegt. **Kontextfenster** — die Gesamtgrenze an Tokens (dein Prompt + Antwort), die das Modell pro Runde verarbeiten kann. **Embedding** — Umwandeln von Text in Zahlen zur Ähnlichkeitsvergleichbarkeit. **Zero-shot / few-shot** — eine Aufgabe ohne Beispiele vs. mit 1–2 Beispielen im Prompt anfordern. **Open-weight** — die Modellgewichte sind herunterladbar (bedeutet nicht, dass es leicht oder einfach zu betreiben ist). **API** — wie dein Code mit einem Modell auf einem anderen Server kommuniziert. **Latenz** — wie lange die Antwort dauert. **Durchsatz** — wie viele Anfragen parallel bearbeitet werden können. **Prompt-Injection** — ein Angriff, bei dem bösartiger Text im verarbeiteten Inhalt das Modell von seinen Anweisungen ablenkt. **Guardrail** — eine externe Regel, die das Modelloutput blockiert oder korrigiert.

Dieses Modell verfügt über einen Kontext von 262K und kann etwa 200.000 Wörter auf einmal verarbeiten, nicht dass es intelligenter wäre.

Das Modell 'vergisst' etwas, das Sie ihm in derselben Konversation zuvor gesagt haben, oder unterbricht die Antwort mitten im Satz

Alle Eingaben und Ausgaben eines Modells werden in Tokens gemessen (ca. ¾ eines Wortes in Spanisch/Englisch). Der Kontextfenster ist ein gemeinsamer TOTALLIMIT für Prompt, Historie und Antwort – es gibt keine separaten Kontingente. Nähert man sich dem Limit, beginnt das Modell, Details aus dem weiteren Verlauf zu verlieren.

Ein Modell mit 128K Kontext und einem Gesprächsverlauf von 100K Tokens verfügt nur noch über 28K freie Tokens für Ihre nächste Nachricht und die Antwort – wenn Sie dort ein langes Dokument anfordern, wird es abgeschnitten oder übermäßig zusammengefasst.

Sie möchten, dass das Modell eine bestimmte Information über Ihr Unternehmen „weiß", und es ist nicht offensichtlich, welche der drei Techniken verwendet werden soll.

**Prompting** (geben Sie die Informationen direkt im Prompt ein) — für kleine Datenmengen, die sich häufig ändern und keine Infrastruktur erfordern. **RAG** (retrieven und relevante Informationen vor der Antwort abrufen) — für große Wissensbasen, die sich häufig ändern (Dokumente, Richtlinien, Kataloge). **Fine-tuning** (Nachtrainieren des Modells) — nur erforderlich, wenn Sie den STIL/Verhalten des Modells ändern möchten, nicht um ihm Daten hinzuzufügen — dies ist teurer und nicht die richtige Methode, um dem Modell Fakten beizubringen.

Ein Bot, der zu über 500 Produkten eines sich wöchentlich ändernden Katalogs antwortet: RAG, kein Fine-Tuning. Ein Bot, der unabhängig vom Thema stets in einem spezifischen juristischen Ton antworten muss: hier ist Fine-Tuning sinnvoll.

Alle drei sind 'open-weight', haben aber völlig unterschiedliche Hardwareanforderungen — das Label sagt euch nicht, ob ihr sie selbst betreiben könnt.

Qwen3.6 27B dicht: läuft auf 1–2 Consumer-GPUs (16–24 GB VRAM in Q4) – der einzige der drei, der heute tatsächlich für individuelles Self-Hosting zugänglich ist. Kimi K3 (2,8T Parameter) und DeepSeek V4 (bis zu 1,6T): offene Gewichte, aber Datacenter-Skala – Hunderte von GB VRAM, auch quantisiert, konzipiert für den Betrieb über eine API eines Anbieters oder einen eigenen Cluster, nicht für Ihren Desktop.

Wenn Sie 1-2 GPUs haben und etwas sofort ausführen möchten: Qwen3.6 27B. Wenn Sie maximale open-weight-Kapazität wünschen und es Ihnen nichts ausmacht, einem Anbieter zu zahlen, der es hostet: Kimi K3 oder DeepSeek V4 über API.