Metodologia para Benchmarking Consistente de LLMs Locais vs na Nuvem

Um desenvolvedor no r/LocalLLaMA detalhou uma metodologia para obter números de benchmark consistentes ao comparar LLMs locais com APIs em nuvem, abordando frustrações comuns com comparações inadequadas devido a diferenças de latência, pontuação e metodologias.

O Problema Central com Benchmarking

Comparações ingênuas que enviam requisições simultaneamente para modelos locais e em nuvem medem coisas diferentes. APIs em nuvem envolvem filas, balanceamento de carga e roteamento. Modelos locais envolvem aquecimento, processamento em lote e contenção de GPU. A solução implementada é usar apenas requisições sequenciais. Embora mais lento — um benchmark de 60 chamadas leva ~3 minutos em vez de 45 segundos — isso garante que cada medição seja limpa, isolando o tempo de inferência do tempo de fila.

A Configuração de Medição

A configuração usa o ZenMux como endpoint unificado, fornecendo uma URL base para quatro modelos: GPT-5.4, Claude Sonnet 4.6, Gemini 3.1 Pro e um Llama 4 quantizado local. A abordagem funciona com qualquer endpoint compatível com OpenAI, como:

• servidor llama.cpp: curl http://localhost:8080/v1/chat/completions ...
• vLLM: curl http://localhost:8000/v1/chat/completions ...
• Ollama: curl http://localhost:11434/v1/chat/completions ...

A chave é usar o mesmo código do cliente, configurações de timeout e lógica de repetição para tudo.

Como a Medição Funciona

O sistema é estruturado em cinco módulos: Config YAML → BenchRunner → AIClient → Analyzer → Reporter.

A configuração YAML define tarefas e modelos. Exemplo:

suite: coding-benchmark
models:
  - gpt-5.4
  - claude-sonnet-4.6
  - gemini-3.1-pro
  - llama-4
runs_per_model: 3
tasks:
  - name: fizzbuzz
    prompt: "Write a Python function that prints FizzBuzz for numbers 1-100"
  - name: refactor-suggestion
    prompt: "Given this code, suggest improvements:\n\ndef calc(x):\n if x == 0: return 0\n if x == 1: return 1\n return calc(x-1) + calc(x-2)"

O BenchRunner toma o produto cartesiano de tarefas × modelos × execuções e chama a API sequencialmente, registrando latência, tokens do prompt e tokens de conclusão.

A Parte da Pontuação

A pontuação de qualidade é baseada em regras, não em LLM-como-juiz, para evitar viés de autopreferência e garantir reprodutibilidade. A função _quality_score usa três sinais:

• Comprimento da resposta: 50–3000 caracteres pontua 4.0, mais curto pontua 1.0, mais longo pontua 3.0.
• Formatação: Presença de marcadores adiciona até 3.0 pontos.
• Presença de código: Detecção de blocos de código ou definições de função adiciona 2.0 pontos.

A pontuação máxima é 9.0. Isso separa de forma confiável "resposta estruturada boa" de "lixo/vazia/alucinada" para classificação relativa. Para latência, o tempo de resposta do percentil 95 (P95) também é calculado.