Viele Aufgaben, für die heute Sprach- oder Bildmodelle genutzt werden, lassen sich grundsätzlich auch lokal auf einem Desktop-System ausführen: Text zusammenfassen, Code erklären, Dokumente klassifizieren oder Bilder generieren. In der Praxis scheitert der Einstieg jedoch oft an handfesten technischen Fragen: Reicht die vorhandene Hardware aus, warum ist die VRAM-Größe bei GPUs so entscheidend, und welche Laufzeit- und Modellformate funktionieren in welchem Setup? Hinzu kommen betriebliche Aspekte wie Speicherverbrauch durch Modell-Caches, Update-Mechanismen, die Kontrolle über Hintergrundprozesse sowie die Frage, welche Daten den Rechner überhaupt verlassen. Wer Modelle offline betreiben will oder aus Datenschutz- und Compliance-Gründen keine Cloud-APIs nutzen darf, braucht eine belastbare Einschätzung der Ressourcenanforderungen und eine Umgebung, die sich reproduzierbar konfigurieren, aktualisieren und auch wieder sauber entfernen lässt.
Hardware und Leistungsgrenzen: CPU, GPU, RAM, VRAM, Speicherbandbreite und Massenspeicher realistisch einordnen
Lokale Sprach- und Bildmodelle wirken auf dem Desktop oft „nur“ wie Software. Tatsächlich verhalten sie sich wie ein kontinuierlicher Datenstrom durch mehrere Speicherhierarchien: Massenspeicher lädt Modellgewichte in den RAM, von dort gelangen Tensorblöcke in den GPU-Speicher, und jede Generation erzeugt wiederholt Speicherzugriffe. Die beobachtete Geschwindigkeit wird deshalb weniger von der nominellen Rechenleistung geprägt als von Engpässen bei Speichergröße, -bandbreite und Datenbewegung.
CPU vs. GPU: Rechenpfad und typische Engpässe
Eine CPU-Ausführung eignet sich für kleinere Sprachmodelle, Vorverarbeitung, Embeddings oder Situationen, in denen keine diskrete GPU verfügbar ist. Moderne Laufzeiten nutzen Vektorbefehle (AVX2, teils AVX-512 je nach CPU und Build) und Parallelisierung über Threads; die Skalierung endet jedoch häufig an der Speicherbandbreite des Arbeitsspeichers und an der Latenz vieler kleiner Matrixoperationen. Bei quantisierten Modellen kann die CPU konkurrenzfähig erscheinen, weil weniger Daten pro Operation bewegt werden, aber der Abstand zur GPU bleibt bei größeren Kontextfenstern und höheren Tokenraten meist deutlich.
GPUs beschleunigen Transformer-Modelle primär durch massiv parallele Matrixmultiplikation und hohe Speicherbandbreite im VRAM. Der Vorteil zeigt sich besonders bei längeren Sequenzen, höherer Parallelität (z. B. mehrere gleichzeitige Anfragen) und bei Bildmodellen (Diffusion), die viele wiederholte Schritte mit großen Aktivierungstensoren ausführen. Sobald der VRAM nicht ausreicht und Teile der Gewichte oder Aktivierungen ausgelagert werden müssen, kippt die Bilanz: Der Datentransfer über PCIe wird zum dominierenden Kostenfaktor, selbst wenn die GPU rechnerisch noch Reserven hätte.
VRAM als harte Grenze: Modellgröße, Kontextfenster und Offloading
VRAM begrenzt, was „in einem Stück“ auf der GPU gehalten werden kann: Modellgewichte, Key/Value-Cache (bei Sprachmodellen), temporäre Aktivierungen und der Overhead der Laufzeit. Ein häufiges Missverständnis besteht darin, nur die Parameterzahl zu betrachten. Bei Inferenz steigt der Speicherbedarf zusätzlich mit dem Kontextfenster, weil der Key/Value-Cache pro Token anwächst. Bei Bildmodellen bestimmt neben dem Modell selbst die Auflösung und die Anzahl der Zwischentensoren den Peak-Verbrauch.
Wenn der VRAM knapp wird, erlauben viele Toolchains ein „Offloading“: Teile der Gewichte verbleiben im RAM und werden bei Bedarf über PCIe nachgeladen. Das kann ein Modell überhaupt erst startbar machen, reduziert jedoch die Tokenrate deutlich und verschlechtert die Latenz. Besonders ungünstig ist eine Mischung aus VRAM-Fragmentierung und dynamischer Speicherallokation, weil dann auch bei rechnerisch ausreichendem VRAM Allokationen scheitern können. Praktisch hilft ein Sicherheitsabstand, da Desktop-Umgebungen zusätzlich VRAM für Display, Browser oder Videodecoder belegen.
- VRAM-Budgetierung: Für stabile Läufe einen Puffer einplanen und parallel laufende GPU-Programme minimieren; bei NVIDIA lässt sich die Auslastung häufig über
nvidia-smibeobachten. - Offloading sichtbar machen: Bei stark schwankender Tokenrate und hoher PCIe-Last liegt meist ein Nachladen aus RAM vor; bei vielen Setups zeigt
nvidia-smi dmonodernvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.width.current,utilization.gpu,memory.used --format=csventsprechende Muster (je nach Treiber/Modell können die PCIe-Felder abweichen). - Kontextfenster als VRAM-Treiber: Größere Kontexte erhöhen den Key/Value-Cache; eine Reduktion des Context-Limits oder eine aggressivere Quantisierung des KV-Cache (falls vom Runner unterstützt) kann stabilisieren, ohne das Modell zu wechseln.
- Bildauflösung und Batch: Bei Diffusion erhöhen
width,heightundbatch_sizeden Peak-VRAM; kleinere Schritte wie geringerer Batch vermeiden Out-of-Memory oft effektiver als das Wechseln des Schedulers.
RAM und Unified Memory: Warum „genug Arbeitsspeicher“ nicht automatisch hilft
Arbeitsspeicher puffert Modellgewichte, Tokenizer-Daten, Caches und häufig mehrere Modellvarianten. Bei GPU-Nutzung wirkt RAM zunächst großzügig, solange der VRAM das Working Set trägt. Sobald jedoch ausgelagert wird, zählt nicht nur die RAM-Größe, sondern auch die Bandbreite des Speichercontrollers (Dual-/Quad-Channel), die Latenz und die Fähigkeit des Systems, große zusammenhängende Bereiche bereitzustellen. Hintergrunddienste, viele Browser-Tabs oder virtuelle Maschinen erhöhen den Druck und können zu Paging auf das Systemlaufwerk führen, was Inferenz spürbar destabilisiert.
Bei iGPUs und manchen Plattformen mit gemeinsamem Speicher (Unified Memory im Sinne von „shared system memory“) teilen sich CPU und GPU denselben physikalischen RAM. Das vereinfacht den Datenfluss, verschiebt die Grenze aber auf die RAM-Bandbreite. Gerade bei Bildgenerierung kann der Durchsatz dann deutlich unter dem diskreter GPUs liegen, obwohl die Recheneinheiten ausreichend erscheinen. In solchen Konfigurationen zählt schneller RAM (Takt und Timings) stärker als bei rein CPU-lastigen Aufgaben.
Speicherbandbreite: Der unterschätzte Taktgeber für Tokenrate und Diffusion
Transformermodelle sind bei Inferenz häufig bandbreitenlimitiert: Pro berechnetem Token müssen große Gewichtsmatrizen aus dem Speicher gelesen werden. Quantisierung (z. B. 8‑Bit oder 4‑Bit) reduziert den Datenverkehr und erhöht damit oft stärker die Tokenrate als zusätzliche Recheneinheiten. Bei GPUs entscheidet die VRAM-Bandbreite (GDDR6/GDDR6X/HBM) darüber, wie schnell diese Matrizen an die Recheneinheiten gelangen. Die reine Anzahl an Shadern oder Tensor-Cores liefert ohne passende Bandbreite nur eingeschränkt Mehrwert.
Bei Bildmodellen verteilt sich die Last auf Bandbreite und Compute, abhängig von Auflösung, Sampler und Precision (FP16/BF16, teils FP8 auf unterstützter Hardware und im passenden Stack). In der Praxis fallen Engpässe an ungleichmäßiger Auslastung auf: hohe GPU-Compute-Spitzen bei gleichzeitig moderater Speicherauslastung deuten auf Compute-Limitierung, dauerhaft hohe Speicherauslastung auf Bandbreitenlimitierung. Messwerte sind interpretationsbedürftig, weil Kernel-Fusion, Attention-Optimierungen und Treiber-Versionen das Profil verschieben.
| Komponente | Typischer Flaschenhals im lokalen KI-Betrieb | Praktisches Symptom |
|---|---|---|
| VRAM (Größe) | Working Set passt nicht vollständig auf die GPU | Out-of-Memory, stark schwankende Latenz, erzwungenes Offloading |
| VRAM-Bandbreite | Gewichte/Aktivierungen werden zu langsam geliefert | Geringe Tokenrate trotz niedriger GPU-Compute-Auslastung |
| RAM (Größe) | Modelle/Caches konkurrieren mit anderen Prozessen | Paging auf SSD, Hänger beim Laden, Abbrüche bei großen Kontexten |
| RAM-Bandbreite | CPU-Inferenz oder Shared-Memory-GPU limitiert | Mehr Threads bringen kaum Zuwachs; hohe Speichercontroller-Last |
| Massenspeicher (SSD/HDD) | Laden/Entpacken großer Modellfiles und Cache-I/O | Lange Startzeiten, „Stottern“ beim ersten Zugriff auf neue Modelle |
| PCIe-Verbindung | Offloading/Streaming zwischen RAM und VRAM | Tokenrate bricht ein, Transferlast steigt, GPU wirkt „unterfordert“ |
Massenspeicher: Ladezeiten, Cache-Verhalten und I/O-Spitzen
Für lokale Modelle zählt Massenspeicher weniger für die eigentliche Rechenphase als für Start, Modellwechsel und Caching. Modellgewichte liegen oft als mehrere Gigabyte große Dateien vor; bei häufigem Wechseln zwischen Varianten (z. B. unterschiedliche Quantisierungen oder Checkpoints) dominieren I/O und Dekompression die gefühlte Reaktionszeit. NVMe-SSDs reduzieren diese Wartezeiten deutlich gegenüber SATA-SSDs, während HDDs bei vielen kleinen Dateien oder parallelem Zugriff schnell zum Nadelöhr werden.
Zusätzlich erzeugen einige Laufzeiten Cache-Dateien für kompilierte Kernel, Graphen oder Tokenizer-Artefakte. Diese Caches verkürzen Folgestarts, können aber bei knappen System-SSDs stören und bei Updates inkompatibel werden. Sinnvoll ist eine Trennung: große Modelldateien auf ein schnelles Datenlaufwerk, System- und Cache-Operationen auf eine SSD mit ausreichend freiem Platz, um Write-Amplification und Performance-Drops zu vermeiden. Bei limitiertem Speicherplatz wirkt ein konsistentes Aufräumen älterer Modellrevisionen oft stärker als das Minimieren einzelner Cache-Dateien.
Lokale Toolchain aufsetzen: Modellformate, Runner und Frontends, Modellverwaltung, Konfiguration, Ressourcensteuerung, Caches und Updates
Eine lokale KI-Toolchain setzt sich typischerweise aus drei Schichten zusammen: Modellformat (Dateien und Metadaten), Runner (Inference-Engine mit Hardware-Backends) und Frontends (CLI, Desktop-Apps oder Web-UIs). Eine saubere Trennung erleichtert Updates, verhindert doppelte Modellablagen und macht Ressourcensteuerung nachvollziehbar. Praktisch relevant ist dabei weniger „das eine Tool“, sondern die Frage, welche Komponenten reproduzierbar zusammenarbeiten und wo sie Daten ablegen.
Modellformate und ihre Konsequenzen für Runner und Speicher
Für lokale Sprachmodelle dominieren quantisierte Containerformate, die auf schnelle Inferenz mit begrenztem VRAM und RAM zielen. Im Desktop-Umfeld verbreitet sind GGUF-Modelle für llama.cpp-basierte Runner. Sie bündeln Gewichte, Tokenizer-Infos und häufig auch Chat-Templates. Für Bildmodelle sind .safetensors gängig, meist im Umfeld von Diffusion-Pipelines (z. B. Stable Diffusion), ergänzt um LoRAs und Embeddings. Daneben existiert der klassische Framework-Stack (PyTorch), bei dem die Laufzeit deutlich stärker von CUDA/ROCm-Versionen, Python-Abhängigkeiten und passenden Wheels abhängt.
Das Format entscheidet indirekt über das Caching-Verhalten, die Möglichkeit zum Offloading (Layer auf GPU, Rest auf CPU) und über die Frage, ob ein Modell als „ein File“ transportiert wird oder als Sammlung von Artefakten (Base-Checkpoint, VAE, Text-Encoder, ControlNets, LoRAs). Für reproduzierbare Setups lohnt es sich, die Artefaktstruktur früh festzulegen: ein zentraler Modell-Store, dazu pro Runner ein klar abgegrenzter Cache.
| Format / Artefakt | Typischer Runner / Stack | Praktische Implikation |
|---|---|---|
GGUF |
llama.cpp, Desktop-Apps mit integriertem Backend |
Quantisierung im File; häufig einfacher Offline-Transfer; Layer-Offload über Runner-Parameter. |
.safetensors (Diffusion) |
Diffusers/PyTorch, ComfyUI/InvokeAI (je nach Backend) | Mehrere Komponenten (Checkpoint, VAE, LoRA) erhöhen Verwaltungsaufwand; VRAM-Spitzen bei hoher Auflösung/Batch. |
ONNX |
onnxruntime (CPU, CUDA, DirectML) |
Stabiler Deployment-Fokus; Performance hängt stark vom Execution Provider und Graph-Optimierungen ab. |
| Container/Hub-Layout (Snapshots) | Hugging Face Cache, eigene Mirror-Struktur | Versionierte Snapshots erleichtern Rollbacks; Bedarf an Speicher und konsequenter Cache-Pflege. |
Runner auswählen: CPU, GPU, Treiber-Backends und Prozessmodell
Runner kapseln die Inferenz und entscheiden, ob CPU-Vektorisierung (AVX2, teils AVX-512), GPU-Kernels (CUDA, ROCm) oder plattformnahe Abstraktionen wie DirectML genutzt werden. In der Praxis fällt die Wahl oft zwischen einem llama.cpp-Runner (für LLMs), einem Python-basierten Diffusion-Stack (für Bilder) und spezialisierten Engines wie onnxruntime für bestimmte Modelle. Wichtig ist das Prozessmodell: Manche Lösungen starten einen lokalen Server (HTTP, teils auch gRPC je nach Projekt) und lassen mehrere Clients darauf zugreifen; andere binden Bibliotheken direkt in eine Desktop-App ein. Server-basierte Runner vereinfachen das Teilen von Modellcache und erlauben zentrale Limits (Threads, VRAM), benötigen aber definierte Ports und saubere Shutdown-Logik.
Bei GPU-Ausführung gilt: Treiber und Runtime müssen zum Runner passen. Unter Windows bedeutet das meist ein aktueller NVIDIA-Treiber; ob eine separate CUDA-Installation nötig ist, hängt vom jeweiligen Stack ab (viele Python-Framework-Wheels bringen CUDA-Libraries mit, andere Setups erwarten ein lokal installiertes CUDA-Toolkit). Unter Linux kommen Kernel-Module und Distribution-Aspekte hinzu; bei AMD hängen Verfügbarkeit und Reifegrad von ROCm und Distribution ab. DirectML kann auf Windows eine Option sein, wenn CUDA/ROCm nicht verfügbar sind, ist aber stark modell- und runnerabhängig. Für CPU-Inferenz sind dagegen stabile BLAS-Backends, korrekte Threading-Einstellungen und NUMA-Aspekte relevanter als Treiberfragen.
- LLM-Runner (GGUF):
llama.cpp-basierte Runner unterstützen Layer-Offload und Quantisierung; typische Stellschrauben sind--threads,--ctx-size,--n-gpu-layersund ggf.--flash-attn(abhängig vom Build/Backend). - Diffusion-Runner (Python): Für Bildmodelle hängen Stabilität und Performance stark von
torch-Build, CUDA/ROCm und optionalen Optimierern (z. B. xFormers oder PyTorch-SDPA je nach Umgebung) ab; typische Limits sind--medvram/--lowvram(toolabhängig) sowie Batch- und Auflösungsparameter im Workflow. - ONNX als Zwischenebene: Mit
onnxruntimelässt sich zwischenCPUExecutionProvider,CUDAExecutionProvideroderDmlExecutionProviderwechseln; entscheidend sind kompatible Operatoren und eine konsistente Modell-Export-Pipeline.
Frontends: CLI, Desktop-UIs und Web-UIs lokal betreiben
Frontends definieren Prompt-Handling, Chat-Verläufe, Parameterprofile, Bild-Workflows und Integrationen (Editoren, Dateisystem, Zwischenablage). Leichtgewichtige Setups nutzen eine CLI plus lokale REST-API, während Desktop-UIs häufig ein eingebettetes Backend mitbringen. Web-UIs laufen meist als lokaler Dienst und werden über http://127.0.0.1 angesprochen; damit bleiben Daten lokal, solange keine externen Plugins, Telemetrie oder Modell-Downloads unkontrolliert aktiv sind. Für Mehrbenutzer-Systeme sollte Bindung an 127.0.0.1 oder ein explizites Auth-Konzept gesetzt werden, statt Dienste auf 0.0.0.0 zu öffnen.
Für Codeunterstützung ist die Trennung zwischen Modellserver und IDE-Plugin zentral: IDEs senden häufig Quelltextausschnitte als Kontext. Ein lokaler Server reduziert das Risiko, dass Daten in Cloud-Endpoints geraten, setzt aber klare Kontextgrenzen voraus (z. B. maximale Token, Dateifilter, Blocklisten für Verzeichnisse). Bei Bildworkflows ist die UI-Frage oft entscheidend für Reproduzierbarkeit: Node-basierte Frontends speichern Graphen inklusive Seeds und Sampler-Parameter, während einfache UIs eher „Sessions“ verwalten.
Modellverwaltung: Ablageorte, Versionierung, Integrität
Modellverwaltung wird schnell zum Engpass, weil große Dateien, häufige Updates und Duplikate zusammenkommen. Bewährt hat sich ein dedizierter Modell-Root auf einem schnellen Datenträger, getrennt nach llm/, diffusion/, loras/ und embeddings/. Viele Tools nutzen zusätzlich eigene Caches, beispielsweise der Hugging-Face-Cache. Ohne Planung entstehen dadurch doppelte Gigabytes: einmal im zentralen Store, einmal im Snapshot-Cache.
- Hugging-Face Cache (Standardpfad): Linux typischerweise
~/.cache/huggingface/, Windows typischerweise%USERPROFILE%\.cache\huggingface\; steuerbar überHF_HOMEoderHUGGINGFACE_HUB_CACHE. - PyTorch/Transformers Download-Verhalten: Wiederverwendung erfolgt über Snapshot-Verzeichnisse; für Offline-Betrieb sind lokal gespiegelte Repos oder vorab befüllte Caches relevant, ohne die Codepfade zu ändern.
- Integritätsprüfung: Für manuell bezogene Modelle sind Hashes (z. B.
sha256) und unveränderte Dateinamen sinnvoll, damit Runner-Profile reproduzierbar bleiben.
Bei quantisierten LLMs lohnt es sich, pro Modellfamilie eine definierte Quantisierungsstufe zu halten statt viele Varianten parallel zu lagern. Für Diffusion-Setups reduziert ein konsistentes Benennungsschema (Basis-Checkpoint, VAE, LoRA-Stacks) die Fehlersuche, wenn Ergebnisse abweichen. Versionierung lässt sich pragmatisch über Ordnernamen oder Git-LFS-artige Mirror-Strukturen abbilden; entscheidend ist, dass Frontends nicht „stillschweigend“ auf neuere Dateien zeigen.
Laufzeitkonfiguration und Ressourcensteuerung: Kontext, VRAM, Threads, Parallelität
Lokale Inferenz erfordert harte Grenzen, sonst konkurrieren mehrere Prozesse um VRAM und RAM. Bei LLMs treiben vor allem Kontextlänge, KV-Cache und Parallelität (mehrere gleichzeitige Requests) den Speicherbedarf. Ein Runner-Profil sollte deshalb Kontext (ctx), maximale gleichzeitige Anfragen und Offload-Strategie festschreiben. Für Bildmodelle sind Auflösung, Batch-Größe, Anzahl Schritte und aktivierte Zusatzmodule (ControlNet, Highres-Fix, Upscaler) die dominierenden Faktoren.
| Stellgröße | Wirkt primär auf | Typische Nebenwirkung |
|---|---|---|
Kontextlänge (ctx) |
RAM/VRAM (KV-Cache) | Mehr Kontext reduziert Durchsatz; bei VRAM-Knappheit erhöht sich CPU-Offload und Latenz. |
GPU-Layer-Offload (n-gpu-layers) |
VRAM vs. RAM | Zu aggressives Offload führt zu OOM; zu wenig Offload verschenkt GPU-Bandbreite. |
Threads/Worker (--threads, parallele Requests) |
CPU-Auslastung, Antwortzeit | Oversubscription erzeugt Kontextwechsel und Cache-Thrashing; für Interaktivität sind weniger Worker oft stabiler. |
| Bildauflösung und Batch | VRAM-Spitzen | OOM tritt häufig erst beim U-Net-Pass oder VAE-Decoding auf; geringere Batch-Größe stabilisiert. |
Für planbare Ressourcennutzung ist Prozess-Isolation hilfreich: ein Modellserver pro GPU oder pro Modellklasse, dazu fixe Limits. Unter Linux lässt sich CPU- und RAM-Druck zusätzlich über systemd (z. B. MemoryMax, CPUQuota) steuern; containerisierte Setups können diese Grenzen ebenfalls erzwingen, solange der GPU-Zugriff korrekt durchgereicht wird. Unter Windows sind ähnliche Grenzen eher über Job-Objekte (z. B. durch den jeweiligen Launcher/Service-Wrapper) oder Drittwerkzeuge realistisch, während viele KI-Tools ihre Limits primär in der eigenen Konfiguration setzen.
Caching, Updates und Deinstallation: systemnah und nachvollziehbar
Caches beschleunigen Downloads und Modell-Initialisierung, verschleiern aber Speicherverbrauch und erschweren saubere Updates. Sinnvoll ist eine Trennung zwischen „Artefakt-Store“ (bewusst verwaltete Modelle) und „Build/Runtime-Caches“ (automatisch erzeugt). Bei GPU-Stacks kommen weitere Schichten hinzu: Kernel-Caches, Shader- oder Triton-Caches sowie Python-Wheels. Updates sollten möglichst eine Variable pro Schritt ändern: erst Runner/Engine, dann Modell, dann Frontend. Andernfalls wird die Fehlersuche bei numerisch abweichenden Outputs und OOM-Problemen unnötig komplex.
- Cache-Löschung gezielt statt pauschal: Hugging-Face Artefakte liegen in
~/.cache/huggingface/bzw.%USERPROFILE%\.cache\huggingface\; ein selektives Entfernen einzelner Snapshots ist oft sinnvoller als das Löschen des gesamten Baums. - Python-Umgebungen entkoppeln: Für Diffusion-Tools reduziert eine separate Umgebung pro Anwendung (z. B.
venvoder Conda) Konflikte beitorch-Updates; Deinstallation bleibt dann auf das Entfernen des Env-Verzeichnisses begrenzt. - Runner-Updates mit Rollback-Pfad: Bei serverbasierten Runnern sind versionierte Binaries/Container und feste Startparameter wichtig; ein Rollback gelingt, wenn das alte Artefakt parallel verfügbar bleibt und nur der Service auf die frühere Version zeigt.
- Datenspuren minimieren: Chat-Historien, Prompt-Logs und generierte Bilder liegen häufig in App-spezifischen Datenverzeichnissen; kontrollierbar über Einstellungen für
history/loggingsowie über definierte Output-Ordner auf einem separaten Volume.
Bei Deinstallation systemnaher Komponenten ist zu unterscheiden: Treiber (GPU), Runtimes (z. B. CUDA/ROCm/DirectML-Backends je nach Stack), Runner-Binaries, Python-Environments und Modell-/Cache-Daten. Treiber bleiben in der Regel systemweit installiert und sollten nur aus Wartungsgründen entfernt werden. Dagegen lassen sich Runner und Frontends meist vollständig durch Entfernen ihrer Programmverzeichnisse und Services deinstallieren, sofern zusätzlich die zugehörigen Cache- und Datenpfade bekannt sind. Ein dokumentierter „Inventory“-Ordner mit Pfaden, Versionen und Startparametern verhindert, dass nach Monaten unklare Reste übrig bleiben, die Speicher belegen oder unbemerkt Ports öffnen.
Praxis-Workflows und Modellwahl: Text/Chat, Codeunterstützung und Bildgenerierung mit Offline-Betrieb, Speicherorten und Deinstallation
Text/Chat lokal: Latenz, Kontextfenster, Streaming und robuste Defaults
Für lokale Chat-Workflows zählt weniger die theoretische Maximalleistung als ein stabiler Durchsatz bei akzeptabler Latenz. In der Praxis bestimmen drei Faktoren das Nutzungsgefühl: das Kontextfenster (KV-Cache im Arbeitsspeicher bzw. VRAM), die Token-Rate (CPU- bzw. GPU-Ausführung, Speicherbandbreite) und die I/O-Charakteristik beim Modellladen (SSD und Dateisystem-Cache). Bei längeren Dialogen wächst der KV-Cache proportional zur Sequenzlänge; das kann VRAM oder RAM überraschend schnell binden, selbst wenn die Modellgewichte noch „passen“.
Werkzeuge wie Ollama oder llama.cpp-basierte UIs (beispielsweise Open WebUI als Frontend) ermöglichen Offline-Betrieb, sofern Modell-Downloads und Telemetrie-Optionen kontrolliert werden. Sinnvoll sind konservative Startwerte: moderate Kontextlängen, aktiviertes Token-Streaming, klare Stop-Sequenzen und deterministische Einstellungen (z. B. niedrige Temperatur) für reproduzierbare Ausgaben. Sobald das System unter Speicherdruck gerät, sinkt die Interaktivität typischerweise abrupt (Swap/Paging, VRAM-Oversubscription, Treiber-Timeouts).
- Bind-Adresse (Loopback) setzen:
OLLAMA_HOST=127.0.0.1:11434ollama serve - Modell laden und testen:
ollama pull llama3.1ollama run llama3.1 - Kontext/KV-Druck reduzieren (llama.cpp):
llama-cli -m model.gguf -c 4096 --keep -1 --temp 0.2 - GPU-Offload gezielt staffeln (llama.cpp, abhängig von Build/Backend):
llama-cli -m model.gguf -ngl 30
Codeunterstützung offline: In-IDE-Vervollständigung, Repo-Kontext und Sicherheitsgrenzen
Lokale Codeassistenz unterscheidet sich vom Chat vor allem durch Kontextzufuhr: Quelltexte, Abhängigkeitsbäume, Tests und Build-Logs müssen in das Prompting oder in eine Retrieval-Schicht einfließen. Für reine Autovervollständigung reichen oft kleinere Instruct- oder Code-Modelle; für Refactorings und mehrschrittige Änderungen steigt der Nutzen mit größerem Kontextfenster und konsistenter Tool-Anbindung (Dateizugriff, Diff-Generierung, Patch-Anwendung). Offline bleibt der entscheidende Punkt, dass keine Inhalte an externe Dienste übertragen werden, während dennoch eine saubere Trennung zwischen Projektkontext und Modell-Cache nötig ist.
In der Praxis haben sich zwei Muster etabliert: (1) ein lokaler Model-Server (z. B. Ollama) als einheitliches Backend für mehrere Clients; (2) ein IDE-Plugin, das gegen einen lokalen OpenAI-kompatiblen Endpoint spricht (häufig http://127.0.0.1:11434/v1 bei Nutzung einer OpenAI-kompatiblen API-Schicht, sofern diese im jeweiligen Setup aktiviert ist). Für größere Repositories lohnt es sich, Retrieval (lokales Embedding-Modell, Vektorindex) getrennt zu betreiben, damit nicht jeder Prompt den gesamten Code als Rohtext trägt. Dabei sind Dateifilter (z. B. node_modules, dist, Binärdateien) und Größenlimits essenziell, um Latenzspitzen und Speicherexplosionen zu vermeiden.
| Aufgabenprofil | Praktische Modell-Eigenschaften | Typische Engpässe lokal |
|---|---|---|
| Inline-Vervollständigung | Kleineres Code-Modell, niedrige Latenz, moderates Kontextfenster | Single-Thread-Limit auf CPU, Prompt-Overhead im IDE-Loop |
| Refactoring über mehrere Dateien | Stabiles Instruct-Verhalten, gutes Tool-Use/Planung, größeres Kontextfenster oder Retrieval | KV-Cache (RAM/VRAM), I/O beim Laden vieler Dateien |
| Debugging/Log-Analyse | Starke Textverständnisleistung, saubere Zitierung von Log-Ausschnitten, deterministische Settings | Promptgröße, Token-Rate bei langen Antworten |
Bildgenerierung lokal: Diffusion, VRAM-Budgets, Sampler und Batch-Strategien
Für Bildgenerierung wird die Hardwaregrenze meist durch VRAM bestimmt, nicht durch reine Rechenleistung. Diffusion-Workflows (z. B. Stable-Diffusion-Familie) belegen VRAM für Modellgewichte, Aktivierungen und Zwischenpuffer; Auflösung, Batch-Größe, Anzahl der Schritte und Zusatzmodule (ControlNet, LoRA-Stapel, High-Res-Fix, Upscaler) verschieben den Bedarf. Wenn VRAM knapp wird, helfen Kachelverfahren (Tiling), geringere Auflösung, kleinere Batch-Größen oder ein Wechsel auf effizientere Attention-Implementierungen, sofern das gewählte Backend sie unterstützt.
In Desktop-Setups sind AUTOMATIC1111 (WebUI), ComfyUI (Node-Graph) und Fooocus verbreitet. Offline-Betrieb gelingt, wenn Modelle lokal gespeichert werden und optionale Online-Checks (Update-Hinweise, Modell-Download-Links) deaktiviert bleiben. Für reproduzierbare Ergebnisse sind feste Seeds, dokumentierte Sampler/Steps und eine konsistente VAE-/Scheduler-Kombination wichtig, weil selbst kleine Änderungen an Komponenten das Bildrauschen und damit das Ergebnis beeinflussen.
- VRAM-Planung nach Workflow: Hohe Auflösungen und
batch_sizetreiben VRAM stärker als ein einzelner zusätzlicher LoRA; Control-Workflows (z. B. Kanten/Depth) benötigen zusätzliche Netze im Speicher. - Stabilität vor Geschwindigkeit: Bei Treiber-Timeouts oder sporadischen
CUDA out of memory-Fehlern sind kleinerebatch-Werte, reduzierte Auflösung und weniger parallele Jobs meist wirksamer als aggressives Offloading. - Modellwahl für Bildstile: Basismodelle (SDXL vs. SD 1.5-Ökosystem) unterscheiden sich im Speicherbedarf und in der Verfügbarkeit von Erweiterungen; LoRAs und VAEs sollten versionskompatibel gehalten werden (Dateinamen/Hashes dokumentieren).
Speicherorte, Caching und Updates: Modelle, Layer-Caches, Artefakte
Lokale KI-Stacks verteilen Daten oft über mehrere Ebenen: Modell-Repository, Laufzeit-Cache, temporäre Artefakte (z. B. generierte Bilder) und optionale Vektorindizes. Für planbare Backups und kontrollierbare Plattenbelegung sollten diese Pfade bewusst gesetzt werden. Bei containerisierten Setups kommt zusätzlich das Volume-Layout hinzu. Ein häufiger Fehler besteht darin, Modelle mehrfach zu speichern: einmal im Tool-eigenen Cache und ein weiteres Mal im UI-Ordner, was schnell Hunderte Gigabyte belegt.
- Ollama-Modelle (Standardpfade): Linux typischerweise
/usr/share/ollama/.ollamaoder~/.ollama(je nach Installation)
macOS~/.ollama
Windows%USERPROFILE%\.ollama - Hugging-Face-Cache (Transformers/Diffusers): Standard
~/.cache/huggingfacebzw. Windows%USERPROFILE%\.cache\huggingface; umlegen überHF_HOMEoderTRANSFORMERS_CACHE(je nach Stack). - Python/PyTorch-Kompilate und Erweiterungen: Caches liegen typischerweise unter
~/.cache/torchbzw. Windows%LOCALAPPDATA%\torch; nach Treiber-/CUDA-Änderungen können Rebuilds nötig sein. - ComfyUI/A1111 Modellordner (üblich): Häufig
models/innerhalb des Installationsverzeichnisses; strukturierte Unterordner wiecheckpoints,loras,vae,controlnetreduzieren Dubletten und erleichtern Updates.
Update-Strategien profitieren von Trennung: Das Tool (UI/Runtime) wird versionsgeführt aktualisiert, Modelle werden als eigene Artefakte behandelt. Für Modelle sind Hashes und genaue Herkunft (Release/Commit) entscheidend, weil sich „gleich benannte“ Dateien inhaltlich unterscheiden können. Bei Offline-Betrieb bietet sich ein lokales Spiegeln der benötigten Artefakte an, etwa über ein internes Dateirepository oder einen dedizierten Modellordner mit unveränderlichen Dateinamen.
Deinstallation und Bereinigung: Dienste, Container, Caches und Treiber-nahe Komponenten
Eine vollständige Deinstallation umfasst mehr als das Entfernen des Frontends. Lokale Model-Server können als Dienst laufen, Container können Volumes behalten, und Python-Umgebungen hinterlassen Wheels, Build-Artefakte und Shader-Caches. Saubere Bereinigung reduziert Plattenverbrauch und verhindert, dass alte Modelle oder inkompatible Erweiterungen später unbemerkt wieder geladen werden. Gleichzeitig sollten Treiber- und Runtime-Komponenten (GPU-Treiber, CUDA/ROCm-Laufzeiten) getrennt betrachtet werden: Sie werden oft auch von anderen Anwendungen genutzt und sollten nur nach Abhängigkeitsprüfung entfernt werden.
- Ollama entfernen (Beispiele): Linux (systemd, je nach Paket)
sudo systemctl stop ollamasudo systemctl disable ollama
macOS (Homebrew, falls so installiert)brew uninstall ollama - Modelldaten und Cache löschen: Nach Deinstallation Ordner wie
~/.ollamaund~/.cache/huggingfacesowie UI-spezifischemodels/-Verzeichnisse prüfen und gezielt entfernen. - Container-Volumes bereinigen: Bei Docker bleiben Daten häufig in Volumes; Prüfung über
docker volume lsund Entfernen überdocker volume rm <name>(nur nach Verifikation des Inhalts). - Python-Umgebungen konsolidieren: Virtuelle Umgebungen pro Tool (z. B.
.venv) erleichtern die Entfernung durch simples Löschen des Projektordners; globale Installationen überpiperzeugen schwer nachvollziehbare Restbestände.
Für den Offline-Modus bleibt neben der reinen Netztrennung die Frage nach indirekten Datenabflüssen: UIs können externe Ressourcen nachladen (Schriftarten, CDN-Dateien), und manche Erweiterungen führen Update-Checks aus. Technisch lässt sich das durch lokale Asset-Bundles, Deaktivieren von Auto-Update-Funktionen und restriktive Firewall-Regeln (nur Loopback) einhegen. Umgekehrt darf „offline“ nicht mit „ohne Metadaten“ verwechselt werden: Prompt-Historien, generierte Dateien und Logs liegen lokal oft persistent und sollten entsprechend in Backup-, Berechtigungs- und Löschkonzepte eingeplant werden.
