2.2 KiB
Aktueller produktiver Laufzustand
Stand: 3. September 2026
Produktive llama.cpp-Runtime
Alle Textprofile verwenden llama.cpp Build 10781,
Commit c7bda030e7faee594dbe7550185e857351ad405d. Der Stand enthält die ab
Build 10751 verfügbare Korrektur für eine zwischenzeitliche
MTP-/KV-Cache-Initialisierungsregression. Der vorherige produktive Stand war
Build 10718, Commit 41ef91f7c8046087cdfbb276b79bff311ecf1c6d, und bleibt über das alte
lokale Image mike-ai/llama.cpp:b10718-fallback als unmittelbarer
Rückfallpunkt erhalten.
Build 10781 wurde nach dem Bau produktiv verifiziert: Alle fünf Profilcontainer verwenden dasselbe neue Image, ausschließlich Medium läuft, Qwen Medium ist mit 160.000 Tokens Kontext gesund, der MTP-Kontext wurde erfolgreich initialisiert, der Vision-Projektor geladen und eine lokale Textprobe korrekt beantwortet.
Qwen Medium: Vision-Projektor wieder aktiviert
qwen-medium läuft wieder mit dem Qwen-Vision-Projektor. Der Projektor wird
über --mmproj-offload --mmproj-device CUDA1 gezielt auf der RTX 3060 geladen.
Der vorübergehende Text-only-Workaround ist damit auf ausdrücklichen Wunsch
beendet.
Dabei gilt ausdrücklich:
- Der Gesamtkontext bleibt bei 160.000 Tokens.
- Das Profil verwendet wieder einen Slot. Die getestete Zwei-Slot-Variante ist nicht produktiv.
- MTP / Speculative Decoding bleibt aktiviert; MTP wurde nicht entfernt.
- Modell, Quantisierung, GPU-Aufteilung und KV-Cache-Quantisierung bleiben unverändert.
- Bildanalyse ist im Medium-Profil wieder verfügbar.
- Der bekannte llama.cpp-/MMProj-Cachefehler kann weiterhin vollständige Prompt-Neuverarbeitung in späteren Turns auslösen. Diese Einschränkung wird zugunsten der benötigten Vision-Funktion bewusst akzeptiert.
Referenz:
- https://github.com/ggml-org/llama.cpp/issues/19858
- https://github.com/ggml-org/llama.cpp/issues/21133
Separates bekanntes Problem
Automatische Hermes-Hintergrundanfragen können weiterhin den einzigen aktiven llama.cpp-Slot belegen und damit den Cache eines großen Chats verdrängen. Dieses Slot-Eviction-Problem ist unabhängig vom MMProj-Workaround und muss separat in der Hermes-Auxiliary-/Hintergrundverarbeitung geklärt werden.