Un modelo entrenado es un archivo de pesos. Para que una aplicación lo use hace falta un servidor de : un proceso que carga esos pesos en memoria, recibe requests, genera y devuelve respuestas con una latencia y un costo razonables. Es un problema clásico de infraestructura con particularidades propias.
En esta lección vemos las decisiones principales: dónde corre el modelo, en qué formato, con qué motor, detrás de qué API, cómo se comparte entre clientes y qué determina realmente el costo. Adapta es el caso del lado del servidor; docket, el del lado del cliente.
Local u hospedado
| API hospedada | Servidor propio | |
|---|---|---|
| Modelos | los más capaces del mercado | modelos de pesos abiertos |
| Costo | por token | hardware y operación, fijo |
| Datos | salen hacia el proveedor | se quedan en tu infraestructura |
| Operación | casi nula | tuya: GPU, actualizaciones, monitoreo |
| Personalización | la que ofrezca el proveedor | total, incluidos adapters propios |
No es binario: muchos equipos combinan un modelo hospedado para tareas difíciles con uno local para alto volumen o datos sensibles.
Pesos, formatos y cuantización
Un modelo de 7B parámetros en 16 bits ocupa unos 14 GB solo en pesos. La reduce la precisión numérica de los pesos (por ejemplo, a 4 bits) para que el modelo ocupe menos memoria y corra más rápido, a cambio de cierta pérdida de calidad que depende del modelo, del método y de la tarea.
- es el formato de archivo de llama.cpp: un solo archivo con pesos (a menudo cuantizados), tokenizer y metadatos. Nombres como
Q4_K_Mindican el esquema de cuantización. - es el formato habitual en el ecosistema de Hugging Face, normalmente en precisión completa o media.
El motor de inferencia
Generar texto tiene dos fases. En el prefill se procesa todo el de una vez; en el decode se genera un token por paso. Para no recalcular el prompt en cada paso, el motor guarda estados intermedios en el KV cache, cuya memoria crece con la longitud del contexto y con el número de requests simultáneas. Por eso la y la concurrencia compiten por la misma memoria.
Adapters por request
Un adapter LoRA es un archivo pequeño que se aplica sobre un modelo base. Así, un solo base sirve muchos comportamientos, eligiendo el adapter en cada request. Los motores difieren en el costo: en el backend llama.cpp de Adapta, cada par (base, adapter) es una instancia completa en memoria; en vLLM, varios adapters comparten el mismo base y el mismo batch (hasta --max-loras, 8 por defecto en docker-compose.yml).
La API compatible con OpenAI
El formato POST /v1/chat/completions se convirtió en la interfaz de hecho entre aplicaciones y modelos. Permite cambiar de proveedor cambiando base_url y model. Pero "compatible" no significa "equivalente": el soporte de herramientas, structured output, streaming o conteo de tokens cacheados varía entre servidores.
Multi-tenancy y llaves con alcance
Si varios equipos o clientes comparten un servidor, cada llamada debe resolver quién llama y a qué puede acceder.
Qué define el costo y la latencia
- Tokens de entrada vs. de salida: el prompt se procesa en paralelo (prefill); la salida se genera token por token. Las respuestas largas dominan la latencia, y la salida suele cobrarse más cara.
- Tamaño del contexto: más contexto implica más cómputo en el prefill y más KV cache.
- Batching: agrupar requests aprovecha mejor la GPU, pero una request individual puede esperar más.
- Prompt caching: un prefijo idéntico y estable (system prompt, definiciones de herramientas) puede reutilizarse más barato en muchos servicios.
- Tamaño del modelo: el factor más grande. De ahí el : usar el modelo más pequeño que resuelva bien cada tarea.
El detalle de routing y está en Contexto, routing y costo.
Para CTOs
La decisión central es qué tráfico justifica operar tu propia inferencia. Tres preguntas ayudan a tomarla:
- ¿Hay datos que no pueden salir de tu infraestructura? Si la respuesta es sí, el servidor propio deja de ser opcional.
- ¿El volumen es estable y alto? La capacidad fija se amortiza con uso sostenido; el tráfico irregular suele salir más barato por token.
- ¿Quién opera las GPU, las actualizaciones de modelos y la seguridad del endpoint? Un servidor sin auditar, expuesto a la red, es un riesgo mayor que una API hospedada.
En cualquier caso, mide latencia y calidad con tu tráfico real antes de comprometerte.
Para llevar
- Servir un modelo es infraestructura: memoria, concurrencia, autenticación y costos, con el KV cache como recurso central.
- La cuantización cambia calidad por memoria y velocidad; evalúa en condiciones cercanas a las de servicio.
- La API compatible con OpenAI facilita cambiar de proveedor, pero no garantiza las mismas funciones.
- Los adapters permiten muchos comportamientos sobre un base; el costo depende de si el motor comparte el base entre adapters.
- La latencia la dominan los tokens de salida y el tamaño del modelo; el routing y el caching son las palancas principales.
Comprueba lo aprendido
¿Por qué el backend llama.cpp de Adapta no escala bien con muchos endpoints de fine-tuning?
Porque cada par (base, adapter) es una instancia completa en memoria, limitada por un caché LRU. vLLM permite que varios adapters compartan un solo base cargado.
Una llave de Adapta del endpoint A envía `"model": "slug-de-B"`. ¿Qué pasa?
Recibe un 403: el campo model debe coincidir con el slug del endpoint al que pertenece la llave.
¿Qué significa que un servidor sea "compatible con OpenAI" y qué no garantiza?
Acepta el mismo formato de request y respuesta de chat completions, así que el cliente puede cambiar de servidor cambiando base_url y model. No garantiza el mismo soporte de herramientas, structured output, streaming o reporte de uso.