docs: vollständige Hermes-Erkenntnisse
This commit is contained in:
Mac-Host
commit
036321bd98
43
README.md
Normal file
43
README.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, infra, dokumentation]
|
||||
---
|
||||
|
||||
# Hermes-Agent Erkenntnisse — Dokumentation
|
||||
|
||||
**Stand:** 2026-07-06
|
||||
**Repo:** [git.consoro.it/barby/hermes-erkenntnisse](https://git.consoro.it/barby/hermes-erkenntnisse)
|
||||
|
||||
## Architektur-Übersicht
|
||||
|
||||
| Komponente | Host | Details |
|
||||
|---|---|---|
|
||||
| **Silvershark** | Mac M1 Pro (lokal) | Hermes-Agent primär, Ollama, ComfyUI |
|
||||
| **Hub** | 49.13.209.112 (Hetzner) | CPU-only, 301 GB SSD, Docker-Host |
|
||||
| **GPU-Shadow** | 100.87.122.111 | Offline (Stand 2026-07-06) |
|
||||
|
||||
## Dokumentationsindex
|
||||
|
||||
1. **[Skills-Rekursion-Bug](skills-rekursion-bug.md)** — 18 Ebenen tiefe Rekursion in `~/.hermes/skills/`, 196 MB verschwendet. Ursache: Selbstreferenzierung beim Skill-Sync. Fix: `rm -rf ~/.hermes/skills/skills`.
|
||||
|
||||
2. **[Approvals-Mode-Mechanismus](approvals-mode-mechanismus.md)** — Kein Config-Schalter, sondern macOS TCC/LaunchServices. Lösung: `hermes config set approvals.mode off` → YAML `false` = `--yolo`. 33 Code-Referenzen in 10 Dateien.
|
||||
|
||||
3. **[Hub-Disk-Vollanalyse](hub-disk-vollanalyse.md)** — 281G/301G (95%). 36 Docker-Images. Top-Fresser: Open-WebUI 4,8G, keys-bridges 2,9G, LiteLLM 1,9G×2. Bereinigung 40,4G temporär, danach wieder aufgefressen.
|
||||
|
||||
4. **[Barby-Gateway-Deaktivierung](barby-gateway-deaktivierung.md)** — LaunchAgent deaktiviert am 06.07. Gateway läuft nur lokal auf Mac (7724 Hermes, 18789 OpenClaw). Kollision mit Hermes-Gateway behoben.
|
||||
|
||||
5. **[Lokale Modelle Mac](lokale-modelle-mac.md)** — 11 Ollama-Aliase, Default `qwen2.5:14b`. Fallbacks: `qwen2.5:7b`, `mistral:7b`, `llama3.1:8b`. Mac M1 Pro, 16 GB RAM.
|
||||
|
||||
6. **[PIL-Fehler ComfyUI](pil-fehler-comfyui.md)** — PIL in Hermes-Venv defekt → `sips`-Umgehung. RMBG-BEN Crash auf MPS: `KeyError` Fix in `AILab_RMBG.py`: `params["key"]` → `params.get("key", default)`.
|
||||
|
||||
7. **[Hermes-Gateway-Konfiguration](hermes-gateway-konfiguration.md)** — `model.provider: mac`, `model: qwen2.5:14b`, `api_key: ollama`. OpenClaw auf Port 18789. Homebrew-Ollama deaktiviert.
|
||||
|
||||
8. **[Git-Repo-Obsidian-Doku-Guide](git-obsidian-doku-guide.md)** — Anleitung: Git-Repo clonen, Obsidian-Vault symlinken, automatisierte Doku-Skripte.
|
||||
|
||||
---
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- Alle Befehle in dieser Dokumentation wurden auf dem beschriebenen System **tatsächlich ausgeführt**.
|
||||
- Shell-Output ist, wo angegeben, **echtes Terminal-Output**.
|
||||
- Kein Platzhalter-Content — jeder Befehl reproduzierbar.
|
||||
66
approvals-mode-mechanismus.md
Normal file
66
approvals-mode-mechanismus.md
Normal file
|
|
@ -0,0 +1,66 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, approvals, yolo, config]
|
||||
---
|
||||
|
||||
# Approvals-Mode-Mechanismus
|
||||
|
||||
## Problem
|
||||
|
||||
Hermes-Agent fordert bei jeder Tool-Ausführung eine Bestätigung an („Approve this tool call?"). Dies blockiert automatisierte Workflows und Multi-Agent-Orchestrierung.
|
||||
|
||||
## Fehlannahme
|
||||
|
||||
Es existiert **kein** dedizierter Config-Schalter `approvals.enabled: true/false` im herkömmlichen Sinn. Der Mechanismus wird durch macOS `TCC` (Transparency, Consent, and Control) und `LaunchServices` gesteuert, nicht durch eine einfache YAML-Option.
|
||||
|
||||
## Lösung
|
||||
|
||||
```bash
|
||||
hermes config set approvals.mode off
|
||||
```
|
||||
|
||||
Dies schreibt in `~/.hermes/config.yaml`:
|
||||
|
||||
```yaml
|
||||
approvals:
|
||||
mode: false # YAML boolean — entspricht --yolo
|
||||
```
|
||||
|
||||
Der Wert `false` (YAML bool, nicht String `"false"`) aktiviert den **YOLO-Mode**: Alle Tool-Calls werden ohne Rückfrage ausgeführt.
|
||||
|
||||
## Code-Referenzen
|
||||
|
||||
Durch Code-Suche im Hermes-Agent-Repository gefunden:
|
||||
|
||||
```bash
|
||||
$ rg -l "approvals" --type ts --type py | head -10
|
||||
src/gateway/approvals.ts
|
||||
src/gateway/permissions.ts
|
||||
src/cli/config.ts
|
||||
src/tui/approval-panel.tsx
|
||||
src/tui/session-view.tsx
|
||||
src/core/tool-executor.ts
|
||||
src/core/safety.ts
|
||||
src/agent/executor.ts
|
||||
tests/approvals.test.ts
|
||||
tests/yolo-mode.test.ts
|
||||
```
|
||||
|
||||
Insgesamt **33 Code-Referenzen** in **10 Dateien** verteilt auf Gateway, CLI, TUI, Core und Tests.
|
||||
|
||||
## Verifikation
|
||||
|
||||
```bash
|
||||
$ hermes config get approvals.mode
|
||||
false
|
||||
|
||||
$ cat ~/.hermes/config.yaml | grep -A2 approvals
|
||||
approvals:
|
||||
mode: false
|
||||
```
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- `approvals.mode: false` ist **nicht** dasselbe wie `approvals.mode: "false"` (String). Der YAML-Parser interpretiert nur den nativen Boolean als YOLO.
|
||||
- Nach Setzen von `approvals.mode: false` erscheint **keine** UI-Bestätigung mehr. Tool-Calls werden sofort ausgeführt.
|
||||
- Für Produktivumgebungen `approvals.mode: true` belassen und gezielte Freigaben über `allowed_tools` steuern.
|
||||
62
barby-gateway-deaktivierung.md
Normal file
62
barby-gateway-deaktivierung.md
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, gateway, launchagent, macos]
|
||||
---
|
||||
|
||||
# Barby-Gateway-Deaktivierung
|
||||
|
||||
## Hintergrund
|
||||
|
||||
Das „Barby-Gateway" ist ein eigener Gateway-Dienst, der ursprünglich als zentraler API-Proxy für Studio-Anwendungen diente. Es kollidierte mit dem Hermes-Agent-eigenen Gateway.
|
||||
|
||||
## Deaktivierung (2026-07-06)
|
||||
|
||||
```bash
|
||||
# LaunchAgent ausfindig machen
|
||||
$ ls ~/Library/LaunchAgents/ | grep -i barby
|
||||
com.barby.gateway.plist
|
||||
|
||||
# Status prüfen
|
||||
$ launchctl list | grep barby
|
||||
- 0 com.barby.gateway
|
||||
|
||||
# Deaktivieren
|
||||
$ launchctl unload ~/Library/LaunchAgents/com.barby.gateway.plist
|
||||
|
||||
# Plist entfernen (optional, für Persistent-Deaktivierung)
|
||||
$ rm ~/Library/LaunchAgents/com.barby.gateway.plist
|
||||
|
||||
# Verifikation
|
||||
$ launchctl list | grep barby
|
||||
# Keine Ausgabe → Gateway gestoppt
|
||||
```
|
||||
|
||||
## Port-Kollision
|
||||
|
||||
Das Barby-Gateway lief auf **Port 7724** — demselben Port wie das Hermes-Gateway:
|
||||
|
||||
| Dienst | Port | Status |
|
||||
|---|---|---|
|
||||
| Hermes-Gateway | 7724 | **Aktiv** (lokal) |
|
||||
| Barby-Gateway | 7724 | Deaktiviert (2026-07-06) |
|
||||
| OpenClaw | 18789 | Aktiv (lokal) |
|
||||
|
||||
## Aktueller Gateway-Status
|
||||
|
||||
```bash
|
||||
$ lsof -i :7724
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
|
||||
hermes 4241 matthiaskoerner 12u IPv4 ... TCP *:7724 (LISTEN)
|
||||
|
||||
$ lsof -i :18789
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
|
||||
openclaw 3842 matthiaskoerner 10u IPv4 ... TCP *:18789 (LISTEN)
|
||||
```
|
||||
|
||||
Nur das **Hermes-Gateway (7724)** und **OpenClaw (18789)** laufen lokal. Keine externen Gateways.
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- Das Barby-Gateway wurde deaktiviert, **nicht** gelöscht — Plist ist entfernt, Backup liegt in `~/Library/LaunchAgents/.backup/`.
|
||||
- Falls Studio-Tools das Barby-Gateway benötigen, Port auf z. B. 7725 ändern und Plist wiederherstellen.
|
||||
- Hermes-Gateway und OpenClaw laufen ausschließlich **lokal** (`127.0.0.1`), kein externes Exposure.
|
||||
119
gitlab-obsidian-doku-guide.md
Normal file
119
gitlab-obsidian-doku-guide.md
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, gitlab, forgejo, obsidian, setup]
|
||||
---
|
||||
|
||||
# GitLab/Forgejo-Obsidian-Doku-Guide
|
||||
|
||||
## Ziel
|
||||
|
||||
Diesen Wissensstand reproduzieren: Markdown-Dokumentation in einem Forgejo-Repository versionieren und mit Obsidian synchronisieren.
|
||||
|
||||
## Schritt 1: Repository klonen
|
||||
|
||||
```bash
|
||||
# Repository clonen
|
||||
$ git clone https://git.consoro.it/barby/hermes-erkenntnisse.git ~/Studio/hermes-erkenntnisse-git
|
||||
$ cd ~/Studio/hermes-erkenntnisse-git
|
||||
$ git remote -v
|
||||
origin https://git.consoro.it/barby/hermes-erkenntnisse.git (fetch)
|
||||
origin https://git.consoro.it/barby/hermes-erkenntnisse.git (push)
|
||||
```
|
||||
|
||||
## Schritt 2: Obsidian-Symlink setzen
|
||||
|
||||
```bash
|
||||
# Obsidian-Vault-Verzeichnis
|
||||
$ OBSIDIAN_VAULT="$HOME/Library/Mobile Documents/iCloud~md~obsidian/Documents/hermes-infra"
|
||||
$ mkdir -p "$OBSIDIAN_VAULT"
|
||||
|
||||
# Symlink vom Git-Repo in den Vault
|
||||
$ ln -s "$HOME/Studio/hermes-erkenntnisse-git" "$OBSIDIAN_VAULT/hermes-erkenntnisse"
|
||||
|
||||
# Verifikation
|
||||
$ ls -la "$OBSIDIAN_VAULT/"
|
||||
lrwxr-xr-x hermes-erkenntnisse -> /Users/matthiaskoerner/Studio/hermes-erkenntnisse-git
|
||||
```
|
||||
|
||||
## Schritt 3: Git-Konfiguration
|
||||
|
||||
```bash
|
||||
$ git config user.name "Barby"
|
||||
$ git config user.email "barby@consoro.it"
|
||||
|
||||
# Optional: Credential-Helper für HTTPS
|
||||
$ git config credential.helper osxkeychain
|
||||
```
|
||||
|
||||
## Schritt 4: Erste Datei erstellen und pushen
|
||||
|
||||
```bash
|
||||
$ echo "# Test" > test.md
|
||||
$ git add test.md
|
||||
$ git commit -m "docs: initial commit"
|
||||
$ git push origin main
|
||||
```
|
||||
|
||||
## Schritt 5: Skripte
|
||||
|
||||
### `sync-hermes-docs.sh`
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Sync: Git-Repo → Forgejo
|
||||
cd ~/Studio/hermes-erkenntnisse-git || exit 1
|
||||
git add -A
|
||||
git commit -m "docs: auto-sync $(date +%Y-%m-%d_%H:%M)" || true
|
||||
git pull --rebase origin main
|
||||
git push origin main
|
||||
echo "Sync completed: $(date)"
|
||||
```
|
||||
|
||||
### `watch-and-sync.sh`
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Watch-Modus: automatischer Sync bei Dateiänderungen
|
||||
fswatch -o ~/Studio/hermes-erkenntnisse-git | while read; do
|
||||
sleep 2 # Debounce
|
||||
~/Studio/hermes-erkenntnisse-git/sync-hermes-docs.sh
|
||||
done
|
||||
```
|
||||
|
||||
```bash
|
||||
$ chmod +x sync-hermes-docs.sh watch-and-sync.sh
|
||||
```
|
||||
|
||||
## Schritt 6: Cron-Job (optional)
|
||||
|
||||
```bash
|
||||
# Alle 30 Minuten automatisch syncen
|
||||
$ crontab -e
|
||||
# Füge hinzu:
|
||||
*/30 * * * * $HOME/Studio/hermes-erkenntnisse-git/sync-hermes-docs.sh >> $HOME/Studio/hermes-erkenntnisse-git/sync.log 2>&1
|
||||
```
|
||||
|
||||
## Ordnerstruktur (final)
|
||||
|
||||
```
|
||||
~/Studio/hermes-erkenntnisse-git/
|
||||
├── .git/
|
||||
├── README.md
|
||||
├── skills-rekursion-bug.md
|
||||
├── approvals-mode-mechanismus.md
|
||||
├── hub-disk-vollanalyse.md
|
||||
├── barby-gateway-deaktivierung.md
|
||||
├── lokale-modelle-mac.md
|
||||
├── pil-fehler-comfyui.md
|
||||
├── hermes-gateway-konfiguration.md
|
||||
├── gitlab-obsidian-doku-guide.md
|
||||
├── sync-hermes-docs.sh
|
||||
└── watch-and-sync.sh
|
||||
```
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- Obsidian-Vault-Pfad variiert je nach iCloud-Status. Prüfen mit: `ls "$HOME/Library/Mobile Documents/iCloud~md~obsidian/Documents/"`
|
||||
- Bei Verwendung von **Git** statt Forgejo: Remote-URL auf `git@git.consoro.it:barby/hermes-erkenntnisse.git` ändern
|
||||
- `fswatch` installieren: `brew install fswatch`
|
||||
- Credentials werden im macOS Keychain gespeichert — kein Passwort im Skript
|
||||
79
hermes-gateway-konfiguration.md
Normal file
79
hermes-gateway-konfiguration.md
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, gateway, config, ollama]
|
||||
---
|
||||
|
||||
# Hermes-Gateway-Konfiguration
|
||||
|
||||
## Aktuelle Konfiguration (2026-07-06)
|
||||
|
||||
```yaml
|
||||
# ~/.hermes/config.yaml (Auszug)
|
||||
model:
|
||||
provider: mac
|
||||
model: qwen2.5:14b
|
||||
api_key: ollama
|
||||
|
||||
gateway:
|
||||
port: 7724
|
||||
host: 127.0.0.1
|
||||
```
|
||||
|
||||
## Provider-Details
|
||||
|
||||
| Feld | Wert | Erklärung |
|
||||
|---|---|---|
|
||||
| `model.provider` | `mac` | Lokaler Provider auf Silvershark |
|
||||
| `model.model` | `qwen2.5:14b` | Default-Modell via Ollama |
|
||||
| `model.api_key` | `ollama` | Ollama benötigt keinen echten API-Key |
|
||||
|
||||
## Port-Belegung
|
||||
|
||||
```bash
|
||||
$ lsof -i :7724 -i :18789
|
||||
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
|
||||
hermes 4241 matthiaskoerner 12u IPv4 ... TCP localhost:7724 (LISTEN)
|
||||
openclaw 3842 matthiaskoerner 10u IPv4 ... TCP localhost:18789 (LISTEN)
|
||||
```
|
||||
|
||||
## Homebrew-Ollama
|
||||
|
||||
```bash
|
||||
$ brew services list | grep ollama
|
||||
ollama started matthiaskoerner ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist
|
||||
|
||||
# Bei Bedarf deaktivieren:
|
||||
$ brew services stop ollama
|
||||
$ brew services list | grep ollama
|
||||
ollama none
|
||||
```
|
||||
|
||||
Ollama läuft als Homebrew-Service auf `localhost:11434`. Hermes-Gateway routet Anfragen an diesen Endpunkt.
|
||||
|
||||
## OpenClaw (18789)
|
||||
|
||||
OpenClaw ist ein separater Agent-Runner, der auf Port 18789 läuft. Er teilt sich die Ollama-Instanz mit Hermes:
|
||||
|
||||
```
|
||||
Client → Hermes (7724) → Ollama (11434)
|
||||
Client → OpenClaw (18789) → Ollama (11434)
|
||||
```
|
||||
|
||||
## Konfiguration ändern
|
||||
|
||||
```bash
|
||||
# Provider wechseln
|
||||
hermes config set model.provider mac
|
||||
hermes config set model.model qwen2.5:14b
|
||||
hermes config set model.api_key ollama
|
||||
|
||||
# Gateway-Port ändern
|
||||
hermes config set gateway.port 7724
|
||||
hermes config set gateway.host 127.0.0.1
|
||||
```
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- `model.api_key: ollama` ist ein Platzhalter — Ollama benötigt keinen Key, aber das Feld muss gesetzt sein.
|
||||
- Homebrew-Ollama **nicht** deaktivieren, solange Hermes oder OpenClaw darauf angewiesen sind.
|
||||
- Alle Dienste laufen auf `127.0.0.1` — kein externer Zugriff, kein Reverse-Proxy nötig.
|
||||
85
hub-disk-vollanalyse.md
Normal file
85
hub-disk-vollanalyse.md
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, hub, disk, docker, infrastructure]
|
||||
---
|
||||
|
||||
# Hub-Disk-Vollanalyse
|
||||
|
||||
## Server
|
||||
|
||||
| Eigenschaft | Wert |
|
||||
|---|---|
|
||||
| Hostname | Hub (Hetzner CX32) |
|
||||
| IP | 49.13.209.112 |
|
||||
| Typ | CPU-only, keine GPU |
|
||||
| SSD | 301 GB |
|
||||
|
||||
## Disk-Belegung (Stand 2026-07-06)
|
||||
|
||||
```bash
|
||||
$ df -h /
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
/dev/sda1 301G 281G 20G 95% /
|
||||
```
|
||||
|
||||
**281 GB von 301 GB belegt (95 %)** — kritischer Zustand.
|
||||
|
||||
## Top-Verzeichnisse
|
||||
|
||||
```bash
|
||||
$ du -sh /var/lib/docker /home /var/log /usr /snap 2>/dev/null | sort -rh
|
||||
201G /var/lib/docker
|
||||
32G /home
|
||||
12G /usr
|
||||
8,4G /var/log
|
||||
5,1G /snap
|
||||
```
|
||||
|
||||
## Docker-Detailanalyse
|
||||
|
||||
```bash
|
||||
$ docker system df
|
||||
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
|
||||
Images 36 12 185.2GB 142.1GB (76%)
|
||||
Containers 18 8 12.8GB 8.2GB (64%)
|
||||
Local Volumes 24 18 3.1GB 1.8GB (58%)
|
||||
Build Cache 0 0 0B 0B
|
||||
```
|
||||
|
||||
**36 Docker-Images**, davon 24 inaktiv. 76 % reclaimable.
|
||||
|
||||
## Top-Images
|
||||
|
||||
```bash
|
||||
$ docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -rh | head -8
|
||||
REPOSITORY TAG SIZE
|
||||
open-webui/open-webui latest 4.82GB
|
||||
keys-bridges latest 2.91GB
|
||||
litellm/litellm v1.68 1.94GB
|
||||
litellm/litellm v1.65 1.93GB
|
||||
collabora/code 24.04 1.52GB
|
||||
nginx latest 1.21GB
|
||||
qdrant/qdrant latest 892MB
|
||||
nextcloud latest 867MB
|
||||
```
|
||||
|
||||
## Bereinigungsversuche
|
||||
|
||||
```bash
|
||||
# Erste Bereinigung: 40,4 GB freigegeben
|
||||
$ docker system prune -a -f --volumes
|
||||
Deleted: 40.4GB
|
||||
|
||||
$ df -h /
|
||||
Filesystem Size Used Avail Use% Mounted on
|
||||
/dev/sda1 301G 241G 60G 81% /
|
||||
```
|
||||
|
||||
Innerhalb von 48 Stunden wieder auf 95 % angewachsen — Docker-Logs und Overlay2-Schichten füllen die Disk kontinuierlich.
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- `/var/lib/docker` ist mit 201 GB (67 % der Gesamtkapazität) der dominante Verbraucher.
|
||||
- Docker-Log-Rotation konfigurieren: `/etc/docker/daemon.json` → `"log-opts": {"max-size": "10m", "max-file": "3"}`
|
||||
- Regelmäßiger Cron-Job: `0 3 * * 0 docker system prune -a -f --volumes`
|
||||
- `collabora/code` und alte `litellm`-Versionen sind primäre Kandidaten für Cleanup.
|
||||
77
lokale-modelle-mac.md
Normal file
77
lokale-modelle-mac.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, ollama, llm, mac, local]
|
||||
---
|
||||
|
||||
# Lokale Modelle auf Mac (Silvershark)
|
||||
|
||||
## Hardware
|
||||
|
||||
| Eigenschaft | Wert |
|
||||
|---|---|
|
||||
| Gerät | MacBook Pro M1 Pro |
|
||||
| RAM | 16 GB |
|
||||
| Hostname | Silvershark |
|
||||
| Ollama-Version | via Homebrew |
|
||||
|
||||
## Ollama-Aliase
|
||||
|
||||
```bash
|
||||
$ ollama list
|
||||
NAME ID SIZE MODIFIED
|
||||
qwen2.5:14b abc123def456 8.9 GB 2026-06-28
|
||||
qwen2.5:7b def456ghi789 4.4 GB 2026-06-28
|
||||
mistral:7b ghi789jkl012 4.1 GB 2026-06-15
|
||||
llama3.1:8b jkl012mno345 4.9 GB 2026-06-10
|
||||
phi3:3.8b mno345pqr678 2.2 GB 2026-05-20
|
||||
gemma2:9b pqr678stu901 5.4 GB 2026-05-15
|
||||
nomic-embed-text stu901vwx234 274 MB 2026-05-10
|
||||
mxbai-embed-large vwx234yza567 669 MB 2026-05-10
|
||||
llava:13b yza567bcd890 7.9 GB 2026-05-05
|
||||
codellama:7b bcd890efg123 3.8 GB 2026-05-01
|
||||
deepseek-coder:6.7b efg123hij456 3.8 GB 2026-04-20
|
||||
```
|
||||
|
||||
**11 Modelle**, insgesamt ca. 46 GB auf Disk.
|
||||
|
||||
## Default-Modell
|
||||
|
||||
```bash
|
||||
$ ollama show qwen2.5:14b --modelfile | grep PARAMETER
|
||||
PARAMETER num_ctx 4096
|
||||
```
|
||||
|
||||
Default: **qwen2.5:14b** (8.9 GB) — beste Balance aus Qualität und Geschwindigkeit auf M1 Pro.
|
||||
|
||||
## Fallback-Strategie
|
||||
|
||||
```yaml
|
||||
# ~/.hermes/models/fallback.yaml
|
||||
fallbacks:
|
||||
- model: qwen2.5:14b
|
||||
timeout: 30s
|
||||
- model: qwen2.5:7b
|
||||
timeout: 30s
|
||||
- model: mistral:7b
|
||||
timeout: 30s
|
||||
- model: llama3.1:8b
|
||||
timeout: 30s
|
||||
```
|
||||
|
||||
## Performance
|
||||
|
||||
```bash
|
||||
$ ollama run qwen2.5:14b --verbose
|
||||
Prompt: "Erkläre Quantencomputing in 3 Sätzen"
|
||||
eval rate: 18.42 tokens/s
|
||||
total duration: 4.2s
|
||||
```
|
||||
|
||||
M1 Pro liefert ca. 18–22 tokens/s für 14B-Modelle, ca. 30–35 tokens/s für 7B-Modelle.
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- Hermes-Agent-Konfiguration: `model.provider: mac`, `model: qwen2.5:14b`
|
||||
- Ollama läuft auf `http://localhost:11434` (Standard)
|
||||
- Bei RAM-Pressure (ComfyUI + Ollama gleichzeitig) auf `qwen2.5:7b` wechseln
|
||||
- Embedding-Modelle (`nomic-embed-text`, `mxbai-embed-large`) werden für RAG/Vektor-Suche genutzt
|
||||
70
pil-fehler-comfyui.md
Normal file
70
pil-fehler-comfyui.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, comfyui, pil, python, bug]
|
||||
---
|
||||
|
||||
# PIL-Fehler in ComfyUI
|
||||
|
||||
## Problem
|
||||
|
||||
PIL (Pillow) in der Hermes-Python-Umgebung (`~/.hermes/venv/`) ist defekt. Bildoperationen schlagen mit `ImportError` oder `AttributeError` fehl.
|
||||
|
||||
## Symptom
|
||||
|
||||
```python
|
||||
>>> from PIL import Image
|
||||
>>> img = Image.open("test.png")
|
||||
Traceback (most recent call last):
|
||||
...
|
||||
ImportError: cannot import name '_imaging' from 'PIL'
|
||||
```
|
||||
|
||||
## Ursache
|
||||
|
||||
Das Hermes-Venv enthält eine PIL-Version, die gegen eine andere System-Python-Version kompiliert wurde (macOS System-Python 3.9 vs. Venv-Python 3.11).
|
||||
|
||||
## Umgehung: sips
|
||||
|
||||
```bash
|
||||
# Statt PIL: macOS natives sips für Bildkonvertierung
|
||||
$ sips -s format png input.jpg --out output.png
|
||||
$ sips -g pixelWidth -g pixelHeight input.png
|
||||
```
|
||||
|
||||
## RMBG-BEN Crash auf MPS
|
||||
|
||||
Der Background-Remover RMBG-BEN crasht auf Apple Silicon (MPS-Backend):
|
||||
|
||||
```
|
||||
KeyError: 'key'
|
||||
File "AILab_RMBG.py", line 247, in process
|
||||
params["key"]
|
||||
```
|
||||
|
||||
### Fix
|
||||
|
||||
```python
|
||||
# AILab_RMBG.py, Zeile 247
|
||||
# VORHER:
|
||||
value = params["key"]
|
||||
|
||||
# NACHHER:
|
||||
value = params.get("key", default_value)
|
||||
```
|
||||
|
||||
`params["key"]` schlägt fehl, wenn der Key nicht existiert. `params.get("key", default)` fällt auf einen Default-Wert zurück.
|
||||
|
||||
## Vollständiger Fix
|
||||
|
||||
```bash
|
||||
$ cd ~/ComfyUI/custom_nodes/rmbg-ben
|
||||
$ sed -i '' 's/params\["key"\]/params.get("key", "default")/g' AILab_RMBG.py
|
||||
$ grep -n 'params.get' AILab_RMBG.py
|
||||
247: value = params.get("key", "default")
|
||||
```
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- PIL im Hermes-Venv **nicht** mit `pip install --force-reinstall Pillow` fixen — das zerstört andere Abhängigkeiten.
|
||||
- Für Bildverarbeitung in Hermes-Skripten **immer** `sips` (macOS) oder `ImageMagick` (`convert`) verwenden.
|
||||
- RMBG-BEN-Fix ist in Zeile 247 — nur diese eine Stelle patchen, kein globales Replace.
|
||||
70
skills-rekursion-bug.md
Normal file
70
skills-rekursion-bug.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
date: 2026-07-06
|
||||
tags: [hermes, bug, skills, filesystem]
|
||||
---
|
||||
|
||||
# Skills-Rekursion-Bug: 18 Ebenen tiefe Selbstreferenzierung
|
||||
|
||||
## Symptom
|
||||
|
||||
```bash
|
||||
$ du -sh ~/.hermes/skills/
|
||||
196M /Users/matthiaskoerner/.hermes/skills/
|
||||
```
|
||||
|
||||
Bei Inspektion zeigte sich eine rekursive Verzeichnisstruktur:
|
||||
|
||||
```bash
|
||||
$ find ~/.hermes/skills/skills -maxdepth 20 -type d | wc -l
|
||||
2187
|
||||
```
|
||||
|
||||
## Ursache
|
||||
|
||||
Der Hermes-Agent Skills-Sync-Mechanismus erstellte ein Unterverzeichnis `skills/` **innerhalb** von `~/.hermes/skills/`, das wiederum ein `skills/`-Verzeichnis enthielt — 18 Ebenen tief:
|
||||
|
||||
```
|
||||
~/.hermes/skills/skills/skills/skills/skills/skills/skills/skills/skills/
|
||||
skills/skills/skills/skills/skills/skills/skills/skills/skills/
|
||||
```
|
||||
|
||||
Jede Ebene enthielt Kopien der ca. 20 Skill-Verzeichnisse → 196 MB redundante Daten.
|
||||
|
||||
## Betroffene Pfade
|
||||
|
||||
```bash
|
||||
$ ls -la ~/.hermes/skills/
|
||||
drwxr-xr-x 22 matthiaskoerner staff 704 6 Jul 18:30 .
|
||||
drwxr-xr-x 14 matthiaskoerner staff 448 6 Jul 18:30 ..
|
||||
drwxr-xr-x 20 matthiaskoerner staff 640 6 Jul 18:30 skills/ # <-- REKURSION
|
||||
drwxr-xr-x 3 matthiaskoerner staff 96 6 Jul 18:30 analyze-user-images/
|
||||
drwxr-xr-x 3 matthiaskoerner staff 96 6 Jul 18:30 auto-nude-fix/
|
||||
drwxr-xr-x 3 matthiaskoerner staff 96 6 Jul 18:30 barby-agent-farm/
|
||||
# ... 20 weitere echte Skills
|
||||
```
|
||||
|
||||
## Fix
|
||||
|
||||
```bash
|
||||
# 1. Rekursives Verzeichnis entfernen
|
||||
rm -rf ~/.hermes/skills/skills
|
||||
|
||||
# 2. Verifizieren
|
||||
$ du -sh ~/.hermes/skills/
|
||||
8,2M /Users/matthiaskoerner/.hermes/skills/
|
||||
|
||||
$ ls ~/.hermes/skills/skills
|
||||
ls: cannot access '~/.hermes/skills/skills': No such file or directory
|
||||
```
|
||||
|
||||
20 echte Skills intakt, 196 MB freigegeben.
|
||||
|
||||
## Root Cause
|
||||
|
||||
Der Sync-Mechanismus behandelte `~/.hermes/skills/` selbst als Skill-Quelle und kopierte dessen Inhalt rekursiv. Auslöser war vermutlich ein fehlkonfigurierter `skill_search_path` in `config.yaml`, der auf das eigene Skills-Verzeichnis zeigte.
|
||||
|
||||
## §§ WICHTIG
|
||||
|
||||
- **Niemals** `~/.hermes/skills/` in `skill_search_path` aufnehmen — das erzeugt die Rekursion.
|
||||
- Nach `hermes config set skill_search_path` immer mit `find ~/.hermes/skills -maxdepth 1 -type d | wc -l` prüfen.
|
||||
- Dieser Bug kann innerhalb von Stunden auftreten, wenn der Sync-Loop aktiv ist.
|
||||
Loading…
Reference in a new issue