01 — [ inference ]

Modelos locales vs APIs: cálculo real de coste, privacidad y hardware propio

Análisis técnico y financiero para decidir entre desplegar hardware propio (vLLM, Mac Studio, GPUs) o consumir APIs comerciales bajo acuerdos de confidencialidad.

Equipo Personnn 6 min de lectura

La trampa del análisis superficial: privacidad contractual vs física

El debate entre consumir modelos propietarios vía API (OpenAI, Anthropic, Mistral) o desplegar infraestructura interna suele abordarse desde dos extremos viciados: la complacencia legal o la paranoia de infraestructura.

Por un lado, los departamentos legales poco técnicos asumen que marcar la casilla de Zero Data Retention (ZDR) en los contratos empresariales de OpenAI o Azure elimina cualquier riesgo de fuga. Por otro, los equipos de sistemas tienden a pedir presupuestos desmedidos para clusters de servidores con GPUs Nvidia H100 sin calcular el coste operativo real (OPEX) del personal cualificado para mantenerlos levantados.

Para empresas que gestionan secretos industriales, código fuente propietario o datos bajo estrictos Acuerdos de Confidencialidad (NDAs), la decisión técnica debe regirse por tres variables no negociables: vector de ataque de exfiltración, throughput sostenido (tokens/segundo) y depreciación del hardware.


La realidad del hardware propio: Números duros más allá del silicio

Existe una corriente reciente que sugiere adquirir máquinas Apple Silicon (Mac Studio con chips M2/M3 Ultra y 192 GB de memoria unificada) o ensamblar rigs locales con dos o cuatro GPUs Nvidia RTX 4090 de 24 GB. Analicemos la viabilidad técnica de ambos escenarios.

1. El clúster Mac Studio (Memoria unificada vs ancho de banda)

Un Mac Studio M2 Ultra con 192 GB de memoria unificada permite cargar en RAM modelos densos de 70B parámetros cuantizados a 4 o 8 bits (usando llama.cpp o MLX).

  • Ventaja: Inversión de capital fija accesible (alrededor de 7.000 € por nodo) y consumo eléctrico insignificante (~150-200W bajo carga).
  • Cuello de botella: El ancho de banda de memoria (~800 GB/s) limita drásticamente la latencia por token cuando atiendes a múltiples usuarios concurrentes. Carece de soporte nativo para técnicas de PagedAttention eficientes a gran escala como las que ofrece vLLM o TensorRT-LLM.
  • Veredicto: Excelente para estaciones de desarrollo individual o flujos por lotes nocturnos no críticos; inviable para servir como backend de una aplicación empresarial con más de 5 usuarios concurrentes.

2. Estaciones de trabajo con GPUs de consumo (Nvidia RTX 4090)

  • Ventaja: Soporte completo del ecosistema CUDA, compatibilidad directa con vLLM y un ancho de banda de 1.008 GB/s por tarjeta.
  • Cuello de botella: 24 GB de VRAM por tarjeta. Para correr un modelo Llama 3.1 70B en 4 bits (AWQ/GPTQ) requieres al menos dos tarjetas sólo para el peso del modelo y un buffer mínimo de KV Cache. Al no contar con soporte NVLink en la serie 40, la comunicación tensor-paralela viaja sobre el bus PCIe, introduciendo latencias de interconexión severas si la placa base no cuenta con suficientes líneas PCIe dedicadas (Gen 4/5 a x16/x16).

Cálculo del TCO (Total Cost of Ownership) a 24 meses

Levantar un servidor rack propio con 4x RTX 4090 o 2x Nvidia A6000 Ada implica:

  1. Hardware e infraestructura: Servidor bare-metal base, refrigeración adecuada, SAIs/UPS dedicados (~18.000 € - 30.000 €).
  2. Electricidad y climatización: Consumo sostenido de ~1.5 kW. A 0,18 €/kWh son aproximadamente 2.300 € anuales solo en energía directa, más el factor de eficiencia de refrigeración (PUE).
  3. Mantenimiento e ingeniería: Tiempo de ingeniería sénior para parches de CUDA, compilación de kernels, actualizaciones de drivers y monitoreo de caída del servicio.

Si tu volumen no satura la GPU las 24 horas del día, el coste por millón de tokens procesados en hardware propio es con frecuencia de 4 a 10 veces más alto que el coste de inferencia bajo demanda vía API.


Arquitectura recomendada: El proxy de inferencia privado

Para la mayoría de organizaciones con contratos de confidencialidad estrictos, la solución de ingeniería no es aislarse del ecosistema de APIs, sino implementar una capa de control determinista entre los clientes y los proveedores de inferencia.

[Cliente / App Interna]
         │ (TLS 1.3 / mTLS)
         ▼
┌───────────────────────────────────────────────┐
│      GATEWAY DE INFERENCIA PERSONNN           │
│  - Detección/Redacción local de PII/Secretos  │
│  - Enrutamiento por criticidad de datos       │
│  - Registro de auditoría local (Hash del raw) │
└──────────┬─────────────────────────┬──────────┘
           │ (Datos altamente        │ (Datos anonimizados
           │  clasificados / Airgap) │  o bajo contrato ZDR)
           ▼                         ▼
┌──────────────────────┐  ┌──────────────────────┐
│ Inferencia On-Prem   │  │ API Externa Segura   │
│ (vLLM / Modelo 8B-70B│  │ (Zero Data Retention │
│ en cluster local)    │  │ Endpoint dedicado)   │
└──────────────────────┘  └──────────────────────┘

Componentes técnicos clave de este patrón:

  1. Inspección de carga útil en el borde: Antes de que el payload salga de la red corporativa, un modelo ligero especializado (ej. Gliner o expresiones regulares compiladas en Rust) detecta patrones de secretos industriales, credenciales, tokens de API o PII (Personally Identifiable Information).
  2. Enrutamiento semántico condicional:
    • Si la petición contiene identificadores de clientes o secretos no anonimizables: la llamada se desvía al cluster interno (ej. vLLM con Llama 3 8B/70B).
    • Si el prompt es analítico, lógico o código abstracto sin datos propietarios: se enruta a una API externa de frontera (Claude 3.5 Sonnet o GPT-4o) bajo un endpoint empresarial con ZDR verificado mediante contrato SOC2/ISO27001.
  3. Auditoría y hashing: Se guarda únicamente el hash criptográfico del prompt y de la respuesta para fines de cumplimiento normativo interno, sin almacenar el texto plano en discos no cifrados.

Matriz de decisión: ¿Cuándo comprar hardware?

Variable Desplegar Hardware Propio Usar APIs con Gateway Seguro
Obligación regulatoria Auditorías militares, sector defensa o secreto bancario estricto que prohíben explícitamente tráfico externo. GDPR, HIPAA o SOC2 estándar con acuerdos de procesamiento de datos (DPA).
Throughput continuo Consumo constante de >20 millones de tokens diarios los 7 días de la semana (justifica amortización). Picos de tráfico o volumen inferior a 10 millones de tokens al día.
Capacidad de razonamiento requerida Tareas concretas, extracción de datos, clasificación o RAG acotado (modelos 8B a 70B son suficientes). Razonamiento arquitectónico complejo, análisis legal multivariable o generación de código avanzado.
Equipo de DevOps/MLOps Cuentas con ingenieros dedicados a gestionar CUDA, OOM errors y balanceo de vLLM. El equipo debe enfocarse en la lógica de negocio y el producto final.

Tomar la decisión con métricas, no con suposiciones

Comprar hardware por miedo al entorno cloud suele terminar en servidores obsoletos en 18 meses y modelos desactualizados que reducen la productividad de los equipos. Por el contrario, conectar directamente sistemas internos a APIs externas sin una capa intermedia de inspección y anonimización es una negligencia técnica.

La infraestructura de inferencia moderna requiere diseñar un balance higiénico entre seguridad operativa y pragmatismo económico. En Personnn estructuramos arquitecturas de inferencia híbridas y pasarelas de control privado para que las empresas operen modelos de vanguardia sin ceder el control de su propiedad intelectual.

ia localinferenciagpusprivacidadcostos llm

02 — [ seguir leyendo ]

03 — [ modelos propios & privacidad ]

Corre modelos locales o inferencia privada sin filtraciones.

Modelos abiertos afinados con tu contexto, infraestructura soberana y API privada sin que tus datos entrenen nubes públicas.