Quantos Usuários Seu Servidor LLM Consegue Realmente Suportar?

A implantação de Large Language Models (LLMs) em um ambiente corporativo deixou de ser um exercício de prova de conceito para se tornar uma disciplina de engenharia rigorosa. No entanto, prever com precisão a capacidade de um servidor de inferência sob carga concorrente e real continua sendo um desafio formidável. Engenheiros de infraestrutura frequentemente se deparam com espaços de configuração complexos, questionando se o ajuste de parâmetros como --max-num-batched-tokens ou --gpu-memory-utilization no vLLM otimizará o throughput ou degradará inadvertidamente a latência de cauda. A documentação oficial fornece os mecanismos para ajuste, mas raramente oferece um método sistemático para descobrir a configuração ideal para uma carga de trabalho específica, arquitetura de hardware e um Acordo de Nível de Serviço (SLA) rigoroso.

Para abordar isso, empreendemos uma iniciativa abrangente de planejamento de capacidade para um modelo Mixture-of-Experts (MoE) de 120 bilhões de parâmetros (gpt-oss-120b), implantado em múltiplos clusters NVIDIA H100 e H200 para alimentar um assistente interno de codificação de IA. Em vez de apenas publicar nossas métricas finais de capacidade, documentamos a metodologia rigorosa e completa que desenvolvemos para alcançá-las. Compilamos nossas descobertas em um white paper técnico detalhado: SPOC: a Stateful, Profile-based Optimization for LLM Capacity Planning Methodology. Este white paper serve como um guia abrangente para a engenharia de desempenho de LLM. Ele foi projetado para equipar as equipes de infraestrutura com as ferramentas analíticas e técnicas empíricas necessárias para:

• Construir conjuntos de dados com estado (stateful) e multi-turn que simulam com precisão o complexo acúmulo de contexto de desenvolvedores consultando monorepos corporativos compartilhados.
• Aplicar algoritmos evolucionários multi-objetivo (Optuna NSGA-II) para navegar matematicamente pelo espaço de parâmetros do motor de inferência, substituindo suposições heurísticas por otimização rigorosa.
• Implantar uma pilha avançada de telemetria (Prometheus e DCGM Exporter) para correlacionar métricas internas do motor de inferência com o estado físico do hardware.
• Capturar e interpretar traces de nível de kernel do NVIDIA Nsight Systems para identificar os verdadeiros gargalos arquitetônicos, que frequentemente desafiam as previsões de um modelo teórico simples de roofline.

Se você é responsável por escalar a infraestrutura de LLM, este artigo fornece o projeto empírico necessário para fazer a transição da estimativa de capacidade para sua medição e otimização sistemática.

O Problema com o Conceito de "Apenas Rodar um Benchmark"

Benchmarks padrão de LLM enviam um prompt fixo com uma concorrência fixa e relatam a latência média, ou benchmarks de única rodada (MLPerf, GenAI Perf, InferenceMax). Isso é bom para comparar modelos em um leaderboard. Não é bom para o planejamento de capacidade para casos de uso do mundo real, como fazer muitas perguntas de acompanhamento para tarefas de codificação, ou para análise de logs; nessas situações, a simulação de tráfego multi-turn é essencial.

O tráfego real é complicado. Em nosso caso, 70% dos usuários enviam requisições curtas (começando em cerca de 5.000 tokens e crescendo até 50.000 tokens), 20% enviam requisições de tamanho médio (começando em 15.000 e crescendo até 120.000 tokens), e 10% submetem bases de código inteiras para análise profunda (começando em cerca de 75.000 tokens e atingindo o limite de contexto de 128.000 tokens). Esses três segmentos sobrecarregam o motor de inferência de maneiras fundamentalmente diferentes. As requisições curtas dominam a taxa de requisições e definem o limite inferior para o time-to-first-token (TTFT). As requisições grandes dominam a largura de banda da memória da GPU e o cálculo de prefill. Um benchmark que as trata todas como requisições de tamanho médio fornecerá um número que não prevê onde o sistema realmente falhará. Precisávamos de algo melhor.

O Que Construímos

O white paper descreve uma estrutura com três estágios principais:

• Modelagem da carga de trabalho – Definimos três perfis de usuário (P0, P1, P2) calibrados a partir de padrões de uso observados, cada um com sua própria distribuição de tamanho de prompt, orçamento de saída e tempo de pensamento. Construímos um corpus com estado a partir de trajetórias de código aberto (togethercomputer/CoderForge-Preview e nebius/SWE-rebench-openhands-trajectories) e usamos Locust para simular conversas de streaming multi-turn que se comportam como desenvolvedores reais interagindo com um assistente de codificação, incluindo uma geometria de "Common Ground Parcial" para simular monorepos corporativos compartilhados.
• Busca de parâmetros evolucionária – Em vez de tentar manualmente combinações de parâmetros ou executar uma busca exaustiva em grade, usamos o sampler NSGA-II do Optuna para pesquisar o espaço de parâmetros do vLLM em nossa concorrência alvo. NSGA-II é um algoritmo evolucionário multi-objetivo que otimiza simultaneamente o throughput, o time-to-first-token e a latência inter-token. Ele encontra a fronteira de Pareto: o conjunto de configurações onde você não pode melhorar uma métrica sem sacrificar outra.
• Profiling em nível de kernel – Aqui as coisas ficaram interessantes. Capturamos traces do NVIDIA Nsight Systems durante a carga em estado estacionário nos nossos limites de capacidade (300 usuários concorrentes em 4x H100 e 85 usuários em 2x H200). Decompomos o tempo ativo da GPU em categorias funcionais: Flash Attention, MoE Expert GEMMs e coletivos NCCL. Os traces revelaram que, para esta arquitetura MoE esparsa com grandes tamanhos de batch, o sistema se torna fortemente limitado pelo cálculo de Attention e pela largura de banda da memória, desafiando as previsões simples de roofline. A partir daí, varremos a melhor configuração em todos os níveis de concorrência, coletando contadores de hardware do Prometheus e DCGM Exporter.

O Que Você Aprenderá com o Artigo

O artigo pretende ser tanto uma referência quanto um guia prático, e aborda os seguintes tópicos:

• Como projetar uma simulação de carga de trabalho que reflita o comportamento real do usuário e o acúmulo de contexto com estado, e não médias sintéticas sem estado.
• Como usar a otimização multi-objetivo para pesquisar o espaço de parâmetros do vLLM de forma eficiente e ver em primeira mão a diferença dramática que o investimento de ciclos de otimização nesses parâmetros faz para extrair o máximo desempenho de suas GPUs disponíveis.
• Como configurar o Prometheus e o DCGM Exporter para obter visibilidade simultânea dos componentes internos do motor de inferência e do estado do hardware da GPU.
• Como capturar e interpretar traces de kernel do NVIDIA Nsight Systems de uma implantação vLLM conteinerizada sob carga.

Além da metodologia, aqui estão algumas das descobertas que merecem atenção especial:

• Chunked Prefill é um trade-off vital. Para proteger a latência inter-token (ITL) das gerações em andamento de picos massivos de prefill causados por nossos usuários de 128k tokens, --max-num-batched-tokens deve ser cuidadosamente ajustado. Descobrimos que configurá-lo para 2048 (em 4x H100) ou 1024 (em 2x H200) sacrifica um pouco da velocidade do TTFT, mas mantém uma experiência de streaming suave e evita timeouts catastróficos de compilação de grafo CUDA.
• A utilização da GPU não é uma métrica de SLA. Medimos aproximadamente 37% de SM Active no limite de capacidade. Você pode pensar que 60% da capacidade de computação da GPU está sendo desperdiçada. No entanto, forçar uma utilização maior preenchendo lacunas de agendamento degrada a latência de decodificação por etapa (ITL) e faz com que o sistema não cumpra o SLA. O artigo explica por que buscar uma utilização maior da GPU pode degradar ativamente a experiência do usuário.
• VRAM nem sempre é o gargalo. Mesmo com 10% dos usuários submetendo contextos massivos de 80k-128k tokens, o uso ativo do cache KV permaneceu notavelmente baixo (~10,5% em 4x H100). Como nosso conjunto de dados simula um monorepo corporativo compartilhado, o cache de prefixos do vLLM deduplica as raízes compartilhadas de forma eficiente. O sistema estava fundamentalmente limitado por kernels de Attention e largura de banda da memória, não pela capacidade da VRAM.
• A escalabilidade do hardware não é linear sob restrições de latência de cauda. O sistema 4x H100 atingiu aproximadamente 3,5x a capacidade do sistema 2x H200 (300 vs 85 usuários), em vez do esperado 2x. Isso se deve aos efeitos combinados da largura de banda de memória agregada, da divisão matemática do Tensor Parallelism e da penalidade de chunked prefill em clusters de GPU menores.
• Vulnerabilidades térmicas no Tensor Parallelism. Sob TP > 1, toda a etapa de inferência prossegue apenas tão rápido quanto a GPU mais lenta. Uma única GPU que experimenta throttling térmico forçará todas as GPUs saudáveis a esperar nas barreiras de sincronização NVLink, causando picos de latência graves e em todo o sistema.
• Realidades de Profiling de Hardware vs. Modelos Teóricos. O artigo demonstra como suposições sobre quantização podem enganar o planejamento de capacidade. Por exemplo, enquanto o gpt-oss-120b armazena pesos de expert em MXFP4 (4-bit), o vLLM em H100s os descompacta para BF16 em registradores SM antes da multiplicação de matriz (W4A16). Assumir que o modelo roda inteiramente em FP4 leva a uma previsão errônea do regime de gargalo, uma realidade confirmada por nosso profiling de kernel.

Leia o White Paper

Não podemos afirmar saber o número ideal de usuários para sua implantação; cada implantação tem uma combinação única de modelo, hardware, mix de carga de trabalho e metas de latência que produzem números-alvo diferentes. O valor derivado de nossa pesquisa está na metodologia detalhada em nosso white paper: um processo repetível para encontrar sua própria resposta com confiança.

O artigo completo está disponível aqui: SPOC: a Stateful, Profile-based Optimization for LLM Capacity Planning Methodology.

Gostaríamos muito de saber como funciona se você adaptar a estrutura à sua própria configuração. Os melhores benchmarks são aqueles que refletem seus usuários reais.

Descubra mais no Blog VMware Cloud Foundation (VCF)

Assine para receber as últimas publicações em seu e-mail. Digite seu e-mail… Assinar

Como parceira certificada em soluções de infraestrutura e otimização de TI, a VirtuAllIT pode auxiliar sua empresa na implementação e adaptação de metodologias avançadas de planejamento de capacidade para LLMs, garantindo que sua infraestrutura atenda às demandas de desempenho e SLA.