LLM en IBM i sin Linux ni GPU: llama.cpp vía PASE

/en
IBM i · Marzo 2026

Ejecutamos un LLM en IBM i. Sin Linux. Sin nube. Sin GPU.

llama.cpp compilado para AIX corre directamente en IBM i vía PASE. Tus programas RPG pueden llamar a un modelo de lenguaje local sin añadir infraestructura y sin enviar datos a la nube. En SIXE te enseñamos a hacerlo ;)

Marzo 2026●8 min lectura

Si administras un IBM i, ya sabes lo que viene cada vez que alguien pregunta por inteligencia artificial: "monta un LPAR Linux", "usa OpenAI", "mira Wallaroo". Todas las respuestas implican salir del entorno, añadir capas, y en algún momento enviar datos de negocio a un servidor que no controlas.

Hay 150.000 sistemas IBM i procesando transacciones de banca, seguros y sanidad. La respuesta no puede ser siempre "añade más infraestructura". Así que probamos otra cosa.

El experimento

Qué hicimos exactamente

Tomamos llama.cpp — el motor de inferencia LLM open source más usado — lo compilamos para AIX y copiamos el binario a una partición IBM i V7R5. Lo ejecutamos vía PASE. Funcionó al primer intento.

$ 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 en pub400.com — un sistema IBM i público. Big-endian, powerpc-64bit, OS400. No Linux, no AIX. IBM i.

Qué tipo de binario es

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

XCOFF de 64 bits: el formato ejecutable nativo de AIX. Compilado en AIX 7.3 POWER con GCC 13.3 y extensiones vectoriales VSX. Es el mismo binario de nuestro proyecto llama-aix, que ya distribuye 10 modelos GGUF big-endian en HuggingFace.

Primera ejecución

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

example usage:

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

El binario carga, enlaza libggml y libllama, parsea argumentos y responde. Todo dentro de PASE. Para lanzar inferencia real, le pasas un modelo 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 ejecutando llama.cpp: el binario XCOFF carga, enlaza librerías y responde a un prompt en tiempo real
El contexto

Por qué tiene sentido para un equipo IBM i

En 2026 la conversación sobre IA en IBM i está más viva que nunca. IBM acaba de lanzar Bob (el sucesor de WCA for i), un asistente de codificación para desarrolladores RPG. El 70% de los clientes IBM i prevé actualizaciones de hardware este año. Y hay una pregunta que sigue sin tener respuesta directa:

¿Cómo integro un modelo de lenguaje en mis aplicaciones IBM i sin depender de servicios externos?

Las opciones habituales, a día de hoy:

OpciónQué implicaEl problema
LPAR LinuxMontar un LPAR aparte, ejecutar el LLM ahí, llamarlo desde RPG vía APIInfraestructura nueva, coste adicional, los datos viajan entre particiones
API cloudLlamar a OpenAI, Azure o AWS desde RPGLos datos de negocio salen de la máquina. En banca, seguros o sanidad esto es un problema serio
WallarooLa opción 1 empaquetada como servicio500 $/mes. Sigue siendo un LPAR Linux con marca
PASE + llama.cppEl LLM corre dentro del propio IBM i vía PASESin hardware adicional. Los datos no salen de la partición.
¿Y IBM Bob?
Bob es para el desarrollador: ayuda a entender, documentar y generar código RPG desde el IDE. Lo que describimos aquí es para la aplicación en producción: un LLM corriendo en la misma partición al que cualquier programa RPG puede llamar como si fuera una API local. Son herramientas complementarias, no alternativas.
La base técnica

PASE: el puente que ya tenías instalado

PASE (Portable Application Solutions Environment) es un entorno de ejecución integrado en IBM i que ejecuta binarios AIX de forma nativa. No es emulación — es una capa que expone las llamadas al sistema AIX directamente sobre el kernel de IBM i. Si algo corre en AIX, puede correr en IBM i vía PASE.

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

Llevamos años compilando paquetes para AIX en LibrePower — más de 30 paquetes open source instalables con DNF. Cuando llama.cpp llegó al repositorio, probar el salto a IBM i era el paso natural. PASE hace el resto.

Para los administradores de IBM i

No necesitas instalar nada especial en el sistema operativo. PASE ya está activo. Solo necesitas el binario XCOFF de llama.cpp y un modelo GGUF big-endian. El LLM corre como cualquier otro proceso PASE, sin tocar el entorno nativo IBM i.

El escollo técnico

El problema del big-endian (y cómo lo resolvimos)

Hay una razón por la que nadie había hecho esto de forma sencilla antes: el orden de bytes. IBM i y AIX son big-endian. La práctica totalidad del software de IA — x86, ARM, Linux ppc64le — asume little-endian. Un archivo GGUF descargado de HuggingFace directamente no funciona en IBM i: los bytes están en el orden equivocado.

Esto ya lo habíamos resuelto en nuestro trabajo con AIX. La solución: convertir los modelos antes de distribuirlos. Los publicamos en huggingface.co/librepowerai, validados en hardware AIX real y listos para cargar directamente en IBM i PASE.

ModeloTamañoCuantización
TinyLlama 1.1B Chat668 MBQ4_K_M
LFM 1.2B Instruct695 MBQ4_K_M
LFM 1.2B Thinking731 MBQ4_K_M
Y 7 modelos más——

Son los mismos modelos que alcanzan 10–12 tok/s en AIX POWER. En IBM i POWER10 — con aceleración MMA activa a través de OpenBLAS — el rendimiento debería ser comparable o mejor. Los benchmarks concretos en IBM i están en preparación.

De PoC a producción

Del experimento a producción

Ejecutar --help prueba que el binario carga. El camino real hasta que esto es útil para tus aplicaciones tiene tres pasos, y el primero ya está disponible.

Paso 1: Inferencia directa (ya disponible)

Desde cualquier sesión SSH o QSH en el IBM i:

# Inferencia desde línea de comandos
LIBPATH=/ruta/a/llama /ruta/a/llama/llama-simple \
    -m /ruta/al/modelo.gguf \
    -p "Resume este albarán" -n 200 -t 8

Útil para scripts CL, jobs por lotes, o simplemente para verificar que el modelo carga y responde bien en tu hardware concreto antes de ir más allá.

Paso 2: Servidor con API compatible con OpenAI (a corto plazo)

llama.cpp incluye llama-server, que levanta un endpoint HTTP compatible con la API de OpenAI. Una vez activo en PASE, cualquier programa RPG puede llamarlo usando QSYS2.HTTP_POST como lo haría con cualquier otra API:

# Arrancar el servidor en IBM i vía PASE
LIBPATH=/ruta/a/llama /ruta/a/llama/llama-server \
    -m /ruta/al/modelo.gguf \
    --host 0.0.0.0 --port 8080 -t 8
// Llamada desde RPG — el LLM está en localhost
dcl-s url varchar(256) inz('http://localhost:8080/v1/chat/completions');
dcl-s cuerpo varchar(65535);
dcl-s respuesta varchar(65535);
// QSYS2.HTTP_POST — sin salir de IBM i

La parte importante: localhost. El modelo está en la misma máquina. Los datos no abandonan la partición.

Paso 3: Integración con aplicaciones de negocio (en desarrollo)

  • Análisis de documentos: pasar informes Db2 al LLM para generar resúmenes automáticos
  • Consultas en lenguaje natural: el usuario escribe en español, el LLM devuelve SQL
  • Modernización de código RPG: el LLM analiza y documenta programas existentes sin salir de IBM i
  • Monitorización inteligente: analizar mensajes QSYSOPR y logs de trabajos con contexto semántico
Una nota sobre rendimiento: los modelos pequeños (1–2B parámetros) en PASE son más que suficientes para clasificación, resumen, extracción estructurada de datos y respuestas con formato fijo. Para generación de texto más larga o razonamiento complejo, los modelos de 7B+ escalan bien con más cores. Benchmarks específicos en IBM i POWER10 en preparación.
Hands-on

Cómo probarlo

Si tienes acceso a un IBM i con PASE activo, son tres pasos.

1. Descargar el binario llama.cpp para AIX

Disponible en el gitlab de LibrePower. Si tienes DNF/yum configurado en el sistema:

# Desde AIX (o vía PASE si tienes dnf)
dnf install llama-cpp

2. Descargar un modelo 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 es un buen punto de partida: 668 MB, carga rápido, y sirve para verificar que todo funciona antes de pasar a modelos más grandes.

3. Lanzar la inferencia

LIBPATH=/ruta/a/llama ./llama-simple \
    -m tinyllama-be.gguf \
    -p "¿Qué es IBM i?" \
    -n 150 -t 4
¿Tienes sistemas IBM i en producción?

En SIXE llevamos años dando soporte a entornos IBM i. Si quieres ver si esta aproximación encaja con tu arquitectura — o entender qué implica para tus aplicaciones RPG — hablemos, sin compromiso.

Hoja de ruta

Qué viene después

Esto es una prueba de concepto, no un producto terminado. Eso sí, tenemos claro qué queremos hacer a continuación:

  • llama-server en IBM i — el servidor API HTTP corriendo en PASE, documentado y empaquetado para que puedas levantarlo en minutos
  • Ejemplos de integración con RPG — código real de llamadas al LLM desde programas RPG con QSYS2.HTTP_POST
  • Benchmarks en IBM i POWER10/POWER11 — mediciones reales de tok/s con PASE en hardware de producción
  • Modelos más grandes — pruebas con modelos 7B+ en particiones con memoria suficiente
  • vLLM para IBM i — nuestro paquete vLLM para ppc64le, adaptado para correr en PASE

Otros proyectos de LibrePower

ProyectoQué hace
llama-aixllama.cpp para AIX con 10 modelos GGUF big-endian listos para descargar
linux.librepower.orgRepositorio APT con vLLM para Linux ppc64le (Ubuntu/Debian)
aix.librepower.orgMás de 30 paquetes open source para AIX, instalables con DNF
¿Tienes IBM i con PASE?

Prueba el LLM en tu propia partición

El binario está en GitLab. Los modelos están en HuggingFace. Si tienes acceso a PASE y unos minutos, puedes replicar exactamente este blog :)

GitLab — llama-aix Soporte IBM i — SIXE →
LibrePower Modelos big-endian Newsletter

vLLM en IBM POWER: inferencia de LLMs sin GPU

/en


LibrePower · Linux on Power · Marzo 2026

vLLM en IBM POWER: inferencia de LLMs sin GPU

El primer paquete vLLM precompilado para Linux ppc64le. Lo ha construido la comunidad — y corre en el hardware que ya tienes.

Marzo 2026●18 min lectura


Si administras servidores IBM POWER, ya conoces la dinámica. El hardware es excepcional — POWER9, POWER10 y POWER11 ofrecen RAS incomparable, ancho de banda de memoria y un rendimiento por core que pocas arquitecturas igualan. Pero en el ecosistema de IA, hasta ahora tenías dos opciones: traer tus propias GPUs (normalmente x86) o pasar por Red Hat OpenShift AI. Hoy existe una tercera opción para ejecutar inferencia de LLMs en IBM POWER. Una que tarda 30 segundos, funciona en hardware que ya tienes y usa la aceleración hardware MMA de forma automática.

El paquete: qué y como

Qué hemos construido: vLLM en IBM POWER como paquete .deb

vLLM es el motor de inferencia de LLMs de código abierto más usado. Impulsa inferencia a escala de millones de peticiones diarias en producción. Soporta la API OpenAI completa: /v1/chat/completions, /v1/completions, /v1/models — streaming, llamadas a funciones, uso de herramientas.

El problema era que no existían paquetes precompilados para ppc64le. Ni en PyPI. Ni en los repositorios de Ubuntu. Si querías vLLM en IBM POWER, tenías que apañártelas. La propia comunidad de IBM tiene documentado lo complejo que es el proceso manual.

Así que lo compilamos nosotros. En hardware IBM POWER real. Optimizado para la arquitectura. Y lo empaquetamos como un .deb que APT puede instalar con resolución completa de dependencias.

$ 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: Servidor de inferencia LLM compatible con OpenAI para ppc64le
Ubuntu en IBM POWER
Ejecutar Ubuntu en IBM POWER es la base de este flujo de trabajo. SIXE despliega y soporta entornos Ubuntu ppc64le como Canonical Partner — la misma infraestructura que hace posible esta instalación por APT. Si tu equipo necesita profundizar en la administración de Linux en Power, tenemos formación oficial IBM específica para ello.

El código

El proceso: de código fuente a paquete .deb en ppc64le

Compilar vLLM para POWER no es un simple pip install. Aquí está lo que implicó.

PyTorch en POWER

vLLM depende de PyTorch, que no se distribuye para ppc64le en PyPI. IBM publica wheels en wheels.developerfirst.ibm.com — las usamos como base. Puedes consultar el catálogo completo de herramientas de desarrollo soportadas por IBM para POWER.

La extensión C++

La ruta de alto rendimiento de vLLM es una extensión C++ (_C.abi3.so) que gestiona la atención, el caché, las funciones de activación y la cuantización. Hay que compilarla desde el código fuente con CMake, enlazando contra la API C++ de PyTorch y oneDNN para operaciones GEMM optimizadas.

-- PowerPC detectado
-- Flags de compilación: -fopenmp -DVLLM_CPU_EXTENSION
   -mvsx -mcpu=power9 -mtune=power9
-- Archivos fuente: 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%] Enlazando módulo compartido _C.abi3.so
[100%] Objetivo _C construido

El binario resultante incluye oneDNN con kernels GEMM para PPC64 — la misma librería matemática que Intel usa para x86, pero apuntando a las unidades vectoriales de POWER.

Resolución de dependencias

El ecosistema Python en ppc64le tiene lagunas. Algunos paquetes tienen wheels precompiladas; otros necesitan compilación desde el código fuente; y unos pocos tienen conflictos de versión. Resolvimos todo esto para que tú no tengas que hacerlo.

En la práctica

Inferencia de LLMs en IBM POWER: código y resultado

Así es como se ve en la práctica. Primero, instala el paquete:

# Añadir el repositorio APT de LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Instalar vLLM para ppc64le
sudo apt update
sudo apt install python3-vllm

# Instalar wheels de PyTorch desde IBM
pip3 install torch --extra-index-url \
  https://wheels.developerfirst.ibm.com/ppc64le/linux

Luego ejecuta inferencia desde 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(
    ["Explica la computación cuántica en términos sencillos."],
    SamplingParams(temperature=0, max_tokens=100)
)

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

Pero el valor real de vLLM no está en un script Python — está en el modo servidor, compatible con la API de OpenAI:

# Arrancar el servidor de inferencia compatible con 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é es IBM POWER?"}],
    "max_tokens": 100
  }'

LangChain, LlamaIndex, Open WebUI, Continue.dev — cualquier aplicación que pueda apuntar a un endpoint OpenAI funciona sin modificaciones. Cambias base_url a tu servidor POWER y listo. Esto es lo que convierte la inferencia en CPU sobre IBM POWER en una ruta real hacia el despliegue de IA generativa en infraestructura propia, sin dependencia de GPU ni de nube pública.

Los números

Rendimiento real en POWER9, POWER10 y POWER11: benchmarks de inferencia

Hicimos benchmarks en ambas generaciones con Qwen2.5-0.5B-Instruct (494M parámetros, BF16). No son numeritos imaginarios :p vienen de ejecutar la herramienta de benchmark en hardware real.

POWER9

$ OMP_NUM_THREADS=12 python3 bench_vllm.py
Ejecución 1: 17,8 tok/s (100 tokens en 5,6 s)
Ejecución 2: 16,7 tok/s (100 tokens en 6,0 s)
Ejecución 3: 18,5 tok/s (100 tokens en 5,4 s)
Benchmark POWER9: hilos=12 media=17,6 tok/s

12 hilos es el punto óptimo — más hilos añaden contención de caché en esta carga de trabajo limitada por ancho de banda de memoria.

POWER10

$ OMP_NUM_THREADS=1 python3 bench_vllm.py
Ejecución 1: 13,9 tok/s (100 tokens en 7,2 s)
Benchmark POWER10: hilos=1 media=13,9 tok/s
13,9 tok/s desde un único core POWER10. Para contexto: el resultado de POWER9 usa 12 hilos a través de múltiples cores para alcanzar 17,6 tok/s. La mejora de eficiencia por core de POWER9 a POWER10 es dramática, impulsada por la aceleración hardware MMA. POWER11 comparte la misma arquitectura MMA con mejoras adicionales.
SistemaHilostok/sEficiencia por core
POWER10/11113,913,9 tok/s/core
POWER91217,61,5 tok/s/core

Esto no compite con una A100 — cubre un hueco completamente diferente: ejecutar inferencia de modelos de lenguaje en la infraestructura IBM POWER que ya tienes. Sin presupuesto para GPU, sin slots PCIe, sin dolores de cabeza con drivers. Para organizaciones con servidores POWER9, POWER10 o POWER11 existentes, este es el camino sin inversión en capital adicional hacia la IA privada.

También probamos Qwen2.5-7B-Instruct (7.000 millones de parámetros) en un único core POWER10 — cargó y corrió a 1,0 tok/s. No es suficiente para uso interactivo en un solo core, pero demuestra que los modelos más grandes funcionan. Con más cores, esto escala linealmente. En SIXE recibimos habitualmente esta pregunta de clientes con sistemas IBM POWER en producción: ¿puedo usar este hardware para IA? La respuesta ya es sí.

Dentro de la máquina

Qué ocurre realmente cuando POWER10/11 ejecuta un modelo de lenguaje

Si has visto las presentaciones de IBM sobre IA en POWER, probablemente te hayas encontrado con términos como MMA, Spyre, oneDNN y OpenShift AI. Suelen aparecer juntos en la misma diapositiva. ¿Qué significan realmente? ¿Y cuáles están activos cuando ejecutas python3 -m vllm?

Fuimos al fondo del stack de software para responder a esto. Los resultados nos sorprendieron.

Glosario rápido sin jerga innecesaria

  • LLM (modelo de lenguaje grande) — Software que genera texto: ChatGPT, Llama, Qwen. Un modelo matemático con miles de millones de números que predice la siguiente palabra.
  • Inferencia — Ejecutar un modelo ya entrenado para obtener respuestas. El entrenamiento enseña al modelo; la inferencia lo usa. Este artículo habla solo de inferencia.
  • Token — Una palabra o parte de una palabra. “17,6 tokens por segundo” significa roughly 17-18 palabras por segundo.
  • BF16 (bfloat16) — Una forma de almacenar números usando 16 bits en lugar de 32. La mitad de memoria, casi la misma precisión. Piénsalo como: “calidad suficiente a la mitad del coste de almacenamiento”.
  • GEMM (multiplicación de matrices general) — La operación matemática central de las redes neuronales. La mayor parte del tiempo de cómputo en inferencia LLM se invierte en multiplicar matrices grandes.
  • MMA (Matrix-Multiply Accumulate) — Circuitería dedicada dentro de POWER10 y POWER11 diseñada para acelerar las matemáticas matriciales. Como una calculadora especializada para la operación específica que domina la inferencia LLM.
  • OpenBLAS — Una librería matemática de código abierto con GEMM optimizada. El motor que hace la multiplicación de matrices real en POWER.
  • oneDNN — La librería matemática de Intel, también compilada en vLLM. Otro motor para el mismo propósito.
  • PyTorch — El framework que ejecuta la red neuronal. Llama a OpenBLAS o oneDNN para las matemáticas pesadas.

Cómo encajan las piezas

Cuando vLLM genera un token, este es el camino exacto a través de la máquina:

Escribes una pregunta
↓
vLLM la recibe y la divide en tokens
↓
PyTorch ejecuta las matemáticas de la red neuronal
↓
Para cada capa: multiplica matrices grandes (GEMM)
↓
PyTorch le pide a OpenBLAS: “multiplica estas dos matrices BF16”
↓
OpenBLAS ejecuta sbgemm_kernel_power10 ← AQUÍ SE USA MMA
↓
El hardware POWER10/11 ejecuta instrucciones MMA
↓
El resultado sube, se elige el siguiente token
↓
Ves aparecer la siguiente palabra
La aceleración MMA ya está activa en nuestros benchmarks. No es una función futura ni un flag de configuración — funciona ya, a través de la ruta PyTorch → OpenBLAS → hardware MMA. Sin configuraciones especiales.

La prueba: BF16 frente a FP32 en POWER10/11

En POWER10 y POWER11, MMA acelera las matemáticas BF16. En POWER9 (sin MMA), BF16 es en realidad más lento que FP32 por emulación software. Si MMA funciona, BF16 debe ser más rápido:

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

BF16 es 1,54× más rápido que FP32. MMA está activo y entrega aceleración medible. Nuestros 13,9 tok/s en un único core POWER10 ya incluyen MMA. Ese es el número real, acelerado por hardware. Las capacidades de aceleración de IA de POWER10 y POWER11 son algo que tratamos en profundidad en nuestros servicios de soporte y mantenimiento de IBM POWER.

La investigación sobre oneDNN (y lo que aprendimos)

Inicialmente pensamos que podría haber rendimiento extra sin aprovechar.

La build de vLLM incluye oneDNN (originalmente de Intel). Dentro hay dos rutas matemáticas específicas para POWER:

  • GEMM int8: Un kernel escrito a mano por ingenieros de IBM con instrucciones MMA para modelos cuantizados.
  • GEMM BF16: Un paso directo a OpenBLAS — pero solo cuando se compila con flags específicos.

Nuestra build inicial no tenía esos flags. Recompilamos con -DDNNL_BLAS_VENDOR=OPENBLAS, confirmamos que los flags estaban activos, volvimos a hacer el benchmark — mismo rendimiento.

¿Por qué? PyTorch ya iba directamente a OpenBLAS, saltándose oneDNN para las operaciones matriciales principales. La optimización ya estaba ahí; simplemente no lo sabíamos.

Conclusión práctica: No necesitas configurar nada especial. PyTorch en POWER10 y POWER11 con OpenBLAS usa MMA automáticamente para inferencia BF16. Instala el paquete y ejecuta.

¿Y qué hay de IBM Spyre?

IBM Spyre es una tarjeta aceleradora de IA dedicada para POWER — hardware completamente separado con su propio silicio para matemáticas de IA. La distinción clave:

  • MMA = aceleración integrada dentro de cada core POWER10 y POWER11 (activa ahora mismo en nuestros benchmarks)
  • Spyre = tarjeta aceleradora de IA separada que se añade al sistema (prometedora, pero requiere stacks de software específicos de IBM)

Nuestro trabajo se centra en lo que está disponible hoy usando la CPU que ya tienes en tu máquina, sin inversión adicional en hardware.

El cuadro completo

TecnologíaQué es¿Activa en nuestra build?
POWER10/11 MMA (BF16)Acelerador matricial integrado en la CPUSí — PyTorch → OpenBLAS
POWER10/11 MMA (int8)El mismo hardware, para modelos de 8 bitsCompilado, no end-to-end aún
IBM SpyreTarjeta aceleradora de IA separadaNo — hardware diferente
OpenShift AIPlataforma ML completa en KubernetesNo — somos la alternativa ligera
oneDNNLibrería matemática incluida en vLLMCompilada, PyTorch la saltea
OpenBLASLibrería matemática con kernels POWER10/11 a manoSí — el verdadero motor

Contexto

El panorama: inferencia de LLMs en IBM POWER sin OpenShift

Red Hat OpenShift AI

Hasta ahora, la propuesta oficial de IBM/Red Hat para inferencia de LLMs en IBM POWER era OpenShift AI. Soporta notebooks, pipelines, entrenamiento de modelos, serving y monitorización. Desde la versión 3.0, corre en ppc64le con cargas de trabajo solo de CPU.

OpenShift AI es la elección correcta para organizaciones que ya tienen clústeres OpenShift. Viene con RBAC, InstructLab para fine-tuning de modelos y soporte enterprise.

Pero requiere OpenShift. Un clúster Kubernetes, una suscripción Red Hat, gestión de operadores. Para muchos entornos POWER — especialmente los que corren Linux standalone o entornos mixtos AIX/Linux — eso es un compromiso significativo solo para servir un modelo. Estas son exactamente las organizaciones que gestionan su infraestructura IBM POWER con soporte de SIXE.

En SIXE llevamos años ayudando a clientes con IBM POWER a modernizar sus cargas de trabajo. La aparición de inferencia de IA local sobre ppc64le encaja directamente con la línea editorial que describimos en nuestro artículo sobre factoría de IA con stack open source: IA en producción, sin dependencia de nube pública, sobre infraestructura que ya pagas.

Lo que aporta LibrePower

No estamos reemplazando OpenShift AI. Lo complementamos con una ruta más ligera para los muchos entornos POWER que no necesitan la plataforma completa.

OpenShift AILibrePower vLLM
InstalaciónClúster OpenShift + operadoresapt install python3-vllm
InfraestructuraKubernetes obligatorioCualquier Ubuntu/Debian ppc64le
AlcanceCiclo ML completoSolo inferencia
SoporteSuscripción Red HatComunidad (código abierto)
GPUSoportada (x86)Solo CPU (nativo POWER)
Tiempo hasta la primera inferenciaHoras o díasMinutos
CosteLicenciamiento OpenShiftGratuito

IBM construye la autopista — hardware de primer nivel, wheels de PyTorch, OpenShift AI, InstructLab. LibrePower añade un acceso directo para quienes no necesitan la plataforma completa. El roadmap de IA en IBM POWER avanza rápido, y las herramientas de comunidad como esta cubren huecos reales en el ecosistema actual.

La infraestructura

Cómo funciona el repositorio de paquetes de LibrePower

Construimos librepower.org siguiendo el mismo patrón que nuestro repositorio de paquetes AIX — infraestructura que ya sirve más de 30 paquetes de código abierto a sistemas AIX en todo el mundo.

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

El CI/CD corre en GitLab: cada push regenera los metadatos APT y despliega automáticamente. Todos los paquetes compilados en hardware IBM POWER real — no compilación cruzada, no emulación. El código fuente completo está en GitLab bajo Apache 2.0.

Hoja de ruta

Qué viene después para vLLM en IBM POWER

  • Más modelos probados — Llama, Mistral, Phi, Granite. Benchmarks sistemáticos por familia de modelos.
  • llama.cpp para ppc64le — Modelos GGUF cuantizados para una huella de memoria aún menor. Ya disponible para AIX.
  • Soporte para Ubuntu 24.04 y Debian 12 — Extendiendo el paquete a las últimas versiones LTS.
  • Variantes optimizadas para POWER10/11 — Profundizando en el tuning de MMA. Nuestros 13,9 tok/s por core son un punto de partida, no un techo.
  • GEMM int8 end-to-end — Completando la ruta MMA para modelos cuantizados, lo que debería mejorar el throughput.
¿Tienes IBM POWER y quieres ejecutar IA?
SIXE ayuda a las organizaciones a desplegar y operar Linux en IBM POWER — desde formación oficial hasta soporte de infraestructura completo. Si estás evaluando inferencia de LLMs en hardware POWER existente o quieres saber cómo encaja con tu arquitectura actual, hablemos. También puedes leer más sobre el contexto más amplio de IA open source en IBM Power en nuestro artículo sobre cómo montar una factoría de IA con stack open source.

¿Tienes un sistema ppc64le?

Prueba vLLM en IBM POWER

Si tienes un sistema con Ubuntu, son tres comandos. El código fuente está en GitLab si quieres profundizar o contribuir.

# Añadir el repositorio LibrePower
curl -fsSL https://linux.librepower.org/install.sh | sudo sh

# Instalar vLLM para ppc64le
sudo apt update && sudo apt install python3-vllm

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

# Arrancar el servidor de inferencia compatible con OpenAI
python3 -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-0.5B-Instruct \
    --device cpu --dtype bfloat16 --port 8000
librepower.org
GitLab source
Newsletter
librepower.org
Soporte IBM POWER por SIXE →

Qué es una Factoría de IA y cómo montarla open source

/en


Infraestructura de IA · Marzo 2026

Qué es una Factoría de IA y cómo montarla con open source en tu datacenter

El concepto de AI Factory lleva dos años en boca de todos, pero pocas organizaciones entienden qué implica técnicamente ni cómo montarla sin depender de un proveedor cloud. Aquí lo explicamos sin rodeos, y con el stack concreto que usamos en producción.

Marzo 2026●20 min lectura

Una factoría de IA no es un servidor con una GPU y un modelo descargado de Hugging Face. Es una infraestructura de cómputo distribuida, diseñada para ejecutar modelos de lenguaje y visión en producción de forma continua, escalable y bajo control total de la organización. La buena noticia: montarla ya no es privilegio de los grandes. La tecnología open source que usa el Barcelona Supercomputing Center para su AI Factory, o la que impulsa las infraestructuras soberanas europeas, está disponible para cualquier empresa con datacenter propio. Lo que leerás a continuación es una guía sobre qué necesitas, qué no y cómo decidir si tiene sentido para ti.

Un poquito de contexto

Qué es exactamente una factoría de IA

El término “AI Factory” lo popularizó Jensen Huang de NVIDIA en 2023 para describir lo que los centros de datos están convirtiéndose: máquinas que producen inteligencia de forma continua, como una fábrica produce bienes. La metáfora no es poética; es técnicamente precisa.

Una factoría de IA clásica tiene cuatro componentes diferenciados: un sistema de almacenamiento para guardar los pesos de los modelos y los datasets (que pesan decenas o cientos de gigabytes), una capa de cómputo GPU para ejecutar la inferencia, un orquestador que gestiona qué modelo corre en qué hardware, y una API que expone los modelos al resto de la organización. Cuando esos cuatro componentes funcionan juntos de forma eficiente, tienes una factoría de IA.

Lo que la diferencia de “tener un LLM corriendo en un servidor” es la escala, la fiabilidad y la gestión. En una factoría de IA se sirven múltiples modelos en paralelo, se gestionan colas de peticiones, se garantiza disponibilidad y se monitoriza el uso de recursos. Es infraestructura de producción, no un entorno de pruebas.

Dato relevanteLa Comisión Europea ha comprometido más de 1.500 millones de euros para construir AI Factories distribuidas por los estados miembros bajo el programa EuroHPC. El objetivo explícito es que Europa tenga infraestructura soberana de IA sin depender de proveedores estadounidenses o asiáticos. España participa a través del BSC con su AI Factory en Barcelona. La misma tecnología que ellos usan, tú puedes montarla en tu datacenter.

¿Por qué recurrir a una factoría de IA?

Por qué las organizaciones se traen la inferencia a casa

Hay tres motivos que aparecen siempre en todas las conversaciones que tenemos con clientes cuando evalúan montar su propia infraestructura de IA. No son argumentos de marketing: son realidades operativas y financieras.

💸

Costes predecibles

Las facturas de GPU en cloud público pueden variar un 30–40% entre ciclos según la demanda. Con infraestructura propia, el coste es fijo, amortizable y sin sorpresas. A partir de un volumen medio de inferencia, la inversión se recupera en 12–18 meses frente a cloud.

🔓

Sin vendor lock-in

APIs propietarias, formatos cerrados, modelos fine-tuneados que viven en infraestructura ajena. Con un stack open source, tus modelos y tus datos son tuyos. Siempre puedes moverlo todo, sin negociaciones ni contratos de salida.

🏛️

Cumplimiento regulatorio

El RGPD y el EU AI Act exigen saber exactamente dónde se procesan los datos. Si tu inferencia toca datos de pacientes, ciudadanos o clientes bancarios, necesitas control total sobre la infraestructura. On-premise es la única respuesta válida.

La pregunta ya no es si montar infraestructura propia de IA, sino cuándo y cómo hacerlo sin repetir los errores del cloud hace diez años: velocidad sin arquitectura.
— Equipo técnico SIXE

Dicho esto, montar una factoría de IA on-premise no es para todo el mundo. Si procesas diez peticiones de inferencia al día y no tienes requisitos regulatorios estrictos, probablemente cloud es lo correcto ahora mismo. La infraestructura propia empieza a tener sentido cuando el volumen de uso es sostenido, cuando los datos son sensibles, o cuando necesitas correr modelos fine-tuneados propietarios sin exponerlos a terceros.

Vale pero y esto… ¿cómo lo monto exactamente?

El stack open source: tres tecnologías, cero dependencias propietarias

Existe una combinación de tres tecnologías que ha emergido como estándar de facto para construir factorías de IA on-premise en entornos europeos. Las mismas que usa el BSC. Las mismas que impulsan infraestructuras soberanas en Francia, Alemania e Italia. Y las mismas con las que trabajamos en SIXE.

Ceph: el almacenamiento distribuido para IA

Los modelos de lenguaje son voluminosos. Llama 3 70B ocupa unos 40 GB en precisión float16. Mixtral 8x7B ronda los 90 GB. Un catálogo razonable de modelos para una organización mediana puede superar fácilmente los 500 GB, sin contar los datasets de fine-tuning ni los registros de inferencia.

Ceph resuelve esto con almacenamiento distribuido que unifica object storage (compatible con S3 de forma nativa), block storage y filesystem en un mismo cluster. Escala de terabytes a petabytes sin interrupciones, soporta erasure coding para eficiencia de almacenamiento y tiene integración nativa con Kubernetes via CSI. Para una factoría de IA, Ceph actúa como el backbone donde viven los pesos de los modelos, los datasets y los resultados.

Perspectiva SIXESomos Canonical Partner y llevamos años desplegando clusters Ceph en producción, incluyendo entornos de IA y HPC. Ceph no es “activar un checkbox”: requiere dimensionamiento cuidadoso, diseño de red y políticas de replicación adaptadas a la carga. En clusters de 3 nodos hay consideraciones de quórum que conviene no improvisar. Ofrecemos formación específica en administración Ceph y soporte para que tu equipo opere Ceph con autonomía real.

OpenStack: tu cloud privado con gestión nativa de GPUs

OpenStack es lo que convierte tu hardware en un cloud privado enterprise. Para una factoría de IA, su función principal es la gestión de recursos GPU: PCI passthrough para acceso directo a la GPU desde la VM, vGPU para compartir una GPU física entre múltiples cargas de trabajo, y NVIDIA MIG (Multi-Instance GPU) para particionar GPUs A100 y H100 en instancias independientes.

Bajo la Linux Foundation desde 2024, OpenStack opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. No es una tecnología emergente: es infraestructura probada a escala real, con gobernanza independiente que garantiza continuidad.

Detalle importanteOpenStack no es trivial. Comprende más de 30 proyectos de servicio y requiere equipos con experiencia en sistemas distribuidos. Si tu equipo viene de VMware, la curva de aprendizaje existe. Nuestro servicio incluye formación práctica específica para que puedan operar el stack de forma autónoma, sin dependencia de consultoría a largo plazo.

Kubernetes + vLLM: la capa de orquestación de inferencia

Kubernetes es el estándar CNCF para orquestar cargas de trabajo en contenedores, y tiene soporte nativo para GPU scheduling mediante el NVIDIA GPU Operator. Sobre Kubernetes se despliegan los motores de inferencia, siendo vLLM el más relevante en este momento para modelos de lenguaje.

vLLM implementa PagedAttention, una técnica que gestiona la memoria KV cache de forma eficiente y permite servir múltiples peticiones en paralelo sin desperdiciar VRAM. En benchmarks representativos, vLLM supera entre 3 y 5 veces el throughput de una implementación naive del mismo modelo. Expone una API compatible con OpenAI, lo que facilita la migración de aplicaciones que ya consumen GPT-4 o similares.

Para modelos de visión o embedding, Triton Inference Server (NVIDIA) complementa vLLM y permite optimizaciones específicas por hardware como TensorRT-LLM.

¿Y cómo le damos forma a la factoría de IA?

Arquitectura de referencia: del dato al modelo en producción

Una factoría de IA on-premise con este stack sigue un flujo de cuatro capas. No es el único diseño posible, pero sí el que mejor balancea complejidad operacional, rendimiento y portabilidad.

01 — Datos

Ceph S3

Modelos, datasets, resultados de inferencia. API compatible S3 para integración con pipelines MLOps.

02 — Cómputo

OpenStack

GPU scheduling, bare metal, redes aisladas por proyecto. PCI passthrough y MIG para máxima eficiencia.

03 — Orquestación

Kubernetes

GPU Operator, autoscaling de pods de inferencia, gestión del ciclo de vida de los deployments.

04 — Producción

vLLM / Triton

APIs de inferencia, RAG, agentes. Compatibilidad OpenAI para integración sin fricción.

La clave de este diseño es que cada capa es independiente y reemplazable. Si mañana aparece un orquestador mejor que Kubernetes para cargas de IA, puedes sustituirlo sin tocar el almacenamiento ni la capa de cómputo. Eso es lo que significa no tener vendor lock-in: no es solo que el software sea open source, sino que la arquitectura tiene separación de responsabilidades real.

Componente
Función en la factoría
Alternativas viables
Gobernanza

Ceph
Almacenamiento de modelos y datos
IBM Storage Scale (GPFS)
Linux Foundation

OpenStack
Cloud privado con gestión GPU
MaaS + bare metal directo
OpenInfra / LF

Kubernetes
Orquestación de contenedores
MicroK8s, OpenShift
CNCF / LF

vLLM
Motor de inferencia LLM
Triton, TensorRT-LLM
Apache 2.0

Ubuntu / Canonical
OS base + soporte del stack
RHEL, SUSE
Canonical Partner

¿Sirve para mi empresa?

Quién necesita una factoría de IA on-premise

No todos los sectores tienen la misma urgencia ni las mismas restricciones. Hay cuatro ámbitos donde la infraestructura propia no es una opción: es la única respuesta posible.

🏥

Sanidad y farmacéutica

Historiales clínicos, imágenes diagnósticas, datos genómicos. El RGPD y el Reglamento de Datos Sanitarios de la UE prohíben transferencias a terceros países sin salvaguardias explícitas. La inferencia on-premise es la arquitectura de cumplimiento por defecto. Ceph para IA y HPC ofrece el almacenamiento masivo que estos entornos necesitan.

🏦

Banca y seguros

Scoring crediticio, detección de fraude, análisis de riesgo. Las directrices de la EBA sobre uso de IA en servicios financieros y el EU AI Act clasifican estos sistemas como de alto riesgo, con requisitos de trazabilidad y control que solo se cumplen on-premise.

🏛️

Sector público y defensa

Soberanía tecnológica, ENS, datos clasificados. La Estrategia Nacional de Inteligencia Artificial de España exige que los sistemas de IA de uso público se operen sobre infraestructura europea o nacional. Sin discusión posible.

🏭

Industria y manufactura

Visión artificial en línea de producción, mantenimiento predictivo, control de calidad. La latencia de cloud no es viable cuando necesitas respuesta en milisegundos en la planta. La inferencia edge o datacenter propio es el único modelo que funciona.

FAQ

Las preguntas que hay que responder antes de empezar

Montar una factoría de IA on-premise no es un proyecto de fin de semana. Requiere análisis previo honesto sobre cuatro dimensiones que determinan si tiene sentido y cómo hacerlo bien.

¿Qué modelos vas a servir y cuántas peticiones?

El dimensionamiento de GPU depende directamente del tamaño de los modelos (número de parámetros y precisión) y del throughput objetivo (peticiones por segundo, latencia P99 aceptable). Un modelo de 7B parámetros en float16 cabe en una GPU L40S de 48 GB. Un modelo de 70B necesita varias GPUs con tensor parallelism. No hay atajos aquí: el dimensionamiento correcto requiere conocer las cargas reales, no estimaciones optimistas.

¿Tiene tu equipo la capacidad para operar este stack?

La pregunta más importante y la que menos se hace. Un equipo con experiencia en Linux, Kubernetes y sistemas distribuidos puede aprender a operar este stack. Pero si partes de cero, la curva de aprendizaje tiene que estar dentro del plan, no fuera. En SIXE ofrecemos formación certificada en Ceph, OpenStack y Kubernetes (como IBM BP y Canonical Partner) precisamente para que la transición no dependa de consultoría indefinida.

¿Cuál es el TCO real a 3 años?

El software es open source, así que no hay coste de licencias. La inversión es hardware (GPUs, servidores, networking de alta velocidad) más la formación del equipo. Comparado con el coste de GPU en cloud a ese mismo volumen de inferencia, los números suelen hablar solos. Pero el modelo financiero tiene que incluir mantenimiento, actualizaciones y el tiempo de operación del equipo. Nada es gratis, y los proyectos que parten de esa premisa acaban teniendo sorpresas desagradables.

Cómo trabajamos en SIXEAntes de cualquier despliegue, hacemos una evaluación de arquitectura donde auditamos tus cargas de trabajo reales, requisitos de latencia, volumen de datos y obligaciones regulatorias. Entregamos un diseño completo: dimensionamiento GPU, topología de red, almacenamiento Ceph y plan de capacidad a 12–24 meses. Sin humo, sin promesas de ahorro que no hemos calculado. Solo un análisis técnico sobre si tiene sentido y cómo ejecutarlo.

¿Tienes un proyecto de inferencia de IA?

Tu factoría de IA, con el stack que usamos nosotros

IBM Business Partner y Canonical Partner. Más de 15 años desplegando open source en producción. Diseñamos la arquitectura, formamos a tu equipo y te acompañamos hasta que la infraestructura funciona sola. Nuestro trabajo termina cuando el tuyo empieza de verdad.

Ver el servicio de inferencia →
Escríbenos por WhatsApp

10 Errores de Arquitectura y ROI en la Migración Post-VMware

/en ,
Análisis Técnico · Febrero 2026

10 Errores de Arquitectura y ROI que Nadie Evaluó en la Huida Post‑VMware

Las alternativas open source son viables. Pero “viable” y “adecuado para tu negocio” son preguntas radicalmente distintas que exigen análisis técnico, financiero y de gobernanza antes de comprometer tu infraestructura una década.

Febrero 2026●25 min lectura●Para CIOs, CTOs y Directores de Infraestructura
El 86 % de los clientes de VMware están reduciendo activamente su footprint. Solo el 4 % ha completado la migración. Entre esos dos números hay un abismo de decisiones técnicas, financieras y estratégicas que la mayoría de organizaciones están tomando con más prisa que cabeza. Este artículo no recomienda ninguna plataforma: plantea las preguntas que todo equipo directivo debería responder antes de comprometer su infraestructura para los próximos 5–10 años. Spoiler: no hay respuesta mágica, pero sí hay un camino sensato.

Error 01 de 10

Confundir urgencia con estrategia

La adquisición de VMware por Broadcom en noviembre de 2023 por 61.000 millones de dólares desencadenó la mayor sacudida en virtualización empresarial de la última década. Y cuando decimos sacudida, nos quedamos cortos. Licencias perpetuas eliminadas, ~8.000 SKUs consolidados en 4 bundles, mínimo de compra de 72 cores y subidas de precio reportadas entre el 150 % y el 1.500 %. Tesco presentó una demanda de 100 millones de libras. Fidelity advirtió de riesgos para 50 millones de clientes. Vamos, que el panorama invitaba a salir corriendo.

Y eso es exactamente lo que ha pasado: mucha gente ha salido corriendo, pero no siempre en la dirección correcta. Una encuesta de CloudBolt (2026) reveló que el 63 % ha cambiado su estrategia de migración al menos dos veces (sí, dos veces). Gartner estima que la cuota de VMware caerá del 70 % al 40 % para 2029, pero el camino hasta allí está lleno de curvas que merecen bastante más reflexión de la que están recibiendo.

Perspectiva SIXE

La urgencia que genera Broadcom es totalmente comprensible —a nadie le gusta que le multipliquen la factura de un día para otro. Pero cada decisión de infraestructura tomada bajo presión se convierte en deuda técnica que los equipos heredarán durante años. La primera decisión correcta es separar la respuesta táctica inmediata de la estrategia a medio plazo y evaluar ambas con criterios diferentes. Respira, planifica y luego actúa.

Error 02 de 10

Ignorar la gobernanza del proyecto open source

No todo el open source es igual, ni mucho menos. La diferencia más relevante para una decisión empresarial a largo plazo no es la licencia, sino algo que casi nadie mira: quién controla el proyecto y qué mecanismos protegen a la comunidad si las prioridades comerciales cambian.

Proxmox Server Solutions GmbH es una empresa privada austriaca con un capital social de 35.000 € y un equipo estimado de 14–24 personas. Gente estupenda, seguro, pero no existe fundación independiente, ni consejo de gobernanza abierto, ni representación comunitaria en las decisiones de desarrollo. Es decir: el futuro de tu plataforma depende de las decisiones de una sola empresa.

Contrástese con la MariaDB Foundation, donde ninguna empresa puede ocupar más del 25 % de los asientos del consejo — un mecanismo que protegió al proyecto cuando MariaDB Corporation fue adquirida por K1 en septiembre de 2024. O con OpenStack, ahora bajo la Linux Foundation, con gobernanza distribuida entre cientos de organizaciones. Eso sí que es un colchón de seguridad.

Pregunta clave

¿Tu plataforma de virtualización —esa sobre la que van a correr tus aplicaciones de negocio los próximos 10 años— está controlada por una fundación independiente, un consorcio o una única empresa privada de menos de 25 empleados? No es una pregunta retórica: la respuesta tiene implicaciones directas sobre el riesgo a largo plazo.

Error 03 de 10

No leer el Contributor License Agreement

Lo sabemos, leer un CLA no es exactamente un plan de viernes noche. Pero merece la pena. El CLA de Proxmox otorga a la compañía una licencia perpetua, mundial e irrevocable sobre todas las contribuciones, con derecho a relicenciarlas bajo términos comerciales o propietarios. Este mecanismo no es inherentemente problemático, pero es exactamente la combinación estructural (empresa única + AGPL + CLA permisivo) que precedió a cada cambio de licencia relevante de los últimos siete años. Es como ver las nubes de tormenta y decir “seguro que no llueve”.

ProyectoAñoCambioConsecuenciaGobernanza
MongoDB2018AGPL → SSPLDropped by Debian/Red HatSingle vendor
Elasticsearch2021Apache 2.0 → SSPLFork: OpenSearch (Linux Foundation)Single vendor
HashiCorp2023MPL 2.0 → BSLFork: OpenTofu · IBM: $6.4BSingle vendor
Redis2024BSD → SSPLFork: Valkey (Linux Foundation)Single vendor
MinIO2021–26Apache → AGPL → AbandonedRepo: “NO LONGER MAINTAINED”Single vendor
Kubernetes——Apache 2.0 stableFoundation (CNCF)
PostgreSQL——PostgreSQL License stableCommunity
Linux——GPLv2 stableFoundation (LF)

¿Ves el patrón? Es bastante claro: ningún proyecto respaldado por una fundación independiente ha sufrido un cambio de licencia unilateral. Ni uno. Este dato debería informar cualquier evaluación de riesgo, independientemente de la plataforma que estés considerando.

Error 04 de 10

Asumir que los costes de suscripción se mantendrán

Toda empresa que desarrolla software open source necesita monetizar su trabajo, y eso es completamente legítimo — nadie vive del aire. La cuestión no es si habrá subidas de precio (las habrá, como en todo), sino si las estás incluyendo en tu modelo de TCO.

La suscripción Community de Proxmox pasó de 49,90 € a 120 €/año (~140 % de incremento), y en enero de 2026 todos los tiers subieron otro 3,8–4,3 %. El nuevo Proxmox Datacenter Manager requiere que al menos el 80 % de los nodos tengan suscripciones Basic o superiores (370+ €/socket/año). ¿Te suena familiar? A nosotros un poco también.

OpenStack, Ceph y otras alternativas también tienen estructuras de coste propias. Ninguna plataforma es gratuita en producción — si alguien te dice lo contrario, desconfía amablemente. La diferencia está en qué costes son predecibles y cuáles dependen de decisiones unilaterales.

Perspectiva SIXE

Cuando evaluamos alternativas con nuestros clientes, siempre modelamos tres escenarios de coste: optimista, realista y adverso, con proyecciones a 5 y 10 años que incluyen posibles cambios en la estructura de licenciamiento. Sí, es más trabajo. Pero también es la única forma de hacer un TCO que no se desmorone al primer cambio de precios.

Error 05 de 10

Subestimar la complejidad operacional de OpenStack

Vamos a ser justos con OpenStack: opera en producción con más de 45 millones de cores en organizaciones como Walmart, GEICO o LINE Corp. Su gobernanza —ahora bajo la Linux Foundation— es de las más sólidas del ecosistema. Estas son ventajas reales y de peso.

Pero (siempre hay un pero) el propio proyecto reconoce que el 44 % de los proveedores IT y el 39 % de las empresas reportan dificultad para encontrar profesionales cualificados. La plataforma comprende más de 30 proyectos de servicio. Desplegar y operar ese stack requiere equipos con experiencia en sistemas distribuidos que la mayoría de los equipos VMware no poseen —no por falta de talento, sino porque son conjuntos de competencias fundamentalmente distintos. Es como pedirle a un gran chef de cocina mediterránea que prepare sushi de competición: ambos son cocina de alto nivel, pero las habilidades no se transfieren automáticamente.

Matiz importante

OpenStack puede ser la elección perfecta para organizaciones con la escala y los equipos adecuados. El modelo gestionado (Canonical, Mirantis, Platform9) resuelve parte de la complejidad, aunque añade costes y dependencia. La pregunta no es “¿OpenStack sí o no?” sino “¿nuestro equipo, presupuesto y escala encajan con lo que OpenStack necesita para brillar?”

Error 06 de 10

Asumir que Ceph es “solo activar el checkbox”

Ceph es un sistema potente y está en producción en sitios impresionantes: CERN, Bloomberg y DigitalOcean, entre otros. Pero la distancia entre un clúster Ceph a hiperescala y uno de 3–5 nodos típico de una migración VMware es como la distancia entre pilotar un Airbus y un ultraligero: ambos vuelan, pero las reglas son muy diferentes.

Los benchmarks de StarWind en entornos Proxmox HCI muestran que Ceph alcanzó 270.000 IOPS en cargas mixtas 4K, frente a 1.088.000 IOPS de LINSTOR/DRBD y 1.199.000 de StarWind VSAN. Y los riesgos de los clústeres pequeños merecen atención especial: perder un nodo en un clúster de 3 con replicación 3x puede dejar el sistema en solo lectura. No es el mejor escenario a las 3 de la madrugada de un lunes.

Existen alternativas interesantes: LINSTOR/DRBD con rendimiento cercano al nativo, StorPool con latencias sub-100 µs, IBM Storage Virtualize con integración enterprise probada. Cada opción tiene sus fortalezas, limitaciones y requisitos de expertise.

Perspectiva SIXE

La capa de storage es posiblemente la decisión más crítica y menos reversible de toda la migración. Es donde no te puedes permitir improvisar. Debe evaluarse con pruebas reales sobre cargas de trabajo reales, no con benchmarks genéricos ni con “a fulanito le va fenomenal”. Es precisamente donde un integrador con experiencia en múltiples plataformas de almacenamiento aporta más valor.

Error 07 de 10

No inventariar las funcionalidades enterprise que desaparecen

VMware lleva más de una década construyendo funcionalidades sobre las que muchas organizaciones han diseñado sus procesos operativos. Son esas cosas que “simplemente funcionan” hasta que dejan de estar ahí. Y cuando desaparecen, el impacto va mucho más allá de lo tecnológico.

⚖️

Balanceo automático (DRS)

Proxmox no tiene equivalente nativo: toca scripting propio. OpenStack ofrece funcionalidad parcial con Nova scheduling. En ambos casos, prepárate para arremangarte.

🛡️

Fault Tolerance y DR

VMware FT/SRM proporcionan failover automático. Las alternativas open source requieren orquestación propia con ZFS replication, Ansible y runbooks manuales. Funciona, pero alguien tiene que construirlo y mantenerlo.

🌐

SDN y microsegmentación

Proxmox SDN soporta VLANs/VXLANs/EVPN, pero IPAM/DHCP están en “tech preview” (léase: todavía no está listo del todo). No existe equivalente al firewall distribuido de NSX.

📋

Certificaciones de vendor

SAP, Oracle y Microsoft no certifican Proxmox. NVIDIA AI Enterprise tampoco está soportado oficialmente. Si dependes de estas certificaciones, es un detalle que conviene no pasar por alto.

🔧

Automatización y API

Los providers de Terraform para Proxmox son comunitarios. La API requiere especificar el nodo de destino manualmente. Nada insalvable, pero son fricciones que suman.

📞

Soporte 24/7

Proxmox opera en horario austriaco (7:00–17:00 CET), sin opción 24/7 a ningún nivel. Cuando producción cae a las 3 AM, literalmente no hay a quién llamar. Y no, Google no cuenta.

Ninguna de estas limitaciones invalida la plataforma — que quede claro. Pero cada una representa un hueco que hay que cubrir con ingeniería, herramientas o consultoría, y cada solución tiene un coste que debe figurar en el modelo financiero. Hacer como que no existen es la receta perfecta para sorpresas desagradables.

Error 08 de 10

Calcular el ROI solo con la línea de licenciamiento

El ahorro en licencias es real. Pero presentar ese ahorro como el ROI del proyecto es como valorar una mudanza solo por lo que cuesta el camión: técnicamente correcto, prácticamente incompleto.

Gartner estima que los servicios de migración cuestan entre 300 y 3.000 dólares por VM. El 44 % de las organizaciones sufre downtime no planificado durante la migración. Y los proyectos estimados en 6 meses se convierten en 24 con una frecuencia que ya nadie debería ignorar.

Los costes ocultos que erosionan el ROI

Formación: 5.000–15.000 $/técnico + 3–6 meses de productividad reducida (tu equipo aprende rápido, pero no es instantáneo). Integración: backup, monitorización, CMDB, automatización — conectores maduros para VMware que no existen para Proxmox. Desarrollo custom: scripts de balanceo, DR, monitorización = deuda técnica interna. Rotación: cuando el ingeniero que los construyó se marcha, el conocimiento se va con él. Y siempre se marcha en el peor momento.

Error 09 de 10

Diseñar para el Día 1 e ignorar el Día 2

La migración es solo el principio — la luna de miel, si quieres verlo así. El coste real se manifiesta en las operaciones del día a día durante años.

Cybernews reveló que muchas organizaciones que migraron a Proxmox no mantienen las actualizaciones de seguridad. Es comprensible: cuando todo el esfuerzo se concentra en migrar, es fácil olvidar que después hay que mantener. A escala, la UI se vuelve poco responsiva con varios miles de VMs y pmxcfs alcanza sus límites en torno a 11.000 VMs.

🔐

Seguridad y compliance

Gestión de CVEs, hardening, auditorías (ENS, ISO 27001, PCI DSS). ¿Qué SLA de respuesta ante vulnerabilidades críticas ofrece cada plataforma? Pregunta incómoda pero necesaria.

📊

Telemetría y observabilidad

Las alternativas open source (Prometheus, Grafana, Zabbix) son excelentes — de verdad que lo son — pero requieren integración y mantenimiento dedicado. No se configuran solas.

💾

Backup y recuperación

Proxmox Backup Server es funcional pero juega en otra liga de ecosistema comparado con Veeam, Commvault o IBM Spectrum Protect.

🏗️

Deuda técnica

Cada script custom es código que hay que mantener, documentar, testear y transferir. La deuda técnica es invisible hasta que no lo es — y entonces es lo único que ves.

Error 10 de 10

Creer que la tecnología es la decisión

La migración desde VMware no es un proyecto tecnológico: es una transformación operacional que afecta a personas, procesos, proveedores, presupuestos y riesgos. La tecnología es importante, por supuesto. Pero es solo una pieza del puzzle.

La migración de VMware no es un problema tecnológico. Es un problema de desacoplamiento operacional disfrazado de problema tecnológico.— Keith Townsend, The CTO Advisor

Las preguntas que realmente importan: ¿qué nivel de riesgo de gobernanza es aceptable para nosotros? ¿Tenemos el equipo necesario — o podemos formarlo a tiempo? ¿Cuál es nuestro TCO real a 5 y 10 años? ¿Cómo protegemos la inversión si el proyecto open source cambia de rumbo? ¿Qué cargas de trabajo migramos primero y cuáles quizá nunca deberían moverse? ¿Y quién será nuestro partner técnico cuando las cosas no funcionen como esperábamos? (Porque en algún momento, no funcionarán como se esperaba. Así es la vida.)

Nuestra convicción

El open source es, sin duda, la respuesta correcta para la infraestructura del futuro. De eso no tenemos ninguna duda. La cuestión no es si migrar, sino cómo hacerlo con el rigor que la decisión merece. La diferencia entre una migración exitosa y una que genere años de quebraderos de cabeza está en la calidad del análisis previo, la arquitectura elegida y el acompañamiento experto durante todo el proceso. Y oye, si después de leer todo esto te apetece hablar, aquí estamos.

La mejor migración es la que se hace con criterio, no con prisa

Más de 15 años diseñando, implementando y operando infraestructura de misión crítica. Conocemos VMware, Proxmox, OpenStack, Ceph, IBM Storage y las alternativas porque trabajamos con todas. Sin preferencias: solo la solución que encaja con tu negocio.

Hablemos de tu caso →
Conocer SIXE
Liquid AI’s New Model on IBM AIX

Corremos el último modelo de Liquid AI en IBM Power sin GPU | AIX

/en

Olvidémonos por un momento de los clusters de H100. En SIXE nos planteamos un reto: llevar hardware empresarial de 2018 al límite absoluto. La pregunta era simple pero ambiciosa: ¿Puede un IBM Power System ejecutando AIX y funcionando únicamente con CPU manejar modelos de IA de última generación?

Tomamos el nuevo modelo LFM2.5-1.2B de Liquid AI y lo ejecutamos en un procesador IBM POWER9. Hasta donde sabemos, esta es la primera vez que un modelo LFM2.5 funciona en AIX en modo Big-Endian.

El resultado

Casi 27 tokens por segundo, respuestas coherentes y menos de 750 MB de uso de memoria. Sin GPU. Sin NPU. Solo la potencia bruta de la arquitectura Power.

Pero la velocidad bruta es solo la mitad de la historia. Para demostrar que esto no es solo un juguete de benchmark, sometimos a LFM2.5 a un “Desafío de SysAdmin” — tareas reales de administración AIX — y lo comparamos con un Transformer estándar (TinyLlama 1.1B). Los resultados fueron impactantes.

IBM POWER9 + Liquid AI

La “salsa secreta”: ¿Qué es LFM2.5?

LFM2.5 es una arquitectura híbrida diseñada para máxima eficiencia, combinando bloques convolucionales (shortconv) para velocidad y capas de atención (GQA) para contexto. Cuenta con una enorme ventana de contexto de 128k tokens — suficiente para leer miles de líneas de logs sin olvidar el principio.

El hardware: IBM Power S924

Estas son las configuraciones específicas del benchmark:

EspecificaciónValor
ServidorIBM Power System S924
ProcesadorIBM POWER9 @ 2.75 GHz
ConfiguraciónEnterprise Multi-Core (compatible SMT-8)
Sistema operativoAIX 7.3 TL4
ArquitecturaBig-Endian

Rendimiento: encontrando el punto óptimo

Descubrimos que lanzar todos los núcleos contra el modelo perjudica el rendimiento debido a la sobrecarga de sincronización. El veredicto fue claro: usar solo 8 núcleos en modo SMT-2 (16 hilos) nos dio 26.7 tokens por segundo.

El momento de las pruebas: el desafío del admin

Los números están bien, pero ¿realmente funciona? Ejecutamos exactamente los mismos prompts a través de LFM2.5-1.2B y TinyLlama 1.1B (un transformer puro de tamaño similar). Aquí están las salidas reales.

Ronda 1: El error críptico (errpt)

Alimentamos los modelos con un log de error AIX relacionado con un fallo en la fuente de alimentación.

La entrada:

$ 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…”

Veredicto: Fallo. Se quedó atascado en un bucle infinito repitiendo “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)…”

Veredicto: Éxito. Identificó el componente y dio consejos accionables para revisar los ventiladores.

Ronda 2: La auditoría de seguridad

Proporcionamos un historial de logins que contenía un evento de crash oculto.

La entrada:

$ 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:

(generó 1 token y se detuvo)

Veredicto: Fallo. Silencio absoluto.

✅ 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.”

Veredicto: Éxito. Detectó inmediatamente la detención anormal del 27 de enero y recomendó una investigación.

Ronda 3: El consejo peligroso (/etc/passwd)

Pedimos a los modelos que auditaran un archivo de contraseñas estándar. Los resultados aquí fueron impactantes.

La entrada:

$ 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.”

Veredicto: FALLO CATASTRÓFICO. Afirmó que el usuario “root” no era necesario y recomendó eliminarlo. Seguir este consejo destruiría el servidor.

✅ 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.”

Veredicto: Éxito. Identificó correctamente riesgos potenciales reales como las cuentas “guest” y “nobody” con UIDs altos.

Ronda 4: Endurecimiento de servicios (lssrc -a)

Pedimos a los modelos que revisaran los servicios en ejecución.

La entrada:

$ lssrc -a

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

❌ TinyLlama 1.1B:

(generó 0 tokens)

Veredicto: Fallo. Silencio de nuevo.

✅ 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”

Veredicto: Éxito. Marcó servicios arriesgados como sendmail y portmap, y proporcionó el comando AIX correcto (stopsrc) para deshabilitarlos.

Por qué esto importa para los usuarios de IBM Power

Este benchmark demuestra que los IBM Power son motores de inferencia de IA capaces para tareas críticas on-premise:

Soberanía de datos: Analiza logs errpt sensibles, datos financieros o auditorías de usuarios localmente. Ningún dato sale de tu servidor.

Modernización de legacy: Usa LLMs locales para ayudar a entender y documentar código legacy COBOL o C que reside en el servidor.

Eficiencia: No necesitas un cluster de GPUs. Probablemente ya tienes el hardware capaz de hacer esto.

Pruébalo tú mismo :)

En SIXE creemos en el código abierto. Te dejamos aquí el código y el modelo para que puedas hacer tus pruebas. Cualquier aportación que quieras hacer, somos todo oídos.

Código: gitlab.com/librepower/llama-aix

Modelos: huggingface.co/librepowerai

user@aix:~$ # Inicio rápido en AIX
user@aix:~$ git clone https://gitlab.com/librepower/llama-aix.git
user@aix:~$ ./scripts/build_aix_73.sh

user@aix:~$ # Optimizar threading para el "punto óptimo"
user@aix:~$ smtctl -t 2 -w now

user@aix:~$ # ¡A disfrutar!
Flash systems 2026

Nuevo IBM FlashSystem 2026 | 5600, 7600 y 9600

/en

IBM acaba de presentar en Varsovia la nueva generación de IBM FlashSystem. Tres modelos nuevos (5600, 7600 y 9600), un motor de IA integrado llamado FlashSystem.ai, la quinta generación de su unidad flash propietaria y un mensaje que suena muy bien en un keynote: “almacenamiento autónomo co-dirigido por IA agéntica”.

Trabajamos con las cabinas FlashSystem a diario. Pero precisamente por eso creemos que merece un análisis de verdad ;) Así que vamos a desgranar qué hay detrás de cada cifra y dónde está el valor real.

Nuevo Flash System Storage de IBM para 2026

Qué trae IBM y por qué es el mayor lanzamiento en seis años

IBM no exagera cuando dice que este es su lanzamiento más importante desde 2020. No es un refresh cosmético: son tres cabinas simultáneas, un rediseño completo de la unidad flash y una capa de IA que va mucho más allá de lo que tenía la generación anterior.

La idea de fondo es que la cabina de almacenamiento deje de ser un “armario que guarda datos” y se convierta en un sistema que analiza, optimiza y se protege de forma autónoma.

Sam Werner, GM de IBM Storage, fue bastante claro durante la presentación: no se trata de reemplazar al administrador, sino de que deje de pasarse el día haciendo tareas repetitivas y pueda dedicar tiempo a arquitectura y planificación.

¿Suena a slide de keynote? Un poco. Pero los números de hardware que hay detrás son reales y, en algunos casos, genuinamente impresionantes.

Los tres modelos de FlashSystem de 2026: FlashSystem 5600, 7600 y 9600

La nueva línea sustituye a los FlashSystem 5300, 7300 y 9500 con mejoras sustanciales en capacidad, densidad y eficiencia. Los tres modelos estrenan formato de unidades NVMe EDSFF (Enterprise and Data Center SSD Form Factor), que es el estándar de la industria para máxima densidad y refrigeración en entornos de CPD:

FlashSystem 5600FlashSystem 7600FlashSystem 9600
Factor de forma1U · 12 drives2U · 32 drives2U · 32 drives (antes 4U)
CPU2×12 Core Intel Xeon · PCIe Gen 42×16 Core AMD EPYC · PCIe Gen 52×48 Core AMD EPYC · PCIe Gen 5
Capacidad raw633 TB1,68 PB3,37 PB (vs 1,8 PB del 9500)
Capacidad usable400 TBu1,2 PBu2,4 PBu
Capacidad efectivaHasta 2,4 PBeHasta 7,2 PBeHasta 11,8 PBe
IOPS2,6 millones4,3 millones6,3 millones
Read BW30 GB/s55 GB/s86 GB/s (vs 100 GB/s del 9500)
Puertos16× FC o 20× Ethernet32× FC o Ethernet32× FC o Ethernet (vs 48 del 9500)
Caso de usoEdge, ROBO, CPDs pequeñosVirtualización, analíticasBanca, ERP, cargas IA

Un salto generacional interesante: el 7600 y el 9600 usan AMD EPYC con PCIe Gen 5, mientras que el 5600 se queda con Intel Xeon y PCIe Gen 4. Tiene sentido por segmento — PCIe Gen 5 duplica el ancho de banda por lane, pero para el caso de uso edge del 5600, Gen 4 es más que suficiente y probablemente ayuda a mantener el precio contenido.

El dato que más llama la atención es el FlashSystem 5600 metiendo 2,4 PBe en 1U. Para entornos edge o centros de datos con limitaciones de espacio, esto cambia la ecuación. Y el 9600 pasa de 4U a 2U casi duplicando la capacidad raw (de 1,8 PB a 3,37 PB). Eso es progreso real, no marketing.

Eso sí, un matiz importante: las capacidades “efectivas” (PBe) asumen ratios de deduplicación y compresión que dependen enormemente del tipo de datos. Con datos ya comprimidos o cifrados, esos 11,8 PBe del 9600 se quedan en sus 2,4 PBu (usables) o 3,37 PB raw. Es física, no magia. IBM lo especifica en las notas al pie, pero conviene tenerlo muy presente.

Otro dato interesante que ha pasado bastante desapercibido: el 9600 baja de 48 a 32 puertos de I/O y su ancho de banda máximo de lectura pasa de 100 GB/s a 86 GB/s respecto al 9500. Es un tradeoff de diseño: más densidad a costa de algo de conectividad bruta. Dependiendo de tu arquitectura, esto puede importar o no, pero conviene saberlo.

Los modelos 7600 y 9600 incorporan biseles LED interactivos para visualizar el estado del sistema. Parece un detalle menor, pero cualquier admin que haya identificado un chasis a las 3 de la madrugada en un CPD lo va a agradecer.

Familia nuevo IBM FlashSystem 2026 modelos 5600 7600 9600 vista frontal con biseles LED

Nuevos IBM FlashSystem 2026 modelos 5600 7600 9600

FlashCore Module 5: QLC que rinde como TLC (y por qué eso importa)

Aquí es donde IBM tiene una ventaja competitiva que no es humo: diseñan y fabrican sus propias unidades flash. Y esto en el nuevo FlashCore Module de quinta generación (FCM5) se traduce en algo muy concreto.

El FCM5 ofrece capacidades de 6,6 / 13,2 / 26,4 / 52,8 y 105,6 TB en el nuevo formato NVMe EDSFF. Esa última cifra, 105 TB por unidad, es la más alta de la industria para cargas de trabajo enterprise. ¿Cómo lo consiguen? Usando NAND QLC con IP propietaria que rinde como TLC.

Para los que no vivan el día a día del almacenamiento: QLC (Quad-Level Cell) es más denso y barato que TLC (Triple-Level Cell), pero normalmente tiene menor resistencia a escritura y peor rendimiento. Los competidores que usan QLC estándar la limitan a cargas de lectura intensiva. IBM, al controlar el diseño de la unidad de principio a fin, ha conseguido superar esa limitación. De hecho, según las propias cifras de IBM, los FCM consiguen 5,5 veces más ciclos de escritura que las unidades QLC estándar de la industria.

Alistair Symon, VP de desarrollo de sistemas de almacenamiento, lo explicó durante el briefing previo al lanzamiento: otros fabricantes ofrecen unidades QLC de mayor capacidad, pero al ser QLC estándar, no soportan cargas de escritura intensiva durante la vida útil de depreciación del hardware. Los FCM5 de IBM sí.

¿Qué más integra el FCM5 directamente en el hardware?

  • Cifrado quantum-safe para todos los datos, directamente en la unidad
  • Compresión por hardware
  • Deduplicación en la propia unidad (novedad de esta generación), habilitando ratios de reducción 5:1
  • Análisis de E/S acelerado por hardware: estadísticas complejas en cada operación sin impactar rendimiento

Al descargar estas operaciones al módulo flash en lugar de hacerlas en los controladores de la cabina, IBM libera capacidad de procesamiento para las cargas de trabajo del cliente. Es la misma filosofía que aplicaron con las generaciones anteriores de FCM para la detección de anomalías, pero llevada un paso más allá con la deduplicación integrada.

FlashSystem.ai: IA agéntica en la cabina, con sus luces y sus sombras

FlashSystem.ai es la nueva capa de servicios de datos con IA agéntica (nosotros también implementamos agentes en de ia en empresas por cierto, jeje). Según IBM, está entrenada con decenas de miles de millones de puntos de telemetría y años de datos operativos reales. El sistema ejecuta miles de decisiones automatizadas al día que antes requerían supervisión humana.

Las capacidades que más interesan:

  • Se adapta al comportamiento de las aplicaciones en horas, no en semanas como los sistemas basados en plantillas
  • Recomienda optimizaciones de rendimiento explicando su razonamiento (esto permite auditar las decisiones de la IA, algo crucial para compliance)
  • Incorpora feedback del administrador para refinar recomendaciones con el tiempo
  • Ubicación inteligente de cargas de trabajo con movilidad de datos no disruptiva, incluyendo cabinas de terceros
  • Reduce a la mitad el tiempo de documentación para auditorías y cumplimiento

Y por supuesto, el dato estrella: reducción del 90% del esfuerzo manual de gestión. Es un número espectacular, pero viene con una nota al pie que merece leerse con cariño. IBM lo mide comparando tareas rutinarias específicas (provisionamiento de volúmenes con políticas de copia protegida y DR) en la nueva generación con FlashSystem.ai vs. la misma generación sin FlashSystem.ai. Es una comparación interna, en laboratorio, sobre operaciones seleccionadas.

¿Significa que el 90% es inventado? No. Significa que es el mejor escenario en tareas concretas. En la operativa real, con sus integraciones, sus peculiaridades y la entropía natural de cualquier infraestructura, el beneficio será menor. Probablemente seguirá siendo significativo — la automatización de tareas repetitivas aporta valor real — pero no esperéis que vuestro admin de storage de repente trabaje un día a la semana.

Hay algo que sí nos parece genuinamente útil: el razonamiento operativo explicable. Que el sistema no solo haga cosas, sino que explique por qué las hace. Para auditorías y compliance (que cada vez pesan más en sectores regulados), tener un log generado por IA de las decisiones operativas es una ventaja real frente a la competencia.

Detección de ransomware en 60 segundos: los datos y los asteriscos

Otro de los datos llamativos: el FCM5 detecta ransomware en menos de un minuto. Vamos a mirarlo con lupa.

El sistema analiza cada operación de E/S directamente en el hardware, buscando patrones anómalos asociados a cifrado malicioso. El modelo de detección (versión 3.3, lanzado en Q4 2025) acumula 24 meses de entrenamiento con telemetría de producción y mantiene una tasa de falsos positivos por debajo del 1%, medida durante 3 meses.

Combinado con Safeguarded Copy (copias con air gap lógico, inmutables y ocultas a cualquier conexión externa), IBM afirma que es posible recuperarse de un ataque en menos de un minuto.

Ahora bien, los asteriscos que IBM pone al pie:

  • La prueba original de detección sub-minuto se hizo en un FlashSystem 5200 (generación anterior) con un simulador de ransomware propio de IBM llamado WannaLaugh. Sí, se llama así. Puntos extra por el naming.
  • La detección es sobre el inicio del proceso de cifrado, no sobre la intrusión en el sistema.
  • Un ransomware suficientemente sofisticado que cifre lentamente y mimetice patrones normales de escritura podría evadir la detección

Dicho esto — y esto es importante — tener detección a nivel de hardware con menos del 1% de falsos positivos es objetivamente bueno. La mayoría de soluciones de detección de ransomware del mercado operan a nivel de sistema de archivos o red, con latencias mayores y tasas de error superiores. IBM opera una capa más abajo, directamente en el I/O del almacenamiento. Como capa adicional en una estrategia de seguridad por capas, aporta un valor real que la competencia no puede replicar fácilmente porque no controla el hardware de sus unidades flash.

El argumento que no sale en los datasheets: la cadena de suministro

Un ángulo que puede ser más relevante que cualquier benchmark para muchos responsables de TI en 2026: la crisis de suministro de almacenamiento. La demanda de capacidad para entrenamiento de modelos de IA está generando escasez y subidas de precios en SSDs a nivel global.

Werner fue directo al respecto: IBM está mejor posicionada que la mayoría de competidores porque fabrica sus propias unidades flash.

Si estás planificando una expansión de capacidad para los próximos 12-18 meses y te encuentras con lead times de 6 meses en SSDs estándar, tener un proveedor que controla la fabricación de sus unidades es un argumento que no aparece en ningún comparador de Gartner pero que puede definir un proyecto.

Pure Storage, Dell, NetApp y el resto, ¿ahora qué?

El mercado de cabinas all-flash enterprise está reñido. Comparemos lo que realmente diferencia al nuevo FlashSystem del resto:

AspectoIBM FlashSystem (nuevo)Pure Storage FlashArrayDell PowerStoreNetApp AFF
Unidades propietarias✅ FlashCore Module (QLC→TLC)✅ DirectFlash (150 TB)❌ SSDs estándar❌ SSDs estándar
IA en gestiónFlashSystem.ai (agéntica)Pure1 MetaCloudIQBlueXP / AIOps
Detección ransomware HW✅ En la unidad flash❌ Software❌ Software❌ Software (ONTAP)
Soporte cabinas 3ros✅ +500 vendors❌ Ecosistema cerradoParcialParcial (FabricPool)
Cifrado quantum-safe HW✅❌❌❌
Modelo de licenciamientoTradicional IBMEvergreen (muy transparente)APEX / tradicionalKeystone / tradicional

Donde IBM gana terreno claramente:

El FlashCore Module es una ventaja real y difícil de replicar. Controlar el diseño de la unidad flash permite integrar funcionalidades a nivel de hardware (detección de ransomware, cifrado quantum-safe, deduplicación) que la competencia solo puede hacer en software. Pure Storage también diseña sus propias unidades (DirectFlash), pero a día de hoy no integra detección de ransomware ni cifrado post-cuántico en el hardware.

La compatibilidad con más de 500 vendors de almacenamiento de terceros a través de FlashSystem Grid es una jugada inteligente. En la vida real nadie tiene un entorno homogéneo, y poder mover datos de forma no disruptiva entre cabinas IBM y de otros fabricantes resuelve un problema real de consolidación y migración.

Donde la competencia aprieta:

  • Pure Storage tiene una experiencia de usuario consistentemente mejor valorada y su modelo Evergreen es difícil de superar en transparencia de licenciamiento. Si el precio y la simplicidad de contratación son tus prioridades, Pure sigue siendo un rival formidable.
  • NetApp cuenta con ONTAP, un sistema operativo de almacenamiento con una madurez brutal en entornos híbridos y una base instalada enorme. Para quien ya está en el ecosistema NetApp, migrar es difícil de justificar solo por features nuevas.
  • Dell PowerStore compite bien en precio y tiene una integración profunda con el ecosistema VMware (ahora Broadcom), que sigue siendo el hipervisor dominante en muchas organizaciones.

En resumen: IBM no llega a barrer a la competencia, pero con esta generación sí se posiciona con argumentos técnicos sólidos que van más allá del marketing, especialmente en seguridad a nivel de hardware y en flexibilidad multivendor.

FlashCore Module 5 de IBM unidad flash propietaria para nuevo IBM FlashSystem con detección ransomware por hardware

FlashCore Module 5 de IBM

¿Para quién tiene sentido?

Después de digerir toda la información, los escenarios donde el nuevo FlashSystem encaja mejor:

  • Entornos de misión crítica (banca, seguros, sanidad) donde la combinación de detección de ransomware por hardware, Safeguarded Copy y cifrado quantum-safe aporta capas de seguridad que la competencia no iguala al mismo nivel.
  • Organizaciones con infraestructura heterogénea que necesitan consolidar sin hacer un rip-and-replace total. La compatibilidad con +500 vendors y la movilidad de datos entre cabinas es un argumento genuino.
  • CPDs con limitaciones de espacio donde la densidad del 5600 (2,4 PBe en 1U) puede evitar ampliaciones físicas.
  • Empresas que ya trabajan con infraestructura IBM Storage y buscan una evolución natural que se integre con sus inversiones existentes, especialmente si combinan con SVC u otras soluciones del portfolio.

¿Y quién debería pensárselo dos veces? Si tu entorno es 100% virtualizado con VMware y toda tu gestión pasa por vCenter, la integración con Dell puede tener más sentido operativo. Si tu prioridad es simplicidad de contratación y tu equipo es pequeño, el modelo Evergreen de Pure Storage es difícil de batir.

Conclusiones

IBM ha hecho los deberes con este lanzamiento. La combinación de hardware propietario (FCM5 con QLC que rinde como TLC), IA agéntica integrada (FlashSystem.ai) y la estrategia de compatibilidad multivendor posiciona al nuevo FlashSystem como una propuesta seria.

¿Es perfecto? No. El marketing infla algunos números (como hacen todos, no nos engañemos), la etiqueta de “almacenamiento autónomo” es más aspiracional que descriptiva, y hasta que no veamos benchmarks independientes y experiencias de campo con meses de operación, ciertos claims quedan como promesas.

Pero si ponemos todo en una balanza: la tecnología es sólida, la arquitectura tiene sentido, la dirección es la correcta. Y el hecho de que IBM controle desde el diseño de la unidad flash hasta la capa de IA pasando por el sistema operativo SVC le da una coherencia de stack que no muchos fabricantes pueden ofrecer.

Disponibilidad general: 6 de marzo de 2026.

¿Estás evaluando el nuevo IBM FlashSystem o planificando una migración?

En SIXE llevamos años trabajando con cabinas IBM FlashSystem en entornos de producción reales. Diseñamos, implantamos, migramos y damos soporte técnico de IBM Storage sin intermediarios. Si necesitas asesoramiento sobre cómo encajaría esta nueva generación en tu infraestructura, estaremos encantados de echar un cable.

Ceph vs MinIO 2026 | Guía de almacenamiento distribuido

/en

Otro año más vivo, otro año más viendo cómo la industria del almacenamiento distribuido consigue superarse a sí misma en creatividad comercial. Si 2024 fue el año en que todos descubrieron que necesitaban “almacenamiento para IA” (spoiler: es el mismo almacenamiento de siempre, pero con mejor marketing), 2025 ha sido el año en que MinIO decidió inmolarse públicamente mientras el resto del ecosistema sigue evolucionando a buen ritmo.

Agarraos, que vienen curvas.

minio vs ceph se vienen curvas

El drama del año: MinIO pasa a “modo mantenimiento” (léase: modo abandono)

Si no habéis seguido la telenovela de MinIO, dejadme que os ponga en contexto. MinIO era el object storage open source que todo el mundo desplegaba. Sencillo, rápido, compatible con S3. Lo tenías funcionando en 15 minutos. Era el WordPress del almacenamiento de objetos.

Pues bien, en diciembre de 2025, un commit silencioso en el README cambió todo: “This project is currently under maintenance and is not accepting new changes.” Sin comunicado. Sin guía de migración. Sin despedida. Solo un commit y adiós muy buenas.

La comunidad, como era de esperar, ardió. Un desarrollador lo resumió perfectamente: “A silent README update just ended the era of MinIO as the default open-source S3 engine.”

Pero esto no vino de la nada. MinIO llevaba años con una estrategia de “open source pero no te pases”:

  • 2021: Cambio silencioso de Apache 2.0 a AGPL v3 (sin anuncio, sin PR, sin nada)
  • 2022-2023: Campañas agresivas contra Nutanix y Weka por “violaciones de licencia”
  • Febrero 2025: Eliminan la consola web, gestión de buckets y replicación de la versión Community
  • Octubre 2025: Dejan de distribuir imágenes Docker
  • Diciembre 2025: Modo mantenimiento

El mensaje es claro: si quieres MinIO de verdad, paga. Su producto enterprise AIStor empieza en 96.000€/año para 400 TiB. Para 1 PB, hablamos de más de 244.000€/año.

¿La lección? En 2025, “Open Source” sin Gobernanza Abierta no vale nada. MinIO era una empresa con un producto open source, no un proyecto de comunidad. La diferencia importa.

Mientras tanto, Ceph sigue nadando tranquilo

Mientras MinIO se autodestruía, Ceph celebraba su vigésima release estable: Tentacle (v20.2.0), lanzada en noviembre de 2025. El proyecto acumula más de 1 exabyte de almacenamiento desplegado globalmente en más de 3.000 clusters.

Lo más interesante de Tentacle es FastEC (Fast Erasure Coding), que mejora el rendimiento de lecturas y escrituras pequeñas entre 2x y 3x. Esto hace que erasure coding sea finalmente viable para cargas de trabajo que no son puro archivo frío. Con un perfil EC 6+2, ahora puedes conseguir aproximadamente el 50% del rendimiento de réplica 3 mientras usas solo el 33% del espacio.

Para los que llevamos años oyendo “erasure coding es lento para producción”, esto es un cambio de juego real.

Otras novedades de Tentacle:

  • Soporte SMB integrado via Samba Manager
  • Grupos de gateway NVMe/TCP con soporte multi-namespace
  • Autenticación OAuth 2.0 en el dashboard
  • Directorios CephFS case-insensitive (por fin)
  • ISA-L reemplaza a Jerasure (que estaba abandonado)

El Crimson OSD (basado en Seastar para optimización NVMe) sigue en technical preview. No está listo para producción, pero el roadmap es prometedor.

Los números que importan

Bloomberg opera más de 100 PB en clusters Ceph. Son Diamond member de la Ceph Foundation y su Head of Storage Engineering está en el Governing Board. DigitalOcean tiene 54+ PB en 37 clusters de producción. CERN mantiene 50+ PB en más de 10 clusters.

Y aquí viene lo interesante: ZTE Corporation está entre los top 3 contribuidores globales a Ceph y el número 1 en China. Su producto TECS CloveStorage (basado en Ceph) está desplegado en más de 320 proyectos NFV en todo el mundo, incluyendo China Mobile, izzi Telecom (México) y Deutsche Telekom.

El sector telco es el superpoder secreto de Ceph. Mientras muchos siguen pensando en appliances tradicionales, las telecos están corriendo Ceph en producción a escala masiva.

El ecosistema enterprise: entendiendo qué estás comprando

Aquí es donde la cosa se pone interesante. Y merece la pena entender bien qué hay detrás de cada opción.

 

IBM Fusion: dos sabores para diferentes necesidades

IBM tiene dos productos bajo la marca Fusion, y es importante entender la diferencia:

  • IBM Fusion HCI: Usa IBM Storage Scale ECE (el antiguo GPFS/Spectrum Scale). Sistema de ficheros paralelo con erasure coding distribuido. Appliance hiperconvergente que escala de 6 a 20 nodos.
  • IBM Fusion SDS: Usa OpenShift Data Foundation (ODF), que está basado en Ceph empaquetado por Red Hat.

Storage Scale es una tecnología genuinamente diferenciada, especialmente para HPC. Su arquitectura de sistema de ficheros paralelo ofrece capacidades que Ceph simplemente no tiene: gestión avanzada de metadatos, tiering integrado, AFM para federación… Si tienes cargas de trabajo de computación de alto rendimiento, supercomputación o IA a escala seria, Storage Scale tiene argumentos técnicos sólidos que lo justifican.

Los claims de rendimiento de IBM Fusion HCI son impresionantes: aceleración 90x en queries S3 con caching local, rendimiento equivalente a Databricks Photon al 60% del coste, etc.

Ahora bien, siempre merece la pena preguntarse: ¿cuánto de ese rendimiento es la tecnología propietaria y cuánto es simplemente hardware bien dimensionado con una configuración adecuada? No es una crítica, es una pregunta legítima que cualquier arquitecto debería hacerse antes de tomar una decisión.

En el caso de Fusion SDS, estás comprando Ceph con el valor añadido del empaquetado, la integración con OpenShift, y el soporte enterprise de IBM. Para muchas organizaciones, eso tiene un valor real.

Red Hat Ceph Storage: el estándar enterprise

Red Hat Ceph Storage sigue siendo la distribución enterprise de referencia. Ofrecen 36 meses de soporte de producción más 24 meses opcionales de soporte extendido. El producto está sólido y bien integrado.

Lo que estás comprando realmente es:

  • Paquetes testeados y certificados
  • Soporte enterprise 24/7
  • Ciclos de vida predecibles
  • Integración con OpenShift

¿Vale la pena? Depende de tu contexto. Si tu organización necesita un contrato de soporte para cumplir con compliance o simplemente para dormir tranquila, probablemente sí. Y nosotros encantados de ayudarte con ello. Pero si tienes el equipo técnico para operar Ceph upstream, es una decisión que merece análisis.

SUSE: una lección sobre dependencia de vendors

Aquí hay una historia que merece reflexión: SUSE abandonó completamente el mercado de Ceph enterprise. Su producto SUSE Enterprise Storage (SES) llegó a fin de soporte en enero de 2023. Tras adquirir Rancher Labs en 2020, pivotaron hacia Longhorn para almacenamiento Kubernetes-nativo.

Si eras cliente de SES, te encontraste huérfano. Tus opciones fueron migrar a Red Hat Ceph Storage, Canonical Charmed Ceph, community Ceph, o buscar un partner especializado que te ayudara con la transición.

No es una crítica a SUSE; las empresas pivotan según su estrategia. Pero es un recordatorio de que el control sobre tu infraestructura tiene un valor que no siempre aparece en el TCO.

Pure Storage y NetApp: el enfoque appliance

Pure Storage ha creado una categoría llamada “Unified Fast File and Object” (UFFO) con su familia FlashBlade. Hardware impresionante, rendimiento consistente, experiencia de usuario pulida. Su FlashBlade//S R2 escala hasta 60 PB por cluster con DirectFlash Modules de 150 TB.

NetApp StorageGRID 12.0 se enfoca en IA con mejoras de throughput de 20x via caching avanzado y soporte para más de 600 mil millones de objetos en un solo cluster.

Ambas son soluciones sólidas que compiten con Ceph RGW en object storage compatible con S3. El rendimiento es excelente. La pregunta que cada organización debe hacerse es si el premium justifica la dependencia del vendor para su caso de uso específico.

La pregunta que nadie hace: ¿qué estás comprando realmente?

Aquí es donde me pongo el sombrero de ingeniero reflexivo.

Ceph upstream es extremadamente estable. Lleva 20 releases. La Ceph Foundation incluye a IBM, Red Hat, Bloomberg, DigitalOcean, OVHcloud y decenas más. El desarrollo está activo, la comunidad es sólida, y la documentación es extensa.

Entonces, ¿cuándo tiene sentido pagar por una distribución enterprise y cuándo no?

Tiene sentido cuando:

  • Tu organización requiere un contrato de soporte por compliance o política interna
  • No tienes el personal técnico para operar Ceph y no quieres desarrollarlo
  • Necesitas ciclos de actualización predecibles y testeados
  • El coste del downtime es mayor que el coste de la licencia
  • Necesitas integración específica con otros productos del vendor

Merece más análisis cuando:

  • La decisión se basa en “es lo que hace todo el mundo”
  • Nadie ha evaluado realmente las alternativas
  • La principal razón es que “el vendor nos dijo que el open source no tiene soporte”
  • Tienes equipo técnico capaz pero no se ha invertido en su formación

El desafío real es el conocimiento. Ceph tiene una curva de aprendizaje pronunciada. Diseñar un cluster correctamente, entender CRUSH maps, tunear BlueStore, optimizar placement groups… esto requiere formación seria y experiencia práctica.

Pero una vez que tienes ese conocimiento, tienes opciones. Puedes elegir un vendor enterprise con criterio, sabiendo exactamente qué valor añadido estás comprando. O puedes operar upstream con soporte especializado. La clave es que la decisión sea informada.

Desmitificando los claims de marketing

Una cosa que siempre recomiendo es leer los benchmarks y claims de marketing con espíritu crítico constructivo.

“Nuestro producto es 90x más rápido” — ¿Comparado con qué baseline? ¿En qué workload específico? ¿Con qué configuración del competidor?

“Rendimiento equivalente a [competidor] al 60% del coste” — ¿Incluye el TCO completo? ¿Licenciamiento, soporte, formación, personal?

“Solución certificada enterprise-grade” — ¿Qué significa eso exactamente? Porque Ceph upstream también es “enterprise-grade” en CERN, Bloomberg, y cientos de telecos.

No digo que los claims sean falsos. Digo que el contexto importa. La realidad es que el rendimiento de almacenamiento distribuido depende enormemente de:

  • Diseño correcto del cluster (failure domains, placement groups)
  • Hardware apropiado (red 25/100GbE, NVMe con protección power-loss)
  • Configuración del sistema operativo (IOMMU, CPU governors)
  • Tuning específico del workload (osd_memory_target, bluestore settings)

Un cluster Ceph bien diseñado y operado por gente con experiencia puede alcanzar rendimientos impresionantes. El benchmark de Clyso alcanzó 1 TiB/s con 68 servidores Dell PowerEdge. IBM demostró más de 450.000 IOPS en un cluster Ceph de 4 nodos con 24 NVMe por nodo.

A veces, ese sello de “solución certificada” que ves en un datasheet es, en el fondo, software libre con una configuración experta, hardware bien dimensionado, y mucho testing. Lo cual tiene valor, pero conviene saberlo.

La jugada inteligente: decidir con información

Después de 15 años en este sector, mi conclusión es que no hay una respuesta única. Lo que hay son decisiones informadas.

Para algunas organizaciones, una solución enterprise empaquetada es exactamente lo que necesitan: soporte garantizado, ciclos predecibles, integración validada, y la tranquilidad de tener un vendor responsable. IBM Fusion con Storage Scale es una opción excelente para HPC. Red Hat Ceph Storage es sólido para quien quiere Ceph con respaldo enterprise.

Para otras organizaciones, Ceph upstream con soporte y formación especializada ofrece ventajas importantes:

  1. Governance de fundación: Ceph es un proyecto de la Linux Foundation con gobierno abierto. No puede pasar lo de MinIO.
  2. Comunidad activa: Miles de contribuidores, releases regulares, bugs corregidos rápidamente.
  3. Flexibilidad: Es tu cluster, tu configuración. Si mañana decides cambiar de partner de soporte, no pierdes nada.
  4. TCO transparente: El software es gratis. Inviertes en hardware apropiado y en conocimiento.
  5. Control de versiones: Actualizas cuando tiene sentido para ti, no cuando el vendor saca la siguiente release empaquetada.

El denominador común en ambos casos es el conocimiento. Ya sea que compres una solución enterprise o despliegues upstream, entender Ceph a fondo te permite tomar mejores decisiones, negociar mejor con vendors, y resolver problemas más rápido.

¿Dónde conseguir ese conocimiento?

Ceph es complejo. Pero habemus caminos..

La documentación oficial es extensa y ha mejorado mucho. El Ceph blog tiene deep-dives técnicos excelentes.

Cephalocon es la conferencia anual donde puedes aprender de los que operan Ceph a escala real (Bloomberg, CERN, DigitalOcean).

Formación estructurada con labs prácticos es la forma más eficiente de construir competencia real. No se aprende Ceph leyendo slides; se aprende rompiendo y arreglando clusters.

Soporte técnico L3 de gente que vive Ceph a diario te saca de los apuros cuando las cosas se complican en producción. Porque se van a complicar. En SIXE llevamos años formando equipos técnicos en Ceph y dando soporte L3 a organizaciones de todo tipo: las que operan upstream, las que usan distribuciones enterprise, y las que están evaluando opciones.

Nuestro programa de formación en Ceph cubre desde arquitectura básica hasta operaciones avanzadas con labs prácticos reales. Y si ya tienes Ceph en producción y necesitas respaldo técnico de verdad, nuestro soporte técnico especializado está diseñado exactamente para eso.

Además, acabamos de lanzar un programa de certificación con badges en Credly para que tu equipo pueda demostrar sus competencias de forma tangible. Porque en este sector, “sé Ceph” no significa lo mismo para todo el mundo.


Conclusiones para 2026

  1. MinIO está muerto para uso serio. Busca alternativas. Ceph RGW, SeaweedFS, o incluso el fork OpenMaxIO si eres valiente.
  2. Entiende qué estás comprando. Hay casos donde una solución enterprise empaquetada aporta valor real. Hay otros donde estás pagando principalmente por un logo y una configuración que podrías replicar.
  3. Ceph upstream está maduro y es production-ready. Bloomberg, DigitalOcean, CERN y 320+ proyectos de telecos no pueden estar todos equivocados.
  4. El verdadero coste del almacenamiento distribuido es el conocimiento. Invierte en formación y soporte técnico de calidad, independientemente de qué opción elijas.
  5. El control sobre tu infraestructura tiene valor. Pregúntale a los clientes de SUSE SES cómo les fue cuando el vendor decidió pivotar.
  6. La governance del proyecto importa tanto como la tecnología. Fundación abierta > empresa con producto open source.

El 2026 se presenta interesante. FastEC va a cambiar la ecuación de erasure coding. La integración con IA y ML va a seguir presionando por más rendimiento. Y el ecosistema de vendors va a seguir evolucionando con propuestas que merecen evaluación seria.

Tú decides.

mariadb en AIX

Portar MariaDB a IBM AIX | Cómo AIX empata con Linux – Parte 2

/en

De “AIX es lento” a “AIX iguala a Linux” (si usas las herramientas adecuadas)

En la Parte 1, peleé con CMake, implementé un Thread Pool desde cero y logré una versión estable de MariaDB 11.8.5 para AIX. El servidor aguantó 1.000 conexiones concurrentes, 11 millones de consultas y cero fugas de memoria.

Entonces, lancé un benchmark de búsqueda vectorial.

  • AIX: 42 consultas por segundo (QPS).
  • Linux (mismo hardware): 971 consultas por segundo.

Veintitrés veces más lento. En idéntico hardware IBM Power S924. Misma versión de MariaDB. Mismo dataset.

Esta es la historia de cómo descubrimos que no existía tal brecha de rendimiento: solo errores de configuración y un compilador que no estaba a la altura.

Engineering debugging process visualization

Capítulo 1: Esa sensación de hundimiento

Existe un tipo particular de desesperación que sientes al ver una diferencia de rendimiento de 23x en hardware idéntico. Es ese momento en el que piensas: “quizá debería haberme hecho florista”.

Pongámonos en situación: ambas máquinas son LPARs corriendo en servidores IBM Power S924 con procesadores POWER9 a 2750 MHz. El mismo MariaDB 11.8.5. El mismo dataset de prueba: 100.000 vectores con 768 dimensiones, usando el índice MHNSW (Hierarchical Navigable Small World) de MariaDB.

La prueba era simple: encontrar los 10 vecinos más cercanos (KNN) a un vector de consulta. Es el tipo de operación que alimenta todas las funciones de búsqueda por IA (RAG) modernas.

  • Linux lo hizo en ~1 milisegundo.
  • AIX tardó 24 milisegundos.

Mi primer instinto fue la negación. “El benchmark está mal”. No lo estaba. “El índice está corrupto”. No lo estaba. “La red va lenta”. Era una conexión socket local.

Tocaba remangarse y cavar hondo.

Capítulo 2: Los primeros 65x – La configuración importa

La caché amnésica

La primera pista nos la dio el profiler de MariaDB. Cada consulta tardaba exactamente lo mismo, fuera la primera o la número cien. Las cachés no funcionan así.

Revisé la configuración MHNSW de MariaDB:

SHOW VARIABLES LIKE 'mhnsw%';

mhnsw_max_cache_size: 16777216

16 MB. Nuestro grafo vectorial necesita unos 300 MB para mantener la estructura HNSW en memoria.

Aquí está el problema: cuando la caché se llena, MariaDB no expulsa las entradas antiguas (no hay LRU). Lo tira todo y empieza de cero. En. Cada. Consulta.

Imagina una biblioteca donde, cuando las estanterías se llenan, el bibliotecario quema todos los libros y pide copias nuevas. Para cada usuario.

El arreglo: mhnsw_max_cache_size = 4GB en la configuración.

Resultado: 42 QPS → 112 QPS. Una mejora de 2.7x con una línea de configuración.

El problema del tamaño de página (Page Size)

AIX usa por defecto páginas de memoria de 4 KB. Linux en POWER usa páginas de 64 KB.

Para el patrón de acceso de MHNSW —que consiste en perseguir punteros a través de un grafo de 300 MB— esto es crítico. Con páginas de 4 KB, necesitas 16 veces más entradas en el TLB (Translation Lookaside Buffer) para mapear la misma memoria. Los fallos de TLB (TLB misses) son caros.

Piénsalo como navegar por una ciudad. Con páginas de 4 KB, necesitas instrucciones paso a paso para cada edificio. Con páginas de 64 KB, te dan instrucciones por barrios. Mucho más rápido cuando te mueves constantemente.

El arreglo: Un script wrapper que establece LDR_CNTRL=DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K@SHMPSIZE=64K.

Resultado: 112 QPS → 208 QPS secuenciales, y 2.721 QPS con 12 workers paralelos.

Marcador tras la Fase 1

ConfiguraciónQPS SecuencialCon 12 workers
Base42~42
+ 4 GB caché112–
+ 64K pages2082.721

Mejora de 65x con dos cambios de configuración. Sin tocar código.

Pero seguíamos siendo 6 veces más lentos que Linux por núcleo. La investigación continuó.

Capítulo 3: El misterio de CPU vs. Memory Stalls

Con la configuración arreglada, saqué las herramientas de profiling. MariaDB tiene un profiler interno que desglosa el tiempo por fases.

AIX:

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

Linux:

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

El tiempo de CPU era 1.8x más lento en AIX (esperable por diferencias de compilador). Pero los “stalls” (paradas de memoria) eran 329 veces peores.

La causa raíz: Invalidación de caché por el Hipervisor

Tardé dos días en descubrir esto: en una LPAR compartida, el hipervisor POWER interrumpe periódicamente a los procesadores virtuales para dar tiempo a otras particiones. Cuando lo hace, puede invalidar líneas de caché L2/L3.

Recorrer un grafo MHNSW es una “persecución de punteros” a través de 300 MB de memoria: literalmente el peor escenario para la invalidación de caché. Saltas de nodo en nodo y el hipervisor te vacía la caché periódicamente.

Es como intentar leer un libro mientras alguien te lo cierra y lo devuelve a la estantería cada dos por tres.

El sistema Linux tenía procesadores dedicados. El AIX estaba en modo compartido. No estábamos comparando manzanas con manzanas.

Pero antes de probar procesadores dedicados, tenía que arreglar el problema del compilador.

Capítulo 4: La odisea del compilador

Todo lo que intenté con GCC (y por qué falló)

IntentoResultadoRazón
-flto (Link Time Optimization)ImposibleGCC LTO requiere formato ELF; AIX usa XCOFF.
-fprofile-generate (PGO)Falla compilaciónErrores del ensamblador con reubicación TOC.
-ffast-mathRompe todoViolaciones IEEE corrompen el hash del Bloom filter.
-funroll-loopsMás lentoInfla la caché de instrucciones (I-cache bloat). A POWER9 no le gusta.

El toolchain de GCC en AIX no tiene soporte LTO real. No es un flag que olvidé: es arquitecturalmente imposible porque la implementación LTO de GCC requiere ELF, y AIX usa XCOFF. Los paquetes de MariaDB en Ubuntu usan -flto=auto. Esa optimización simplemente no existe para AIX con GCC.

IBM Open XL: El giro de guion

Llevaba tres días intentando que GCC fuera más rápido. Era hora de probar algo diferente.

IBM Open XL C/C++ 17.1.3 es el compilador moderno de IBM, basado en LLVM/Clang. Genera un código significativamente mejor para POWER9 que GCC.

Compilar MariaDB con Open XL requirió resolver cinco problemas:

  1. Falta header HTM: Open XL no tiene el htmxlintrin.h de GCC. Creé un stub.
  2. 32-bit por defecto: Las herramientas de AIX son de 32 bits. Tuve que forzar OBJECT_MODE=64.
  3. LLVM AR incompatible: El AR de Open XL no manejaba bien XCOFF. Usé el /usr/bin/ar del sistema.
  4. Conflictos OpenSSL: Usar -DWITH_SSL=system para evitar líos con wolfSSL.
  5. Rutas de librerías: Flags explícitos -L/opt/freeware/lib para el linker.

Y entonces, lancé el benchmark:

Compilador30 ConsultasPor consulta
GCC 13.3.00.190s6,3 ms
Open XL 17.1.30.063s2,1 ms

Tres veces más rápido. Mismo código fuente. Mismos flags de optimización (-O3 -mcpu=power9).

Y un detalle clave: la varianza con GCC era del 10-40% entre ejecuciones. Con Open XL fue menor al 2%. Una estabilidad roca.

¿Por qué tanta diferencia?

Open XL (al estar basado en LLVM) tiene:

  • Mejor planificación de instrucciones (instruction scheduling) para la ejecución fuera de orden (Out-of-Order) de POWER9.
  • Asignación de registros superior.
  • Pasadas de optimización más agresivas.

Capítulo 5: Los callejones sin salida de LTO y PGO

La esperanza es lo último que se pierde. ¿Quizás LTO y PGO sí funcionan en Open XL?

LTO: La ironía

Open XL soporta -flto=full en XCOFF. ¡Compila! Pero…

Resultado: 27% más lento que Open XL sin LTO.

¿Por qué? Las librerías compartidas en AIX requieren una lista explícita de exportaciones (exports.exp). El script de CMake vio ~27.000 símbolos para exportar.

La ventaja principal de LTO es la internalización de funciones (hacerlas locales para optimizarlas o hacer inlining). Cuando te obligan a exportar 27.000 símbolos, no puedes internalizar nada. Te quedas con el overhead de LTO pero sin sus ventajas.

Es como pagar el gimnasio y que te digan que no puedes usar ninguna máquina.

PGO: Los perfiles que nunca existieron

Profile Guided Optimization sonaba prometedor:

  1. Compilar con -fprofile-generate
  2. Ejecutar carga de entrenamiento
  3. Recompilar con -fprofile-use

El paso 1 funcionó. El paso 2… los perfiles nunca aparecieron.

La causa raíz: El runtime de profiling de LLVM usa destructores al salir. En AIX con XCOFF, la semántica de los destructores en librerías compartidas es distinta a ELF. Simplemente, no se llaman de forma fiable en configuraciones complejas como MariaDB.

Capítulo 6: La revelación de la LPAR

Ahora tenía un compilador rápido. Toca probar procesadores dedicados y eliminar el problema de la caché del hipervisor.

La matriz de pruebas

Configuración LPARGCCOpen XL
12 vCPUs compartidas0.190s0.063s
12 dedicadas (Capped)0.205s0.082s
21 dedicadas (Capped)0.320s0.067s

Espera. ¿El modo Compartido es más rápido que el Dedicado?

El factor WoF

POWER9 tiene una función llamada Workload Optimized Frequency (WoF). En modo compartido con baja utilización, un solo núcleo puede acelerar hasta ~3.8 GHz (turbo). Los procesadores dedicados “Capped” suelen estar limitados a la frecuencia base (2750 MHz).

Para una consulta mono-hilo, el modo compartido gana un 38% extra de velocidad de reloj. Eso supera la penalización de la caché para esta carga específica.

Es como elegir entre un Ferrari en una autopista con tráfico ocasional (Compartido) vs un camión en un carril exclusivo pero con limitador de velocidad (Dedicado).

El desastre del modo Donación

Hay una tercera opción: procesadores dedicados en modo “Donación” (Donating), que ceden ciclos ociosos al pool compartido.

ModoGCCOpen XL
Capped0.205s0.082s
Donating0.325s0.085s

Regresión del 60% con GCC.
Cada vez que llega una consulta (burst), hay una latencia para recuperar los ciclos donados. Para bases de datos, esto es devastador.

Recomendación: Nunca uses modo Donating para bases de datos.

Capítulo 7: El marcador final (el verdadero giro)

Nuevos benchmarks en hardware POWER9 idéntico, Enero 2026:

PlataformaNúcleos30 Consultas
Linux24 dedicados0.057s
AIX + Open XL12 compartidos0.063s
AIX + Open XL21 dedicados0.067s

Un momento. El sistema AIX tiene 21 núcleos vs los 24 de Linux. Eso es un 12.5% menos de núcleos (y menos caché L3).

¿La “diferencia” medida? Entre 10-18%.

Eso no es una diferencia de rendimiento de software. Es una diferencia de hardware pura y dura.

Con IBM Open XL, AIX ofrece un rendimiento por núcleo idéntico a Linux. ¿La diferencia de 23x con la que empezamos? Nunca fue culpa de AIX. Fue culpa de:

  1. Una caché mal configurada (16MB vs 4GB).
  2. Tamaño de página incorrecto (4 KB vs 64 KB).
  3. El compilador equivocado (GCC vs Open XL).

El mito de “AIX es lento” ha muerto.

El Museo de los Intentos Fallidos

La ciencia no va solo de lo que funciona, sino de documentar lo que no funciona. Aquí mi muro de “buen intento”:

Qué probamosResultadoNotas
mhnsw_max_cache_size = 4GB5x más rápidoElimina el “thrashing” de caché.
LDR_CNTRL 64K pages~40% más rápidoReduce fallos de TLB.
IBM Open XL 17.1.33x más rápidoMejor generación de código POWER9.
Open XL + LTO27% más lentoConflicto con exportaciones AIX.
POWER VSX Bloom Filter41% más lentoNo hay multiplicación de vectores de 64-bit en P9.
Software PrefetchingSin efectoEl hipervisor desaloja los datos antes de usarlos.
DSCR TuningBloqueadoEl hipervisor controla el DSCR en LPAR compartida.

El dato del VSX es interesante: implementamos un Bloom Filter SIMD usando extensiones vectoriales de POWER. Fue un 41% más lento que el escalar. POWER9 no tiene multiplicación vectorial de 64 bits, por lo que simularla es más lento que dejar que el motor Out-of-Order maneje el bucle escalar.

Lecciones aprendidas

1. Los “defaults” los carga el diablo

Una caché por defecto de 16MB convertía consultas de 1ms en 24ms. Una penalización de 24x por un parámetro de configuración. Cuestiona siempre los valores por defecto al portar software.

2. El mito de la lentitud era un problema de Toolchain

Con GCC, éramos 3-4x más lentos que Linux. Con Open XL, igualamos a Linux. La plataforma nunca fue lenta; la cadena de herramientas por defecto (GCC en AIX) no está optimizada para alto rendimiento.

3. No todas las optimizaciones se portan

LTO, PGO y vectorización SIMD fallaron en AIX por razones arquitecturales. Lo que hace rápido a Linux no siempre se traduce directamente. Mídelo todo.

Recomendaciones para usuarios

Si usas MariaDB en AIX:

  1. Usa la build con Open XL (versión 3, próximamente).
  2. Configura mhnsw_max_cache_size a mínimo 4GB si usas vectores.
  3. Usa LPAR compartida para latencia de consultas individuales (WoF ayuda).
  4. Nunca uses modo “Donating” para BBDD.
  5. Fuerza páginas de 64K con el wrapper LDR_CNTRL.

¿Qué sigue?

Los RPMs están publicados en aix.librepower.org. La Release 2 incluye los arreglos de configuración. La Release 3 (con Open XL) está en camino.

Para las organizaciones que ya corren cargas críticas en AIX —bancos, aseguradoras, sanidad— la opción de correr también MariaDB moderno con rendimiento nativo abre un mundo de posibilidades.

AIX iguala a Linux. El mito ha muerto. Y MariaDB en AIX está listo para producción.

TL;DR

  • Empezamos con un gap de 23x de rendimiento (42 QPS vs 971 QPS).
  • Arreglo de caché: Mejora de 5x.
  • Arreglo de Page Size (64K): ~40% extra.
  • Cambio a compilador IBM Open XL: 3x mejor que GCC.
  • Resultado final: GAP CERO (la diferencia del 10% corresponde a tener 12.5% menos núcleos).
  • “AIX es lento para Open Source” siempre fue un mito causado por usar el compilador incorrecto.
mariadb en AIX

Portar MariaDB a IBM AIX | 3 semanas de sufrimiento – Parte 1

/en

Llevamos MariaDB a AIX (Parte 1)

Hay decisiones en la vida que tomas sabiendo perfectamente que te van a doler. Casarte. Tener hijos. Correr una maratón. Portar MariaDB 11.8 a IBM AIX.

Esta (Parte 1) es la historia de la última decisión.

MariaDB en AIX

“¿Tan difícil puede ser llevar MariaDB a AIX?”

Todo empezó con una pregunta inocente durante una reunión de equipo: “¿Por qué no tenemos MariaDB en nuestros sistemas AIX?”.

Esto es lo que pasa con AIX que la gente que nunca ha trabajado con él no entiende: AIX no se anda con chiquitas. Cuando los bancos necesitan un uptime de “cinco nueves” para sus sistemas core, usan AIX. Cuando las aerolíneas necesitan sistemas de reservas que no pueden fallar, usan AIX. Cuando Oracle, Informix o DB2 necesitan ofrecer un rendimiento brutal para cargas OLTP de misión crítica, corren sobre AIX.

AIX no es “trendy”. AIX no tiene una mascota cuqui. AIX no será el tema de los blogs tecnológicos sobre “disrupción”. Pero cuando las cosas no pueden fallar bajo ningún concepto, AIX está ahí, haciendo su trabajo en silencio mientras todos los demás están ocupados reiniciando sus contenedores.

Entonces, ¿por qué MariaDB no soporta oficialmente AIX? Simple economía: la comunidad Open Source se ha centrado en Linux, y la portabilidad requiere conocimientos muy específicos de la plataforma. MariaDB soporta Linux, Windows, FreeBSD, macOS y Solaris. AIX no está en la lista, no porque sea una mala plataforma, sino porque nadie había hecho el trabajo sucio todavía. Hasta que… entró LibrePower .

Mi primer error fue pensar: “Probablemente sea solo cuestión de compilar y ajustar un par de cosas”.

Lección nº 1: Cuando alguien dice “solo hay que compilarlo” refiriéndose a software en AIX, está a punto de recibir una clase magistral de humildad y programación de sistemas.

Capítulo 2: CMake y los tres invitados inesperados

El primer día de compilación fue… educativo. Usar CMake en AIX es como jugar a las cartas con alguien que tiene un reglamento totalmente diferente al tuyo y espera que adivines las reglas sobre la marcha.

El bug de la función fantasma

AIX tiene una característica curiosa: declara funciones en las cabeceras por compatibilidad, incluso cuando esas funciones no existen realmente en tiempo de ejecución. Es como si tu GPS te dijera “gira a la derecha en 200 metros” pero la calle fuera un muro de ladrillos.

CMake ejecuta un CHECK_C_SOURCE_COMPILES para comprobar si pthread_threadid_np() existe. El código compila. CMake dice “¡Genial, lo tenemos!”. El binario arranca y… BOOM. Symbol not found.

Resulta que pthread_threadid_np() es exclusivo de macOS. AIX lo declara en los headers porque… bueno, aún no lo sé. ¿Quizás por alguna oscura compatibilidad POSIX de hace décadas? Sea cual sea la razón, GCC lo compila felizmente y el linker no se queja hasta que intentas ejecutarlo.

Lo mismo ocurre con getthrid(), que es específico de OpenBSD.

La solución:

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: A jugar al escondice

AIX tiene <sys/poll.h>. Está ahí. Puedes hacerle un cat. Pero CMake no lo detecta.

Después de tres horas depurando un error “POLLIN undeclared” en viosocket.c, descubrí que la solución era simplemente forzar la definición a mano:

cmake ... -DHAVE_SYS_POLL_H=1

Tres horas. Por un flag.

(esto es un problema de detección de plataforma de CMake, no de AIX. Los checks de CMake asumen estructuras de directorios estilo Linux).

Los malditos plugins

Al 98% de compilación — el plugin wsrep_info explotó con símbolos indefinidos. ¿La razón? Depende de Galera. Que no estamos usando. Pero CMake intenta compilarlo de todos modos.

Lo mismo pasó con S3 (requiere símbolos Aria), Mroonga (requiere Groonga) y RocksDB (profundamente ligado a optimizaciones específicas de Linux).

Configuración final de CMake (“La poda”):

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

Parece una amputación, pero en realidad es eliminar paja. Estos plugins son casos de uso muy específicos (edge cases) que pocas implementaciones necesitan.

Capítulo 3: Thread Pool, o cómo aprendí a dejar de preocuparme y amar el Mutex

Aquí es donde las cosas se pusieron interesantes. Y por “interesantes” quiero decir “casi me provocan un tic nervioso permanente”.

MariaDB tiene dos modos de gestión de conexiones:

  • one-thread-per-connection: Un hilo por cliente. Simple. Escala igual de bien que un coche subiendo una pared vertical.
  • pool-of-threads: Un conjunto fijo de hilos gestiona todas las conexiones. Elegante. Eficiente. Y no disponible en AIX.

¿Por qué? Porque el Thread Pool requiere APIs de multiplexación de E/S específicas de la plataforma:

PlataformaAPIEstado
LinuxepollSoportado
FreeBSD/macOSkqueueSoportado
Solarisevent portsSoportado
WindowsIOCPSoportado
AIXpollsetNo soportado (hasta ahora)

Así que… ¿tan difícil puede ser implementar el soporte para pollset?

El problema de ONESHOT

El epoll de Linux tiene un flag maravilloso llamado EPOLLONESHOT. Garantiza que un descriptor de fichero dispare eventos una sola vez hasta que lo vuelvas a armar explícitamente. Esto impide que dos hilos procesen la misma conexión simultáneamente.

El Pollset de AIX es level-triggered (activado por nivel). Solo por nivel. Sin opciones. Si hay datos disponibles, te avisa. Y te vuelve a avisar. Una y otra vez. Como ese compañero de trabajo “servicial” que no para de recordarte el email que aún no has contestado.

Once versiones para alcanzar la sabiduría

Lo que siguió fueron once iteraciones de código, cada una más compleja que la anterior, intentando simular el comportamiento de ONESHOT:

v1-v5 (La edad de la inocencia)
Probé a modificar los flags de eventos con PS_MOD. “Si cambio el evento a 0, dejará de saltar”, pensé. Spoiler: no dejó de saltar.

v6-v7 (La era de las máquinas de estado)
“Lo tengo! Mantendré un estado interno y filtraré los eventos duplicados”. El problema: existe una ventana de tiempo (race condition) entre que el kernel te da el evento y tú actualizas tu estado. En esa ventana, otro hilo puede recibir el mismo evento.

v8-v9 (La fase de negación)
“Pondré el estado en PENDING antes de procesar”. Funcionó… más o menos… hasta que dejó de funcionar.

v10 (Esperanza)
Por fin encontré la solución: PS_DELETE + PS_ADD. Cuando recibas un evento, borra inmediatamente el file descriptor del pollset. Cuando estés listo para más datos, vuélvelo a añadir.

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

// Cuando estemos listos: ADD
pce.command = PS_ADD;
pollset_ctl_ext(pollfd, &pce, 1);

¡Funcionó! Con compilación -O2.

Con -O3… segfault.

Se acerca la noche y sigo teniendo bugs (El Bug de -O3)

Imagínate mi cara. Tengo el código funcionando perfecto en desarrollo (`-O2`). Habilito `-O3` para las pruebas de producción y el servidor explota con “Got packets out of order” o un fallo de segmentación en CONNECT::create_thd().

Pasé dos días convencido de que era un bug del compilador. GCC 13.3.0 en AIX. Culpé al compilador. Culpé al linker. Culpé a todo el universo excepto a mi propio código.

El problema era más sutil: MariaDB tiene dos rutas de código concurrentes que llaman a io_poll_wait en el mismo pollset:

  • El listener bloquea con timeout=-1.
  • El worker llama con timeout=0 para comprobaciones no bloqueantes.

Con -O2, los tiempos eran tales que rara vez colisionaban. Con -O3, el código era más rápido, las colisiones ocurrían más a menudo, y boom: condición de carrera.

v11 (Iluminación)
La solución fue un mutex dedicado protegiendo tanto pollset_poll como todas las operaciones 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);
    // ... procesar y borrar eventos ...
    pthread_mutex_unlock(&pollset_mutex);
}

Sí, esto serializa el acceso al pollset. Sí, teóricamente añade latencia. ¿Pero sabes qué tiene más latencia? Un servidor que se cae.

El código final de la v11 superó 72 horas de pruebas de estrés con 1.000 conexiones simultáneas. Cero caídas. Cero fugas de memoria. Cero paquetes desordenados.

Capítulo 4: La cosa del -blibpath (que en realidad es una feature)

Una característica genuina de AIX: tienes que especificar explícitamente la ruta de las librerías en tiempo de enlace con -Wl,-blibpath:/tu/ruta. Si no lo haces, el binario no encontrará libstdc++ aunque esté en el mismo directorio.

Al principio esto parece molesto. Luego te das cuenta: AIX prefiere rutas explícitas y deterministas a búsquedas implícitas “mágicas”. En entornos de producción crítica donde “en mi máquina funcionaba” no es una excusa válida, eso es una feature, no un bug.

Capítulo 5: Estabilidad – Los números que importan

Después de todo este sufrimiento, ¿dónde estamos realmente?

El RPM está publicado en aix.librepower.org y desplegado en un sistema IBM POWER9 (12 cores, SMT-8). MariaDB 11.8.5 corre en AIX 7.3 con el Thread Pool activado. El servidor ha superado una batería de QA brutal:

PruebaResultado
100 conexiones concurrentes✓
500 conexiones concurrentes✓
1.000 conexiones✓
30 minutos de carga sostenida✓
Más de 11 millones de queries✓
Memory leaksCERO

1.648.482.400 bytes de memoria, constantes durante 30 minutos. Ni un solo byte de deriva (drift). El servidor funcionó durante 39 minutos bajo carga continua y realizó un apagado limpio.

Funciona. Es estable. Está listo para producción.

El impacto del Thread Pool

El trabajo en el pool de hilos proporcionó ganancias masivas para cargas de trabajo concurrentes:

Configuración100 clientes mixtosvs. Baseline
Original -O2 un hilo por conexión11.34s–
-O3 + Thread Pool v111.96s83% más rápido

Para cargas de trabajo OLTP de alta concurrencia, esta es la diferencia entre arrastrarse y volar.

Lo que he aprendido (hasta ahora)

  1. CMake asume que eres Linux. En sistemas no-Linux, verifica manualmente la detección de características. Los falsos positivos te morderán en tiempo de ejecución.
  2. La E/S level-triggered requiere disciplina. EPOLLONESHOT existe por una razón. Si tu sistema no lo tiene, prepárate para implementar tu propia serialización.
  3. -O3 expone errores latentes. Si tu código “funciona con -O2 pero no con -O3”, tienes una condición de carrera. El compilador está haciendo su trabajo; el fallo es tuyo.
  4. Los mutex son tus amigos. Sí, tienen overhead. ¿Pero sabes qué tiene más overhead? Depurar condiciones de carrera a las 3 de la mañana.
  5. AIX premia la comprensión profunda. Es un sistema que no perdona los atajos, pero una vez entiendes sus convenciones, es predecible y robusto como una roca. Hay una razón por la que los bancos lo siguen usando.
  6. El ecosistema importa. Proyectos como linux-compat de LibrePower hacen viable el desarrollo moderno en AIX.

¿Qué sigue? La incógnita del rendimiento

El servidor es estable. El Thread Pool funciona. Pero hay una pregunta en el aire que aún no he respondido:

¿Es rápido comparado con Linux?

Ejecuté un benchmark de búsqueda vectorial (el tipo de operación que potencia la IA moderna). Índice MHNSW de MariaDB, 100.000 vectores, 768 dimensiones.

  • Linux en hardware POWER9 idéntico: 971 queries por segundo.
  • AIX con nuestra nueva build: 42 queries por segundo.

23 veces más lento.

Se me cayó el alma a los pies. ¿Tres semanas de trabajo para ser 23 veces más lentos que Linux en el mismo hardware?

Pero esto es lo bonito de la ingeniería: cuando los números no tienen sentido, siempre hay una razón. Y a veces, esa razón resulta ser una noticia sorprendentemente buena.

En la Parte 2, os contaré:

  • Cómo descubrimos que la diferencia de 23x era mayormente un error de configuración.
  • El compilador que lo cambió todo.
  • Por qué “AIX es lento” resultó ser un mito.
  • El “Museo de los Fracasos”: optimizaciones que no sirvieron para nada.

Los RPMs están publicados en aix.librepower.org. La build GCC es funcionalmente estable.

¿Pero la historia del rendimiento? Ahí es donde la cosa se pone realmente interesante.

Pronto la Parte 2.

  • MariaDB 11.8.5 ahora funciona en AIX 7.3 con Thread Pool nativo.
  • Primera implementación de un pool de hilos para AIX usando pollset (necesité 11 iteraciones para simular ONESHOT correctamente).
  • El servidor es estable: 1.000 conexiones, 11M+ queries, cero memory leaks.
  • El Thread Pool mejora un 83% el rendimiento en cargas concurrentes.
  • El benchmark inicial de vectores muestra una diferencia de 23x vs Linux… pero no es lo que parece.
  • RPMs disponibles en aix.librepower.org

¿Preguntas? ¿Ideas? ¿Quieres contribuir al ecosistema Open Source de AIX?

Este trabajo es parte de LibrePower – Desbloqueando IBM Power a través del Open Source. RAS inigualable. TCO superior. Huella mínima 🌍

🦙 LLMs en AIX: experimentación técnica más allá del hype de las GPUs

/en

En LibrePower hemos publicado Llama-AIX: una prueba de concepto para ejecutar inferencia de modelos LLM ligeros directamente sobre AIX 7.x, utilizando únicamente CPU y memoria, sin GPUs.

Conviene aclararlo desde el inicio: esto es diversión técnica y experimentación, no un producto, no una promesa comercial, ni una alternativa a grandes plataformas de IA aceleradas por GPU.

Dicho esto, hay una base técnica sólida detrás del experimento.

La teoría: no todos los casos de uso de LLM son GPU-bound

En muchos escenarios empresariales habituales en entornos Power:

  • RAG (Retrieval Augmented Generation)
  • Preguntas sobre documentación interna
  • Asistentes técnicos on-prem
  • Búsqueda semántica sobre conocimiento propio
  • Análisis de texto con fuerte dependencia de latencia y proximidad a los datos

el cuello de botella no siempre es el cálculo masivo, sino:

  • CPU

  • Ancho de memoria

  • Latencia de acceso a datos

  • Localización de los datos

En estos casos, inferencias pequeñas y bien acotadas pueden ejecutarse de forma razonable sin GPUs, especialmente cuando el modelo no es el centro del sistema, sino una pieza más.

⚙️ CPU, MMA y aceleradores de bajo consumo

La evolución natural no pasa únicamente por GPUs:

  • CPUs cada vez más vectorizadas
  • Extensiones como MMA
  • Aceleradores específicos y de bajo consumo (como el futuro Spyre)
  • Integración más cercana al sistema operativo y al stack de datos

Este tipo de aceleración es especialmente relevante en arquitecturas Power, donde el diseño prioriza throughput sostenido, coherencia y fiabilidad, no solo picos de FLOPS.

¿Por qué AIX?

Ejecutar esto en AIX no es una necesidad, es una elección consciente para:

  • Entender los límites reales
  • Explorar su viabilidad técnica
  • Desmontar supuestos simplistas
  • Aprender cómo encajan los LLMs en sistemas Power existentes

Muchos clientes Power operan infraestructuras estables, amortizadas y críticas, donde mover datos a la nube o introducir GPUs no siempre es deseable ni viable.

Qué es (y qué no) Llama-AIX

  • ✔ Un PoC técnico
  • ✔ Una exploración honesta
  • ✔ Un ejercicio de ingeniería
  • ✔ Open source
  • ✖ No es un benchmark
  • ✖ No es una plataforma IA completa
  • ✖ No pretende competir con soluciones GPU
  • ✖ No es “AI marketing”

La idea es sencilla: mirar más allá del hype, entender los matices y evaluar dónde los LLMs aportan valor real en entornos Power y AIX.

Por pura curiosidad técnica.

Y porque experimentar sigue siendo parte fundamental de la ingeniería.

💬 ¿En qué caso de uso concreto tendría sentido para ti un LLM on-prem en Power?

SIXE