- Gesucht wird ein Modell, das auf einer 5060ti + 16GB VRAM grundlegende Gespräche führen kann. Wenn möglich, sollte es schnell und nahezu in Echtzeit laufen.
Zusammenfassung der Antworten
- Verschiedene 8B~14B- und 30B-Parameter-Modelle laufen effizient auf 16GB VRAM; besonders empfohlen werden Qwen3, DeepSeek-R1, Mistral, Gemma3.
- Das lokale Ausführen von LLMs bietet Vorteile bei Leistung, Kosten und Privatsphäre, aber für die tatsächliche Performance und die Eignung eines Modells sind individuelle Tests und Tuning unverzichtbar.
- Tipps zur optimalen Hardware-Nutzung werden rege geteilt, etwa zur Größe der Modelldateien, zum Quantisierungsgrad (Q4~Q6 usw.) und zum verteilten Laden über GPU und RAM.
- Es gibt verschiedene Tools wie Ollama, LM Studio, llama.cpp, OpenWebUI, die jeweils Vor- und Nachteile bei Zugänglichkeit, Flexibilität und Komfort der Modellverwaltung haben.
- Community-Quellen (z. B. Reddit LocalLLaMA) sind nützlich für aktuelle Informationen und Praxistipps, allerdings ist wegen Übertreibungen und Fehlinformationen Vorsicht geboten.
Wichtige LLM-Empfehlungen und Nutzungstipps
- Qwen3: Es gibt Modelle mit verschiedenen Parametergrößen wie 8B/14B/30B; die 8B~14B-Modelle lassen sich auf 16GB VRAM komfortabel nutzen. Die reasoning-Leistung ist stark, und dank MoE(Mixture of Experts)-Architektur können einige größere Modelle per RAM-Offloading betrieben werden.
- DeepSeek-R1-0528-Qwen3-8B: Gilt als eines der neuesten 8B-Modelle mit sehr guter reasoning-Leistung. In der 8B-Klasse ist es bei Q4~Q6-Quantisierung für 4GB~8GB VRAM geeignet.
- Mistral Small 3.1: Empfohlen werden 14B- oder 24B-Modelle; die Dialogqualität ist hoch und das Modell gilt als vergleichsweise wenig zensiert. Besonders erwähnenswert ist die Unterstützung für Bildeingaben.
- Gemma3: Ein von Google bereitgestelltes Modell mit Stärken bei intuitiven Gesprächen. Es wird aber auch als stark HR-orientiert beschrieben, mit vielen Disclaimern. Halluzinationen treten ebenfalls relativ häufig auf.
- Devstral: Ein großes Modell auf Basis von Mistral. Ab 30B und mehr kann es auf 16GB VRAM langsam werden.
- Dolphin, Abliterated: Varianten mit weniger Zensur, nützlich in nicht routinemäßigen Situationen.
Optimierung von Hardware und Laufzeitumgebung
- Quantisierungseinstellungen: Bei Q4, Q5, Q6 usw. sinkt der VRAM-Verbrauch mit niedrigerer Quantisierung (Q4 ≒ Parameter/2, Q6 ≒ Parameter*0.75). Dabei sollte man jedoch mögliche Qualitätsverluste beachten.
- Abschätzung des VRAM-Bedarfs: Beispiel: 8B Q4 benötigt 4GB, 14B Q4 7GB, 30B Q4 etwa 15GB VRAM.
- RAM-Offloading: Wenn der VRAM nicht ausreicht, können einige Layer in den CPU-Speicher ausgelagert werden. Das geht allerdings zulasten der Geschwindigkeit.
- KV-Cache-Quantisierung: Beim Vergrößern des context window wird empfohlen, den Cache etwa mit q4 zu komprimieren.
Tools und Frontends
- llama.cpp: Läuft schnell und flexibel auf verschiedenen Plattformen. Unterstützt eine REST API und ein einfaches React-Frontend. Modelle können verteilt über VRAM und RAM geladen werden.
- Ollama: Einfache Installation und leichter Modellwechsel, außerdem gute Anbindung an GUI-Frontends. Allerdings gibt es Einschränkungen bei der Unterstützung der neuesten Modelle und bei der context-Größe.
- LM Studio: Komfortable Modellverwaltung in einer GUI-Umgebung. Bietet eine Funktion zur Einschätzung, ob ein Modell in den verfügbaren VRAM passt.
- OpenWebUI: Reines Frontend; benötigt ein Backend wie llama.cpp oder vllm. Mehrere Modelle lassen sich gleichzeitig verwalten und testen.
- KoboldCPP, SillyTavern: Spezialisierte Frontends für Rollenspiel, Storytelling und Spiele.
Community und Praxisinformationen
- Reddit LocalLLaMA, HuggingFace, Discord: Dort werden aktuelle Modellneuigkeiten, Anleitungen, Benchmarks und Setup-Know-how aktiv geteilt. Vorsicht ist jedoch vor Fehlinformationen und groupthink geboten.
- Benchmark-Websites: livebench.ai, aider.chat usw. liefern aktuelle Scores und Rankings für verschiedene Modelle.
Einsatzzwecke und Praxiserfahrungen
- Privatsphäre, Kosteneinsparung: Bei sensiblen Daten, Datenschutzthemen oder wiederholter Nutzung sind lokale Modelle gegenüber der Cloud oft attraktiver.
- Freiheit für Experimente und Tuning: Bei domänenspezifischem Fine-Tuning, Sampling-Strategien und Prompt Engineering sind lokale Modelle flexibler als API-Modelle.
- Anwendungsbeispiele: RAG(Retrieval-Augmented Generation), Anbindung an lokale Datenbanken, Agent-Automatisierung, Offline-Assistenten und weitere praxisnahe Szenarien.
Häufige Fragen und Tipps
- Berechnung der Modellgröße: Anzahl der Parameter × Bit(Quantisierung)/8 = ungefährer VRAM-Bedarf (GB). Overhead und context window sollten ebenfalls berücksichtigt werden.
- Eigenschaften einzelner Modelle: Qwen3 für reasoning/Coding, Gemma3 für Intuition/Konversation, Mistral mit weniger Zensur, Dolphin/abliterated als uncensor-Versionen usw.
- Leistungsvergleich: Es wird empfohlen, per eigenem Benchmarking und individuellen Tests das passende Modell zu finden.
Fazit und Praxishinweise
- Das „beste Modell“ gibt es nicht; je nach Hardware, Einsatzzweck und Vorlieben ist es am sinnvollsten, aktuelle 8B~14B-Modelle wie Qwen3, Mistral oder Gemma3 breit auszuprobieren.
- Da Dateigröße des Modells, Quantisierung und context-Größe entscheidend sind, ist es besonders effektiv, mehrere Modelle selbst zu testen und Community-Tipps zur Optimierung für die eigene Hardware und den jeweiligen Zweck zu nutzen.
1 Kommentare
Hacker-News-Kommentare
Wenn du LLMs lokal ausführen willst, findest du viel Hilfe in der localllama-Community auf Reddit
Ein einzelnes LLM-Modell als das besondere „beste“ gibt es nicht; jedes Modell hat Vor- und Nachteile, daher sollte man mehrere selbst ausprobieren
Zum Beispiel wurde heute das Modell DeepSeek-R1-0528-Qwen3-8B veröffentlicht und zeigt in der 8B-Klasse die beste Leistung bei logischem Schlussfolgern
Und auch die Qwen3-Reihe ist kürzlich erschienen und bietet einen hybriden Ansatz, gute Leistung und mehrere Größen für unterschiedliche Hardware
Qwen3-30B-A3B kann sogar auf der CPU mit brauchbarer Geschwindigkeit laufen
Sogar das Mini-Modell mit 0.6B ist erstaunlich konsistent, was überraschend gut ist
Bei der Nutzung von llama-cpp habe ich Fälle gesehen, in denen das Offloading einiger Tensoren auf die CPU gute Leistung erhält
Normalerweise legt man in llama-cpp die Anzahl der auf die GPU geladenen Layer fest (
-ngl), aber wenn es sich nicht um rechenintensive Tensoren handelt, kann man durch CPU-Offloading GPU-Speicher sparen, ohne langsamer zu werdenIch habe auch eine Arbeit gelesen, bei der nur „heiße“ Neuronen von der CPU geladen werden (arXiv-Link), und ich hoffe, dass man KI künftig auch zu Hause sehr elegant nutzen kann
Ein Hinweis für Leute, die Reddit nicht gewohnt sind
Auf Reddit, einschließlich LocalLlama, gibt es viele Fehlinformationen und auch populäre Falschinformationen, und das Verhältnis von Upvotes zu Downvotes garantiert nicht die Richtigkeit der Inhalte
Präzise, aber trocken erklärte Kommentare sind oft eher unbeliebt, während unterhaltsame, emotionale oder gruppenkonforme falsche Erklärungen häufig populär werden
Wer wie ich schon lange im Web unterwegs ist, kann das grob einordnen, aber wenn man neu in solchen von Gruppendenken geprägten Räumen ist, sollte man Informationen mit Vorsicht aufnehmen
Inzwischen haben die meisten Modelle ein solides Grundniveau, daher läuft es oft darauf hinaus, eine „Modellpersönlichkeit“ zu finden, die zum eigenen Geschmack passt
OP sollte sie einfach nacheinander herunterladen und ausprobieren
Mit 16 GB Speicher kann man mit llama.cpp und teilweisem Offloading auf DDR5 Modelle bis 30B, sogar dichte Modelle, mit „vertretbarer“ Geschwindigkeit betreiben; mit Tensor-Offloading noch besser
Qwen hat als Konversationsmodell ein paar Schwächen
Mistral Nemo, Small und die Llama-3.X-Reihe sind auch heute noch ausgezeichnete Optionen
Gemma 3s sind gut, aber etwas unberechenbar
Wenn du zu Hause etwas auf GPT-4-Niveau brauchst, empfehle ich QwQ
Und es gibt sicher noch weitere gute Modelle, die ich gerade vergessen habe
Ich frage mich, ob es Empfehlungen für Modelle gibt, die man zusammen mit Coding-Tools wie aider oder roo verwenden kann
Es war für mich ziemlich schwierig, Modelle zu finden, die eigenständig gut mit Tool-Use umgehen können
DeepSeek-R1-0528-Qwen3-8B ist ein Modell, das den Chain-of-Thought von DeepSeek-R1-0528 auf Qwen3-8B Base destilliert; bei AIME 2024 liegt es mehr als 10 % vor Qwen3-8B und erreicht das Niveau von Qwen3-235B-thinking
Das zeigt erneut, wie effektiv Distillation ist
Vermutlich ist das auch der Grund, warum verschiedene OpenAI-Unternehmen und Forschungslabore ihren Chain-of-Thought(COT) inzwischen verbergen (Hinweis)
Ich frage mich, wofür die meisten Leute lokale LLMs eigentlich am häufigsten verwenden
Wenn die Hardware nicht extrem gut ist, kommt man an proprietäre Modelle wie Gemini oder Claude kaum heran; auch solche kleinen Modelle scheinen natürlich nützlich zu sein, aber mich interessieren konkrete Anwendungsfälle
Das Unbehagen, Daten an Dritte weiterzugeben
Viele Leute wollen ihre Prompts oder Fragen nicht an externe Dienste senden
Ich probiere für die meisten Prompts zuerst ein lokales Modell aus und erlebe überraschend oft, dass ich in mehr als der Hälfte der Fälle bereits gute genug Ergebnisse bekomme
Jedes Mal, wenn ich keinen Cloud-Dienst nutzen muss, fühlt sich das sehr befriedigend an
Ich denke, die Zukunft lokaler LLMs wird darin liegen, schnell zu entscheiden, welche Aufgaben wie verarbeitet und wohin sie delegiert werden sollen
Also ob etwas lokal über Systeme wie MCP erledigt werden kann, ob System-API-Aufrufe für Kalender oder E-Mail nötig sind oder ob es an das optimale Cloud-Modell weitergereicht werden sollte
Ich stelle mir das wie eine Siri vor, die tatsächlich richtig funktioniert
Ich experimentiere gerade mit einem selbst gebauten lokalen Coding-Agenten auf Basis von Devstral
Was mir im Vergleich zu Codex besser gefällt, ist der vollständige Hardwarezugriff, sodass Dinge wie das Starten von VMs oder Netzwerkanfragen möglich sind, die in Codex nicht gehen
Außerdem ist es vom Setup bis zur Patch-Erstellung viel schneller als Codex
Natürlich erreicht es noch nicht die Ergebnisse von Codex, aber Devstral ist für kleinere Änderungen oder Refactorings brauchbar, und wenn man die Software weiterentwickelt, werden wohl nach und nach auch größere Änderungen möglich
Ich nutze aus Prinzip möglichst wenig Cloud
Es gibt zum Beispiel Berichte, dass OpenAI zuletzt sogar an einer Art sozialem Netzwerk arbeitet, das ChatGPT-Konversationen teilt
Wenn man lokal arbeitet, versteht man auch die internen Funktionsweisen der KI besser, was den eigenen Marktwert steigert
Man kann frei mit LLM-Backends experimentieren, etwa für Websuche oder Agenten, hat keine Cloud-Kosten und hatte vielleicht schon seit der ersten LLaMa ein Gaming-Desktop-System
Das Projekt LocalScore von Mozilla ist ebenfalls einen Blick wert
Ein Dienst, der vergleicht und analysiert, wie gut verschiedene Modelle auf unterschiedlicher Hardware laufen
Ich stimme der Empfehlung für das LocalLLama-Subreddit zu
Es ist nicht dafür da, das „beste Modell“ auszuwählen, aber sehr hilfreich für Fragen, das Finden von Guides, aktuelle Neuigkeiten oder Tool-Infos und Vergleiche verschiedener Modelle
Am Ende geht es darum, selbst mehrere Modelle auszuprobieren und mit den Parametern zu spielen, bis man das findet, was zum eigenen Zweck am besten passt
Als Hacker-News-Nutzer kann man auch erwägen, Ollama oder LMStudio zu überspringen
Der Zugang zu den neuesten Modellen kann eingeschränkt sein, und oft ist man auf die Modelle beschränkt, die sie getestet haben
Außerdem fehlt ein wenig der Reiz, die internen Abläufe „unter der Haube“ zu sehen
Allein mit llamacpp wird die Unterstützung für die meisten aktuellen Modelle abgedeckt, und bei Bedarf kommen Updates sehr schnell
Ich bevorzuge es, Modelle von huggingface herunterzuladen und das GGUF-Format zu verwenden, um durch niedrigere Quantisierung Speicher zu sparen
An der GGUF-Dateigröße kann man grob erkennen, ob es in den VRAM passt (Beispiel: 24-GB-GGUF ist für 16 GB zu viel, 12 GB geht – allerdings steigt mit größerem Context auch der RAM-Verbrauch)
Auch auf das Context Window achten: Ältere Modelle haben meist 8K Context, und selbst wenn man auf 32K stellt, bringt das oft nicht viel
Für llamacpp kann man unter Linux, Windows und macOS Binärdateien herunterladen oder selbst bauen, und Modelle lassen sich zwischen VRAM und RAM aufteilen
Es gibt ein einfaches React-Frontend (
llamacpp-server) und auch eine OpenAI-ähnliche REST-APIDadurch lässt es sich mit verschiedenen Frontends wie oobabooga(textgeneration webui) verbinden
Koboldcpp ist ein Backend, das man in Betracht ziehen kann, wenn llamacpp zu roh wirkt (intern weiterhin auf llamacpp basierend)
Reizvoll an Ollama ist, dass man jedes GGUF direkt von HuggingFace ziehen und mit etwas wie
ollama run hf.co/unsloth/DeepSeek-R1-0528-GGUF:Q8_0ausführen kannEiner der Vorteile von Ollama ist, dass sich Modelle leicht auf die GPU laden und wieder entladen lassen, sodass man in Frontends wie librechat oder openwebui einfach per Dropdown zwischen Modellen wechseln kann
Ich möchte betonen, wie bequem ein Modellwechsel ohne Kommandozeilenarbeit ist
Ollama macht aus dem Desktop einen LLM-Server, auf den auch entfernte Geräte über Wi‑Fi zugreifen können
Beim Modellwechsel kann Ollama nahtlos umschalten, ohne den Server herunterzufahren
Bei llama.cpp muss man in der CLI dagegen den Server stoppen, neue Flags setzen und ihn neu starten, was beim Experimentieren oder bei schneller App-Entwicklung unpraktisch ist
Unter meinen Apps gibt es auch welche, bei denen es zwingend nötig ist, Modelle wie 1B, 8B oder 30B per Web-Request-Parameter umzuschalten, ohne den Server neu zu starten
Ich habe nur 8 GB VRAM, verwende aber OpenWebUI als Ollama-Frontend, lade mehrere Modelle gleichzeitig und teste sie abwechselnd im Round-Robin-Verfahren
Dabei überwache ich fortlaufend auch die Qualität der Antworten und kann langfristig auswählen, welches Modell besser zu meinem Zweck passt
Mit OpenWebUI ist das eine interessante Nutzungserfahrung
Als Nutzer einer AMD 6700XT (12 GB VRAM) konnte ich nach erfolgreichem lokalem ROCm-Setup Ollama problemlos mit GPU-Beschleunigung betreiben
Eine per Docker gestartete OpenWebUI-Instanz mit dem lokalen Ollama-Server zu verbinden, war mit dem Setzen einer einzigen ENV-Variablen erledigt
Das ist keine Produktionsumgebung, sondern eine persönliche Testumgebung, passt aber sehr gut zu dem oben beschriebenen Zweck
Man sollte wissen, dass OpenWebUI seit einer kürzlichen Lizenzänderung nicht mehr Open Source ist
Die Qwen3-Familie (und auch das R1-qwen3-8b-distill-Modell) liegt bei Coding und logischem Schlussfolgern an erster Stelle
Allerdings gibt es wegen der Herkunft aus China bei politischen Themen starke Zensur
Für Weltwissen und aktuelle Informationen empfehle ich Gemma3
Mit hoher Wahrscheinlichkeit ist dieser Beitrag schon in einem Monat veraltet, daher besser die aktuellen Benchmarks auf livebench.ai oder im aider.chat-Leaderboard prüfen
Nicht nur Modelle, sondern auch Tools, Router, MCP, Bibliotheken und SDKs entwickeln sich ständig weiter
Wenn ich allein entwickle und keine Kollegen oder Gruppe zum Austausch habe, brauche ich Ratschläge dazu, wie man Informationen sammelt und aktuelle Entwicklungen sinnvoll verfolgt
Die beste Informationsquelle ist HuggingFace
Die Qwen-Reihe ist insgesamt vielseitig brauchbar, und ich empfehle das Modell Qwen/Qwen3-14B-GGUF Q4_K_M
Es benötigt nur etwa 7–8 GB VRAM und ist daher gut handhabbar; empfohlen sind llama-server oder LM Studio
Llama 3.3 ist ebenfalls eine gute Wahl
Devstral ist zu groß und daher nur als quantisiertes Modell realistisch
Gemma lehnt vieles ab, ist aber für bestimmte Zwecke wie Medgemma nützlich
Eric Hartfords „Uncensored“-Dolphin-Modelle und abliterated-Modelle sind empfehlenswert, wenn man ein Modell ohne starke Zurückhaltung braucht, etwa für Witzgenerierung oder Themen wie Sicherheit und Verteidigung (für Alltagsnutzung nicht zwingend nötig)
Mit
bf16als Datentyp berechnet man die Größe eines unquantisierten Modells grob mit Parameterzahl x2Bei einem mit Q4_K_M(4 Bit) quantisierten Modell entspricht der VRAM-Bedarf etwa der Hälfte der Parameterzahl
Wegen Aktivierungs-Overhead und Ähnlichem sollte man am besten zunächst mit Modellen experimentieren, die deutlich unter 16 GB liegen
llama-server bietet auch eine GUI und unterstützt mit der Option
-hfdas Herunterladen von ModellenLM Studio ist ebenfalls bequem für Installation und Modellverwaltung
Wenn man schnelle Antwortzeiten will, sollte der Server einmal gestartet werden und das Modell für mehrere Anfragen gemeinsam genutzt werden; bei jedem Prompt neu zu laden ist langsam
Bei 16 GB laufen Q4-quantisiertes Mistral Small 3.1 oder FP8 Qwen3-14B ohne größere Probleme gut
Je nach VRAM-Nutzung ist Q4-quantisiertes Qwen3-14B bei langen Context Lengths zwar leistungsschwächer als FP8, bietet aber mehr Speicherreserve
Mistral Small unterstützt auch Bildeingaben, Qwen3 ist stärker auf Mathematik und Coding spezialisiert
Unterhalb von Q4 sinkt die Effizienz, daher nicht empfohlen
Wenn langes Context das Ziel ist, ist Q4-quantisiertes Qwen3-8B die bessere Wahl; Qwen3-30B-A3 dürfte für 16 GB VRAM etwas knapp sein (schwere Modelle belegen in GGUF oft mehr als 15 GB)
Dense-Modelle (alle Parameter werden genutzt) sind bei der Leistung pro Parameter besser als Sparse-Modelle, aber langsamer; auf einer GPU der 5060-Klasse sind 14B angenehm nutzbar
Auf Blackwell-Architektur sind mit NVFP4 quantisierte Modelle schneller als FP8, die Qualität ist aber minimal schlechter; in ollama wird das noch nicht unterstützt, daher braucht man vLLM separat
Vorgequantisierte NVFP4-Modelle sind kaum verfügbar, daher empfiehlt sich die Quantisierung mit Tools wie llmcompressor
Solche Werkzeuge würde ich erst einsetzen, wenn das gewünschte LLM feststeht und man gezielt die Performance verbessern will
Eine objektive, klare Antwort auf die Frage nach dem besten LLM ist nahezu unmöglich; am wichtigsten ist es, selbst mehrere aktuelle Modelle mit Aufgaben auszuprobieren, die für einen persönlich relevant sind
Je nach Aufgabentyp können die Qualitätsunterschiede extrem ausfallen
Ich frage mich oft, wie man den VRAM-Bedarf normalerweise abschätzt
Bei herunterladbaren Modellen wie GGUF steht leider meist nicht direkt dabei, wie viel VRAM oder Speicher sie brauchen
Sehr grob kann man die Parameterzahl (in B) als GB-Speicherbedarf betrachten
Beispiele je nach Quantisierung:
FP16 = 2 x 8GB = 16GB (8B-Modell)
Q8 = 1 x 8GB, Q4 = 0.5 x 8GB = 4GB
In der Praxis weicht das etwas ab, liegt aber meist in dieser Größenordnung; zusätzlicher Speicher für Context Length usw. kommt noch dazu
Das Prinzip ist einfach die Anzahl der Float-Werte multipliziert mit der Bitzahl des Datentyps (4, 8, 16 ...)
Wenn man zusätzlich zur Quantisierung auch Dinge wie den KV-Cache genauer berechnen will, ist dieser VRAM-Rechner zu empfehlen