A eficiência energética de LLM não é uma característica fixa do modelo. O mesmo modelo pode consumir quantidades muito diferentes de energia por solicitação útil quando você altera o tamanho do prefill, o tamanho da saída, o formato do batch, a precisão, o momento das solicitações, os clocks da GPU ou o runtime de serving. Meça esses fatores junto com a latência e a qualidade antes de considerar uma configuração eficiente.
Este guia é destinado a leitores avançados que operam ou avaliam inferência de LLM. A conclusão prática é simples: colete a energia no dispositivo ou nó, explique-a com a telemetria de serving e normalize-a em relação ao trabalho útil na camada de solicitação. Uma única leitura de watts não consegue cumprir as três funções.
A distinção se torna mais importante à medida que os orçamentos de raciocínio crescem. Tokens gerados adicionais aumentam a computação, mas o sistema ao redor desses tokens determina com que eficiência o hardware realiza esse trabalho. Minha análise anterior sobre tokens de raciocínio e seu custo computacional aborda o lado da carga de trabalho. Este artigo se concentra na auditoria de energia e no lado do serving.
A eficiência energética de LLM é um resultado da serving stack
Energia é a potência integrada ao longo do tempo. Se uma GPU opera a uma média de 400 watts durante dez segundos, ela consome 4.000 joules. Essa parte é fácil. A parte difícil é escolher a janela de tempo, o limite do hardware e a unidade de relatório.
“Energia por token” pode significar pelo menos três coisas diferentes:
| Métrica | Útil para | O que pode ocultar |
|---|---|---|
| --- | --- | --- |
| Joules por token de saída | Chat e geração com muito decode | Processamento do prompt, solicitações com falha, diferenças de qualidade |
| Joules por token de entrada efetivo | Prefill e trabalho com contexto longo | Trabalho de saída e valor da solicitação de ponta a ponta |
| Joules por solicitação bem-sucedida | Comparação de produtos e cargas de trabalho | Grandes diferenças no tamanho do prompt e da resposta |
| Solicitações por quilowatt-hora | Planejamento de capacidade e operações | Dificuldade da solicitação, qualidade e latência |
Nenhuma é universalmente correta. Escolha a unidade que corresponde ao contrato do serviço e, em seguida, informe contexto suficiente para que outra equipe possa repetir o teste.
O limite do hardware é igualmente importante. A API de gerenciamento da NVIDIA expõe contadores de energia do dispositivo em hardwares compatíveis. Isso pode produzir um delta limpo da GPU, mas, por padrão, não inclui trabalho da CPU, memória do host, armazenamento, rede, refrigeração ou perdas de conversão de energia. O CodeCarbon pode ampliar o limite com partes medidas e estimadas, mas sua documentação descreve estimativas de fallback para hardwares que ele não consegue ler. “Medido por uma ferramenta” não significa que todas as partes foram monitoradas.
Quatro estudos mediram partes diferentes da stack
Pesquisas recentes tornam visível o efeito do sistema. As porcentagens destacadas abaixo não formam um ranking. Cada estudo usa uma plataforma, uma carga de trabalho, uma linha de base e um limite de energia diferentes.
| Estudo | Escopo e método | Resultado relatado | Limite a considerar |
|---|---|---|---|
| --- | --- | --- | --- |
| AFlex | Desagrega o trabalho de attention e feed-forward e, em seguida, controla provisionamento, frequência, tamanho do batch e microbatching em sistemas A800 | Até 49% menos energia por token do que a linha de base desagregada testada, mantendo as metas de TTFT e TPOT | Duas famílias de modelos, hardware A800 e traces avaliados no estilo de produção |
| Festina | Coordena posicionamento, particionamento de GPU, ponto de operação, consolidação e migração para inferência compartilhada em H100 | Até 56% menos energia, com o cumprimento dos SLOs mantido dentro de dois pontos percentuais na configuração relatada | Contexto serverless com GPU compartilhada; os ganhos diminuem quando o prefill já é intensivo em computação |
| EnerInfer | Prevê throughput e potência em diferentes configurações de NPU e memória e, em seguida, gerencia as configurações de controle sob limites térmicos | Ganhos de eficiência energética de 65% em celulares, 12% em um laptop e 24% em uma placa de edge | As economias no dispositivo de ponta a ponta foram menores, de 4,2–11%, porque outras partes e fases ainda consumiram energia |
| Understanding Efficiency | Testa quantização, batching, padrões de chegada e escolhas de serving em GPUs H100 | O continuous batching reduziu a energia por solicitação em 12,5× em comparação com a linha de base sequencial do estudo; chegadas estruturadas alcançaram ganhos maiores em um teste fixo | Prompts curtos, dois tamanhos de modelos Llama, uma família de aceleradores e dados de energia principalmente focados na GPU |
O resultado compartilhado é mais importante do que qualquer porcentagem individual: a orquestração pode alterar o consumo de energia o suficiente para invalidar uma estimativa baseada apenas no modelo. Os artigos também mostram por que “use menor precisão” é um conselho incompleto. O estudo com H100 descobriu que menor precisão ajudou o prefill limitado por computação, enquanto o overhead de desquantização e dos kernels podia eliminar ou inverter o benefício durante o decode limitado por memória.
Trate todo número “de até” como uma propriedade do experimento dos autores. O AFlex não prova uma economia de 49% no seu cluster B200. O EnerInfer não prova uma economia de 65% no dispositivo inteiro para todo celular. Os resultados identificam controles que vale a pena testar, não economias que você pode copiar para uma previsão.
Separe prefill de decode antes de otimizar
Uma solicitação de LLM tem duas fases com gargalos diferentes.
O prefill geralmente exige muita computação
O prefill processa o prompt e constrói o cache de chave-valor. Prompts longos criam rajadas de trabalho paralelo de matrizes. Alterações de precisão e clocks mais altos podem ajudar quando essa fase é limitada por computação, mas um time-to-first-token menor ainda pode vir acompanhado de um pico de potência maior. Meça energia, não apenas potência.
O decode geralmente exige muita memória
O decode produz tokens um passo por vez. Ele lê repetidamente os pesos do modelo e o KV cache crescente, portanto o tráfego de memória e a formação do batch frequentemente dominam. Clocks mais altos podem adicionar potência sem throughput proporcional. A quantização também pode adicionar overhead de conversão quando os kernels ou o caminho de hardware não estão bem alinhados.
Essa divisão por fases explica por que uma média de toda a solicitação pode induzir ao erro. Uma configuração pode melhorar o prefill de prompts longos e prejudicar o decode de prompts curtos. Informe pelo menos o tamanho do prompt, o tamanho da saída, o batch ou a concorrência, a precisão e os tempos de cada fase junto com todo resultado de energia.
O KV cache deve estar no mesmo registro. Meu guia sobre falhas de eviction do KV cache explica o lado da confiabilidade. Para o trabalho de energia, a pressão do cache pode alterar o tráfego de memória, a recomputação, o posicionamento e as taxas de retry. Uma execução com evictions silenciosos não é comparável a uma execução sem eles.
Execute uma auditoria de energia que proteja os SLOs de latência
A auditoria precisa de três camadas conectadas: resultados das solicitações, contexto de serving e energia do dispositivo ou nó.
*Um resultado de energia útil precisa de uma unidade clara, contexto de serving e um limite explícito de hardware.*
1. Congele uma carga de trabalho representativa
Crie fatias da carga de trabalho em vez de uma única média sintética. No mínimo, separe prompts curtos e longos, saídas curtas e longas, chegadas constantes e em rajadas e os níveis de qualidade usados pela sua aplicação. Mantenha o modelo, o tokenizer, a política de sampling e as regras de parada fixos durante uma comparação.
Use formatos reais de solicitações quando privacidade e consentimento permitirem. Se usar prompts sintéticos, preserve as distribuições de tamanho dos tokens e de chegada que impulsionam o sistema. O relatório final deve identificar a demanda sintética como sintética.
2. Registre os resultados no nível da solicitação
Para cada solicitação, capture:
Não remova falhas do total de energia. Uma configuração que consome menos energia em solicitações concluídas ao atingir timeout nas solicitações difíceis não é mais eficiente.
3. Registre o contexto de serving
Registre os controles que podem explicar uma mudança: duração do prefill e do decode, tamanho do batch, sequências ativas, profundidade da fila, precisão, paralelismo, ocupação do cache, posicionamento, clocks ou limite de potência da GPU e carga de co-tenant.
Essa telemetria também captura efeitos de ociosidade e rajadas. Um runtime que mantém as CPUs ocupadas enquanto a GPU espera pode parecer adequado em uma leitura apenas da GPU e pior no limite do nó ou da frota. Threads de issues de código aberto são úteis para encontrar esses modos de falha, mas são anedotas até que você os reproduza na sua stack.
4. Meça um limite explícito de energia
Em GPUs NVIDIA compatíveis, o NVML expõe um contador de energia total em milijoules. Uma sonda Python mínima pode delimitar uma carga de trabalho fixa:
python from pynvml import ( nvmlDeviceGetHandleByIndex, nvmlDeviceGetTotalEnergyConsumption, nvmlInit, nvmlShutdown, )
nvmlInit() gpu = nvmlDeviceGetHandleByIndex(0) start_mj = nvmlDeviceGetTotalEnergyConsumption(gpu)
run_fixed_workload() # same requests, model, and stopping rules
end_mj = nvmlDeviceGetTotalEnergyConsumption(gpu) nvmlShutdown()
gpu_joules = (end_mj - start_mj) / 1_000 joules_per_output_token = gpu_joules / completed_output_tokens
A documentação de consultas de dispositivo do NVML define o contador e suas unidades. Verifique o suporte na GPU e no driver exatos. O valor cumulativo é redefinido quando o driver é recarregado; portanto, rejeite um delta negativo ou inválido. Para dispositivos sem contador de energia, faça amostragem da potência em uma frequência que capture solicitações curtas e integre o trace na mesma janela.
A energia da GPU é um limite válido se você o nomear. Para contabilidade de capacidade, custo ou carbono, adicione as partes do host e da instalação conforme a decisão exigir. A documentação do CodeCarbon pode ampliar a auditoria, mas leia quais valores a ferramenta mede e quais estima. A medição externa no rack ou na parede continua sendo a verificação mais forte para comparações de nós inteiros.
5. Normalize o resultado de mais de uma forma
Informe um pequeno conjunto de métricas em vez de um único número vencedor:
Uma métrica ajuda a ajustar o caminho de decode. Outra conecta a mudança ao valor do produto. Os campos de latência e qualidade impedem que uma otimização de energia enfraqueça silenciosamente o serviço.
6. Altere um controle e depois reproduza a demanda
Comece com experimentos isolados: precisão, política de batch, agrupamento de solicitações, configuração do cache, limite de potência ou clock da GPU e posicionamento. Execute testes repetidos após o aquecimento. Altere a ordem entre os testes quando o calor ou o horário do dia puderem enviesar o resultado.
Depois, reproduza os melhores candidatos sob chegadas mistas. Festina e AFlex coordenam vários controles porque os ótimos locais interagem. Sua primeira etapa deve isolar as causas; a etapa final deve testar a política combinada sob o SLO real.
Otimize na ordem sustentada pelas evidências
A ordem de otimização mais segura começa pelo trabalho desperdiçado e depois avança para controles de hardware mais precisos.
Se o sistema atende a diferentes níveis de qualidade, combine esse processo com um benchmark de trabalho real. O fluxo prático de benchmarking de modelos mantém qualidade, latência e custo visíveis enquanto você altera o caminho de serving.
Não confunda energia, custo e carbono
Essas métricas respondem a perguntas diferentes.
Uma conta menor na nuvem não prova menor consumo de energia. Um contador menor da GPU não prova menor consumo de energia da instalação. Uma execução com menor consumo de energia não tem automaticamente menores emissões se for executada em outro horário ou local.
O problema de relatório é suficientemente ativo para chegar ao trabalho de padronização. Um item de trabalho ITU-T sobre métricas de eficiência energética de inferência de AI inclui limites de tokens, indicadores de energia por token, cálculos de carbono e regras de relatório em seu escopo. Esse trabalho mostra que as unidades de token e os limites do sistema continuam indefinidos. Não é um benchmark concluído.
A regra de decisão para produção
Aceite uma mudança na eficiência energética de LLM somente quando ela reduzir a energia para a unidade pretendida de trabalho útil e mantiver o contrato da solicitação dentro do orçamento.
Escreva esse contrato antes do teste:
Essa regra evita três erros comuns: otimizar watts em vez de joules, otimizar tokens concluídos enquanto oculta falhas e transferir o resultado “de até” de um artigo para um hardware diferente.
A pesquisa aponta uma direção prática, não uma configuração universal. Crie perfis separados para prefill e decode. Mantenha os registros da solicitação, do runtime e do hardware vinculados. Meça o limite que você pretende gerenciar. É assim que um número de energia se transforma em uma decisão de engenharia.