Cómo enrutar las solicitudes de LLM al modelo adecuado para cada tarea

Respuesta breve: enruta las solicitudes en tu aplicación y luego usa una sola clave de CometAPI y la URL base compatible con OpenAI https://api.cometapi.com/v1 para llamar al modelo seleccionado. Envía el trabajo repetitivo y fácil de verificar a un nivel de bajo costo; las interacciones con clientes sensibles a la latencia a un nivel rápido; y el trabajo ambiguo o de alto impacto a un nivel de alta precisión. Mantén las etiquetas como tu propia política, no como una clasificación universal de modelos, y mide cada nivel con el mismo conjunto de pruebas.

Esta guía construye ese enrutador de tres niveles con un ejemplo compacto en Python, una reserva limitada y un modelo de costos que cuenta reintentos y salidas rechazadas. El ejemplo usa IDs de modelos actuales del catálogo de CometAPI, pero la lógica de enrutamiento permanece separada para que los modelos puedan reemplazarse sin reescribir la aplicación.

¿Qué es el enrutamiento de LLM?

El enrutamiento de LLM es el proceso de enviar cada solicitud al modelo o nivel de servicio que mejor se ajuste a su tarea, objetivo de latencia, requisito de calidad y presupuesto.

¿Cómo debes enrutar solicitudes de LLM por tarea?

A 20 de agosto de 2026, los siguientes IDs de modelos y campos de precios del catálogo estaban disponibles a través de la API pública de Modelos de CometAPI. Las tarifas estimadas para consumidores a continuación aplican el valor actual de ratio del catálogo a sus precios base de entrada y salida, conforme a la guía de precios de CometAPI. Confirma la tarifa final mostrada para tu cuenta antes de usar en producción.

“Rápida” significa que la ruta tiene un objetivo de latencia; “alta precisión” significa que tiene un objetivo de calidad más estricto. Ninguna etiqueta demuestra que un modelo sea siempre el más rápido o el más preciso. Mide latencia p50 y p95, tasa de aprobación por tarea y costo por salida aceptada en tu propio tráfico antes de hacer el mapeo permanente.

¿Cómo configuras CometAPI para un enrutador de LLM?

Necesitas una clave de API de CometAPI, Python 3.10 o posterior, y el paquete de Python de OpenAI. Almacena la clave del lado del servidor en lugar de en el código fuente.

pip install openaiexport COMETAPI_KEY="your-key-here"

El ejemplo usa POST /v1/chat/completions. CometAPI documenta esto como una interfaz compartida para múltiples proveedores, pero el comportamiento de los parámetros aún puede variar según el modelo. Revisa la entrada actual del modelo y la referencia de Chat Completions antes de agregar campos específicos del proveedor.

¿Qué necesitas para construir un enrutador de LLM?

• Asigna tareas estables a niveles de servicio. No pidas a otro LLM que clasifique cada solicitud a menos que las señales simples de la aplicación sean insuficientes. Una etiqueta de soporte es trabajo previsiblemente de nivel económico; una respuesta en vivo es sensible a la latencia; una revisión de políticas merece la puerta de calidad más estricta.
• Valida la salida. Un estado HTTP exitoso no significa que el resultado sea utilizable. Pasa un validador específico de la tarea al enrutador. Un validador de clasificación puede verificar una etiqueta permitida; un validador de respuesta al cliente puede aplicar longitud y afirmaciones prohibidas; un flujo estructurado puede validar un esquema JSON.
• Limita las reservas. Intenta la siguiente ruta aprobada tras un tiempo de espera, 408, 429, 5xx temporales o un fallo acotado de la puerta de calidad. No uses otro modelo para ocultar entradas mal formadas, una clave inválida o parámetros no compatibles.

¿Cómo construyes un enrutador de LLM en Python?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

¿Cómo limitas los reintentos antes de una reserva?

Mantén los reintentos del SDK en cero y envuelve cada llamada de modelo con un límite explícito. El helper siguiente reintenta solo fallos de API reintables una vez y luego lanza la excepción para que la ruta externa pueda pasar al siguiente nivel aprobado.

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

En route(), reemplaza la llamada directa a client.chat.completions.create(...) con call_model(model, prompt). Con tres niveles, una solicitud se detiene tras como máximo seis llamadas a proveedores; los fallos de validación aún escalan una vez por nivel en lugar de reintentar la misma salida.

Ejecuta con python3 llm_task_router.py. Para cambiar proveedores o generaciones de modelos más adelante, actualiza MODELS; la política de tareas y el contrato de respuesta permanecen en un solo lugar.

El ejemplo usa solo parámetros compartidos por los modelos seleccionados. Agrega controles de tokens específicos de modelo mediante una capa adaptadora tras verificar la compatibilidad del modelo.

¿Cómo pruebas una política de enrutamiento de LLM?

Primero verifica que la política determinista seleccione el nivel primario previsto. Estas son expectativas de enrutamiento, no resultados de rendimiento de proveedores:

Una prueba de humo exitosa devuelve la respuesta más el nivel seleccionado, el ID del modelo, el uso de tokens y cada intento. Los valores reales de tokens y latencia variarán:

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

Para una comparación real, ejecuta las mismas solicitudes etiquetadas en los tres modelos. Registra la tasa de aprobación por tarea, la latencia p50 y p95, la tasa de errores, los tokens de entrada y salida, la tasa de reserva y la tasa de revisión humana. La métrica que más importa suele ser el costo por salida aceptada, no el costo por llamada a la API.

¿Cuánto cuesta el enrutamiento multi-modelo?

Usa una misma forma de carga para una comparación justa. Supón 1 millón de tokens totales: 800,000 tokens de entrada y 200,000 tokens de salida. Usando las tarifas derivadas del catálogo verificadas el 20 de agosto de 2026:

Si el tráfico es 60% económico, 30% rápido y 10% de alta precisión, el costo token combinado proyectado es aproximadamente $1.19 por 1 millón de tokens totales. Enviar la misma mezcla enteramente a la ruta de alta precisión sería alrededor de $7.20 bajo estas suposiciones. Este es un cálculo de precios, no una prueba de que la política mixta cumplirá tu objetivo de calidad.

Los reintentos y rechazos cambian el resultado. Una tasa de reintentos única del 5% eleva la proyección de $1.19 a aproximadamente $1.25. Si una salida de bajo costo falla la validación y se repite toda la solicitud en el nivel de alta precisión, cuenta ambas llamadas. Rastrea las salidas aceptadas para que un modelo aparentemente barato no oculte costos de revisión o regeneración.

¿Cuáles son los fallos de enrutamiento de LLM más comunes?

La guía de errores y reintentos recomienda reintentar límites de tasa y fallos temporales de la plataforma con backoff, mientras que las solicitudes mal formadas y fallos de autenticación deben corregirse. La guía de reserva igualmente mantiene las reservas de modelos ordenadas y explícitas.

Enrutamiento en la aplicación vs. CometAPI Auto: ¿Cuál deberías usar?

Usa enrutamiento en la aplicación cuando importen el control y la reproducibilidad. Mantén la decisión en tu código cuando las tareas sean estables y necesites identidades de modelo fijas, presupuestos por nivel, validadores personalizados y un orden de reserva auditable. Este enfoque también facilita comparar el mismo mapa de modelos entre versiones.

Usa CometAPI Auto cuando reducir el mantenimiento del enrutamiento importe más. Establece model=auto para un equilibrio predeterminado o model=auto-high cuando la calidad tenga mayor prioridad. CometAPI selecciona dinámicamente un modelo elegible a partir de las características de la solicitud y el pool de enrutamiento actual, por lo que el modelo subyacente puede variar; eso hace que Auto sea menos adecuado cuando cada ejecución debe usar el mismo modelo o parámetros específicos del modelo.

¿Cómo ejecutas el enrutamiento de LLM en producción?

• Actualiza el registro de modelos. Llama a GET https://api.cometapi.com/api/models durante el despliegue o el arranque y falla la versión si falta un ID configurado o un endpoint requerido. Los IDs de modelos, precios y capacidades pueden cambiar.
• Mantén las opciones específicas del proveedor fuera del enrutador. Una superficie común de Chat Completions no hace idéntico cada parámetro. Por ejemplo, el soporte para logprobs, controles de razonamiento o múltiples candidatos puede diferir. Coloca esas diferencias en adaptadores probados.
• Limita el tráfico y la salida. Limita la concurrencia antes de que las solicitudes salgan de la aplicación, usa backoff exponencial con jitter para 429 y establece un techo de tokens de salida. La guía de límites de tasa de CometAPI recomienda los mismos controles del lado de la aplicación.
• Registra la decisión. Registra el tipo de tarea, la versión de la política, el nivel elegido, el ID del modelo, la latencia, el uso de tokens, el resultado de la validación, el número de reintentos, la razón de la reserva y la estimación de costo. Evita registrar secretos o contenido de cliente innecesario.
• Promueve rutas con evidencia. Mantén un conjunto de evaluación etiquetado para cada tarea. Despliega cambios de mapeo gradualmente, compáralos con la política anterior y conserva una vía rápida de reversión.

Preguntas frecuentes

¿CometAPI decide automáticamente qué modelo es económico, rápido o preciso?

Este tutorial mantiene esa política en el código de la aplicación. CometAPI proporciona la clave compartida, la URL base, el catálogo de modelos, la interfaz de Chat Completions y los bloques de construcción de reservas documentados. Tu equipo define qué significa cada nivel y qué modelo ha pasado sus pruebas.

¿Una sola clave de CometAPI puede llamar a modelos de diferentes proveedores?

Sí. Para rutas de texto compatibles con OpenAI, usa https://api.cometapi.com/v1 y cambia el valor de model. El catálogo actual debe verificarse antes del despliegue.

¿Por qué no enviar cada solicitud al modelo más barato?

La tarifa de tokens más baja puede volverse costosa si las salidas fallan la validación, requieren reintentos o generan trabajo de revisión humana. Compara el costo por resultado aceptado y mantén tareas de alto impacto detrás de puertas de calidad más estrictas.

¿Debe un fallo de calidad activar una reserva?

Solo cuando el fallo sea detectable por máquina y la escalación esté acotada. Un error de esquema, un campo obligatorio faltante o una promesa prohibida pueden justificar una escalación. Una insatisfacción vaga debería convertirse en datos de evaluación en lugar de un bucle de reintentos ilimitados.

¿Con qué frecuencia debe cambiar el mapa de modelos?

Cámbialo cuando los datos actuales del catálogo y una evaluación repetible muestren un mejor compromiso. No gires modelos solo porque aparece un nombre nuevo en el catálogo.

¿Puedo añadir un modelo de OpenAI más adelante?

Sí. Añade un ID de modelo actual compatible con OpenAI a MODELS, prueba el mismo contrato de solicitud y respuesta y colócalo en el orden de rutas. El cliente, la clave y la URL base permanecen sin cambios.

¿Cómo mantienes una política de enrutamiento de LLM sostenible?

El enrutador multi-proveedor más simple no es una caja negra autónoma. Es una política de tareas corta y versionada respaldada por acceso compartido a la API, metadatos de modelos actuales, un validador de calidad y una cadena de reservas estrecha. CometAPI reduce el trabajo de conexión a una clave y una URL base compatible con OpenAI; tu aplicación mantiene el control de las decisiones de costo, latencia y calidad.