Guía del usuario de LLM de código abierto en GDC aislado

En esta guía de implementación, se proporcionan instrucciones detalladas para ejecutar modelos de lenguaje grandes (LLM) de vanguardia con software de código abierto (OSS) en entornos aislados de Google Distributed Cloud (GDC). En particular, esta guía presenta todos los pasos necesarios para ejecutar las versiones más recientes de los modelos Gemma, DeepSeek y Llama, y, al mismo tiempo, presenta procedimientos comunes para entregar otros LLM disponibles públicamente. Aprovecharemos los backends de servicio basados en contenedores, como vLLM y Ollama, que abarcan una amplia gama de funcionalidades, diferentes niveles de configuración y facilidad de implementación.

Resumen del contenido

En esta guía, se detalla la implementación y el funcionamiento de los modelos de lenguaje grandes (LLM) de código abierto en entornos aislados de Google Distributed Cloud (GDC).

Objetivos e infraestructura principales

• Propósito: Instrucciones detalladas para ejecutar LLMs de estado del arte, incluidos Gemma 3 (multimodal), DeepSeek-R1 y Llama (3.1/3.2) con backends optimizados como vLLM y Ollama.
• Versión mínima: Versión de software de GDC aislado 1.15.x*.
• Requisitos de hardware: Se requiere un mínimo de 1 GPU NVIDIA A100. Se recomienda el almacenamiento de alto rendimiento (PVC de más de 500 GiB) para optimizar los tiempos de carga de los pesos del modelo de 30 minutos a menos de 5 minutos.

Componentes de implementación

Componente	Descripción
Backends de LLM	vLLM (entrega de alta capacidad de procesamiento con PagedAttention) y Ollama (administración local simplificada y compatibilidad multimodal)
Modelos	LLM disponibles públicamente, incluidas las familias Gemma, DeepSeek y Llama
Aceleradores	Admite GPU NVIDIA A100 completas o segmentos de GPU de instancias múltiples (MIG) según la huella de VRAM del modelo.
Servicios de GDC	Usa GDC Container Service, Load Balancer (ELB/ILB), Harbor Container Registry

Procedimientos operativos clave

• Administración de modelos: El backend del LLM administra la carga y descarga de modelos según el uso. vLLM fija los modelos en la memoria para lograr una latencia baja constante, mientras que Ollama permite la carga dinámica de modelos, pero los descarga automáticamente después de 30 minutos de inactividad.
• Personalización: Los usuarios pueden incorporar los LLM que prefieran extrayéndolos de Internet, compilando nuevas imágenes de Docker y subiéndolas al registro local de Harbor.

Requisitos previos

Versión

• Versión 1.15.1 o posterior de GDC aislado

Componentes

• Se creó un clúster de usuario con recursos suficientes (CPU, memoria y GPU).
• Se requiere un mínimo de 1 GPU NVIDIA A100.
• La instancia de Harbor está disponible y se puede acceder a ella.
• CLIs de kubectl y gdcloud configuradas para acceder al clúster de usuario
• El cliente de Docker está instalado y configurado para enviar a Harbor.
• Se otorgaron los permisos de IAM necesarios (por ejemplo, Administrador de espacios de nombres, Desarrollador de clústeres).
• Cuenta de Hugging Face y autenticación configuradas si se usan modelos con acceso restringido

Capacidad necesaria

Recurso	Capacidad
CPU	8 CPU virtuales
Memoria RAM	32 GiB
Almacenamiento efímero	16 Gi
GPU	1 GPU NVIDIA A100
Volumen persistente	*Más de 500 GiB

Estos recursos de hardware son necesarios para que los backends de entrega ejecuten LLMs con aceleración por GPU. Por ejemplo, un tipo de máquina a2-ultragpu-1g-gdc proporcionaría recursos suficientes.

Diagrama de alto nivel

En este diagrama, se muestra un usuario que consume las APIs expuestas por dos backends de LLM, vLLM y Ollama, para obtener respuestas de inferencia de modelos de código abierto, como Gemma, Llama y DeepSeek. Según el tamaño del modelo, medido en miles de millones de parámetros, cada LLM podría necesitar una GPU completa o una parte de ella para ejecutarse.

Nota: vLLM no admite la entrega de varios modelos en un solo proceso de servidor ni la definición de varios modelos en el comando del servidor de vLLM. Para ejecutar varios modelos, debes iniciar instancias separadas del servidor vLLM, cada una en un puerto y (opcionalmente) una GPU diferentes, y usar un enrutador o balanceador de cargas externo (por ejemplo, Nginx) para dirigir las solicitudes al servidor adecuado según el modelo solicitado.

Diagrama de límites de servicio y seguridad para una implementación de LLM

Esta solución se basa en los siguientes servicios que ya se incluyen en la pila de software de GDC aislado:

• Servicio de contenedores de GDC: Para ejecutar todos los procesos y ajustarlos con HPA
• Balanceador de cargas de GDC: Se usa un objeto Service de Kubernetes para entregar todos los backends de esta solución y hacer que los LLM sean accesibles desde la red del cliente. Se denomina ELB, que significa External Load Balancer. Por el contrario, el cliente puede optar por mantener los LLM accesibles solo desde el interior de un clúster de usuario, lo que podría ser útil cuando solo hay un agente interno que solicita inferencias dentro de su solución. Esto se denomina ILB, que significa balanceador de cargas interno.
• CI/CD de GDC: Container Registry de Harbor para almacenar back-ends de LLM y pesos del modelo.
• Pila de Observabilidad de GDC: Para recopilar y buscar registros de backend, y proporcionar paneles.

En términos de seguridad, el acceso a la implementación del LLM depende de qué usuarios pueden acceder al servicio de balanceador de cargas que expone los backends de servicio del LLM, que se ejecutan como Pods en un proyecto o espacio de nombres de Kubernetes.

Implementación

Requisitos previos

Instala las siguientes herramientas en una estación de trabajo conectada a tu entorno aislado de GDC:

1. docker
2. kubectl
3. CLI de gcloud

Este documento contiene todos los archivos de configuración y código fuente que necesitas para implementar LLMs.

Crea un secreto para extraer imágenes de Harbor

Para configurar un secreto de extracción de imágenes para una carga de trabajo de contenedor en GDC aislado, debes crear un secreto de Kubernetes docker-registry que contenga credenciales para acceder a tu proyecto privado de Harbor. Luego, se hace referencia a este secreto en la especificación de implementación.

Debes usar una cuenta de robot de Harbor para acceder de forma programática a las imágenes en proyectos privados de Harbor.

Sigue estos pasos para configurar el secreto de extracción de imágenes:

Crea una cuenta de robot de Harbor:

• Navega a la IU de tu instancia de Harbor.
• Ve a tu proyecto de Harbor.
• Selecciona la pestaña "Cuentas de robot".
• Haz clic en "+ NEW ROBOT ACCOUNT".
• Asigna un nombre (por ejemplo, oss-llm-puller) y otorga los permisos necesarios (al menos acceso de "extracción") hasta una hora de vencimiento.
• Almacena de forma segura el nombre de la cuenta del robot (por ejemplo, robot$oss-llm-puller) y el token secreto proporcionado.

Autentica Docker en Harbor:

En tu máquina con Docker instalado y acceso a la red del registro de Harbor, accede con las credenciales de la cuenta de 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

Como se muestra en el resultado de ejemplo, este comando actualiza tu archivo de configuración de Docker local ($HOME/.docker/config.json) con los detalles de autenticación. El archivo config.json se ve de la siguiente manera:

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

Si usaste tu cliente de Docker para acceder a otros registros en el pasado, verás más entradas dentro de "auths".

Crea el secreto de extracción de imágenes de Kubernetes:

Usa kubectl para crear un secreto de tipo docker-registry en el espacio de nombres de tu proyecto con el archivo de configuración de Docker actualizado en el paso anterior:

# 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}

Harás referencia a este secreto más adelante en la especificación del contenedor de backend del LLM incluyendo el campo imagePullSecrets.

Si sigues estos pasos, tu clúster de Kubernetes ahora usará las credenciales proporcionadas para extraer una imagen de contenedor de tu registro privado de Harbor en tu entorno de GDC aislado. Estos pasos también se incluyen en la documentación del producto.

Configura la implementación del LLM

Tienes las siguientes dos opciones para el backend del LLM:

• vLLM
• Ollama

Puedes elegir uno de ellos o implementar ambos backends. Cada backend puede ejecutar uno o más LLM, por ejemplo:

• Gemma 3
• DeepSeek
• Llama
• Otros LLMs

En la sección 1, proporcionamos instrucciones para implementar vLLM y, en la sección 2, mostramos cómo instalar Ollama.

1. Implementa vLLM como tu backend de LLM

Obtén la imagen de Docker de vLLM

En general, vLLM se usa para entregar modelos descargados de Hugging Face, como mostraremos en esta implementación de LLM. Algunos modelos están restringidos, lo que significa que los usuarios deben solicitar o aceptar explícitamente el acceso a sus archivos y contenido en Hugging Face Hub antes de poder descargarlos o usarlos.

Accede a tu instancia de Harbor con Docker, como se explica en la documentación. En una máquina con acceso a Internet, extrae la imagen de Docker de vLLM y, luego, transfiérela a tu proyecto de 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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.

La versión de vLLM que se usa en esta guía de implementación es la v0.13.0.

Almacena los pesos de tu modelo de LLM en un PVC

Abre una terminal nueva y crea una carpeta en la que guardarás los archivos de implementación de vLLM:

mkdir vllm-deployment
cd vllm-deployment

Luego, crea un archivo YAML (por ejemplo, model-pvc.yaml) para declarar un PersistentVolumeClaim (PVC) con elementos primitivos estándar de Kubernetes:

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

Conéctate a tu clúster aislado de GDC y aplica el 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

Descarga los pesos del modelo de 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

Resultado de muestra:

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

Como puedes ver en el ejemplo de salida, el tamaño del modelo en el disco es de 8.64 GB, lo que se ajusta al PVC de 500 GiB que definimos antes. Siempre asegúrate de que este sea el caso de cualquier modelo que elijas cargar en el volumen persistente (PV) y, por ejemplo, un modelo de 15 GB, usando un PVC de 500 GiB para lograr 1,500 IOPS, lo que reduce significativamente el tiempo de carga de peso de aproximadamente 30 minutos a menos de 5 minutos.

Copia los archivos del modelo en su volumen para completar el PV. Esto suele implicar lo siguiente:

• Crea un Pod "auxiliar" temporal que monte el PV.
• Usa kubectl cp para copiar los archivos del modelo de tu estación de trabajo en el volumen de la unidad auxiliar.
• Ejemplo de grupo de anuncios de ayuda:

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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.
• oss-llm-pull-secret: Si elegiste un nombre diferente para el secreto de extracción de imágenes
• model-pvc: con el nombre que le diste a tu PVC.

Envía la imagen de Docker auxiliar (busybox):

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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.

Aplica el archivo helper-pod.yaml y copia los pesos del modelo en el 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

Implementa el backend de vLLM

Crea el archivo de implementación para que vLLM ejecute el servidor del modelo. En el siguiente ejemplo, se implementa el modelo 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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.
• oss-llm-pull-secret: Es el nombre que le diste durante la creación del Secret de extracción de imágenes.
• claimName: Es el nombre que le diste a la creación inicial de la PVC.

Nota: Solicitamos una GPU completa en esta implementación, aunque el modelo puede caber en una porción de GPU con solo 20 GB de VRAM. Sin embargo, esto proporcionará la mayor capacidad de procesamiento al LLM, medida en tokens/s, ya que todos los núcleos de la GPU estarán disponibles para la inferencia.

A continuación, crea un archivo de servicio de Kubernetes para exponer las APIs de backend de 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

Aplica las configuraciones de implementación y servicio:

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

Verifica y prueba la implementación de vLLM

1. Verifica el estado del pod:

   kubectl get pods
   

   Espera a que el Pod esté en el estado Running.

2. Verifica el servicio:

   kubectl get service
   

   Resultado de muestra:

   # 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
   

   Toma nota del EXTERNAL-IP del servicio de vLLM (por ejemplo, 136.125.37.198) del resultado anterior. También puedes imprimirlo con el siguiente comando:

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

3. Consulta los registros:

   kubectl logs YOUR_VLLM_POD
   

   Busca mensajes que indiquen que el servidor se inició y que el modelo se cargó (por ejemplo, INFO: Application startup complete.). Como no hay descargas de Hugging Face, debería ser rápido si los archivos están en el PVC con una capacidad alta de volumen persistente.

4. Prueba la inferencia con curl:

   Después de verificar que el Pod de vLLM se esté ejecutando y de obtener la dirección IP externa del servicio, puedes enviar una solicitud de inferencia con curl. Dado que vLLM proporciona una API compatible con OpenAI, puedes usar el extremo /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
     }'
   

   Reemplaza EXTERNAL_IP por la dirección IP externa del servicio vLLM.

2. Implementa Ollama como tu backend de LLM

Ollama es un framework popular para ejecutar LLMs de código abierto de forma local y en entornos alojados en contenedores. Simplifica la ejecución del modelo controlando las descargas de pesos, la cuantización y la aceleración de la GPU. Incluye una API de REST integrada para generar finalizaciones, respuestas de chat y embeddings.

A diferencia de otros motores de procesamiento, Ollama administra la ejecución del modelo de forma dinámica:

• Carga dinámica de modelos: Cuando se recibe una solicitud para un modelo específico, Ollama carga los pesos en la memoria (VRAM de la GPU o RAM del sistema) a pedido.
• Descarga por inactividad: Si no se reciben solicitudes de inferencia para un modelo durante 30 minutos (se puede configurar con OLLAMA_KEEP_ALIVE), Ollama lo descarga de la memoria para liberar recursos de hardware para otras cargas de trabajo.
• Un solo modelo activo por instancia: Ollama procesa solicitudes para un modelo activo a la vez por instancia de servidor. Si se llama a varios modelos en paralelo, Ollama pone en cola las solicitudes y cambia los modelos de forma secuencial, lo que puede generar latencia. Para publicar varios modelos de forma simultánea sin intercambiarlos, debes implementar instancias de Ollama separadas para cada modelo.

Descarga los pesos del modelo y crea una imagen de Docker

A diferencia de vLLM, que puede cargar pesos directamente desde un volumen persistente, Ollama suele esperar que los modelos se almacenen en su formato de directorio interno (~/.ollama/models).

En un entorno aislado, en el que los contenedores de tiempo de ejecución no pueden descargar modelos de Internet pública, debes empaquetar previamente los pesos del modelo en la imagen del contenedor durante la fase de compilación. Este enfoque garantiza que el contenedor sea completamente autónomo y esté listo para entregar contenido inmediatamente después de la implementación sin necesidad de acceso a una red externa.

Crea una carpeta para la implementación de Ollama:

mkdir ollama-gemma3
cd ollama-gemma3

Crea un archivo Dockerfile con el siguiente contenido:

# 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"]

Si quieres probar un LLM de código abierto diferente, como un modelo de las familias Llama 3.2 o DeepSeek-R1, modifica este comando de Ollama en el Dockerfile anterior:

ollama pull gemma3:latest

Por ejemplo, si quieres extraer Llama 3.2 con 3,000 millones de parámetros, usa este comando:

ollama pull llama3.2:3b

O, si prefieres usar DeepSeek-R1 con 8,000 millones de parámetros, usa este comando:

ollama pull deepseek-r1:8b

También puedes descargar más de un LLM y tener sus pesos del modelo en contenedores. Luego, Ollama podrá cambiar entre los modelos a medida que solicites inferencias con diferentes modelos precargados. Por ejemplo, puedes agregar los modelos Gemma y Llama a tu imagen de Docker. Recuerda que, en un entorno aislado, un backend de Ollama no tiene acceso a la biblioteca de Ollama para descargar ningún modelo en ningún momento.

Recuerda revisar y aceptar cada licencia de modelo y condiciones de uso antes de ejecutarlos en tus aplicaciones. Hay muchos LLM en la biblioteca de Ollama. Solo necesitarás una conexión a Internet para descargar los pesos del modelo mientras compilas la imagen de Docker del backend del LLM.

Compila la imagen de Docker y envíala a Harbor

Accede a tu instancia de Harbor con Docker, como se explica en la documentación. Compila la imagen de Docker de Gemma 3 y súbela a tu repositorio de Harbor:

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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.

Versión de Ollama que se usó para esta guía de implementación: 0.14.1

Prepara una implementación y un servicio de Kubernetes

Crea un archivo llamado ollama-gemma3.yaml para definir la implementación del backend de Ollama y su configuración del balanceador de cargas para exponerlo como un servicio:

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

Reemplaza lo siguiente:

• HARBOR_URL: Es la URL de la instancia de Harbor.
• PROJECT: Es el nombre del proyecto de Harbor.
• oss-llm-pull-secret: Si elegiste un nombre diferente para el secreto de extracción de imágenes

Verifica la asignación de GPU

GDC aislado admite las GPU de múltiples instancias (MIG) de NVIDIA, y sus diferentes perfiles de MIG se pueden revisar en la documentación pública. Si implementas LLMs pequeños, te recomendamos que verifiques sus tamaños (en memoria) y que particiones las GPUs según corresponda. El esquema de partición de un grupo de nodos se define en su recurso personalizado Cluster. Para obtener más información sobre cómo aplicar un esquema de partición de GPU, consulta Agrega un grupo de nodos. Si eres operador de aplicaciones (AO), consulta a tu administrador de la plataforma (PA) sobre los aceleradores instalados y disponibles en tu proyecto o clúster. Puedes encontrar más detalles sobre cómo configurar un contenedor para usar recursos de GPU y cómo verificar la asignación de recursos de GPU.

La precisión predeterminada del modelo Gemma 3 4B es de 16 bits. Según esta tabla publicada por Google, el requisito de memoria de GPU para este LLM es de 6.4 GB, con una precisión de BF16 (16 bits).

En el ollama-gemma3.yaml anterior, conectamos una porción de GPU de 10 GB (NVIDIA A100) al contenedor, ya que esta cantidad de memoria VRAM es suficiente para cargar el modelo Gemma 3 4B y ejecutarlo, como se muestra a continuación:

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 ...

Implementa el backend de Ollama y exponlo como un servicio

Conéctate a tu clúster y configura el contexto en el espacio de nombres de tu proyecto:

# 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

Aplica el manifiesto de Ollama:

kubectl apply -f ollama-gemma3.yaml

Asegúrate de que el Pod de Ollama esté en ejecución y de que el servicio asociado esté en su lugar:

kubectl get pods

Resultado de muestra:

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

kubectl get service

Resultado de muestra:

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

Toma nota del EXTERNAL-IP del servicio de Ollama (por ejemplo, 10.0.0.1) del resultado anterior. También puedes imprimirlo con el siguiente comando:

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

Antes de verificar que Ollama Gemma 3 funcione, deberás aplicar una política de red, como la siguiente :

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

Aplica la política de red:

kubectl apply -f ollama-netpol.yaml

Verifica y prueba la implementación de Ollama:

1. Verifica si Ollama se está ejecutando:

   curl http://EXTERNAL_IP:11434
   

   Respuesta esperada: "Ollama is running"

2. Envía una solicitud de finalización:

   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
     }'
   

Solicita inferencias

Ahora que tus back-ends de LLM (vLLM y Ollama) están implementados y son accesibles a través de sus respectivos servicios de LoadBalancer, puedes comenzar a consumirlos para la inferencia.

Según tu caso de uso, tienes varias opciones:

• IU web interactiva: Para realizar pruebas, crear prototipos o brindar a los usuarios una experiencia similar a la de ChatGPT, puedes implementar Open WebUI o un frontend similar.
• Interfaz de línea de comandos (CLI): Para realizar verificaciones rápidas, crear secuencias de comandos o automatizar tareas, puedes usar curl o secuencias de comandos personalizadas.
• Application Integration: Conecta tus aplicaciones internas, agentes de IA o complementos para IDE (por ejemplo, Continue para VS Code/JetBrains) directamente a los extremos compatibles con OpenAI que proporcionan vLLM (/v1) o Ollama (/v1).

1. Interactúa con el LLM a través de una IU

Para proporcionar una interfaz similar a ChatGPT para interactuar con tus modelos, implementa Open WebUI en tu clúster.

Crea la implementación de 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

Aplica la política de red

Debes permitir que tu máquina llegue al servicio de Open WebUI en el puerto 80.

Actualiza la política de tu red de proyectos de PNP para incluir el servicio de open-webui o aplica una política amplia:

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

Verificación

1. Obtén la IP de la IU web:

   kubectl get service open-webui -n NAMESPACE
   

2. Accede a la IU: Abre el navegador y navega a http://WEB_UI_EXTERNAL_IP.

3. Configuración: En el primer acceso, crea una cuenta de administrador. En la configuración, asegúrate de que la conexión de OpenAI apunte a http://gemma-3-4b-it/v1.

4. Selecciona el modelo: En la interfaz de chat, selecciona google/gemma-3-4b-it en el menú desplegable del modelo.

   

2. Realiza solicitudes HTTP con 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
}'

Validación y verificación

Verifica que todos los contenedores y servicios estén en ejecución:

# 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

Pasos para quitar la información

1. Quita todos los recursos de Kubernetes:

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

2. Borra manualmente los contenedores sin usar de tu repositorio de Harbor.

Operaciones

Backend de vLLM

Conceptos básicos de vLLM

vLLM está diseñado como un motor de entrega de un solo modelo de alto rendimiento. No admite la publicación de varios modelos en un solo proceso de servidor ni la definición de varios modelos en un solo comando de inicio. Para entregar más de un modelo (por ejemplo, un modelo de chat y un modelo de incorporación independiente), debes iniciar instancias de vLLM separadas, cada una en su propio pod o contenedor, que se pueden asignar a diferentes GPU o segmentos de GPU. A diferencia de otros backends que pueden intercambiar modelos de forma dinámica, una instancia de vLLM fija su modelo y la memoria caché de KV asociada durante la inicialización para garantizar una capacidad de procesamiento alta y constante, y una latencia baja.

Puedes abrir una terminal en cualquiera de los Pods de vLLM con los siguientes comandos:

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

Se mostrarán los modelos cargados, sus argumentos y sus PIDs :

ps aux | grep vllm

Resultado similar esperado:

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

Si quieres una vista más limpia y "similar a Ollama" sin el desorden del comando grep en sí y los PIDs del sistema, puedes usar esta línea:

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

Respuesta de ejemplo :

google/gemma-3-4b-it

Puedes supervisar el estado de tu implementación de vLLM con los comandos kubectl estándar y consultando los extremos de API internos.

Verificar los registros de Pods

Abre una terminal para ver los registros de inicialización y de servicio:

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

Busca la confirmación de que el servidor está listo:

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

Consultar el estado interno

Dado que vLLM proporciona una API compatible con OpenAI, puedes verificar los modelos cargados y el estado del sistema directamente desde una terminal dentro del clúster (por ejemplo, con un pod debug-sh).

Primero debes iniciar el Pod de depuración. Estas son las instrucciones :

Inicia el Pod de depuración

Ejecuta el siguiente comando para iniciar una shell efímera en el espacio de nombres de tu proyecto. Esta configuración usa la imagen de busybox (que se envió anteriormente a tu registro de Harbor) y, luego, inyecta las credenciales necesarias con la marca --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

Parámetros clave:

• --rm: Borra automáticamente el pod cuando se cierra, lo que preserva los recursos del clúster.
• --overrides: Es obligatorio en entornos aislados para permitir que el pod se autentique con el registro privado de Harbor.

Consultar el estado del servidor del modelo

Una vez dentro del pod, usa la utilidad wget para consultar la API de vLLM. Dado que el servicio de vLLM asigna el puerto interno 8000 al puerto 80, puedes usar el nombre de DNS del servicio:

• List Loaded Models: Verifica que el motor de vLLM se haya inicializado y cargado correctamente los pesos de Gemma 3.

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

  Respuesta correcta:

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

• Verifica el estado de la aplicación: Confirma que el servidor de la API esté listo para procesar solicitudes.

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

  Respuesta correcta:

  OK
  

Conceptos básicos de Ollama

Ollama no admite la carga de varios modelos en la memoria de forma simultánea. Además, si no usas el LLM durante un cierto período (por lo general, 30 minutos de forma predeterminada), Ollama descarga el modelo actual de la memoria.

Debido al comportamiento descrito anteriormente, la solución implementa dos o más backends de Ollama según tus necesidades y casos de uso, de modo que muchos desarrolladores o usuarios puedan usarlos en paralelo sin tener solo una instancia de Ollama que cargue y descargue modelos con frecuencia, lo que produce una latencia innecesaria.

Puedes abrir una terminal en cualquiera de los Pods de Ollama con los siguientes comandos:

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

Dentro de los Pods, puedes usar la CLI de Ollama para explorar los modelos disponibles y ver cuál está cargado:

• En el pod ollama-chat, encontrarás un modelo:

  # 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
  

• En el pod ollama-autocomplete, encontrarás dos modelos:

  # 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
  

• Cuando Ollama descarga su modelo actual, el resultado está vacío:

  # ollama ps
  NAME    ID    SIZE    PROCESSOR    UNTIL
  

Ten en cuenta que Ollama vuelve a cargar un modelo de forma dinámica cuando envías la siguiente solicitud de asistencia con el código, sin ninguna intervención manual.

Importancia de la capacidad de la GPU

Si aprovisionas una porción de una GPU con 10 GB, pero el espacio en memoria del modelo es (ligeramente) mayor, notarás que parte del LLM se carga en la CPU, como se muestra a continuación:

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

Esto no es óptimo y produce una mayor latencia de respuesta, por lo que debes asegurarte de proporcionar el tamaño de GPU sugerido en esta guía.

Nota: Esto solo sucede con Ollama. En el caso de vLLM, si el modelo es demasiado grande para la memoria de GPU asignada, fallará (error OutOfMemory) durante la inicialización. Se niega a ejecutarse en un estado de división de CPU "degradado" porque su función principal PagedAttention requiere VRAM de alta velocidad para funcionar.

LLM

Usa un LLM diferente o tu LLM preferido con vLLM

Para ejecutar diferentes tamaños de Gemma o cualquier otro modelo de lenguaje grande (LLM) de código abierto con vLLM en GDC aislado, como DeepSeek-R1 o Llama 3.1, debes incorporar los nuevos pesos del modelo en tu entorno y actualizar el manifiesto de implementación para que apunte a los nuevos recursos.

Según los procedimientos operativos establecidos para esta solución, sigue estos pasos para cargar un modelo diferente :

1. Descarga los pesos del modelo nuevo:

   En una estación de trabajo con acceso a Internet, usa la CLI de Hugging Face para descargar los pesos del modelo que prefieras.

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

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

   • Para DeepSeek-R1 (7B Distill):

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

   • Para Llama 3.1 (8B):

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

   Nota: Asegúrate de haber aceptado las condiciones de la licencia del modelo en Hugging Face antes de descargarlo.

2. Propaga el volumen persistente (PVC):

   Actualiza tu model-pvc existente o crea uno nuevo con capacidad suficiente para el nuevo modelo. Usa el método de Pod de ayuda para transferir los pesos desde tu estación de trabajo. Los factores de forma más grandes requieren mucho más espacio en el disco. Asegúrate de que tu reclamo de volumen persistente (PVC) tenga capacidad suficiente para almacenar los nuevos pesos.

   • Gemma 3 4B: ~15.2 GB
   • Gemma 3 27B: Alrededor de 54 GB o más
   • Recomendación: Mantén la recomendación de PVC de 500 GiB para garantizar una cantidad alta de IOPS (1,500) para una carga más rápida, independientemente del tamaño del modelo.

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

3. Actualiza el manifiesto de implementación de vLLM:

   Modifica el archivo YAML de implementación de vLLM para hacer referencia al nuevo ID del modelo. A diferencia de Ollama, que puede intercambiar modelos de forma dinámica, una instancia de vLLM se dedica a un solo modelo y debe actualizarse o volver a implementarse para cambiar de modelo.

   Actualiza la sección de argumentos de tu implementación según el modelo que uses. Aquí se muestra deepseek como ejemplo:

   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. Ajusta los recursos de GPU y memoria:

   Los modelos más grandes requieren más VRAM para los pesos y la caché de KV. Si cambias de un modelo de 4B a uno de 8B o 14B, asegúrate de que los límites de recursos sean suficientes para evitar fallas por "memoria insuficiente".

   • Huella de VRAM: Con una precisión de 16 bits, un modelo de 8B requiere aproximadamente 16 GB solo para los pesos, además de memoria adicional para la caché de vLLM.PagedAttention
   • Recomendación: Usa una GPU A100 completa (nvidia.com/gpu-pod-NVIDIA_A100_80GB_PCIE: 1) para los modelos con más de 7 mil millones de parámetros para garantizar un rendimiento óptimo y espacio libre para la caché de KV.

5. Verifica el modelo nuevo:

   Una vez que la implementación haya terminado de conciliarse, verifica que el modelo nuevo esté activo con la API interna:

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

   Respuesta correcta:

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

Cómo incorporar un LLM diferente con Ollama

Si quieres probar un LLM de código abierto diferente, como un modelo de las familias Llama 3.2 o DeepSeek-R1, modifica este comando de Ollama en el Dockerfile anterior:

ollama pull gemma3:latest

Por ejemplo, si quieres extraer Llama 3.2 con 3,000 millones de parámetros, usa este comando:

ollama pull llama3.2:3b

O, si prefieres usar DeepSeek-R1 con 8,000 millones de parámetros, usa este comando:

ollama pull deepseek-r1:8b

También puedes descargar más de un LLM y tener sus pesos del modelo en contenedores. Luego, Ollama podrá cambiar entre los modelos a medida que solicites inferencias con diferentes modelos precargados. Por ejemplo, puedes agregar los modelos Gemma y Llama a tu imagen de Docker. Recuerda que, en un entorno aislado, un backend de Ollama no tiene acceso a la biblioteca de Ollama para descargar ningún modelo en ningún momento.

Recuerda revisar y aceptar cada licencia de modelo y condiciones de uso antes de ejecutarlos en tus aplicaciones. Hay muchos LLM en la biblioteca de Ollama. Solo necesitarás una conexión a Internet para descargar los pesos del modelo mientras compilas la imagen de Docker del backend del LLM.

Abre la IU web

Comprueba si el pod de Open WebUI está en estado de ejecución :

kubectl get pods -n NAMESPACE

Resultado esperado :

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

Verifica la IP del servicio :

kubectl get service -n NAMESPACE

Resultado esperado:

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

En las siguientes secciones, se muestra cómo usar las principales funciones de la IU.

Cómo escalar la solución con un backend de Ollama

Verticalmente

• Asigna una porción de GPU más grande a tu LLM, que se convirtió en un cuello de botella, hasta que uses una GPU completa.
• Si quieres usar un LLM más grande para obtener una mejor precisión en las respuestas, por ejemplo, un LLM con 405 mil millones de parámetros en lugar de uno con 7 mil millones, es posible que necesites más de una GPU para ejecutarlo sin problemas.
• Los modelos que se ajustan a más de una GPU experimentan cierta latencia relacionada con la comunicación entre GPU.

Horizontalmente

• Implementa tantos Pods de Ollama como necesites para alcanzar el rendimiento objetivo en un LLM determinado.
  • Para lograr esto, aumenta la cantidad de replicas en el archivo YAML de implementación de Ollama correspondiente.
• El servicio de Kubernetes, que es de tipo LoadBalancer, distribuirá las solicitudes de asistencia de código entre los extremos (es decir, los Pods) y devolverá sus respuestas respectivas a través de la IP externa expuesta.
• Recuerda que el complemento Continue apunta a una sola dirección IP por funcionalidad.

Para escalar el backend de vLLM en tu entorno aislado de GDC, puedes seguir una estrategia similar a la que se usa para Ollama, enfocándote en la asignación de recursos de hardware y la replicación de pods.

Cómo escalar la solución con un backend de vLLM

Verticalmente

• Actualiza la asignación de GPU: Si la capacidad de procesamiento de la inferencia (tokens/s) se convierte en un cuello de botella, asigna una porción de GPU más grande hasta que uses una GPU NVIDIA A100 completa.
• Configuraciones de varias GPUs: Para modelos masivos (por ejemplo, de 70 mil millones a 405 mil millones de parámetros) que no caben en la memoria de una sola GPU A100 de 80 GB, debes escalar a varias GPUs con el paralelismo de tensor.
• Consideración sobre la latencia: Ten en cuenta que los modelos que abarcan más de una GPU pueden experimentar una ligera sobrecarga relacionada con la comunicación entre GPU (por ejemplo, la sincronización de NCCL).

Horizontalmente

• Aumenta la capacidad de procesamiento con réplicas: Para controlar un mayor volumen de solicitudes de usuarios simultáneas para el mismo modelo, aumenta el recuento de replicas en tu YAML de implementación de vLLM.
• Instancias de modelos dedicadas: Dado que vLLM está diseñado como un motor de servicio de un solo modelo y fija su memoria caché de KV tras la inicialización, debes implementar un conjunto separado de pods para cada LLM diferente que desees alojar.
• Balanceo de cargas: El servicio de Kubernetes de GDC (tipo LoadBalancer) distribuirá automáticamente las solicitudes de inferencia entrantes entre todos los extremos de Pod de vLLM en buen estado asociados con ese servicio.

Soluciona problemas

Error	Mitigación
FALLA EN LA AUTOPRUEBA DE FIPS	Ocurre cuando bibliotecas como BoringSSL no tienen firmas de integridad. Soluciona el problema configurando BORINGSSL_FIPS=0 y utilizando imágenes oficiales de vLLM
Carga de peso detenida	Verifica si hay regulación de IOPS en los PVC pequeños. Se requiere un volumen de 500 GiB para la inicialización del modelo de rendimiento.
Se rechazó la conexión	Confirma que el PNP permite de forma explícita el targetPort (8000/8080). Los firewalls de GDC no otorgan acceso automáticamente a los puertos de backend para las VIP del balanceador de cargas.