Personalizzare la configurazione di GKE Inference Gateway

Questa pagina descrive come personalizzare il deployment di GKE Inference Gateway.

Questa pagina è rivolta agli specialisti di networking responsabili della gestione dell'infrastruttura GKE e agli amministratori della piattaforma che gestiscono i carichi di lavoro AI.

Per gestire e ottimizzare i carichi di lavoro di inferenza, configura le funzionalità avanzate di GKE Inference Gateway.

Comprendi e configura le seguenti funzionalità avanzate:

Configurare i controlli di sicurezza e protezione dell'AI

GKE Inference Gateway si integra con Model Armor per eseguire controlli di sicurezza su prompt e risposte per le applicazioni che utilizzano modelli linguistici di grandi dimensioni (LLM). Questa integrazione fornisce un ulteriore livello di applicazione della sicurezza a livello di infrastruttura che integra le misure di sicurezza a livello di applicazione. Ciò consente l'applicazione centralizzata dei criteri a tutto il traffico LLM.

Il seguente diagramma illustra l'integrazione di Model Armor con GKE Inference Gateway su un cluster GKE:

Integrazione di Google Cloud Model Armor in un cluster GKE
Figura: integrazione di Model Armor in un cluster GKE

Per configurare i controlli di sicurezza dell'AI:

  1. Assicurati che siano soddisfatti i seguenti prerequisiti:

    1. Abilita il servizio Model Armor nel tuo progetto Trusted Cloud by S3NS .
    2. Crea i template Model Armor utilizzando la console Model Armor, Google Cloud CLI o l'API.

  2. Assicurati di aver già creato un modello Model Armor denominato my-model-armor-template-name-id.

  3. Per configurare GCPTrafficExtension, segui questi passaggi:

    1. Salva il seguente manifest di esempio come 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'

      Sostituisci quanto segue:

      • GATEWAY_NAME: il nome del gateway.
      • MODEL_ARMOR_TEMPLATE_NAME: il nome del tuo template Model Armor.

      Il file gcp-traffic-extension.yaml include le seguenti impostazioni:

      • targetRefs: specifica il gateway a cui si applica questa estensione.
      • extensionChains: definisce una catena di estensioni da applicare al traffico.
      • matchCondition: definisce le condizioni in cui vengono applicate le estensioni.
      • extensions: definisce le estensioni da applicare.
      • supportedEvents: specifica gli eventi durante i quali viene richiamata l'estensione.
      • timeout: specifica il timeout per l'estensione.
      • googleAPIServiceName: specifica il nome del servizio per l'estensione.
      • metadata: specifica i metadati dell'estensione, incluse le impostazioni di sanificazione di extensionPolicy e prompt o risposte.

    2. Applica il manifest di esempio al cluster:

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

Dopo aver configurato i controlli di sicurezza dell'AI e averli integrati con il gateway, Model Armor filtra automaticamente i prompt e le risposte in base alle regole definite.

Configura l'osservabilità

GKE Inference Gateway fornisce informazioni dettagliate su integrità, prestazioni e comportamento dei tuoi carichi di lavoro di inferenza. In questo modo puoi identificare e risolvere i problemi, ottimizzare l'utilizzo delle risorse e garantire l'affidabilità delle tue applicazioni.

Trusted Cloud by S3NS fornisce le seguenti dashboard di Cloud Monitoring che offrono l'osservabilità dell'inferenza per GKE Inference Gateway:

  • Dashboard di GKE Inference Gateway: fornisce metriche fondamentali per la pubblicazione di LLM, come throughput di richieste e token, latenza, errori e utilizzo della cache per InferencePool. Per visualizzare l'elenco completo delle metriche di GKE Inference Gateway disponibili, consulta Metriche esposte.
  • Dashboard del server modello: fornisce una dashboard per gli indicatori aurei del server modello. In questo modo puoi monitorare il carico e le prestazioni dei server dei modelli, ad esempio KVCache Utilization e Queue length. In questo modo puoi monitorare il carico e il rendimento dei server dei modelli.
  • Dashboard del bilanciatore del carico: riporta le metriche del bilanciatore del carico, ad esempio le richieste al secondo, la latenza di gestione delle richieste end-to-end e i codici di stato richiesta-risposta. Queste metriche ti aiutano a comprendere le prestazioni del servizio di gestione delle richieste end-to-end e a identificare gli errori.
  • Metriche Data Center GPU Manager (DCGM): fornisce metriche dalle GPU NVIDIA, ad esempio le prestazioni e l'utilizzo delle GPU NVIDIA. Puoi configurare le metriche NVIDIA Data Center GPU Manager (DCGM) in Cloud Monitoring. Per ulteriori informazioni, vedi Raccogliere e visualizzare le metriche DCGM.

Visualizza la dashboard di GKE Inference Gateway

Per visualizzare la dashboard di GKE Inference Gateway, segui questi passaggi:

  1. Nella console Trusted Cloud , vai alla pagina Monitoring.

    Vai a Monitoring

  2. Nel riquadro di navigazione, seleziona Dashboard.

  3. Nella sezione Integrazioni, seleziona GMP.

  4. Nella pagina Modelli di dashboard di Cloud Monitoring, cerca "Gateway".

  5. Visualizza la dashboard di GKE Inference Gateway.

In alternativa, puoi seguire le istruzioni riportate in Dashboard di monitoraggio.

Configurare la dashboard di osservabilità del server di modelli

Per raccogliere indicatori chiave da ogni server di modelli e capire cosa contribuisce al rendimento di GKE Inference Gateway, puoi configurare il monitoraggio automatico per i tuoi server di modelli. Sono inclusi server di modelli come i seguenti:

Per visualizzare le dashboard di integrazione, segui questi passaggi:

  1. Raccogli le metriche dal server del modello.

  2. Nella console Trusted Cloud , vai alla pagina Monitoring.

    Vai a Monitoring

  3. Nel riquadro di navigazione, seleziona Dashboard.

  4. In Integrazioni, seleziona GMP. Vengono visualizzate le dashboard di integrazione corrispondenti.

    Una visualizzazione delle dashboard di integrazione
    Figura: dashboard di integrazione

Per ulteriori informazioni, vedi Personalizzare il monitoraggio per le applicazioni.

Configurare gli avvisi di Cloud Monitoring

Per configurare gli avvisi di Cloud Monitoring per GKE Inference Gateway, segui questi passaggi:

  1. Modifica la soglia negli avvisi. Salva il seguente manifest di esempio come 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. Per creare criteri di avviso, esegui questo comando:

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

    Nella pagina Avvisi vengono visualizzate nuove policy di avviso.

Modificare gli avvisi

Puoi trovare l'elenco completo delle metriche più recenti disponibili nel repository GitHub kubernetes-sigs/gateway-api-inference-extension e puoi aggiungere nuovi avvisi al manifest utilizzando altre metriche.

Per apportare modifiche agli avvisi di esempio, prendi in considerazione il seguente avviso:

  - 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'avviso viene attivato se il 99° percentile della durata della richiesta in 5 minuti è superiore a 10 secondi. Puoi modificare la sezione expr dell'avviso per regolare la soglia in base ai tuoi requisiti.

Configura la registrazione per GKE Inference Gateway

La configurazione della registrazione per GKE Inference Gateway fornisce informazioni dettagliate su richieste e risposte, utili per la risoluzione dei problemi, il controllo e l'analisi delle prestazioni. I log di accesso HTTP registrano ogni richiesta e risposta, incluse intestazioni, codici di stato e timestamp. Questo livello di dettaglio può aiutarti a identificare i problemi, trovare gli errori e comprendere il comportamento dei tuoi carichi di lavoro di inferenza.

Per configurare la registrazione per GKE Inference Gateway, abilita la registrazione degli accessi HTTP per ciascuno dei tuoi oggetti InferencePool.

  1. Salva il seguente manifest di esempio come 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

    Sostituisci quanto segue:

    • NAMESPACE_NAME: il nome dello spazio dei nomi in cui è stato eseguito il deployment di InferencePool.
    • INFERENCE_POOL_NAME: il nome di InferencePool.

  2. Applica il manifest di esempio al cluster:

    kubectl apply -f logging-backend-policy.yaml

Dopo aver applicato questo manifest, GKE Inference Gateway abilita i log di accesso HTTP per il InferencePool specificato. Puoi visualizzare questi log in Cloud Logging. I log includono informazioni dettagliate su ogni richiesta e risposta, come l'URL della richiesta, le intestazioni, il codice di stato della risposta e la latenza.

Configura scalabilità automatica

La scalabilità automatica regola l'allocazione delle risorse in risposta alle variazioni di carico, mantenendo le prestazioni e l'efficienza delle risorse aggiungendo o rimuovendo dinamicamente i pod in base alla domanda. Per GKE Inference Gateway, ciò comporta la scalabilità automatica orizzontale dei pod in ogni InferencePool. Horizontal Pod Autoscaler (HPA) di GKE esegue la scalabilità automatica dei pod in base alle metriche del server di modelli come KVCache Utilization. Ciò garantisce che il servizio di inferenza gestisca diversi carichi di lavoro e volumi di query gestendo in modo efficiente l'utilizzo delle risorse.

Per configurare le istanze InferencePool in modo che vengano scalate automaticamente in base alle metriche prodotte da GKE Inference Gateway, segui questi passaggi:

  1. Esegui il deployment di un oggetto PodMonitoring nel cluster per raccogliere le metriche prodotte da GKE Inference Gateway. Per saperne di più, consulta Configurare l'osservabilità.

  2. Esegui il deployment dell'adattatore Stackdriver delle metriche personalizzate per consentire ad HPA di accedere alle metriche:

    1. Salva il seguente manifest di esempio come 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. Applica il manifest di esempio al cluster:

      kubectl apply -f adapter_new_resource_model.yaml

  3. Per concedere all'adattatore le autorizzazioni per leggere le metriche dal progetto, esegui questo comando:

    $ 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

    Sostituisci PROJECT_ID con l'ID del tuo progetto Trusted Cloud .

  4. Per ogni InferencePool, esegui il deployment di un HPA simile al seguente:

    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

    Sostituisci quanto segue:

    • INFERENCE_POOL_NAME: il nome di InferencePool.
    • INFERENCE_POOL_NAMESPACE: lo spazio dei nomi di InferencePool.
    • CLUSTER_NAME: il nome del cluster.
    • MIN_REPLICAS: la disponibilità minima di InferencePool (capacità di base). HPA mantiene questo numero di repliche quando l'utilizzo è inferiore alla soglia target di HPA. I carichi di lavoro ad alta disponibilità devono impostare questo valore su un valore superiore a 1 per garantire la disponibilità continua durante le interruzioni dei pod.
    • MAX_REPLICAS: il valore che vincola il numero di acceleratori che devono essere assegnati ai carichi di lavoro ospitati in InferencePool. HPA non aumenterà il numero di repliche oltre questo valore. Durante i periodi di picco del traffico, monitora il numero di repliche per assicurarti che il valore del campo MAX_REPLICAS fornisca un margine sufficiente in modo che il workload possa scalare per mantenere le caratteristiche di rendimento del workload scelte.
    • TARGET_VALUE: il valore che rappresenta il KV-Cache Utilization target scelto per il server del modello. Si tratta di un numero compreso tra 0 e 100 e dipende molto dal server del modello, dal modello, dall'acceleratore e dalle caratteristiche del traffico in entrata. Puoi determinare questo valore target in modo sperimentale tramite test di carico e tracciando un grafico del throughput rispetto alla latenza. Seleziona una combinazione di velocità effettiva e latenza dal grafico e utilizza il valore KV-Cache Utilization corrispondente come target HPA. Devi modificare e monitorare attentamente questo valore per ottenere i risultati di prezzo/rendimento che hai scelto. Puoi utilizzare i suggerimenti per l'inferenza di GKE per determinare automaticamente questo valore.

Passaggi successivi