Déployez des agents locaux partout avec LFM2.5-2.6B

Déployez des agents locaux partout avec LFM2.5-2.6B

L'IA agentique est devenue le thème dominant du développement logiciel moderne. Des mises à jour de feuille de route d'OpenAI aux annonces d'IA pour entreprises de Microsoft, en passant par les travaux d'Anthropic sur les modèles utilisant des outils, le message est constant : l'avenir appartient aux systèmes capables de planifier, d'appeler des outils et d'agir de manière autonome. Mais tandis qu'une grande partie de ces progrès se déroule dans de vastes centres de données cloud, une révolution plus discrète est en cours : exécuter des agents capables sur du matériel que vous possédez réellement.

Cette révolution est portée par des modèles open-weights petits mais puissants. Le modèle LFM2.5-2.6B, un modèle de fondation de 2,6 milliards de paramètres issu de la génération LFM (Liquid Foundation Model), est l'une des entrées les plus intéressantes dans ce domaine. Présenté sur le blog Hugging Face, il est conçu pour couvrir le point idéal entre performance brute et efficacité computationnelle. Dans cet article, vous apprendrez à transformer ce modèle en un véritable agent local fonctionnel — l'installer, le configurer et le connecter pour l'utilisation d'outils — afin de pouvoir exécuter des assistants autonomes sur un ordinateur portable, un petit serveur, ou même un appareil Edge de faible puissance.

Pourquoi les agents locaux sont importants

Avant de plonger dans les aspects techniques, il convient de se demander pourquoi vous voudriez un agent local. Les grands laboratoires d'IA ont passé des années à développer des modèles frontières massifs avec d'énormes fenêtres de contexte et des capacités d'appel d'outils sophistiquées. Ces modèles sont impressionnants, mais ils comportent des contraintes : ils sont hébergés à distance, nécessitent une connexion réseau, et vos requêtes sont traitées sur des infrastructures hors de votre contrôle.

Les agents locaux résolvent un ensemble différent de problèmes. Lorsque tout s'exécute sur votre matériel, vos données ne quittent jamais votre machine, ce qui importe pour les documents commerciaux confidentiels, les dossiers médicaux et les conversations personnelles. Le déploiement local élimine également les coûts par token des API. Il n'y a pas de compteur qui tourne lorsque vous exécutez votre propre modèle ; le seul coût est l'électricité et le prix du matériel que vous possédez déjà.

Il y a aussi une histoire de latence. Un agent local peut répondre aux questions et invoquer des outils en quelques millisecondes car il n'y a pas d'aller-retour vers un centre de données distant. Pour l'automatisation interactive — des bots qui réagissent aux raccourcis clavier, aux déclencheurs de capteurs ou aux événements du système de fichiers — une faible latence n'est pas un luxe ; c'est une exigence.

Enfin, il y a la question de la flexibilité. Un agent déployé localement peut être continuellement affiné, personnalisé et reprogrammé sans se heurter à des limites de débit ou à des politiques produit. Vous possédez toute la pile, des poids jusqu'au code d'inférence.

Présentation de LFM2.5-2.6B

La génération LFM2.5 des Liquid Foundation Models a été construite avec l'efficacité comme objectif de conception central. La variante 2.6B — LFM2.5-2.6B — est suffisamment légère pour fonctionner sur un GPU grand public, un processeur d'ordinateur portable moderne, voire un appareil de classe Raspberry Pi lorsqu'elle est correctement quantifiée.

Le modèle est conçu pour les flux de travail agentiques : il gère de longs contextes conversationnels, peut générer des sorties structurées telles que du JSON pour l'appel de fonctions, et est délibérément configuré pour laisser suffisamment de marge mémoire pour l'infrastructure de support dont un agent a besoin — schémas d'outils, historique de conversation et boucle d'exécution. Comme il est distribué ouvertement sur Hugging Face, vous obtenez les poids complets, le tokeniseur et la fiche modèle, ce qui signifie que vous n'êtes pas enfermé dans un format d'API propriétaire.

Tout cela fait de LFM2.5-2.6B un exemple typique de la philosophie « déployez des agents locaux partout » : assez petit pour être portable, assez capable pour être réellement utile, et assez ouvert pour être façonné selon les besoins de votre flux de travail.

Prérequis

Les exigences exactes dépendent de la manière dont vous prévoyez d'optimiser, mais voici une base qui fonctionnera pour la plupart des lecteurs :

• **Python 3.10 ou plus récent**, ainsi que `pip` et un outil d'environnement virtuel.
• **Une machine avec au moins 8 Go de RAM** pour l'inférence CPU en pleine précision. Si vous voulez une expérience confortable, 16 Go de RAM sont préférables.
• **Un GPU avec au moins 4 Go de VRAM**. Les cartes NVIDIA sont les plus simples en raison du support CUDA et `bitsandbytes`. Apple Silicon est également une option viable via le backend Metal (PyTorch le prend en charge nativement).
• **Git** installé pour cloner des dépôts d'aide comme `llama.cpp`.
• **Un compte Hugging Face gratuit**, y compris un jeton d'accès utilisateur, pour télécharger le modèle. Certains modèles sont soumis à des restrictions ; vous devrez peut-être accepter les conditions sur la fiche modèle à huggingface.co/models avant le téléchargement.

Si vous n'avez rien de tout cela mais possédez un ordinateur, ne vous inquiétez pas — toute l'installation est conçue pour fonctionner sur du matériel modeste, et nous inclurons la quantification comme une étape de première classe.

Installation pas à pas

1. Créer un environnement isolé

La première étape consiste à créer un nouvel environnement virtuel Python. Cela évite les conflits de dépendances avec d'autres projets sur votre machine.

python3 -m venv lfm-agent
source lfm-agent/bin/activate

La commande `source` active l'environnement ; sous Windows, remplacez-la par `lfm-agent\Scripts\activate`.

2. Installer PyTorch et la pile de chargement de modèles

PyTorch est le framework d'apprentissage profond qui exécutera le modèle. Si vous avez un GPU NVIDIA, installez la version avec CUDA ; sinon, utilisez la version CPU. Les deux commandes sont présentées ci-dessous.

pip install --upgrade pip
pip install torch --index-url https://download.pytorch.org/whl/cu121

Pour les machines CPU uniquement :

pip install torch --index-url https://download.pytorch.org/whl/cpu

Ensuite, installez l'écosystème Hugging Face : `transformers` est notre bibliothèque d'inférence principale, tandis que `accelerate` gère le placement sur les appareils, et `bitsandbytes` permet une quantification efficace en 4 bits.

pip install "transformers>=4.45.0" accelerate bitsandbytes huggingface_hub sentencepiece

3. S'authentifier auprès du Hub Hugging Face

De nombreux modèles ouverts, dont plusieurs de la famille LFM, sont distribués via le Hub Hugging Face et peuvent exiger que vous acceptiez les termes de la licence avant le téléchargement. L'outil `huggingface-cli` est déjà installé avec le paquet `huggingface_hub`. Connectez-vous avec votre jeton :

huggingface-cli login

La commande demande votre jeton, que vous créez sous **Paramètres → Jetons d'accès** sur hf.co. Une fois saisi, le jeton est mis en cache localement, et tous les téléchargements ultérieurs l'utilisent automatiquement.

4. Télécharger les poids du modèle

Nous allons télécharger le modèle dans un répertoire local afin de pouvoir exécuter plusieurs backends d'inférence différents sur le même ensemble de fichiers. N'oubliez pas de remplacer `votre-org` par l'espace de noms réel indiqué sur la fiche du modèle LFM2.5-2.6B.

from huggingface_hub import snapshot_download

repo_id = "votre-org/LFM2.5-2.6B-instruct"
snapshot_download(repo_id=repo_id, local_dir="lfm2.5-2.6b-instruct")

La fonction `snapshot_download` préserve la structure exacte du dépôt. Si vous êtes à court d'espace disque, vous pouvez passer `allow_patterns=["*.json", "*.safetensors"]` pour ignorer les fichiers non essentiels.

5. Charger le modèle avec Transformers

Voici un script minimal qui charge le modèle en bfloat16 et le place intelligemment sur votre matériel à l'aide de `device_map="auto"`. Cela devrait fonctionner sur un GPU unique, une configuration multi-GPU ou un CPU puissant.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_path = "lfm2.5-2.6b-instruct"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(
    model_path,
    torch_dtype=torch.bfloat16,
    device_map="auto",
)

L'argument `torch_dtype` réduit de moitié l'utilisation mémoire par rapport à la précision float32 complète, avec un coût de qualité négligeable.

6. Quantifier pour du matériel plus faible

Si votre machine a moins de 8 Go de RAM sans GPU, chargez le modèle en mode 4 bits. La quantification est le plus grand facteur de facilitation pour exécuter des agents locaux sur de vieux ordinateurs portables et des boîtiers Edge.

from transformers import BitsAndBytesConfig

quant_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.bfloat16,
)

model = AutoModelForCausalLM.from_pretrained(
    model_path,
    quantization_config=quant_config,
)

Avec la quantification 4 bits, LFM2.5-2.6B devient très léger en mémoire. Il y a une légère baisse de qualité de sortie, mais vous gagnez la possibilité d'exécuter l'agent sur presque n'importe quel ordinateur portable.

7. Alternative : l'exécuter avec llama.cpp sur CPU pur

Si vous préférez un runtime C++ hautement optimisé qui fonctionne bien sur les CPU et prend en charge la quantification GGUF, `llama.cpp` est un excellent choix. Tout d'abord, clonez et compilez-le :

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release

Ensuite, convertissez les poids Hugging Face au format GGUF :

python3 tools/convert_hf_to_gguf.py ../lfm2.5-2.6b-instruct --outfile lfm2.5-2.6b-q8.gguf

Enfin, exécutez une inférence brute pour vérifier l'installation :

./build/bin/llama-cli -m lfm2.5-2.6b-q8.gguf -p "Expliquez les agents locaux en une phrase." -n 128

Si vous voyez une phrase sensée s'afficher dans le terminal, le déploiement est opérationnel.

Exemples d'utilisation

Installer le modèle n'est que la moitié de la bataille. La vraie valeur vient lorsque vous l'enveloppez dans une boucle d'agent capable d'utiliser des outils. Ci-dessous, nous passons d'une simple invocation de chat à un agent complet avec appel d'outils et une API HTTP.

1. Génération de texte de base

Commencez par une génération simple pour confirmer que le modèle fonctionne de bout en bout. Nous utiliserons le template de chat du modèle afin que la sortie suive le format conversationnel.

prompt = tokenizer.apply_chat_template(
    [{"role": "user", "content": "Quel est le moyen le plus rapide de tester une boucle d'agent ?"}],
    tokenize=False,
    add_generation_prompt=True,
)

inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=256)
response = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True)
print(response)

Si cela fonctionne, le modèle est prêt à devenir un agent.

2. Construire une boucle d'agent avec appel d'outils

L'idée centrale d'un agent est une boucle : le modèle reçoit une tâche, décide quel outil appeler, l'outil s'exécute, le résultat est renvoyé, et le modèle produit la réponse finale. Voici une implémentation minimale mais complète en Python pur. Elle utilise des expressions régulières pour extraire une action JSON, ce qui maintient les dépendances à zéro.

import json
import re
from transformers import pipeline

generator = pipeline("text-generation", model=model, tokenizer=tokenizer)

# Exemples d'outils : remplacez par vos propres fonctions
TOOLS = {
    "get_weather": lambda city: f"Le temps à {city} est de 21°C et dégagé.",
    "get_git_status": lambda repo: "3 fichiers modifiés, 42 insertions(+)",
}

def run_agent(prompt: str, max_steps: int = 5) -> str:
    messages = [
        {
            "role": "system",
            "content": (
                "Vous êtes un agent local. Choisissez un outil et répondez en JSON "
                'dans ce format : {"tool": "nom", "args": {...}}. '
                "Sinon, répondez en texte brut."
            ),
        },
        {"role": "user", "content": prompt},
    ]

    for _ in range(max_steps):
        reply = generator(
            messages,
            max_new_tokens=120,
            do_sample=False,
        )[0]["generated_text"][-1]["content"]

        match = re.search(r'\{"tool": "(.*?)", "args": (\{.*?\})\}', reply, re.DOTALL)

        if not match:
            return reply

        tool_name, raw_args = match.group(1), match.group(2)
        args = json.loads(raw_args)

        result = TOOLS[tool_name](**args)

        messages.append({"role": "assistant", "content": reply})
        messages.append({"role": "tool", "content": result})

    return "Nombre maximal d'étapes atteint sans conclusion."

print(run_agent("Quel temps fait-il à Bruxelles ?"))

Décomposons ce qui se passe ici. Le prompt système demande au modèle d'émettre du JSON lorsqu'il souhaite appeler un outil. La boucle détecte ce JSON, exécute la fonction Python correspondante, ajoute le résultat comme nouveau message, et laisse le modèle continuer. Lorsque le modèle décide qu'aucun outil n'est nécessaire, la boucle se termine et renvoie la réponse en texte brut.

Ce modèle est volontairement léger. Il ne dépend pas de LangChain ni d'un framework d'agent, ce qui signifie qu'il peut fonctionner n'importe où — y compris dans un conteneur Docker sur un Raspberry Pi. Si vous avez besoin d'un format plus structuré, consultez la fiche du modèle LFM2.5 pour la syntaxe exacte d'appel de fonctions sur laquelle il a été entraîné ; la boucle générale reste la même.

3. Servir l'agent comme API HTTP

Un agent local est beaucoup plus utile lorsque d'autres processus peuvent l'appeler. Exposons la boucle de l'agent via un petit serveur FastAPI afin que des scripts, des tableaux de bord, et même d'autres machines sur votre réseau local puissent lui parler.

Tout d'abord, installez les dépendances du serveur :

pip install fastapi uvicorn pydantic

Enregistrez le code suivant sous le nom `server.py` :

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class AgentRequest(BaseModel):
    prompt: str
    max_steps: int = 5

class AgentResponse(BaseModel):
    output: str

@app.post("/agent", response_model=AgentResponse)
def agent_endpoint(req: AgentRequest):
    return AgentResponse(output=run_agent(req.prompt, req.max_steps))

Puis démarrez le serveur :

uvicorn server:app --host 0.0.0.0 --port 8000

Le drapeau `--host 0.0.0.0` rend l'API disponible aux autres appareils de votre réseau, de sorte que votre téléphone, l'ordinateur portable d'un collègue ou un module IoT puissent tous envoyer des requêtes au même agent local.

Testez avec `curl` :

curl -X POST http://localhost:8000/agent \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Quel temps fait-il à Bruxelles ?"}'

Passer à des déploiements locaux de style production

Les exemples ci-dessus couvrent une utilisation mono-utilisateur. Si vous prévoyez de déployer LFM2.5-2.6B comme service d'agent pour une équipe ou une flotte d'appareils, envisagez de passer de `transformers` à un moteur d'inférence de qualité production comme `vLLM`, qui offre un batch continu et un débit bien supérieur. L'installation est simple :

pip install vllm

Puis démarrez un point de terminaison compatible OpenAI :

vllm serve votre-org/LFM2.5-2.6B-instruct --max-model-len 8192

Une fois en service, les bibliothèques client OpenAI standard peuvent s'y connecter en pointant l'URL de base vers `http://localhost:8000/v1`. Cela vous permet de réutiliser les frameworks et outils d'agent existants sans dépenser de crédits cloud.

Pour les déploiements de flotte « partout » — y compris les appareils Edge avec du matériel GPU/CPU mixte — conservez un seul point de contrôle GGUF ou 4 bits partagé, poussez-le vers chaque appareil via votre outil standard de gestion de configuration, et exécutez la même boucle d'agent partout.

Conclusion

Les agents locaux ne sont plus un passe-temps de niche. L'industrie de l'IA évolue dans deux directions complémentaires à la fois : les laboratoires frontières comme OpenAI, Microsoft et Anthropic continuent de pousser les agents à l'échelle du cloud, tandis que la communauté open-source, suivie de près sur le blog Hugging Face, prouve que les petits modèles peuvent gérer une quantité surprenante d'automatisation réelle. LFM2.5-2.6B s'inscrit parfaitement dans cette deuxième catégorie.

Dans cet article, vous avez parcouru le cycle de vie complet d'un déploiement d'agent local : installation de l'environnement Python, récupération des poids du modèle depuis Hugging Face, chargement en pleine précision ou quantifié, construction d'une boucle d'appel d'outils à partir de zéro, et exposition de cette boucle via HTTP. Vous avez également vu le chemin vers une configuration de qualité production avec `vLLM` ou un backend CPU pur `llama.cpp`.

L'essentiel est simple : avec environ 2,6 milliards de paramètres et la bonne pipeline de déploiement, vous n'avez pas besoin d'un centre de données pour exécuter un agent. Vous avez besoin d'un ordinateur portable, de quelques outils et de la volonté d'expérimenter. Les agents que vous construisez peuvent lire vos fichiers, interroger le web, vérifier la météo, gérer des dépôts git ou automatiser votre maison — tout cela localement, en privé et sans frais récurrents.

C'est la promesse de déployer des agents locaux partout. Le modèle est chargé. Les outils sont connectés. Que fera votre agent ?