Llama.cpp: n_ctx_train-Limit blockiert 64k-Kontextanfragen bei GGUF-Modellen
Der Reddit-Nutzer /u/Inner-End7733 beschreibt ein konkretes Praxisproblem beim Aufbau eines vollständig lokalen Hermes-Agent-Setups auf einem Lenovo P520 mit 64 GB Quad-Channel-RAM und einer RTX 3060. Als primäres Sprachmodell setzt er Qwen3.5 35B im CPU-Offloading-Modus ein, der lediglich etwa 4 GB VRAM belegt und dabei noch rund 30 Token pro Sekunde erreicht. Für LCM-Context-Compaction und Hilfsaufgaben des Hermes-Agenten wird ein Sekundärmodell benötigt, das nativ 64k Token Kontext unterstützt. Das Kernproblem: llama.cpp liest den Wert `n_ctx_train` direkt aus den GGUF-Metadaten des Modells und verweigert Anfragen, die diesen Wert überschreiten – unabhängig davon, was per RoPE-Flags oder Kontextparameter extern gesetzt wird. Hermes kodiert die Compaction-Anfragen mit einer festen Kontextgröße über 64k, was dazu führt, dass Modelle, die im Original 64k unterstützen, als GGUF-Quant aber einen kleineren `n_ctx_train`-Wert eingetragen haben, vom Inferenz-Server abgelehnt werden. Der Nutzer sucht daher explizit nach einem dichten, nicht-reasoning GGUF-Modell, dessen quantisierte Version den 64k-Wert korrekt im `n_ctx_train`-Feld verankert hat.
- Hardware-Setup: Lenovo P520 mit 64 GB Quad-Channel-RAM + RTX 3060; Qwen3.5 35B läuft im CPU-Modus mit ~4 GB VRAM-Nutzung und 30 t/s.
- Kernproblem: llama.cpp liest n_ctx_train aus den GGUF-Metadaten – extern gesetzte RoPE-Flags oder --ctx-size-Parameter können diesen Wert nicht überschreiben.
- Hermes-Agent verwendet hartkodierte Kontextanfragen über 64k für LCM-Context-Compaction; unterschreitet n_ctx_train diesen Wert, lehnt llama.cpp den Task ab.
- Diskrepanz zwischen nativen Quants und GGUF: Manche Modelle unterstützen 64k im Original, haben aber in der GGUF-Version einen kleineren n_ctx_train-Eintrag.
- Gesuchter Modelltyp: dicht (dense), kein Reasoning-Modell, als GGUF quantisiert, mit nativ ≥ 64k in n_ctx_train verankert.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Verwandte Beiträge
Llama.cpp: n_ctx_train-Limit blockiert 64k-Kontextanfragen bei GGUF-Modellen
Der Reddit-Nutzer /u/Inner-End7733 beschreibt ein konkretes Praxisproblem beim Aufbau eines vollständig lokalen Hermes-Agent-Setups auf einem Lenovo P520 mit 64 GB Quad-Channel-RAM und einer RTX 3060. Als primäres Sprachmodell setzt er Qwen3.5 35B im CPU-Offloading-Modus ein, der lediglich etwa 4 GB VRAM belegt und dabei noch rund 30 Token pro Sekunde erreicht. Für LCM-Context-Compaction und Hilfsaufgaben des Hermes-Agenten wird ein Sekundärmodell benötigt, das nativ 64k Token Kontext unterstützt. Das Kernproblem: llama.cpp liest den Wert `n_ctx_train` direkt aus den GGUF-Metadaten des Modells und verweigert Anfragen, die diesen Wert überschreiten – unabhängig davon, was per RoPE-Flags oder Kontextparameter extern gesetzt wird. Hermes kodiert die Compaction-Anfragen mit einer festen Kontextgröße über 64k, was dazu führt, dass Modelle, die im Original 64k unterstützen, als GGUF-Quant aber einen kleineren `n_ctx_train`-Wert eingetragen haben, vom Inferenz-Server abgelehnt werden. Der Nutzer sucht daher explizit nach einem dichten, nicht-reasoning GGUF-Modell, dessen quantisierte Version den 64k-Wert korrekt im `n_ctx_train`-Feld verankert hat.
- Hardware-Setup: Lenovo P520 mit 64 GB Quad-Channel-RAM + RTX 3060; Qwen3.5 35B läuft im CPU-Modus mit ~4 GB VRAM-Nutzung und 30 t/s.
- Kernproblem: llama.cpp liest n_ctx_train aus den GGUF-Metadaten – extern gesetzte RoPE-Flags oder --ctx-size-Parameter können diesen Wert nicht überschreiben.
- Hermes-Agent verwendet hartkodierte Kontextanfragen über 64k für LCM-Context-Compaction; unterschreitet n_ctx_train diesen Wert, lehnt llama.cpp den Task ab.
- Diskrepanz zwischen nativen Quants und GGUF: Manche Modelle unterstützen 64k im Original, haben aber in der GGUF-Version einen kleineren n_ctx_train-Eintrag.
- Gesuchter Modelltyp: dicht (dense), kein Reasoning-Modell, als GGUF quantisiert, mit nativ ≥ 64k in n_ctx_train verankert.
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.