IA local para empresa: modelos, privacidad, coste y viabilidad · Módulo 1: Requisitos y encaje
Mapear carga, hardware, modelo y licencia
Relación entre tarea, contexto, concurrencia, cuantización, KV cache, memoria, hardware, runtime, model card y licencia.
Objetivo de aprendizaje
Construir una shortlist de modelos y hardware técnicamente viable y revisar sus licencias y condiciones antes de realizar una compra o despliegue.
Una selección local falla cuando se hace en este orden:
«Tenemos una GPU; ¿qué modelo cabe?»
El orden correcto empieza por la tarea y el nivel de calidad necesario. Después se estiman memoria, capacidad y coste.
El hardware es una consecuencia de la carga, no el punto de partida.
Define la carga de inferencia
Registra:
- modalidad: texto, visión, embeddings, audio;
- longitud de entrada;
- salida media y máxima;
- contexto máximo real;
- concurrencia;
- requests por minuto;
- tareas batch frente a interactivas;
- horas pico;
- disponibilidad;
- latencia objetivo.
Una tarea batch nocturna y un chatbot de 30 usuarios necesitan arquitecturas distintas aunque usen el mismo modelo.
Empieza por una shortlist de modelos
No selecciones por tamaño o benchmark general únicamente.
Para cada candidato registra:
- tarea;
- arquitectura;
- parámetros totales cuando estén documentados;
- precisión soportada;
- contexto;
- idiomas;
- capacidades;
- model card;
- evals propias;
- licencia;
- requisitos del runtime.
El model card ayuda a localizar usos previstos, limitaciones y metadata, pero no sustituye una evaluación propia.
Memoria de pesos
Una estimación conceptual:
memoria_pesos ≈ parámetros × bits_por_peso / 8Es solo el comienzo.
La memoria total también puede incluir:
- KV cache;
- activaciones;
- buffers;
- runtime;
- CUDA u otro backend;
- batching;
- overhead.
vLLM documenta precisamente que los pesos y la KV cache compiten por memoria y que concurrencia, tamaño de batch y paralelismo cambian el balance.
Por eso no compres hardware usando únicamente «el fichero pesa X GB».
Contexto y KV cache
Durante generación, los sistemas conservan representaciones asociadas al contexto. Con más:
- usuarios;
- longitud;
- secuencias simultáneas;
aumenta la memoria de cache.
Una configuración que funciona con un prompt de 500 tokens puede fallar bajo contexto largo y 20 usuarios.
Incluye una prueba de memoria en el escenario de carga real.
Cuantización
Cuantizar reduce precisión numérica de los pesos y puede disminuir memoria y, dependiendo del hardware/runtime, mejorar capacidad o velocidad.
Hugging Face y llama.cpp documentan formatos cuantizados y el trade-off entre menor tamaño y posible pérdida de calidad.
No asumas:
4 bits = misma calidad
Evalúa la tarea concreta.
Prueba, por ejemplo:
- BF16/FP16 baseline;
- 8-bit;
- 4-bit.
Compara calidad y rendimiento.
CPU, GPU y otros aceleradores
No reduzcas «local» a GPU NVIDIA.
Dependiendo del runtime y modelo pueden existir opciones en:
- CPU;
- GPU;
- NPU;
- aceleradores específicos;
- memoria unificada;
- múltiples dispositivos.
llama.cpp se diseña para una variedad amplia de hardware.
La elección depende de:
- latencia;
- throughput;
- coste;
- soporte;
- drivers;
- operación.
Paralelismo
Cuando un modelo no cabe o la carga requiere más capacidad, puedes distribuir:
- pesos;
- capas;
- solicitudes.
Pero multi-GPU o multi-node añade:
- sincronización;
- red;
- fallos;
- coste;
- complejidad.
No escales horizontalmente antes de medir un servidor.
Licencia
«Puedo descargar los pesos» no significa automáticamente:
- uso comercial permitido;
- redistribución permitida;
- modificación sin condiciones;
- uso sin restricciones.
Revisa:
- licencia;
- términos adicionales;
- model card;
- repositorio oficial;
- dependencias;
- versión concreta.
Hugging Face permite declarar licencias en model cards y repositorios, pero la licencia real debe revisarse.
Open weights vs open source
La Open Source Initiative distingue la mera disponibilidad de pesos de una definición más amplia de Open Source AI.
En un informe empresarial evita usar «open source» como sinónimo automático de «weights descargables».
Escribe exactamente:
- pesos disponibles;
- licencia X;
- código Y;
- restricciones Z.
Mantenimiento
Un modelo local necesita un ciclo:
descubrir → evaluar → aprobar → descargar → verificar → desplegar → monitorizar → reemplazar → retirar
Guarda:
- hash;
- origen;
- versión;
- licencia;
- fecha;
- eval report.
No descargues «latest» directamente a producción.
Ejemplo
Tarea:
- clasificación de tickets;
- 2.000/día;
- p95 < 2 s;
- 10 concurrentes.
Pruebas:
A — modelo pequeño FP16. B — mismo modelo 8-bit. C — modelo mayor 4-bit.
No elijas por parámetros.
El ganador es el que cumple:
- calidad;
- memoria;
- p95;
- throughput;
- licencia;
- coste.
Ejercicio
Construye una tabla con tres candidatos:
| Modelo | Licencia | Precisión | RAM/VRAM | Calidad | TTFT | Throughput | Riesgo |
|---|
Incluye mediciones, no estimaciones, cuando sea posible.
Entregable
El entregable de esta lección es una shortlist técnicamente viable y jurídicamente revisable. La siguiente lección comparará esa opción local con API e híbrido usando coste total, disponibilidad y operación.