Lokale LLM als Chatbot

Für reine Benchmarks reicht llama.cpp in seiner puren Form völlig aus, LMStudio nutzt das unter der Haube auch. Wenn es etwas praktischer sein soll, kann man auch die WebUI von llama.cpp server nutzen.

Der Vorteil von LMStudio ist, dass Du schnell und einfach zwischen Modellen wechseln kannst. Klappt mit llama.cpp theoretisch zwar auch, Du musst dir das aber zuerst selbst zusammenfrickeln.
 
Zuletzt bearbeitet:
Also Qwen 3.5-27B-Q4_K_M ist 17,5 GB + 1GB Overhead + 1-2 GB deine Grafikanzeige, + je 8k Kontent nochmal 1 GB (Faustregel, kann stark variieren) dazu wenn du den Kontent nicht auch quantisierst. Macht also > 20 GB. Einen Tick zu groß für deine Karte, damit landet ein Teil im RAM. Zudem nutzt du ein DENSE Modell, kein MOE was auch nochmal Zeit dauert.

QWEN hat ein starkes reasening Modell, braucht also länger bis es eine Antwort herausspuckt. Zum schnellen Chatten manchmal nervig.
Ich nutze Qwen 3.6-35B-A3B Q4_K_M (MOE) für alles, was mathematisch ist, wo ich mehr Wert auf die Qualität lege.
Das Gemma-4-26b-a4b (MOE) Modell hat zwar auch reasening, antwortet aber deutlich schneller. Gut zum Chatten, aber weniger für Agenten, mathematisches etc. läuft bei mir auf einer RX 7900 XTX bei ~110 Tokens/s.
Für schnelle Antworten bei QWEN, nimm QWEN 3.5 9B - entspricht QWEN 3 14B.

Und schau dir erstmal das Thema Systemprompt an. Total wichtig und mächtig. Frag die KI dazu genau aus:
Stell diese Frage:
"Erkläre mir das Thema System Prompt so, als hätte ich noch nie mit KI-Prompts gearbeitet. Was ist ein System Prompt, wofür nutzt man ihn, was darf hinein, was sollte nicht hinein, und wie sieht ein gutes Beispiel aus?"

Schneller Chat, kleines Modell wählen. Tiefgründig mit viel Qualität, dann große Modelle mit MOE nehmen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: valovalo, Snakeeater und TomH22
Snakeeater schrieb:
Ich habe auch noch gar keinen Plan welchen Systemprompt ich tatsächlich nutzen soll für einen lokalen Chatbot.
Ich nutze "use metric/SI units". Sonst gibt der mir bei Englischen prompts miles, feet, pounds, cups, etc

Wenn du viel mehr token/s willst dann MOE versionen ausprobieren. (Qwen 3.6-35B-A3B & Gemma-4-26b-a4b)
 
grand_sniper schrieb:
Schneller Chat, kleines Modell wählen. Tiefgründig mit viel Qualität, dann große Modelle mit MOE nehmen.
Schonmal danke für den hilfreichen Input, ich werde die genannten Modelle mal testen. Aktuell zickt das Gemma bei mir rum, weil es ewig zum laden braucht. Okay, fertig geladen und lande jetzt bei Prompt: 857.4 t/s | Generation: 82.6 t/s das gefällt mir schon ziemlich gut.

Bzgl. der Aussage im Zitat, woran erkenne ich den genau ob ein Modell groß oder klein ist. Nur rein an den Parametern?

Was natürlich noch angenehm wäre ist nun verschiedene Chats getrennt zu speichern, gibt da sicherlich einen Fachbegriff, so dass man auf gewisse Verläufe später zurückgreifen kann. Dazu wäre sicherlich eine UI hilfreich, daher schau ich mir demnächst mal die genannten an.
 
Kleinere MoE-Modelle glänzen meiner Erfahrung nach vor allem in den Benchmarks. Durch die kleinere Zahl an Parametern pro Experte sinkt entsprechend auch die Fähigkeit komplexere Prompts zu verarbeiten und wichtige Fakten zu speichern. In der Praxis bestimmt zudem das Routing, ob dein Prompt vom besten Experten bearbeitet wird.

Snakeeater schrieb:
Aktuell zickt das Gemma bei mir rum, weil es ewig zum laden braucht.
Liegt das Modell auf einer NVMe oder einer SATA-SSD?

Snakeeater schrieb:
Bzgl. der Aussage im Zitat, woran erkenne ich den genau ob ein Modell groß oder klein ist. Nur rein an den Parametern?
Exakt. Kleine Modelle haben 10B (10 billion, also zehn Milliarden) Parameter oder weniger. Mittlere Modelle liegen irgendwo im Bereich von 30B, deutlich jenseits davon würde man von einem großen Modell sprechen. ChatGPT, Claude, Gemini, aber auch LeChat nutzen im Hintergrund vermutlich SEHR große Modelle mit hunderten Milliarden Parametern.

Mixture-of-Experts-Modelle stellen einen Kompromiss dar: Sie bestehen aus "Experten", die jeweils nur einen Teil der Parameter nutzen. Dadurch bekommst du schneller eine Antwort, musst dich aber darauf verlassen, dass der richtige Experte deinen Prompt verarbeitet.

Wichtig ist außerdem der Quantisierungsgrad des Modells. Im Original hast Du in der Regel 16 oder sogar 32 Bit pro Parameter, wodurch selbst kleine Modelle schnell den Speicher der meisten Grafikkarten sprengen. llama.cpp nutzt GGUF-quantisierte Modelle mit "gerundeten" Parametern, die weniger Platz brauchen. Q8 steht für 8 Bit, Q4 entsprechend für 4 Bit pro Parameter. Dadurch sparst Du zwar VRAM, je nach Modellgröße sinkt damit aber auch die Qualität des Modells ähnlich einer verlustbehafteten Kompression (vgl. JPEG).

Snakeeater schrieb:
Was natürlich noch angenehm wäre ist nun verschiedene Chats getrennt zu speichern, gibt da sicherlich einen Fachbegriff, so dass man auf gewisse Verläufe später zurückgreifen kann
Das kann jede GUI (LMStudio, OpenWebUI, llama.cpp Server-GUI, ...). Am Ende des Tages sind das nur einfache JSON-Files.
 
  • Gefällt mir
Reaktionen: Snakeeater
Vielen Dank für die ausführliche Antwort, dass bringt deutlich mehr Licht ins Dunkle. Ich habe den Anfagspost mal erweitert und meinen aktuellen Stand etwas genauer hinterlegt.

Bei den Nachteilen habe ich kursiv mal Punkte hinzugefügt die ich gern versuchen würde zu lösen.
 
Achtung, die Sampling-Parameter sind bei Gemma falsch gesetzt, siehe

https://huggingface.co/google/gemma-4-26B-A4B

im Abschnitt "1. Sampling Parameters". Fehler dort können die Qualität weiter einschränken oder zu unerwünschtem Verhalten führen, etwa endlosen Wiederholungen oder Gibberish.

Beim context size (-c) musst du schauen, ob dir 8192 tokens reichen. Für einfache Fragen und Antworten kannst Du den Wert sogar reduzieren, das spart VRAM. Ein Token entspricht im Schnitt 4 Buchstaben, zumindest in der englischen Sprache.
 
  • Gefällt mir
Reaktionen: Azdak und Snakeeater
Da du es scheinbar auf "Performance" abgesehen hast, poste mal den Rest deines Systems.
Evtl. hast du ja noch woanders ein Bottleneck.

Denn wenn du Flash Attention und mmap benutzt, brauchst du auch viel RAM. Passt es da nicht rein wird es ausgelagert auf die SSD. Bei den ~ 30B Modellen bei nur 32 GB RAM, wirds eng.
 
Zuletzt bearbeitet:
Wüsste jetzt nicht was abseits von 32 GB RAM abseits aus den Informationen aus meiner Signatur dafür relevant wäre.

Wie gesagt die Geschwindigkeit des Gemma models ist für mich aktuell absolut ausreichend.
 
Snakeeater schrieb:
Im Grunde nutze ich die Chatbots als schlauere Internetrecherche.

Wenn dir die Informationen genügen, die vor dem Knowledge Cut-Off im Modell gelandet sind, und du nicht auf neueste quasi tagesaktuelle Informationen zugreifen möchtest, funktioniert das bestimmt ganz ordentlich.
Beim Web Crawling sind die lokalen Modelle aber um Lichtjahre den großen Online LLMs unterlegen.

Wenn du quasi instantane Antworten möchtest, probier mal das neue Gemma 26b MoE Modell aus! Sollte auch deinem Bedarf als Erklärer gut entsprechen.
 
  • Gefällt mir
Reaktionen: Snakeeater
Interessant, das Web Crawling steht auf meiner Liste um eben dem Cut-Off entgegen zu wirken. Aber schon einmal gut zu wissen das ich hier deutlich schlechtere Performance erwarten kann. Ich werde es trotzdem mal ausprobieren wenn ich dazu komme.
 
Rein autoregressive Sprachmodelle ohne Anschluss an eine Wissensquelle würde ich keinesfalls für die Recherche nutzen. LLMs sind nicht für Fragen gedacht, die sich exakt beantworten lassen, sondern generieren als Antwort stets eine Synthese von Häppchen der Traingsdaten - wobei diese Häppchen auch nur näherungsweise erzeugt werden können. Diese Antwort passt statistisch zu den erlernten Mustern, passt aber nicht zwangsläufig genau zu den Inhalten der Trainingsdaten.

Das funktioniert super beim Brainstorming, wenn es nicht um präzise Antworten geht und überall dort, wo sich aus den Traingsdaten sinnvolle übergeordnete Muster ergeben, etwa beim Coding (Stichwort Syntax). Aber für exakt lösbare Fragen würde ich immer empfehlen eine Suchmaschine zu nutzen oder das LLM mit einer Datenbank zu koppeln (Stichwort RAG).
 
  • Gefällt mir
Reaktionen: madmax2010 und grand_sniper
SirKhan schrieb:
koboldcpp hat alles in einer Binary gebündelt. Einfach starten und fertig. Läuft mit GGUF. Implementiert aktuelle Standards. Hat sogar eine eigene (optionale) Chat-Oberfläche. Für AMD funktioniert die Vulkan-Variante sehr gut.

Ansonsten ist wohl ollama die einsteigerfreundliche Version von llama.cpp.
Ich hab gerade ollama-rocm auf CachyOS am laufen. Da ist das direkt im Paketmanager anklickbar und funktioniert auch direkt.
Ist das Ding Portabel? Falls ja, mal mit Gemma 4 27b (oder waren's 28) getestet? Liest sich echt gut bei GitHub.
 
@Keuleman Jo, läuft direkt überall ohne Installer. Ich habs schon auf Windows und Linux mit AMD und Nvidia getestet. Mit Gemma 4 allerdings noch nicht (wird aber wohl seit 1.111.2 unterstützt).
 
  • Gefällt mir
Reaktionen: Keuleman
Ich bin begeistert, nicht der Threadersteller aber sowas habe ich gesucht. Besonders die Fähigkeiten, auch Bilder etc generieren zu können... gucke ich mir alles mal an!
 
Ich nutze aktuell Ollama (gemma4:31b) mit Open-Web-UI und es ist das erste Mal, dass die Qualität aus meiner Sicht mit Cloud-Chatbots mithalten kann. Leider ist die Performance, v.a. mit einem großen Kontext, sehr schlecht (einstellige T/s), aber ich hatte auch noch keine Zeit, um da irgendwelche Änderungen vorzunehmen (quantisieren usw.) und es scheint auch die GPU gar nicht kaum (edit) zu nutzen, was ich mir auch noch näher anschauen muss. Für Aufgaben, die nicht schnell sein müssen, z. B. das Zusammenfassen von großen PDFs, Überarbeiten von Texten/fertigem Code, bin ich aber hochzufrieden. Hardware ist ein Thinkpad P16 mit i9 (13. Gen), 192 GB RAM und RTX 3500 (12GB VRAM).
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: drake23
Von "Nachteilen" würde ich nicht unbedingt sprechen.

# Performance/Anforderungen an Hardware
Hält sich in Grenzen: Ich fahre eine RTX 5060 16GB vRAM ti für große Sachen, und wenn es Zeit hat,
nutze ich eine Kiste ohne extra GPU: CPU: AMD Ryzen 5 5500U with Radeon Graphics (12) @ 2.100GHz. Es
ist eine Frage der Optimierung, nicht der reinen Gewalt.

# nur lokal verfügbar (mit gewissem Aufwand kann man das umgehen)
Ich würde "nur" streichen. Das ist gerade der Vorteil, wenn man die Hoheit über seine Daten behalten
will. Wer von unterwegs Zugriff braucht, baut sich ein VPN (z.B. Wireguard) auf – dann ist die
"Limitierung" Geschichte und man behält die volle Kontrolle.

# je nach Anwendungsfall versch. Modelle nötig die Storage verbrauchen
Ja, so ist das in der Welt – ohne ein gewisses Maß an Speicher funktioniert nicht mal ein OS. Auf
der anderen Seite sind gerade quantisierte Modelle nun auch nicht so riesig, und die laufen dann
sogar langsam auf einem Raspberry Pi 5 :-)

# Gedächtnis nicht vorhanden
Das kannst du mit einem RAG ändern. Ich behaupte sogar, dass es elementar ist, ein RAG – besser: ein
Hybrid-RAG – zu implementieren, wenn man das LLM nicht nur als Spielzeug verwenden will. Wer einmal
gesehen hat, wie man die KI mit eigenen Daten füttert, sodass sie wirklich weiß, wovon sie redet,
der will nicht mehr zum "nackten" LLM zurück.

# Cutoff der Trainingsdaten liefern ca 2 Jahre alte Informationen (besonders bei IT Themen stellenweise ausschlaggebend)
Auch hier kommt wieder das RAG ins Spiel. Dem Modell werden dann einfach die nötigen Infos
"zugeflüstert", sozusagen vom Influencer-RAG. So wird das Modell an deine aktuellen IT-Dokus und
Datenbanken gebunden und halluziniert nicht mehr.

# Hardwareisolation/containerization gar nicht so trivial (rootless)
Bin nicht sicher, was du genau für ein Problem meinst, aber sowas wie Docker, QEMU, Proxmox (für das
schöne Setup) oder OpenStack (wenn es eine Nummer größer sein soll) sind doch genau dafür da.
Rootless-Betrieb und saubere Isolation sind bei modernen Setups heute eher die Kür als ein
unlösbares Problem.


LG Olav

PS: Ich fahre mein Setting mt Ollama, und auf Blech, lama.cpp hatte ich mir angesehen, aber nur um 2% mehr Power zu bekommen, ewig zu basteln, war es mir dann nicht Wert. Müssen dann doch in den Settings der Modlele geöndert werden lege ich dafür einfach ein neues Modelfile an :-)
 
  • Gefällt mir
Reaktionen: C0r3 und SirKhan
Ganz komischer Post.

Ich werde mir definitiv mal anschauen wie genau man so einen RAG einbindet und nutzt.
 
Keuleman schrieb:
Ich bin begeistert, nicht der Threadersteller aber sowas habe ich gesucht. Besonders die Fähigkeiten, auch Bilder etc generieren zu können... gucke ich mir alles mal an!
Probiert und bleibe dabei! Genau das, was ich gesucht habe. Besten Dank für die Empfehlung!
 
  • Gefällt mir
Reaktionen: SirKhan
Habt ihr Tipps wie man passende Modelle für verschiedene GPUs wählt? Reicht es hier anhand des VRAM und möglichem Nutzungsszenario zu entscheiden? Wie berrechne ich die Quantisierung mit ein? Wie bleibt ihr auf dem aktuellen Stand bzgl. neuer Modelle?
 
Zurück
Oben