Forge
Em desenvolvimentoProjeto pessoal — um artefato de serving + benchmarking para Llama 3.1 8B self-hosted (AWQ-INT4 no vLLM). Responde "devo hospedar um LLM open-source em vez de pagar uma API comercial" com uma metodologia reproduzível.
O que é
Um artefato de engenharia focado, não um SaaS. As peças entregues:
- Serving — config do vLLM orientada por variáveis de ambiente com continuous batching, KV cache e uma API de streaming compatível com OpenAI. Métricas nativas do Prometheus exportadas e coletadas num dashboard Grafana provisionado automaticamente.
- Quantização — receita AWQ-INT4 documentada em
forge/quantization/awq.pycontrameta-llama/Llama-3.1-8B-Instruct, servida com os kernels Marlin do vLLM. - Harness de benchmark — encapsula o
vllm bench servecom um trace ShareGPT, varre concorrência 1/4/16/32/64 (256 prompts por nível) e grava JSON estruturado emresults/bench/com a GPU, versão do vLLM e SHA do modelo nos metadados de cada registro. - Eval de qualidade —
lm-evaluation-harnesscom o tipo de modelolocal-completionsapontado para o endpoint vLLM em execução. Tarefas: MMLU (5-shot,acc), GSM8K (5-shot,exact_match), HellaSwag (5-shot,acc_norm). A matemática de retenção fica emforge/eval/. - Modelo de custo —
$/1M tokens = gpu_hourly_usd * 1e6 / (3600 * sustained_throughput * utilization). O número principal usa o throughput de pico comutilization=1.0; o JSON de comparação de custo ao lado do gráfico reporta a sensibilidade a 80% de utilização. - Pipeline de gráficos — cinco gráficos canônicos (throughput vs concorrência, TTFT vs concorrência, TPOT vs concorrência, custo por 1M tokens, retenção de qualidade da quantização), regenerados a partir de
results/com um únicomake chart. - CI — GitHub Actions roda Ruff + mypy (strict) + pytest em todo PR. Sem jobs de GPU no CI — a reprodução do benchmark é um passo manual, orientado pela metodologia, no RunPod.
Por que construí
Para provar que consigo servir e otimizar um LLM open-source de ponta a ponta — não só chamar uma API hospedada. A pergunta interessante não é “o vLLM consegue rodar o Llama 3.1 8B” (sim, a documentação cobre isso) — é “como fica o número defensável de $/1M tokens quando você leva em conta utilização, latência p99 e regressão de qualidade da quantização?” É isso que o Forge mede, e ele rastreia cada número até um arquivo JSON que você pode inspecionar.
Como funciona
Reprodutibilidade como restrição de primeira classe
Metodologia, hardware, SHAs do modelo, versão exata do vLLM, receita AWQ e datas das fontes de preço estão commitados em docs/methodology.md e nos metadados de cada run. Qualquer pessoa com o doc de metodologia e uma conta no RunPod consegue reproduzir os números — esse é o ponto do entregável. As versões são fixadas em uv.lock, com as dependências acopladas à GPU (vLLM, lm-eval, transformers) fixadas separadamente em constraints/serve.txt e constraints/eval.txt para que a imagem de CI possa instalá-las sem GPU.
Gate de ensaio no M1
O mesmo shell script que roda o benchmark pago no RunPod roda em modo --rehearsal num MacBook M1 base contra Qwen/Qwen2.5-0.5B-Instruct. O ensaio precisa passar antes de qualquer GPU paga ser alugada. Erros de config, bugs de parser e regressões no pipeline de gráficos custam $0 no M1 em vez de $0,27/hr num A5000.
Cobertura de testes estratégica
Os testes cobrem os utilitários estruturais — modelo de custo, parsers de resultados, formatação de dados para gráficos, validadores de config — não as saídas do LLM. O LLM é o sistema sob teste; os testes verificam o harness ao redor dele.
Status
A config de serving, receita de quantização, harness de benchmark, eval de qualidade, modelo de custo e pipeline de gráficos estão prontos e ensaiados de ponta a ponta no M1 contra um modelo pequeno. O run pago no RunPod RTX A5000, que substitui cada número ilustrativo por um medido, está na fila; o writeup final do case study vem assim que esses números chegarem.
Perguntas
O que é o Forge?
O Forge responde uma pergunta com rigor — devo hospedar um LLM open-source em vez de pagar uma API comercial? O entregável é uma metodologia reproduzível, um harness de benchmark sobre o vllm bench serve, uma avaliação de qualidade via lm-evaluation-harness, um pipeline de gráficos e um modelo de custo. Cada afirmação remete a um arquivo JSON em results/ cujos metadados identificam a GPU, a versão do vLLM, o SHA do modelo e a data.
Por que AWQ-INT4 no vLLM?
AWQ-INT4 com os kernels Marlin nativos do vLLM é o caminho INT4 mais rápido no vLLM e retém ~1–2 pontos percentuais a mais de qualidade do que GPTQ nas tarefas padrão. O vLLM oferece continuous batching, KV cache, métricas nativas do Prometheus e uma API de streaming compatível com OpenAI — a stack que um produto real usaria, não um benchmark sintético.
Como a metodologia se mantém defensável?
Hardware (RunPod RTX A5000 24 GB a $0,27/hr), SHAs do modelo (baseline BF16 meta-llama/Llama-3.1-8B-Instruct e variante AWQ-INT4 da hugging-quants), versão do vLLM, workload (trace ShareGPT com concorrência 1/4/16/32/64, 256 prompts por nível) e datas das fontes de preço estão todos commitados em docs/methodology.md e no JSON de resultados. O pipeline completo é ensaiado localmente num MacBook M1 base contra um modelo pequeno (Qwen 2.5 0.5B) antes de qualquer minuto de GPU pago, então o harness é depurado em hardware gratuito.
Por que o gate de ensaio no M1?
O mesmo shell script que roda o benchmark real no RunPod roda em modo --rehearsal no M1 contra o modelo pequeno. Esse gate precisa passar antes de qualquer GPU paga ser alugada. Ele pega erro de config, bug de parser ou regressão no pipeline de gráficos de graça, em vez de custar $0,27/hr.