Explorar notas
Modelos de despliegue
Al elegir cómo utilizar un modelo, dos preguntas aclaran casi todo el mapa: dónde se ejecuta la inferencia y qué parte del sistema gestionas tú.
| 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 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 |
Producto terminado: SaaS
En un producto SaaS utilizas una aplicación ya construida. El proveedor decide cómo sirve el modelo, qué funciones expone, qué tools integra y buena parte de cómo prepara las requests.
A cambio de perder parte de ese control, no tienes que construir el cliente ni operar la infraestructura de inferencia. Para trabajo interactivo suele ser la forma con menos componentes que gestionar.
Inferencia gestionada: APIs y gateways
Con una API directa, tu aplicación decide qué input enviar, cómo conservar su estado y qué hacer con la response; el proveedor carga el modelo y opera el runtime y el hardware. Una plataforma cloud como Azure AI Foundry o Amazon Bedrock añade su propia identidad, cuotas, regiones y configuración alrededor de esa inferencia gestionada.
Un gateway se coloca delante de uno o varios proveedores. Puede centralizar credenciales, logging, límites o routing y ofrecer una interfaz común a la aplicación. OpenRouter es un ejemplo de esta capa.
Compartir interfaz reduce cambios en el cliente, pero las capacidades de los modelos siguen pudiendo variar en tools, reasoning, usage o parámetros. APIs de modelos cubre la integración a ese nivel.
Inferencia propia: self-hosted y local
Con inferencia self-hosted operas el runtime y la infraestructura donde se carga el modelo. Eso permite controlar modelo y configuración, y también te deja a cargo de capacidad, memoria, concurrencia, actualizaciones y disponibilidad.
La inferencia local es el mismo tipo de responsabilidad en un equipo cercano, normalmente una workstation o portátil. LM Studio o llama.cpp pueden cargar el modelo y exponer una API para que otras aplicaciones lo consuman. Inferencia local entra en los compromisos de cuantización, contexto, VRAM y offload que aparecen en este caso.
Criterios de elección
Para una decisión práctica suelo separar cuatro cosas:
- Control: cuánto necesitas decidir sobre modelo, parámetros, contexto y herramientas.
- Operación: cuánto runtime, capacidad y disponibilidad quieres gestionar.
- Datos: qué restricciones existen sobre dónde pueden procesarse o almacenarse.
- Coste y uso: si encaja mejor una suscripción, consumo de API o infraestructura propia para la carga esperada.
Las opciones pueden convivir. Un mismo equipo puede utilizar SaaS para trabajo interactivo, una API para una aplicación y un modelo local para pruebas sin convertirlo en un único despliegue homogéneo.