Orquestar varios LLM sin quedar atado a ninguno

Cuando una empresa nos pregunta qué modelo de lenguaje debería usar, la respuesta honesta casi nunca es un nombre. Es una pregunta de vuelta: ¿qué pasa con tu producto el día que ese proveedor suba el precio, cambie la API o discontinúe el modelo?

No es un escenario hipotético. Pasó varias veces en los últimos dos años, y va a volver a pasar.

El acoplamiento no está donde uno cree

La mayoría de los equipos cree que está desacoplado porque usa una librería cliente. No lo está. El acoplamiento real suele estar en tres lugares menos visibles:

En el prompt. Los modelos responden distinto al mismo texto. Un prompt afinado durante semanas contra un proveedor puede degradarse notablemente contra otro, y eso no se descubre hasta que se migra.

En el formato de salida. Si tu código espera la forma exacta en que un proveedor devuelve llamadas a herramientas o JSON, migrar significa reescribir la capa de parseo.

En los supuestos de latencia y costo. Un flujo diseñado alrededor de respuestas de 300 ms se rompe si el reemplazo tarda 2 segundos, aunque la calidad sea igual o mejor.

Lo que sí funciona

Una frontera propia, delgada. No un framework pesado: una interfaz mínima que tu producto llama y que traduce hacia cada proveedor. Debe expresar lo que tu producto necesita —completar, extraer estructura, clasificar— no lo que la API ofrece.

Contratos de salida verificables. Definí el esquema que esperás y validalo siempre, sin importar el proveedor. Si el modelo devuelve algo que no cumple, reintentá o degradá. Esta validación deja de ser opcional en cuanto hay más de un proveedor.

Un conjunto de casos de referencia. Veinte o treinta entradas reales con la salida que considerás aceptable. Es lo único que permite comparar proveedores con evidencia en vez de con impresiones. Sin esto, la elección de modelo es una discusión de opiniones.

Configuración por variable de entorno, no por código. El nombre del modelo no debería estar escrito en ningún archivo fuente. Cambiar de proveedor tiene que ser un despliegue de configuración, no una rama.

El caso de la degradación

Un sistema en producción necesita saber qué hace cuando el proveedor no responde. Las opciones razonables son enrutar a un modelo alternativo, responder con una versión reducida de la funcionalidad, o decir con claridad que la función no está disponible.

La opción que no es razonable es fallar en silencio y devolver algo inventado. Un agente que responde cualquier cosa cuando no puede razonar es peor que uno que se declara caído.

El costo de esta disciplina

Es real: una frontera propia agrega código, y validar todas las salidas cuesta algo de latencia. Vale la pena cuando el producto va a vivir más de un año o cuando el costo del proveedor es una línea significativa del presupuesto.

Si estás construyendo un prototipo para validar una idea en dos semanas, no hace falta. Conviene saber que es deuda deliberada y no un descuido.