Questions Logicielles¶

Dans cet article

Mon noyau et mes pilotes ne se mettent pas à jour/ s'installent pas sur Ubuntu

J'ai une erreur avec Docker Compose

Les modèles de réseaux neuronaux multilingues comme DeepSeek R1 répondent en chinois au lieu du langage que vous utilisez

Le modèle neuronal dans OpenWebUI ou Ollama met beaucoup de temps à répondre

Mon noyau et mes pilotes ne se mettent pas à jour/ s'installent pas sur Ubuntu¶

Le problème où un nouveau noyau ou des pilotes (modules de noyau) ne s'installent pas peut survenir lorsque la partition /boot est pleine lors de mises à jour simultanées du système de noyau, empêchant ainsi la création de nouveaux disques initiaux en mémoire vive (initrd). Pour vérifier cela, exécutez la commande :

sudo apt --fix-broken install

Si vous voyez des erreurs dans la sortie, vérifiez le niveau d'occupation de la partition /boot. À cette fin, consultez la sortie de la commande df -h /boot

/dev/sda2       739M  287M  398M  42% /boot

Pour des reconstructions réussies des initrd, le nombre avant le pourcentage d'occupation de la partition /boot devrait être supérieur à 200M. Si il n'y a pas d'espace libre, procédez aux étapes suivantes :

Créez une sauvegarde de la partition afin de pouvoir rapidement restaurer les fichiers si vous en supprimez accidentellement des nécessaires :
```
sudo rsync -av /boot/ /boot.old/
```

Consultez le contenu de la partition /boot et trouvez tous les images initrd :

ls /boot | grep 'initrd.img-'

Vous devriez obtenir une sortie similaire à celle-ci :

initrd.img
initrd.img-6.8.0-57-generic
initrd.img-6.8.0-58-generic
initrd.img-6.8.0-59-generic
initrd.img-6.8.0-60-generic
initrd.img-initrd.img
initrd.img-initrd.img.old
initrd.img.old

Supprimez les images initrd supplémentaires, EN LAISSANT LES DEUX DERNIÈRES. Dans notre cas, nous devons supprimer initrd.img-6.8.0-57-generic et initrd.img-6.8.0-58-generic.

Attention

Les commandes suivantes peuvent entraîner un dysfonctionnement de votre système d'exploitation, alors faites attention aux versions des fichiers supprimés. Il doit y avoir des fichiers pour les dernières et deuxièmes-dernières versions du noyau dans la partition /boot ! Vous pouvez vérifier quelle version du noyau vous utilisez actuellement avec la commande uname -a. Si quelque chose ne va pas, vous pouvez restaurer le contenu de la partition /boot à partir de la sauvegarde effectuée à l'étape un avec la commande sudo rsync -av /boot.old/ /boot/.

Faites ceci avec la commande :
```
rm -f /boot/initrd.img-6.8.0-57-generic
```
Répétez cela pour chaque fichier.

Faites de même avec les fichiers vmlinuz et System.map (optionnel) :
```
rm -f /boot/vmlinuz-6.8.0-57-generic 
rm -f /boot/System.map-6.8.0-57-generic
```
Nettoyez le système des paquets liés aux anciens noyaux et exécutez les installations postérieures ainsi que la construction de pilotes et modules de noyau avec les commandes :
```
sudo apt autoremove
sudo apt --fix-broken install
```
Redémarrez le système d'exploitation :
```
reboot
```

J'ai une erreur avec Docker Compose¶

Si vous recevez une erreur comme docker: 'compose' is not a docker command ou docker-compose: command not found lors de l'exécution de docker compose, cela peut signifier que la version de votre système d'exploitation est ancienne où Docker Compose n'a pas été installé en tant que plugin ou ajouté à PATH. Pour résoudre ce problème, suivez ces étapes :

Installez Docker Compose (si non installé) :

mkdir -p ~/.docker/cli-plugins/
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose
chmod +x ~/.docker/cli-plugins/docker-compose

Remplacez latest par la version actuelle du dépôt officiel si nécessaire.

Vérifiez l'installation :
```
docker-compose --version
```
Si la commande s'exécute correctement, Docker Compose est installé.
Si la commande n'est toujours pas trouvée, assurez-vous que ~/.docker/cli-plugins/ est ajouté à la variable d'environnement PATH. Ajoutez ceci dans ~/.bashrc ou ~/.zshrc :
```
export PATH=$PATH:~/.docker/cli-plugins/
```
Ensuite, exécutez :
```
source ~/.bashrc  # or source ~/.zshrc
```
Vérifiez à nouveau l'installation :
```
docker-compose --version
```

Les modèles de réseaux neuronaux multilingues comme DeepSeek R1 répondent en chinois au lieu du langage que vous utilisez¶

La plupart des modèles multilingues, tels que DeepSeek, peuvent parfois basculer sur la langue d'entraînement principale (chinois ou anglais) même si la requête a été effectuée en français. Cela se produit en raison de la distillation des modèles, de leur compression ou de la prédominance des réponses dans une seule langue principale.

Pour minimiser ce comportement, il est recommandé d'indiquer explicitement la langue du message en ajoutant "Répondez en français" à la fin de l'invite de requête et en intégrant cette ligne dans l'invite système. Il est également conseillé d'utiliser des modèles comme Qwen3 ou Gemma3, qui démontrent une plus grande stabilité dans les versions avec moins de paramètres par rapport à DeepSeek.

De plus, vous pouvez vérifier manuellement les réponses en français à l'aide d'outils tels qu'OpenWebUI ou sur le back-end de votre chat si vous travaillez via une API.

Le modèle neuronal dans OpenWebUI ou Ollama met beaucoup de temps à répondre¶

Si le modèle met beaucoup de temps à répondre, cela peut être dû à sa taille et à la capacité de votre serveur.

Tout d'abord, assurez-vous que votre modèle s'intègre entièrement dans la mémoire vidéo du GPU. Par exemple, le modèle llama4:16x17b est de 67 Go lorsqu'il est compressé (q4) et nécessite 80–90 Go de mémoire vidéo lorsqu'il est entièrement décompressé. Si votre GPU est une NVIDIA A5000 ou RTX 4090 avec 24 Go de mémoire vidéo, ollama va évincer certaines couches du modèle vers le CPU du serveur, provoquant un engorgement de la machine virtuelle, une réduction des allocations de cœurs et des retards importants dans les réponses.

Pour travailler avec un tel modèle, des GPU plus puissants sont nécessaires, tels qu'une Nvidia H100 avec 80 Go de mémoire vidéo ou une combinaison de quatre RTX 4090. La RAM est importante uniquement pour les tâches RAG (travail avec base de connaissances et fichiers chargés) et nécessite généralement au moins 32 Go.

Pour vérifier la charge de votre GPU, connectez-vous à votre serveur via SSH et exécutez ollama ps dans la ligne de commande :

[ root ]$ ollama ps 
NAME                                  ID              SIZE      PROCESSOR    UNTIL
yxchia/multilingual-e5-base:latest    f5248cae7e12    1.1 GB    100% GPU     il y a 14 minutes
qwen3:14b                             bdbd181c33f2    14 GB     100% GPU     il y a 14 minutes

La sortie montrera combien d'espace occupe votre modèle et s'il rentre entièrement dans le GPU.

Note

Pour les cartes vidéo avec 24 Go de mémoire, les modèles plus grands que 14B ou compressés au-delà de q8 ne sont pas recommandés. Plus la taille du modèle en termes de paramètres (volume) et de fenêtre de contexte est grande, plus le processus de réponse sera long.

Information

Performances de calcul pour les modèles de 14B sur Nvidia A5000:

Démarrage à froid prend environ 30-40 secondes avant une réponse.
Temps de réponse est de 10–15 secondes (sans raisonnement).
Temps de réponse est de 20-30 secondes (avec raisonnement).

Si RAG (Retrieval-Augmented Generation) ou MCP est utilisé, le temps de réponse augmente de 5 à 10 secondes (temps de recherche dans la base de données et de requête d'outil).

La vitesse de génération des jetons est d'environ 40–45 jetons par seconde. Vous pouvez vérifier cette valeur en cliquant sur l'icône en bas de la ligne de réponse du chat OpenWebUI et en regardant le paramètre response_token/s.

Une partie du contenu de cette page a été créé ou traduit en utilisant l'IA.