Une réponse rapide à une seule question courte montre qu’un modèle de langage local fonctionne dans son principe. Pour décider de l’infrastructure, un essai avec les futures tâches et leur charge réelle est bien plus instructif. Cela comprend la qualité des réponses, les délais, les entrées longues, l’usage simultané et le fonctionnement après un incident.
Un pilote est particulièrement utile lorsque la décision qu’il doit permettre est définie à l’avance. Par exemple : l’environnement existant suffit-il, faut-il un autre matériel ou un service externe ou hybride convient-il mieux ? Cette question guide le plan de test.
Commencer par un petit ensemble de tâches représentatives
Les tâches pertinentes viennent du processus prévu : une courte question métier, le résumé d’un document approuvé plus long ou un brouillon de script à vérifier. Pour chaque tâche, on définit ce qui rend un résultat exploitable.
Pour les questions de connaissances, prévoir les sources attendues et les cas sans fondement suffisant. Le code exige une revue technique et des tests adaptés. Les données originales confidentielles ne sont utilisées que dans l’environnement autorisé ; des données nettoyées ou créées pour les essais peuvent suffire à la préparation.
Évaluer séparément qualité et rapidité
Un modèle qui fournit rapidement des résultats faux n’atteint pas l’objectif. On évalue d’abord l’utilité métier, les corrections nécessaires et le traitement des informations manquantes. On peut ensuite comparer les délais et les efforts nécessaires pour obtenir cette qualité.
Consigner la version du modèle, la quantification, le logiciel d’inférence, les réglages et les données de test. Sinon, une réponse plus rapide peut provenir d’une tâche modifiée ou d’un autre niveau de qualité. Une collection documentaire changeante peut aussi modifier la comparaison d’une application RAG.
Décomposer le temps d’attente
- Délai jusqu’au premier token
- Il indique quand la sortie commence. La file d’attente et le traitement de l’entrée peuvent l’influencer. Mesurer aussi le délai perçu entre l’envoi dans l’application et l’apparition de la réponse.
- Génération de la réponse
- La vitesse de génération influe sur la durée d’une réponse longue. Un débit global élevé du serveur ne dit pas encore à quelle vitesse chaque utilisateur reçoit sa réponse.
- Durée totale
- Elle couvre toute l’opération applicative. Recherche, préparation documentaire, appels d’outils et trajets réseau peuvent s’y ajouter.
- Dispersion et erreurs
- Examiner ensemble les valeurs typiques et les cas limites plus lents. Le nombre de mesures, les dépassements de délai et les tâches interrompues font partie du résultat.
La documentation officielle des métriques vLLM (lien externe) distingue notamment les mesures d’attente, d’entrée et de sortie. Vérifier les métriques disponibles dans le moteur d’exécution et la version utilisés. Les mesures de composants différents doivent correspondre à la même période et à la même tâche.
Tester les échanges courts, les contextes longs et la simultanéité
Un contexte long exige davantage de calcul et de mémoire. Plusieurs requêtes simultanées se partagent les ressources disponibles. La documentation Ollama sur le contexte (lien externe) et la documentation d’optimisation de vLLM (lien externe) expliquent ces relations ; les réglages concrets dépendent de la version et du matériel.
Un test pertinent combine donc des entrées courtes et longues avec une simultanéité adaptée à l’usage prévu. Outre les requêtes régulières, examiner les pics attendus. Si le traitement par lots augmente le débit, vérifier malgré tout que les délais individuels conviennent aux utilisateurs.
Un exemple de plan de test
Exécuter d’abord les mêmes tâches métier individuellement. Tester ensuite ensemble les requêtes courtes et les tâches sur documents approuvés. Puis reproduire une période de pointe attendue et observer le comportement en surcharge. Les objectifs sont convenus au préalable avec les utilisateurs.
Ce plan est un exemple adaptable. Il ne contient aucun chiffre de performance DAXS mesuré et ne remplace pas l’évaluation de l’environnement concret.
Distinguer démarrage, fonctionnement courant et reprise
Après un redémarrage, le modèle doit éventuellement être chargé. Mesurer cette phase à froid séparément du fonctionnement avec le modèle déjà chargé. Des disques NVMe rapides peuvent aider au chargement et aux opérations sur les données ; cela n’implique pas une accélération générale de la génération des tokens d’un modèle entièrement en mémoire GPU.
Le pilote inclut aussi une connexion perdue, une tâche interrompue et le redémarrage d’un service. L’application devrait afficher clairement son état et offrir une procédure pertinente de nouvelle tentative ou de transfert. Une surcharge ne doit pas produire silencieusement des résultats incomplets.
Transformer les résultats en décision d’architecture
Comparer les résultats exploitables, l’effort de correction, la latence, la capacité et l’exploitation courante. Le coût total comprend aussi administration, maintenance, énergie, sauvegarde et disponibilité requise. Pour les services externes s’ajoutent les coûts d’usage concrets et les trajets de données convenus.
Le résultat peut être un modèle plus petit mais adapté, des ressources supplémentaires, une file d’attente limitée ou un autre mode d’exploitation. Les approches locales, externes et hybrides s’évaluent sur la même tâche. Un pilote doit permettre une prochaine décision solide, sans justifier après coup l’achat d’un matériel déjà considéré comme nécessaire.
DAXS prépare le test, met en place un environnement adapté et évalue les résultats avec votre équipe informatique. Notre page spécialisée sur les LLM locaux et l’infrastructureexplique les bases techniques. Pour les connaissances connectées, la qualité de la recherche, des sources et des autorisations fait partie du même cadre d’évaluation.
