Diese Seite wurde von der Cloud Translation API übersetzt.

LLM mit mehreren GPUs in GKE bereitstellen

In dieser Anleitung wird gezeigt, wie Sie ein Large Language Model (LLM) mit mehreren GPUs in GKE bereitstellen und ausführen, um eine effiziente und skalierbare Inferenz zu ermöglichen. Sie erstellen einen GKE-Cluster, der mehrere L4-GPUs verwendet, und bereiten die Infrastruktur für die Bereitstellung eines der folgenden Modelle vor:

Je nach Datenformat des Modells variiert die erforderliche Anzahl der GPUs. In dieser Anleitung verwendet jedes Modell zwei L4-GPUs. Weitere Informationen finden Sie unter Anzahl der GPUs berechnen.

Diese Anleitung richtet sich an ML-Entwickler (Machine Learning), Plattformadministratoren und ‑operatoren sowie an Daten- und KI-Spezialisten, die daran interessiert sind, Kubernetes-Container-Orchestrierungsfunktionen zum Bereitstellen von LLMs zu nutzen. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die in Google Cloud-Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

Umgebung vorbereiten

Starten Sie in der Google Cloud Console eine Cloud Shell-Instanz:
Cloud Shell öffnen
Legen Sie die Standardumgebungsvariablen fest:
```
gcloud config set project PROJECT_ID
gcloud config set billing/quota_project PROJECT_ID
export PROJECT_ID=$(gcloud config get project)
export CONTROL_PLANE_LOCATION=us-central1
```
Ersetzen Sie PROJECT_ID durch Ihre Google Cloud Projekt-ID.

Hinweis: Wenn Ihre Cloud Shell-Instanz während der Ausführung der Anleitung getrennt wird, wiederholen Sie den vorherigen Schritt.

GKE-Cluster und -Knotenpool erstellen

Sie können Gemma auf GPUs in einem GKE-Cluster im Autopilot- oder Standardmodus bereitstellen. Für eine vollständig verwaltete Kubernetes-Umgebung empfehlen wir die Verwendung eines Autopilot-Clusters. Informationen zum Auswählen des GKE-Betriebsmodus, der für Ihre Arbeitslasten am besten geeignet ist, finden Sie unter GKE-Betriebsmodus auswählen.

Autopilot

Führen Sie in Cloud Shell den folgenden Befehl aus:
```
gcloud container clusters create-auto l4-demo \
  --project=${PROJECT_ID} \
  --location=${CONTROL_PLANE_LOCATION} \
  --release-channel=rapid
```
GKE erstellt einen Autopilot-Cluster mit CPU- und GPU-Knoten, wie von den bereitgestellten Arbeitslasten angefordert.

Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster:

gcloud container clusters get-credentials l4-demo --location=${CONTROL_PLANE_LOCATION}

Standard

Führen Sie in Cloud Shell den folgenden Befehl aus, um einen Standardcluster zu erstellen, der Workload Identity-Föderation für GKE verwendet:

gcloud container clusters create l4-demo \
  --location ${CONTROL_PLANE_LOCATION} \
  --workload-pool ${PROJECT_ID}.svc.id.goog \
  --enable-image-streaming \
  --node-locations=${CONTROL_PLANE_LOCATION}-a \
  --workload-pool=${PROJECT_ID}.svc.id.goog \
  --machine-type n2d-standard-4 \
  --num-nodes 1 --min-nodes 1 --max-nodes 5 \
  --release-channel=rapid

Die Erstellung eines Clusters kann einige Minuten dauern.

Führen Sie den folgenden Befehl aus, um einen Knotenpool für Ihren Cluster zu erstellen:
```
gcloud container node-pools create g2-standard-24 --cluster l4-demo \
  --location ${CONTROL_PLANE_LOCATION} \
  --accelerator type=nvidia-l4,count=2,gpu-driver-version=latest \
  --machine-type g2-standard-24 \
  --enable-autoscaling --enable-image-streaming \
  --num-nodes=0 --min-nodes=0 --max-nodes=3 \
  --node-locations ${CONTROL_PLANE_LOCATION}-a,${CONTROL_PLANE_LOCATION}-c \
  --spot
```
GKE erstellt die folgenden Ressourcen für das LLM:
- Ein öffentlicher Cluster der Google Kubernetes Engine (GKE) Standard Edition.
- Ein Knotenpool mit dem Maschinentyp g2-standard-24, der auf 0 Knoten herunterskaliert wurde. GPUs werden Ihnen erst in Rechnung gestellt, wenn Sie Pods starten, die GPUs anfordern. Dieser Knotenpool bietet Spot-VMs, die günstiger als Standard-VMs von Compute Engine sind und keine Verfügbarkeit versprechen. Sie können das Flag --spot aus diesem Befehl und den cloud.google.com/gke-spot-Knotenselektor in der text-generation-inference.yaml-Konfiguration entfernen, um On-Demand-VMs zu verwenden.

Konfigurieren Sie kubectl für die Kommunikation mit Ihrem Cluster:

gcloud container clusters get-credentials l4-demo --location=${CONTROL_PLANE_LOCATION}

Arbeitslast vorbereiten

In diesem Abschnitt wird gezeigt, wie Sie Ihre Arbeitslast abhängig vom Modell einrichten. In dieser Anleitung werden Kubernetes-Deployments verwendet, um das Modell bereitzustellen. Ein Deployment ist ein Kubernetes-API-Objekt, mit dem Sie mehrere Replikate von Pods ausführen können, die auf die Knoten in einem Cluster verteilt sind.

Llama 3 70b

Legen Sie die Standardumgebungsvariablen fest:
```
export HF_TOKEN=HUGGING_FACE_TOKEN
```
Ersetzen Sie HUGGING_FACE_TOKEN durch Ihr Hive-Face-Token.

Erstellen Sie ein Kubernetes-Secret für das HuggingFace-Token:

kubectl create secret generic l4-demo \
    --from-literal=HUGGING_FACE_TOKEN=${HF_TOKEN} \
    --dry-run=client -o yaml | kubectl apply -f -

Erstellen Sie das folgende text-generation-inference.yaml-Bereitstellungsmanifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm
  template:
    metadata:
      labels:
        app: llm
    spec:
      containers:
      - name: llm
        image: us-docker.pkg.dev/deeplearning-platform-release/gcr.io/huggingface-text-generation-inference-cu121.2-1.ubuntu2204.py310
        resources:
          requests:
            cpu: "10"
            memory: "60Gi"
            nvidia.com/gpu: "2"
          limits:
            cpu: "10"
            memory: "60Gi"
            nvidia.com/gpu: "2"
        env:
        - name: MODEL_ID
          value: meta-llama/Meta-Llama-3-70B-Instruct
        - name: NUM_SHARD
          value: "2"
        - name: MAX_INPUT_TOKENS
          value: "2048"
        - name: PORT
          value: "8080"
        - name: QUANTIZE
          value: bitsandbytes-nf4
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: l4-demo
              key: HUGGING_FACE_TOKEN
        volumeMounts:
          - mountPath: /dev/shm
            name: dshm
          # mountPath is set to /tmp as it's the path where the HUGGINGFACE_HUB_CACHE environment
          # variable in the TGI DLCs is set to instead of the default /data set within the TGI default image.
          # i.e. where the downloaded model from the Hub will be stored
          - mountPath: /tmp
            name: ephemeral-volume
      volumes:
        - name: dshm
          emptyDir:
              medium: Memory
        - name: ephemeral-volume
          ephemeral:
            volumeClaimTemplate:
              metadata:
                labels:
                  type: ephemeral
              spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: "premium-rwo"
                resources:
                  requests:
                    storage: 150Gi
      nodeSelector:
        cloud.google.com/gke-accelerator: "nvidia-l4"
        cloud.google.com/gke-spot: "true"

In diesem Manifest:

NUM_SHARD muss 2 sein, da für das Modell zwei NVIDIA L4-GPUs erforderlich sind.
QUANTIZE ist auf bitsandbytes-nf4 gesetzt, was bedeutet, dass das Modell mit 4 Bit anstelle von 32 Bit geladen wird. Dadurch kann GKE den benötigten GPU-Arbeitsspeicher reduzieren und die Inferenzgeschwindigkeit verbessern. Die Modellgenauigkeit kann jedoch sinken. Informationen zur Berechnung der angeforderten GPUs finden Sie unter Anzahl der GPUs berechnen.

Wenden Sie das Manifest an:

kubectl apply -f text-generation-inference.yaml

Die Ausgabe sieht in etwa so aus:

deployment.apps/llm created

Prüfen Sie den Status des Modells:

kubectl get deploy

Die Ausgabe sieht in etwa so aus:

NAME          READY   UP-TO-DATE   AVAILABLE   AGE
llm           1/1     1            1           20m

So rufen Sie die Logs des laufenden Deployments auf:

kubectl logs -l app=llm

Die Ausgabe sieht in etwa so aus:

{"timestamp":"2024-03-09T05:08:14.751646Z","level":"INFO","message":"Warming up model","target":"text_generation_router","filename":"router/src/main.rs","line_number":291}
{"timestamp":"2024-03-09T05:08:19.961136Z","level":"INFO","message":"Setting max batch total tokens to 133696","target":"text_generation_router","filename":"router/src/main.rs","line_number":328}
{"timestamp":"2024-03-09T05:08:19.961164Z","level":"INFO","message":"Connected","target":"text_generation_router","filename":"router/src/main.rs","line_number":329}
{"timestamp":"2024-03-09T05:08:19.961171Z","level":"WARN","message":"Invalid hostname, defaulting to 0.0.0.0","target":"text_generation_router","filename":"router/src/main.rs","line_number":343}

Mixtral 8x7b

Legen Sie die Standardumgebungsvariablen fest:
```
export HF_TOKEN=HUGGING_FACE_TOKEN
```
Ersetzen Sie HUGGING_FACE_TOKEN durch Ihr Hive-Face-Token.

Erstellen Sie ein Kubernetes-Secret für das HuggingFace-Token:

kubectl create secret generic l4-demo \
    --from-literal=HUGGING_FACE_TOKEN=${HF_TOKEN} \
    --dry-run=client -o yaml | kubectl apply -f -

Erstellen Sie das folgende text-generation-inference.yaml-Bereitstellungsmanifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm
  template:
    metadata:
      labels:
        app: llm
    spec:
      containers:
      - name: llm
        image: us-docker.pkg.dev/deeplearning-platform-release/gcr.io/huggingface-text-generation-inference-cu124.2-3.ubuntu2204.py311
        resources:
          requests:
            cpu: "5"
            memory: "40Gi"
            nvidia.com/gpu: "2"
          limits:
            cpu: "5"
            memory: "40Gi"
            nvidia.com/gpu: "2"
        env:
        - name: MODEL_ID
          value: mistralai/Mixtral-8x7B-Instruct-v0.1
        - name: NUM_SHARD
          value: "2"
        - name: PORT
          value: "8080"
        - name: QUANTIZE
          value: bitsandbytes-nf4
        - name: HUGGING_FACE_HUB_TOKEN
          valueFrom:
            secretKeyRef:
              name: l4-demo
              key: HUGGING_FACE_TOKEN          
        volumeMounts:
          - mountPath: /dev/shm
            name: dshm
          # mountPath is set to /tmp as it's the path where the HF_HOME environment
          # variable in the TGI DLCs is set to instead of the default /data set within the TGI default image.
          # i.e. where the downloaded model from the Hub will be stored
          - mountPath: /tmp
            name: ephemeral-volume
      volumes:
        - name: dshm
          emptyDir:
              medium: Memory
        - name: ephemeral-volume
          ephemeral:
            volumeClaimTemplate:
              metadata:
                labels:
                  type: ephemeral
              spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: "premium-rwo"
                resources:
                  requests:
                    storage: 100Gi
      nodeSelector:
        cloud.google.com/gke-accelerator: "nvidia-l4"
        cloud.google.com/gke-spot: "true"

In diesem Manifest:

NUM_SHARD muss 2 sein, da für das Modell zwei NVIDIA L4-GPUs erforderlich sind.
QUANTIZE ist auf bitsandbytes-nf4 gesetzt, was bedeutet, dass das Modell mit 4 Bit anstelle von 32 Bit geladen wird. Dadurch kann GKE den benötigten GPU-Arbeitsspeicher reduzieren und die Inferenzgeschwindigkeit verbessern. Dies kann jedoch die Modellgenauigkeit verringern. Informationen, wie Sie GPUs anfragen, finden Sie unter Anzahl der GPUs berechnen.

Wenden Sie das Manifest an:

kubectl apply -f text-generation-inference.yaml

Die Ausgabe sieht in etwa so aus:

deployment.apps/llm created

Prüfen Sie den Status des Modells:
```
watch kubectl get deploy
```
Wenn das Deployment bereit ist, sieht die Ausgabe in etwa so aus:
```
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
llm           1/1     1            1           10m
```
Geben Sie CTRL + C ein, um die Smartwatch zu beenden.

So rufen Sie die Logs des laufenden Deployments auf:

kubectl logs -l app=llm

Die Ausgabe sieht in etwa so aus:

{"timestamp":"2024-03-09T05:08:14.751646Z","level":"INFO","message":"Warming up model","target":"text_generation_router","filename":"router/src/main.rs","line_number":291}
{"timestamp":"2024-03-09T05:08:19.961136Z","level":"INFO","message":"Setting max batch total tokens to 133696","target":"text_generation_router","filename":"router/src/main.rs","line_number":328}
{"timestamp":"2024-03-09T05:08:19.961164Z","level":"INFO","message":"Connected","target":"text_generation_router","filename":"router/src/main.rs","line_number":329}
{"timestamp":"2024-03-09T05:08:19.961171Z","level":"WARN","message":"Invalid hostname, defaulting to 0.0.0.0","target":"text_generation_router","filename":"router/src/main.rs","line_number":343}

Falcon 40b

Erstellen Sie das folgende text-generation-inference.yaml-Bereitstellungsmanifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: llm
  template:
    metadata:
      labels:
        app: llm
    spec:
      containers:
      - name: llm
        image: us-docker.pkg.dev/deeplearning-platform-release/gcr.io/huggingface-text-generation-inference-cu121.1-4.ubuntu2204.py310
        resources:
          requests:
            cpu: "10"
            memory: "60Gi"
            nvidia.com/gpu: "2"
          limits:
            cpu: "10"
            memory: "60Gi"
            nvidia.com/gpu: "2"
        env:
        - name: MODEL_ID
          value: tiiuae/falcon-40b-instruct
        - name: NUM_SHARD
          value: "2"
        - name: PORT
          value: "8080"
        - name: QUANTIZE
          value: bitsandbytes-nf4
        volumeMounts:
          - mountPath: /dev/shm
            name: dshm
          # mountPath is set to /data as it's the path where the HUGGINGFACE_HUB_CACHE environment
          # variable points to in the TGI container image i.e. where the downloaded model from the Hub will be
          # stored
          - mountPath: /data
            name: ephemeral-volume
      volumes:
        - name: dshm
          emptyDir:
              medium: Memory
        - name: ephemeral-volume
          ephemeral:
            volumeClaimTemplate:
              metadata:
                labels:
                  type: ephemeral
              spec:
                accessModes: ["ReadWriteOnce"]
                storageClassName: "premium-rwo"
                resources:
                  requests:
                    storage: 175Gi
      nodeSelector:
        cloud.google.com/gke-accelerator: "nvidia-l4"
        cloud.google.com/gke-spot: "true"

In diesem Manifest:

NUM_SHARD muss 2 sein, da für das Modell zwei NVIDIA L4-GPUs erforderlich sind.
QUANTIZE ist auf bitsandbytes-nf4 gesetzt, was bedeutet, dass das Modell mit 4 Bit anstelle von 32 Bit geladen wird. Dadurch kann GKE den benötigten GPU-Arbeitsspeicher reduzieren und die Inferenzgeschwindigkeit verbessern. Die Modellgenauigkeit kann jedoch sinken. Informationen, wie Sie GPUs anfragen, finden Sie unter Anzahl der GPUs berechnen.

Wenden Sie das Manifest an:

kubectl apply -f text-generation-inference.yaml

Die Ausgabe sieht in etwa so aus:

deployment.apps/llm created

Prüfen Sie den Status des Modells:
```
watch kubectl get deploy
```
Wenn die Bereitstellung abgeschlossen ist, sieht die Ausgabe in etwa so aus:
```
NAME          READY   UP-TO-DATE   AVAILABLE   AGE
llm           1/1     1            1           10m
```
Geben Sie CTRL + C ein, um die Smartwatch zu beenden.

So rufen Sie die Logs des laufenden Deployments auf:

kubectl logs -l app=llm

Die Ausgabe sieht in etwa so aus:

{"timestamp":"2024-03-09T05:08:14.751646Z","level":"INFO","message":"Warming up model","target":"text_generation_router","filename":"router/src/main.rs","line_number":291}
{"timestamp":"2024-03-09T05:08:19.961136Z","level":"INFO","message":"Setting max batch total tokens to 133696","target":"text_generation_router","filename":"router/src/main.rs","line_number":328}
{"timestamp":"2024-03-09T05:08:19.961164Z","level":"INFO","message":"Connected","target":"text_generation_router","filename":"router/src/main.rs","line_number":329}
{"timestamp":"2024-03-09T05:08:19.961171Z","level":"WARN","message":"Invalid hostname, defaulting to 0.0.0.0","target":"text_generation_router","filename":"router/src/main.rs","line_number":343}

Service vom Typ ClusterIP erstellen

Machen Sie Ihre Pods intern im Cluster verfügbar, damit sie von anderen Anwendungen erkannt und auf sie zugegriffen werden kann.

Erstellen Sie das folgende llm-service.yaml-Manifest:

apiVersion: v1
kind: Service
metadata:
  name: llm-service
spec:
  selector:
    app: llm
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Wenden Sie das Manifest an:
```
kubectl apply -f llm-service.yaml
```

Chatoberfläche bereitstellen

Webanwendung mit Gradio erstellen, um mit Ihrem Modell zu interagieren. Gradio ist eine Python-Bibliothek mit einem ChatInterface-Wrapper, der Benutzeroberflächen für Chatbots erstellt.

Llama 3 70b

Erstellen Sie eine Datei mit dem Namen gradio.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gradio
  labels:
    app: gradio
spec:
  strategy:
    type: Recreate
  replicas: 1
  selector:
    matchLabels:
      app: gradio
  template:
    metadata:
      labels:
        app: gradio
    spec:
      containers:
      - name: gradio
        image: us-docker.pkg.dev/google-samples/containers/gke/gradio-app:v1.0.4
        resources:
          requests:
            cpu: "512m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "512Mi"
        env:
        - name: CONTEXT_PATH
          value: "/generate"
        - name: HOST
          value: "http://llm-service"
        - name: LLM_ENGINE
          value: "tgi"
        - name: MODEL_ID
          value: "meta-llama/Meta-Llama-3-70B-Instruct"
        - name: USER_PROMPT
          value: "<|begin_of_text|><|start_header_id|>user<|end_header_id|> prompt <|eot_id|><|start_header_id|>assistant<|end_header_id|>"
        - name: SYSTEM_PROMPT
          value: "prompt <|eot_id|>"
        ports:
        - containerPort: 7860
---
apiVersion: v1
kind: Service
metadata:
  name: gradio-service
spec:
  type: LoadBalancer
  selector:
    app: gradio
  ports:
  - port: 80
    targetPort: 7860

Wenden Sie das Manifest an:
```
kubectl apply -f gradio.yaml
```

Suchen Sie die externe IP-Adresse des Dienstes:

kubectl get svc

Die Ausgabe sieht in etwa so aus:

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
gradio-service   LoadBalancer   10.24.29.197   34.172.115.35   80:30952/TCP   125m

Kopieren Sie die externe IP-Adresse aus der Spalte EXTERNAL-IP.
Rufen Sie die Modellschnittstelle über Ihren Webbrowser auf, indem Sie die externe IP-Adresse mit dem freigegebenen Port verwenden:
```
http://EXTERNAL_IP
```

Mixtral 8x7b

Erstellen Sie eine Datei mit dem Namen gradio.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gradio
  labels:
    app: gradio
spec:
  strategy:
    type: Recreate
  replicas: 1
  selector:
    matchLabels:
      app: gradio
  template:
    metadata:
      labels:
        app: gradio
    spec:
      containers:
      - name: gradio
        image: us-docker.pkg.dev/google-samples/containers/gke/gradio-app:v1.0.4
        resources:
          requests:
            cpu: "512m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "512Mi"
        env:
        - name: CONTEXT_PATH
          value: "/generate"
        - name: HOST
          value: "http://llm-service"
        - name: LLM_ENGINE
          value: "tgi"
        - name: MODEL_ID
          value: "mixtral-8x7b"
        - name: USER_PROMPT
          value: "[INST] prompt [/INST]"
        - name: SYSTEM_PROMPT
          value: "prompt"
        ports:
        - containerPort: 7860
---
apiVersion: v1
kind: Service
metadata:
  name: gradio-service
spec:
  type: LoadBalancer
  selector:
    app: gradio
  ports:
  - port: 80
    targetPort: 7860

Wenden Sie das Manifest an:
```
kubectl apply -f gradio.yaml
```

Suchen Sie die externe IP-Adresse des Dienstes:

kubectl get svc

Die Ausgabe sieht in etwa so aus:

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
gradio-service   LoadBalancer   10.24.29.197   34.172.115.35   80:30952/TCP   125m

Kopieren Sie die externe IP-Adresse aus der Spalte EXTERNAL-IP.
Rufen Sie die Modellschnittstelle über Ihren Webbrowser auf, indem Sie die externe IP-Adresse mit dem freigegebenen Port verwenden:
```
http://EXTERNAL_IP
```

Falcon 40b

Erstellen Sie eine Datei mit dem Namen gradio.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gradio
  labels:
    app: gradio
spec:
  strategy:
    type: Recreate
  replicas: 1
  selector:
    matchLabels:
      app: gradio
  template:
    metadata:
      labels:
        app: gradio
    spec:
      containers:
      - name: gradio
        image: us-docker.pkg.dev/google-samples/containers/gke/gradio-app:v1.0.4
        resources:
          requests:
            cpu: "512m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "512Mi"
        env:
        - name: CONTEXT_PATH
          value: "/generate"
        - name: HOST
          value: "http://llm-service"
        - name: LLM_ENGINE
          value: "tgi"
        - name: MODEL_ID
          value: "falcon-40b-instruct"
        - name: USER_PROMPT
          value: "User: prompt"
        - name: SYSTEM_PROMPT
          value: "Assistant: prompt"
        ports:
        - containerPort: 7860
---
apiVersion: v1
kind: Service
metadata:
  name: gradio-service
spec:
  type: LoadBalancer
  selector:
    app: gradio
  ports:
  - port: 80
    targetPort: 7860

Wenden Sie das Manifest an:
```
kubectl apply -f gradio.yaml
```

Suchen Sie die externe IP-Adresse des Dienstes:

kubectl get svc

Die Ausgabe sieht in etwa so aus:

NAME             TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
gradio-service   LoadBalancer   10.24.29.197   34.172.115.35   80:30952/TCP   125m

Kopieren Sie die externe IP-Adresse aus der Spalte EXTERNAL-IP.
Rufen Sie die Modellschnittstelle über Ihren Webbrowser auf, indem Sie die externe IP-Adresse mit dem freigegebenen Port verwenden:
```
http://EXTERNAL_IP
```

Anzahl der GPUs berechnen

Die Anzahl der GPUs hängt vom Wert der Konfiguration QUANTIZE ab. In dieser Anleitung ist QUANTIZE auf bitsandbytes-nf4 gesetzt, was bedeutet, dass das Modell in 4 Bit geladen wird.

Ein Parametermodell mit 70 Milliarden Attributen würde mindestens 40 GB GPU-Arbeitsspeicher benötigen, was 70 Milliarden Mal 4 Bit (70 Milliarden x 4 Bits= 35 GB) entspricht und 5 GB Overhead berücksichtigt. In diesem Fall hätte eine einzelne L4-GPU nicht genügend Arbeitsspeicher. Daher werden in den Beispielen dieser Anleitung zwei L4-GPUs des Arbeitsspeichers (2 x 24 = 48 GB) verwendet. Diese Konfiguration ist ausreichend, um Falcon 40b oder Llama 3 70b in L4-GPUs auszuführen.

LLM mit mehreren GPUs in GKE bereitstellen Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Umgebung vorbereiten

GKE-Cluster und -Knotenpool erstellen

Autopilot

Standard

Arbeitslast vorbereiten

Llama 3 70b

Mixtral 8x7b

Falcon 40b

Service vom Typ ClusterIP erstellen

Chatoberfläche bereitstellen

Llama 3 70b

Mixtral 8x7b

Falcon 40b

Anzahl der GPUs berechnen

LLM mit mehreren GPUs in GKE bereitstellen