Erfahrungsaustausch zu lokal LLM workflow

[derbe]

@schumischumi

Sorry für die späte Antwort. Also meine QA hat Zugang zu der Anforderungsstory. Damit weis es was gewünscht ist und kennt die Akzeptanzkirterien, somit kann er da draus die Blackboxtest generieren.

Das habe ich so gebaut, weil ich selbst QA bin gefühlt mein halbes leben. Ich muss kein Code kennen und Software zu testen ich muss nur wissen was gefordert wird und wo drauf geachtet werden muss.

Zum Thema Kontextfenster, da habe ich auch stark dran gearbeitet ich habe ein Kontextfenster für alle Agenten (max 7 Aktiv) von ca 1,3 Mio. Aber ich versuche das jeder immer unter der 100k grenze bleibt.

Bei meinen aktuellen Setup von 2x 3090 bin ich gerade aktuell nach der Reise von Qwen 3.8 27B (Unfassbar gutes Model) zurück auf Qwen 3.6 35B A3B, weil ich damit peak ca 450 Token/s generieren kann, das ist unfalls krank schnell. Und wenn man die Tasks klein genug bekommt, schafft das Model fast alle Aufgaben.

Zur Not habe ich mir eine Eskalations Pipeline gebaut, heißt wenn ein Task 3x nicht erfüllt wird, dann wird es auf den 2 Server geroutet der hat Platz für 1x Qwen 3.8 27B (ist Lahm mit ca 10 Token/s) aber der Schafft das zu 99%. Und die letzten 0,5% gehen dann falls es Qwen nicht packt in die Cloud.

Puh das war glaub ich viel Input. Btw bin mit dem Test von Deepseek Harness fertig, ist speziel, auch sehr gut aber der unterhält sich mir zu viel ähnlich wie BMAD. Daher zurück bei Hermes und recht happy damit.


Protip: falls ihr Hermes benutzt hostet (notfalls auf der CPU) ein gutes AUX Model mit 4B reicht es meist (ich nutze hier auch eins von qwen) für kleines Toolcalling und nimmt dafür nicht die Shotgun wie Qwen 3.6 35B A3B z.B das mach den Workflow ca 200% schneller, das war heftig was das für ein speed boost war!

 

[schumischumi]

Gar kein Problem dass es länger dauert. Soll ja ein gemütlicher Austausch sein
bei Qwen 3.8 27B hab ich ca ~20 tokens/sekunde und Qwen 3.6 35B A3B das doppelte. mit Q4 quantisierung und MTP. dreistellig wirds bei mir nur mit gemma4 26b was aber auch garnicht so schlecht ist.

Also meine QA hat Zugang zu der Anforderungsstory. Damit weis es was gewünscht ist und kennt die Akzeptanzkirterien, somit kann er da draus die Blackboxtest generieren.

Das habe ich so gebaut, weil ich selbst QA bin gefühlt mein halbes leben. Ich muss kein Code kennen und Software zu testen ich muss nur wissen was gefordert wird und wo drauf geachtet werden muss.

Ja das war auch mein Ansatz zu Erzeugung der Tests.
Dann kam es aber dazu dass die implementierung den blackbox test (der unter ./test im python projekt lag) immer mit ausgeführt hat und auch "fixen" wollte. Ob der Fehler jetzt im Test oder im Code war ist unklar.
Das könnte ich evtl noch besser guarden.

Die Kernfrage für mich ist allerdings wie ich die blackbox / QA tests technisch von den unittests usw. trenne. Als ich nen Ausflug ins QA Dasein gemacht hab, haben wir das mit Excellisten sichergestellt. Das will ich definitiv nicht mehr.
Für eine Automatisierung müssen ja (meiner Vorstellung nach) fixe schnittstellen definiert sein. z.B. bei Python CLI Parameter, Module + Klassen oder Input+Output Artefakte. Bei GUI/TUI wirds schon schwieriger.

Bei dem QA Thema bin ich kurz davor es entweder weg zu lassen oder auf ne automatisierte Excelliste mit Parameter zu welchseln. Sprich der QA test ist ein python oder shellscript das Zugriff auf eine definierte Liste von input parameter hat und die gegen eine definierte Liste von Anworten/Artefakten testet.
Das bedingt aber, dass ich mich auf Parameter/Click-Module apps beschränke (gibt schlimmeres) die aber auch so kommunizieren dass die Tests prüfbar sind. Das letzte macht mir eher Probleme.

Was ist den da dein Ansatz um das technisch zu implementieren?

 

[derbe]

Ob der Fehler jetzt im Test oder im Code war ist unklar.

Dafür muss dem den QA hard beibringen das er niemals den Code anfassen darf, er darf ihn sogar gar nicht kennen bzw gar kein Zugriff haben. Nur auf das fertig Produkt was auch immer das ist.

haben wir das mit Excellisten sichergestellt.

Ja oldscool, sowas hat man in den 2000er Jahre gemacht.

Das bedingt aber, dass ich mich auf Parameter/Click-Module apps beschränke (gibt schlimmeres) die aber auch so kommunizieren dass die Tests prüfbar sind. Das letzte macht mir eher Probleme.

Mach das so nicht, baue dir mit dem QA Agenten Skripte die deine Software testen, und lass den QA diese Skripte laufen, er soll dann nur checken ob was failed ist und ggf erweitern nach Bugs etc.


Wenn du mir deine Software beschrieben magst kann ich dir vielleicht paar Tipps geben.

 

[conspectumortis]

Edit: Hier stand was zu lokalen llms und frontier modellen, was nicht relevant für das Thema war.

 

[schumischumi]

Danke für das angebot.
Bei allem was z.b. über parameter input entgegen nimmt und dann ein ergebnis errechnet kann ichs mir ganz gut vorstellen.
bei sowas wie der TUI ist es eher schlecht https://github.com/schumischumi/gsd-light-workflow

gsd-light-workflow — Projektbeschreibung

gsd-light-workflow ist eine Python-basierte Terminal-UI-Anwendung (TUI), die Workflow-Dateien (workflow.yml) für ein "gsd-light"-Projekt rendert und live ausführt.
Sie dient als Steuerungszentrale für die automatische Abarbeitung von Epic-basierten Entwicklungsworkflows.

### Kernfunktionen

1. Workflow-Rendering (Bearbeiten):
Die Anwendung listet alle verfügbaren Epics unter docs/gds-light/active/<epic>/ auf. Der Benutzer kann eine Workflow-Datei interaktiv einsehen und bearbeiten — neue
Tasks hinzufügen, Schleifenparameter (Loops, Break-Bedingungen) anpassen und Änderungen speichern. Task-Befehle werden gegen Shell-Metazeichen geprüft
(Sicherheitsfilter).

2. Workflow-Ausführung (Live-Execution):
Der Benutzer wählt ein Epic aus und startet die Ausführung. Jeder Task in der Workflow-Datei wird sequenziell abgearbeitet — entweder als einfacher Befehl oder als
Schleife (z. B. 3× Implementierung + Review, bis "REVIEW STATUS: PASS"). Die Ausgabe wird live in scrollbaren Panels angezeigt. Bei einem Task-Fehler erscheint ein
Prompt mit den Optionen Retry, Skip oder Cancel. Der Benutzer kann zudem mit einem in-flight Task in eine detaillierte Verbindungsansicht einsteigen, um das
Live-Transkript zu sehen.

### Architektur

- Technologie: Python mit der Textual-Bibliothek (Terminal UI Framework)
- Workflow-Format: YAML mit Tasks, Loop-Tasks und Tooling-Konfiguration (u. a. "pi" als KI-Agent-Provider)
- KI-Integration: Task-Befehle werden per RPC an den "pi"-Agenten gesendet (z. B. /skill:light-implementation Story 1)
- Dateistruktur: Epics leben unter docs/gds-light/active/ und werden bei Abschluss nach docs/gds-light/done/ verschoben
- Exports: Pro Task werden HTML-Exporte und JSON-Sitzungsdateien erstellt

### Testrelevanz

Für Tester bedeutet das: Es gibt mehrere UI-Screens (Home, Render, Execute, Connect), die auf Tastaturkürzel (r/e/b/q/s/t/c/o) reagieren. Zu testende Szenarien
umfassen: Workflow-Validierung (doppelte Task-Namen, Metazeichen), Fehlerbehandlung (Retry/Skip/Cancel-Logik), Live-Streaming der Task-Ausgabe, Schleifenabbruch bei
erfüllter Break-Bedingung, und die Verbindung zu laufenden Sessions. Die Testsuite verwendet pytest und deckt alle Screens sowie Schema-Validierung ab.