Aller au contenu

Démarrer

De rien à une passerelle

Cinq étapes. Chaque bloc ci-dessous est une vraie sortie — la règle du projet est qu'une affirmation est une mesure ou elle est retirée, et cela vaut aussi pour sa documentation.

  1. 01Installer

    Python 3.10–3.13 et git. Un GPU — un processeur graphique — n'est nécessaire que sur la machine qui sert ; les clients n'en ont pas besoin. 

    git clone https://github.com/warith-harchaoui/ai-bunker.git
cd ai-bunker
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[api]"

  2. 02Savoir ce qu'il vous faut

    Avant d'acheter quoi que ce soit. La réponse la moins chère est souvent la machine que vous avez déjà, qui figure au catalogue à 0 $ pour que « ne rien acheter » soit une option chiffrée plutôt qu'un haussement d'épaules. 

    $ ai-bunker recommend --team 2 --model qwen3-coder-next --vision qwen3-vl-8b

  LOAD MODEL
    each person decodes 25% of a session, 50% of the team is in session at peak
    → 95th percentile of Binomial(2, 0.125) = 2 concurrent sequences
    the machine must sustain 2 sequence(s) above 20 tok/s

  ✔ BUY
      Apple MacBook Pro M2 Max 96GB (existing)
      90 GiB · 400 GB/s · $0
      carries 5 sequences (needs 2) at 20 tok/s each, 27 tok/s alone

    Pourquoi le dimensionnement fonctionne ainsi →

  3. 03Configurer, et vérifier les promesses 

    cp config/gateway.example.yaml config/gateway.yaml
export AI_BUNKER_API_KEY="$(python3 -c 'import secrets; print(secrets.token_urlsafe(32))')"

$ ai-bunker doctor
  [ok  ] charter carries operating rules
  [ok  ] 27 rules loaded
  [ok  ] 247 rule assertions pass
  [ok  ] 100% of rules carry evidence
  [WARN] upstream local answers at http://127.0.0.1:8001/v1   not reachable
  [ok  ] no route leaves this network
  12/14 checks pass

    doctor rapporte ce que le déploiement fait vraiment, y compris qu'une passerelle sans clé d'API — une clé d'interface de programmation — est ouverte à quiconque peut l'atteindre. Ouverte par accident et ouverte exprès se ressemblent vues de dehors ; c'est ce qui les distingue.

  4. 04Servir, et y pointer un client 

    ai-bunker serve                      # localhost:8000

export OPENAI_BASE_URL="http://127.0.0.1:8000/v1"
export OPENAI_API_KEY="$AI_BUNKER_API_KEY"

    C'est toute la configuration client. Tout client qui parle OpenAI reçoit désormais la charte, le moteur de règles et le budget sans avoir été configuré pour.

    Le tableau de bord est sur /gui :

    Le tableau de bord d'ai-bunker dans son thème clair. Un bandeau en haut porte les pastilles « sovereign », « open to anyone who can reach it », « 10 output rules », « 12 command rules » et « 3 tool rules », ainsi qu'un bouton soleil qui bascule vers le thème sombre. En dessous, une barre fine montre le plancher de session en un filet orange sur une fenêtre presque vide, légendée « floor 595 — under 1% of the window » et « 193,120 left to work with ». Une seconde barre, plus large, décompose ce plancher en ses deux composants, la charte à 448 tokens (75 %) et l'index de connaissance à 147 (25 %), tous deux détenus par ai-bunker, et un tableau les reprend avec leurs parts. Un panneau à droite indique 262 144 tokens servis par le moteur, 209 715 déclarés aux clients, une marge de compaction de 16 000 et 193 120 d'espace de conversation, et précise que le compte vient du tokenizer du serveur plutôt que d'une estimation.
    Deux barres plutôt qu'une : un rapport de 300:1 et une composition sont deux questions différentes, et une seule barre ne peut pas porter les deux.

  5. 05Équiper un dépôt 

    $ ai-bunker adopt /chemin/du/projet --list
Adopting ai-bunker into /chemin/du/projet:
  + charter/AGENTS.md   (how to work here, injected every request)
  + charter/packs   (the standards pages, read on demand)
  + charter/rules   (the rules, with their own evidence)
  + opencode.json   (points at the gateway)
  + .opencode/plugins/bounded-reads.js   (the one thing the gateway cannot do)
  + .claude/settings.ai-bunker.json   (merge into .claude/settings.json)
  + CLAUDE.md   (what the gateway does to a session)

    Rien n'est remplacé sans --force. Le kit client est délibérément une configuration et un plugin : tout ce que la passerelle peut voir, elle l'impose, donc un kit ne porte que ce qui se passe avant qu'une requête n'existe — lectures bornées, pas d'injection de skills, seuils de compaction.

Avant d'en dépendre

C'est un 0.2.0-alpha : une porte d'intégration continue (CI) verte, à côté de projets qui ont des années de production. Le filtrage des commandes s'applique au streaming comme à l'atomique — un appel d'outil demandé en fragments est assemblé, jugé par le même chemin de code, et refusé de la même façon — et /health publie quelles garanties sont actives plutôt que de laisser croire qu'elles le sont toutes.

Et ce qui reste ouvert

  • Le comptage bloque la boucle d'événements. La sonde du tokenizer et les comptages eux-mêmes sont des appels synchrones dans des gestionnaires asynchrones : pendant qu'un tourne, la passerelle ne sert personne. C'est borné, pas supprimé ; déplacer ces appels sur un pool de threads est le vrai correctif, et il n'est pas fait. Un déploiement qui attend de la concurrence doit le savoir avant d'en dépendre.
  • Le journal d'audit grossit sans borne. Ajouté, jamais rotaté : la rotation revient à ce qui rotate déjà les journaux sur cette machine, et rien ici ne vous dira que le fichier est gros. L'état en mémoire, lui, est borné, les sessions les plus anciennes évincées d'abord.
  • Le vocabulaire d'outils shell est un défaut, pas une prétention à l'exhaustivité. Une passerelle ne peut pas connaître les noms d'outils de tous les clients, donc SHELL_TOOLS est surchargeable — et un outil qu'elle ne reconnaît pas est une commande qu'elle ne filtre pas.

Une limite que personne ne publie est une limite que quelqu'un découvre. Les bornes chiffrées sont citées une seule fois, là où elles peuvent être vérifiées contre le code : limites assumées, en entier →

Chaque commande, avec sa vraie sortie →