LLM Council: fazendo vários modelos deliberarem locaux

#LLM Council: o padrão em três etapas

O repositório descreve um fluxo fixo em três etapas. Cada etapa é uma chamada de modelo comum, sem ferramenta nem memória: o único truque está na forma como as saídas da primeira etapa alimentam as duas seguintes.

1. 01
   Primeiras opiniões

   A pergunta do usuário é enviada exatamente como está a cada membro do conselho, separadamente. Cada um responde sem ver os outros. Na interface original, essas respostas são exibidas em abas, uma por modelo.
2. 02
   Revisão e classificação

   Em seguida, cada membro recebe as respostas dos outros, anonimizadas (rotuladas como « Resposta A », « Resposta B »...), e deve classificá-las da melhor à pior, avaliando a correção e a profundidade. A anonimização busca evitar que um modelo favoreça ou prejudique um concorrente conhecido.
3. 03
   Síntese do presidente

   Um modelo designado como presidente recebe a pergunta, todas as respostas e todas as classificações, e então redige a única resposta final apresentada ao usuário.

Nada nesse esquema exige modelos diferentes, mas esse é justamente o interesse: contamos com a diversidade dos treinamentos para que os erros de um modelo sejam identificados por outro. O presidente pode ser um dos membros ou um modelo separado, geralmente o mais capaz da lista.

#O que o repositório de Karpathy contém

O repositório github.com/karpathy/llm-council é uma aplicação web local que se parece com uma interface de chat clássica. De acordo com o README e os arquivos de configuração no momento da redação, ele é composto por:

Um backend em Python (FastAPI)

Na pasta backend/: a lógica das três etapas, um cliente HTTP para a API da OpenRouter e o armazenamento das conversas em arquivos JSON em uma pasta data/. As dependências são gerenciadas com uv.

Um frontend React (Vite)

Na pasta frontend/: a interface que exibe as respostas individuais, as classificações e a síntese.

Um arquivo de configuração

backend/config.py lista os membros do conselho (COUNCIL_MODELS) e o presidente (CHAIRMAN_MODEL) na forma de identificadores do OpenRouter, além do endereço da API chamada.

Um script de inicialização

start.sh inicia o backend e o frontend juntos. Uma chave OPENROUTER_API_KEY é esperada em um arquivo .env.

Os modelos configurados por padrão são modelos de nuvem fechados (famílias GPT, Gemini, Claude e Grok na versão publicada). Esse é o ponto a alterar para uma versão local: o restante do código não se importa com quem responde, desde que a API use o formato « chat completions » popularizado pela OpenAI. Leia novamente o README e o config.py antes de seguir este guia; o projeto pode ter evoluído desde 12 de outubro de 2026.

#Pré-requisitos para uma versão local

Ollama instalado e funcionando

O servidor escuta por padrão em http://localhost:11434. Verifique com o comando ollama list se seus modelos aparecem.

Três a quatro modelos de famílias diferentes

Um conselho de modelos da mesma família perde o benefício da diversidade. Busque, por exemplo, um Qwen, um Llama, um Mistral e um Gemma, com tamanhos semelhantes.

Memória adequada

Em Q4_K_M, considere cerca de 5 GB por modelo 7B e 9 GB por modelo 14B. Os membros não precisam estar todos na memória ao mesmo tempo, mas o conforto depende disso (consulte a seção sobre custos).

Python 3.10 ou superior

Para o script mínimo deste guia, com o pacote requests. Para o repositório original, uv e Node.js também.

Patience

Uma rodada do conselho custa pelo menos o dobro de gerações do número de membros, mais uma. Não é uma ferramenta de chat instantâneo.

#Etapa 1: escolher o conselho e o presidente

A escolha dos membros é uma questão de equilíbrio entre diversidade e memória. Já o presidente precisa, sobretudo, ler bem contextos longos: ele recebe a pergunta, todas as respostas e todas as classificações, o que facilmente representa vários milhares de tokens. Para essa função, escolha o modelo mais capaz que sua máquina suporte, mesmo que seja mais lento, pois ele é chamado apenas uma vez por rodada.

# Exemple de conseil pour une carte 12 Go (noms à vérifier avec `ollama search` ou sur ollama.com/library)
ollama pull qwen3:8b
ollama pull llama3.1:8b
ollama pull mistral:7b
ollama pull gemma3:12b   # président : plus gros, appelé une seule fois par tour
ollama list

Os tamanhos de 7B a 8B são adequados para os membros em uma placa de 12 GB: um único modelo cabe na memória com margem para o contexto, e Ollama alterna entre eles. Com 24 GB ou um Mac com 48 GB de memória unificada, você pode aumentar os membros para 14B ou manter dois a três modelos carregados ao mesmo tempo, eliminando os recarregamentos.

#Etapa 2: configurar Ollama para vários modelos

Duas configurações de Ollama são importantes aqui. A primeira é o número de modelos mantidos na memória, definido pela variável OLLAMA_MAX_LOADED_MODELS: se a memória permitir, manter todos os membros carregados evita recarregá-los a cada troca. A segunda é a janela de contexto, num_ctx, que por padrão é curta em Ollama: a etapa de classificação e a síntese do presidente fazem com que várias respostas completas sejam lidas, e um contexto pequeno demais trunca silenciosamente o início do prompt.

sudo systemctl edit ollama
# puis dans le bloc [Service] :
# Environment="OLLAMA_MAX_LOADED_MODELS=2"
# Environment="OLLAMA_KEEP_ALIVE=30m"
sudo systemctl restart ollama

No macOS, as mesmas variáveis são definidas com launchctl setenv antes de reiniciar o aplicativo. O valor de OLLAMA_MAX_LOADED_MODELS deve permanecer coerente com sua memória: dois modelos 8B em Q4 já ocupam cerca de dez Go com o contexto. O contexto, por sua vez, é configurado por requisição (campo options.num_ctx da API) ou em um Modelfile derivado; a seção seguinte o transmite a cada chamada.

#Etapa 3: um conselho mínimo em Python

O script abaixo reproduz as três etapas do conselho usando a API nativa do Ollama, sem interface. Ele mistura a ordem das respostas antes da classificação para que os rótulos não revelem o autor, pede a cada membro uma classificação curta e depois entrega tudo ao presidente. Adapte os nomes dos modelos aos da sua máquina.

import random
import requests

OLLAMA = "http://localhost:11434/api/chat"
COUNCIL = ["qwen3:8b", "llama3.1:8b", "mistral:7b"]
CHAIRMAN = "gemma3:12b"
NUM_CTX = 16384


def ask(model, prompt):
    r = requests.post(OLLAMA, json={
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "stream": False,
        "options": {"num_ctx": NUM_CTX, "temperature": 0.3},
    }, timeout=1800)
    r.raise_for_status()
    return r.json()["message"]["content"].strip()


def council(question):
    # Étape 1 : premières opinions, une par membre, sans se voir
    answers = {m: ask(m, question) for m in COUNCIL}

    # Anonymisation : ordre mélangé, étiquettes A, B, C...
    order = list(COUNCIL)
    random.shuffle(order)
    labels = {m: chr(65 + i) for i, m in enumerate(order)}
    packed = "\n\n".join(
        f"### Réponse {labels[m]}\n{answers[m]}" for m in order
    )

    # Étape 2 : chaque membre classe les réponses (les siennes incluses)
    rankings = {}
    for m in COUNCIL:
        rankings[m] = ask(m,
            f"Question : {question}\n\n{packed}\n\n"
            "Classe ces réponses de la meilleure à la moins bonne selon leur "
            "justesse et leur profondeur. Pour chacune, une ligne de justification. "
            "Termine par la ligne 'CLASSEMENT :' suivie des lettres dans l'ordre.")

    # Étape 3 : le président rédige la synthèse finale
    votes = "\n\n".join(
        f"### Avis du juge {labels[m]}\n{rankings[m]}" for m in COUNCIL
    )
    final = ask(CHAIRMAN,
        f"Question : {question}\n\n{packed}\n\n{votes}\n\n"
        "Tu présides ce conseil. En t'appuyant sur les réponses et les classements, "
        "rédige une réponse finale unique, précise et sans redite. Signale les points "
        "sur lesquels les réponses se contredisent.")
    return answers, labels, rankings, final


if __name__ == "__main__":
    import sys
    q = " ".join(sys.argv[1:]) or "Quelle quantification choisir pour un modèle 14B sur 12 Go de VRAM ?"
    answers, labels, rankings, final = council(q)
    for m in COUNCIL:
        print(f"\n===== {m} (Réponse {labels[m]}) =====\n{answers[m]}")
    for m in COUNCIL:
        print(f"\n===== Classement par {m} =====\n{rankings[m]}")
    print(f"\n===== Synthèse ({CHAIRMAN}) =====\n{final}")

python3 -m venv .venv && source .venv/bin/activate
pip install requests
python council.py "Faut-il un reranker dans un pipeline RAG local ?"

O repositório original vai um pouco além: ele extrai a linha de classificação de cada avaliador para calcular uma posição média por resposta e exibi-la ao lado das abas. Você pode adicioná-la em algumas linhas lendo a linha « CLASSIFICAÇÃO: » de cada saída. Tenha em mente que os modelos pequenos nem sempre respeitam esse formato: preveja uma alternativa quando a linha estiver ausente.

#Etapa 4: adaptar o repositório original para Ollama

Se você quiser a interface web, o caminho mais curto é usar o endpoint compatível com OpenAI de Ollama, servido em http://localhost:11434/v1/chat/completions. O backend do repositório já envia requisições nesse formato para o OpenRouter: em princípio, basta substituir o endereço da API e os identificadores dos modelos em backend/config.py e depois informar uma chave fictícia, Ollama ignorando o cabeçalho de autorização.

git clone https://github.com/karpathy/llm-council
cd llm-council
uv sync
cd frontend && npm install && cd ..
echo 'OPENROUTER_API_KEY=ollama' > .env

COUNCIL_MODELS = [
    "qwen3:8b",
    "llama3.1:8b",
    "mistral:7b",
]
CHAIRMAN_MODEL = "gemma3:12b"

# Ollama expose une API compatible OpenAI sur /v1
OPENROUTER_API_URL = "http://localhost:11434/v1/chat/completions"

./start.sh
# backend sur le port 8001, interface Vite sur http://localhost:5173 (valeurs du README à vérifier)

Dois pontos ainda precisam ser tratados manualmente. Primeiro, o contexto: o endpoint compatível com a OpenAI não tem o campo num_ctx; portanto, é preciso criar variantes dos modelos com um Modelfile que fixe o contexto ou mudar o cliente para a API nativa /api/chat, que aceita opções. Depois, o paralelismo mencionado acima: a primeira etapa inicia as chamadas ao mesmo tempo, o que exige passar para o modo sequencial se os seus membros não couberem todos na memória.

cat > Modelfile.qwen-council <<'EOF'
FROM qwen3:8b
PARAMETER num_ctx 16384
EOF
ollama create qwen3-council -f Modelfile.qwen-council

Vários forks da comunidade fizeram essas modificações para Ollama ou para outros servidores locais. Antes de adotar um deles, verifique a data do último commit, o número de arquivos alterados em relação ao repositório original e leia o código que chama o modelo: ele é curto, e é ali que ficam as diferenças. Este guia não recomenda nenhum fork específico; o estado deles muda rápido demais.

#Custo de memória e tempo

A conta é simples e vale a pena apresentá-la antes de começar. Para um conselho de N membros, uma rodada completa exige N gerações na etapa 1, N gerações na etapa 2 e uma para o presidente, ou seja, 2N + 1 chamadas. As chamadas da etapa 2 e a do presidente são mais demoradas para processar que a primeira, porque o prompt contém todas as respostas: o tempo de leitura do prompt se soma ao tempo de geração.

Três membros

Sete gerações por pergunta. Se cada resposta levar cerca de meio minuto na sua máquina, uma rodada ultrapassará três minutos, sem contar os recarregamentos.

Memória mínima

O maior modelo do conselho mais o contexto dele. Com membros 8B em Q4 e um contexto de 16 000 tokens, uma placa de 12 GB dá conta, desde que apenas um modelo permaneça carregado.

Memória para uso confortável

Todos os membros carregados ao mesmo tempo: a soma dos tamanhos deles, mais um cache de contexto por modelo. Três modelos 8B em Q4 exigem uma GPU de 24 GB ou um Mac com 32 GB de memória unificada, no mínimo.

Rechargements

Quando os membros não cabem juntos, cada troca de modelo custa alguns segundos de carregamento a partir do disco. Em uma rodada, isso acontece até 2N vezes. Um SSD NVMe torna esse custo suportável; um disco lento o torna incômodo.

Essas ordens de grandeza dependem do seu hardware, da quantização e do tamanho das respostas: não medimos o tempo de uma rodada para este artigo, e os números acima são regras de cálculo, não resultados. Para avaliar seu caso, cronometre uma geração simples com cada um dos seus membros e aplique a fórmula.

#Limitações e vieses do conselho

O padrão é atraente porque se parece com uma revisão por pares. Ainda assim, é preciso resistir à ideia de que ele é necessariamente mais preciso do que um bom modelo sozinho: o repositório não apresenta nenhuma medição nesse sentido, e vários vieses conhecidos dos modelos avaliadores jogam contra ele.

Anonimização imperfeita

Os rótulos ocultam o nome, não o estilo. Um modelo pode reconhecer seu próprio modo de escrever, ou o de uma família que conhece, e classificar de acordo. O próprio Karpathy observa, de forma qualitativa, que os modelos muitas vezes preferiram a resposta de outro à própria: isso é uma observação, não uma garantia.

Viés de posição e de extensão

Os trabalhos sobre modelos avaliadores, como o artigo MT-Bench de Zheng et al. (2023), documentam uma preferência pela primeira resposta lida e por respostas longas. Misturar a ordem atenua o primeiro viés; o segundo é difícil de corrigir.

Erros correlacionados

Modelos treinados com corpora semelhantes frequentemente cometem os mesmos erros. Um conselho de modelos pequenos pode votar por unanimidade em uma resposta errada, e o presidente irá escolhê-la.

O presidente permanece sozinho

A síntese depende inteiramente do modelo presidente: se ele alucinar, o conselho não poderá fazer nada. Leia as respostas individuais quando o assunto for importante; esse é, aliás, o propósito das abas da interface original.

Modelos pequenos, instruções longas

O prompt de classificação é exigente: ler três ou quatro textos, avaliar, justificar e respeitar um formato. Abaixo de 7B, as saídas se tornam irregulares e a classificação média perde o sentido.

#Casos de uso reais de um LLM Council local

O custo adicional de 2N + 1 gerações se justifica quando a pergunta é rara e importante, não para conversa fiada. Três situações se destacam entre as pessoas que adotaram o padrão localmente.

Revisão de um texto ou código sensível

Uma correspondência contratual, um procedimento, uma função crítica: os membros identificam problemas diferentes, e o presidente os consolida em uma lista. Aqui, a classificação importa menos do que a diversidade das observações.

Decisão técnica fundamentada

« Devemos migrar este banco de dados », « qual formato para esta exportação »: as respostas divergentes são uma informação por si só. Peça ao presidente que torne as discordâncias visíveis em vez de suavizá-las.

Controle de qualidade de um único modelo

Usar o conselho como júri para comparar duas versões de um prompt ou duas quantizações do mesmo modelo, pedindo que ele classifique saídas produzidas por você em outro lugar. É uma aplicação direta da etapa 2, sem a etapa 1.

Em todos esses casos, a privacidade é o verdadeiro argumento a favor da versão local: os documentos analisados não saem da máquina, enquanto a versão original os envia a quatro fornecedores diferentes por meio do OpenRouter. É isso que torna o padrão interessante para uma equipe que trabalha com dados internos, desde que aceite os minutos de espera.

#Solução de problemas

A classificação ignora uma resposta

O contexto é curto demais e o início do prompt foi truncado. Aumente num_ctx (ou o Modelfile) e verifique nos logs do Ollama se não aparece nenhum aviso de truncamento.

As chamadas da etapa 1 estão muito lentas

Os membros são chamados em paralelo e competem pela memória. Passe para o modo sequencial ou reduza o conselho ao que couber simultaneamente na VRAM.

O presidente responde outra coisa

O contexto dele é o mais carregado da rodada. Dê a ele um modelo maior ou resuma as classificações antes de transmiti-las a ele.

Formato de classificação ausente

Os modelos pequenos esquecem a linha « CLASSEMENT: ». Relembre o formato no fim do prompt, reduza a temperatura ou aceite uma leitura manual das justificativas.

Respostas de um membro vazias ou em inglês

Verifique se o modelo não retorna apenas sua fase de raciocínio e especifique no prompt o idioma esperado.

Memória saturada depois de algumas rodadas

OLLAMA_MAX_LOADED_MODELS alto demais para a máquina. Reduza-o para 1 e deixe Ollama alternar.

#Para se aprofundar

LLM Council é um padrão de deliberação, não um framework de agentes: ele não gerencia ferramentas, funções nem memória. Se sua necessidade vai além da síntese de opiniões, estes guias do site abordam os componentes relacionados.

CrewAI com Ollama

Quando os modelos precisam dividir funções e encadear tarefas, em vez de julgar a mesma resposta. https://quelllm.fr/guide/crewai-ollama-multi-agents

LiteLLM como gateway local

Para expor vários servidores de modelos por trás de uma única API compatível com a OpenAI, por exemplo, um conselho distribuído em duas máquinas. https://quelllm.fr/guide/litellm-proxy-gateway-local

Arquitetura de um agente de IA local

Os componentes a serem combinados em torno de um modelo quando se quer dar a ele ferramentas e memória. https://quelllm.fr/guide/agent-ia-local-architecture

Compartilhar um servidor Ollama na rede local

Hospedar os membros do conselho em uma máquina maior e chamá-los a partir do seu computador. https://quelllm.fr/guide/ollama-serveur-reseau-local-partage

Guia redigido em 12 de outubro de 2026 com base no repositório GitHub de Karpathy e na documentação de Ollama. Nenhuma medição de tempo ou qualidade foi realizada para este artigo; as referências de memória são ordens de grandeza em Q4_K_M. Os nomes de constantes, portas e modelos mudam: leia novamente as fontes abaixo antes de copiar os comandos.

• Repositório GitHub karpathy/llm-council (README, backend/config.py, start.sh)
• Documentação Ollama (API nativa /api/chat, compatibilidade com OpenAI, variáveis de ambiente)
• Zheng et al., 2023: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (viés dos modelos avaliadores)