Palancas para gastar menos vatios por token: catálogo cuantificado para inferencia LLM

Tue, 16 Jun 2026 09:00:00 +0200

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

TL;DR

Siete palancas independientes actúan sobre el numerador o el denominador de la identidad (\text{J/token} = \text{potencia (W)} / \text{throughput (tok/s)}). Aplicadas en orden de coste-beneficio: la cuantización (FP16→FP8) recorta el J/token un 30–50% sin cambiar hardware; el power capping al 70% del TDP reduce la potencia un 30% con menos de un 10% de caída de throughput en cargas memory-bound; el DVFS en fase decode ahorra un 22–45% adicional; el continuous batching baja el J/token un 25–40% respecto a stacks sin optimizar; el speculative decoding recorta hasta un 29% el J/token en batch bajo; el prefix caching elimina el recompute de prefill para prompts repetidos; y el scheduling a horas limpias desplaza la huella de carbono sin cambiar el consumo físico. Referencia de partida: un stack vLLM FP16 en H100 SXM (700 W TDP) con Llama-3 70B produce ~0,39 J/token bajo cargas batch realistas; un stack sin optimizar (PyTorch baseline) parte de 2–6× más. Las palancas se apilan; el efecto combinado puede llegar a un 73% de reducción respecto al baseline no optimizado (arXiv 2504.17674).

La identidad de referencia

$$\text{J/token} = \frac{\overline{P}\ [\text{W}]}{\text{throughput}\ [\text{tok/s}]}$$

donde (\overline{P}) es la potencia media sobre la ventana de medición (ver metodología en energía por token). Las palancas actúan sobre uno de los dos factores:

Reducen (\overline{P}): power capping, DVFS, scheduling a horas de baja intensidad.
Aumentan throughput (denominador): cuantización, continuous batching, speculative decoding, prefix caching, chunked prefill, selección de modelo.
Ambos a la vez: cuantización (menor footprint de pesos → mayor batch cabe en VRAM → mayor throughput a potencia similar o menor).

La fórmula expandida incluyendo el overhead de infraestructura:

$$\text{J/token}{\text{efectivo}} = \frac{\overline{P}{\text{GPU}} + \overline{P}{\text{resto nodo}}}{\text{throughput}{\text{tok/s}}} \times \text{PUE}$$

Para los cálculos de palancas se trabaja sobre (\overline{P}_{\text{GPU}}) por claridad; el factor PUE (ver energía por token) amplifica o atenúa el efecto de cada palanca de forma proporcional.

Tabla maestra: palancas × impacto × coste × herramienta

Palanca	Reducción J/token (%)	Efecto en latencia	Efecto en calidad	Herramienta OSS principal	Fuente
Cuantización FP16→FP8	30–50%	−8–33% TPOT (mejora)	degradación <1% en benchmarks	vLLM, TRT-LLM, llm-compressor	arXiv 2504.17674, baseten.co
Cuantización FP16→INT4 (AWQ/GPTQ)	45–60%	mejora latencia (menor BW)	degradación 1–3% según modelo	AutoAWQ, llm-compressor, vLLM	arXiv 2504.17674
Continuous batching vs estático	25–40% vs PyTorch	+5× throughput (mejora)	sin impacto	vLLM, TGI, TRT-LLM	arXiv 2504.17674, TokenPowerBench
Power capping 70% TDP	20–30% potencia	<10% throughput (decode)	sin impacto	nvidia-smi, DCGM, Zeus	arXiv 2604.11391, NERSC docs
DVFS decode-phase	22–45% en decode	1–6% latencia total	sin impacto	nvidia-smi, GreenLLM, DVFS-GPT	arXiv 2501.08219, HAL 05190051
Speculative decoding	hasta 29% (batch≤16)	TTFT mejora	sin impacto demostrable	vLLM, TRT-LLM	arXiv 2602.09113
Prefix caching	50–90% en prefill reusable	TTFT −50–80% (prompts repetidos)	sin impacto	vLLM, SGLang	vLLM docs
Chunked prefill	~10–15% en cargas mixtas	TTFT más estable	sin impacto	vLLM (SARATHI)	arXiv 2308.16369
Selección SLM vs LLM denso	60–80% (modelo 7B vs 70B)	latencia baja	degradación variable por tarea	Ollama, vLLM, llama.cpp	arXiv 2504.17674
Scheduling a horas limpias	0% J/token, hasta −70% CO₂	sin impacto en la carga	sin impacto	Kueue, Volcano, cron	ACM SLIT, arXiv 2507.09942

Nota: los porcentajes son sobre el J/token efectivo de la carga, no sobre la potencia de placa en vacío. Los efectos se miden siempre en condiciones de igual calidad de salida (mismo modelo, mismo serving stack, misma distribución de prompts).

Palanca 1: cuantización

Mecánica

La cuantización reduce la precisión numérica de los pesos (y opcionalmente las activaciones), lo que acorta el tiempo de lectura de pesos desde HBM por token generado. El decode es memory-bandwidth-bound: el cuello es leer los pesos, no computar. Reducir la anchura de bits libera ancho de banda para mayor throughput o permite meter más batch en VRAM.

Formato	Bits/peso	Reducción BW vs FP32	J/token vs FP16	Herramienta
FP32	32	1× (referencia)	+100% (peor)	—
BF16/FP16	16	2×	referencia	vLLM nativo
FP8 (W8A8)	8	~4×	−30–50%	vLLM, TRT-LLM, llm-compressor
INT4 AWQ (W4A16)	4	~8×	−45–60%	AutoAWQ, llm-compressor
INT4 GPTQ (W4A16)	4	~8×	−40–55%	AutoGPTQ, vLLM

Datos concretos de referencia:

Llama-3 405B en H100, FP16→FP8: −30% J/token medido; TPOT mejora un 33% (Baseten, baseten.co/blog/33-faster-llm-inference-with-fp8-quantization).
El stack vLLM+CUDA graphs vs PyTorch baseline: 2–6× más eficiente en J/token (arXiv 2504.17674).
Llama-65B en V100 FP16: 3–4 J/token. Llama-3 70B en H100 FP8: 0,39 J/token. Reducción combinada hardware+cuantización: ~90% (MLCommons, arXiv 2504.17674).

Coste de calidad

La cuantización FP8 con calibración produce degradación <1% en benchmarks estándar (MMLU, HumanEval). INT4 AWQ puede producir 1–3% de degradación dependiendo del modelo y la tarea; INT4 GPTQ sin calibración fina, hasta 2–5%. Se valida con leaderboards de energía y benchmarks de calidad propios.

Herramientas OSS

# vLLM con FP8 (cuantización en tiempo de carga, H100/A100)
vllm serve meta-llama/Llama-3-70B-Instruct \
 --quantization fp8 \
 --dtype auto

# llm-compressor: cuantización offline a W4A16 (AWQ)
python -m llmcompressor.transformers.compression.helpers \
 --model meta-llama/Llama-3-70B-Instruct \
 --recipe w4a16_awq.yaml \
 --output-dir llama-70b-w4a16/

Palanca 2: continuous batching

Mecánica

El batching estático mantiene el batch fijo: si una petición termina antes, el slot queda vacío hasta el final del batch. El continuous batching inserta nuevas peticiones en cuanto un slot libera, manteniendo la GPU siempre al máximo de utilización posible.

El efecto energético: la potencia GPU es casi constante (la GPU está siempre activa); el throughput crece. El resultado es un denominador mayor a potencia similar:

$$\text{J/token}{\text{batch continuo}} = \frac{\overline{P}}{\text{throughput}{\uparrow}}$$

Datos medidos (arXiv 2504.17674, TokenPowerBench arXiv 2512.03024):

vLLM con PagedAttention vs Transformers sin optimizar: −25–40% J/token en cargas batch altas.
Continuous batching online vs static offline: −5% adicional de J/token (pequeño pero consistente).
Batch 32→256 tokens: −25% J/token en Llama-3 70B (economías de escala de kernel).
Throughput: ×5 respecto a stacks de batching estático a carga equivalente.

El knee de eficiencia en H100 se sitúa en torno a 256–512 tokens de batch; más allá, el J/token se estabiliza o sube ligeramente.

Herramientas OSS

vLLM, TGI (Text Generation Inference de HuggingFace), TRT-LLM. El flag relevante en vLLM: --max-num-seqs (máximo de secuencias concurrentes); ajustarlo al tamaño de VRAM disponible maximiza el batch efectivo.

Palanca 3: power capping

Mecánica

El power cap fija un techo de potencia instantánea (W). La GPU lo respeta recortando el clock (DVFS interno). El truco de eficiencia: LLM decode es memory-bandwidth-bound; la GPU ya no está a full clock útil, y bajar el TDP reduce la potencia sin degradar el throughput de forma proporcional.

La curva power cap vs throughput (H100 SXM)

Datos de (arXiv 2604.11391) y NERSC (docs.nersc.gov/jobs/power-capping):

Power cap (W)	% del TDP (700 W)	Throughput relativo (memory-bound)	Eficiencia (tok/W)
700 W	100%	100%	1,00×
560 W	80%	~95%	~1,19×
490 W	70%	~90–95%	~1,27× (sweet spot)
420 W	60%	~80–85%	~1,33× (latencia sube)
350 W	50%	~75% (H100 alcanza BW máximo a 350 W memory-bound)	~1,50×
200 W	29%	~50%	saturación de frecuencia

Hallazgo clave de arXiv 2604.11391: el H100 alcanza su máximo ancho de banda de memoria efectivo con solo ~350 W en cargas memory-bound (STriad benchmark), frente a 700 W de TDP. Bajar de 700 W a 490 W (−30% potencia) produce menos de un 10% de caída de throughput en decode: el J/token mejora un ~20–27%.

Para cargas compute-bound (prefill pesado), el sweet spot se desplaza a 400–500 W, donde el rendimiento escala de forma casi lineal con el cap; de 500 W a 700 W, la ganancia es solo ~10% de throughput adicional por cada 100 W más.

Fórmula de J/token con power cap

$$\text{J/token}(P_{\text{cap}}) = \frac{P_{\text{cap}} \times \eta(P_{\text{cap}})}{\text{throughput}{\text{base}} \times f(P{\text{cap}})}$$

donde (\eta(P_{\text{cap}})) es la fracción de potencia efectivamente consumida bajo el cap (en cargas memory-bound, la GPU ya no consume todo el cap), y (f(P_{\text{cap}})) es la fracción de throughput resultante. En la zona 490–560 W del H100, (\eta \approx 0{,}9) y (f \approx 0{,}92\text{–}0{,}95): el numerador baja más que el denominador, por lo que el J/token mejora.

Comandos

# Fijar el power cap a 490 W en la GPU 0 (H100 SXM, TDP 700 W)
sudo nvidia-smi -i 0 -pl 490

# Verificar el límite aplicado y la potencia en tiempo real
nvidia-smi --query-gpu=power.limit,power.draw --format=csv -l 1

# Con DCGM: leer DCGM_FI_DEV_POWER_USAGE en Prometheus
# y DCGM_FI_DEV_POWER_LIMIT para confirmar que el cap está activo

# Aplicar el cap a todas las GPUs del nodo (script de systemd/cron)
for i in $(seq 0 3); do
 sudo nvidia-smi -i $i -pl 490
done

Con DCGM en producción, el cap se puede establecer vía dcgmi policy --set powercap:490 o mediante el GPU Operator de NVIDIA (campo powerLimit en el DevicePlugin). Zeus (ml.energy/zeus) permite sweepear caps automáticamente y medir el J/token resultante por configuración.

Palanca 4: DVFS (Dynamic Voltage and Frequency Scaling)

Mecánica

DVFS es más fino que el power cap: permite ajustar la frecuencia del SM directamente (nvidia-smi -lgc para lock GPU clock) o dejar que el driver la ajuste dinámicamente según la potencia disponible y la carga. En LLM inference, la asimetría entre fases es el dato clave:

Prefill: compute-bound. Beneficia de clock máximo. Sensible a reducción de frecuencia.
Decode: memory-bandwidth-bound. El clock del SM apenas importa; lo que manda es el ancho de banda HBM.

Esta asimetría es la que explotan los sistemas de DVFS específicos para LLM:

Sistema	Ahorro energético	Penalidad latencia	Hardware	Fuente
DVFS-GPT (HAL)	hasta 32% en iso-latencia	~1–2%	A100, RTX 4090	HAL 05190051
EcoInfer	hasta 25,4% (media 21,5%)	<5%	A100	arXiv MDPI Electronics
DualScale (prefill/decode disaggregado)	22–45% con SLO	1–6%	H100	arXiv 2602.18755
GreenLLM (SLO-aware DVFS)	18–30%	dentro del SLO	—	arXiv 2508.16449

El paper arXiv 2501.08219 mide que reducir la frecuencia de GPU de 2.842 MHz a 180 MHz logra un ahorro medio del 42% con solo 1–6% de aumento de latencia en la fase decode — porque el decode es memory-bound y la frecuencia del SM no es el cuello.

Comandos (DVFS manual)

# Bloquear el clock del SM a 1.200 MHz (H100 boost: 1.980 MHz) para decode
sudo nvidia-smi -i 0 -lgc 1200,1200

# Restaurar el clock dinámico
sudo nvidia-smi -i 0 -rgc

# Modo persistente (necesario para que el lock sobreviva entre trabajos)
sudo nvidia-smi -pm 1

Para DVFS automático ajustado al SLO (TPOT objetivo), los sistemas como GreenLLM o DVFS-GPT miden el tiempo de cada iteración y ajustan la frecuencia en tiempo real, sin sobrespasar el presupuesto de latencia.

Palanca 5: selección de modelo (SLM, MoE vs denso)

El efecto de la escala

El J/token escala con el tamaño del modelo, pero de forma sublineal. Para Llama-3 (arXiv 2504.17674):

Modelo	Parámetros	J/token relativo	Factor vs 1B
Llama-3 1B	1B	1,0×	referencia
Llama-3 8B	8B	~2,3×	×2,3 (no ×8)
Llama-3 70B	70B	~7,3×	×7,3 (no ×70)
Llama-3 405B	405B	~40×	×40 (no ×405)

El J/token crece ~7,3× de 1B a 70B, mientras que los parámetros crecen ×70: la eficiencia de hardware (caches, tensor parallelism, kernels) amortigua la escala. Aun así, pasar de 70B a 8B recorta el J/token un ~68% si la calidad es suficiente para la tarea.

MoE vs denso

Los MoE activan solo un subconjunto de expertos por token (típicamente 2 de 8–64), lo que reduce el cómputo activo. Pero hay una trampa de implementación:

OLMoE-1B-7B (MoE, 1B activos) vs OLMo-1B (denso): el MoE consume un 54,24% más de energía por token que el modelo denso de igual tamaño activo (arXiv 2504.17674), porque los kernels fusionados de los expertos son ~19–63% más lentos que una GEMM densa equivalente.
OLMoE-1B-7B vs OLMo-7B (denso): el MoE sí es más eficiente (7B activos → solo 1B activos, ~7× reducción de FLOPs activos por token).

La regla: MoE es eficiente cuando la comparación es parámetros totales iguales, activos menores (p.ej. Mixtral 8×7B vs Llama-3 70B denso). No es eficiente cuando la comparación es parámetros activos iguales por token.

Tabla de selección de modelo por caso de uso

Caso de uso	Modelo recomendado	Razón de eficiencia
Chat simple, extracción de entidades	SLM 7–8B FP8	−68% J/token vs 70B
RAG con contextos largos	70B FP8 o MoE 8×7B	calidad/J óptimo en K>2K tokens
Código complejo, razonamiento	70B FP8 o 405B INT4	calidad no negociable
Clasificación, embeddings	modelo dedicado (ej. E5, BGE)	órdenes de magnitud menos J
Batch diferible offline	MoE grande (DeepSeek, Mixtral)	alta calidad, throughput batch

Palanca 6: speculative decoding

Mecánica

El speculative decoding usa un modelo borrador pequeño (draft model) para proponer varios tokens, que el modelo objetivo verifica en paralelo en un solo forward pass. Si los tokens son aceptados, se generan K tokens por paso en lugar de 1: throughput potencialmente K×.

Condición de eficiencia energética

El beneficio en J/token depende del batch size (arXiv 2602.09113):

Batch size	Efecto en J/token	Razón
1–16 (batch bajo)	−hasta 29%	el draft model llena el tiempo de espera; verificación es barata
32–64 (batch medio)	~0% (neutro)	el overhead de verificación compensa el ganado
128+ (batch alto)	+25% (peor)	GPU saturada; el draft model añade overhead sin ahorrar

Conclusión: speculative decoding es una palanca de J/token solo en régimen de baja latencia (batch≤16); en high-throughput serving, es contraproducente en términos de J/token (aunque reduce latencia TPOT).

Herramientas OSS

vLLM soporta speculative decoding con --speculative-model y --num-speculative-tokens. TRT-LLM también. El draft model debe ser de la misma familia (p.ej. Llama-3 8B para draft de Llama-3 70B).

Palanca 7: prefix caching y chunked prefill

Prefix caching

El KV-cache del prefill de un prompt compartido (system prompt, few-shot examples, contexto de documento) es idéntico entre peticiones. Almacenarlo y reutilizarlo elimina el recompute del prefill para esa fracción del prompt.

Impacto en energía: el prefill es compute-bound y tira picos de potencia. Eliminar el prefill repetido elimina esos picos. En escenarios con system prompt fijo de 1.000 tokens y prompts de usuario de 200 tokens, el ahorro es ~1.000/(1.000+200) = ~83% de la energía de prefill. En J/token total, el efecto depende de la longitud del prompt compartido vs la longitud de generación.

Habilitación en vLLM:

vllm serve meta-llama/Llama-3-70B-Instruct \
 --enable-prefix-caching \
 --max-num-seqs 256

Chunked prefill (SARATHI)

El chunked prefill parte el prefill en chunks de tamaño fijo y procesa cada chunk junto con tokens de decode de otras peticiones. El beneficio: el prefill de un prompt largo ya no bloquea el decode de otras peticiones (reducing TPOT spikes), lo que permite mayor utilización de la GPU en el tiempo.

En términos de J/token total, el chunked prefill reduce la potencia de pico del nodo (menos spikes de prefill) y mejora la utilización media, lo que se traduce en ~10–15% menos de J/token en cargas mixtas con prompts largos (arXiv 2308.16369).

# Activar chunked prefill en vLLM (tamaño de chunk: 512 tokens)
vllm serve meta-llama/Llama-3-70B-Instruct \
 --enable-chunked-prefill \
 --max-num-batched-tokens 512

Palanca 8: scheduling a horas limpias

Esta palanca no reduce el J/token físico, pero sí el gCO₂/token de la carga diferible. La mecánica: mover entrenamiento, ingestión de documentos, re-ranking batch y fine-tuning a las horas de menor intensidad de carbono de la red.

Datos de impacto de temporal shifting (ACM SLIT, arXiv 2507.09942):

Reducción de CO₂ por temporal shifting: hasta 34,7% para cargas flexibles.
Con carbon-aware reinforcement learning (Eco-Orchestrator): hasta 70% de offset en despliegues integrados.
En España, la variación horaria de intensidad es ~80–250 gCO₂/kWh: un factor ~3× en el mismo día (ver del vatio al carbono).

La implementación práctica usa Kueue o Volcano en Kubernetes, con una métrica de intensidad de red (ElectricityMaps API o esios) como señal de scheduling. Las cargas se marcan con una anotación carbon-deadline (tiempo máximo de espera tolerable) y el scheduler las coloca en las horas de mínima intensidad dentro de esa ventana.

# Anotación Kueue para scheduling consciente de carbono
metadata:
 annotations:
 kueue.x-k8s.io/carbon-aware: "true"
 kueue.x-k8s.io/carbon-deadline: "8h"

La curva power cap vs throughput: el sweet spot

La lectura del gráfico: la curva de potencia (línea continua) cae más rápido que la curva de throughput (línea discontinua) en la zona 490–560 W. Por encima de 560 W, cada 70 W adicionales dan solo un ~5% de throughput extra; por debajo de 420 W, el throughput empieza a caer más rápido que la potencia. El sweet spot de eficiencia (J/token mínimo) está en 490–560 W para cargas decode-bound.

Para cargas compute-bound (prefill puro), el sweet spot se desplaza a 500–600 W: el prefill satura el cómputo de los SM y necesita más potencia para mantener el throughput.

Cómo medir el efecto y validar la calidad

Stack de medición

El stack completo para medir el efecto de cada palanca:

Qué medir	Herramienta	Métrica
Potencia GPU en tiempo real	DCGM (`DCGM_FI_DEV_POWER_USAGE`)	W por GPU, 100ms
J/token en producción	Kepler + vLLM tokens	`rate(kepler_joules) / rate(vllm_tokens)`
J/token en banco	Zeus (`ZeusMonitor`)	J medidos durante el benchmark
Throughput	vLLM metrics (`vllm:generation_tokens_total`)	tok/s
Latencia TPOT	vLLM (`vllm:e2e_request_latency`)	ms/tok
Calidad de salida	lm-evaluation-harness	MMLU, HumanEval, etc.

Ver el stack completo en herramientas de energía.

Protocolo de medición por palanca

# J/token en tiempo real (Kepler + vLLM en Prometheus)
sum(rate(kepler_container_joules_total{container="vllm"}[5m]))
 /
sum(rate(vllm_generation_tokens_total[5m]))

# Potencia media por GPU (DCGM)
avg by (gpu) (DCGM_FI_DEV_POWER_USAGE)

# Verificar power cap activo
avg by (gpu) (DCGM_FI_DEV_POWER_LIMIT)

Con Zeus, el sweep de configuraciones es automático:

from zeus.monitor import ZeusMonitor

monitor = ZeusMonitor(gpu_indices=[0, 1, 2, 3])

with monitor.begin_window("fp8_inference"):
 # lanzar benchmark con vLLM FP8
 run_benchmark(model="llama-3-70b-fp8", num_tokens=10_000)

result = monitor.end_window("fp8_inference")
print(f"J/token: {result.total_energy / 10_000:.4f}")

Validación de calidad

La validación de que la palanca no degrada la calidad se hace con lm-evaluation-harness (github.com/EleutherAI/lm-evaluation-harness):

# Comparar MMLU entre FP16 y FP8
lm_eval --model vllm \
 --model_args pretrained=meta-llama/Llama-3-70B-Instruct,dtype=float16 \
 --tasks mmlu --num_fewshot 5 --output_path ./results/fp16/

lm_eval --model vllm \
 --model_args pretrained=meta-llama/Llama-3-70B-Instruct,quantization=fp8 \
 --tasks mmlu --num_fewshot 5 --output_path ./results/fp8/

La diferencia de puntuación en MMLU entre FP16 y FP8 con calibración es típicamente <1%. Sin calibración puede ser 2–4%.

Tabla de decisión Pareto (energía / latencia / calidad)

Palanca	J/token	TPOT (latencia)	Calidad	Coste implementación	Reversibilidad
Cuantización FP8	↓↓↓	↓ (mejora)	~ (−<1%)	Bajo (1 flag)	Alta
Cuantización INT4 AWQ	↓↓↓↓	↓ (mejora)	↓ (−1–3%)	Medio (recalibrar)	Alta
Continuous batching	↓↓↓	~ (neutro en TPOT)	~	Bajo (motor nuevo)	Alta
Power cap 70% TDP	↓↓	↑ <10%	~	Muy bajo (1 comando)	Inmediata
DVFS decode	↓↓↓	↑ <6%	~	Medio (script + tuning)	Alta
Speculative decoding	↓ (batch bajo)	↓ (mejora TTFT)	~	Medio (draft model)	Alta
Prefix caching	↓↓ (prefill)	↓↓ (TTFT mejora)	~	Bajo (1 flag)	Alta
Chunked prefill	↓	↑ TPOT estable	~	Bajo (1 flag)	Alta
SLM (7B vs 70B)	↓↓↓↓	↓↓ (mejora mucho)	↓↓ (−variable)	Alto (re-eval calidad)	Media
MoE (vs denso mismo tamaño activo)	↑ (+54%)	↑	~	—	—
Scheduling a horas limpias	~ J/token, ↓↓ CO₂	~ (para diferible)	~	Medio (scheduler)	Alta

Leyenda: ↓↓↓↓ mejora fuerte · ↓↓↓ mejora significativa · ↓↓ mejora moderada · ↓ mejora leve · ~ neutro · ↑ empeora · ↑↑ empeora significativamente.

Apilamiento de palancas: efecto combinado

Las palancas son en su mayoría ortogonales y se apilan. El impacto combinado máximo documentado en (arXiv 2504.17674):

“La aplicación correcta de las optimizaciones de inferencia relevantes puede reducir el consumo de energía total hasta un 73% respecto a baselines sin optimizar.”

Secuencia recomendada por coste-beneficio:

Motor optimizado (vLLM, TRT-LLM) con continuous batching: −25–40% inmediato.
Cuantización FP8 (si el hardware lo soporta: H100, A100 con soporte limitado): −30–50% adicional sobre el J/token restante.
Power cap al 70% TDP: −20–30% de potencia con <10% de throughput. Bajo coste.
Prefix caching: actívalo si hay system prompts o contextos repetidos. Sin coste.
Chunked prefill: si la carga tiene prompts variables largos.
DVFS en decode: −22–45% adicional si el SLO lo permite.
Speculative decoding: solo si el batch es bajo (<16) y la latencia TTFT importa.
Selección de modelo: pasar a SLM si la calidad es suficiente (evaluar con lm-evaluation-harness en tu tarea concreta).

Ejemplo cuantificado en 4×H100 SXM (2.800 W TDP nodo), Llama-3 70B, carga chat:

Configuración	Potencia (W)	Throughput (tok/s)	J/token
PyTorch FP16, batch estático	~2.100	~400	5,25
vLLM FP16, continuous batching	~2.200	~1.800	1,22
vLLM FP8, continuous batching	~2.100	~2.400	0,875
+ power cap 490 W/GPU (1.960 W nodo)	~1.960	~2.160	0,907
+ prefix caching (40% hit rate)	~1.960	~2.600	0,754
+ DVFS decode 1.200 MHz	~1.500	~2.400	0,625

Los valores son estimaciones ilustrativas basadas en los papers citados aplicados a un nodo 4×H100. El J/token real depende de la distribución de prompts, el batch efectivo y la temperatura de los modelos. Medirlo con Zeus o DCGM+Kepler es obligatorio.

Hardware de referencia: TDP y rangos de power cap

GPU	TDP (W)	Rango de cap soportado	Sweet spot decode
H100 SXM 80GB	700	200–700 W	~490–560 W
H100 PCIe 80GB	350	100–350 W	~245–280 W
A100 SXM 80GB	400	100–400 W	~280–320 W
A100 PCIe 80GB	300	100–300 W	~210–240 W
L40S 48GB	350	100–350 W	~245–280 W
RTX 5090 (referencia, PCIe)	575	~100–575 W	~400–460 W

Para los rangos exactos: nvidia-smi -q -d POWER | grep -E "Min|Max|Current".

Resumen ejecutivo por rol

Rol	Primera acción	Segunda acción	Herramienta clave
Operador de cluster	`nvidia-smi -pl [70% TDP]` en todos los nodos	Activar persistent mode	nvidia-smi, DCGM
Ingeniero de serving	Migrar a vLLM FP8 con continuous batching	Activar prefix caching	vLLM, llm-compressor
Arquitecto de plataforma	Seleccionar el modelo mínimo que cumple el SLO de calidad	Diseñar policy de scheduling por carbono	lm-evaluation-harness, Kueue
Equipo de MLOps	Montar sweep de power cap con Zeus	Instrumentar J/token en Prometheus	Zeus, DCGM exporter

Ver el stack de medición completo en herramientas de energía y la metodología de J/token en energía por token. Para el contexto de leaderboards y benchmarks de referencia de energía, ver leaderboards de energía LLM. La conexión con el TCO completo está en utilización GPU como FinOps.

Fuentes

arXiv 2504.17674 · Energy Considerations of LLM Inference and Efficiency Optimizations (CMU/Hugging Face, 2025) — https://arxiv.org/pdf/2504.17674
arXiv 2604.11391 · Architectural Trade-offs: power-capping NVIDIA H100 and H200 (FAU Erlangen, 2026) — https://arxiv.org/html/2604.11391v1
arXiv 2512.03024 · TokenPowerBench: Benchmarking the Power Consumption of LLM Inference — https://arxiv.org/pdf/2512.03024
arXiv 2602.09113 · Benchmarking the Energy Savings with Speculative Decoding Strategies — https://arxiv.org/pdf/2602.09113
arXiv 2501.08219 · Characterizing LLM Inference Energy-Performance Tradeoffs across Workloads and GPU Scaling — https://arxiv.org/abs/2501.08219
arXiv 2602.18755 · DualScale: Energy-Efficient Disaggregated LLM Serving via Phase-Aware Placement and DVFS — https://arxiv.org/pdf/2602.18755
arXiv 2508.16449 · GreenLLM: SLO-Aware Dynamic Frequency Scaling for Energy-Efficient LLM Serving — https://arxiv.org/pdf/2508.16449
HAL 05190051 · DVFS-GPT: Dynamic Voltage and Frequency Scaling for Energy-Efficient LLMs — https://hal.science/hal-05190051
arXiv 2308.16369 · SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills — https://arxiv.org/pdf/2308.16369
arXiv 2507.09942 · Green-LLM: Optimal Workload Allocation for Environmentally-Aware Distributed Inference — https://arxiv.org/pdf/2507.09942
arXiv 2505.06371 · The ML.ENERGY Benchmark: Toward Automated Inference Energy Measurement and Optimization — https://arxiv.org/html/2505.06371v1
Zeus Project (ml.energy) — https://ml.energy/zeus/
Zeus · PyTorch blog: Deep Learning Energy Measurement and Optimization — https://pytorch.org/blog/zeus/
Baseten · 33% faster LLM inference with FP8 quantization — https://www.baseten.co/blog/33-faster-llm-inference-with-fp8-quantization/
NVIDIA · Managing Power Capping (DGX H100/H200 User Guide) — https://docs.nvidia.com/dgx/dgxh100-user-guide/power-capping.html
NERSC · GPU Power Capping documentation — https://docs.nersc.gov/jobs/power-capping/
MLCommons · MLPerf Inference v5.1 results — https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
vLLM · Disaggregated Prefill documentation — https://docs.vllm.ai/en/latest/features/disagg_prefill/
Microsoft Research · Characterizing Power Management Opportunities for LLMs in the Cloud (ASPLOS 2024) — https://www.microsoft.com/en-us/research/wp-content/uploads/2024/03/GPU_Power_ASPLOS_24.pdf
EcoInfer (MDPI Electronics) · Optimizing Energy Efficiency with Latency Guarantees Through Iteration-Level GPU Frequency Control — https://doi.org/10.3390/electronics15102139

Power-Capping on lo0 — Blog Técnico

Palancas para gastar menos vatios por token: catálogo cuantificado para inferencia LLM

TL;DR

La identidad de referencia

Tabla maestra: palancas × impacto × coste × herramienta

Palanca 1: cuantización

Mecánica

Coste de calidad

Herramientas OSS

Palanca 2: continuous batching

Mecánica

Herramientas OSS

Palanca 3: power capping

Mecánica

La curva power cap vs throughput (H100 SXM)

Fórmula de J/token con power cap

Comandos

Palanca 4: DVFS (Dynamic Voltage and Frequency Scaling)

Mecánica

Comandos (DVFS manual)

Palanca 5: selección de modelo (SLM, MoE vs denso)

El efecto de la escala

MoE vs denso

Tabla de selección de modelo por caso de uso

Palanca 6: speculative decoding

Mecánica

Condición de eficiencia energética

Herramientas OSS

Palanca 7: prefix caching y chunked prefill

Prefix caching

Chunked prefill (SARATHI)

Palanca 8: scheduling a horas limpias

La curva power cap vs throughput: el sweet spot

Cómo medir el efecto y validar la calidad

Stack de medición

Protocolo de medición por palanca

Validación de calidad

Tabla de decisión Pareto (energía / latencia / calidad)

Apilamiento de palancas: efecto combinado

Hardware de referencia: TDP y rangos de power cap

Resumen ejecutivo por rol

Fuentes