Files
dotfiles/claude/memory/project-mempalace-mps-transition-pending.md
T
David F GliddenandClaude Opus 4.8 3f9a89b00c chore(memory): Basic Memory trial begins — sync normalization baseline (283 files)
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized
live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds
long YAML description lines, strips final newlines. Bodies untouched —
verified via full diff classification. From this commit forward, any diff in
claude/memory shows only what Basic Memory or the session writes.

Trial design: MemPalace untouched as incumbent; git status check on this dir
at every wrap; end-of-day evaluation (recall quality, sync robustness,
rebuild-from-files, malformed-file behavior).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-06 09:52:17 +02:00

8.7 KiB

permalink
permalink
claude-memory/project-mempalace-mps-transition-pending

name: MemPalace bge-m3 + MPS transition — paused mid-flight; resume in fresh session description: Chamber-library mine with bge-m3 was running on CPU and projected to take 4-5 days. Plan: enable Apple Silicon Metal (MPS) acceleration via chroma.py patch addition (~5-10x speedup, finish in hours not days). Processes already killed and palace wiped clean to skeleton; ready to resume. Independent BMF audit thread also surfaced. type: project originSessionId: 17dee884-74bf-43e7-9b6a-44bc82b97303

MemPalace bge-m3 + MPS transition — paused

Started 2026-04-30 evening, paused 2026-05-01 morning after diagnosing the speed problem. Steward chose fresh session for the resume rather than continuing in a long context.

Current state at pause (2026-05-01 ~10:30 AM Barcelona)

  • Chamber mine killed — PID 9199 (was 30/371 files in 9 hours under bge-m3 CPU). Projected 4-5 days at that rate; abandoned.
  • BMF service killed — PID 1043. Was at 224% CPU for 14+ hours. Investigation surfaced a Lance store pathology (1,349 index segments, 25,449+ transactions, no compaction). NOT issue #10 (steward 2026-05-01: "BMF issue #10 was resolved ages ago"). This is a fresh pathology and needs a deliberate audit session with steward + Seb. Lance is resumable — restart cleanly when audit happens.
  • Palace wiped to skeleton — ~/.mempalace/palace/ is the 168 KB fresh skeleton from palace.skeleton-backup-2026-04-30. Both prior backups preserved:
    • palace.pre-bge-m3-2026-04-30 (956 MB; full all-MiniLM state under 263k drawers; rollback target if bge-m3 ever proves wrong)
    • palace.crashed-2026-04-30 (141 MB sqlite; forensic value if anyone wants to inspect the original crashed state)
  • chroma.py patch in place — bge-m3 model selection (lines ~26-46). Just needs ONE more line: device="mps".
  • Global entity registry clean — ~/.mempalace/known_entities.json has the canonical 21-person list (Alexander, Bachelard, Berger, Bringhurst, Derrida, Harrison, Heidegger, Leopardi, Manutius, Norris, Sennett, Stevens, Vico, Warde, etc.). The per-repo chamber-library/entities.json is still noisy from yesterday's init --llm --yes but mining doesn't read that file (verified: miner.py loads ~/.mempalace/known_entities.json only).

Decisions locked

  1. Stay with bge-m3 (not switch to a faster English-only model). Chamber library is overwhelmingly English but contains critical French texts and a couple in German. Quality for citation-grade Chamber retrieval is non-negotiable; multilingual coverage matters for the French/German passages.
  2. Add MPS (Metal Performance Shaders) acceleration. Apple Silicon GPU sits idle; sentence-transformers supports device='mps' natively. Same model, same outputs, runs on Metal cores. ~5-10x speedup expected for 1024-dim transformer embedding work.
  3. Mine converted_texts/ only, not the whole repo. scripts/ is stale per steward 2026-05-01. Use --wing chamber_library explicitly (otherwise the wing defaults to directory name).
  4. mempalace.yaml stale but ignorable. The yaml at ~/_Dev/chamber-library/mempalace.yaml lists rooms that no longer exist on disk (observer_problem_sources, derrida, jaccottet:handke:lichtenberg). Mining converted_texts/ directly sidesteps the yaml entirely; mempalace will use a single "general" room. Sub-room granularity (collections, dialogues, indices, traditions as separate rooms) can be added later via a proper yaml + re-roomification — does not require re-embedding.

Resume plan — 5 steps for the fresh session

  1. Verify state — ps aux | grep -iE "mempalace|node.*Better" should show nothing relevant. Palace should be the 168K skeleton at ~/.mempalace/palace/.
  2. Edit chroma.py — file: /Users/davidglidden/_Dev/mempalace/mempalace/backends/chroma.py. The _mempalace_embedding_fn() function around line 38-43 currently reads:
    def _mempalace_embedding_fn():
        global _embedding_fn_cache
        if _embedding_fn_cache is None:
            from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction
            _embedding_fn_cache = SentenceTransformerEmbeddingFunction(model_name=_MEMPALACE_EMBED_MODEL)
        return _embedding_fn_cache
    
    Add the device="mps" parameter:
    _embedding_fn_cache = SentenceTransformerEmbeddingFunction(
        model_name=_MEMPALACE_EMBED_MODEL,
        device="mps",
    )
    
  3. Sanity test MPS — quick script to verify bge-m3 loads on Metal and produces 1024-dim output:
    ~/_Dev/mempalace/.venv/bin/python -c "
    import time, torch
    print('mps available:', torch.backends.mps.is_available())
    from chromadb.utils.embedding_functions import SentenceTransformerEmbeddingFunction
    t0 = time.time()
    ef = SentenceTransformerEmbeddingFunction(model_name='BAAI/bge-m3', device='mps')
    print(f'load: {time.time()-t0:.1f}s')
    t0 = time.time()
    v = ef(['hello', 'bonjour le monde', 'guten tag'])
    print(f'embed 3: {time.time()-t0:.2f}s, dim={len(v[0])}')
    "
    
    Expected: load ~10s (model cached), embed 3 sentences ~0.1-0.5s, dim=1024.
  4. Start mine — same form as before:
    nohup ~/_Dev/mempalace/.venv/bin/mempalace mine ~/_Dev/chamber-library/converted_texts --wing chamber_library > /tmp/mine-chamber-library-$(date +%Y-%m-%d).log 2>&1 < /dev/null & disown
    
  5. Verify GPU engagement — within 30 seconds:
    • Activity Monitor → GPU view should show GPU utilization
    • Log shows "Loading weights" then file processing
    • Estimated rate at MPS: ~16-30 files/hr (vs 3.3 files/hr on CPU)
    • Total chamber-library: ~12-24 hours (vs 4-5 days on CPU)

After chamber-library completes

Three other wings need re-mining under bge-m3 + MPS, in the steward's preferred order:

  • Phase 4b — Obsidian vault (was 112,558 drawers under all-MiniLM-L6-v2). Path: ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/David, root-and-branch. --wing obsidian-vault.
  • Phase 4c — Claude transcripts. Path: ~/.claude/projects/-Users-davidglidden. --mode convos. Was 12,688 drawers. (Note: a Stop hook auto-fires mempalace mine on this directory — saw it spawn an unauthorized parallel mine 2026-04-30 night; if the hook is still active, it'll do this work automatically when sessions end. Otherwise queue manually.)
  • Phase 4d — CapableMind thinking docs. Path: ~/_Dev/CapableMind-AI/docs/thinking/David/. --wing capablemind-thinking. Was 6,137 drawers.

Likely 1-2 days total for all three under MPS. Could run sequentially overnight on consecutive nights.

Independent thread surfaced — BMF L1 audit

Killing BMF (PID 1043) revealed a real L1 pathology that needs deliberate attention:

  • 1,349 index segments in ~/.capablemind/data/mindfabric-00/lance/vector_chunks.lance/_indices/ (healthy Lance stores have 1-10)
  • 25,449+ transactions in the same store
  • 14+ hours of sustained 224% CPU consuming all those segments per query
  • Data store itself is small (139 MB) — the bloat is metadata/segment count, not data volume

This is not issue #10 (resolved). It's a fresh pathology — likely Lance compaction never ran, or a write-amplification loop in BMF's ingestion path creates a new index segment per drawer/batch.

Belongs to: a separate L1 audit session, steward + Seb territory. Lance state is preserved (BMF's killed but data intact); when audit happens, pkill node cleanup is already done.

Reference forensic notes from prior L1 audit: ~/_Dev/CapableMind-AI/docs/thinking/David/l1-reliability/ (l1-deep-audit-plan-2026-04-19.md, l1-ingestion-forensic-2026-04-19.md, l1-recall-quality-baseline-2026-04-19.md).

Why this transition felt long

Steward 2026-05-01: "I can see how mempalace helps us immensely and want to finish this update transition which I almost regret doing — I didn't think it would take days to do."

Honest accounting:

  • Power failure 2026-04-30 mid-stream cost a full mine + caused the 217 GB HNSW corruption requiring full reset.
  • bge-m3 on CPU is genuinely 5-10x slower than was reasonable to expect for this corpus size. CPU choice was a default-not-a-decision; should have proposed MPS from the start.
  • Multiple parallel processes (auto-Stop-hook transcripts mine + BMF) competed for CPU and confused diagnosis.
  • Each diagnostic round added time without throughput.

After the MPS switch the transition should feel proportionate to its value.

Pulling thread for the fresh session

Apply the device="mps" patch and restart the chamber-library mine; everything else (palace state, kills, scope decision, model decision) is already done. Five steps from "open a fresh session" to "mine running on Metal."