Antes de ampliar o pool de GPUs, mensure o resultado

Essa distinção começa com a necessidade de diferenciar GPU alocada, GPU ocupada e carga de trabalho que produz resultados úteis. Entender como esses elementos se relacionam permite aproveitar melhor a capacidade existente antes de provisionar novos recursos.

Comece pelo resultado e pelo prazo definido

Analise as cargas de trabalho e os casos de uso que elas suportam. Um chatbot de atendimento ao cliente pode exigir capacidade de inferência 24 horas por dia, enquanto os resultados de uma avaliação de modelo podem ser necessários apenas antes da próxima sincronização de lançamento interno. Classificar cargas de trabalho em categorias amplas como “inference” e “training” não determina a urgência; algumas tarefas de inferência em lote podem esperar, enquanto um treinamento pode ter prazo rígido.

KubeCon + CloudNativeCon acontecerá em Salt Lake City de 9 a 12 de novembro. Registre-se agora!

Para cada carga de trabalho, registre seu prazo, tempo de execução esperado, requisitos de recursos e se interrupções são aceitáveis. Defina também o que constitui um resultado valioso. Um serviço de inferência deve ter um limiar de qualidade específico e um objetivo de latência. Uma solicitação concluinte ou uma resposta JSON válida por si só não demonstra se o objetivo foi atingido.

Mantenha a flexibilidade de início separada da tolerância à interrupção. Uma tarefa que pode ser iniciada em horário posterior ainda pode precisar rodar sem interrupções.

Use flexibilidade de agendamento antes de ampliar o pool

Suponha que quatro GPUs compatíveis estejam disponíveis para trabalhos em lote das 12h às 17h. Quatro trabalhos de avaliação independentes estão prontos às 12h. Cada um requer duas GPUs por uma hora, e todos os resultados precisam ser entregues até as 17h.

Iniciar todos os trabalhos imediatamente exigiria oito GPUs. Contudo, executar dois trabalhos às 12h e os outros dois às 13h conclui os quatro trabalhos até as 14h usando apenas as quatro GPUs já disponíveis. Considerando que os tempos de execução e os recursos de suporte permanecem inalterados, ambas as programações consomem oito horas de GPU, excluindo sobrecarga de inicialização.

“Agrupando os trabalhos, a demanda de pico é reduzida. As tarefas ainda terminam dentro do prazo sem precisar ampliar o pool.”

Antes de provisionar GPUs adicionais para limpar a fila, considere quanto de flexibilidade existe nos horários de início.

Ferramentas como Kueue oferecem um ponto de controle de admissão, usando cotas e políticas configuradas para determinar quando o trabalho é aceito. As equipes ainda precisam definir como representar e aplicar prazos e requisitos de carga de trabalho. Fila flexível pode apoiar o planejamento de capacidade e reduzir a necessidade de iniciar trabalhos antecipadamente, apenas para preemptá‑los depois.

Meça quanto de trabalho útil a implantação pode sustentar

O agendamento flexível pode aliviar restrições de capacidade. Contudo, equipes de inferência devem analisar se o modelo e a configuração de serviço correspondem ao tipo de trabalho.

Alta atividade de GPU não estabelece quanto de throughput adicional está disponível. A documentação de profiling da Nvidia explica que a atividade dos multiprocessadores de streaming pode incluir warps aguardando memória. Métricas de serviço, como solicitações em execução, solicitações em espera e ocupação do cache, adicionam contexto, enquanto contagens de preempção ajudam a explicar o comportamento. No vLLM, o uso do KV‑cache mede a fração de blocos de cache ocupados, mas não mede diretamente a capacidade total de serviço.

“Alta atividade de GPU não estabelece quanto de throughput adicional está disponível.”

Meça a capacidade sustentável com uma carga de teste representativa. Mantenha o modelo, o hardware, as configurações de serviço e a mistura de solicitações constantes. Em seguida, aumente a taxa de chegada e observe o throughput, a qualidade e a latência. A maior taxa sustentável que ainda atende aos requisitos da carga, incluindo limites de erro e percentis de latência selecionados, fornece uma estimativa útil de capacidade. Para geração interativa, inclua o tempo até o primeiro token e a entrega de tokens subsequentes, não apenas o tempo médio de conclusão. O DistServe mostra por que é importante avaliar a capacidade de serviço contra objetivos de nível de aplicação, como latência.

Compare o tráfego de produção com a capacidade testada. Baixa ocupação do cache pode indicar necessidade de investigação, mas afirmar que há dez vezes mais throughput sem um teste de throughput é inadequado. Filas breves podem representar bursts temporários, enquanto filas persistentes podem exigir diagnóstico. Nenhuma delas, isoladamente, identifica o recurso limitante.

Conecte dados do OpenCost a resultados verificáveis

A comunidade FinOps enquadra a eficiência de IA em torno de custo e resultados úteis. Para cargas de trabalho de IA, o custo se torna mais relevante quando está ligado aos resultados que a infraestrutura ajuda a entregar. Equipes de Kubernetes podem tornar essa relação concreta combinando custo da carga de trabalho, comportamento de serviço e resultados da aplicação.

Use a API de alocação do OpenCost para obter custos das cargas de trabalho em intervalos definidos, depois una esses dados com telemetria de serviço e registros de resultados usando identificadores de carga e timestamps. O OpenCost também oferece rastreamento opcional de custo por milhão de tokens. Ao calcular custo por resultado, inclua custos de GPU, CPU, memória e demais infraestruturas aplicáveis, e documente como custos compartilhados e ociosos são alocados. Adicione custos relevantes fora do OpenCost separadamente, sem duplicá‑los.

Um métrica útil é o custo por resultado verificado: custo total atribuível dividido pelo número de resultados que atendem aos requisitos de qualidade e são entregues dentro do prazo definido. Considere retries, falhas, inicialização e períodos ociosos que contribuem para o custo total. Conte o resultado final de negócio apenas uma vez. Quando a correção for estimada a partir de amostras revisadas, documente o método de amostragem e a incerteza.