Guida per l'utente degli LLM open-weight su GDC con air gap

Questa guida al deployment fornisce istruzioni dettagliate su come eseguire modelli linguistici di grandi dimensioni (LLM) all'avanguardia utilizzando software open source (OSS) in ambienti air-gap di Google Distributed Cloud (GDC). In particolare, questa guida presenta tutti i passaggi necessari per eseguire le ultime release dei modelli Gemma, DeepSeek e Llama, introducendo al contempo procedure comuni per pubblicare altri LLM disponibili pubblicamente. Utilizzeremo backend di serving containerizzati, come vLLM e Ollama, che coprono un'ampia gamma di funzionalità, diversi livelli di configurazione e facilità di deployment.

Riepilogo dei contenuti

Questa guida descrive in dettaglio il deployment e il funzionamento di modelli linguistici di grandi dimensioni (LLM) open source negli ambienti air-gap di Google Distributed Cloud (GDC).

Obiettivi e infrastruttura principali

• Scopo: istruzioni dettagliate per l'esecuzione di LLM allo stato dell'arte, tra cui Gemma 3 (multimodale), DeepSeek-R1 e Llama (3.1/3.2) utilizzando backend ottimizzati come vLLM e Ollama.
• Versione minima: versione software GDC con air gap 1.15.x*.
• Requisiti hardware: è richiesta almeno 1 GPU NVIDIA A100. Per ottimizzare i tempi di caricamento dei pesi del modello da 30 minuti a meno di 5 minuti, è consigliabile utilizzare uno spazio di archiviazione ad alte prestazioni (PVC da almeno 500 GiB).

Componenti di deployment

Componente	Descrizione
Backend LLM	vLLM (servizio ad alto throughput con PagedAttention) e Ollama (gestione locale semplificata e supporto multimodale)
Modelli	LLM disponibili pubblicamente, tra cui le famiglie Gemma, DeepSeek e Llama
Acceleratori	Supporta GPU NVIDIA A100 complete o sezioni GPU multi-istanza (MIG) a seconda dell'impronta VRAM del modello
Servizi GDC	Utilizza GDC Container Service, Load Balancer (ELB/ILB), Harbor Container Registry

Procedure operative chiave

• Gestione dei modelli: il backend LLM gestisce il caricamento e lo scaricamento dei modelli in base all'utilizzo. vLLM blocca i modelli in memoria per una latenza bassa e coerente, mentre Ollama consente il caricamento dinamico dei modelli, ma li scarica automaticamente dopo 30 minuti di inattività.
• Personalizzazione: gli utenti possono utilizzare gli LLM preferiti estraendoli da internet, creando nuove immagini Docker e caricandole nel registro Harbor locale.

Prerequisiti

Release

• GDC con air gap versione 1.15.1 o successive.

Componenti

• Cluster utente creato con risorse sufficienti (CPU, memoria, GPU).
• È richiesta almeno una GPU NVIDIA A100.
• L'istanza Harbor è disponibile e accessibile.
• Interfacce a riga di comando kubectl e gdcloud configurate per accedere al cluster utente.
• Il client Docker è installato e configurato per il push su Harbor.
• Autorizzazioni IAM necessarie concesse (ad esempio, Amministratore spazio dei nomi, Sviluppatore cluster).
• Account Hugging Face e autenticazione configurati se utilizzi modelli con accesso limitato.

Capacità necessaria

Risorsa	Capacità
CPU	8 vCPU
Memoria RAM	32 GiB
Archiviazione temporanea	16 Gi
GPU	1 GPU NVIDIA A100
Volume permanente	*500 GB o più

Queste risorse hardware sono necessarie per l'esecuzione dei backend per eseguire LLM con accelerazione GPU. Ad esempio, un tipo di macchina a2-ultragpu-1g-gdc fornirebbe risorse sufficienti.

Diagramma di alto livello

Questo diagramma mostra un utente che utilizza le API esposte da due backend LLM, vLLM e Ollama, per ottenere risposte di inferenza da modelli open source, come Gemma, Llama e DeepSeek. A seconda delle dimensioni del modello, misurate in miliardi di parametri, ogni LLM potrebbe aver bisogno di una GPU completa o di una sua parte per essere eseguito.

Nota :vLLM non supporta l'erogazione di più modelli in un singolo processo server o la definizione di più modelli nel comando del server vLLM. Per eseguire più modelli, devi avviare istanze del server vLLM separate, ognuna su una porta e (facoltativamente) una GPU diverse, e utilizzare un router o un bilanciatore del carico esterno (ad esempio Nginx) per indirizzare le richieste al server appropriato in base al modello richiesto.

Diagramma del perimetro di servizio e di sicurezza per un deployment LLM

Questa soluzione si basa sui seguenti servizi già inclusi nello stack software GDC con air gap:

• GDC Container Service: per eseguire tutti i processi e scalarli utilizzando HPA.
• Bilanciatore del carico GDC: utilizza un servizio Kubernetes per gestire tutti i backend in questa soluzione e rendere gli LLM accessibili dalla rete del cliente. Questo bilanciatore del carico è chiamato ELB, che sta per bilanciatore del carico esterno. Al contrario, il cliente può scegliere di mantenere raggiungibili gli LLM solo dall'interno di un cluster utente, il che potrebbe essere utile quando è presente solo un agente interno che richiede inferenze all'interno della propria soluzione. Questa opzione è chiamata ILB, che sta per bilanciamento del carico interno.
• GDC CI/CD: Harbor Container Registry per archiviare i backend LLM e i pesi del modello.
• Stack di osservabilità GDC: per raccogliere e cercare i log di backend e fornire dashboard.

In termini di sicurezza, l'accesso al deployment dell'LLM dipende da quali utenti possono raggiungere il servizio bilanciatore del carico che espone i backend di servizio dell'LLM, che vengono eseguiti come pod in un progetto / spazio dei nomi Kubernetes.

Deployment

Prerequisiti

Installa i seguenti strumenti su una workstation connessa al tuo ambiente GDC air-gapped:

1. docker
2. kubectl
3. gcloud CLI

Questo documento contiene tutto il codice sorgente e i file di configurazione necessari per il deployment di LLM.

Crea un secret per estrarre immagini da Harbor

Per configurare un secret di pull delle immagini per un workload container in GDC con air gap, devi creare un secret Kubernetes docker-registry contenente le credenziali per accedere al tuo progetto Harbor privato. Questo secret viene quindi referenziato nella specifica del deployment.

Devi utilizzare un account robot Harbor per l'accesso programmatico alle immagini nei progetti Harbor privati.

Segui questi passaggi per configurare il secret di pull dell'immagine:

Crea un account robot Harbor:

• Vai all'interfaccia utente dell'istanza Harbor.
• Vai al tuo progetto Harbor.
• Seleziona la scheda "Account robot".
• Fai clic su "+ NUOVO ACCOUNT ROBOT".
• Assegna un nome (ad esempio, oss-llm-puller) e concedi le autorizzazioni necessarie (almeno l'accesso "pull") fino a una data di scadenza.
• Memorizza in modo sicuro il nome dell'account robot (ad esempio robot$oss-llm-puller) e il token segreto fornito.

Autentica Docker in Harbor:

Sulla macchina su cui è installato Docker e con accesso alla rete al registro Harbor, accedi utilizzando le credenziali dell'account robot:

export INSTANCE_URL="your-harbor-instance-url"
# for example, harbor1-project1.org1.zone1.google.gdc.com

export ROBOT_NAME="your-robot-account-name"
# for example, robot\$oss-llm-puller (note how we escape the $ character)

export ROBOT_SECRET="your-robot-account-secret"

docker login ${INSTANCE_URL} --username ${ROBOT_NAME} --password ${ROBOT_SECRET}

# Sample output:

WARNING! Using --password via the CLI is insecure. Use --password-stdin.

WARNING! Your credentials are stored unencrypted in '$HOME/.docker/config.json'.
Configure a credential helper to remove this warning. See
https://docs.docker.com/go/credential-store/

Login Succeeded

Come mostrato nell'output di esempio, questo comando aggiorna il file di configurazione Docker locale ($HOME/.docker/config.json) con i dettagli di autenticazione. Il file config.json ha il seguente aspetto:

{
    "auths": {
        "harbor1-project1.org1.zone1.google.gdc.com": {
            "auth": "...omitted..."
        }
    }
}

Se in passato hai utilizzato il client Docker per accedere ad altri registri, vedrai più voci all'interno di "auths".

Crea il secret di pull dell'immagine Kubernetes:

Utilizza kubectl per creare un secret di tipo docker-registry nello spazio dei nomi del progetto, utilizzando il file di configurazione Docker aggiornato nel passaggio precedente:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS certificate}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

export SECRET_NAME="oss-llm-pull-secret" # You can choose another name
export NAMESPACE="your-project-namespace"
# Assuming default Docker config path. Adjust if necessary.
export DOCKER_CONFIG_PATH="$HOME/.docker/config.json"

kubectl create secret docker-registry ${SECRET_NAME} \
      --from-file=.dockerconfigjson=${DOCKER_CONFIG_PATH} \
      -n ${NAMESPACE}

Farai riferimento a questo secret in un secondo momento nella specifica del contenitore di backend LLM includendo il campo imagePullSecrets.

Se segui questi passaggi, il cluster Kubernetes utilizzerà le credenziali fornite per eseguire il pull di un'immagine container dal registro Harbor privato nell'ambiente GDC con air gap. Questi passaggi sono inclusi anche nella documentazione del prodotto.

Configurare il deployment LLM

Hai a disposizione le seguenti due opzioni per il backend LLM:

• vLLM
• Ollama

Puoi scegliere uno dei due o eseguire il deployment di entrambi i backend. Ogni backend può eseguire uno o più LLM, ad esempio:

• Gemma 3
• DeepSeek
• Llama
• Altri LLM

Nella sezione 1 forniamo istruzioni su come eseguire il deployment di vLLM e nella sezione 2 mostriamo come installare Ollama.

1. Esegui il deployment di vLLM come backend LLM

Recupera l'immagine Docker vLLM

In generale, vLLM viene utilizzato per pubblicare i modelli scaricati da Hugging Face, come mostreremo in questo deployment LLM. Alcuni modelli sono protetti, il che significa che gli utenti devono richiedere o accettare esplicitamente l'accesso ai propri file e contenuti su Hugging Face Hub prima di poterli scaricare o utilizzare.

Accedi all'istanza Harbor utilizzando Docker come spiegato nella documentazione. Su una macchina con accesso a internet, esegui il pull dell'immagine Docker vLLM e poi trasferiscila al tuo progetto Harbor:

# Pull and Tag vLLM (v0.13.0 recommended for stability)
docker pull vllm/vllm-openai:v0.13.0
docker tag vllm/vllm-openai:v0.13.0 HARBOR_URL/PROJECT/vllm-openai:v0.13.0
docker push HARBOR_URL/PROJECT/vllm-openai:v0.13.0

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.

La versione di vLLM utilizzata per questa guida al deployment è: v0.13.0

Memorizzare i pesi del modello LLM in un PVC

Apri un nuovo terminale e crea una cartella in cui salvare i file di deployment di vLLM:

mkdir vllm-deployment
cd vllm-deployment

Poi crea un file YAML (ad esempio model-pvc.yaml) per dichiarare una richiesta di volume permanente (PVC) utilizzando le primitive Kubernetes standard:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
  storageClassName: standard-rwo
  volumeMode: Filesystem

Connettiti al cluster GDC con air gap e applica il PVC:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS cert}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

# Apply the PVC manifest
kubectl apply -f model-pvc.yaml

Scarica i pesi del modello da Hugging Face:

# Log in to Hugging Face
hf auth login

# Download weights for Gemma 3 (for example, 4B instruction-tuned)
hf download google/gemma-3-4b-it

Esempio di output:

Fetching 9 files: 100%| 9/9 [00:00<00:00, 19.34it/s]
Downloading (…)7f58a/.gitattributes: 100%| 1.62k/1.62k [00:00<00:00, 7.82MB/s]
Downloading (…)del-00002-of-00002.safetensors: 100%| 3.75G/3.75G [00:46<00:00, 81.3MB/s]
Downloading (…)del-00001-of-00002.safetensors: 100%| 4.90G/4.90G [00:54<00:00, 90.1MB/s]
Downloading (…)-3-4b-it/README.md: 100%| 23.3k/23.3k [00:00<00:00, 48.0MB/s]
Downloading (…)8a/model.safetensors.index.json: 100%| 26.3k/26.3k [00:00<00:00, 39.5MB/s]
Downloading (…)f58a/config.json: 100%| 908/908 [00:00<00:00, 4.41MB/s]
Downloading (…)generation_config.json: 100%| 210/210 [00:00<00:00, 936kB/s]
Downloading (…)tokenizer.json: 100%| 33.1M/33.1M [00:01<00:00, 17.6MB/s]
/Users/rashjab/.cache/huggingface/hub/models--google--gemma-3-4b-it/snapshots/952ec8ffca3adadfd00c6d71b40280ebdbb7f58a

Come puoi vedere nell'output di esempio, la dimensione del modello su disco è 8,64 GB, che rientra nel PVC da 500 GiB che abbiamo definito in precedenza. Assicurati sempre che sia così per qualsiasi modello che scegli di caricare nel volume permanente (PV) e, ad esempio, un modello da 15 GB, utilizzando un PVC da 500 GiB per ottenere 1500 IOPS, riducendo significativamente il tempo di caricamento del peso da circa 30 minuti a meno di 5 minuti.

Compila il PV copiando i file del modello nel relativo volume. Spesso comporta:

• Creazione di un pod "helper" temporaneo che monta il PV.
• Utilizzando kubectl cp per copiare i file del modello dalla workstation nel volume montato del pod helper.
• Pod helper di esempio:

helper-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: model-uploader
spec:
  containers:
  - name: uploader
    image: HARBOR_URL/PROJECT/busybox:latest
    command: ["sleep", "3600"]
    volumeMounts:
    - name: model-data
      mountPath: /data
  imagePullSecrets:
  - name: oss-llm-pull-secret
  volumes:
  - name: model-data
    persistentVolumeClaim:
      claimName: model-pvc

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.
• oss-llm-pull-secret: se hai scelto un nome diverso per il secret di pull dell'immagine.
• model-pvc: con il nome che hai dato al tuo PVC.

Esegui il push dell'immagine Docker helper (busybox):

docker pull busybox:latest
docker tag busybox HARBOR_URL/PROJECT/busybox:latest
docker push HARBOR_URL/PROJECT/busybox:latest

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.

Applica il file helper-pod.yaml e copia i pesi del modello nel PV:

kubectl apply -f helper-pod.yaml

# Wait for the pod to be Running
kubectl cp ~/.cache/huggingface/hub/ NAMESPACE/model-uploader:/data/

# After copying, delete the helper pod
kubectl delete pod model-uploader

Esegui il deployment del backend vLLM

Crea il file di deployment per vLLM per eseguire il server di modelli. L'esempio seguente esegue il deployment del modello gemma-3-4b-it.

vllm-gemma-3-4b-it-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: gemma-3-4b-it
  labels:
    app: gemma-3-4b-it
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gemma-3-4b-it
  template:
    metadata:
      labels:
        app: gemma-3-4b-it
    spec:
      volumes:
      - name: cache-volume
        persistentVolumeClaim:
          claimName: model-pvc # change with the name you gave initially to your PVC
      # vLLM needs to access the host's shared memory for tensor parallel inference.
      - name: shm
        emptyDir:
          medium: Memory
          sizeLimit: "16Gi"
      containers:
      - name: gemma-3-4b-it
        image: HARBOR_URL/PROJECT/vllm-openai:v0.13.0
        command: ["python3"]
        args: [
          "-m",
          "vllm.entrypoints.openai.api_server",
          "--model",
          "google/gemma-3-4b-it", # Use the repo ID
          "--max-model-len",
          "32768",
          "--enforce-eager"
        ]
        env:
        - name: HF_HUB_OFFLINE
          value: "1"
        - name: HF_HOME
          value: "/model" # Tells vLLM to look for models in /model/hub
        # --- PERFORMANCE & STABILITY OPTIMIZATIONS ---
        - name: NCCL_P2P_DISABLE
          value: "1" # Prevents initialization hangs on P2P checks
        - name: NCCL_IB_DISABLE
          value: "1" # Prevents initialization hangs on InfiniBand checks
        # --- FIPS BYPASS ---
        - name: BORINGSSL_FIPS
          value: "0"
        - name: OPENSSL_FIPS
          value: "0"
        - name: OPENSSL_CONF
          value: "/dev/null"
        - name: FIPS_SIG
          value: "off"
        ports:
        - containerPort: 8000
        securityContext:
          privileged: true
          runAsUser: 0
        resources:
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
            cpu: "8"       # Increased to handle model weight verification
            memory: "64Gi"  # Increased to ensure headroom for weight loading
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
            cpu: "8"
            memory: "32Gi"
        volumeMounts:
        - name: cache-volume
          mountPath: /model
        - name: shm
          mountPath: /dev/shm
      imagePullSecrets:
      - name: oss-llm-pull-secret

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.
• oss-llm-pull-secret: il nome che hai assegnato durante la creazione del secret di pull dell'immagine.
• claimName: il nome che hai assegnato alla creazione iniziale del PVC.

Nota :in questo deployment richiediamo una GPU completa, anche se il modello può essere inserito in una sezione di GPU con soli 20 GB di VRAM. Tuttavia, in questo modo si otterrà il throughput più elevato per l'LLM, misurato in token/sec, poiché tutti i core della GPU saranno disponibili per l'inferenza.

Successivamente, crea un file di servizio Kubernetes per esporre le API di backend vLLM:

vllm-gemma-3-4b-it-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: gemma-3-4b-it
  namespace: NAMESPACE
spec:
  ports:
  - name: http-gemma-3-4b-it
    port: 80
    protocol: TCP
    targetPort: 8000
  selector:
    app: gemma-3-4b-it
  sessionAffinity: None
  type: LoadBalancer

Applica le configurazioni del deployment e del servizio:

kubectl apply -f vllm-gemma-3-4b-it-deployment.yaml
kubectl apply -f vllm-gemma-3-4b-it-service.yaml

Verifica e testa il deployment di vLLM

1. Controlla lo stato del pod:

   kubectl get pods
   

   Attendi che il pod sia nello stato Running.

2. Controlla il servizio:

   kubectl get service
   

   Esempio di output:

   # NAME          TYPE         CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   # gemma-3-4b-it LoadBalancer 10.201.136.62  136.125.37.198   80:30109/TCP   3d1h
   

   Prendi nota di EXTERNAL-IP del servizio vLLM (ad esempio, 136.125.37.198) dall'output precedente. Puoi anche stamparlo con:

   kubectl get service gemma-3-4b-it \
   -o jsonpath='{.status.loadBalancer.ingress[*].ip}'
   

3. Visualizza i log:

   kubectl logs YOUR_VLLM_POD
   

   Cerca messaggi che indicano che il server è stato avviato e il modello è stato caricato (ad esempio, INFO: Application startup complete.). Poiché non è previsto il download di Hugging Face, l'operazione dovrebbe essere rapida se i file si trovano sul PVC con una capacità del Persistent Volume elevata.

4. Testa l'inferenza con curl:

   Dopo aver verificato che il pod vLLM è in esecuzione e aver ottenuto l'indirizzo IP esterno del servizio, puoi inviare una richiesta di inferenza utilizzando curl. Poiché vLLM fornisce un'API compatibile con OpenAI, puoi utilizzare l'endpoint /v1/chat/completions:

   curl http://EXTERNAL_IP/v1/chat/completions \
     -H "Content-Type: application/json" \
     -d '{
       "model": "google/gemma-3-4b-it",
       "messages": [
         {"role": "user", "content": "What is Google Distributed Cloud air-gapped?"}
       ],
       "max_tokens": 100
     }'
   

   Sostituisci EXTERNAL_IP con l'indirizzo IP esterno del servizio vLLM.

2. Esegui il deployment di Ollama come backend LLM

Ollama è un framework popolare per l'esecuzione di LLM open source in locale e in ambienti containerizzati. Semplifica l'esecuzione del modello gestendo il download dei pesi, la quantizzazione e l'accelerazione GPU. Include un'API REST integrata per generare completamenti, risposte della chat e incorporamenti.

A differenza di altri motori di pubblicazione, Ollama gestisce l'esecuzione del modello in modo dinamico:

• Caricamento dinamico del modello: quando viene ricevuta una richiesta per un modello specifico, Ollama carica i pesi in memoria (VRAM della GPU o RAM di sistema) su richiesta.
• Scarico per inattività: se non vengono ricevute richieste di inferenza per un modello per 30 minuti (configurabile con OLLAMA_KEEP_ALIVE), Ollama lo scarica dalla memoria per liberare risorse hardware per altri carichi di lavoro.
• Singolo modello attivo per istanza: Ollama elabora le richieste per un modello attivo alla volta per istanza del server. Se vengono chiamati più modelli in parallelo, Ollama mette in coda le richieste e scambia i modelli in sequenza, il che può introdurre latenza. Per pubblicare più modelli contemporaneamente senza scambiarli, devi eseguire il deployment di istanze Ollama separate per ogni modello.

Scarica i pesi del modello e crea un'immagine Docker

A differenza di vLLM, che può caricare i pesi direttamente da un Persistent Volume, Ollama in genere si aspetta che i modelli vengano archiviati nel formato di directory interno (~/.ollama/models).

In un ambiente air-gap, in cui i container di runtime non possono scaricare modelli da internet pubblico, devi pre-pacchettizzare i pesi del modello nell'immagine del container stesso durante la fase di build. Questo approccio garantisce che il container sia completamente autonomo e pronto per la pubblicazione immediatamente dopo il deployment senza richiedere l'accesso alla rete esterna.

Crea una cartella per il deployment di Ollama:

mkdir ollama-gemma3
cd ollama-gemma3

Crea un Dockerfile con il seguente contenuto:

# Use a standard Linux base image
FROM ubuntu

# Install necessary dependencies
RUN apt-get update && apt-get install -y --no-install-recommends \
    curl \
    ca-certificates \
    zstd \
    && rm -rf /var/lib/apt/lists/*

# Install Ollama
# This uses Ollama's official installation script, which adds Ollama to /usr/local/bin
RUN curl -fsSL https://ollama.com/install.sh -o install.sh && \
    chmod +x install.sh && \
    ./install.sh && \
    rm install.sh

# Set environment variables for Ollama (optional, but a good practice)
# ENV OLLAMA_HOST="0.0.0.0"

# If you want to customize the model storage path within the container, set OLLAMA_MODELS, for example:
# ENV OLLAMA_MODELS="/usr/local/ollama/models"
# The default OLLAMA_MODELS is /root/.ollama
# Then, ensure you create and populate that directory.

# --- Download Gemma 3 model weights ---
# This step starts Ollama server in the background, pulls the model,
# and then kills the server to allow the Docker build to continue.
# This approach works around the Docker RUN command limitations for services.

RUN ollama serve & \
    # Give the Ollama server a moment to start up
    # Use --retry and --retry-connrefused to handle startup delays
    curl --retry 10 --retry-connrefused -s http://localhost:11434 || true && \
    # Pull the Gemma 3 model weights
    ollama pull gemma3:latest && \
    # Stop the background Ollama server process cleanly
    pkill ollama || true

# Expose Ollama's default port
EXPOSE 11434

# Command to run Ollama server when the container starts
CMD ["ollama", "serve"]

Se vuoi provare un LLM open source diverso, ad esempio un modello delle famiglie Llama 3.2 o DeepSeek-R1, modifica questo comando Ollama nel Dockerfile precedente:

ollama pull gemma3:latest

Ad esempio, se vuoi eseguire il pull di Llama 3.2 con 3 miliardi di parametri, utilizza questo comando:

ollama pull llama3.2:3b

In alternativa, se preferisci utilizzare DeepSeek-R1 con 8 miliardi di parametri, utilizza questo comando:

ollama pull deepseek-r1:8b

Puoi anche scaricare più di un LLM e containerizzare i relativi pesi del modello. In questo modo, Ollama potrà passare da un modello all'altro quando richiedi inferenze con modelli precaricati diversi. Ad esempio, puoi aggiungere i modelli Gemma e Llama all'immagine Docker. Ricorda che in un ambiente isolato, un backend Ollama non ha accesso alla libreria Ollama per scaricare qualsiasi modello in qualsiasi momento.

Ricordati di controllare e accettare ogni licenza e i termini di utilizzo del modello prima di eseguirli nelle tue applicazioni. Nella libreria di Ollama sono presenti molti LLM. Avrai bisogno di una connessione a internet solo per scaricare i pesi del modello durante la creazione dell'immagine Docker del backend LLM.

Crea l'immagine Docker ed eseguine il push su Harbor

Accedi all'istanza Harbor utilizzando Docker come spiegato nella documentazione. Crea l'immagine Docker Gemma 3 e caricala nel tuo repository Harbor:

docker build -t ollama-gemma3 .
docker tag ollama-gemma3 HARBOR_URL/PROJECT/ollama-gemma3:latest
docker push HARBOR_URL/PROJECT/ollama-gemma3:latest

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.

Versione di Ollama utilizzata per questa guida al deployment: 0.14.1

Prepara un deployment e un servizio Kubernetes

Crea un file denominato ollama-gemma3.yaml per definire il deployment del backend Ollama e la relativa configurazione del bilanciatore del carico per esporlo come servizio:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama-gemma3
  namespace: osd-dev
  labels:
    app: ollama-gemma3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama-gemma3
  template:
    metadata:
      labels:
        app: ollama-gemma3
    spec:
      containers:
      - name: ollama-gemma3
        image: rashjab-mhs-rashjab-test2.gdc1.us-west6-a.staging.gpcdemolabs.com/rashjab-repo/ollama-gemma3:latest
        env:
        # This is the crucial fix: Tell Ollama to listen on all network interfaces
        - name: OLLAMA_HOST
          value: "0.0.0.0"
        imagePullPolicy: Always
        ports:
        - containerPort: 11434
        securityContext:
          privileged: true
          runAsUser: 0
        resources:
          limits:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
          requests:
            nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1
      imagePullSecrets:
      - name: oss-llm-pull-secret
---
apiVersion: v1
kind: Service
metadata:
  name: ollama-gemma3
  namespace: osd-dev
spec:
  type: LoadBalancer
  selector:
    app: ollama-gemma3
  ports:
  - name: ollama-gemma3-port
    port: 11434
    protocol: TCP
    targetPort: 11434

Sostituisci quanto segue:

• HARBOR_URL: l'URL dell'istanza Harbor.
• PROJECT: il nome del progetto Harbor.
• oss-llm-pull-secret: se hai scelto un nome diverso per il secret di pull dell'immagine.

Verificare l'allocazione della GPU

GDC con air gap supporta le GPU multi-istanza (MIG) NVIDIA e i suoi diversi profili MIG possono essere esaminati nella documentazione pubblica. Se esegui il deployment di LLM di piccole dimensioni, ti consigliamo di controllare le loro dimensioni (in memoria) e di partizionare le GPU di conseguenza. Lo schema di partizionamento per un pool di nodi è definito nella risorsa personalizzata Cluster. Per saperne di più su come applicare uno schema di partizionamento della GPU, consulta Aggiungere un pool di nodi. Se sei un Application Operator (AO), consulta il tuo Platform Administrator (PA) in merito agli acceleratori installati e disponibili nel tuo progetto / cluster. Puoi trovare maggiori dettagli su come configurare un container per utilizzare le risorse GPU e come controllare l'allocazione delle risorse GPU.

La precisione predefinita del modello Gemma 3 4B è a 16 bit. Secondo questa tabella pubblicata da Google, il requisito di memoria della GPU per questo LLM è di 6,4 GB, utilizzando la precisione BF16 (16 bit).

Nel ollama-gemma3.yaml precedente, abbiamo collegato una sezione della GPU da 10 GB (NVIDIA A100) al container, poiché questa quantità di memoria VRAM è sufficiente per caricare il modello Gemma 3 4B ed eseguirlo, come mostrato di seguito:

ollama-gemma3.yaml

... omitted ...

        resources:
          limits:
            nvidia.com/mig-1g.10gb-NVIDIA_A100_80GB_PCIE: 1
          requests:
            nvidia.com/mig-1g.10gb-NVIDIA_A100_80GB_PCIE: 1

... omitted ...

Esegui il deployment del backend Ollama ed esponilo come servizio

Connettiti al cluster e imposta il contesto sullo spazio dei nomi del progetto:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS certificate}

gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

Applica il manifest di Ollama:

kubectl apply -f ollama-gemma3.yaml

Assicurati che il pod Ollama sia in esecuzione e che il servizio associato sia attivo:

kubectl get pods

Esempio di output:

# NAME                             READY   STATUS    RESTARTS   AGE
# ollama-gemma3-6fc6fff74b-9qtpf   1/1     Running   0          1h

kubectl get service

Esempio di output:

# NAME             TYPE          CLUSTER-IP    EXTERNAL-IP    PORT(S)          AGE
# ollama-gemma3   LoadBalancer  172.0.0.1     10.0.0.1       11434:31822/TCP  1d

Prendi nota di EXTERNAL-IP del servizio Ollama (ad esempio, 10.0.0.1) dall'output precedente. Puoi anche stamparlo con:

kubectl get service ollama-gemma3 \
-o jsonpath='{.status.loadBalancer.ingress[*].ip}'

Prima di verificare che Ollama Gemma 3 funzioni, devi applicare una policy di rete come :

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-ollama-ingress
  namespace: osd-dev
spec:
  subject:
    subjectType: UserWorkload
  policyType: Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0 # Allows traffic from any IP. Restrict this for production.
    ports:
    - protocol: TCP
      port: 11434

Applica la policy di rete:

kubectl apply -f ollama-netpol.yaml

Verifica e testa il deployment di Ollama:

1. Controlla se Ollama è in esecuzione:

   curl http://EXTERNAL_IP:11434
   

   Risposta prevista: "Ollama is running"

2. Invia una richiesta di completamento:

   curl -X POST http://EXTERNAL_IP:11434/v1/completions \
     -H "Content-Type: application/json" \
     -d '{
       "model": "gemma3:latest",
       "prompt": "Google Distributed Cloud air-gapped is a",
       "max_tokens": 128,
       "temperature": 0.90
     }'
   

Richiedi inferenze

Ora che i backend LLM (vLLM e Ollama) sono di cui è stato eseguito il deployment e sono raggiungibili tramite i rispettivi servizi LoadBalancer, puoi iniziare a utilizzarli per l'inferenza.

A seconda del caso d'uso, hai diverse opzioni:

• UI web interattiva: per testare, creare prototipi o fornire agli utenti un'esperienza simile a ChatGPT, puoi eseguire il deployment di Open WebUI o di un frontend simile.
• Interfaccia a riga di comando (CLI): per la verifica rapida, la creazione di script o l'automazione, puoi utilizzare curl o script personalizzati.
• Integrazione di applicazioni: collega le tue applicazioni interne, gli agenti AI o i plug-in IDE (ad esempio Continue per VS Code/JetBrains) direttamente agli endpoint compatibili con OpenAI forniti da vLLM (/v1) o Ollama (/v1).

1. Interagire con l'LLM utilizzando una UI

Per fornire un'interfaccia simile a ChatGPT per interagire con i tuoi modelli, esegui il deployment di Open WebUI nel tuo cluster.

Crea il deployment di Open WebUI

Crea open-webui-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: open-webui
  namespace: osd-dev
  labels:
    app: open-webui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: open-webui
  template:
    metadata:
      labels:
        app: open-webui
    spec:
      containers:
      - name: open-webui
        image: HARBOR_URL/PROJECT/open-webui:latest
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        env:
        - name: OPENAI_API_BASE_URL
          value: "http://gemma-3-4b-it/v1" # Point to your vLLM service
        - name: OPENAI_API_KEY
          value: "EMPTY"
        - name: WEBUI_AUTH
          value: "False"
      imagePullSecrets:
      - name: oss-llm-pull-secret
---
apiVersion: v1
kind: Service
metadata:
  name: open-webui
  namespace: osd-dev
spec:
  type: LoadBalancer
  selector:
    app: open-webui
  ports:
  - port: 80
    targetPort: 8080

Applica il criterio di rete

Devi consentire alla tua macchina di raggiungere il servizio Open WebUI sulla porta 80.

Aggiorna la policy di rete del progetto PNP in modo da includere il servizio open-webui o applicane una generica:

apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  name: allow-webui-ingress
  namespace: NAMESPACE
spec:
  subject:
    subjectType: UserWorkload
  policyType: Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0 # Allows traffic from any IP then restrict this for production
    ports:
    - protocol: TCP
      port: 8080

Verifica

1. Ottieni l'IP della GUI web:

   kubectl get service open-webui -n NAMESPACE
   

2. Accedi alla UI: apri il browser e vai all'indirizzo http://WEB_UI_EXTERNAL_IP

3. Configura: al primo accesso, crea un account amministratore. Nelle impostazioni, assicurati che i punti di connessione OpenAI puntino a http://gemma-3-4b-it/v1.

4. Seleziona Modello: nell'interfaccia di chat, seleziona google/gemma-3-4b-it dal menu a discesa dei modelli.

   

2. Inviare richieste HTTP utilizzando una CLI

• curl:

curl -X POST http://OLLAMA_LOAD_BALANCER_IP:11434/v1/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "gemma3:latest",
  "prompt": "Google Distributed Cloud air-gapped is a",
  "max_tokens": 128,
  "temperature": 0.90
}'

Convalida e verifica

Controlla che tutti i container e i servizi siano in esecuzione:

# Log in to GDC air-gapped using the next commands

gdcloud auth login --login-config-cert {path to your web TLS cert}
gdcloud clusters get-credentials {Your User Cluster}
kubectl config set-context --current --namespace=NAMESPACE

# Pods

kubectl get pods # This command should return results like below

# NAME                                   READY   STATUS    RESTARTS   AGE
# vllm-6fc6fff74b-9qtpf                 1/1     Running   0          1h
# ollama-798fbf6ff6-9m7ln               1/1     Running   0          1h


# Services

kubectl get services # This command should return results like below

# NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)           AGE
# vllm-service              LoadBalancer   172.0.0.1        10.0.0.1       11434:31822/TCP   1h
# ollama-service        LoadBalancer   172.0.0.2        10.0.0.2       11434:30728/TCP   1h

Passaggi per la rimozione

1. Rimuovi tutte le risorse Kubernetes:

   kubectl delete -f vllm-gemma-3-4b-it-deployment.yaml
   kubectl delete -f vllm-gemma-3-4b-it-service.yaml
   

2. Elimina manualmente i container inutilizzati dal repository Harbor.

Operazioni

Backend vLLM

Nozioni di base sui vLLM

vLLM è progettato come motore di pubblicazione di un singolo modello ad alte prestazioni. Non supporta la pubblicazione di più modelli all'interno di un singolo processo server o la definizione di più modelli in un unico comando di avvio. Per pubblicare più di un modello (ad esempio, un modello di chat e un modello di incorporamento separato), devi avviare istanze vLLM separate, ognuna nel proprio pod o container, assegnate facoltativamente a GPU o sezioni di GPU diverse. A differenza di altri backend che potrebbero scambiare dinamicamente i modelli, un'istanza vLLM blocca il modello e la memoria della cache KV associata all'inizializzazione per garantire un throughput elevato e una bassa latenza costanti.

Puoi aprire un terminale su uno qualsiasi dei pod vLLM utilizzando i seguenti comandi:

kubectl exec -it gemma-3-4b-random-string -n NAMESPACE -- /bin/bash

Verranno visualizzati i modelli caricati, i relativi argomenti e i relativi PID :

ps aux | grep vllm

Output simile previsto:

root           1  0.1  0.8 9436960 1550504 ?     Ssl  Feb04   9:18 python3 -m vllm.entrypoints.openai.api_server --model google/gemma-3-4b-it --max-model-len 32768 --enforce-eager
root         504  0.0  0.0   3476  1596 pts/0    S+   02:48   0:00 grep --color=auto vllm

Se vuoi una visualizzazione più pulita e simile a quella di Ollama, senza il disordine del comando grep stesso e dei PID di sistema, puoi utilizzare questo comando one-liner:

ps aux | grep [v]llm.entrypoints | awk -F'--model ' '{print $2}' | awk '{print $1}'

Esempio di risposta :

google/gemma-3-4b-it

Puoi monitorare lo stato del deployment di vLLM utilizzando i comandi kubectl standard e interrogando gli endpoint API interni.

Controllare i log dei pod

Apri un terminale per visualizzare i log di inizializzazione e pubblicazione:

kubectl logs -f gemma-3-4b-it-random_string -n NAMESPACE

Cerca la conferma che il server è pronto:

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

Query Internal Status

Poiché vLLM fornisce un'API compatibile con OpenAI, puoi verificare i modelli caricati e l'integrità del sistema direttamente da un terminale all'interno del cluster (ad esempio, utilizzando un pod debug-sh).

Per prima cosa devi avviare il pod di debug. Ecco le istruzioni :

Avviare il pod di debug

Esegui questo comando per avviare una shell effimera nello spazio dei nomi del tuo progetto. Questa configurazione utilizza l'immagine busybox (precedentemente eseguita il push nel registro Harbor) e inserisce le credenziali necessarie con il flag --overrides:

kubectl run --rm -it debug-sh \
  --image=HARBOR_URL/PROJECT/busybox:latest \
  --restart=Never -n osd-dev --overrides='{
    "spec": {
      "imagePullSecrets": [{"name": "oss-llm-pull-secret"}]
    }
  }' -- sh

Parametri chiave:

• --rm: elimina automaticamente il pod all'uscita, preservando le risorse del cluster.
• --overrides: obbligatorio negli ambienti isolati per consentire al pod di autenticarsi con il registro Harbor privato.

Stato del server del modello di query

Una volta all'interno del pod, utilizza l'utilità wget per eseguire query sull'API vLLM. Poiché il servizio vLLM mappa la porta interna 8000 alla porta 80, puoi utilizzare il nome DNS del servizio:

• Elenco dei modelli caricati: verifica che il motore vLLM sia stato inizializzato correttamente e che i pesi di Gemma 3 siano stati caricati.

  wget -qO- http://gemma-3-4b-it/v1/models
  

  Risposta di successo:

  {"object":"list","data":[{"id":"google/gemma-3-4b-it"}]}
  

• Controlla lo stato dell'applicazione: verifica che il server API sia pronto a elaborare le richieste.

  wget -qO- http://gemma-3-4b-it/health
  

  Risposta di successo:

  OK
  

Nozioni di base su Ollama

Ollama non supporta il caricamento simultaneo di più modelli in memoria. Inoltre, se non utilizzi l'LLM per un determinato periodo di tempo (in genere 30 minuti per impostazione predefinita), Ollama scarica il modello corrente dalla memoria.

A causa del comportamento descritto in precedenza, la soluzione implementa due o più backend Ollama a seconda delle tue esigenze e del tuo caso d'uso, in modo che molti sviluppatori o utenti possano utilizzarli in parallelo senza che una sola istanza Ollama carichi e scarichi frequentemente i modelli, producendo una latenza non necessaria.

Puoi aprire un terminale su uno qualsiasi dei pod Ollama utilizzando i seguenti comandi:

kubectl exec -it ollama-chat-random_string -- sh
kubectl exec -it ollama-autocomplete-random_string -- sh

All'interno dei pod, puoi utilizzare la CLI Ollama per esplorare i modelli disponibili e vedere quale è caricato:

• Nel pod ollama-chat troverai un modello:

  # ollama list
  NAME                     ID              SIZE      MODIFIED
  codegemma:7b-instruct    0c96700aaada    5.0 GB    2 hours ago
  
  # ollama ps
  NAME                     ID              SIZE     PROCESSOR    UNTIL
  codegemma:7b-instruct    0c96700aaada    10 GB    100% GPU     4 minutes from now
  

• Nel pod ollama-autocomplete troverai due modelli:

  # ollama list
  NAME                     ID              SIZE      MODIFIED
  codegemma:2b             926331004170    1.6 GB    2 hours ago
  codegemma:7b-code        aee9a63c13b9    5.0 GB    2 hours ago
  
  # ollama ps
  NAME                 ID              SIZE      PROCESSOR    UNTIL
  codegemma:7b-code    aee9a63c13b9    7.1 GB    100% GPU     4 minutes from now
  

• Quando Ollama scarica il modello corrente, l'output è vuoto:

  # ollama ps
  NAME    ID    SIZE    PROCESSOR    UNTIL
  

Tieni presente che Ollama ricarica dinamicamente un modello quando invii la richiesta successiva di assistenza per il codice, senza alcun intervento manuale.

Importanza della capacità della GPU

Se esegui il provisioning di una sezione di una GPU con 10 GB, ma il footprint della memoria del modello è (leggermente) più grande, noterai che parte dell'LLM viene caricato sulla CPU, come segue:

# ollama ps
NAME                     ID              SIZE     PROCESSOR         UNTIL
codegemma:7b-instruct    0c96700aaada    10 GB    6%/94% CPU/GPU    29 minutes from now

Questa soluzione non è ottimale e produce una latenza di risposta più elevata, quindi assicurati di fornire le dimensioni della GPU suggerite in questa guida.

Nota: questo si verifica solo con Ollama. Per vLLM, se il modello è troppo grande per la memoria GPU allocata, si arresterà in modo anomalo (errore OutOfMemory) durante l'inizializzazione. Si rifiuta di funzionare in uno stato di suddivisione della CPU "degradato" perché la sua funzionalità principale PagedAttention richiede una VRAM ad alta velocità per funzionare.

LLM

Utilizzare un LLM diverso o il tuo preferito con vLLM

Per eseguire diverse dimensioni di Gemma o di qualsiasi altro modello linguistico di grandi dimensioni (LLM) open source con vLLM su GDC con air gap, come DeepSeek-R1 o Llama 3.1, devi acquisire i nuovi pesi del modello nel tuo ambiente e aggiornare il manifest di deployment in modo che punti ai nuovi asset.

In base alle procedure operative stabilite per questa soluzione, segui questi passaggi per caricare un modello diverso :

1. Scarica i nuovi pesi del modello:

   Su una workstation con accesso a internet, utilizza la CLI di Hugging Face per scaricare i pesi per il modello che preferisci.

   • Per Gemma 3 (3-12b-it):

   hf download google/gemma-3-12b-it
   

   • Per DeepSeek-R1 (7B Distill):

   hf download deepseek-ai/DeepSeek-R1-Distill-Qwen-7B
   

   • Per Llama 3.1 (8B):

   hf download meta-llama/Meta-Llama-3.1-8B-Instruct
   

   Nota: prima di scaricare il modello, assicurati di aver accettato i termini di licenza su Hugging Face.

2. Compila il volume permanente (PVC):

   Aggiorna il model-pvc esistente o creane uno nuovo con capacità sufficiente per il nuovo modello. Utilizza il metodo del pod helper per trasferire i pesi dalla workstation. I fattori di forma più grandi richiedono molto più spazio su disco. Assicurati che la Persistent Volume Claim (PVC) abbia capacità sufficiente per archiviare i nuovi pesi.

   • Gemma 3 4B: circa 15,2 GB.
   • Gemma 3 27B: circa 54 GB+.
   • Consiglio: mantieni il PVC da 500 GiB consigliato per garantire un numero elevato di IOPS (1500) per un caricamento più rapido, indipendentemente dalle dimensioni del modello.

   # Copy the new model's hub directory to the helper pod
   kubectl cp ~/.cache/huggingface/hub/ osd-dev/model-uploader:/data/
   

3. Aggiorna il manifest di deployment di vLLM:

   Modifica il file YAML del deployment di vLLM in modo che faccia riferimento al nuovo ID modello. A differenza di Ollama, che può scambiare i modelli in modo dinamico, un'istanza vLLM è dedicata a un singolo modello e deve essere aggiornata o ridistribuita per cambiare modello.

   Aggiorna la sezione args del deployment a seconda del modello che utilizzi. Ecco deepseek come esempio:

   args: [
     "-m", "vllm.entrypoints.openai.api_server",
     "--model", "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", # Update to new Repo ID
     "--max-model-len", "32768",
     "--enforce-eager" # Recommended for GDC stability
   ]
   

4. Regola le risorse di GPU e memoria:

   I modelli più grandi richiedono più VRAM per i pesi e la cache KV. Se passi da un modello 4B a un modello 8B o 14B, assicurati che i limiti delle risorse siano sufficienti per evitare arresti anomali per "out of memory".

   • Impronta VRAM: con una precisione di 16 bit, un modello da 8 miliardi richiede circa 16 GB solo per i pesi, più memoria aggiuntiva per la cache vLLM PagedAttention.
   • Consiglio: utilizza una GPU A100 completa (nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1) per i modelli con più di 7 miliardi di parametri per garantire prestazioni ottimali e spazio di manovra per la cache KV.

5. Verifica il nuovo modello:

   Una volta terminata la riconciliazione del deployment, verifica che il nuovo modello sia attivo con l'API interna:

   # Inside a debug-sh pod
   wget -qO- http://gemma-3-4b-it/v1/models
   

   Risposta di successo:

   {"object":"list","data":[{"id":"deepseek-ai/DeepSeek-R1-Distill-Qwen-7B"}]}
   

Utilizzare un LLM diverso con Ollama

Se vuoi provare un LLM open source diverso, ad esempio un modello delle famiglie Llama 3.2 o DeepSeek-R1, modifica questo comando Ollama nel precedente Dockerfile:

ollama pull gemma3:latest

Ad esempio, se vuoi eseguire il pull di Llama 3.2 con 3 miliardi di parametri, utilizza questo comando:

ollama pull llama3.2:3b

In alternativa, se preferisci utilizzare DeepSeek-R1 con 8 miliardi di parametri, utilizza questo comando:

ollama pull deepseek-r1:8b

Puoi anche scaricare più di un LLM e containerizzare i relativi pesi del modello. In questo modo, Ollama potrà passare da un modello all'altro quando richiedi inferenze con modelli precaricati diversi. Ad esempio, puoi aggiungere i modelli Gemma e Llama all'immagine Docker. Ricorda che in un ambiente isolato, un backend Ollama non ha accesso alla libreria Ollama per scaricare qualsiasi modello in qualsiasi momento.

Ricordati di controllare e accettare ogni licenza e i termini di utilizzo del modello prima di eseguirli nelle tue applicazioni. Nella libreria di Ollama sono presenti molti LLM. Avrai bisogno di una connessione a internet solo per scaricare i pesi del modello durante la creazione dell'immagine Docker del backend LLM.

Apri WebUI

Controlla se il pod Open WebUI è in stato di esecuzione :

kubectl get pods -n NAMESPACE

Output previsto :

NAME                             READY   STATUS    RESTARTS   AGE
open-webui-69df4664d-przjl       1/1     Running   0          6d3h

Controlla l'IP del servizio :

kubectl get service -n NAMESPACE

Output previsto:

NAME          TYPE            CLUSTER-IP       EXTERNAL-IP      PORT(S)           AGE
open-webui     LoadBalancer   10.201.137.164   136.125.37.224   80:30492/TCP      6d3h

Le sezioni seguenti mostrano come utilizzare le funzionalità principali dell'interfaccia utente.

Scalare la soluzione con un backend Ollama

Verticalmente

• Alloca una fetta di GPU più grande per il tuo LLM che è diventato un collo di bottiglia finché non utilizzi una GPU completa.
• Se vuoi utilizzare un LLM più grande per una migliore precisione delle risposte, ad esempio un LLM con 405 miliardi di parametri anziché uno con 7 miliardi, potresti aver bisogno di più di una GPU per eseguirlo senza problemi.
• I modelli che rientrano in più di una GPU subiscono una latenza correlata alla comunicazione tra GPU.

Orizzontalmente

• Esegui il deployment di tutti i pod Ollama necessari per raggiungere il throughput target su un LLM specifico.
  • Per farlo, aumenta il numero di repliche nel file YAML di deployment di Ollama corrispondente.
• Il servizio Kubernetes, di tipo LoadBalancer, distribuirà le richieste di assistenza per il codice tra gli endpoint (ovvero i pod) e restituirà le rispettive risposte tramite l'IP esterno esposto.
• Ricorda che il plug-in Continua punta a un solo indirizzo IP per funzionalità.

Per scalare il backend vLLM all'interno dell'ambiente GDC air-gapped, puoi seguire una strategia simile a quella utilizzata per Ollama, concentrandoti sia sull'allocazione delle risorse hardware sia sulla replica dei pod.

Scalare la soluzione con un backend vLLM

Verticalmente

• Esegui l'upgrade dell'allocazione della GPU:se la velocità effettiva di inferenza (token/sec) diventa un collo di bottiglia, alloca una porzione di GPU più grande finché non utilizzi una GPU NVIDIA A100 completa.
• Configurazioni multi-GPU: per modelli di grandi dimensioni (ad esempio, da 70 miliardi a 405 miliardi di parametri) che non rientrano nella memoria di una singola A100 da 80 GB, devi scalare a più GPU utilizzando il parallelismo dei tensori.
• Considerazione della latenza: tieni presente che i modelli che si estendono su più GPU potrebbero riscontrare un leggero sovraccarico correlato alla comunicazione tra GPU (ad esempio, la sincronizzazione NCCL).

Orizzontalmente

• Aumenta la velocità effettiva tramite le repliche: per gestire un volume maggiore di richieste simultanee degli utenti per lo stesso modello, aumenta il conteggio di replicas nel file YAML di deployment di vLLM.
• Istanze di modelli dedicate: poiché vLLM è progettato come motore di servizio di un singolo modello e blocca la memoria della cache KV all'inizializzazione, devi eseguire il deployment di un insieme separato di pod per ogni LLM diverso che vuoi ospitare.
• Bilanciamento del carico: il servizio GDC Kubernetes (tipo LoadBalancer) distribuirà automaticamente le richieste di inferenza in entrata tra tutti gli endpoint pod vLLM integri associati a quel servizio.

Risoluzione dei problemi

Errore	Mitigazione
FIPS SELFTEST FAILURE	Si verifica quando le librerie come BoringSSL non hanno firme di integrità. Correzione impostando BORINGSSL_FIPS=0 e utilizzando immagini vLLM ufficiali
Caricamento del peso bloccato	Verifica la presenza di limitazione degli IOPS sui PVC di piccole dimensioni. Per l'inizializzazione del modello di prestazioni è necessario un volume di 500 GiB.
Connessione rifiutata	Verifica che PNP consenta esplicitamente targetPort (8000/8080). I firewall GDC non concedono automaticamente l'accesso alle porte di backend per gli indirizzi IP virtuali del bilanciatore del carico.