Todos los productos
Search
Centro de documentos

Platform For AI:Improve inference efficiency with the LLM intelligent router

Última actualización: Sep 05, 2026

Las cargas de trabajo de modelos de lenguaje extenso (LLM) presentan desafíos como longitudes de solicitud variables, generación aleatoria de tokens y fluctuaciones en la utilización de GPU. Los balanceadores de carga tradicionales no detectan la presión del backend en tiempo real, lo que provoca una distribución desigual de la carga entre instancias y degrada el rendimiento del sistema. Para resolver estos problemas, EAS ofrece el router inteligente para LLM, un servicio que integra programación inteligente y O&M visualizado. Este servicio equilibra dinámicamente la potencia de cómputo y la memoria de la GPU según las métricas del LLM en tiempo real para garantizar un alto throughput y estabilidad. El banco de trabajo WebUI integrado proporciona monitoreo en vivo, actualizaciones dinámicas de configuración y gestión de claves API multiusuario con aislamiento de identidad, lo que reduce significativamente la complejidad operativa.

Funcionamiento

Componentes principales

El servicio de router inteligente para LLM consta de los siguientes dos componentes principales:

  • LLM Gateway: Punto de entrada de tráfico y centro de procesamiento de solicitudes. Recibe las solicitudes de los usuarios y las reenvía a la instancia de inference destino según las decisiones del LLM Scheduler.

    • Admite los protocolos HTTP (HTTP_SSE) y WebSocket.

    • De forma predeterminada, la función de conversión de protocolo de la API de Anthropic está habilitada. Esta función convierte automáticamente las solicitudes compatibles con Anthropic a un formato compatible con OpenAI. Esto permite utilizar herramientas del ecosistema, como Claude Code, para invocar servicios de modelo que siguen el estándar de la API de OpenAI sin modificar el código. Para obtener más información, consulte Use Claude Code to make calls.

  • LLM Scheduler: Motor de programación inteligente. Selecciona la instancia destino óptima para cada solicitud según una directiva de programación, como el enrutamiento basado en caché de prefijos.

Flujo de trabajo

A continuación se describe el flujo de trabajo clave:

  1. Recepción de la solicitud: Una solicitud de usuario llega al LLM Gateway. Si las instancias de inference del backend experimentan una carga alta, el gateway coloca la solicitud en una cola.

  2. Programación inteligente: El LLM Gateway envía una solicitud de programación al LLM Scheduler. Posteriormente, el LLM Scheduler selecciona la instancia óptima según la directiva de programación y las métricas en tiempo real de cada instancia.

  3. Reenvío de la solicitud: Tras recibir la decisión de programación, el LLM Gateway reenvía la solicitud del usuario directamente a la instancia seleccionada.

image

Mecanismo de failover

Un mecanismo de tolerancia a fallos multicapa garantiza la estabilidad del servicio:

  • LLM Gateway: Se recomienda desplegar como mínimo dos instancias. Si una instancia falla, el tráfico se redirige automáticamente mediante failover a una instancia sana.

  • LLM Scheduler: Si el programador falla, el LLM Gateway recurre automáticamente al enrutamiento round-robin. Esto garantiza la disponibilidad a costa de perder la programación inteligente. Cuando el programador se recupera, reanuda automáticamente la programación inteligente.

  • Instancia de inference: Si una instancia de inference falla, el LLM Scheduler la elimina inmediatamente del pool disponible y deja de enrutar nuevo tráfico hacia ella. Una vez que la instancia se recupera, el programador la agrega nuevamente al pool de forma automática.

Limitaciones

  • Requisitos del grupo de servicios:

    • El router inteligente para LLM debe desplegarse en el mismo grupo de servicios que el servicio de inference para funcionar correctamente.

    • Un servicio de router inteligente y un servicio de cola no pueden coexistir en el mismo grupo de servicios.

  • El servicio de router inteligente solo se puede configurar al crear un nuevo servicio de inference: La pertenencia de un servicio a un grupo se define durante su creación y no se puede modificar posteriormente. Por lo tanto, la función de enrutamiento inteligente solo se puede configurar al crear un nuevo servicio de inference. No es posible utilizar Update service para agregar o modificar el enrutamiento inteligente en un servicio de inference existente.

  • Limitación del motor de inference: Solo se admiten vLLM o SGLang.

  • Incompatible con NLB y Nacos: No se puede utilizar el router inteligente para LLM con servicios de inference expuestos mediante NLB o Nacos.

  • Se recomiendan varias instancias: El router inteligente para LLM solo ofrece ventajas de programación cuando se despliegan múltiples instancias de inference.

Inicio rápido: Router inteligente para LLM

Paso 1: Desplegar el router inteligente para LLM

  1. Inicie sesión en la PAI console y seleccione la región destino en la parte superior de la página.

  2. En el panel de navegación izquierdo, haga clic en Elastic Algorithm Service (EAS). En la página de EAS, seleccione el espacio de trabajo destino.

  3. Haga clic en Deploy Service y luego seleccione Scenario-based Model Deployment > Deploy LLM gateway.

  4. Configure los parámetros:

    Parámetro

    Descripción

    Basic Information

    Service Name

    Introduzca un nombre personalizado para el servicio, por ejemplo, llm_gateway.

    Resource Information

    Deployment Resources

    Especifica la configuración de recursos para el LLM Gateway. Para garantizar alta disponibilidad, el Number of Replicas se establece en 2 de forma predeterminada; se recomienda mantener este valor. La configuración predeterminada es de 4 vCPUs y 8 GB de memory.

    Scheduling configuration

    Especifica la configuración de recursos para el LLM Scheduler. El valor predeterminado es de 2 vCPUs y 4 GB de memory.

    Scheduling Policy

    Directiva de balanceo de carga para las instancias de inference del backend. El valor predeterminado es Prefix cache. Para consultar una comparación detallada que le ayude a elegir, consulte Scheduling policy reference.

    Advanced Features

    Redis config

    Opcional. Persiste la información de usuarios y las estadísticas de uso. Si no se configura, el servicio utiliza la memoria local y los datos se pierden al detenerse el servicio. Para obtener más detalles, consulte Configure Redis persistent storage.

  5. Haga clic en Deploy. Cuando el estado del servicio cambie a Running, el despliegue se habrá completado correctamente.

    Después del despliegue, el sistema crea automáticamente un grupo de servicios llamado group_<nombre del servicio de router inteligente para LLM>. Para ver el grupo, vaya a la página de Elastic Algorithm Service (EAS) y haga clic en la pestaña Group Service.

Paso 2: Desplegar un servicio de LLM

Debe configurar la función de router inteligente al desplegar un nuevo servicio de LLM. No es posible agregar esta función a un servicio existente mediante la acción Update.

Los siguientes pasos utilizan el despliegue de Qwen3-8B como ejemplo:

  1. Haga clic en Deploy Service y luego seleccione Scenario-based Model Deployment > LLM Deployment.

  2. Configure los siguientes parámetros clave:

    Parámetro

    Valor

    Basic Information

    Model Settings

    Seleccione Public Model y, a continuación, busque y seleccione Qwen3-8B.

    Inference Engine

    Seleccione vLLM (recomendado; compatible con la API de OpenAI).

    Nota

    Si el servicio de router inteligente para LLM utiliza la Prefix cache como scheduling policy y usted selecciona vLLM como motor de inference, asegúrese de que la función de prefix caching esté habilitada para dicho motor.

    Deployment Template

    Seleccione Single node. El sistema completará automáticamente las especificaciones de instancia recomendadas, la imagen y otros parámetros a partir de la plantilla.

    Features

    LLM Intelligent Router

    Active el interruptor y seleccione el servicio de router inteligente para LLM desplegado en el Paso 1 de la lista desplegable.

  3. Haga clic en Deploy. El despliegue tarda aproximadamente 5 minutos. Cuando el estado del servicio cambie a Running, el despliegue se habrá completado correctamente.

Paso 3: Probar el servicio

Todas las solicitudes deben enviarse al endpoint de acceso del servicio de router inteligente para LLM, no a los servicios de inference del backend.

Nota
  • Si algún servicio de inference dentro del grupo de servicios tiene habilitada la distribución de tráfico, las solicitudes enviadas a través del punto de entrada de tráfico agregado del grupo podrían omitir el router inteligente, lo que provocaría fallos en la programación.

  • Asegúrese de que solo el servicio de router inteligente tenga habilitada la distribución de tráfico dentro del grupo de servicios. Envíe las solicitudes a través de la URL del punto de entrada de tráfico dedicado del servicio de router inteligente.

  1. Obtenga las credenciales de acceso.

    1. Vaya a la página de Overview del servicio de router inteligente para LLM. En la sección Basic Information, haga clic en View Endpoint Information.

    2. En la página Endpoint Information, bajo Service-specific Traffic Entry, copie el Internet Endpoint y el token.

    Importante

    El token del servicio mostrado aquí es la clave API de administrador. Si un administrador le asignó una clave API independiente a través del banco de trabajo WebUI, utilice su propia clave API para reemplazar <YOUR_TOKEN> en el siguiente ejemplo.

  2. Construya la URL de la solicitud e invoque el servicio.

    • Formato de URL: <endpoint de acceso del router inteligente para LLM>/<ruta de la API del servicio de LLM>

    • Ejemplo: http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions

    Ejemplo de solicitud:

    # Replace <YOUR_GATEWAY_URL> and <YOUR_TOKEN> with your actual values
    curl -X POST "<YOUR_GATEWAY_URL>/v1/chat/completions" \
         -H "Authorization: Bearer <YOUR_TOKEN>" \
         -H "Content-Type: application/json" \
         -N \
         -d '{
               "messages": [{"role": "user", "content": "Hello"}],
               "stream": true
             }'

    Ejemplo de respuesta:

    data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"role":"assistant","content":""},"logprobs":null,"finish_reason":null}]}
    data: {"id":"chatcmpl-9a9f8299*****","object":"chat.completion.chunk","created":1762245102,"model":"Qwen3-8B","choices":[{"index":0,"delta":{"content":"<think>","tool_calls":[]}}]}
    
    ...
    data: [DONE]

Una vez desplegado el servicio, puede utilizar el banco de trabajo WebUI para tareas como el monitoreo en vivo y la gestión de configuraciones. Para obtener más detalles, consulte Use the LLM intelligent router workbench.

Configurar Redis para almacenamiento persistente

El router inteligente para LLM incluye una función integrada de gestión de usuarios que admite la administración multiusuario, control de acceso basado en roles, registros de auditoría y resúmenes de datos. Puede utilizar una instancia externa de Redis para persistir la información de usuarios y las estadísticas de uso. Si no se configura Redis, el servicio utiliza la memoria local y todos los datos se pierden al detenerse el servicio. Para despliegues en producción, configure Redis para garantizar el almacenamiento persistente.

Paso 1: Aprovisionar una instancia de Tair (Redis)

  1. Adquiera una instancia desde la página de compra de Tair.

    Importante

    Al crear la instancia, seleccione la misma VPC y vSwitch que utiliza su servicio de router inteligente para LLM. Para las demás opciones, puede comenzar con las especificaciones mínimas.

  2. Agregue el bloque CIDR del vSwitch correspondiente al servicio de router inteligente para LLM a la lista de permitidos de la instancia. Para obtener más información, consulte Configure an allowlist.

  3. Haga clic en el ID de la instancia destino para abrir la página de detalles. Necesitará la información de conexión cuando despliegue el servicio de router inteligente para LLM.

    • Dirección de conexión y puerto: En la sección Instance information, ubique la dirección de conexión VPC y el número de puerto bajo Connection information.

    • Nombre de usuario y contraseña: En la página Account management, localice la cuenta predeterminada. Si no estableció una contraseña al crear la instancia, puede definirla o restablecerla desde aquí. También puede crear una nueva cuenta en lugar de utilizar la predeterminada.

Paso 2: Configurar Redis

Además de la configuración básica, debe configurar la VPC y agregar los parámetros de conexión de Redis para habilitar el almacenamiento persistente.

  • Configurar VPC: La VPC y el vSwitch deben ser los mismos que los de la instancia de Tair aprovisionada en el Paso 1. Esto garantiza que el servicio de router inteligente para LLM pueda conectarse a la instancia de Tair.

  • Configurar Redis:

    Console

    En la sección Advanced Features, habilite Redis config e introduzca los siguientes parámetros:

    Parámetro

    Descripción

    Redis Address

    La dirección de conexión de la instancia de Tair, con el formato <dirección VPC>:<puerto>. Por ejemplo, r-uxxx.redis.rds.aliyuncs.com:6379.

    Redis Username

    El nombre de usuario de la instancia de Tair.

    Redis Password

    La contraseña de la instancia de Tair.

    JSON

    En el nodo llm_gateway del cuerpo JSON, agregue los siguientes parámetros:

    Parámetro

    Descripción

    enable_user_management

    Habilita la gestión de usuarios. El valor predeterminado es true.

    redis_addrs

    La dirección de conexión de la instancia de Tair, con el formato <dirección VPC>:<puerto>. Por ejemplo, r-uxxx.redis.rds.aliyuncs.com:6379.

    redis_username

    El nombre de usuario de la instancia de Tair.

    redis_password

    La contraseña de la instancia de Tair.

    Ejemplo de JSON:

    {
        "llm_gateway": {
            "enable_user_management": true,
            "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379",
            "redis_username": "xxx",
            "redis_password": "xxx"
        }
    }

Configuración avanzada (JSON)

Utilice el despliegue JSON para configurar las especificaciones de recursos del LLM Gateway y ajustar finamente el manejo de sus solicitudes.

En la página Inference Service, haga clic en Deploy Service. En la sección Custom Model Deployment, haga clic en JSON Deployment.

Ejemplo de configuración

{
    "cloud": {
        "computing": {
            "instance_type": "ecs.c7.large"
        }
    },
    "llm_gateway": {
        "max_queue_size": 128,
        "retry_count": 2,
        "wait_schedule_timeout": 5000,
        "wait_schedule_try_period": 500
    },
    "llm_scheduler": {
        "cpu": 2,
        "memory": 4000,
        "policy": "prefix-cache"
    },
    "metadata": {
        "group": "group_llm_gateway",
        "instance": 2,
        "name": "llm_gateway",
        "type": "LLMGatewayService",
         "rpc": {
            "disable_auth": true
        }
    }
}

Parámetros

Parámetro

Descripción

metadata

type

Obligatorio. Debe establecerse en LLMGatewayService, lo cual indica el despliegue de un servicio de router inteligente para LLM.

instance

Obligatorio. Número de réplicas del LLM Gateway. Se recomienda establecer este valor en 2 o más para evitar un punto único de fallo.

cpu

Número de vCPUs para cada réplica del LLM Gateway.

memory

Memoria (en GB) para el LLM Gateway.

group

Grupo de servicios al que pertenece el servicio de router inteligente para LLM.

rpc.disable_auth

Obligatorio. Debe establecerse en true.

cloud.computing.instance_type

Especifica el tipo de instancia para el LLM Gateway. Si se especifica este parámetro, no es necesario configurar metadata.cpu ni metadata.memory.

llm_gateway

max_queue_size

Profundidad máxima de la cola para el LLM Gateway. Valor predeterminado: 128.

Cuando las solicitudes superan la capacidad del framework de inference del backend, el exceso se retiene en esta cola a la espera de programación.

retry_count

Número de reintentos. Valor predeterminado: 2. Si una instancia de inference del backend falla, el sistema reintenta la solicitud y la reenvía a una instancia sana.

wait_schedule_timeout

Cuando los motores del backend están a plena capacidad, este parámetro especifica el tiempo de espera total en milisegundos para programar una solicitud. El valor predeterminado es 5000 (5 segundos).

wait_schedule_try_period

Intervalo, en milisegundos, entre intentos de programación. El valor predeterminado es 500 (0.5 segundos).

request_stream_prefill_timeout

Tiempo de espera de prellenado en segundos para solicitudes de streaming. Es el tiempo máximo de espera para recibir el primer token. Valor predeterminado: 300.

request_stream_decode_timeout

Tiempo de espera de decodificación en segundos para solicitudes de streaming. Es el intervalo máximo de inactividad entre fragmentos consecutivos. Valor predeterminado: 300.

request_stream_total_timeout

Tiempo de espera total en segundos para toda la solicitud de streaming. Valor predeterminado: 0, lo que significa que no hay límite de tiempo.

request_non_stream_timeout

Tiempo de espera en segundos para solicitudes sin streaming. Es el tiempo máximo para obtener una respuesta completa. Valor predeterminado: 900.

llm_scheduler

cpu

Número de vCPUs para el LLM Scheduler. El valor predeterminado es 2.

memory

Memoria (en GB) para el LLM Scheduler. El valor predeterminado es 4 GB.

policy

Directiva de programación. Valor predeterminado: prefix-cache. Para consultar los valores disponibles y sus descripciones, consulte Scheduling Policy Reference.

prefill_policy

Cuando policy se establece en pd-split, debe especificar directivas de programación separadas para las etapas de Prefill y Decode. Los valores válidos son: prefix-cache, llm-metric-based, least-request y least-token.

decode_policy

Apéndice

Uso de Claude Code

  1. Configure Claude Code para utilizar la BASE URL y el TOKEN del servicio de router inteligente de EAS.

    # Replace <YOUR_GATEWAY_URL> and <YOUR_TOKEN> with your actual values
    export ANTHROPIC_BASE_URL=<YOUR_GATEWAY_URL>
    export ANTHROPIC_AUTH_TOKEN=<YOUR_TOKEN>
  2. Ejecute Claude Code.

    claude "Write a Python Hello World program"

Directivas de programación

La siguiente tabla compara la lógica, los casos de uso, las ventajas y las consideraciones de cada directiva de programación.

Directiva

Valor JSON

Descripción

Casos de uso

Ventajas

Consideraciones

Prefix cache

prefix-cache

(Recomendada) Directiva compuesta que prioriza el enrutamiento de solicitudes con el mismo historial de conversación (prompt) hacia una instancia que tenga una caché KV coincidente.

Chatbots de múltiples turnos y sistemas RAG con un prompt de sistema fijo.

Reduce significativamente el Tiempo hasta el Primer Token (TTFT) y mejora el rendimiento y el throughput en conversaciones de varios turnos.

Requiere que el motor de inference tenga habilitada la caché de prefijos.

Minimum Requests

least-request

Dirige las nuevas solicitudes a la instancia que actualmente esté procesando la menor cantidad de solicitudes.

Cargas de trabajo con complejidad de solicitud relativamente uniforme (longitudes de token y de generación similares).

Simple y eficiente. Equilibra rápidamente el conteo de solicitudes entre las instancias.

No considera el costo computacional real de las solicitudes. Las instancias que manejan solicitudes cortas pueden quedar inactivas mientras aquellas que procesan solicitudes largas se sobrecargan.

Minimum tokens

least-token

Dirige las nuevas solicitudes a la instancia que actualmente esté procesando la menor cantidad total de tokens (entrada + salida).

Cargas de trabajo donde el conteo de tokens refleja de manera confiable el costo de procesamiento.

Refleja la carga real de la instancia con mayor precisión que la directiva Least Request.

Depende de la estimación del conteo de tokens, y no todos los motores de inference reportan esta métrica.

Static PD Disaggregation

pd-split

Las instancias se dividen previamente en grupos de Prefill y Decode, y se establece una directiva de programación independiente para cada grupo.

Cargas de trabajo donde las etapas de Prefill y Decode tienen patrones de cómputo y acceso a memoria significativamente diferentes, y donde la desintegración ofrece ventajas claras.

Maximiza la utilización del hardware mediante ajustes específicos para cada etapa.

Compleja de configurar. Requiere comprender el modelo y la carga de trabajo, además de desplegar servicios separados para Prefill y Decode.

Evaluación comparativa de rendimiento

Las pruebas de rendimiento en los modelos Distill-Qwen-7B, QwQ-32B y Qwen2.5-72B demuestran que el router inteligente de LLM mejora significativamente la velocidad y el throughput de inference.

Importante

Estos resultados son solo de referencia. Ejecute sus propias evaluaciones para validar el rendimiento según su carga de trabajo.

Entorno de prueba

  • Directiva de programación: prefix-cache

  • Conjunto de datos de prueba: ShareGPT_V3_unfiltered_cleaned_split.json (conjunto de datos de conversaciones multivuelta)

  • Motor de inference: vLLM (0.7.3)

  • Instancias de backend: 5

Resultados de la prueba

Modelo de prueba

Distill-Qwen-7B

QwQ-32B

Qwen2.5-72b

Tipo de instancia

ml.gu8tf.8.40xlarge

ml.gu8tf.8.40xlarge

ml.gu7xf.8xlarge-gu108

Concurrencia

500

100

100

Métrica

Sin router inteligente

Con router inteligente

Mejora

Sin router inteligente

Con router inteligente

Mejora

Sin router inteligente

Con router inteligente

Mejora

Solicitudes exitosas

3698

3612

-

1194

1194

-

1194

1194

-

Duración de la evaluación

460.79 s

435.70 s

-

1418.54 s

1339.04 s

-

479.53 s

456.69 s

-

Tokens de entrada totales

6605953

6426637

-

2646701

2645010

-

1336301

1337015

-

Tokens generados totales

4898730

4750113

-

1908956

1902894

-

924856

925208

-

Throughput de solicitudes

8.03 req/s

8.29 req/s

+3.2%

0.84 req/s

0.89 req/s

+5.95%

2.49 req/s

2.61 req/s

+4.8%

Throughput de tokens de salida

10631.17 tok/s

10902.30 tok/s

+2.5%

1345.72 tok/s

1421.08 tok/s

+5.6%

1928.66 tok/s

2025.92 tok/s

+5.0%

Throughput total de tokens

24967.33 tok/s

25652.51 tok/s

+2.7%

3211.52 tok/s

3396.38 tok/s

+5.8%

4715.34 tok/s

4953.56 tok/s

+5.0%

TTFT promedio

532.79 ms

508.90 ms

+4.5%

1144.62 ms

859.42 ms

+25.0%

508.55 ms

389.66 ms

+23.4%

Mediana de TTFT

274.23 ms

246.30 ms

-

749.39 ms

565.61 ms

-

325.33 ms

190.04 ms

-

P99 de TTFT

3841.49 ms

3526.62 ms

-

5339.61 ms

5027.39 ms

-

2802.26 ms

2678.70 ms

-

TPOT promedio

40.65 ms

39.20 ms

+3.5%

68.78 ms

65.73 ms

+4.4%

46.83 ms

43.97 ms

+6.1%

Mediana de TPOT

41.14 ms

39.61 ms

-

69.19 ms

66.33 ms

-

45.37 ms

43.30 ms

-

P99 de TPOT

62.57 ms

58.71 ms

-

100.35 ms

95.55 ms

-

62.29 ms

54.79 ms

-