Déploiements
Un déploiement est l'instance en cours d'exécution de ce que vous avez construit : un agent, un workflow ou une application, qui s'exécute et est accessible à ses utilisateurs. Studio propose trois manières de l'exécuter :
- Développement local : vous exécutez le worker sur votre propre machine, en interaction avec la plateforme. Pour itérer, pas pour la production.
- Auto-hébergés : vous exécutez les workers sur votre propre infrastructure (machines virtuelles, Kubernetes, votre cloud privé), et Mistral les orchestre.
- Gérés : Mistral exécute tout. Vous pointez Studio vers votre code, et Mistral Cloud le construit, l'exécute, le met à l'échelle et le rétablit en cas de défaillance. Rien à héberger.
Déployer un modèle est une décision distincte, traitée dans Inférence > Déploiement.
Ce qu'est un déploiement
Qu'il s'agisse d'agents, de workflows ou d'applications, un déploiement répond aux trois mêmes questions :
- Où s'exécute-t-il ? Sur votre machine (local), sur une infrastructure que vous exploitez (auto-hébergé), ou sur Mistral Cloud (géré).
- Comment y accède-t-on ? Via la plateforme : les exécutions, les déclencheurs et les webhooks sont routés vers le déploiement, et Studio l'observe.
- À qui s'adresse-t-il ? Les utilisateurs, les services et les planifications qui l'appellent.
Chaque déploiement porte un nom. C'est par ce nom que la plateforme achemine le travail vers la bonne instance en cours d'exécution, et que vous le retrouvez dans la console, l'API et vos traces.
Local, auto-hébergés, gérés
| Développement local | Auto-hébergés | Gérés | |
|---|---|---|---|
| Où le code s'exécute | Votre machine | Votre infrastructure | Mistral Cloud |
| Qui l'exploite | Vous | Vous | Mistral |
| Ce que la plateforme fournit | Orchestration : routage, durabilité, observabilité | Orchestration : routage, durabilité, mise à l'échelle de vos charges de travail | Construire, exécuter, mettre à l'échelle, rétablir |
| Authentification | La clé API de votre espace de travail | Clé API d'espace de travail ou compte de service | Un token de compte de service est injecté ; aucune clé API dans votre code |
| Idéal pour | Itérer sur un workflow ou un agent | Résidence des données, réseaux privés, compute existant, maîtrise des coûts | Livrer rapidement, sans rien à gérer |
Local et Auto-hébergés diffèrent par l'endroit où le code s'exécute, et non par sa manière de s'exécuter : le même code de worker et le même nom de déploiement fonctionnent dans les deux cas. Auto-hébergés et Géré diffèrent par la personne qui opère l'infrastructure.
Commencez en local pendant que vous construisez. Passez à Auto-hébergés quand vous avez besoin de contrôler l'endroit où le code s'exécute. Passez à Géré quand vous ne voulez rien opérer. Les concepts de déploiement, le routage et l'observabilité restent identiques.
L'auto-hébergement d'un déploiement n'est pas la même chose qu'exécuter l'ensemble de la plateforme Studio dans vos propres locaux. Consultez la documentation on-premises.
Ce qui ne change pas
Quel que soit votre mode d'exécution, le cycle de vie est le même :
- Construire ou démarrer : empaquetez votre code (géré), ou démarrez vos charges de travail (local et auto-hébergé).
- Déployer : le déploiement enregistre ce qu'il peut exécuter et devient actif.
- Exécuter : les exécutions, les déclencheurs et les webhooks sont routés vers lui.
- Mettre à jour : livrez une nouvelle version ; la plateforme la déploie progressivement.
- Observer : les exécutions, les logs et les traces sont visibles dans Studio.
Les secrets, les variables d'environnement et les autorisations se comportent de la même façon dans les trois modes : les identifiants proviennent du Secrets Manager, et l'accès repose sur vos rôles d'espace de travail.
Contrôle des accès
Pour les workflows, vous pouvez restreindre les utilisateurs et les comptes de service autorisés à enregistrer des workers sur un déploiement. C'est ce qu'on appelle un déploiement durci. Le durcissement est nécessaire pour les workflows on-behalf-of, qui agissent avec les autorisations de l'utilisateur qui les déclenche. Les déploiements gérés créés dans Studio sont durcis par défaut. Pour les agents, agents deploy durcit le déploiement seulement quand l'agent agit au nom de l'utilisateur de la session, sauf si vous passez --hardened ou --no-hardened : voir Déploiements durcis.
Points de départ
Choisissez le parcours qui correspond à ce que vous souhaitez exécuter :
Ou passez directement au déploiement d'un système précis :