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

 

[derbe]

Hey, ich versuche mir auch gerade lokal etwas aufzubauen. Ich habe aktuell einen recht alten PC mit 2x RTX 3090. Leider kann die alte CPU nicht alle nötigen Befehlssätze, daher muss ich das wohl bald ersetzen. Bin quasi stuck mit llama.cpp. Für vLLM braucht es eine neuere Plattform, das soll wohl deutlich besser bei Multicalls sein. Aber das kommt bald. Die GPUs habe ich recht günstig geschossen.

Erstmal habe ich selbst alles via CLI gemacht, dann bin ich viel auf Skills umgestiegen, was schon mal geholfen hat. Sofern möglich, so viel wie es geht deterministisch geschaltet hat auch geholfen.

Dann habe ich vor ca. 2-3 Wochen mit Hermes Agents angefangen und mir dann ein „Team“ aufgebaut. Es gibt alle möglichen Rollen wie PO, Dev, QA usw. Zuerst habe ich mir testweise das große Abo von Kimi K3 geholt, als es neu war, und alle damit ausgestattet. Du kannst dir sicher denken, dass es nach knapp 2-3 Tagen einfach leer war bzw. das Wochenlimit reingehauen hat. War aber erstaunt, was alles möglich ist. Bugs fixen, Neues implementieren und auch 3D-Grafiken. Alles echt gut.

Gut, dann habe ich überlegt: Wie bekomme ich das besser hin? Wobei das schon echt gute Ergebnisse produziert hat, hier und da hat es aber noch ab und zu gehakt.

In der Zwischenzeit ist DeepSeek V4 Flash gedroppt und ich habe mal $5 aufgeladen und war erstaunt, wie gut es für den mega günstigen Preis klappt. Habe dann recht viel damit gemacht, knapp 4 Billionen Tokens Input +/- für knapp $25 rausgehauen. Das hat auch recht gute Ergebnisse erzeugt, aber ich merkte: Wenn du das alles noch ausbauen willst, wirst du arm davon. DeepSeek soll aber wieder raus, weil nach ein paar Tagen direkt die Meldung kam, dass alles bald viel teurer wird Bin mir recht sicher, dass P/L trotzdem immer noch auf Platz 1 bleibt. Und es cached bei mir wie irre, 95 % und mehr. Btw: Cache kostet in der Regel viel weniger als nicht gecachte Tokens.

Dann bin ich noch mal zu Qwen 3.6 27B Q4 gekommen und habe damit ein bisschen getestet. Das war bei mir gut genug, um, sagen wir mal, einfache Aufgaben zu erledigen. Dann dachte ich mir: Mach einfach eine Q5-Version auf beide Karten mit Split und 256k Kontext. Das war auch okay, hat aber recht lange gedauert, bis gewisse Tasks fertig waren. Habe dann auch die schweren Tasks damit machen lassen. Es ging, aber dauert teils recht lange. Was, denke ich, auch teilweise dem geschuldet ist, dass meine Karten hart gedrosselt laufen.

Dann habe ich festgestellt, dass, wenn beide Karten richtig Gas geben, mein Netzteil nicht mehr reicht. Bin noch im Urlaub, daher muss das warten. Greife atm nur remote drauf zu und teste rum. Also beide Karten hart gedrosselt, aus je 125 W. Damit sind die dann beim Generieren echt lahm. Aber gut, der Speed ist echt runter mit Qwen, aber es kann echt mehr als gedacht. Ich bin davon ausgegangen, dass es nichts ordentlich hinbekommt.

Btw: Mit Q4 3.6 27B konnte ich je Karte inkl. MTP 2 Slots fahren, mit je 96k Kontext. Durch die kleinen Tickets war das nie ein Problem. Habe noch einen Skill, der das Repo gut beschrieben hat.

Für den, den es interessiert: Es ist ein Vampire-Survivor-Clone in 3D im Western-Style, damit kommen die Agenten gut klar. Und ich hatte mal das 35B A3B auch von Qwen getestet. War schlechter als 27B, aber für Kleinkram viel schneller, ca. 3x!

Gestern ist Qwen 3.8 27B gedroppt. Das läuft aktuell auf beiden Karten, einmal mit Vision, einmal ohne. Die ohne hat dann mehr Kontext für, sagen wir mal, größere Aufgaben. Die zweite Karte ist für Kleinkram. Da bin ich noch dabei und steuere zwischendurch mal im Hermes, wenn ich vom Pool und Strand zurück bin. Aktuell nutze ich Kimi K3, um Hermes maximal zu optimieren, wenn Fehler oder Probleme aufkommen.

Was ich noch unbedingt machen möchte:

1. Dickes Netzteil rein, dann schauen, wie viel man aus den Karten rausbekommt.
2. Das System noch besser aufteilen. Ich glaube, nur lokal oder nur Cloud ist nicht optimal.
3. Überlegen, wie ich es noch autonomer hinbekomme, damit ich, sagen wir mal, nur noch detaillierte Epics abgeben muss und am Ende ordentlich Qualität bekomme.
4. Einen anderen PC, damit ich auch mit vLLM testen kann. Das soll wohl einen dicken Boost bringen ab 2 Usern gleichzeitig. Bin gespannt, vielleicht noch mit SGLang rumspielen und mit allem, was es noch so gibt, checken, was am besten zu meinem Fall passt.

Das kommt aber frühestens nächstes Wochenende.

Da will ich hin: maximal ein Abo, was API-Key anbietet, als Steuer- und Planungshilfe. So viel es geht lokal, sofern es nicht zu stark bremst. Und ich denke, der größte Teil, wenn Cloud, dann DeepSeek Flash V4. Die mega harten Aufgaben dann via Abo. Möchte noch Qwen 3.8 Max testen, kommt nach Kimi K3, wenn das Abo in knapp 1,5 Wochen abläuft.

Wie schaut es bei euch aus? Freue mich über Fragen, Erfahrungen etc. Bestimmt habe ich hier und da noch was vergessen. Sorry, alles am Handy am Strand getippt

Habe mir ein kleines Interface gebaut, damit ich grob sehen kann was wie läuft:

// Habe es mal besser formulieren lassen.. das war ja grausam

 

[schumischumi]

Super interessant. hatte heute tatsächlich eine ähnliche Idee für einen orchtestrator und wollte schon fast anfangen ne TUI in python zu bauen.
glücklicherweise davor noch mal geschaut obs jemand schonmal gemacht hat und bin auch https://pi.dev/packages/pi-subagent-workflows gestoßen.
das kann ich glaub ich ganz gut mit den gsd-light und context mode skill verbinden um nach den brainstorming/planning in einen entwicklungsloop mit starken reviews zu kommen.

Kann man deine skills irgendwo einsehen? Würden mich sehr interessieren
meine haben definitiv noch probleme mit der abgrenzung (nach dem planning läuft das model teilweise direkt in story 1 weiter) und auch das planning an sich ist noch zu schwach bzw. die stories sind noch nicht gut genug.

wenn ich morgen mal zeit hab werd ich den subagent-workflow testen und die skills verbessern. und evtl qwen3.8 angucken...
Nächstes Ziel wäre es so eine art workflow pro "epic" abzubilden (nicht 100% sauber):

Hardware habe ich eine amd 9070xt mit 16gb vram, einen 9700x und 32gb memory.
Habs gerade noch rechtzeitig im August / September letzten Jahres gekauft bevors komplett eskaliert ist...

update: das subagent module läuft zumindest nicht super easy out of the box. liegt wahrscheinlich auch an meinem fehlenden verständnis von js/ts.
da ich dieses verständnis auch nicht wirklich aufbauen will, bin ich kurz davor ne python tui zu baun. evtl n guter test für qwen3.8. des benchmark video von lukes dev lab verspricht ja viel.

 

[derbe]

@schumischumi​

Was ich echt hart gelernt habe, ist: Deinen Orchestrator, der aus dem Epic die Stories schneidet, musst du so einstellen/erziehen, dass er bei allem, wo er „raten“ muss, was du meinst, dich einfach eiskalt bei allem, was nicht 100 % klar ist, nachfragt. Und wenn du vorher Brainstorming machst, nimm nicht den gleichen Agenten dafür! Das war bei mir der dickste Boost. Seitdem sind kaum bis gar nicht, sagen wir mal, Sachen umgesetzt worden, bei denen ich mir dachte: „Warum ist das jetzt so?“


Was ich noch machen würde: Pack nach der Implementierung einen QA-(Qualitätssicherungs-)Agenten rein. Der darf sich nicht den Code anschauen, nur die Story und die AC (Akzeptanzkriterien). Danach soll er a) deterministische Tests (Regressionstests) schreiben/bauen und prüfen, ob die Story wirklich das tut, was sie soll. Dann hast du auch die Sicherheit, dass, selbst wenn in Zukunft etwas in die Hose geht, das sofort auffällt. Meiner darf Bugfix-Stories für die Dev-Agenten schreiben, aber nichts selbst fixen. Das klappt ganz gut. Vielleicht meinst du das schon mit deinem „Reviews Stories“, aber so wäre es sauber.


Das waren bisher so die Learnings, die echt viel gebracht haben.



€: Kurzes update bin bei Qwen auf -> Qwen3.8-27B-UD-Q4_K_XL.gguf für DEV umgestiegen das soll noch mal besser sein, dafür kostet es etwas mehr platz auf der GPU, bisher kann ich mich aber auch nicht über die Qualität beschweren, Qwen ist echt gut geworden

 

[schumischumi]

danke für den input.
der QA ansatz ist gut und ich überleg auch schon länger auf der arbeit weg von unittests und coverage zu gehen und dafür black-box tests zu verwenden.
kenn das von ausflug in ne test-manger tätigkeit, dass man pro feature das bei den devs angefragt wurde eine excel list gemacht hat, bei der man sich tests und testdaten überlegt hat die das feature danach z.b. in der webui erfüllen muss.
Excel muss ich jetzt nicht mehr haben (auch wenn das besten mini-datenbanksystem, prototyping app und vieles mehr ist) aber die logik "ich denke meine tests unabhängig von der implementierung und prüfe sie gegen das fertige artefakt" gefällt mir immer besser.
gerade wenn unittests eh von der KI geschrieben werden und mich eigentlich nicht mehr interessiert ob die unit das macht was sie soll oder was sie überhaupt macht.
ich will ja keine neue unit als feature sondern hab ein non-technical requirement.
hab mein skill set nochmal bissl aufgebohrt https://github.com/schumischumi/pi-gsd-light (und wegen der LLM regelungen von codeberg nach github umgezogen).
Ist noch nicht durchgetestet aber hoffe dass es besser funktioniert.

das workflow tool ist leider noch nicht viel weiter bzw. qwen3.8 plant grad noch fleissig. generell soll das tool auf basis der ordner die das skillset erstellt ein workflow zu erstellen/rendern und dann ausführen.
beispielsweise sowas (mockup und noch nicht final):

tooling:
    - name: pi
      command: pi
      task-arg: '-p "<taks-command>"'
      task-arg-interactive: '"<taks-command>"'
      provider: "crossbar-llamacpp-127-0-0-1-8080"
      model: "unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_XL.gguf"
workflow:
    tooling: pi
    epic:
        name: epic-1
    tasks:
        - name: implement-story-1
          command: "/skill:light-execution Story 1"
          type: single
        - name: review-fix-loop-story-1
          type: loop
          break-condition: "REVIEW STATUS: PASS"
          loops: 5
          tasks:
            - name: review-story-1
              command: "/skill:light-review Story 1"
            - name: fix-story-1
              command: "/skill:light-fix Story 1"
        - name: implement-story-2
          command: "/skill:light-execution Story 2"
        - name: review-fix-loop-story-1
          type: loop
          break-condition: "REVIEW STATUS: PASS"
          loops: 5
          tasks:
            - name: review-story-2
              command: "/skill:light-review Story 2"
            - name: fix-story-2
              command: "/skill:light-fix Story 2"

        - name: finalize-epic-1
          command: "/skill:light-finalize epic 1"
          interactive: true

zu qwen3.8:
läuft und ergebnisse sehen hochqualitativ aus, aber glaub die parameter die ich verwende sind nicht optimal. aktuell nur ~ 7 token pro sekunde.

llama-server -m unsloth/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_XL.gguf  \
--fit on   --fit-target 265   -c 65536   -fa on   -ctk q8_0   -ctv q8_0  \
 -np 1 --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 --presence-penalty 0.0

 

[Azdak]

Da du auch Pi zu nutzen scheinst (ich mag den sehr), wenn man Dateien mit @ referenziert müssen sie nicht gesucht werden. Alleine so was hilft manchmal enorm. Ansonsten habe ich mir angewöhnt, nach einer weile die Session-Files nach Dingen auszuwerten, die via deterministischen Code anstelle von LLM-Requests gelöst werden können, zu durchsuchen und dann projektspezifische Erweiterungen zu erstellen, genau dafür.
Noch nicht auf meiner liste, aber etwas, dass ich noch testen will: Vielleicht kennst du ja schon LLM-Wiki nach der Idee von Karpathy Link. So eins fürs Projekt aufsetzen, um eine andere Meta-Ebene für Wissen und Suche zu etablieren, könnte auch was bringen.
Was ich zunehmend mache, auch bei großen Modellen, analysieren, bewerten, ausfragen und dann im Anschluss einen detaillierten Aufgabenprompt erstellen und diesen genau kontrollieren. So bleibt der neue Kontext clean und man merkt, wo das Modell falsch abbiegen will und kann das bereits im Prompt gut unterdrücken.

Soweit das, was ich mache.

 

[derbe]

Kurzes Update, seit gestern habe ich mir mal das neue Harness von Deepseek installiert, bin gerade noch damit am "spielen" noch kann man nichts sagen und ich denke es wird noch ne weile dauern bis man es bewerten kann, aber bisher bin ich sehr positiv überrascht was es so sieht, wo Hermes es "nicht gesehen hat". Mal sehen was es am Ende des Tages so bringt, ist aber total anders wieder...

 

[schumischumi]

Heut abend dazu ein video angeschaut. sieht super interessant aus und geht n bissl in die richtung wo google mit android hin will.
sprich die tools / apps die man braucht nicht irgendwo runter laden sondern direkt schreiben lassen.

mir fehlt grad noch die Kreativität was ich damit mach würd. bin bei sowas meistens recht spartanisch.
funktioniert darin das coding gut das man sonst mit pi oder claude machen würde?

sry den beitrag zu llm-wiki fast überlesen.
Das mit dem llm wiki hatte ich auch schon überlegt, aber wenn ich es richtig verstehe ist rags schlechter bei code änderungen und "continue tasks x" im vergleich zu zu einer FTS5 knowledge base (context mode).
beim @ bin ich mir noch nicht ganz sicher aber könnte ganz cool bei statischen files sein. das ding ist dass ich die hard-coded pfade beim erstellen der stories kennen muss. ich will ja keinen index über die files erstellen. das macht FTS5 wieder besser.
zudem ist contextmode ein deterministisches tool das keine tokens nutzt (oder fast keine) und das llm wiki muss die md files ja mit tokens generieren.
meine struktur sieht ja so aus:

docs/gds-light
└── active
    └── epic-1
        ├── epic-brainstorm.md
        ├── epic-plan.md
        ├── story-1
        │   ├── story-plan.md
        │   └── story-review.md
        ├── story-2
        │   ├── story-plan.md
        │   └── story-review.md
        ├── story-3
        │   ├── story-plan.md
        │   └── story-review.md
        ├── story-4
        │   ├── story-plan.md
        │   └── story-review.md
        ├── story-5
        │   ├── story-plan.md
        │   └── story-review.md
        ├── story-6
        │   ├── story-plan.md
        │   └── story-review.md
        └── story-7
            ├── story-plan.md
            └── story-review.md

und auf dem selben level wie docs kommt dann src mit dem source code. neben den story-review.md files solls dann auch ein file für findings und eins für fixes geben. evtl lässt sich da was gut machen mit dem @


heut noch qwen3.8 27b mit mtp probiert und das war deutlich angenehmer mit ~20 token per second. auch wenn ich glaub es sich öfters im kreis dreht.

Spoiler: llama qwen3.6 27b mtp

llama-server -m DavidAU/Qwen3.8-27B-Cold-Fusion-GAIN-V1.1-NM-DAU-NEO-MAX-MTP-GGUF/Qwen3.8-27B-Cold-Fusion-GAIN-V1.1-NM-DAU-NEO-MAX-NEO-MTP-IQ4_NL.gguf -ngl all --fit on --fit-target 256 -c 62000 -fa on -ctk q8_0 -ctv q8_0 -np 1 --spec-type draft-mtp --spec-draft-n-max 2

 

[schumischumi]

ich hab die letzten wochen (wenn diablo 2 nicht interessanter war) an der TUI weiter gearbeitet (lassen)
den aktuellen stand findet man hier https://github.com/schumischumi/gsd-light-workflow und in doc gibts auch ne übersicht der noch zu implementierenden epics.

@derbe mich würd sehr interessieren wie du den QA-(Qualitätssicherungs-)Agenten designed hast. gerade mit dem ansatz "erstelle vorab blackbox tests" tut sich mein skill sehr schwer. gerade wenn sich die schnittstellen ändern. wenn du hier noch erfahrungsberichte oder input hast wärs cool

update: ich komm (aktuell bei epic 3) auch immer wieder an die token grenzen beim planning. evtl werd ich das planning nochmal high leveliger machen und dann jede story einzeln refinen, wie mans als mensch auch machen würd.

 

[simdcm]

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.

Ich grüble noch, zur Zeit lese ich mich nur ein und spiele mit Kombinatorikaufgaben und Trivialmathematik auf öffentlichen API-Servern. »KI« installieren um der »KI«-Willen, leuchtet mir nicht ein, zumal die kognitiven Nachteile enorm sind. Von den Modellen interessieren eigentlich nur Destillate und von denen nur die mittelkleinen. Die einzigen Modelle, die wirklich nützlich waren, sind Spracherkennungen, die die Untertitel transkribieren.

 

[schumischumi]

sry wenn ich oft KI geschrieben hab. richtig wär natürlich in meinem Kontext LLM.

Ich denke es kommt immer drauf an, was man den erreichen will.
Wenn ich Code / Anwendungen entwickeln will um damit geld zu verdienen -> Claude oder andere frontier modelle. Funktioniert auf arbeit ausgezeichnet, aber auch hier gibts logischerweise Grenzen. Ich möchts allerdings nicht mehr missen.

Um zu lernen / probieren, z.B. wie man mit Limitierungen von LLMs gerade was die Kontext Größe betrifft besser umgeht -> hierfür finde ich lokale quantisierte Modelle sehr geeignet, da sie diese Limitierungen von Haus aus mitbringen und mich somit zwingen in ihnen zu agieren. Sprich bei Opus 5 mit 1M Kontext komm ich auf Arbeit selten an die Grenze und wenn dann meistens weil ichs suboptimal nutz. Die Erkenntnisse kann ich dann auch auf Frontier Modelle anwenden. Entweder um das gegebene Token Tageslimit besser auszureizen oder noch größere Aufgaben umsetzen zu können.

Etwas produktiver als "nur lernen" hab ich lokale LLMs in einem ähnlichen Ansatz daheim im Einsatz wie du ihn bereits beschreibst. Einmal zur Spracherkennung um die Tastatur in manchen Szenarien zu ersezten, aber auch zur Kategorisierung bzw. unstrukturierten Arbeit. Entweder bei paperless ngx fürs ergänzen / aufräumen der Metadaten oder bei n8n hab ich mir n workflow gebastelt bei dem ich mit nem notiz gerät (pala note von dem menschen: https://ko-fi.com/s/674a1a82e0) die Sprachstücke erste in Text übertragen lasse und dann daraus obsidian notes erzeuge (formatierung, strukturierung und ergänzungen). Ist jetzt keine Weltneuheit, aber für mich ganz nützlich. für das obsidian notes zeug nehm ich ein kleines LLM (gemma3:4b) mit ollama.

Aber generell geb ich dir recht: Man muss sich überlegen ob man Anwendungszwecke dafür hat und wenn ned kann man es auch sehr gut lassen.
Für mich persönlich fällt "lustige spielerrei ab und zu" allerdings auch schon in die Kategorie Anwendungszweck^^