Fonctionnement

Cette page explique les concepts qui sous-tendent Model Router : lisez-la une fois et toutes les autres pages seront plus claires.

Le solde prépayé

Votre installation dispose d'un solde prépayé en USD. Il n'évolue que dans deux sens :

• À la hausse lorsque vous rechargez (manuellement, via le rechargement automatique ou par un ajustement crédité sur votre compte). Les rechargements apparaissent instantanément.
• À la baisse au fur et à mesure de l'utilisation. L'utilisation est communiquée en temps réel par le service d'inférence et rapprochée de votre solde prépayé toutes les 15 minutes ; l'activité très récente peut donc mettre quelques minutes à apparaître dans Monthly usage. L'historique des transactions ne répertorie que les rechargements et les ajustements de solde.

Le solde constitue la barrière financière : lorsqu'il atteint zéro, les requêtes d'inférence sont bloquées avec une erreur insufficient credits jusqu'à ce que vous rechargiez. La liste des modèles fonctionne toujours avec un solde nul, de sorte que les intégrations peuvent découvrir le catalogue avant que vous n'approvisionniez le compte.

Le catalogue de modèles

Le catalogue contient des modèles de nombreux fournisseurs, chacun facturé par million de tokens (entrée et sortie facturées séparément, comme indiqué dans les paramètres Models). Tous les modèles sont activés par défaut pour votre installation ; vous pouvez :

• Désactiver des modèles pour l'ensemble du compte dans Settings → Models (au moins un modèle doit rester activé).
• Restreindre les modèles par clé API ou par service connecté : une liste plus restreinte qui s'ajoute à l'ensemble des modèles activés pour l'installation.

Une entrée spéciale du catalogue, auto (l'Auto Router), n'a pas de prix propre. Pour chaque requête, il sélectionne automatiquement le meilleur modèle en fonction de la complexité du prompt, et vous êtes facturé au tarif du modèle qu'il choisit. Consultez Models.

Deux façons d'utiliser les modèles

1. Services connectés

Les appareils Agent IA associés à votre installation se connectent automatiquement à Model Router (aucune clé API n'est jamais saisie sur l'appareil), et les Workflows peuvent également se connecter. Chaque service connecté apparaît dans Settings → Service Access & API Keys sous Connected Services avec ses propres chiffres de dépenses, et vous pouvez attribuer à chacun ses propres limites de dépenses, restrictions de modèles et remplacements de guardrails. Consultez Connected Services.

2. Vos propres clés API

Vous pouvez créer des clés API (elles commencent par phk_) afin que les logiciels et systèmes tiers prenant en charge le BYOK (Bring Your Own Key) puissent se connecter aux modèles publiés par Performance Hub. Le point de terminaison est compatible OpenAI : pointez n'importe quel SDK ou outil OpenAI vers l'URL de base et authentifiez-vous avec votre clé. Consultez Clés API et Connecter votre application.

Les deux voies puisent dans le même solde, respectent les mêmes limites de dépenses à l'échelle du compte, apparaissent dans les mêmes analyses Activity et dans les mêmes Logs, et peuvent être encadrées individuellement.

Solde et limites de dépenses

Il s'agit de deux mécanismes distincts, et tous deux s'appliquent :

Les limites de dépenses du compte existent sur trois périodes : quotidienne (réinitialisée chaque jour à minuit, heure locale de l'installation), mensuelle (réinitialisée le 1er de chaque mois, heure locale de l'installation) et un plafond absolu à vie (comptabilise les dépenses depuis la dernière réinitialisation manuelle ; ne se réinitialise jamais de lui-même). N'importe quelle combinaison peut être active en même temps, et les limites s'appliquent à l'ensemble des clés API et des services connectés réunis. Le solde prépayé s'applique toujours en plus.

Les limites par clé et par service fonctionnent de la même manière (quotidienne, mensuelle, à vie), mais ne comptabilisent que les dépenses de cette clé ou de ce service. Lorsqu'une limite est atteinte, seuls cette clé ou ce service sont bloqués : le reste de l'installation continue de fonctionner.

Traitement d'une requête

Lorsqu'une requête arrive au point de terminaison, les vérifications s'exécutent dans cet ordre :

1. Authentification : une clé API ou une identité de service connecté valide. Pour une clé API, une installation dans laquelle Model Router n'est pas activé est rejetée à ce stade avec un HTTP 403 ("Model Router is not enabled for this facility"). La liste des modèles (GET /v1/models) est renvoyée juste après l'authentification ; elle fonctionne donc même avec un solde nul.
2. Vérification du crédit prépayé : le solde disponible doit être supérieur à $0 (pour les services connectés, Model Router doit également être activé) ; sinon, la requête est rejetée avec une erreur insufficient credits (HTTP 402).
3. Limites de dépenses du compte : si un plafond quotidien, mensuel ou à vie est dépassé, la requête est rejetée avec une erreur budget exceeded (HTTP 402) qui indique quand la période est réinitialisée, dans le fuseau horaire de votre installation.
4. Limites de dépenses par clé / par service : même vérification, limitée à la clé ou au service appelant.
5. Vérifications du prompt : la protection contre l'injection de prompts et vos filtres de contenu personnalisés s'exécutent sur le prompt. Un filtre block ou une détection d'injection rejette la requête (HTTP 403, content policy violation) ; les filtres redact remplacent les correspondances par [REDACTED] et laissent la requête se poursuivre.
6. Routage du modèle : auto est résolu en un modèle concret par l'Auto Router (une requête contenant une image est envoyée à un modèle doté de capacités de vision que vous autorisez). Les modèles de repli sont filtrés pour ne garder que ceux que la clé peut utiliser, votre paramètre de raisonnement est appliqué lorsque la requête ne définit pas le sien, et les limites de sortie demandées sont ramenées à ce que le modèle prend en charge.
7. Inférence : le masquage des données personnelles et le masquage des secrets (lorsqu'ils sont activés) sont appliqués par le service d'inférence avant que le prompt n'atteigne le modèle ; la requête est ensuite transmise au fournisseur du modèle et la réponse est renvoyée en streaming.

Les limites de débit (requêtes/min et tokens/min, si elles sont définies sur la clé ou le service) sont appliquées tout au long du processus ; leur dépassement renvoie un HTTP 429.

Ce qui est enregistré

Chaque requête est journalisée avec ses métadonnées : heure, modèle (à la fois le modèle demandé et celui retenu par le routeur), fournisseur, tokens (prompt, complétion, mis en cache, raisonnement), coût, latence, délai avant le premier token, vitesse, état, et la clé ou le service appelant. Le contenu des prompts et des réponses n'est jamais stocké.

Les chiffres d'utilisation et de dépenses affichés dans le module sont les mêmes que ceux utilisés pour l'application des limites : ce que vous voyez comme « limit reached » correspond exactement à ce qui est bloqué.

Glossaire