llama.cpp 0.8.0 : nouveaux modèles, voix en temps réel et fonctionnalités d’IA locale

llama.cpp v0.8.0 est une mise à jour importante pour l’IA locale, en particulier pour l’inférence multimodale. Sortie le 28 octobre 2026, elle ajoute la prise en charge de la famille LFM3 de Liquid AI, de nouvelles architectures de modèles, dont DeepSeek V4.1 Flash, ainsi que des fonctionnalités expérimentales d’audio en temps réel via /v1/realtime et de synthèse vocale via POST /tts. Elle améliore également la gestion des modèles, les outils serveur et plusieurs mécanismes de gestion de la mémoire. Cela ne signifie pas que toutes les architectures nouvellement répertoriées ou tous les flux de travail audio sont prêts pour la production sur chaque appareil.

Pour un serveur domestique, la première mesure la plus utile consiste à épingler la version, exécuter un modèle GGUF connu, relever la mémoire maximale et la latence, puis garder l’API privée. Testez ensuite seulement la vision ou l’audio. Un nouveau point de terminaison serveur ne remplace ni un modèle vocal compatible, ni une interface multimédia, ni une chaîne de traitement pour microphone, ni le contrôle d’accès, ni une capacité GPU/CPU suffisante.

Quelles sont les nouveautés de llama.cpp 0.8.0 ?

Les notes de la version officielle v0.8.0 regroupent les modifications en plusieurs catégories : compatibilité des modèles, multimodalité, mises à jour de l’API et du serveur, gestion de la mémoire centrale et optimisations du backend. Pour comprendre au mieux cette version, il faut distinguer les fonctionnalités immédiatement accessibles aux utilisateurs locaux des fonctionnalités avancées qui nécessitent du matériel spécifique ou du nouveau code d’intégration.

L’explication de la mise à jour DeepSeek V4.1 Flash aide à distinguer une mise à jour de modèle de la capacité d’un environnement d’exécution à charger un modèle. Une note de version indiquant « pris en charge » ne garantit ni une quantification particulière, ni une configuration GPU spécifique, ni une expérience utilisateur en temps réel.

Comment fonctionnent la voix en temps réel et la synthèse vocale dans cette version ?

Auparavant, de nombreux assistants vocaux hébergés à domicile associaient plusieurs composants distincts : capture du microphone, reconnaissance vocale, requête à un LLM et synthèse vocale. La version 0.8.0 introduit une voie expérimentale de flux audio entrant dans l’interface multimodale (mtmd) et expose un point de terminaison de serveur en temps réel utilisant un protocole temps réel de type OpenAI. Le serveur dispose également d’un point de terminaison distinct POST /tts pour les modèles compatibles.

Il s’agit de fonctionnalités distinctes. /v1/realtime est le point d’entrée des workflows de conversation ou de transcription avec flux audio ; /tts génère de la parole à partir de texte au moyen d’un modèle vocal compatible. Aucun des deux ne crée à lui seul un assistant toujours à l’écoute, et aucun ne garantit une langue particulière, une latence aller-retour, un format audio de sortie ou une intégration à une plateforme sans tester le checkpoint réel.

Pour un test audio pratique, vérifiez les autorisations du microphone, la fréquence d’échantillonnage, la conversion du codec, le comportement en cas de trame partielle, la détection de fin de tour, l’annulation et la gestion des délais d’attente réseau. Conservez les enregistrements audio et les transcriptions conformément à une politique de conservation explicite. Si l’application utilisée par l’utilisateur se trouve sur une autre machine, le fait que l’inférence s’exécute sur un NAS ne signifie pas que l’audio ne transite jamais par un réseau.

Pourquoi les changements concernant la mémoire et le MoE sont-ils importants ?

La version v0.8.0 introduit un cache SLRU segmenté 50/50 pour les poids des modèles à mélange d’experts stockés dans la mémoire de l’hôte. L’objectif est de mieux gérer les experts présentant différents profils de réutilisation ; les avantages réels varient selon le routage des experts, la distribution des prompts et la présence en mémoire. Pour les petits modèles denses classiques, ce changement peut avoir peu ou pas d’effet.

Le traitement par attention éparse est également remanié, et la version inclut une gestion plus propre de no_alloc, de nouvelles opérations ggml et des optimisations du backend. Ces changements peuvent influer sur l’allocation mémoire ou le débit, mais ne suppriment pas les contraintes fondamentales du calcul pour servir un modèle : empreinte des poids + tampons d’exécution + état KV/contexte + tenseurs multimodaux + traitements simultanés + marge de fonctionnement.

Un modèle de classe 2B quantifié sur 4 bits peut tenir facilement là où un checkpoint plus volumineux ne tient pas. Malgré cela, traiter des prompts plus longs et servir plusieurs clients peut surcharger un petit NAS. Notre guide de routage selon l’empreinte mémoire des modèles explique pourquoi la mémoire de pointe totale, et pas seulement la taille du téléchargement GGUF, doit être prise en compte dans le dimensionnement. L’analyse des limites de déploiement de Kimi K3 montre le cas extrême inverse : les fonctionnalités d’exécution ne peuvent pas faire tenir un checkpoint d’un billion de paramètres dans la mémoire d’un ordinateur grand public.

Quels nouveaux modèles pouvez-vous réellement essayer en local ?

Pour une expérimentation locale rapide avec des mesures, LFM3-1.7B GGUF est un meilleur point de départ qu’un grand checkpoint multimodal non testé. Sa fiche GGUF officielle indique une utilisation compatible avec llama.cpp. Passez à LFM3-VL-2B si vous avez besoin d’images ou de vidéos, et testez le projecteur et le prétraitement appropriés. L’audio et l’omni nécessitent leurs propres intégrations spécifiques au modèle.

Pour comparer plus en détail les tailles de modèles locaux et les niveaux de quantification, consultez notre guide des modèles d’IA pour matériel grand public. Si vous utilisez l’App Store de ZimaOS, les exigences matérielles d’Ollama offrent une autre option de déploiement ; le conditionnement d’Ollama et les fonctionnalités amont de llama.cpp ne sont pas des garanties interchangeables.

Comment installer et vérifier llama.cpp v0.8.0 sous Linux ?

Voici une procédure de vérification par compilation des sources, et non l’affirmation infondée que la version v0.8.0 est déjà disponible dans l’App Store de ZimaOS. Elle compile un serveur compatible avec le CPU, fixe le tag pour assurer la reproductibilité, utilise un modèle GGUF LFM3 documenté et se lie uniquement à l’interface de bouclage :

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout v0.8.0
cmake -S . -B build
cmake --build build --config Release -j --target llama-server
./build/bin/llama-server \
  -hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
  -c 4096 --host 127.0.0.1 --port 8080

Dans un deuxième terminal sur le même hôte, vérifiez que le serveur a bien chargé un modèle :

curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"local","messages":[{"role":"user","content":"Citez deux avantages d’un modèle GGUF local."}],"max_tokens":128}'

Si nécessaire, remplacez "local" par l’ID exact du modèle renvoyé par /v1/models. La version exige explicitement un argument de modèle (--model ou -hf) dans l’utilisation actuelle de l’interface en ligne de commande. Un ancien script de lancement dépourvu de l’un ou l’autre peut donc cesser de fonctionner. Consultez les instructions de compilation en amont pour connaître les options de backend prises en charge, notamment CUDA, Vulkan et Metal. N’exposez pas le port 8080 au public avant d’avoir configuré l’authentification, TLS, les limites et les frontières de confiance des clients.

Sur un serveur domestique basé sur des conteneurs, vous devez également prévoir un stockage persistant des modèles, des limites de ressources, des capacités CPU/GPU compatibles et un mappage des volumes vérifié. La meilleure référence pour la suite est déployer un LLM local sans perturber les applications NAS ; consultez-la avant de déplacer les téléchargements de modèles vers un disque de démarrage partagé.

Que faut-il tester avant de mettre à niveau un serveur IA existant ?

Une version amont riche en fonctionnalités peut modifier le comportement même si le serveur démarre sans problème. Conservez le binaire ou l’image de conteneur actuel, le hachage du modèle, les anciens indicateurs et au moins une réponse acceptée comme référence pour le retour arrière. Exécutez ensuite une petite matrice de régression :

1. Compatibilité : consignez le tag, le nom de fichier GGUF, la somme de contrôle, le backend et le modèle de conversation ; vérifiez les avertissements au démarrage.
2. Latence : exécutez les mêmes invites courtes et longues sur les deux versions et consignez le temps de préremplissage, la vitesse de décodage et la latence au 95e percentile, sans modifier le modèle ni le contexte.
3. Mémoire : consignez les pics d’utilisation de la RAM hôte et de la VRAM, le comportement de déchargement des modèles, les requêtes simultanées et la réactivité des autres applications NAS.
4. Audio : validez séparément le cycle de vie de la connexion en temps réel, les transcriptions, la sortie TTS, l’annulation et la reconnexion si ces fonctionnalités sont pertinentes.
5. Sécurité et récupération : vérifiez la liaison réseau, les autorisations des fichiers, les chemins persistants, le comportement au redémarrage et la possibilité de revenir au binaire précédent.

Utilisez notre liste de vérification pour vérifier le chemin d’accès aux fichiers de modèle et consultez les conseils pour séparer l’état d’exécution des poids. C’est particulièrement important lorsqu’un navigateur de modèles facilite les téléchargements : la facilité de téléchargement ne remplace pas le suivi de l’emplacement réel de plusieurs gigaoctets de données.

FAQ

llama.cpp v0.8.0 est-il la même chose que LFM3 ?

Non. llama.cpp est un moteur d’inférence. LFM3 est la famille de points de contrôle de modèles de Liquid AI. La version v0.8.0 ajoute la prise en charge de l’intégration de LFM3, mais les fichiers de modèle doivent toujours être choisis et obtenus séparément.

La version v0.8.0 me permet-elle de parler en temps réel avec n’importe quel modèle GGUF ?

Non. Les nouveaux chemins audio sont expérimentaux et dépendent du modèle. Un modèle uniquement textuel ne devient pas capable de traiter ou de produire de la parole simplement parce que le serveur expose /v1/realtime ou /tts.

/v1/realtime est-elle une API vocale prête pour la production ?

Considérez cette version comme expérimentale à sa sortie. Testez le modèle choisi, l’encodage audio, la compatibilité client, le comportement en cas d’interruption et la stabilité lors des sessions prévues avant de l’utiliser pour un service sans supervision.

Une mise à niveau réduira-t-elle la VRAM utilisée par tous mes modèles ?

Pas nécessairement. Certaines modifications de la mémoire et du backend peuvent améliorer des charges de travail spécifiques, mais les besoins en VRAM et en RAM dépendent des poids, du contexte, de la quantification, du backend matériel et du nombre de requêtes. Évaluez votre configuration exacte plutôt que de tirer des conclusions à partir des notes de version.

Ai-je besoin d’un GPU NVIDIA pour exécuter llama.cpp ?

Non. Il prend en charge l’inférence sur CPU et plusieurs moteurs GPU. Les performances sur CPU seul peuvent être suffisantes pour les petits modèles, mais seront bien plus lentes qu’avec une accélération matérielle bien adaptée. Vérifiez d’abord la RAM disponible et la taille du modèle, puis choisissez un moteur.

Puis-je installer directement v0.8.0 depuis l’App Store ZimaOS ?

Cet article ne vérifie pas la version du paquet de l’App Store ZimaOS et ne propose pas d’installation officielle en un clic. Le guide décrit une compilation à partir des sources en amont pour Linux, avec version épinglée, et propose des vérifications que vous pouvez adapter à votre matériel ou à votre environnement de conteneurs.

Mon ancienne commande llama-server continuera-t-elle de fonctionner sans modification ?

Vérifiez vos options et vos modèles. Les notes de v0.8.0 indiquent que les commandes CLI actuelles nécessitent --model ou -hf. Épinglez la version, examinez les journaux de démarrage, testez les réponses de l’API et conservez des fichiers de restauration avant de modifier un service fonctionnel.

En résumé

llama.cpp v0.8.0 est surtout utile pour une compatibilité élargie avec les modèles et un serveur local plus performant ; la voix en temps réel est l’aspect prometteur, mais encore expérimental. Un petit modèle LFM3 au format GGUF sur une API privée en boucle locale constitue un bon premier test. Notez l’utilisation réelle de la mémoire et la qualité des résultats avant d’ajouter des entrées d’image, des flux audio ou plusieurs utilisateurs simultanés.

Pour les propriétaires de NAS, l’architecture gagnante reste rigoureuse : stockage du modèle sur un volume connu, moteur d’inférence dimensionné selon la RAM/VRAM réellement disponible et applications protégées utilisant son API. Le ZimaCube 2 peut servir de plateforme privée de stockage et d’applications ; ne le présentez pas comme un nœud d’inférence multimodale à haut débit garanti sans configuration matérielle et logicielle mesurée. Si vous évaluez cette nouvelle famille de modèles prise en charge, consultez notre guide sur le modèle LFM3 local et le matériel nécessaire en complément des notes de version réelles du moteur.

Sources et périmètre

Documentation officielle consultée le 29 octobre 2026 : notes de llama.cpp v0.8.0, guide de compilation en amont, GGUF officiel de LFM3-1.7B, GGUF officiel de LFM3-VL et explication du lancement par Liquid AI. La prise en charge des fonctionnalités est tirée des notes de version en amont ; ZimaSpace n’a pas testé cette version de manière indépendante ni certifié sa compatibilité avec une version particulière de ZimaOS.

Image de couverture : ggml-org/llama.cpp, fiche officielle de la version v0.8.0 sur GitHub.