Retour

LLM Council — Orchestrateur multi-LLM local

Système de consensus multi-LLM local avec Ollama : réponses parallèles → revue anonymisée → synthèse chairman.

Rôle: Démonstration d’ingénierie systèmesDurée: PrototypeStack: Node.js • TypeScript • Ollama • Zod • SQLite • Vite
Local AIDistributed SystemsOllamaZodSQLiteObservabilityLAN Deployment
LLM Council — Orchestrateur multi-LLM local
En bref
  • Problème
    Système de consensus multi-LLM local avec Ollama : réponses parallèles → revue anonymisée → synthèse chairman.
  • Rôle
    Démonstration d’ingénierie systèmes
  • Durée
    Prototype
  • Stack
    Node.js • TypeScript • Ollama • Zod
  • Focus
    Local AI • Distributed Systems • Ollama
  • Résultats
    Un pattern local-first qui transforme les divergences multi-LLM en consensus traçable et auditable sans dépendre du cloud.

Problème

Un seul modèle peut produire des réponses fragiles, biaisées ou inconsistantes. Comparer plusieurs modèles de façon reproductible est difficile, et il est souvent impossible d’expliquer pourquoi un résultat final a été retenu.

Le local-first compte : les données sensibles restent sur la machine, l’inférence fonctionne hors ligne, les coûts sont prévisibles et l’on évite le vendor lock‑in.

Résumé exécutif
  • Inférence locale uniquement (Ollama), aucun appel cloud
  • Contrats JSON/Zod stricts entre services
  • Observabilité + historique de runs pour des démos reproductibles

Contexte

Architecture en bref
Architecture LLM CouncilFlux local de consensus multi-LLM avec orchestrateur, pairs Ollama et synthèse président.UI clientprompt + politiqueOrchestrateurcontrats ZodPairs Ollamavotes anonymisésChairmansynthèse + JSONSQLitehistorique runsHealth/Heartbeatstatut LANLocal uniquementPas d'inférence cloud

Architecture en bref — L’UI envoie un prompt et une politique à l’orchestrateur. Celui-ci distribue vers les pairs Ollama, anonymise, collecte les votes, puis transmet au chairman pour une réponse JSON finale. Health/heartbeat et historique de runs sont stockés localement.

Comment vérifier
  • Quickstart (local)
    npm install
npm --prefix orchestrator install
npm --prefix chairman install
npm --prefix ui install

cp .env.example .env
cp orchestrator/.env.example orchestrator/.env
cp chairman/.env.example chairman/.env
cp ui/.env.example ui/.env

./scripts/run_all_local.sh
open http://localhost:5173
Liens
GitHub repoCaptures UINotes d’architecture

Orchestration multi‑LLM locale avec Ollama et contrats JSON

LLM Council fonctionne en local et coordonne plusieurs modèles via des contrats JSON validés par Zod.

L’inférence reste privée, offline et reproductible.

Pipeline de consensus : revue anonymisée + synthèse chairman

Les réponses sont anonymisées, évaluées, puis classées avant la synthèse finale.

Le processus reste transparent et auditable.

Architecture

  1. Étapes du pipeline (Stage 1 → 3)
    • Stage 1 : réponses indépendantes des membres du council.
    • Stage 2 : revue anonymisée et classement des réponses.
    • Stage 3 : synthèse finale par le chairman avec sortie JSON stricte.
    • Tolérance aux pannes partielles : un pair manquant n’interrompt pas le run.
  2. Frontières de services & contrats
    • L’orchestrateur coordonne, anonymise et persiste les métadonnées.
    • Payloads JSON validés par Zod pour éviter la dérive des API.
    • Run IDs + latences rendent chaque résultat traçable.
  3. Observabilité & run history
    • UI avec timing par étape, état des pairs et synthèse finale.
    • SQLite stocke les runs, classements et exports JSON.

Sécurité / Modèle de menace

  • Inférence locale via Ollama ; aucun appel cloud.
  • Historique SQLite activable/désactivable selon la sensibilité des démos.
  • Pas d’auth/rate limiting par défaut (à ajouter pour un usage LAN partagé).

Résultats

Un pattern local-first qui transforme les divergences multi-LLM en consensus traçable et auditable sans dépendre du cloud.

Stack technique

Node.jsTypeScriptOllamaZodSQLiteVite

FAQ

Pourquoi du local‑first plutôt qu’une API cloud ?

Pour garder les données sensibles sur la machine, fonctionner hors ligne et éviter des coûts variables ou le vendor lock‑in.

L’orchestrateur appelle‑t‑il les LLMs ?

Non. Il coordonne les requêtes et agrège les réponses ; les appels LLM sont faits par les services membres.

Qu’est‑ce qui rend les résultats reproductibles ?

Les contrats JSON/Zod et l’historique SQLite permettent de rejouer et auditer les runs.

Retour aux projetsVoir d’autres études de cas
    LLM Council — Orchestrateur multi-LLM local — Case Study