>
Documentation technique
Du défi à l'appel LLM — les principes d'architecture d'AIMOS.
Le défi
Les LLM cloud fonctionnent avec d'énormes fenêtres de contexte sur des clusters de serveurs spécialisés. AIMOS fonctionne sur une seule carte graphique dans votre bureau — et atteint, grâce à des moyens architecturaux, une performance qui non seulement suffit pour les tâches d'entreprise, mais fournit souvent de meilleurs résultats que les modèles cloud surdimensionnés.
Des modèles à 200 milliards de paramètres et 1 million de tokens de contexte sont impressionnants — mais pour des tâches d'entreprise structurées, souvent surdimensionnés. Inversement, le contact client externe exige un modèle plus grand que les requêtes de données internes. AIMOS s'adapte à la tâche.
Cas simples, catégorisation de documents, e-mails de statut. Fonctionne sur une RTX 4060 Ti (16 Go, à partir de 400 €). Avec Multi-Pass Self-Refinement ~80 % de la qualité 27B.
Assistant IA complet, FuSa Safety Manager, analyses complexes. Appels d'outils précis (~86 % BFCL), 33K de contexte avec TurboQuant KV compression. Sur RTX 3090 (24 Go) ou RTX 5090 avec Speculative Decoding (~7× plus rapide).
Les deux tailles de modèle fonctionnent sur la même plateforme AIMOS. Une mise à niveau de 27B vers 70B est possible à tout moment — par simple changement de matériel, sans reconfigurer les agents.
AIMOS ne compense pas la fenêtre de contexte plus petite par du matériel plus puissant — mais par une architecture qui s'assure que l'agent dispose exactement de ce dont il a besoin dans le contexte pour la tâche en cours.
AIMOS compense cela avec sept principes d'architecture, expliqués en détail sur cette page :
Flux de données
Les messages arrivent par différents canaux, sont distribués de manière centralisée et traités par l'agent adapté — sur un GPU partagé.
Principes d'architecture
Chaque principe répond à une limitation concrète de l'exploitation locale — ensemble, ils permettent une aptitude à l'entreprise sur un seul GPU.
Des faits illimités au lieu de tokens de contexte finis
Chaque agent possède sa propre mémoire avec deux mécanismes de recherche : FTS5 (recherche en texte intégral) et MiniLM-L6-v2 (embeddings vectoriels 384 dimensions). Les résultats sont combinés par Reciprocal Rank Fusion — les souvenirs pertinents sont retrouvés même avec des termes de recherche imprécis.
Au lieu de stocker 200 000 tokens d'historique, l'agent retient les faits pertinents — et les retrouve immédiatement avec la bonne question. Le nombre de souvenirs stockés est illimité.
Sécuriser les connaissances avant que le contexte ne soit plein
Non temporisé, mais déclenché par la pression du contexte : lorsque l'historique de conversation dépasse le seuil (12/18/25 messages, selon l'agent), l'orchestrateur lance un cycle Dreaming.
Le LLM analyse l'historique et extrait les faits sous forme de lignes MEM: dans la mémoire à long terme. En parallèle, les fichiers de l'espace de travail (notes, listes de tâches) sont mis à jour via des lignes FILE:.
Ensuite, l'historique est effacé — sans perte d'information. Les rapports hebdomadaires (phase 5) résument en outre l'état tous les 7 jours.
Des spécialistes plutôt que des généralistes
Au lieu de surcharger un agent avec un énorme prompt système, AIMOS répartit les tâches sur plusieurs spécialistes avec des prompts courts et ciblés. Chaque agent n'occupe que 17–22% de sa fenêtre de contexte pour le prompt système — le reste est disponible pour la mémoire, la conversation et la réponse.
Gestion automatique des tokens avant chaque appel LLM
KV-Cache (Key-Value Cache) = la mémoire de travail du modèle linguistique pendant une conversation. Elle contient le prompt système, les souvenirs, l'historique de conversation et les tokens réservés pour la réponse. Plus il reste de VRAM pour le KV-Cache, plus les conversations longues et profondes sont possibles.
Le History-Cap s'adapte dynamiquement : les agents avec un prompt court (17%) conservent jusqu'à 35 messages, les agents avec un prompt long seulement 15. Avant chaque appel LLM, la somme des tokens est vérifiée — si elle dépasse le budget, une réduction automatique est effectuée. Le prompt de l'agent et les définitions d'outils restent toujours intégralement préservés.
Information maximale avec un minimum de tokens
Au lieu d'insérer calendriers, projets et contacts sous forme de texte libre dans le contexte, AIMOS les injecte sous forme de blocs compacts et structurés. Le LLM comprend ces formats avec un minimum de tokens et peut y réagir immédiatement.
Tous les agents partagent un GPU, un modèle
Modèle à 27 milliards de paramètres avec Tool-Calling natif. Les modèles plus petits (<20B) échouent au pilotage fiable des outils — un résultat critique pour la production issu de notre évaluation.
L'orchestrateur détecte les nouveaux messages dans la file d'attente DB, démarre l'agent concerné et s'assure qu'un seul agent occupe le GPU à la fois. La surveillance par heartbeat détecte les processus bloqués (>60s) et libère la VRAM bloquée.
Runtime LLM haute performance avec endpoint API compatible OpenAI. RadixAttention : le cache de préfixes est partagé entre les agents — changement d'agent en millisecondes au lieu de secondes.
Le modèle reste 30 minutes en VRAM. Tous les agents partagent le même modèle — pas de déchargement lors du changement d'agent. La VRAM n'est libérée qu'après 30 minutes d'inactivité.
Fallback automatique pour les tâches complexes
Si une tâche dépasse les capacités du modèle local 27B — ou en cas de timeout — l'agent escalade automatiquement vers un LLM cloud plus puissant (p. ex. Claude Sonnet). L'utilisateur ne remarque rien ; il reçoit toujours une réponse.
Avant l'escalade, le PII-Vault anonymise automatiquement toutes les données personnelles : noms, numéros de téléphone, adresses e-mail, noms d'entreprise. Seule la question nettoyée quitte le réseau. La réponse est re-personnalisée localement. Vos données restent toujours locales.