Requirements pour le Déploiement de Devana.ai

Version: 1.1 Date: Novembre 2025 Audience: Architectes d'entreprise, DevOps, Décideurs IT

📑 Table des matières

1. Vue d'ensemble
2. Architecture de la plateforme
3. Requirements Matériels
   • Configuration minimale
   • Configuration production
   • Configuration entreprise
4. Requirements LLM & Embeddings
   • Scénario 1 : Cloud Providers
   • Scénario 2 : Auto-hébergé
   • Scénario 3 : Hybride
   • Scénario 4 : Clusters Mac
5. Requirements Réseau
6. Requirements Stockage
7. Requirements Sécurité
8. Requirements Kubernetes
9. Monitoring & Observabilité
10. Ressources complémentaires

📋 Vue d'ensemble

Ce document spécifie les exigences techniques pour le déploiement de la plateforme Devana.ai en environnement d'entreprise. Il est conçu pour les organisations à grande échelle nécessitant haute disponibilité, sécurité renforcée et conformité réglementaire.

Portée

• Déploiement on-premise ou cloud privé
• Architecture multi-environnements (dev, staging, production)
• Support de 100 à 10 000+ utilisateurs concurrents
• Intégration avec infrastructure existante (SSO, réseau, stockage)

🏗️ Architecture de la plateforme

Composants principaux

La plateforme Devana.ai s'articule autour de 8 composants critiques :

Dépendances externes

• LLM Provider (OpenAI, Azure OpenAI, ou auto-hébergé)
• Embedding Model (OpenAI, auto-hébergé via vLLM/TGI)
• Services optionnels : SharePoint, Azure AD, services web externes

💻 Requirements Matériels

Configuration minimale (Environnement de test / < 50 utilisateurs)

Configuration recommandée (Production / 100-500 utilisateurs)

* GPU pour Odin : recommandé pour l'OCR haute performance (NVIDIA T4 ou supérieur)

Configuration entreprise (1000-10 000+ utilisateurs)

Cluster Kubernetes recommandé :

• Nœuds de calcul : 10-20 nœuds (32 cores, 128 GB RAM chacun)
• Nœuds GPU (LLM 70B+) : 4-8 nœuds GPU (NVIDIA H100/H200)
• Nœuds GPU (Embeddings) : 2-3 nœuds GPU (NVIDIA L4 ou L40S)
• Nœuds de données (PostgreSQL, ChromaDB) : 3-5 nœuds (NVMe, 128-256 GB RAM)
• Réseau : 100 Gbps minimum entre nœuds GPU, 10 Gbps pour le reste

🤖 Requirements LLM & Embeddings

Scénario 1 : Cloud Providers (OpenAI, Azure OpenAI, Anthropic)

Avantages :

• Pas d'infrastructure GPU nécessaire
• Scalabilité automatique
• Latence optimisée (CDN global)
• Coûts prévisibles (pay-per-token)

Requirements :

• Bande passante : 100 Mbps minimum (synchrone), 1 Gbps recommandé
• Latence : < 100ms vers endpoints API (idéalement < 50ms)
• Disponibilité : SLA 99.9% minimum (Azure/OpenAI)
• Coûts estimés (production, 1000 utilisateurs actifs) :
  • LLM : $5,000-$15,000/mois selon modèle et volume
  • Embeddings : $500-$2,000/mois

Configuration réseau :

# Whitelist endpoints
api.openai.com           # OpenAI
*.openai.azure.com       # Azure OpenAI
api.anthropic.com        # Claude

Limitations :

• Dépendance externe critique
• Données transitent hors infrastructure (conformité RGPD/HIPAA)
• Contrôle limité sur latence et disponibilité

Scénario 2 : LLM Auto-hébergés (Recommandé pour entreprises)

Avantages :

• Contrôle total des données (on-premise)
• Latence prévisible (<10ms en réseau local)
• Conformité réglementaire garantie
• Coûts fixes après investissement initial

Requirements matériels par modèle

Modèles de production (recommandés)

GPU nouvelle génération (recommandés)

Configuration recommandée (production) :

• LLM principal : 2x serveurs GPU (Llama 3.3 70B ou Qwen 2.5 72B)

  • GPU : 2x NVIDIA H100 80GB par serveur (ou 2x H200 141GB pour modèles >100B)
  • CPU : 64 cores (AMD EPYC 9004 series ou Intel Xeon Sapphire Rapids)
  • RAM : 512 GB DDR5
  • Stockage : 4 TB NVMe Gen4 (modèles + cache)
  • Réseau : 400 Gbps InfiniBand ou 100 Gbps Ethernet

• Embedding Model : 2x serveurs GPU (e5-mistral-7b-instruct ou gte-Qwen2-7B)

  • GPU : 1x NVIDIA L4 24GB par serveur
  • CPU : 16 cores
  • RAM : 128 GB
  • Stockage : 1 TB NVMe
  • Réseau : 25 Gbps

Architectures supportées :

• vLLM : Plateforme de serving haute performance (recommandé)
• TGI (Text Generation Inference) : Solution Hugging Face
• Ollama : Déploiement simplifié (dev/test uniquement)
• TensorRT-LLM : Performance maximale (NVIDIA)

Exemple de déploiement vLLM (Kubernetes) :

# Voir cluster-embeddings/embedding.yml pour référence complète
resources:
  limits:
    nvidia.com/gpu: 1 # Par réplica
    cpu: "4"
    memory: "24Gi"
replicas: 2 # Haute disponibilité

Scalabilité (modèles 70B+) :

• 100-500 utilisateurs : 2x H100 80GB (Llama 3.3 70B)
• 500-2000 utilisateurs : 4x H100 80GB (2 serveurs en load balancing)
• 2000-5000 utilisateurs : 8x H100 80GB (4 serveurs) ou 4x H200 141GB
• 5000-10000 utilisateurs : Cluster GPU dédié (12-16x H100 ou 8-12x H200)

Note : Les petits modèles (<70B) ne sont pas recommandés pour un usage production enterprise-grade nécessitant des capacités de raisonnement avancées.

Scénario 3 : Hybride (Recommandé pour flexibilité)

Configuration :

• LLM principal : Auto-hébergé (données sensibles)
• LLM secondaire : Cloud (fallback, pic de charge)
• Embeddings : Auto-hébergé (volumétrie élevée)

Bénéfices :

• Résilience maximale
• Optimisation coûts
• Conformité assurée sur données critiques

Scénario 4 : Clusters Mac (Apple Silicon)

⚠️ AVERTISSEMENT : Limitations macOS pour usage serveur

macOS n'est PAS conçu comme système d'exploitation serveur. Apple a discontinué macOS Server en avril 2022.

Limitations opérationnelles majeures :

• Authentification obligatoire : macOS requiert login/mot de passe au démarrage, compliquant l'automatisation et les redémarrages non supervisés
• Gestion à distance complexe : Pas d'équivalent SSH headless natif sans session utilisateur active, configuration VNC/Screen Sharing requise
• Updates disruptives : Mises à jour macOS nécessitent redémarrages fréquents et intervention manuelle, pas de stratégie de patching automatisée enterprise-grade
• File descriptors limités : Maximum 12,288 FD (vs quasi-illimité sur Linux), risque de "too many files open" sous charge
• Absence d'outils enterprise : Pas de clustering OS natif, gestion de flotte limitée, monitoring système rudimentaire

Limitations matérielles :

• Hardware consumer : Mac Mini/Studio non certifiés pour opérations datacenter 24/7 critiques
• Aucune redondance : Pas de PSU doubles, RAID matériel, ou hot-swap
• Form factor instable : Changements dimensionnels entre générations compliquant le rack-mounting standardisé

Recommandations d'usage :

• ✅ Acceptable : Développement, staging, prototypage, CI/CD (Xcode/iOS builds)
• ⚠️ Acceptable avec réserves : Production légère (<500 users), avec monitoring humain et tolérance aux interruptions
• ❌ Non recommandé : Production critique 24/7, environnements nécessitant SLA >99.9%, compliance stricte (SOC 2, ISO 27001)

Pour production enterprise critique, privilégier Scénario 2 (Linux + GPU NVIDIA) ou Scénario 3 (Hybride).

Cas d'usage appropriés :

• Organisations avec infrastructure Mac existante et équipes macOS expérimentées
• Environnements nécessitant efficacité énergétique maximale
• Déploiements on-premise avec contraintes de bruit/chaleur (bureaux)
• Prototypage et développement avant scale-out GPU
• Workloads non-critiques avec tolérance aux interruptions planifiées
• Build farms Xcode/iOS (cas d'usage historique des Mac en datacenter)

Avantages :

• Efficacité énergétique : 3-5x moins de consommation vs serveurs GPU
• Mémoire unifiée : CPU/GPU/Neural Engine partagent la RAM (jusqu'à 512 GB)
• Architecture zero-copy : Pas de transfert PCIe entre CPU et GPU
• Silence opérationnel : Idéal pour bureaux et petits datacenters
• Infrastructure simplifiée : Pas de serveur GPU dédié requis

Requirements matériels par configuration

Configuration développement / test (< 50 utilisateurs)

Configuration production (100-500 utilisateurs)

Configuration cluster haute performance (500-2000 utilisateurs)

Exemple cluster économique (démontré par Exo Labs) :

• 4x Mac Mini M4 + 1x MacBook Pro M4 Max
• RAM totale : 496 GB de mémoire unifiée
• Use case : Développement, staging, petites productions

Performances mesurées (benchmarks 2025)

Formule approximative (M-series avec FP16) :

• Tokens/sec ≈ Bandwidth (GB/s) / 160
• M2 (100 GB/s) : ~6.5 tok/s
• M2 Pro (200 GB/s) : ~13 tok/s
• M2 Max (400 GB/s) : ~25 tok/s
• M2 Ultra (800 GB/s) : ~41 tok/s
• M3 Ultra (819 GB/s) : ~51 tok/s (théorique, 40 tok/s réel avec compute bottleneck)

Frameworks et stack logiciel

Stack recommandé pour production Mac :

Option 1 : Ollama (simplicité)

• Ollama avec MLX backend
• API OpenAI-compatible
• Gestion automatique des ressources

Option 2 : llama.cpp (performance)

• Compilation Metal optimisée
• Quantization personnalisée (Q4_K_M, Q5_K_M, Q8)
• Contrôle fin des paramètres

Option 3 : MLX natif (flexibilité)

• Python direct avec mlx-lm
• Fine-tuning local possible
• Intégration custom

Configuration réseau pour clustering

Requirements réseau :

• Minimum : 10 Gbps Ethernet (latence ~8-10ms inter-node)
• Recommandé : 25 Gbps RoCEv2 (latence ~3-5ms inter-node)
• Optimal : Thunderbolt 5 direct (120 GB/s entre 2 machines)

Impact réseau mesuré (cluster DBRX) :

• 10 Gbps : ~14 tok/s
• 25 Gbps : ~16.3 tok/s (+16% performance)
• Note : Communication inter-nodes peut égaler ou dépasser le temps de calcul

Topologie cluster recommandée :

Légende :

• 🔵 Bleu : LLM nodes (Mac Studio M3 Ultra + Mac Mini M4 Pro)
• 🟣 Violet : Embeddings nodes (Mac Mini M4)

Limitations et considérations

Avantages comparés à NVIDIA :

• ✅ Efficacité énergétique : ~400W vs ~2000W pour serveur GPU équivalent
• ✅ Mémoire : Jusqu'à 512 GB unifiée (vs 80 GB VRAM H100)
• ✅ Architecture : Mémoire unifiée zero-copy CPU/GPU/Neural Engine
• ✅ Bruit/chaleur : Déploiement bureau possible (opération silencieuse)

Limitations vs NVIDIA :

• ❌ Compute brut : 38 TOPS (Neural Engine) vs 2000 TFLOPS (H100)
• ❌ Scaling : Clustering complexe vs NVLink natif
• ❌ Écosystème : MLX/Ollama uniquement vs vLLM/TGI/TensorRT
• ❌ Modèles >70B : Performance dégradée (17-19 tok/s pour 672B)
• ❌ Multi-GPU : Pas de support natif type NVLink

Cas d'usage IDÉAUX pour Mac :

• Modèles 7B-70B en production légère/moyenne
• Environnements contraints (énergie, bruit, espace)
• Organisations Mac-first (Apple Silicon déjà déployé)
• Prototypage avant déploiement GPU cloud/on-prem
• Embeddings haute volumétrie (mémoire importante)

Cas d'usage NON RECOMMANDÉS :

• Modèles >100B en production intensive (>2000 users)
• Requirements >100 tok/s
• Workloads nécessitant vLLM/TGI spécifiquement
• Scaling horizontal massif (>10 nodes)

Roadmap Apple (2025+)

M5 (fin 2025) :

• Coprocesseurs dédiés Transformers
• Performance LLM prévue : 2-3x M3 Ultra
• Efficacité énergétique encore améliorée

Recommandation : Pour projets 2025+ nécessitant Mac, considérer attente M5 ou déploiement hybride (M3/M4 + GPU NVIDIA pour scale-out).

🌐 Requirements Réseau

Bande passante

Latence maximale acceptable

Ports requis

Externes (Internet)

Internes (Cluster)

Règles Firewall (exemples)

# Production - Règles strictes
# Frontend accessible uniquement via Load Balancer
LB -> Frontend:3000 (ALLOW)
* -> Frontend:3000 (DENY)

# API accessible uniquement depuis Frontend et LB
Frontend -> API:4666,5001 (ALLOW)
LB -> API:4666 (ALLOW)
* -> API:4666,5001 (DENY)

# Services internes isolés
API -> PostgreSQL:5432 (ALLOW)
API -> ChromaDB:8000 (ALLOW)
API -> Redis:6379 (ALLOW)
API -> Odin:3003 (ALLOW)
* -> Services-internes:* (DENY)

# LLM/Embeddings (si auto-hébergé)
API -> LLM-Cluster:8000 (ALLOW)
Odin -> Embeddings:8000 (ALLOW)
* -> LLM-Cluster:8000 (DENY)

💾 Requirements Stockage

Dimensionnement par volume

Calcul détaillé (1000 utilisateurs) :

• Fichiers utilisateurs (S3/MinIO) : 5 TB (500 docs × 10 MB avg × 1000 users)
• Base de données PostgreSQL : 500 GB (métadonnées, conversations, logs)
• ChromaDB (vecteurs) : 200 GB (1000 dims × 4 bytes × 50M chunks)
• Meilisearch (index) : 100 GB (index inversé + cache)
• Redis (cache) : 20 GB (sessions + cache applicatif)
• Backups : 6 TB (retention 30 jours, snapshots quotidiens)
• Logs : 50 GB/mois (application + système)

Total : ~12 TB avec marge de 30%

Performances requises

Stratégie de backup

RTO (Recovery Time Objective) : < 4h RPO (Recovery Point Objective) : < 15min

• PostgreSQL : WAL archiving + snapshots quotidiens
• ChromaDB : Snapshots quotidiens (données reconstructibles)
• S3/MinIO : Réplication géographique + snapshots hebdomadaires
• Redis : RDB snapshots + AOF (append-only file)

🔒 Requirements Sécurité

Conformité réglementaire

Chiffrement

At-Rest :

• PostgreSQL : Chiffrement TDE (Transparent Data Encryption)
• S3/MinIO : AES-256 (SSE-S3 ou SSE-KMS)
• Disques : LUKS ou équivalent

In-Transit :

• TLS 1.3 minimum (1.2 acceptable avec ciphers forts)
• Certificats signés (Let's Encrypt ou CA interne)
• Mutual TLS pour services internes (optionnel mais recommandé)

Authentification & Autorisation

SSO requis (production) :

• OIDC / OAuth 2.0
• SAML 2.0
• LDAP / Active Directory

RBAC (Role-Based Access Control) :

• Admin système
• Admin organisation
• Gestionnaire d'agents
• Utilisateur standard
• Utilisateur lecture seule

Audit Logs :

• Toutes actions admin
• Accès aux données sensibles
• Modifications de configuration
• Retention : 1 an minimum

Isolation réseau

Zones de sécurité :

[Internet] → [DMZ: LB, WAF] → [App: Frontend, API] → [Data: DB, Storage]
                                                    → [AI: LLM, Embeddings]

Segmentation réseau (VLANs/Subnets) :

• DMZ : Load Balancers, Reverse Proxy (10.0.1.0/24)
• Application : Frontend, API (10.0.10.0/24)
• Services : Odin, Redis, Meilisearch (10.0.20.0/24)
• Données : PostgreSQL, ChromaDB (10.0.30.0/24)
• AI : LLM, Embeddings (10.0.40.0/24)
• Management : Monitoring, Backup (10.0.99.0/24)

☸️ Requirements Kubernetes

Version

• Minimum : Kubernetes 1.31+
• Recommandé : Kubernetes 1.32+ ou OpenShift 4.19+
• Distributions supportées :
  • Vanilla Kubernetes
  • Red Hat OpenShift
  • Rancher RKE2
  • VMware Tanzu
  • Amazon EKS / Azure AKS / Google GKE (cloud privé)

Addons conseillés

Namespaces recommandés

- devana-prod # Application production
- devana-staging # Pre-production
- devana-services # Services partagés (DB, Redis)
- devana-ai # LLM & Embeddings
- monitoring # Prometheus, Grafana, Loki
- cert-manager # Gestion certificats

Storage Classes

# Haute performance (PostgreSQL, ChromaDB)
storageClassName: fast-ssd
provisioner: kubernetes.io/no-provisioner  # Local NVMe
volumeBindingMode: WaitForFirstConsumer

# Standard (logs, backups)
storageClassName: standard
provisioner: kubernetes.io/aws-ebs  # Ou équivalent

# Objets (S3/MinIO via CSI)
storageClassName: s3-csi
provisioner: ru.yandex.s3.csi

📊 Monitoring & Observabilité

Métriques critiques à surveiller

Stack recommandé

• Prometheus : Métriques système + applicatives
• Grafana : Dashboards + alerting
• Loki : Logs agrégés (alternative à ELK)
• Jaeger / Tempo : Tracing distribué (optionnel)
• OpenTelemetry : Instrumentation standardisée

Alerting critique

# Exemples de règles Prometheus
- alert: APIHighLatency
  expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 0.5
  for: 5m
  severity: warning

- alert: PostgreSQLDown
  expr: up{job="postgresql"} == 0
  for: 1m
  severity: critical

- alert: LLMGPUMemoryHigh
  expr: nvidia_gpu_memory_used_bytes / nvidia_gpu_memory_total_bytes > 0.9
  for: 10m
  severity: warning

📚 Ressources complémentaires

Documentation technique

• Guide de déploiement Kubernetes
• Configuration des variables d'environnement
• Fournisseurs LLM
• Configuration SSO
• Monitoring et health checks

Ressources externes

• vLLM Documentation : https://docs.vllm.ai
• Kubernetes Best Practices : https://kubernetes.io/docs/concepts/
• PostgreSQL Performance Tuning : https://wiki.postgresql.org/wiki/Performance_Optimization
• NVIDIA GPU Operator : https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/

🔄 Historique des révisions

Note légale : Ce document est confidentiel et destiné uniquement aux clients et partenaires de Scriptor Artis. Toute reproduction ou diffusion est interdite sans autorisation écrite.

© 2025 Scriptor Artis - Tous droits réservés