Arquitectura SLM-First: La Estrategia de Enrutamiento 80/20 Que Reduce Costos de AI un 75%

La mayoría de las cargas de trabajo de AI en producción son simples. Clasificación, extracción, formateo, resumen de documentos cortos, generación basada en plantillas. Estas tareas consumen el 80% o más de tu presupuesto de inferencia, y no requieren un modelo frontier de más de 200B parámetros.

La arquitectura SLM-first invierte la suposición predeterminada. En lugar de enrutar todo a una API en la nube y optimizar después, comienzas con un modelo de lenguaje pequeño ajustado (7B-14B parámetros) como la ruta predeterminada y solo escalas a una API en la nube cuando la solicitud genuinamente lo necesita.

El resultado: reducción de costos del 60-75% sin pérdida de calidad medible en las tareas que importan.

Qué Significa Realmente SLM-First

En una arquitectura de AI tradicional, el flujo de solicitudes se ve así:

Solicitud del Usuario → API en la Nube (GPT-4o / Claude) → Respuesta

Cada solicitud, independientemente de la complejidad, va a la opción más cara. Esto es lo predeterminado porque es lo más simple de construir. Un endpoint, un modelo, una integración.

SLM-first invierte lo predeterminado:

Solicitud del Usuario → Router → [80%] SLM Ajustado (7B-14B, local) → Respuesta
                               → [20%] API en la Nube (GPT-4o / Claude) → Respuesta

El router examina cada solicitud y toma una decisión: ¿puede un modelo pequeño ajustado manejar esto adecuadamente, o genuinamente necesita razonamiento de nivel frontier? La respuesta, para la mayoría de las cargas de trabajo SaaS, es que el modelo pequeño lo maneja bien.

Las Matemáticas de Costos

Hagamos los números para un producto SaaS que procesa 500,000 solicitudes de AI por mes. Usaremos precios representativos de principios de 2026.

Escenario A: Todo va a GPT-4o

Escenario B: Enrutamiento 80/20 con modelo 7B ajustado

Eso es una reducción de costos del 70%. A 1 millón de solicitudes por mes, los ahorros se acercan al 75% porque el costo de infraestructura local se mantiene casi plano mientras que el costo solo-API se duplica.

El costo de infraestructura local de AU$1,200/mes cubre una instancia GPU capaz de servir un modelo 7B cuantizado a varios cientos de solicitudes por segundo. Con 400,000 solicitudes por mes — aproximadamente 9 solicitudes por minuto en promedio — esto está bien dentro de la capacidad.

Qué Solicitudes Van a Dónde

La decisión de enrutamiento no es complicada. Sigue un patrón que se mapea limpiamente a tipos de solicitudes.

Enrutar al SLM local (80% del tráfico):

• Clasificación y categorización de texto
• Extracción de entidades nombradas
• Análisis de sentimiento
• Generación de contenido basada en plantillas (emails, resúmenes, descripciones)
• Formateo y transformación de datos (estructuración JSON, análisis CSV)
• Respuestas de FAQ y base de conocimientos
• Resumen de formato corto (menos de 500 palabras de material fuente)
• Detección de intención y enrutamiento

Estas tareas comparten rasgos comunes: salidas bien definidas, profundidad de razonamiento limitada, patrones consistentes. Un modelo 7B ajustado entrenado con 2,000-5,000 ejemplos de tu tarea específica igualará o superará a GPT-4o en estas, porque ha aprendido tu formato exacto, terminología y criterios de calidad.

Enrutar a la API en la nube (20% del tráfico):

• Razonamiento multi-paso a través de entradas complejas
• Escritura creativa donde la novedad y el estilo importan
• Análisis de documentos largos (más de 10,000 tokens de material fuente)
• Tareas que requieren conocimiento general amplio y actualizado
• Casos extremos para los que el modelo local no ha sido entrenado
• Tipos de tareas nuevos para los que aún no has hecho fine-tuning

Implementando el Router

El router en sí puede ser simple. No necesitas un modelo de ML separado para tomar decisiones de enrutamiento. Tres enfoques prácticos, en orden de complejidad:

1. Enrutamiento basado en reglas (comienza aquí)

Mapea tus endpoints de API o tipos de tareas a niveles directamente en código:

if task_type in ["classify", "extract", "format", "summarize_short"]:
    route_to_local_slm()
elif task_type in ["reason", "create", "analyze_long"]:
    route_to_cloud_api()

Esto funciona bien cuando tus tipos de tareas están bien definidos y son estables. La mayoría de los productos SaaS tienen 5-15 tipos de tareas de AI distintos, y puedes categorizar cada uno manualmente.

2. Enrutamiento basado en confianza

Ejecuta la solicitud a través del SLM local primero. Si la confianza de la salida del modelo (medida por probabilidades de tokens o un clasificador de calidad separado) excede un umbral, úsala. Si no, recurre a la API en la nube.

Esto captura más solicitudes localmente con el tiempo a medida que mejoras tu modelo ajustado, y automáticamente enruta solicitudes genuinamente difíciles al modelo frontier.

3. Enrutamiento híbrido con puntuación sombra

Enruta basándote en reglas, pero periódicamente envía una muestra de respuestas del SLM local a la API en la nube para comparación de calidad. Usa los datos de comparación para ajustar tus reglas de enrutamiento e identificar tareas donde el modelo local necesita más datos de entrenamiento.

La mayoría de los equipos deberían comenzar con enrutamiento basado en reglas. Es explícito, depurable, y te da el 80% de los ahorros de costos con el 20% del esfuerzo de implementación.

Ajustando el Nivel Local

El SLM local es tan bueno como su fine-tuning. Un modelo base Llama 3.3 o Qwen 2.5 no igualará a GPT-4o directamente en tus tareas específicas. Pero una versión ajustada entrenada con tus datos de producción sí lo hará.

El proceso de fine-tuning para el nivel local:

1. Recopilar ejemplos de producción. Exporta 2,000-5,000 pares de solicitud-respuesta de tu uso existente de GPT-4o. Estos son tus datos de entrenamiento — la API en la nube ya ha generado las salidas de referencia.

2. Ajustar un modelo base de 7B o 14B. Usando QLoRA, esto toma 30-90 minutos en una sola GPU. El resultado es un modelo que ha aprendido los patrones de tus tareas específicas, formatos de salida y criterios de calidad.

3. Evaluar contra las salidas de tu API en la nube. Ejecuta el modelo ajustado en un conjunto de prueba retenido y compara las salidas. Para tareas bien definidas, espera una paridad de calidad del 92-98%.

4. Cuantizar y desplegar. Convierte a formato GGUF (cuantización Q4_K_M o Q5_K_M) para inferencia eficiente. Despliega vía Ollama o llama.cpp detrás de un endpoint de API compatible con OpenAI.

5. Monitorear y reentrenar. Rastrea métricas de calidad en producción. Cuando recojas nuevos casos extremos que el modelo maneja mal, agrégalos a los datos de entrenamiento y reentrena. Cada iteración mejora la cobertura.

Ertas maneja los pasos 2-4 en un solo flujo de trabajo — sube tu dataset, selecciona un modelo base, y obtén un archivo GGUF ajustado listo para despliegue. El fine-tuning se ejecuta en infraestructura gestionada, así que no necesitas tus propias GPUs de entrenamiento.

Arquitectura para el Stack Completo

Así es como se ve la arquitectura SLM-first completa en producción:

┌─────────────────────────────────────────────┐
│                Tu App SaaS                  │
│                                             │
│  ┌─────────┐    ┌──────────────────────┐    │
│  │ Cola de  │───▶│   Capa de Enrutam.   │    │
│  │Solicitud │    │ (regla / confianza)  │    │
│  └─────────┘    └──────────┬───────────┘    │
│                    ┌───────┴───────┐         │
│                    ▼               ▼         │
│           ┌──────────────┐  ┌───────────┐   │
│           │ SLM Local    │  │ API Nube  │   │
│           │ (Ollama /    │  │ (GPT-4o / │   │
│           │  llama.cpp)  │  │  Claude)  │   │
│           │ Ajustado     │  │           │   │
│           │ 7B-14B       │  │           │   │
│           └──────────────┘  └───────────┘   │
│                    │               │         │
│                    ▼               ▼         │
│              ┌──────────────────────┐       │
│              │  Manejador de Resp.  │       │
│              │  (normalizar formato)│       │
│              └──────────────────────┘       │
└─────────────────────────────────────────────┘

Detalles clave de implementación:

• Ambos niveles exponen endpoints compatibles con OpenAI. Tu código de aplicación usa la misma biblioteca cliente para ambos — la única diferencia es la URL base y el nombre del modelo.
• El manejador de respuestas normaliza las salidas. Diferentes modelos pueden devolver formatos ligeramente diferentes. Una capa de normalización delgada asegura una salida consistente independientemente de qué nivel manejó la solicitud.
• El registro captura nivel, latencia y costo por solicitud. Estos datos alimentan tu optimización de enrutamiento e identifican candidatos para mejora del modelo.

Cuando 80/20 Se Convierte en 90/10

A medida que ajustas tu modelo local con más datos de producción, el porcentaje de solicitudes que maneja bien aumenta. Los equipos que comienzan con enrutamiento 80/20 típicamente alcanzan 90/10 dentro de 3-6 meses, porque:

• Los casos extremos se capturan en datos de entrenamiento y se ajustan en el modelo
• Los nuevos tipos de tareas se agregan al nivel local una vez que están bien definidos
• Los umbrales de calidad para enrutamiento basado en confianza pueden ajustarse a medida que el modelo mejora

Con enrutamiento 90/10, el mismo escenario de 500,000 solicitudes/mes baja a:

Eso es una reducción de costos del 80% comparado con el uso completo de API, con un perfil de calidad que ha sido validado durante meses de datos de producción.

Objeciones Comunes

"¿Qué pasa si el modelo local da una mala respuesta?"

Implementa verificaciones de calidad. Para salidas estructuradas, valida contra esquemas. Para texto libre, usa un clasificador ligero para marcar salidas de baja confianza para reintento con la API en la nube. Esto agrega unos pocos cientos de milisegundos de latencia en el ~2% de solicitudes que se marcan, pero elimina el riesgo de calidad.

"No tenemos infraestructura GPU."

Un modelo 7B cuantizado corre en un VPS de AU$80/mes sin GPU. La inferencia en CPU en hardware moderno maneja 2-5 solicitudes por segundo para un modelo 7B cuantizado en Q4. Para la mayoría de las cargas de trabajo SaaS con menos de 200,000 solicitudes/mes, esto es suficiente. Las instancias GPU solo se necesitan para mayor rendimiento.

"Nuestras tareas son demasiado complejas para modelos pequeños."

Algunas lo son. La mayoría no. Ejecuta una evaluación. Toma tus últimas 1,000 solicitudes de API, clasifícalas por complejidad, y prueba un modelo pequeño ajustado en las simples. Los datos te dirán qué porcentaje de tu tráfico es realmente complejo.

"Gestionar dos rutas de inferencia es demasiada sobrecarga operacional."

Ambas rutas usan APIs compatibles con OpenAI. Tu código de aplicación no sabe ni le importa cuál manejó la solicitud. La capa de enrutamiento son 50-100 líneas de código. La sobrecarga operacional es un servicio adicional a monitorear, lo cual es comparable a agregar una capa de caché.

Primeros Pasos

La ruta de migración es incremental. No necesitas implementar la arquitectura completa el día uno.

1. Semana 1: Audita tu uso actual de API de AI. Categoriza las solicitudes por tipo. Identifica los 2-3 tipos de tareas de mayor volumen y más simples.
2. Semana 2: Ajusta un modelo 7B en esas tareas específicas usando tus salidas de API existentes como datos de entrenamiento.
3. Semana 3: Despliega el modelo localmente y enruta esos tipos de tareas específicos a él. Mantén todo lo demás en la API en la nube.
4. Semana 4: Monitorea calidad y costos. Ajusta las reglas de enrutamiento según los resultados.

Repite cada mes, moviendo más tipos de tareas al nivel local a medida que validas la calidad. Dentro de 3 meses, tendrás la división 80/20 corriendo en producción y un camino claro hacia 90/10.

---

Lectura Adicional

• Fine-Tuning de Modelos Pequeños vs GPT-4 — Comparación directa de modelos 7B ajustados contra APIs frontier en tareas específicas
• Comparación de Costos de Inferencia AI 2026 — Precios actuales de APIs en la nube, instancias GPU y hardware local
• Mejor Modelo de Lenguaje Pequeño para Empresas 2026 — Qué modelos base elegir para el nivel local