Tarjeta gráfica RTX PRO 6000 Blackwell para IA: versiones, servidores y MIG

RTX PRO 6000 Blackwell para IA: versiones, servidores y MIG

/en
Ir a las preguntas frecuentes
IA en local · Guía

RTX PRO 6000 Blackwell para IAQué cambia entre sus tres versiones, en qué servidores va, cuándo conviene más una H200 y cómo se parte en cuatro con MIG.

La RTX PRO 6000 Blackwell es una tarjeta PCIe con 96 GB de memoria, y esa cifra explica por qué aparece en tantas configuraciones de servidores de IA. En 96 GB cabe un modelo de 70.000 millones de parámetros en 8 bits con sitio para unas cuantas conversaciones, y hasta ahora eso pedía dos tarjetas o una GPU de centro de datos bastante más cara.

La llevan buena parte de los servidores de nuestro catálogo, y antes de configurar uno hay que decidir qué versión pedir, cuántas caben en cada máquina y cómo repartirla entre varios equipos.

96GBde memoria GDDR7 con ECC
1,6TB/sde ancho de banda de memoria
4GPU independientes con MIG

Las tres versiones de la RTX PRO 6000

Las tres llevan el mismo chip, los mismos 96 GB de GDDR7 con corrección de errores y las mismas 24.064 unidades CUDA, y las tres admiten MIG. Lo que cambia es cuánta energía pueden gastar y cómo se refrigeran, y eso decide dónde se puede meter cada una.

VersiónConsumoRefrigeraciónDónde va
Server EditionDe 400 a 600 WPasiva, con el aire del chasisServidores de rack, de una a ocho tarjetas
Workstation Edition600 WDos ventiladores, saca el aire dentro de la cajaEquipo de sobremesa con una tarjeta
Max-Q Workstation Edition300 WTurbina, expulsa el aire por detrásEstación de trabajo con varias tarjetas

Para un servidor de rack la que toca es la Server Edition, porque no lleva ventiladores y se refresca con el aire que mueve el propio chasis. La Workstation Edition saca el calor hacia dentro de la caja y está pensada para una sola tarjeta en un equipo de sobremesa. La Max-Q gasta la mitad y lo expulsa por detrás, de modo que se pueden poner varias juntas en una estación de trabajo, a cambio de rendir menos que las de 600 W.

En qué servidores va y cuántas caben

Con dos tarjetas son 192 GB, que dan para un modelo de 70.000 millones de parámetros con bastante gente a la vez o para uno de más de 100.000 en 8 bits. Es lo que llevan el Supermicro SYS-212GB-FNR, que las mete en 2U con un solo Xeon, y el AS-5126GS-TNRT, que sale con dos y deja sitio para llegar a ocho cuando haga falta.

En Lenovo, el ThinkSystem SR650a V4 admite cuatro en 2U si se limitan a 450 W, o dos a 600 W. Para cuatro u ocho a plena potencia están el SYS-422GA-NRT con cuatro, el mismo chasis con ocho y 768 GB de memoria de GPU entre todas, y el ThinkSystem SR675 V3, que también acepta ocho.

Con ocho tarjetas solo las GPU pueden pedir casi 5 kW, así que antes de elegir el chasis conviene mirar cuánta potencia llega al armario y cuánto calor puede sacar la sala. Las cuentas completas, del modelo al CPD, están en nuestra guía para elegir un servidor para IA.

RTX PRO 6000 frente a H200 y frente a RTX 5090

La H200 NVL, también en PCIe, tiene 141 GB de memoria HBM3e que se lee a 4,8 TB/s, tres veces más deprisa que la de la RTX PRO 6000. Esa velocidad es la que marca lo rápido que aparece cada palabra de la respuesta cuando hay mucha gente esperando, y además las H200 se pueden unir entre sí con puentes NVLink. Las RTX PRO 6000 no tienen NVLink y se hablan por PCIe, de modo que rinden mejor cuando cada modelo cabe en una tarjeta o en pocas.

Si vas a servir varios modelos de hasta unos 70.000 millones de parámetros, o uno así a un departamento, la RTX PRO 6000 suele bastar. Si es un modelo grande repartido entre varias GPU y lo van a usar cientos de personas, la H200 o una placa HGX con B200 o B300 compensa lo que cuesta de más. Si no lo tienes claro, podemos medirlo con tu carga antes de la compra.

La GeForce RTX 5090 sale mucho en esta comparación porque usa la misma generación de chip, pero tiene 32 GB, no admite MIG y su refrigeración está pensada para una torre de sobremesa. Para probar modelos pequeños en un puesto de trabajo va bien, y para un servidor compartido se queda corta de memoria antes que de potencia.

Partir la RTX PRO 6000 en cuatro con MIG

MIG (Multi-Instance GPU) divide la tarjeta por hardware en GPU más pequeñas, cada una con su memoria y sus núcleos, de modo que lo que pasa en una no afecta a las demás. Según la guía de MIG de NVIDIA, la RTX PRO 6000 admite hasta cuatro instancias de 24 GB, la RTX PRO 5000 hasta dos, y las H100, H200 y B200 hasta siete. Cuatro trozos de 24 GB dan para servir a la vez varios modelos pequeños, como uno de embeddings, un clasificador y uno de voz a texto, sin que se peleen por la memoria.

Para activarlo hace falta el controlador R575 (575.51.03) o posterior y una versión mínima del vBIOS, la memoria de arranque de la tarjeta. Hay RTX PRO 6000 que salieron de fábrica con un vBIOS anterior, y entonces nvidia-smi -i 0 -mig 1 responde con un «Not Supported» que no explica la causa. Se comprueba con nvidia-smi --query-gpu=vbios_version --format=csv, y si se queda corto la actualización se pide al fabricante del servidor o a quien te vendió la tarjeta.

En una estación de trabajo con una sola tarjeta, MIG necesita que trabaje en modo de cálculo, y en ese modo deja de dar imagen al monitor. En un servidor no pasa, ya que la pantalla la lleva la placa base.

Si la tarjeta va a un clúster de Kubernetes, el GPU Operator de NVIDIA configura los trozos en cada nodo y los ofrece como si fueran GPU normales. Cómo se combinan con el reparto por turnos y con las colas por equipo lo contamos en GPU compartida en Kubernetes.

Preguntas frecuentes

¿Cuánta memoria tiene la RTX PRO 6000 Blackwell?

96 GB de GDDR7 con corrección de errores, igual en sus tres versiones, con un ancho de banda de unos 1,6 TB/s.

¿Qué modelo de lenguaje cabe en una RTX PRO 6000?

Un modelo de 70.000 millones de parámetros en 8 bits ocupa unos 70 GB, así que cabe con unos 25 GB libres para conversaciones. gpt-oss-120b, que viene en 4 bits, también cabe. Para modelos de más de 100.000 millones en 8 bits hacen falta dos o más tarjetas.

¿La RTX PRO 6000 tiene NVLink?

No. Las tarjetas se comunican por PCIe 5.0, así que funcionan mejor cuando cada modelo cabe en una o en pocas. Para repartir un modelo muy grande entre ocho GPU se usan placas HGX con NVLink.

¿Qué diferencia hay entre la Server Edition y la Max-Q?

La Server Edition no tiene ventiladores, puede gastar entre 400 y 600 W y va en servidores de rack. La Max-Q se queda en 300 W, lleva un ventilador que expulsa el aire por detrás y está pensada para estaciones de trabajo con varias tarjetas.

¿Por qué no puedo activar MIG en mi RTX PRO 6000?

Lo primero que hay que mirar es el vBIOS. NVIDIA pide una versión mínima para cada edición y hay tarjetas que salieron con una anterior. Compruébalo con nvidia-smi --query-gpu=vbios_version --format=csv y revisa también que el controlador sea R575 o posterior.

Servidores para IA

¿Cuántas RTX PRO 6000 te hacen falta?

Dinos qué modelo quieres servir y para cuánta gente, y te proponemos el servidor con las tarjetas, el sistema instalado y el soporte incluido. Si prefieres hacer tú las cuentas, el configurador te deja montarlo paso a paso.

Configurar mi servidor WhatsApp
Servidores Lenovo y Supermicro con RTX PRO 6000, con Ubuntu o Rocky Linux y soporte
Servidor de rack en 3D

vLLM vs Ollama: cuál elegir según cuántas personas lo usen a la vez

/en
Ir a las preguntas frecuentes
IA en local · Guía

vLLM vs OllamaCuál elegir según cuántas personas lo usen a la vez y qué cambia al pasar de uno a otro.

Si vas a probar un modelo en tu portátil o a dar servicio a una sola persona, usa Ollama. Si lo van a usar varias personas a la vez sobre una GPU de servidor, usa vLLM. Muchos equipos usan los dos, uno para probar y otro para producción. La diferencia está en cómo reparte cada uno la tarjeta cuando llegan varias peticiones juntas.

Qué hace cada uno

Con Ollama, un modelo funciona en cinco minutos. Lo instalas, escribes ollama run con el nombre del modelo y lo tienes respondiendo, con los pesos, los archivos que forman el modelo, ya reducidos para que quepan en un equipo normal y sin tener que elegir nada. Funciona en portátiles, en estaciones de trabajo y sin GPU, aunque entonces más despacio.

vLLM es un servidor de inferencia, el programa que ejecuta el modelo y responde a las peticiones, pensado para sacar todo lo posible de cada GPU. Agrupa las peticiones que llegan a la vez y, en lugar de esperar a que acabe una tanda, va metiendo peticiones nuevas en cuanto otra termina. Eso es lo que permite atender a mucha gente con la misma tarjeta, a cambio de pedir más de ti: hay que elegir los pesos, ajustar los parámetros y calcular cuánta memoria necesita cada modelo.

Los dos ofrecen una API como la de OpenAI, así que el código de tu aplicación apenas cambia: puedes desarrollar contra Ollama y desplegar contra vLLM cambiando poco más que una dirección. Si el modelo invoca funciones de tu aplicación, las llamadas a herramientas, tendrás que activarlas al arrancar vLLM.

Qué pasa cuando entran varios a la vez

Una de las pruebas más citadas es la de Red Hat, con una NVIDIA A100, Llama 3.1 de 8.000 millones de parámetros y hasta 256 usuarios simultáneos. vLLM llegó a un pico de 793 tokens por segundo frente a 41 de Ollama, que no lo alcanzó ni ajustándolo para atender más peticiones en paralelo. En Ollama, además, el tiempo hasta la primera palabra subía mucho porque las peticiones hacían cola.

Eso acaba en dinero: si la misma tarjeta atiende a más gente a la vez, hacen falta menos tarjetas para dar el mismo servicio, y las GPU son la parte más cara de la máquina.

Esas cifras son de versiones de 2025 y de una carga llevada al extremo, y otras comparaciones sacan diferencias bastante menores porque usan otras tarjetas, otros modelos y otra cuantización, que es el grado en que se reducen los pesos. Lo que se repite en las comparaciones publicadas es la dirección: cuantos más usuarios simultáneos, más se aleja vLLM.

Si vas a quedarte con Ollama para un equipo pequeño, mira un ajuste. Según su documentación, OLLAMA_NUM_PARALLEL atiende por defecto una sola petición por modelo, y si lo subes, la memoria crece en proporción, porque cada petición en paralelo reserva su propio contexto. Ese valor ha cambiado entre versiones, así que compruébalo en la tuya. Si Ollama te parece lento con varios usuarios, empieza por aquí: puede que estén esperando turno.

Cuándo usar cuál

El número de usuarios simultáneos es lo que más pesa, y no el de personas con acceso: cien empleados que preguntan de vez en cuando pueden ser tres peticiones a la vez. Dónde está el límite depende del modelo, de la tarjeta y de lo largas que sean las preguntas, así que lo fiable es medir tu hora punta, y es lo primero que hacemos antes de recomendar una máquina.

SituaciónOllamavLLM
Probar un modeloLo mejor: funciona en minutosDemasiado trabajo para esto
Una persona, sin GPU de servidorSíSolo si ya lo tienes montado
Equipo pequeño, pocas peticiones a la vezVale, ajustando el paraleloVale, y aguantará si crece
Varias personas a la vez en producciónSe forman colasSí, es para lo que está hecho
Sacar más de una GPU caraNo es su objetivoSí

Cuando ya tienes vLLM y la carga no cabe en una máquina, un siguiente paso habitual es Kubernetes con llm-d, que reparte las peticiones entre réplicas.

Si tus máquinas son IBM Power, no hace falta comprar otras para empezar: vLLM funciona en Power sin GPU, y eso permite probar modelos sobre el hardware que ya tienes.

Qué cambia al pasar de Ollama a vLLM

En la aplicación, casi nada. Cambias el puerto, que en Ollama suele ser el 11434 y en vLLM el 8000, y el nombre del modelo, porque Ollama usa sus etiquetas y vLLM el nombre de Hugging Face, donde este modelo pide aceptar su licencia y usar un token de acceso:

from openai import OpenAI

# Ollama
cliente = OpenAI(
  base_url="http://localhost:11434/v1",
  api_key="nada",
)
modelo = "llama3.1:8b"

# vLLM
cliente = OpenAI(
  base_url="http://localhost:8000/v1",
  api_key="nada",
)
modelo = (
  "meta-llama/Llama-3.1-8B-Instruct"
)

Lo que cambia está debajo. Los modelos de Ollama vienen en formato GGUF, que vLLM solo admite de forma experimental, así que en producción hay que descargar los pesos en el formato que espera. vLLM también trabaja con pesos cuantizados, pero según cuál elijas el mismo modelo puede ocupar más memoria, y por eso conviene hacer las cuentas de memoria y usuarios antes de comprar nada.

También cambia la forma de usar la tarjeta. vLLM reserva por defecto el 92 % de la memoria de la GPU al arrancar, tenga o no trabajo, y eso sorprende cuando compartes la máquina con otros procesos. Si la vas a repartir entre varios equipos, lo que necesitas es GPU compartida en Kubernetes.

Y antes de abrir el servicio a la red, ponle puerta. Ollama escucha por defecto solo en 127.0.0.1 y no trae autenticación, de modo que para compartirlo hay que poner delante un proxy que la pida. vLLM admite claves con --api-key, aunque solo protegen las rutas de la API, así que en un servicio real también conviene una pasarela con acceso por usuario.

Si quieres que lo montemos nosotros, servimos modelos con vLLM en tu propia infraestructura, y si prefieres que lo lleve tu equipo, tenemos el curso vLLM y llm-d en Kubernetes.

Preguntas frecuentes

¿Es mejor vLLM u Ollama?

Depende de la carga. Ollama es mejor para probar modelos y para una sola persona porque se instala en minutos. vLLM es mejor cuando varias personas usan el modelo a la vez sobre una GPU de servidor.

¿vLLM necesita GPU?

Está pensado para GPU, y es ahí donde saca su ventaja, pero también puede funcionar sin ella, más despacio, en x86, Arm o IBM Power.

¿Puedo usar los modelos de Ollama en vLLM?

Para producción, no. Ollama usa GGUF y vLLM trabaja con los pesos en el formato de Hugging Face. Tiene soporte experimental para GGUF, pero lo normal es descargar el modelo de nuevo.

¿Cuántos usuarios aguanta Ollama?

Por defecto atiende una petición por modelo y deja las demás en cola. Se puede subir con OLLAMA_NUM_PARALLEL, a costa de más memoria, y sirve para un equipo pequeño, pero no escala como vLLM.

¿Cambia mi aplicación al pasar de Ollama a vLLM?

Muy poco. Los dos ofrecen una API compatible con la de OpenAI, así que basta con cambiar la dirección y el nombre del modelo, y activar en vLLM las llamadas a herramientas si las usas.

Inferencia de IA

¿Cuántas personas usarán tu modelo a la vez?

Dinos qué modelo quieres servir y cuántas personas lo usarán a la vez, y te decimos qué motor y qué máquina necesitas. Si quieres, nos encargamos también del despliegue y del soporte.

Cuéntanos tu caso WhatsApp
Inferencia con vLLM en tu infraestructura
Bloques 3D conectados entre sí

Servidor MCP en local: qué es y cómo montarlo

/en
Ir a las preguntas frecuentes
IA en local · Guía

Servidor MCP en localQué es, cómo se monta uno en Python, qué hace falta para conectarlo a un modelo que corre en tus máquinas y qué hay que cerrar antes de dárselo a nadie.

Un modelo de lenguaje no ve tus sistemas. Para que consulte tus incidencias o abra un ticket tiene que poder llamar a algo, y durante un tiempo cada aplicación resolvía eso a su manera. MCP (Model Context Protocol) es el estándar que lo unifica: escribes un servidor una vez y sirve para cualquier cliente que hable el protocolo.

El ejemplo de esta guía no saca los datos de tu red y está escrito para la versión 2 del SDK de Python, que dejó sin funcionar buena parte de los tutoriales que circulan.

Qué es un servidor MCP

Es un programa pequeño que se pone delante de un sistema tuyo, ya sea una base de datos, una carpeta o una API interna, y le dice al asistente qué puede hacer con él y cómo pedirlo. En el otro extremo está la aplicación de IA, que el protocolo llama host, y dentro de ella un cliente que mantiene la conexión con cada servidor.

Un servidor puede ofrecer tres cosas: herramientas, que son funciones que el modelo puede pedir que se ejecuten; recursos, que son datos que le dan contexto; y plantillas de instrucciones reutilizables. Casi todo lo que vas a escribir al principio son herramientas, y la que importa es la descripción, porque es lo que lee el modelo para decidir cuándo usarla.

Local o remoto: stdio y HTTP

El protocolo define dos formas de conectarse, y elegir una u otra es la primera decisión, porque de ella depende quién puede usar el servidor y cuánto trabajo de seguridad te espera.

stdioHTTP (Streamable HTTP)
Dónde correEn la misma máquina que la aplicación de IA, como proceso suyoComo servicio aparte, en un servidor
Quién lo usaNormalmente una personaMuchos clientes a la vez
RedNo abre puertosAbre un puerto y hay que protegerlo
CredencialesLas del usuario que lo arrancaAutenticación por usuario
Encaja conProbar y uso personalDar servicio a un equipo

Para empezar, stdio: el cliente arranca el servidor como un proceso más y hablan por la entrada y la salida estándar, sin abrir ningún puerto. El problema llega cuando lo quieren usar veinte personas, porque cada una necesitaría su copia y sus credenciales. Entonces toca pasar a HTTP y tratarlo como cualquier otro servicio interno, con su autenticación y sus registros.

La revisión del protocolo de julio de 2026 eliminó las sesiones, y cada petición se entiende ya por sí sola. Eso facilita poner varios servidores detrás de un balanceador. La misma revisión deja obsoleto el antiguo transporte HTTP+SSE, así que en un proyecto nuevo no lo uses.

Cómo montar un servidor MCP en Python

Este servidor da a un asistente una sola herramienta, que busca incidencias abiertas en una base de datos SQLite. Se instala con pip install mcp y es todo el código que hace falta:

import sqlite3
from contextlib import closing
from mcp.server import MCPServer

BD = (
    "file:/srv/soporte/incidencias.db"
    "?mode=ro"
)
mcp = MCPServer("incidencias")

SQL = (
    "SELECT id, asunto, estado "
    "FROM incidencias "
    "WHERE estado = 'abierta' "
    "AND asunto LIKE ? LIMIT 20"
)

@mcp.tool()
def buscar_incidencias(
    texto: str,
) -> list[dict]:
    """Busca incidencias abiertas cuyo
    asunto contenga el texto."""
    with closing(
        sqlite3.connect(BD, uri=True)
    ) as bd:
        bd.row_factory = sqlite3.Row
        filas = bd.execute(
            SQL, (f"%{texto}%",)
        ).fetchall()
    return [dict(f) for f in filas]

if __name__ == "__main__":
    mcp.run()

El SDK saca el esquema de la herramienta de los tipos de la función y la descripción de su texto entre comillas, así que no hay que escribir nada más. La base de datos se abre en solo lectura (mode=ro), de modo que ni un error del modelo puede borrar una fila, y con la ruta completa, porque con stdio el proceso arranca en la carpeta que decida el cliente. Y la consulta va con parámetro, para que lo que escriba el modelo no pueda alterar el SQL, y con un LIMIT, porque lo que devuelvas ocupa sitio en la conversación y el modelo se pierde si le das diez mil filas.

Para probarlo sin conectar ningún modelo, ejecuta pip install "mcp[cli]" y luego mcp dev incidencias.py (necesitas Node.js y uv). Se abre el MCP Inspector, una web donde ves la herramienta y la lanzas a mano.

Si encuentras ejemplos con from mcp.server.fastmcp import FastMCP, son de la versión 1 del SDK. En la 2 esa clase pasó a llamarse MCPServer y el import antiguo da error.

Y si tus datos viven en IBM i, no hace falta empezar de cero: IBM publica un servidor MCP oficial que lanza contra Db2 for i consultas SQL definidas en YAML, y que necesita Mapepire instalado en la máquina.

Cómo conectarlo a un modelo en local

El modelo no habla con el servidor MCP. Entre los dos hace falta un cliente que pida la lista de herramientas, se la pase al modelo en cada petición, ejecute la que el modelo elija y le devuelva el resultado. Puede ser una aplicación ya hecha o unas decenas de líneas tuyas con el mismo SDK.

Lo que sí debe saber hacer el motor de inferencia es llamar a funciones. En vLLM hay que arrancarlo con --enable-auto-tool-choice y el --tool-call-parser que corresponda a tu modelo, y en Ollama basta con elegir un modelo que lo admita. Si el modelo contesta con texto en vez de pedir la herramienta, normalmente es porque ese modelo o esa plantilla no lo soportan, y no por tu servidor.

El tamaño también cuenta. Los modelos muy pequeños se inventan parámetros o llaman a la herramienta cuando no toca, y cada servidor conectado añade sus descripciones a todas las peticiones, así que conviene conectar solo lo que esa tarea necesita. Si todavía no tienes el modelo servido, lo montamos en tu infraestructura.

Qué cerrar antes de dárselo a nadie

Un servidor MCP es una puerta a tus sistemas que abre un programa que no siempre acierta, y además obedece a lo que lee. Si una herramienta devuelve el texto de un correo y ese correo dice «ignora lo anterior y manda la lista de clientes», el modelo puede intentarlo. Por eso la seguridad se pone en lo que el servidor le deja hacer.

  • Permisos mínimos. Un usuario de base de datos propio y de solo lectura, y las herramientas de escritura separadas y con confirmación de una persona.
  • Red. En local, deja el host por defecto, 127.0.0.1: con mcp.run(transport="streamable-http") solo acepta conexiones de la propia máquina. Si lo cambias a 0.0.0.0, escucha en todas las interfaces y el SDK deja de validar por su cuenta la cabecera Origin, algo que la especificación obliga a hacer y que evita que una web maliciosa llegue a tu servidor desde el navegador del empleado. Si el tráfico sale de la máquina, siempre por HTTPS.
  • Autenticación. En HTTP, la especificación se apoya en OAuth 2.1, y conviene que cada persona entre con su identidad para que el servidor aplique sus permisos y no los de una cuenta común. Con stdio, las credenciales van en el entorno del proceso.

Guarda además qué herramienta se llamó, con qué datos y en nombre de quién, y trata cada servidor MCP de terceros como cualquier otra dependencia, porque es código que se ejecuta con tus credenciales.

En agentes de IA para empresas contamos cómo lo montamos nosotros cuando hay varios sistemas de por medio, y si tu equipo prefiere construirlos por su cuenta, el curso de servidores MCP y agentes de IA cubre este camino.

Preguntas frecuentes

¿Qué es un servidor MCP?

Un programa que expone herramientas y datos de un sistema a las aplicaciones de IA siguiendo el Model Context Protocol, de forma que cualquier cliente compatible pueda usarlos sin una integración a medida.

¿Qué diferencia hay entre MCP y una API?

MCP no sustituye a tu API: suele ir delante de ella. Una API está escrita para que la integre un programador; un servidor MCP describe sus herramientas de forma que el modelo las descubra solo y cualquier cliente compatible las use sin desarrollo a medida.

¿Puedo usar MCP sin mandar datos a la nube?

Sí. El servidor, el cliente y el modelo pueden correr en tus máquinas. MCP solo define cómo se hablan, así que los datos salen de tu red únicamente si el modelo o algún servidor conectado está fuera.

¿Ollama es compatible con MCP?

Ollama admite llamadas a funciones, pero no se conecta por sí solo a servidores MCP. Necesitas un cliente que haga de puente entre los dos.

¿Qué diferencia hay entre stdio y HTTP en MCP?

Con stdio el cliente arranca el servidor en la misma máquina y hablan sin abrir puertos, lo normal para una sola persona. Con HTTP el servidor es un servicio aparte al que se conectan muchos clientes, y necesita autenticación.

¿Por qué me da error mcp.server.fastmcp?

Porque usas la versión 2 del SDK de Python, donde FastMCP pasó a llamarse MCPServer. Cambia el import por from mcp.server import MCPServer.

Agentes y MCP

¿Qué sistemas quieres conectar?

Cuéntanos qué tiene que consultar o hacer el asistente y dónde están esos datos. Te decimos qué servidores MCP harían falta y cómo dejarlos cerrados.

Cuéntanos qué quieres conectar WhatsApp
Agentes de IA y servidores MCP en tu infraestructura
Tarjeta GPU de servidor con disipador pasivo

Servidor para IA: cómo elegirlo según el modelo, los usuarios y tu CPD

/en
Ir a las preguntas frecuentes
IA en local · Guía

Servidor para IA: cómo elegirloPrimero el modelo, luego la gente que lo va a usar a la vez y al final lo que aguanta tu CPD. Estas son las cuentas que hacemos antes de recomendar una máquina.

80GBle bastan a gpt-oss-120b
2,5GBpor conversación larga en un modelo de 70.000 millones
14,3kWun servidor de 8 GPU B200 a tope

gpt-oss-120b, el modelo abierto de OpenAI, tiene 117.000 millones de parámetros y cabe en una sola GPU de 80 GB. Lo consigue con el formato: guarda casi todos sus números en 4 bits en lugar de 16, y eso cambia la máquina que necesitas más que cualquier novedad de catálogo.

Si todavía estás en el «¿y para qué quiero yo la IA en casa?», lo contamos en por qué las empresas montan sus propios servidores de IA.

Cuánta memoria ocupa el modelo

Un modelo de lenguaje es una lista enorme de números (los parámetros) que tienen que estar cargados todo el rato en la memoria de la GPU. La cuenta es una multiplicación: los parámetros por lo que ocupa cada uno, que son dos bytes en el formato original de 16 bits, uno en 8 bits y medio en 4 bits. Así, un modelo de 70.000 millones de parámetros (un 70B, con la B de billion, mil millones en inglés) pide 140 GB tal como sale de fábrica, unos 70 en 8 bits y unos 35 en 4 bits.

Llama 3.3 70B: lo que ocupa solo el modelo

16 bitsL4 · 24 GBL40S · 48 GBH100 · 80 GBRTX PRO 6000 · 96 GB16 bits140 GB8 bits8 bits70 GB4 bits4 bits35 GB
Las líneas marcan la memoria de cada tarjeta. En 8 bits, el 70B cabe en una H100 o en una RTX PRO 6000; en 4 bits, incluso en una L40S.

En 8 bits la calidad apenas se resiente, y es por donde proponemos empezar. En 4 bits el modelo sigue acertando casi siempre, pero ese «casi» conviene comprobarlo con tus documentos antes de fiarte.

En los modelos de mezcla de expertos, muy comunes entre los abiertos, solo trabaja una parte del modelo para cada token (cada trocito en que se corta el texto, más o menos una sílaba). Responden deprisa, pero la memoria se la piden entera. Es el caso de Mistral Small 4.

ModeloParámetrosMemoria del modeloDónde cabe
gpt-oss-20b21.000 millones3.600 millones activosMenos de 16 GB, porque viene en 4 bitsUna L4 de 24 GB
Gemma 4 31B31.000 millonesUnos 31 GB en 8 bitsUna L40S de 48 GB
Llama 3.3 70B70.000 millonesUnos 70 GB en 8 bitsUna RTX PRO 6000 de 96 GB
gpt-oss-120b117.000 millones5.100 millones activosMenos de 80 GB, porque viene en 4 bitsUna H100 de 80 GB o una RTX PRO 6000
Mistral Small 4119.000 millones6.500 millones activosUnos 119 GB en 8 bitsDos RTX PRO 6000
DeepSeek-V4-Flash284.000 millones13.000 millones activosUnos 284 GB en 8 bitsCuatro RTX PRO 6000 o dos B300
DeepSeek-V3 y R1671.000 millones37.000 millones activosUnos 671 GB en 8 bitsOcho H200 o B200 unidas por NVLink

Cuánta gente lo usa a la vez

Cada conversación en curso ocupa su propio trozo de memoria en la GPU mientras el modelo le responde, porque el modelo apunta ahí lo que ya ha leído para no tener que releerlo entero con cada token que escribe. Y ese trozo crece a medida que la conversación se alarga. En Llama 3.3 70B son unos 0,3 MB por token, así que una conversación de 8.000 tokens (un informe de quince páginas y unas cuantas preguntas sobre él) se lleva unos 2,5 GB. En un modelo de 8.000 millones de parámetros como Llama 3.1 8B, la misma conversación se queda en 1 GB.

Ahora pon a veinte personas lanzando preguntas a la vez sobre documentos largos. El 70B necesita 50 GB solo para sus conversaciones, el doble de lo que le queda libre a una RTX PRO 6000 de 96 GB después de cargarlo en 8 bits. Esos 25 GB dan para unas diez conversaciones largas a la vez, o el doble si esa memoria también se guarda en 8 bits, y con preguntas cortas caben muchas más. Para cien personas en hora punta hace falta otra máquina.

Una RTX PRO 6000 de 96 GB con Llama 3.3 70B en 8 bits

Lo que cabe96 GB
Modelo · 70 GBLibre · unas 10 conversaciones largas de 2,5 GB
Veinte personas con documentos largos
Modelo · 70 GBConversaciones · 50 GB
Con veinte personas, modelo y conversaciones suman 120 GB, y la tarjeta tiene 96.

La velocidad con que aparece la respuesta depende sobre todo de lo rápida que sea esa memoria, porque para cada token el modelo lee buena parte de sus parámetros. En una H200, la memoria HBM (montada junto al chip) mueve 4,8 TB/s, unas tres veces más que en una RTX PRO 6000, y eso se nota cuando mucha gente espera la respuesta.

Cuántas tarjetas hacen falta depende de cuánta gente lo use a la vez y con qué documentos. Conviene medirlo con tu carga antes de comprar. Podemos hacerlo nosotros, o tu equipo puede aprender a hacerlo en el curso de LLM en local e infraestructura GPU.

Qué máquina sale de esas cuentas

Si el modelo es pequeño y lo usan pocas personas, o el trabajo va por lotes de noche, basta una CPU con mucha memoria. Pero en cuanto hay alguien esperando la respuesta, la GPU deja de ser opcional.

El escalón más habitual en una empresa es un servidor de rack con entre una y ocho tarjetas PCIe (las que se pinchan en una ranura del servidor). La L4, de 24 GB, va bien para modelos pequeños; la L40S llega a 48 GB, y la RTX PRO 6000 Blackwell a 96 GB, suficiente para un 70B en 8 bits. Con estas tarjetas se montan desde un servidor 2U (una U son 4,45 cm de altura de armario) con hasta cuatro hasta uno 4U con ocho, donde ya caben todos los modelos de la tabla hasta DeepSeek-V4-Flash. DeepSeek-V3 cabría en memoria, pero repartido entre ocho tarjetas que solo se hablan por PCIe iría mucho más lento.

Por encima están las placas HGX: ocho GPU de centro de datos (H200, B200 o B300, de 141 a 288 GB cada una) unidas por NVLink, una conexión directa entre ellas varias veces más rápida que PCIe. Con ella, un modelo de cientos de miles de millones de parámetros se reparte entre las ocho como si fueran una sola GPU. Es la máquina para modelos como DeepSeek-V3, para cientos de usuarios o para entrenar modelos propios, y la hay con B300 y refrigeración por aire. Comprarla para que un departamento resuma contratos es matar moscas a cañonazos.

De la máquina más sencilla a la más grande

CPU con mucha memoria

sin GPU

Modelos pequeños, pocas personas o lotes de noche.

De una a cuatro tarjetas PCIe

2U

Con una RTX PRO 6000 de 96 GB, un 70B en 8 bits.

Hasta ocho tarjetas PCIe

4U

Todos los modelos de la tabla hasta DeepSeek-V4-Flash.

Placa HGX: ocho GPU con NVLink

141 a 288 GB por GPU

DeepSeek-V3 y R1, cientos de usuarios o entrenar modelos propios.

NVIDIA no es la única opción: AMD vende sus Instinct y vLLM también funciona sobre ellas, aunque casi todo el software de IA se prueba antes en NVIDIA, así que conviene comprobar que lo que vas a usar va bien en AMD.

Lo que tiene que aguantar tu CPD

La cuenta que más sustos da es la de la sala. Un servidor de ocho GPU B200 consume hasta 14,3 kW, más o menos lo que tienen contratado tres pisos con la potencia habitual de 4,6 kW. Antes de pedir nada hay que saber cuánta potencia llega al armario, si la climatización puede sacar ese calor y si el suelo aguanta el peso.

Las tarjetas PCIe son más llevaderas, aunque no tanto como parece: cada RTX PRO 6000 puede llegar a 600 W, y ocho suman casi 5 kW solo en GPU. Algunos servidores 2U las limitan a 450 W para que quepan cuatro. Y si la sala no da para más aire acondicionado, hay servidores 5U de ocho B200 con refrigeración líquida, siempre que la sala tenga o pueda tener circuito de agua.

Potencia eléctrica, en kW

Servidor de ocho GPU B20014,3 kWTres pisos de 4,6 kW13,8 kWOcho RTX PRO 6000 a 600 W4,8 kWCuatro RTX PRO 6000 a 450 W1,8 kW
Las dos últimas barras cuentan solo las tarjetas; el servidor entero consume algo más.

Si la máquina va a una oficina o a una planta sin CPD, mandan el fondo del armario y la temperatura. Hay servidores cortos, de unos 44 cm de fondo, que en algunas configuraciones aguantan hasta 55 °C con GPU pequeñas como la L4 y unos 40 °C con GPU mayores.

Quién mantiene el software

Con la máquina elegida falta el software: el sistema operativo, los controladores de la GPU y el programa que sirve el modelo. Las tres piezas tienen que ir a juego, porque un controlador de NVIDIA que no casa con la versión de CUDA convierte la GPU en un pisapapeles carísimo. Trabajamos con dos combinaciones de software. Una es Ubuntu, que desde la 26.04 LTS trae CUDA (las bibliotecas de NVIDIA para usar la GPU) en sus propios repositorios, con el soporte de Canonical. La otra es Rocky Linux en su edición RLC Pro AI, con CUDA, los controladores de red y PyTorch ya validados y el soporte de CIQ, más cómoda si tus servidores ya son de la familia Red Hat.

Encima va vLLM, el programa de código abierto que reparte la memoria entre las conversaciones. Habla el mismo idioma que la API de OpenAI, así que las aplicaciones que ya tengas apenas cambian. Si varios equipos van a compartir las GPU, se añade Kubernetes para repartirlas entre ellos, y eso se practica en el curso de vLLM en Kubernetes. Como somos partner de Canonical y de CIQ, del servidor, el sistema y el soporte se encarga el mismo equipo. Y si prefieres no pelearte con nada de esto, te lo dejamos montado como servicio de inferencia en tus servidores.

Preguntas frecuentes

¿Cuánta memoria de GPU necesita un modelo de 70.000 millones de parámetros?

Solo para el modelo, 140 GB en 16 bits, unos 70 en 8 bits y unos 35 en 4 bits. A eso se suman unos 2,5 GB por cada conversación larga. Una RTX PRO 6000 de 96 GB lo sirve en 8 bits a unas pocas personas a la vez.

¿Se puede tener IA en local sin GPU?

Sí. Con modelos pequeños, pocos usuarios o trabajos por lotes basta una CPU con memoria suficiente. Cuando hay gente esperando respuesta o el modelo crece, hace falta GPU.

¿A cuántas personas atiende un servidor con una sola GPU?

Depende del modelo y de lo largas que sean las conversaciones, porque cada una ocupa memoria. Un 70B en 8 bits en una RTX PRO 6000 atiende unas diez conversaciones largas a la vez, y un modelo de 8.000 millones en la misma tarjeta, decenas. Lo fiable es medirlo con tu carga.

¿Cuánto cuesta un servidor para IA?

Lo que más pesa en el precio es el número y la clase de GPU; después vienen la memoria, la red y los años de soporte. Por eso el precio sale del modelo que vas a servir y de cuánta gente lo va a usar. Con esos datos y el sitio donde irá la máquina, en el configurador o hablando con nosotros, te preparamos una propuesta.

Servidores para IA

¿Qué servidor te hace falta?

Dinos qué modelo quieres servir, para cuánta gente y dónde va a ir la máquina. Si hace falta, medimos tu carga antes de que compres, y del servidor, el sistema y el soporte se encarga el mismo equipo. Si prefieres hacer tú las cuentas, el configurador te deja montarla paso a paso.

Configurar mi servidor WhatsApp
Servidores para IA, con Ubuntu o Rocky Linux y soporte
Rack Vera Rubin NVL72 frente a GB300 NVL72

Vera Rubin contra GB300: cuánto mejora y qué le exige a tu CPD

/en
Ir a las preguntas frecuentes
Comparativa · Rubin vs Blackwell

Vera Rubin contra GB300: cuánto mejora y qué le exige a tu CPDComparamos el Vera Rubin NVL72 con el GB300 NVL72, el último Blackwell, rack contra rack y con las cifras de la ficha de NVIDIA.

El Vera Rubin NVL72 es el rack que sustituye al GB300 NVL72, y por fuera cuesta distinguirlos: mismo armario, 72 GPU y 36 CPU. Por dentro, Rubin da unas 2,5 veces más cálculo en FP4 (2,3 en entrenamiento) y una memoria casi dos veces y media más rápida, con los mismos 288 GB por GPU.

Ese salto se paga en el CPD: de unos 135 kW por rack se pasa a hasta 227 kW, y ya no hay aire, todo va por agua. Y ojo con las cifras de «diez veces más» que circulan, porque casi todas lo comparan con el GB200, no con el GB300.

2,5×el FP4 del GB300
288GB por GPU en los dos
227kW por rack, a tope

Dos racks que parecen gemelos

Los dos son lo que NVIDIA llama un sistema de escala de rack: un armario de 48U en el que 18 bandejas de cálculo y 9 de conmutadores se comportan como un único ordenador enorme. Cada bandeja lleva dos CPU y cuatro GPU, así que el rack suma 36 CPU y 72 GPU, todas unidas por NVLink (la red propia de NVIDIA para conectar GPU entre sí), de modo que el software las ve como un solo bloque de memoria y cálculo.

Por dentro cambian las piezas. El GB300 lleva CPU Grace, de 72 núcleos Arm, y GPU Blackwell Ultra; el Vera Rubin, CPU Vera, de 88 núcleos diseñados por la propia NVIDIA, y GPU Rubin. Por fuera son casi idénticos, con el mismo armario MGX, el mismo número de bandejas y el agua entrando a la misma temperatura, 45 °C, y de ahí la tentación de pensar que basta con cambiar las bandejas. Ya veremos que no.

Si además te has liado con los nombres, no es culpa tuya. Durante 2025 NVIDIA llamó a este sistema Vera Rubin NVL144, porque cada GPU Rubin lleva dos chips dentro y le pareció buena idea contar chips en vez de GPU; después volvió a contar GPU y lo rebautizó como NVL72. Y para rematar, en las noticias de 2026 «NVL144» suele referirse ya a otro producto, el rack Kyber con Rubin Ultra, que NVIDIA sitúa en 2027.

Las cifras, rack contra rack

Todas son por rack completo y salen de las fichas actuales de GB300 NVL72 y Vera Rubin NVL72. FP4 es el formato de números de cuatro bits con el que hoy se sirven los modelos grandes, y un petaflop son mil billones de operaciones por segundo.

Por rackGB300 NVL72Vera Rubin NVL72
CPU36 Grace de 72 núcleos36 Vera de 88 núcleos
GPU72 Blackwell Ultra72 Rubin
Memoria por GPU288 GB de HBM3e288 GB de HBM4
Velocidad de esa memoria576 TB/s1.400 TB/s×2,4
NVLink130 TB/s216 TB/s×1,7
FP4 para inferencia1.440 petaflops3.600 petaflops×2,5
FP4 para entrenamiento1.080 petaflops2.520 petaflops×2,3
Memoria de las CPU17 TBHasta 54 TB
Consumo135 kW, picos de 155De 156 a 227 kW
RefrigeraciónAgua, con algo de aireSolo agua
RedConnectX-8, BlueField-3ConnectX-9, BlueField-4

La fila que más pesa es la de la memoria, aunque parezca la más aburrida. Rubin no trae más memoria por GPU, porque los dos llevan 288 GB, pero la que trae es muchísimo más rápida: el salto de HBM3e a HBM4 lleva el ancho de banda del rack de 576 a 1.400 TB/s. Y eso importa más de lo que parece, porque cuando un modelo genera texto la GPU pasa buena parte del tiempo de brazos cruzados, esperando a que le lleguen los datos de la memoria.

Los anuncios, eso sí, conviene leerlos con lupa. NVIDIA dio en enero unas cifras de NVLink y de memoria más altas que las de su ficha de octubre, que son las que usamos aquí. Las promesas de «una décima parte del coste por millón de tokens» o «diez veces más tokens por megavatio» están medidas contra el GB200 NVL72, el abuelo de la familia, no contra el GB300. Y como la cifra de inferencia de cada generación se mide con condiciones distintas, la comparación más limpia es la de entrenamiento, que pasa de 1.080 a 2.520 petaflops.

Qué cambia en el CPD

Aquí es donde el parecido se acaba. El GB300 NVL72 consume unos 135 kW por rack, con picos de 155 kW, mientras que NVIDIA publica para Rubin tres perfiles de potencia que van de 156 kW en el más comedido a 227 kW en el de máximo rendimiento. Para hacerse una idea, 227 kW es lo que tienen contratado unos cincuenta pisos con la potencia habitual de 4,6 kW, todo en un solo armario. Las bandejas que reparten la electricidad también cambian, de unidades de 33 kW a cuatro de 110 kW, así que la cuenta de cuántos racks caben en tu sala hay que rehacerla.

Con el agua pasa algo parecido. El GB300 saca alrededor del 90 % del calor con agua y el resto con aire, pero en Rubin todo va por agua, hasta las barras que llevan la corriente, y las bandejas ni siquiera tienen ventiladores. Por eso lo primero que hay que revisar es la CDU (el equipo que reparte el agua entre los racks) y el caudal, unos datos que por ahora no hemos encontrado publicados para Rubin.

Para quién es cada uno

Los fabricantes empezaron a enviarlo en octubre de 2026 y lo dirigen a proveedores de nube y de infraestructura de IA, que son quienes pueden tener 72 GPU ocupadas día y noche y salas preparadas para más de 150 kW por armario. El GB300 NVL72 sigue a la venta, y es la opción lógica si ya tienes la sala diseñada para él o si necesitas capacidad ahora.

Para una empresa que quiere tener sus modelos en casa, ninguno de los dos suele ser el punto de partida: si la idea es que el departamento legal resuma contratos con un modelo propio, un rack de 72 GPU es como comprarse un Airbus para ir a por el pan. Un servidor de ocho GPU con B300 y refrigeración por aire, que hoy fabrican casi todas las marcas, sirve modelos grandes sin instalación de agua, aunque pide bastante más potencia por armario que un servidor corriente. Si la carga crece, se añaden más. El rack entero tiene sentido cuando un solo modelo necesita más memoria de la que cabe en ocho GPU, o cuando vendes capacidad de cálculo a terceros.

Preguntas frecuentes

¿Para qué sirve el Vera Rubin NVL72?

Para entrenar y servir modelos de IA muy grandes a escala de centro de datos: sus 72 GPU trabajan como un solo bloque de memoria y cálculo. Lo compran sobre todo proveedores de nube e infraestructura de IA. Para tener modelos propios en una empresa suele bastar un servidor de ocho GPU.

¿Vera Rubin NVL144 y Vera Rubin NVL72 son lo mismo?

Sí. NVIDIA lo llamaba NVL144 porque contaba los dos chips de cada GPU Rubin, y después lo rebautizó como NVL72 para contar GPU, igual que en el GB300. Son 72 GPU Rubin y 36 CPU Vera en un rack.

¿Puedo cambiar un GB300 NVL72 por un Vera Rubin en el mismo sitio?

El armario tiene el mismo formato y la misma entrada de agua a 45 °C, pero Rubin consume más por rack, se refrigera entero con agua y usa otras bandejas de potencia. Antes de planificarlo hay que revisar la potencia contratada, la CDU y el caudal de agua.

¿Rubin es diez veces más barato por token que el GB300?

No. Esa cifra de NVIDIA compara Rubin con el GB200 NVL72, la generación anterior al GB300. Contra el GB300 la mejora es menor, y la real depende del modelo y de cuántos usuarios atiendas a la vez.

¿Cuánto cuesta un rack Vera Rubin NVL72?

Ni NVIDIA ni los fabricantes que lo montan publican precio. Se vende por proyecto, junto con la red, el almacenamiento, la instalación y los servicios, y el precio sale de todo ello.

SIXE

¿Cuánta GPU necesitas de verdad?

Cuéntanos qué modelos quieres servir, para cuántos usuarios y qué CPD tienes, y te decimos si te basta un servidor de ocho GPU o necesitas un rack entero.

Cuéntanos tu caso WhatsApp
Servidores para IA de cualquier fabricante, instalados y con soporte · sixe.es

Instalar drivers de NVIDIA y CUDA en Rocky Linux 8, 9 y 10

/en
Ir a las preguntas frecuentes
Guía · Rocky Linux

Cómo instalar los drivers de NVIDIA y CUDA en Rocky Linux 8, 9 y 10Elige tu versión y tu caso, copia los comandos y comprueba que funciona.

Poner en marcha una GPU de NVIDIA en Rocky Linux lleva una docena de comandos, y cuáles depende de la versión de Rocky y de si la máquina tiene escritorio, Secure Boot o contenedores.

Aquí abajo eliges tu caso y te quedan solo los comandos que te tocan. Salen de la guía de instalación de NVIDIA para Rocky Linux.

Antes de empezar

Lo primero es comprobar que el sistema ve la tarjeta. Si esto no devuelve nada, el problema está en el hardware o en la BIOS, y ningún driver lo va a arreglar:

lspci | grep -i nvidia

Los paquetes de esta guía usan los módulos abiertos del kernel de NVIDIA, que son los que NVIDIA recomienda para GPU de la generación Turing en adelante. Eso incluye las tarjetas de centro de datos desde la T4 y las RTX de la serie 20 en adelante. Las más antiguas, como la P100 o la V100, necesitan los módulos propietarios, y esta guía no los cubre.

Luego mira si tienes Secure Boot activado:

mokutil --sb-state

Si sale enabled, marca Secure Boot en la guía. Vas a necesitar acceso a la consola del servidor en el siguiente reinicio, porque la pantalla para confirmar la clave no aparece por SSH.

Instala el driver y CUDA

Elige tu versión de Rocky y marca lo que te toque. Los pasos cambian sobre la marcha y cada comando tiene su botón de copiar. Si vas a preparar varias máquinas, cópialo todo como script.

Versión
Tu caso

    Comprueba que funciona

    Después de reiniciar, nvidia-smi debería mostrar tus GPU con la versión del driver. La versión de CUDA que aparece arriba a la derecha es la más alta que admite ese driver, no la del toolkit que tienes instalado, y eso lía a mucha gente.

    Para ver la versión del módulo que está cargado de verdad en el kernel:

    cat /proc/driver/nvidia/version

    El toolkit se instala en /usr/local/cuda y no queda en el PATH. Para usar el compilador, añádelo a tu perfil y compruébalo:

    export PATH=/usr/local/cuda/bin:$PATH
nvcc --version

    Actualiza y quita el driver

    Para actualizar dentro de la misma rama basta con un sudo dnf update. Cuando entra un kernel nuevo, DKMS compila el módulo para él. Merece la pena comprobar que lo ha hecho antes de reiniciar, porque si no el servidor vuelve sin GPU:

    dkms status

    En Rocky 8 y 9, pasar a otra rama del driver obliga a cambiar el flujo del módulo:

    sudo dnf module reset nvidia-driver
sudo dnf module enable nvidia-driver:<flujo>
sudo dnf update --allowerasing

    Rocky 10 no tiene flujos de módulos. Si necesitas quedarte en una rama, fíjala con dnf versionlock.

    Para quitar el driver en Rocky 8 y 9:

    sudo dnf module remove --all nvidia-driver
sudo dnf module reset nvidia-driver

    Y en Rocky 10:

    sudo dnf remove nvidia-driver\*

    En los dos casos solo se va el driver. El toolkit de CUDA se queda hasta que lo quites tú.

    Cuando hay más de un servidor

    En un equipo de trabajo, todo esto se hace en una mañana. En un rack de servidores con GPU se convierte en mantenimiento. Cada actualización del kernel obliga a recompilar los módulos en todos los nodos, CUDA y PyTorch tienen que seguir casando con el driver, y un nodo que arranca sin GPU se queda parado hasta que alguien se da cuenta.

    Eso es lo que resuelve RLC Pro AI, la edición de Rocky Linux de CIQ para servidores de IA. Trae el driver de centro de datos, CUDA, cuDNN, NCCL y PyTorch instalados y probados con su propio kernel. Somos partner de CIQ: lo desplegamos en tus servidores y le damos soporte. El resto de ediciones están en nuestra página de soporte de Rocky Linux.

    Preguntas frecuentes

    ¿Necesito el toolkit de CUDA para usar PyTorch?

    No. Los paquetes de PyTorch que se instalan con pip traen las librerías de CUDA que necesitan, así que basta con el driver. El toolkit sirve para compilar tu propio código CUDA con nvcc.

    nvidia-smi dice que no puede comunicarse con el driver de NVIDIA. ¿Qué ha pasado?

    Casi siempre es un kernel nuevo para el que no se compiló el módulo. Mira dkms status, instala las cabeceras del kernel nuevo si faltan y reinicia.

    ¿Sirve también para AlmaLinux?

    Sí. NVIDIA documenta AlmaLinux 8, 9 y 10 con los mismos comandos que Rocky, flujos de módulos incluidos en la 8 y la 9.

    ¿Qué rama del driver uso?

    El flujo open-dkms instala la última. En producción, muchos equipos fijan una rama, por ejemplo la 580, para que una actualización no les meta una versión mayor sin avisar.

    SIXE

    ¿Tienes servidores con GPU en Rocky?

    Cuéntanos cuántos servidores tienes, con qué GPU y qué quieres ejecutar en ellos, y te decimos si RLC Pro AI tiene sentido y cómo sería el cambio.

    Hablar con SIXE WhatsApp
    Soporte de Rocky Linux, Red Hat, SUSE y Ubuntu · sixe.es

    SIXE, partner de CIQ: qué cambia para Rocky, CentOS y RHEL

    /en
    Ir a las preguntas frecuentes
    Alianza · Rocky Linux

    SIXE, partner de CIQ: qué cambia para Rocky, CentOS y RHELLo que supone para quien tiene servidores con CentOS, RHEL o Rocky.

    Desde octubre de 2026 somos partner de CIQ, la empresa detrás de Rocky Linux, y estamos muy contentos.

    Rocky llevaba tiempo apareciendo en los servidores de nuestros clientes y hasta ahora lo atendíamos por nuestra cuenta. A partir de ahora lo hacemos con el respaldo de quien lo hace.

    Por qué CIQ

    CIQ la fundó Gregory Kurtzer, cofundador de CentOS. Cuando Red Hat anunció en 2020 el final de CentOS Linux, Kurtzer lanzó Rocky Linux para que quien tenía servidores con CentOS pudiera seguir trabajando igual, y hoy CIQ es su principal patrocinador.

    Para muchos de nuestros clientes que venían de CentOS, Rocky era el paso natural. Lo que faltaba era una empresa detrás que lo respaldara con suscripción y soporte, y eso es lo que pone CIQ.

    Qué cambia para nuestros clientes

    Quien quiera Rocky con soporte ya no tiene que tratar por un lado con un fabricante en Estados Unidos y por otro con nosotros. Nos encargamos de dar de alta la suscripción, migramos los servidores y atendemos las incidencias del día a día.

    Lo tenemos explicado en la página de soporte de Rocky Linux. Si ya sabes de dónde partes, quizá te sirva más una de estas guías:

    La parte de inteligencia artificial

    El acuerdo incluye también los productos de IA de CIQ, y es la parte que más ganas teníamos de contar. Desde hace un tiempo montamos infraestructura de inferencia sobre Ceph, OpenStack y Kubernetes para empresas que prefieren no sacar sus datos del CPD. Ahora también podemos ofrecer el sistema operativo de esos servidores con GPU, RLC Pro AI, con soporte del fabricante.

    Rocky se suma a Ubuntu, Red Hat y SUSE

    Seguimos sin casarnos con ninguna distribución. Somos partner de Canonical para Ubuntu y llevamos Red Hat, SUSE y Debian en producción. Rocky con CIQ es una opción más, y la propondremos cuando encaje con lo que corre en cada servidor.

    Preguntas frecuentes

    ¿Desde cuándo es SIXE partner de CIQ?

    Desde octubre de 2026. Desde entonces podemos ofrecer las suscripciones de CIQ además de la migración y el soporte que ya hacíamos.

    ¿Qué es CIQ?

    La empresa que fundó Gregory Kurtzer, cofundador de CentOS, y el principal patrocinador de Rocky Linux. Vende las ediciones empresariales de Rocky: RLC Pro, RLC Pro Hardened, RLC Pro AI y CIQ Bridge para CentOS 7.

    Si ya trabajo con SIXE con Red Hat o Ubuntu, ¿cambia algo?

    No. Seguimos con Red Hat, SUSE, Ubuntu y Debian igual que hasta ahora. Solo te hablaremos de Rocky si vemos que te encaja.

    SIXE

    ¿Tienes servidores con CentOS, RHEL o Rocky?

    Cuéntanos qué servidores tienes y qué corre en cada uno, y te decimos qué edición encaja y cómo sería el paso.

    Hablar con SIXE WhatsApp
    Soporte de Rocky Linux, Red Hat, SUSE y Ubuntu · sixe.es

    Qué es IBM Connect:Direct y por qué sigue moviendo los ficheros de la banca

    /en
    Ir a las preguntas frecuentes
    Transferencia de ficheros · MFT

    Qué es IBM Connect:Direct y por qué sigue moviendo los ficheros de la bancaEn qué se diferencia de SFTP, cómo funcionan sus Process y el reinicio desde el punto de fallo, y cuándo tiene sentido hoy.

    Hay software que conoce todo el mundo y software que lleva décadas sosteniendo el proceso nocturno de un banco sin que nadie fuera del departamento lo haya oído nombrar. IBM Connect:Direct es de los segundos.

    Mueve ficheros entre sistemas (las nóminas, el cuadre de tarjetas, el envío a la cámara de compensación), no tiene interfaz bonita, no sale en ninguna presentación de producto y su documentación sigue hablando de «nodos» como hace treinta años. Y sigue ahí.

    Qué es exactamente

    Connect:Direct es un producto de transferencia gestionada de ficheros (MFT, por sus siglas en inglés) que mueve datos punto a punto entre dos sistemas que se conocen previamente. Usa su propio protocolo y no pasa por ningún servidor de terceros. IBM lo llamó durante años Sterling Connect:Direct, y en la documentación actual ya aparece como IBM Connect:Direct.

    A un servidor SFTP se conecta cualquiera que tenga credenciales, y lo que pueda hacer una vez dentro depende de cómo esté configurado el servidor. Aquí la relación es al revés: los dos extremos son nodos definidos el uno en el otro, con su identidad, sus permisos y sus reglas, y una transferencia entre dos sistemas que no se han declarado mutuamente no ocurre.

    La segunda diferencia es la que explica por qué sigue instalado, y es tan poco vistosa como decisiva: el reinicio desde el punto de fallo. Cuando se transfiere un fichero de doscientos gigas y la línea se cae al 93 %, un FTP o un SFTP lanzados desde un script suelen volver a empezar desde cero. Solo continúan si alguien programó la reanudación. Connect:Direct va guardando puntos de control por el camino, y el parámetro ckpt del paso de copia define cada cuánto, así que al reanudar continúa desde el último. En una ventana nocturna que termina a las seis de la mañana, esa diferencia decide si el proceso del día siguiente arranca o no.

    PreguntaSFTPConnect:Direct
    ¿Quién puede conectarse?Cualquiera con credenciales del servidor.Solo los nodos que se han declarado el uno en el otro.
    ¿Y si se corta a mitad?Desde un script, normalmente vuelta a empezar.Sigue desde el último punto de control.
    ¿Qué pasa al terminar?Nada, salvo que lo programes aparte.El Process puede lanzar un job o un comando en el destino.
    ¿Socios fuera de tu red?Lo habitual es dejar un servidor expuesto en la DMZ.Secure Proxy en la DMZ, sin puertos entrantes hacia la red interna.

    El trabajo se declara, no se teclea

    En Connect:Direct no se «hace una transferencia»: se escribe un Process, un pequeño programa en su propio lenguaje que declara qué hay que mover, desde dónde, hacia dónde, con qué disposición de fichero y qué hacer después. Y ese «qué hacer después» es más de lo que parece, porque un Process puede ejecutar un job, un programa o un comando en el servidor del otro extremo, encadenar pasos y decidir el siguiente según el resultado del anterior.

    Un mismo Process puede recoger el fichero, enviarlo, lanzar en el destino el proceso que lo carga en la base de datos y avisar si el código de retorno no es el esperado. Todo eso queda escrito, versionado y auditable en un sitio, en vez de repartido entre un script, un planificador y la memoria de quien lo montó. La contrapartida es que hay que aprender el lenguaje, y ahí es donde se atasca casi todo el que llega desde el mundo del scripting.

    La seguridad, que es de donde vienen casi todos los proyectos

    El complemento Secure Plus añade cifrado y autenticación a las sesiones entre nodos, con TLS y certificados, de modo que los dos extremos se identifican antes de mover un solo byte.

    El caso que decide estos proyectos es cuando el socio está fuera de tu red, que es lo normal. La respuesta de IBM se llama Sterling Secure Proxy: un intermediario en la DMZ que termina ahí la sesión entrante, autentica al que llama y abre él mismo una conexión nueva hacia dentro. Nadie de fuera alcanza el servidor de verdad, y no hace falta abrir ningún puerto entrante hacia la red interna. Es la arquitectura que pide cualquier auditoría seria, y la razón por la que muchos proyectos de Connect:Direct no empiezan por una necesidad de negocio, sino por un informe de auditoría.

    El último motivo de su longevidad es dónde corre: z/OS, UNIX y Linux, Windows, y también plataformas que ya casi nadie nombra pero siguen en producción, como i5/OS, OpenVMS o HP NonStop. Un nodo de z/OS y uno de Linux hablan entre sí igual, con el mismo lenguaje de Process y las mismas reglas, y nadie tiene que traducir nada entre el mainframe y el servidor distribuido. Cuando una organización tiene las dos cosas, y la banca las tiene, eso vale más que cualquier funcionalidad nueva.

    Si montaras esto hoy de cero, ¿usarías Connect:Direct?

    Depende de con quién tengas que hablar. Para un intercambio nuevo con un socio nuevo, hoy se empieza por algo más estándar: SFTP gestionado, una API, o Sterling File Gateway si hace falta una puerta de entrada única con su portal y sus perfiles. Connect:Direct gana cuando el volumen es grande, la ventana es estrecha, un fallo a mitad no es aceptable y, sobre todo, cuando el otro extremo ya lo tiene. Esto último pesa más que todo lo demás junto, porque en el intercambio de ficheros el protocolo casi siempre lo decide la entidad grande del otro lado.

    Tampoco es un producto de EDI: mueve el fichero, pero no interpreta lo que hay dentro ni traduce un pedido de un formato a otro, que es trabajo de Sterling B2B Integrator. Ni sirve para que alguien mande un adjunto grande, porque está pensado para transferencias que se repiten cada día a la misma hora entre los mismos dos sistemas. Y cuando los nodos se cuentan por decenas, el seguimiento centralizado va aparte, en Sterling Control Center.

    La formación, que es donde está el problema

    El producto se vende, se soporta y se actualiza, pero la plantilla que lo montó en su día se va jubilando, y los Process que escribió siguen ejecutándose cada noche. Encontrar a alguien que sepa leerlos, y no digamos cambiarlos sin romper el cierre del día, es cada vez más difícil.

    Nosotros impartimos los tres cursos oficiales, con laboratorio sobre nodos reales, porque el ckpt se entiende cortando la conexión a mitad de una transferencia y viendo qué pasa, no leyendo la definición del parámetro: Connect:Direct para UNIX (6C02G), para Windows (6C03G) y para z/OS (6C07G). Los tres cubren lo mismo desde la plataforma donde corra tu nodo, y el resto de la familia está en el catálogo de formación de IBM Sterling. Se montan en grupo cerrado, en español, inglés o francés, online o en tus instalaciones.

    Preguntas frecuentes

    ¿Qué es IBM Connect:Direct?

    Es un producto de IBM de transferencia gestionada de ficheros que mueve datos punto a punto entre sistemas que se conocen previamente. Tiene su propio protocolo, reinicia desde el punto de fallo y puede ejecutar tareas en el destino al terminar.

    ¿En qué se diferencia Connect:Direct de SFTP?

    En SFTP se conecta cualquiera con credenciales y, si la transferencia se corta, vuelve a empezar. En Connect:Direct los dos nodos se declaran el uno en el otro, la transferencia continúa desde el último punto de control y el propio Process puede lanzar acciones en el otro extremo.

    ¿Connect:Direct sirve para EDI?

    No. Mueve el fichero sin interpretar su contenido. La traducción de formatos de EDI la hace otro producto de la familia, Sterling B2B Integrator.

    SIXE

    ¿Tienes un Connect:Direct heredado?

    Si nadie en tu equipo sabe tocarlo, o una auditoría te ha dicho que no puedes seguir exponiendo el servidor, dinos qué versión tienes instalada y en qué plataforma, y te decimos qué haría falta.

    Hablar con SIXE WhatsApp
    Formación y soporte de IBM Sterling · sixe.es

    IBM i 7.4 ya no tiene soporte: qué hacer si sigues en esa versión

    /en
    Ir a las preguntas frecuentes
    IBM i · Fin de soporte

    IBM i 7.4 ya no tiene soporte: qué hacer si sigues en esa versiónQué cambia desde el 30 de septiembre, qué camino te deja tu servidor Power y cuándo compensa pagar la extensión de IBM.

    El 30 de septiembre de 2026 IBM dejó de dar soporte estándar a IBM i 7.4, la versión en la que siguen funcionando muchos de los AS400 que hay en las empresas.

    El servidor no se va a apagar ni va a fallar mañana, pero ya no recibe correcciones con el mantenimiento normal, tampoco las de seguridad, salvo que contrates aparte la extensión de IBM.

    30.09fin del soporte estándar de IBM i 7.4
    2029último año de la extensión de pago
    70% de las empresas encuestadas prevé actualizar en 2026

    Lo de AS400 es costumbre. IBM le cambió el nombre hace más de veinte años, primero a iSeries, luego a System i y por último a IBM i sobre servidores Power. Aun así, en casi todas las empresas la máquina se sigue llamando así, y seguramente en la tuya también. Lo que importa es qué versión del sistema lleva y en qué servidor corre, y para saber la versión basta con el comando DSPPTF: en la cabecera aparece, y V7R4M0 es IBM i 7.4.

    Qué ha cambiado el 30 de septiembre

    IBM anunció la fecha en septiembre de 2025, y desde el 30 de abril de 2026 ya no vende 7.4. Desde el 1 de octubre, quien sigue en esa versión ya no recibe los PTF, los parches con los que IBM corrige fallos y agujeros de seguridad. Tampoco tiene soporte técnico normal cuando algo se rompe.

    Para quien todavía no haya actualizado, IBM vende una extensión de servicio que cubre hasta el 30 de septiembre de 2029. Mantiene las correcciones críticas y de seguridad, pero cuesta más que el soporte normal y cubre menos, así que no está pensada para quedarse a vivir en ella.

    No eres el único que tiene la actualización pendiente. En la última encuesta anual sobre el mercado de IBM i, con 315 empresas, el 70 % decía tener previsto actualizar el hardware, el software o las dos cosas durante 2026.

    Tu servidor decide el camino

    Antes de hablar de versiones hay que mirar el hierro, porque cada generación de procesador Power admite IBM i hasta una versión concreta, y eso marca lo que puedes hacer:

    ServidorVersión máxima de IBM iQué puedes hacer
    Power87.4Ninguna versión nueva: cambiar de servidor, llevar las cargas a la nube o pagar la extensión mientras tanto.
    Power97.5Subir a 7.5 te da margen. Para 7.6 habrá que cambiar de servidor.
    Power10 (firmware FW1060 o posterior)7.6Saltar de 7.4 a 7.6 directamente.
    Power117.6Saltar de 7.4 a 7.6 directamente.

    Si tu servidor es un Power8, la decisión deja de ser solo de software y pasa a ser de presupuesto. No hay versión nueva que instalar sin cambiar de máquina o llevar las cargas a un servidor Power en la nube. Con un Power9 puedes ganar tiempo subiendo a 7.5, y dejar el cambio de servidor para cuando toque 7.6. Y si el Power9 te funciona bien, alargarle la vida con un buen mantenimiento también es una opción razonable, como contamos en Power9: ¿actualizar o mantener?

    Saltar de 7.4 a 7.6 de una vez

    Con un Power10 o un Power11, IBM permite pasar de 7.4 a 7.6 directamente, sin parar en 7.5. Te ahorras una actualización, aunque hay que leer con calma las notas de cambios de las dos versiones, porque lo que cambió en 7.5 también te afecta. Y antes hay que instalar unos parches previos que IBM tiene documentados.

    Lo que más tiempo lleva es comprobar que todo lo que corre encima sigue funcionando igual: los programas en RPG o COBOL de hace años, las herramientas de otros proveedores y las copias de seguridad con BRMS, la herramienta de backup del propio IBM i. Por eso conviene probarlo antes en una partición aparte o en una copia del sistema, y no en la máquina de producción un viernes por la tarde.

    A cambio, 7.6 trae cosas que en 7.4 no vas a ver nunca. La más visible es la verificación en dos pasos integrada en el inicio de sesión, sin coste extra, que hasta ahora obligaba a comprar un producto aparte. El resto lo contamos en qué trae IBM i 7.6, y si tu equipo necesita ponerse al día, para eso está nuestro curso de novedades de IBM i 7.6 y Power10.

    Si no puedes actualizar todavía

    Hay motivos razonables para no hacerlo este trimestre: una aplicación de un proveedor que aún no garantiza que funcione en 7.6, un cierre de ejercicio o un presupuesto de hardware que llega el año que viene. En esos casos la extensión de IBM es lo sensato, siempre que se use como lo que es, un puente con fecha de salida.

    Lo que no conviene es quedarse en 7.4 sin extensión y sin plan. El sistema seguirá arrancando cada mañana, pero cualquier fallo de seguridad que aparezca a partir de ahora se queda sin corregir, y eso es difícil de explicar en una auditoría. Si lo que falta es gente para hacerlo, nosotros nos ocupamos del mantenimiento de IBM i, y si toca cambiar de servidor, la generación actual es IBM Power11.

    Preguntas frecuentes

    ¿Mi AS400 deja de funcionar si sigue en IBM i 7.4?

    No. El sistema sigue funcionando igual, pero desde el 30 de septiembre de 2026 ya no recibe correcciones ni soporte técnico de IBM salvo que contrates la extensión de servicio de pago.

    ¿Se puede pasar de IBM i 7.4 a 7.6 directamente?

    Sí, si el servidor es un Power10 con firmware FW1060 o posterior, o un Power11. En Power9 el máximo es IBM i 7.5, y en Power8 el máximo es 7.4.

    ¿Hasta cuándo puedo seguir en IBM i 7.4 con soporte?

    Con la extensión de servicio que vende IBM, hasta el 30 de septiembre de 2029. Cubre las correcciones críticas y de seguridad, y cuesta más que el soporte normal.

    SIXE

    ¿Sigues en IBM i 7.4?

    Cuéntanos qué servidor tienes y qué aplicaciones corren encima, y te decimos qué camino tiene sentido: actualizar ya, pagar la extensión mientras tanto o cambiar de máquina.

    Hablar con SIXE WhatsApp
    Soporte, mantenimiento y formación de IBM i · sixe.es

    Qué es la IA soberana y por qué tener los datos en Europa no basta

    /en
    Ir a las preguntas frecuentes
    IA soberana · CLOUD Act

    Qué es la IA soberana y por qué tener los datos en Europa no bastaQué significa de verdad, qué es la CLOUD Act y cómo decidir dónde poner la IA de tu empresa según el dato que le vayas a dar.

    El 10 de junio de 2025, en el Senado francés, preguntaron bajo juramento al director jurídico de Microsoft Francia si podía garantizar que los datos que el Estado francés le confía nunca acabarían en manos del Gobierno de Estados Unidos sin permiso de Francia. «No, no puedo garantizarlo», respondió, y añadió que eso no había pasado nunca.

    Si tu empresa usa Copilot, ChatGPT o cualquier nube americana, la respuesta vale igual para tus datos.

    7.800millones de euros de AWS en su nube «soberana»
    192GB de GPU en un servidor con dos RTX PRO 6000

    Microsoft tiene centros de datos en Europa y, como se explicó en esa misma sesión, se compromete por contrato a que los datos de sus clientes europeos se queden en la Unión. Lo que no puede prometer es que nadie de fuera vaya a pedirlos, porque eso no depende de dónde esté el edificio, sino del país al que responde la empresa que lo gestiona.

    Qué es la IA soberana (y qué se vende como tal)

    La definición corta. Una IA es soberana cuando ninguna empresa ni ningún gobierno extranjero puede leer lo que le cuentas ni dejarte sin servicio. Suena sencillo, pero obliga a mirar cuatro cosas a la vez: dónde están los servidores, quién los maneja, a qué leyes responde la empresa propietaria y de quién es el modelo que usas.

    Lo que suele venderse. Casi todos los proveedores ofrecen ya que los datos se queden en Europa, y muchos lo llaman soberanía cuando en realidad es residencia. La diferencia importa el día en que un tribunal de otro país pide esos datos.

    La CLOUD Act, en cristiano

    Es una ley estadounidense de 2018 que obliga a las empresas de ese país a entregar los datos que controlan cuando se lo ordena su justicia, estén donde estén los servidores. En la práctica, un centro de datos de una empresa americana en Madrid o en Fráncfort queda a su alcance, y lo máximo que puede hacer el proveedor es recurrir la petición si la considera infundada. Es exactamente lo que defendió Microsoft ante los senadores franceses.

    Ojo, porque esto no convierte en ilegal usar ChatGPT, Copilot o Gemini con datos personales. El Marco de Privacidad de Datos entre la UE y Estados Unidos permite esas transferencias desde 2023 a las empresas adheridas, para las demás existen las cláusulas contractuales tipo, y el Tribunal General de la UE avaló el marco en septiembre de 2025, aunque el recurso sigue pendiente en el Tribunal de Justicia. Lo que una empresa tiene que preguntarse es qué pasaría si esos datos acabaran fuera, o si un día se quedara sin servicio.

    Lo de quedarse sin servicio ya ha pasado. En mayo de 2025, después de que Estados Unidos sancionara a la Corte Penal Internacional, su fiscal jefe se quedó sin acceso al correo de Microsoft que usaba. Microsoft niega haber suspendido sus servicios a la Corte y no ha explicado qué pasó con esa cuenta, pero la Corte tomó nota: en octubre de 2025 anunció que dejaba Office por una alternativa europea de código abierto, precisamente para depender menos de Estados Unidos.

    Tres caminos con la misma etiqueta

    Hoy se vende como «IA soberana» casi cualquier cosa que tenga un servidor en Europa, y debajo de esa etiqueta conviven tres opciones que se parecen poco.

    El gigante americano con región europea. Azure, AWS o Google Cloud con centros de datos aquí, e incluso sus versiones «soberanas», como la nube europea que AWS abrió en enero de 2026 en Alemania, operada solo por personal residente en la UE y con más de 7.800 millones de euros de inversión detrás. Es lo más cómodo y lo que da acceso a los modelos más potentes, pero la empresa matriz sigue siendo estadounidense.

    La nube de una empresa europea. OVHcloud, Scaleway o IONOS, donde además funcionan modelos europeos como los de Mistral. Si la empresa no tiene matriz en Estados Unidos, la CLOUD Act no la alcanza de forma directa, aunque conviene preguntar si tiene filiales allí. Francia ha ido un paso más allá con un sello oficial, SecNumCloud, que exige blindar el servicio frente a leyes de fuera de Europa, y lo tiene incluso una nube de Thales que funciona con tecnología de Google.

    Tus propios servidores. Un modelo de pesos abiertos (los que se pueden descargar e instalar) funcionando en máquinas de tu centro de datos, solas o dentro de una nube privada. Los hay muy buenos: Mistral, Llama, Qwen e incluso OpenAI, que publicó uno que cabe en una sola GPU de 80 GB. Nadie de fuera puede obligarte a entregar lo que pasa por ellos, apagarlos a distancia ni retirarte el modelo, porque una vez descargado es tuyo. A cambio, mantenerlos es cosa tuya.

    PreguntaGigante americano con región europeaNube de empresa europeaTus servidores
    ¿Los datos se quedan en Europa?Sí, si eliges la región y lo firma el contrato.Sí.Sí, en tu edificio.
    ¿Le alcanza la CLOUD Act?Sí, porque la empresa matriz es estadounidense.En principio no, salvo filiales en EE. UU.No.
    ¿Pueden cortarte el servicio desde fuera?Depende de las decisiones de la empresa y de su gobierno.Solo por motivos europeos o contractuales.No.
    ¿Quién lo mantiene?El proveedor.El proveedor.Tú o quien contrates.

    Qué camino necesita cada dato

    Montar servidores propios para que la IA traduzca la web es tirar el dinero, y mandar a un servicio americano los planos de un producto que aún no has lanzado es un riesgo que nadie en la empresa ha decidido asumir. Se falla en los dos sentidos, y lo sensato es clasificar antes los datos, y la clasificación suele salir bastante clara:

    • Textos de marketing, traducciones de la web o código sin nada sensible pueden ir a cualquier servicio de la nube, que suele ser el más capaz y el más barato.
    • Con los datos personales de clientes y empleados, la nube americana es legal con un buen contrato. Aun así, en sanidad, banca o administración pública compensa llevarlos a una nube europea, porque el riesgo de una petición de fuera baja mucho.
    • Y lo que no puede salir nunca (secretos industriales, I+D, contratos, datos clínicos, defensa) va en servidores propios o en una nube con el sello SecNumCloud o equivalente.

    La mayoría de las empresas acaba combinando: un modelo en casa para lo delicado y la nube para todo lo demás, el mismo reparto que contamos en por qué las empresas montan sus propios servidores de IA.

    Si eliges tus propios servidores

    Lo que decide el tamaño de la máquina es la memoria de las tarjetas gráficas (GPU): el modelo entero tiene que caber en ella y todavía sobrar sitio para atender a varias personas a la vez. Cuánto cuesta depende de tres cosas: cuánta gente la va a usar a la vez, qué tamaño de modelo necesitas y quién lo va a mantener. Para hacerse una idea con máquinas reales:

    • Para un departamento, un servidor de 2U con dos NVIDIA RTX PRO 6000 como el SYS-212GB-FNR suma 192 GB de memoria de GPU, más del doble de lo que pide el modelo abierto de OpenAI.
    • Para varios equipos a la vez o modelos más grandes, el SYS-422GA-NRT lleva cuatro tarjetas (384 GB) y su versión de ocho llega a 768 GB en 4U.
    • Y si antes quieres probar con un modelo pequeño, una workstation en torre como la SYS-C542i, preparada para una RTX de la serie 50, cabe debajo de una mesa.

    Es lo que montamos en nuestros proyectos de inferencia de IA en local, y la parte menos vistosa suele ser quién lo mantiene. Un servidor de IA necesita actualizaciones, copias de seguridad y alguien que vigile su consumo, y sin un equipo que lo haga, tener la IA en casa sale más caro de lo que parece. Con ese equipo, o con alguien que lo opere por ti, es el único camino en el que la soberanía no depende de lo que diga un contrato. Eso sí, tener el modelo en casa no lo protege de los ataques propios de la IA, que contamos en los diez riesgos de OWASP para LLM.

    Preguntas frecuentes

    ¿Qué es la IA soberana?

    Es una IA que funciona sin que ninguna empresa ni gobierno extranjero pueda acceder a los datos que le das ni cortarte el servicio. Exige controlar dónde están los servidores, quién los maneja y a qué leyes está sometida la empresa que los opera.

    ¿Es ilegal usar ChatGPT o Copilot con datos de clientes?

    No necesariamente. Enviar datos personales a Estados Unidos es legal con las garantías adecuadas, como el Marco de Privacidad de Datos de 2023 o las cláusulas contractuales tipo. Lo que conviene revisar es el contrato, el sector en el que trabajas y qué pasaría si esos datos acabaran en manos de una autoridad extranjera.

    ¿Una nube con servidores en Europa ya es soberana?

    Solo si la empresa que la opera no está sometida a leyes de fuera de Europa, como la CLOUD Act estadounidense. Tener los datos en Europa garantiza la residencia, pero no la soberanía.

    SIXE

    ¿Estás decidiendo dónde poner tu IA?

    Dinos qué datos quieres darle a la IA y cuánta gente la va a usar, y te decimos si te basta la nube o qué servidor de IA necesitarías.

    Hablar con SIXE WhatsApp
    Infraestructura y servicios de IA · sixe.es
    SIXE