Serve Mistral Small using GPUs on GKE with vLLM

To serve Mistral large language models (LLMs) on Google Kubernetes Engine (GKE) with vLLM framework using GPUs, you must provision a GKE cluster with supported accelerators, such as NVIDIA H100 GPUs.

To serve Mistral small 4 model, the prebuilt vLLM container is configured to load model weights. Weights will be loaded from Cloud Storage buckets (specified by the --model argument).

Once the weights are loaded, the vLLM container exposes an OpenAI-compatible API endpoint for high-throughput inference.

This tutorial is intended for Machine learning (ML) engineers, Platform admins and operators, and for Data and AI specialists who are interested in using Kubernetes container orchestration capabilities for serving AI/ML workloads on H100 GPU hardware.

Before reading this page, ensure that you're familiar with the following:

Objectives

This tutorial provides a foundation for understanding and exploring practical LLM deployment for inference in a managed Kubernetes environment.

  1. Prepare your environment with a GKE cluster in Autopilot mode.
  2. Deploy a vLLM container to your cluster.
  3. Use vLLM to serve the Mistral model through curl interface.

Before you begin

  • In the Cloud de Confiance console, on the project selector page, select or create a Cloud de Confiance project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • Verify that billing is enabled for your Cloud de Confiance project.

  • Enable the required API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  • Make sure that you have the following role or roles on the project: roles/container.admin, roles/iam.serviceAccountAdmin

    Check for the roles

    1. In the Cloud de Confiance console, go to the IAM page.

      Go to IAM
    2. Select the project.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Cloud de Confiance console, go to the IAM page.

      Go to IAM
    2. Select the project.
    3. Click Grant access.

    4. In the New principals field, enter your user identifier. This is typically the identifier for a user in a workforce identity pool. For details, see Represent workforce pool users in IAM policies, or contact your administrator.

    5. Click Select a role, then search for the role.
    6. To grant additional roles, click Add another role and add each additional role.
    7. Click Save.

Prepare your environment

In this tutorial, you will use kubectl and gcloud CLI to manage resources hosted on Cloud de Confiance by S3NS. You can authorize with gcloud CLI to access Cloud de Confiance by S3NS.

To set up your environment with gcloud CLI, follow these steps:

  1. Set the default environment variables in gcloud CLI:

    gcloud config set project PROJECT_ID
gcloud config set billing/quota_project PROJECT_ID
export PROJECT_ID=$(gcloud config get project)
export REGION=u-france-east1
export CLUSTER_NAME=CLUSTER_NAME
export GSA_NAME=GSA_NAME
export KSA_NAME=KSA_NAME
export NAMESPACE=NAMESPACE
export PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format="value(projectNumber)")
export MODEL_BUCKET_NAME=MODEL_BUCKET_NAME

    Replace the following values:

    • PROJECT_ID: your Cloud de Confiance project ID.
    • REGION: u-france-east1 region that supports H100 GPU. You can find which region has which GPUs available.
    • CLUSTER_NAME: the name of your cluster.
    • GSA_NAME: the name for the Google Service Account, for example, mistral-small-gsa.
    • KSA_NAME: the name for the Kubernetes ServiceAccount, for example, mistral-small-ksa.
    • NAMESPACE: the Kubernetes namespace, for example, default.
    • MODEL_BUCKET_NAME: the name of Cloud Storage bucket where model weights will be stored. It can be the same name as the selected model, such as mistral-small-4-119b-weights.

Create and configure Cloud de Confiance resources

Follow these instructions to create the required resources.

Create a GKE cluster and node pool

You can serve Mistral on GPUs in a GKE Autopilot cluster. Autopilot cluster provides a fully managed Kubernetes experience.

In gcloud CLI, run the following command:

gcloud container clusters create-auto CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=REGION \
    --release-channel=rapid

Replace the following values:

  • PROJECT_ID: your Cloud de Confiance project ID.
  • CLUSTER_NAME: the name of your cluster.
  • REGION: the region where your cluster is located.

GKE creates an Autopilot cluster with CPU and GPU nodes as requested by the deployed workloads.

Create a Cloud Storage bucket

  1. In gcloud CLI, run the following command:

    gcloud storage buckets create gs://${MODEL_BUCKET_NAME} \
  --project=${PROJECT_ID} \
  --location=${REGION} \
  --uniform-bucket-level-access

    This creates a Cloud Storage bucket to store the model files you download from Hugging Face.

  2. Download and Upload Model Weights:

    You need to obtain the Mistral small model weights for the versions you intend to serve (e.g. from Hugging Face or other official sources). Organize the downloaded files locally into directories. For example:

    • ./mistral-small-4-119b-weights-local/ (containing all files for the Mistral small model)

    Upload these directories to your Cloud Storage bucket with the specific prefixes expected by the deployment manifests:

    # Upload files for the mistral-small model
gcloud storage cp --recursive ./mistral-small-4-119b-weights-local/* gs://${MODEL_BUCKET_NAME}

    This command structure ensures the model files are located at paths like gs://${MODEL_BUCKET_NAME}/config.json, etc.

Configure Workload Identity Federation for GKE for Cloud Storage Access

To allow your Kubernetes pods to securely access the Cloud Storage bucket containing the model weights, you'll configure GKE Workload Identity Federation for GKE.

  1. Create the Google Service Account (GSA):

    gcloud iam service-accounts create ${GSA_NAME} \
  --project=${PROJECT_ID}

  2. Determine and Export GSA Email:

    The email format depends on whether your ${PROJECT_ID} is domain-scoped (contains a colon).

    if [[ $PROJECT_ID == *:* ]]; then
  DOMAIN=$(echo $PROJECT_ID | cut -d: -f1)
  PROJ_NAME=$(echo $PROJECT_ID | cut -d: -f2)
  export GSA_EMAIL="${GSA_NAME}@${PROJ_NAME}.${DOMAIN}.s3ns.iam.gserviceaccount.com"
else
  export GSA_EMAIL="${GSA_NAME}@${PROJECT_ID}.s3ns.iam.gserviceaccount.com"
fi
  echo "Using GSA Email: ${GSA_EMAIL}"

  3. Create the Kubernetes Service Account (KSA):

    This KSA is used in your deployment manifest.

    kubectl create serviceaccount ${KSA_NAME} --namespace ${NAMESPACE}

    Run the following command to verify creation

    kubectl get serviceaccounts --namespace ${NAMESPACE}

  4. Annotate the KSA to Link it to the GSA:

    This annotation tells GKE which GSA the KSA can impersonate.

    kubectl annotate serviceaccount ${KSA_NAME} \
  --namespace ${NAMESPACE} \
  iam.gke.io/gcp-service-account=${GSA_EMAIL}

  5. Grant the KSA Permission to Impersonate the GSA:

    This IAM binding on the GSA allows the KSA to act as the GSA.

    if [[ $PROJECT_ID == *:* ]]; then
  DOMAIN=$(echo $PROJECT_ID | cut -d: -f1)
  PROJ_NAME=$(echo $PROJECT_ID | cut -d: -f2)
  export WI_MEMBER="serviceAccount:${PROJ_NAME}.${DOMAIN}.s3ns.svc.id.goog[${NAMESPACE}/${KSA_NAME}]"
else
  export WI_MEMBER="serviceAccount:${PROJECT_ID}.s3ns.svc.id.goog[${NAMESPACE}/${KSA_NAME}]"
fi

gcloud iam service-accounts add-iam-policy-binding ${GSA_EMAIL} \
  --role roles/iam.workloadIdentityUser \
  --member="${WI_MEMBER}" \
  --project=${PROJECT_ID}

  6. Grant the GSA permission to read from the Bucket:

    Grant the GSA the storage.objectViewer role on the bucket. 

    gcloud storage buckets add-iam-policy-binding gs://${MODEL_BUCKET_NAME} \
  --member="serviceAccount:${GSA_EMAIL}" \
  --role="roles/storage.objectViewer" \
  --project=${PROJECT_ID}

Deploy Mistral small 4 model on vLLM

To deploy Mistral small 4 model, create Cloud Storage buckets for each model to store model weights, and apply a Kubernetes Deployment manifest for your selected model size. A Deployment is a Kubernetes API object that lets you run multiple replicas of Pods that are distributed among the nodes in a cluster..

Procedure

Applying this manifest pulls the vLLM container image, requests an NVIDIA GPU, and automatically connects to the model weights from Cloud Storage buckets to start the vLLM inference engine.

Mistral Small

Follow these instructions to deploy the Mistral Small instruction tuned model.

  1. Create the following vllm-mistral-small.yaml manifest:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: a3-edgegpu-8g-nolssd
spec:
  priorities:
  - machineType: a3-edgegpu-8g-nolssd
    gpu:
      count: 8
      type: nvidia-h100-80gb
  nodePoolAutoCreation:
    enabled: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-mistral-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mistral-server
  template:
    metadata:
      labels:
        app: mistral-server
        ai.gke.io/model: mistral-small-4-119b-weights
        ai.gke.io/inference-server: vllm
        examples.ai.gke.io/source: user-guide
    spec:
      containers:
      - name: inference-server
        image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:gemma4
        resources:
          requests:
            cpu: "48"
            memory: "200Gi"
            ephemeral-storage: "250Gi"
            nvidia.com/gpu: "2"
          limits:
            cpu: "48"
            memory: "200Gi"
            ephemeral-storage: "250Gi"
            nvidia.com/gpu: "2"
        command: ["./entrypoint.sh"] # Use the image's entrypoint
        args:
        - "python"
        - "-m"
        - "vllm.entrypoints.api_server"
        - "--host=0.0.0.0"
        - "--port=8080"
        - "--model=gs://mistral-small-4-119b-weights" # YOUR Cloud Storage PATH
        - "--tensor-parallel-size=2"
        - "--enable-log-requests"
        - "--enable-chunked-prefill"
        - "--enable-prefix-caching"
        - "--enable-auto-tool-choice"
        - "--generation-config=auto"
        - "--tool-call-parser=mistral"
        - "--dtype=bfloat16"
        - "--max-num-seqs=256"
        - "--max-model-len=8192"
        - "--gpu-memory-utilization=0.90"
        - "--reasoning-parser=mistral"
        - "--trust-remote-code"
        ports:
        - containerPort: 8080
        env:
        - name: GOOGLE_CLOUD_UNIVERSE_DOMAIN
          value: ""
        - name: CLOUDSDK_CORE_UNIVERSE_DOMAIN
          value: ""
        - name: GCS_URI_ARG_KEY
          value: "model"
        - name: GCS_URI_ENV_KEY
          value: "AIP_STORAGE_URI"
        - name: LORA_ADAPTER_ARG_KEY
          value: "lora-modules"
        - name: HF_HUB_ENABLE_HF_TRANSFER
          value: "1"
        volumeMounts:
        - mountPath: /dev/shm
          name: dshm
      volumes:
      - name: dshm
        emptyDir:
          medium: Memory
      nodeSelector:
        cloud.google.com/compute-class: a3-edgegpu-8g-nolssd
---
apiVersion: v1
kind: Service
metadata:
  name: llm-service
spec:
  selector:
    app: mistral-server
  type: ClusterIP
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

  2. Apply the manifest:

    kubectl apply -f vllm-mistral-small.yaml

    If you want you can limit the context window size by 16 K using vLLM option --max-model-len=16384. If you want a larger context window size (up to 128 K), adjust your manifest and node pool configuration with more GPU capacity.

Verification

  1. Wait for the Deployment to be available:

    kubectl wait --for=condition=Available --timeout=1800s deployment/vllm-mistral-deployment

  2. View the logs from the running Deployment:

    kubectl logs -f -l app=mistral-server

    The Deployment resource downloads the Mistral small model data. This process can take a few minutes. The output is similar to the following:

      ...
  ...
  (APIServer pid=1) INFO:     Started server process [1]
  (APIServer pid=1) INFO:     Waiting for application startup.
  (APIServer pid=1) INFO:     Application startup complete.

After the deployment is available, set up port forwarding to interact with the model.

Serve the model

In this section, you interact with the model. Make sure the model is fully downloaded before proceeding.

Set up port forwarding

Run the following command to set up port forwarding to the model:

kubectl port-forward svc/llm-service 8080:8080 --namespace default &

The output is similar to the following:

Forwarding from 127.0.0.1:8080 -> 8080

Interact with the model using curl

This section shows how you can perform a basic smoke test to verify your deployed Mistral instruction-tuned models. For other models, replace mistral-small-4-119b-weights with the name of the respective model.

This example shows how to test the Mistral instruction tuned model with text-only input.

In a new terminal session, use curl to chat with your model:

curl http://127.0.0.1:8080/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-Small-4-119B-2603-eagle",
    "prompt": "What is the capital of France?",
    "max_tokens": 50,
    "temperature": 0.7
  }'

The output looks similar to the following:

{
  "id": "cmpl-b5d649b6a2d7a330",
  "object": "text_completion",
  "created": 1781137490,
  "model": "openapi",
  "choices": [
    {
      "index": 0,
      "text": " This question is likely to have been asked millions of times, 
      and the answer is always the same: Paris. But why is Paris the capital 
      of France? The answer to this question is not as simple as 
      it may seem, as it involves a complex",
      "logprobs": null,
      "finish_reason": "length",
      "stop_reason": null,
      "token_ids": null,
      "prompt_logprobs": null,
      "prompt_token_ids": null
    }
  ],
  "service_tier": null,
  "system_fingerprint": null,
  "usage": {
    "prompt_tokens": 8,
    "total_tokens": 58,
    "completion_tokens": 50,
    "prompt_tokens_details": null
  },
  "kv_transfer_params": null
}

Troubleshoot issues

  • If you get the message Empty reply from server, it's possible the container has not finished downloading the model data. Check the Pod's logs again for the Connected message which indicates that the model is ready to serve.
  • If you see Connection refused, verify that your port forwarding is active.

Observe model performance

To view the dashboards for observability metrics of a model, follow these steps:

  1. In the Cloud de Confiance console, go to the Deployed Models page.

    Go to Deployed Models

  2. To view details about the specific deployment, including its metrics, logs, and dashboards, click the model name in the list.

  3. In the model details page, click the Observability tab to view the following dashboards. If prompted, click Enable to enable metrics collection for the cluster.

    • The Infrastructure usage dashboard displays utilization metrics.
    • The DCGM dashboard displays DCGM metrics.
    • If you are using vLLM, then the Model performance dashboard is available and displays metrics for the vLLM model performance.

You can also view metrics in the vLLM dashboard integration in Cloud Monitoring. These metrics are aggregated for all vLLM deployments with no pre-set filters

vLLM exposes metrics in Prometheus format by default; you don't need to install an additional exporter. For information about using Google Cloud Managed Service for Prometheus to collect metrics from your model, see the vLLM observability guidance in the Cloud Monitoring documentation.

Clean up

To avoid incurring charges to your Google Cloud account for the resources used in this tutorial, either delete the project that contains the resources, or keep the project and delete the individual resources.

Delete the deployed resources

To avoid incurring charges to your Cloud de Confiance account for the resources that you created in this guide, run the following command:

gcloud container clusters delete CLUSTER_NAME \
    --location=REGION

Replace the following values:

  • REGION: the region of your cluster.
  • CLUSTER_NAME: the name of your cluster.

What's next