Quels modèles IA locaux utiliser avec Stellary ?

Un modèle IA local peut préparer des cartes, résumer des documents ou contribuer à une mission de code. Son intérêt dépend de la machine, du moteur d’exécution, des outils disponibles et de la qualité du résultat obtenu sur votre travail.

Choisissez une configuration complète, puis testez une mission représentative. Un nom de modèle, un nombre de paramètres et un benchmark ne suffisent pas à établir qu’un agent fonctionnera dans Stellary.

Modèle local et application locale

Un modèle local produit ses réponses sur une machine ou un serveur que vous maîtrisez. Une application installée sur votre ordinateur peut, elle, appeler une API distante. Les deux notions doivent rester distinctes dans votre configuration.

Stellary Desktop peut connecter des moteurs présents sur un ordinateur et rendre leurs capacités disponibles aux agents selon la configuration. Le workspace, les documents partagés et l’historique de collaboration peuvent toujours dépendre de services en ligne. L’inférence locale ne constitue donc pas une promesse de fonctionnement entièrement hors ligne.

Le guide local, cloud et hybride aide à choisir le lieu de traitement. Cet article porte sur la sélection d’un modèle et la vérification de son usage dans une mission.

Des candidats à comparer

Les candidats ci-dessous couvrent des tailles et des spécialités différentes. Ils ne forment pas une liste de configurations Stellary déjà validées. La version du moteur, la quantification et le contrat d’outils doivent être vérifiés pendant l’essai.

Les grands modèles à poids ouverts comme Mistral Large 4 concernent aussi l’hébergement maîtrisé. Leur disponibilité ne signifie pas qu’ils conviennent à un ordinateur ordinaire. Le matériel et l’exploitation restent des choix de déploiement.

Commencer par une mission utile

Retenez un travail que vous pouvez relire. Un classement de demandes peut être vérifié sur une série d’exemples. Une extraction peut être comparée aux documents sources. Une correction de code doit passer un parcours et des contrôles adaptés.

Préparez au moins une entrée facile et une entrée qui révèle une difficulté réelle : document incomplet, information contradictoire, texte long ou outil indisponible. Une configuration utile doit savoir produire un résultat correct ou expliquer ce qui empêche de le terminer.

Pour une première utilisation dans Stellary, vous pouvez proposer la rédaction d’un rapport d’avancement depuis un ensemble de cartes, sans modification ni envoi. Le contrôle porte sur les faits et leurs sources. Un essai de code exige un environnement et un périmètre différents.

Vérifier la machine et la quantification

La mémoire disponible doit accueillir les poids, le contexte, le moteur et le reste du travail. La longueur de contexte et les exécutions simultanées changent le besoin. Une taille de fichier téléchargé ne suffit pas à calculer toute la mémoire nécessaire.

La quantification réduit la taille des poids avec un compromis à évaluer sur le résultat. Deux fichiers associés au même nom peuvent produire des comportements et des temps différents. Notez la variante exacte au lieu de publier une recommandation portant seulement sur la famille.

Sur une machine partagée avec d’autres applications, observez également la réactivité du poste. Une inférence qui ralentit le reste du travail peut annuler le gain de l’agent. Mesurez l’usage représentatif avant de décider d’un équipement dédié.

Distinguer réponse textuelle et agent outillé

Un serveur qui répond à une requête de chat ne prouve pas qu’il peut appliquer les permissions d’une mission et utiliser ses outils. Le moteur peut prendre en charge certaines opérations et en refuser d’autres.

Dans Stellary, les chemins LM Studio, Ollama et les autres runners ont leurs propres capacités. Une mission outillée exige le contrat compatible avec le moteur et le modèle sélectionnés. N’interprétez pas un refus de configuration comme une invitation à supprimer les contrôles.

Le guide des apps IA locales décrit le parcours de connexion. Vérifiez d’abord la configuration simple, puis la mission avec les outils nécessaires. Les permissions des agents restent une partie du résultat à contrôler.

Le parcours à démontrer dans Stellary

1. Le moteur local est accessible sur la machine connectée et le modèle est identifié.
2. Le modèle est partagé selon le parcours Desktop prévu.
3. Il apparaît dans le catalogue du workspace et peut être sélectionné pour l’agent.
4. La mission utilise réellement cette configuration, avec les accès autorisés.
5. Le résultat revient dans Stellary et peut être relu depuis la carte.

Une découverte réussie dans Desktop ne prouve pas à elle seule les étapes suivantes. Si le modèle est absent de la configuration d’agent, contrôlez le partage et le catalogue avant de conclure que l’installation locale est terminée.

Conservez le nom exact du modèle utilisé dans l’essai. Une sélection peut pointer vers un modèle différent après un changement de serveur ou de configuration. Vérifiez l’identité dans les traces disponibles et le résultat de la mission.

Comparer les résultats à conditions constantes

Donnez les mêmes entrées et critères à chaque configuration. Relevez le temps jusqu’à un résultat accepté, les erreurs, les reprises et l’effort humain. La vitesse de génération seule ne dit pas si le travail est utile.

Le coût local comprend l’équipement, son usage et l’entretien. Il peut être intéressant pour des tâches régulières, mais il ne devient pas nul parce qu’aucune facture API n’apparaît à chaque réponse.

Construire un workflow hybride lorsque c’est utile

Vous pouvez envisager un modèle local pour une étape documentaire et un autre moteur pour une investigation difficile. Le passage de données entre étapes doit rester explicite : quelles informations quittent la machine et vers quel service ?

Cette répartition dépend des capacités vérifiées de chaque configuration. Elle ne doit pas être présentée comme un routage universel automatique. Le guide des workflows supervisés explique comment préciser les entrées et sorties des rôles.

Prévoyez une sortie lisible lorsqu’un moteur est indisponible. Passer silencieusement d’un modèle local à un service distant changerait une condition essentielle du choix. L’utilisateur doit comprendre ce qui peut être relancé et avec quelle configuration.

Retenir une configuration que l’équipe peut maintenir

Documentez l’installation utilisée, les mises à jour et la personne qui peut intervenir. Conservez quelques tâches de référence pour contrôler le comportement après un changement de modèle ou de moteur.

Une bonne configuration locale a une utilité démontrable : elle termine certaines missions à un niveau de qualité acceptable, sur une machine adaptée et avec un fonctionnement compréhensible. C’est cette utilité qu’il faut comparer à l’option cloud, plutôt qu’une promesse générale de remplacer tous les modèles distants.

Garder une petite référence de qualité

Conservez les entrées de quelques missions acceptées et les critères qui ont permis leur revue. Après une mise à jour, rejouez ces tâches sans changer simultanément le modèle et les sources. Vous pourrez distinguer une variation du moteur d’un changement dans le contenu du projet.

Incluez une tâche qui doit rester bloquée lorsqu’une information manque. Un modèle qui invente une réponse pour terminer vite peut sembler performant sur les cas ordinaires tout en créant beaucoup de corrections sur les cas réels. La capacité à s’arrêter avec une question précise fait partie du résultat.

Pour une utilisation d’équipe, vérifiez aussi ce qui arrive lorsque la machine s’éteint ou que le modèle est déchargé. La file de travail et le message utilisateur doivent permettre de comprendre l’attente. Une installation sur un poste individuel a des contraintes de disponibilité différentes d’un service partagé.

Garder les observations d’un premier essai

Téléchargez la fiche d’évaluation locale ou cloud et renseignez la machine, la quantification, le moteur et le modèle exact. Les candidats cités dans cet article viennent des fiches des éditeurs ; ils ne constituent pas une liste de configurations toutes testées dans Stellary.

Pour un client externe, le guide LM Studio décrit un chemin MCP ; il est distinct du partage d’un modèle par Stellary Desktop. Vérifiez le chemin que votre mission utilise avant d’interpréter le résultat.