Erfahrungsaustausch zu lokal LLM workflow

[schumischumi]

Hi
ich wollte mich hier mit euch austauschen wie ihr lokale LLMs nutzt und würd gern voneinander lernen.
Vor allem welches tooling und workflows ihr nutzt.

Ich würd da einfach mal mit meinen Erfahrungen und den Problemen auf die ich gestoßen bin starten.
Das Kernproblem für mich ist, dass ich im Endeffekt unendlich Tokens habe, allerdings sehr begrenzte Tokens in einer Session (context window durch VRAM/RAM) begrenzt.
D.h. ich kann ein Projekt in einer Session starte und evtl sogar die Änderung die ich machen möchte implementieren. Wenn ich aber eine neue Session auf der selben Codebase aufmache um z.B. Nachzubessern oder ein neues Feature hinzuzufügen, muss das LLM erstmal einen großen Teil meines context windows dazu verwenden um wieder auf Stand zu kommen.

Ich würds mal am Beispiel des dungeon game promt hier erläutern https://github.com/lukesdevlab/youtube/blob/main/prompts/dungeon-game.txt
Verwendet habe ich gemma 4 12b qat in lmstudio mit pi und opencode mit 16gb vram und 32gb ram. context wurde auf vollen vram gemaxt.

Nach der initialen Erstellung war meine Folgeaufgabe (simplifiziert): erstelle eine Treppe über die man in das nächste dungeon level kommt. die Treppe soll eine neue dungeon Generierung triggern

Ich hab mich dann dem Problem genähert wie ich es ohne LLM machen würde:
Cleaner Code/Structure:

• Ich hab nicht alles in eine HTML schreiben lassen, sondern in mehrere einzelne die auch durch den Namen identifizierbar waren
• die Hoffnung war dass das LLM beim erweitern nur noch weniger Dateien lesen und editieren muss.

=> es hat es auch besser gemacht aber nicht um super viel

Planning:

• Session 1: Bevor implementiert wird, erstelle ein PLAN.md mit Aufgaben die implementiert werden müssen
• Session 2: Implementieren punkt 1 aus PLAN.md
• Session 3: Implementiere Punkt 2 aus PLAN.md usw

=> Es hat es leider schlechter gemacht. das LLM war in der Lage ein relativ gutes Ergebnis in einem one-shot ohne Planung zu machen, aber mit Plannung hat es im Endeffekt nur länger gedauert und es wurden ein paar Fehler mehr eingebaut.

Spec based Entwicklung:

• Annahme: Wenn es durch meine Plannung schlechte wurde, habe ich wahrscheinlich schlecht geplant. Durch spezifikationen muss es darduch besser werden
• In der Arbeit hatte ich mit openspec (claude bzw. copilot als backend) ganz gute Ergebnisse bekommen, aber lokal ist das LLM hart überfordert und kann die Plannung nichtmal richtig abschließen
• Dann hab ich ein kleineres Framework probiert mit open-gsd (getting shit done), leider Ähnlich. Die Plannung überfordert das Model
• auch https://github.com/PatrickSys/workspine war leider nicht viel besser

Mein Grundgedanke war:
Wie bei menschen würde ich die Aufgaben in kleinere Teile aufteilen (Epics, Stories, Tasks) die unabhängig voneinander implementiert werden können. Wenn die einzelne Aufgabe klein genug ist sollte das context window kein Problem sein.

Das was ich unterschätzt habe, ist das der menschliche Entwickler über die Dauer die Codebase (zu einem gewissen Grad) ins Langzeitgedächnis legt und dadurch nie vom Anfang starten muss.

Da sehe ich auch noch das größte Potential:

• code leichter verstehbar machen, durch indexierung
• persistierung des codebasewissens durch vector oder graphdb

Bevor ich dort weiter mache würd ich mich aber gern mit euch austauschen.

Wie geht ihr mit diesem Problem um?
Wie sieht euer Workflow aus?
Nutzt ihr Plugins/Skills die das Problem komplett lösen?

 

[chr1zZo]

Lokale Modelle dieser "kleinen" größe wie 12B können eben nicht mehr, erst Recht nicht Gemma. Da finde ich Qwen viel besser. Frontier Modelle Arbeiten weitaus besser. Da kannst du noch so gut mitdenken und Planen, das wird nix.

 

[schumischumi]

Ja klar sind die online frontier modelle besser. steht ja auch garnicht zur debatte. find qwen auch super. nehme qwen 3.5 9b als daily driver und 3.6 27 bzw. 35b für spezialaufgaben.
gemma 12b hat schon ein recht gutes Ergebnis im one-shot erzeugt, mit dem level wär ich hier schon zufrieden.
Mich stört vor allem, dass es durch planung schlerchter wurde.

mir gehts hier eher um techniken wie man damit effizienter arbeitet. das lässt sich ja auch auf frontier modelle übertragen um besser und sparsamer damit zu entwickeln

Daher die Bitte: hier keine diskussion ob lokale llm entwicklung sinn macht oder warum frontier modelle besser/schlechter sind.
Ist einfach nicht der Scope meines Posts.

 

[Tornhoof]

Wenn die einzelne Aufgabe klein genug ist sollte das context window kein Problem sein.

Jein, wenn das Modell irgendwann der Meinung ist, dass es der Meinung ist es braucht Zusatzinformationen, dann greppt es sich durch den ganzen Quelltext und füllt deinen Kontext auf und dann schmeißt die Kompression relevante Teile raus.

Dein Ansatz es zu trennen in kleine Module ist schon richtig, viel bessere Ansätze gibt es nicht.
Du kannst natürlich versuchen die eigentliche Kontextgröße zu reduzieren, zb mit einem caveman skill. Du kannst auch deinen Quelltext mit entsprechenden Claude.md etc. Dateien versehen, die nur bestimmte Aspekte beschreiben.
Ist aber viel ausprobieren.

 

[adfsrg]

Lass doch die Planung von einem Frontier-Modell machen und das lokale führt den Plan nur aus.

 

[schumischumi]

aktuelle idee:

• eine light version von https://github.com/skhoroshavin/pi-supergsd/tree/main/skills erstellen (wenn jemand schon sowas kennt gerne linken) die explizit auf kleine context windows ausgelegt ist und context-mode verwendet
• context-mode verwenden um MD files und code zu indexieren und zu durchsuchen https://pi.dev/packages/context-mode

light version workflow idee (sehr grob):

• plan stage: ein plan, multiple tasks
• execution stage: implementierung eines tasks
• review stage: optional, review eines tasks
• finalize stage: entscheiden ob tasks erfolgreich implementiert wurde oder ob plan + execution stage wiederholt werden muss

Lass doch die Planung von einem Frontier-Modell machen und das lokale führt den Plan nur aus.

klar gehts aber es geht mir ja drum es konzeptionell so zu gestalten dass es auch kleine on prem modelle können. frontier modell verwenden ist halt (in dem kontext) immer ein design problem mit leistung zu erschlagen.
für die arbeit für die ich bezahlt werden auf jeden fall der richtige weg, aber für das hobby projekt will ichs anders machen

 

[schumischumi]

Hab heut noch bissl rumgespielt und mit dem skillset funktionierts sehr viel besser https://codeberg.org/schumischumi/pi-gsd-light und verwendet den context-mode

die tasks können auch im kleinen kontext fenster von 32k bei qwen3.6 27b (ca 30 token per second) gut implementiert werden.

Spoiler: llama.cpp qwen3.6 27b

llama-server -m unsloth/Qwen3.6-27B-MTP-GGUF/Qwen3.6-27B-IQ4_NL.gguf \
-ngl all \
--fit on \
--fit-target 1024 \
-c 32000 \
-fa on \
-ctk q8_0 \
-ctv q8_0 \
-np 1 \
--spec-type draft-mtp \
--spec-draft-n-max 2

überrascht hat mich gemma 4 26b und 62k window. da gehts um ein vielfaches schneller (ca 140 token per second) und das ergebnis ist auch gut und konsistent. Tatsächlich war auch das arbeiten damit problemloser.

Spoiler: llama.cpp gemma 4 26b

llama-server -hf unsloth/gemma-4-26B-A4B-it-qat-GGUF:UD-Q4_K_XL \
-ngl all \
--fit on \
--fit-target 512 \
-c 62000 \
-fa on \
-ctk q8_0 \
-ctv q8_0 \
-np 1 \
--spec-type draft-mtp \
--spec-draft-n-max 2

bei interesse könnte ich das durch das llm erstellt git projekt publishen. da sieht man pro commit recht schön was es gemacht hat.

 

[valovalo]

Moin,
ich denke, da muss man die Modelle noch ein wenig spezieller auswählen. Qwen-Modelle sind gut, aber auch nicht für alles.

Ich hatte mir beispielsweise einen kleinen E-Mail-Chatbot gebaut, der auf E-Mails antworten sollte. Mit den Qwen-Modellen ab 9B gab es nur schlechte oder gar keine sauberen Antworten – das ließ sich auch durch strikte System-Prompts nicht ändern. Als ich dann spontan ein anderes lokales Modell eingesetzt habe, hat der Bot sofort funktioniert. Man muss also eben erst immer alle Modelle in aller Ruhe testen; dann sind sie manchmal sogar den Riesen-Modellen überlegen.

Beispiel Gemini: Das vergisst im Chatfenster ständig Instruktionen (da können wir sicher ein eigenes Hybrid-RAG vertragen) und hat auch Probleme, sauberen Markdown-Code auszugeben. An einem Tag geht es, an einem anderen Tag geht es ums Verrecken nicht. Schicke ich die Anforderung, einen Text mal schnell in Markdown zu formatieren, dagegen an ein Qwen-Modell: Zack, hab ich meinen Markdown-Text!

Man muss also die Modelle herausfinden, die für das jeweilige Setting optimal sind.

Die Plannung überfordert das Model

Ja, und genau hier muss man ansetzen, denke ich: Erstmal ein großes Modell finden, welches planen kann. Und den Plan dann an ein ausführendes Coding-Modell übergeben – sowie eines dazustellen, welches das Ganze überprüfen kann.

Ein solches multi-agentisches Setting wird die Lösung sein. Anders bauen es die großen Anbieter mit ihren Frontschweinen (LLMs) im Hintergrund schließlich auch nicht zusammen.

LG Olav

 

[Enurian]

Wenn du selber kein Softwareentwickler bist, kannst du das vergessen. Die kleinen Modelle muss man sehr stark lenken und korrigieren, damit das Produkt wartbar und lauffähig bleibt. Selbst aktuelle high-end-Modelle können auf die schiefe Bahn geraten und ihre Prinzipien vergessen. Deshalb merkt man, wie immens auf "validiere, validiere, validiere" in neueren Models und Agenten Wert gelegt wird. Damit selbst wenn die Architektur Scheiße es, es doch irgendwie lauffähig bleibt.

Jedenfalls, ich dachte auch, lokal wäre ja nett für Kleinkram, aber am Ende ist man selbst bei diesem Kleinkram dermaßen mit Nacharbeit beschäftigt, dass es die 2 Cent um es mit Deepseek oder 5.6 Luna zu machen einfach wert sind.

Davon ab: das 27B fand ich nicht sonderlich gut nutzbar mit 16GB VRAM (kein vernünftiger Quant machbar), daher war das 35B (Balanced / Quality https://huggingface.co/mudler/Qwen3.6-35B-A3B-APEX-GGUF) am praktikabelsten. Kontextgröße >120k und akzeptable Geschwindigkeit.

 

[schumischumi]

Ja, und genau hier muss man ansetzen, denke ich: Erstmal ein großes Modell finden, welches planen kann. Und den Plan dann an ein ausführendes Coding-Modell übergeben – sowie eines dazustellen, welches das Ganze überprüfen kann.

ja stimme da zu.
grade lass ichs n python gui tool for llama.cpp bauen (mich nervt jedes mal die commands aus der history zu laden).

Spoiler: prompt

a tkinter-based Python frontend for llama-server (llama.cpp) with these finalized specs:

---

## Core Features

• Full parameter UI: Expose all llama-server --help parameters with CLI descriptions.
• Dynamic refresh: Button to re-parse llama-server --help and update the UI.
• Profile system: Save/load YAML profiles to/from ~/.config/llama-gui/profiles/.

## Smart Behavior

• Auto-set LLAMA_CACHE: When -hf is used, set LLAMA_CACHE to a user-configurable folder.
• Command parsing: Support both short (-hf) and long (--hf-repo) parameter forms.
• Command generation: Output field for copy-paste, plus a button to start the server in the background.
• Server output: Dedicated window for stdout/stderr from the running process.

## VRAM Calculator
- LM Studio-style: Estimate VRAM usage based on:
- Model size (from -hf or file path)
- Context window (-c)

## Platform & Tech Stack

• OS: Linux (primary)
• Language: Python
• UI: tkinter
• Profiles: YAML

---
Example command to support:

llama-server -hf unsloth/Qwen3.6-35B-A3B-MTP-GGUF:UD-Q4_K_XL -ngl 99 -c 8192 -fa on -np 1 --spec-type draft-mtp --spec-draft-n-max 2

was für mich gerade ganz gut funktioniert ist mit qwen3.6 35b mtp (selber llama-server command wie für 27b oben) bei ca 30-40 token/sekunde das planning zu machen (skills sind noch nicht top. muss es hart abbrechen sonst implementiert er gleich) und dann mit gemma 4 26b quat zu implementieren. beide 62k context. gemma frist halt die tokens wie sau mit 140 tokens/sec.

das erste projekt war explizit on html/js/css projekt weil ich da das letzte mal was sinnvoll vor 20 jahren gemach hab und somit auch die zuschauer / PO rolle einnehmen musste.
das andere jetzt mit python weil ich da die code qualität besser beurteilen und ein sinnvolles review machen kann.tkinter nicht weils so schön ist, sondern weils n standard lib ist was anscheinend sehr gut für llms sein soll.

evtl muss ich noch untersagen, dass tests direkt mit implementiert werden. glaub da ist einfach zu viel.

Falls ihr tipps habt welches model sich fürs planning besser eignet (darf auch größer / langsamer sein, dann läuft halt in RAM über) gern her damit.

gemma 4 26b quat ist für mich grad der sweet spot beim implementieren. wobeis auch halb so schnell und dafür bissl schlauer bzw. token sparsamer sein dürfte.
als alternative hatte ich heut https://huggingface.co/bartowski/Kwaipilot_KAT-Coder-V2.5-Dev-GGUF IQ4_XS mit dem selben plan getestet und das war gut lansamer ~40 token/sek (wär noch ok) und vor allem schelchter. hat die story 1 (parser + widget) vom plan nur sehr schlecht umgesetzt.

update: war recht fix fertig https://github.com/schumischumi/ai_slop_llama_gui/commits/main/ und musste nur leicht nachbessern. der letzte llm commit war feat: complete Story 4 - polish UI

Falls es euch interessiert hab ich die pi sessions exportiert https://github.com/schumischumi/ai_slop_llama_gui/tree/main/docs/sessions