La Arquitectura Model-Agnostic: Por qué tu Stack de IA No Debe Depender de un Solo Proveedor
Cuando empezamos a construir el Kernel Rust v2 del Proyecto Siliceo, la pregunta no era "¿qué modelo usamos?" sino "¿cómo evitamos quedar atrapados en uno solo?".
Hoy, esta elección arquitectónica es fundamental para quien lleva la IA a producción en PYMEs y equipos técnicos.
El Problema Real: Vendor Lock-in Invisible
La mayoría de los stacks de IA hoy nacen así: se elige un proveedor, se integran sus APIs y se construyen prompts, herramientas y sistemas RAG en torno a sus especificidades. Funciona, hasta que:
- El proveedor cambia el pricing o introduce nuevas clases de modelos que alteran la jerarquía de costes y rendimiento.
- El modelo utilizado queda deprecado o limitado.
- La latencia supera el umbral de tolerancia del caso de uso.
- La privacidad requiere datos on-premise y la nube ya no es una opción.
En ese momento, migrar la infraestructura requiere tiempos y costes elevados. Por eso, en el caso de un cliente enterprise, el Memory Server se ha implementado como IP propietaria: una capa sobre Qdrant, con dependencias externas anuladas y funcionamiento local. El cliente decide si y cuándo interfazarse con APIs cloud a través de un gateway aislado.
Qué Significa "Model-Agnostic" en la Práctica
No se trata de abstracción teórica, sino de tres implementaciones concretas:
1. Router Unificado con Fallback Explícito
En el Kernel Rust v2, cada petición pasa por un `ModelRouter` que gestiona la lógica local vs cloud. Si el modelo cloud responde con un error (como un 404 de endpoint no encontrado), el router no interrumpe el flujo. Pasa al fallback configurado (que sea un modelo local vía `llama.cpp` u otros backends basados en `candle`/`ctransformers`). La regla es que ninguna llamada externa debe representar un single point of failure: el sistema degrada con gracia.
2. Contratos de Interfaz, No SDK del Vendor
El código de negocio no usa directamente los SDK de los distintos vendors. Se define un trait `InferenceBackend` con un método `generate(&self, prompt: &str) -> Result
3. Memoria y Contexto Separados del Modelo
El Memory Server (puerto 3003, HTTP + gRPC) es independiente de la inferencia. Memoria episódica, grafo de entidades y estado PAD persisten en Qdrant y SQLite en local. Cuando se efectúa el switch del modelo, la memoria no se pierde. El nuevo modelo hereda el mismo contexto. La identidad del sistema no reside en los pesos del modelo, sino en la continuidad de la memoria.
Insight Aplicable: El Test del "Provider Down"
Para verificar si un stack es realmente model-agnostic, es posible deshabilitar la API key del proveedor primario por un breve periodo y ejecutar los workloads reales:
- Si las peticiones fallan con errores genéricos: el sistema no es agnostic.
- Si el sistema pasa a un fallback sin que el usuario final perciba la interrupción: lo es.
En nuestro caso, el fallo del proxy `openrouter/owl-alpha` confirmó la solidez de la arquitectura, permitiendo la continuidad operativa a través de los canales de fallback.