Fine-tuning multitenant: modelos de IA por cliente en tu SaaS

Tus clientes SaaS quieren IA que entienda sus datos. No tus datos de entrenamiento. No un promedio mezclado de todos tus inquilinos. Su terminología, sus flujos de trabajo, sus casos extremos.

Una plataforma legal-tech que sirve a 80 bufetes de abogados tiene 80 vocabularios diferentes. Una plataforma de soporte que sirve a 50 marcas de e-commerce tiene 50 catálogos de productos diferentes, guías de tono y políticas de escalamiento. Un SaaS de salud que sirve a 30 clínicas tiene 30 estilos de documentación diferentes y abreviaciones específicas de especialidad.

La IA genérica da respuestas genéricas. Y las respuestas genéricas son la razón por la que tus clientes siguen pidiendo "mejor IA" en cada encuesta de feedback.

La solución no son mejores prompts. Son modelos por inquilino — y es más práctico de lo que piensas.

Los tres patrones de arquitectura

Hay exactamente tres formas de agregar fine-tuning consciente del inquilino a un producto SaaS. Cada una hace diferentes compensaciones en costo, aislamiento y calidad.

Patrón 1: fine-tune compartido

Combinas datos de entrenamiento de todos los inquilinos en un solo dataset y ajustas un único modelo. Todos los inquilinos utilizan el mismo modelo.

Cómo funciona:

• Agrega ejemplos de entrenamiento de todos los inquilinos
• Ajusta un modelo con el dataset combinado
• Todas las solicitudes API se enrutan al mismo endpoint del modelo

La ventaja: Simple. Un modelo que gestionar, un despliegue que monitorear, un fine-tune que ejecutar. El costo de almacenamiento es mínimo — estás ejecutando un modelo.

La desventaja: El modelo aprende un promedio de todos los inquilinos. Si el Inquilino A usa "cliente" y el Inquilino B usa "consumidor" para significar lo mismo, el modelo aprende un punto medio confuso. Peor aún, los datos del Inquilino A influyen en las respuestas del Inquilino B. Para industrias reguladas, eso es un problema de cumplimiento.

Cuándo funciona: Cuando tus inquilinos son homogéneos — misma industria, datos similares, vocabulario similar. Si estás construyendo un SaaS para consultorios dentales y todos documentan procedimientos de manera similar, un fine-tune compartido podría ser suficiente.

Patrón 2: adaptadores LoRA por inquilino sobre una base compartida

Ajustas un modelo base una vez (o lo usas tal cual), luego creas un pequeño adaptador LoRA para cada inquilino. En tiempo de inferencia, cargas el modelo base más el adaptador del inquilino.

Cómo funciona:

• Despliega un modelo base (ej., Llama 3.3 8B o Qwen 2.5 7B)
• Ajusta un adaptador LoRA por inquilino usando solo los datos de ese inquilino
• En tiempo de solicitud, carga el modelo base + el adaptador correcto basado en el ID del inquilino

La ventaja: Cada inquilino obtiene un modelo que genuinamente entiende sus datos. El almacenamiento es diminuto — un adaptador LoRA ocupa 50-200MB dependiendo del rango y los módulos objetivo, comparado con 4-14GB para un modelo completo. El entrenamiento es rápido y barato. El aislamiento de datos es absoluto: los datos del Inquilino A nunca tocan el adaptador del Inquilino B.

La desventaja: Necesitas infraestructura de intercambio en caliente de adaptadores. Hay un pequeño costo de latencia al cambiar entre adaptadores (típicamente 50-200ms para un intercambio en frío).

Cuándo funciona: Esta es la respuesta correcta para la mayoría de los productos SaaS. Es la arquitectura que recomendamos para el 90% de los casos de uso de IA multitenant.

Patrón 3: fine-tunes completos por inquilino

Ajustas un modelo completo para cada inquilino. Cada inquilino obtiene su propio modelo completamente independiente.

Cómo funciona:

• Ajusta un modelo separado para cada inquilino
• Despliega y sirve cada modelo de forma independiente
• Sin infraestructura compartida entre inquilinos a nivel de modelo

La ventaja: Máximo aislamiento. Máxima personalización. Cada modelo puede ser de un tamaño diferente, una base diferente, una cuantización diferente. Puedes darle al Inquilino Enterprise A un modelo 70B y al Inquilino Startup B un modelo 7B.

La desventaja: Los costos de almacenamiento y cómputo escalan linealmente con la cantidad de inquilinos. Gestionar 100 despliegues de modelos separados es una pesadilla operacional. Los costos de fine-tuning son 10-50x mayores por inquilino.

Cuándo funciona: Clientes enterprise con datasets masivos (más de 100K ejemplos), requisitos estrictos de aislamiento de datos y presupuestos que lo respalden. Piensa en bancos, contratistas de defensa, grandes redes hospitalarias.

Las matemáticas de almacenamiento

Aquí es donde la decisión generalmente se toma sola. Esto es lo que cada patrón cuesta en almacenamiento bruto a diferentes cantidades de inquilinos:

Las matemáticas: un adaptador LoRA con rango 64 apuntando a las capas de atención ocupa 50-200MB. Un modelo 7B completo en cuantización Q4 ocupa aproximadamente 4-5GB. Con 100 inquilinos, LoRA por inquilino te cuesta 5-20GB en total (un modelo base más 100 adaptadores). Fine-tunes completos por inquilino te cuestan 400-500GB como mínimo.

Eso es una diferencia de 20-50x solo en almacenamiento. Y el almacenamiento es la parte barata.

Arquitectura de servicio: cómo funciona el intercambio en caliente de adaptadores

El patrón LoRA por inquilino solo funciona si puedes intercambiar adaptadores rápidamente. Aquí está la arquitectura.

El flujo de solicitud

Solicitud entrante
  → Extraer tenant_id del token de auth / header
  → Verificar caché de adaptadores (LRU en memoria)
  → Si está en caché: enrutar a modelo base + adaptador cacheado
  → Si no está en caché: cargar adaptador desde disco/S3 (50-200ms)
  → Ejecutar inferencia
  → Devolver respuesta

Ejecutándolo con Ollama

Ollama soporta cargar adaptadores LoRA sobre modelos base. La configuración:

1. Un modelo base en memoria. Carga tu modelo base (ej., llama3.3:8b-q5_K_M) una vez. Permanece residente. Esto cuesta ~6GB de VRAM.

2. Archivos de adaptador en disco. Almacena el archivo .gguf del adaptador de cada inquilino en una estructura de directorio: /models/adapters/{tenant_id}/adapter.gguf

3. Enrutamiento de solicitudes. Tu gateway API extrae el tenant_id, selecciona la ruta del adaptador correcto y crea un Modelfile que referencia el modelo base más el adaptador.

4. Caché de adaptadores. Mantén los adaptadores usados más recientemente en un caché LRU. Para la mayoría de los productos SaaS, el 80% del tráfico viene del 20% de los inquilinos. Un caché con 10-20 adaptadores maneja la mayoría de las solicitudes con latencia de intercambio cero.

Presupuesto de latencia

Para un adaptador cacheado, la sobrecarga por inquilino es insignificante. Para un intercambio en frío, agregas 50-500ms una vez — las solicitudes subsiguientes para ese inquilino llegan al caché.

Estrategia de escalado

• Menos de 50 inquilinos: Servidor con una sola GPU. Todos los adaptadores caben en memoria o caché con intercambios rápidos.
• 50-200 inquilinos: Dos servidores GPU con hashing consistente por tenant_id. Cada servidor maneja un subconjunto de inquilinos, mejorando las tasas de acierto de caché.
• Más de 200 inquilinos: Clúster Kubernetes con nodos GPU. Pre-calentamiento de adaptadores basado en patrones de actividad de inquilinos. La mayoría de los productos SaaS nunca llegarán a este nivel.

Aislamiento de datos y cumplimiento

Aquí es donde los adaptadores LoRA por inquilino ganan decisivamente sobre el fine-tuning compartido.

Separación de datos de entrenamiento

Con adaptadores por inquilino, el aislamiento de datos es estructural, no basado en políticas:

• Los datos de entrenamiento del Inquilino A se usan exclusivamente para crear el adaptador del Inquilino A
• Los datos de entrenamiento del Inquilino B nunca entran en la misma ejecución de entrenamiento
• Eliminar un inquilino significa eliminar un archivo de adaptador — no reentrenar un modelo compartido
• La auditoría es directa: cada adaptador tiene un rastro de procedencia claro

Con un fine-tune compartido, no puedes des-aprender los datos de un inquilino sin reentrenar el modelo completo. Eso es un problema del Artículo 17 del GDPR — el derecho al borrado significa que necesitas la capacidad de eliminar la influencia de un inquilino en el modelo.

Implicaciones de GDPR y SOC 2

Para cualquier SaaS que venda a empresas, salud, legal o servicios financieros, la historia de cumplimiento por sí sola justifica los adaptadores por inquilino. Cuando el equipo de seguridad de un cliente potencial pregunta "¿se usan nuestros datos para entrenar modelos que sirven a otros clientes?" — la respuesta necesita ser no.

Ciclo de vida de datos del inquilino

Un ciclo de vida de datos limpio para fine-tuning por inquilino:

1. Ingesta: El inquilino sube datos de entrenamiento a través de tu UI o API
2. Validación: Verificaciones automatizadas de calidad (formato, completitud, deduplicación)
3. Almacenamiento: Datos de entrenamiento en almacenamiento aislado por inquilino (prefijos o buckets S3 separados)
4. Entrenamiento: Ajusta el adaptador usando solo los datos de este inquilino
5. Despliegue: Almacena el adaptador en una ruta específica del inquilino
6. Servicio: Carga el adaptador bajo demanda por solicitud
7. Eliminación: Elimina los datos de entrenamiento + adaptador cuando el inquilino cancela o solicita eliminación

Ningún paso toca los datos de otro inquilino. Sin estado compartido entre inquilinos a nivel de modelo.

Modelo de costos: lo que realmente cuesta

Costo de fine-tuning por inquilino

Usando una plataforma como Ertas en hardware modesto (GPU de consumidor única o Mac serie M):

Ajustar un modelo 7B con LoRA en 1,000 ejemplos toma 15-45 minutos en una RTX 4090 o M3 Max. El costo de cómputo es $2-5 por inquilino. Incluso con 100 inquilinos, tu factura total de fine-tuning es $200-500 — un costo único que puedes trasladar como tarifa de incorporación o absorber en el precio de tu suscripción.

Compara eso con fine-tunes completos a $30-80 cada uno: $3,000-8,000 para 100 inquilinos. Y los repetirás periódicamente a medida que los inquilinos acumulan más datos.

Costo de servicio

Aquí es donde LoRA por inquilino brilla más:

• Un modelo base en VRAM: ~6GB para un modelo 7B Q5
• Sobrecarga del adaptador: ~50-200MB por adaptador cargado, pero solo cargas los activos
• VRAM total para 100 inquilinos con 10 adaptadores cacheados: ~8GB

Estás sirviendo a 100 inquilinos desde una sola GPU que de otro modo serviría a uno. El costo de servicio por inquilino es efectivamente 1/100 de un despliegue de modelo dedicado.

Comparación de costo mensual de servicio (100 inquilinos):

A $150-300/mes para servir a 100 inquilinos modelos personalizados, el costo por inquilino es $1.50-3.00/mes. Eso es un error de redondeo en tu precio SaaS.

Cómo incluirlo en el precio de tu SaaS

Tres modelos que funcionan:

1. Incluido en el plan enterprise. La IA ajustada es una función de tu plan de $500+/mes. Te cuesta $2-5 configurar por inquilino, $1.50-3.00/mes servir. Margen masivo.

2. Función adicional. $50-100/mes como complemento de "Personalización de IA". Los clientes auto-gestionan la subida de datos de entrenamiento, tú automatizas el pipeline de fine-tuning.

3. Tarifa de incorporación + incluido. $500 de tarifa única de configuración cubre costos de fine-tuning y preparación de datos. El servicio continuo está incluido en la suscripción.

Cualquiera de estos produce más del 90% de margen en la función de IA en sí misma.

Cronograma de implementación

Agregar fine-tuning por inquilino a un producto SaaS existente es un proyecto de 2-4 semanas para un ingeniero backend. Aquí está el desglose.

Semana 1: pipeline de entrenamiento

• Configurar Ertas o infraestructura equivalente de fine-tuning
• Construir exportación de datos por inquilino (extraer ejemplos de entrenamiento de tu base de datos por inquilino)
• Crear conversor de formato de datos de entrenamiento (de tu esquema a pares instrucción/respuesta)
• Probar pipeline de fine-tuning de extremo a extremo con un inquilino

Semana 2: infraestructura de servicio

• Desplegar modelo base con Ollama o vLLM
• Construir capa de carga y caché de adaptadores
• Implementar enrutamiento de solicitudes consciente del inquilino
• Agregar lógica de intercambio en caliente de adaptadores con caché LRU

Semana 3: integración de producto

• Construir UI de subida de datos o activación de entrenamiento orientada al inquilino
• Agregar seguimiento del estado de trabajos de fine-tuning
• Integrar modelo específico del inquilino en tus funciones de IA existentes
• Implementar respaldo al modelo base cuando el adaptador no está listo

Semana 4: operaciones y pulido

• Agregar monitoreo: latencia por inquilino, tasas de acierto de caché, tiempos de carga de adaptadores
• Construir activadores de reentrenamiento automatizado (umbral de datos nuevos, programado)
• Configurar versionamiento de adaptadores y rollback
• Pruebas de carga con tráfico multitenant simulado

No necesitas un equipo de ML. Necesitas un ingeniero backend que pueda seguir documentación e integrar una API. La complejidad del fine-tuning es manejada por la plataforma. Tu trabajo es la fontanería: obtener datos de entrada, enrutar solicitudes, gestionar adaptadores.

Errores comunes

Sobre-ingeniar la primera versión. Empieza con 5 inquilinos. Valida que los modelos por inquilino mejoran mediblemente las métricas de tu producto. Luego escala la infraestructura.

Ignorar la calidad de los datos. Un adaptador LoRA entrenado con 200 ejemplos de alta calidad supera a uno entrenado con 2,000 ejemplos ruidosos. Construye la validación de datos antes de construir el pipeline de entrenamiento.

Saltarse el respaldo. Cuando un nuevo inquilino se registra, aún no tiene un adaptador ajustado. Tu sistema necesita recurrir elegantemente al modelo base (o a un fine-tune compartido) hasta que su adaptador esté listo.

No medir el delta. Ejecuta pruebas A/B: modelo base vs. adaptador específico del inquilino. Si el adaptador no mejora mediblemente la precisión, relevancia o satisfacción del usuario para un inquilino dado, no lo envíes. Algunos inquilinos pueden no tener suficientes datos únicos para beneficiarse.

Entrenar con demasiada frecuencia. La mayoría de los inquilinos no necesitan reentrenamiento diario. El reentrenamiento semanal o mensual activado por un umbral de datos (ej., 100 nuevos ejemplos desde el último entrenamiento) es suficiente y mantiene los costos de cómputo predecibles.

Hacia dónde va esto

Los productos SaaS que ganen los próximos tres años tratarán la personalización de IA como tratan el almacenamiento de datos hoy — como un recurso por inquilino que se aprovisiona automáticamente y escala con el uso.

Ahora mismo, el fine-tuning por inquilino se siente como una ventaja competitiva. Para 2028, será lo básico esperado. Tus clientes esperarán que tu IA entienda su terminología, sus flujos de trabajo, sus casos extremos — porque la IA de tu competidor lo hará.

La buena noticia: la infraestructura está lista ahora. Los adaptadores LoRA hicieron el fine-tuning por inquilino económicamente viable. El intercambio en caliente de adaptadores lo hizo operacionalmente factible. Plataformas como Ertas lo hicieron accesible para equipos sin experiencia en ML.

La pregunta no es si construir IA por inquilino. Es si la construyes antes o después que tus competidores.

Lectura adicional

• Despliegue de IA multitenant para agencias — Cómo las agencias gestionan despliegues de modelos por cliente a escala
• Adaptadores LoRA explicados para agencias — Inmersión profunda en cómo funcionan los adaptadores LoRA y por qué son la unidad correcta de personalización
• Agregar funciones de IA a tu SaaS sin equipo de ML — El manual más amplio para enviar funciones de IA con tu equipo de ingeniería existente