# Rapport Hermes — 2026-06-07_16-30 > Branche : `hermes/daily-work` · Fichiers analysés : 5 --- ## Résumé - ✅ À jour : 5 - ⚠️ À améliorer : 0 ## ✅ `admin/ia/litellm.md` — 7/10 **Statut** : à_jour **Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM, avec des lacunes dans la gestion des modèles CPU via Ansible **Problèmes :** - Le template Ansible manque les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) nécessaires à ask-agent - La colonne 'Coût' dans le tableau des modèles a un format incohérent (dash au lieu de chiffre) - La phrase 'Utilisation courante' manque de précision - Formatage des tableaux mal aligné - L'absence de gestion des erreurs dans la validation API **Suggestions :** - Mettre à jour le template Ansible pour inclure les modèles CPU - Corriger le formatage des tableaux et remplir les champs de coût - Ajouter des exemples de gestion d'erreurs dans la validation API - Préciser les instructions pour le déploiement des modèles CPU - Ajouter une section dédiée aux problèmes courants et solutions **État réel connu de Hermes :** Le service LiteLLM est opérationnel avec les modèles GPU, mais les modèles CPU ne sont pas déployés via Ansible. Le script hermes-switch permet le basculement manuel, mais cela représente un gap IaC. --- ## ✅ `admin/ia/llama_server.md` — 9/10 **Statut** : ok **Résumé** : Documentation complète sur la configuration et les performances de llama-server sur gpu-01, avec des commandes de gestion et des métriques détaillées. **Problèmes :** - La section des métriques Prometheus manque une explication sur la configuration requise du flag --metrics dans le service systemd - Le calcul VRAM mentionné (~9GB) ne tient pas compte des autres processus en cours sur la carte graphique **Suggestions :** - Ajouter une vérification de la configuration des métriques Prometheus dans la section 'Service systemd' - Mettre à jour la note sur l'utilisation VRAM avec des instructions pour mesurer la consommation réelle via nvidia-smi - Ajouter un avertissement sur le bug de parallélisme mentionné dans la section des performances **État réel connu de Hermes :** Le composant est correctement documenté, mais les métriques Prometheus nécessitent une configuration supplémentaire pour être activées. La gestion des ressources VRAM pourrait être améliorée avec des outils de surveillance. --- ## ✅ `admin/ia/rag.md` — 7/10 **Statut** : à_jour **Résumé** : Documentation complète sur le RAG de Funk, expliquant l'architecture, les composants et les limitations actuelles du système. **Problèmes :** - Utilisation d'un modèle génératif (Qwen3-8B) pour les embeddings, ce qui entraîne une perte de discrimination sémantique - Scores de similarité cosinus uniformément élevés (0.90-0.95) indiquant une faible pertinence réelle des résultats - Manque de détails sur l'état actuel de l'index et des performances réelles **Suggestions :** - Déployer un modèle d'embedding dédié comme nomic-embed-text-v1.5 ou bge-m3 pour améliorer la recherche sémantique - Mettre à jour les instructions d'indexation avec des exemples concrets de retraitement de documents - Ajouter des benchmarks de performance avant/après migration vers un modèle d'embedding dédié **État réel connu de Hermes :** Le système utilise actuellement Qwen3-8B pour les embeddings via llama-server (port 1234). L'index est mis à jour via Ansible ou manuellement, mais les résultats de recherche souffrent de perte de pertinence en raison des limitations du modèle. --- ## ✅ `admin/ia/rocm.md` — 8/10 **Statut** : à_jour **Résumé** : Documentation complète sur la configuration ROCm pour RX 6700XT avec vérifications opérationnelles et commandes de debug **Problèmes :** - Absence de mention des nouvelles versions ROCm disponibles (>=5.14.0-687.5.3.el9_8) - Aucune indication sur la configuration des profils CUDA/ROCm pour les conteneurs - Les commandes 'rocm-smi' ne sont pas disponibles sur gpu-01 (état documenté mais non expliqué) **Suggestions :** - Ajouter une section sur la vérification des pilotes ROCm avec 'rocminfo -v' - Inclure des exemples de configurations pour les applications GPU (llama-server, Qwen3) - Mettre en évidence les différences entre ROCm 5.14 et les versions antérieures - Ajouter des conseils sur la surveillance à long terme (Prometheus/Grafana intégration) **État réel connu de Hermes :** ROCm 5.14.0 installé, amdgpu module chargé, HSA_OVERRIDE_GFX_VERSION=10.3.0 actif, aucune erreur détectée dans les logs, configuration conforme aux spécifications RX 6700XT (gfx1031) --- ## ✅ `admin/incidents.md` — 8/10 **Statut** : à_jour **Résumé** : Document d'historique des incidents complet et structuré avec résolutions détaillées, mais manque d'informations sur l'état post-résolution des composants **Problèmes :** - La section 'État post-migration' est incomplète (manque l'état des autres composants) - Certains incidents (AlertManager, nftables) ont des résolutions incomplètes - Format des tables est incohérent entre l'index et les sections détaillées - Aucune mention des mesures préventives ou corrections à long terme **Suggestions :** - Ajouter un tableau récapitulatif des états post-résolution pour chaque incident - Compléter les résolutions avec des vérifications post-corrections (ex: tests, monitoring) - Standardiser le format des tables avec des colonnes identiques pour chaque incident - Inclure une section 'Prévention' pour chaque incident majeur **État réel connu de Hermes :** Le système utilise désormais NVMe pour /srv/data, les composants critiques sont restaurés, mais des supervisions continues sont nécessaires pour éviter les récidives ---