Cortex (passerelle LLM)
Le saut interne emprunté par chaque appel LLM, embedding et image. Là où vivent le routage des modèles, le basculement et l'observabilité.
Cortex est la passerelle interne au cluster par laquelle transitent tous les appels LLM, embedding, image et OCR. Elle existe pour une seule raison : la plateforme doit pouvoir changer de modèle, basculer en cas de défaillance et appliquer la gouvernance sans reconstruire les workflows. Le service Cortex sert également l'application Chat orientée clients ; cette page couvre les mécanismes internes de la passerelle.
Cortex est un service interne. Les workflows ne l'appellent jamais directement — ils référencent une capacité (« un LLM qui prend en charge l'utilisation d'outils »), et Cortex résout cette capacité vers l'intégration installée correspondante.
Ce qu'elle fait
| Préoccupation | Comment Cortex la gère |
|---|---|
| Résolution des capacités | Un workflow demande un LLM. Cortex choisit le bon fournisseur en fonction du remplacement par appel → politique de l'organisation → correspondance automatique parmi les candidats installés. Jamais codé en dur. |
| Gestion des identifiants | Les identifiants d'intégration vivent dans le coffre de secrets. Cortex récupère l'identifiant approprié pour le fournisseur résolu, délimité par le workspace et la requête. |
| Streaming | Tous les fournisseurs sont exposés via une interface de streaming SSE unifiée, de sorte que le runtime agentique n'a pas à se soucier que le modèle soit OpenAI, Anthropic, vLLM ou Bedrock. |
| Basculement | Si le fournisseur principal retourne une classe d'erreur correspondant à la politique de basculement de l'organisation, Cortex réessaie avec le prochain candidat. |
| Observabilité | Les comptages de tokens, la latence, le coût, l'identifiant du modèle et la source d'intégration sont émis vers le pipeline analytique pour la facturation et les tableaux de bord. |
| Gouvernance | La couche de garde-fous DLP peut pré- et post-filtrer le contenu (détection de données personnelles, scoring d'hallucination) sans que le workflow ait à le câbler. |
Catalogue de fournisseurs
Cortex ne livre pas ses propres modèles. Il expose les fournisseurs installés dans le registre d'intégrations :
- Auto-hébergés — Ollama, vLLM, déploiements Azure AI Foundry dans votre propre abonnement.
- Cloud — OpenAI, Anthropic, Mistral, AWS Bedrock, Azure OpenAI.
- Personnalisés — tout ce qui est créé avec le SDK Intégrations et qui expose une capacité LLM.
Chaque modèle déclare sa propre surface de capacités — fenêtre de contexte, support des outils, plage de température, sortie structurée, vision, etc. Les workflows peuvent exiger ces capacités, et Cortex n'achemine que vers des modèles qui correspondent.
Routage auto-hébergé vs. cloud
Cortex n'a pas d'opinion sur l'endroit où le modèle s'exécute — dans votre espace de noms GPU ou chez un fournisseur tiers. Le même point d'appel est utilisé :
Workflow → Cortex → resolve capability → pick provider:
├── Self-hosted vLLM in scrydon-inference namespace
├── Ollama service in scrydon-inference namespace
├── Azure AI Foundry deployment in your subscription
├── OpenAI / Anthropic / Bedrock (external, opt-in)
└── Custom authored integrationLe choix est gouverné par la politique de l'organisation. Patterns courants :
- « Toute l'IA sur le cluster » — seuls les fournisseurs auto-hébergés sont installés. Aucun appel sortant.
- « Auto-hébergé avec déversement cloud » — le modèle par défaut est auto-hébergé ; l'organisation autorise le basculement vers un fournisseur cloud pour les appels nécessitant de nombreux outils ou un long contexte.
- « Cloud en premier » — l'organisation fonctionne principalement sur un modèle cloud géré (déploiements Azure typiques).
Où configurer cela
- Intégrations — ce qui est installé et les capacités que chaque fournisseur expose. Paramètres → Plateforme → Intégrations.
- Politique de capacité — paramètres par défaut et listes d'autorisation par capacité. Paramètres → Plateforme → Intégrations → [Vendeur] → Capacités.
- Remplacement par workflow — un bloc Agent spécifique peut épingler un modèle. L'interface du bloc affiche le fournisseur résolu pour que vous puissiez voir ce qui s'exécuterait.
Voir la section de résolution des capacités des vendeurs pour l'ordre complet.
Voir aussi
- Intégrations — le registre que Cortex résout.
- Vendeurs — le catalogue de fournisseurs livrés avec Scrydon.
- Architecture → Agentic — ce qui appelle Cortex.
- Sécurité → Gestion des secrets — où vivent les identifiants des fournisseurs.