Enable cross-chat llama prompt cache reuse
This commit is contained in:
@@ -43,6 +43,9 @@ Zielplattform.
|
||||
- RTX 5080 + RTX 3060 im Verhältnis 90:10
|
||||
- Flash Attention
|
||||
- KV-Cache Q4_0 für K und V
|
||||
- explizites Prompt-Caching mit 8.192 MiB profilinternem RAM-Cache
|
||||
- `--cache-reuse 256` für die Wiederverwendung langer stabiler Präfixe trotz
|
||||
kleiner späterer Abweichungen
|
||||
- MTP Draft, maximal drei Tokens
|
||||
- MTP-Akzeptanzschwelle 0,05; im Referenzlauf 77,26 statt 73,88 Tok/s
|
||||
- sechs Threads und sechs Batch-Threads
|
||||
@@ -96,6 +99,18 @@ Der Router übernimmt:
|
||||
|
||||
## Hermes Agent
|
||||
|
||||
- Hermes 0.20.5 baut den Systemprompt bereits in drei geordneten Bereichen:
|
||||
einen chatübergreifend stabilen Präfix, sitzungsstabilen Kontext und einen
|
||||
variablen Nachlauf. Der stabile Präfix bleibt bei gleicher Profil- und
|
||||
Werkzeugkonfiguration wortgleich und kann dadurch vom llama.cpp-RAM-Cache
|
||||
wiederverwendet werden.
|
||||
- Der RAM-Promptcache lebt nur so lange wie der jeweilige llama.cpp-Prozess.
|
||||
Ein Profilwechsel entlädt das bisherige Modell und damit dessen Cache.
|
||||
- Persistente Slot-Dateien (`--slot-save-path`) sind vorerst bewusst nicht
|
||||
aktiviert. Die aktuelle llama.cpp-Linie hat offene Restore-Fehler; ein
|
||||
gemeldetes erfolgreiches Restore kann trotzdem einen vollständigen Prefill
|
||||
auslösen. Erst nach einem isolierten Regressionstest aktivieren.
|
||||
|
||||
- Kontextkompression läuft spätestens bei 60.000 Token; die relative
|
||||
65-Prozent-Grenze greift nur, wenn sie noch früher erreicht wird. Damit gilt
|
||||
dieselbe Obergrenze auch für Medium, Large und Ultra und ein Profilwechsel
|
||||
|
||||
@@ -51,6 +51,14 @@ Der Cache `/var/lib/docker/unraid-update-status.json` ist nur ein
|
||||
Kandidatenhinweis. Er darf nie allein eine Neuerstellung auslösen. Autoritativ
|
||||
ist der Image-ID-Vergleich nach dem Pull.
|
||||
|
||||
Die Unraid-Weboberfläche und mobile Ansichten lesen weiterhin diesen separaten
|
||||
Cache. Ein technisch verifizierter Pull/Rebuild aktualisiert dessen Anzeige
|
||||
nicht zwingend sofort. Deshalb kann dort weiterhin „Apply Update“ stehen,
|
||||
obwohl der lokale Image-ID-Vergleich bereits `already-current` ergeben hat.
|
||||
Für eine frische Anzeige muss Unraids eigener Statuslauf
|
||||
`dynamix.docker.manager/scripts/dockerupdate check` abgeschlossen sein. Das ist
|
||||
eine Aktualisierung der Anzeige und kein erneuter Container-Rebuild.
|
||||
|
||||
Ein wiederholter Lauf muss bei einem aktuellen Image folgendes melden:
|
||||
|
||||
```text
|
||||
@@ -86,4 +94,3 @@ einzelne Update-Aufrufe. Dieser Pfad ist ersetzt.
|
||||
4. Ein ausdrücklich schreibender synthetischer Auftrag muss beide MUA-Zugänge
|
||||
bereitstellen und das Batch-Werkzeug wählen.
|
||||
5. Ein Wiederholungstest mit aktuellem Image darf keine Neuerstellung auslösen.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user