Main Page: Difference between revisions

From Essential
Jump to navigation Jump to search
No edit summary
Line 32: Line 32:


== Vue d’ensemble ==
== Vue d’ensemble ==
* [https://github.com/ynotopec/infra-archi-overview/tree/main Infra architecture overview]
* [[File:Ailab-architecture.png|'''Infra architecture overview''']]


----
----

Revision as of 13:55, 30 March 2026

Discover cloud and AI on infocepo.com

infocepo.com – Cloud, AI & Labs

Bienvenue sur le portail infocepo.com.

Ce wiki documente l’écosystème Cloud, IA, automatisation et lab d’Infocepo. Il s’adresse aux :

  • administrateurs systèmes,
  • ingénieurs cloud,
  • développeurs,
  • étudiants,
  • curieux qui veulent apprendre en pratiquant.

L’objectif est simple : transformer la théorie en scripts réutilisables, schémas, architectures, APIs et laboratoires concrets.


Accès rapide

Portail principal

Assistant IA

Liste des pages du wiki

Vue d’ensemble

  • Infra architecture overview

Démarrer rapidement

Parcours recommandés

1. Construire un assistant IA privé
  • Déployer une stack type Open WebUI + Ollama + GPU
  • Ajouter un modèle de chat et un modèle de résumé
  • Brancher des données internes via RAG + embeddings
2. Lancer un lab cloud
  • Créer un petit cluster Kubernetes, OpenStack ou bare-metal
  • Mettre en place un pipeline de déploiement (Helm, Ansible, Terraform…)
  • Ajouter un service IA : transcription, résumé, chatbot, OCR…
3. Préparer un audit ou une migration
  • Inventorier les serveurs avec ServerDiff.sh
  • Concevoir l’architecture cible
  • Automatiser la migration avec des scripts reproductibles

Vue d’ensemble du contenu

  • Guides IA & outils : assistants, modèles, évaluation, GPU, RAG
  • Cloud & infrastructure : Kubernetes, OpenStack, HA, HPC, DevSecOps
  • Labs & scripts : audit, migration, automatisation
  • Comparatifs : Kubernetes vs OpenStack vs AWS vs bare-metal, etc.

Vision

The world after automation

Le but à long terme est de construire un environnement où :

  • les assistants IA privés accélèrent la production,
  • les tâches répétitives sont automatisées,
  • les déploiements sont industrialisés,
  • l’infrastructure reste compréhensible, portable et réutilisable.
Main page summary

Catalogue rapide des services

Services principaux
Catégorie Service Lien Rôle
API LLM API LLM Modèles de chat, code, RAG, OCR
API STT API STT Transcription audio
API TTS API TTS Synthèse vocale
API Realtime AI api-realtime-ai Temps réel WebSocket / WebRTC
API Image to Text API LLM OCR / VLM via endpoint dédié
API Summary API Summary Résumé de textes longs
API Text Embeddings Text Embeddings Embeddings pour RAG
API ChromaDB ChromaDB Base vecteur
API Text to Image TXT2IMAGE Génération d’images
API Diarization Diarization Segmentation locuteurs
Observabilité Monitoring Grafana Dashboards techniques
Observabilité Status Uptime Kuma Disponibilité des services
Observabilité Web stats Web Stat Statistiques web
Observabilité LLM stats LLM Stat Vue API / usage
Outils DataLab DataLab Environnement de travail hors-production
Outils Translation UI Translation Traduction
Outils Demos Demos Démonstrateurs

Nouveautés

Nouveautés 21/03/2026

  • Ajout de nemotron-cascade-2 : modèle open 30B MoE NVIDIA orienté raisonnement et tâches agentiques.
  • Ajout de opencode : CLI coder à comparer avec Aider / OpenHands.
  • Ajout de localai : infrastructure locale unifiée pour STT / TTS / LLM.
  • DGX Spark : architecture CPU ARM.
  • Ajout de qwen3.5 : famille de modèles open source multimodaux.
  • Ajout de api-convert2md : extraction de tableaux pour RAG compatible Open WebUI.
  • Mise à jour des paramètres RAG optimisation.
  • Ajout de experimental brains.
  • Ajout de legal-agent.
  • Ajout de ai-security.
  • Ajout de langextract : démo extraction d’entités.
  • Ajout de sam-audio : séparation audio sémantique.
  • Ajout de glm-4.7-flash : modèle 30B léger orienté performance / efficacité.
  • Ajout de API Realtime : WebRTC / WebSocket bidirectionnel basse latence.
  • Ajout de gpt-oss : modèles open-weight conçus pour raisonnement et tâches agentiques.

Priorités

Top tasks

  • Ajouter Presidio : anonymisation / masquage PII, socle RGPD.
  • Ajouter SGLang : serving LLM haute performance.
  • Ajouter llm-d : blueprints + charts Kubernetes pour industrialiser les déploiements.
  • Ajouter Dynamo : orchestration inférence multi-nœuds.
  • Ajouter GuideLLM : capacity planning / benchmark réaliste.
  • Ajouter NeMo Guardrails : garde-fous et politiques.

Backlog / veille


Assistants IA & outils cloud

Assistants IA

ChatGPT
  • ChatGPT – Assistant conversationnel public, utile pour exploration, rédaction, expérimentation rapide.
Assistants IA auto-hébergés
Stack typique pour assistant privé, API OpenAI-compatible et expérimentation locale.
Outil de résumé local, rapide et hors ligne.

Développement, modèles & veille

Découverte de modèles
Évaluation & benchmarks
Outils de développement & fine-tuning

Matériel IA & GPU


Modèles ouverts & endpoints internes

Dernière mise à jour : 2026-02-13

Les modèles ci-dessous correspondent à des endpoints logiques exposés derrière une passerelle.

Endpoint Description / usage principal
ai-chat Basé sur gpt-oss-20b – chat généraliste, bon compromis coût / qualité
ai-translate gpt-oss-20b, température = 0 – traduction déterministe et reproductible
ai-summary qwen3 – résumé de textes longs
ai-code gpt-oss-20b – raisonnement et explication de code
ai-code-completion gpt-oss-20b – auto-complétion rapide
ai-parse qwen3 – extraction structurée, parsing logs / JSON / tableaux
ai-RAG-FR qwen3 – RAG en français
gpt-oss-20b tâches agentiques

API Realtime AI (DEV)

Statut : environnement DEV, remplaçante prévue de l’API OpenAI pour les cas temps réel.

Configuration

Variable Valeur
OPENAI_API_BASE wss://api-realtime-ai.ai.lab.infocepo.com:wait-2026-06/v1
OPENAI_API_KEY sk-XXXXX

Dépôt GitHub

Page de test

  • external-test/half-duplex.html — annulation d’écho + mode half-duplex.

Compatibilité

Remplacer l’URL OpenAI par $OPENAI_API_BASE pour tester compatibilité et performances.


API LLM (OpenAI compatible)

Liste des modèles

curl -X GET \
  'https://api.ai.lab.infocepo.com:wait-2026-06/v1/models' \
  -H 'Authorization: Bearer sk-XXXXX' \
  -H 'accept: application/json' \
  | jq | sed -rn 's#^.*id.*: "(.*)".*$#* \1#p' | sort -u

Modèles mis en avant

Model Commentaire
ai-chat qwen3-coder
ai-translate qwen3-coder
ai-summary qwen3-coder
ai-code-completion qwen3-coder
ai-RAG-FR qwen3-coder
qwen3-coder Function Calling
ai-ocr qwen3-vl

Exemple bash

export OPENAI_API_MODEL="ai-chat"
export OPENAI_API_BASE="https://api.ai.lab.infocepo.com:wait-2026-06/v1"
export OPENAI_API_KEY="sk-XXXXX"

promptValue="Quel est ton nom ?"
jsonValue='{
  "model": "'${OPENAI_API_MODEL}'",
  "messages": [{"role": "user", "content": "'${promptValue}'"}],
  "temperature": 0
}'

curl -k ${OPENAI_API_BASE}/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d "${jsonValue}" 2>/dev/null | jq '.choices[0].message.content'

Vue infra LLM

DEV (au choix)

  • A. LiteLLM → vLLM : tests perf / compatibilité
  • B. LiteLLM → Ollama : simple, rapide à itérer
  • C. Ollama direct : POC ultra-léger

DEV – modèle FR / résumé

  • LiteLLM → Ollama /v1

PROD

  • Standard : LiteLLM → vLLM
  • Pont DEV→PROD : LiteLLM (DEV) → LiteLLM (PROD) → vLLM

Notes :

  • LiteLLM = passerelle unique (clés, quotas, logs)
  • vLLM = performance / stabilité en charge
  • Ollama = simplicité de prototypage

API Image to Text

  • Utilise l’API LLM avec un endpoint adapté à l’OCR / VLM.
  • Modèle recommandé : ai-ocr

Exemple bash

OPENAI_API_KEY=sk-XXXXX

base64 -w0 "/path/to/image.png" > img.b64

jq -n --rawfile img img.b64 \
'{
  model: "ai-ocr",
  messages: [
    {
      role: "user",
      content: [
        { "type": "text", "text": "Décris cette image." },
        {
          "type": "image_url",
          "image_url": { "url": ("data:image/png;base64," + ($img | rtrimstr("\n"))) }
        }
      ]
    }
  ]
}' > payload.json

curl https://api.ai.lab.infocepo.com:wait-2026-06/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @payload.json

Exemple Python

import base64
import json
import requests
import os

API_KEY = os.getenv("OPENAI_API_KEY")
MODEL = "ai-ocr"
IMG_PATH = "/path/to/image.png"
API_URL = "https://api.ai.lab.infocepo.com:wait-2026-06/v1/chat/completions"

with open(IMG_PATH, "rb") as f:
    img_b64 = base64.b64encode(f.read()).decode("utf-8")

payload = {
    "model": MODEL,
    "messages": [
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Décris cette image."},
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/png;base64,{img_b64}"}
                }
            ]
        }
    ]
}

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

response = requests.post(API_URL, headers=headers, data=json.dumps(payload))

if response.ok:
    print(json.dumps(response.json(), indent=2, ensure_ascii=False))
else:
    print(f"Erreur {response.status_code}: {response.text}")

API STT

Exemple Python

import requests

OPENAI_API_KEY = 'sk-XXXXX'

url = 'https://stt.ai.lab.infocepo.com:wait-2026-06/v1/audio/transcriptions'
headers = {
    'Authorization': f'Bearer {OPENAI_API_KEY}',
}
files = {
    'file': ('file.opus', open('/path/to/file.opus', 'rb')),
    'model': (None, 'whisper-1')
}

response = requests.post(url, headers=headers, files=files)
print(response.json())

Exemple curl

[ ! -f /tmp/test.ogg ] && wget "https://upload.wikimedia.org/wikipedia/commons/1/17/Fables_de_La_Fontaine_Livre_1_01.ogg" -O /tmp/test.ogg

export OPENAI_API_KEY=sk-XXXXX

curl https://stt.ai.lab.infocepo.com:wait-2026-06/v1/audio/transcriptions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F model="whisper-1" \
  -F file="@/tmp/test.ogg"

Notes

  • Plusieurs formats audio sont acceptés.
  • Le flux final est normalisé en 16 kHz mono.
  • Pour une qualité optimale : privilégier OPUS 16 kHz mono.

UI


API TTS

Exemple

export OPENAI_API_KEY=sk-XXXXX

curl https://tts.ai.lab.infocepo.com:wait-2026-06/v1/audio/speech \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini-tts",
    "input": "Bonjour, ceci est un test de synthèse vocale.",
    "voice": "coral",
    "instructions": "Speak in a cheerful and positive tone.",
    "response_format": "opus"
  }' | ffplay -i -

API Text to Image

Exemple

export OPENAI_API_KEY=EMPTY

curl https://api-txt2image.ai.lab.infocepo.com:wait-2026-06/v1/images/generations \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "prompt": "a photo of a happy corgi puppy sitting and facing forward, studio light, longshot",
    "n": 1,
    "size": "1024x1024"
  }'

API Diarization

Exemple

wget "https://upload.wikimedia.org/wikipedia/commons/6/60/Mike_Peters_on_Politics_and_Emotion_%28Interview_1984%29.mp3" -O /tmp/test.mp3

curl -X POST "https://api-diarization.ai.lab.infocepo.com:wait-2026-06/upload-audio/" \
  -H "Authorization: Bearer token1" \
  -F "file=@/tmp/test.mp3"

API Summary

Exemple

text="The tower is 324 metres tall and is one of the most recognizable monuments in the world."

json_payload=$(jq -nc --arg text "$text" '{"text": $text}')

curl -X POST https://api-summary.ai.lab.infocepo.com:wait-2026-06/summary/ \
  -H "Content-Type: application/json" \
  -d "$json_payload"

API Text Embeddings

Exemple

curl -k https://text-embeddings.ai.lab.infocepo.com:wait-2026-06/embed \
  -X POST \
  -d '{"inputs":"What is Deep Learning?"}' \
  -H 'Content-Type: application/json'

API DB Vectors (ChromaDB)

Production

Lab

export CHROMA_HOST=https://chromadb.c1.ai.lab.infocepo.com:wait-2026-06
export CHROMA_PORT=443
export CHROMA_TOKEN=XXXX

Exemple curl

curl -v "${CHROMA_HOST}"/api/v1/collections \
  -H "Authorization: Bearer ${CHROMA_TOKEN}"

Exemple Python

import chromadb
from chromadb.config import Settings

def chroma_http(host, port=80, token=None):
    return chromadb.HttpClient(
        host=host,
        port=port,
        ssl=host.startswith('https') or port == 443,
        settings=(
            Settings(
                chroma_client_auth_provider='chromadb.auth.token.TokenAuthClientProvider',
                chroma_client_auth_credentials=token,
            ) if token else Settings()
        )
    )

client = chroma_http(CHROMA_HOST, CHROMA_PORT, CHROMA_TOKEN)
collections = client.list_collections()
print(collections)

Déployer sa propre instance

export nameSpace=your_namespace
domainRoot=ai.lab.infocepo.com:wait-2026-06

helm repo add chroma https://amikos-tech.github.io/chromadb-chart/
helm repo update

helm upgrade --install chromadb chroma/chromadb -n ${nameSpace} \
  --set chromadb.apiVersion="0.4.24" \
  --set ingress.enabled=true \
  --set ingress.hosts[0].host="${nameSpace}-chromadb.${domainRoot}" \
  --set ingress.hosts[0].paths[0].path=/ \
  --set ingress.hosts[0].paths[0].pathType=ImplementationSpecific \
  --set ingress.annotations."cert-manager\.io/cluster-issuer"=letsencrypt-prod \
  --set ingress.tls[0].secretName=${nameSpace}-chromadb.${domainRoot}-tls \
  --set ingress.tls[0].hosts[0]="${nameSpace}-chromadb.${domainRoot}"

kubectl -n ${nameSpace} patch ingress/chromadb --type=json \
  -p '[{"op":"add","path":"/metadata/annotations/nginx.ingress.kubernetes.io~1proxy-body-size","value":"0"}]'

Récupérer le token

kubectl --namespace ${nameSpace} get secret chromadb-auth \
  -o jsonpath="{.data.token}" | base64 --decode && echo

Registry

Exemple

curl -u "user:XXXXX" https://registry.ai.lab.infocepo.com:wait-2026-06/v2/_catalog

Exemple K8S

deploymentName=
nameSpace=

kubectl -n ${nameSpace} create secret docker-registry pull-secret \
  --docker-server=registry.ai.lab.infocepo.com:wait-2026-06 \
  --docker-username=user \
  --docker-password=XXXXX \
  --docker-email=contact@example.com

kubectl -n ${nameSpace} patch deployment ${deploymentName} \
  -p '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"pull-secret"}]}}}}'

Stockage objet externe (S3)

Un bucket nommé ORG a été créé pour stocker des documents de démonstration.


RAG optimisation

  • Embeddings : BAAI/bge-m3
  • chunk_size=1200
  • chunk_overlap=100
  • LLM : qwen3
  • Pour les PDF mixtes : PDF → image → OCR / VLM peut améliorer les résultats.

Processus usine IA

Étape Description Outils utilisés Responsable(s)
1 Idée - Équipe projet
2 Développement Environnement Onyxia / lab Équipe projet
3 Déploiement CI/CD, GitHub, Kubernetes Équipe DevOps
4 Surveillance Uptime-Kuma, dashboards Équipe DevOps
5 Alertes Mattermost Équipe DevOps
6 Support infrastructure - Équipe SRE
7 Support applicatif - Équipe applicative

Environnements

Hors production

  • Utiliser datalab
  • Support : canal Mattermost Offre IA
  • Le pseudo utilisateur doit respecter la convention interne
  • Demander si besoin un accès Linux + Kubernetes

Production (best-effort)

  • Publier le code applicatif, les secrets (format SOPS), le Dockerfile et le code infra (Helm ou manifests K8S) sur Git
  • Demander un namespace
  • Lire la documentation de surveillance associée

Limites de l’infrastructure

  • Les charges GPU sont intentionnellement limitées en journée.

Cloud Lab & projets d’audit

Cloud Lab reference diagram

Le Cloud Lab fournit des scénarios reproductibles : audit d’infrastructure, migration cloud, automatisation, haute disponibilité.

Projet d’audit

ServerDiff.sh

Script Bash d’audit permettant de :

  • détecter les dérives de configuration,
  • comparer plusieurs environnements,
  • préparer un plan de migration ou de remédiation.

Exemple de migration cloud

Cloud migration diagram

Tâche Description Durée (jours)
Audit infrastructure 82 services, audit automatisé via ServerDiff.sh 1.5
Diagramme d’architecture Conception visuelle et documentation 1.5
Contrôles de conformité 2 clouds, 6 hyperviseurs, 6 To RAM 1.5
Installation plateforme cloud Déploiement des environnements cibles 1.0
Vérification de stabilité Premiers tests fonctionnels 0.5
Étude d’automatisation Identification des tâches répétitives 1.5
Développement des templates 6 templates, 8 environnements, 2 clouds / OS 1.5
Diagramme de migration Illustration du processus 1.0
Écriture du code de migration 138 lignes (voir MigrationApp.sh) 1.5
Stabilisation Validation de la reproductibilité 1.5
Benchmark cloud Comparaison vs legacy 1.5
Réglage des temps d’arrêt Calcul du downtime 0.5
Chargement VM 82 VMs : OS, code, 2 IP par VM 0.1
Total 15 jours.homme

Vérifications de stabilité (HA minimale)

Action Résultat attendu
Extinction d’un nœud Tous les services redémarrent automatiquement sur les autres nœuds
Extinction / redémarrage simultané de tous les nœuds Les services repartent correctement après reboot

Architecture web & bonnes pratiques

Reference web architecture

Principes de conception :

  • privilégier une infrastructure simple, modulaire et flexible,
  • rapprocher le contenu du client (GDNS ou équivalent),
  • utiliser des load balancers réseau (LVS, IPVS),
  • comparer les coûts et éviter le vendor lock-in,
  • pour TLS :
    • HAProxy pour les frontends rapides,
    • Envoy pour les cas avancés (mTLS, HTTP/2/3),
  • pour le cache :
    • Varnish, Apache Traffic Server,
  • favoriser les stacks open-source,
  • utiliser files, buffers, queues et quotas pour lisser les pics.

Références


Comparatif des grandes plateformes cloud

Fonctionnalité Kubernetes OpenStack AWS Bare-metal HPC CRM oVirt
Outils de déploiement Helm, YAML, ArgoCD, Juju Ansible, Terraform, Juju CloudFormation, Terraform, Juju Ansible, Shell xCAT, Clush Ansible, Shell Ansible, Python
Méthode de bootstrap API API, PXE API PXE, IPMI PXE, IPMI PXE, IPMI PXE, API
Contrôle routeur Kube-router Router/Subnet API Route Table / Subnet API Linux, OVS xCAT Linux API
Contrôle firewall Istio, NetworkPolicy Security Groups API Security Group API Linux firewall Linux firewall Linux firewall API
Virtualisation réseau VLAN, VxLAN VPC VPC OVS, Linux xCAT Linux API
DNS CoreDNS DNS-Nameserver Route 53 GDNS xCAT Linux API
Load balancer Kube-proxy, LVS LVS Network Load Balancer LVS SLURM Ldirectord N/A
Stockage Local, cloud, PVC Swift, Cinder, Nova S3, EFS, EBS, FSx Swift, XFS, EXT4, RAID10 GPFS SAN NFS, SAN

Cette table sert de point de départ pour choisir la bonne stack selon :

  • le niveau de contrôle souhaité,
  • le contexte (on-prem, cloud public, HPC…),
  • les outils d’automatisation existants.

Haute disponibilité, HPC & DevSecOps

Haute disponibilité avec Corosync & Pacemaker

HA cluster architecture

Principes :

  • clusters multi-nœuds ou multi-sites,
  • fencing via IPMI,
  • provisioning PXE / NTP / DNS / TFTP,
  • pour 2 nœuds : attention au split-brain,
  • 3 nœuds ou plus recommandés en production.

Ressources fréquentes

  • multipath, LUNs, LVM, NFS,
  • processus applicatifs,
  • IP virtuelles, DNS, listeners réseau.

HPC

Overview of an HPC cluster

  • orchestration de jobs (SLURM ou équivalent),
  • stockage partagé haute performance,
  • intégration possible avec des workloads IA.

DevSecOps

DevSecOps reference design

  • CI/CD avec contrôles de sécurité intégrés,
  • observabilité dès la conception,
  • scans de vulnérabilité,
  • gestion des secrets,
  • policy-as-code.

News & trends


Formation & apprentissage


Liens cloud & IT utiles


Outils collaboratifs

Dépôts de code

Base de connaissance

  • ce wiki

Messagerie

  • contact interne / support selon les projets

SSO

MLflow


À propos & contributions

Suggestions de corrections, améliorations de schémas, retours d’expérience ou nouveaux labs bienvenus.

Ce wiki a vocation à rester un laboratoire vivant pour l’IA, le cloud et l’automatisation.