Utiliser Mastra avec des modèles open source hébergés dans l’UE

Mastra est un framework TypeScript open source créé par l’équipe à l’origine de Gatsby. Il fournit des agents dotés d’outils et de mémoire, des workflows en graphe avec suspension et reprise, des briques RAG, des évaluations et un Studio local pour les tests. Les applications Mastra tournent sous Node.js et se déploient sur des serveurs, des plateformes serverless ou au sein de frameworks web existants.

Les modèles se choisissent via le routeur de modèles de Mastra. En plus des fournisseurs intégrés, il accepte un point d’accès compatible OpenAI personnalisé lorsque vous passez url avec l’identifiant du modèle : c’est la méthode documentée pour connecter un service comme inference.eu.

Au lieu d’une chaîne comme "openai/...", réglez model sur un objet. id suit la forme fournisseur/modèle ; avec inference-eu/kimi-k3, Mastra envoie l’identifiant seul, kimi-k3, au point d’accès. url est l’URL de base d’inference.eu terminée par /v1, jamais le chemin complet de Chat Completions. apiKey est envoyée comme jeton bearer.

Les URL personnalisées utilisent par défaut l’API Chat Completions, ce qui convient à inference.eu. Vous pouvez aussi créer un fournisseur avec createOpenAICompatible de l’AI SDK et passer le modèle obtenu à l’agent : Mastra accepte directement les modèles de l’AI SDK.

Les agents Mastra appellent des outils et tournent souvent dans des workflows en plusieurs étapes : les modèles aux appels d’outils fiables donnent les meilleurs résultats. kimi-k3 et glm-5.3 sont de bons choix par défaut pour les agents de support, de recherche ou d’exploitation qui planifient et utilisent plusieurs outils.

Pour les agents qui écrivent ou relisent du code, utilisez qwen3-coder-480b-a35b-instruct. Pour les étapes rapides de classification, de routage ou d’extraction structurée dans un workflow, gpt-oss-120b limite la latence. Chaque agent et chaque étape peut avoir son propre modèle, et les modèles de secours de Mastra permettent d’indiquer un second modèle inference.eu en cas d’échec.

Une erreur 401 signifie que INFERENCE_EU_API_KEY n’est pas définie là où l’agent s’exécute : vérifiez le fichier .env en local et les réglages d’environnement de votre déploiement. Une erreur 404 vient le plus souvent d’une url contenant /chat/completions ou un autre chemin. Utilisez l’URL de base terminée par /v1.

« Model not found » signifie que la partie de id après inference-eu/ ne correspond à aucun identifiant inference.eu. Si la sortie structurée échoue, simplifiez le schéma Zod. Si un agent ignore ses outils, choisissez un modèle aux appels d’outils plus solides. Ne réglez pas api: "responses" pour inference.eu : gardez le chemin Chat Completions par défaut.

Avec le modèle pointé vers inference.eu, les messages, extraits de mémoire et résultats d’outils envoyés par vos agents sont traités dans des centres de données de l’UE et ne servent jamais à l’entraînement. Nous signons un accord de sous-traitance au titre de l’article 28 du RGPD, publions la liste de nos sous-traitants et facturons en euros.

Mastra n’appelle que les services que vous configurez. Le stockage de la mémoire, les bases vectorielles et les exportateurs d’observabilité conservent aussi des données : choisissez pour eux des solutions hébergées dans l’UE ou auto-hébergées. Déployez votre serveur Mastra dans une région européenne pour que les requêtes ne soient pas traitées ailleurs avant d’atteindre inference.eu.