Exécuter LFM3 avec Ollama sur un VPS Linux : un LLM de 1,7 milliard de paramètres qui tourne sur CPU avec 2 Go de RAM

LFM3 : un LLM de 1,7 milliard de paramètres pensé pour tourner sans GPU

LFM3 est la famille de modèles de langage open weights annoncée par Liquid AI le 27 octobre 2026. Six modèles d'environ 2 milliards de paramètres sont dérivés d'un même tronc, LFM3-1.7B-Base : un modèle texte, un modèle vision, un modèle audio, un modèle omni (texte, image, audio) et deux modèles de décision. Le modèle texte, LFM3-1.7B, compte exactement 1,73 milliard de paramètres, accepte un contexte de 256K tokens (entrée et sortie confondues), appelle des outils nativement, produit des sorties structurées et comprend seize langues dont le français. Il est publié sous licence LFM Open License v1.0 et distribué dans la bibliothèque Ollama sous le nom lfm3.

Ce qui le rend intéressant pour un administrateur de VPS Linux, c'est sa taille et son architecture. Le fichier GGUF Q4_K_M pèse 1,1 Go ; Liquid AI indique qu'en précision 4 bits le modèle occupe environ 1 Go de mémoire. L'architecture dite tri-hybride compte 24 couches : 13 couches de convolution courte à porte, 5 couches d'attention à fenêtre glissante (256 tokens) et seulement 6 couches d'attention globale. Seules ces 6 couches font grossir le cache KV avec la longueur du contexte : d'après Liquid AI, un contexte plein de 128K tokens coûte 1,6 Go de cache KV, contre 4,3 Go pour Qwen3.5-4B et 5,6 Go pour MiniCPM5-2B. En inférence CPU, où chaque token généré oblige le processeur à relire tous les poids, un modèle de 1,1 Go produit des dizaines de tokens par seconde là où un 27B en produit deux ou trois (Qwen 3.8 27B sur un VPS sans GPU).

Ce tutoriel part d'un serveur virtuel KVM où Ollama tourne déjà en service systemd (installer Ollama sur un VPS Linux). Ollama et le moteur llama.cpp qu'il embarque sont des logiciels open source sous licence MIT ; LFM3 est un modèle à poids ouverts sous sa propre licence, sans cluster de GPU ni abonnement à une API. Le guide détaille ce qui est propre à LFM3 : la version d'Ollama à avoir, les tags du registre, le débit à attendre sur 2 et 4 vCPU, la mémoire selon le contexte, les fichiers, logs et sauvegardes du modèle, le mode réflexion, l'appel d'outils, les clients Python, PHP et shell, l'exposition de l'API derrière un serveur web, les variantes vision et audio, et surtout les usages pour lesquels un modèle de cette taille est pertinent.

Prérequis : Ollama 0.40.13 au minimum, 4 Go de RAM, 2 vCPU

Le premier prérequis est la version d'Ollama, et c'est le piège de ce modèle. Ollama 0.40.12, publié le 27 octobre 2026, a ajouté LFM3 uniquement sur Apple Silicon via le moteur MLX, les notes de version annonçant le support Linux et Windows pour plus tard. Sur un serveur Linux à jour ce jour-là, ollama pull lfm3 renvoyait « this model requires MLX support, but the MLX runtime is not available », et le chargement d'un GGUF LFM3 téléchargé depuis Hugging Face échouait avec « error loading model: unknown model architecture: 'lfm3' » (ticket GitHub ollama/ollama n° 19347, ouvert le 27 octobre). Le llama.cpp embarqué dans Ollama ne connaissait pas encore l'architecture. Ollama 0.40.13, publié le 28 octobre, synchronise llama.cpp et fait tourner les modèles LFM3 sur Linux et Windows ; la version stable courante est la 0.40.15 du 3 novembre 2026. Vérifiez et mettez à jour avant toute chose :

ollama -v
curl -fsSL https://ollama.com/install.sh | sh
sudo systemctl restart ollama

La fiche du modèle dans le registre déclare la version minimale : un binaire trop ancien refuse de le charger avec un message explicite demandant la 0.40.13 ou plus récente, ce qui est plus clair que l'erreur d'architecture inconnue des premiers jours.

• Distribution : Ubuntu 22.04/24.04 LTS ou Debian 12/13, avec un accès SSH et un compte sudo ou root (sécuriser SSH sur un VPS Linux). Le script d'installation se relance en sudo s'il n'est pas root, place le binaire sous /usr/local, crée un utilisateur Unix de service ollama sans shell (useradd -r -s /bin/false, répertoire /usr/share/ollama) et écrit l'unité /etc/systemd/system/ollama.service qui tourne sous cet utilisateur. Deux paquets sont nécessaires avant de le lancer : curl, qui télécharge le script, et zstd, sans lequel le script s'arrête en indiquant la commande apt-get install zstd, car le binaire est distribué en archive .tar.zst ;
• RAM : le modèle chargé avec son contexte par défaut occupe environ 1,4 Go d'après les mesures publiées avec ollama ps, et 2 Go suffisent à le faire tourner avec un contexte de 32K. Mais le VPS héberge aussi un système, Ollama lui-même et l'application qui interroge le modèle : 4 Go est le minimum confortable, 8 Go si vous ouvrez le contexte au-delà de 64K ou si un bot et une base de données partagent la machine ;
• vCPU : 2 vCPU suffisent pour un usage mono-utilisateur, 4 vCPU accélèrent la lecture des prompts longs. Sous virtualisation KVM, le vCPU vendu par l'hébergeur est un thread du processeur de l'hôte, dont la fréquence et la charge des voisins fixent le débit réel. Le jeu d'instructions compte autant que le nombre de coeurs : llama.cpp s'appuie sur AVX2, présent sur tous les processeurs de serveur récents (pourquoi tous les vCPU ne se valent pas) ;
• Disque : 2 Go libres pour le tag Q4_K_M, 4 Go si vous comparez avec la Q8_0.

Chez ElypseCloud, le palier VPS Linux Starter (2 vCPU Xeon E5-2697 v4, 4 Go DDR4, 50 Go SSD) est le premier qui accueille LFM3 avec une marge pour le système et une application. Le palier Classic (4 vCPU, 8 Go DDR4, 70 Go SSD) permet un contexte long, un second modèle chargé ou un bot Discord et sa base de données à côté. C'est un ordre de grandeur en dessous des 32 Go exigés par un modèle 27B.

Sous Windows, Ollama s'installe avec OllamaSetup.exe dans le profil de l'utilisateur, tourne en application de bureau en arrière-plan, expose la même API sur localhost:11434 et écrit ses logs dans %LOCALAPPDATA%\Ollama (server.log) ; pour un vrai service, la documentation renvoie à l'archive ollama-windows-amd64.zip et à ollama serve lancé par NSSM. Les notes de version 0.40.13 annoncent LFM3 sur Windows comme sur Linux, mais la fiche Windows d'Ollama exige Windows 10 22H2 ou plus récent : vérifiez la compatibilité de votre édition avant de transposer ce guide sur un VPS Windows. Sur Linux, le service systemd, le reverse proxy et les sauvegardes s'automatisent plus simplement, et c'est la voie suivie ici.

ollama pull lfm3 : tags, quantisations et vérification

Le registre Ollama liste neuf tags pour lfm3, tous à 1,7 milliard de paramètres et 256K de contexte, en entrée texte uniquement. Le tag par défaut (lfm3, alias lfm3:1.7b) se résout sur Linux en Q4_K_M, soit 1,1 Go. Les tags marqués MLX sont destinés aux Mac Apple Silicon et aux GPU NVIDIA et ne servent à rien sur un VPS CPU :

Téléchargez le tag explicite, puis lisez ses métadonnées :

ollama pull lfm3:1.7b-q4_K_M
ollama show lfm3:1.7b-q4_K_M

Trois points à contrôler dans la sortie de ollama show : l'architecture lfm3, la liste des capacités (tools et thinking doivent y figurer) et les paramètres embarqués. Le tag officiel porte les valeurs d'échantillonnage recommandées par Liquid AI : température 0,1, top_k 50, repeat_penalty 1,1 avec repeat_last_n à -1. Vous n'avez donc rien à régler pour les usages généraux. Si ollama show n'affiche pas la capacité tools, vous avez probablement un GGUF importé depuis Hugging Face via hf.co/... plutôt que le tag du registre : le modèle du registre embarque le gabarit de conversation et le format d'appel d'outils de LFM3, un fichier importé peut ne pas les porter. Supprimez-le et reprenez le tag officiel (gérer ses modèles Ollama).

Premier test avec --verbose, qui affiche les débits à la fin de la réponse :

ollama run lfm3:1.7b-q4_K_M --verbose "Classe ce message en spam, insulte ou normal : 'venez sur mon serveur, lien en bio'"

Débit sur 2 et 4 vCPU : ce qu'il faut attendre et comment le mesurer

Deux lignes comptent dans le résumé de --verbose : prompt eval rate (vitesse de lecture du prompt, en tokens par seconde) et eval rate (vitesse de génération). Sur CPU, la génération est bornée par la bande passante mémoire et le calcul : pour un fichier de 1,1 Go, le plafond théorique à 20 Go/s de bande passante effective dépasse 15 tokens par seconde, et c'est le calcul sur deux coeurs qui devient la vraie limite. Liquid AI ne publie pas de mesure CPU seule : ses chiffres (43,6 tokens/s sur iPhone 17 Pro, 129,6 sur Ryzen AI Max+ 395, 237,1 sur Apple M5 Max) sont obtenus avec déchargement GPU. Les tests indépendants publiés depuis donnent les repères suivants :

Ces chiffres ne sont pas les nôtres : ils dépendent du processeur de l'hôte, de la charge des voisins et de la fréquence réelle de vos vCPU. Mesurez sur votre serveur, en répétant la même commande trois fois pour lisser le premier chargement depuis le disque. Passer de 2 à 4 vCPU améliore surtout le prompt eval rate, donc le temps avant le premier token sur un prompt long (une page de logs, un ticket avec son historique) ; le gain en génération pure est réel mais pas proportionnel, llama.cpp ne tirant pas un gain linéaire de coeurs supplémentaires sur un modèle aussi petit. Pendant la mesure, ouvrez un second terminal :

ollama ps

La colonne SIZE donne la mémoire réellement occupée (poids plus cache KV), la colonne PROCESSOR affiche 100% CPU. Complétez avec htop ou btop pour vérifier que les vCPU sont bien saturés pendant la génération : s'ils ne le sont pas, c'est que le modèle attend la mémoire, et le swap est le premier suspect. Pour un bot en production, ajoutez une sonde de monitoring sur http://127.0.0.1:11434/api/version, qui répond tant que le service est vivant, et une alerte sur la RAM disponible (mettre en place des alertes de monitoring) : sur ce modèle, une dérive de débit vient presque toujours d'une mémoire qui se remplit.

Mémoire, contexte 256K et réglages systemd

Ollama ouvre chaque modèle avec une fenêtre de 4 096 tokens par défaut, quelle que soit la limite du modèle. Avec LFM3, ouvrir le contexte coûte peu : d'après le chiffre de Liquid AI (1,6 Go pour 128K), le cache KV revient à environ 12 Ko par token, et les mesures publiées avec ollama ps sur le tag Q4_K_M le confirment :

Le contexte long a un autre coût que la RAM : la lecture du prompt sur CPU se compte en dizaines de tokens par seconde, et 32 768 tokens demandent de longues minutes avant le premier mot de la réponse. Et la fiche Hugging Face du modèle donne un score RULER 128K de 65,56, quand Liquid AI reconnaît que les modèles plus gros gardent l'avantage sur les tâches de connaissance : le modèle accepte 256K, il ne les exploite pas aussi finement qu'un modèle de 9 ou 27 milliards de paramètres. Pour un VPS 4 Go, 16 384 ou 32 768 tokens sont le bon compromis.

Les limites se fixent dans une surcharge systemd, sans toucher au fichier d'unité installé par le script (comprendre les unités systemd) :

sudo systemctl edit ollama.service

Section [Service] pour un VPS 4 Go dédié à LFM3 :

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_CONTEXT_LENGTH=32768"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_KEEP_ALIVE=-1"

• OLLAMA_CONTEXT_LENGTH : fenêtre par défaut pour tous les modèles ; une requête peut la dépasser ponctuellement avec l'option num_ctx de l'API ;
• OLLAMA_NUM_PARALLEL : requêtes traitées en parallèle par modèle, 1 par défaut. Avec LFM3, passer à 2 est envisageable sur 4 vCPU : le cache KV est multiplié d'autant, mais il reste petit ;
• OLLAMA_MAX_LOADED_MODELS : 3 par défaut en inférence CPU. Sur 4 Go, limitez à 1 pour qu'un ollama run d'essai sur un autre modèle ne pousse pas le serveur en swap ;
• OLLAMA_KEEP_ALIVE : 5 minutes par défaut avant déchargement. À 1,4 Go, garder LFM3 chargé en permanence (-1) ne coûte presque rien et supprime la latence de rechargement pour un bot qui répond à toute heure.

La quantisation du cache KV (OLLAMA_KV_CACHE_TYPE=q8_0, qui exige Flash Attention) n'a d'intérêt qu'au-delà de 128K de contexte : en dessous, le cache de LFM3 est déjà négligeable. Appliquez et redémarrez :

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -u ollama -n 30

Gardez un swap de 1 ou 2 Go comme filet de sécurité, jamais comme extension de RAM (configurer le swap sur un VPS Linux) : le test à 0,72 token par seconde cité plus haut montre ce qu'il en coûte. Si la mémoire sature malgré tout, le noyau tue le processus ollama et la requête échoue sans message côté client ; les traces se lisent dans journalctl -k (comprendre l'OOM Killer).

Fichiers, logs et sauvegarde : où vit LFM3 sur le disque

Avec l'installation standard, Ollama range les modèles dans /usr/share/ollama/.ollama/models, le répertoire personnel de l'utilisateur Unix ollama. Un tag n'est pas un fichier GGUF nommé mais un manifeste et des blobs adressés par empreinte, ce qui explique qu'un ls n'y montre rien de lisible et que ollama list reste la bonne commande d'inventaire. Pour déplacer ce stockage sur un disque plus grand, la FAQ d'Ollama indique la variable OLLAMA_MODELS, à ajouter dans la surcharge systemd vue plus haut (fichier /etc/systemd/system/ollama.service.d/override.conf), et un chown -R ollama:ollama sur le nouveau répertoire, sans quoi le service ne peut plus écrire.

Les logs du service sont dans le journal systemd : journalctl -e -u ollama affiche la fin du journal, et la variable OLLAMA_DEBUG=1 dans la même surcharge rend les traces verbeuses le temps d'un diagnostic (chargement du modèle, allocation mémoire, requêtes reçues). Un « unknown model architecture » ou un « 403 » renvoyé à un client s'y lisent en clair, quand le client, lui, ne voit qu'une erreur générique.

Pour la configuration du modèle, préférez un Modelfile versionné dans Git plutôt que des options répétées dans chaque appel. Il part du tag officiel et n'écrit que ce qui change ; les paramètres non mentionnés gardent les valeurs du tag d'origine, à contrôler avec ollama show --modelfile :

FROM lfm3:1.7b-q4_K_M
PARAMETER num_ctx 32768
SYSTEM """Tu es le modérateur du serveur. Tu réponds en français, en une ligne, sans commentaire."""

ollama create moderation-lfm3 -f Modelfile
ollama show --modelfile moderation-lfm3

Côté sauvegarde, ce Modelfile de trois lignes et la liste des tags suffisent : restaurer un VPS, c'est réinstaller Ollama, relancer ollama pull lfm3:1.7b-q4_K_M puis ollama create. Archiver les blobs de 1,1 Go n'a de sens que si le serveur n'a pas accès au registre ou si vous voulez une copie figée : dans ce cas, rsync du répertoire des modèles vers une machine distante, service arrêté, fait l'affaire (sauvegarder un VPS avec rsync). Ce qui mérite une vraie sauvegarde, ce sont les données que le modèle produit, à savoir les classifications, les extractions et les décisions du bot, rangées dans vos bases de données MySQL ou PostgreSQL, et pas les poids, qui se retéléchargent en une minute.

Mode réflexion et paramètres d'échantillonnage

LFM3 réfléchit par défaut : avant de répondre, il produit un bloc de raisonnement. Sur un modèle de cette taille, ce bloc multiplie souvent le nombre de tokens générés par quatre pour une tâche simple. Le test du 2 novembre le chiffre sur un même appel d'outil : 83 tokens et 12,5 secondes avec réflexion, 18 tokens et 3,3 secondes sans. Pour la classification, l'extraction et les réponses courtes d'un bot, désactivez-la ; gardez-la pour les questions qui demandent plusieurs étapes. Liquid AI précise sur la fiche du modèle que la désactivation peut être inconsistante : vérifiez sur vos propres prompts que le champ de raisonnement reste vide.

ollama run lfm3:1.7b-q4_K_M --think=false "Extrais le pseudo et le motif de ce ticket : 'Joueur Dark_Nico banni pour injures vocales'"

Dans l'API, le champ think accepte true, false ou null (défaut du modèle). La réponse sépare le raisonnement (message.thinking) du contenu (message.content) :

curl http://localhost:11434/api/chat -d '{
  "model": "lfm3:1.7b-q4_K_M",
  "messages": [{"role": "user", "content": "Résume ce journal systemd en trois points."}],
  "think": false,
  "stream": false,
  "options": {"num_ctx": 16384, "temperature": 0.1, "top_k": 50, "repeat_penalty": 1.1}
}'

Les valeurs d'échantillonnage ci-dessus sont celles que Liquid AI recommande pour la conversation, l'appel d'outils et les agents (température 0,1, top_k 50, pénalité de répétition 1,1) ; elles sont déjà embarquées dans le tag du registre, les répéter dans options protège seulement contre un Modelfile qui les aurait changées. Pour les mathématiques et les sciences, la fiche recommande au contraire température 1,0, top_p 0,95 et top_k 20. Utiliser le profil agent sur un problème de maths est le moyen le plus sûr de faire paraître le modèle plus mauvais qu'il n'est.

Appel d'outils et sorties structurées : le vrai usage de LFM3

Liquid AI a post-entraîné LFM3-1.7B pour les harnais d'agents (Hermes Agent, Pi, OpenClaw) et le présente comme un modèle d'agents locaux, d'appel d'outils et de sorties structurées. Les scores publiés par l'éditeur vont dans ce sens : 71,39 sur BFCL V4 et 80,36 sur ToolSandbox (appel d'outils), 96,66 sur IFEval (suivi d'instructions). À l'inverse, 32,57 sur MCP-Atlas montre qu'il est à l'aise avec un outil au contrat clair et nettement moins sur des enchaînements de plusieurs outils. Dimensionnez vos cas d'usage en conséquence : un outil par requête, un schéma de sortie strict.

L'appel d'outils passe par le champ tools de /api/chat. Le modèle répond avec message.tool_calls, votre code exécute la fonction et renvoie le résultat dans un message de rôle tool :

curl -s http://localhost:11434/api/chat -H "Content-Type: application/json" -d '{
  "model": "lfm3:1.7b-q4_K_M",
  "think": false,
  "stream": false,
  "messages": [{"role": "user", "content": "Le joueur Dark_Nico spamme le chat, applique la sanction prévue."}],
  "tools": [{"type": "function", "function": {
    "name": "sanctionner_joueur",
    "description": "Applique une sanction à un joueur du serveur de jeu",
    "parameters": {"type": "object", "required": ["pseudo", "sanction"],
      "properties": {
        "pseudo": {"type": "string", "description": "Pseudo exact du joueur"},
        "sanction": {"type": "string", "enum": ["avertissement", "mute_1h", "kick"]}
      }}}}]
}'

Pour l'extraction et la classification, les sorties structurées sont encore plus simples : le champ format accepte un schéma JSON et contraint la réponse à cette structure. La documentation Ollama conseille de rappeler le schéma dans le prompt et de baisser la température, ce que le tag LFM3 fait déjà :

curl -s http://localhost:11434/api/chat -H "Content-Type: application/json" -d '{
  "model": "lfm3:1.7b-q4_K_M",
  "think": false,
  "stream": false,
  "messages": [{"role": "user", "content": "Classe ce ticket et extrais les champs : 'Bonjour, impossible de me connecter au serveur depuis la mise à jour, erreur de connexion, pseudo Lila_R'"}],
  "format": {"type": "object", "required": ["categorie", "urgence", "pseudo"],
    "properties": {
      "categorie": {"type": "string", "enum": ["connexion", "sanction", "bug", "paiement", "autre"]},
      "urgence": {"type": "string", "enum": ["faible", "normale", "haute"]},
      "pseudo": {"type": "string"}
    }}
}'

Le même mécanisme est disponible sur l'endpoint compatible OpenAI via response_format, ce qui permet de brancher LFM3 sur un workflow n8n ou sur n'importe quel SDK en changeant seulement l'URL de base. Pour un agent complet, la fiche Ollama du modèle documente ollama launch hermes --model lfm3 et ollama launch openclaw --model lfm3, qui configurent l'agent pour utiliser le modèle local (installer Hermes Agent sur un VPS). Réglez alors OLLAMA_CONTEXT_LENGTH à 32 768 au moins : un harnais d'agent envoie des prompts système longs, et un contexte de 4 096 tokens tronque l'historique.

Appeler LFM3 depuis Python, PHP ou un script shell

Les exemples curl ci-dessus suffisent pour tester ; un bot ou un site passe par un client. En Python, la bibliothèque officielle s'installe avec le paquet ollama depuis PyPI. Debian 12 et Ubuntu 24.04 refusent un pip install hors d'un environnement virtuel (erreur « externally-managed-environment ») : créez-en un, ce qui suppose le paquet python3-venv de la distribution :

sudo apt install -y python3-venv
python3 -m venv ~/lfm3-env
~/lfm3-env/bin/pip install ollama

La fonction chat reprend les champs de l'API, y compris think et format, et la réponse se lit dans response.message.content :

from ollama import chat

schema = {"type": "object", "required": ["categorie", "urgence"],
          "properties": {
              "categorie": {"type": "string", "enum": ["connexion", "sanction", "bug", "paiement", "autre"]},
              "urgence": {"type": "string", "enum": ["faible", "normale", "haute"]}}}

ticket = "Impossible de me connecter depuis la mise à jour, pseudo Lila_R"
reponse = chat(model="lfm3:1.7b-q4_K_M", think=False, format=schema,
               messages=[{"role": "user", "content": "Classe ce ticket : " + ticket}])
print(reponse.message.content)

Pour l'appel d'outils, le client Python accepte directement une fonction dans la liste tools : il construit le schéma à partir de sa signature et de sa docstring, et response.message.tool_calls contient le nom et les arguments à exécuter. Le client Client(host=...) sert quand le modèle tourne sur un autre serveur que le script.

Depuis un site en PHP (un formulaire de signalement, un espace d'administration hébergé sur le même VPS avec PHP-FPM), l'extension curl suffit, sans bibliothèque supplémentaire :

$ch = curl_init('http://127.0.0.1:11434/api/chat');
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => ['Content-Type: application/json'],
    CURLOPT_POSTFIELDS => json_encode([
        'model' => 'lfm3:1.7b-q4_K_M', 'think' => false, 'stream' => false,
        'messages' => [['role' => 'user', 'content' => 'Ce message est-il du spam ? Réponds oui ou non : ' . $message]],
    ]),
]);
$reponse = json_decode(curl_exec($ch), true);
echo $reponse['message']['content'];

Pour un traitement par lots lancé par cron ou un timer systemd (planifier des tâches sur un VPS Linux), un script shell avec curl et le paquet jq fait le travail. Construisez le JSON avec jq plutôt qu'en concaténant des chaînes, sinon un guillemet dans le texte casse la requête :

#!/bin/bash
while IFS= read -r ticket; do
  payload=$(jq -n --arg t "$ticket" '{model: "lfm3:1.7b-q4_K_M", think: false, stream: false,
    messages: [{role: "user", content: ("Classe en spam ou normal, un seul mot : " + $t)}]}')
  verdict=$(curl -s http://127.0.0.1:11434/api/chat -d "$payload" | jq -r '.message.content')
  echo "$ticket;$verdict" >> resultats.csv
done < tickets.txt

Dans les trois cas, le résultat finit dans une base de données plutôt que dans un fichier plat dès que le volume dépasse quelques centaines de lignes par jour : une table MySQL ou MariaDB (installer MySQL sur un VPS Linux) ou PostgreSQL (installer PostgreSQL sur un VPS Linux) avec le texte d'origine, le verdict du modèle et la date, ce qui permet de relire les erreurs de classification et d'ajuster le prompt. Sur un VPS 4 Go, le serveur de base de données et LFM3 cohabitent sans difficulté tant que le contexte reste à 32K.

Exposer l'API Ollama derrière NGINX ou Apache, avec un nom de domaine

L'API Ollama n'a aucune authentification propre : laissez le service sur 127.0.0.1:11434 et placez un serveur web devant, avec une authentification HTTP Basic et un certificat Let's Encrypt. Il faut d'abord un nom de domaine : créez dans sa zone DNS un enregistrement A (et AAAA si le VPS a une IPv6) pointant vers l'adresse IP publique du serveur, puis vérifiez la résolution avec dig ollama.example.com avant de demander le certificat, car Certbot échoue tant que le DNS ne répond pas la bonne adresse (diagnostiquer la résolution DNS sous Linux). La configuration NGINX complète (fichier htpasswd, bloc server, en-têtes) est détaillée dans NGINX en reverse proxy sur VPS Linux. La différence avec un gros modèle tient aux délais : à 10 tokens par seconde, une réponse de 500 tokens prend moins d'une minute, les 300 secondes par défaut du guide générique suffisent largement. Le point qui reste indispensable est proxy_buffering off, sans lequel NGINX retient la réponse en streaming jusqu'à la fin :

    location / {
        auth_basic "Ollama API";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 300s;
    }

L'en-tête Host réécrit en localhost:11434 n'est pas un détail : quand Ollama écoute sur l'adresse de bouclage, son code vérifie l'en-tête Host de chaque requête et n'accepte que localhost, une adresse IP locale ou privée, le nom de la machine ou un suffixe .local ; tout autre hôte, par exemple votre nom de domaine transmis tel quel par le proxy, reçoit un 403 Forbidden.

Si un serveur web Apache est déjà en place sur le VPS, inutile d'ajouter NGINX : mod_proxy_http et l'authentification Basic font la même chose. Activez les modules (sudo a2enmod proxy proxy_http), créez le fichier de mots de passe avec htpasswd -c /etc/apache2/.htpasswd ollama-user (paquet apache2-utils) et ajoutez au VirtualHost :

<Location "/">
    AuthType Basic
    AuthName "Ollama API"
    AuthUserFile /etc/apache2/.htpasswd
    Require valid-user
    ProxyPass "http://127.0.0.1:11434/" timeout=300
    ProxyPassReverse "http://127.0.0.1:11434/"
</Location>

Laissez ProxyPreserveHost à sa valeur par défaut (Off) : Apache envoie alors l'hôte de la ligne ProxyPass, soit 127.0.0.1, que la vérification d'Ollama accepte. Le paramètre timeout joue le rôle de proxy_read_timeout. Une réserve : d'après la documentation Apache, le paramètre flushpackets de ProxyPass ne s'applique qu'aux backends AJP et FastCGI, donc pour un client qui lit la réponse en streaming, NGINX avec proxy_buffering off reste la configuration dont le comportement est documenté ; derrière Apache, envoyez "stream": false.

Rechargez NGINX après sudo nginx -t (ou Apache après sudo apache2ctl configtest), obtenez le certificat avec Certbot et Let's Encrypt, et n'ouvrez au firewall que les ports 22, 80 et 443, jamais le 11434, que ce soit avec UFW (configurer UFW sur un VPS Linux) ou nftables (pare-feu nftables sur un VPS Linux). Depuis un poste distant, l'endpoint compatible OpenAI s'utilise ainsi :

curl -u ollama-user:VOTRE_MOT_DE_PASSE https://ollama.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "lfm3:1.7b-q4_K_M", "messages": [{"role": "user", "content": "Bonjour"}]}'

Si le bot ou l'application qui interroge LFM3 tourne sur le même VPS, n'exposez rien du tout : il parle à 127.0.0.1:11434 et NGINX ne sert qu'à une éventuelle interface de chat (installer Open WebUI avec Docker), qui sur un VPS 4 Go consomme quelques centaines de Mo à côté du modèle.

Variantes vision, audio et omni sous Ollama : ce qui marche sur un VPS CPU

Les autres membres de la famille sont aussi dans le registre Ollama : lfm3-vl, lfm3-audio et lfm3-omni. Les notes de version d'Ollama 0.40.13 indiquent qu'ils tournent sur Linux et Windows depuis cette version, y compris la synthèse vocale de lfm3-audio et lfm3-omni. Avant 0.40.13, ils étaient réservés à Apple Silicon.

Sur un VPS CPU, trois limites à connaître. D'abord le coût de lecture : une image est découpée en blocs de patchs qui deviennent des tokens (un par bloc de 2 x 2 sur lfm3-omni), et chaque image ajoute donc des centaines de tokens au prompt, lus à la vitesse du prompt eval rate de votre processeur. Ensuite la RAM : d'après les tailles des tags, les encodeurs ajoutent 400 Mo à 1,3 Go au modèle texte, ce qui reste dans un VPS 4 Go mais interdit d'en charger deux à la fois. Enfin le contexte : la fiche de lfm3-audio et celle de lfm3-omni donnent 32K, bien en dessous des 256K du modèle texte. Le test d'une image passe par le chemin d'un fichier présent sur le serveur, donc envoyé au préalable par SFTP ou scp, c'est-à-dire par le canal SSH déjà ouvert, sans installer de serveur FTP, puis indiqué dans le prompt :

ollama pull lfm3-vl:2b-q4_K_M
ollama run lfm3-vl:2b-q4_K_M --verbose "Cette capture d'écran contient-elle un lien ou un texte publicitaire ? /home/admin/capture.png"

C'est un usage réaliste pour un serveur de jeu : vérifier les images postées sur un Discord ou un forum avant publication. Pour la parole, lfm3-audio s'utilise par l'API, en envoyant l'audio au modèle et en récupérant du texte ou de l'audio ; gardez la synthèse vocale pour des messages courts, le temps de génération sur CPU grimpe vite.

Usages réalistes, et ce qu'il ne faut pas demander à un 1,7B

Liquid AI est explicite sur la fiche du modèle : LFM3-1.7B « n'est pas recommandé pour le codage agentique ni le raisonnement complexe en plusieurs étapes en raison de sa petite taille », et les tâches qui reposent sur des connaissances doivent s'appuyer sur une recherche ou une récupération de documents. Les scores de l'éditeur le confirment : 43,40 sur SWE-bench Verified et 12,92 sur Terminal-Bench 2.1, loin des modèles de code. Ne branchez donc pas LFM3 sur un agent de code qui enchaîne des dizaines d'appels : c'est l'usage le plus coûteux sur CPU et celui où le modèle est le plus faible. Ce pour quoi il est fait, sur un VPS 4 Go :

Un mot sur la licence, puisque ces usages sont souvent commerciaux : la LFM Open License v1.0 accorde une licence perpétuelle et sans redevance, à condition que vous ou votre entité ne dépassiez pas 10 millions de dollars de chiffre d'affaires annuel ; au-delà, l'usage commercial n'est pas couvert et suppose un accord avec Liquid AI. Les organisations à but non lucratif qualifiées en sont exemptées, et la redistribution impose de joindre la licence et de signaler les fichiers modifiés. Pour un propriétaire de serveur de jeu ou une petite structure, c'est en pratique un usage libre ; lisez le texte avec ollama show lfm3 --license.

Quand le besoin dépasse ce cadre (plusieurs utilisateurs simultanés, raisonnement long, code), ce n'est pas un réglage qui manque mais un modèle plus gros et une machine à sa mesure : un serveur dédié à forte RAM pour un 27B sur CPU (LLM sur CPU avec llama.cpp sur Xeon Gold), ou un GPU avec vLLM pour la charge concurrente (vLLM vs Ollama sur serveur dédié).

Conclusion

LFM3 change l'échelle du LLM auto-hébergé : un modèle de 1,73 milliard de paramètres, 1,1 Go en Q4_K_M, 1,4 Go chargé, qui génère une dizaine de tokens par seconde sur 2 vCPU sans GPU et ouvre 32K de contexte pour 100 Mo de plus. La recette sur un VPS Linux tient en cinq points : Ollama 0.40.13 ou plus récent (sinon « unknown model architecture: 'lfm3' »), le tag lfm3:1.7b-q4_K_M du registre officiel plutôt qu'un GGUF importé, un contexte fixé à 32 768 dans la surcharge systemd avec le modèle gardé chargé et un Modelfile versionné dans Git, la réflexion désactivée pour les tâches simples, et des usages qui collent à sa taille : classification, extraction avec schéma JSON, bots de modération, agents locaux à un outil, le tout appelé depuis Python, PHP ou un script shell et exposé, si besoin, derrière NGINX ou Apache sur votre nom de domaine. Mesurez avec --verbose et ollama ps sur votre propre serveur : avec ce modèle, les deux chiffres tiennent dans un VPS Starter, et c'est précisément ce qui le rend utile.