Functionary : un modèle de chat pour l'appel de fonctions, désormais figé

Le problème visé : laisser le modèle choisir ses appels

Un modèle de chat classique produit du texte. Pour qu'il agisse sur un système, il faut décider à sa place quand appeler un outil, dans quel ordre, et comment réinjecter le résultat. Functionary déplace cette décision dans le modèle lui-même. Le README indique qu'il détermine quand exécuter des fonctions, en parallèle ou en série, et qu'il comprend leurs sorties. Il ne déclenche les fonctions que lorsque c'est nécessaire. Le public visé est donc celui qui veut brancher un LLM sur des outils sans écrire une couche d'orchestration qui devine l'intention à partir du texte. Les définitions de fonctions sont fournies sous forme d'objets JSON Schema, comme pour les appels de fonctions d'OpenAI. Ce point compte : le format d'entrée est déjà familier à quiconque a utilisé l'API d'OpenAI, ce qui réduit le coût de portage des schémas existants. Le projet est écrit en Python et publié sous licence MIT.

Ce que le dépôt contient réellement

Le README ouvre sur un avertissement en bloc : le projet est déprécié, plus activement maintenu, et le dépôt reflète un instantané ancien de Functionary qui ne représente pas l'état actuel du projet. Le texte précise que le code, les modèles et la documentation sont nettement obsolètes, que le dépôt reste disponible pour référence seulement, et que les tickets et pull requests peuvent ne pas être examinés. Aucune release n'a été récupérée dans les métadonnées fournies. Le dernier push enregistré porte la date du 30 juin 2026, ce qui ne contredit pas l'avertissement : une date de push récente n'implique pas une reprise du développement, et le README affirme le contraire. Il n'existe pas de page d'accueil dans les métadonnées, mais le README renvoie à functionary.meetkai.com pour la documentation et des exemples. La licence MIT autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, à condition de conserver l'avis de copyright et le texte de licence. Elle ne donne aucune garantie, ce qui est cohérent avec un dépôt annoncé sans support.

Deux serveurs, deux chemins d'installation

Functionary se déploie via vLLM ou SGLang, au choix. L'installation se fait depuis la racine du dépôt. Pour vLLM : pip install -e .[vllm]. Pour SGLang : pip install -e .[sglang] --find-links https://flashinfer.ai/whl/cu124/torch2.5/flashinfer-python. Le second chemin tire des roues FlashInfer depuis une URL externe, ce qui suppose une machine avec accès réseau à ce dépôt et une pile CUDA cohérente. Le lancement du petit modèle tient en une ligne. Avec vLLM : python3 server_vllm.py --model "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --max-model-len 8192. Avec SGLang : python3 server_sglang.py --model-path "meetkai/functionary-v4r-small-preview" --host 0.0.0.0 --port 8000 --context-length 8192. Les deux serveurs exposent une API de type OpenAI, puisque les exemples de requête utilisent /v1/chat/completions avec les champs model, messages, tools et tool_choice. Les modèles medium, eux, exigent selon le README 4xA6000 ou 2xA100 80GB, avec tensor-parallel-size côté vLLM ou tp côté SGLang. Pour vLLM, le README impose aussi d'exporter VLLM_WORKER_MULTIPROC_METHOD=spawn avant de lancer le serveur, en renvoyant à un ticket vLLM précis. C'est le genre de détail qui fait échouer un premier démarrage si on le saute.

Le support LoRA, limité à vLLM

Le serveur vLLM accepte des adaptateurs LoRA, au démarrage ou à chaud. Le README précise que ce support n'existe actuellement que dans vLLM, pas dans SGLang. Au démarrage, on passe --enable-lora et --lora-modules avec des paires nom=chemin. À chaud, on appelle POST /v1/load_lora_adapter avec un corps JSON contenant lora_name et lora_path, puis on adresse une requête de chat au nom de l'adaptateur via le champ model. Le déchargement se fait par POST /v1/unload_lora_adapter avec lora_name. Cette mécanique est utile pour servir plusieurs variantes spécialisées sur une même base, mais elle enferme le déploiement dans vLLM dès qu'on en dépend. Un lecteur qui préfère SGLang pour d'autres raisons devra renoncer à cette fonctionnalité. Le README mentionne également un service d'inférence via Text-Generation-Inference, avec Docker et le SDK Python, mais le texte fourni est tronqué au milieu de la commande pip, donc je ne peux pas confirmer la procédure complète.

La dépréciation est la contrainte principale

Le fait le plus déterminant n'est pas technique. Le README déclare le projet déprécié et non maintenu, et indique que les tickets et pull requests peuvent ne pas être examinés. Cela signifie qu'un bogue dans server_vllm.py, dans les gabarits de prompt ou dans l'analyse des sorties de fonctions restera en l'état. Les modèles cités dans le changelog, de functionary-small-v2.4 à functionary-v4r-small-preview, sont des artefacts publiés sur Hugging Face, mais le dépôt ne promet aucune mise à jour. Autre limite de conception : le README affirme que le modèle décide seul du moment et de l'ordre des appels. Cette autonomie est précisément ce qu'on ne peut pas auditer facilement, puisque la logique de déclenchement est apprise et non écrite. Un lecteur qui a besoin d'un ordonnancement déterministe, par exemple pour respecter une séquence d'appels imposée par un système externe, devra ajouter sa propre couche de contrôle. Enfin, les modèles medium demandent 4xA6000 ou 2xA100 80GB selon le README, ce qui exclut un poste de travail ordinaire et déplace l'essai vers une machine multi-GPU.

Face à une API propriétaire, ce qui change vraiment

L'alternative la plus directe est l'appel de fonctions d'un fournisseur hébergé, du type OpenAI, dont Functionary reprend explicitement le format de schéma. La différence n'est pas le format d'entrée mais l'endroit où tourne l'inférence. Avec une API hébergée, vous envoyez messages et tools et recevez les appels ; vous ne gérez ni GPU, ni version de vLLM, ni adaptateur LoRA, et le fournisseur corrige les bogues à votre place. Avec Functionary, vous hébergez le modèle, vous choisissez la version, et vous restez responsable du serveur. L'écart se paie en exploitation : installation depuis le dépôt, dépendances CUDA, mémoire GPU, et pour les modèles medium un matériel que le README chiffre en plusieurs cartes. En échange, les poids sont téléchargeables, la licence MIT s'applique au code du dépôt, et rien ne dépend d'une clé d'API ni d'un quota. Un lecteur qui veut garder l'inférence sur sa propre infrastructure a là un argument concret. Celui qui veut la fonctionnalité sans la charge d'exploitation n'a aucune raison de choisir un dépôt annoncé déprécié.

Coût de maintenance et conséquences de la licence

Le coût de maintenance se lit dans le README : plus de correctifs, plus de support, revue des contributions incertaine. Concrètement, une équipe qui adopte ce code doit prévoir de reprendre elle-même le suivi des dépendances, notamment vLLM, SGLang et FlashInfer, dont les interfaces évoluent. Les commandes du README, comme python3 server_vllm.py ou l'appel à /v1/load_lora_adapter, sont des points d'entrée qui peuvent cesser de fonctionner après une montée de version d'une dépendance, sans qu'aucun correctif n'arrive du dépôt. Sur la licence, le MIT est permissif : réutilisation, modification et redistribution sont autorisées, y compris en contexte commercial, sous réserve de conserver l'avis de copyright et le texte de licence. Il n'impose aucune obligation de publication des modifications, contrairement à une licence copyleft. Cela dit, la licence couvre le code du dépôt ; les poids des modèles cités sur Hugging Face peuvent relever de conditions propres, et le matériel fourni ne permet pas de les vérifier. Ce point mérite un examen séparé avant tout usage en production. Je ne peux pas, à partir de ces seuls éléments, trancher la question des conditions applicables aux poids.

Conclusion éditoriale

Functionary convient à un lecteur qui veut étudier une implémentation d'appel de fonctions ou reproduire des résultats sur un modèle figé, pas à une équipe qui construit un produit devant rester corrigé et supporté. Avant tout essai, vérifiez sur le dépôt que l'avertissement de dépréciation est toujours en tête du README et que les commits ne reprennent pas, puis testez le serveur vLLM sur votre propre matériel avec la commande du README.

Sources officielles

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