Mémoire et modèles locaux — explication

De quoi s'agit-il ?

Les agents de Sidekicks utilisent le plus souvent des modèles de langage locaux : un serveur (llmman) charge le modèle dans la mémoire de l'ordinateur, où il reste jusqu'à son déchargement. La machine de développement est un MacBook Air de 32 Go : au-delà de deux petits modèles chargés, la pression mémoire l'arrête. Cette contrainte façonne à la fois l'outillage de test et le produit.

Dans l'outillage

La contrainte reposait sur la mémoire du développeur (« jamais plus de deux agents »). Elle repose désormais sur l'outil : scripts/agents.sh est la seule façon dont le projet démarre un agent de test, et il refuse le troisième. Il décharge aussi le modèle d'un agent quand celui-ci s'arrête, mais seulement si le modèle est réellement chargé — demander à llmman de décharger un modèle absent de la mémoire le chargerait d'abord. Bob et Riker utilisent le même modèle : il est conservé tant que l'un des deux tourne.

Comme la protection vit dans un script qui relaie stdio, elle protège aussi les agents démarrés par un client ACP comme Zed, par le client du spike, et plus tard par les tests de Sidekicks.

Dans le produit

Le même raisonnement s'applique aux personnes qui utiliseront Sidekicks sur leur portable ; l'application l'applique donc (internal/agents, milestone M1 ; ADR 0003) :

les agents démarrent au premier appel, pas à l'ouverture de l'application ;
un agent inutilisé depuis un moment (dix minutes par défaut) est arrêté pour libérer son modèle ;
une limite d'agents simultanés (limits.maxRunningAgents, deux par défaut) fait partie de la configuration. Quand elle est atteinte, l'agent inutilisé depuis le plus longtemps laisse sa place — à condition qu'il soit inactif : un agent en train de répondre n'est jamais interrompu, et le démarrage est alors refusé ;
dans un channel à plusieurs agents, seuls les agents mentionnés répondent, l'un après l'autre par défaut, plutôt que tous à la fois.

Le prix de l'arrêt des agents inactifs est une mémoire d'un autre genre : mm ne sait pas recharger une session, donc un agent redémarré après une pause ne se souvient plus du début de la conversation. Sidekicks le dit dans la conversation (milestone M2) et redonnera le contexte à l'agent avec les channels (issue #25).

Alternatives écartées

Démarrer tous les agents configurés au lancement : simple, et inutilisable avec quatre modèles locaux.
Laisser chaque agent décharger son propre modèle : mm le sait faire (/unload), mais seul Sidekicks sait si un autre agent a encore besoin du même modèle.

Lien avec le reste

Le gestionnaire d'agents qui appliquera ces règles dans l'application est internal/agents (voir Architecture) ; les agents de test eux-mêmes sont présentés dans Comment lancer un agent de test.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


# Mémoire et modèles locaux — explication

## De quoi s'agit-il ?

Les agents de Sidekicks utilisent le plus souvent des modèles de langage **locaux** : un serveur (llmman) charge le modèle dans la mémoire de l'ordinateur, où il reste jusqu'à son déchargement. La machine de développement est un MacBook Air de 32 Go : au-delà de deux petits modèles chargés, la pression mémoire l'arrête. Cette contrainte façonne à la fois l'outillage de test et le produit.

## Dans l'outillage

La contrainte reposait sur la mémoire du développeur (« jamais plus de deux agents »). Elle repose désormais sur l'outil : [`scripts/agents.sh`](../reference/script-agents.md) est la seule façon dont le projet démarre un agent de test, et il refuse le troisième. Il décharge aussi le modèle d'un agent quand celui-ci s'arrête, mais seulement si le modèle est réellement chargé — demander à llmman de décharger un modèle absent de la mémoire le chargerait d'abord. Bob et Riker utilisent le même modèle : il est conservé tant que l'un des deux tourne.

Comme la protection vit dans un script qui relaie stdio, elle protège aussi les agents démarrés par un client ACP comme Zed, par le client du spike, et plus tard par les tests de Sidekicks.

## Dans le produit

Le même raisonnement s'applique aux personnes qui utiliseront Sidekicks sur leur portable ; l'application l'applique donc (`internal/agents`, milestone M1 ; [ADR 0003](../../adr/0003-architecture.md)) :

- les agents démarrent **au premier appel**, pas à l'ouverture de l'application ;
- un agent inutilisé depuis un moment (dix minutes par défaut) est arrêté pour libérer son modèle ;
- une limite d'agents simultanés (`limits.maxRunningAgents`, deux par défaut) fait partie de la [configuration](../reference/configuration.md). Quand elle est atteinte, l'agent inutilisé depuis le plus longtemps laisse sa place — à condition qu'il soit inactif : un agent en train de répondre n'est jamais interrompu, et le démarrage est alors refusé ;
- dans un channel à plusieurs agents, seuls les agents **mentionnés** répondent, l'un après l'autre par défaut, plutôt que tous à la fois.

Le prix de l'arrêt des agents inactifs est une mémoire d'un autre genre : mm ne sait pas recharger une session, donc un agent redémarré après une pause ne se souvient plus du début de la conversation. Sidekicks le dit dans la conversation (milestone M2) et redonnera le contexte à l'agent avec les channels (issue #25).

## Alternatives écartées

- **Démarrer tous les agents configurés au lancement** : simple, et inutilisable avec quatre modèles locaux.
- **Laisser chaque agent décharger son propre modèle** : mm le sait faire (`/unload`), mais seul Sidekicks sait si un autre agent a encore besoin du même modèle.

## Lien avec le reste

Le gestionnaire d'agents qui appliquera ces règles dans l'application est `internal/agents` (voir [Architecture](architecture.md)) ; les agents de test eux-mêmes sont présentés dans [Comment lancer un agent de test](../how-to/lancer-un-agent-de-test.md).