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.