LLM Router: Enruta Peticiones y Recorta Costes un 60% [2026]

LLM Router: Enruta Peticiones y Recorta Costes un 60% [2026]

Un LLM router es una capa fina entre tu aplicación y varios modelos de lenguaje que decide qué modelo atiende cada petición. Inspecciona la petición (tipo de tarea, complejidad, presupuesto de tokens), la reenvía al modelo más adecuado y, si ese modelo falla, recurre a un respaldo. El objetivo: respuestas a la medida de cada tarea al menor coste por token.

Pagarle a un modelo frontera para responder "¿cuál es vuestra política de reembolsos?" es la forma clásica de inflar la factura. AWS midió la alternativa en abril de 2025: un router con clasificador añade 0,53 segundos de latencia, un router semántico añade 0,10 segundos y el enrutamiento dentro de una misma familia de modelos rebaja la factura hasta un 30%. Si rehaces esas cuentas entre proveedores con los precios de lista de julio de 2026, como hacemos más abajo, el recorte llega al 70%. La mayor parte del ahorro nace de una sola decisión, tomada antes de generar un solo token.

Conclusiones Clave

• Un LLM router decide qué modelo atiende cada petición, según el tipo de tarea, el coste o la calidad medida.
• Existen cinco estrategias: basada en reglas, sensible al coste, sensible a la latencia, semántica (embeddings) y enrutamiento con clasificador LLM.
• El enrutamiento por reglas añade ~0 ms y 0 $; el enrutamiento con clasificador añade 300-800 ms más el coste en tokens del clasificador por petición.
• El enrutamiento puede recortar el gasto en tokens hasta un 60% cuando la mayor parte del tráfico simple pasa a un modelo 10-20 veces más barato.
• ¿Un solo proveedor, menos de 10.000 peticiones al día y sin presión de costes? Sáltate el router. Unos simples fallbacks bastan.

¿Qué Hace Exactamente un LLM Router?

Un LLM router ejecuta un pequeño paso de decisión antes de cada llamada al modelo: lee la petición, la puntúa contra una regla de enrutamiento, elige un modelo, envía la llamada y reintenta sobre un fallback si el primer modelo falla. Nada más cambia en tu aplicación. Sigues haciendo una petición y recibiendo una respuesta.

El ciclo de vida de la petición, en orden:

1. La petición llega al endpoint del router, exactamente igual que llegaría a la API de un modelo.
2. Análisis. El router inspecciona el prompt: palabras clave, recuento de tokens, un embedding o la puntuación de un clasificador.
3. Selección. La estrategia de enrutamiento traduce esa señal a un nivel de modelo (barato, intermedio, frontera o local).
4. Reenvío. La llamada sale hacia el modelo elegido a través de una API compatible con OpenAI.
5. Fallback. Ante un timeout, un límite de tasa o un error, la petición se reintenta en el siguiente nivel de la cadena.

La gente busca "llm gateway vs router" porque la documentación de los proveedores difumina los términos. Una frase lo arregla: el gateway es la tubería; el router es la decisión. Son capas, no rivales, y la mayoría de los gateways llevan un router dentro.

Según la documentación de LiteLLM, el mismo proxy que guarda tus claves virtuales también ejecuta el router. ¿Comparas las herramientas a nivel de tubería en concreto? Nuestro ranking de las mejores herramientas de gateway LLM clasifica diez.

¿Siquiera Necesitas un LLM Router?

La mayoría de las aplicaciones pequeñas no. Un router se gana el sueldo cuando el tráfico se divide en tipos de tarea claramente distintos, cuando la factura de tokens es tu mayor coste de infraestructura o cuando trabajas con más de un proveedor y necesitas failover. Por debajo de esos umbrales, unos simples reintentos más un modelo de respaldo te compran la fiabilidad sin la pieza móvil.

Lo diremos sin rodeos, porque nadie más en este sector lo hará: si trabajas con un solo proveedor por debajo de 10.000 peticiones al día, un router es sobrecarga que no necesitas. Los fallbacks simples ganan.

¿Por qué tanta franqueza? Cada ruta es una afirmación ("esta clase de tarea es segura en el modelo barato") que se degrada a medida que cambian los modelos, los precios y tu producto. Compra ese coste de mantenimiento solo cuando el ahorro lo supere con claridad.

Las 5 Estrategias de Enrutamiento LLM (Y Cuándo Usar Cada Una)

Toda estrategia de enrutamiento LLM responde a una sola pregunta: ¿en qué señal confías lo bastante para elegir un modelo? Las reglas confían en palabras clave. El enrutamiento por coste confía en el presupuesto de tokens. El enrutamiento por latencia confía en un cronómetro. El enrutamiento semántico confía en embeddings. El enrutamiento con clasificador confía en otro LLM. El intercambio tiene siempre la misma forma: más calidad de señal, más latencia y coste añadidos por petición.

El autocompletado las muestra como "llm routing strategies", "llm task routing", "llm intent routing" y "llm dynamic routing". Se corresponden con cinco patrones:

Un patrón atraviesa los cinco: la cascada, también llamada escalonamiento de modelos. Empieza barato y escala solo ante un fallo o una confianza baja. Un bot de soporte responde con un modelo de 0,25 $ por millón de tokens; si su confianza cae por debajo de 0,7, la misma petición se reintenta en un modelo frontera. Pagas inteligencia solo cuando el nivel barato admite que está atascado.

Para profundizar en lo académico, la biblioteca LLMRouter de ulab-uiuc cataloga más de 16 algoritmos de enrutamiento investigados (KNN, SVM, MLP, factorización de matrices, Elo, grafos y estilo BERT). Si el enrutamiento semántico es tu elección, los embeddings de ejemplo lo deciden casi todo; nuestra guía de los mejores modelos de embeddings cubre cuáles aguantan con corpus reales.

¿Cómo Construyes un LLM Router en Python?

Lo construyes con unas 80 líneas de Python sencillo contra cualquier endpoint compatible con OpenAI. Sin frameworks. Los cuatro routers de abajo escalan en sofisticación: reglas de palabras clave, un umbral de coste, similitud de embeddings y un modelo clasificador con failover. Cada uno imprime el modelo que eligió, para que veas la decisión ocurrir.

Si has buscado "how to build an llm router" y solo encontraste stacks de AWS CDK y repos académicos, esta sección es la respuesta sencilla. La implementación de referencia de AWS es sólida, pero está soldada a Bedrock, Lambda y CDK. La nuestra corre donde apunte el cliente de OpenAI: OpenAI, Anthropic a través de un proxy, Ollama en un portátil, vLLM en una máquina con GPU. Este es el router que primero bosquejamos para los clientes.

Paso 1: Router basado en reglas (palabras clave a modelos)

La línea base de latencia cero. Un mapa de regex decide; todo lo que no coincide va al nivel frontera.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Entrada: una pregunta de soporte. Decisión: coincidencia de regex con "cancel". Modelo elegido: gpt-5-mini. No hizo falta ninguna llamada API para enrutarla, por eso este sigue siendo el predeterminado.

Paso 2: Router sensible al coste (umbral de presupuesto de tokens)

La misma idea, pero la señal es el tamaño de la petición en lugar de las palabras clave. Los prompts cortos con presupuestos de salida pequeños van al barato; todo lo demás va al frontera.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

¿Burdo? Sí. ¿Eficaz? También, porque el volumen de tokens se correlaciona con el tamaño de la tarea mejor de lo que la mayoría espera. Esta es la estrategia entera detrás de varios productos de pago de "cheap llm router".

Paso 3: Router semántico (embeddings contra ejemplos)

Para la entrada de usuario difusa que esquiva las palabras clave, genera un embedding del prompt y compáralo con embeddings de prompts de ejemplo. El clúster más cercano se queda con la petición.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

La llamada de enrutamiento cuesta un embedding (unos cientos de tokens) y 50-150 ms. Precomputa los centroides al arrancar, no por petición.

Paso 4: Router con clasificador LLM y fallback

La señal más fuerte: un modelo barato lee el prompt y puntúa su dificultad. Esta es la estrategia que AWS midió en 0,53 segundos de latencia añadida, así que la envolvemos en una cadena de fallback.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Ese es todo el ejemplo de llm router: cuatro funciones, un cliente, sin más infraestructura que la que ya ejecutas. El endurecimiento para producción es la siguiente sección.

¿Cuánto Ahorra de Verdad el Enrutamiento LLM?

AWS midió la sobrecarga del router en 107,90-188,90 $ al mes por cada 100.000 preguntas al día, con el enrutamiento con clasificador añadiendo 0,53 segundos por petición y el semántico 0,10 segundos. El lado del ahorro empequeñece esa sobrecarga. Nuestro ejemplo calculado de abajo, construido sobre los precios de lista de julio de 2026, aterriza en una reducción del gasto del 70,7%. La trampa está en la mezcla de tráfico: necesitas que la mayoría de las peticiones califiquen para el nivel barato.

Dos tablas. Primero, lo que el propio router te cuesta por cada 1.000 peticiones:

La entrada de AWS de abril de 2025 es el único conjunto de mediciones publicado de forma independiente en este terreno, así que nos anclamos a él y etiquetamos nuestras extensiones como estimaciones, no como cifras que ejecutamos. El Bedrock Intelligent Prompt Routing recortó el coste dentro de una misma familia hasta un 30%, según AWS.

Segundo, el ejemplo de ahorro calculado que respalda nuestro titular:

Supuestos, etiquetados: 100.000 peticiones al mes; 800 tokens de entrada más 200 de salida por petición en promedio; una división 80% simple / 20% compleja; precios de lista de la página de precios de Anthropic y la página de precios de OpenAI a julio de 2026, con la tabla completa de tarifas en nuestra comparativa de precios de API LLM. Cuentas por petición: Sonnet 4 cuesta 800 x 3 $/M + 200 x 15 $/M = 0,0054 $; GPT-5 mini cuesta 800 x 0,25 $/M + 200 x 2 $/M = 0,0006 $.

El resultado es una reducción del 70,7%, de donde sale el 60% de nuestro título, con margen de sobra. Advertencias honestas: esto es un ejemplo calculado, no un benchmark que ejecutáramos. Asume que tu nivel barato es 10-20 veces más económico y que el 80% del tráfico califica de verdad. El enrutamiento dentro de una familia, el escenario de AWS, se queda cerca del 30%. Y el enrutamiento es una palanca entre muchas; el caching y el recorte de prompts suelen rentabilizarse antes, y nuestra guía de formas de reducir los costes de API LLM clasifica las doce.

Patrones de Enrutamiento en Producción

Un router de juguete elige un modelo. Un router de producción además reintenta, equilibra la carga, cachea las repeticiones y aísla las claves API por equipo. Pasadas unas pocas miles de peticiones al día, deja de fabricar esas piezas a mano y ejecuta un gateway que lleve un router dentro.

Los cuatro patrones que importan:

• Cadenas de fallback. Primero el nivel barato, el frontera ante un error o timeout. El patrón de mayor valor con diferencia; la mayor parte de tu fiabilidad viene solo de esto.
• Balanceo de carga. Reparte las llamadas entre despliegues duplicados o claves API para esquivar los límites de tasa por clave.
• Caché de respuestas. Los prompts idénticos devuelven respuestas cacheadas. El tráfico de soporte se repite más de lo que creerías; las tasas de acierto del 10-30% son comunes.
• Claves virtuales y presupuestos. Emite claves por equipo con topes mensuales para que un bucle descontrolado no queme la factura entera.

Esto se acerca a la configuración que ejecutamos en nuestro stack de agentes de staging (archivo: litellm-router.yaml, montado en el contenedor del proxy de LiteLLM):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Dónde encaja cada herramienta, con opinión:

• LiteLLM. Elígelo si quieres autoalojado y de código abierto y ya ejecutas Docker. Nuestra guía de configuración del proxy de LiteLLM recorre el despliegue completo, claves y presupuestos incluidos.
• OpenRouter. Elígelo si quieres cientos de modelos detrás de una sola clave y cero operaciones. Su página de rankings sirve a la vez como datos de throughput.
• Portkey. Elígelo si los requisitos empresariales (SSO, registros de auditoría, informes de cumplimiento) mandan en la decisión.
• Código propio de este artículo. Elígelo si estás por debajo de ~50.000 peticiones al día y no quieres infraestructura nueva.

Sea cual sea tu elección, el ranking de herramientas de gateway LLM compara diez de ellas cara a cara.

¿Se Puede Enrutar Entre Modelos Locales y APIs Alojadas?

Sí, y las cuentas de tokens son seductoras: un modelo local factura 0 $ por token, así que cada petición que responden Ollama o vLLM es ahorro puro. El intercambio es latencia y calidad por vatio. Lo local gana en tareas simples de alto volumen sobre hardware que ya tienes; la API alojada atrapa todo lo que necesita un cerebro frontera.

La mecánica es anticlimática, y ese es el punto. Ollama expone un endpoint compatible con OpenAI en localhost:11434/v1, y vLLM sirve la misma forma. Así que todos los routers de arriba funcionan sin cambios: apunta base_url al servidor local, pon qwen3:8b en el hueco barato y mantén gpt-5 como nivel de respaldo. Para una caja de router autoalojada, LiteLLM se distribuye como imagen de Docker, que es el montaje de "llm router docker" que la gente busca.

Dos notas de honestidad. Un modelo de 70B en una sola A100 sirve unos 30-40 tokens por segundo; las APIs alojadas superan eso en throughput de ráfaga, así que el enrutamiento local encaja mejor con el tráfico de fondo constante que con el chat de cara al usuario con picos. Y los modelos locales de 8B tropiezan con las llamadas a herramientas de varios pasos, así que mantén las rutas difíciles apuntando a la nube. Si estás eligiendo el propio motor de serving, vLLM vs SGLang hace el benchmark de ambos.

El enrutamiento también alimenta los montajes de agentes de programación multimodelo. Un proxy estilo LiteLLM deja que Claude Code hable con modelos locales y alojados a través de un solo endpoint; mira cómo usar diferentes modelos en Claude Code para ver el cableado exacto.

¿Cómo Sabes Si el Enrutamiento Está Funcionando?

Lo mides, o estás adivinando. Registra qué modelo respondió cada petición, puntúa una muestra de las salidas contra una rúbrica y devuelve esas puntuaciones a las reglas de enrutamiento. Los equipos que se saltan este paso acaban con una configuración estática que se pudre en silencio mientras los modelos y los precios cambian debajo de ella.

El arco de graduación recorre reglas, luego coste, luego calidad medida:

1. Registra la ruta. Guarda el modelo elegido, la latencia y los recuentos de tokens por petición como una columna más en tus trazas existentes.
2. Puntúa las salidas cada semana. Un juez LLM o una muestra humana, aprobado/suspenso por clase de petición. Cincuenta salidas calificadas por clase bastan para orientarte.
3. Reajusta. Si el nivel barato aprueba el 95% o más en una clase, amplía su regla para capturar más de ese tráfico. Si cae por debajo del 90%, estréchala.

Esta es la línea que repetimos a los clientes sin parar: un router que nunca reajustas es solo una configuración estática con latencia extra. Registra el modelo elegido, puntúa las salidas, devuelve las puntuaciones.

Ese bucle es evals más observabilidad aplicados al enrutamiento. Nuestra guía de evals LLM cubre las rúbricas de puntuación; la guía de observabilidad de IA cubre dónde viven las trazas.

¿Hacia Dónde Va la Investigación del Enrutamiento LLM?

La línea académica trata el enrutamiento como un problema de aprendizaje, no como un archivo de configuración. LLMRouter de ulab-uiuc, la biblioteca que rankea primero para esta palabra clave, implementa más de 16 algoritmos (KNN, SVM, MLP, factorización de matrices, Elo, grafos, BERT y routers con RL) con un pipeline de benchmark sobre 11 datasets. El paper reciente más citado, RouteLLM (Ong et al., arXiv:2406.18665), entrena routers con datos de preferencia humana y reporta más de 2x de reducción de coste sin pérdida de calidad en MMLU y MT-Bench. La novedad más reciente: los routers de activaciones de prefill, la línea de "prefill is all you need", que leen las activaciones internas de un modelo durante el prefill para predecir la dificultad antes de que empiece la generación. La dirección del viaje son routers que se entrenan solos con tus datos de evals, que es exactamente el bucle de retroalimentación de la sección anterior.

Cómo lo enfoca Techsy: los stacks de agentes que entregamos a clientes B2B ejecutan exactamente este patrón, un router por niveles de coste con cadenas de fallback cableadas al gateway, más reajustes guiados por evals. Si estás valorando si el enrutamiento encaja en tu stack, pide una consulta gratuita y mapeamos juntos tu mezcla de tráfico.

Preguntas Frecuentes

¿Qué es un LLM router?

Un LLM router es una capa entre tu aplicación y varios modelos de lenguaje que decide qué modelo atiende cada petición. Comprueba el tipo de tarea, el tamaño o la dificultad de la petición y la reenvía al modelo más adecuado, con un fallback si ese modelo falla. Piénsalo como un controlador de tráfico para tus llamadas a la API de modelos.

¿Cómo funciona el enrutamiento LLM?

El enrutamiento LLM funciona en cinco pasos: la petición llega, el router la inspecciona (palabras clave, recuento de tokens o un embedding), una estrategia elige un nivel de modelo, la llamada se reenvía y un modelo de respaldo atrapa cualquier fallo. Toda la decisión ocurre antes de que empiece la generación, así que añade milisegundos, no segundos, a menos que un modelo clasificador haga la puntuación.

¿Es lo mismo un LLM router que un LLM gateway?

No. Un gateway es la tubería: claves API, límites de tasa, presupuestos y registros. Un router es la decisión: qué modelo responde. Son capas, no rivales, y la mayoría de los gateways (LiteLLM, Portkey, OpenRouter) llevan un router dentro. Puedes ejecutar un router sin un gateway, pero en producción normalmente querrás los dos juntos.

¿El enrutamiento de modelos ahorra dinero de verdad?

Sí, cuando la mayor parte de tu tráfico califica para un nivel mucho más barato. Nuestro ejemplo calculado mueve el 80% de las peticiones de un modelo de 3 $/15 $ por millón de tokens a uno de 0,25 $/2 $ y recorta la factura un 70,7%. AWS reportó hasta un 30% para el enrutamiento dentro de una misma familia de modelos. Si tu tráfico es uniformemente complejo, el ahorro se encoge hacia cero.

¿Cuál es el mejor LLM router de código abierto?

Para producción, LiteLLM: autoalojado, mantenido de forma activa y combina un gateway con un router. Para algoritmos de nivel académico, LLMRouter de ulab-uiuc implementa más de 16 estrategias de enrutamiento de la literatura académica. RouteLLM es el router de mayor calidad por dólar entrenado con datos de preferencia. La mayoría de los equipos deberían empezar con LiteLLM y recurrir a las bibliotecas de investigación solo si necesitan puntuación a medida.

¿Cómo construyo un LLM router en Python?

Empieza con el cliente de OpenAI y unas 80 líneas de código: un mapa de reglas de palabras clave a modelos, un umbral de coste sobre el recuento de tokens, similitud de embeddings con prompts de ejemplo o un modelo clasificador barato que puntúa la dificultad. Los cuatro patrones están en la sección de construcción de arriba, ejecutables contra OpenAI, Ollama o vLLM sin cambios.

¿Puedo enrutar entre modelos locales y APIs en la nube?

Sí. Ollama (localhost:11434/v1) y vLLM exponen endpoints compatibles con OpenAI, así que el mismo código del router apunta a un modelo local para el tráfico barato y a una API alojada para el tráfico difícil. Los tokens locales cuestan 0 $, pero el hardware y la latencia corren de tu cuenta. Este es el patrón detrás de la mayoría de los montajes multimodelo de Claude Code.

¿Qué es el enrutamiento semántico?

El enrutamiento semántico genera un embedding de cada prompt entrante y lo compara con embeddings de prompts de ejemplo, enviando la petición al modelo que posea el clúster de ejemplos más cercano. Maneja la entrada de usuario difusa y parafraseada que las reglas de palabras clave se pierden, a un coste de 50-150 ms más tokens de embedding por petición. AWS lo midió en 0,10 segundos de latencia añadida.

¿Cuánta latencia añade un router con clasificador LLM?

AWS midió 0,53 segundos de latencia añadida para la clasificación asistida por LLM, frente a 0,10 segundos del enrutamiento semántico. El enrutamiento basado en reglas y el sensible al coste añaden aproximadamente cero, porque son rutas de código puro. Si tu producto tiene un SLA de tiempo de respuesta ajustado, prefiere reglas, umbrales de coste o embeddings, y reserva el clasificador para cargas de trabajo offline o en cola.

Fuentes

• Seifi, N. y Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (consultado el 30 de julio de 2026)
• Código de ejemplo de AWS: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (consultado el 30 de julio de 2026)
• Documentación de LiteLLM. https://docs.litellm.ai (consultado el 30 de julio de 2026)
• Precios de Anthropic. https://www.anthropic.com/pricing (consultado el 30 de julio de 2026)
• Precios de la API de OpenAI. https://openai.com/api/pricing (consultado el 30 de julio de 2026)
• LLMRouter de ulab-uiuc. https://github.com/ulab-uiuc/LLMRouter (consultado el 30 de julio de 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (consultado el 30 de julio de 2026)
• Rankings de OpenRouter. https://openrouter.ai/rankings (consultado el 30 de julio de 2026)