253 lines
8.0 KiB
Markdown
253 lines
8.0 KiB
Markdown
# 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.
|