Sur cette page : Tableau décisionnel · Modelfile & contexte · Budget mémoire · Acceptation · FAQ · Pour la suite
Les équipes veulent plusieurs personnalités (code, support) sans dupliquer les GGUF ; Ollama lie une base et des ADAPTER, mais le coût dépend du rechargement, du cache KV et de la thermique Apple Silicon. Ce guide donne une matrice (bascule, mémoire, débit vs latence), une discipline de contexte avant swap, et une checklist loyer/egress sur nœud distant. Croisez la matrice llama.cpp vs Ollama, la matrice de routage et LangGraph checkpoint / sandbox pour les mêmes budgets de latence.
1. Multiplier les fichiers sans Modelfile versionné fige des chemins implicites et rend les swaps non reproductibles.
2. Un historique agent « griffonné » gonfle le contexte avant même que le LoRA ne change ; la mémoire unifiée paie la facture.
3. Prouver la perf sur le laptop du développeur sous-estime le coût réel : veille, Wi-Fi et UI mangent la bande passante mémoire.
Tableau décisionnel : bascule, mémoire, débit et latence
Choisissez une ligne par stratégie d’exploitation ; la colonne « bascule » décrit ce qui se passe quand vous changez d’adaptateur, pas le marketing de la fiche technique.
| Stratégie | Mono-base, multi-LoRA (tags Ollama) | VRAM / mémoire unifiée | Débit | Latence |
|---|---|---|---|---|
Hot-swap par tag (ollama create + alias) |
Même FROM, ADAPTER différent par persona ; rechargement adaptateur mesurable. |
Pic lors du swap si le cache KV ne se réutilise pas ; surveiller la pression unifiée. | Élevé si files de prompts homogènes et batch maîtrisé. | TTFT peut grimper si le contexte est trop long ; préférer préfixes stables. |
| Processus parallèles | Un tag par service ; isolation forte, duplication possible des poids. | Coût mémoire multiplié ; utile pour SLA distincts. | Meilleure concurrence si le CPU/GPU suit. | Plus prévisible par file, mais risque de saturation thermique. |
| Repli cloud | Basculer vers le fournisseur quand la base locale déborde. | Soulage la machine locale ; dépend du budget API. | Variable selon région ; files réseau. | Ajout du RTT ; à comparer avec la matrice de routage. |
En revue, alignez labo et prod : écarts typiques = adaptateurs flottants ou num_ctx trop large.
Modelfile & « défragmentation » du contexte
Le Modelfile fixe FROM, ADAPTER, PARAMETER num_ctx et le TEMPLATE. Chaque ollama create doit produire un tag stable (codex-m4 vs support-m4). La « défrag » contextuelle : résumer l’historique bruyant, factoriser le système, éviter les politiques dupliquées — KV plus compact au passage d’un LoRA « code » à un LoRA « conformité ».
# Exemple Modelfile (chemins à adapter) — base unique, adaptateur dédié
FROM ./base-7b-q4_k_m.gguf
ADAPTER ./lora-code-v3.gguf
PARAMETER num_ctx 8192
PARAMETER temperature 0.2
# ollama create codex-m4 -f ./Modelfile.codex
# ollama run codex-m4 "ping"Alignez swaps et timeouts du graphe : changer de tag pendant un tour d’outils impose état minimal ou latence de reprise.
Budget VRAM et mémoire unifiée
Sur Apple Silicon, lisez surtout la pression mémoire globale (Spotlight, navigateurs). Par combinaison base + LoRA : taille GGUF, num_ctx, concurrence, marge thermique ; exigez une capture sous rafale (memory_pressure ou équivalent).
Repères à coller dans le runbook :
- Chaque alias Ollama liste : base, adaptateur, quantification,
num_ctxplafonné et propriétaire de la charge. - Les scénarios agents documentent la longueur d’historique avant résumé automatique.
- Les bascules LoRA incluent un seuil de mémoire au-delà duquel le repli cloud ou une autre machine est obligatoire.
CLI Ollama et séquence d’acceptation (nœud distant)
Les secrets et chemins réels restent dans votre coffre ; les commandes ci-dessous sont des gabarits pour CI ou documentation interne.
# Inventaire et création des tags
ollama list
ollama create codex-m4 -f ./Modelfile.codex
ollama create support-m4 -f ./Modelfile.support
# smoke + charge légère (répéter après chaque swap)
ollama run codex-m4 "résume ce fichier en cinq puces"
ollama run support-m4 "réponds à un ticket fictif"
# Surveiller le service (macOS) pendant le test : charge, mémoire, thermique1. Épingler versions Ollama, chemins GGUF et hashes LoRA dans le dépôt d’infra.
2. Mesurer TTFT et débit après chaque create pour chaque persona ; journaliser les pics de mémoire.
3. Rejouer une session agent complète avec swap milieu de parcours pour valider la reprise.
4. Comparer portable et Mac distant loué : réseau stable, moins de bruit de fond.
5. Tableau de bord : loyer, egress, idle, coût API si repli — même grille que la matrice de routage.
FAQ
Swap LoRA sans coût latence ? Non : rechargement adaptateur + cache ; mesurez sur votre Mac.
Contexte minimal toujours ? Non si résumés et retries bouclent : le coût revient.
Mémoire partagée agents / modèle ? Oui : quotas comme dans LangGraph.
Pour la suite
Figez les preuves sur un Mac mini M4 : accueil, tarifs, achat sans compte, aide, blog technique.
Pages publiques : Accueil, tarifs, achat, aide ; le blog technique liste les articles agents et inférence locale.