glpi-neural-brain/SPEED-MODE-V11.md

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

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

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:

Workers = 1

Im Speed Mode:

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:

{
  "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:

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:

Ticker -> ein Classification-Batch -> ein Security-Batch -> warten

Speed:

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.

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:

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:

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:

speed_cpu_tasks = Anzahl logischer/zugewiesener CPU-Kerne

GPU zunaechst:

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:

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:

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.