Exécution de l’indexeur sur Serverless et Standard 3 Haute densité (S3 HD) (préversion)

Cet article décrit le modèle d’exécution de l’indexeur que Recherche Azure AI utilise pour les services de recherche Serverless et Standard 3 Haute densité (S3 HD). Les deux options ont un quota d’exécution quotidien au niveau du service qui régit la durée totale de l’indexeur que vous pouvez utiliser par fenêtre UTC de 24 heures.

Les fonctionnalités décrites dans cet article sont en préversion :

• La prise en charge de l’indexeur sur S3 HD nécessite l’API2025-11-01-preview REST ou une version ultérieure.
• La prise en charge des indexeurs serverless nécessite l’utilisation de l’API 2026-05-01-previewREST ou d’une version ultérieure.

Dans ce cas

Le modèle d’exécution de cet article s’applique à :

• Services de recherche sans serveur qui exécutent des indexeurs via l’API REST 2026-05-01-preview ou une version ultérieure.
• Services de recherche S3 HD qui exécutent des indexeurs à l’aide de l’API REST 2025-11-01-preview ou d’une version ultérieure.

Les définitions d’indexeur prises en charge, les sources de données, les ensembles de compétences et les sources de connaissances indexées fonctionnent sans modification sur les deux options.

Modèle d’exécution

Les indexeurs sur Serverless et S3 HD ont les caractéristiques d’exécution suivantes :

• Vous ne provisionnez ni ne gérez l’infrastructure d’indexeur. Le service gère la capacité pour vous.

• Les indexeurs s’exécutent uniquement dans l'environnement d’exécution multilocataire. L’environnement d’exécution privée, fourni par le biais de ressources de liaison privée partagée, n’est pas disponible pour les indexeurs sur ces références SKU.

• Pour S3 HD, si vous avez besoin de connexions d’indexeur pour rester hors de l’Internet public, configurez un périmètre de sécurité réseau (NSP) sur votre service de recherche pour contrôler le trafic entrant et sortant via des règles d’accès explicites.

• Pour Serverless, il n’existe aucune prise en charge des connexions privées.

Quota quotidien de durée d’exécution cumulée

L’exécution de l’indexeur est régie par un quota d’exécution quotidien qui est réinitialisé à 00:00 UTC. Le quota est le suivant :

• Niveau de service : Il s’applique au service de recherche dans son ensemble.
• Cumulé : Le temps d’exécution de chaque indexeur du service est comptabilisé dans le même quota. Le quota n’est pas appliqué pour chaque indexeur.

Tous les indexeurs en cours d’exécution accumulent du temps par rapport à un budget de service partagé. Le service ne réserve pas le runtime pour les indexeurs individuels ou divise automatiquement le quota de manière égale entre eux. Par exemple, les durées cumulées de 12 indexeurs s’exécutant chacun pendant deux heures peuvent consommer la totalité des 24 heures d’exécution cumulées, que les exécutions se chevauchent ou aient lieu à des moments différents.

Le tableau suivant répertorie le quota quotidien par référence SKU et la version minimale de l’API qui la prend en charge :

Lorsque le quota quotidien est épuisé :

• Les indexeurs en cours d’exécution s’arrêtent dans un délai d’environ cinq minutes.

• Les nouvelles exécutions de l’indexeur ne traitent pas les documents et renvoient immédiatement une erreur transitoire indiquant que le quota quotidien a été dépassé.

• L’exécution normale de l’indexeur reprend après la réinitialisation du compteur à 00:00 UTC.

Récupérer après épuisement du quota

Pour récupérer à partir de l’épuisement du quota et réduire la probabilité de l’atteindre à nouveau :

• Attendez la prochaine réinitialisation à 00:00 UTC, ou utilisez Get Service Statistics (API REST) pour confirmer que remainingSeconds est reconstitué avant de lancer de nouvelles exécutions.

• Configurez les indexeurs selon des horaires décalés afin que la charge de travail se répartisse sur une période de 24 heures au lieu de s’exécuter simultanément.

• Vous ne pouvez pas suspendre ou arrêter les exécutions actives. Utilisez Obtenir l’état de l’indexeur pour les surveiller et voir Exécuter ou réinitialiser les indexeurs pour le comportement du contrôle d’exécution.

• Si le runtime reste mais que les exécutions de l’indexeur échouent, consultez Résoudre les problèmes d’indexeur.

• Réduisez le coût de l’ensemble de compétences. Les compétences qui font appel à des services externes, telles que la compétence Azure OpenAI Embedding skill, la compétence GenAI Prompt skill et la compétence Azure Content Understanding skill, consomment rapidement le temps d’exécution. Réduisez le nombre de compétences, de documents par lots ou configurez un cache d’enrichissement pour réutiliser les résultats antérieurs au lieu de retraiter.

• Surveillez remainingSeconds de manière proactive au niveau du service et de l’indexeur pour que vous puissiez limiter les charges de travail avant qu’elles ne échouent.

Contrôler le temps de fonctionnement cumulatif

Cette section explique comment suivre l’utilisation du runtime et le budget restant à l’aide des API REST du service de recherche. Il n’existe aucune expérience du portail pour le runtime cumulatif pendant la préversion.

Environnement d’exécution au niveau du service

Utilisez Get Service Statistics (API REST) pour récupérer le runtime d’indexeur cumulé sur tous les indexeurs du service pour la fenêtre actuelle de 24 heures :

GET {endpoint}/servicestats?api-version=2026-08-01-preview

La réponse comprend une indexersRuntime section. Le code JSON suivant montre un service dont le quota quotidien de 24 heures n’est pas utilisé :

"indexersRuntime": {
    "usedSeconds": 0,
    "remainingSeconds": 86400,
    "beginningTime": "2026-05-16T00:00:00.000Z",
    "endingTime": "2026-05-17T00:00:00.000Z"
}

Points clés :

• usedSeconds: nombre total de secondes pendant lesquelles tous les indexeurs du service ont fonctionné au cours de la fenêtre en cours.
• remainingSeconds: Secondes encore disponibles avant que le quota quotidien soit atteint. S’affiche lorsqu’une limite propre au niveau s’applique.
• beginningTime et endingTime: Début et fin de la fenêtre de comptage UTC actuelle de 24 heures.

Runtime au niveau de l’indexeur

Utilisez l’état Get Indexer (API REST) pour récupérer le runtime cumulatif d’un indexeur individuel :

GET {endpoint}/indexers('{indexerName}')/search.status?api-version=2026-08-01-preview

La réponse comprend une runtime section. Le code JSON suivant montre un indexeur sur un service dont le quota quotidien de 24 heures n’est pas utilisé :

"runtime": {
    "usedSeconds": 0,
    "remainingSeconds": 86400,
    "beginningTime": "2026-05-16T00:00:00.000Z",
    "endingTime": "2026-05-17T00:00:00.000Z"
}

Points clés :

• usedSeconds: nombre total de secondes que l’indexeur a exécutées pendant la fenêtre active.
• remainingSeconds: Nombre de secondes encore disponibles pour l’ensemble des indexeurs du service, et pas seulement pour cet indexeur. S’affiche lorsqu’une limite propre au niveau s’applique.
• beginningTime et endingTime: Début et fin de la fenêtre de comptage UTC actuelle de 24 heures.

Bonnes pratiques

La prise en charge de l’indexeur sur S3 HD et Serverless est en version préliminaire. Suivez ces instructions pour dimensionner les charges de travail de manière appropriée et planifier la facturation de Serverless à introduire ultérieurement.

S3 HD

En préversion, la prise en charge de l’indexeur S3 HD est conçue pour les charges de travail sans ensemble de compétences ou avec des ensembles de compétences de petite taille. Pour rester dans le quota quotidien :

• Prévoyez des index de petite taille, d’environ 1 Go.

• Dimensionner soigneusement l’utilisation de l’ensemble de compétences. Les compétences qui font appel à des services externes, telles que la compétence Azure OpenAI Embedding, la compétence GenAI Prompt et la compétence Azure Content Understanding, augmentent considérablement le temps d’exécution et peuvent consommer rapidement le quota quotidien, en particulier dans les scénarios multilocataires.

• Attendez-vous à un parallélisme limité pendant la préversion. Utilisez des exécutions planifiées et échelonnées pour les grandes flottes d’indexeurs afin que la charge de travail se répartisse sur l’ensemble de la période de 24 heures au lieu de se disputer le même budget.

Charge de travail de fractionnement et d’incorporation illustratif

Dans un test S3 HD contrôlé, une compétence de fractionnement et une compétence Azure OpenAI Embedding ont généré des segments et des vecteurs d’incorporation. La charge de travail a produit environ 2,5 blocs par document source et environ 22 000 documents sources ont été observés dans ce test pendant une fenêtre de test S3 HD de 24 heures.

Les valeurs suivantes sont arrondies, illustrant l’arithmétique de partage équitable en fonction de l’observation agrégée. Ils ne sont pas mesurés en tant que résultats par indexeur.

Le service ne réserve pas de capacité et ne garantit pas une répartition uniforme, un ordre d’exécution ou un débit pour ce nombre d’indexeurs.

Le débit peut varier considérablement en fonction de la complexité et du profil des documents, du découpage en segments, du nombre et du type de compétences et de résultats vectoriels, de la latence du modèle, de la capacité et du quota, des performances de la source et de la cible, de la concurrence, de l’ordre de planification, de la limitation du débit, de la région, des échecs et des tentatives répétées, du craquage de documents ou de la reconnaissance optique de caractères (OCR), ainsi que de volumes inégaux selon les locataires. Testez avec des entrées de production représentatives avant de planifier la capacité.

Serverless

Au cours de la préversion, les indexeurs serverless sont conçus pour simplifier l’ingestion pour les scénarios de génération augmentée par récupération (RAG) et de base de connaissances :

• L’exécution de l’indexeur (à l’exclusion des compétences) est actuellement gratuite. L’écriture de documents dans un index entraîne un coût.

• L’exécution de l’ensemble de compétences est facturée de la même façon que sur les indexeurs dédiés. Les appels aux services externes, tels que la compétence Azure OpenAI Embedding, la compétence GenAI Prompt et la compétence Azure Content Understanding, sont facturés via la ressource Foundry ou ressource Azure AI services associée.

Limites et quotas

Pour connaître les limites de l’indexeur sur Serverless et S3 HD, consultez les limites de l’indexeur.

Le quota d’exécution du service et les limites de l’indexeur ne remplacent pas les limites d’entrée, de requête ou de traitement des compétences et des services externes au sein d’un jeu de compétences. Vérifiez chaque référence à une compétence séparément lorsque vous dimensionnez un pipeline d’enrichissement.

Contenu connexe

• Indexers dans Recherche Azure AI
• Exécuter ou réinitialiser des indexeurs
• Surveiller l’état et les résultats de l’indexeur
• Sources de connaissances
• Limites de service de la Recherche Azure AI