LLM sur IBM i via PASE — Sans Linux ni GPU

/dans /par
LibrePower · IBM i · Mars 2026

On a exécuté un LLM sur IBM i. Sans Linux. Sans cloud. Sans GPU.

llama.cpp compilé pour AIX tourne nativement sur IBM i via PASE. Vos programmes RPG peuvent appeler un LLM local sans infrastructure supplémentaire et sans envoyer vos données à l'extérieur.

Mars 2026●8 min de lecture

Si vous administrez un IBM i, vous connaissez bien la réponse habituelle quand quelqu'un pose la question de l'IA : « montez un LPAR Linux », « utilisez OpenAI », « regardez Wallaroo ». Toutes ces options impliquent de sortir de la plateforme, d'ajouter des couches, et à un moment ou un autre d'envoyer des données métier sur un serveur que vous ne contrôlez pas.

Il y a 150 000 systèmes IBM i qui traitent des transactions bancaires, d'assurance et de santé dans le monde. La réponse ne peut pas toujours être « ajoutez de l'infrastructure ». On a donc essayé autre chose.

L'expérience

Ce qu'on a fait exactement

On a pris llama.cpp — le moteur d'inférence LLM open source le plus utilisé — on l'a compilé pour AIX et copié le binaire sur une partition IBM i V7R5. On l'a exécuté via PASE. Ça a fonctionné du premier coup.

$ uname -a
OS400 WWW 5 7 007800001B91

$ /QOpenSys/pkgs/bin/python3 -c "import platform; print(platform.platform())"
OS400-5-007800001B91-powerpc-64bit

$ /QOpenSys/pkgs/bin/python3 -c "import sys; print('Byte order:', sys.byteorder)"
Byte order: big

IBM i V7R5 sur pub400.com — un système IBM i public. Big-endian, powerpc-64bit, OS400. Pas Linux, pas AIX. IBM i.

Le type de binaire

$ file llama/llama-simple
llama/llama-simple: 64-bit XCOFF executable or object module

Un binaire XCOFF 64 bits — le format exécutable natif d'AIX. Compilé sur AIX 7.3 POWER avec GCC 13.3 et les extensions vectorielles VSX. C'est le même binaire de notre projet llama-aix, qui distribue déjà 10 modèles GGUF big-endian sur HuggingFace.

Première exécution

$ LIBPATH=/home/HBSIXE/llama /home/HBSIXE/llama/llama-simple --help

example usage:

    /home/HBSIXE/llama/llama-simple -m model.gguf [-n n_predict] [prompt]

Le binaire charge, lie libggml et libllama, analyse les arguments et répond. Tout à l'intérieur de PASE. Pour lancer une vraie inférence, on lui passe un modèle GGUF big-endian :

$ LIBPATH=/home/HBSIXE/llama /home/HBSIXE/llama/llama-simple \
    -m models/tinyllama-1.1b-q4_k_m-be.gguf \
    -p "What is IBM i?" -n 100 -t 4
Terminal IBM i PASE exécutant llama.cpp : le binaire XCOFF charge, lie les bibliothèques et répond à un prompt en temps réel
Le contexte

Pourquoi ça a du sens pour un environnement IBM i

En 2026, la conversation sur l'IA dans la communauté IBM i est plus active que jamais. IBM vient de lancer Bob (le successeur de WCA for i), un assistant de codage pour les développeurs RPG. 70 % des clients IBM i prévoient des mises à jour matérielles cette année. Et pourtant, une question reste sans réponse claire :

Comment intégrer un modèle de langage dans mes applications IBM i sans dépendre d'un service externe ?

Les options habituelles aujourd'hui :

OptionCe que ça impliqueLe problème
LPAR LinuxMonter une partition séparée, y faire tourner le LLM, l'appeler depuis RPG via APIInfrastructure supplémentaire, coût additionnel, les données transitent entre partitions
API cloudAppeler OpenAI, Azure ou AWS depuis RPGLes données métier quittent la machine. Problème sérieux en banque, assurance, santé — et potentiellement incompatible avec le RGPD
WallarooL'option 1 packagée comme service500 $/mois. C'est toujours un LPAR Linux avec une étiquette
PASE + llama.cppLe LLM tourne directement dans IBM i via PASEPas de matériel supplémentaire. Les données ne quittent pas la partition.
Et IBM Bob ?
Bob est fait pour le développeur : il aide à comprendre, documenter et générer du code RPG depuis l'IDE. Ce qu'on décrit ici concerne l'application en production : un LLM qui tourne dans la même partition et que n'importe quel programme RPG peut appeler comme une simple API locale. Ce sont des outils complémentaires, pas concurrents.
RGPD et résidence des données

Pour les organisations belges et françaises soumises au RGPD, la question de la résidence des données est non négociable. Une inférence LLM qui s'exécute en local sur IBM i, sans aucun transfert vers un service cloud tiers, est par construction conforme sur ce point. Aucune donnée ne sort de votre infrastructure.

La base technique

PASE : le pont que vous aviez déjà

PASE (Portable Application Solutions Environment) est un environnement d'exécution intégré à IBM i qui exécute des binaires AIX de façon native. Ce n'est pas de l'émulation — c'est une couche qui expose les appels système AIX directement sur le noyau IBM i. Si quelque chose tourne sur AIX, ça peut tourner sur IBM i via PASE.

┌──────────────────────────────────────────┐ │ IBM i (OS400) │ │ │ │ ┌──────────────┐ ┌────────────────┐ │ │ │ RPG / CL │ │ PASE │ │ │ │ COBOL / Db2 │───→│ (AIX runtime) │ │ │ │ │ │ │ │ │ │ localhost │ │ llama-server │ │ │ │ :8080 │ │ + modèle GGUF │ │ │ └──────────────┘ └────────────────┘ │ │ │ │ IBM POWER Hardware │ └──────────────────────────────────────────┘

On compile et distribue des paquets AIX via le dépôt AIX de LibrePower depuis plusieurs années — plus de 30 paquets open source installables via DNF. Quand llama.cpp a rejoint le catalogue, tester le passage à IBM i était l'étape naturelle. PASE s'occupe du reste.

Pour les administrateurs IBM i

Vous n'avez rien de spécial à installer sur le système d'exploitation. PASE est déjà actif. Il vous faut seulement le binaire XCOFF de llama.cpp et un modèle GGUF big-endian. Le LLM tourne comme n'importe quel processus PASE, sans toucher à l'environnement natif IBM i.

L'obstacle technique

Le problème du big-endian (et comment on l'a résolu)

Il y a une raison pour laquelle personne n'avait fait ça proprement avant : l'ordre des octets. IBM i et AIX sont big-endian. La quasi-totalité des logiciels d'IA — x86, ARM, Linux ppc64le — suppose un ordre little-endian. Un fichier GGUF téléchargé directement depuis HuggingFace ne fonctionne pas sur IBM i : les octets sont dans le mauvais sens.

On avait déjà résolu ce problème dans notre travail sur AIX. La solution : convertir les modèles avant de les distribuer. On les publie sur huggingface.co/librepowerai, validés sur du vrai matériel AIX et prêts à être chargés directement dans IBM i PASE.

ModèleTailleQuantisation
TinyLlama 1.1B Chat668 MoQ4_K_M
LFM 1.2B Instruct695 MoQ4_K_M
LFM 1.2B Thinking731 MoQ4_K_M
7 autres modèles disponibles——

Ce sont les mêmes modèles qui atteignent 10–12 tok/s sur AIX POWER. Sur IBM i POWER10 — avec l'accélération matérielle MMA active via OpenBLAS — les performances devraient être comparables ou meilleures. Les benchmarks concrets sur IBM i sont en cours de préparation.

De la PoC à la production

De la preuve de concept à la production

Exécuter --help prouve que le binaire charge. Le chemin réel vers quelque chose d'utile pour vos applications comporte trois étapes — et la première est déjà disponible.

Étape 1 : Inférence directe (disponible maintenant)

Depuis n'importe quelle session SSH ou QSH sur l'IBM i :

# Inférence en ligne de commande
LIBPATH=/chemin/vers/llama /chemin/vers/llama/llama-simple \
    -m /chemin/vers/modele.gguf \
    -p "Résume ce bon de commande" -n 200 -t 8

Utile pour les scripts CL, les jobs en batch, ou simplement pour vérifier que le modèle charge et répond correctement sur votre matériel avant d'aller plus loin.

Étape 2 : Serveur API compatible OpenAI (prochainement)

llama.cpp inclut llama-server, qui expose un endpoint HTTP compatible avec l'API OpenAI. Une fois actif dans PASE, n'importe quel programme RPG peut l'appeler via QSYS2.HTTP_POST — comme n'importe quelle autre API :

# Démarrer le serveur d'inférence sur IBM i via PASE
LIBPATH=/chemin/vers/llama /chemin/vers/llama/llama-server \
    -m /chemin/vers/modele.gguf \
    --host 0.0.0.0 --port 8080 -t 8
// Appel depuis RPG — le LLM est sur localhost
dcl-s url varchar(256) inz('http://localhost:8080/v1/chat/completions');
dcl-s corps varchar(65535);
dcl-s reponse varchar(65535);
// QSYS2.HTTP_POST — aucune donnée ne quitte IBM i

L'essentiel : localhost. Le modèle est sur la même machine. Les données ne quittent pas la partition.

Étape 3 : Intégration applicative métier (en développement)

  • Analyse de documents : passer des rapports Db2 au LLM pour générer des résumés automatiques
  • Requêtes en langage naturel : l'utilisateur écrit en français, le LLM renvoie du SQL
  • Modernisation du code RPG : le LLM analyse et documente les programmes existants sans quitter IBM i
  • Supervision intelligente : analyser les messages QSYSOPR et les journaux de travaux avec un contexte sémantique
Une note sur les performances : les petits modèles (1–2 milliards de paramètres) dans PASE sont largement suffisants pour la classification, le résumé, l'extraction de données structurées et les réponses à format fixe. Pour la génération de texte plus longue ou le raisonnement complexe, les modèles 7B+ scalent bien avec davantage de threads. Les benchmarks IBM i POWER10 sont en cours de préparation.
Hands-on

Comment l'essayer vous-même

Si vous avez accès à un IBM i avec PASE actif, c'est trois étapes.

1. Récupérer le binaire llama.cpp pour AIX

Disponible sur le GitLab de LibrePower. Si vous avez DNF/yum configuré :

# Depuis AIX (ou via PASE si vous avez dnf)
dnf install llama-cpp

2. Télécharger un modèle big-endian

curl -L -o tinyllama-be.gguf \
  "https://huggingface.co/librepowerai/TinyLlama-1.1B-Chat-v1.0-GGUF-big-endian/resolve/main/tinyllama-1.1b-q4_k_m-be.gguf"

TinyLlama est un bon point de départ : 668 Mo, chargement rapide, suffisant pour vérifier que tout fonctionne avant de passer à des modèles plus grands.

3. Lancer l'inférence

LIBPATH=/chemin/vers/llama ./llama-simple \
    -m tinyllama-be.gguf \
    -p "Qu'est-ce qu'IBM i ?" \
    -n 150 -t 4
Des systèmes IBM i en production ?

SIXE accompagne des organisations belges et françaises dans la gestion de leurs environnements IBM i depuis des années. Si vous voulez évaluer si cette approche correspond à votre architecture — ou comprendre ce qu'elle implique pour vos applications RPG — contactez-nous, sans engagement.

Feuille de route

La suite

C'est une preuve de concept solide, pas un produit fini. Voici ce qu'on prévoit de faire ensuite :

  • llama-server sur IBM i — le serveur API HTTP dans PASE, documenté et packagé pour que vous puissiez le lancer en quelques minutes
  • Exemples d'intégration RPG — du vrai code d'appel au LLM depuis des programmes RPG via QSYS2.HTTP_POST
  • Benchmarks IBM i POWER10/POWER11 — des mesures réelles de tok/s avec PASE sur du matériel de production
  • Modèles plus grands — tests avec des modèles 7B+ sur des partitions avec suffisamment de mémoire
  • vLLM pour IBM i — notre paquet vLLM pour ppc64le, adapté pour tourner dans PASE

Autres projets LibrePower

ProjetCe qu'il fait
llama-aixllama.cpp pour AIX avec 10 modèles GGUF big-endian prêts à télécharger
linux.librepower.orgDépôt APT avec vLLM pour Linux ppc64le (Ubuntu/Debian)
aix.librepower.orgPlus de 30 paquets open source pour AIX, installables via DNF
IBM i avec PASE ?

Testez le LLM sur votre propre partition

Le binaire est sur GitLab. Les modèles sont sur HuggingFace. Si vous avez accès à PASE et quelques minutes, vous pouvez reproduire exactement ce qu'on décrit ici :)

GitLab — llama-aix Support IBM i — SIXE →
LibrePower Modèles big-endian Newsletter

vLLM sur IBM POWER : inférence LLM sans GPU

/dans /par


LibrePower · Linux on Power · Mars 2026

vLLM sur IBM POWER : inférence LLM sans GPU

Le premier paquet vLLM précompilé pour Linux ppc64le. Construit par la communauté — et il tourne sur le matériel que vous avez déjà.

Mars 2026●18 min de lecture


Si vous administrez des serveurs IBM POWER, vous connaissez la dynamique. Le matériel est exceptionnel — POWER9, POWER10 et POWER11 offrent une fiabilité incomparable, une bande passante mémoire sans égal et un débit par cœur que peu d’architectures peuvent égaler. Mais dans l’écosystème IA, vous aviez jusqu’ici deux options : apporter vos propres GPU (généralement x86) ou passer par Red Hat OpenShift AI. Il existe désormais une troisième option pour exécuter l’inférence de LLMs sur IBM POWER. Elle prend 30 secondes, fonctionne sur du matériel existant et utilise l’accélération matérielle MMA de façon automatique.

Le paquet

Ce que nous avons construit : vLLM sur IBM POWER en paquet .deb

vLLM est le moteur d’inférence LLM open source le plus utilisé. Il alimente l’inférence à l’échelle de millions de requêtes quotidiennes en production. Il prend en charge l’API OpenAI complète : /v1/chat/completions, /v1/completions, /v1/models — streaming, appels de fonctions, usage d’outils.

Le problème : il n’existait aucun paquet précompilé pour ppc64le. Ni sur PyPI. Ni dans les dépôts Ubuntu. Si vous vouliez vLLM sur IBM POWER, vous étiez livré à vous-même. La communauté IBM elle-même a documenté la complexité de l’installation manuelle.

Nous l’avons donc compilé. Sur du vrai matériel IBM POWER. Optimisé pour l’architecture. Et packagé sous forme de .deb qu’APT peut installer avec résolution complète des dépendances.

$ apt-cache show python3-vllm

Package: python3-vllm
Version: 0.9.2-1
Architecture: ppc64el
Maintainer: LibrePower <packages@librepower.org>
Depends: python3 (>= 3.10), python3-numpy, python3-requests
Homepage: https://librepower.org/stack/databases-operating-systems/linux/
Description: Serveur d'inférence LLM compatible OpenAI pour ppc64le
Ubuntu sur IBM POWER
Faire tourner Ubuntu sur IBM POWER est la base de ce flux de travail. SIXE déploie et supporte les environnements Ubuntu ppc64le en tant que Canonical Partner — la même infrastructure qui rend possible cette installation par APT. Pour aller plus loin sur l’administration Linux en Power, nous proposons des formations officielles IBM en français, disponibles à Paris, Bruxelles, Luxembourg et en ligne.

Sous le capot

Le processus : du code source au paquet .deb sur ppc64le

Compiler vLLM pour POWER n’est pas un simple pip install. Voici ce que cela a impliqué.

PyTorch sur POWER

vLLM dépend de PyTorch, qui n’est pas distribué pour ppc64le sur PyPI. IBM publie des wheels sur wheels.developerfirst.ibm.com — nous les utilisons comme base. Consultez le catalogue complet des outils de développement IBM supportés pour POWER.

L’extension C++

La voie haute performance de vLLM est une extension C++ (_C.abi3.so) qui gère l’attention, le cache, les fonctions d’activation et la quantification. Elle doit être compilée depuis le code source avec CMake, en liant l’API C++ de PyTorch et oneDNN pour des opérations GEMM optimisées.

-- PowerPC détecté
-- Flags de compilation : -fopenmp -DVLLM_CPU_EXTENSION
   -mvsx -mcpu=power9 -mtune=power9
-- Fichiers source : csrc/cpu/quant.cpp csrc/cpu/activation.cpp
   csrc/cpu/attention.cpp csrc/cpu/cache.cpp csrc/cpu/utils.cpp
   csrc/cpu/layernorm.cpp csrc/cpu/pos_encoding.cpp
[100%] Liaison du module partagé CXX _C.abi3.so
[100%] Cible _C construite

Le binaire résultant inclut oneDNN avec des noyaux GEMM PPC64 — la même bibliothèque mathématique qu’Intel utilise pour x86, mais ciblant les unités vectorielles de POWER.

Résolution des dépendances

L’écosystème Python sur ppc64le présente des lacunes. Certains paquets ont des wheels précompilées, d’autres nécessitent une compilation depuis le source, et quelques-uns ont des conflits de version. Nous avons tout résolu pour que vous n’ayez pas à le faire.

En pratique

Inférence LLM sur IBM POWER : code et résultat

Voici ce que cela donne en pratique. D’abord, installez le paquet :

# Ajouter le dépôt APT LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Installer vLLM pour ppc64le
sudo apt update
sudo apt install python3-vllm

# Installer les wheels PyTorch d'IBM
pip3 install torch --extra-index-url \
  https://wheels.developerfirst.ibm.com/ppc64le/linux

Puis exécutez l’inférence depuis Python :

# Python
from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen/Qwen2.5-0.5B-Instruct",
    dtype="bfloat16",
    device="cpu",
    enforce_eager=True
)

output = llm.generate(
    ["Explique l'informatique quantique en termes simples."],
    SamplingParams(temperature=0, max_tokens=100)
)

print(output[0].outputs[0].text)

Mais la vraie valeur de vLLM est le mode serveur, compatible avec l’API OpenAI :

# Démarrer le serveur d'inférence compatible OpenAI
python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --device cpu --dtype bfloat16 --port 8000
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-0.5B-Instruct",
    "messages": [{"role": "user", "content": "Qu'\''est-ce qu'\''IBM POWER ?"}],
    "max_tokens": 100
  }'

LangChain, LlamaIndex, Open WebUI, Continue.dev — toute application pouvant pointer vers un endpoint OpenAI fonctionne sans modification. Changez base_url vers votre serveur POWER et c’est tout. C’est ce qui fait de l’inférence CPU sur IBM POWER une voie réaliste vers le déploiement d’IA générative sur infrastructure propre, sans dépendance GPU ni cloud public.

Les chiffres

Performances réelles sur POWER9, POWER10 et POWER11 : benchmarks d’inférence

Nous avons effectué des benchmarks sur les deux générations POWER avec Qwen2.5-0.5B-Instruct (494M paramètres, BF16). Ce ne sont pas des chiffres théoriques — ils proviennent de l’exécution de l’outil de benchmark sur du vrai matériel.

POWER9

$ OMP_NUM_THREADS=12 python3 bench_vllm.py
Exécution 1 : 17,8 tok/s (100 tokens en 5,6 s)
Exécution 2 : 16,7 tok/s (100 tokens en 6,0 s)
Exécution 3 : 18,5 tok/s (100 tokens en 5,4 s)
Benchmark POWER9 : fils=12 moyenne=17,6 tok/s

12 fils est le point optimal — davantage de fils ajoutent de la contention de cache sur cette charge de travail limitée par la bande passante mémoire.

POWER10

$ OMP_NUM_THREADS=1 python3 bench_vllm.py
Exécution 1 : 13,9 tok/s (100 tokens en 7,2 s)
Benchmark POWER10 : fils=1 moyenne=13,9 tok/s
13,9 tok/s depuis un seul cœur POWER10. Pour contexte : le résultat POWER9 utilise 12 fils sur plusieurs cœurs pour atteindre 17,6 tok/s. L’amélioration d’efficacité par cœur de POWER9 à POWER10 est spectaculaire, portée par l’accélération matérielle MMA. POWER11 partage la même architecture MMA avec des améliorations supplémentaires.
SystèmeFilstok/sEfficacité par cœur
POWER10/11113,913,9 tok/s/cœur
POWER91217,61,5 tok/s/cœur

Ce n’est pas une concurrence avec une A100 — cela comble un fossé entièrement différent : exécuter l’inférence de LLMs sur l’infrastructure IBM POWER que vous possédez déjà. Sans budget GPU, sans slot PCIe, sans maux de tête liés aux drivers. Pour les organisations avec des serveurs POWER9, POWER10 ou POWER11 existants, c’est la voie vers l’IA privée sans investissement en capital supplémentaire.

Nous avons également testé Qwen2.5-7B-Instruct (7 milliards de paramètres) sur un seul cœur POWER10 — il a chargé et tourné à 1,0 tok/s. Insuffisant pour une utilisation interactive sur un cœur, mais preuve que les modèles plus grands fonctionnent. Avec davantage de cœurs, cela évolue linéairement. Nos clients disposant de systèmes IBM POWER en production nous posent régulièrement la question : puis-je utiliser ce matériel pour de l’IA ? La réponse est désormais oui.

À noter que les nouveaux serveurs IBM Power11 introduisent la carte accélératrice Spyre — un matériel dédié à l’IA qui viendra compléter cette approche CPU dans les prochains mois.

Dans la machine

Ce qui se passe vraiment quand POWER10/11 exécute un modèle de langage

Si vous avez vu les présentations IBM sur l’IA en POWER, vous avez probablement rencontré les termes MMA, Spyre, oneDNN et OpenShift AI. Ils apparaissent souvent sur la même diapositive. Que signifient-ils réellement ? Et lesquels sont actifs quand vous exécutez python3 -m vllm ?

Nous avons plongé dans la pile logicielle pour répondre à cette question. Les résultats nous ont surpris.

Lexique rapide sans jargon superflu

  • LLM (grand modèle de langage) — Logiciel qui génère du texte : ChatGPT, Llama, Qwen. Un modèle mathématique avec des milliards de nombres qui prédit le mot suivant.
  • Inférence — Exécuter un modèle déjà entraîné pour obtenir des réponses. L’entraînement apprend au modèle ; l’inférence l’utilise. Cet article parle uniquement d’inférence.
  • Token — Un mot ou un fragment de mot. « 17,6 tokens par seconde » correspond à environ 17-18 mots par seconde.
  • BF16 (bfloat16) — Une façon de stocker des nombres sur 16 bits au lieu de 32. Moitié moins de mémoire, précision quasi identique. En résumé : « qualité suffisante à la moitié du coût de stockage ».
  • GEMM (multiplication générale de matrices) — L’opération mathématique centrale des réseaux de neurones. La majeure partie du temps de calcul en inférence LLM est consacrée à la multiplication de grandes matrices.
  • MMA (Matrix-Multiply Accumulate) — Circuits dédiés à l’intérieur de POWER10 et POWER11 conçus pour accélérer les calculs matriciels. Comme une calculatrice spécialisée pour l’opération précise qui domine l’inférence LLM.
  • OpenBLAS — Une bibliothèque mathématique open source avec des routines GEMM optimisées. Le moteur qui effectue la vraie multiplication de matrices sur POWER.
  • oneDNN — La bibliothèque mathématique d’Intel, également compilée dans vLLM. Un autre moteur pour le même usage.
  • PyTorch — Le framework qui exécute le réseau de neurones. Il appelle OpenBLAS ou oneDNN pour les calculs intensifs.

Comment les pièces s’assemblent

Quand vLLM génère un token, voici le chemin exact à travers la machine :

Vous tapez une question
↓
vLLM la reçoit et la découpe en tokens
↓
PyTorch exécute les calculs du réseau de neurones
↓
Pour chaque couche : multiplication de grandes matrices (GEMM)
↓
PyTorch demande à OpenBLAS : « multiplie ces deux matrices BF16 »
↓
OpenBLAS exécute sbgemm_kernel_power10 ← ICI MMA EST UTILISÉ
↓
Le matériel POWER10/11 exécute les instructions MMA
↓
Le résultat remonte, le token suivant est choisi
↓
Vous voyez le mot suivant apparaître
L’accélération MMA est déjà active dans nos benchmarks. Ce n’est pas une fonctionnalité future ni un flag de configuration — elle fonctionne dès maintenant, via le chemin PyTorch → OpenBLAS → matériel MMA. Aucune configuration spéciale requise.

La preuve : BF16 vs FP32 sur POWER10/11

Sur POWER10 et POWER11, MMA accélère les calculs BF16. Sur POWER9 (sans MMA), BF16 est en réalité plus lent que FP32 à cause de l’émulation logicielle. Si MMA fonctionne, BF16 devrait être plus rapide :

# Benchmark de multiplication de matrices (1024×1024) sur POWER10
BF16 : 384,4 GFLOPS  (5,6 ms)
FP32 : 249,6 GFLOPS  (8,6 ms)
Ratio BF16/FP32 : 1,54×

BF16 est 1,54× plus rapide que FP32. MMA est actif et fournit une accélération mesurable. Nos 13,9 tok/s sur un seul cœur POWER10 incluent déjà MMA. C’est le chiffre réel, accéléré par le matériel. Les capacités d’accélération IA de POWER10 et POWER11 sont au cœur de nos formations Linux sur IBM POWER Systems disponibles en français.

L’investigation oneDNN (et ce que nous avons appris)

Nous pensions initialement qu’il restait des performances inexploitées.

La build vLLM intègre oneDNN (initialement d’Intel). À l’intérieur, il existe deux chemins mathématiques spécifiques à POWER :

  • GEMM int8 : Un noyau écrit à la main par des ingénieurs IBM utilisant les instructions MMA pour les modèles quantifiés.
  • GEMM BF16 : Un passage direct à OpenBLAS — mais seulement quand compilé avec des flags spécifiques.

Notre build initiale n’avait pas ces flags. Nous avons recompilé avec -DDNNL_BLAS_VENDOR=OPENBLAS, confirmé que les flags étaient actifs, re-benchmarké — mêmes performances.

Pourquoi ? PyTorch allait déjà directement à OpenBLAS, contournant oneDNN pour les opérations matriciales principales. L’optimisation était déjà là ; nous ne le savions simplement pas.

Conclusion pratique : Vous n’avez rien de spécial à configurer. PyTorch sur POWER10 et POWER11 avec OpenBLAS utilise automatiquement MMA pour l’inférence BF16. Installez le paquet et exécutez.

Et IBM Spyre ?

IBM Spyre est une carte accélératrice IA dédiée pour POWER — un matériel entièrement séparé avec son propre silicium pour les calculs IA. La distinction clé :

  • MMA = accélération intégrée dans chaque cœur POWER10 et POWER11 (active dès maintenant dans nos benchmarks)
  • Spyre = carte accélératrice IA séparée ajoutée au système (prometteuse, mais nécessite des piles logicielles IBM spécifiques)

Notre travail se concentre sur ce qui est disponible aujourd’hui en utilisant le CPU déjà dans votre machine, sans investissement matériel supplémentaire.

Le tableau complet

TechnologieCe que c’estActive dans notre build ?
POWER10/11 MMA (BF16)Accélérateur matriciel intégré dans le CPUOui — PyTorch → OpenBLAS
POWER10/11 MMA (int8)Même matériel, pour les modèles 8 bitsCompilé, pas encore bout en bout
IBM SpyreCarte accélératrice IA séparéeNon — matériel différent
OpenShift AIPlateforme ML complète sur KubernetesNon — nous sommes l’alternative légère
oneDNNBibliothèque mathématique intégrée à vLLMCompilée, contournée par PyTorch
OpenBLASBibliothèque mathématique avec noyaux POWER10/11 écrits à la mainOui — le vrai moteur

Contexte

Vue d’ensemble : inférence LLM sur IBM POWER sans OpenShift

Red Hat OpenShift AI

Jusqu’ici, la proposition officielle d’IBM/Red Hat pour l’inférence LLM sur IBM POWER était OpenShift AI. Il supporte les notebooks, pipelines, entraînement de modèles, serving et monitoring. Depuis la version 3.0, il tourne sur ppc64le avec des charges de travail CPU uniquement.

OpenShift AI est le bon choix pour les organisations qui ont déjà des clusters OpenShift. Il vient avec RBAC, InstructLab pour le fine-tuning de modèles et un support enterprise.

Mais il requiert OpenShift. Un cluster Kubernetes, un abonnement Red Hat, la gestion des opérateurs. Pour beaucoup d’environnements POWER — notamment ceux qui tournent sous Linux standalone ou des environnements mixtes AIX/Linux — c’est un engagement significatif juste pour servir un modèle. Ces organisations font justement appel au service de maintenance et support IBM POWER de SIXE pour maintenir leur infrastructure opérationnelle.

Ce qu’apporte LibrePower

Nous ne remplaçons pas OpenShift AI. Nous le complétons avec un chemin plus léger pour les nombreux environnements POWER qui n’ont pas besoin de la plateforme complète.

OpenShift AILibrePower vLLM
InstallationCluster OpenShift + opérateursapt install python3-vllm
InfrastructureKubernetes obligatoireN’importe quel Ubuntu/Debian ppc64le
PérimètreCycle ML completInférence uniquement
SupportAbonnement Red HatCommunauté (open source)
GPUSupporté (x86)CPU uniquement (POWER natif)
Temps jusqu’à la première inférenceHeures ou joursMinutes
CoûtLicences OpenShiftGratuit

IBM construit l’autoroute — matériel de premier plan, wheels PyTorch, OpenShift AI, InstructLab. LibrePower ajoute une bretelle d’accès pour ceux qui n’ont pas besoin de la plateforme complète. La feuille de route IA d’IBM POWER avance rapidement, et les outils communautaires comme celui-ci comblent des lacunes réelles dans l’écosystème actuel. Pour une vue d’ensemble de l’évolution de POWER avec Power10 et Power11, consultez notre article sur les nouveaux serveurs IBM Power10.

L’infrastructure

Fonctionnement du dépôt de paquets LibrePower

Nous avons construit librepower.org en suivant le même modèle que notre dépôt de paquets AIX — une infrastructure qui distribue déjà plus de 30 paquets open source à des systèmes AIX dans le monde entier.

linux.librepower.org/
  dists/jammy/
    InRelease          (signé avec GPG)
    Release
    main/binary-ppc64el/
      Packages
  pool/main/
    python3-vllm_0.9.2-1_ppc64el.deb
  install.sh

Le CI/CD tourne sur GitLab : chaque push régénère les métadonnées APT et déploie automatiquement. Tous les paquets compilés sur du vrai matériel IBM POWER — pas de compilation croisée, pas d’émulation. Le code source complet est sur GitLab sous licence Apache 2.0.

Feuille de route

La suite pour vLLM sur IBM POWER

  • Plus de modèles testés — Llama, Mistral, Phi, Granite. Benchmarks systématiques par famille de modèles.
  • llama.cpp pour ppc64le — Modèles GGUF quantifiés pour une empreinte mémoire encore plus faible. Déjà disponible pour AIX.
  • Support Ubuntu 24.04 et Debian 12 — Extension du paquet aux dernières versions LTS.
  • Variantes optimisées pour POWER10/11 — Approfondissement du tuning MMA. Nos 13,9 tok/s par cœur actuels sont un point de départ, pas un plafond.
  • GEMM int8 bout en bout — Finalisation de la voie MMA pour les modèles quantifiés, ce qui devrait améliorer le débit.
Vous avez un IBM POWER et souhaitez déployer de l’IA ?
SIXE accompagne les organisations dans le déploiement et l’exploitation de Linux sur IBM POWER — de la formation officielle IBM en français au support d’infrastructure complet, en passant par Paris, Bruxelles et Luxembourg. Si vous évaluez l’inférence LLM sur du matériel POWER existant, parlez-nous de votre projet.

Vous avez un système ppc64le ?

Essayez vLLM sur IBM POWER dès maintenant

Si vous avez un système sous Ubuntu, c’est trois commandes. Le code source est sur GitLab si vous souhaitez approfondir ou contribuer. Formation et support infrastructure IBM POWER par SIXE.

# Ajouter le dépôt LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Installer vLLM pour ppc64le
sudo apt update && sudo apt install python3-vllm

# Installer PyTorch (wheels IBM)
pip3 install torch --extra-index-url \
  https://wheels.developerfirst.ibm.com/ppc64le/linux

# Lancer le serveur d'inférence compatible OpenAI
python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --device cpu --dtype bfloat16 --port 8000
librepower.org
Code source GitLab
Newsletter
librepower.org
Support IBM POWER SIXE →

Qu’est-ce qu’une usine IA et comment la construire avec l’open source

/dans /par


Infrastructure IA · Mars 2026

Qu’est-ce qu’une usine IA et comment la construire avec l’open source dans votre datacenter

Le concept d’AI Factory est sur toutes les lèvres depuis deux ans — mais peu d’organisations comprennent réellement ce qu’il implique techniquement, ni comment le mettre en œuvre sans dépendre d’un fournisseur cloud. Voici une explication sans détour, avec le stack concret que nous utilisons en production.

Mars 2026●20 min de lecture

Une usine IA n’est pas un serveur équipé d’un GPU avec un modèle téléchargé depuis Hugging Face. C’est une infrastructure de calcul distribuée, conçue pour exécuter des modèles de langage et de vision en production de façon continue, à grande échelle et sous contrôle total de l’organisation. La bonne nouvelle : la construire n’est plus réservé aux géants du numérique. La technologie open source qui propulse l’AI Factory du Barcelona Supercomputing Center et les programmes d’infrastructure souveraine à travers l’Europe est accessible à toute organisation disposant de son propre datacenter. Ce qui suit est un guide pratique : ce dont vous avez besoin, ce dont vous n’avez pas besoin, et comment décider si cela a du sens pour vous.

Un peu de contexte

Qu’est-ce qu’une usine IA exactement ?

Le terme « AI Factory » a été popularisé par Jensen Huang de NVIDIA en 2023 pour décrire ce que deviennent les centres de données : des machines qui produisent de l’intelligence en continu, à la manière d’une usine qui fabrique des biens. La métaphore n’est pas poétique — elle est techniquement précise.

Une usine IA classique comprend quatre composantes distinctes : un système de stockage pour les poids des modèles et les datasets (qui pèsent des dizaines voire des centaines de gigaoctets), une couche de calcul GPU pour exécuter l’inférence, un orchestrateur qui gère quel modèle tourne sur quel matériel, et une API qui expose les modèles au reste de l’organisation. Quand ces quatre composantes fonctionnent efficacement ensemble, vous avez une usine IA.

Ce qui la distingue d’un « LLM qui tourne sur un serveur », c’est l’échelle, la fiabilité et la gestion. Une usine IA sert plusieurs modèles en parallèle, gère des files d’attente de requêtes, garantit la disponibilité et surveille l’utilisation des ressources. C’est de l’infrastructure de production — pas un environnement de test.

Chiffre clé

La Commission européenne a engagé plus de 1,5 milliard d’euros pour construire des AI Factories réparties dans les États membres dans le cadre du programme EuroHPC. L’objectif explicite est que l’Europe dispose d’une infrastructure IA souveraine, sans dépendance envers les fournisseurs américains ou asiatiques. L’Espagne participe via le BSC à Barcelone. La même stack technologique qu’ils utilisent peut être déployée dans votre datacenter.

Pourquoi rapatrier l’inférence IA ?

Pourquoi les organisations rapatrient leur inférence IA on-premise

Trois arguments reviennent systématiquement dans chaque conversation que nous avons avec des clients qui évaluent une infrastructure IA propre. Ce ne sont pas des arguments marketing : ce sont des réalités opérationnelles et financières.

💸

Coûts prévisibles

Les factures GPU en cloud public peuvent varier de 30 à 40 % d’un cycle de facturation à l’autre selon la demande. Avec une infrastructure propre, le coût est fixe, amortissable et sans surprise. À partir d’un volume d’inférence moyen, l’investissement est récupéré en 12 à 18 mois par rapport au cloud.

🔓

Zéro vendor lock-in

APIs propriétaires, formats fermés, modèles fine-tunés hébergés chez un tiers. Avec un stack open source, vos modèles et vos données vous appartiennent — toujours portables, sans négociations de sortie ni contrats bloquants.

🏛️

Conformité réglementaire

Le RGPD et l’AI Act exigent de savoir précisément où les données sont traitées. Si votre inférence touche des données de patients, de citoyens ou de clients bancaires, vous avez besoin d’un contrôle total sur l’infrastructure. L’on-premise est la seule réponse architecturalement viable.

AI Act — sanctions actives depuis août 2025

Depuis le 2 août 2025, la deuxième phase de l’AI Act est entrée en vigueur : les règles sur les modèles GPAI et les premières sanctions sont applicables. Les amendes peuvent atteindre 35 millions d’euros ou 7 % du chiffre d’affaires mondial en cas de non-conformité. La Belgique ne dispose pas encore de législation nationale spécifique, mais les obligations européennes s’appliquent sans exception. La maîtrise de l’infrastructure d’inférence est le premier levier de conformité.

La question n’est plus de savoir s’il faut construire sa propre infrastructure IA, mais quand et comment le faire sans répéter les erreurs de la ruée vers le cloud il y a dix ans : vitesse sans architecture.
— Équipe technique SIXE

Cela dit, une usine IA on-premise n’est pas adaptée à tout le monde. Si vous traitez dix requêtes d’inférence par jour et n’avez pas de contraintes réglementaires strictes, le cloud est probablement la bonne réponse pour l’instant. L’on-premise commence à avoir du sens quand les volumes sont soutenus, quand les données sont sensibles, ou quand vous devez faire tourner des modèles fine-tunés propriétaires sans exposer les poids à des tiers.

Concrètement, comment ça se construit ?

Le stack open source : trois technologies, zéro dépendance propriétaire

Une combinaison de trois technologies a émergé comme standard de facto pour construire des usines IA on-premise dans les environnements d’entreprise européens. Le même stack que le BSC. Le même que celui qui propulse les infrastructures souveraines en France, en Allemagne et en Italie. Et le même que celui que nous déployons chez SIXE.

Ceph : le stockage distribué conçu pour l’IA

Les modèles de langage sont lourds. Llama 3 70B occupe environ 40 Go en précision float16. Mixtral 8x7B avoisine les 90 Go. Un catalogue raisonnable de modèles pour une organisation de taille moyenne peut facilement dépasser 500 Go — sans compter les datasets de fine-tuning ni les journaux d’inférence.

Ceph résout ce problème avec un stockage distribué qui unifie l’object storage (compatible S3 nativement), le block storage et le filesystem dans un seul cluster. Il évolue des téraoctets aux pétaoctets sans interruption, supporte l’erasure coding pour l’efficacité du stockage et dispose d’une intégration native avec Kubernetes via CSI. Dans une usine IA, Ceph constitue la colonne vertébrale où résident les poids des modèles, les datasets et les résultats d’inférence.

Perspective SIXE

Nous sommes Canonical Partner et déployons des clusters Ceph en production depuis des années, y compris dans des environnements IA et HPC. Ceph ne s’active pas d’un simple clic : il nécessite un dimensionnement soigné, une conception réseau adaptée et des politiques de réplication calibrées à la charge. Sur les clusters à 3 nœuds, les considérations de quorum ne s’improvisent pas. Nous proposons une formation dédiée et un support pour que votre équipe opère Ceph en toute autonomie — sans dépendance de conseil permanente.

OpenStack : votre cloud privé avec gestion native des GPU

OpenStack transforme votre matériel en cloud privé d’entreprise. Pour une usine IA, son rôle principal est la gestion des ressources GPU : PCI passthrough pour un accès direct au GPU depuis les VMs, vGPU pour partager un GPU physique entre plusieurs charges de travail, et NVIDIA MIG (Multi-Instance GPU) pour partitionner les GPU A100 et H100 en instances indépendantes.

Sous la Linux Foundation depuis 2024, OpenStack fonctionne en production sur plus de 45 millions de cœurs dans des organisations comme Walmart, GEICO ou LINE Corp. Il ne s’agit pas d’une technologie émergente — c’est une infrastructure éprouvée à grande échelle, avec une gouvernance indépendante qui en garantit la pérennité.

Point d’attention

OpenStack n’est pas trivial. Il couvre plus de 30 projets de services et nécessite des équipes expérimentées en systèmes distribués. Si votre équipe vient d’un environnement VMware, la courbe d’apprentissage existe. Notre service de formation couvre la montée en compétences pratique pour que votre équipe puisse opérer le stack en autonomie — sans dépendance de conseil à long terme.

Kubernetes + vLLM : la couche d’orchestration de l’inférence

Kubernetes est le standard CNCF pour l’orchestration de charges de travail conteneurisées, avec planification GPU native via le NVIDIA GPU Operator. Les moteurs d’inférence sont déployés sur Kubernetes — et vLLM est le plus pertinent pour les modèles de langage actuellement.

vLLM implémente PagedAttention, une technique qui gère efficacement la mémoire KV cache et permet de servir plusieurs requêtes en parallèle sans gaspiller la VRAM. En production, vLLM atteint 3 à 5 fois le débit d’une implémentation naïve du même modèle. Il expose une API compatible OpenAI, ce qui facilite la migration des applications qui consomment déjà GPT-4 ou des modèles similaires.

Pour les modèles de vision ou d’embedding, Triton Inference Server de NVIDIA complète vLLM et permet des optimisations matérielles spécifiques comme TensorRT-LLM.

Quelle forme prend concrètement une usine IA ?

Architecture de référence : de la donnée au modèle en production

Une usine IA on-premise avec ce stack suit un flux en quatre couches. Ce n’est pas le seul design possible, mais c’est celui qui équilibre le mieux la complexité opérationnelle, les performances et la portabilité.

01 — Données

Ceph S3

Modèles, datasets, résultats d’inférence. API compatible S3 pour l’intégration avec les pipelines MLOps.

02 — Calcul

OpenStack

Planification GPU, bare metal, réseaux isolés par projet. PCI passthrough et MIG pour une efficacité maximale.

03 — Orchestration

Kubernetes

GPU Operator, autoscaling des pods d’inférence, gestion du cycle de vie des déploiements.

04 — Production

vLLM / Triton

APIs d’inférence, RAG, agents. Compatibilité OpenAI pour une intégration sans friction.

La clé de ce design : chaque couche est indépendante et remplaçable. Si demain un meilleur orchestrateur que Kubernetes émerge pour les charges IA, vous pouvez le substituer sans toucher au stockage ni à la couche de calcul. C’est ce que signifie vraiment l’absence de vendor lock-in : pas seulement que le logiciel est open source, mais que l’architecture dispose d’une réelle séparation des responsabilités.

Composant
Rôle dans l’usine IA
Alternatives viables
Gouvernance

Ceph
Stockage des modèles et des données
IBM Storage Scale (GPFS)
Linux Foundation

OpenStack
Cloud privé avec gestion GPU
MaaS + bare metal direct
OpenInfra / LF

Kubernetes
Orchestration de conteneurs
MicroK8s, OpenShift
CNCF / LF

vLLM
Moteur d’inférence LLM
Triton, TensorRT-LLM
Apache 2.0

Ubuntu / Canonical
OS de base + support du stack
RHEL, SUSE
Canonical Partner

Est-ce adapté à mon organisation ?

Qui a réellement besoin d’une usine IA on-premise

Tous les secteurs n’ont pas la même urgence ni les mêmes contraintes. Dans quatre domaines, l’infrastructure IA propre n’est pas une préférence — c’est la seule réponse architecturalement viable.

🏥

Santé et pharma

Dossiers cliniques, imagerie diagnostique, données génomiques. Le RGPD et le règlement européen sur l’espace des données de santé imposent des restrictions strictes sur les transferts vers des pays tiers. L’inférence on-premise est l’architecture de conformité par défaut.

🏦

Banque et assurance

Scoring de crédit, détection de fraude, analyse de risque. Les lignes directrices de l’ABE sur l’IA dans les services financiers et l’AI Act classent ces systèmes comme à haut risque, avec des exigences de traçabilité et de contrôle que seule une architecture on-premise peut satisfaire.

🏛️

Secteur public et défense

Souveraineté numérique, NIS2, données classifiées. La stratégie européenne d’IA exige que les systèmes IA à usage public opèrent sur une infrastructure européenne ou nationale. Sans discussion possible.

🏭

Industrie et manufacture

Vision artificielle en ligne de production, maintenance prédictive, contrôle qualité. La latence du cloud n’est pas viable quand vous avez besoin d’une réponse en millisecondes sur le site de production. L’inférence edge ou dans votre propre datacenter est le seul modèle qui fonctionne.

FAQ

Les questions à se poser avant de commencer

Construire une usine IA on-premise n’est pas un projet de week-end. Cela nécessite une analyse préalable honnête sur quatre dimensions qui déterminent si c’est pertinent et comment bien l’exécuter.

Quels modèles allez-vous servir et à quels volumes ?

Le dimensionnement GPU dépend directement de la taille des modèles (nombre de paramètres et précision) et des objectifs de débit (requêtes par seconde, latence P99 acceptable). Un modèle de 7 milliards de paramètres en float16 tient dans un seul GPU L40S de 48 Go de VRAM. Un modèle de 70 milliards nécessite plusieurs GPU avec du tensor parallelism. Il n’y a pas de raccourcis ici : un dimensionnement correct exige de connaître les charges réelles, pas des estimations optimistes.

Votre équipe a-t-elle la capacité d’opérer ce stack ?

C’est la question la plus importante — et celle que l’on pose le moins souvent. Une équipe avec une expérience en Linux, Kubernetes et systèmes distribués peut apprendre à opérer ce stack. Mais si vous partez de zéro, la courbe d’apprentissage doit être intégrée au plan, pas oubliée. SIXE propose des formations certifiées en Ceph, OpenStack et Kubernetes (en tant qu’IBM Business Partner et Canonical Partner) précisément pour que la transition ne crée pas de dépendance de conseil indéfinie.

Quel est le TCO réel sur 3 ans ?

Le logiciel est open source, donc il n’y a pas de coûts de licences. L’investissement porte sur le matériel (GPU, serveurs, réseau haute performance) et la montée en compétences de l’équipe. Comparé au coût des GPU cloud au même volume d’inférence sur cette période, les chiffres parlent généralement d’eux-mêmes. Mais le modèle financier doit inclure la maintenance, les mises à jour et le temps d’exploitation de l’équipe. Rien n’est gratuit — et les projets qui partent de ce postulat se retrouvent souvent face à de mauvaises surprises.

Comment nous travaillons chez SIXE

Avant tout déploiement, nous réalisons une évaluation d’architecture : nous auditons vos charges de travail réelles, vos exigences de latence, vos volumes de données et vos obligations réglementaires. Nous livrons un design complet — dimensionnement GPU, topologie réseau, architecture de stockage Ceph et plan de capacité sur 12 à 24 mois. Pas de promesses d’économies non calculées. Seulement une analyse technique sur la pertinence du projet et la façon de l’exécuter.

Vous avez un projet d’inférence IA ?

Votre usine IA, avec le stack que nous utilisons nous-mêmes

IBM Business Partner et Canonical Partner. Plus de 15 ans à déployer de l’open source en production. Nous concevons l’architecture, formons votre équipe et vous accompagnons jusqu’à ce que l’infrastructure fonctionne seule. Notre travail se termine quand le vôtre commence vraiment.

Voir le service d’inférence →
Écrivez-nous sur WhatsApp

10 erreurs d’architecture et de ROI dans l’exode post-VMware

/dans , /par
Analyse technique · Février 2026

10 erreurs d’architecture et de ROI que personne n’a évaluées dans l’exode post‑VMware

Les alternatives VMware open source sont viables. Mais « viable » et « adapté à votre entreprise » sont des questions radicalement différentes qui exigent une analyse technique, financière et de gouvernance avant d’engager votre infrastructure pour une décennie.

Février 2026●25 min de lecture●Pour DSI, CTO et Directeurs d’Infrastructure
86 % des clients VMware réduisent activement leur empreinte. Seuls 4 % ont achevé la migration. Entre ces deux chiffres se trouve un gouffre de décisions techniques, financières et stratégiques que la plupart des organisations prennent avec plus de précipitation que de méthode. Cet article ne recommande aucune plateforme : il pose les questions que toute équipe dirigeante devrait se poser avant d’engager son infrastructure pour les 5 à 10 prochaines années. Spoiler : il n’y a pas de réponse magique, mais il y a un chemin raisonnable.

Erreur 01 sur 10

Confondre urgence et stratégie

L’acquisition de VMware par Broadcom en novembre 2023 pour 61 milliards de dollars a déclenché le plus grand séisme dans la virtualisation d’entreprise depuis plus d’une décennie. Et le mot « séisme » est encore en dessous de la réalité. Licences perpétuelles supprimées, ~8 000 SKUs consolidés en 4 bundles, minimum d’achat de 72 cœurs et hausses de prix rapportées entre 150 % et 1 500 %. Tesco a déposé une plainte de 100 millions de livres. Fidelity a alerté sur des risques pour 50 millions de clients. Autant dire que le paysage invitait à courir.

Et c’est exactement ce qui s’est passé : beaucoup ont couru, mais pas toujours dans la bonne direction. Une enquête CloudBolt (2026) a révélé que 63 % ont changé leur stratégie de migration au moins deux fois (oui, deux fois). Gartner estime que la part de marché de VMware passera de 70 % à 40 % d’ici 2029, mais le chemin jusque-là est parsemé de virages qui méritent nettement plus de réflexion qu’ils n’en reçoivent.

Perspective SIXE

L’urgence créée par Broadcom est parfaitement compréhensible — personne n’aime voir sa facture multipliée du jour au lendemain. Mais chaque décision d’infrastructure prise sous pression devient de la dette technique que vos équipes hériteront pendant des années. La première bonne décision est de séparer la réponse tactique immédiate de la stratégie à moyen terme et d’évaluer chacune avec des critères différents. Respirez, planifiez, puis agissez.

Erreur 02 sur 10

Ignorer la gouvernance du projet open source

Tout l’open source ne se vaut pas — loin de là. La différence la plus pertinente pour une décision d’entreprise à long terme n’est pas la licence, mais quelque chose que presque personne ne vérifie : qui contrôle le projet et quels mécanismes protègent la communauté si les priorités commerciales changent.

Proxmox Server Solutions GmbH est une entreprise privée autrichienne avec un capital social de 35 000 € et une équipe estimée entre 14 et 24 personnes. Des gens formidables, certainement, mais il n’existe ni fondation indépendante, ni conseil de gouvernance ouvert, ni représentation communautaire dans les décisions de développement. Autrement dit : l’avenir de votre plateforme de virtualisation dépend des choix d’une seule entreprise.

Comparez avec la Fondation MariaDB, où aucune entreprise ne peut occuper plus de 25 % des sièges au conseil — un mécanisme qui a protégé le projet lorsque MariaDB Corporation a été rachetée par K1 en septembre 2024. Ou avec OpenStack, désormais sous la Linux Foundation, avec une gouvernance distribuée entre des centaines d’organisations. Ça, c’est un filet de sécurité.

Question clé

Votre plateforme de virtualisation — celle sur laquelle tourneront vos applications métier pendant les 10 prochaines années — est-elle gouvernée par une fondation indépendante, un consortium ou une seule entreprise privée de moins de 25 employés ? Ce n’est pas une question rhétorique : la réponse a des implications directes sur le risque de verrouillage fournisseur à long terme.

Erreur 03 sur 10

Ne pas lire le Contributor Licence Agreement

On sait — lire un CLA n’est pas exactement un programme de vendredi soir. Mais ça vaut le coup. Le CLA de Proxmox accorde à l’entreprise une licence perpétuelle, mondiale et irrévocable sur toutes les contributions, avec le droit de les relicencier sous des termes commerciaux ou propriétaires. Ce mécanisme n’est pas problématique en soi, mais c’est exactement la combinaison structurelle (entreprise unique + AGPL + CLA permissif) qui a précédé chaque changement de licence majeur des sept dernières années. C’est un peu comme voir les nuages d’orage s’accumuler et dire « je suis sûr qu’il ne pleuvra pas ».

ProjetAnnéeChangementConséquenceGouvernance
MongoDB2018AGPL → SSPLRetiré de Debian/Red HatSingle vendor
Elasticsearch2021Apache 2.0 → SSPLFork : OpenSearch (Linux Foundation)Single vendor
HashiCorp2023MPL 2.0 → BSLFork : OpenTofu · IBM : 6,4 Mds $Single vendor
Redis2024BSD → SSPLFork : Valkey (Linux Foundation)Single vendor
MinIO2021–26Apache → AGPL → AbandonnéDépôt : « NO LONGER MAINTAINED »Single vendor
Kubernetes——Apache 2.0 stableFondation (CNCF)
PostgreSQL——Licence PostgreSQL stableCommunauté
Linux——GPLv2 stableFondation (LF)

Vous voyez le schéma ? Il est assez limpide : aucun projet soutenu par une fondation indépendante n’a jamais subi un changement de licence unilatéral. Pas un seul. Ce constat devrait nourrir toute évaluation de risque, quelle que soit la plateforme envisagée.

Erreur 04 sur 10

Supposer que les coûts d’abonnement resteront stables

Toute entreprise qui développe du logiciel open source a besoin de monétiser son travail, et c’est parfaitement légitime — personne ne vit d’amour et d’eau fraîche. La question n’est pas de savoir si les prix augmenteront (ils augmenteront, comme partout), mais si vous les intégrez dans votre modèle de coût total de possession.

L’abonnement Community de Proxmox est passé de 49,90 € à 120 €/an (~140 % d’augmentation), et en janvier 2026, tous les niveaux ont augmenté de 3,8 à 4,3 %. Le nouveau Proxmox Datacenter Manager exige qu’au moins 80 % des nœuds disposent d’un abonnement Basic ou supérieur (370+ €/socket/an). Ça vous rappelle quelque chose ? À nous aussi.

OpenStack, Ceph et les autres alternatives VMware ont aussi leurs propres structures de coûts. Aucune plateforme n’est gratuite en production — si quelqu’un vous dit le contraire, souriez poliment et demandez la facture. La vraie différence réside dans les coûts prévisibles et ceux qui dépendent de décisions unilatérales.

Perspective SIXE

Lorsque nous évaluons des alternatives avec nos clients, nous modélisons toujours trois scénarios de coûts : optimiste, réaliste et défavorable, avec des projections à 5 et 10 ans intégrant d’éventuels changements de licences. Oui, c’est plus de travail. Mais c’est aussi la seule façon de construire un TCO qui ne s’effondre pas au premier changement de tarif.

Erreur 05 sur 10

Sous-estimer la complexité opérationnelle d’OpenStack

Soyons justes avec OpenStack : il tourne en production avec plus de 45 millions de cœurs dans des organisations comme Walmart, GEICO ou LINE Corp. Sa gouvernance — désormais sous la Linux Foundation — est parmi les plus solides de l’écosystème. Ce sont de véritables atouts.

Mais (il y a toujours un mais) le projet lui-même reconnaît que 44 % des fournisseurs IT et 39 % des entreprises déclarent avoir du mal à trouver des professionnels qualifiés. La plateforme comprend plus de 30 projets de services. Déployer et opérer ce stack nécessite des équipes expérimentées en systèmes distribués que la plupart des équipes VMware ne possèdent pas — non par manque de talent, mais parce que ce sont des compétences fondamentalement différentes. C’est comme demander à un brillant chef de cuisine méditerranéenne de concourir en sushi : les deux sont de la gastronomie de haut vol, mais les compétences ne se transfèrent pas automatiquement.

Nuance importante

OpenStack peut être le choix idéal pour les organisations avec l’échelle et les équipes adéquates. Le modèle managé (Canonical, Mirantis, Platform9) résout une partie de la complexité, mais ajoute des coûts et de la dépendance. La question n’est pas « OpenStack oui ou non ? » mais « nos équipes, notre budget et notre échelle correspondent-ils à ce qu’OpenStack exige pour briller ? »

Erreur 06 sur 10

Croire que Ceph, c’est « juste cocher la case »

Ceph est un système puissant qui tourne en production dans des environnements impressionnants : CERN, Bloomberg et DigitalOcean, entre autres. Mais la distance entre un cluster Ceph à hyperscale et un déploiement typique de 3 à 5 nœuds dans une migration VMware, c’est comme la distance entre piloter un Airbus et un ULM : les deux volent, mais les règles sont très différentes.

Les benchmarks StarWind en environnement Proxmox HCI montrent que Ceph a atteint 270 000 IOPS en charges mixtes 4K, contre 1 088 000 IOPS pour LINSTOR/DRBD et 1 199 000 pour StarWind VSAN. Et les risques des clusters de petite taille méritent une attention particulière : perdre un nœud dans un cluster de 3 avec réplication 3x peut laisser le système en lecture seule. Pas exactement ce qu’on souhaite un lundi à 3 h du matin.

Les alternatives à considérer incluent LINSTOR/DRBD avec des performances proches du natif, StorPool avec des latences sub-100 µs, et IBM Storage Virtualize avec une intégration entreprise éprouvée. Chacun a ses forces, ses limites et ses exigences d’expertise.

Perspective SIXE

La couche de stockage est sans doute la décision la plus critique et la moins réversible de toute la migration. C’est là qu’on ne peut pas se permettre d’improviser. Elle doit être évaluée avec des tests réels sur des charges de travail réelles — pas avec des benchmarks génériques ni des « ça marche super bien chez quelqu’un que je suis sur LinkedIn ». C’est précisément là qu’un intégrateur expérimenté sur plusieurs plateformes de stockage apporte le plus de valeur.

Erreur 07 sur 10

Ne pas inventorier les fonctionnalités entreprise qui disparaissent

VMware a passé plus d’une décennie à construire des fonctionnalités sur lesquelles de nombreuses organisations ont bâti leurs processus opérationnels. Ce sont ces choses qui « marchent tout simplement » — jusqu’à ce qu’elles ne soient plus là. Et quand elles disparaissent, l’impact va bien au-delà de la technologie.

⚖️

Équilibrage automatique (DRS)

Proxmox n’a pas d’équivalent natif : il faut du scripting maison. OpenStack offre une fonctionnalité partielle via le scheduling Nova. Dans les deux cas, retroussez vos manches.

🛡️

Tolérance aux pannes et DR

VMware FT/SRM fournissent un basculement automatique. Les alternatives open source nécessitent une orchestration manuelle avec réplication ZFS, Ansible et runbooks. Ça fonctionne, mais quelqu’un doit le construire et le maintenir.

🌐

SDN et microsegmentation

Proxmox SDN supporte VLANs/VXLANs/EVPN, mais IPAM/DHCP sont en « tech preview » (comprendre : pas tout à fait prêt). Il n’y a pas d’équivalent au firewall distribué de NSX.

📋

Certifications éditeurs

SAP, Oracle et Microsoft ne certifient pas Proxmox. NVIDIA AI Enterprise n’est pas officiellement supporté non plus. Si vous dépendez de ces certifications, c’est un détail qu’il vaut mieux ne pas négliger.

🔧

Automatisation et API

Les providers Terraform pour Proxmox sont maintenus par la communauté. L’API exige de spécifier manuellement le nœud cible. Rien de rédhibitoire, mais ces frictions s’additionnent.

📞

Support 24/7

Proxmox fonctionne en horaires autrichiens (7 h–17 h CET), sans option 24/7 à aucun niveau. Quand la production tombe à 3 h du matin, il n’y a littéralement personne à appeler. Et non, Google ne compte pas.

Aucune de ces limitations n’invalide la plateforme — soyons clairs. Mais chacune représente un écart à combler par de l’ingénierie, des outils ou du conseil, et chaque solution de contournement a un coût qui doit figurer dans votre modèle financier. Faire comme si elles n’existaient pas, c’est la recette idéale pour des surprises désagréables.

Erreur 08 sur 10

Calculer le ROI uniquement sur la ligne des licences

Les économies sur les licences sont réelles. Mais présenter ces économies comme le ROI du projet, c’est comme évaluer un déménagement au seul prix du camion : techniquement correct, pratiquement incomplet.

Gartner estime que les services de migration coûtent entre 300 et 3 000 dollars par VM. 44 % des organisations subissent des interruptions non planifiées pendant la migration. Et les projets estimés à 6 mois se transforment régulièrement en 24 — un constat désormais très documenté.

Les coûts cachés qui érodent votre ROI

Formation : 5 000–15 000 $/ingénieur + 3–6 mois de productivité réduite (votre équipe apprend vite, mais pas du jour au lendemain). Intégration : sauvegarde, supervision, CMDB, automatisation — des connecteurs matures pour VMware qui n’existent tout simplement pas pour Proxmox. Développement sur mesure : scripts d’équilibrage, DR, monitoring = dette technique interne. Turnover : quand l’ingénieur qui les a construits s’en va, le savoir-faire part avec lui. Et c’est toujours au pire moment.

Erreur 09 sur 10

Concevoir pour le Jour 1 et oublier le Jour 2

La migration n’est que le début — la lune de miel, si vous voulez. Le vrai coût se manifeste dans les opérations quotidiennes, année après année.

Cybernews a révélé que de nombreuses organisations ayant migré vers Proxmox ne maintiennent pas les mises à jour de sécurité. C’est compréhensible : quand tout l’effort se concentre sur la migration, on oublie facilement qu’ensuite, il faut encore opérer. À grande échelle, l’interface devient peu réactive avec plusieurs milliers de VMs, et pmxcfs atteint ses limites autour de 11 000 VMs.

🔐

Sécurité et conformité

Gestion des CVE, durcissement, audits (ISO 27001, RGPD, NIS2). Quel SLA de réponse aux vulnérabilités critiques chaque plateforme offre-t-elle ? Question gênante, mais indispensable.

📊

Télémétrie et observabilité

Les alternatives open source (Prometheus, Grafana, Zabbix) sont excellentes — elles le sont vraiment — mais elles nécessitent intégration et maintenance dédiées. Elles ne se configurent pas toutes seules.

💾

Sauvegarde et restauration

Proxmox Backup Server est fonctionnel, mais il joue dans une autre catégorie d’écosystème comparé à Veeam, Commvault ou IBM Spectrum Protect.

🏗️

Dette technique

Chaque script personnalisé est du code à maintenir, documenter, tester et transmettre. La dette technique est invisible jusqu’à ce qu’elle ne le soit plus — et alors, c’est la seule chose que vous voyez.

Erreur 10 sur 10

Croire que la technologie est la décision

Migrer depuis VMware n’est pas un projet technologique : c’est une transformation opérationnelle qui touche les personnes, les processus, les fournisseurs, les budgets et les risques. La technologie compte, bien sûr. Mais ce n’est qu’une pièce du puzzle.

La migration VMware n’est pas un problème technologique. C’est un problème de découplage opérationnel déguisé en problème technologique.— Keith Townsend, The CTO Advisor

Les questions qui comptent vraiment : quel niveau de risque de gouvernance est acceptable pour nous ? Avons-nous l’équipe nécessaire — ou pouvons-nous la former à temps ? Quel est notre TCO réel à 5 et 10 ans ? Comment protégeons-nous l’investissement si le projet open source change de cap ? Quelles charges de travail migrons-nous d’abord, et lesquelles ne devraient peut-être jamais bouger ? Et qui sera notre partenaire technique quand les choses ne se passeront pas comme prévu ? (Parce qu’à un moment, ça arrivera. C’est la vie.)

Notre conviction

L’open source est, sans aucun doute, la bonne réponse pour l’infrastructure du futur. Nous n’avons aucun doute là-dessus. La question n’est pas de savoir s’il faut migrer, mais comment le faire avec la rigueur que la décision mérite. La différence entre une migration réussie et une qui génère des années de maux de tête tient à la qualité de l’analyse en amont, à l’architecture choisie et à l’accompagnement expert tout au long du processus. Et si après avoir lu tout ça, vous avez envie d’en discuter, nous sommes là.

La meilleure migration est celle qui se fait avec discernement, pas dans la précipitation

Plus de 15 ans de conception, de déploiement et d’exploitation d’infrastructures critiques. Nous connaissons VMware, Proxmox, OpenStack, Ceph, IBM Storage et les alternatives parce que nous travaillons avec toutes. Aucune préférence : uniquement la solution qui correspond à votre entreprise.

Parlons de votre cas →
Découvrir SIXE
Liquid AI’s New Model on IBM AIX

Liquid AI LFM2.5 sur IBM Power9 AIX : 27 tokens/s sans GPU

/dans /par

Oublions un instant les clusters de H100. Chez SIXE, nous avons décidé de pousser le matériel d’entreprise à ses limites absolues pour répondre à une question brûlante : Un IBM Power System de 2018, fonctionnant sous AIX et reposant uniquement sur le CPU, peut-il gérer les modèles d’IA de dernière génération ?

Nous avons pris le nouveau modèle LFM2.5-1.2B de Liquid AI et l’avons exécuté sur un processeur IBM POWER9. À notre connaissance, c’est la première fois qu’un modèle LFM2.5 fonctionne sous AIX en mode Big-Endian.

Le résultat

Près de 27 tokens par seconde, des réponses cohérentes et moins de 750 Mo d’utilisation mémoire. Pas de GPU. Pas de NPU. Juste la puissance brute de l’architecture Power.

Mais la vitesse brute n’est que la moitié de l’histoire. Pour prouver qu’il ne s’agit pas d’un simple jouet de benchmark, nous avons soumis LFM2.5 à un « Défi SysAdmin » — de vraies tâches d’administration AIX — et l’avons comparé à un Transformer standard (TinyLlama 1.1B). Les résultats ont été choquants.

L’ingrédient secret : qu’est-ce que LFM2.5 ?

LFM2.5 est une architecture hybride conçue pour une efficacité maximale, mélangeant des blocs convolutifs (shortconv) pour la vitesse et des couches d’attention (GQA) pour le contexte. Il dispose d’une énorme fenêtre de contexte de 128k tokens — suffisante pour lire des milliers de lignes de logs sans oublier le début.

Le matériel : IBM Power System S924

Nous avons utilisé le cheval de bataille du monde de l’entreprise. Voici les configurations spécifiques utilisées pour ce benchmark :

SpécificationValeur
ServeurIBM Power System S924
ProcesseurIBM POWER9 @ 2.75 GHz
ConfigurationEnterprise Multi-Core (compatible SMT-8)
Système d’exploitationAIX 7.3 TL4
ArchitectureBig-Endian

Performance : trouver le point optimal

Nous avons découvert que mobiliser tous les cœurs sur le modèle nuit en réalité aux performances en raison de la surcharge de synchronisation. Le verdict était clair : utiliser seulement 8 cœurs en mode SMT-2 (16 threads) nous a donné 26,7 tokens par seconde.

Test en conditions réelles : le défi de l’administrateur système

Les chiffres c’est bien, mais est-ce que ça fonctionne vraiment ? Nous avons exécuté exactement les mêmes prompts à travers LFM2.5-1.2B et TinyLlama 1.1B (un transformer pur de taille similaire). Voici les sorties brutes.

Round 1 : L’erreur cryptique (errpt)

Nous avons fourni aux modèles un log d’erreur AIX brut concernant une défaillance d’alimentation.

L’entrée :

$ errpt -a -l BFE4C025

Description: Power/Cooling subsystem Unrecovered Error,
             bypassed with loss of redundancy.
Possible FRUs:
  Priority: H
  FRU:      PWRSPLY
  Location: U78D2.001.WZS00P4

❌ TinyLlama 1.1B :

“7. What is the location of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY. 8. What is the description of the FRU that is affected by this error? The FRU that is affected by this error is PWRSPLY…”

Verdict : Échec. Il s’est bloqué dans une boucle infinie répétant “PWRSPLY”.

✅ LFM2.5 1.2B :

“What is the likely cause? The error usually points to a problem with the power or cooling hardware (like a fan or power supply) that couldn’t be fixed automatically. It might be a hardware failure or a misconfiguration. What action should I take? First, check the hardware — look at the fans (especially the power fans)…”

Verdict : Réussite. Il a identifié le composant et donné des conseils actionnables pour vérifier les ventilateurs.

Round 2 : L’audit de sécurité (last)

Nous avons fourni un historique de connexions contenant un événement de crash caché.

L’entrée :

$ last -20

root   pts/0   10.10.10.1   Jan 28 11:14 - 18:38 (07:23)
reboot ~                     Jan 28 11:12
root   pts/0   10.10.10.1   Jan 27 22:09 - System halted abnormally. (13:03)

❌ TinyLlama 1.1B :

(a généré 1 token puis s’est arrêté)

Verdict : Échec. Silence absolu.

✅ LFM2.5 1.2B :

“Suspicious patterns: The system was halted abnormally on Jan 27. This could indicate a security incident or a misconfiguration. Security recommendations: Investigate the cause of the system halt on Jan 27. Review the login history for any unauthorized access attempts.”

Verdict : Réussite. Il a immédiatement repéré l’arrêt anormal du 27 janvier et recommandé une investigation.

Round 3 : Le conseil dangereux (/etc/passwd)

Nous avons demandé aux modèles d’auditer un fichier de mots de passe standard. Les résultats ici ont été choquants.

L’entrée :

$ cat /etc/passwd

root:!:0:0::/:/usr/bin/bash
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
...

❌ TinyLlama 1.1B :

“1. root:!:0:0::/:/usr/bin/bash — This user is not required for system maintenance and should be removed. 2. daemon:!:1:1::/etc: — This user is not required for system maintenance and should be removed.”

Verdict : ÉCHEC CATASTROPHIQUE. Il a affirmé que l’utilisateur “root” n’était pas nécessaire et a recommandé de le supprimer. Suivre ce conseil détruirait le serveur.

✅ LFM2.5 1.2B :

“Unauthorized or suspicious accounts: You should be very concerned about the presence of the following accounts: guest with a high UID (100), nobody with a high UID (4294967294)… These accounts are either misconfigured, potentially malicious, or not needed.”

Verdict : Réussite. Il a correctement identifié les risques potentiels réels comme les comptes “guest” et “nobody” avec des UID élevés.

Round 4 : Durcissement des services (lssrc -a)

Nous avons demandé aux modèles de passer en revue les services en cours d’exécution et de recommander des étapes de durcissement.

L’entrée :

$ lssrc -a

Subsystem    Group      Status
sendmail     mail       active
portmap      portmap    active
inetd        tcpip      active
snmpd        tcpip      active

❌ TinyLlama 1.1B :

(a généré 0 tokens)

Verdict : Échec. Silence à nouveau.

✅ LFM2.5 1.2B :

“1. sendmail Risk: Running mail daemon can be a target for attacks. Recommendation: Disable sendmail. stopsrc -s sendmail 2. portmap Risk: Running portmap daemon can be abused… stopsrc -s portmap”

Verdict : Réussite. Il a signalé des services à risque comme sendmail et portmap, et a fourni la commande AIX correcte (stopsrc) pour les désactiver.

Pourquoi c’est important pour les utilisateurs d’IBM Power

Ce benchmark prouve que les IBM Power Systems sont des moteurs d’inférence IA capables pour des tâches critiques sur site :

Souveraineté des données : Analysez les logs errpt sensibles, les données financières ou les audits d’utilisateurs localement. Aucune donnée ne quitte votre serveur.

Modernisation du legacy : Utilisez des LLM locaux pour aider à comprendre et documenter le code legacy COBOL ou C résidant sur le serveur.

Efficacité : Vous n’avez pas besoin d’un cluster de GPU. Vous possédez probablement déjà le matériel capable de faire cela.

Essayez-le vous-même

Nous croyons en l’open source. Nous avons publié le port AIX et les modèles convertis en Big-Endian.

Code : gitlab.com/librepower/llama-aix

Modèles : huggingface.co/librepowerai

user@aix:~$ # Démarrage rapide sur AIX
user@aix:~$ git clone https://gitlab.com/librepower/llama-aix.git
user@aix:~$ ./scripts/build_aix_73.sh

user@aix:~$ # Optimiser le threading pour le "point optimal"
user@aix:~$ smtctl -t 2 -w now

user@aix:~$ # Amusez-vous bien !
Systèmes flash 2026

Nouveau IBM FlashSystem 2026 – 5600, 7600 et 9600

/dans /par

IBM vient de dévoiler à Varsovie la nouvelle génération d’IBM FlashSystem. Trois nouveaux modèles (5600, 7600 et 9600), un moteur d’IA intégré baptisé FlashSystem.ai, la cinquième génération de son unité flash propriétaire et un message qui sonne très bien en keynote : « stockage autonome co-piloté par l’IA agentique ».

Nous travaillons avec les baies FlashSystem au quotidien. Mais c’est justement pour cette raison qu’une analyse sérieuse s’impose ;) Décortiquons ensemble ce qui se cache derrière chaque chiffre et où se trouve la vraie valeur ajoutée.

Ce qu’apporte IBM et pourquoi c’est le plus grand lancement en six ans

IBM n’exagère pas en affirmant que c’est son lancement le plus important depuis 2020. Ce n’est pas un simple rafraîchissement cosmétique : ce sont trois baies simultanées, une refonte complète de l’unité flash et une couche d’IA qui va bien au-delà de ce que proposait la génération précédente.

L’idée de fond est que la baie de stockage cesse d’être « une armoire qui stocke des données » et devienne un système qui analyse, optimise et se protège de manière autonome.

Sam Werner, Directeur Général d’IBM Storage, a été assez clair lors de la présentation : il ne s’agit pas de remplacer l’administrateur, mais de le libérer des tâches répétitives pour qu’il puisse consacrer son temps à l’architecture et à la planification.

Ça ressemble à un slide de keynote ? Un peu. Mais les chiffres matériels qui se cachent derrière sont réels et, dans certains cas, véritablement impressionnants.

Les trois modèles FlashSystem de 2026 : FlashSystem 5600, 7600 et 9600

La nouvelle gamme remplace les FlashSystem 5300, 7300 et 9500 avec des améliorations substantielles en capacité, densité et efficacité. Les trois modèles adoptent le format d’unités NVMe EDSFF (Enterprise and Data Center SSD Form Factor), le standard de l’industrie pour une densité et un refroidissement optimaux en environnement de centre de données :

FlashSystem 5600FlashSystem 7600FlashSystem 9600
Format1U · 12 disques2U · 32 disques2U · 32 disques (avant 4U)
CPU2×12 cœurs Intel Xeon · PCIe Gen 42×16 cœurs AMD EPYC · PCIe Gen 52×48 cœurs AMD EPYC · PCIe Gen 5
Capacité brute633 To1,68 Po3,37 Po (vs 1,8 Po du 9500)
Capacité utilisable400 Tou1,2 Pou2,4 Pou
Capacité effectiveJusqu’à 2,4 PoeJusqu’à 7,2 PoeJusqu’à 11,8 Poe
IOPS2,6 millions4,3 millions6,3 millions
Débit lecture30 Go/s55 Go/s86 Go/s (vs 100 Go/s du 9500)
Ports16× FC ou 20× Ethernet32× FC ou Ethernet32× FC ou Ethernet (vs 48 du 9500)
Cas d’usageEdge, sites distants, petits DCVirtualisation, analytiqueBanque, ERP, charges IA

Un saut générationnel intéressant : les 7600 et 9600 embarquent AMD EPYC avec PCIe Gen 5, tandis que le 5600 reste sur Intel Xeon et PCIe Gen 4. C’est logique par segment — le PCIe Gen 5 double la bande passante par lane, mais pour le cas d’usage edge du 5600, le Gen 4 est plus que suffisant et contribue probablement à maintenir le prix contenu.

Le chiffre le plus frappant est le FlashSystem 5600 qui loge 2,4 Poe dans 1U. Pour les environnements edge ou les centres de données avec des contraintes d’espace, cela change la donne. Et le 9600 passe de 4U à 2U tout en doublant quasiment la capacité brute (de 1,8 Po à 3,37 Po). C’est du progrès réel, pas du marketing.

Cela dit, une nuance importante : les capacités « effectives » (Poe) supposent des taux de déduplication et de compression qui dépendent énormément du type de données. Avec des données déjà compressées ou chiffrées, les 11,8 Poe du 9600 se réduisent à ses 2,4 Pou (utilisables) ou 3,37 Po bruts. C’est de la physique, pas de la magie. IBM le précise en notes de bas de page, mais il convient de le garder bien à l’esprit.

Un autre détail intéressant passé largement inaperçu : le 9600 passe de 48 à 32 ports d’E/S et son débit de lecture maximal passe de 100 Go/s à 86 Go/s par rapport au 9500. C’est un compromis de conception : plus de densité au prix d’un peu de connectivité brute. Selon votre architecture, cela peut compter ou non, mais il vaut mieux le savoir.

Les modèles 7600 et 9600 intègrent des façades LED interactives pour visualiser l’état du système. Cela semble être un détail mineur, mais tout administrateur qui a dû identifier un châssis à 3 heures du matin dans un datacenter l’appréciera.

Famille nouveau IBM FlashSystem 2026 modèles 5600 7600 9600 vue frontale avec façades LED interactives

Nouveaux IBM FlashSystem 2026 — modèles 5600, 7600 et 9600

FlashCore Module 5 : du QLC qui performe comme du TLC (et pourquoi c’est important)

C’est ici qu’IBM dispose d’un avantage concurrentiel qui n’est pas du vent : ils conçoivent et fabriquent leurs propres unités flash. Et dans le nouveau FlashCore Module de cinquième génération (FCM5), cela se traduit par quelque chose de très concret.

Le FCM5 est disponible en capacités de 6,6 / 13,2 / 26,4 / 52,8 et 105,6 To au nouveau format NVMe EDSFF. Ce dernier chiffre, 105 To par unité, est le plus élevé de l’industrie pour les charges de travail entreprise. Comment y parviennent-ils ? En utilisant du NAND QLC avec une propriété intellectuelle propriétaire qui performe comme du TLC.

Pour ceux qui ne vivent pas le stockage au quotidien : le QLC (Quad-Level Cell) est plus dense et moins cher que le TLC (Triple-Level Cell), mais offre normalement une endurance en écriture moindre et des performances inférieures. Les concurrents utilisant du QLC standard le limitent aux charges en lecture intensive. IBM, en contrôlant la conception de l’unité de bout en bout, a réussi à surmonter cette limitation. De fait, selon les propres chiffres d’IBM, les FCM obtiennent 5,5 fois plus de cycles d’écriture que les unités QLC standard du marché.

Alistair Symon, VP du développement des systèmes de stockage, l’a expliqué lors du briefing pré-lancement : d’autres fabricants proposent des unités QLC de plus grande capacité, mais étant du QLC standard, elles ne supportent pas les charges d’écriture intensives sur la durée d’amortissement du matériel. Les FCM5 d’IBM, si.

Qu’intègre encore le FCM5 directement dans le matériel ?

  • Chiffrement quantum-safe pour toutes les données, directement sur l’unité
  • Compression accélérée par le matériel
  • Déduplication embarquée (nouveauté de cette génération), permettant des taux de réduction de 5:1
  • Analyse des E/S accélérée par le matériel : statistiques complexes sur chaque opération sans impact sur les performances

En déchargeant ces opérations sur le module flash au lieu de les exécuter sur les contrôleurs de la baie, IBM libère de la puissance de calcul pour les charges de travail des clients. C’est la même philosophie appliquée avec les générations précédentes de FCM pour la détection d’anomalies, mais poussée un cran plus loin avec la déduplication intégrée.

FlashSystem.ai : l’IA agentique dans la baie, entre promesses et réalité

FlashSystem.ai est la nouvelle couche de services de données alimentée par l’IA agentique (nous aussi, nous déployons des agents IA en entreprise, au passage). Selon IBM, elle a été entraînée sur des dizaines de milliards de points de télémétrie et des années de données opérationnelles réelles. Le système exécute des milliers de décisions automatisées par jour qui nécessitaient auparavant une supervision humaine.

Les capacités les plus intéressantes :

  • S’adapte au comportement des applications en quelques heures, et non en semaines comme les systèmes basés sur des modèles
  • Recommande des optimisations de performance en expliquant son raisonnement (cela permet d’auditer les décisions de l’IA, crucial pour la conformité)
  • Intègre le retour d’expérience de l’administrateur pour affiner ses recommandations dans le temps
  • Placement intelligent des charges de travail avec mobilité des données non disruptive, y compris vers des baies tierces
  • Réduit de moitié le temps de documentation pour les audits et la conformité

Et bien sûr, le chiffre phare : réduction de 90 % de l’effort de gestion manuel. C’est un chiffre spectaculaire, mais qui s’accompagne d’une note de bas de page qui mérite une lecture attentive. IBM le mesure en comparant des tâches routinières spécifiques (provisionnement de volumes avec politiques de copie protégée et DR) sur la nouvelle génération avec FlashSystem.ai vs. la même génération sans FlashSystem.ai. C’est une comparaison interne, en laboratoire, sur des opérations sélectionnées.

Cela signifie-t-il que les 90 % sont inventés ? Non. Cela signifie que c’est le meilleur scénario sur des tâches précises. En exploitation réelle, avec ses intégrations, ses particularités et l’entropie naturelle de toute infrastructure, le bénéfice sera moindre. Il restera probablement significatif — l’automatisation des tâches répétitives apporte une valeur réelle — mais n’attendez pas que votre admin stockage ne travaille plus qu’un jour par semaine.

Il y a quelque chose que nous trouvons véritablement utile : le raisonnement opérationnel explicable. Le système ne se contente pas d’agir — il explique pourquoi. Pour les audits et la conformité (qui pèsent de plus en plus dans les secteurs régulés, comme l’exige la CNIL et les réglementations européennes), disposer d’un journal généré par l’IA des décisions opérationnelles est un avantage réel face à la concurrence.

Détection de ransomware en 60 secondes : les données et les astérisques

Un autre chiffre accrocheur : le FCM5 détecte les ransomware en moins d’une minute. Regardons cela de plus près.

Le système analyse chaque opération d’E/S directement dans le matériel, recherchant des schémas anormaux associés au chiffrement malveillant. Le modèle de détection (version 3.3, lancé au T4 2025) cumule 24 mois d’entraînement avec de la télémétrie de production et maintient un taux de faux positifs inférieur à 1 %, mesuré sur 3 mois.

Combiné à Safeguarded Copy (des copies avec un air gap logique, immuables et invisibles depuis toute connexion externe), IBM affirme qu’il est possible de récupérer d’une attaque en moins d’une minute.

Maintenant, les astérisques qu’IBM met en notes de bas de page :

  • Le test original de détection sub-minute a été réalisé sur un FlashSystem 5200 (génération précédente) avec un simulateur de ransomware propriétaire d’IBM baptisé WannaLaugh. Oui, il s’appelle vraiment comme ça. Points bonus pour le nom.
  • La détection porte sur le début du processus de chiffrement, et non sur l’intrusion initiale dans le système.
  • Un ransomware suffisamment sophistiqué qui chiffre lentement et imite des schémas d’écriture normaux pourrait potentiellement échapper à la détection.

Cela étant dit — et c’est important — disposer d’une détection au niveau matériel avec moins de 1 % de faux positifs est objectivement excellent. La plupart des solutions de détection de ransomware du marché opèrent au niveau du système de fichiers ou du réseau, avec des latences supérieures et des taux d’erreur plus élevés. IBM opère une couche plus bas, directement au niveau des E/S du stockage. En tant que couche supplémentaire dans une stratégie de défense en profondeur, cela apporte une valeur réelle que la concurrence ne peut pas facilement reproduire car elle ne contrôle pas le matériel de ses unités flash.

L’argument qui n’apparaît pas dans les datasheets : la chaîne d’approvisionnement

Un angle qui peut être plus pertinent que n’importe quel benchmark pour de nombreux responsables informatiques en 2026 : la crise d’approvisionnement en stockage. La demande de capacité pour l’entraînement de modèles d’IA génère des pénuries et des hausses de prix sur les SSD à l’échelle mondiale.

Werner a été direct à ce sujet : IBM est mieux positionné que la plupart des concurrents car il fabrique ses propres unités flash.

Si vous planifiez une extension de capacité sur les 12 à 18 prochains mois et que vous faites face à des délais de 6 mois sur des SSD standard, avoir un fournisseur qui contrôle la fabrication de ses unités est un argument qui n’apparaît dans aucun comparateur Gartner mais qui peut définir un projet.

Pure Storage, Dell, NetApp et les autres — et maintenant ?

Le marché des baies all-flash entreprise est très disputé. Comparons ce qui différencie réellement le nouveau FlashSystem du reste :

AspectIBM FlashSystem (nouveau)Pure Storage FlashArrayDell PowerStoreNetApp AFF
Unités propriétaires✅ FlashCore Module (QLC→TLC)✅ DirectFlash (150 To)❌ SSD standard❌ SSD standard
IA de gestionFlashSystem.ai (agentique)Pure1 MetaCloudIQBlueXP / AIOps
Détection ransomware HW✅ Sur l’unité flash❌ Logiciel❌ Logiciel❌ Logiciel (ONTAP)
Support baies tierces✅ +500 fabricants❌ Écosystème ferméPartielPartiel (FabricPool)
Chiffrement quantum-safe HW✅❌❌❌
Modèle de licenceTraditionnel IBMEvergreen (très transparent)APEX / traditionnelKeystone / traditionnel

Là où IBM prend clairement l’avantage :

Le FlashCore Module est un avantage réel et difficile à reproduire. Contrôler la conception de l’unité flash permet d’intégrer des fonctionnalités au niveau matériel (détection de ransomware, chiffrement quantum-safe, déduplication) que la concurrence ne peut faire qu’en logiciel. Pure Storage conçoit également ses propres unités (DirectFlash), mais à ce jour n’intègre ni la détection de ransomware ni le chiffrement post-quantique dans le matériel.

La compatibilité avec plus de 500 fabricants de stockage tiers via FlashSystem Grid est un choix judicieux. En conditions réelles, personne ne dispose d’un environnement homogène, et pouvoir déplacer des données de manière non disruptive entre des baies IBM et celles d’autres fabricants résout un vrai problème de consolidation et de migration.

Là où la concurrence résiste :

  • Pure Storage obtient systématiquement de meilleures évaluations en termes d’expérience utilisateur et son modèle Evergreen est difficile à battre en transparence de licences. Si le prix et la simplicité contractuelle sont vos priorités, Pure reste un rival redoutable.
  • NetApp dispose d’ONTAP, un système d’exploitation de stockage d’une maturité remarquable dans les environnements hybrides avec une base installée considérable. Pour ceux qui sont déjà dans l’écosystème NetApp, migrer est difficile à justifier uniquement par de nouvelles fonctionnalités.
  • Dell PowerStore est compétitif en prix et dispose d’une intégration profonde avec l’écosystème VMware (désormais Broadcom), qui reste l’hyperviseur dominant dans de nombreuses organisations.

En résumé : IBM ne balaie pas la concurrence, mais avec cette génération, il se positionne avec des arguments techniques solides qui vont au-delà du marketing, en particulier sur la sécurité au niveau matériel et la flexibilité multi-fournisseurs.

FlashCore Module 5 d'IBM unité flash propriétaire pour nouveau IBM FlashSystem avec détection ransomware matérielle

FlashCore Module 5 d’IBM

À qui s’adresse-t-il ?

Après avoir digéré toutes ces informations, voici les scénarios où le nouveau FlashSystem s’impose le mieux :

  • Environnements critiques (banque, assurance, santé) où la combinaison de détection de ransomware matérielle, Safeguarded Copy et chiffrement quantum-safe apporte des couches de sécurité que la concurrence n’égale pas au même niveau.
  • Organisations avec une infrastructure hétérogène qui doivent consolider sans tout remplacer. La compatibilité avec +500 fabricants et la mobilité des données entre baies est un argument authentique.
  • Datacenters avec des contraintes d’espace où la densité du 5600 (2,4 Poe dans 1U) peut éviter des extensions physiques.
  • Entreprises qui travaillent déjà avec l’infrastructure IBM Storage et qui cherchent une évolution naturelle intégrée à leurs investissements existants, notamment en combinaison avec SVC ou d’autres solutions du portfolio.

Et qui devrait y réfléchir à deux fois ? Si votre environnement est 100 % virtualisé avec VMware et que toute votre gestion passe par vCenter, l’intégration avec Dell peut avoir plus de sens sur le plan opérationnel. Si votre priorité est la simplicité contractuelle et que votre équipe est réduite, le modèle Evergreen de Pure Storage est difficile à battre.

Conclusions

IBM a fait ses devoirs avec ce lancement. La combinaison du matériel propriétaire (FCM5 avec du QLC qui performe comme du TLC), de l’IA agentique intégrée (FlashSystem.ai) et de la stratégie de compatibilité multi-fournisseurs positionne le nouveau FlashSystem comme une proposition sérieuse.

Est-ce parfait ? Non. Le marketing gonfle certains chiffres (comme tout le monde, ne nous voilons pas la face), l’étiquette de « stockage autonome » est plus aspirationnelle que descriptive, et tant que nous n’aurons pas vu des benchmarks indépendants et des retours d’expérience terrain avec des mois d’exploitation, certaines affirmations restent des promesses.

Mais si l’on met tout dans la balance : la technologie est solide, l’architecture fait sens, la direction est la bonne. Et le fait qu’IBM contrôle depuis la conception de l’unité flash jusqu’à la couche d’IA en passant par le système d’exploitation SVC lui confère une cohérence de stack que peu de fabricants peuvent offrir.

Disponibilité générale : 6 mars 2026.

Vous évaluez le nouveau IBM FlashSystem ou planifiez une migration ?

Chez SIXE, nous travaillons depuis des années avec les baies IBM FlashSystem dans des environnements de production réels. Nous concevons, déployons, migrons et assurons le support technique IBM Storage sans intermédiaire. Si vous avez besoin de conseils sur la manière dont cette nouvelle génération s’intégrerait dans votre infrastructure, n’hésitez pas à nous contacter.

Stockage distribué 2026. Un guide technique (controversé)

/dans /par

Une autre année vivante, une autre année à regarder l’industrie du stockage distribué se surpasser en créativité commerciale. Si 2024 était l’année où tout le monde a découvert qu’il fallait du “stockage pour l’IA” (spoiler : c’est le même vieux stockage, mais avec un meilleur marketing), 2025 est l’année où MinIO a décidé de s’immoler publiquement pendant que le reste de l’écosystème continue d’évoluer à un rythme soutenu.

Accrochez-vous, ça va secouer !

Tendances et courbes du marché du stockage distribué 2026

Le Drame de l’Année : MinIO Passe en « Mode Maintenance » (Lire : Mode Abandon)

Si tu n’as pas suivi le feuilleton MinIO, laisse-moi te donner un peu de contexte. MinIO était le stockage d’objets open source que tout le monde déployait. Simple, rapide, compatible avec S3. Tu le mettais en place et en service en 15 minutes. C’était le WordPress du stockage objet.

Annonce MinIO mode maintenance capture d'écran Reddit décembre 2025

Eh bien, en décembre 2025, un commit silencieux dans le README a tout changé : « Ce projet est actuellement en maintenance et n’accepte pas de nouvelles modifications. » Pas d’annonce. Pas de guide de migration. Pas d’adieu. Juste un commit et un simple au revoir.

La communauté, sans surprise, s’est enflammée. Un développeur a parfaitement résumé la situation : « Une mise à jour silencieuse du README vient de mettre fin à l’ère de MinIO en tant que moteur S3 open-source par défaut. »

Mais cela ne s’est pas fait du jour au lendemain. MinIO poursuivait depuis des années une stratégie « open source mais sans en faire trop » :

  • 2021 : Passage silencieux d’Apache 2.0 à AGPL v3 (pas d’annonce, pas de PR, rien)
  • 2022-2023 : Campagnes agressives contre Nutanix et Weka pour « violation de licence »
  • Février 2025 : Console Web, gestion des buckets et réplication supprimées de la version communautaire
  • Octobre 2025 : Arrêt de la distribution des images Docker
  • Décembre 2025 : Mode maintenance

Le message est clair : si tu veux MinIO pour de vrai, paie. Leur produit entreprise AIStor commence à 96 000 €/an pour 400 TiB. Pour 1 PB, on parle de plus de 244 000 €/an.

La leçon à retenir ? En 2025, « Open Source » sans gouvernance ouverte ne vaut rien. MinIO était une entreprise avec un produit open source, pas un projet communautaire. La différence est capitale.

Pendant Ce Temps, Ceph Continue de Nager Paisiblement

Pendant que MinIO s’autodétruisait, Ceph fêtait sa 20e version stable : Tentacle (v20.2.0), sortie en novembre 2025. Le projet accumule plus d’un exaoctet de stockage déployé à l’échelle mondiale sur plus de 3 000 clusters.

Mascotte Ceph Tentacle version v20.2.0 novembre 2025

L’élément le plus intéressant de Tentacle est FastEC (Fast Erasure Coding), qui améliore les performances des petites lectures et écritures de 2x à 3x. Cela rend l’erasure coding enfin viable pour les charges de travail qui ne sont pas du stockage froid pur. Avec un profil EC 6+2, tu peux désormais obtenir environ 50 % des performances de la réplication 3 tout en utilisant seulement 33 % de l’espace.

Pour ceux d’entre nous qui entendent depuis des années que « le codage par effacement est lent pour la production », cela change vraiment la donne.

Autres nouveautés de Tentacle :

  • Prise en charge intégrée de SMB via Samba Manager
  • Groupes de passerelles NVMe/TCP avec prise en charge multi-namespace
  • Authentification OAuth 2.0 sur le tableau de bord
  • Répertoires CephFS insensibles à la casse (enfin !)
  • ISA-L remplace Jerasure (qui a été abandonné)

Le Crimson OSD (basé sur Seastar pour l’optimisation NVMe) est encore en avant-première technique. Il n’est pas prêt pour la production, mais la feuille de route est prometteuse.

Les Chiffres Qui Comptent

Bloomberg exploite plus de 100 Po dans des clusters Ceph. Ils sont membre Diamant de la Fondation Ceph et leur responsable de l’ingénierie du stockage siège au conseil d’administration. DigitalOcean possède plus de 54 Po dans 37 clusters de production. Le CERN maintient 50+ Po dans plus de 10 clusters.

Et voici la partie intéressante : ZTE Corporation fait partie des 3 premiers contributeurs mondiaux à Ceph et est numéro 1 en Chine. Son produit TECS CloveStorage (basé sur Ceph) est déployé dans plus de 320 projets NFV dans le monde, notamment chez China Mobile, izzi Telecom (Mexique) et Deutsche Telekom.

Le secteur des télécoms est la superpuissance secrète de Ceph. Alors que beaucoup pensent encore aux appliances traditionnelles, les télécoms font tourner Ceph en production à grande échelle.

L’Écosystème Entreprise : Comprendre Ce Que Tu Achètes

C’est là que les choses deviennent intéressantes. Et il vaut la peine de comprendre ce qui se cache derrière chaque option.

Comparatif marché stockage entreprise bazaar 2026

IBM Fusion : Deux Saveurs pour Différents Besoins

IBM propose deux produits sous la marque Fusion, et il est important de comprendre la différence :

  • IBM Fusion HCI : utilise IBM Storage Scale ECE (l’ancien GPFS/Spectrum Scale). Système de fichiers parallèle avec erasure coding distribué. Appliance hyperconvergée qui évolue de 6 à 20 nœuds.
  • IBM Fusion SDS : utilise OpenShift Data Foundation (ODF), qui est basé sur Ceph packagé par Red Hat.

Storage Scale est une technologie véritablement différenciée, notamment pour le HPC. Son architecture de système de fichiers parallèle offre des capacités que Ceph n’a tout simplement pas : gestion avancée des métadonnées, tiering intégré, AFM pour la fédération… Si tu as des charges de travail de calcul haute performance, de supercalculateur ou d’IA à une échelle sérieuse, Storage Scale a de solides arguments techniques pour se justifier.

Les performances revendiquées par IBM Fusion HCI sont impressionnantes : accélération de 90x sur les requêtes S3 avec mise en cache locale, performances équivalentes à celles de Databricks Photon à 60 % du coût, etc.

Cependant, il vaut toujours la peine de se poser la question suivante : quelle est la part de cette performance qui relève de la technologie propriétaire et quelle est celle qui relève simplement d’un matériel bien dimensionné dans la bonne configuration ? Ce n’est pas une critique, c’est une question légitime que tout architecte devrait se poser avant de prendre une décision.

Dans le cas de Fusion SDS, tu achètes Ceph avec la valeur ajoutée du packaging, de l’intégration OpenShift et du support entreprise IBM. Pour de nombreuses organisations, cela a une réelle valeur.

Red Hat Ceph Storage : Le Standard Entreprise

Red Hat Ceph Storage continue d’être la distribution de choix pour les entreprises. Ils offrent 36 mois d’assistance production et 24 mois d’assistance étendue en option. Le produit est solide et bien intégré.

Ce que tu achètes réellement : des packages testés et certifiés, un support entreprise 24h/24 et 7j/7, des cycles de vie prévisibles et l’intégration OpenShift.

Est-ce que ça en vaut la peine ? Cela dépend de ton contexte. Si ton organisation a besoin d’un contrat de support pour la conformité ou simplement pour dormir tranquille, probablement oui. Et nous serions heureux de t’aider dans ce domaine. Mais si tu as l’équipe technique pour exploiter Ceph upstream, c’est une décision qui mérite d’être analysée.

SUSE : Une Leçon sur le Verrouillage Fournisseur

Voici une histoire qui mérite réflexion : SUSE a complètement quitté le marché entreprise Ceph. Leur produit SUSE Enterprise Storage (SES) a atteint la fin du support en janvier 2023. Après avoir acquis Rancher Labs en 2020, ils ont pivoté vers Longhorn pour le stockage natif Kubernetes.

Si tu étais client SES, tu t’es retrouvé orphelin. Tes options étaient de migrer vers Red Hat Ceph Storage, Canonical Charmed Ceph, Ceph communautaire, ou de trouver un partenaire spécialisé pour t’aider dans la transition.

Ce n’est pas une critique envers SUSE ; les entreprises pivotent selon leur stratégie. Mais c’est un rappel que le contrôle de ton infrastructure a une valeur qui n’apparaît pas toujours dans le TCO.

Pure Storage et NetApp : L’Approche Appliance

Pure Storage a créé une catégorie appelée « Unified Fast File and Object » (UFFO) avec sa famille FlashBlade. Matériel impressionnant, performances constantes, expérience utilisateur soignée. Son FlashBlade//S R2 évolue jusqu’à 60 Po par cluster avec des modules DirectFlash de 150 To.

NetApp StorageGRID 12.0 met l’accent sur l’IA avec des améliorations de débit de 20x via une mise en cache avancée et la prise en charge de plus de 600 milliards d’objets dans un seul cluster.

Les deux sont des solutions solides qui rivalisent avec Ceph RGW dans le stockage d’objets compatible S3. Les performances sont excellentes. La question que chaque organisation doit se poser est de savoir si le premium justifie le verrouillage fournisseur pour son cas d’utilisation spécifique.

La Question Que Personne Ne Pose : Qu’achètes-tu Vraiment ?

C’est ici que je mets mon chapeau d’ingénieur réfléchi.

Ceph upstream est extrêmement stable. Il compte 20 versions à son actif. La Fondation Ceph comprend IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud et des dizaines d’autres. Le développement est actif, la communauté est forte et la documentation est abondante.

Alors, quand est-il judicieux de payer pour une distribution entreprise et quand ne l’est-il pas ?

Cela a du sens lorsque : ton organisation a besoin d’un contrat de support pour la conformité ou une politique interne ; tu n’as pas le personnel technique pour faire fonctionner Ceph et tu ne veux pas le développer ; tu as besoin de cycles de mise à jour prévisibles et testés ; le coût de l’arrêt est plus élevé que le coût de la licence ; ou tu as besoin d’une intégration spécifique avec les produits d’autres fournisseurs.

Cela mérite une analyse plus approfondie lorsque : la décision est basée sur « c’est ce que tout le monde fait » ; personne n’a vraiment évalué les alternatives ; la raison principale est que « le fournisseur nous a dit que l’open source n’était pas supporté » ; ou tu disposes d’un équipement technique performant mais tu n’as pas investi dans sa formation.

Le vrai défi, c’est la connaissance. Ceph a une courbe d’apprentissage abrupte. Concevoir correctement un cluster, comprendre les CRUSH maps, régler BlueStore, optimiser les placement groups… tout cela nécessite une formation sérieuse et une expérience pratique.

Mais une fois que tu as ces connaissances, tu as des options. Tu peux choisir judicieusement un fournisseur entreprise, en sachant exactement quelle valeur ajoutée tu achètes. Ou tu peux opérer en upstream avec un support spécialisé. L’essentiel est de prendre une décision en connaissance de cause.

Démystifier les Affirmations Marketing

Une chose que je recommande toujours est de lire les benchmarks et les affirmations marketing avec un esprit critique constructif.

« Notre produit est 90x plus rapide » – Par rapport à quelle base de référence ? Sur quelle charge de travail spécifique ? Avec quelle configuration du concurrent ?

« Des performances équivalentes à celles de [concurrent] à 60 % du coût » – Cela inclut-il le TCO complet ? Licences, support, formation, personnel ?

« Solution certifiée de niveau entreprise » – Qu’est-ce que cela signifie exactement ? Parce que Ceph upstream est également de niveau entreprise au CERN, chez Bloomberg et dans des centaines de télécoms.

Je ne dis pas que ces affirmations sont fausses. Je dis que le contexte est important. En réalité, les performances du stockage distribué dépendent fortement de la conception correcte des clusters (domaines de défaillance, placement groups), du matériel approprié (réseau 25/100GbE, NVMe avec protection contre la perte de puissance), de la configuration du système d’exploitation (IOMMU, CPU governors) et du réglage spécifique à la charge de travail (osd_memory_target, paramètres BlueStore).

Un cluster Ceph bien conçu et géré par des personnes expérimentées peut atteindre des performances impressionnantes. Le benchmark Clyso a atteint 1 TiB/s avec 68 serveurs Dell PowerEdge. IBM a démontré plus de 450 000 IOPS sur un cluster Ceph à 4 nœuds avec 24 NVMe par nœud.

Parfois, cette estampille « solution certifiée » que tu vois sur une fiche technique est, au fond, un logiciel libre avec une configuration experte, un matériel bien dimensionné et beaucoup de tests. Cela a de la valeur, mais c’est bon de le savoir.

Une Décision Intelligente : Décider en S’informant

Après 15 ans dans ce secteur, ma conclusion est qu’il n’y a pas de réponse unique. Ce qu’il y a, ce sont des décisions éclairées.

Pour certaines organisations, une solution entreprise packagée est exactement ce dont elles ont besoin : un support garanti, des temps de cycle prévisibles, une intégration validée et la tranquillité d’esprit d’avoir un fournisseur responsable. IBM Fusion avec Storage Scale est un excellent choix pour le HPC. Red Hat Ceph Storage est une solution solide pour tous ceux qui veulent Ceph avec un backup entreprise.

Pour d’autres organisations, Ceph upstream avec un support et une formation spécialisés offre des avantages significatifs :

  1. Gouvernance de fondation : Ceph est un projet de la Linux Foundation avec une gouvernance ouverte. Le cas MinIO ne peut pas se produire.
  2. Communauté active : des milliers de contributeurs, des versions régulières, des bugs corrigés rapidement.
  3. Flexibilité : c’est ton cluster, ta configuration. Si demain tu décides de changer de partenaire de support, tu ne perds rien.
  4. TCO transparent : Le logiciel est gratuit. Tu investis dans le matériel et les connaissances appropriés.
  5. Contrôle des versions : Tu mets à jour quand cela te semble logique, et non pas quand le fournisseur sort la prochaine version packagée.

Le dénominateur commun dans les deux cas est la connaissance. Que tu achètes une solution entreprise ou que tu déploies upstream, une compréhension approfondie de Ceph te permet de prendre de meilleures décisions, de mieux négocier avec les fournisseurs et de résoudre les problèmes plus rapidement.

Où Trouver Ces Connaissances

Ceph est complexe. Mais il existe des chemins clairs :

La documentation officielle est très complète et s’est beaucoup améliorée. Le blog Ceph propose d’excellents approfondissements techniques.

Cephalocon est la conférence annuelle où tu peux apprendre de ceux qui exploitent Ceph à une échelle réelle (Bloomberg, CERN, DigitalOcean).

Une formation structurée avec des laboratoires pratiques est le moyen le plus efficace d’acquérir de réelles compétences. Tu n’apprends pas Ceph en lisant des diapositives ; tu l’apprends en cassant et en réparant des clusters.

L’assistance technique L3 assurée par des personnes qui vivent Ceph tous les jours te sort du pétrin quand les choses se compliquent en production. Parce qu’elles se compliqueront. Chez SIXE, nous avons passé des années à former des équipes techniques à Ceph et à fournir une assistance L3 à des organisations de tous types : celles qui opèrent upstream, celles qui utilisent des distributions entreprise et celles qui évaluent les options. Notre programme de formation Ceph couvre tout, de l’architecture de base aux opérations avancées, avec de véritables laboratoires pratiques. Et si tu as déjà Ceph en production et que tu as besoin d’une véritable assistance technique, notre support technique spécialisé est conçu exactement pour cela.

Nous venons également de lancer un programme de certification avec des badges sur Credly pour que ton équipe puisse démontrer ses compétences de manière tangible. Parce que dans ce secteur, « connaître Ceph » ne signifie pas la même chose pour tout le monde.

Badge de certification SIXE CEPH Administrator - Administration du stockage Ceph niveau entrée
Badge de certification SIXE CEPH Advanced Administrator - Niveau avancé d'administration du stockage Ceph
Badge de certification SIXE CEPH Production Operations - Niveau expert en opérations Ceph en production

Conclusions pour 2026

  1. MinIO est mort pour une utilisation sérieuse. Cherche des alternatives : Ceph RGW, SeaweedFS, Garage, ou même le fork RustFS si tu es courageux.
  2. Comprends ce que tu achètes. Il y a des cas où une solution entreprise packagée apporte une réelle valeur ajoutée. Il y en a d’autres où tu paies principalement pour un logo et une configuration que tu pourrais reproduire.
  3. Ceph upstream est mature et prêt pour la production. Bloomberg, DigitalOcean, le CERN et plus de 320 projets télécoms ne peuvent pas tous se tromper.
  4. Le véritable coût du stockage distribué est la connaissance. Investis dans une formation et un support de qualité, quelle que soit l’option choisie.
  5. Le contrôle de ton infrastructure a de la valeur. Demande aux clients de SUSE SES comment cela s’est passé lorsque le fournisseur a décidé de pivoter.
  6. La gouvernance du projet compte autant que la technologie. Fondation ouverte > entreprise avec un produit open source.

2026 s’annonce intéressant. FastEC va changer l’équation de l’erasure coding. L’intégration avec l’IA et le ML continuera de pousser vers plus de performance. Et l’écosystème des fournisseurs continuera d’évoluer avec des propositions qui méritent une évaluation sérieuse.

C’est à toi de décider. C’est la seule chose importante.

Portage de MariaDB vers IBM AIX (Partie 2) : comment AIX se met au niveau de Linux

/dans /par

De “AIX est lent” à “AIX égale Linux” (avec les bons outils et le bon code)

Dans la première partie, je me suis battu avec CMake, j’ai implémenté un pool de threads à partir de zéro et j’ai livré un serveur MariaDB 11.8.5 stable pour AIX. Le serveur a passé 1 000 connexions simultanées, 11 millions de requêtes et aucune fuite de mémoire.

Ensuite, j’ai effectué une recherche vectorielle de référence.

AIX: 42 requêtes par seconde.
Linux (même HW) : 971 requêtes par seconde.

Vingt-trois fois plus lent. Sur un matériel IBM Power S924 identique. Même version de MariaDB. Même jeu de données.

Voici l’histoire de la façon dont nous avons découvert qu’il n’y avait aucun écart de performance – juste des erreurs de configuration et un compilateur sous-optimal.

Chapitre 1 : Le sentiment d’affaissement

Il y a un genre particulier de désespoir qui vient quand on voit un écart de performance de 23x sur un matériel identique. C’est le genre de désespoir “j’aurais peut-être dû devenir fleuriste”.

Permettez-moi de planter le décor : les deux machines sont des LPARs fonctionnant sur des serveurs IBM Power S924 avec des processeurs POWER9 à 2750 MHz. Même MariaDB 11.8.5. Même ensemble de données de test – 100 000 vecteurs à 768 dimensions, utilisant l’index MHNSW (Hierarchical Navigable Small World) de MariaDB pour la recherche vectorielle.

Le critère de référence était simple : trouver les 10 voisins les plus proches d’un vecteur de requête. C’est le genre d’opération qui alimente toutes les fonctions de recherche améliorées par l’IA que tu as déjà utilisées.

Linux l’a fait en environ 1 milliseconde. AIX a mis 24 millisecondes.

Mon premier réflexe a été le déni. “Le repère doit être erroné”. Ce n’était pas le cas. “Peut-être que l’index est corrompu”. Ce n’était pas le cas. “Peut-être que le réseau est lent”. Il s’agissait d’une connexion locale.

Il est temps de creuser.

Chapitre 2 : Les premiers 65x – L’importance de la configuration

Le cache qui a tout oublié

Le premier indice est venu du profileur de MariaDB. Chaque requête prenait le même temps, qu’il s’agisse de la première ou de la centième. Ce n’est pas ainsi que fonctionnent les caches.

J’ai vérifié la configuration MHNSW de MariaDB :

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MO. Notre graphique vectoriel a besoin d’environ 300 Mo pour contenir la structure HNSW en mémoire.

C’est là que le bât blesse : lorsque le cache se remplit, MariaDB n’expulse pas les anciennes entrées (pas de LRU). Il jette tout et repart à zéro. Chaque. Chaque. Demande.

Imagine une bibliothèque où, lorsque les étagères sont pleines, le bibliothécaire brûle tous les livres et commande de nouveaux exemplaires. Pour chaque utilisateur.

Correction: mhnsw_max_cache_size = 4GB dans la configuration du serveur.

Résultat : 42 QPS → 112 QPS. Une amélioration de 2,7x à partir d’une seule ligne de configuration.

Le problème de la taille des pages

AIX utilise par défaut des pages de mémoire de 4 Ko. Linux sur POWER utilise des pages de 64 Ko.

Pour le modèle d’accès du MHNSW – la chasse aux pointeurs sur un graphique de 300 Mo – cela a une importance énorme. Avec des pages de 4 Ko, tu as besoin de 16x plus d’entrées TLB (Translation Lookaside Buffer) pour mapper la même quantité de mémoire. Les erreurs du TLB coûtent cher.

C’est comme si tu naviguais dans une ville. Avec des pages de 4 Ko, tu as besoin d’indications pour chaque bâtiment. Avec des pages de 64 Ko, tu obtiens des indications par quartier. C’est beaucoup plus rapide quand tu es constamment en train de sauter d’un bâtiment à l’autre.

Correction: script d’enrobage qui définit LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K

Résultat : 112 QPS → 208 QPS en séquentiel, et 2 721 QPS avec 12 travailleurs en parallèle.

Le tableau d’affichage après la phase 1

ConfigurationQPS séquentielAvec 12 travailleurs
Base de référence42~42
+ 4GB cache112–
+ 64K pages2082,721

Amélioration de 65x à partir de deux changements de configuration. Aucune modification du code.

Mais nous étions toujours 6x plus lents que Linux par cœur. L’enquête s’est poursuivie.

Chapitre 3 : Le mystère du décrochage entre le CPU et la mémoire

Une fois la configuration établie, j’ai sorti les outils de profilage. MariaDB possède un profileur intégré qui décompose le temps de requête par phase.

AIX:

Sending data: 4.70ms total
  - CPU_user: 1.41ms
  - CPU_system: ~0ms
  - Stalls: 3.29ms (70% of total!)

Linux:

Sending data: 0.81ms total
  - CPU_user: 0.80ms
  - Stalls: ~0.01ms (1% of total)

Le temps d’exécution de l’unité centrale était 1,8 fois plus lent sur AIX – ce qui peut s’expliquer par les différences de compilateur. Mais les blocages de la mémoire étaient 329 fois pires.

La cause première : Invalidation du cache de l’hyperviseur

Voici quelque chose que j’ai mis deux jours à comprendre : dans une LPAR (Logical Partition) partagée, l’hyperviseur POWER préempte périodiquement les processeurs virtuels pour donner du temps à d’autres partitions. Ce faisant, il peut invalider des lignes de cache L2/L3.

La traversée du graphe du MHNSW est une chasse aux pointeurs à travers 300 Mo de mémoire – littéralement le pire scénario pour l’invalidation de la mémoire cache. Tu sautes de nœud en nœud, chacun dans une partie différente de la mémoire, et l’hyperviseur vide périodiquement ton cache.

C’est comme essayer de lire un livre alors que quelqu’un ne cesse de le fermer et de le remettre sur l’étagère.

Le système Linux avait des processeurs dédiés. Le système AIX fonctionnait avec des processeurs partagés. Ce ne sont pas des pommes pour des pommes.

Mais avant de pouvoir tester les processeurs dédiés, je devais résoudre le problème du compilateur.

Chapitre 4 : L’odyssée du compilateur

Tout ce que j’ai essayé avec GCC (et pourquoi ça a échoué)

TentativeRésultatPourquoi
-flto (Optimisation du temps de connexion)ImpossibleGCC LTO nécessite le format ELF ; AIX utilise XCOFF
-fprofile-generate (PGO)Échec de la constructionErreurs de l’assembleur concernant la relocalisation relative au TOC
-ffast-mathTout se casse la figureIEEE float violations corrupt bloom filter hashing
-funroll-loopsPlus lentCache d’instruction gonflé – POWER9 n’aime pas ça
-finline-functionsPlus lentMême problème de cache I

La boîte à outils AIX GCC est construite sans support LTO. Ce n’est pas un drapeau que tu as oublié – c’est architecturalement impossible parce que l’implémentation LTO de GCC nécessite ELF, et AIX utilise XCOFF.

Les paquets MariaDB d’Ubuntu utilisent -flto=auto. Cette optimisation n’existe tout simplement pas pour AIX avec GCC.

IBM Open XL : Le rebondissement de l’intrigue

À ce stade, j’ai passé trois jours à essayer de rendre GCC plus rapide. Il est temps d’essayer quelque chose de différent.

IBM Open XL C/C++ 17.1.3 est le compilateur moderne d’IBM, basé sur LLVM/Clang. Il génère un code nettement meilleur pour POWER9 que GCC.

Pour construire MariaDB avec Open XL, il a fallu résoudre cinq problèmes différents :

  1. En-tête HTM manquant: Open XL n’a pas le fichier htmxlintrin.h de GCC. J’ai créé un stub.
  2. AR 32 bits par défaut: Les outils AIX sont par défaut en 32 bits. Définis OBJECT_MODE=64.
  3. Incompatibilité LLVM AR: Open XL’s AR ne pouvait pas gérer XCOFF. Utilise le système /usr/bin/ar.
  4. Conflits OpenSSL: Utilise -DWITH_SSL=system pour éviter les problèmes liés à WolfSSL.
  5. Chemins d’accès aux bibliothèques manquants: Explicit -L/opt/freeware/lib pour l’éditeur de liens.

Ensuite, j’ai exécuté le test de référence :

Compilateur30 requêtesPar requête
GCC 13.3.00.190s6.3ms
Open XL 17.1.30.063s2.1ms

Trois fois plus rapide. Même code source. Mêmes drapeaux d’optimisation (-O3 -mcpu=power9).

Et voici le bonus : la variance du benchmark de GCC était de 10 à 40 % entre les exécutions. La variance d’Open XL était inférieure à 2 %. Il n’y a pratiquement pas de gigue.

Pourquoi une telle différence ?

Open XL (qui est basé sur LLVM) l’a fait :

  • Meilleure planification des instructions pour l’exécution hors ordre de POWER9
  • Attribution de registres supérieurs
  • Des passes d’optimisation plus agressives

Le backend POWER/XCOFF de GCC n’est tout simplement pas aussi mature. La boîte à outils AIX GCC est fonctionnelle, mais elle n’est pas optimisée pour les charges de travail critiques en termes de performances.

Chapitre 5 : Les impasses du LTO et du PGO

L’espoir est éternel. Peut-être que les LTO et PGO d’Open XL fonctionneraient ?

LTO : L’ironie

Open XL prend en charge -flto=full sur XCOFF. Il se construit vraiment ! Mais…

Résultat : 27 % plus lent que l’Open XL non LTO.

Pourquoi ? Les bibliothèques partagées AIX nécessitent une liste d’exportation explicite (exports.exp). Avec LTO, le script de CMake a vu ~27 000 symboles à exporter.

Le principal avantage de l’OLT est d’internaliser les fonctions, c’est-à-dire de les marquer comme étant locales afin qu’elles puissent être optimisées ou mises en ligne. Lorsque tu es obligé d’exporter 27 000 symboles, aucun d’entre eux ne peut être internalisé. Les frais généraux de l’OLT (fichiers intermédiaires plus volumineux, liaison plus lente) demeurent, mais l’avantage disparaît.

C’est comme si tu payais un abonnement à une salle de sport et qu’on te disait ensuite que tu ne peux utiliser aucun des équipements.

PGO : Les profils qui n’ont jamais existé

L’optimisation guidée par le profil semblait prometteuse :

  1. Construis avec -fprofile-generate
  2. Charge de travail pour l’entraînement à la course à pied
  3. Reconstruis avec -fprofile-use
  4. Profite d’un code plus rapide

L’étape 1 a fonctionné. Étape 2… les profils ne sont jamais apparus.

J’ai lié manuellement le runtime de profilage LLVM à la bibliothèque partagée. Toujours pas de profils.

La cause première : Le runtime de profilage de LLVM utilise atexit() ou __attribute__((destructor)) pour écrire des profils à la sortie. Sur AIX avec XCOFF, la sémantique des destructeurs de bibliothèques partagées est différente de celle d’ELF. Le gestionnaire n’est tout simplement pas appelé de manière fiable pour les configurations complexes à plusieurs bibliothèques comme MariaDB.

Les cas de test simples fonctionnent. Les applications réelles ne fonctionnent pas.

Chapitre 6 : La révélation LPAR

J’avais maintenant un compilateur rapide. Il est temps de tester les processeurs dédiés et d’éliminer le problème d’invalidation du cache de l’hyperviseur.

La matrice de test

Config LPARGCCOpen XL
12 vCPUs partagés0.190s0.063s
12 plafonds dédiés0.205s0.082s
21 dédiés plafonnés0.320s0.067s

Attends. Les services partagés sont plus rapides que les services dédiés ?

Le facteur WoF

POWER9 dispose d’une fonction appelée Workload Optimized Frequency (WoF). En mode partagé avec une faible utilisation, un seul cœur peut atteindre ~3,8 GHz. Les processeurs dédiés plafonnés sont bloqués à 2750 MHz.

Pour une requête à un seul fil, le mode partagé obtient 38 % de vitesse d’horloge en plus. Cela bat la pénalité d’invalidation du cache pour cette charge de travail.

Imagine que tu choisisses entre une voiture de sport sur une autoroute avec une circulation occasionnelle (partagée) et un camion avec une voie réservée mais une limite de vitesse (dédiée plafonnée).

Le désastre du mode donateur de PowerVM

Il existe une troisième option : les processeurs dédiés en mode “Donating”, qui redonnent les cycles inactifs au pool partagé.

ModeGCCOpen XL
Plafonné0.205s0.082s
Faire un don0.325s0.085s

60% de régression avec GCC.

Chaque fois qu’une requête explose, il y a un temps de latence pour récupérer les cycles donnés. Pour les charges de travail en rafale et à un seul fil, comme les requêtes de base de données, c’est dévastateur.

Recommandation: N’utilise jamais le mode Don pour les charges de travail des bases de données.

Le 21-Core Sweet Spot

Avec 21 cœurs dédiés (contre 24 pour Linux), Open XL a atteint 0,067s – égalant presque les 0,063s du mode partagé. Le cache L3 supplémentaire apporté par plus de cœurs compense l’absence d’augmentation de la fréquence du WoF.

Chapitre 7 : Le tableau d’affichage final (rebondissement)

Nouveaux benchmarks sur du matériel POWER9 identique, janvier 2026 :

PlateformeCœurs30 requêtes
Linux24 dédié0.057s
AIX + Open XL12 partagés0.063s
AIX + Open XL21 dédié0.067s
AIX + GCC12 partagé0.190s
AIX + GCC21 dédié0.320s

Attends. Le système AIX a 21 cœurs contre 24 pour Linux. Cela représente 12,5 % de cœurs en moins, ce qui signifie 12,5 % de cache L3 en moins.

L’écart mesuré ? 10-18%.

Ce n’est pas un écart de performance. C’est une différence de matériel.

Avec IBM Open XL, AIX offre des performances par cœur identiques à celles de Linux. L’écart de 23x que nous avons constaté au début ? Il n’a jamais été question de la lenteur d’AIX. C’était le cas :

  1. Un cache mal configuré (16 Mo au lieu de 4 Go)
  2. Taille des pages incorrecte (4KB au lieu de 64KB)
  3. Le mauvais compilateur (GCC au lieu d’Open XL)

Le mythe “AIX est lent” est mort.

Le musée complet de l’échec

La science ne se limite pas à ce qui fonctionne – il s’agit aussi de documenter ce qui ne fonctionne pas. Voici notre mur de “bien essayé, mais non” :

Ce que nous avons essayéRésultatNotes
mhnsw_max_cache_size = 4GB5 fois plus rapideÉlimine les tressautements de la mémoire cache
LDR_CNTRL 64K pages~40% plus rapideRéduit les erreurs de la TLB
MAP_ANON_64K patch mmap~8% plus rapideAmélioration mineure du TLB
IBM Open XL 17.1.33x plus rapideMeilleur codegen POWER9
LPAR partagé (vs dédié)~25% plus rapideAugmentation de la fréquence du WoF
Open XL + LTO27% plus lentConflit d’exportation AIX
Open XL + PGONe fonctionne pasProfils non écrits
GCC LTOImpossibleXCOFF n’est pas pris en charge
GCC PGOÉchecs de constructionErreurs de relocalisation du TOC
-ffast-mathCasse MHNSWCorruption par flottaison
-funroll-loopsPireI-cache bloat
POWER VSX bloom filter41% plus lentPas de multiplication vec 64 bits sur P9
Préfixe logicielAucun effetL’hyperviseur évince les données préfixées
Réglage du DSCRBloquéL’hyperviseur contrôle le DSCR dans les LPAR partagés
Mode de don60% de régressionNe jamais utiliser pour les bases de données

Le résultat de VSX est particulièrement intéressant : nous avons implémenté un filtre Bloom SIMD en utilisant les extensions vectorielles de POWER. Il était 41 % plus lent que le scalaire. POWER9 n’a pas de multiplication vectorielle 64 bits – il faut vec_extract → multiplication scalaire → vec_insert pour chaque voie, ce qui est plus lent que de laisser le moteur Out-of-Order gérer une boucle scalaire.

Ce que j’ai appris

1. Les défauts de paiement sont plus importants que tu ne le penses

Un cache de 16 Mo par défaut a transformé des requêtes de moins d’une milliseconde en requêtes de 24 ms. C’est une pénalité de 24x pour un seul paramètre mal configuré.

Lorsque tu portes un logiciel, remets en question tous les paramètres par défaut. Ce qui fonctionne sous Linux peut ne pas fonctionner sur ta plateforme.

2. Le mythe de la lenteur d’AIX a toujours été un problème de chaîne d’outils

Avec GCC, nous étions 3 à 4 fois plus lents que Linux. Avec Open XL, nous sommes au même niveau que Linux par cœur.

La plateforme n’a jamais été lente. La chaîne d’outils par défaut n’était tout simplement pas optimisée pour les charges de travail critiques en termes de performances. Choisis le bon compilateur.

3. La virtualisation comporte des compromis cachés

Les LPAR partagés peuvent être plus rapides que les LPAR dédiés pour les charges de travail monothématiques (augmentation de la fréquence du WoF). Le mode dédié est plus efficace pour les charges de travail multithreads soutenues. Le mode don est un piège.

Connais ta charge de travail. Choisis ta configuration LPAR en conséquence.

4. Tous les ports d’optimisation n’ont pas la même valeur

LTO, PGO et la vectorisation SIMD ont tous échoué sur AIX pour diverses raisons. Les techniques qui rendent Linux rapide ne se traduisent pas toujours.

Parfois, l’optimisation “évidente” est le mauvais choix. Mesure tout.

5. Parfois, il n’y a pas d’écart du tout

Nous avons passé des jours à enquêter sur un “écart de performance” qui s’est avéré être :

  • Erreurs de configuration
  • Mauvais compilateur
  • Moins de cœurs sur le système de test

La leçon à retenir : vérifie tes données de base. Assure-toi de comparer des pommes avec des pommes avant de supposer qu’il y a un problème à résoudre.

Recommandations

Pour les utilisateurs d’AIX MariaDB

  1. Utilise la version Open XL (version 3, bientôt disponible)
  2. Règle mhnsw_max_cache_size sur au moins 4 Go pour la recherche vectorielle
  3. Conserver le LPAR partagé pour une latence de requête unique
  4. N’utilise jamais le mode don pour les bases de données
  5. Utilise des pages de 64K via le wrapper LDR_CNTRL

Pour MariaDB en amont

  1. Augmente la valeur par défaut de mhnsw_max_cache_size – 16MB est beaucoup trop petit
  2. Mettre en œuvre l’éviction LRU – jeter tout le cache en cas de débordement est brutal.
  3. N’ajoute pas le filtre bloom POWER VSX – le scalaire est plus rapide sur POWER9

Prochaines étapes

Les RPM sont publiés sur aix.librepower.org. Release 2 includes the configuration fixes. La version 3 avec Open XL est également disponible.

Priorités immédiates:

  • Licence commerciale Open XL : L’évaluation expire bientôt. Il faut vérifier auprès d’IBM si nous sommes d’accord pour utiliser xLC à cette fin.
  • Implémentation native de l’AIO: AIX a POSIX AIO et IOCP compatible avec Windows. Il est temps d’écrire le backend InnoDB.
  • Retour d’information sur le MHNSW en amont: La valeur par défaut de mhnsw_max_cache_size (16 Mo) est trop faible pour les charges de travail réelles ; nous suggérerons une valeur par défaut plus élevée.

Pour les organisations qui exécutent déjà des charges de travail critiques sur AIX – et il y en a beaucoup, des banques aux compagnies aériennes en passant par les systèmes de santé – la possibilité d’exécuter également MariaDB moderne et performant ouvre de nouvelles possibilités.

AIX correspond à Linux. Le mythe est mort. Et MariaDB sur AIX est prêt pour la production.

TL;DR

  • Au départ, l’écart de performance était de 23x (42 QPS contre 971 QPS).
  • Configuration du cache corrigée : Amélioration de 5x
  • Taille de page fixe : ~40% de plus
  • Passage à IBM Open XL: amélioration de 3x par rapport à GCC
  • LPAR partagé utilisé : ~25% plus rapide que le dédié (WoF boost)
  • Résultat final : NO GAP – 10% de différence = 12,5% de cœurs en moins (21 vs 24)
  • AIX atteint les mêmes performances par cœur que Linux grâce à Open XL
  • Open XL LTO : n’aide pas (27% plus lent)
  • Open XL PGO : ne fonctionne pas (problème AIX XCOFF)
  • POWER VSX SIMD : 41% plus lent que le scalaire (pas de multiplication vec 64 bits)
  • Mode donateur : 60% de régression – ne jamais utiliser pour les bases de données
  • “AIX est lent pour les bases de données open source” a toujours été un mythe de la chaîne d’outils.

Des questions ? Des idées ? Tu utilises MariaDB sur AIX et tu veux partager ton expérience ?

This work is part of LibrePower – Unlocking IBM Power Systems through open source. Unmatched RAS. Superior TCO. Minimal footprint 🌍

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

MariaDB sur AIX | 3 Semaines de Développement Technique (Partie 1)

/dans /par

MariaDB sur AIX, la plateforme qui alimente les systèmes les plus critiques au monde

Dans la vie, il y a des décisions que tu prends en sachant très bien qu’elles te feront souffrir. Se marier. Avoir des enfants. Courir un marathon. Porter MariaDB 11.8 sur IBM AIX.

Voici (partie 1) l’histoire de la dernière édition – et les raisons pour lesquelles je la referais sans hésiter.

Chapitre 1 : “C’est si dur que ça ?”

Tout a commencé par une question innocente lors d’une réunion d’équipe : “Pourquoi n’avons-nous pas MariaDB sur nos systèmes AIX ?”

Voici ce que les gens qui n’ont jamais travaillé avec AIX ne comprennent pas : AIX ne plaisante pas. Lorsque les banques ont besoin d’un temps de disponibilité de cinq neuf pour leurs systèmes bancaires de base, elles utilisent AIX. Lorsque les compagnies aériennes ont besoin de systèmes de réservation qui ne peuvent pas tomber en panne, elles utilisent AIX. Quand Oracle, Informix ou DB2 doivent fournir des performances absolument brutales pour des charges de travail OLTP critiques, ils utilisent AIX.

AIX n’est pas à la mode. AIX n’a pas de mascotte cool. AIX ne fera pas l’objet d’articles de blogs technologiques essoufflés sur la “perturbation”. Mais lorsque les choses ne peuvent absolument pas échouer, AIX est là, faisant tranquillement son travail pendant que tous les autres sont occupés à redémarrer leurs conteneurs.

Alors pourquoi MariaDB ne prend-elle pas officiellement en charge AIX ? L’économie est simple : la communauté open source s’est concentrée sur Linux, et le portage nécessite une expertise spécifique à la plateforme. MariaDB prend officiellement en charge Linux, Windows, FreeBSD, macOS et Solaris. AIX ne figure pas sur la liste – non pas parce que c’est une mauvaise plate-forme, mais parce que personne n’a encore fait le travail.

Chez LibrePower, c’est exactement ce que nous faisons.

Ma première erreur a été de dire tout haut : “Il suffit sans doute de le compiler et d’ajuster quelques éléments”.

Leçon n° 1: Lorsque quelqu’un dit ” compile-le simplement ” à propos d’un logiciel sur AIX, il est sur le point d’en apprendre beaucoup sur la programmation des systèmes.

Chapitre 2: Défis de CMake pour MariaDB sur AIX

Le premier jour de la compilation a été… éducatif. CMake sur AIX, c’est comme jouer aux cartes avec quelqu’un qui a une compréhension très différente des règles – et qui s’attend à ce que tu les découvres toi-même.

Le bogue de la fonction fantôme

AIX a une caractéristique intéressante : il déclare des fonctions dans les en-têtes pour des raisons de compatibilité, même si ces fonctions n’existent pas réellement au moment de l’exécution. C’est comme si ton GPS te disait “tourne à droite dans 200 mètres” mais que la rue était un mur de briques.

CMake fait un CHECK_C_SOURCE_COMPILES pour tester si pthread_threadid_np() existe. Le code se compile. CMake dit “super, on l’a !” Le binaire démarre et… BOOM. Symbole non trouvé.

Il s’avère que pthread_threadid_np() est réservé à macOS. AIX le déclare dans les en-têtes parce que… eh bien, je ne suis pas encore tout à fait sûr. Peut-être pour une raison de compatibilité POSIX qui avait un sens il y a des décennies ? Quelle que soit la raison, GCC le compile sans problème et l’éditeur de liens ne se plaint pas jusqu’à l’exécution.

Même chose avec getthrid(), qui est spécifique à OpenBSD.

La solution:

IF(NOT CMAKE_SYSTEM_NAME MATCHES "AIX")
  CHECK_C_SOURCE_COMPILES("..." HAVE_PTHREAD_THREADID_NP)
ELSE()
  SET(HAVE_PTHREAD_THREADID_NP 0)  # Trust but verify... okay, just verify
ENDIF()

poll.h : Cache-cache

AIX a <sys/poll.h>. C’est juste là. Tu peux cat. Mais CMake ne le détecte pas.

Après trois heures de débogage d’une erreur “POLLIN undeclared” dans viosocket.c, j’ai découvert que la solution consistait simplement à forcer la définition :

cmake ... -DHAVE_SYS_POLL_H=1

Trois heures. Pour un drapeau.

(Pour être honnête, il s’agit d’un problème de détection de plate-forme CMake, et non d’un problème AIX. Les vérifications de CMake supposent des dispositions d’en-tête de type Linux).

Les plugins maudits

À 98 % de la compilation – 98 % ! – le plugin wsrep_info a explosé avec des symboles non définis. Parce qu’il dépend de Galera. Que nous n’utilisons pas. Mais CMake le compile quand même.

Egalement S3 (nécessite les symboles Aria), Mroonga (nécessite Groonga), et RocksDB (profondément lié aux optimisations spécifiques à Linux).

Configuration finale de CMake :

-DPLUGIN_MROONGA=NO -DPLUGIN_ROCKSDB=NO -DPLUGIN_SPIDER=NO 
-DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DPLUGIN_S3=NO -DPLUGIN_WSREP_INFO=NO

Cela ressemble à une amputation chirurgicale, mais il s’agit en fait de tailler dans le gras. Ces plugins sont des cas limites dont peu de déploiements ont besoin.

Chapitre 3: Implémentation du Thread Pool pour MariaDB sur AIX via Pollset

C’est là que les choses sont devenues intéressantes. Et par “intéressant”, je veux dire “j’ai failli me donner un tic permanent”.

MariaDB a deux modes de gestion des connexions :

  • une-filière-par-connexion: Un thread par client. Simple. S’adapte comme une voiture qui monte une côte.
  • pool de threads: Un pool fixe de threads gère toutes les connexions. Élégant. Efficace. Et non disponible sur AIX.

Pourquoi ? Parce que le pool de threads nécessite des API de multiplexage d’E/S spécifiques à la plateforme :

PlateformeAPIStatut
LinuxepollPris en charge
FreeBSD/macOSkqueuePris en charge
Solarisports d’événementsPris en charge
WindowsIOCPPris en charge
AIXpollsetNon pris en charge (jusqu’à présent)

Alors… à quel point la mise en œuvre de la prise en charge des jeux de vote peut-elle être difficile ?

(Note de la rédaction : à ce stade, l’auteur a besoin d’une pause de 20 minutes et d’une boisson).

Le problème ONESHOT

Linux epoll possède un merveilleux drapeau appelé EPOLLONESHOT. Il garantit qu’un descripteur de fichier ne déclenche des événements qu’une seule fois jusqu’à ce que tu le réarmes explicitement. Cela empêche deux threads de traiter la même connexion simultanément.

Le pollset AIX est déclenché par niveau. Uniquement déclenché par niveau. Pas d’options. Si des données sont disponibles, il les signale. Encore et encore et encore. Comme un collègue serviable qui te rappelle sans cesse ce courriel auquel tu n’as pas encore répondu.

Onze versions de la sagesse croissante

Il s’en est suivi onze itérations de code, toutes plus élaborées les unes que les autres, pour essayer de simuler le comportement de ONESHOT :

v1-v5 (L’âge de l’innocence)

J’ai essayé de modifier les drapeaux d’événements avec PS_MOD. “Si je mets l’événement à 0, il ne se déclenchera plus”, me suis-je dit. Spoiler : il n’a pas cessé de se déclencher.

v6-v7 (L’ère des machines à états)

“Je sais ! Je vais maintenir l’état interne et filtrer les événements en double.” Le problème : il y a une fenêtre de temps entre le moment où le noyau te donne l’événement et celui où tu mets à jour ton état. Dans cette fenêtre, un autre thread peut recevoir le même événement.

v8-v9 (La phase de déni)

“Je vais mettre l’état à PENDANT avant de traiter”. Ça a marché… en quelque sorte… jusqu’à ce que ça ne marche plus.

v10 (Espoir)

J’ai enfin trouvé la solution : PS_DELETE + PS_ADD. Lorsque tu reçois un événement, supprime immédiatement le fd du pollset. Lorsque tu es prêt à recevoir d’autres données, ajoute-le à nouveau.

// On receiving events: REMOVE
for (i = 0; i < ret; i++) {
    pctl.cmd = PS_DELETE;
    pctl.fd = native_events[i].fd;
    pollset_ctl(pollfd, &pctl, 1);
}

// When ready: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

Ça a marché ! Avec -O2.

Avec -O3… segfault.

Porter MariaDB sur AIX = Bugs (Le bug -O3)

Imagine mon visage. J’ai un code qui fonctionne parfaitement avec -O2. J’active -O3 pour les benchmarks de production et le serveur se plante avec “Got packets out of order” ou un segfault dans CONNECT::create_thd().

J’ai passé deux jours à penser qu’il s’agissait d’un bug du compilateur. GCC 13.3.0 sur AIX. J’ai accusé le compilateur. J’ai blâmé l’éditeur de liens. J’ai tout blâmé sauf mon propre code.

Le problème était plus subtil : MariaDB a deux chemins de code concurrents qui appellent io_poll_wait sur le même pollset :

  • Les blocs d’écoute avec timeout=-1
  • Le travailleur fait appel à timeout=0 pour les vérifications non bloquantes.

Avec -O2, la synchronisation était telle que les collisions étaient rares. Avec -O3, le code était plus rapide, les collisions se produisaient plus souvent, et boom – race condition.

v11 (L’illumination)

La solution consistait à créer un mutex dédié protégeant à la fois pollset_poll et toutes les opérations de pollset_ctl:

static pthread_mutex_t pollset_mutex = PTHREAD_MUTEX_INITIALIZER;

int io_poll_wait(...) {
    pthread_mutex_lock(&pollset_mutex);
    ret = pollset_poll(pollfd, native_events, max_events, timeout);
    // ... process and delete events ...
    pthread_mutex_unlock(&pollset_mutex);
}

Oui, il sérialise l’accès au pollset. Oui, c’est théoriquement plus lent. Mais tu sais ce qui est encore plus lent ? Un serveur qui tombe en panne.

Le code final de la v11 a passé 72 heures de tests de résistance avec 1 000 connexions simultanées. Aucun plantage. Aucune fuite de mémoire. Aucun “paquet hors service”.

Chapitre 4 : La chose -blibpath (en fait une caractéristique)

Une véritable caractéristique d’AIX : tu dois spécifier explicitement le chemin de la bibliothèque au moment de la liaison avec -Wl,-blibpath:/your/path. Si tu ne le fais pas, le binaire ne trouvera pas libstdc++ même s’il se trouve dans le même répertoire.

Au début, cela te semble ennuyeux. Puis tu réalises : AIX préfère les chemins explicites et déterministes aux recherches implicites. Dans les environnements de production où “ça a marché sur ma machine” n’est pas acceptable, c’est une caractéristique, pas un bogue.

Chapitre 5 : Stabilité – Les chiffres qui comptent

Après tout ce travail, où en sommes-nous ?

Le RPM est publié sur aix.librepower.org et déployé sur un système IBM POWER9 (12 cœurs, SMT-8). MariaDB 11.8.5 fonctionne sur AIX 7.3 avec le pool de threads activé. Le serveur a passé avec succès une suite d’assurance qualité brutale :

TestRésultat
100 connexions simultanées✓
500 connexions simultanées✓
1 000 connexions✓
30 minutes de charge soutenue✓
11+ millions de requêtes✓
Fuites de mémoireZÉRO

1 648 482 400 octets de mémoire – constants pendant 30 minutes. Pas un seul octet de dérive. Le serveur a fonctionné pendant 39 minutes en charge continue et s’est éteint proprement.

Il fonctionne. Il est stable. Il est prêt à être mis en production.

Impact du pool de fils

Le travail sur le pool de threads a permis des gains massifs pour les charges de travail simultanées :

ConfigurationMélange de 100 clientspar rapport à la ligne de base
Original -O2 one-thread-per-connection11.34s–
-O3 + pool-of-threads v111.96s83% plus rapide

Pour les charges de travail OLTP à forte concordance, c’est la différence entre “lutter” et “voler”.

Ce que j’ai appris (jusqu’à présent)

  1. CMake suppose qu’il s’agit de Linux. Sur les systèmes non-Linux, vérifie manuellement que la détection des fonctionnalités est correcte. Les faux positifs te feront mal au moment de l’exécution.
  2. Les entrées/sorties déclenchées par niveau nécessitent de la discipline. EPOLLONESHOT existe pour une raison. Si ton système ne l’a pas, prépare-toi à mettre en œuvre ta propre sérialisation.
  3. -O3 expose les bogues latents. Si ton code “fonctionne avec -O2 mais pas avec -O3”, tu as une condition de course. Le compilateur fait son travail ; le bogue est le tien.
  4. Les mutex sont tes amis. Oui, elles ont des frais généraux. Mais tu sais ce qui est le plus coûteux ? Déboguer les conditions de course à 3 heures du matin.
  5. AIX récompense la compréhension profonde. C’est un système qui ne pardonne pas les raccourcis, mais une fois que tu as compris ses conventions, il est prévisible et robuste. Ce n’est pas pour rien que les banques l’utilisent encore – et qu’elles continueront à le faire dans un avenir prévisible.
  6. L’écosystème est important. Des projets comme linux-compat de LibrePower rendent le développement moderne viable sur AIX. Contribuer à cet écosystème profite à tout le monde.

Qu’est-ce qu’on fait maintenant ? La question de la performance

Le serveur est stable. Le pool de discussion fonctionne. Mais il y a une question en suspens à laquelle je n’ai pas encore répondu :

Quelle est sa rapidité par rapport à Linux ?

J’ai effectué un test de recherche vectorielle – le type d’opération qui permet d’améliorer les fonctions de recherche de l’IA. Index MHNSW (Hierarchical Navigable Small World) de MariaDB, 100 000 vecteurs, 768 dimensions.

Linux sur du matériel POWER9 identique : 971 requêtes par seconde.

AIX avec notre nouvelle version : 42 requêtes par seconde.

Vingt-trois fois plus lent.

Mon cœur s’est effondré. Trois semaines de travail, et nous sommes 23x plus lents que Linux ? Sur un matériel identique?

Mais voici ce qu’il en est de l’ingénierie : lorsque les chiffres n’ont pas de sens, il y a toujours une raison. Et parfois, cette raison s’avère être une bonne nouvelle surprenante.

Dans la deuxième partie, je couvrirai :

  • Comment nous avons découvert que l’écart de 23x était surtout une erreur de configuration.
  • Le compilateur qui a tout changé
  • Pourquoi “AIX est lent” s’est avéré être un mythe
  • Le “musée des échecs” complet des optimisations qui n’ont pas fonctionné.

Les RPM sont publiés sur aix.librepower.org. La version GCC est stable et prête pour la production.

Mais l’histoire de la performance ? C’est là que les choses deviennent vraiment intéressantes.

La deuxième partie arrive bientôt.

TL;DR

  • MariaDB 11.8.5 fonctionne maintenant sur AIX 7.3 avec le pool de threads activé
  • Première mise en œuvre d’un pool de threads pour AIX à l’aide d’un pollset (11 itérations pour obtenir une simulation ONESHOT correcte).
  • Le serveur est stable: 1 000 connexions, plus de 11 millions de requêtes, aucune fuite de mémoire.
  • Le pool de threads offre une amélioration de 83 % pour les charges de travail simultanées
  • Le premier test de recherche vectorielle montre un écart de 23x par rapport à Linux – mais est-ce que c’est tout ?
  • RPMs publiés sur aix.librepower.org
  • La deuxième partie sera bientôt disponible: L’enquête sur les performances

Des questions ? Des idées ? Tu veux contribuer à l’écosystème open source AIX ?

Ce travail fait partie de LibrePower – Unlocking IBM Power Systems through open source. RAS inégalé. Coût total de possession supérieur. Empreinte minimale 🌍

Dépôt du projet LibrePower AIX : gitlab.com/librepower/aix

LLMs sur AIX : expérimentation technique au-delà de l’engouement pour les GPUs

/dans /par

À LibrePower, nous avons publié Llama-AIX: une preuve de concept pour exécuter l’inférence de modèle LLM léger directement sur AIX 7.x, en utilisant seulement le CPU et la mémoire, sans GPU.

Il faut être clair dès le départ : il s’agit d’amusement technique et d’expérimentation, pas d’un produit, pas d’une promesse commerciale, pas d’une alternative aux grandes plateformes d’IA accélérées par le GPU.

Cela dit, l’expérience repose sur une base technique solide.

La théorie : tous les cas d’utilisation du LLM ne sont pas liés au GPU.

Dans de nombreux scénarios professionnels courants dans les environnements Power :

  • RAG (Retrieval Augmented Generation)
  • Questions sur la documentation interne
  • Assistants techniques sur place
  • Recherche sémantique sur ses propres connaissances
  • Analyse de texte fortement dépendante de la latence et de la proximité des données.

Le goulot d’étranglement n’est pas toujours le calcul de la masse, mais.. :

  • CPU
  • Largeur de la mémoire
  • Temps de latence de l’accès aux données
  • Localisation des données

Dans ces cas, les inférences petites et bien délimitées peuvent être raisonnablement exécutées sans GPU, surtout lorsque le modèle n’est pas le centre du système, mais juste une autre pièce du système.

⚙️ CPU, MMA et accélérateurs basse consommation

L’évolution naturelle ne concerne pas seulement les GPU :

  • Des processeurs de plus en plus vectorisés
  • Extensions en tant que MMA
  • Accélérateurs dédiés et économes en énergie (comme le futur Spyre).
  • Intégration plus étroite avec le système d’exploitation et la pile de données

Ce type d’accélération est particulièrement pertinent dans les architectures de puissance, où la conception donne la priorité au débit soutenu, à la cohérence et à la fiabilité, et pas seulement aux pics de FLOPS.

🧩 Pourquoi AIX ?

L’exécuter sur AIX n’est pas une nécessité, c’est un choix conscient :

  • Comprendre les limites réelles
  • Explorer sa faisabilité technique
  • Démonter les hypothèses simplistes
  • Apprendre comment les LLM s’intègrent dans les systèmes d’alimentation existants

De nombreux clients Power exploitent des infrastructures stables, amorties et critiques, où le déplacement des données vers le cloud ou l’introduction de GPU n’est pas toujours souhaitable ou viable.

🔍 Ce qui est (et ce qui n’est pas) Llama-AIX

  • ✔ Un PoC technique
  • ✔ Une exploration honnête
  • ✔ Un exercice d’ingénierie
  • ✔ Source ouverte
  • ✖ Pas un benchmark
  • ✖ Pas une plateforme d’IA complète
  • ✖ Pas destinée à concurrencer les solutions GPU
  • ✖ Pas de ” marketing de l’IA “.

L’idée est simple : voir au-delà du battage médiatique, comprendre les nuances et évaluer où les LLM apportent une réelle valeur dans les environnements Power et AIX.

Purement par curiosité technique.

Et parce que l’expérimentation reste un élément fondamental de l’ingénierie.

Dans quel cas d’utilisation spécifique un LLM in Power sur site aurait-il du sens pour toi ?

SIXE