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:
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.Programación inteligente: El
LLM Gatewayenvía una solicitud de programación alLLM Scheduler. Posteriormente, elLLM Schedulerselecciona la instancia óptima según la directiva de programación y las métricas en tiempo real de cada instancia.Reenvío de la solicitud: Tras recibir la decisión de programación, el
LLM Gatewayreenvía la solicitud del usuario directamente a la instancia seleccionada.
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 Gatewayrecurre 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 Schedulerla 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
Inicie sesión en la PAI console y seleccione la región destino en la parte superior de la página.
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.
Haga clic en Deploy Service y luego seleccione Scenario-based Model Deployment > Deploy LLM gateway.
-
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.
-
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:
Haga clic en Deploy Service y luego seleccione Scenario-based Model Deployment > LLM Deployment.
-
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).
NotaSi 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.
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.
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.
-
Obtenga las credenciales de acceso.
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.
En la página Endpoint Information, bajo Service-specific Traffic Entry, copie el Internet Endpoint y el token.
ImportanteEl 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. -
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)
-
Adquiera una instancia desde la página de compra de Tair.
ImportanteAl 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.
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.
-
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_gatewaydel cuerpo JSON, agregue los siguientes parámetros:Parámetro
Descripción
enable_user_managementHabilita la gestión de usuarios. El valor predeterminado es
true.redis_addrsLa 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_usernameEl nombre de usuario de la instancia de Tair.
redis_passwordLa 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 |
|
instance |
Obligatorio. Número de réplicas del |
|
|
cpu |
Número de vCPUs para cada réplica del |
|
|
memory |
Memoria (en GB) para el |
|
|
group |
Grupo de servicios al que pertenece el servicio de router inteligente para LLM. |
|
|
rpc.disable_auth |
Obligatorio. Debe establecerse en |
|
|
cloud.computing.instance_type |
Especifica el tipo de instancia para el |
|
|
llm_gateway |
max_queue_size |
Profundidad máxima de la cola para el 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 |
|
memory |
Memoria (en GB) para el |
|
|
policy |
Directiva de programación. Valor predeterminado: |
|
|
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
-
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> -
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.
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 |
- |