Platform For AI:Déployer un service d'inférence asynchrone

Informations générales

Fonctionnalités

• Inférence asynchrone

  L'inférence en ligne à faible latence utilise généralement l'inférence synchrone : le client envoie une requête et attend le résultat sur la même connexion.

  Lorsque les temps d'inférence sont longs ou imprévisibles, l'attente synchrone peut provoquer la fermeture des connexions HTTP et des délais d'expiration côté client. Avec l'inférence asynchrone, le client envoie une requête et récupère le résultat ultérieurement par scrutation ou en s'abonnant aux notifications.

• Service de file d'attente

  Les scénarios quasi temps réel, tels que le traitement de courtes vidéos, l'analyse de flux audio/vidéo ou le traitement intensif d'images, exigent un retour des résultats dans un délai spécifique. Ces scénarios rencontrent les défis suivants :

  • L'algorithme d'équilibrage de charge tourniquet (round-robin) est inadapté. Les requêtes doivent être distribuées en fonction de la charge réelle de chaque réplica.

  • En cas de défaillance d'un réplica, ses tâches inachevées doivent être réaffectées à d'autres réplicas sains pour traitement.

  PAI propose un framework de service de file d'attente pour résoudre ces problèmes de distribution des requêtes.

Fonctionnement

• Un service d'inférence asynchrone comprend deux sous-services : un sous-service d'inférence et un sous-service de file d'attente. Le sous-service de file d'attente dispose de deux files intégrées : une file d'entrée et une file de sortie (sink). Les requêtes arrivent d'abord dans la file d'entrée. Chaque réplica du sous-service d'inférence s'abonne à la file d'entrée, traite les requêtes et écrit les réponses dans la file de sortie.

• Lorsque la file de sortie est pleine, le framework de service cesse de consommer les données de la file d'entrée afin d'éviter la perte de résultats non livrables.

  Si vous écrivez directement les résultats d'inférence dans OSS ou dans votre propre middleware de messagerie, renvoyez une réponse vide depuis l'interface HTTP d'inférence. La file de sortie est alors ignorée.

• Le sous-service de file d'attente reçoit les requêtes clientes et les distribue aux réplicas d'inférence en fonction de leur capacité de concurrence. Chaque réplica s'abonne à une fenêtre de requêtes, ce qui évite la surcharge et garantit que toutes les données sont finalement renvoyées au client.

  Remarque

  Par exemple, si chaque réplica peut traiter cinq flux audio, définissez la taille de la fenêtre à 5. Lorsqu'un réplica termine un flux et valide le résultat, le sous-service de file d'attente pousse un nouveau flux. Cela limite chaque réplica à cinq flux simultanés.

• Le sous-service de file d'attente surveille les connexions des réplicas. En cas de défaillance d'un réplica, ses requêtes non traitées sont redistribuées aux réplicas sains, garantissant ainsi qu'aucune donnée n'est perdue.

Accéder à un service d'inférence asynchrone

Le système crée un groupe de services portant le même nom. Étant donné que le sous-service de file d'attente gère le trafic entrant, accédez-y directement via les endpoints suivants. Consultez la rubrique Accéder à un service de file d'attente.

Gérer un service d'inférence asynchrone

Gérez un service d'inférence asynchrone comme un service classique. Le système gère automatiquement les sous-services : la suppression du service entraîne la suppression des deux sous-services, tandis que la mise à jour du sous-service d'inférence laisse le sous-service de file d'attente inchangé.

Même avec un seul réplica configuré, la liste des instances affiche une instance supplémentaire pour le sous-service de file d'attente.

Le nombre de réplicas fait référence aux réplicas du sous-service d'inférence. Les réplicas du sous-service de file d'attente sont mis à l'échelle automatiquement. Par exemple, si vous augmentez le nombre de réplicas d'inférence à 3, le nombre de réplicas de file d'attente passe à 2.

Règles de mise à l'échelle des réplicas :

• Lorsque le service est arrêté, les deux sous-services passent à 0 réplica.

• Avec un seul réplica d'inférence, le sous-service de file d'attente compte également un seul réplica (sauf configuration contraire).

• Avec deux réplicas d'inférence ou plus, le sous-service de file d'attente maintient deux réplicas (sauf configuration contraire).

• Si la mise à l'échelle automatique autorise un minimum de 0 réplica, le sous-service de file d'attente conserve un réplica de secours lorsque les réplicas d'inférence passent à 0.

Paramètres du sous-service de file d'attente

Le sous-service de file d'attente fonctionne avec la configuration par défaut dans la plupart des cas. Personnalisez-le dans le champ queue de premier niveau du fichier JSON :

{  
  "queue": {
     "sink": {
        "memory_ratio": 0.3
     },
     "source": {
        "auto_evict": true,
     }
 }

Les sections suivantes décrivent les options de configuration.

Ressources du sous-service de file d'attente

Par défaut, les ressources du sous-service de file d'attente héritent de metadata. Configurez-les séparément si nécessaire.

• Déclarez le groupe de ressources pour le sous-service de file d'attente à l'aide de queue.resource.

  {
    "queue": {
      "resource": "eas-r-slzkbq4tw0p6xd****"  // By default, it uses the resource group of the inference sub-service.
    }
  }

  • Utilise par défaut le groupe de ressources du sous-service d'inférence.

  • Pour déployer le sous-service de file d'attente dans un groupe de ressources public, définissez resource sur une chaîne vide (""). Cette option est utile lorsque votre groupe de ressources dédié manque de CPU ou de mémoire.

    Remarque

    Déployez le sous-service de file d'attente dans un groupe de ressources public chaque fois que possible.

• Déclarez le CPU (en cœurs) et la mémoire (en Mo) pour chaque réplica du sous-service de file d'attente à l'aide de queue.cpu et queue.memory.

  {
    "queue": {
       "cpu": 2,  // Default: 1.
       "memory": 8000  // Default: 4000.
    }
  }

  La configuration par défaut (1 cœur CPU, 4 Go de mémoire) suffit pour la plupart des scénarios.

  Important

  • Pour plus de 200 abonnés (réplicas du sous-service d'inférence), configurez 2 cœurs CPU ou plus.

  • Ne réduisez pas la mémoire du sous-service de file d'attente en production.

• Configurez le nombre minimal de réplicas pour le sous-service de file d'attente à l'aide de queue.min_replica.

  {
    "queue": {
       "min_replica": 3  // Default: 1.
    }
  }

  Les réplicas du sous-service de file d'attente sont mis à l'échelle automatiquement avec les réplicas d'inférence en cours d'exécution. La plage par défaut est [1, min{2, the number of inference sub-service replicas}]. Si la mise à l'échelle automatique permet de réduire à 0, un réplica de file d'attente est conservé. Utilisez queue.min_replica pour ajuster ce minimum.

  Remarque

  Un plus grand nombre de réplicas de file d'attente améliore la disponibilité, mais pas les performances.

Fonctionnalités du sous-service de file d'attente

Le sous-service de file d'attente prend en charge les configurations de fonctionnalités suivantes.

• Configurez l'éviction automatique des données pour les files de sortie et d'entrée à l'aide de queue.sink.auto_evict ou queue.source.auto_evict, respectivement.

  {
    "queue": {
       "sink": {
          "auto_evict": true  // Enables automatic eviction for the sink queue. Default: false.
        },
        "source": {
           "auto_evict": true  // Enables automatic eviction for the input queue. Default: false.
        }
    }
  }

  L'éviction automatique est désactivée par défaut : une file pleine rejette les nouvelles données. Activez l'éviction pour supprimer les données les plus anciennes et faire de la place pour les nouvelles entrées.

• Configurez le nombre maximal de tentatives de livraison à l'aide de queue.max_delivery.

  {
     "queue": {
        "max_delivery": 10  // The maximum number of delivery attempts is 10. Default: 5. If set to 0, this feature is disabled, and data can be delivered an unlimited number of times.
     }
  }

  Lorsque le nombre de tentatives de livraison dépasse le seuil, le message est marqué comme lettre morte. Consultez la rubrique Politique de lettres mortes.

• Configurez le temps maximal de traitement d'un message à l'aide de queue.max_idle.

  {
      "queue": {
        "max_idle": "1m"  // Configures the maximum processing time for a single message to 1 minute. If this time is exceeded, the message is delivered to another subscriber, and the delivery count is incremented. The default value is 0, which means no maximum processing time.
      }
  }

  Unités de temps prises en charge : h (heure), m (minute) et s (seconde). Si le traitement dépasse la durée configurée :

  • Si le seuil queue.max_delivery n'est pas dépassé, le message est relivré aux autres abonnés.

  • Si le seuil queue.max_delivery est dépassé, la politique de lettres mortes s'applique.

• Configurez la politique de lettres mortes à l'aide de queue.dead_message_policy.

  {
      "queue": {
        "dead_message_policy":  "Rear"  // The value can be Rear (default) or Drop. Rear moves the message to the end of the queue. Drop deletes the message. 																 
      }
  }

Longueur de file ou taille maximale de charge utile

La mémoire du réplica de file d'attente est fixe : augmenter la taille maximale de la charge utile par message réduit la longueur maximale de la file.

• Configurez la longueur maximale des files de sortie et d'entrée à l'aide de queue.sink.max_length ou queue.source.max_length, respectivement.

  {
      "queue": {
         "sink": {
            "max_length": 8000  // Configures the maximum length of the sink queue to 8,000 messages.
         },
         "source": {
            "max_length": 2000  // Configures the maximum length of the input queue to 2,000 messages.
         }
      }
  }

• Configurez la taille maximale de la charge utile par message pour les files de sortie et d'entrée à l'aide de queue.sink.max_payload_size_kb ou queue.source.max_payload_size_kb, respectivement.

  {
      "queue": {
         "sink": {
            "max_payload_size_kb": 10  // Configures the maximum payload size per message for the sink queue to 10 KB. Default: 8 KB.
         },
         "source": {
            "max_payload_size_kb": 1024  // Configures the maximum payload size per message for the input queue to 1024 KB (1 MB). Default: 8 KB.
         }
      }
  }

Ratio d'allocation de mémoire

• Ajustez l'allocation de mémoire entre les files d'entrée et de sortie à l'aide de queue.sink.memory_ratio.

  {
      "queue": {
         "sink": {
            "memory_ratio": 0.9  // Configures the memory ratio for the sink queue. Default: 0.5.
         }
      }
  }

  Remarque

  Par défaut, les files d'entrée et de sortie partagent la mémoire de manière égale. Augmentez queue.sink.memory_ratio si la file de sortie nécessite plus d'espace (par exemple, entrée textuelle et sortie image), ou diminuez-la pour l'effet inverse.

Mise à l'échelle horizontale automatique

Fonctionnement

Le système met à l'échelle dynamiquement les réplicas d'inférence en fonction de l'état de la file, y compris une réduction à zéro lorsque la file est vide. Le schéma suivant illustre ce mécanisme.