Personnaliser la configuration de GKE Inference Gateway

Cette page explique comment personnaliser le déploiement de GKE Inference Gateway.

Cette page s'adresse aux spécialistes de la mise en réseau chargés de gérer l'infrastructure GKE, ainsi qu'aux administrateurs de plate-forme qui gèrent les charges de travail d'IA.

Pour gérer et optimiser les charges de travail d'inférence, vous devez configurer les fonctionnalités avancées de la passerelle d'inférence GKE.

comprendre et configurer les fonctionnalités avancées suivantes ;

Configurer les vérifications de sécurité et de sûreté de l'IA

GKE Inference Gateway s'intègre à Model Armor pour effectuer des vérifications de sécurité sur les requêtes et les réponses des applications qui utilisent de grands modèles de langage (LLM). Cette intégration fournit un niveau supplémentaire d'application des règles de sécurité au niveau de l'infrastructure, qui complète les mesures de sécurité au niveau de l'application. Cela permet d'appliquer des règles de manière centralisée à l'ensemble du trafic LLM.

Le schéma suivant illustre l'intégration de Model Armor à GKE Inference Gateway sur un cluster GKE :

Intégration de Google Cloud Model Armor sur un cluster GKE
Figure : Intégration de Model Armor sur un cluster GKE

Pour configurer les vérifications de sécurité de l'IA, procédez comme suit :

  1. Assurez-vous de remplir les conditions préalables suivantes :

    1. Activez le service Model Armor dans votre projet Trusted Cloud by S3NS .
    2. Créez les modèles Model Armor à l'aide de la console Model Armor, de la Google Cloud CLI ou de l'API.

  2. Assurez-vous d'avoir déjà créé un modèle Model Armor nommé my-model-armor-template-name-id.

  3. Pour configurer GCPTrafficExtension, procédez comme suit :

    1. Enregistrez l'exemple de fichier manifeste suivant sous le nom gcp-traffic-extension.yaml :

      kind: GCPTrafficExtension
apiVersion: networking.gke.io/v1
metadata:
  name: my-model-armor-extension
spec:
  targetRefs:
  - group: "gateway.networking.k8s.io"
    kind: Gateway
    name: GATEWAY_NAME
  extensionChains:
  - name: my-model-armor-chain1
    matchCondition:
      celExpressions:
      - celMatcher: request.path.startsWith("/")
    extensions:
    - name: my-model-armor-service
      supportedEvents:
      - RequestHeaders
      timeout: 1s
      googleAPIServiceName: "modelarmor.us-central1.rep.googleapis.com"
      metadata:
        'extensionPolicy': MODEL_ARMOR_TEMPLATE_NAME
        'sanitizeUserPrompt': 'true'
        'sanitizeUserResponse': 'true'

      Remplacez les éléments suivants :

      • GATEWAY_NAME : nom de la passerelle.
      • MODEL_ARMOR_TEMPLATE_NAME : nom de votre modèle Model Armor.

      Le fichier gcp-traffic-extension.yaml inclut les paramètres suivants :

      • targetRefs : spécifie la passerelle à laquelle s'applique cette extension.
      • extensionChains : définit une chaîne d'extensions à appliquer au trafic.
      • matchCondition : définit les conditions dans lesquelles les extensions sont appliquées.
      • extensions : définit les extensions à appliquer.
      • supportedEvents : spécifie les événements au cours desquels l'extension est appelée.
      • timeout : spécifie le délai avant expiration de l'extension.
      • googleAPIServiceName : spécifie le nom du service pour l'extension.
      • metadata : spécifie les métadonnées de l'extension, y compris les paramètres de extensionPolicy et de désinfection des requêtes ou des réponses.

    2. Appliquez l'exemple de fichier manifeste à votre cluster :

      kubectl apply -f `gcp-traffic-extension.yaml`

Une fois que vous avez configuré les vérifications de sécurité de l'IA et que vous les avez intégrées à votre passerelle, Model Armor filtre automatiquement les requêtes et les réponses en fonction des règles définies.

Configurer l'observabilité

La passerelle d'inférence GKE fournit des informations sur l'état, les performances et le comportement de vos charges de travail d'inférence. Cela vous aide à identifier et à résoudre les problèmes, à optimiser l'utilisation des ressources et à assurer la fiabilité de vos applications.

Trusted Cloud by S3NS fournit les tableaux de bord Cloud Monitoring suivants, qui offrent une observabilité de l'inférence pour GKE Inference Gateway :

  • Tableau de bord GKE Inference Gateway : fournit des métriques clés pour le service LLM, telles que le débit de requêtes et de jetons, la latence, les erreurs et l'utilisation du cache pour InferencePool. Pour obtenir la liste complète des métriques GKE Inference Gateway disponibles, consultez Métriques exposées.
  • Tableau de bord du serveur de modèles : fournit un tableau de bord pour les signaux clés du serveur de modèles. Cela vous permet de surveiller la charge et les performances des serveurs de modèles, tels que KVCache Utilization et Queue length. Cela vous permet de surveiller la charge et les performances des serveurs de modèles.
  • Tableau de bord de l'équilibreur de charge : il fournit des métriques de l'équilibreur de charge, comme les requêtes par seconde, la latence de traitement des requêtes de bout en bout et les codes d'état des requêtes et des réponses. Ces métriques vous aident à comprendre les performances de la diffusion des requêtes de bout en bout et à identifier les erreurs.
  • Métriques du gestionnaire de GPU de centre de données (DCGM) : fournissent des métriques sur les GPU NVIDIA, telles que les performances et l'utilisation des GPU NVIDIA. Vous pouvez configurer les métriques du gestionnaire GPU de centre de données (DCGM) NVIDIA dans Cloud Monitoring. Pour en savoir plus, consultez Collecter et afficher les métriques DCGM.

Afficher le tableau de bord GKE Inference Gateway

Pour afficher le tableau de bord GKE Inference Gateway, procédez comme suit :

  1. Dans la console Trusted Cloud , accédez à la page Surveillance.

    Accéder à Monitoring

  2. Dans le volet de navigation, sélectionnez Tableaux de bord.

  3. Dans la section Intégrations, sélectionnez GMP.

  4. Sur la page Modèles de tableaux de bord Cloud Monitoring, recherchez "Gateway".

  5. Affichez le tableau de bord GKE Inference Gateway.

Vous pouvez également suivre les instructions de la section Tableau de bord de surveillance.

Configurer le tableau de bord d'observabilité du serveur de modèles

Pour collecter des signaux d'or à partir de chaque serveur de modèle et comprendre ce qui contribue aux performances de la passerelle d'inférence GKE, vous pouvez configurer la surveillance automatique de vos serveurs de modèle. Cela inclut les serveurs de modèles suivants :

Pour afficher les tableaux de bord d'intégration, procédez comme suit :

  1. Collectez les métriques à partir de votre serveur de modèle.

  2. Dans la console Trusted Cloud , accédez à la page Surveillance.

    Accéder à Monitoring

  3. Dans le volet de navigation, sélectionnez Tableaux de bord.

  4. Sous Integrations (Intégrations), sélectionnez GMP. Les tableaux de bord d'intégration correspondants s'affichent.

    Vue des tableaux de bord d'intégration
    Figure  : Tableaux de bord d'intégration

Pour en savoir plus, consultez Personnaliser la surveillance des applications.

Configurer les alertes Cloud Monitoring

Pour configurer des alertes Cloud Monitoring pour GKE Inference Gateway, procédez comme suit :

  1. Modifier le seuil dans les alertes Enregistrez l'exemple de fichier manifeste suivant sous le nom alerts.yaml :

    groups:
- name: gateway-api-inference-extension
  rules:
  - alert: HighInferenceRequestLatencyP99
    annotations:
      title: 'High latency (P99) for model {{ $labels.model_name }}'
      description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.'
    expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0
    for: 5m
    labels:
      severity: 'warning'
  - alert: HighInferenceErrorRate
    annotations:
      title: 'High error rate for model {{ $labels.model_name }}'
      description: 'The error rate for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 5% for 5 minutes.'
    expr: sum by (model_name) (rate(inference_model_request_error_total[5m])) / sum by (model_name) (rate(inference_model_request_total[5m])) > 0.05
    for: 5m
    labels:
      severity: 'critical'
      impact: 'availability'
  - alert: HighInferencePoolAvgQueueSize
    annotations:
      title: 'High average queue size for inference pool {{ $labels.name }}'
      description: 'The average number of requests pending in the queue for inference pool {{ $labels.name }} has been consistently above 50 for 5 minutes.'
    expr: inference_pool_average_queue_size > 50
    for: 5m
    labels:
      severity: 'critical'
      impact: 'performance'
  - alert: HighInferencePoolAvgKVCacheUtilization
    annotations:
      title: 'High KV cache utilization for inference pool {{ $labels.name }}'
      description: 'The average KV cache utilization for inference pool {{ $labels.name }} has been consistently above 90% for 5 minutes, indicating potential resource exhaustion.'
    expr: inference_pool_average_kv_cache_utilization > 0.9
    for: 5m
    labels:
      severity: 'critical'
      impact: 'resource_exhaustion'

  2. Pour créer des règles d'alerte, exécutez la commande suivante :

    gcloud alpha monitoring policies migrate --policies-from-prometheus-alert-rules-yaml=alerts.yaml

    De nouvelles règles d'alerte s'affichent sur la page Alertes.

Modifier les alertes

Vous trouverez la liste complète des dernières métriques disponibles dans le dépôt GitHub kubernetes-sigs/gateway-api-inference-extension. Vous pouvez également ajouter de nouvelles alertes au fichier manifeste en utilisant d'autres métriques.

Pour modifier les exemples d'alertes, prenez l'alerte suivante comme exemple :

  - alert: HighInferenceRequestLatencyP99
    annotations:
      title: 'High latency (P99) for model {{ $labels.model_name }}'
      description: 'The 99th percentile request duration for model {{ $labels.model_name }} and target model {{ $labels.target_model_name }} has been consistently above 10.0 seconds for 5 minutes.'
    expr: histogram_quantile(0.99, rate(inference_model_request_duration_seconds_bucket[5m])) > 10.0
    for: 5m
    labels:
      severity: 'warning'

L'alerte se déclenche si le 99e centile de la durée de la requête sur cinq minutes dépasse 10 secondes. Vous pouvez modifier la section expr de l'alerte pour ajuster le seuil en fonction de vos besoins.

Configurer la journalisation pour GKE Inference Gateway

La configuration de la journalisation pour GKE Inference Gateway fournit des informations détaillées sur les requêtes et les réponses, ce qui est utile pour le dépannage, l'audit et l'analyse des performances. Les journaux d'accès HTTP enregistrent chaque requête et réponse, y compris les en-têtes, les codes d'état et les codes temporels. Ce niveau de détail peut vous aider à identifier les problèmes, à trouver les erreurs et à comprendre le comportement de vos charges de travail d'inférence.

Pour configurer la journalisation pour GKE Inference Gateway, activez la journalisation des accès HTTP pour chacun de vos objets InferencePool.

  1. Enregistrez l'exemple de fichier manifeste suivant sous le nom logging-backend-policy.yaml :

    apiVersion: networking.gke.io/v1
kind: GCPBackendPolicy
metadata:
  name: logging-backend-policy
  namespace: NAMESPACE_NAME
spec:
  default:
    logging:
      enabled: true
      sampleRate: 500000
  targetRef:
    group: inference.networking.x-k8s.io
    kind: InferencePool
    name: INFERENCE_POOL_NAME

    Remplacez les éléments suivants :

    • NAMESPACE_NAME : nom de l'espace de noms dans lequel votre InferencePool est déployé.
    • INFERENCE_POOL_NAME : le nom du InferencePool.

  2. Appliquez l'exemple de fichier manifeste à votre cluster :

    kubectl apply -f logging-backend-policy.yaml

Après avoir appliqué ce fichier manifeste, GKE Inference Gateway active les journaux d'accès HTTP pour le InferencePool spécifié. Vous pouvez consulter ces journaux dans Cloud Logging. Les journaux incluent des informations détaillées sur chaque requête et réponse, telles que l'URL de la requête, les en-têtes, le code d'état de la réponse et la latence.

Configurer l'autoscaling

L'autoscaling ajuste l'allocation des ressources en réponse aux variations de charge, en maintenant les performances et l'efficacité des ressources en ajoutant ou en supprimant dynamiquement des pods en fonction de la demande. Pour GKE Inference Gateway, cela implique l'autoscaling horizontal des pods dans chaque InferencePool. L'autoscaler horizontal de pods (AHP) GKE fait évoluer automatiquement les pods en fonction des métriques du serveur de modèle, telles que KVCache Utilization. Cela garantit que le service d'inférence gère différents volumes de charges de travail et de requêtes tout en gérant efficacement l'utilisation des ressources.

Pour configurer des instances InferencePool afin qu'elles s'adaptent automatiquement en fonction des métriques produites par GKE Inference Gateway, procédez comme suit :

  1. Déployez un objet PodMonitoring dans le cluster pour collecter les métriques générées par GKE Inference Gateway. Pour en savoir plus, consultez Configurer l'observabilité.

  2. Déployez l'adaptateur de métriques personnalisées Stackdriver pour donner à AHP accès aux métriques :

    1. Enregistrez l'exemple de fichier manifeste suivant sous le nom adapter_new_resource_model.yaml :

      apiVersion: v1
kind: Namespace
metadata:
  name: custom-metrics
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-metrics-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-metrics-resource-reader
  namespace: custom-metrics
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics-resource-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-metrics-resource-reader
subjects:
- kind: ServiceAccount
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
---
apiVersion: apps/v1
kind: Deployment
metadata:
  run: custom-metrics-stackdriver-adapter
  k8s-app: custom-metrics-stackdriver-adapter
spec:
  replicas: 1
  selector:
    matchLabels:
      run: custom-metrics-stackdriver-adapter
      k8s-app: custom-metrics-stackdriver-adapter
  template:
    metadata:
      labels:
        run: custom-metrics-stackdriver-adapter
        k8s-app: custom-metrics-stackdriver-adapter
        kubernetes.io/cluster-service: "true"
    spec:
      serviceAccountName: custom-metrics-stackdriver-adapter
      containers:
      - image: gcr.io/gke-release/custom-metrics-stackdriver-adapter:v0.15.2-gke.1
        imagePullPolicy: Always
        name: pod-custom-metrics-stackdriver-adapter
        command:
        - /adapter
        - --use-new-resource-model=true
        - --fallback-for-container-metrics=true
        resources:
          limits:
            cpu: 250m
            memory: 200Mi
          requests:
            cpu: 250m
            memory: 200Mi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: custom-metrics-stackdriver-adapter
    k8s-app: custom-metrics-stackdriver-adapter
    kubernetes.io/cluster-service: 'true'
    kubernetes.io/name: Adapter
  name: custom-metrics-stackdriver-adapter
  namespace: custom-metrics
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 443
  selector:
    run: custom-metrics-stackdriver-adapter
    k8s-app: custom-metrics-stackdriver-adapter
  type: ClusterIP
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 100
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta1
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta2.custom.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: custom.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 200
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta2
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.external.metrics.k8s.io
spec:
  insecureSkipTLSVerify: true
  group: external.metrics.k8s.io
  groupPriorityMinimum: 100
  versionPriority: 100
  service:
    name: custom-metrics-stackdriver-adapter
    namespace: custom-metrics
  version: v1beta1
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: external-metrics-reader
rules:
- apiGroups:
  - "external.metrics.k8s.io"
  resources:
  - "*"
  verbs:
  - list
  - get
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: external-metrics-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: external-metrics-reader
subjects:
- kind: ServiceAccount
  name: horizontal-pod-autoscaler
  namespace: kube-system

    2. Appliquez l'exemple de fichier manifeste à votre cluster :

      kubectl apply -f adapter_new_resource_model.yaml

  3. Pour accorder à l'adaptateur l'autorisation de lire les métriques du projet, exécutez la commande suivante :

    $ PROJECT_ID=PROJECT_ID
$ PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
$ gcloud projects add-iam-policy-binding projects/PROJECT_ID \
  --role roles/monitoring.viewer \
  --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/$PROJECT_ID.svc.id.goog/subject/ns/custom-metrics/sa/custom-metrics-stackdriver-adapter

    Remplacez PROJECT_ID par l'ID de votre projet Trusted Cloud .

  4. Pour chaque InferencePool, déployez un AHP semblable à ce qui suit :

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: INFERENCE_POOL_NAME
  namespace: INFERENCE_POOL_NAMESPACE
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: INFERENCE_POOL_NAME
  minReplicas: MIN_REPLICAS
  maxReplicas: MAX_REPLICAS
  metrics:
  - type: External
    external:
      metric:
        name: prometheus.googleapis.com|inference_pool_average_kv_cache_utilization|gauge
        selector:
          matchLabels:
            metric.labels.name: INFERENCE_POOL_NAME
            resource.labels.cluster: CLUSTER_NAME
            resource.labels.namespace: INFERENCE_POOL_NAMESPACE
      target:
        type: AverageValue
        averageValue: TARGET_VALUE

    Remplacez les éléments suivants :

    • INFERENCE_POOL_NAME : le nom du InferencePool.
    • INFERENCE_POOL_NAMESPACE : espace de noms du InferencePool.
    • CLUSTER_NAME : nom du cluster.
    • MIN_REPLICAS : disponibilité minimale de InferencePool (capacité de référence). AHP maintient ce nombre de répliques lorsque l'utilisation est inférieure au seuil cible du AHP. Les charges de travail à haute disponibilité doivent définir cette valeur sur une valeur supérieure à 1 pour assurer une disponibilité continue en cas de perturbations des pods.
    • MAX_REPLICAS : valeur qui limite le nombre d'accélérateurs à attribuer aux charges de travail hébergées dans InferencePool. AHP n'augmentera pas le nombre d'instances répliquées au-delà de cette valeur. Pendant les périodes de trafic maximal, surveillez le nombre de répliques pour vous assurer que la valeur du champ MAX_REPLICAS offre une marge suffisante pour que la charge de travail puisse évoluer afin de maintenir les caractéristiques de performances choisies.
    • TARGET_VALUE : valeur représentant la cible choisie KV-Cache Utilization par serveur de modèle. Il s'agit d'un nombre compris entre 0 et 100, qui dépend fortement du serveur de modèle, du modèle, de l'accélérateur et des caractéristiques du trafic entrant. Vous pouvez déterminer cette valeur cible de manière expérimentale en effectuant des tests de charge et en traçant un graphique du débit par rapport à la latence. Sélectionnez une combinaison de débit et de latence dans le graphique, puis utilisez la valeur KV-Cache Utilization correspondante comme cible AHP. Vous devez ajuster et surveiller attentivement cette valeur pour obtenir les résultats prix/performances souhaités. Vous pouvez utiliser les recommandations d'inférence GKE pour déterminer automatiquement cette valeur.

Étapes suivantes