llama.cpp kann jetzt einen Modelltyp laden, bei dem ein einzelnes Steuer-Token einen eingebetteten LoRA-Adapter auswählt. Das klingt nach einem Detail im Modellformat. Für lokale Inference ist es aber ein nützlicher Architekturversuch: Aufgaben wie Query-Rewriting oder die Erkennung unbeantwortbarer Fragen müssen nicht zwingend als separates Modell oder als nachgelagerter Prompt-Schritt laufen.
Was in b10342 neu ist
Das am 10. August 2026 um 12:47 UTC veröffentlichte Release b10342 ergänzt eine experimentelle graniteswitch-Architektur. Sie basiert laut Release Notes auf einem dichten Granite-4.1-Modell mit eingebetteten LoRA-Adaptern. Steuer-Tokens wählen den Adapter nicht für den gesamten Prozess, sondern im Tokenstrom aus.
Der Upstream enthält dafür den kompletten lokalen Pfad: GGUF-Schema und Konvertierung, Laden der Architektur sowie einen Graphen für switched LoRA. Der Status ist ausdrücklich POC, CPU – also kein Versprechen einer ausgereiften Universal-Serving-Schicht.
Warum das für lokale Stacks interessant ist
LoRA wird oft als austauschbarer Adapter neben einem Basismodell betrieben. Granite-Switch legt mehrere Adapter in einem Modell ab und nutzt ein spezielles Token als Auswahlmechanismus. Das kann eine Pipeline vereinfachen, wenn eine eng umrissene Hilfsaufgabe zuverlässig auf demselben lokalen Modellpfad erfolgen soll.
| Bislang häufig | Granite-Switch in llama.cpp |
|---|---|
| Adapter oder Modell vor dem Request wählen | Adapter über ein Steuer-Token im Tokenstrom aktivieren |
| Zusätzlicher Routing-Schritt in der Anwendung | Auswahl ist Teil des Modellgraphen |
| Separater Inference-Kontext je Spezialaufgabe | Adapter sind im selben GGUF gebündelt |
Die wichtige Betriebsgrenze: ein Wechsel pro Sequenz
Die Release Notes beschreiben einen sequenzgebundenen Router im KV-Cache. Damit sind parallele Sequenzen voneinander getrennt; genau das behebt einen früheren globalen Zustand im POC. Die andere Seite der Medaille: Nach einem aktivierenden Token lässt sich innerhalb derselben laufenden Sequenz nicht zurück zum Basisadapter schalten. Das entspricht laut Release auch dem Verhalten der Referenzpfade in Hugging Face und vLLM.
Für fortgesetzte Chat-Sitzungen bedeutet das: Wer nach einer spezialisierten Aufgabe wieder Basisverhalten erwartet, muss eine neue Sequenz beginnen – oder das Routing bewusst anders implementieren.
# Schematisch: erst Steuer-Token, dann die Spezialaufgabe
<|query_rewrite|> Formuliere diese Suchanfrage präziser: ...
# Für den Rückweg zum Basisverhalten: frische Sequenz / neuer KV-Cache
Das ist kein kleiner Fußnotenhinweis. Anwendungen, die KV-Caches über mehrere Turns halten, sollten den Reset als Teil ihres Session-Designs behandeln. Andernfalls bleibt der zuletzt gewählte Adapter aktiv – ein Verhalten, das sich wie ein unerklärlicher Prompt-Drift lesen kann.
Einordnung
b10342 macht Granite-Switch nicht automatisch zur Standardarchitektur für lokale Agenten. Der Wert liegt zunächst in der konkreten Implementierung: llama.cpp zeigt, wie tokenbasiertes Adapter-Routing in GGUF, Graph und sequenzisoliertem KV-Cache abgebildet werden kann. Wer lokale Spezialschritte bündelt, bekommt einen interessanten Baustein – mit einer klaren Vertragsbedingung für Sessions.
Quelle
- llama.cpp Release b10342, veröffentlicht am 10. August 2026, 12:47 UTC.
Leave a Reply