Architecture
Kisuno tourne dans des conteneurs sur une machine Linux. Cette page montre la structure à grands traits. Elle décrit le chemin que prend une requête et les décisions qui se trouvent derrière, mais non la mise en place dans le détail.
Le flux de données
Section intitulée « Le flux de données »Deux choses y sont essentielles. Premièrement, tout chemin venu de l’extérieur passe par le reverse proxy ; les autres services n’acceptent aucune connexion depuis le réseau. Deuxièmement, les comptes, les conversations et les fichiers restent sur votre serveur, tandis que, pour les réponses des modèles elles-mêmes, le fournisseur est sollicité.
Les couches
Section intitulée « Les couches »Reverse proxy. Le seul point d’entrée depuis l’extérieur. Il termine TLS, s’occupe du certificat et répartit les requêtes vers les services situés derrière.
Application. C’est LibreChat. Le service livre l’interface, sollicite les fournisseurs de modèles, exécute les agents et traite les fichiers téléversés.
Stockage des données. Les comptes, les conversations, les messages, les agents et les journaux se trouvent dans la base de données de l’instance, auxquels s’ajoutent un index de recherche sur vos propres chats et les fichiers téléversés sur le même serveur. La base de données est la source de vérité, l’index de recherche peut en être reconstruit à tout moment.
Les ajouts de Kisuno. Autour de LibreChat se trouvent nos propres services pour l’administration, la gestion des droits et l’aperçu de la consommation, ainsi que le raccordement aux systèmes tiers. Ils ne sont joignables qu’à l’intérieur de l’instance et ne sont pas exposés au réseau.
En dehors de l’instance. Pour les réponses des modèles, le fournisseur d’inférence est sollicité, pour la recherche web des moteurs de recherche externes. Si l’exécution de code est activée, elle tourne dans un environnement propre et séparé, à côté de l’application.
Pourquoi une instance par client
Section intitulée « Pourquoi une instance par client »LibreChat ne connaît pas les mandants. La séparation se situe donc en dessous de l’application : un client est une instance distincte, avec sa propre base de données, son propre index de recherche, ses propres fichiers, sa propre configuration et sa propre clé d’inférence. Que deux instances partagent une machine n’est ensuite qu’une pure question de coûts et de risques.
Ne peuvent être partagées, tout au plus, que des ressources d’exploitation sans lien avec un client. Doivent rester séparés dans tous les cas le stockage des données, la configuration avec toutes ses clés et l’environnement de l’exécution de code. Sinon, ni les données ni les coûts ne se laissent attribuer proprement à chaque client.