Os sistemas de IA possuem características de performance fundamentalmente diferentes das aplicações tradicionais. Em uma aplicação web tradicional, a latência vem principalmente da transferência de rede e de consultas a bancos de dados, geralmente na faixa de 50 a 200 ms. Em um sistema de IA, o tempo de inferência do modelo domina, muitas vezes levando de 2 a 30 segundos, e muda dinamicamente conforme a complexidade da entrada e o tamanho da saída. As práticas clássicas de performance — como adicionar cache, ajustar SQL e fazer dimensionamento de instâncias — resolvem apenas parte do problema para aplicações de IA. Otimizar a performance de IA exige um entendimento profundo da mecânica de inferência do modelo, das características de recursos de GPU e da percepção do usuário, o que demanda uma nova metodologia.
Métricas de performance de IA
Uma otimização eficaz começa com as métricas corretas. Os sistemas de IA devem focar nos seguintes indicadores-chave de performance:
Time to first token (TTFT). O tempo desde o envio da requisição pelo usuário até o retorno do primeiro token gerado pelo sistema, tipicamente de 200 ms a 2 segundos. Esta métrica é crítica para interações em streaming porque determina a percepção de responsividade do usuário. Quando o TTFT ultrapassa 3 segundos, os usuários experimentam uma clara ansiedade de espera. As formas de otimizar o TTFT incluem reutilização de KV-Cache, aquecimento do modelo e agendamento de requisições baseado em prioridade.
Inter-token latency (ITL). O intervalo de tempo entre dois tokens adjacentes, com meta inferior a 50 ms. O ITL molda a experiência de leitura para saídas em streaming. Um ITL estável abaixo do limiar de leitura humana cria uma experiência de usuário "fluida". Quando o ITL flutua ou apresenta pausas longas ocasionais, a experiência é quebrada. O ITL depende principalmente da capacidade de computação da GPU e da concorrência.
Tempo total de geração. O tempo de ponta a ponta desde o envio da requisição até o último token. Para gerações longas, como escrita de relatórios ou geração de código, o tempo total de geração pode ultrapassar 30 segundos. O streaming reduz a espera percebida, mas um tempo total excessivamente longo ainda prejudica a eficiência do fluxo de trabalho, especialmente em cenários iterativos e de múltiplas interações.
Throughput. Mede a capacidade de processamento do sistema em três subdimensões: Tokens/s/GPU mede a eficiência de computação por GPU, a capacidade de concorrência mede quantas requisições o sistema pode atender simultaneamente, e a profundidade da fila reflete a pressão da carga. Existe um trade-off clássico entre throughput e latência por requisição. Um throughput maior frequentemente exige um batch size maior, o que, por sua vez, aumenta a latência de enfileiramento por requisição.
Métricas de qualidade de recuperação (cenários RAG). O Recall@K mede a proporção de consultas em que os K melhores resultados incluem documentos relevantes. A precisão mede a proporção de resultados recuperados que são relevantes. O Mean Reciprocal Rank (MRR) mede a posição no ranking do primeiro resultado relevante. Essas métricas afetam diretamente a qualidade final da geração, pois as informações perdidas durante a recuperação não podem ser recuperadas durante a geração.
Taxa de sucesso da tarefa de ponta a ponta. Mede se o sistema conclui a tarefa pretendida sob o ponto de vista do usuário. Uma interação bem-sucedida exige mais do que gerar texto; a saída deve ser correta, completa e utilizável. A taxa de sucesso da tarefa é a métrica de negócio final, e todas as métricas técnicas acima servem a esse objetivo.
Goodput. Este conceito do Google Cloud mede a saída efetiva por unidade de computação em três níveis. Nível de agendamento: As GPUs são usadas para trabalho em vez de ficarem ociosas? Nível de execução: O framework de inferência roda de forma eficiente sem overhead desnecessário? Nível de programa: O usuário realmente usa o conteúdo gerado ou ele é descartado devido a problemas de qualidade? O goodput destaca que nem toda computação cria valor. Se um usuário ignora uma resposta devido a uma alucinação, a computação consumida tem goodput zero.
Performance de inferência
BP-PERF-01 Selecione o hardware pela contagem de parâmetros do modelo
Justificativa
A contagem de parâmetros do modelo determina diretamente a capacidade de memória da GPU e o poder de computação necessários. Um hardware subdimensionado leva a trocas de memória frequentes — como erros de falta de memória ou offloading para a memória da CPU — e a uma queda acentuada de performance. Um hardware superdimensionado desperdiça recursos e aumenta o custo. A escolha correta do hardware é a base da otimização de performance.
Implementação
Estabeleça um mapeamento entre a contagem de parâmetros e o hardware. Um modelo de 7B parâmetros pode executar inferência em uma única GPU A10 (16 GB de memória), sendo adequado para aplicações leves e ambientes de desenvolvimento/teste. Um modelo de 14B parâmetros precisa de uma A30 (32 GB de memória) ou equivalente, sendo adequado para workloads de produção de complexidade média. Um modelo de 72B parâmetros precisa de pelo menos duas GPUs A100-80GB implantadas com paralelismo de tensores, sendo adequado para cenários de missão crítica que exigem a mais alta qualidade. A escolha do batch size envolve um trade-off: um batch size maior melhora a utilização da GPU (de 30% para mais de 80%), mas aumenta a latência de enfileiramento por requisição (de processamento quase imediato para centenas de milissegundos de espera). Recomendamos definir um limite superior de batch size com base no seu SLA. Para cenários de chat em tempo real, limite o batch size a no máximo 8–16. Para jobs em batch offline, você pode relaxar para 64–128.
Anti-pattern
Usar uma única configuração de hardware para todos os cenários, o que causa superprovisionamento e desperdício de dinheiro, ou subprovisionamento e prejuízo à performance. Ignorar o impacto do batch size ao buscar o throughput máximo em cenários de tempo real às custas da latência. Provisionar para a carga média ignorando o tráfego de pico.
Mapeamento de product da Alibaba Cloud
O PAI-EAS fornece uma variedade de especificações de instâncias de GPU e suporta Auto Scaling. O Lingjun Intelligent Computing Cluster fornece clusters de GPU em grande escala para suportar a implantação de modelos extragrandes e é equipado com redes RDMA de alta velocidade para garantir a eficiência do paralelismo de tensores.
BP-PERF-02 Stack de otimização de modelo
Justificativa
Os modelos base frequentemente armazenam e computam com precisão FP32 ou FP16, o que deixa uma margem significativa para otimização. Com técnicas de quantização, otimização de compilação e aceleração de inferência, você pode obter ganhos de performance múltiplos com perda de qualidade limitada, reduzindo significativamente o custo e a latência de inferência.
Implementação
Quantização: A quantização de FP16 para INT8 reduz o uso de memória da GPU pela metade e corta a latência em cerca de 40%, com uma perda de qualidade típica de 3–5% que se encaixa na maioria dos cenários de produção. A quantização INT4 reduz ainda mais a memória para um quarto e corta a latência em mais 30%, mas a perda de qualidade pode chegar a 8–12%. Use-a para workloads com requisitos de precisão mais baixos, como classificação de texto e extração de informações. Otimização de compilação: Use o TensorRT ou ONNX Runtime para otimizar o grafo de computação do modelo. A fusão de operadores reduz as cópias de memória, e a computação de precisão mista utiliza totalmente os Tensor Cores. Gerenciamento de KV-Cache: Use o PagedAttention para gerenciar a memória da GPU com paginação. Esta técnica evita a fragmentação e o desperdício do KV-Cache (a alocação contígua tradicional frequentemente desperdiça 30–50% da memória da GPU). A quantização do KV-Cache (FP16 para FP8) reduz ainda mais o espaço do cache e suporta janelas de contexto mais longas. Decodificação especulativa: Use um modelo de rascunho pequeno (como um modelo de 1B parâmetros) para gerar rapidamente sequências de tokens candidatas e, em seguida, faça o modelo alvo grande validá-las em paralelo. Se a validação passar, aceite os tokens. Caso contrário, regenere a partir do ponto de divergência. Esta técnica pode oferecer uma aceleração de 2x a 3x com qualidade de saída idêntica à do modelo original.
Anti-pattern
Aplicar o esquema de quantização mais agressivo sem avaliação, levando a uma degradação inaceitável da qualidade. Negligenciar o gerenciamento do KV-Cache, causando interrupções de service em cenários de diálogo longo devido à exaustão da memória da GPU. Não realizar testes de regressão após a otimização de compilação, levando a erros esporádicos devido a problemas de precisão numérica.
Mapeamento de product da Alibaba Cloud
O PAI-Blade fornece um recurso de aceleração de modelo com um clique que integra tecnologias de quantização, otimização de compilação e aceleração de inferência. O motor vLLM integrado ao PAI-EAS suporta PagedAttention e continuous batching. O service de inferência do DashScope vem pré-configurado com várias técnicas de otimização.
BP-PERF-03 Arquitetura de resposta em streaming
Justificativa
A "velocidade" percebida não é a mesma coisa que o tempo total de processamento. Estudos psicológicos mostram que, quando um sistema começa a responder em até 200 ms e continua a gerar saídas de forma constante, os usuários percebem a interação como "rápida e fluida", mesmo que a geração total leve 10 segundos. Uma resposta em streaming transforma uma longa espera em uma entrega progressiva de informações e muda fundamentalmente a forma como os usuários percebem a latência.
Implementação
Use o protocolo Server-Sent Events (SSE) para entregar tokens progressivamente. Um ponto técnico chave é manter o TTFT dentro de 200 ms, que é o limiar para a "resposta instantânea" percebida. Configure os gateways de API e os balanceadores de carga para suportar conexões de longa duração e transporte em streaming (desative o buffer de resposta). Implemente a renderização incremental no cliente adicionando e exibindo imediatamente cada token à medida que chega, e use um efeito de animação de máquina de escrever para reforçar a sensação de fluidez. Implemente uma estratégia de fallback para interrupções de stream, como reter o conteúdo recebido durante uma falha de rede, reconectar automaticamente e retomar a partir do ponto de interrupção. Para fluxos de trabalho de Agent de múltiplas etapas, forneça atualizações de progresso durante as fases de não geração (como esperas de chamadas de ferramentas) para que os usuários não fiquem olhando para uma tela em branco.
Anti-pattern
Retornar a resposta inteira de uma vez após a conclusão da geração, deixando os usuários olhando para uma tela em branco por segundos ou até dezenas de segundos. Usar transporte em streaming, mas falhar na implementação da renderização progressiva no cliente, fazendo com que o conteúdo ainda apareça todo de uma vez. Ignorar as configurações de buffer do gateway de API, o que faz com que as respostas em streaming sejam agregadas em transferências fragmentadas (chunked transfers).
Mapeamento de product da Alibaba Cloud
A API de streaming do DashScope suporta nativamente o push no nível de token por meio do protocolo SSE. Os endpoints de streaming do PAI-EAS suportam saída em streaming para modelos personalizados. O Application Load Balancer (ALB) suporta o encaminhamento de conexões de longa duração via WebSocket e SSE.
BP-PERF-04 Estratégia de batching de requisições
Justificativa
As características de computação da GPU tornam o batching uma alavanca fundamental para a eficiência. O tempo da GPU para processar uma requisição em comparação com oito requisições simultâneas pode diferir em apenas 30%, mas o throughput aumenta várias vezes. Com a estratégia de batching correta, você pode melhorar muito a capacidade geral do sistema e a utilização da GPU sem um grande aumento na latência por requisição.
Implementação
Batching dinâmico: Acumule as requisições recebidas em uma janela curta (5–20 ms) e, em seguida, envie-as para a GPU como um batch. O tamanho dessa janela exige um trade-off: se for muito curta, os batches serão muito pequenos para utilizar totalmente a GPU; se for muito longa, você adiciona uma latência de espera evitável. Batching contínuo: Uma inovação central do vLLM, quebra a restrição tradicional de esperar que todas as requisições em um batch terminem antes de liberar recursos. Quando uma requisição em um batch termina a geração, seus recursos são imediatamente liberados e uma nova requisição é admitida no batch. Isso pode elevar a utilização da GPU de 50–60% no batching clássico para mais de 85%. Batching por prioridade: Mantenha filas separadas para requisições com prioridades diferentes. Coloque usuários VIP e requisições interativas em tempo real em batches menores para baixa latência. Coloque requisições analíticas de background em batches maiores para um throughput alto e estável.
Anti-pattern
Usar um batch size fixo e ignorar as flutuações de carga, o que causa espera desnecessária sob carga baixa e picos de latência sob carga alta. Enfileirar todas as requisições juntas sem prioridades, de modo que o tráfego em tempo real seja bloqueado por inúmeros workloads offline. Usar frameworks de batching tradicionais onde requisições curtas são atrasadas por requisições de longa duração no mesmo batch ("head-of-line blocking").
Mapeamento de product da Alibaba Cloud
O PAI-EAS inclui recursos de batching dinâmico e suporta batching contínuo (baseado em vLLM). O PAI-EAS suporta configuração de múltiplas filas para agendamento por prioridade. O Lingjun Intelligent Computing Cluster fornece implantações de GPU de alta densidade para suportar concorrência em grande escala.
Performance de recuperação aumentada
BP-PERF-05 Otimize a performance do pipeline de embedding
Justificativa
A computação de embedding é uma etapa preliminar em um sistema RAG (Retrieval-Augmented Generation). Sua performance afeta diretamente a velocidade de construção da base de conhecimento e a latência de consultas em tempo real. Para uma base de conhecimento com milhões de documentos, um pipeline de embedding ineficiente pode fazer com que a construção inicial do índice leve vários dias. As atualizações incrementais podem não ser concluídas dentro de uma janela de tempo de negócio aceitável.
Implementação
Processamento em batch: Após fatiar os documentos, envie-os para o modelo de embedding em batches de 100 a 500. Isso utiliza totalmente o poder de computação paralela das GPUs. Em comparação com o processamento um a um, o processamento em batch pode aumentar o throughput de 5 a 10 vezes. Construção de índice acelerada por GPU: Use a aceleração de GPU para a construção inicial da base de conhecimento. Isso reduz o tempo de construção do índice HNSW para milhões de documentos de várias horas em uma CPU para dezenas de minutos em uma GPU. Estratégia de processamento incremental: Detecte alterações usando fingerprints de documentos (hashes de conteúdo). Faça o re-embedding e atualize o índice apenas para documentos novos e modificados para evitar o alto custo de uma reconstrução completa. Para cenários atualizados frequentemente, use uma estratégia de "buffer duplo assíncrono". Alterne atomicamente para o novo índice após sua construção em background. Isso evita que as atualizações afetem a performance das consultas online.
Anti-patterns
Processar documentos um a um, resultando em utilização da GPU abaixo de 10%. Acionar uma reconstrução completa para cada alteração de documento, o que desperdiça recursos computacionais significativos. Compartilhar recursos entre atualizações de índice e consultas online, causando uma queda significativa na performance das consultas durante as atualizações.
Mapeamento de product da Alibaba Cloud
O PAI-EAS fornece service de inferência de modelo de alta performance para embeddings e suporta requisições em batch. A API de embedding em batch do Model Studio suporta a vetorização eficiente de documentos em grande escala. O AnalyticDB for Vector fornece recursos de construção de índice acelerada por GPU.
BP-PERF-06 Ajuste os parâmetros de recuperação
Justificativa
A etapa de recuperação de um sistema RAG é como a primeira página de resultados de um mecanismo de busca tradicional. Se as informações relevantes não forem recuperadas nesta etapa, não importa o quão poderosa seja a etapa de geração subsequente, ela não poderá compensar. A configuração adequada dos parâmetros de recuperação determina diretamente se as informações corretas chegarão ao modelo.
Implementação
A estratégia de fatiamento de texto é fundamental para a qualidade da recuperação. Se os fatiamentos forem muito pequenos (como menos de 128 tokens), o contexto é perdido. Isso resulta em fragmentos recuperados que carecem de significado independente e são difíceis para o modelo entender. Se os fatiamentos forem muito grandes (como mais de 1024 tokens), a relevância é diluída. Isso mistura uma grande quantidade de conteúdo irrelevante com uma pequena quantidade de informações-chave, reduzindo a precisão da recuperação. A faixa ideal é tipicamente de 256 a 512 tokens, com uma sobreposição de 10% a 20% para garantir a integridade dos limites semânticos. Configure a quantidade de recuperação: Defina o top-K de recuperação inicial para 10 a 20 para uma recuperação ampla, garantindo que nenhuma informação seja perdida. Após o reranking com um Cross-Encoder, envie os 3 a 5 principais itens para o modelo. A etapa de reranking adiciona cerca de 80 a 120 ms de latência, mas pode aumentar a precisão em 20% a 35%, tornando-a altamente custo-efetiva. Use métodos de fatiamento diferentes para tipos de documentos diferentes: Fatie documentos estruturados, como FAQs, por entrada. Fatie documentos narrativos por parágrafo. Fatie documentos de código por função ou classe.
Anti-patterns
Usar um tamanho de fatiamento único e fixo para todos os tipos de documentos. Definir o top-K muito baixo, o que causa a perda de informações-chave, ou muito alto, o que faz com que conteúdo irrelevante interfira na geração. Pular a etapa de reranking para economizar latência, mas a perda de qualidade resultante supera em muito o tempo economizado.
Mapeamento de product da Alibaba Cloud
A base de conhecimento do Model Studio fornece estratégias de fatiamento e parâmetros de recuperação configuráveis. O AnalyticDB for Vector suporta o ajuste de parâmetros de índice personalizados e configurações de recuperação. O Model Studio possui um recurso integrado de reranking com Cross-Encoder.
BP-PERF-07 Use busca híbrida e fusão de pontuação
Justificativa
Um único método de recuperação possui pontos cegos inerentes. A recuperação por vetores densos se destaca na correspondência de similaridade semântica (entendendo que "carro" e "automóvel" são sinônimos), mas pode perder correspondências exatas de palavras-chave. Por exemplo, quando um usuário busca um modelo específico como "ModelY", a recuperação por vetores pode retornar modelos semanticamente similares, mas diferentes. Métodos de recuperação esparsa, como o BM25, se destacam na correspondência exata de palavras-chave, mas não conseguem lidar com reescritas sinônimas e inferência semântica. A busca híbrida combina as vantagens de ambos para melhorar significativamente as taxas de recuperação.
Implementação
Execute a recuperação por vetores densos e a recuperação esparsa BM25 simultaneamente. Mescle os resultados usando uma estratégia de fusão de pontuação. Métodos de fusão: A fusão de classificação recíproca (RRF) é a escolha mais robusta. Ela calcula uma soma ponderada com base no recíproco da classificação e não depende do valor absoluto das pontuações originais. Isso fornece um efeito de normalização natural para as diferentes distribuições de pontuação de vários métodos de recuperação. A Fusão de Pontuação Ponderada permite ajustar os pesos com base no cenário. Para cenários de consulta exata, como recuperar números de regulamentos, aumente o peso do BM25 para 0,6 a 0,7. Para cenários de consulta semântica, como "como reduzir custos", aumente o peso do vetor para 0,6 a 0,7. Dados medidos: Em comparação com a recuperação pura por vetores, a busca híbrida melhora o Recall@10 em 10% a 15%. Em comparação com o BM25 puro, melhora a recuperação semântica em 20% a 30%. A latência adicional é de apenas cerca de 15 a 25 ms porque os dois caminhos de recuperação são executados em paralelo e o overhead de computação de fusão é extremamente baixo.
Anti-patterns
Usar apenas um único método de recuperação, o que cria pontos cegos sistemáticos para determinados tipos de consulta. Usar pesos de fusão fixos que não são otimizados para a distribuição real de consultas. Executar os dois caminhos de recuperação em série em vez de em paralelo, o que aumenta desnecessariamente a latência.
Mapeamento de product da Alibaba Cloud
O AnalyticDB for Vector suporta nativamente a busca híbrida (vetor + texto completo) e possui estratégias integradas de RRF e fusão ponderada. O Elasticsearch, quando usado com um plug-in de vetor, pode implementar recursos de busca híbrida. A base de conhecimento do Model Studio suporta a configuração de um modo de busca híbrida.
Otimização de ponta a ponta
BP-PERF-08: Profiling de performance full-link
Justificativa
A latência de ponta a ponta de um sistema de IA consiste em múltiplas etapas seriais e paralelas. A otimização deve começar identificando os verdadeiros gargalos. Um erro comum é focar todos os esforços na otimização da inferência do modelo. No entanto, o gargalo real pode ser um índice não otimizado na recuperação por vetores, um número excessivo de tokens em um modelo de prompt ou saltos desnecessários na transmissão de rede. O profiling full-link é essencial para garantir que você otimize as áreas corretas.
Implementação
Incorpore timestamps em cada etapa crítica do processamento da requisição: início da requisição do cliente → recepção pelo AI Gateway → autenticação → reconhecimento de intenção → recuperação de conhecimento (incluindo cálculo de embedding, consulta de índice e reranking) → montagem do prompt → inferência do modelo (incluindo enfileiramento e computação) → pós-processamento (formatação e verificações de segurança) → retorno da resposta. Use dados amostrados para construir gráficos de distribuição de latência e identificar distribuições de gargalos nos percentis P50, P95 e P99. As descobertas comuns incluem: alta latência na primeira consulta devido a um índice de vetor frio (um problema de cold start); modelos de prompt inchados que causam inferência de contexto desnecessariamente longa; e chamadas de ferramentas seriais não paralelizadas que tornam a latência total a soma de todas as etapas. Estabeleça um mecanismo de orçamento de latência. Defina um orçamento de latência para cada etapa. Se o orçamento for excedido, acione automaticamente alertas e estratégias de degradação.
Anti-patterns
Monitorar apenas a latência total sem dividi-la por etapa. Decidir a direção da otimização com base na intuição em vez de dados. Otimizar uma etapa que representa apenas 5% da latência enquanto ignora o verdadeiro gargalo que representa 60%. Não ter um profiling contínuo e falhar no rastreamento da performance após uma otimização única.
Mapeamento de product da Alibaba Cloud
O distributed tracing do ARMS, compatível com OpenTelemetry, fornece visualização de rastreamento full-link. A visualização de pipeline do SLS mostra a distribuição de latência e tendências para cada etapa. O Performance Testing Service (PTS) suporta testes de carga e identificação de gargalos.
BP-PERF-09: Arquitetura de cache de múltiplas camadas
Justificativa
O alto custo computacional da inferência de IA torna o cache muito mais valioso do que em aplicações tradicionais. O custo de uma única inferência de modelo grande pode ser mais de 1.000 vezes o custo de uma única consulta Redis. Uma arquitetura de cache bem projetada pode reduzir o número de requisições de inferência reais em 30% a 60% sem afetar a experiência do usuário. Isso se traduz diretamente em economia de custos e redução de latência.
Implementação
Construa um sistema de cache de três camadas. Cada camada atende a um cenário de reutilização diferente.
Camada 1: Reutilização de Prompt Cache e KV-Cache. Quando múltiplas requisições compartilham o mesmo prefixo de prompt do sistema, o KV-Cache correspondente para esse prefixo pode ser reutilizado entre as requisições para evitar computação redundante. Na prática, para prompts de sistema longos (2.000 a 4.000 tokens), a reutilização do KV-Cache pode reduzir o Time to First Token (TTFT) em 40% a 60%. Pontos-chave de implementação: Garanta a consistência do prompt do sistema. Por exemplo, evite inserir dinamicamente conteúdos alteráveis, como timestamps, em cada requisição. Defina uma política de eviction de cache adequada.
Camada 2: Cache semântico. Combine consultas de usuários com base na similaridade semântica. Quando a similaridade semântica entre uma nova consulta e uma consulta histórica ultrapassa um limiar (tipicamente 0,92 a 0,95), retorne a resposta histórica diretamente. Isso elimina completamente o custo de inferência. Um cenário típico ocorre em sistemas de atendimento ao cliente, onde muitos usuários fazem a mesma pergunta usando redações diferentes. A taxa de acerto do cache semântico geralmente fica entre 15% e 35%. Cada acerto economiza de 2 a 10 segundos de tempo de inferência. Atenção aos requisitos de invalidação de cache: quando a base de conhecimento é atualizada, as entradas relevantes do cache semântico devem ser limpas de forma síncrona.
Camada 3: Cache de resposta. Para consultas idênticas (correspondência no nível de caractere), retorne o resultado em cache diretamente. Isso reduz o tempo de resposta de segundos para milissegundos. É adequado para chamadas de API repetidas em cenários de integração de sistemas.
Cada camada de cache usa uma estratégia de invalidação diferente. O KV-Cache usa uma política de Least Recently Used (LRU) e é limitado pela capacidade de memória de vídeo. O cache semântico é invalidado com base na versão da base de conhecimento e em janelas de tempo. O cache de resposta é invalidado com base no Time to Live (TTL) e na atualização ativa.
Anti-patterns
Fazer cache de todas as respostas indiscriminadamente, o que faz com que os usuários recebam informações desatualizadas. Não ter uma estratégia de invalidação de cache, resultando no retorno de respostas antigas após a atualização da base de conhecimento. Definir o limiar de similaridade semântica muito baixo, o que leva a correspondências incorretas para consultas não relacionadas.
Mapeamento de product da Alibaba Cloud
O Tair, um Redis pronto para empresas, fornece cache semântico e de resposta de alta performance e suporta busca por similaridade de vetores. O PAI-EAS possui otimização de KV-Cache e recursos de Prefix Cache integrados. O Content Delivery Network (CDN) acelera o cache de borda para recursos estáticos.
BP-PERF-10: Load shedding e filas de prioridade
Justificativa
Os recursos de inferência de IA, como as GPUs, escalam muito mais lentamente do que os recursos de computação tradicionais. Uma nova instância de GPU pode levar vários minutos para ficar pronta a partir de um cold start, incluindo o tempo de carregamento do modelo. No entanto, picos de tráfego podem ocorrer em segundos. Se um sistema ficar sobrecarregado sem um gerenciamento seletivo de carga, todas as requisições darão timeout devido a filas longas. Isso leva a um cenário catastrófico de "falha total". Filas de prioridade e load shedding são mecanismos centrais para "salvar o importante e descartar o menos importante" durante a sobrecarga.
Implementação
Defina prioridades de requisição claras. P0 é para conversas de usuários em tempo real, que impactam diretamente a experiência do usuário e exigem um Service Level Agreement (SLA) com tempo de resposta em segundos. P1 é para análise de background em tempo real, como recomendações em tempo real ou resumo de streams, que podem tolerar um atraso de vários segundos. P2 é para processamento em batch offline, como avaliações completas ou backfills de dados, que podem tolerar um atraso de minutos. Mantenha filas de processamento separadas para cada prioridade e configure diferentes Service Level Objectives (SLOs). Por exemplo, defina o limite de profundidade da fila P0 para 20 com um timeout de 30 segundos. Defina o limite de profundidade da fila P1 para 100 com um timeout de 60 segundos. Defina o limite de profundidade da fila P2 como ilimitado, sem timeout rígido. Implemente uma estratégia de load shedding para cenários de carga extrema. Quando a utilização da GPU exceder consistentemente 90% e a profundidade da fila P0 estiver crescendo, primeiro pare de aceitar novas requisições P2 e retorne um status 429 Retry-After. Se isso não for suficiente, pause as requisições P1 para garantir que o SLA P0 não seja violado. Implemente o agendamento baseado em SLO. Quando os recursos forem abundantes, agende as filas de forma justa. Quando os recursos forem escassos, use preempção estrita com base na prioridade. Como mecanismo de suporte, as requisições P2 que sofrem load shedding devem entrar automaticamente em uma fila de retentativa atrasada. Essas requisições são processadas automaticamente após a carga voltar ao normal para garantir a conclusão eventual.
Anti-patterns
Colocar todas as requisições em uma única fila sem priorização, forçando usuários VIP e tarefas de background a competir pelos mesmos recursos. Simplesmente descartar requisições que deram timeout sem um mecanismo de retentativa, o que causa a falha permanente das tarefas de processamento em batch. Não ter sistemas de pré-alerta de carga, de modo que a sobrecarga só é descoberta quando o sistema trava.
Mapeamento de product da Alibaba Cloud
O AI Gateway e o Application Load Balancer (ALB) suportam roteamento baseado em prioridade e limitação de taxa com base nos headers da requisição. O RocketMQ fornece filas de mensagens prioritárias e recursos de entrega atrasada. O PAI-EAS suporta configuração de múltiplas filas e agendamento de prioridade de requisições. O Cloud Monitor fornece alertas de utilização de GPU e gatilhos para Auto Scaling.
Arquitetura de implementação para o pilar de performance da Alibaba Cloud
As camadas a seguir formam uma arquitetura completa de otimização de performance para sistemas de IA:
Camada de aceleração de inferência. O PAI-EAS atua como a plataforma central de inference service. Seu motor vLLM integrado suporta continuous batching e PagedAttention. O PAI-EAS trabalha com o PAI-Blade para fornecer quantização de modelo e otimização de compilação. O Lingjun Intelligent Computing Cluster fornece poder de computação de GPU em grande escala com A100/H100. Sua interconexão RDMA de alta velocidade garante comunicação eficiente para paralelismo de tensores e paralelismo de pipeline. O DashScope fornece um inference service gerenciado com uma API de alta performance pronta para uso, para cenários que não exigem inferência autoconstruída.
Camada de aceleração de recuperação. O AnalyticDB for Vector fornece recuperação de vetores de alta performance e busca híbrida. Suporta múltiplos tipos de índice, como HNSW e IVF, e possui fusão de classificação recíproca (RRF) e reranking com Cross-Encoder integrados. O Elasticsearch, combinado com plug-ins de vetor, suporta cenários de busca de texto completo. A base de conhecimento do Model Studio fornece otimização de busca RAG (Retrieval-Augmented Generation) de ponta a ponta. Isso inclui configurar estratégias de fatiamento, ajustar parâmetros de recuperação e avaliar a performance.
Camada de aceleração de cache. O Tair (Enterprise Edition for Redis) fornece cache semântico e cache de resposta com latência no nível de milissegundos. Suporta cálculo de similaridade de vetores para atender aos requisitos de baixa latência de cenários de alta concorrência. Os recursos integrados de otimização de KV-Cache e Prefix Cache no PAI-EAS permitem a reutilização de computação no nível do motor de inferência.
Camada de garantia de ponta a ponta. O distributed tracing do Application Real-Time Monitoring Service (ARMS) fornece visualização completa de rastreamento do cliente ao motor de inferência. Isso ajuda a localizar com precisão os gargalos de latência. O Application Load Balancer (ALB) fornece roteamento inteligente, agendamento de prioridade e recursos para limitação de tráfego e circuit breaking. O Cloud Monitor e o Log Service (SLS) trabalham juntos para fornecer alertas em tempo real, acionamento automático de Auto Scaling e análise de tendências históricas.
Recomendações de implementação: A otimização de performance deve ser orientada por medições e focada em gargalos. Primeiro, estabeleça uma linha de base de performance fazendo o profiling de todo o link para identificar as etapas com maior latência. Em seguida, aplique métodos de otimização direcionados. Para gargalos de inferência, use aceleração por quantização e otimização de processamento em batch. Para gargalos de recuperação, use ajuste de índice e busca híbrida. Para gargalos de computação repetida, use cache de múltiplas camadas. Por fim, monitore e verifique continuamente os resultados da otimização para criar um ciclo de feedback positivo para a melhoria da performance. Evite espalhar seus esforços uniformemente. Uma estratégia eficiente de otimização de performance é focar 80% do seu esforço nos 20% das etapas que causam mais latência.