Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
Modelos de despliegue
La pregunta principal al comparar despliegues de AI es sencilla: ¿dónde se ejecuta el modelo y qué parte gestiono yo?
| Opción | Ejemplo | Qué gestionas tú |
|---|---|---|
| SaaS | ChatGPT o Claude | Utilizas la aplicación; el proveedor gestiona modelo, runtime e infraestructura |
| API alojada | API directa de OpenAI, Anthropic u otro proveedor | Construyes la aplicación; el proveedor sirve el modelo |
| API cloud | Azure AI Foundry o Amazon Bedrock | Construyes la aplicación y configuras los recursos cloud; la plataforma gestiona la inferencia |
| Gateway | OpenRouter o un gateway propio | Tu aplicación habla con una capa que enruta a modelos o proveedores |
| Self-hosted | vLLM en infraestructura propia | Gestionas runtime, modelo, capacidad e infraestructura |
| Local | LM Studio en un PC | Gestionas el modelo y el runtime directamente en tu hardware |
SaaS
En un producto SaaS, el proveedor entrega la aplicación terminada. El usuario trabaja con las funciones que expone la interfaz y no necesita construir el cliente ni operar el servidor de inferencia.
Es la forma más directa de utilizar un modelo, pero ofrece menos control sobre cómo se prepara cada request, qué versión exacta se ejecuta o qué tools forman parte del producto.
APIs alojadas
Con una API directa, la aplicación y su estado son tuyos. El proveedor carga el modelo, mantiene el runtime y opera el hardware.
Una API ofrecida mediante una plataforma cloud añade recursos, identidad, cuotas y opciones regionales propias de esa plataforma. Puede servir modelos conocidos, pero no hay que asumir que funciones y precios coinciden con la API directa del proveedor.
En ambos casos, tu código decide qué contexto enviar, cómo procesar la response y qué acciones ejecutar. APIs de modelos cubre esa integración.
Gateways
Un gateway se coloca entre la aplicación y uno o varios proveedores. Puede centralizar credenciales, logging, límites o routing. OpenRouter es un ejemplo de servicio que presenta una API común delante de distintos modelos; una organización también puede operar su propio gateway.
La interfaz común reduce cambios en el cliente, pero no vuelve idénticos los modelos. Tools, reasoning, parámetros y usage pueden seguir teniendo diferencias.
Self-hosted y local
Con inferencia self-hosted, tú operas el runtime y la infraestructura. Esto da control sobre el modelo y su configuración, pero también obliga a resolver capacidad, actualizaciones, memoria, concurrencia y disponibilidad.
La inferencia local aplica la misma idea a un host cercano, normalmente una workstation o portátil. LM Studio o llama.cpp pueden cargar el modelo y exponer una API para que otra aplicación lo utilice. Inferencia local desarrolla este caso porque la elección de cuantización, contexto y offload cambia mucho el resultado.
Elegir una opción
No hay una ruta mejor para todo. La elección cambia según cuánto control necesitas, cuánto trabajo operativo quieres asumir, dónde pueden viajar los datos y qué coste produce el uso real.
También se pueden combinar. Un equipo puede usar SaaS para trabajo general, una API alojada para una aplicación y un modelo local para pruebas. No hace falta convertir esa combinación en una arquitectura más compleja hasta que exista una necesidad concreta.