Aller au contenu principal
Dernière mise à jour le

Monter en charge le throughput de l'Endpoint de recherche IA avec un QPS élevé

Par default, les endpoints standard prennent en charge de 20 à 200 QPS selon la taille de l'index. Les applications en temps réel telles que les barres de recherche, les systèmes de recommandation et la correspondance d'entités nécessitent souvent de 100 à plus de 1 000 QPS. Sur les Endpoint standard uniquement, vous pouvez définir un QPS cible. Databricks provisionne l'infrastructure pour correspondre au mieux à ce niveau de throughput (meilleur effort, non garanti).

important

La définition d'un QPS cible provisionne une capacité supplémentaire, ce qui augmente le coût de l'endpoint. Vous êtes facturé pour cette capacité supplémentaire, indépendamment du trafic réel de query. La mise à l'échelle du throughput est un effort optimal et n'est pas garantie.

Utiliser QPS élevé lorsque :

  • Votre application nécessite plus de 50 QPS de throughput soutenu.
  • Vous recevez des erreurs 429 (Too Many Requests) sous une charge normale.
  • La latence se dégrade à mesure que le trafic augmente, même lorsque l'utilisation moyenne semble faible.

Exigences​

  • Le QPS élevé est disponible uniquement pour les Endpoints standard. Les endpoints optimisés pour le stockage ne sont pas pris en charge.
  • Utilisez l'authentification OAuth du Service Principal et l'URL d'index pour les charges de travail de production à QPS élevé. Les jetons d'accès personnels (PAT) et l'URL de query du Workspace sont appropriés pour le prototypage, mais ils n'utilisent pas la route de query optimisée et sont plafonnés à quelques dizaines de QPS.
  • Pour les index Delta Sync qui utilisent des modèles d'embedding gérés pour les query de texte, la route de query optimisée n'est pas disponible lorsque le Workspace utilise des listes d'accès IP ou une connectivité privée, telle qu'AWS PrivateLink. Dans cette configuration, l'Endpoint pourrait ne pas atteindre le QPS cible configuré.

Configurer le QPS cible​

Définissez un QPS cible lors de la création d'un nouvel endpoint ou de la mise à jour d'un endpoint existant. La capacité supplémentaire nécessaire pour correspondre au mieux au throughput cible est provisionnée automatiquement. La mise à l'échelle du throughput est fait au mieux et n'est pas garantie : le QPS réel dépend de la taille de votre index, de la dimensionnalité des vecteurs, de la complexité des query et de l'utilisation des filtres.

Lorsque vous créez un nouvel endpoint :

  1. Dans la barre latérale gauche, cliquez sur Compute .

  2. Cliquez sur l'onglet Recherche IA et cliquez sur Créer un Endpoint .

    Créer un compute de Recherche IA.

  3. Sous Paramètres avancés , saisissez la valeur QPS cible .

    Boîte de dialogue : Créer un endpoint de recherche IA.

Lors de la mise à jour d'un Endpoint existant :

  1. Accédez à la page de détails du Endpoint.

  2. Dans le panneau de droite, cliquez sur l'icône en forme de crayon Icône de crayon. à côté de QPS cible .

    Modifier le QPS cible.

  3. Saisissez la nouvelle valeur et cliquez sur Enregistrer .

    Saisissez la valeur QPS cible.

Interroger l'URL de l'index​

Une fois que l'état de mise à l'échelle de l'endpoint est SCALING_CHANGE_APPLIED, envoyez des queries à l'URL de l'index en utilisant un jeton OAuth de service principal. Cette URL est nécessaire pour utiliser la capacité de query supplémentaire provisionnée par target_qps.

Pour les applications Python, appelez get_index() une fois et réutilisez l'objet index retourné. Le SDK Python envoie des requêtes à l'URL de l'index.

Python
from databricks.ai_search.client import AISearchClient

client = AISearchClient(
    service_principal_client_id="...",
    service_principal_client_secret="...",
    workspace_url="https://<workspace-url>",
)

index = client.get_index(endpoint_name="my-high-qps-endpoint", index_name="catalog.schema.index")

# Reuse this index object for every query.
index.similarity_search(query_vector=[...], columns=["id", "text"], num_results=10)

Pour les applications REST ou non-Python, obtenez d'abord l'URL d'index, puis envoyez les requêtes de query à cette URL. Le jeton doit être un jeton OAuth de Service Principal.

sh
export WORKSPACE_URL=https://<workspace-url>
export INDEX_NAME=catalog.schema.index
export TOKEN=<oauth-token>

export INDEX_URL=$(curl -X GET \
  -H "Authorization: Bearer $TOKEN" \
  "$WORKSPACE_URL/api/2.0/vector-search/indexes/$INDEX_NAME" \
  | jq -r '.status.index_url')

case "$INDEX_URL" in
  http://*|https://*) ;;
  *) INDEX_URL="https://$INDEX_URL" ;;
esac

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "$INDEX_URL/query" \
  --data '{"num_results": 10, "query_vector": [...], "columns": ["id", "text"]}'

N'utilisez pas l'URL de query du workspace, telle que /api/2.0/vector-search/indexes/<index_name>/query, pour le trafic de production à QPS élevé. Cette URL n'utilise pas la route de query optimisée et peut renvoyer des erreurs 429 avant que l'endpoint n'atteigne le QPS cible configuré.

Comment la mise à l'échelle s'applique​

Après avoir défini un QPS cible, la capacité requise est approvisionnée automatiquement. Le nouveau niveau de throughput s'applique une fois le provisionnement terminé ; vous n'avez pas besoin de synchroniser les index pour trigger le changement.

remarque

Toute tentative de mise à jour du QPS cible pendant une opération de mise à l'échelle renvoie une erreur RESOURCE_CONFLICT. Attendez que l'opération actuelle se termine avant de réessayer.

Dépanner les erreurs 429​

Pour les charges de travail à QPS élevé, utilisez ces vérifications pour trouver le goulot d'étranglement :

  • Si vous utilisez un PAT ou l'URL de query du Workspace, passez à l'authentification OAuth du Service Principal et à l'URL d'index.
  • Si scaling_info.state est SCALING_CHANGE_IN_PROGRESS, attendez que l'état passe à SCALING_CHANGE_APPLIED.
  • Si votre application envoie des querys vectorielles avec query_vector, le modèle d’intégration ne se trouve pas dans le chemin de query. Si les erreurs 429 persistent après la fin de la montée en charge, réduisez la concurrence des requêtes ou définissez un target_qps plus élevé.
  • Si votre application envoie des queries textuelles à un index Delta Sync avec des modèles d’intégration gérés par Databricks, le modèle d’intégration pourrait être le goulot d’étranglement. Utilisez un modèle d’intégration plus petit, tel que databricks-qwen3-embedding-0-6b, au lieu de databricks-gte-large-en, ou utilisez un Endpoint d’API de modèle de fondation à throughput provisionné ou un autre Endpoint de Model Serving dédié pour les intégrations.

Limitations​

  • Pas de mise à l'échelle automatique : Vous devez définir le QPS cible manuellement en fonction du trafic attendu. Si le trafic dépasse le niveau provisionné, des erreurs 429 se produisent. Consultez Planifier les pics de query.
  • Endpoint standards uniquement : les Endpoint optimisés pour le stockage ne prennent pas en charge target_qps.
  • Route optimisée requise : Le QPS cible configuré s'applique au trafic qui utilise l'authentification OAuth du Service Principal et l'URL d'index. Le trafic PAT et le trafic d'URL de query du Workspace sont plafonnés à quelques dizaines de QPS.
  • **Les modèles d'intégration gérés peuvent ajouter une deuxième limite** : Pour les index Delta Sync qui utilisent un modèle d'intégration géré pour les query de texte, le throughput des query dépend également de l'Endpoint de déploiement du modèle d'intégration. Augmentez la capacité de service des modèles, utilisez le throughput provisionné ou utilisez des incorporations autogérées pour un throughput de query prévisible.
Sur cette page