Avanzado 10 minVarios modelos

LLM Council: hacer deliberar a varios modelos locaux

LLM Council es un pequeño proyecto publicado por Andrej Karpathy a finales de 2025: en lugar de enviar una pregunta a un solo modelo, se envía a varios; después, cada uno clasifica las respuestas de los demás sin saber quién las ha escrito, y un modelo «presidente» redacta la síntesis final. El repositorio está pensado para modelos en la nube mediante OpenRouter, pero el patrón cabe en unas cien líneas y se puede adaptar a modelos locales servidos por Ollama. Esta guía explica las tres etapas, muestra cómo reproducirlas en un ordenador personal, detalla cuánto cuesta en memoria y tiempo, y por qué no hay que suponer que el consejo responde mejor que un buen modelo por sí solo.

Por Léa B.·Actualización 2026-10-12·Probado en Windows, macOS y Linux

#LLM Council: el patrón en tres etapas

El repositorio describe un flujo fijo en tres etapas. Cada etapa es una llamada ordinaria a un modelo, sin herramientas ni memoria: el único truco está en la forma en que las salidas de la primera etapa alimentan las dos siguientes.

  1. 01
    Primeras opiniones
    La pregunta del usuario se envía tal cual a cada miembro del consejo, por separado. Cada uno responde sin ver a los demás. En la interfaz original, estas respuestas se muestran en pestañas, una por modelo.
  2. 02
    Revisión y clasificación
    A continuación, cada miembro recibe las respuestas de los demás, anonimizadas (etiquetadas como «Respuesta A», «Respuesta B»...), y debe clasificarlas de la mejor a la peor, juzgando su exactitud y profundidad. La anonimización pretende evitar que un modelo favorezca o perjudique a un competidor conocido.
  3. 03
    Síntesis del presidente
    Un modelo designado como presidente recibe la pregunta, todas las respuestas y todas las clasificaciones, y después redacta la única respuesta final que se presenta al usuario.

Nada de este esquema exige modelos diferentes, pero ese es precisamente su interés: se confía en la diversidad de los entrenamientos para que los errores de un modelo sean detectados por otro. El presidente puede ser uno de los miembros o un modelo aparte, por lo general el más capaz de la lista.

i
Un proyecto de exploración, no un producto
En su mensaje de anuncio, Karpathy presenta LLM Council como un proyecto de fin de semana escrito en gran parte por asistentes de programación, que no tiene previsto mantener. Las impresiones que comparte sobre los modelos que se clasifican bien o mal entre sí son cualitativas y están fechadas. El repositorio no incluye ninguna evaluación cuantitativa: esta guía tampoco añade ninguna.

#Qué contiene el repositorio de Karpathy

El kit Agentes Locales

Agentes que actúan en tu máquina: Cline agéntico, MCP, n8n + Ollama, automatizaciones locales.

  • Espacio en línea de por vida
  • PDF + archivos
  • Actualizaciones de por vida
El kit Agentes Locales →o todos los kits de por vida — 49 € →

El repositorio github.com/karpathy/llm-council es una aplicación web local que se parece a una interfaz de chat clásica. Según su README y sus archivos de configuración en el momento de redactar este texto, se compone de:

Un backend de Python (FastAPI)
En la carpeta backend/: la lógica de las tres etapas, un cliente HTTP para la API de OpenRouter y el almacenamiento de las conversaciones en archivos JSON dentro de una carpeta data/. Las dependencias se gestionan con uv.
Un frontend de React (Vite)
En la carpeta frontend/: la interfaz que muestra las respuestas individuales, las clasificaciones y la síntesis.
Un archivo de configuración
backend/config.py enumera los miembros del consejo (COUNCIL_MODELS) y el presidente (CHAIRMAN_MODEL) en forma de identificadores de OpenRouter, así como la dirección de la API utilizada.
Un script de lanzamiento
start.sh inicia el backend y el frontend juntos. Se espera una clave OPENROUTER_API_KEY en un archivo .env.

Los modelos configurados de forma predeterminada son modelos cloud cerrados (familias GPT, Gemini, Claude y Grok en la versión publicada). Este es el punto que hay que cambiar para una versión local: al resto del código no le importa quién responde, siempre que la API hable el formato «chat completions» popularizado por OpenAI. Revise el README y config.py antes de seguir esta guía; el proyecto puede haber evolucionado desde el 12 de octubre de 2026.

#Requisitos previos para una versión local

Ollama instalado y funcional
El servidor escucha de forma predeterminada en http://localhost:11434. Comprueba con el comando ollama list que tus modelos aparecen.
Tres o cuatro modelos de familias diferentes
Un consejo de modelos de la misma familia pierde el interés de la diversidad. Por ejemplo, apunta a un Qwen, un Llama, un Mistral y un Gemma, de tamaños similares.
Memoria adecuada
En Q4_K_M, calcula aproximadamente 5 GB por modelo 7B y 9 GB por modelo 14B. No es necesario que todos los miembros quepan en la memoria al mismo tiempo, pero la comodidad depende de ello (consulta la sección sobre costes).
Python 3.10 o posterior
Para el script mínimo de esta guía, con el paquete requests. Para el repositorio original, uv y Node.js además.
Patience
Una ronda de deliberación cuesta al menos el doble de generaciones que el número de miembros, más una. No es una herramienta de chat instantáneo.

#Etapa 1: elegir el consejo y el presidente

La elección de los miembros es una cuestión de equilibrio entre diversidad y memoria. El presidente, por su parte, debe leer bien contextos largos: recibe la pregunta, todas las respuestas y todas las clasificaciones, lo que fácilmente representa varios miles de tokens. Para este papel, elige el modelo más capaz que admita tu máquina, aunque sea más lento, porque solo se llama una vez por ronda.

Terminal
# 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

Los tamaños de 7B a 8B son adecuados para los miembros en una tarjeta de 12 GB: uno solo cabe en la memoria dejando margen para el contexto, y Ollama alterna entre ellos. Con 24 GB o un Mac con 48 GB de memoria unificada, puede subir los miembros a 14B o mantener cargados entre dos y tres modelos al mismo tiempo, lo que elimina las recargas.

→
Añade un modelo de razonamiento si puedes
Un miembro capaz de «reflexionar» antes de responder suele aportar un punto de vista diferente al de los modelos directos. En cambio, recuerde desactivar o limitar la fase de reflexión durante la etapa de clasificación; de lo contrario, esta etapa se convierte en la más larga de la ronda.

#Etapa 2: configurar Ollama para varios modelos

Aquí importan dos ajustes de Ollama. El primero es el número de modelos mantenidos en memoria, fijado por la variable OLLAMA_MAX_LOADED_MODELS: si la memoria lo permite, mantener cargados todos los miembros evita volver a cargar uno cada vez que se pasa al siguiente. El segundo es la ventana de contexto, num_ctx, que de forma predeterminada es corta en Ollama: la etapa de clasificación y la síntesis del presidente hacen leer varias respuestas completas, y un contexto demasiado pequeño trunca silenciosamente el principio del prompt.

Terminal (Linux, servicio systemd)
sudo systemctl edit ollama
# puis dans le bloc [Service] :
# Environment="OLLAMA_MAX_LOADED_MODELS=2"
# Environment="OLLAMA_KEEP_ALIVE=30m"
sudo systemctl restart ollama

En macOS, las mismas variables se configuran con launchctl setenv antes de volver a iniciar la aplicación. El valor de OLLAMA_MAX_LOADED_MODELS debe ser coherente con tu memoria: dos modelos 8B en Q4 ya ocupan alrededor de diez GB con su contexto. El contexto, por su parte, se configura por solicitud (campo options.num_ctx de la API) o en un Modelfile derivado; la sección siguiente lo pasa en cada llamada.

!
Paralelismo: secuencial de forma predeterminada
El código original inicia los miembros en paralelo, lo que tiene sentido con API en la nube. En local, enviar cuatro solicitudes simultáneas a cuatro modelos diferentes obliga a Ollama a cargarlos y descargarlos por turnos, e incluso a trasladar una parte al procesador. A menos que todos los miembros quepan en la memoria, llámalos uno tras otro.

#Etapa 3: un consejo mínimo en Python

El script siguiente reproduce las tres etapas del repositorio con la API nativa de Ollama, sin interfaz. Mezcla el orden de las respuestas antes de la clasificación para que las etiquetas no delaten al autor, pide a cada miembro una clasificación breve y luego se lo confía todo al presidente. Adapte los nombres de los modelos a los de su máquina.

council.py
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}")
Terminal
python3 -m venv .venv && source .venv/bin/activate
pip install requests
python council.py "Faut-il un reranker dans un pipeline RAG local ?"

El repositorio original va un poco más allá: extrae la línea de clasificación de cada juez para calcular una posición media por respuesta y mostrarla junto a las pestañas. Puedes añadirla en unas pocas líneas leyendo la línea «CLASIFICACIÓN:» de cada salida. Ten en cuenta que los modelos pequeños no siempre respetan este formato: prevé una alternativa cuando falte la línea.

→
El miembro se juzga a sí mismo
Tanto en este script como en el repositorio, cada juez ve su propia respuesta entre las demás, bajo una etiqueta anónima. Es intencionado: permite comprobar si un modelo reconoce su estilo y se favorece a sí mismo. Si prefieres excluirla, retira su respuesta del bloque que se envía a cada juez, pero las clasificaciones ya no se referirán al mismo conjunto y la media será menos clara.

#Etapa 4: adaptar el repositorio original a Ollama

Si quieres la interfaz web, el camino más corto consiste en utilizar el punto de acceso compatible con OpenAI de Ollama, disponible en http://localhost:11434/v1/chat/completions. El backend del repositorio ya envía solicitudes con ese formato a OpenRouter: en principio basta con sustituir la dirección de la API y los identificadores de los modelos en backend/config.py, y después indicar una clave ficticia, Ollama ignorará la cabecera de autorización.

Terminal
git clone https://github.com/karpathy/llm-council
cd llm-council
uv sync
cd frontend && npm install && cd ..
echo 'OPENROUTER_API_KEY=ollama' > .env
backend/config.py (fragmento que adaptar; comprueba los nombres de las constantes en tu versión)
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"
Terminal
./start.sh
# backend sur le port 8001, interface Vite sur http://localhost:5173 (valeurs du README à vérifier)

Quedan dos puntos que deben tratarse manualmente. Primero, el contexto: el punto de acceso compatible con OpenAI no tiene un campo num_ctx, por lo que hay que crear variantes de modelos con un Modelfile que fije el contexto o cambiar el cliente a la API nativa /api/chat, que acepta opciones. Después, el paralelismo mencionado anteriormente: la primera etapa inicia las llamadas al mismo tiempo, lo que equivale a pasar a modo secuencial si sus miembros no caben todos en la memoria.

Terminal (variante con contexto fijado)
cat > Modelfile.qwen-council <<'EOF'
FROM qwen3:8b
PARAMETER num_ctx 16384
EOF
ollama create qwen3-council -f Modelfile.qwen-council

Varios forks comunitarios han realizado estas modificaciones para Ollama o para otros servidores locales. Antes de adoptar uno, comprueba la fecha del último commit, el número de archivos afectados con respecto al repositorio original y lee el código que llama al modelo: es corto, y ahí es donde se encuentran las diferencias. Esta guía no recomienda ningún fork en particular; su estado cambia demasiado rápido.

#Coste en memoria y tiempo

El cálculo es sencillo y merece la pena plantearlo antes de comprometerse. Para una deliberación de N miembros, una ronda completa requiere N generaciones en la etapa 1, N generaciones en la etapa 2 y una para el presidente, es decir, 2N + 1 llamadas. Las llamadas de la etapa 2 y la del presidente tardan más en procesarse que la primera, porque el prompt contiene todas las respuestas: el tiempo de lectura del prompt se suma al tiempo de generación.

Tres miembros
Siete generaciones por pregunta. Si cada respuesta tarda del orden de medio minuto en su máquina, una ronda supera los tres minutos, sin contar las recargas.
Memoria mínima
El modelo más grande del consejo más su contexto. Con miembros 8B en Q4 y un contexto de 16 000 tokens, una tarjeta de 12 GB es suficiente, siempre que solo se mantenga un modelo cargado.
Memoria para funcionar con holgura
Todos los miembros cargados al mismo tiempo: la suma de sus tamaños, más una caché de contexto por modelo. Tres modelos 8B en Q4 requieren una GPU de 24 GB o un Mac con 32 GB de memoria unificada como mínimo.
Rechargements
Cuando los miembros no caben juntos, cada cambio de modelo cuesta unos segundos de carga desde el disco. En una ronda, esto ocurre hasta 2N veces. Un SSD NVMe hace soportable este coste; un disco lento lo vuelve molesto.

Estas magnitudes dependen de tu hardware, de la cuantización y de la longitud de las respuestas: no hemos medido el tiempo de una ronda para este artículo y las cifras anteriores son reglas de cálculo, no resultados. Para evaluar tu caso, cronometra una generación sencilla con cada uno de tus miembros y aplica la fórmula.

#Limitaciones y sesgos del consejo

El patrón resulta atractivo porque se parece a una revisión por pares. Sin embargo, hay que resistirse a la idea de que necesariamente es más preciso que un buen modelo por sí solo: el repositorio no aporta ninguna medición en ese sentido, y varios sesgos conocidos de los modelos que juzgan juegan en su contra.

Anonimización imperfecta
Las etiquetas ocultan el nombre, no el estilo. Un modelo puede reconocer su propia forma de escribir, o la de una familia que conoce, y clasificar en consecuencia. El propio Karpathy señala, de forma cualitativa, que los modelos a menudo han preferido la respuesta de otro a la suya: es una observación, no una garantía.
Sesgo de posición y longitud
Los trabajos sobre modelos jueces, por ejemplo el artículo MT-Bench de Zheng et al. (2023), documentan una preferencia por la primera respuesta leída y por las respuestas largas. Mezclar el orden atenúa el primer sesgo; el segundo se corrige mal.
Errores correlacionados
Los modelos entrenados con corpus similares suelen equivocarse de la misma manera. Un consejo de modelos pequeños puede votar por unanimidad a favor de una respuesta falsa, y el presidente la conservará.
El presidente se queda solo
La síntesis depende por completo del modelo presidente: si alucina, el consejo no cambia nada. Lea las respuestas individuales cuando el tema sea importante; de hecho, ese es el interés de las pestañas de la interfaz original.
Modelos pequeños, instrucciones largas
El prompt de clasificación es exigente: leer tres o cuatro textos, juzgar, justificar y respetar un formato. Por debajo de 7B, las salidas se vuelven irregulares y la clasificación media pierde su sentido.
!
Sin medición, sin promesas
Si quiere saber si el consejo mejora sus resultados, construya un pequeño conjunto de preguntas cuyas respuestas conozca, ejecute primero el mejor modelo por separado y luego el consejo, y compare a ciegas. Sin esta prueba con sus propios casos, la intuición de que «varias opiniones valen más que una» no es más que una hipótesis.

#Casos de uso reales de un LLM Council local

El coste adicional de 2N + 1 generaciones se justifica cuando la pregunta es poco frecuente e importante, no para charlas triviales. Entre las personas que han adoptado el patrón localmente destacan tres situaciones.

Revisión de un texto o código sensible
Una carta contractual, un procedimiento, una función crítica: los miembros detectan problemas diferentes y el presidente los consolida en una lista. Aquí, la clasificación importa menos que la diversidad de las observaciones.
Decisión técnica fundamentada
«¿Hay que migrar esta base de datos?», «¿qué formato usar para esta exportación?»: las respuestas divergentes son información en sí mismas. Pide al presidente que haga visibles los desacuerdos en lugar de suavizarlos.
Control de calidad de un solo modelo
Usar el consejo como jurado para comparar dos versiones de un prompt o dos cuantizaciones del mismo modelo, pidiéndole que clasifique salidas que haya producido en otro lugar. Es una aplicación directa de la etapa 2, sin la etapa 1.

En todos estos casos, la privacidad es el verdadero argumento a favor de la versión local: los documentos revisados no salen de la máquina, mientras que la versión original los envía a cuatro proveedores diferentes mediante OpenRouter. Eso es lo que hace interesante el patrón para un equipo que trabaja con datos internos, siempre que acepte los minutos de espera.

#Solución de problemas

La clasificación ignora una respuesta
El contexto es demasiado corto y el principio del prompt ha quedado truncado. Aumente num_ctx (o el Modelfile) y compruebe en los registros de Ollama que no aparezca ningún aviso de truncamiento.
Las llamadas de la etapa 1 son muy lentas
Los miembros se invocan en paralelo y compiten por la memoria. Cambie a modo secuencial o reduzca el consejo a lo que quepa simultáneamente en la VRAM.
El presidente responde sin venir a cuento
Su contexto es el más cargado de la ronda. Dale un modelo más grande o resume las clasificaciones antes de transmitírselas.
Falta el formato de clasificación
Los modelos pequeños olvidan la línea «CLASIFICACIÓN:». Recuerde el formato al final del prompt, baje la temperatura o acepte una lectura manual de las justificaciones.
Respuestas de un miembro vacías o en inglés
Comprueba que el modelo no devuelva únicamente su fase de razonamiento y especifica en la pregunta el idioma esperado.
Memoria saturada después de unas cuantas rondas
OLLAMA_MAX_LOADED_MODELS demasiado alto para la máquina. Redúcelo a 1 y deja que Ollama se turne.

#Para ir más allá

LLM Council es un patrón de deliberación, no un marco de agentes: no gestiona herramientas, roles ni memoria. Si sus necesidades van más allá de la síntesis de opiniones, estas guías del sitio cubren los componentes relacionados.

CrewAI con Ollama
Cuando los modelos deben repartirse los roles y encadenar tareas en lugar de juzgar una misma respuesta. https://quelllm.fr/guide/crewai-ollama-multi-agents
LiteLLM como pasarela local
Para exponer varios servidores de modelos detrás de una única API compatible con OpenAI, por ejemplo un consejo distribuido entre dos máquinas. https://quelllm.fr/guide/litellm-proxy-gateway-local
Arquitectura de un agente de IA local
Los componentes que se ensamblan alrededor de un modelo cuando se quiere dotarlo de herramientas y memoria. https://quelllm.fr/guide/agent-ia-local-architecture
Compartir un servidor Ollama en la red local
Alojar los miembros del consejo en una máquina más potente y llamarlos desde su equipo. https://quelllm.fr/guide/ollama-serveur-reseau-local-partage

Guía redactada el 12 de octubre de 2026 a partir del repositorio de GitHub de Karpathy y de la documentación de Ollama. No se ha realizado ninguna medición de tiempo ni de calidad para este artículo; las referencias de memoria son órdenes de magnitud en Q4_K_M. Los nombres de las constantes, los puertos y los modelos evolucionan: vuelve a leer las fuentes siguientes antes de copiar los comandos.

¿Esta guía te ha ayudado?

¿Un comentario, un error, una precisión? Avísanos, eso mejora la guía para todos.