Openchip & Software Technologies y SUSE han firmado un memorando de entendimiento para adaptar Linux, Kubernetes y las herramientas empresariales de SUSE a los futuros procesadores y aceleradores RISC-V diseñados por la compañía barcelonesa. El acuerdo busca que el hardware llegue acompañado de un entorno capaz de ejecutar cargas de inteligencia artificial, supercomputación y cloud sin depender por completo de arquitecturas controladas fuera de Europa.
La colaboración no anuncia todavía un servidor comercial ni un procesador disponible para comprar. Abre un trabajo de integración que abarcará SUSE Linux Enterprise Server, openSUSE Tumbleweed, SUSE Kubernetes Engine, Rancher Prime y SUSE AI Factory. El objetivo es que el software esté validado cuando el hardware de Openchip alcance el mercado, una condición indispensable para que RISC-V pueda salir del laboratorio y entrar en centros de datos con aplicaciones críticas.
Openchip y SUSE: las claves en 20 segundos
- Las compañías han firmado un memorando de entendimiento, no un acuerdo definitivo de suministro.
- SUSE adaptará su plataforma empresarial a los procesadores y aceleradores RISC-V de Openchip.
- El trabajo incluirá SUSE Linux Enterprise Server y openSUSE Tumbleweed.
- RKE2 y Rancher Prime deberán gestionar nodos y aceleradores RISC-V en Kubernetes.
- La integración contempla el perfil RVA23 y las instrucciones vectoriales RVV.
- También se estudiará el soporte de virtualización para entornos cloud.
- SUSE AI Factory se combinará con el software de inferencia de Openchip.
- El proyecto apunta a IA, HPC, telecomunicaciones, administración pública y sectores regulados.
- La plataforma se presenta como una opción europea para cargas que requieren mayor control tecnológico.
- Todavía no hay fechas de lanzamiento, precios, benchmarks ni configuraciones de servidor anunciadas.
La elección de SUSE tiene sentido por su presencia histórica en Linux empresarial. La compañía mantiene una distribución orientada a producción, ofrece soporte de larga duración y desarrolla herramientas para administrar clústeres Kubernetes. Para Openchip, esa capa reduce el riesgo de presentar un acelerador técnicamente capaz, pero difícil de instalar, actualizar o integrar en las plataformas que ya utilizan las empresas.
RISC-V aporta una arquitectura de instrucciones abierta. Cada fabricante puede desarrollar sus propios núcleos y aceleradores sin depender de una licencia de x86 o Arm para definir el conjunto básico de instrucciones. Esa libertad ayuda a diseñar chips especializados, aunque no resuelve por sí sola el problema más complejo: construir el software necesario para utilizarlos.
El reto de RISC-V no termina cuando el chip arranca Linux
Conseguir que el kernel de Linux inicie en una plataforma es solo el primer paso. Un sistema empresarial necesita firmware estable, controladores, compiladores, bibliotecas, virtualización, actualizaciones de seguridad, imágenes de contenedores y herramientas de diagnóstico.
También debe ejecutar aplicaciones creadas para otras arquitecturas. La mayor parte del software de centros de datos se distribuye hoy para x86-64 y, en menor medida, Arm64. Aunque una aplicación sea de código abierto, compilarla para RISC-V no garantiza que funcione con el mismo rendimiento ni que todas sus dependencias estén disponibles.
El acuerdo entre Openchip y SUSE intenta intervenir antes de que el hardware llegue a producción. La colaboración temprana permite probar el kernel, los compiladores y las bibliotecas sobre prototipos, detectar extensiones que necesitan soporte y preparar procesos de certificación.
| Capa tecnológica | Trabajo necesario |
|---|---|
| Firmware y arranque | Inicialización del hardware, UEFI, gestión de errores y actualizaciones |
| Kernel de Linux | CPU, memoria, interrupciones, energía, PCIe y controladores |
| Compiladores | Optimización en GCC y LLVM para los núcleos de Openchip |
| Bibliotecas | Álgebra lineal, criptografía, comunicación y ejecución de IA |
| Virtualización | KVM, aislamiento, asignación de dispositivos y migración de cargas |
| Contenedores | Imágenes RISC-V, runtimes y registros multiarquitectura |
| Kubernetes | Detección, reserva y supervisión de aceleradores |
| Observabilidad | Métricas de uso, temperatura, errores y rendimiento |
| Seguridad | Arranque verificado, parches, firma de paquetes y cadena de suministro |
| Soporte empresarial | Ciclos de mantenimiento, certificación y resolución de incidencias |
SUSE Linux Enterprise Server será la base destinada a los despliegues con soporte comercial. openSUSE Tumbleweed puede actuar como espacio de integración más rápido, ya que su modelo de actualización continua permite incorporar versiones recientes del kernel, compiladores y herramientas.
La presencia de ambas distribuciones resulta útil. Tumbleweed puede recibir antes las mejoras necesarias para el nuevo hardware, mientras SLES necesita un ritmo más controlado, pruebas de regresión y compromisos de mantenimiento más largos.
Uno de los puntos técnicos del acuerdo es el perfil RVA23. RISC-V permite combinar numerosas extensiones, pero esa flexibilidad puede fragmentar el mercado si cada procesador ofrece capacidades diferentes. Los perfiles definen una base común que los sistemas operativos y compiladores pueden asumir.
RVA23 incorpora la extensión vectorial RVV como parte de esa referencia. Las instrucciones vectoriales permiten aplicar una operación a varios elementos de datos y resultan útiles en simulación científica, procesamiento de señales, criptografía, multimedia e inteligencia artificial.
El soporte de una instrucción no asegura, sin embargo, un buen rendimiento. La velocidad dependerá de la anchura real de las unidades vectoriales, la caché, la memoria, el número de núcleos y la capacidad del compilador para generar código adecuado.
Openchip y SUSE tendrán que validar cargas completas, no únicamente instrucciones aisladas. Un acelerador puede ofrecer un elevado rendimiento matemático y quedar limitado por el movimiento de datos, la memoria o la comunicación entre nodos.
Kubernetes tendrá que entender el hardware de Openchip
La mayoría de las plataformas de IA actuales se administran mediante Kubernetes. Los aceleradores se presentan al clúster como recursos especializados que deben descubrirse, reservarse y asignarse a cada contenedor.
Nvidia utiliza complementos de dispositivo, operadores y bibliotecas para que Kubernetes reconozca sus GPU. AMD sigue un camino similar con sus aceleradores Instinct. Openchip necesitará una capa equivalente para que sus dispositivos puedan utilizarse sin configurar manualmente cada nodo.
El acuerdo contempla extensiones para SUSE Kubernetes Engine, basado en RKE2, y Rancher Prime. En la práctica, esto puede incluir complementos que informen al clúster sobre la cantidad de aceleradores disponibles, su estado y las capacidades de cada dispositivo.
También serán necesarias herramientas para instalar controladores, actualizar firmware y recopilar métricas. En un entorno con cientos de servidores, estas tareas no pueden depender de que un administrador entre por SSH en cada máquina.
Un operador de Kubernetes podría automatizar parte del proceso:
- Detectar un acelerador instalado en el nodo.
- Comprobar la versión del firmware y del controlador.
- Instalar los componentes compatibles.
- Publicar el recurso en Kubernetes.
- Asignarlo a los contenedores que lo soliciten.
- Recopilar métricas de uso y errores.
- Retirar el nodo cuando necesite mantenimiento.
La gestión de cargas multiarquitectura será otro desafío. Es probable que muchos centros de datos combinen servidores x86, Arm y RISC-V durante años. Rancher tendrá que permitir que una aplicación seleccione el nodo adecuado y que los registros almacenen imágenes compatibles con cada arquitectura.
Los desarrolladores deberán publicar imágenes multiarquitectura o compilar versiones específicas. Algunas aplicaciones escritas en Java, Go o lenguajes interpretados pueden trasladarse con relativa facilidad. Otras dependen de bibliotecas nativas, código ensamblador o extensiones disponibles únicamente para x86.
El valor del acuerdo estará en reducir esa diferencia. Una empresa no elegirá RISC-V solo porque su arquitectura sea abierta. Lo hará cuando pueda desplegar una aplicación con los mismos procesos de automatización, observabilidad y soporte que ya utiliza.
Una plataforma soberana, pero no aislada del mundo
Openchip y SUSE presentan el proyecto como una infraestructura europea soberana. El término requiere más precisión que una simple etiqueta comercial.
La arquitectura RISC-V es abierta, pero internacional. SUSE tiene raíces europeas y Openchip diseña en Barcelona, aunque la fabricación de semiconductores depende de fundiciones, herramientas y proveedores distribuidos por varios continentes.
Un chip diseñado en Europa puede utilizar software de automatización estadounidense, producirse en Asia, integrar memoria surcoreana y ensamblarse en otro país. La soberanía real no exige necesariamente fabricar cada pieza dentro de la Unión Europea, pero sí conocer las dependencias y disponer de capacidad para mantener los componentes más sensibles.
| Área | Qué supone un mayor control europeo |
|---|---|
| Arquitectura | Capacidad para diseñar y modificar el procesador |
| Propiedad intelectual | Derechos sobre los núcleos, aceleradores e interconexiones |
| Sistema operativo | Código auditable y soporte controlado desde Europa |
| Firmware | Acceso a actualizaciones y procesos de firma |
| Orquestación | Gestión de clústeres sin depender de un servicio externo |
| Datos y modelos | Elección de la ubicación y jurisdicción |
| Cadena de suministro | Conocimiento de proveedores y alternativas |
| Operación | Control de identidades, claves y administración |
| Mantenimiento | Capacidad para corregir vulnerabilidades a largo plazo |
La colaboración puede ofrecer más capacidad de decisión sobre la arquitectura, el sistema operativo y la operación. No elimina la dependencia de fundiciones avanzadas, memoria HBM, redes de alta velocidad o equipos para fabricar chips.
Tampoco convierte automáticamente la plataforma en una solución compatible con NIS2, DORA o el Reglamento de Ciberresiliencia. Estas normas afectan a la gestión de riesgos, la continuidad, los proveedores, la notificación de incidentes y el mantenimiento seguro de los productos.
Una infraestructura con componentes auditables y soporte europeo puede facilitar parte del cumplimiento, pero cada organización seguirá necesitando controles, pruebas y documentación.
El uso de software abierto aporta otra ventaja: si un proveedor abandona un producto, el cliente conserva al menos la posibilidad técnica de estudiar el código, mantener una versión o contratar a otra empresa. Esa opción no siempre es sencilla ni barata, pero reduce el bloqueo absoluto frente a una plataforma cerrada.
IA y HPC pondrán a prueba el rendimiento real
Openchip orienta sus futuros aceleradores a inteligencia artificial y computación de alto rendimiento. Son dos mercados donde la arquitectura del procesador importa, pero el software suele decidir qué hardware puede utilizarse de verdad.
Nvidia mantiene su posición gracias a CUDA, las bibliotecas matemáticas, los compiladores y las herramientas que rodean sus GPU. AMD intenta reducir esa distancia con ROCm. Intel desarrolla sus propias capas para CPU y aceleradores.
Openchip deberá ofrecer un entorno capaz de ejecutar modelos y aplicaciones científicas sin obligar a reescribir grandes cantidades de código. La compatibilidad con frameworks, bibliotecas de inferencia y formatos de modelos tendrá tanto peso como los teraflops anunciados.
SUSE AI Factory puede aportar la capa para desplegar y administrar modelos, mientras Openchip proporcionaría el hardware y el software de ejecución de sus aceleradores. La integración tendrá que responder a preguntas concretas: qué frameworks serán compatibles, qué formatos numéricos soportará el chip, cuánta memoria tendrá y cómo escalará entre varios nodos.
Por ahora esas respuestas no se han publicado. El memorando describe las áreas de trabajo, pero no ofrece resultados de rendimiento, consumo, latencia ni coste.
Ese matiz evita presentar el acuerdo como una alternativa ya terminada a Nvidia, AMD, Intel o Arm. Openchip y SUSE están preparando el terreno para que exista esa opción, pero todavía deben convertir la arquitectura en hardware producido y el software en una plataforma certificada.
El avance más relevante está en empezar la integración antes del lanzamiento. Europa ha financiado distintos proyectos de procesadores que después han tenido dificultades para encontrar aplicaciones y clientes. Un chip sin Linux bien soportado, Kubernetes, herramientas y una comunidad activa corre el riesgo de quedar limitado a demostraciones.
SUSE y Openchip intentan evitar ese escenario. El resultado se medirá cuando un administrador pueda instalar SLES, añadir varios nodos RISC-V a Rancher, desplegar un modelo y mantenerlo con los mismos procedimientos utilizados en cualquier centro de datos.
Preguntas frecuentes
¿Qué han firmado Openchip y SUSE?
Un memorando de entendimiento para adaptar y validar la plataforma Linux y Kubernetes de SUSE sobre los futuros procesadores y aceleradores RISC-V de Openchip.
¿Openchip tendrá una distribución Linux propia?
No es lo anunciado. La colaboración se basa en SUSE Linux Enterprise Server y openSUSE Tumbleweed, junto con herramientas de Kubernetes y gestión empresarial.
¿Qué aporta RVA23?
Define una base común para procesadores RISC-V de 64 bits e incluye instrucciones vectoriales relevantes para IA, HPC y procesamiento de datos.
¿La plataforma puede sustituir ya a servidores x86 o GPU de Nvidia?
Todavía no. No hay sistemas comerciales, precios ni benchmarks publicados. La colaboración busca preparar el software necesario para futuras pruebas y despliegues.
