Cradle en tant que service datacenter

Cradle peut être livré comme un service datacenter managé. Plutôt que de louer des GPU, vous vendez un résultat vérifié : le client fournit une tâche et des données, les agents Cradle travaillent sous le système de risque à deux niveaux, un opérateur approuve ou modifie, et le client reçoit une réponse vérifiée avec une piste d'audit complète et des citations de sources.

[tâche + données] ──► [Cradle : triage + agent + RAG] ──► [risque : approuver/modifier/rejeter] ──► [résultat]
                                                          │
                                                          └─► audit : évaluations de risque,
                                                              sources citées, événements de coût

Cela se mappe sur Cradle presque gratuitement : le système de risque à deux niveaux, le journal d'audit et le suivi des coûts existent déjà. La facturation devient un hook sur l'approbation d'un ticket, pas un nouveau sous-système.

Terminologie

Avoir ces termes clairs évite la plupart des confusions :

• Tenant — un client isolé. Chaque tenant a sa propre infrastructure et sa propre base de données ; les tenants ne peuvent pas partager un périmètre. Un tenant est un cradle-server séparé (son propre répertoire de données, base de données, périmètre), pas une ligne dans une table partagée.
• Projet — une subdivision à l'intérieur d'un tenant (ses propres agents, bases de connaissances, tickets, clés). projectId sépare les données dans le périmètre d'un tenant mais ne remplace pas l'isolation entre tenants.
• Topologie — où chaque pièce s'exécute physiquement et qui communique avec qui.

Topologies (du simple au complexe)

T0 — tout sur un seul serveur (départ recommandé)

cradle-server plus un LlamaCppRunner local (CUDA) sur un nœud GPU. Le client est une console légère sur l'API. Le cerveau et l'inférence vivent ensemble. Le moins de nouveau code.

[nœud GPU]
  cradle-server + LlamaCppRunner(CUDA)   ◄──API── [client] (console)
       ▲ trafic connecteur (Telegram / widget / API vers le serveur)

T1 — plan de contrôle séparé du plan de données

Cradle gère un daemon d'inférence sur une machine GPU séparée : cycle de vie et sélection de modèle sur un canal de contrôle, trafic d'inférence sur HTTP. Implémenté comme un module fournisseur remote-gpu plus un contrôleur fin.

[cradle-server]  ──contrôle──► start/stop daemon, load model
        │        ──HTTP─────► generate / embed
        ▼
[GPU box]  llama.cpp-server / vLLM (géré)

T2 — pool GPU partagé + file d'attente

Mise à l'échelle, instances spot, distribution automatique des tâches à travers un pool. C'est le bout avancé du spectre — pas quelque chose à construire avant que T0 ne fonctionne.

Isolation des tenants

Exigence stricte : chaque tenant a sa propre infrastructure et sa propre base de données ; les tenants ne peuvent pas partager un périmètre. L'isolation est donc une instance par tenant — un cradle-server séparé (son propre répertoire de données, base de données, périmètre) par tenant. Une instance partagée avec « projet = tenant » est explicitement exclue, car elle violerait le périmètre.

[périmètre tenant A]              [périmètre tenant B]
  cradle-server  ~/.cradle-A        cradle-server  ~/.cradle-B
    ├─ projet A1                     ├─ projet B1
    └─ projet A2                     └─ ...
  (propre DB, propres clés)         (propre DB, propres clés)

projectId fonctionne à l'intérieur du périmètre d'un tenant : il partitionne les agents, bases de connaissances, tickets et événements de coût, et supporte les clés API scopées et les budgets par projet. L'isolation entre tenants vient d'instances séparées, jamais de projectId.

Pourquoi SQLite, pas Postgres

Sous un modèle d'une instance par tenant, une base SQLite embarquée est un choix délibéré, pas un raccourci :

• Embarquée, pas un service. SQLite vit à l'intérieur du processus cradle-server comme un fichier — pas de daemon séparé, port réseau, rôles DB, ni sauvegarde séparée. « Les données ne quittent jamais le périmètre » devient littéral : un fichier dans le répertoire de données du tenant.
• Recherche vectorielle intégrée. Le RAG fonctionne sur sqlite-vec dans la même base et le même processus. L'équivalent Postgres nécessiterait un serveur pgvector — échangeant « zéro infrastructure » contre un serveur de base de données entier juste pour l'index vectoriel.
• Le profil de charge correspond. Une instance par tenant, triage piloté par l'opérateur (de dizaines à quelques centaines de messages), better-sqlite3 single-writer avec marge. Le goulot d'étranglement est le GPU, pas la base de données.

Postgres devient pertinent uniquement au stade de pool T2, et même là l'isolation par tenant pousse plutôt vers une base par tenant qu'une base unique partagée.

Échelle d'isolation des instances

Le datacenter choisit le niveau d'isolation selon ses exigences de périmètre :

Partage GPU entre instances : une carte entière par tenant (le plus simple), une partition via MIG (A100/H100) ou time-slicing, ou un pool partagé via le fournisseur remote-gpu (T1) pour que les instances de tenant partagent le pool plutôt que le matériel directement.

Modèles de livraison

• Installateur curl — pour les cas ouverts / auto-hébergés avec accès internet.
• Tarball autonome — JS bundle + modules natifs précompilés, pour les réseaux fermés sans registry.
• Image VM — le datacenter garde une image gold avec Cradle Server préinstallé ; le client télécharge uniquement le client et colle les credentials.

Pour parler d'un déploiement managé, contactez-nous. Pour les mécanismes d'installation sous-jacents, voir déploiement serveur distant.