Livre blancGouverner les agents IA en production : politiques, approbations humaines et arrêt d'urgence.Lire le livre blanc
NavinAI Platform

Scalabilité

Du premier pilote à la production à grande échelle

Chaque runtime monte en charge indépendamment, les files absorbent les pics et les quotas protègent chaque tenant. L'architecture reste la même du pilote à la production.

En bref

  • Autoscaling HPA et KEDA
  • Exécution durable avec points de reprise
  • Haute disponibilité déclarée par service

L'enjeu

Les agents ne se comportent pas comme des API classiques

Une exécution d'agent dure des secondes ou des heures, appelle des dizaines d'outils et consomme des GPU par pics. Une architecture pensée pour des requêtes courtes casse au premier passage à l'échelle.

  • Des exécutions longues interrompues par un redémarrage
  • Des pics de charge qui saturent les GPU
  • Un tenant gourmand qui pénalise tous les autres
  • La panne d'un fournisseur de modèles

La montée en charge

Des files et des runtimes qui s'adaptent à la demande

Les événements et les tâches passent par des files durables ; KEDA ajuste le nombre de workers à la profondeur des files, HPA à la charge.
  1. 01

    Requêtes et événements

    API, webhooks, canaux, planificateur

  2. 02

    NATS JetStream

    Files durables et déclencheurs

  3. 03

    Workers et agents

    Mis à l'échelle par KEDA et HPA

  4. 04

    Points de reprise

    Checkpoints PostgreSQL, reprise après bail

  5. 05

    Inférence

    vLLM sur pools GPU, fournisseurs distants

Un worker qui s'arrête rend son travail à la file : l'exécution reprend ailleurs, depuis son dernier point de reprise.

Tenir la charge

Conçue pour le trafic de production

  • Runtimes spécialisés

    Agents, voix temps réel, traitements par lots et médias, tâches périodiques et inférence montent en charge séparément.

  • Autoscaling

    HPA et KEDA dimensionnent les services selon la charge et la profondeur des files NATS JetStream.

  • Exécution durable

    Les exécutions d'agents enregistrent des points de reprise et reprennent après un incident, sans repartir de zéro.

  • Limites de ressources

    Chaque exécution est bornée en temps, en mémoire, en appels et en jetons ; un heartbeat détecte les exécutions bloquées.

  • Quotas par tenant

    Quotas et budgets isolent les tenants : un usage intensif n'affecte pas les autres.

  • GPU gérés

    NVIDIA GPU Operator, DCGM et comptabilité GPU pour les modèles servis par vLLM, avec des pools dédiés par tenant si nécessaire.

  • Bascule des fournisseurs

    LiteLLM et le routeur de modèles basculent vers un fournisseur ou un modèle de repli en cas de panne.

  • Haute disponibilité et PRA

    La haute disponibilité est déclarée service par service ; Velero assure sauvegardes et reprise après sinistre.

La preuve

Une capacité qui se planifie

Les métriques d'usage, de coût et de performance sont disponibles par tenant, par projet et par modèle pour dimensionner l'infrastructure avant qu'elle ne sature.

  • Objectifs de service et alertes Alertmanager
  • Surveillance de chaque service dans le Navin Manager et tableaux de bord du portail
  • Comptabilité GPU par déploiement
  • Exigences de charge, de haute disponibilité et de PRA vérifiées avant livraison

Pour aller plus loin

  • ArticleScalabilité

    Faire passer les agents IA à l'échelle sur Kubernetes

    Autoscaling avec HPA et KEDA, déclencheurs d'événements sur NATS JetStream, checkpoints durables, quotas et comptabilité GPU : comment Navin Enterprise AI exécute de nombreux agents sans perdre de travail ni de contrôle, avec une haute disponibilité déclarée par service.

    3 min de lecture

Dimensionnez votre plateforme IA avec nos architectes

Nous estimons avec vous la capacité nécessaire à vos cas d'usage, du pilote à la production.