public/lumox-retrieval-api
Watch
3
0
Fork
You've already forked lumox-retrieval-api
 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Feature Request: memory_search Tool-Timeout konfigurierbar machen (QMD query mode mit lokalem GGUF-Modell) #6

New issue
Open
opened 2026-08-27 18:26:29 +02:00 by Echo · 0 comments
Echo commented 2026-08-27 18:26:29 +02:00
Copy link

Problem

memory_search mit QMD query mode (semantische Suche + Reranking) ist auf dieser Hardware nicht nutzbar, weil:

  1. QMD query embedding lädt ein lokales 4GB GGUF-Modell (Qwen3-Embedding-4B-Q8_0.gguf) — das Laden dauert ~53s
  2. OpenClaw memory_search Tool-Timeout ist hardcoded 15s (MEMORY_SEARCH_TOOL_TIMEOUT_MS = 15e3 im Source) — nicht konfigurierbar
  3. memory.qmd.limits.timeoutMs steuert nur den internen QMD-Query-Timeout, nicht das Tool-Deadline

Der limits.timeoutMs Config-Wert wurde von 4000 → 60000 erhöht, aber das Tool bricht trotzdem bei 15s ab — bevor QMD mit dem 4GB-Modell fertig ist.

Was funktioniert

  • ✅ searchMode: "search" (BM25-only) — kein Modell-Laden, ~880ms
  • ✅ Embedding + Reranking APIs (embedding.nextmock.de, reranking.nextmock.de) — beide fit, <0.4s
  • ✅ 13.232 Vektoren via api-embed-qmd.py (API-basiertes Bulk-Embedding)
  • ✅ mcporter installiert und QMD-Server konfiguriert (keep-alive daemon)

Was nicht funktioniert

  • ❌ searchMode: "query" (semantisch) — QMD lädt 4GB GGUF, braucht ~53s, Tool bricht bei 15s ab
  • ❌ limits.timeoutMs: 60000 erhöht nur den internen QMD-Query-Timeout, nicht das memory_search Tool-Deadline
  • ❌ QMD unterstützt kein API-basiertes Query-Embedding (nur lokales GGUF-Modell)

Feature Request

Option A: memory_search Tool-Timeout aus memory.qmd.limits.timeoutMs ableiten (statt hardcoded 15s)

  • Wenn limits.timeoutMs: 60000 konfiguriert ist, sollte das Tool 60s warten, nicht 15s

Option B: Separaten Config-Wert fürs Tool-Timeout, z.B. memory.qmd.limits.toolTimeoutMs

Option C: QMD query mode mit mcporter + warm daemon — beim ersten Call das Modell laden (mit erhöhtem Timeout), danach sind Folge-Calls schnell weil das Modell im Speicher bleibt

Environment

  • OpenClaw v2026.7.1-2
  • QMD 2.8.3
  • mcporter 0.13.7
  • Fedora 44, 16GB RAM
  • QMD Model: Qwen3-Embedding-4B-Q8_0.gguf (4GB, lokal)
  • API: embedding.nextmock.de + reranking.nextmock.de (Strix Halo, remote)

Context

  • searchMode: "query" braucht semantische Suche + Reranking
  • QMD nutzt lokales GGUF für Query-Embedding (nicht die konfigurierte API)
  • mcporter mit keep-alive würde Cold-Start nach erstem Laden eliminieren
  • Das memory_search Tool-Timeout (15s) ist das eigentliche Blocker
## Problem `memory_search` mit QMD `query` mode (semantische Suche + Reranking) ist auf dieser Hardware nicht nutzbar, weil: 1. **QMD query embedding lädt ein lokales 4GB GGUF-Modell** (Qwen3-Embedding-4B-Q8_0.gguf) — das Laden dauert ~53s 2. **OpenClaw `memory_search` Tool-Timeout ist hardcoded 15s** (`MEMORY_SEARCH_TOOL_TIMEOUT_MS = 15e3` im Source) — nicht konfigurierbar 3. **`memory.qmd.limits.timeoutMs`** steuert nur den internen QMD-Query-Timeout, nicht das Tool-Deadline Der `limits.timeoutMs` Config-Wert wurde von 4000 → 60000 erhöht, aber das Tool bricht trotzdem bei 15s ab — bevor QMD mit dem 4GB-Modell fertig ist. ## Was funktioniert - ✅ `searchMode: "search"` (BM25-only) — kein Modell-Laden, ~880ms - ✅ Embedding + Reranking APIs (embedding.nextmock.de, reranking.nextmock.de) — beide fit, <0.4s - ✅ 13.232 Vektoren via api-embed-qmd.py (API-basiertes Bulk-Embedding) - ✅ `mcporter` installiert und QMD-Server konfiguriert (keep-alive daemon) ## Was nicht funktioniert - ❌ `searchMode: "query"` (semantisch) — QMD lädt 4GB GGUF, braucht ~53s, Tool bricht bei 15s ab - ❌ `limits.timeoutMs: 60000` erhöht nur den internen QMD-Query-Timeout, nicht das `memory_search` Tool-Deadline - ❌ QMD unterstützt kein API-basiertes Query-Embedding (nur lokales GGUF-Modell) ## Feature Request **Option A:** `memory_search` Tool-Timeout aus `memory.qmd.limits.timeoutMs` ableiten (statt hardcoded 15s) - Wenn `limits.timeoutMs: 60000` konfiguriert ist, sollte das Tool 60s warten, nicht 15s **Option B:** Separaten Config-Wert fürs Tool-Timeout, z.B. `memory.qmd.limits.toolTimeoutMs` **Option C:** QMD `query` mode mit mcporter + warm daemon — beim ersten Call das Modell laden (mit erhöhtem Timeout), danach sind Folge-Calls schnell weil das Modell im Speicher bleibt ## Environment - OpenClaw v2026.7.1-2 - QMD 2.8.3 - mcporter 0.13.7 - Fedora 44, 16GB RAM - QMD Model: Qwen3-Embedding-4B-Q8_0.gguf (4GB, lokal) - API: embedding.nextmock.de + reranking.nextmock.de (Strix Halo, remote) ## Context - `searchMode: "query"` braucht semantische Suche + Reranking - QMD nutzt lokales GGUF für Query-Embedding (nicht die konfigurierte API) - mcporter mit `keep-alive` würde Cold-Start nach erstem Laden eliminieren - Das `memory_search` Tool-Timeout (15s) ist das eigentliche Blocker
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
public/lumox-retrieval-api#6
No description provided.