Smart Balancers

Un endpoint. Un panel de routing vivo detrás.

Enruta por intención y prioridad configuradas, con failover ordenado entre destinos disponibles.

Panel en directo

Balancer de ejemplo: support-balancer

online

petición

prompt del cliente

endpoint

Endpoint de ejemplo: support-balancer

ruta eficiente

activo

Ejemplo: qwen-cheap

resúmenes, borradores y respuestas sencillas

ruta de razonamiento

activo

Ejemplo: gpt-oss-120b

decisiones de soporte con varios pasos

ruta alternativa

activo

grupo de respaldo

el mismo endpoint sigue respondiendo

Plano de control

Mueve las decisiones de routing a la capa de control.

Trata Smart Balancers como una superficie de control de routing: mantén un único contrato para quien llama, ajusta las prioridades detrás y decide cuándo debe actuar una ruta por intención o un failover ordenado.

Entra la petición

01

Tu aplicación llama a un único endpoint estable.

El SDK sigue usando el balancer de ejemplo support-balancer en lugar de seleccionar endpoints de modelos directamente desde el código de la aplicación.

Ruta seleccionada

02

El panel elige el carril adecuado.

Enruta por intención y prioridad configuradas. El routing por intención añade una llamada a un modelo router, que puede sumar latencia y coste; el modo ordenado ofrece failover determinista entre destinos disponibles.

Fallback preparado

03

La ruta de respaldo ya está conectada.

Cuando falla la ruta principal, Smart Balancers mantienen el mismo contrato para quien llama y mueven el tráfico detrás.

Routing de fallback

Haz failover sin enseñar una segunda ruta a cada aplicación.

Cuando la ruta principal deja de estar disponible, Smart Balancers mantiene al cliente en el balancer de ejemplo support-balancer y mueve la ruta en la capa de control.

Ejemplo: support-balancer

cliente sin cambios

ruta principal

prioridad 1

estado de salud

no disponible

ruta alternativa

activa

  1. 01 Principal

    Las peticiones entran en el balancer de ejemplo support-balancer y prueban primero el grupo principal.

  2. 02 Fallo

    La ruta principal se marca como no disponible dentro de la capa de control.

  3. 03 Fallback

    El mismo endpoint sigue respondiendo a través del grupo de respaldo.

Routing basado en prompts

Usa los modelos potentes cuando el prompt lo merece.

Pon el routing por intención configurada detrás de un único endpoint. Añade una llamada a un modelo router, que puede sumar latencia y coste; el modo ordenado ofrece failover determinista entre destinos disponibles.

endpoint del panel

Ejemplo: support-balancer

Ambas decisiones ocurren detrás del mismo endpoint: los clientes siguen llamando al mismo nombre de modelo mientras el panel elige la ruta.

  1. Decisión de routing de ejemplo

    Resume esta respuesta de soporte.

    ruta eficiente

  2. Decisión de routing de ejemplo

    Resuelve una disputa de reembolso con varios pasos.

    ruta de razonamiento

Qué incluye Smart Balancers.

Routing, fallback y control del coste sin cambiar el contrato del cliente.

Grupos de destino

Agrupa varios modelos detrás de un balancer para mantener estable el endpoint mientras evoluciona la lógica de routing.

Routing de fallback

Combina un grupo primario con otro de fallback y usa failover ordenado entre destinos disponibles.

Routing basado en prompts

El routing por intención añade una llamada a un modelo router, que puede sumar latencia y coste al elegir destino.

Prioridades de ruta

El modo ordenado ofrece failover determinista probando los destinos disponibles por prioridad.

Endpoint compatible con OpenAI

Mantén los flujos existentes del SDK y apúntalos a un único endpoint del balancer.

Herencia del precio de capacidad

Las rutas respaldadas por Compute mantienen el precio por capacidad; las rutas de Public Models mantienen el precio por token.

Flujo de SDK existente

Un endpoint de balancer. El flujo de SDK que ya tienes.

Tu cliente habla con un único endpoint. Smart Balancers decide qué grupo responde detrás, en qué orden y cuándo entra el fallback.

Las rutas respaldadas por Compute mantienen el precio por capacidad; las rutas de Public Models mantienen el precio por token.

quickstart.py
from openai import OpenAI

client = OpenAI(
    base_url="https://api.qdiv0.com/v1",
    api_key="your-api-key",
)

response = client.chat.completions.create(
    model="support-balancer",
    messages=[{"role": "user", "content": prompt}],
)
Configuración de ruta de ejemplo · route_config.json

efficient_group

Ruta de intención configurada de ejemplo hacia un destino de menor coste.

reasoning_group

Ruta de intención configurada de ejemplo hacia un destino más potente.

fallback_group

Mantén una ruta de respaldo detrás del mismo endpoint.

Equilibra coste, calidad y continuidad detrás de un endpoint.

Pon la lógica de routing en la capa de control, no en cada cliente que la llama.