llama.cpp unterstützt Entscheidungsmodelle: Klassifizieren statt Antworten generieren

Von /

Nicht jede Aufgabe in einer KI-Anwendung braucht eine ausformulierte Antwort. Oft muss ein System zunächst entscheiden, welches Team eine Anfrage erhält, ob ein Vorgang dringend ist oder ob ein Agent seinen Arbeitsschritt erfolgreich abgeschlossen hat. Seit dem 2. Oktober unterstützt llama.cpp dafür spezialisierte Entscheidungsmodelle über den neuen Endpunkt /v1/systemone. Die Änderung wurde in das Projekt übernommen; das Projekt beschreibt die Nutzung anhand mehrerer bereits konvertierter Modelle.

Was die neue Schnittstelle leistet

Eine Anwendung übergibt dem Server einen Zustand und eine oder mehrere Fragen. Der Zustand kann beispielsweise der Text einer Kundenanfrage sein; bei einem geeigneten Modell lässt sich auch ein Bild mitgeben. Statt eine Antwort Wort für Wort zu formulieren, bewertet das Modell vorgegebene Möglichkeiten. Der Server liefert die gewählte Option und die Verteilung der Modellwahrscheinlichkeiten zurück. Das erspart nachgelagerten Anwendungen das Parsen frei formulierter Antworten, beschränkt die Entscheidung aber zugleich auf die angebotenen Kategorien.

Die Serverdokumentation unterscheidet drei Fragetypen. choice wählt aus benannten Optionen, score bewertet abgestufte Kriterien und gibt einen erwarteten Wert zurück, der auch zwischen zwei Stufen liegen kann. noul beantwortet eine Ja-Nein-Frage mit einer Wahrscheinlichkeit für „Ja“. Eine Anwendung könnte damit eine Reklamation an die Buchhaltung leiten und unabhängig davon ihre Dringlichkeit einschätzen. Mehrere Fragen in einer Anfrage sind möglich, werden aber grundsätzlich unabhängig beantwortet; man sollte die Ausgabe daher nicht als gemeinsam begründete Entscheidung lesen.

Technisch ergänzt der zusammengeführte Pull Request die Konvertierung der Modelle, einen Entscheidungskopf in der Inferenz und die Verarbeitung im Server. Das ist etwas anderes als ein gewöhnliches Chatmodell, das nacheinander Ausgabetoken erzeugt. Die Ausgabe enthält zwar im API-Schema null Output-Tokens, doch daraus folgt weder, dass die Berechnung kostenlos ist, noch, dass jede Kombination aus Fragen nur einen einzigen Rechenschritt benötigt. Entscheidend für die Laufzeit bleiben Modell, Eingabelänge, Anzahl der Fragen und Hardware.

Welche Modelle sich einsetzen lassen

Zum Start nennt das Projekt unter anderem Julia-1, Laya, Kev-4B, lev und OpenJev. Für einen ersten lokalen Versuch zeigt die Anleitung den Aufruf llama serve -hf ggml-org/Kev-4B-GGUF; anschließend nimmt /v1/systemone Anfragen mit state und questions entgegen. Die Modellkarte von Kev-4B weist die GGUF-Variante als Apache-2.0-lizenziertes Modell mit vier Milliarden Parametern aus.

Wer Bilder wie Rechnungen oder Bildschirmaufnahmen einordnen will, braucht dagegen ein Modell mit Bildverarbeitung und den passenden Projektor. Das Projekt führt dafür OpenJev an. Seine GGUF-Modellkarte nennt die nichtkommerzielle Lizenz CC BY-NC 4.0 – ein wichtiger Unterschied, wenn ein Unternehmen die Funktion in einem Produkt einsetzen möchte. Die laufend gepflegte Modellsammlung enthält inzwischen auch Bespoke-Nimble-9B-v3; die im Ankündigungstext genannten fünf Beispiele sind also nicht als abgeschlossene Liste aller verfügbaren Varianten zu verstehen. Welche Modellgröße passt, hängt von Sprache, Datenart, Genauigkeit und der vorhandenen Hardware ab.

Warum das für Agenten und Datenpipelines interessant ist

In einem Agentensystem kann ein Entscheidungsmodell vor einem teureren generativen Aufruf eine Anfrage klassifizieren oder nach einem Werkzeugaufruf einen überprüfbaren Zustand bewerten. Ähnlich lassen sich Dokumente vorsortieren oder Supportfälle an definierte Arbeitsabläufe verteilen. Weil llama.cpp die Modelle lokal bereitstellen kann, muss die Anwendung solche Eingaben für diesen Entscheidungsschritt nicht zwangsläufig an einen externen Inferenzdienst senden. Welche Daten dennoch übertragen werden, hängt von der übrigen Architektur ab.

Die zurückgegebenen Zahlen sind allerdings keine verlässlichen Erfolgsquoten für den eigenen Betrieb. Die Dokumentation warnt ausdrücklich, dass die Wahrscheinlichkeiten für eigene Daten nicht garantiert kalibriert sind. Bezeichnungen und Beschreibungen der Optionen beeinflussen zudem das Ergebnis, wie die Projektanleitung an einer Kundenanfrage zeigt. Wer Entscheidungen automatisiert, sollte daher eigene, repräsentative Fälle testen, Grenzwerte pro Modell festlegen und unsichere oder folgenreiche Fälle an Menschen weitergeben. Auch Datenschutz, Zugriffsschutz und die Lizenz des konkret verwendeten Modells bleiben Teil der Einführung.

Fazit

Mit /v1/systemone bekommt llama.cpp eine eigene Schnittstelle für begrenzte, strukturierte Entscheidungen. Sie kann dort helfen, wo ein System Optionen auswählen oder bewerten muss und generierter Fließtext eher zusätzlichen Aufwand verursacht. Ob daraus ein zuverlässiger produktiver Ablauf wird, entscheidet sich jedoch nicht am API-Format, sondern an der Qualität des gewählten Modells und an Tests mit den tatsächlichen Eingaben.

Quellen

Nach oben scrollen