Choisir ses modèles
Le modèle de langage détermine la qualité, la vitesse et le coût des réponses, ainsi que la question de savoir si des données sortent de votre périmètre. WivenLLM ne vous en impose aucun.
Trois familles
1. Modèles locaux intégrés
WivenLLM télécharge et exécute lui-même des modèles ouverts, sans dépendance externe. Un catalogue intégré propose des modèles de tailles variées, du modèle léger de quelques milliards de paramètres aux modèles nettement plus lourds.
- Aucune donnée ne sort, aucune clé d'API, aucun coût à l'usage.
- La vitesse dépend entièrement de votre matériel.
- Le modèle est chargé en mémoire à la première utilisation et déchargé automatiquement après une période d'inactivité, pour libérer les ressources.
Le diagnostic matériel (Réglages → Diagnostic matériel) analyse votre
machine, exécute une mesure courte et indique pour chaque modèle du catalogue
s'il est confortable, limite ou hors de portée. C'est le moyen le
plus rapide de savoir quoi télécharger.
2. Serveur d'inférence interne
Votre organisation exploite déjà un serveur de modèles ? WivenLLM s'y connecte comme client. Le principe reste le même — rien ne sort du réseau — mais c'est votre serveur qui gère le cycle de vie des modèles, pas WivenLLM.
Tout serveur exposant une API compatible avec le standard OpenAI convient, y compris les solutions locales les plus répandues.
3. Fournisseurs externes
Les grands fournisseurs commerciaux sont pris en charge. Ils offrent généralement la meilleure qualité et la meilleure vitesse, sans exigence matérielle.
En contrepartie : vos messages et le contexte documentaire associé sont transmis au fournisseur, et l'usage est facturé. Ce choix doit être conscient et documenté auprès des utilisateurs.
Quel matériel pour un modèle local
Ces ordres de grandeur concernent les modèles quantifiés du catalogue intégré.
| Taille de modèle | Mémoire vive utile | Sans GPU | Avec GPU adapté |
|---|---|---|---|
| 3 milliards de paramètres | 8 Go | Utilisable | Très rapide |
| 7–9 milliards | 16 Go | Lent mais praticable | Rapide |
| 14 milliards | 24 Go | Difficile | Confortable |
| 32 milliards | 32 Go et plus | Non recommandé | Confortable avec un GPU dimensionné |
| 70 milliards | 48 Go et plus | Non | Nécessite un GPU haut de gamme |
Deux points souvent sous-estimés :
- La mémoire est la contrainte dure. Un modèle qui n'entre pas en mémoire ne démarre pas, ou s'exécute par échanges disque à une vitesse inutilisable.
- Le GPU change l'échelle, pas le résultat. Il multiplie la vitesse de génération ; il ne rend pas un petit modèle plus intelligent.
Le modèle d'agent peut être différent
Un espace de travail distingue deux modèles :
- le modèle de conversation, qui répond aux questions ;
- le modèle d'agent, qui pilote les enchaînements d'outils.
Les agents exigent davantage : le modèle doit décider quel outil appeler, avec quels arguments, et interpréter le résultat. Un modèle qui converse correctement peut échouer en agent.
Recommandation : si les agents comptent pour vous, affectez-leur le modèle le plus capable dont vous disposez, même si la conversation courante tourne sur un modèle plus léger.
→ Agents
Le moteur d'embeddings est un choix à part
Il ne rédige rien : il traduit le texte en vecteurs pour la recherche documentaire. Le moteur intégré s'exécute localement et convient à la majorité des usages.
Contrainte structurante : tous les vecteurs d'un index doivent provenir du même moteur. En changer rend les index existants inutilisables et impose une réindexation complète de tous les espaces. Décidez-le au démarrage.
Un moteur externe peut se justifier pour des corpus multilingues exigeants ou des besoins de qualité de recherche très élevés — au prix d'une sortie réseau à chaque indexation et à chaque question.
Arbitrer
| Votre priorité | Configuration |
|---|---|
| Confidentialité stricte | Modèle local intégré + embeddings natifs + base vectorielle locale |
| Qualité maximale | Fournisseur externe, mentionné explicitement aux utilisateurs |
| Coût nul à l'usage | Tout local |
| Vitesse sur matériel modeste | Fournisseur externe, ou serveur d'inférence interne mutualisé |
| Les deux selon les cas | Routeur de modèles : local par défaut, escalade sur règles |
Changer d'avis plus tard
- Changer de modèle de langage : sans conséquence. Les documents restent indexés, les conversations restent lisibles.
- Changer de moteur d'embeddings : impose une réindexation complète.
- Changer de base vectorielle : impose une réindexation complète.
Autrement dit, seul le premier de ces trois choix est réellement réversible sans effort. C'est pourquoi les deux autres méritent une décision réfléchie à l'installation.