mirror of
https://github.com/Alkatrazz24/Funk-lab.git
synced 2026-07-11 00:24:42 +02:00
Analysés : litellm.md, llama_server.md, rag.md, rocm.md, incidents.md À améliorer : 0/5 Co-Authored-By: Hermes <hermes@funk.lab>
114 lines
5.6 KiB
Markdown
114 lines
5.6 KiB
Markdown
# Rapport Hermes — 2026-06-07_22-30
|
|
> Branche : `hermes/daily-work` · Fichiers analysés : 5
|
|
|
|
---
|
|
## Résumé
|
|
- ✅ À jour : 5
|
|
- ⚠️ À améliorer : 0
|
|
|
|
## ✅ `admin/ia/litellm.md` — 8/10
|
|
|
|
**Statut** : à_jour
|
|
**Résumé** : Documentation complète sur la configuration et l'utilisation de LiteLLM comme proxy LLM, avec des détails techniques et des exemples de commandes, mais présentant un gap IaC sur les modèles CPU
|
|
|
|
**Problèmes :**
|
|
- Les modèles CPU (qwen3-1.7b-system et qwen3-1.7b-monitor) ne sont pas inclus dans le template Ansible, nécessitant une configuration manuelle
|
|
- Le coût des modèles Claude n'est pas quantifié de manière explicite dans le tableau
|
|
- Le script hermes-switch modifie directement /etc/litellm/config.yaml sans validation des changements
|
|
|
|
**Suggestions :**
|
|
- Mettre à jour le template Ansible pour inclure tous les modèles disponibles
|
|
- Ajouter une section sur la gestion des clés API et la sécurité des secrets
|
|
- Préciser les limites des modèles locaux (ex: débit, mémoire vive)
|
|
- Ajouter des exemples de monitoring et de débogage avancés
|
|
|
|
**État réel connu de Hermes :**
|
|
Le système fonctionne correctement avec des modèles locaux et cloud, mais dépend de configurations manuelles pour les modèles CPU qui devraient être gérés par IaC
|
|
|
|
---
|
|
|
|
## ✅ `admin/ia/llama_server.md` — 8/10
|
|
|
|
**Statut** : à_jour
|
|
**Résumé** : Documentation complète sur la configuration et les performances de llama-server sur gpu-01, avec tests et métriques opérationnelles
|
|
|
|
**Problèmes :**
|
|
- Manque la mention du paramètre HSA_OVERRIDE_GFX_VERSION=10.3.0 crucial pour ROCm
|
|
- La section embeddings pourrait expliquer pourquoi le pooling 'mean' est obligatoire
|
|
- Le tableau de performances manque les métriques de latence
|
|
- Aucune mention des procédures de sauvegarde ou de basculement
|
|
- Absence de section dédiée aux résolutions de problèmes courants
|
|
|
|
**Suggestions :**
|
|
- Ajouter les paramètres environnementnels critiques pour ROCm
|
|
- Préciser la nécessité du pooling pour la compatibilité OpenAI
|
|
- Inclure des métriques de latence supplémentaires
|
|
- Documenter les protocoles de backup et de basculement
|
|
- Ajouter une section 'Dépannage' avec les erreurs fréquentes
|
|
|
|
**État réel connu de Hermes :**
|
|
Le composant est opérationnel avec des performances conformes aux spécifications, mais manque quelques détails critiques pour une documentation exhaustive
|
|
|
|
---
|
|
|
|
## ✅ `admin/ia/rag.md` — 7/10
|
|
|
|
**Statut** : à_jour
|
|
**Résumé** : Documentation complète sur l'implémentation RAG de Funk, avec architecture, composants, limitations et procédures de mise à jour, mais avec des recommandations d'amélioration pour les embeddings.
|
|
|
|
**Problèmes :**
|
|
- Utilisation du modèle Qwen3-8B (génératif) pour les embeddings, qui présente une faible discrimination sémantique
|
|
- Scores de similarité uniformément élevés (0.90-0.95) indiquant une pertinence réduite des résultats
|
|
- Manque de mention des alternatives embarquées pour les embeddings (nomic-embed-text-v1.5, bge-m3)
|
|
|
|
**Suggestions :**
|
|
- Ajouter des instructions pour déployer des modèles d'embedding dédiés (nomic-embed-text-v1.5, bge-m3)
|
|
- Mettre en avant les avantages des modèles multilingues comme bge-m3 pour le repo français
|
|
- Préciser les temps d'ingestion (5-10 min) et les prérequis pour la re-génération de l'index
|
|
|
|
**État réel connu de Hermes :**
|
|
Le système RAG est opérationnel mais présente des limitations connues dans la qualité des embeddings. L'index est mis à jour via Ansible avec un processus automatisé, mais les améliorations proposées restent à implémenter.
|
|
|
|
---
|
|
|
|
## ✅ `admin/ia/rocm.md` — 9/10
|
|
|
|
**Statut** : à_jour
|
|
**Résumé** : Le document ROCm est à jour et couvre correctement la configuration du GPU RX 6700XT avec ROCm, bien que quelques améliorations soient possibles.
|
|
|
|
**Problèmes :**
|
|
- La commande 'rocminfo | grep 'ROCk'' pourrait être obsolète (nouvelle syntaxe 'rocminfo --version')
|
|
- Le statut de 'rocm-smi' n'est pas mentionné dans la documentation malgré son absence sur gpu-01
|
|
- Les chemins '/sys/class/drm/card*/device/' pour les températures et VRAM peuvent être dépréciés selon les versions kernel
|
|
|
|
**Suggestions :**
|
|
- Ajouter une note sur l'absence de 'rocm-smi' sur gpu-01 et son impact
|
|
- Mettre à jour la commande de vérification de version ROCm vers 'rocminfo --version'
|
|
- Ajouter des exemples concrets de sortie pour les commandes clés (ex: exemple de 'rocminfo')
|
|
- Préciser les versions ROCm testées et leurs compatibilités avec gfx1031
|
|
|
|
**État réel connu de Hermes :**
|
|
ROCm fonctionne correctement sur gpu-01 avec HSA_OVERRIDE_GFX_VERSION=10.3.0, aucun crash de pod détecté, configuration conforme
|
|
|
|
---
|
|
|
|
## ✅ `admin/incidents.md` — 9/10
|
|
|
|
**Statut** : à_jour
|
|
**Résumé** : Document complet et bien structuré avec quelques ajustements nécessaires
|
|
|
|
**Problèmes :**
|
|
- La dernière ligne du tableau d'état post-migration est incomplète ('Espace disponibl' cut-off)
|
|
- Incohérence dans l'alignement des en-têtes du tableau d'index
|
|
- Absence de mention des impacts sur la disponibilité de l'espace disque post-migration
|
|
|
|
**Suggestions :**
|
|
- Compléter la ligne 'Espace disponibl' avec les métriques réelles post-migration
|
|
- Vérifier la cohérence des en-têtes de tableaux (dates, composants, résumés)
|
|
- Ajouter une section 'Impact' pour chaque incident avec des données quantitatives
|
|
|
|
**État réel connu de Hermes :**
|
|
Le composant /srv/data a été migré vers un LV NVMe XFS avec succès. Les mesures de performance montrent une amélioration significative (205 MB/s vs 50 MB/s avant). La corruption des données a été résolue via la réparation manuelle des segments Qdrant.
|
|
|
|
---
|
|
|