# Speed Mode v11 ## Ziel Speed Mode ist ein expliziter Throughput-/Benchmark-Modus fuer GLPI Neural Brain. Er entfernt kuenstliche Pacing-Pausen, hebt CPU-/GPU-Parallelitaet zur Laufzeit an und treibt vorhandene Queues unmittelbar weiter, solange Arbeit vorhanden ist. Der Modus ist **kein Safety-Off-Schalter**. Datenintegritaet, fachliche Quality-Gates, HTTP-Timeouts, Fehler-Cooldowns, SQLite-/Graph-Locks, Docker-Controller-Policy, Research-Deduplizierung und Tagesbudgets bleiben aktiv. ## Runtime-Schalter ```env BRAIN_SPEED_MODE=false # leer/nicht gesetzt = runtime.NumCPU() BRAIN_SPEED_CPU_TASKS= # gleichzeitige Ollama-Requests pro Node BRAIN_SPEED_GPU_TASKS=4 ``` Die Werte koennen im zentralen Dashboard zur Laufzeit geaendert werden: - `Speed Mode` - `CPU-Tasks` (1..256) - `GPU-Tasks je Ollama-Node` (1..64) Eco und Speed sind gegenseitig exklusiv. Wird Speed eingeschaltet, wird Eco ausgeschaltet. ## CPU-Pfad ### Dynamischer Shared Work Limiter Der bisher statische gemeinsame Research-/Ollama-Limiter ist runtime-resizable. Im Speed Mode wird seine Parallelitaet mindestens auf ```text max(speed_cpu_tasks, speed_gpu_tasks * konfigurierte_ollama_nodes) ``` angehoben. Die Wartequeue wird auf mindestens das 16-fache dieses Werts erweitert. Beim Abschalten von Speed werden die normalen ENV-Limits wiederhergestellt. Bereits laufende Arbeit wird beim Herunterregeln nicht abgebrochen; neue Arbeit wartet auf das normale Limit. ### Vector-Graph intern parallel Der CPU-schwerste deterministische Job war bisher intern weitgehend single-threaded. v11 fuegt `Workers` zum mathematischen Vector-Graph hinzu. Im Normalmodus: ```text Workers = 1 ``` Im Speed Mode: ```text Workers = speed_cpu_tasks ``` Parallelisiert werden die unabhaengigen per-Node Phasen: - LSH-Bucket-Lookups - bounded Candidate-Auswahl - exakte Cosine-Vergleiche - lokale kNN-/Sigma-Berechnung - Orphan-Focused-Pass Die Ergebnisaggregation erfolgt nach Abschluss der Worker wieder deterministisch in sortierter Node-Reihenfolge. Ein Regressionstest vergleicht Single- und Multi-Worker-Ergebnis byte-/strukturidentisch. ### Compute-Agent Burst Das Brain sendet an Compute-Agenten live: ```json { "speed_mode": true, "cpu_tasks": 16 } ``` Ein Speed-Agent kann bis zu `cpu_tasks` Compute-Worker gleichzeitig betreiben und vorhandene `article_quality`-/`vector_graph`-Jobs ohne den normalen Poll-Abstand drainen. Die Performance-Policy wird alle 5 Sekunden separat aktualisiert; bei aktivem Speed gibt es zusaetzlich einen 250-ms-Wake-Poll, der nur bei vorhandener Arbeit Compute ausloest. Source-Polling-Intervalle werden nicht ignoriert. Speed soll nicht dieselbe RSS/Sitemap-Quelle in einer Busy Loop abrufen. ## GPU-/Ollama-Pfad `speed_gpu_tasks` ist das **maximale InFlight-Limit pro Ollama-Node**. Beispiel: ```text 2 Ollama Nodes speed_gpu_tasks = 4 => bis zu 8 reservierbare Modellrequests im Pool ``` Das Limit wird ohne Neustart auf dem Ollama-Client geaendert. Bereits aktive Requests werden beim Herunterregeln nicht abgebrochen. ### Low-Priority-Yield Normale Hintergrundjobs nutzen weiterhin den Low-Priority-Kontext und lassen interaktive Requests vor. Speed Mode entfernt diese kuenstliche Prioritaetsbremse: Background-Modellcalls werden als normale Calls eingereiht. Die echte Node-Kapazitaet bleibt trotzdem bindend. Ist ein Node voll, wartet der Request auf einen freien Slot statt zu busy-spinnen. ### VRAM-Hinweis Mehr InFlight ist nicht automatisch schneller. Bei grossen Modellen kann ein zu hoher Wert zu KV-Cache-/VRAM-Druck, Modell-Evictions oder OOM fuehren. `4` ist nur ein aggressiver Startwert, kein universelles Optimum. Fuer reine Benchmarktests kann weiter erhoeht werden. ## Entfernte kuenstliche Pausen Bei aktivem Speed: - AI-THINK Startup-Delay: `12s -> 0` - `BRAIN_ENRICH_STEP_DELAY`: effektiv `0` - AI-THINK requeued sofort als `speed-drain`, solange Kandidaten verarbeitet werden - Autonomous-Research Startup-Scan: sofort - Autonomous `idle_only`: effektiv aus - `tasks_per_cycle`: innerhalb des verbleibenden Tagesbudgets fuer den Scanner nicht mehr die Durchsatzbremse - erfolgreicher Autonomous Task weckt Queue/Scanner sofort erneut - Source Inbox drainiert Classification + Proactive Security batchweise bis leer - neue Agent-Ingests wecken die Source Inbox ereignisgetrieben - optionale Vector-Agent-Startup-Grace wird uebersprungen, wenn Agent-Offload nicht REQUIRED ist - Vector-Maintenance Startup-Vorsprung: `5s -> 0` - reine 55-ms-UI-Aktivierungspause pro Query-Treffer: `0` - Compute-Agent drainiert vorhandene Compute-Jobs ohne normalen Poll-Sleep ## Bewusst **nicht** entfernt Folgende Grenzen sind keine Performance-Sleeps, sondern Sicherheits-/Konsistenzmechanismen: - HTTP-/Ollama Request Timeouts - Ollama Failure Cooldown - Controller-Job-Laufzeit und laufende Re-Authorisierung - Docker Master/Autonomous/Dry-Run/Destructive-Gates - Research semantische Deduplizierung - Autonomous Tagesbudget - Source-Task PollInterval - SQLite Persistenztransaktionen und WAL-Regeln - Graph-Mutations-Lock (`Engine.mu`) - Vector-Reevaluation-/Layout-Cadence - Agent-Leases - Quality-/Grounding-/Coverage-Gates Damit kann Speed nicht dieselbe Wissensluecke endlos recherchieren, keine Quality-Gates umgehen und keine konkurrierenden Graphschreiber auf denselben semantischen Layer loslassen. ## Source Inbox Normal: ```text Ticker -> ein Classification-Batch -> ein Security-Batch -> warten ``` Speed: ```text Wake/Ticker -> Classification Batch -> Security Batch -> noch Arbeit? ja -> sofort naechste Runde nein -> schlafen bis Event/Ticker ``` Dadurch gibt es keinen Busy-Spin bei leerer Queue. ## Autonomous Research Speed veraendert **Scheduling/Pacing**, nicht die fachlichen Budgets. ```text idle_only wird ignoriert startup scan sofort remaining daily capacity kann in einem Scan enqueueed werden Task-Ende -> sofort speed-drain Wake ``` Weiter aktiv: - `BRAIN_AUTONOMOUS_RESEARCH_MAX_TASKS_PER_DAY` - semantische Queue-Deduplizierung - Quality-/Evidence-Gates - maximal ein graphmutierender Autonomous-Workflow in der kritischen Engine-Sektion ## Vector Agent Verhalten Wenn Speed aktiv und `BRAIN_VECTOR_GRAPH_AGENT_REQUIRED=false`: ```text Agent vorhanden -> Offload Agent nicht sofort vorhanden -> lokaler paralleler CPU-Fallback ``` Es wird nicht mehr optional bis zu zwei Minuten auf einen spaet startenden Agenten gewartet. Bei `AGENT_REQUIRED=true` bleibt die explizite Operatorentscheidung bindend. ## Dashboard Der Hauptbildschirm besitzt einen `SPEED`-Quick-Toggle. Im Settings-Panel koennen CPU-/GPU-Limits exakt gesetzt werden. Status/Analyse enthalten: ```text speed_mode speed_cpu_tasks speed_gpu_tasks speed_algorithm = throughput-v1 ``` Der Ollama-Pool zeigt das live angewendete `node_max_inflight`; die Shared Queue zeigt das live angewendete `max_inflight` und `queue_size`. ## Empfohlene aggressive Testkonfiguration CPU: ```text speed_cpu_tasks = Anzahl logischer/zugewiesener CPU-Kerne ``` GPU zunaechst: ```text speed_gpu_tasks = 2..4 pro Ollama-Node ``` Danach anhand realer Latenz, VRAM und Tokens/s erhoehen. Ein groesserer InFlight-Wert kann bei einem einzelnen grossen Modell langsamer werden, wenn Ollama Requests nur zeitgeteilt statt wirklich parallel verarbeitet. ## Sicherheitsmodell Speed Mode veraendert den Docker-Controller nicht. Ein Controller-Agent bleibt weiterhin an folgende Gates gebunden: ```text Master ON + Autonomous ON (fuer autonome Profile) + Profil enabled/autonomous + Capability + Allow-/Protect-Listen + Dry-Run + Destructive Gate ``` Speed erteilt keinerlei neue Docker- oder Hostrechte. ## Synthetischer CPU-Plausibilitaetscheck In der verfuegbaren Testumgebung (`AMD EPYC 9V74`, Go-Runner mit 5 sichtbaren CPUs) wurde ein synthetischer Build mit 2.500 Vektoren × 256 Dimensionen, CandidateLimit 96 und einem Durchlauf verglichen: ```text Workers=1 ~95.7 ms Workers=5 ~32.7 ms Speedup ~2.9x ``` Das ist nur ein Plausibilitaetsbenchmark und keine Prognose fuer den produktiven 21k×768D-Bestand. Der reale Speedup haengt von Candidate-Dichte, Cache/Memory-Bandbreite und CPU-Zuteilung ab.