Forge

En vivo

Proyecto personal - benchmark de serving con vLLM para Llama 3.1 8B en un RunPod A5000: BF16 a 2,169 tok/s totales, $0.035 por 1M de tokens, y AWQ con 99.4% de calidad promedio.

Rol
Solo - Python, vLLM, benchmarking, infra
Período
may 2026
Stack
  • Python 3.12
  • uv
  • vLLM
  • AWQ-INT4 (Marlin kernels)
  • Llama 3.1 8B
  • lm-evaluation-harness
  • Prometheus
  • Grafana
  • RunPod RTX A5000
  • Matplotlib
  • Ruff
  • mypy (strict)
  • pytest
  • GitHub Actions

Qué es

Un artefacto de ingeniería concreto, no un SaaS. Las piezas entregadas:

  • Serving - configuración de vLLM por variables de entorno con continuous batching, KV cache y una API de streaming compatible con OpenAI, más métricas nativas de Prometheus y provisioning de Grafana.
  • Harness de benchmark - vllm bench serve envuelto sobre un trace de ShareGPT, barriendo concurrencia 1, 4, 16, 32 y 64 con 256 prompts en cada nivel.
  • Comparación de modelos - BF16 meta-llama/Llama-3.1-8B-Instruct versus hugging-quants/Meta-Llama-3.1-8B-Instruct-AWQ-INT4.
  • Evaluación de calidad - lm-evaluation-harness contra el servidor vLLM en ejecución, sobre MMLU, GSM8K y HellaSwag.
  • Modelo de costo - throughput medido convertido en dólares por millón de tokens, comparado con GPT-4o, GPT-4o mini, Claude Sonnet y Claude Haiku.
  • Gráficas y CI - el JSON de resultados alimenta el pipeline de gráficas; el CI cubre parsers, validación de config, cálculo de costos y transformación de datos para gráficas.

Por qué lo construí

Para responder una pregunta de producción con números medidos: ¿conviene autoalojar un modelo abierto en lugar de pagar una API comercial, y la cuantización INT4 mejora la economía en una GPU de 24 GB barata?

Forge responde ambas. BF16 Llama 3.1 8B en el RunPod A5000 fue mucho más barato que las APIs frontier alojadas en costo bruto por token. AWQ-INT4 mantuvo la calidad, pero no mejoró el throughput ni el costo en este setup particular de vLLM/A5000.

Resultado medido

BF16 fue el ganador en throughput. A concurrencia 64, sirvió 2,169 tokens totales por segundo, frente a 1,017 tokens totales por segundo de AWQ-INT4 en el mismo pod A5000.

Gráfica de líneas comparando el throughput total de tokens de BF16 y AWQ en distintos niveles de concurrencia en Forge.
BF16 alcanzó un pico de 2,169 tokens totales por segundo; AWQ alcanzó 1,017.

Latencia dividida por métrica. AWQ tuvo menor p99 de time-to-first-token a alta concurrencia: 508 ms a concurrencia 64 versus 2,822 ms para BF16. BF16 decodificó más rápido: el mean time per output token a concurrencia 64 fue 52.7 ms versus 88.0 ms para AWQ.

Gráfica de líneas comparando el p99 de time to first token para BF16 y AWQ en distintos niveles de concurrencia.
AWQ tuvo menor p99 de TTFT a alta concurrencia en esta corrida.
Gráfica de líneas comparando el mean time per output token para BF16 y AWQ en distintos niveles de concurrencia.
BF16 decodificó más rápido, por eso ganó en throughput y costo.

Costo

A $0.27/hr de cómputo, BF16 costó $0.0346 por 1M de tokens totales al throughput pico medido. AWQ costó $0.0737 por 1M de tokens totales por ser más lento. Frente al precio combinado de GPT-4o de $6.25 por 1M de tokens, los ratios medidos solo de cómputo son aproximadamente 181x más barato para BF16 y 85x más barato para AWQ, antes de storage y overhead operativo.

Gráfica de barras comparando el costo por millón de tokens de BF16 y AWQ en Forge contra precios de APIs comerciales.
Costo por token autoalojado solo de cómputo, usando el throughput medido del A5000.

Calidad

AWQ-INT4 retuvo 99.4% de calidad promedio versus BF16 en las tres tareas de evaluación. Perdió 1.97 puntos porcentuales en MMLU, perdió 0.85 puntos en HellaSwag y ganó 1.52 puntos en GSM8K. Es una retención de calidad suficiente para muchos experimentos de serving, pero el benchmark igual favoreció a BF16 porque AWQ fue más lento.

Gráfica de barras mostrando la retención de calidad de AWQ versus BF16 en GSM8K, HellaSwag, MMLU y el promedio.
AWQ retuvo 99.4% de calidad promedio, pero esa retención no se tradujo en una ventaja de costo aquí.

Cómo funciona

Reproducibilidad como restricción de primer orden

La metodología, el hardware, los IDs de modelo, la configuración exacta de vLLM, la carga de trabajo, las constantes de precios y los resultados generados están commiteados en el repositorio de Forge. Los archivos crudos del benchmark viven en results/bench/full-*, los de evaluación en results/eval/full y los de gráficas en results/charts.

Gate de ensayo en M1

El mismo shell script que corre en RunPod corre localmente en modo ensayo contra Qwen/Qwen2.5-0.5B-Instruct. Eso detecta bugs de parser, config, gráficas y orquestación antes de que empiece el tiempo de GPU pago.

Cobertura de tests estratégica

Los tests cubren las utilidades críticas alrededor del modelo: cálculo de costos, parsers de resultados, transformación de datos para gráficas, validación de config y metadata del benchmark. La salida del modelo en sí se mide en la corrida paga, no se mockea en unit tests.

Estado

Terminado. El milestone principal de Forge está completo: corridas pagas de serving BF16 y AWQ, evaluación de calidad, análisis de costos, gráficas, documentación de metodología y guías de reproducción están entregados. El resultado importante es más acotado y más útil que la suposición original: BF16 autoalojado fue extremadamente barato en el A5000, mientras que AWQ-INT4 fue un éxito en retención de calidad, pero no una mejora de throughput en este setup.

Preguntas

¿Qué es Forge?

Forge es un benchmark de serving completo para Llama 3.1 8B autoalojado. Corre variantes BF16 y AWQ-INT4 en vLLM, barre niveles de concurrencia con prompts estilo ShareGPT, evalúa calidad con lm-evaluation-harness y convierte el throughput medido en costo por millón de tokens.

¿Qué demostró la corrida paga?

BF16 fue el ganador en este setup A5000/vLLM: 2,169 tokens totales por segundo y $0.035 por 1M de tokens. AWQ-INT4 retuvo 99.4% de calidad promedio, pero fue más lento: 1,017 tokens totales por segundo y $0.074 por 1M de tokens.

¿Para qué sirve el resultado de AWQ si fue más lento?

Es un resultado negativo útil. AWQ-INT4 mantuvo la calidad cerca de BF16, pero no produjo la mejora esperada en throughput ni en costo en la configuración medida de RunPod RTX A5000. La página reporta eso directamente, sin convertir la cuantización en una afirmación genérica de mayor velocidad.

¿Cómo se mantiene la metodología defendible?

El hardware, los IDs de modelo, la configuración de vLLM, los niveles de concurrencia, la cantidad de prompts, el JSON crudo del benchmark, el JSON crudo de evaluación y el JSON de gráficas están commiteados en el repositorio de Forge. El pipeline completo se ensaya localmente en M1 antes de usar tiempo de GPU pago.