Archive d’étiquettes pour : LibrePower

LLM sur IBM i via PASE — Sans Linux ni GPU

/dans /par
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 →

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