Sobre los inicios lentos

Partiendo de la nada.

Hace dos días escribí por qué creemos en los modelos pequeños. Esto es lo otro: cómo se monta eso cuando no tienes ni una GPU alquilada.

---

[01] La restricción

Un banco de pruebas para orquestar modelos tiene un coste que no aparece en el diseño: cada iteración cuesta dinero si llamas a una API.

Y las primeras semanas de un orquestador son casi todo iteración. Pruebas el enrutado, sale mal, cambias el prompt del planificador, lo vuelves a lanzar. Cien veces al día.

Con facturación por token eso te obliga a pensar antes de probar. Suena virtuoso y no lo es: en esta fase quieres lo contrario, probar mucho, barato y sin pedir permiso.

Así que la primera decisión no fue de arquitectura. Fue que todo tenía que correr en local, aunque fuera peor.

[02] Los trabajadores

Modelos pequeños, uno por papel. Clasificar, extraer, dar formato, validar.

Cada uno hace una cosa y la hace siempre igual, que es exactamente donde un modelo de tres mil millones de parámetros afinado se comporta mejor de lo que la gente espera.

La ventaja de separarlos no es la calidad: es el diagnóstico. Cuando un sistema de un solo modelo se equivoca, tienes una caja negra y un prompt de cuatro mil palabras. Cuando se equivoca uno de seis trabajadores, sabes cuál.

[03] El planificador

Un SLM más fuerte —Phi-4, Mistral Small— decide qué trabajador interviene y en qué orden: secuencial, paralelo o condicional.

Con llamada a herramientas y salida estructurada en JSON, para que el plan quede legible y revisable en lugar de escondido dentro de una respuesta en prosa.

Esto no es cosmética. Un plan que se puede leer es un plan que se puede auditar, y en cuanto el sistema toca un expediente o una historia clínica, eso deja de ser una comodidad y pasa a ser un requisito.

[04] Sandbox local

vLLM y Ollama para correr varios SLM en paralelo sin pagar tokens por cada movimiento.

Almacenes vectoriales separados por colección —Chroma, Qdrant— de modo que actualizar un dominio no obligue a recompilar el resto. Parece un detalle de organización y resulta ser lo que permite iterar: si reindexar una carpeta te cuesta cuarenta minutos del corpus entero, dejas de reindexar y empiezas a convivir con datos viejos.

[05] Lo que la restricción nos enseñó

Que el hardware modesto no era el problema, sino el enunciado correcto.

Un despacho, una residencia o un ayuntamiento pequeño no tienen una GPU de ocho mil euros. Tienen el portátil que ya estaba encima de la mesa. Demostrar que un orquestador de modelos pequeños funciona en hardware alquilado probaría algo sobre un entorno que nuestro interlocutor no tiene y no va a comprar.

De modo que lo que empezó siendo una limitación de presupuesto acabó definiendo a quién nos dirigimos. No lo planeamos así. Pero es la clase de cosa que solo se descubre construyendo.

[06] Dónde va esto

Estas ideas forman parte de nuestro trabajo en Ragtime, el sitio donde probamos cosas antes de creérnoslas. Hemos hecho los primeros desarrollos con resultados esperanzadores, y seguimos construyendo y midiendo.

Lo que se sostenga acabará incorporándose al catálogo de Lovehacks y de Exedra, que son nuestras marcas comerciales. Lo que no, se quedará aquí contado.

Es lento a propósito. De ahí el título.