Modelos Locales con Ollama: Cuantización GGUF y Hardening

El Dilema Arquitectónico: Cloud APIs vs. Inferencia Local Autohospedada

La adopción de modelos de lenguaje en entornos corporativos suele comenzar consumiendo APIs de nube pública gestionadas por terceros (OpenAI, Anthropic, Google Cloud Vertex AI, AWS Bedrock). Estas APIs ofrecen despliegues inmediatos sin inversión previa en infraestructura ni gestión de aceleradores de hardware. Sin embargo, a medida que las cargas de trabajo alcanzan volúmenes masivos de tokens o procesan información altamente sensible (datos bancarios, historiales clínicos, propiedad intelectual de código fuente), el modelo de Cloud APIs revela fricciones severas:

• Soberanía del Dato y Cumplimiento Normativo: Regulaciones como el RGPD europeo, NIS2 o el Esquema Nacional de Seguridad (ENS) imponen limitaciones estrictas sobre la transferencia transfronteriza y el procesamiento de datos corporativos en centros de datos de terceros.
• Coste Marginal Predictible: A gran escala, el coste por millón de tokens en APIs propietarias supera exponencialmente la amortización de servidores dedicados con GPUs para inferencia local.
• Garantías de Latencia y Disponibilidad: Las APIs públicas sufren de congestión de red, degradación por límites de cuota (rate limiting) y caídas imprevistas de servicio fuera del control de la organización.
• Riesgo de Filtración a Conjuntos de Entrenamiento: La desconfianza legítima sobre si los prompts y documentos confidenciales enviados a APIs externas pueden ser utilizados directa o indirectamente para entrenar futuros modelos fundacionales.

La alternativa técnica reside en la inferencia local autohospedada, impulsada por frameworks como Ollama, llama.cpp y vLLM. No obstante, ejecutar modelos con decenas de miles de millones de parámetros en servidores locales exige dominar la técnica que hace viable este despliegue: la cuantización de pesos.

---

La Física de la Cuantización: De FP32 a Formatos GGUF y AWQ

Un modelo de lenguaje es, en esencia, un grafo de operaciones tensoriales compuesto por matrices de pesos. En precisión estándar de entrenamiento (FP32 - punto flotante de 32 bits de precisión simple), cada parámetro requiere 4 bytes de memoria.

Para cargar un modelo de 70.000 millones de parámetros (70B) en FP32 se necesitarían:

$70 \times 10^9 \text{ parámetros} \times 4 \text{ bytes} = 280 \text{ GB de memoria}$

Incluso en media precisión (FP16 o BF16, 2 bytes por parámetro), el modelo requiere 140 GB de VRAM, obligando a disponer de al menos dos tarjetas de cómputo empresarial NVIDIA A100/H100 de 80 GB, cuyo coste supera los 60.000 euros.

¿Por qué la Inferencia de LLMs está Limitada por el Ancho de Banda?

A diferencia del entrenamiento (que está limitado por la capacidad de cálculo en operaciones por segundo - FLOPS), la inferencia autoregresiva token a token está *estrictamente limitada por el ancho de banda de la memoria (Memory Bandwidth Bound). Para generar un único token, el procesador debe transferir la totalidad de los pesos del modelo desde la memoria (VRAM o RAM) hasta los núcleos de cálculo de la GPU. Cuanto menor sea el peso en bytes de cada parámetro, más rápido se transfiere el modelo y mayor es la velocidad de generación (tokens por segundo*).

Formatos de Cuantización Modernos:

1. GGUF (GPT-Generated Unified Format): El estándar binario diseñado por Georgi Gerganov para llama.cpp y adoptado por Ollama. GGUF almacena la arquitectura del modelo, los hiperparámetros, el vocabulario del tokenizador y los tensores cuantizados en un único fichero autocontenido.
2. K-Quants (Q4KM, Q5KM, Q80): Cuantización por bloques con factores de escala adaptativos. El formato Q4K_M (4 bits medio) utiliza 4 bits para los pesos de los bloques de atención menos críticos y 6 bits para los bloques de mayor sensibilidad semántica, reduciendo el tamaño en disco y memoria a solo ~0,6 bytes por parámetro con una pérdida de perplejidad prácticamente imperceptible (< 0,05 puntos frente a FP16).
3. AWQ (Activation-aware Weight Quantization): Protege el 1% de los pesos más importantes analizando la magnitud de las activaciones durante una pasada de calibración, siendo el formato preferido para servidores de inferencia continua de alto rendimiento como vLLM.

Precisión	Bits / Parámetro	VRAM Requerida (Modelo 8B)	VRAM Requerida (Modelo 70B)	Pérdida de Perplejidad
FP16	16 bits (2 bytes)	16 GB	140 GB	Línea base (0,00)
Q8_0	8 bits (1 byte)	8,5 GB	72 GB	Despreciable (< 0,01)
Q5KM	~5,5 bits	6,0 GB	48 GB	Mínima (< 0,03)
Q4KM	~4,5 bits	5,0 GB	41 GB	Excelente compromiso (< 0,05)
Q2_K	~2,5 bits	3,2 GB	24 GB	Degradación notable (> 0,35)

---

Arquitectura de Inferencia con Ollama y Descarga Mixta a GPU

Ollama encapsula la complejidad de compilación y optimización de llama.cpp bajo una interfaz de línea de comandos y un servidor HTTP REST compatible con los endpoints de OpenAI (/v1/chat/completions).

Una de sus mayores ventajas técnicas es la *descarga parcial de capas (Layer Offloading)*: si el modelo cuantizado no cabe completamente en la VRAM de la GPU, Ollama carga tantas capas del Transformer como sea posible en la memoria de vídeo de la GPU y descarga las capas restantes en la memoria RAM del sistema utilizando instrucciones SIMD de la CPU (AVX-512, AMX o Apple Metal):

graph TD
    subgraph Client_Layer ["🖥️ Cliente / Aplicación Corporativa"]
        App["Microservicio / Chatbot / Agente MCP"]
    end

    subgraph Reverse_Proxy ["🛡️ Capa Perimetral de Seguridad (Nginx / Envoy)"]
        WAF["WAF + Rate Limiting"]
        Auth["Validación mTLS / API Key"]
    end

    subgraph Host_System ["⚙️ Servidor Local de Inferencia"]
        LocalSocket["Socket Local Cero-Red: 127.0.0.1:11434"]
        OllamaServer["Daemon Ollama (Runtime llama.cpp)"]

        subgraph Memory_Allocation ["Distribución Híbrida de Memoria"]
            VRAM["Memoria GPU VRAM (Capas 0 a 28) - Rápido"]
            RAM["Memoria Sistema RAM (Capas 29 a 32) - CPU AVX-512"]
        end

        Storage["Modelos GGUF Almacenados en NVMe Cifrado"]
    end

    App -->|HTTPS TLS 1.3 + Client Cert| Auth
    Auth --> WAF
    WAF -->|Proxy Pass Interno| LocalSocket
    LocalSocket --> OllamaServer
    OllamaServer --> Storage
    OllamaServer --> VRAM
    OllamaServer --> RAM

    classDef client fill:#e1f5fe,stroke:#0288d1,stroke-width:2px;
    classDef proxy fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
    classDef host fill:#e8f5e9,stroke:#388e3c,stroke-width:2px;
    classDef memory fill:#fff3e0,stroke:#f57c00,stroke-width:2px;

    class App client;
    class WAF,Auth proxy;
    class LocalSocket,OllamaServer,Storage host;
    class VRAM,RAM memory;

---

La Amenaza Crítica: Endpoints de Ollama Expuestos en Internet (Puerto 11434)

Por diseño y conveniencia para desarrolladores, Ollama carece por completo de capa de autenticación, autorización o control de acceso nativo. Si se despliega en un servidor cloud o en una estación de trabajo accesible públicamente sin cortafuegos, cualquier actor en Internet puede interactuar con el puerto TCP 11434.

En escáneres globales como Shodan y Censys, se detectan habitualmente miles de instancias de Ollama expuestas a Internet con 0.0.0.0:11434.

Vectores de Ataque Inmediatos en Instancias Expuestas:

1. Exfiltración de Modelos Privados: La API /api/show y /api/tags lista todos los modelos instalados. Mediante la API /api/blobs, un atacante puede descargar los pesos binarios de modelos ajustados (fine-tuned) con datos corporativos confidenciales.
2. Denegación de Servicio y Agotamiento de Disco: Cualquier atacante puede enviar solicitudes POST a /api/pull ordenando al servidor descargar modelos pesados de 70B o 405B, agotando el espacio en disco del servidor en minutos y provocando caídas críticas en el sistema operativo.
3. *Secuestro de Recursos de Cómputo (Compute Hijacking):* Uso no autorizado de las GPUs corporativas para ejecutar inferencia o tareas de generación masiva gratuitas a expensas de la factura eléctrica o cloud de la víctima.
4. Server-Side Request Forgery (SSRF): Forzar al servidor Ollama a conectarse a registros de modelos maliciosos o direcciones IP internas de la red corporativa.

---

Hardening Empresarial: Securización de Ollama Paso a Paso

Para desplegar Ollama o vLLM en producción de forma conforme con los estándares corporativos, deben implementarse las siguientes capas de contención:

1. Vincular el Servicio Estrictamente a localhost

Por defecto en Linux, la variable de entorno OLLAMA_HOST debe fijarse para escuchar única y exclusivamente en la interfaz de bucle invertido (127.0.0.1), impidiendo el enlace con interfaces públicas:

En la configuración del servicio systemd /etc/systemd/system/ollama.service.d/override.conf:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_ORIGINS=https://app.empresa.local"
Environment="OLLAMA_MODELS=/var/lib/ollama/models"
# Restringir permisos de proceso
ProtectSystem=strict
ProtectHome=true
NoNewPrivileges=true
PrivateTmp=true

2. Proxy Reverso con Nginx: Autenticación, TLS 1.3 y mTLS

Cualquier acceso remoto hacia el servicio debe canalizarse a través de un proxy reverso que aplique autenticación fuerte por API Key y cifrado TLS 1.3, como detallamos en nuestra guía sobre TLS y mTLS en servicios empresariales:

# /etc/nginx/conf.d/ollama-secure.conf
server {
    listen 443 ssl http2;
    server_name llm.empresa.local;

    ssl_certificate /etc/ssl/certs/llm-server.crt;
    ssl_certificate_key /etc/ssl/private/llm-server.key;
    ssl_protocols TLSv1.3;

    # Exigir certificado de cliente (mTLS Zero Trust)
    ssl_client_certificate /etc/ssl/certs/internal-ca.crt;
    ssl_verify_client on;

    # Limitar tasa de solicitudes para prevenir DoS
    limit_req_zone $binary_remote_addr zone=llm_limit:10m rate=10r/s;

    location / {
        limit_req zone=llm_limit burst=20 nodelay;

        # Bloquear endpoints administrativos peligrosos desde el exterior
        location ~ ^/(api/pull|api/delete|api/push) {
            return 403 "Forbidden: Administrative operations are disabled remotely.";
        }

        # Validación de cabecera de autenticación estricta
        if ($http_authorization != "Bearer MI_SECRETO_EMPRESARIAL_SEGURO_2026") {
            return 401 "Unauthorized: Invalid or missing API Key.";
        }

        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # Configuración para streaming SSE fluido sin buffering
        proxy_buffering off;
        proxy_cache off;
        proxy_read_timeout 600s;
    }
}

3. Despliegue en Contenedor Docker Hardened

Si se opta por desplegar Ollama dentro de un contenedor Docker, este debe aislarse siguiendo las directivas de hardening de contenedores Docker:

• No mapear el puerto directamente a 0.0.0.0 (emplear 127.0.0.1:11434:11434).
• Ejecutar el contenedor bajo usuario no privilegiado.
• Desactivar la capacidad de escalada de privilegios (--security-opt=no-new-privileges:true).

---

Invocación Segura mediante Python y SDK Compatible con OpenAI

Una vez protegido el endpoint tras el proxy reverso, los desarrolladores y microservicios pueden invocar el modelo local empleando el SDK oficial de OpenAI, garantizando portabilidad absoluta:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://llm.empresa.local/v1",
    api_key=os.environ.get("INTERNAL_LLM_API_KEY", "MI_SECRETO_EMPRESARIAL_SEGURO_2026"),
)

response = client.chat.completions.create(
    model="llama3.1:8b-instruct-q5_K_M",
    messages=[
        {"role": "system", "content": "Eres un asistente de ciberseguridad corporativo."},
        {"role": "user", "content": "¿Cómo mitigar el riesgo de endpoints de inferencia expuestos?"}
    ],
    temperature=0.2,
    max_tokens=500
)

print(response.choices[0].message.content)

---

Checklist de Hardening para Inferencia Local en Producción

• [x] El daemon Ollama/vLLM escucha estrictamente en 127.0.0.1:11434, nunca en interfaces comodín 0.0.0.0.
• [x] El cortafuegos del host (UFW, iptables o AWS Security Group) bloquea cualquier tráfico entrante directo al puerto 11434.
• [x] El acceso remoto está intermediado por un proxy inverso (Nginx/Envoy) con cifrado TLS 1.3 y autenticación obligatoria.
• [x] Los endpoints administrativos destructivos (/api/pull, /api/delete) están bloqueados para clientes externos.
• [x] Se emplea autenticación mutua mTLS para comunicaciones máquina a máquina en la red corporativa.
• [x] Los pesos de los modelos y los datos del sistema residen en volúmenes NVMe con cifrado en reposo (LUKS o AWS KMS).

Si necesitas diseñar infraestructuras de inferencia de IA soberanas, optimizar modelos locales mediante cuantización avanzada o auditar la seguridad de servidores de modelos frente a accesos no autorizados, puedes consultar mis Servicios de Ciberseguridad y Consultoría o ponerte en contacto conmigo a través de Sobre mí.