Forge
En desarrolloProyecto personal — un artefacto de serving + benchmarking para Llama 3.1 8B autoalojado (AWQ-INT4 en vLLM). Responde "¿debería autoalojar un LLM OSS en vez de pagar una API comercial?" con una metodología reproducible.
Qué es
Un artefacto de ingeniería enfocado, no un SaaS. Las piezas entregadas:
- Serving — config de vLLM manejada por variables de entorno con continuous batching, KV cache y una API de streaming compatible con OpenAI. Métricas nativas de Prometheus exportadas y scrapeadas en un dashboard de Grafana auto-provisionado.
- Cuantización — receta AWQ-INT4 documentada en
forge/quantization/awq.pycontrameta-llama/Llama-3.1-8B-Instruct, servida con los kernels Marlin de vLLM. - Harness de benchmark — envuelve
vllm bench servecon una traza ShareGPT, barre concurrencia 1/4/16/32/64 (256 prompts por nivel) y escribe JSON estructurado enresults/bench/con la GPU, la versión de vLLM y el SHA del modelo en el metadata de cada registro. - Eval de calidad —
lm-evaluation-harnesscon el tipo de modelolocal-completionsapuntando al endpoint de vLLM en ejecución. Tareas: MMLU (5-shot,acc), GSM8K (5-shot,exact_match), HellaSwag (5-shot,acc_norm). La matemática de retención vive enforge/eval/. - Modelo de costos —
$/1M tokens = gpu_hourly_usd * 1e6 / (3600 * sustained_throughput * utilization). El número principal usa el throughput pico conutilization=1.0; el JSON de comparación de costos junto al gráfico reporta la sensibilidad al 80% de utilización. - Pipeline de gráficos — cinco gráficos canónicos (throughput vs concurrencia, TTFT vs concurrencia, TPOT vs concurrencia, costo por 1M tokens, retención de calidad de cuantización), regenerados desde
results/con un solomake chart. - CI — GitHub Actions corre Ruff + mypy (strict) + pytest en cada PR. Sin jobs de GPU en CI — la reproducción del benchmark es un paso manual, guiado por la metodología, en RunPod.
Por qué lo construí
Para demostrar que puedo servir y optimizar un LLM de código abierto de punta a punta — no solo llamar a una API hosteada. La pregunta interesante no es “¿puede vLLM correr Llama 3.1 8B?” (sí, la documentación lo cubre) — es “¿cómo queda el número defendible de $/1M tokens una vez que se considera la utilización, la latencia p99 y la regresión de calidad por cuantización?” Eso es lo que Forge mide, y rastrea cada número hasta un archivo JSON que podés inspeccionar.
Cómo funciona
La reproducibilidad como restricción de primer orden
La metodología, el hardware, los SHAs del modelo, la versión exacta de vLLM, la receta AWQ y las fechas de las fuentes de precios están commiteados en docs/methodology.md y en el metadata de cada corrida. Cualquiera con el doc de metodología y una cuenta de RunPod puede reproducir los números — ese es el punto del entregable. Las versiones están fijadas en uv.lock, con las dependencias acopladas a la GPU (vLLM, lm-eval, transformers) fijadas por separado en constraints/serve.txt y constraints/eval.txt para que la imagen de CI pueda instalarlas sin GPU.
Gate de ensayo en M1
El mismo shell script que corre el benchmark pago en RunPod corre en modo --rehearsal en un MacBook M1 base contra Qwen/Qwen2.5-0.5B-Instruct. El ensayo debe pasar antes de rentar cualquier GPU paga. Los typos de config, los bugs de parser y las regresiones en el pipeline de gráficos cuestan $0 en M1 en vez de $0.27/hr en una A5000.
Cobertura de tests estratégica
Los tests cubren las utilidades críticas — modelo de costos, parsers de resultados, formateo de datos para gráficos, validadores de config — no los outputs del LLM. El LLM es el sistema bajo prueba; los tests verifican el harness a su alrededor.
Estado
La config de serving, la receta de cuantización, el harness de benchmark, la eval de calidad, el modelo de costos y el pipeline de gráficos están integrados y ensayados de punta a punta en M1 contra un modelo pequeño. La corrida paga en RunPod RTX A5000 que reemplaza cada número ilustrativo por uno medido está en cola; el writeup final del caso de estudio llega una vez que esos números estén disponibles.
Preguntas
¿Qué es Forge?
Forge responde una pregunta con rigor: ¿debería autoalojar un LLM de código abierto en vez de pagar una API comercial? El entregable es una metodología reproducible, un harness de benchmark sobre vllm bench serve, una eval de calidad vía lm-evaluation-harness, un pipeline de gráficos y un modelo de costos. Cada afirmación se rastrea hasta un archivo JSON en results/ cuyo metadata indica la GPU, la versión de vLLM, el SHA del modelo y la fecha.
¿Por qué AWQ-INT4 en vLLM?
AWQ-INT4 con los kernels Marlin nativos de vLLM es el camino INT4 más rápido en vLLM y retiene ~1–2 puntos porcentuales más de calidad que GPTQ en las tareas estándar. vLLM ofrece continuous batching, KV cache, métricas nativas de Prometheus y una API de streaming compatible con OpenAI — el stack que usaría un producto real, no un benchmark sintético.
¿Cómo se mantiene la metodología defendible?
El hardware (RunPod RTX A5000 24 GB a $0.27/hr), los SHAs del modelo (baseline BF16 de meta-llama/Llama-3.1-8B-Instruct y la variante AWQ-INT4 de hugging-quants), la versión de vLLM, la carga de trabajo (traza ShareGPT con concurrencia 1/4/16/32/64, 256 prompts por nivel) y las fechas de las fuentes de precios están todos commiteados en docs/methodology.md y en el JSON de resultados. El pipeline completo se ensaya localmente en un MacBook M1 base contra un modelo pequeño (Qwen 2.5 0.5B) antes de gastar cualquier minuto de GPU pago, así el harness se depura en hardware gratuito.
¿Por qué el gate de ensayo en M1?
El mismo shell script que corre el benchmark real en RunPod corre en modo --rehearsal en M1 contra el modelo pequeño. Ese gate debe pasar antes de rentar cualquier GPU paga. Atrapa un typo de config, un bug de parser o una regresión en el pipeline de gráficos gratis, en vez de a $0.27/hr.