Engenharia de desempenho de IA: uma escada de evidências de desempenho da GPU à produção para gargalos de inferência

Por que a utilização da GPU não é um diagnóstico de desempenho

Um serviço de inferência em GPU pode parecer saudável em um painel e ainda assim parecer lento para os usuários. O dispositivo está ocupado. As solicitações estão esperando. A latência de cauda está se deslocando. As novas tentativas estão consumindo capacidade. Algumas saídas nunca passam pela aceitação do produto. Todos esses fatos podem ser verdadeiros ao mesmo tempo.

A utilização da GPU costuma ser a métrica principal menos útil em um incidente de inferência. Ela indica que o hardware executou trabalho. Ela não indica se o trabalho certo foi concluído dentro das regras de carga de trabalho e qualidade de que o produto precisa.

O mapa de recursos Wafer AI Performance Engineering V2 ajuda porque reúne as camadas pelas quais as equipes normalmente precisam raciocinar, desde execução e profiling CUDA até kernels, sistemas de serviço e comunicação distribuída. Um mapa de recursos ainda não é um método de aceitação. As equipes precisam de um caminho do sintoma à evidência e depois da evidência a uma mudança de produção com um plano de reversão.

Para inferência em produção, a unidade prática são tarefas aceitas sob um contrato de carga de trabalho definido. Isso significa que p50, p95, p99, tempo até o primeiro token, latência entre tokens, tempo de fila, comprimento do prompt, comprimento da saída, concorrência, batching, taxa de erro, taxa de novas tentativas, taxa de aceitação e custo por tarefa aceita devem avançar juntos na análise. Tokens brutos por segundo têm seu lugar em uma execução de laboratório. Em produção, uma rota mais rápida que causa mais novas tentativas ou falha em verificações de aceitação é pior, não melhor. Uma latência média menor também pode ocultar uma cauda quebrada.

Essa mesma postura orientada por evidências aparece em guias de infraestrutura relacionados da Optijara, incluindo o teste de aceitação de rota AI-in-RAN, o teste de aceitação checkpoint-to-bundle do TensorRT Model Connect e o guia QRAT do Qwen3.8-27B. O princípio é o mesmo aqui. Defina o pacote de evidências antes de alterar o sistema. Para produtos de IA voltados para busca, a disciplina também combina com a atualização de spam de agosto do Google e checklist de GEO da Optijara, em que alegações apoiadas por fontes importam mais do que uma pontuação única organizada.

A Performance Evidence Ladder (PEL) da Optijara

A Performance Evidence Ladder da Optijara, ou PEL, é um método de diagnóstico em cinco estágios para trabalho de inferência da GPU à produção. Ela existe para interromper um padrão comum de falha: alguém vê um sintoma, escolhe uma correção preferida e depois procura métricas que façam a correção parecer razoável. A PEL desacelera esse processo apenas o suficiente para colocar as evidências na ordem certa.

Estágio 1: rastreamento de solicitações e carga de trabalho

Comece onde o usuário sente o sistema. Capture taxa de chegada de solicitações, faixas de concorrência, distribuição de comprimento de prompt, distribuição de comprimento de saída, comportamento de batching, tempo de fila, tempo até o primeiro token, latência entre tokens, p50, p95, p99, falhas, novas tentativas e status de aceitação. Se o serviço lida com tipos de tarefa diferentes, separe-os. Chamadas de retrieval, fluxos de trabalho que usam ferramentas, chat em streaming e solicitações de contexto longo podem atingir limites diferentes.

A saída é um contrato de carga de trabalho. Ele declara o que está sendo servido, sob quais restrições e o que conta como aceito. Sem isso, evidências posteriores da GPU podem tornar a rota errada mais rápida.

Estágio 2: evidências de execução e memória da GPU

O Estágio 2 pergunta o que o dispositivo e o host estão realmente fazendo. A documentação CUDA fornece o modelo mental para execução, hierarquia de threads, hierarquia de memória e sincronização. O Nsight Systems ajuda as equipes a inspecionar atividade de CPU, chamadas de API CUDA, kernels de GPU, operações de memória e lacunas entre eles em uma linha do tempo.

Não persiga uma barra de atividade mais ocupada. Procure causas. Uma lacuna entre kernels não é o mesmo que pressão de largura de banda de memória. Atraso de sincronização não é o mesmo que um kernel lento. Admissão de solicitações no lado do host não é execução no lado do dispositivo. O Estágio 2 deve nomear a classe de evidência antes que alguém reescreva kernels ou altere ajustes de serviço.

Estágio 3: evidências de kernel e operador

O Estágio 3 avança de linhas do tempo para operadores e kernels. O PyTorch profiler pode mostrar caminhos de operadores, tempo de CPU e CUDA, comportamento de memória e rastreamentos que revelam quais operações do modelo dominam uma execução. Diagnósticos do PyTorch compile importam quando captura de grafo, fusão ou comportamento de fallback mudam o caminho de execução. O Triton entra em cena quando uma equipe precisa inspecionar kernels personalizados, formatos de tiles, movimentação de memória e a fronteira entre lógica no nível de Python e trabalho no nível do dispositivo.

É aqui que pertencem intensidade aritmética, pressão de largura de banda de memória, fusão de operadores, caminhos de quantização e padrões de lançamento de kernels. Também é aqui que erros caros acontecem. Quantização, compilação e kernels personalizados podem alterar comportamento de saída, observabilidade, propriedades numéricas e custo de reversão. Teste o candidato contra a aceitação da tarefa, não apenas contra um rastreamento de latência.

Estágio 4: evidências de escalonamento e cache do mecanismo de inferência

O Estágio 4 examina o mecanismo de serviço. Sistemas como vLLM expõem métricas sobre solicitações, tokens, comportamento do escalonador, estado de cache e filas. Essa camada importa porque servir LLMs não é apenas execução de modelo. Inclui prefill, decode, batching contínuo, admissão de solicitações, pressão sobre cache KV, mistura de comprimentos de prompt e saída, comportamento frio, comportamento aquecido e decisões do escalonador.

Tempo alto até o primeiro token pode vir de filas, custo de prefill, partidas frias, controle de admissão ou estado de cache. Latência alta entre tokens pode vir de comportamento de decode, pressão de memória, eficiência de kernel, escalonamento ou comunicação. A PEL mantém essas hipóteses separadas até que a evidência aponte para uma delas.

Estágio 5: evidências de serviço distribuído e capacidade

O Estágio 5 se aplica quando uma GPU não é o sistema inteiro. Inferência distribuída pode envolver paralelismo de tensor, paralelismo de pipeline, coletivas, movimentação de rede, capacidade no nível do nó, posicionamento, transferência de dados e domínios de falha. A documentação NCCL importa aqui porque coletivas e comportamento de comunicação podem se tornar parte do caminho de serviço.

Neste ponto, o pacote de aceitação deve incluir escopo de canary, gatilho de reversão, condições de parada e evidências de capacidade. Uma mudança de topologia não é aceita porque um benchmark melhora. Ela é aceita quando o contrato de carga de trabalho, a latência de cauda, erros, novas tentativas, critérios de aceitação e risco operacional permanecem dentro dos limites acordados.

Uma matriz de decisão de gargalos para inferência em produção

Pare o profiling quando quatro coisas forem verdadeiras: o gargalo foi reproduzido, a camada responsável foi identificada, o impacto na aceitação está visível e o limite de reversão está definido. O profiling pode mudar o comportamento da carga de trabalho, então mais rastreamento não é automaticamente melhor. O ponto certo de parada é evidência suficiente para tomar uma decisão sem fingir que o rastreamento é o produto.

Checklist de implementação: de execução de benchmark a mudança de produção aceita

Mantenha comparações frias, aquecidas e de canary separadas. Execuções frias expõem efeitos de inicialização, compilação, preenchimento de cache ou carregamento de modelo. Execuções aquecidas mostram comportamento em estado estável sob o contrato de carga de trabalho. Execuções de canary respondem à pergunta de produção: este candidato se comporta bem o suficiente no tráfego real sem expor toda a carga de trabalho a risco evitável?

Evidências específicas por ferramenta: onde cada fonte se encaixa na PEL

A documentação CUDA apoia o Estágio 2 porque fornece o modelo para threads, blocos, hierarquia de memória, sincronização e comportamento de execução. O Nsight Systems apoia o mesmo estágio por um ângulo de linha do tempo, especialmente quando as equipes precisam ver trabalho de CPU, kernels de GPU, APIs CUDA, operações de memória e lacunas em conjunto.

O PyTorch profiler apoia o Estágio 3 ao tornar visível o comportamento no nível de operadores. Diagnósticos do PyTorch compile podem importar quando uma rota compilada muda comportamento de grafo, fusão ou caminhos de fallback. O Triton se encaixa no Estágio 3 quando operadores padrão não bastam ou quando um caminho de kernel personalizado precisa de inspeção. Isso não significa que todo gargalo mereça um kernel personalizado. A PEL pede que as equipes provem primeiro que o gargalo vive nessa camada.

Métricas vLLM se encaixam no Estágio 4 porque o comportamento de serviço muitas vezes explica sintomas que métricas no nível da GPU não conseguem explicar. Estado do escalonador, comportamento de cache, métricas de solicitações, métricas de tokens e filas podem mostrar se o problema é admissão, batching, prefill, decode ou pressão de cache. O NCCL se encaixa no Estágio 5 quando a comunicação distribuída faz parte do caminho de serviço.

O que as equipes erram ao otimizar inferência em GPU

Tratar utilização como a resposta

A utilização é fácil de observar e fácil de superinterpretar. Ela não diz a uma equipe se os usuários estão em fila, se a latência p99 é aceitável, se as novas tentativas estão aumentando ou se a tarefa foi aceita. Use-a como um sinal no Estágio 2, não como a métrica principal.

Otimizar tokens de benchmark em vez de tarefas aceitas

Tokens por segundo podem ajudar dentro de um experimento controlado, mas sistemas de produção concluem tarefas. Uma rota que emite tokens rapidamente enquanto falha em verificações de aceitação, aumenta erros ou exige mais novas tentativas não é melhor. A vazão de tarefas aceitas é a unidade mais segura voltada para o negócio.

Alterar batching sem proteger a latência de cauda

Batching e batching contínuo podem melhorar o uso do hardware em algumas cargas de trabalho. Eles também interagem com tempo de fila, TTFT, comprimento de saída e p99. Avalie uma mudança de batching por tipo de tarefa e faixa de concorrência, não apenas pela vazão agregada.

Ignorar obsolescência de cache e drift de carga de trabalho

Comportamento do cache KV, distribuições de prompts, comprimentos de saída e padrões de retrieval podem sofrer drift. Uma execução que parece boa em uma carga de trabalho antiga pode falhar quando a mistura de solicitações muda. Mantenha contratos de carga de trabalho versionados e repetíveis.

Fazer profiling de formas que mudam a carga de trabalho

Profiling adiciona overhead e pode alterar temporização. Isso não torna o profiling inutilizável. Significa que o overhead precisa ser rotulado, execuções com e sem profiling devem ser comparadas com cuidado, e o comportamento do rastreamento não deve ser tratado como o estado natural do sistema.

Ressalvas e trade-offs: trabalho de desempenho é um sistema de engenharia

Evidências de desempenho reduzem suposições, mas não removem custo de implementação. Instrumentação leva tempo. Coleta de rastreamentos pode criar questões de privacidade e segurança porque prompts, saídas, identificadores e metadados operacionais podem ser sensíveis. Logs devem ser minimizados, controlados por acesso e retidos apenas pelo tempo necessário.

A otimização também pode afetar a qualidade. Quantização pode alterar o comportamento de saída. Compilação pode alterar caminhos de execução. Mudanças de kernel podem criar problemas de correção ou portabilidade. Mudanças de escalonador e cache podem deslocar latência entre tipos de solicitação. Mudanças de topologia distribuída podem melhorar um caminho enquanto adicionam custo de comunicação ou complexidade operacional em outro lugar.

Variação de provedor, hardware, driver, framework e modelo importa. Evidências de um ambiente não devem ser copiadas para outro como resultado garantido. A PEL torna essas suposições explícitas em vez de ocultá-las atrás de uma média confiante. Custo por tarefa aceita pode ser útil, mas apenas quando a atribuição de custo está definida.

PEL na prática: um fluxo compacto de evidências e resumo legível por máquina

{
  "framework": "Optijara Performance Evidence Ladder",
  "stages": [
    {"stage": 1, "name": "request_trace", "signals": ["p50", "p95", "p99", "TTFT", "queue_time", "acceptance_rate"]},
    {"stage": 2, "name": "gpu_execution_memory", "signals": ["kernel_gaps", "memory_movement", "occupancy", "synchronization"]},
    {"stage": 3, "name": "kernel_operator", "signals": ["operator_time", "arithmetic_intensity", "bandwidth_pressure", "compile_path"]},
    {"stage": 4, "name": "serving_scheduler_cache", "signals": ["prefill", "decode", "KV_cache", "batching", "admission"]},
    {"stage": 5, "name": "distributed_capacity", "signals": ["collectives", "network_movement", "placement", "canary", "rollback"]}
  ],
  "acceptance_unit": "cost_per_accepted_task_under_workload_contract",
  "stop_conditions": ["reproduced_bottleneck", "owner_layer_identified", "acceptance_impact_visible", "rollback_threshold_defined"]
}

A pergunta de trabalho para a PEL é direta: qual camada limita as tarefas aceitas, que evidência prova isso e que mudança de produção pode ser enviada com um plano claro de reversão? Se a resposta ainda for "a GPU está ocupada", o diagnóstico não terminou.