Cómo elegir un proveedor de LLM: restricciones, enrutamiento y diseño reversible

Los equipos siguen preguntando cuál es el mejor modelo, como si elegir fuera una cata. Esa pregunta caduca pronto. Los precios de los proveedores cambiaron dos veces en el primer semestre de 2026, y todos los grandes laboratorios lanzaron nuevas versiones de sus modelos en ese mismo periodo. Una empresa que en enero se ató a un único proveedor ya ha visto cómo esa apuesta se quedaba vieja.

Una pregunta mejor tiene tres partes. ¿Qué exige esta carga de trabajo? ¿Qué clase de modelo cumple esas exigencias? ¿Y cuánto nos costaría cambiar dentro de seis meses? Si pasar a otro proveedor implica reescribir, no has tomado una decisión de arquitectura. Has adquirido una dependencia.

A continuación, las restricciones que de verdad deciden la cuestión y una organización del código que mantiene la elección reversible.

Cinco restricciones que lo deciden

Repásalas antes de abrir cualquier tabla de benchmarks.

Por dónde pueden viajar tus datos. Los modelos cerrados vía API envían tus datos por la infraestructura del proveedor en cada petición. En sectores regulados, con historiales de pacientes o con contratos públicos, ese hecho por sí solo puede zanjar el debate. Entonces el autoalojamiento o el despliegue dentro de la región deja de ser una cuestión de coste y pasa a ser de cumplimiento normativo.

El coste con volumen de producción. El tráfico de una demo oculta la diferencia. Los modelos económicos rondan los $0.10 por millón de tokens de entrada, mientras que los modelos de frontera llegan a $25–30 por millón de tokens de salida. Con alrededor de un millón de conversaciones al mes, los modelos alojados acaban costando entre $15.000 y $75.000 mensuales. Un modelo pequeño ajustado y ejecutado en tu propio hardware puede asumir esa carga por unos cientos de dólares, siempre que la tarea sea acotada y repetitiva.

La dificultad real de la tarea. La mayoría de las cargas de negocio consisten en clasificar, extraer, resumir y enrutar. Ninguna necesita razonamiento de nivel frontera, así que reserva el nivel caro para la minoría difícil.

La tolerancia a la latencia. Una persona esperando respuesta en un chat y un proceso por lotes nocturno no tienen nada en común. Pagar por una velocidad que no necesitas es el sobrecoste silencioso más habitual.

Las ganas de operar. Los modelos de pesos abiertos no cuestan nada al descargarlos, pero ejecutarlos implica alquilar GPU, desde unos $0.50 hasta $5.00 por hora según crece el modelo, y pagar a ingenieros para desplegar, parchear y monitorizar todo el stack.

Paso 1: construye primero la costura

Define la abstracción antes de elegir a nadie. Todo el resto del código debe hablar con tu interfaz y nunca con el SDK de un proveedor.

class ModelProvider(Protocol):
    def complete(self, messages, *, max_tokens, tools=None) -> Completion: ...

class Router:
    def __init__(self, providers: dict[str, ModelProvider]):
        self.providers = providers
    def complete(self, messages, *, tier="standard", **kw):
        name = MODEL_FOR_TIER[tier]                # config, not code
        try:
            return self.providers[name].complete(messages, **kw)
        except (RateLimited, ProviderDown):
            fallback = FALLBACK_FOR_TIER[tier]     # different vendor entirely
            return self.providers[fallback].complete(messages, **kw)

Esto te da dos cosas. Cambiar de proveedor pasa a ser un ajuste de configuración y no un proyecto. Y la caída de un proveedor ya no tumba tu producto, algo que los equipos subestiman hasta el día en que ocurre.

Mantén las rarezas de cada proveedor dentro de su adaptador. En cuanto los nombres de parámetros de un proveedor se cuelan en la lógica de negocio, la costura desaparece.

Paso 2: enruta por tarea, no por favorito

Mandar todas las peticiones a un único modelo es el hábito más caro de la IA en producción. Divide el trabajo en niveles.

MODEL_FOR_TIER = {
    "bulk":     "small_local",      # classification, extraction, tagging
    "standard": "mid_hosted",       # summaries, drafting, most chat
    "hard":     "frontier_hosted",  # multi-step reasoning, ambiguous cases
    "sensitive":"self_hosted",      # data that cannot leave your estate
}

def choose_tier(task, payload):
    if contains_regulated_data(payload):
        return "sensitive"                      # compliance overrides cost
    if task in {"classify", "extract", "tag", "route"}:
        return "bulk"
    if task == "reason" or payload.get("complexity") == "high":
        return "hard"
    return "standard"

La comprobación de cumplimiento va primero a propósito. Coste y calidad se pueden compensar entre sí. Dónde se pueden procesar los datos, no.

Paso 3: mide con tu propia carga de trabajo

Los rankings públicos muestran cómo rinden los modelos en los rankings públicos. Su relación con cómo se desenvuelve un modelo con tus documentos, tu jerga y tus idiomas es bastante débil.

Organiza tu propia comparativa con el mismo golden set que te protege de las regresiones.

def bake_off(candidates, cases):
    results = {}
    for name, provider in candidates.items():
        passed, cost, latencies = 0, 0.0, []

for case in cases:
            t0 = time.monotonic()
            out = provider.complete(case["messages"], max_tokens=800)
            latencies.append((time.monotonic() - t0) * 1000)
            passed += grade(out.text, case["expected"])
            cost += price(name, out.usage)
        results[name] = {
            "accuracy": passed / len(cases),
            "cost_per_1k_calls": (cost / len(cases)) * 1000,
            "p95_latency_ms": percentile(latencies, 95),
        }
    return results

Evalúa tres cosas a la vez: precisión, precio y velocidad. Un modelo dos puntos más preciso pero cuatro veces más caro no es claramente mejor. Uno algo más barato pero tres veces más lento fracasará en una función de cara al cliente diga lo que diga su puntuación.

Evalúa también el seguimiento de instrucciones y la fiabilidad al llamar herramientas. En la mayoría de los sistemas en producción, llamar a la función correcta con argumentos válidos pesa más que la inteligencia en bruto.

Paso 4: calcula el precio antes de comprometerte

def monthly_estimate(name, calls_per_month, avg_in, avg_out, cache_hit_rate=0.0):
    p = PRICING[name]                              # per million tokens
    billable_in = avg_in * (1 - cache_hit_rate) + avg_in * cache_hit_rate * p["cache_ratio"]

return calls_per_month * (
        (billable_in / 1_000_000) * p["input"]
        + (avg_out / 1_000_000) * p["output"]
    )
# Always run it at 10x expected volume before signing anything.

Dos palancas cambian mucho el resultado y a menudo se olvidan. El procesamiento por lotes suele reducir la tarifa a la mitad para el trabajo que no es urgente. El caché de prompts puede recortar el coste de la entrada repetida hasta en torno a un 90 por ciento, algo enorme cuando cada llamada arrastra el mismo contexto largo.

Tres familias de modelos

Los modelos cerrados vía API son la vía más rápida a producción y lideran la frontera, sin servidores que mantener. A cambio, tus datos pasan por sus sistemas, la factura crece de forma lineal y sin techo, y sus decisiones sobre precios y retirada de modelos te toca asumirlas.

Los modelos de pesos abiertos a través de un proveedor de hosting cuestan menos, se trasladan con más facilidad y mejoran rápido. El precio medio de lanzamiento de los modelos abiertos punteros subió de unos $0.48 en 2024 a $1.35 en 2026, todavía muy por debajo de los niveles cerrados. Una salvedad: los hostings externos a menudo sirven los modelos con menor precisión numérica para ahorrar, lo que puede restar algo de calidad, y sus compromisos de fiabilidad difieren de los del laboratorio original.

El autoalojamiento da control total sobre tus datos y ningún cargo por token. Lo pagas con capacidad de GPU y tiempo de ingeniería, y los parches, el escalado y la disponibilidad son cosa tuya. Se justifica por normas de soberanía o por tareas acotadas de gran volumen en las que un modelo pequeño ajustado supera a uno generalista en precio y precisión.

La mayoría de los sistemas maduros usan los tres, y no es indecisión. Es el diseño.

Cuestiones de seguridad

• Trata la residencia de datos como una entrada del diseño. Decide qué tipos de datos se pueden procesar y dónde antes de buscar proveedor. Añadirlo tarde es la forma en que los proyectos mueren en la revisión de cumplimiento.
• Lee con atención las condiciones de tratamiento de datos: plazos de retención, si las entradas entrenan modelos futuros, la lista de subencargados y qué región responde realmente a tus peticiones. Los contratos empresariales suelen diferir de las condiciones por defecto, y las condiciones por defecto son lo que obtienes si nadie pregunta.
• Un prompt es un flujo de datos saliente. Todo lo que contiene ya ha salido de tu perímetro, así que anonimiza antes de enviar y no después.
• El autoalojamiento traslada el riesgo sin eliminarlo. Ahora te toca proteger los pesos, cada endpoint de inferencia queda expuesto a ataques y las actualizaciones pasan a ser tu trabajo. Un endpoint interno de inferencia sin autenticación es un hallazgo frecuente y grave.
• Trata las claves de API como credenciales de producción: una por entorno y servicio, rotadas, con permisos mínimos y topes de gasto. Una clave filtrada supone un riesgo para los datos más una factura sin límite.
• Fija las versiones de los modelos. Los proveedores retiran y actualizan modelos sin avisar, y un modelo que cambia bajo tus pies puede romper un comportamiento que verificaste hace meses. Fija la versión y vuelve a pasar el golden set antes de aceptar cualquier cambio.

Lista de comprobación

• Una interfaz neutral respecto al proveedor, con los detalles de cada uno confinados en adaptadores
• La elección de modelo en la configuración, modificable sin desplegar
• Un respaldo con otro proveedor para caídas y límites de tasa
• Trabajo enrutado por niveles, con la cuestión de cumplimiento antes que la de coste
• Un golden set ejecutado con cada candidato para precisión, coste y latencia p95
• Llamadas a herramientas y seguimiento de instrucciones evaluados junto con la calidad de las respuestas
• Costes modelados para diez veces el volumen esperado
• Procesamiento por lotes y caché siempre que la carga lo permita
• Residencia decidida por clase de datos antes de elegir proveedor
• Versiones fijadas y revalidadas antes de actualizar
• Claves limitadas por servicio y con topes de gasto

Reflexión final

Quien dice que un modelo concreto es la respuesta está describiendo este mes, no tu sistema.

Los equipos sólidos tratan la elección de modelo como una decisión de enrutamiento dentro de una arquitectura estable. El trabajo barato va a modelos baratos, los datos regulados se quedan donde se les permite, la evaluación usa sus propias tareas y no el ranking de otro, y cualquiera de esas cosas puede cambiar en una tarde.

Los equipos que lo pasan mal coronaron a un favorito, lo enhebraron en cada capa del producto y acaban reescribiendo cada vez que el mercado se mueve. Con precios que se han reajustado dos veces en seis meses, eso suma un impuesto considerable.

Elige por carga de trabajo, construye la costura y rehaz las cuentas cada trimestre.