MeetKai/functionary: Ein eingestelltes Tool-Calling-Modell und was davon bleibt

Welches Problem Functionary löst und für wen es gedacht war

Ein Sprachmodell, das Werkzeuge aufrufen soll, muss drei Dinge leisten: erkennen, wann ein Aufruf nötig ist, das Argumentobjekt korrekt nach JSON-Schema erzeugen und die zurückgegebene Ausgabe wieder in den Dialog einordnen. Functionary adressiert genau diese Kette. Das README formuliert es knapp: Das Modell entscheide, wann Funktionen ausgeführt werden, ob parallel oder seriell, und es verstehe deren Ausgaben. Die Zielgruppe waren Teams, die Tool-Calling selbst hosten wollten, statt es an einen externen API-Anbieter abzugeben. Die Funktionsdefinitionen werden als JSON-Schema-Objekte übergeben, nach dem Muster der OpenAI-GPT-Funktionsaufrufe. Wer bereits gegen die OpenAI-Tool-Schnittstelle entwickelt hatte, sollte die Definitionen also weitgehend übernehmen können. Der Nutzen lag weniger in einem neuen Protokoll als in einer offenen Gewichtung: eigene Hardware, eigenes Serving, kein Zwang zu einem bestimmten Anbieter.

Der Ablauf vom Schema über den Server bis zur Modellantwort

Das Repository trennt Modell und Serving. Die Gewichte liegen auf Hugging Face, im Repository selbst stecken zwei Startskripte: server_vllm.py und server_sglang.py. Beide nehmen ein Modell per Kommandozeile entgegen und stellen einen HTTP-Endpunkt bereit, der Chat-Anfragen mit einem Feld tools und dem Schalter tool_choice entgegennimmt. Das README zeigt den Aufruf an einem Chat-Endpunkt unter /v1/chat/completions, wobei tool_choice auf auto steht. Ein Aufruf enthält damit drei Bestandteile: die Nachrichtenliste, die Werkzeugdefinitionen und die Entscheidung, ob das Modell selbst wählen darf. Für den Code-Interpreter gibt es laut Changelog einen Sonderweg: Statt einer eigenen Funktion wird ein Objekt mit dem Typ code_interpreter in die Werkzeugliste gelegt. Das ist eine bewusste Erweiterung des Schemas, kein Standardfeld. Wer die Werkzeugliste streng nach JSON-Schema validiert, muss diesen Sonderfall kennen, sonst scheitert die Anfrage vor dem Modell.

Installation und Start: zwei Pfade, klare Hardwaregrenzen

Die Installation erfolgt aus dem Repository heraus, nicht über PyPI, was für einen eingefrorenen Stand spricht. Für vLLM lautet der Befehl pip install -e .[vllm], für SGLang pip install -e .[sglang] --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python. Der SGLang-Pfad zieht FlashInfer über einen expliziten Index für CUDA 12.4 und Torch 2.5, was die Umgebung faktisch auf diesen Stack festlegt. Gestartet wird mit python3 server_vllm.py --model "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --max-model-len 8192 oder entsprechend mit server_sglang.py, das --model-path und --context-length statt --model und --max-model-len verwendet. Die unterschiedlichen Flag-Namen sind eine Stolperfalle bei Skripten, die beide Server austauschbar behandeln sollen. Für die Medium-Modelle nennt das README konkrete Hardware: 4xA6000 oder 2xA100 mit 80 GB, dazu tensor-parallel-size 2 beziehungsweise tp 2. Unter vLLM ist vorher export VLLM_WORKER_MULTIPROC_METHOD=spawn nötig, mit Verweis auf ein vLLM-Issue. Das sind harte Betriebsbedingungen, keine Empfehlungen.

LoRA nur unter vLLM und die Frage, was das Repository noch abdeckt

Adapter lassen sich laut README ausschließlich im vLLM-Server nutzen, sowohl beim Start über --enable-lora und --lora-modules als auch zur Laufzeit über die Endpunkte /v1/load_lora_adapter und /v1/unload_lora_adapter. Eine Laufzeit-Anfrage trägt lora_name und lora_path, anschließend wird der Adapter über das Feld model in der Chat-Anfrage adressiert. Das ist praktisch, wenn mehrere Mandanten unterschiedliche Adapter verwenden sollen, ohne den Server neu zu starten. Der SGLang-Pfad bietet das nicht, dort bleibt nur das Basismodell. Hier zeigt sich der eigentliche Engpass des Projekts. Das Repository ist laut Warnhinweis im README ausdrücklich deprecated und wird nicht mehr aktiv gepflegt. Der Stand spiegele eine sehr alte Momentaufnahme, es gebe keine Updates, keine Bugfixes, keinen Support, und Issues wie Pull Requests würden möglicherweise nicht geprüft. Die Changelog-Einträge enden im Dezember 2024. Der Servercode ist also nicht nur eingefroren, er driftet auch von vLLM und SGLang weg, deren Schnittstellen sich weiterentwickeln. Ob die Skripte mit einem aktuellen vLLM-Build noch starten, lässt sich aus dem Material nicht ableiten und muss vor jedem Einsatz geprüft werden.

Wann Functionary die falsche Wahl ist

Der offensichtliche Fehlfall ist jedes Vorhaben, das Support, Sicherheitsupdates oder eine gepflegte Fehlerbehebung voraussetzt. Das README schließt das selbst aus. Ein zweiter Fehlfall ist der Wunsch nach einem schlanken Client ohne GPU. Functionary ist ein selbst gehostetes Modell; die Medium-Varianten verlangen zwei A100 mit 80 GB oder vier A6000. Wer nur gelegentlich ein Werkzeug aufrufen lässt, trägt hier einen Betriebsaufwand, der in keinem Verhältnis zum Nutzen steht. Drittens: Die Lizenz des Repositories ist MIT, aber das betrifft den Code. Die Gewichte bauen laut Changelog auf Meta-Llama-3-Modellen auf, deren eigene Lizenzbedingungen zusätzlich gelten. Wer die Lizenzfrage allein an der MIT-Angabe des Repositories festmacht, übersieht diesen zweiten Layer. Eine rechtliche Bewertung ist hier nicht möglich, aber die Trennung zwischen Code-Lizenz und Gewichtelizenz sollte vor dem Produktiveinsatz geklärt werden.

Was ein Wechsel zu einem gepflegten Serving-Stack ändert

Die naheliegende Alternative ist, den Server wegzulassen und ein Modell mit nativer Werkzeugunterstützung direkt in einem aktiv gepflegten Inferenz-Stack zu betreiben. Der Unterschied liegt nicht in der Modellqualität, sondern in der Verantwortung für die Schnittstelle. Bei Functionary ist die Zuordnung von Werkzeugaufruf zu Modell im Repository fest verdrahtet, inklusive der Sonderbehandlung für code_interpreter. Ein generischer Stack überlässt die Formatierung des Werkzeugaufrufs dem jeweiligen Modell und dessen Chat-Template. Das verschiebt die Fehlerquelle: Statt eines eingefrorenen Python-Skripts ist das Prompt-Template des Modells die kritische Stelle, und dieses Template wird mit dem Modell aktualisiert. Der Preis dafür ist Kontrolle. Functionary erlaubte es, das Aufrufverhalten an einer Stelle im Repository nachzuvollziehen. Bei einem generischen Stack verteilt sich dieselbe Logik auf Modellkarte, Template und Serverkonfiguration. Wer reproduzierbare Werkzeugaufrufe über Monate hinweg braucht, verliert mit dem Wechsel einen Teil dieser Nachvollziehbarkeit.

Wartung, Upgrade-Kosten und der Stand der Dokumentation

Die Wartungskosten sind hier ungewöhnlich klar bezifferbar: Es gibt keine. Das README sagt ausdrücklich, dass keine Updates, Bugfixes oder Supportleistungen mehr erbracht werden. Ein Upgrade im Sinne des Projekts findet nicht statt. Was bleibt, sind Upgrades der Abhängigkeiten, und die trägt der Betreiber allein. Zwei konkrete Stellen sind dabei besonders exponiert: die FlashInfer-Bindung an cu124 und torch2.5 im SGLang-Installationsbefehl und der Umweg über VLLM_WORKER_MULTIPROC_METHOD=spawn, der auf ein externes vLLM-Issue verweist. Beide können durch eine neue Version des jeweiligen Servers ihre Gültigkeit verlieren. Die Dokumentation ist zudem unvollständig: Der README-Auszug bricht im TGI-Abschnitt mitten im Installationsbefehl ab, die dort beschriebene Docker-Route lässt sich aus dem vorliegenden Material nicht rekonstruieren. Wer TGI einsetzen will, muss die vollständige Seite unter functionary.meetkai.com prüfen. Release-Einträge wurden für dieses Repository nicht abgerufen, die Changelog-Einträge im README enden im Dezember 2024.

Redaktionelles Fazit

Wer bereits Functionary-Gewichte betreibt oder den vLLM-Server als Referenzimplementierung für Tool-Calling studieren will, kann das Repository weiterhin als eingefrorenen Stand nutzen. Für Neuentwicklungen mit Support-Erwartung ist es die falsche Wahl, weil das README ausdrücklich keine Bugfixes, keine Reviews und keine Updates zusagt. Prüfe zuerst, ob die Modellgewichte auf Hugging Face noch verfügbar sind, ob die Lizenz der Basisgewichte (Meta Llama) zu deinem Einsatz passt und ob dein vLLM- oder SGLang-Build die im README genannten Flags wie --enable-lora und --lora-modules noch kennt.

Offizielle Quellen

1. Issues
2. License: MIT
3. MeetKai/functionary on GitHub
4. README