Explicación de los modelos de lenguajes grandes: cómo funcionan los LLM y cómo ejecutar los suyos propios en Kubernetes

Una guía en inglés sencillo sobre modelos de lenguaje grande: qué son, cómo funcionan realmente y cómo ejecutar el suyo propio en Kubernetes. Escrito tanto para gerentes no técnicos como para ingenieros: lea las analogías y luego acceda al YAML cuando esté listo para implementar.

1. ¿Qué es realmente un modelo de lenguaje grande?

Imagina el autocompletado en tu teléfono. Escribes "Te llamaré cuando llegue" y te sugiere "casa". Se trata de un modelo de lenguaje diminuto: ha visto muchos mensajes de texto y ha aprendido qué palabras tienden a seguir a cada una. A Grande Language Model es la misma idea ampliada en un factor de millones: entrenada no en sus textos sino en una gran parte de la Internet pública, libros, códigos y documentación.

la palabra "grande" está haciendo un trabajo real. Estos modelos contienen miles de millones de números internos (llamados parámetros) que se sintonizan durante el entrenamiento. Cuando la gente dice que un modelo es "7B" o "70B", se refieren a 7 000 millones o 70 000 millones de parámetros. Más parámetros generalmente significan más capacidad y un mayor apetito por la memoria y la computación.

Un modelo mental útil para directivos: un LLM es un asistente graduado incansable y muy leído. Ha leído más de lo que cualquier humano podría jamás, redacta rápidamente y nunca se aburre, pero a veces dice con total confianza cosas que simplemente están mal y no recuerda el ayer a menos que usted se lo recuerde.

2. Cómo funcionan realmente

Debajo del capó hay cinco ideas. No necesitas matemáticas para seguirlos: cada uno tiene una analogía cotidiana.

2.1 Fichas: cortar texto en pedazos

Los modelos no leen palabras completas. Dividen el texto en fichas: fragmentos comunes de personajes. "Kubernetes" podría convertirse Kub + ernetes; "correr" podría ser run + ning. Apenas, 1 ficha ≈ 0,75 palabras en inglés, por lo que 1000 tokens son aproximadamente 750 palabras. Esto es importante comercialmente: las API alojadas facturan por token y el precio de un modelo ventana contextual (cuánto puede "ver" a la vez) se mide en fichas.

2.2 Incrustaciones: convertir palabras en coordenadas de significado

Cada ficha se convierte en una larga lista de números: una incrustar - que representa su significado como un punto en el espacio. Las palabras utilizadas de manera similar terminan cerca unas de otras. "Rey" y "reina" se sientan muy juntos; "rey" y "plátano" están muy separados. Así puede manipular una máquina que sólo hace aritmética significado: el significado se ha convertido en geometría.

2.3 El transformador y la "atención": el gran avance de 2017

La arquitectura detrás de cada LLM moderno es la Transformador. Su truco clave se llama atención: al procesar una palabra, el modelo vuelve a mirar cada dos palabras de la oración y decide cuáles son relevantes. En "El trofeo no cabía en la maleta porque él era demasiado grande", la atención es lo que permite al modelo determinar que "eso" se refiere al trofeo, no a la maleta. La atención es la razón por la que estos modelos manejan tan bien el contexto, los matices y las referencias de largo alcance, y por qué necesitan tanto cálculo, porque cada palabra atiende a las demás.

2.4 Formación: tres etapas

1. Pre-entrenamiento: Al modelo se le muestran miles de millones de oraciones con la última palabra oculta y se le pide que la adivine. Hágalo mal, modifique los parámetros, repita, billones de veces. Aquí es donde absorbe gramática, hechos, patrones de razonamiento y código. También es la parte cara, que cuesta millones de libras en tiempo de GPU.
2. Sintonia FINA: Luego, el modelo sin procesar se entrena con ejemplos seleccionados de comportamiento útil de preguntas y respuestas, por lo que actúa como un asistente en lugar de un autocompletado.
3. Alineación (RLHF): Finalmente, los humanos clasifican las respuestas del modelo y esa retroalimentación se utiliza para hacerlo más útil, honesto y seguro. Por eso un modelo de chat rechaza solicitudes dañinas y adopta un tono coherente.

2.5 Inferencia: cómo te responde

Cuando envías un mensaje, el modelo genera la respuesta. una ficha a la vez: predice el siguiente token más probable, lo agrega, luego predice el siguiente, y así sucesivamente, como una persona rápida y culta que escribe palabra por palabra sin planificar primero la oración completa. Un escenario llamado temperatura controla lo aventurero que es: la baja temperatura proporciona respuestas seguras y repetibles (buenas para codificación y extracción); La temperatura alta da respuestas creativas y variadas (buena para la lluvia de ideas). Este proceso token por token se llama inferencia, y es la parte que paga en producción: cada solicitud quema ciclos de GPU.

3. ¿En qué son buenos y malos los LLM?

Conocer los bordes de la herramienta evita errores costosos.

La solución para la mayoría de estos es RAG (Generación aumentada de recuperación): en lugar de confiar en la memoria del modelo, obtiene documentos relevantes de sus propios sistemas y los pega en el mensaje, para que el modelo responda de tus datos. Así es como construyes un chatbot a través de tu wiki interna sin que el modelo invente las cosas.

4. El vocabulario, decodificado

5. ¿Por qué realizar tu propio LLM?

Las API alojadas (OpenAI, Anthropic y otras) son la forma más rápida de comenzar y son excelentes. Pero hay cuatro razones por las que las organizaciones eligen albergar un modelo de pesos abiertos como Llama, Mistral, Qwen o Gemma:

• Privacidad y cumplimiento de datos. Los datos confidenciales nunca abandonan su red, lo que es importante para el sector sanitario, financiero, jurídico y público.
• Costo a escala. Por encima de un cierto volumen de solicitudes constante, una GPU de su propiedad puede ser más barata por token que pagar una API.
• Control y estabilidad. El modelo nunca cambia debajo de usted y usted no está sujeto a los límites de tarifas ni a las depreciaciones de un proveedor.
• Latencia y uso sin conexión. Inferencia junto a su aplicación o localmente sin dependencia de Internet.

La compensación es que ahora eres dueño del hardware, el escalamiento y la confiabilidad – que es exactamente en lo que Kubernetes es bueno.

6. La realidad del hardware (lea esto antes de implementar)

Los pesos de un LLM deben caber en la memoria de la GPU (VRAM). Una regla general aproximada:

Dos motores de servicio dominan las implementaciones reales:

• Ollama - la rampa de acceso más fácil. Excelente para desarrollo, herramientas internas y nodos de CPU o GPU única. Extrae modelos cuantificados con un solo comando.
• vllm – el caballo de batalla de la producción. Alto rendimiento, agrupa muchas solicitudes y expone una API compatible con OpenAI para que su código existente funcione con un cambio de URL de una línea. (Hugging Face TGI es una alternativa cercana).

7. Implementar su propio LLM en Kubernetes

Todo lo siguiente supone un clúster con al menos un nodo GPU y el Complemento de dispositivo NVIDIA instalado, que expone las GPU como recurso programable nvidia.com/gpu. Lo iremos construyendo pieza a pieza.

7.1 Un espacio de nombres y un lugar para almacenar pesos de modelos.

Los archivos de modelo son grandes (gigabytes) y se descargan lentamente, por lo que los almacenamos en caché en un Reclamación de volumen persistente en lugar de volver a tirar en cada reinicio del pod.

apiVersion: v1
kind: Namespace
metadata:
  name: llm
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: model-cache
  namespace: llm
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi          # weights are big; size generously
  # storageClassName: fast-ssd   # use an SSD class if your cluster offers one

7.2 Opción A — Ollama (el comienzo fácil)

Ollama es ideal para una primera implementación o una herramienta interna. Esto lo ejecuta con una GPU; eliminar el nvidia.com/gpu límite para ejecutar solo CPU en un nodo robusto.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama
  namespace: llm
  labels:
    app: ollama
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
        - name: ollama
          image: ollama/ollama:latest
          ports:
            - containerPort: 11434
          resources:
            requests:
              cpu: "2"
              memory: 8Gi
            limits:
              nvidia.com/gpu: 1        # remove this line for CPU-only
              memory: 16Gi
          volumeMounts:
            - name: models
              mountPath: /root/.ollama
          readinessProbe:
            httpGet:
              path: /
              port: 11434
            initialDelaySeconds: 10
            periodSeconds: 10
      volumes:
        - name: models
          persistentVolumeClaim:
            claimName: model-cache
---
apiVersion: v1
kind: Service
metadata:
  name: ollama
  namespace: llm
spec:
  selector:
    app: ollama
  ports:
    - port: 80
      targetPort: 11434

Una vez que el pod se esté ejecutando, introduzca un modelo en el caché y charle con él:

# pull a quantized model into the PVC (one-off)
kubectl -n llm exec deploy/ollama -- ollama pull llama3

# ask it something from inside the cluster
kubectl -n llm exec deploy/ollama -- \
  ollama run llama3 "Explain Kubernetes in one sentence."

7.3 Opción B: vLLM (rendimiento de producción, compatible con OpenAI)

Para el tráfico real, vLLM atiende muchas solicitudes simultáneas de manera eficiente y habla el dialecto API de OpenAI. Los modelos cerrados (como Llama) necesitan una ficha de Cara abrazadora, almacenada como Secreto.

apiVersion: v1
kind: Secret
metadata:
  name: hf-token
  namespace: llm
type: Opaque
stringData:
  token: "hf_xxxxxxxxxxxxxxxxxxxxxxxx"   # your Hugging Face access token
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-mistral
  namespace: llm
  labels:
    app: vllm-mistral
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-mistral
  template:
    metadata:
      labels:
        app: vllm-mistral
    spec:
      containers:
        - name: vllm
          image: vllm/vllm-openai:latest
          args:
            - "--model"
            - "mistralai/Mistral-7B-Instruct-v0.3"
            - "--max-model-len"
            - "8192"
            - "--gpu-memory-utilization"
            - "0.90"
          ports:
            - containerPort: 8000
          env:
            - name: HUGGING_FACE_HUB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-token
                  key: token
          resources:
            limits:
              nvidia.com/gpu: 1
          volumeMounts:
            - name: cache
              mountPath: /root/.cache/huggingface
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            initialDelaySeconds: 60      # first start downloads weights
            periodSeconds: 15
            failureThreshold: 40
      volumes:
        - name: cache
          persistentVolumeClaim:
            claimName: model-cache
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-mistral
  namespace: llm
spec:
  selector:
    app: vllm-mistral
  ports:
    - port: 80
      targetPort: 8000

Debido a que vLLM es compatible con OpenAI, el código de la aplicación solo necesita la URL del clúster, sin cambios en el SDK:

curl http://vllm-mistral.llm.svc.cluster.local/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistralai/Mistral-7B-Instruct-v0.3",
    "messages": [{"role": "user", "content": "Summarise our refund policy."}],
    "temperature": 0.2
  }'

7.4 Exponerlo con un Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: llm-api
  namespace: llm
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "300"   # long generations
spec:
  ingressClassName: nginx
  rules:
    - host: llm.internal.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: vllm-mistral
                port:
                  number: 80

7.5 Escalado: y por qué es diferente con las GPU

Puedes escalar automáticamente, pero recuerda cada réplica necesita su propia GPU completa – No puedes compartir uno fraccionariamente en el caso simple, y no tiene sentido escalar más allá de las GPU que tienes físicamente. Escale en una cola o señal de tasa de solicitud (KEDA es excelente aquí) en lugar de CPU.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-mistral
  namespace: llm
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-mistral
  minReplicas: 1
  maxReplicas: 4          # never exceed the number of GPUs in the cluster
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
  # For real LLM scaling, prefer KEDA on a queue depth or
  # requests-per-second metric exported by vLLM, not CPU.

8. Una lista de verificación de implementación pragmática

1. Prototipo en una API alojada para validar el caso de uso antes de comprar GPU.
2. Elija un modelo de pesos abiertos que se ajuste a su hardware (comience con un modelo 7–8B, cuantificado).
3. Empieza con Ollama para un piloto interno; graduarse de vllm cuando necesita rendimiento.
4. Agregar trapo sobre sus propios documentos para eliminar las alucinaciones y mantener las respuestas actualizadas.
5. Mantenga a un humano informado donde una respuesta incorrecta conlleva un costo real.
6. Medir el costo de inferencia y la latencia por solicitud: esa es su verdadera economía unitaria.