OpenStack Gazpacho | Novedades 2026 y guía para empresas

/en
Cloud privada · Abril 2026

OpenStack Gazpacho: la release que acelera la salida de VMware y prepara tu nube privada para lo que viene.

El 1 de abril se publicó OpenStack 2026.1 Gazpacho. Más de 9.000 cambios, 500 colaboradores, migraciones en vivo paralelas, automatización de bare metal con Ironic y la eliminación progresiva de Eventlet. Es la release SLURP del año — y la más relevante para empresas que están evaluando su infraestructura de virtualización.

Abril 2026●14 min lectura
​ Logo de OpenStack 2026.1 Gazpacho, la versión número 33 del software de infraestructura cloud open source más desplegado del mundo

OpenStack acaba de publicar su versión número 33. En otros tiempos, la noticia habría pasado sin pena ni gloria fuera del círculo habitual de operadores de nubes privadas. Pero 2026 no es un año normal para la infraestructura. Broadcom lleva más de un año forzando el cambio de modelo de VMware. Las empresas europeas están midiendo el coste real de la dependencia tecnológica. Y el cloud privado open source ha dejado de ser una opción ideológica para convertirse en una opción económica.

Gazpacho llega en el momento exacto en que más organizaciones están buscando alternativas serias a vSphere. Y esta release, por primera vez en mucho tiempo, tiene respuestas concretas para las preguntas que se hacen esas organizaciones.

Para entender qué hay de nuevo, conviene empezar por algo que no es glamuroso pero que determina si puedes actualizar o no: el modelo de releases.

El modelo de releases

Qué es una release SLURP y por qué Gazpacho es la que importa

OpenStack publica dos versiones al año. Desde 2022, las releases alternas se marcan como SLURP (Skip Level Upgrade Release Process): permiten a los operadores actualizar una sola vez al año, saltando directamente de una SLURP a la siguiente sin pasar por la versión intermedia.

Esto es lo que hay encima de la mesa a fecha de este post:

ReleaseFechaEstado
2026.1 Gazpacho1 abril 2026Release actual. SLURP. Recomendada para nuevos despliegues y actualizaciones.
2025.2 Flamingo1 octubre 2025Soportada. No-SLURP (intermedia).
2025.1 EpoxyAbril 2025SLURP anterior. Actualización directa a Gazpacho posible.
2026.2 HibiscusSeptiembre 2026 (prevista)Próxima release. No-SLURP.

El calendario oficial del ciclo Gazpacho detalla los milestones, fechas de feature freeze y los equipos responsables de cada componente. La página oficial de la release recoge las highlights seleccionadas por la comunidad.

La consecuencia práctica: si tu entorno ejecuta Epoxy (2025.1), puedes saltar directamente a Gazpacho sin tocar Flamingo. Eso reduce a la mitad las actualizaciones obligatorias y simplifica la planificación de ventanas de mantenimiento en producción.

Y si estás en Flamingo, el salto es de un solo paso — el estándar.

Dato de contexto

Gazpacho es la versión 33 de OpenStack. Unos 500 colaboradores de 100 organizaciones — Ericsson, Rackspace, Red Hat, Samsung SDS, SAP, NVIDIA, Walmart, entre otras — han aportado más de 9.000 cambios durante un ciclo de seis meses. El sistema de CI/CD (OpenDev Zuul) procesó más de un millón de jobs para validar esta release. Y un dato relevante para Europa: el 40% de las contribuciones provienen de desarrolladores europeos, impulsados por las iniciativas de soberanía digital del continente. Los detalles completos están en el blog oficial de la OpenInfra Foundation.

Con el calendario claro, veamos qué justifica actualizar — más allá de cerrar una ventana de soporte.

La novedad estrella

Migraciones en vivo paralelas en Nova: el cambio de juego

Si tuviéramos que elegir una sola novedad de Gazpacho para explicar por qué esta release importa a las empresas, sería esta: Nova ahora soporta migraciones en vivo paralelas.

Hasta ahora, la migración en vivo de instancias procesaba las transferencias de memoria de forma secuencial: una conexión tras otra. Gazpacho introduce múltiples conexiones simultáneas, lo que acelera significativamente el traslado de cargas de trabajo grandes entre hosts o zonas de disponibilidad.

¿Por qué importa tanto? Porque la velocidad de migración es, en la práctica, el factor que determina cuánto dura una ventana de mantenimiento. Para una empresa con cientos de máquinas virtuales — o que está evaluando mover cargas desde VMware — la diferencia entre migrar en serie y migrar en paralelo es la diferencia entre una noche de mantenimiento y un fin de semana entero.

​
Migración en vivo — tiempo de ventana ↕ hover para detalle
t=0 t=T t=2T t=3T t=4T

Y eso no es todo lo que cambia en Nova

Las migraciones paralelas son la novedad más visible, pero Nova trae otros tres cambios que se acumulan sobre el mismo principio: menos fricción operativa.

Migración en vivo con vTPM

Otra novedad que acompaña a las migraciones paralelas: Nova permite ahora migrar instancias que utilizan vTPM (módulo de plataforma segura virtual) sin necesidad de apagarlas. Las cargas de trabajo con requisitos de cifrado de disco o arranque seguro — habituales en entornos regulados — ya pueden trasladarse entre nodos sin interrumpir el servicio. Hasta ahora, migrar una VM con vTPM requería apagar, mover, y volver a encender. Eso se ha acabado.

IOThread por defecto en QEMU

Un cambio más sutil pero con impacto real: Nova activa por defecto un IOThread por instancia de QEMU, descargando el procesamiento de E/S de disco de las vCPU. En entornos de alta densidad — muchas VMs por host — esto se traduce en un rendimiento de almacenamiento más consistente bajo carga, sin necesidad de tocar la configuración.

Cobertura completa de OpenAPI en Nova

Nova logra cobertura total de su esquema OpenAPI: cada endpoint del API tiene ahora una especificación legible por máquinas. Para equipos que automatizan con Terraform, Ansible o herramientas propias, esto significa validar peticiones antes de enviarlas al API y reducir errores en despliegues de infraestructura como código.

Bien. Nova controla las VMs. Pero las VMs tienen que vivir en algún sitio. Y si ese sitio es hardware físico que no ha pasado por OpenStack antes — que es exactamente la situación de la mayoría de migraciones desde VMware — entra en escena Ironic.

Bare metal inteligente

Ironic: automatización inteligente que reduce el trabajo manual

Ironic es el servicio de OpenStack para aprovisionar servidores físicos — bare metal — como si fueran máquinas virtuales. En Gazpacho, Ironic recibe un paquete de mejoras que, juntas, representan un salto en la operación del día a día:

  • Autodetect deploy interface. Ironic detecta automáticamente el método de despliegue adecuado para cada servidor, eliminando la selección manual. No suena espectacular, pero en un datacenter con hardware heterogéneo (distintas generaciones, distintos fabricantes) quita horas de configuración por nodo.
  • Detección automática de protocolo (NFS/CIFS) para Redfish. La configuración de arranque por virtual media se simplifica: Ironic determina el protocolo correcto sin intervención del operador.
  • Planificación de puertos basada en traits. La asignación de red se automatiza según los atributos reales de la infraestructura — tipo de NIC, velocidad, capacidades — en lugar de depender de mapeos manuales.
  • Interfaz de despliegue "noop". Quizá la más interesante para proyectos de migración: permite registrar y monitorizar servidores que ya están desplegados y funcionando sin necesidad de reaprovisionarlos. El caso de uso típico: incorporar hardware existente al inventario de OpenStack durante una migración gradual desde VMware o desde otra plataforma.
En la práctica

La interfaz noop es particularmente útil en los proyectos que hacemos en SIXE de migración desde vSphere. Permite registrar los hosts ESXi existentes en OpenStack, monitorizarlos, y planificar la migración de cargas sin necesidad de reinstalar el sistema operativo del host hasta que llega el momento. Es la diferencia entre "migrar todo de golpe un fin de semana" y "migrar por fases con control".

Guía de drivers en Cyborg

Cyborg, el servicio de aceleradores de OpenStack, publica por primera vez una guía de configuración de drivers que cubre todos los tipos soportados: FPGA, GPU, NIC, QAT, SSD y PCI passthrough. Para organizaciones que están incorporando aceleradores de IA o cargas HPC en su cloud privado, disponer de documentación unificada y probada reduce significativamente la barrera de entrada.

Tenemos las VMs migradas con Nova y el hardware registrado con Ironic. Ahora viene la parte que siempre acaba siendo más complicada de lo esperado: la red.

Redes, almacenamiento, seguridad

Lo que cambia por dentro: OVN, Manila, OpenBao

Redes: BGP nativo y mejoras OVN en Neutron

El controlador OVN de Neutron incorpora novedades que llevan tiempo pidiéndose en entornos enterprise:

  • Soporte BGP nativo para anunciar rutas directamente desde el controlador de red, sin necesidad de herramientas externas.
  • Enrutamiento Norte-Sur para puertos externos, simplificando la conectividad con redes físicas.
  • Pares de direcciones permitidos con MACs virtuales, facilitando escenarios multitenant y arquitecturas de conectividad híbrida.

Históricamente, estos eran escenarios donde OpenStack requería soluciones alternativas o herramientas de terceros. Gazpacho los resuelve de forma nativa.

Almacenamiento: QoS en Manila y adjuntos asíncronos

Manila introduce tipos y especificaciones de QoS que permiten aplicar políticas de rendimiento por carga de trabajo al almacenamiento compartido. Si tienes un pool de almacenamiento para bases de datos y otro para ficheros fríos, ahora puedes establecer límites y prioridades a nivel de la plataforma, no solo a nivel del hardware. Cinder avanza en los adjuntos asíncronos de volúmenes, mejorando la respuesta en entornos de alta densidad.

Seguridad: PKI con OpenBao

La integración con OpenBao — fork abierto de HashiCorp Vault — para la gestión de certificados PKI en OpenStack-Ansible permite alinear la infraestructura de certificados de OpenStack con las herramientas de seguridad empresarial existentes. Especialmente relevante en entornos regulados donde la gestión del ciclo de vida de los certificados está auditada y donde la administración ya utiliza Vault como estándar.

Watcher: estrategias de migración cross-zone

Watcher, el servicio de optimización de recursos, mejora sus estrategias de redistribución de cargas entre zonas con un testing reforzado. Para operadores que gestionan clouds multi-site o con zonas de disponibilidad diferenciadas, esto mejora la fiabilidad de las redistribuciones automáticas durante mantenimientos o ante fallos.

Todo lo anterior — migraciones, automatización, redes — son features visibles que puedes vender internamente. Pero hay un trabajo que Gazpacho hace en silencio, más importante a largo plazo que cualquier feature nueva: limpiar la casa por dentro.

Deuda técnica

Eventlet: el principio del fin de una dependencia heredada

Una de las historias de fondo más importantes de OpenStack en los últimos tres años es la eliminación progresiva de Eventlet, una biblioteca de concurrencia cooperativa que se adoptó en los primeros días del proyecto, cuando Python 2 no tenía una alternativa nativa. Python 3 sí la tiene: asyncio. Pero migrar un proyecto del tamaño de OpenStack de un modelo de concurrencia a otro es un trabajo monumental.

En Flamingo (2025.2), cuatro servicios completaron la migración: Ironic, Mistral, Barbican y Heat. En Gazpacho, Nova avanza significativamente hacia el threading nativo, con mejoras de rendimiento y estabilidad medibles. Neutron también progresa. Y nueve proyectos más están en proceso activo de migración.

¿Por qué importa esto a una empresa que no contribuye código a OpenStack? Porque Eventlet es una fuente conocida de bugs sutiles, dificultades de depuración e incompatibilidades con bibliotecas modernas de Python. Su eliminación hace OpenStack más estable, más mantenible y más predecible en producción a largo plazo. Es el tipo de mejora invisible que no aparece en demos pero que se nota en las 3 de la mañana cuando algo falla y hay que diagnosticarlo.

​
​
Progreso de migración de Eventlet
● Completado ◐ En progreso ○ Pendiente
0
Completados
0
En progreso
0
Pendientes
0%
Completado
Progreso global del proyecto Objetivo: asyncio nativo en todos los servicios
El contexto del mercado

Gazpacho como alternativa a VMware: por qué el timing importa

Volvemos al punto de partida del artículo. Dijimos que 2026 no es un año normal para la infraestructura — que Broadcom ha forzado a muchas organizaciones a replantearse su stack de virtualización. La pregunta que se hace ese tipo de organización no es "¿OpenStack es técnicamente capaz?". Eso quedó resuelto hace tiempo. La pregunta es: "¿tiene respuesta para mis problemas concretos?". Y con Gazpacho, la respuesta ha mejorado notablemente.

Desde que Broadcom reestructuró el modelo de licencias — subidas significativas, eliminación de licencias perpetuas, cambio a bundles — las preguntas de los clientes que nos llegan son siempre las mismas. Gazpacho tiene respuesta para cada una de ellas, y es una respuesta que conecta directamente con lo que acabamos de ver:

Preocupación habitualRespuesta de Gazpacho
Velocidad de migraciónMigraciones en vivo paralelas que rivalizan con vMotion. vTPM sin downtime.
Hardware existenteIronic noop permite registrar hosts sin reprovisionar. Migración gradual.
Redes complejasBGP nativo en OVN, enrutamiento N-S, MACs virtuales. Sin herramientas externas.
Aceleradores (GPU, FPGA)Guía unificada de drivers Cyborg. PCI passthrough mejorado.
Actualizaciones predeciblesModelo SLURP: una actualización mayor al año, ruta de upgrade probada.
Soberanía / vendor lock-inProyecto abierto, 100 organizaciones contribuidoras, 40% europeo.

A esto se suma que OpenStack supera los 55 millones de cores en producción a nivel mundial. No es un proyecto de nicho ni una promesa de futuro: es infraestructura que opera en producción en Walmart, CERN, NTT, Deutsche Telekom, y miles de organizaciones más pequeñas que no publican sus números. El proyecto lleva 15 años funcionando y la base de contribuidores está creciendo, no encogiéndose. La release anterior, Flamingo (2025.2), ya había avanzado significativamente en seguridad y en la eliminación de Eventlet.

El ángulo europeo

El 40% de las contribuciones a Gazpacho provienen de desarrolladores europeos. Esto no es casualidad: las iniciativas de soberanía digital de la UE están empujando la adopción de infraestructura abierta en administraciones públicas y empresas reguladas. Para organizaciones españolas que necesitan demostrar independencia tecnológica en sus pliegos o en sus auditorías, OpenStack es una de las pocas opciones que combina madurez técnica con gobernanza verdaderamente abierta.

Siguientes pasos

Cómo encaja esto en tu infraestructura

Modelo de releases, migraciones paralelas, bare metal inteligente, redes sin parches, deuda técnica en retirada, contexto de mercado favorable. Todo confluye en la misma pregunta práctica: ¿y tú, qué haces ahora? La respuesta depende de dónde estás.

Hay tres situaciones habituales, y el diagnóstico es distinto en cada una:

  • Tienes OpenStack en producción y necesitas planificar el salto a Gazpacho. Si estás en Epoxy, el upgrade directo SLURP-a-SLURP es tu ruta. Si estás en Flamingo, es un salto estándar. En ambos casos, la recomendación es validar en entorno de pruebas, especialmente si usas features que han cambiado entre versiones (migraciones, OVN, Ironic).
  • Tienes VMware y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura OpenStack encaja (sobre qué hardware, con qué almacenamiento — Ceph es la opción natural), cómo se migran los datos sin parar el servicio.
  • Arrancas un proyecto nuevo — cloud privado, plataforma de datos, infraestructura de IA — y OpenStack es una de las opciones. Gazpacho es la versión correcta para empezar, con Ceph como almacenamiento y, si necesitas contenedores, Kubernetes integrado a través de Magnum.

En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, y laboratorio de validación antes de tocar producción. Lo que cambia con Gazpacho no es el proceso — es que hay más piezas maduras con las que trabajar.

Para seguir leyendo

¿Evaluando OpenStack o planificando un upgrade?

Hablemos de tu infraestructura.

Nos cuentas dónde estás — upgrade pendiente, salida de VMware, proyecto nuevo — y salimos de la llamada con una idea clara de arquitectura, esfuerzo y siguientes pasos. Sin presupuestos genéricos. Directamente con ingenieros que llevan años con las manos dentro de proyectos como el tuyo.

Reservar sesión técnica WhatsApp
Cloud privada Soporte urgente OpenStack.org
Almacenamiento open source para IA y HPC

Ceph Tentacle 2026: FastEC, Reef EOL y Umbrella

/en
Almacenamiento SDS · Abril 2026

Ceph Tentacle: el salto silencioso que coloca el almacenamiento open source por delante en 2026.

El 6 de abril salió Tentacle v20.2.1. Reef ha llegado al final de su vida. Viene Umbrella con CephFS reescrito por dentro. Y mientras tanto, el lakehouse on-prem de IBM watsonx.data lleva 768 TiB de Ceph dentro. Repasamos qué ha cambiado de verdad y qué implica si tienes o vas a tener almacenamiento distribuido en España.

Abril 2026●13 min lectura

Hay una conversación que se repite casi cada semana en SIXE desde el último trimestre de 2025. La llamada llega con dos variantes y un mismo tono de cansancio. La primera: "nos toca renovar VMware con Broadcom y lo que nos piden no tiene sentido, ¿Ceph podría cubrir esto?". La segunda: "tenemos un clúster de Ceph que lleva años rodando en Reef y no sabemos a qué upgrade tirarle sin romperlo".

Las dos preguntas se responden bien a día de hoy, pero por razones distintas — y más interesantes de lo que parece. Ceph ha tenido un año muy movido sin que casi nadie lo contase en español. Vamos al grano.

El contexto 2026

El mapa de releases: Tentacle arriba, Reef fuera, Umbrella en camino

Si tu última foto mental del calendario de Ceph es de 2024, está desactualizada. Esto es lo que hay encima de la mesa a fecha de publicación de este post:

RamaÚltima versiónEstado
Tentacle (v20.x)v20.2.1 · 6 abril 2026Estable actual. Primera minor del ciclo. Recomendada para nuevos despliegues.
Squid (v19.x)v19.2.3 · 26 septiembre 2024Soportada. Elección conservadora sólida.
Reef (v18.x)v18.2.8 · 20 marzo 2026Fin de vida. Última backport release. Hay que migrar.
Umbrella (v21.x)En desarrolloPróxima major. Presentada en FOSDEM 2026 con foco en CephFS y DR.

La transición más importante aquí es la de Reef. El equipo de release anunció en marzo que v18.2.8 era la última — y previsiblemente la definitiva — backport release de la rama Reef. A partir de ahí, Reef entra en modo "si tienes un problema crítico, toca resolverlo actualizando". Si estás en Reef, ya no estás en una rama mantenida activamente. Hay que mover.

Tentacle, por su parte, es un salto mayor con calado real. Se publicó como versión estable inicial (v20.2.0) en noviembre de 2025, y la v20.2.1 del 6 de abril de 2026 corrige varios bugs significativos detectados en los primeros meses en producción — especialmente uno crítico en Erasure Coding que afectaba al scrub de pools con FastEC activado. Volvemos a ese punto en un momento.

Y luego está Umbrella, la próxima major. No hay fecha firme todavía, pero la presentación en FOSDEM 2026 ha dejado claro el enfoque: recorrer de arriba abajo la experiencia de CephFS, con mejoras en disaster recovery, métricas, tuning de MDS y protección de datos de usuario. Si tu caso de uso principal es fichero (HPC, media, home directories a escala), Umbrella es la versión que vas a querer mirar con calma.

Dato que merece la pena tener presente. La Ceph Foundation ha reorganizado su estrategia de eventos en 2026: en lugar de concentrar todo en un único Cephalocon anual, ahora hay Ceph Days regionales distribuidos por el mundo para bajar la barrera de entrada a la comunidad. El siguiente importante es Ceph Days Raleigh en junio, y hay actividad europea creciente. Para empresas españolas que quieran estar cerca de la toma de decisiones del proyecto, 2026 es un año más accesible que los anteriores.
La novedad con más impacto

FastEC: la mejora que cambia la ecuación de coste por TB

Si tuviéramos que elegir una sola novedad de Tentacle para explicar por qué esta release importa, sería FastEC. Es un cambio que se describe en una frase y cuya consecuencia tarda un rato en calar: la pipeline de I/O para Erasure Coding ha sido reescrita, con mejoras de rendimiento sustanciales y algunas mejoras de capacidad para pools EC. Se activa por pool mediante el flag allow_ec_optimizations. Los clientes no necesitan actualizarse.

¿Por qué esto importa tanto? Porque hasta ahora, en la mayoría de despliegues serios, la regla de oro era esta: replicado para lo que rinde (virtualización, bases de datos, CephFS con mucho metadata); Erasure Coding solo para lo que puede permitírselo (objeto frío, backups, archivado). La razón era puramente de rendimiento: EC tradicional tenía una penalización de escritura y una latencia que lo hacían poco adecuado para bloque o fichero con cargas mixtas. FastEC cambia esa regla. No del todo, no en todos los casos — pero sí lo suficiente como para que muchas cargas que antes solo tenían sentido en replicado de tres copias puedan moverse a EC con una relación de eficiencia mucho mejor.

Traducido a dinero, esto se parece bastante a esto:

──────────────────────────────────────────────── 100 TB útiles, clúster típico de virtualización ────────────────────────────────────────────────Replicado x3 (hasta ahora, lo "obligatorio") → 300 TB raw en cabinas · overhead 200%EC 4+2 con FastEC (ahora viable en más casos) → 150 TB raw · overhead 50% · ahorro ≈ 50%────────────────────────────────────────────────

El número exacto depende del perfil EC que uses (4+2, 6+3, 8+3...) y de la distribución física, pero el orden de magnitud es real. En un clúster de medio petabyte, estamos hablando del tipo de ahorro que justifica un proyecto entero.

Dos avisos importantes, porque no queremos que nadie se lleve sorpresas:

Aviso operativo

La primera Tentacle (v20.2.0) contenía un bug en FastEC que podía producir millones de errores de scrub al activar el flag sobre pools EC existentes. El informe público está documentado por Clyso. La v20.2.1 del 6 de abril corrige la raíz del problema (length calculation en erase_after_ro_offset y varios ajustes en BlueFS). Si vas a activar FastEC, hazlo desde v20.2.1 o posterior, no desde 20.2.0. Y, como siempre, prueba primero en laboratorio con datos no críticos.

El segundo aviso es más general. FastEC no es magia: sigue habiendo cargas para las que EC, incluso optimizado, no es la respuesta correcta — sobre todo IOPS muy altos con bloque pequeño y latencia muy ajustada (piensa en OLTP serio). La decisión de qué pools van en replicado y cuáles en EC sigue siendo una decisión de arquitectura, no de flag. Lo que ha cambiado no es que ahora todo vaya en EC; es que la conversación sobre "replicado vs EC" ya no está tan decantada hacia replicado como lo estaba hace dos años.

Qué más trae Tentacle

Más allá de FastEC: lo que cambia por dentro

FastEC se lleva los titulares, pero no es el único cambio de calado. Estas son las piezas que importan en operación del día a día:

BlueStore: compresión mejorada y un WAL nuevo

El almacén de objetos nativo de Ceph ha recibido dos cambios importantes. La compresión ha mejorado en eficiencia y velocidad, y hay un WAL (write-ahead log) nuevo y más rápido. El efecto práctico es menos latencia en escritura y menos amplificación sobre los dispositivos físicos — especialmente relevante en clusters de NVMe, donde las write amplification heredadas de generaciones anteriores se notaban.

Data Availability Score por pool

Un nuevo indicador por pool que permite ver "cómo de disponibles están de verdad los datos de este pool", teniendo en cuenta réplicas, EC, fallos históricos y recovery. Suena marketing, pero no lo es — para clusters con multi-tenant interno (por ejemplo, un pool para RGW S3 y otro para RBD con SLAs distintos), tener una métrica directa por pool en el dashboard quita trabajo manual de cálculo sobre OSDs y PGs.

Live migration de RBD entre clusters

Este es el cambio que más hemos visto pedir en proyectos de consolidación. Ahora se pueden importar imágenes RBD de otro cluster Ceph, en formato nativo, o desde una gran variedad de fuentes/formatos externos, de forma instantánea. Sin paradas, sin mover bytes antes de empezar a servir. El caso de uso típico: migración de clusters antiguos, consolidación de varios Ceph pequeños en uno grande, o import desde otro SDS o desde imágenes QCOW2. Para quien haya sufrido migraciones de RBD con rbd import en el pasado, esto es un cambio de juego.

CephFS: proxy propio para Samba y mejoras varias

Se despliega automáticamente un nuevo daemon cephfs-proxy que mejora escalabilidad y uso de memoria cuando Samba conecta con CephFS. Además, los directorios se pueden configurar con nombres case-insensitive o normalizados. Si has sufrido alguna vez montando SMB sobre CephFS en entornos mixtos Windows/Linux, esta es la parte que lleva tiempo pidiéndose.

NVMe/TCP para gateway groups y multi-namespace

Ceph lleva tiempo empujando NVMe-oF sobre TCP como puente hacia el almacenamiento de bloque tradicional. En Tentacle, los gateways NVMe/TCP soportan grupos y múltiples namespaces, gestión multi-cluster y OAuth 2.0. El escenario evidente es dar almacenamiento de bloque a hosts VMware o a otros hipervisores sin pasar por iSCSI y sin SAN propietaria. IBM ha sido muy explícito con esta visión y es una de las razones por las que Ceph está entrando en conversaciones donde antes solo se hablaba de vSAN.

SeaStore en tech preview (con Crimson OSD)

SeaStore — el almacén de objetos de próxima generación, diseñado para hardware NVMe moderno y con threading estructurado — es desplegable en preview junto a Crimson-OSD. Esto no es para producción todavía, pero sí es la primera vez que se puede probar end-to-end en un Tentacle estable. Para laboratorios y equipos que quieran familiarizarse con hacia dónde va Ceph en los próximos años, merece el rato.

Lo que se ha ido

Los módulos restful y zabbix, deprecados desde 2020, se han eliminado oficialmente. Si tu monitorización dependía del módulo Zabbix nativo, toca migrar a Prometheus + exporter de Ceph, que es la vía oficial desde hace tiempo.

El factor empresarial

El factor IBM, watsonx.data y la salida de Broadcom-VMware

La parte técnica de Ceph nunca ha sido el problema. Lo que impedía a muchas empresas españolas mirarlo en serio era el factor "esto es muy open source, no lo veo aprobado por comité". En 2026 ese argumento se ha caído solo, por dos vías independientes que se refuerzan.

IBM watsonx.data incluye 768 TiB de Ceph "de serie"

Desde hace un par de años, IBM ha hecho de Ceph el almacenamiento por defecto del lakehouse on-premise de watsonx.data. IBM Storage Ceph es un producto empresarial con precios publicados desde 0.026 USD/GB/mes, soporte 24/7, integración con Apache Iceberg, Apache Parquet, watsonx.ai, y el ecosistema Red Hat completo (OpenShift, OpenStack). La consecuencia práctica: cuando un CISO o un director de infraestructura pide "una opción soportada por un fabricante gran cuenta", Ceph ya no es "solo comunidad". Es un producto IBM con contrato, SLA y escalado de incidencias.

Broadcom-VMware ha empujado a medio sector a buscar alternativas

No hace falta que nos extendamos en esto. La subida de precios y el cambio de modelo de licenciamiento de VMware desde la compra por Broadcom ha abierto oficialmente la puerta a revisar las pilas de virtualización y almacenamiento. En esa revisión, el combo Proxmox + Ceph, o OpenStack + Ceph, o OpenShift/Kubernetes + Rook-Ceph, está entrando en bastantes shortlists que hace dos años no se planteaban.

Ceph, por diseño, encaja bien en esa conversación porque cubre los tres tipos de almacenamiento en una sola plataforma — bloque para VM y contenedores, fichero para datos compartidos, objeto S3 compatible para backups y datos no estructurados. Eso lo diferencia del resto del catálogo SDS open source: MinIO hace muy bien objeto, pero no bloque ni fichero; Longhorn es bloque para Kubernetes pero no objeto. Ceph hace los tres con el mismo cluster, y eso en proyectos reales ahorra cabinas, ahorra licencias y ahorra pliegos.

Nuestra perspectiva en SIXE

Llevamos años desplegando Ceph en proyectos donde el cliente no quería depender de un único fabricante y necesitaba cubrir bloque, fichero y objeto con una misma arquitectura. En 2025-2026 hemos visto cómo el perfil de los clientes ha cambiado: ya no son solo los "pioneros del open source", son también organizaciones medianas con cabinas tradicionales que están calculando su próximo ciclo de refresh. Si tu caso se parece a alguno de esos, la página de migración a Ceph sin downtime cuenta cómo abordamos la parte complicada: mover datos sin parar el servicio.

El ecosistema

Proxmox, Rook y el empuje del ecosistema

Ceph no existe solo. En 2026, tres ecosistemas están tirando del carro y vale la pena mirarlos por separado porque cada uno aporta un ángulo distinto.

Proxmox VE: Ceph integrado y ahora Tentacle en preview

Proxmox lleva años integrando Ceph de forma nativa como almacenamiento del cluster de virtualización. En enero de 2026 Proxmox publicó Ceph 20.2 Tentacle como test preview, con plan de mover a no-subscription una vez estabilice. Para entornos que ya están en Proxmox, esto significa acceso a FastEC, live migration RBD y NVMe/TCP sin cambiar nada más del stack. Proxmox sigue en Squid como default estable y lo mantendrá hasta septiembre de 2026, así que hay margen para planificar.

Rook y el mundo Kubernetes

Rook, el operator oficial de Ceph en Kubernetes, ha recibido actualizaciones importantes. Ceph-CSI v3.16 ya recomienda Ceph-CSI-Operator como mecanismo de despliegue estándar, e introduce driver NVMe-oF CSI para acceder al almacenamiento por NVMe over Fabrics desde Kubernetes. Para equipos que están construyendo plataformas internas tipo IDP sobre Kubernetes, esto abre posibilidades de rendimiento que antes requerían compromisos.

OpenStack y el campo empresarial

En OpenStack, Ceph sigue siendo el almacenamiento de referencia para Cinder (bloque), Glance (imágenes) y Swift-replacement con RGW (objeto). El trabajo de IBM/Red Hat sobre OpenStack y Ceph es continuo, y para organizaciones con necesidades de cloud privado a escala es, probablemente, la combinación más madura del mercado libre.

¿Qué significa todo esto junto? Que Ceph no depende de un único camino de adopción. Hay tres puertas de entrada naturales — virtualización (Proxmox), contenedores (Rook/OpenShift) y nube privada (OpenStack) — y las tres están activamente mantenidas por equipos grandes. Esa diversidad es, probablemente, la razón estructural por la que Ceph es la pieza de SDS open source más difícil de matar.

La parte operativa

Cuándo actualizar y cómo hacerlo sin estropear nada

Esta es la parte práctica. Tenemos cuatro escenarios típicos y una respuesta razonable para cada uno:

  1. Clúster nuevo desde cero (proyecto greenfield). Directamente Tentacle v20.2.1 o posterior. Con ISA-L como plugin EC por defecto (cambio de Jerasure a ISA-L en pools nuevos), FastEC disponible desde el primer día, y sin deuda técnica heredada. Es el escenario más limpio.
  2. Clúster en producción en Squid (v19.x). Sin urgencia. Squid sigue soportada y funcionando bien. La decisión depende de qué features de Tentacle te aportan valor: si necesitas FastEC, live migration RBD, o NVMe/TCP avanzado, planifica el upgrade para Q3 2026 esperando a v20.2.2 o posterior. Si no las necesitas, puedes esperar con tranquilidad a mitad de vida de Tentacle.
  3. Clúster en producción en Reef (v18.x). Hay que migrar. Reef está en fin de vida tras v18.2.8. La ruta oficial recomendada es Reef → Squid → Tentacle, no Reef → Tentacle directamente — y especialmente no desde Pacific, porque QA ha detectado problemas con upgrades directos desde Pacific. Haz el salto en dos pasos y con ventanas de mantenimiento bien planificadas.
  4. Clúster en Pacific, Quincy o anterior. Esto ya no es "mantenimiento", es deuda técnica activa. Pacific está fuera de soporte, Quincy está en sus últimas backport releases. Si sigues en alguna de esas ramas, es el momento de plantear un proyecto formal de modernización — no solo actualización, porque probablemente haya piezas de arquitectura (cephadm, containerización de daemons, dashboard) que también convenga repensar.

Tres principios de migración que no negociamos

En SIXE, cuando hacemos una migración o una actualización seria de Ceph para un cliente, trabajamos siempre con tres reglas. Las ponemos aquí porque funcionan también si lo gestionas tú mismo:

  1. Laboratorio antes que producción. El flag allow_ec_optimizations, la activación de FastEC, el cambio de versión mayor — todo eso se valida primero en un clúster de pruebas con datos no críticos, incluso si es un clúster pequeño. El coste de mantener un laboratorio durante dos semanas es una fracción ínfima del coste de un incidente en producción.
  2. Nunca saltar etapas. La escalera oficial Reef → Squid → Tentacle existe por buenas razones. Saltarse pasos ahorra dos semanas de proyecto y cuesta dos meses de depurar cosas raras. Respetamos la escalera y documentamos cada paso.
  3. Ventana de rollback viable hasta el último momento. No se borran snapshots del filesystem, no se desactivan backups antiguos, no se retiran nodos viejos hasta que el clúster nuevo lleva funcionando un ciclo de scrub completo con cargas reales encima. Es más tedioso, sí. Y funciona.
Siguientes pasos

Cómo encaja todo esto en un proyecto real

Si has leído hasta aquí, probablemente tu caso se parece a alguno de estos tres:

  • Tienes Ceph en producción y necesitas planificar el salto a Tentacle o decidir si FastEC te aplica. Aquí el trabajo es de arquitectura: revisar perfiles EC actuales, dimensionar el cambio, planificar la ventana de upgrade, validar en laboratorio.
  • Tienes VMware con vSAN y el coste de renovación te ha hecho mirar alternativas. Aquí la pregunta es de diseño: qué workloads se mueven primero, qué arquitectura Ceph encaja (Proxmox? OpenStack? Rook?), cómo se migran los datos sin parar el servicio.
  • Arrancas un proyecto nuevo — lakehouse, plataforma de contenedores, cloud privado — y Ceph es una de las opciones sobre la mesa. Aquí conviene diseñar desde el principio con Tentacle, dimensionar bien la red (spoiler: la red es casi siempre el cuello de botella, no los discos), y elegir la puerta de entrada (k8s vs virtualización vs bare metal).

En los tres casos, el orden sensato es el mismo: conversación técnica corta para entender el caso, propuesta de arquitectura con opciones y trade-offs claros, laboratorio de validación, y proyecto de despliegue con ventanas planificadas. No hay atajos que funcionen bien a medio plazo.

Para seguir leyendo sobre Ceph en SIXE

¿Estás planteándote Ceph o un upgrade serio?

Reserva una consultoría de CEPH.

Nos cuentas dónde estás — clúster existente, proyecto nuevo, salida de VMware, consolidación — y salimos de la llamada con una idea clara de arquitectura, esfuerzo y siguientes pasos. Sin presupuestos genéricos. Directamente con ingenieros que llevan años con las manos dentro de proyectos como el tuyo.

Reservar sesión técnica WhatsApp
Migración Ceph Soporte urgente Ceph.io

Qué es Wazuh: SIEM open source alternativa a Splunk y QRadar

/en
SIEM & XDR · Abril 2026

Qué es Wazuh y por qué es la alternativa real a Splunk y QRadar en 2026.

En dos años Cisco compró Splunk por 28.000 millones y Palo Alto Networks compró los activos SaaS de QRadar. Mientras tanto, Wazuh seguía publicando releases, lanzaba threat hunting con LLM local y pasaba los 10 millones de descargas anuales. Te contamos por qué eso cambia la conversación sobre SIEM en 2026.

Abril 2026●11 min lectura

Hay una conversación que llevamos teniendo varias veces al mes en SIXE desde finales de 2024. Llega un director de sistemas o un CISO, normalmente con algo de cansancio en la voz, y nos dice alguna versión de lo mismo: "se nos acaba el contrato de Splunk y el presupuesto del año que viene no lo aguanta", o bien "tenemos QRadar SaaS y IBM nos ha dicho que toca migrar a Cortex XSIAM, pero no sabemos si es lo que queremos".

No es casualidad. El mercado del SIEM comercial ha cambiado en 24 meses más de lo que había cambiado en la década anterior. Y en medio de todo ese movimiento, hay una pieza que sigue donde estaba, que no cotiza en bolsa, que nadie ha comprado, y que mientras tanto no ha parado de crecer. Se llama Wazuh.

El contexto 2024-2026

El mapa del SIEM que cambió en 24 meses

Si llevas años en seguridad defensiva, sabes que el mercado del SIEM comercial siempre ha sido conservador. Los grandes actores cambiaban poco. Los clientes aguantaban contratos dolorosos porque migrar un SIEM es un proyecto serio, y nadie lo hace por gusto. Y entonces, entre la primavera de 2024 y el verano de 2025, pasaron tres cosas que rompieron ese equilibrio.

Marzo 2024 — Cisco compra Splunk por 28.000 millones

El movimiento más caro en la historia del SIEM. Cisco pagó 157 dólares por acción, muy por encima del precio al que había cotizado Splunk ese año. Antes de cerrar la operación, Splunk despidió al 7 % de su plantilla —unas 560 personas— en una reestructuración global. Las encuestas de analistas justo antes de la adquisición ya apuntaban a que el 22 % de los clientes contemplaba cambiarse de proveedor si había subidas de precio tras la compra. Los que hemos visto de cerca este tipo de operaciones sabemos lo que viene después: presión interna por rentabilizar un precio alto, cambios de roadmap y renovaciones cada vez más tensas.

Mayo-septiembre 2024 — Palo Alto Networks compra los activos SaaS de QRadar

Esta fue la que nadie vio venir. En mayo de 2024, IBM y Palo Alto Networks anunciaron que Palo Alto compraba los activos SaaS de QRadar por unos 500 millones de dólares, con cierre confirmado en septiembre. Forrester lo resumió en una frase que los clientes aún están digiriendo: en cuanto venzan los contratos, los clientes de QRadar SaaS tienen que migrar a Cortex XSIAM o marcharse a otro proveedor. No es una opinión, es el plan oficial de la transición.

IBM mantiene el soporte de QRadar on-premise —bug fixes, actualizaciones críticas, conectores nuevos—, así que los clientes que tengan instalaciones propias no se quedan tirados de un día para otro. Pero el mensaje de fondo que están leyendo los comités de seguridad es claro: la inversión fuerte ya no va hacia QRadar, va hacia XSIAM y Precision AI. Muchos están usando esa señal para replantearse toda su estrategia de SOC a medio plazo.

Mientras tanto — Wazuh pasa los 10 millones de descargas anuales

No salió en titulares, porque Wazuh no tiene gabinete de comunicación a la altura de Cisco o Palo Alto. Pero las cifras están ahí. Según los datos que ellos mismos publican, el proyecto supera los 10 millones de descargas anuales, tiene una de las mayores comunidades de seguridad open source del mundo, y en junio de 2025 lanzó una función que ninguno de sus competidores comerciales tiene todavía sin pagar aparte: threat hunting con un modelo de lenguaje grande ejecutándose en local. Volvemos a eso más adelante.

Un apunte importante sobre QRadar. En SIXE seguimos dando soporte y formación oficial de IBM QRadar, y lo vamos a seguir haciendo mientras haya clientes con despliegues activos. QRadar on-prem sigue siendo una herramienta sólida para quien ya lo tiene montado y quiere exprimirlo. Pero si estás arrancando un proyecto SIEM nuevo en 2026, o tienes QRadar SaaS y el contrato se acaba, la conversación que tiene sentido ahora mismo es diferente. Y pasa por Wazuh bastante más a menudo de lo que pasaba hace dos años.
El producto

Qué es Wazuh (más allá del "es gratis")

Si Wazuh fuera solo un recolector de logs barato, esta conversación sería otra. No lo es. Wazuh es una plataforma que unifica, en un mismo agente y en un mismo stack, un montón de funciones que el resto del mercado vende en cajas separadas: SIEM, XDR, detección en endpoint, integridad de ficheros, escaneo de vulnerabilidades CVE, auditoría de configuración contra CIS, cumplimiento regulatorio y respuesta activa. Todo con el mismo agente corriendo en Linux, Windows, macOS, contenedores o máquinas virtuales.

Esto es lo que pasa, en la práctica, cuando un agente de Wazuh se instala en un servidor tuyo:

  • Recoge y correlaciona logs en tiempo real. Syslog, auditd, Windows Event Log, aplicación — todo con decoders nativos. Lo manda cifrado al manager central, donde se evalúan reglas, se correlaciona entre hosts y se dispara alerta si procede.
  • Vigila la integridad de ficheros y configuración. Cualquier cambio en /etc, en el registro de Windows, en binarios de sistema o en ficheros que tú marques como sensibles, dispara una alerta inmediata. Esto es detección de manipulación, y es una de las cosas que antes se compraban aparte.
  • Escanea vulnerabilidades contra bases CVE actualizadas. Wazuh cruza el inventario de paquetes instalados con los feeds oficiales de vendors y bases CVE, y te dice qué máquinas necesitan parche con qué prioridad. Sin pagar Tenable ni Qualys encima.
  • Audita la configuración contra CIS Benchmarks. Cada agente corre evaluaciones periódicas de hardening contra políticas CIS o políticas internas tuyas, y genera el informe de cumplimiento listo para presentar a auditor.
  • Responde activamente. Bloqueo automático de IP, kill de procesos sospechosos, aislamiento del host, ejecución de scripts custom. Sin que nadie toque el teclado a las tres de la mañana.
  • Mapea todo a MITRE ATT&CK. Cada regla disparada se etiqueta con la técnica y táctica ATT&CK correspondiente, lo que hace que los dashboards para el SOC analyst sean mucho más útiles de lo que suelen ser los paneles genéricos.
┌──────────────────────────────────────────────┐ │ Wazuh Manager │ │ (analysis engine · rules · response) │ └──────┬──────────────┬──────────────┬─────────┘ │ │ │ ┌────▼─────┐ ┌─────▼─────┐ ┌────▼──────┐ │ Agents │ │ Indexer │ │ Dashboard │ │ linux │ │ cluster │ │ │ │ windows │ │ OpenSearch│ │ MITRE │ │ macos │ │ │ │ compliance│ │ docker │ │ → shards │ │ SOC view │ │ k8s │ │ → HA │ │ │ └──────────┘ └───────────┘ └───────────┘

El stack es sólido y está probado en producción. Un paper académico publicado por Springer en abril de 2026 evalúa arquitecturas Wazuh distribuidas con alta disponibilidad y gestión de picos de ingesta muy por encima del EPS medio, y concluye —con las palabras cuidadas habituales del mundo académico— que las soluciones SIEM open source bien diseñadas pueden igualar y en algunos aspectos superar a las plataformas comerciales. Dicho en cristiano: cuando alguien que no vende Wazuh evalúa Wazuh con método, los resultados son buenos.

La novedad del año

El as en la manga: threat hunting con LLM local

En junio de 2025, casi sin ruido, Wazuh incorporó una capacidad que cambia la forma de trabajar de un analista de SOC: threat hunting asistido por un modelo de lenguaje grande ejecutándose en local. No en la nube de OpenAI. Local. En tu propia infraestructura.

¿Por qué es relevante? Porque todos los "SIEM con IA" que ha lanzado el mercado comercial —Cortex XSIAM con Precision AI, Splunk con su propia suite, las novedades de QRadar antes de la venta— funcionan enviando tus logs a los modelos del fabricante. En muchos casos eso mismo es lo que el cliente no puede hacer por razones regulatorias. Si tus logs contienen datos de pacientes, de clientes bancarios, o información clasificada de una administración pública, mandarlos a un LLM en la nube de un proveedor externo no es negociable — simplemente no puedes.

La solución de Wazuh se salta ese problema. Tú eliges el modelo, tú lo despliegas donde quieras, tus datos no salen. Y las consultas son las que un analista haría en lenguaje natural: "enséñame todos los intentos de escalada de privilegios del último mes correlacionados con cuentas de servicio", "resume los eventos de este host en las últimas 24 horas, prioriza lo anómalo", "¿hay algo en estos logs que se parezca a la TTP T1078 de MITRE?".

Nuestra perspectiva en SIXE

Esta es exactamente la línea en la que llevamos tiempo trabajando desde el lado de infraestructura — LLMs corriendo on-premise, sin mandar nada a ninguna nube, para entornos que manejan datos sensibles. Lo hemos aplicado en IBM Power, en AIX, y en clusters Ceph+Kubernetes para inferencia privada. Cuando vimos que Wazuh iba por ese mismo camino desde el lado del SOC, fue uno de los factores que nos hicieron apostar más fuerte todavía por la plataforma. Si te interesa el lado "infraestructura" de la historia, lo contamos en detalle en nuestra página de inferencia de IA on-premise.

La comparativa

Wazuh vs Splunk vs QRadar vs XSIAM, estado 2026

Sin discursos de marketing, aquí está el estado actual de los cuatro actores que se cruzan en la mayoría de conversaciones que tenemos. Las cifras y estados son verificables a la fecha de publicación de este post.

PlataformaEstado 2026Modelo comercial
WazuhIndependiente. Sin adquisiciones, sin rondas de funding, creciendo en descargas y comunidad.Open source AGPLv3. Sin coste de licencia. Wazuh Cloud opcional.
SplunkPropiedad de Cisco desde marzo 2024. Reducción de plantilla del 7 % pre-cierre. Integración en curso.Por volumen de datos ingeridos (GB/día). Coste alto, presión de renovaciones.
QRadar SaaSVendido a Palo Alto Networks en 2024. Migración obligatoria a Cortex XSIAM cuando venzan los contratos.El destino es Cortex XSIAM. Migración gratuita para "clientes elegibles".
QRadar on-premMantenido por IBM. Bug fixes, conectores, sin grandes novedades funcionales.Licencia IBM por EPS. Soporte oficial activo.
Cortex XSIAMProducto estratégico de Palo Alto Networks. IA integrada (Precision AI).Por capacidad y features. Posiciona arriba en precio.
ELK / OpenSearch puroGratis pero te lo construyes tú: reglas, decoders, FIM, compliance.Gratis la base. El coste real es en tiempo de ingeniería propia.

La parte interesante de esta tabla no está en ninguna columna — está en lo que implica leerla entera. Cuatro de los seis actores comerciales están en transición, en mantenimiento o en migración obligatoria. Wazuh y ELK son los únicos que siguen exactamente donde estaban hace tres años, con sus comunidades intactas y su roadmap público. De esos dos, solo uno viene con SIEM, XDR, FIM, vulnerability scan, active response y compliance de serie: Wazuh.

Una nota sobre coste. Cuando comparamos Wazuh con Splunk en sesiones técnicas con clientes, la discusión casi nunca acaba siendo sobre el coste de la licencia — que, sí, es mucho más barato. Suele acabar siendo sobre la predictibilidad. Splunk sube contigo: más datos que ingieres, más pagas. Wazuh no. Y en un entorno donde los logs crecen un 30-40 % al año —porque metes nuevos servicios, porque NIS2 te obliga a retener más, porque montas más contenedores— esa diferencia se traduce en una factura que los CFO saben leer muy bien.
El ángulo regulatorio

Compliance sin sufrir: NIS2, ENS, PCI DSS, ISO 27001

Hay una razón muy práctica por la que Wazuh está creciendo más en Europa que en ningún otro sitio, y es la presión regulatoria. España traspuso NIS2 a finales de 2025 y está exigiendo evidencia real. El Esquema Nacional de Seguridad lleva años pidiendo trazabilidad, detección y respuesta ante incidentes. Para muchas organizaciones medianas —ayuntamientos, universidades, operadoras de servicios esenciales, hospitales concertados— la pregunta no es si necesitan un SIEM, sino cuál pueden permitirse sin que el comité de dirección les mire mal.

Wazuh trae los dashboards y reportes mapeados a los marcos regulatorios importantes directamente de serie:

  • NIS2. Controles de detección, trazabilidad de incidentes, reporte de eventos a la autoridad competente, evidencia de medidas de gestión de riesgos.
  • ENS (Esquema Nacional de Seguridad). Mapeo a las medidas de operación, monitorización y gestión de incidentes. Dashboards listos para los auditores que aplican el ENS en cualquiera de sus categorías.
  • PCI DSS. Controles de logging, integridad de ficheros, gestión de vulnerabilidades, retención — la checklist que exige el estándar, mapeada requisito a requisito.
  • ISO/IEC 27001. Evidencia de los controles del Anexo A relacionados con operaciones, comunicaciones, cumplimiento y gestión de incidentes de seguridad.
  • CIS Benchmarks. Auditoría continua de hardening del sistema operativo y de los servicios, con reporte histórico de desviaciones.

Dicho esto — y lo decimos con cariño porque venimos de este mundo — los dashboards por sí solos no aprueban una auditoría. Lo que los aprueba es que alguien haya diseñado la arquitectura bien, que las reglas estén afinadas al contexto del cliente, que las excepciones estén documentadas, que el flujo de evidencias llegue ordenado a quien lo tiene que firmar. Esa parte no la hace el producto, la hace el equipo que lo despliega. Y esa parte es, probablemente, el 70 % del valor de un proyecto Wazuh bien hecho.

Lo que hacemos en SIXE

Llevamos años desplegando Wazuh en organizaciones sujetas a ENS alto, a la transposición española de NIS2, a PCI DSS y a entornos sectoriales regulados. La página completa del servicio, con la arquitectura, el ciclo de despliegue y los casos de uso, está aquí: Implantación y soporte de Wazuh. Si el compliance es lo que más te presiona ahora mismo, esa es la conversación por la que empezar.

La migración

Cómo se migra desde Splunk, QRadar o ELK sin parar el SOC

Migrar un SIEM es un proyecto que asusta, y con razón. Un SIEM mal migrado deja ciegos los controles de detección justo en el peor momento posible. Por eso la forma en la que lo hacemos tiene que ser aburrida y predecible, con tres principios que no negociamos:

  1. Nunca apagar el SIEM antiguo antes de tener el nuevo funcionando. El viejo sigue tragando logs y generando alertas mientras Wazuh empieza a correr en paralelo. Durante unas semanas tienes cobertura doble y cero riesgo. Ese periodo es caro en recursos, sí, pero mucho más barato que un mes de SOC a ciegas.
  2. Convertir las reglas críticas antes de convertir el catálogo entero. Los SIEM grandes suelen tener miles de reglas acumuladas, y una parte importante son reglas que nadie mira o que disparan falsos positivos. La primera pasada identifica las 50-150 reglas críticas que realmente producen detecciones útiles, se reescriben al formato de Wazuh y se validan con eventos reales. El resto llega después, o no llega — porque muchas veces no merece la pena.
  3. Validar con eventos que duelen, no con tests sintéticos. Antes de considerar Wazuh operativo, reproducimos un conjunto de escenarios reales —intento de escalada, exfiltración, ransomware temprano, compromiso de cuenta— y comprobamos que las alertas se disparan, se correlacionan y llegan al SOC con el contexto correcto. Si no se disparan, no se considera que esté operativo. Es así de simple.

La parte que cambia según de dónde vengas es el trabajo de conversión:

  • Desde Splunk. El trabajo más interesante. Las SPL (Search Processing Language) no se traducen automáticamente a las reglas de Wazuh, pero el patrón de detección suele ser reproducible con decoders custom y reglas sobre OpenSearch. Hemos hecho varias migraciones y el grueso del trabajo está en los dashboards y las reglas, no en la ingesta.
  • Desde QRadar. La parte buena es que QRadar y Wazuh comparten mucha filosofía en cuanto a eventos y offenses. La mala es que las DSM de QRadar son propietarias y hay que reconstruir los parsers. Si vienes de QRadar SaaS con la migración a XSIAM encima, esta es una ventana razonable para plantearse la tercera opción.
  • Desde ELK puro. La más sencilla de las tres — Wazuh ya usa OpenSearch como indexer, así que buena parte del stack de datos ya lo conoces. El salto está en añadir reglas, compliance y active response, que en ELK puro habrías tenido que construir a mano.
Siguientes pasos

Por dónde empezar

Si lees esto y te encuentras pensando "esto me aplica más de lo que me gustaría", probablemente tengas razón. No hace falta un proyecto enorme para dar el primer paso. Lo habitual es empezar por una conversación corta con tres preguntas:

  • ¿Dónde estás exactamente ahora mismo? ¿Tienes Splunk con el contrato por venir? ¿QRadar SaaS con la migración a XSIAM en el horizonte? ¿Nada y te empieza a apretar NIS2 o el ENS?
  • ¿Qué normativa te está obligando? NIS2, ENS, PCI DSS, ISO 27001 — no es lo mismo cumplir uno que cumplir los cuatro, y la arquitectura de Wazuh se dimensiona distinto según cuáles apliquen de verdad.
  • ¿Cuántos endpoints, qué sistemas operativos, qué logs ya tienes, qué integraciones necesitas? Con esos datos ya se puede dibujar un diseño concreto y una estimación de esfuerzo realista.

Cuando tengas claro lo que quieres mirar, la página completa con la arquitectura, los módulos, la comparativa con alternativas comerciales y el ciclo de despliegue está aquí: Wazuh — Implantación y soporte SIXE. Y si quieres hablar con alguien que lleve años con las manos dentro de proyectos como el tuyo, la sesión técnica de 30 minutos es gratuita y sin compromiso. Salimos con un esbozo de arquitectura y una idea real de esfuerzo. Si Wazuh encaja, te lo decimos. Si no, también.

Para seguir leyendo

¿Estás replanteándote tu SIEM?

Sesión técnica de 30 minutos. Sin compromiso.

Nos cuentas dónde estás, qué normativa te aplica y qué te preocupa. Salimos de la llamada con un esbozo de arquitectura, una estimación de esfuerzo y los siguientes pasos. Sin presupuestos genéricos, sin discurso comercial — directamente con alguien del equipo técnico.

Servicio Wazuh — SIXE → WhatsApp
Reservar sesión técnica Soporte urgente Wazuh.com

Bacula: backup inmutable anti-ransomware sin coste por TB

/en
Backup & Resiliencia · Abril 2026

Bacula: el backup que sobrevive al ransomware. Sin cobrarte por TB.

Lo primero que hace hoy un ataque de ransomware serio es reventarte el backup. Lo segundo, cifrarte todo lo demás. Te contamos qué es esto del "backup inmutable" del que todo el mundo habla, por qué Bacula lo hace bien, y por qué sale bastante más barato que Veeam.

Abril 2026●9 min lectura

Durante muchos años, el backup ha sido el patito feo del datacenter. Esa cosa aburrida que el admin dejaba configurada un viernes por la tarde, que corría de noche, y que nadie volvía a mirar hasta que ardía Troya. En 2026 la cosa ha cambiado bastante: el servidor de backup es lo primero que busca un atacante cuando entra en tu red. Y tiene toda la lógica del mundo — si te borra las copias antes de cifrar el resto, no tienes plan B. Pagas el rescate o aceptas la pérdida.

Mientras pasa todo esto, Veeam, Veritas y Commvault siguen facturando por terabyte protegido, como si estuviéramos en 2015. Por suerte hay alternativas. Y una que merece mucho la pena mirar se llama Bacula.

El contexto 2026

Por qué tu backup es lo primero que va a tocar un atacante

En marzo, Bacula Systems publicó un artículo con un título que lo deja todo dicho: la infraestructura de backup vale más para un atacante que una cuenta de administrador de dominio. Y no es un titular para vender; es lo que están viendo los equipos de respuesta a incidentes desde hace un par de años.

Si hablas con cualquiera que haya pasado por una recuperación de ransomware "de las feas", el patrón se repite una y otra vez:

Día 1-3 Compromiso inicial (phishing, VPN vieja, CVE sin parchear) Día 4-10 Movimiento lateral + escalada de privilegios Día 11-14 Buscan el servidor de backup y se hacen root en él Día 15 Borrado de catálogos y credenciales de repositorios Día 16 Cifrado masivo del resto de la infraestructura Día 17 Nota de rescate en el escritorio del CEO

Fíjate en lo que pasa entre el día 11 y el 15. El atacante dedica días enteros a neutralizar tu backup antes de pulsar el botón del cifrado. Porque sabe algo que nosotros a veces olvidamos: si el backup sobrevive intacto, él pierde la partida. Por eso la pregunta correcta de 2026 ya no es "¿tenemos backups?" — esa la tenemos resuelta desde hace 20 años. La pregunta incómoda, la que duele, es: ¿esos backups se pueden destruir desde dentro de mi propia red?

Si la respuesta honesta es "sí, probablemente", no estás solo. La mayoría de entornos que auditamos parten de ahí.

El dato que pone los pelos de punta: en los informes de resiliencia de 2025, más de un tercio de las organizaciones atacadas descubrieron que sus copias también habían caído. Tuvieron que elegir entre pagar o perder los datos. Y en casi todos esos casos, el backup estaba "funcionando perfectamente" el día anterior al ataque. Porque sí funcionaba. Solo que ya estaba comprometido.
La definición sin paja

"Backup inmutable" sin marketing de por medio

Hay un problema con el término "backup inmutable": se ha convertido en la palabra favorita del departamento de marketing de cualquier fabricante. Todos lo usan, todos lo prometen, y significa cosas distintas según quién lo diga.

Vamos a la definición que cuenta, la técnica: un backup es realmente inmutable cuando, una vez escrito, nadie puede modificarlo ni borrarlo hasta que expire su retención. Ni tú. Ni el admin con el password maestro. Ni un atacante que se ha hecho root en el servidor de backup. Nadie. Y eso se consigue de tres formas — las tres sólidas, las tres soportadas por Bacula desde el primer día:

MecanismoCómo funcionaCuándo lo usas
WORM en cinta LTOCartuchos marcados Write-Once-Read-Many. El firmware del drive físicamente se niega a sobrescribirlos.Cuando quieres air-gap de verdad. La cinta sale de la librería, va a la caja fuerte, y desde ahí ningún atacante llega.
Object Lock en S3 o CephLos objetos se escriben con una retención bloqueada a nivel de API. Ni el dueño del bucket los puede borrar.Cuando quieres inmutabilidad en almacenamiento de objetos. Funciona con MinIO, Ceph RGW, AWS S3 y Azure Blob.
ZFS o Btrfs append-onlySnapshots que el propio proceso de backup no puede tocar después de crearlos.Como primera línea para entornos pequeños, o como capa rápida antes de bajar a cinta o S3.

Si nunca habías oído el concepto 3-2-1-1-0, apuntatelo porque lo vas a ver mucho en los próximos meses. Es la evolución del clásico 3-2-1 de toda la vida: tres copias, en dos medios distintos, una offsite… una inmutable, y cero errores de verificación. Ese "1-0" del final es lo nuevo. Ya no vale con tener copias — tienen que ser imposibles de alterar, y alguien tiene que estar verificándolas sin que hagas nada. Bacula hace las dos cosas automáticamente, como parte de su rutina normal.

Por qué la cinta está volviendo

Mucha gente piensa que la cinta es tecnología del siglo pasado. Pues LTO-10 llegó en enero con 30/40 TB nativos por cartucho y 400 MBps de velocidad, y el mismo air-gap físico que tenía LTO-1 hace 25 años. Es literalmente la única tecnología de backup donde, aunque el atacante tenga root en tu servidor Bacula, no puede borrar el dato — porque el dato no está enchufado a ninguna red. En SIXE estamos viendo cómo los despliegues con tape library vuelven a crecer desde 2024, y no es casualidad.

Librería de cintas LTO en rack de datacenter utilizada como almacenamiento inmutable air-gap para backups con Bacula
Una librería LTO moderna — el único medio donde el ransomware no llega.
Por qué Bacula

Qué tiene Bacula que otros no

Bacula lleva en producción más de 20 años. No es un proyecto nuevo ni una promesa; está corriendo ahora mismo en bancos, en ministerios, en hospitales, en operadoras de telecomunicaciones y en laboratorios científicos que manejan petabytes. Su edición comercial, Bacula Enterprise 18.0.8, acaba de sumar funciones específicas anti-ransomware: BGuardian (que detecta cuando alguien intenta envenenar el catálogo), un BWeb Security Center para tener todo a la vista, y soporte nativo para Microsoft 365, Nutanix AHV y snapshots CSI de Kubernetes. Vamos, lo que una empresa espera encontrar en 2026.

Pero lo que lo hace especialmente sólido para este juego no es el listado de features. Son cuatro decisiones de diseño que tomaron hace años y que ahora se pagan solas:

  • Todo está separado por diseño. El director que orquesta, el catálogo que indexa, los storage daemons que escriben, y los clientes que se protegen — cuatro procesos distintos que pueden vivir en hosts distintos con credenciales independientes. Comprometer uno no te da los otros tres.
  • El catálogo vive en PostgreSQL de verdad. Una base de datos real, con sus backups, sus réplicas, sus permisos, auditable como cualquier otra base de datos crítica. Puedes ponerla detrás de un firewall distinto del plano de datos. Puedes encriptarla. Puedes replicarla a otro sitio.
  • Se verifica a sí mismo. Bacula vuelve a leer los backups periódicamente, compara checksums y te avisa si algo no cuadra. Si alguien ha metido mano, te enteras antes del día malo, no durante.
  • Es open source de verdad. El formato de los volúmenes está documentado. Si mañana desaparecemos nosotros, o desaparece Bacula Systems, tus backups se siguen pudiendo recuperar con las herramientas de la comunidad. Eso es propiedad real de tus datos, no un eslogan.
┌────────────────────────────────────────────────┐ │ Bacula Director │ │ (orquestación + catálogo) │ └───────┬────────────┬────────────┬──────────────┘ │ │ │ ┌────▼────┐ ┌─────▼─────┐ ┌────▼─────┐ │ Clients │ │ Storage │ │ Catalog │ │ Linux │ │ Daemons │ │ Postgres │ │ VMware │ │ │ │ │ │ Proxmox │ │ → LTO WORM│ │ │ │ IBM i │ │ → Ceph S3 │ │ │ │ DB2 │ │ → Disk ZFS│ │ │ └─────────┘ └───────────┘ └──────────┘

Esa arquitectura no es glamurosa. No sale bien en una presentación de ventas. Pero es exactamente la que necesitas cuando alguien, dentro de tu red, está intentando hacerte todo el daño que puede.

La parte del dinero

La parte del dinero (y por qué Bacula sale a cuenta)

Hablemos claro de precio, porque es ahí donde Bacula hace más ruido. La diferencia con Veeam, Veritas o Commvault no es de descuento — es de modelo. Los tres grandes te cobran por volumen: por terabyte protegido, por workload, por host, por socket. Cuanto más creces, más pagas. Es un modelo fantástico para el fabricante, y cada vez más doloroso para el cliente.

Bacula Systems factura por número de clientes y por funcionalidades. Puedes duplicar el dato protegido durante el año y el coste no se mueve. Y Bacula Community, la edición open source, directamente no tiene licencia — pagas solo el trabajo de los ingenieros que te lo ponen a punto y te lo mantienen.

FabricanteQué estás pagandoQué pasa cuando creces
VeeamPor workload / por socket / por instanciaEl coste sube con cada host o VM nueva
Veritas NetBackupPor capacidad front-end (TB a proteger)El coste sube con cada TB nuevo
CommvaultCapacidad + módulos activadosEl coste sube por partida doble
Bacula EnterprisePor número de clientes y pluginsPlano. Duplica el dato, paga lo mismo.
Bacula Community + SIXESoftware gratuito + nuestras horasSolo pagas el tiempo del equipo técnico.

En las migraciones que hemos hecho, el ahorro suele estar entre el 60% y el 85% en la factura anual de backup el primer año. El pico lo vemos en entornos medianos, de 20 a 200 TB protegidos, que es donde los modelos por capacidad pegan más fuerte. Y lo interesante es que el ahorro se va ampliando con el tiempo: Bacula no te castiga por crecer, así que cada año que pasa la diferencia con el modelo antiguo se hace mayor.

Antes de emocionarnos: los números de arriba son reales, pero dependen mucho de tu contrato concreto, de cuántos hosts tienes, de qué módulos usas y de con quién negociaste la última vez. Por eso, cuando alguien nos pregunta "¿cuánto me voy a ahorrar?", la respuesta siempre es la misma — enséñanos tu factura actual y te lo decimos con números. Si no hay ahorro significativo, también te lo decimos. No estamos aquí para vender Bacula a quien no lo necesita.
Las cinco decisiones

Cinco decisiones que marcan la diferencia

Instalar Bacula es razonablemente fácil. Hay paquetes para casi todo, la documentación es buena y en un par de horas tienes algo haciendo copias. Diseñar un Bacula que aguante a alguien con root en tu red ya es otra historia. Estas son las cinco decisiones que, por experiencia, separan un backup que funciona de un backup que también sobrevive:

1. Separa el plano de control del plano de datos

El director y el catálogo PostgreSQL tienen que vivir en una red administrativa distinta de los servidores que estás protegiendo. Con MFA para quien accede, y a ser posible con un enfoque zero-trust en los propios servidores de backup. Parece una obviedad, pero la mitad de instalaciones que vemos tienen el director colgando del mismo segmento de red que los clientes. Es como guardar la llave de la caja fuerte dentro de la caja fuerte.

2. Al menos dos repositorios independientes

Uno rápido, en disco o en Ceph con Object Lock, para los restores del día a día — el típico "me he cargado una BD a las 11 y la necesito a las 12". Y un segundo repositorio air-gap para retención larga, que puede ser tape LTO, o un Ceph aislado, o ambos. Es lo que hace que un atacante que se ha hecho dueño del primero no se lleve también el segundo. Volvemos a la regla 3-2-1-1-0 — no es un capricho de consultoría, es lo que marca la diferencia el día que pasa algo.

3. Verificación automática, todas las semanas

Bacula sabe volver a leer volúmenes ya escritos y comprobar que los checksums cuadran. Ese job de verificación debería correr semanalmente como mínimo. Es lo que te avisa de la manipulación, del bit rot, del fallo raro del hardware. Configurarlo son cinco minutos y te ahorra el peor día de tu carrera.

4. Retenciones bloqueadas en origen

La retención se define en el director cuando se escribe el volumen, y se sella en el medio en ese mismo momento. Una vez que un volumen está en una cinta WORM o en un bucket con Object Lock activo, ya no hay manera — ni por bconsole, ni por SQL, ni por el soporte del fabricante — de acortar su retención. Si alguien con privilegios de admin intenta borrar ese dato antes de tiempo, no puede. Ese es exactamente el punto.

5. Prueba los restores. De verdad.

Un backup que no se ha restaurado nunca no existe, existe solo en el papel. El ejercicio de recuperación hay que hacerlo, y hay que hacerlo bien: no restaurando una VM vacía de prueba, sino cargas representativas de lo que de verdad duele si se pierde. En SIXE esto lo metemos como parte del Plan de Recuperación ante Desastres, con pruebas calendadas al menos dos veces al año y con un informe que llega al comité de dirección. Porque si no llega al comité, no se hace.

Donde la gente se queda a medias

Los cinco puntos de arriba son exactamente donde la mayoría de proyectos Bacula se quedan cortos. La instalación estándar del paquete no los aplica por defecto — son decisiones de ingeniería que dependen de tu infraestructura concreta y que hay que pensar con tiempo. Cuando SIXE entra en un proyecto de Bacula, este es buena parte del trabajo que hacemos.

La migración

Migrar desde Veeam sin perder el histórico

La objeción que nos llega siempre, en la primera llamada, es la misma. "Tenemos siete años de histórico en Veeam, no nos podemos permitir perderlo". Y es justa — en banca, sanidad o administración pública, la retención larga no es una preferencia, es un requisito regulatorio (ENS, ISO 27001, GDPR, normativa sectorial). Tranquiliza saber que una migración bien diseñada no pierde un solo byte.

La forma en la que lo hacemos se parece siempre un poco a esto:

  1. Ventana de coexistencia. Durante varias semanas — a veces meses — tu Veeam o tu Veritas sigue haciendo lo suyo en paralelo con el Bacula nuevo. Tienes doble cobertura mientras dura la transición. Si algo sale raro en Bacula, el antiguo está ahí.
  2. Restores reales, no de laboratorio. Antes de apagar el sistema antiguo, restauramos desde Bacula cosas que importan de verdad. No una VM de prueba; cargas representativas. Solo cuando esos restores validan el diseño, pasamos de fase.
  3. Histórico en modo solo lectura. El dato viejo se mantiene accesible en modo consulta el tiempo que exija tu política de retención. Si en 2027 alguien pide un restore de 2023, sigue disponible. Lo nuevo ya vive en Bacula.

Este servicio de migración es probablemente lo que más nos están pidiendo últimamente — por la combinación de subidas de precio en el licenciamiento propietario y la nueva exigencia de backup inmutable que está empujando a mucha gente a replantear su estrategia. El detalle completo del servicio, con SLAs y casos reales, lo tienes en la página dedicada: Soporte técnico y migración a Bacula.

Por dónde empiezas

Por dónde empezar hoy mismo

Si has llegado hasta aquí y estás pensando "tendría que revisar nuestro backup", probablemente tengas razón. No hace falta arrancar un proyecto enorme para dar el primer paso. De hecho, lo más útil suele ser una auditoría corta que responda honestamente a tres preguntas:

  • ¿Son mis backups realmente inmutables? Si un atacante con credenciales de admin en mi red quisiera destruirlos, ¿podría?
  • ¿Se están verificando automáticamente? ¿O solo sabré si están corruptos el día que los necesite de verdad?
  • ¿Cuánto estoy pagando al año por TB protegido, y qué cara tendrá esa factura dentro de tres años?

Las tres preguntas las puedes responder tú con tu equipo, sin llamar a nadie. Y si alguna de las respuestas no te gusta, hablamos. Sin comercial por medio, sin PowerPoint, directamente con alguien del equipo técnico que ha tenido las manos dentro de proyectos como el tuyo.

Para seguir leyendo

¿Tu backup sobreviviría a hoy?

Revisemos juntos tu arquitectura de backup

Sin comerciales, sin presentaciones genéricas, sin compromiso. Una llamada técnica con alguien del equipo de SIXE para ver cómo estás y qué tiene sentido tocar. Si Bacula encaja, te lo diremos. Si no, también.

Soporte Bacula SIXE → WhatsApp
Contacto Soporte urgente 24/7 Bacula.org

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

Cómo certificar en el ENS con software libre (Wazuh, Ansible y más)

/en
ENS · Ciberseguridad · Software libre

El ENS con software libre.
Sin licencias, sin lock-in.

Si prestas servicios a la Administración Pública española, el Esquema Nacional de Seguridad no es opcional. Esta guía explica qué controles exige el RD 311/2022, qué herramientas libres los cubren y qué error organizativo se carga la certificación antes de la auditoría.

14 min de lectura●ENS · Seguridad · Open source● · actualizado

El RD 311/2022 obliga a todo proveedor tecnológico de la Administración a demostrar que cumple el ENS antes de firmar un contrato. No es un trámite puntual: es un sistema de gestión que vive contigo. Y entre los acrónimos, los anexos y las consultoras que te miran como si fueras a comprar un yate, es fácil pensar que solo está al alcance de multinacionales.

No lo está. En SIXE llevamos años implantando el stack de seguridad open source para clientes que trabajan con organismos públicos. Wazuh, Ansible, OpenVAS, Keycloak — herramientas sin coste de licencia que, bien configuradas y bien documentadas, pasan la auditoría. Esta guía resume lo que hemos aprendido.

01 · El marco normativo

¿Qué te pide exactamente el ENS?

El ENS, regulado por el Real Decreto 311/2022, clasifica los sistemas en tres niveles según el impacto que tendría un incidente de seguridad. Las medidas se agrupan en tres bloques: marco organizativo (políticas, normativa, procedimientos), marco operacional (cómo operas el día a día) y medidas de protección (instalaciones, equipos, comunicaciones, software e información).

Lo más importante: el ENS no te dice qué producto comprar. Te dice qué control tienes que tener. Y ahí es donde el software libre compite en igualdad de condiciones con cualquier suite comercial.

Calculadora de nivel ENS

Responde tres preguntas para saber qué nivel del ENS te aplica y qué controles son prioritarios:

~/ens-level-calculator
Pregunta 1 de 3
$ ens-calc --question 1
¿Qué tipo de información gestiona tu sistema?
$ ens-calc --output
Kit técnico recomendado

El resultado de la calculadora es orientativo. El nivel definitivo lo fija la guía CCN-STIC-803 mediante el análisis de las dimensiones de seguridad (confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad) de cada sistema.

02 · El stack técnico

Qué herramienta cubre qué control ENS

Selecciona una herramienta para ver qué controles del ENS cubre y cuánto de la cobertura técnica total representa. El RD 311/2022 exige controles técnicos y organizativos — el mapa de abajo refleja solo los técnicos.

⬡
Wazuh (SIEM/XDR/HIDS)
Plataforma open source de seguridad: centralización de logs, detección de intrusiones, FIM, gestión de vulnerabilidades y respuesta activa. Licencia libre, sin coste por agente.
Cobertura ENS técnica
72%
op.exp.8Registro de actividad del sistema✓
op.exp.9Registro y gestión de incidentes✓
op.exp.6Protección frente a código dañino✓
op.mon.1Detección de intrusiones✓
op.mon.3Vigilancia y monitorización (nivel Alto)✓
mp.si.2Integridad de ficheros y directorios (FIM)✓
mp.info.3Cifrado y protección de la informaciónparcial
op.acc.*Control de acceso e identidad—
Servicios Wazuh de SIXE →
⚙
Ansible + OpenSCAP + Lynis
Automatización de hardening: define la configuración segura base como código, aplícala a toda la flota y demuestra a la auditora que es reproducible y auditable. Imprescindible para configuración CIS.
Cobertura ENS técnica
55%
op.exp.2Configuración de seguridad (hardening)✓
op.exp.3Gestión de la configuración (IaC)✓
mp.sw.1Desarrollo y adquisición de software seguro✓
mp.eq.3Seguridad en dispositivos y equipos✓
op.exp.5Gestión de cambios controlada y trazable✓
op.mon.*Monitorización y correlación de eventos—
Cursos Linux + Automatización →
⬦
OpenVAS / GVM (Greenbone)
Escáner de vulnerabilidades open source. En nivel Alto el ENS exige ciclos de escaneo mensuales con priorización por CVSS. GVM Community Edition es gratuita y auditable.
Cobertura ENS técnica
30%
op.exp.4Identificación y gestión de vulnerabilidades✓
op.exp.7Gestión de parches y actualizacionesparcial
mp.sw.2Aceptación y puesta en servicio de software✓
op.mon.1Detección de intrusiones en tiempo real—
Consulta sobre gestión de vulnerabilidades →
⬗
Keycloak / FreeIPA + privacyIDEA
Gestión centralizada de identidades (IAM), SSO y doble factor de autenticación. En nivel Medio/Alto el ENS exige MFA para accesos privilegiados. Keycloak es la referencia open source para cumplirlo.
Cobertura ENS técnica
40%
op.acc.1Identificación y autenticación de usuarios✓
op.acc.2Requisitos de acceso y control de privilegios✓
op.acc.5Mecanismos de autenticación fuerte (MFA)✓
op.acc.6Acceso local (consola) y remoto controlado✓
op.mon.1Monitorización de actividad y correlación—
Soluciones de identidad y acceso →
⬒
pfSense / OPNsense + Suricata
Firewall y segmentación de red. Con Suricata o Zeek como IDS/IPS de red. En nivel Alto el ENS exige separación estricta del tráfico y defensa perimetral documentada.
Cobertura ENS técnica
38%
mp.com.1Perímetro seguro y segmentación de red✓
mp.com.2Protección de la confidencialidad en tránsito✓
mp.com.3Autenticidad y control de la integridad✓
op.ext.1Contratación y acuerdos de interconexiónparcial
op.acc.7Acceso remoto cifrado (VPN)parcial
Arquitectura de red segura →
⬛
BorgBackup / Restic + LUKS
Copias de seguridad cifradas, deduplicadas y verificadas. En nivel Alto el ENS exige restauración probada y documentada. No vale con "se copia, supongo". LUKS para cifrado de soportes.
Cobertura ENS técnica
28%
mp.info.6Copias de seguridad de la información✓
op.cont.1Análisis de impacto y plan de continuidadparcial
op.cont.2Plan de recuperación ante desastres (DRP)parcial
mp.si.2Cifrado de soportes (LUKS / VeraCrypt)✓
op.cont.3Continuidad de servicios en Alta disponibilidad—
Soporte Debian y gestión de backups →
El porcentaje importa menos de lo que parece

Ninguna herramienta cubre el 100% de los controles ENS sola — ni las comerciales. La cobertura completa viene de combinar el stack correctamente y de añadir el marco organizativo. Una herramienta con el 100% del código y el 0% de la documentación no supera la auditoría.

03 · El error que todo el mundo comete

Instalar las herramientas no es cumplir el ENS

Es el error más frecuente y el más caro. Si llegas a la auditoría con Wazuh recién desplegado, sin política de seguridad firmada, sin análisis de riesgos, sin declaración de aplicabilidad y sin un responsable de seguridad designado, las herramientas no te salvan.

El software libre cubre el qué técnico. Pero el ENS también exige el cómo organizativo:

  • Política de seguridad aprobada por la dirección
  • Normativa de uso de los sistemas
  • Procedimientos operativos de seguridad (POS)
  • Declaración de Aplicabilidad — qué controles aplican y por qué
  • Análisis de riesgos formal, no una hoja de Excel sin fecha
  • Plan de continuidad con restauraciones probadas y documentadas
  • Gestión de incidentes con registro trazable
  • Formación al personal — el curso LPIC-1 o LPIC-2 para el equipo técnico refuerza esta parte
El ENS no es un proyecto con fecha de fin

La auditoría de certificación es solo el primer hito. Después vienen las de seguimiento y, cada dos años, la renovación. El sistema de gestión tiene que vivir contigo: revisiones periódicas, actualización de riesgos, registros de incidentes, trazabilidad de cambios. Si no tienes esto interiorizado antes de la primera auditoría, la segunda será más difícil que la primera.

04 · Tu nivel de preparación

¿Cuánto te falta para la auditoría?

Marca todo lo que ya tienes en producción o documentado. La puntuación refleja tu nivel de madurez real, no el declarado:

Evaluación de madurez ENS — autoevaluación rápida
Marca solo lo que tienes operativo y documentado, no lo que "está en proceso".
Marco organizativo
Política de seguridad documentada y aprobada por la dirección (con fecha y firma)
Análisis de riesgos formal completado y actualizado en los últimos 12 meses
Declaración de Aplicabilidad (DoA) que identifica controles aplicables y excluidos
Responsable de Seguridad de la Información (RSEI) designado formalmente
Marco operacional
SIEM/XDR desplegado y con reglas ajustadas a tu entorno (no instalación por defecto)
Hardening documentado y reproducible (Ansible + OpenSCAP o equivalente)
Gestión de vulnerabilidades: escaneos periódicos con seguimiento de CVEs
Control de acceso: MFA activo para cuentas privilegiadas y accesos remotos
Procedimiento de gestión de incidentes con registro trazable y tiempos de respuesta definidos
Medidas de protección
Copias de seguridad cifradas con restauración probada y documentada (no asumida)
Cifrado de soportes en todos los dispositivos con datos sensibles (LUKS, VeraCrypt)
Comunicaciones cifradas: VPN para accesos remotos, TLS en todas las aplicaciones internas
Formación en seguridad impartida al personal (con registro de asistencia)
0%
Punto de partida
Empieza marcando lo que ya tienes. La puntuación se actualiza en tiempo real.
Formación como control ENS

El ENS exige formación al personal en seguridad con evidencia documentada. Los cursos LPIC-1 y LPIC-2 de SIXE cubren las competencias técnicas de administración Linux que los auditores esperan encontrar en el equipo que opera la infraestructura. Los certificados Credly sirven como evidencia.

05 · La base que nadie menciona

Linux es la plataforma del stack ENS. Necesitas dominarlo.

Wazuh corre en Linux. OpenVAS corre en Linux. Ansible gestiona servidores Linux. Keycloak se despliega en Linux. El stack completo de seguridad open source tiene a Linux como base — y un sistema mal administrado invalida cualquier herramienta que corra sobre él.

En SIXE ofrecemos dos servicios que encajan directamente con la certificación ENS:

  • Soporte Debian — mantenimiento proactivo, aplicación de parches de seguridad (op.exp.7), hardening CIS y documentación de cambios. Todo lo que el ENS pide para la gestión del ciclo de vida del sistema operativo.
  • Formación LPIC-1 y LPIC-2 — certificación internacional que cubre administración, seguridad, redes y automatización en Linux. Los auditores ENS valoran que el equipo técnico tenga competencias acreditadas.

Y para el hardening automatizado: nuestro servicio de implantación con Ansible aplica los perfiles de seguridad CIS sobre tu flota completa, genera evidencias de cumplimiento y deja la configuración como código versionado en Git. Exactamente lo que el auditor quiere ver en el control op.exp.3.

Conclusión

Libre, bien hecho y con criterio

Cumplir el ENS con software libre no solo es viable: en muchos casos es la mejor decisión técnica y económica. Sin licencias recurrentes, sin dependencia de fabricante, con control total sobre los datos y con la capacidad de demostrar en auditoría que sabes exactamente lo que corre en tus sistemas.

Pero ninguna herramienta libre te da el criterio, el diseño y el método en una caja. La tecnología es condición necesaria — no suficiente. El marco organizativo, la documentación y el rigor de proceso son lo que diferencia a quien supera la auditoría de quien la suspende con las mismas herramientas instaladas.

Resumen ejecutivo

→ Wazuh cubre el marco operacional: logs, monitorización, FIM, detección de intrusiones.

→ Ansible + OpenSCAP automatiza el hardening y lo hace reproducible y auditable.

→ OpenVAS gestiona vulnerabilidades con escaneos periódicos trazables.

→ Keycloak centraliza identidades y habilita MFA para accesos privilegiados.

→ BorgBackup + LUKS cubre continuidad y cifrado de soportes.

→ Todo esto sin documentación organizativa, política de seguridad y análisis de riesgos: no pasa la auditoría.

FAQ

Preguntas frecuentes sobre ENS y software libre

El ENS, regulado por el Real Decreto 311/2022, es el marco normativo que obliga al sector público español y a sus proveedores tecnológicos a proteger la información y los servicios que manejan. Clasifica los sistemas en tres niveles (Básico, Medio y Alto) según el impacto que tendría un incidente de seguridad.

Sí, si prestas servicios tecnológicos o gestionas datos de cualquier Administración Pública española. Sin certificación ENS, quedas fuera de las licitaciones públicas que la exigen — y cada vez son más.

Sí. El RD 311/2022 no prescribe productos específicos, sino controles de seguridad. Wazuh, Ansible, OpenVAS, Keycloak y pfSense cubren la mayor parte de los controles técnicos exigidos en cualquier nivel ENS.

Para nivel Básico, entre 3 y 6 meses desde que la infraestructura técnica está en marcha. Para nivel Medio, entre 6 y 12 meses. Para nivel Alto, puede superar los 12 meses por la exigencia de redundancia, cifrado integral y auditorías más exhaustivas.

No. Wazuh cubre una parte importante del marco operacional (logs, FIM, monitorización, detección de intrusiones) pero no sustituye las herramientas de IAM, VPN, hardening automatizado, backups ni la documentación organizativa que exige el ENS.

En Básico se exige cumplimiento mínimo. En Medio se añaden registros detallados, separación de funciones y gestión documentada de incidentes. En Alto se requiere cifrado obligatorio, doble factor, redundancia, segregación estricta de redes y monitorización continua 24/7.

Referencias

Normativa y recursos citados

Real Decreto 311/2022, Esquema Nacional de Seguridad. BOE

CCN-CERT — Guías CCN-STIC serie 800 (implementación ENS). ccn-cert.cni.es

CCN-CERT — CCN-STIC-803 Valoración de sistemas en el ENS. ccn-cert.cni.es

Wazuh — documentación oficial. documentation.wazuh.com

Greenbone — GVM Community Edition. greenbone.net

INCIBE — Herramientas y recursos para pymes y empresas. incibe.es

Publicado: · Última actualización:

ENS · Software libre · SIXE

Llevamos años certificando empresas en el ENS con open source

Diseñamos la arquitectura, desplegamos las herramientas, redactamos la documentación y preparamos la auditoría. Si ya tienes parte del stack pero no sabes dónde están los huecos, el diagnóstico inicial es sin compromiso.

WhatsApp Solicitar diagnóstico ENS Soluciones Wazuh
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!
SIXE