Cargas de trabalho de Modelos de Linguagem Grandes (LLM) apresentam desafios como comprimentos variáveis de requisição, geração aleatória de tokens e utilização flutuante de GPU. Balanceadores de carga tradicionais não detectam a pressão no backend em tempo real, o que causa distribuição desigual entre instâncias e degradação do desempenho do sistema. Para resolver esses problemas, o EAS oferece o roteador inteligente de LLM, um service que integra agendamento inteligente e O&M visualizado. Ele equilibra dinamicamente o poder computacional e a memória da GPU com base em métricas de LLM em tempo real para garantir alto throughput e estabilidade. A bancada WebUI integrada ao service fornece monitoramento ao vivo, atualizações dinâmicas de configuração e gerenciamento de chaves de API multiusuário com isolamento de identidade, reduzindo significativamente a complexidade operacional.
Como funciona
Componentes principais
O service de roteador inteligente de LLM consiste nos dois componentes principais a seguir:
-
LLM Gateway: O ponto de entrada de tráfego e centro de processamento de requisições. Recebe as requisições do usuário e as encaminha para a instância de inferência de destino com base nas decisões do
LLM Scheduler.Suporta os protocolos HTTP (HTTP_SSE) e WebSocket.
Por padrão, o recurso de conversão de protocolo da API Anthropic está ativado. Esse recurso converte automaticamente requisições compatíveis com Anthropic para um formato compatível com OpenAI. Isso permite usar ferramentas do ecossistema, como Claude Code, para chamar services de modelo que seguem o padrão da API OpenAI sem modificações no código. Para obter mais informações, consulte Usar Claude Code para fazer chamadas.
LLM Scheduler: O mecanismo de agendamento inteligente. Selecione a instância de destino ideal para cada requisição com base em uma política de agendamento, como roteamento por prefix-cache.
Fluxo de trabalho
O fluxo de trabalho principal é descrito abaixo:
Recebimento da requisição: Uma requisição de usuário chega ao
LLM Gateway. Se as instâncias de inferência do backend estiverem sob alta carga, o gateway coloca a requisição na fila.Agendamento inteligente: O
LLM Gatewayenvia uma requisição de agendamento para oLLM Scheduler. Em seguida, oLLM Schedulerselecione a instância ideal com base na política de agendamento e nas métricas em tempo real de cada instância.Encaminhamento da requisição: Após receber a decisão de agendamento, o
LLM Gatewayencaminha a requisição do usuário diretamente para a instância selecionada.
Mecanismo de failover
Um mecanismo de tolerância a falhas em várias camadas garante a estabilidade do service:
LLM Gateway: Recomendamos implantar pelo menos duas instâncias. Se uma instância falhar, o tráfego fará failover automaticamente para uma instância íntegra.
LLM Scheduler: Se o agendador falhar, o
LLM Gatewayreverte automaticamente para o roteamento round-robin. Isso garante a disponibilidade à custa do agendamento inteligente. Quando o agendador se recupera, ele retoma automaticamente o agendamento inteligente.Instância de inferência: Se uma instância de inferência falhar, o
LLM Schedulera remove imediatamente do pool disponível e interrompe o roteamento de novo tráfego para ela. Após a recuperação da instância, o agendador a adiciona automaticamente de volta ao pool.
Limitações
-
Requisitos do grupo de services:
O roteador inteligente de LLM deve ser implantado no mesmo grupo de services que o service de inferência para funcionar corretamente.
Um service de roteador inteligente e um service de fila não podem coexistir no mesmo grupo de services.
O service de roteador inteligente só pode ser configurado durante a criação de um novo service de inferência: A associação de um service a um grupo é definida na criação e não pode ser alterada posteriormente. Portanto, o recurso de roteamento inteligente só pode ser configurado quando você crie um novo service de inferência. Não é possível usar Atualize service para adicionar ou modifique o roteamento inteligente em um service de inferência existente.
Limitação do mecanismo de inferência: Apenas vLLM ou SGLang são suportados.
Incompatível com NLB e Nacos: Não é possível usar o roteador inteligente de LLM com services de inferência expostos via NLB ou Nacos.
Várias instâncias recomendadas: O roteador inteligente de LLM oferece benefícios de agendamento apenas quando você implanta várias instâncias de inferência.
Início rápido: Roteador inteligente de LLM
Etapa 1: Implantar o roteador inteligente de LLM
Faça logon no PAI console e selecione a região de destino na parte superior da página.
No painel de navegação à esquerda, clique em Elastic Algorithm Service (EAS). Na página do EAS, selecione o workspace de destino.
Clique em Deploy Service e, em seguida, selecione Scenario-based Model Deployment > Deploy LLM gateway.
-
Configure os parâmetros:
Parâmetro
Descrição
Basic Information
Service Name
Insira um nome personalizado para o service, por exemplo,
llm_gateway.Resource Information
Deployment Resources
Especifica a configuração de recursos para o
LLM Gateway. Para alta disponibilidade, o Number of Replicas é definido como 2 por padrão; recomendamos manter essa configuração. A configuração padrão é de 4 vCPUs e 8 GB de memória.Scheduling configuration
Especifica a configuração de recursos para o
LLM Scheduler. O padrão é 2 vCPUs e 4 GB de memória.Scheduling Policy
A política de balanceamento de carga para instâncias de inferência do backend. O padrão é Prefix cache. Para uma comparação detalhada que ajude na sua escolha, consulte Referência de políticas de agendamento.
Advanced Features
Redis config
Opcional. Persiste informações do usuário e estatísticas de uso. Se não for configurado, o service usa a memória local e os dados são perdidos quando o service é interrompido. Para obter detalhes, consulte Configurar armazenamento persistente do Redis.
-
Clique em Deploy. Quando o status do service mudar para Running, a implantação foi bem-sucedida.
Após a implantação, o sistema cria automaticamente um grupo de services chamado group_<nome do service de roteador inteligente de LLM>. Para visualize o grupo, acesse a página Elastic Algorithm Service (EAS) e clique na aba Group Service.

Etapa 2: Implantar um service de LLM
É necessário configure o recurso de roteador inteligente ao implantar um novo service de LLM. Não é possível adicionar esse recurso a um service existente usando a ação Atualize.
As etapas a seguir usam a implantação do Qwen3-8B como exemplo:
Clique em Deploy Service e, em seguida, selecione Scenario-based Model Deployment > LLM Deployment.
-
Configure os seguintes parâmetros principais:
Parâmetro
Valor
Basic Information
Model Settings
Selecione Public Model e, em seguida, pesquise e selecione Qwen3-8B.
Inference Engine
Selecione vLLM (recomendado; compatível com a API OpenAI).
NotaSe o service de roteador inteligente de LLM usar a Prefix cache como política de agendamento e você selecione vLLM como mecanismo de inferência, certifique-se de que o recurso de prefix caching esteja ativado para o mecanismo.
Deployment Template
Selecione Single node. O sistema preenche automaticamente as especificações de instância recomendadas, imagem e outros parâmetros do modelo.
Features
LLM Intelligent Router
Ative a opção e selecione o service de roteador inteligente de LLM implantado na Etapa 1 na lista suspensa.
Clique em Deploy. A implantação leva cerca de 5 minutos. Quando o status do service mudar para Running, a implantação foi bem-sucedida.
Etapa 3: Testar o service
Todas as requisições devem ser enviadas para o endpoint de acesso do service de roteador inteligente de LLM, e não para os services de inferência do backend.
Se qualquer service de inferência no grupo de services tiver a distribuição de tráfego ativada, as requisições enviadas pela entrada de tráfego agregado do grupo poderão ignorar o roteador inteligente, causando falhas de agendamento.
Certifique-se de que apenas o service de roteador inteligente tenha a distribuição de tráfego ativada no grupo de services. Envie requisições através da URL da entrada de tráfego dedicada do service de roteador inteligente.
-
Obtenha as credenciais de acesso.
Acesse a página Overview do service de roteador inteligente de LLM. Na seção Basic Information, clique em View Endpoint Information.
Na página Endpoint Information, em Service-specific Traffic Entry, copie o Internet Endpoint e o token.

ImportanteO token do service aqui é a chave de API do administrador. Se um administrador atribuiu a você uma chave de API separada através da bancada WebUI, use sua própria chave de API para substituir
<YOUR_TOKEN>no exemplo abaixo. -
Construa a URL da requisição e chame o service.
Formato da URL:
<endpoint de acesso do roteador inteligente de LLM>/<caminho da API do service de LLM>Exemplo:
http://********.pai-eas.aliyuncs.com/api/predict/group_llm_gateway.llm_gateway/v1/chat/completions
Exemplo de requisição:
# 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 }'Exemplo de resposta:
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]
Após implantar o service, você pode usar a bancada WebUI para tarefas como monitoramento ao vivo e gerenciamento de configurações. Para obter detalhes, consulte Usar a bancada do roteador inteligente de LLM.
Configure o Redis para armazenamento persistente
O roteador inteligente de LLM inclui um recurso integrado de gerenciamento de usuários que suporta gestão multiusuário, controle de acesso baseado em funções, logs de auditoria e visões gerais de dados. É possível usar uma instância externa do Redis para persistir informações do usuário e estatísticas de uso. Se o Redis não for configurado, o service usa a memória local e todos os dados são perdidos quando o service é interrompido. Para implantações em produção, configure o Redis para armazenamento persistente.
Etapa 1: Provisionar uma instância Tair (Redis)
-
Adquira uma instância na página de compra do Tair.
ImportanteAo crie a instância, selecione a mesma VPC e o mesmo vSwitch do seu service de roteador inteligente de LLM. Para outras opções, você pode começar com as especificações mínimas.
Adicione o bloco CIDR do vSwitch do service de roteador inteligente de LLM à lista de permissões da instância. Para obter mais informações, consulte Configurar uma lista de permissões.
-
Clique no ID da instância de destino para abrir a página de detalhes. Você precisará das informações de conexão ao implantar o service de roteador inteligente de LLM.
Endereço de conexão e porta: Na seção Instance information, encontre o endereço de conexão da VPC e o número da porta em Connection information.
Nome de usuário e senha: Na página Account management, localize a conta padrão. Se você não defina uma senha ao crie a instância, poderá defina ou redefini-la aqui. Também é possível crie uma nova conta em vez de usar a padrão.
Etapa 2: Configure o Redis
Além da configuração básica, é necessário configure a VPC e adicione os parâmetros de conexão do Redis para ative o armazenamento persistente.
Configure VPC: A VPC e o vSwitch devem ser os mesmos da instância Tair provisionada na Etapa 1. Isso garante que o service de roteador inteligente de LLM possa se conectar à instância Tair.
-
Configure Redis:
Console
Na seção Advanced Features, ative Redis config e insira os seguintes parâmetros:
Parâmetro
Descrição
Redis Address
O endereço de conexão da instância Tair, no formato
<endereço da VPC>:<porta>. Por exemplo,r-uxxx.redis.rds.aliyuncs.com:6379.Redis Username
O nome de usuário da instância Tair.
Redis Password
A senha da instância Tair.
JSON
No nó
llm_gatewaydo corpo JSON, adicione os seguintes parâmetros:Parâmetro
Descrição
enable_user_managementAtiva o gerenciamento de usuários. O padrão é
true.redis_addrsO endereço de conexão da instância Tair, no formato
<endereço da VPC>:<porta>. Por exemplo,r-uxxx.redis.rds.aliyuncs.com:6379.redis_usernameO nome de usuário da instância Tair.
redis_passwordA senha da instância Tair.
Exemplo de JSON:
{ "llm_gateway": { "enable_user_management": true, "redis_addrs": "r-uxxx.redis.rds.aliyuncs.com:6379", "redis_username": "xxx", "redis_password": "xxx" } }
Configuração avançada (JSON)
Use a Implantação JSON para configure especificações de recursos para o LLM Gateway e ajustar o tratamento de requisições.
Na página Inference Service, clique em Deploy Service. Na seção Custom Model Deployment, clique em JSON Deployment.
Exemplo de configuração
{
"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 |
Descrição |
|
|
metadata |
type |
Obrigatório. Deve ser definido como |
|
instance |
Obrigatório. O número de réplicas do |
|
|
cpu |
O número de vCPUs para cada réplica do |
|
|
memory |
A memória (em GB) para o |
|
|
group |
O grupo de services ao qual o service de roteador inteligente de LLM pertence. |
|
|
rpc.disable_auth |
Obrigatório. Deve ser definido como |
|
|
cloud.computing.instance_type |
Especifica o tipo de instância para o |
|
|
llm_gateway |
max_queue_size |
A profundidade máxima da fila para o Quando as requisições excedem a capacidade do framework de inferência do backend, as requisições excedentes são mantidas nesta fila para aguardar o agendamento. |
|
retry_count |
O número de tentativas. Padrão: 2. Se uma instância de inferência do backend falhar, o sistema tenta novamente a requisição e a encaminha para uma instância íntegra. |
|
|
wait_schedule_timeout |
Quando os mecanismos do backend estão com capacidade total, este parâmetro especifique o tempo limite total em milissegundos para agendar uma requisição. O padrão é 5000 (5 segundos). |
|
|
wait_schedule_try_period |
O intervalo, em milissegundos, entre as tentativas de agendamento. O padrão é 500 (0,5 segundos). |
|
|
llm_scheduler |
cpu |
O número de vCPUs para o |
|
memory |
A memória (em GB) para o |
|
|
policy |
A política de agendamento. Padrão: |
|
|
prefill_policy |
Quando policy está definido como pd-split, você deve especifique políticas de agendamento separadas para os estágios Prefill e Decode. Os valores válidos são: prefix-cache, llm-metric-based, least-request e least-token. |
|
|
decode_policy |
||
Apêndice
Usar Claude Code
-
Configure o Claude Code para usar a BASE URL e o TOKEN do service de roteador inteligente do 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> -
Execute o Claude Code.
claude "Write a Python Hello World program"
Políticas de agendamento
Esta tabela compara a lógica, casos de uso, vantagens e considerações para cada política de agendamento.
|
Política |
Valor JSON |
Descrição |
Casos de uso |
Vantagens |
Considerações |
|
Prefix cache |
prefix-cache |
(Recomendado) Uma política composta que prioriza o roteamento de requisições com o mesmo histórico de conversa (prompt) para uma instância com um cache KV correspondente. |
Chatbots de múltiplas voltas e sistemas RAG com um prompt de sistema fixo. |
Reduz significativamente o Tempo até o Primeiro Token (TTFT) e melhora o desempenho e o throughput para conversas de múltiplas voltas. |
Requer que o mecanismo de inferência tenha o prefix caching ativado. |
|
Minimum Requests |
least-request |
Roteia novas requisições para a instância que está processando o menor número de requisições no momento. |
Cargas de trabalho com complexidade de requisição relativamente uniforme (comprimentos de token e de geração semelhantes). |
Simples e eficiente. Equilibra rapidamente a contagem de requisições entre as instâncias. |
Não considera o custo computacional real das requisições. Instâncias que lidam com requisições curtas podem ficar ociosas enquanto aquelas que processam requisições longas ficam sobrecarregadas. |
|
Minimum tokens |
least-token |
Roteia novas requisições para a instância que está processando o menor número total de tokens (entrada + saída) no momento. |
Cargas de trabalho onde a contagem de tokens reflete de forma confiável o custo de processamento. |
Reflete a carga real da instância com mais precisão do que a política Least Request. |
Depende da estimativa de contagem de tokens, e nem todos os mecanismos de inferência relatam essa métrica. |
|
Static PD Disaggregation |
pd-split |
As instâncias são pré-particionadas em grupos Prefill e Decode, e uma política de agendamento separada é definida para cada grupo. |
Cargas de trabalho onde os estágios Prefill e Decode têm padrões de computação e acesso à memória significativamente diferentes, e onde a desagregação oferece vantagens distintas. |
Maximiza a utilização do hardware por meio de ajustes específicos para cada estágio. |
Complexo de configure. É necessário entender o modelo e a carga de trabalho, além de implantar services separados para Prefill e Decode. |
Benchmark de desempenho
Benchmarks nos modelos Distill-Qwen-7B, QwQ-32B e Qwen2.5-72B mostram que o roteador inteligente de LLM melhora significativamente a velocidade de inferência e o throughput.
Esses resultados servem apenas como referência. Execute seus próprios benchmarks para validar o desempenho da sua carga de trabalho.
Ambiente de teste
Política de agendamento: prefix-cache
Conjunto de dados de teste: ShareGPT_V3_unfiltered_cleaned_split.json (conjunto de dados de conversas de múltiplas voltas)
Mecanismo de inferência: vLLM (0.7.3)
Instâncias de backend: 5
Resultados do teste
|
Modelo de teste |
Distill-Qwen-7B |
QwQ-32B |
Qwen2.5-72b |
||||||
|
Tipo de instância |
ml.gu8tf.8.40xlarge |
ml.gu8tf.8.40xlarge |
ml.gu7xf.8xlarge-gu108 |
||||||
|
Concorrência |
500 |
100 |
100 |
||||||
|
Métrica |
Sem roteador inteligente |
Com roteador inteligente |
Melhoria |
Sem roteador inteligente |
Com roteador inteligente |
Melhoria |
Sem roteador inteligente |
Com roteador inteligente |
Melhoria |
|
Requisições bem-sucedidas |
3698 |
3612 |
- |
1194 |
1194 |
- |
1194 |
1194 |
- |
|
Duração do benchmark |
460,79 s |
435,70 s |
- |
1418,54 s |
1339,04 s |
- |
479,53 s |
456,69 s |
- |
|
Total de tokens de entrada |
6605953 |
6426637 |
- |
2646701 |
2645010 |
- |
1336301 |
1337015 |
- |
|
Total de tokens gerados |
4898730 |
4750113 |
- |
1908956 |
1902894 |
- |
924856 |
925208 |
- |
|
Throughput de requisições |
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 saída |
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 médio |
532,79 ms |
508,90 ms |
+4,5% |
1144,62 ms |
859,42 ms |
+25,0% |
508,55 ms |
389,66 ms |
+23,4% |
|
TTFT mediano |
274,23 ms |
246,30 ms |
- |
749,39 ms |
565,61 ms |
- |
325,33 ms |
190,04 ms |
- |
|
TTFT P99 |
3841,49 ms |
3526,62 ms |
- |
5339,61 ms |
5027,39 ms |
- |
2802,26 ms |
2678,70 ms |
- |
|
TPOT médio |
40,65 ms |
39,20 ms |
+3,5% |
68,78 ms |
65,73 ms |
+4,4% |
46,83 ms |
43,97 ms |
+6,1% |
|
TPOT mediano |
41,14 ms |
39,61 ms |
- |
69,19 ms |
66,33 ms |
- |
45,37 ms |
43,30 ms |
- |
|
TPOT P99 |
62,57 ms |
58,71 ms |
- |
100,35 ms |
95,55 ms |
- |
62,29 ms |
54,79 ms |
- |