Cómo escoger servidores para IA

La primera pregunta que hay que responder antes de mirar un solo servidor es qué va a correr en él, porque inferencia y entrenamiento tienen perfiles de recurso casi opuestos. La inferencia se mide en latencia por respuesta y en peticiones concurrentes, tolera lotes pequeños y su restricción dominante es que el modelo quepa completo en la memoria del acelerador. El entrenamiento se mide en rendimiento agregado, vive de lotes grandes, necesita guardar gradientes y estados del optimizador además de los pesos, y a partir de cierto tamaño obliga a repartir el trabajo entre varias GPU y varios nodos.

Esa diferencia cambia todo lo demás. Un nodo de inferencia razonable puede ser un servidor de dos sockets con una o dos GPU de perfil medio, alimentación estándar y refrigeración por aire, instalado en un rack convencional. Un nodo de entrenamiento serio es un chasis con cuatro u ocho aceleradores, interconexión directa entre ellos, fuentes de varios kilovatios y requisitos térmicos que muchos centros de datos regionales no cumplen sin obra previa. Comprar el segundo cuando se necesitaba el primero es el error más caro de esta categoría, y es más común de lo que parece.

Hay además una tercera carga que casi nadie presupuesta: el preprocesamiento. Limpiar, normalizar, transcribir audio, extraer texto de documentos escaneados o generar representaciones vectoriales de un corpus consume mucha CPU, mucha memoria y mucho ancho de banda de almacenamiento, y no toca la GPU. En proyectos reales esa etapa suele ser el cuello de botella durante las primeras semanas. Conviene dimensionarla aparte y, con frecuencia, resolverla con servidores de cómputo general que se consiguen a muy buen costo en condición refurbished certificada.

En la práctica lo que descarta una GPU no son sus TFLOPS sino sus gigabytes. La cuenta base es simple: un modelo en precisión de dieciséis bits ocupa aproximadamente dos bytes por parámetro, así que un modelo de siete mil millones de parámetros necesita unos catorce gigabytes solo para los pesos, uno de trece mil millones unos veintiséis, y uno de setenta mil millones alrededor de ciento cuarenta. Cuantizar a ocho bits reduce eso a la mitad y a cuatro bits a la cuarta parte, con una pérdida de calidad que en muchas aplicaciones de negocio es aceptable y perfectamente medible.

A los pesos hay que sumarles la memoria de trabajo, y ahí se rompen los cálculos optimistas. En modelos de lenguaje, la caché de claves y valores crece con la longitud del contexto, el número de capas y la cantidad de peticiones simultáneas: atender veinte conversaciones largas a la vez puede pedir más memoria que el propio modelo. Si su caso es un asistente interno con contextos cortos, una GPU de veinticuatro gigabytes rinde mucho; si es un servicio que procesa documentos completos con alta concurrencia, la memoria pasa a ser el único criterio que realmente importa.

Para entrenamiento la cuenta se multiplica. Un ajuste completo con un optimizador de tipo Adam necesita, además de los pesos, los gradientes y dos estados por parámetro, lo que lleva el requisito al orden de dieciséis a veinte bytes por parámetro antes de contar activaciones. Ese mismo modelo de siete mil millones que cabía en una GPU para inferencia pide más de cien gigabytes para un ajuste completo. Por eso la mayoría de los proyectos regionales usan técnicas de ajuste de bajo rango, que reducen el requisito a algo manejable en una sola tarjeta.

Que un chasis admita aceleradores en la hoja de datos no significa que el suyo los admita. En servidores de rack la instalación depende de tres cosas que se piden por separado: el elevador PCIe correcto para el número de ranuras de doble ancho, un juego de fuentes con capacidad suficiente y un juego de ventiladores de alto rendimiento, además del cableado de alimentación auxiliar hacia la tarjeta. Un Dell PowerEdge R730 o un HPE ProLiant de la misma época aceptan aceleradores, pero solo con esa configuración específica, y es exactamente lo que hay que declarar en la solicitud de cotización.

Después viene la topología, que es lo que separa un servidor que funciona de uno que rinde. Cada acelerador quiere dieciséis líneas PCIe dedicadas; cuando se llenan las ranuras a través de conmutadores o se bifurca a ocho líneas, el ancho de banda hacia la memoria del sistema cae a la mitad y se nota en cargas que mueven muchos datos. Igual de importante es de qué socket cuelga cada dispositivo: si la tarjeta de red y la GPU están en complejos raíz distintos, el tráfico cruza la interconexión entre sockets y el acceso directo desde la red a la memoria de la GPU pierde buena parte de su ventaja.

Para un solo nodo con dos o cuatro tarjetas, PCIe es suficiente y es lo razonable. Cuando el trabajo exige que ocho aceleradores actúen como uno solo, con paralelismo de tensores dentro del nodo, la interconexión directa entre GPU deja de ser un lujo y pasa a ser el factor que determina si el nodo escala o se atasca comunicando. Ese salto cambia de plataforma, de consumo y de requisitos de sitio, así que conviene decidirlo con mediciones de la carga real y no por anticipación a un crecimiento que todavía no existe.

Aquí es donde se caen la mayoría de los proyectos, y siempre de la misma forma: se compra el cómputo y después se descubre que el sitio no puede alimentarlo. Las cifras son fáciles de estimar. Un acelerador de perfil bajo consume del orden de setenta vatios y se alimenta por la propia ranura; uno de gama media entre ciento cincuenta y trescientos cincuenta; los de gama alta llegan a setecientos por tarjeta. Ocho aceleradores de trescientos cincuenta vatios son dos coma ocho kilovatios solo en GPU, y con procesadores, memoria, discos y ventiladores el nodo completo se acerca a cuatro o cinco.

Compare eso con la realidad de los centros de datos regionales, donde la asignación habitual por rack está entre tres y seis kilovatios y superar diez sigue siendo excepcional. Un solo nodo denso puede consumir el rack entero, con lo cual el costo por unidad de rack deja de ser relevante y lo que se compra en realidad es potencia eléctrica. Antes de cotizar hay que confirmar tres números con el operador del sitio: kilovatios contratados por rack, tipo de circuito y tomas disponibles, y si la redundancia de alimentación está dimensionada para que una sola rama sostenga toda la carga.

El resto de la cadena eléctrica también cambia. Estos nodos usan fuentes de mayor capacidad que suelen exigir doscientos ocho o doscientos treinta voltios y tomas de tipo C19, no las C13 de un servidor común; la unidad de distribución debe soportar la corriente por circuito y no solo el total agregado; el sistema de respaldo tiene que cubrir el consumo nuevo con autonomía suficiente; y el generador, si existe, debe absorber el escalón de carga. Es una lista aburrida y es la que decide si el equipo enciende el día de la instalación.

La energía que entra sale como calor, y disiparlo es el segundo límite físico. Con aire y contención de pasillos bien ejecutada, un rack sostiene razonablemente entre diez y quince kilovatios; por encima de eso hay que ir a puertas traseras refrigeradas por agua o a refrigeración líquida directa al componente, que es una obra con implicaciones de instalación, mantenimiento y personal capacitado. No es una decisión de compra de servidores: es una decisión de infraestructura del sitio, y conviene tomarla antes de recibir los equipos y no cuando ya están en el andén.

Hay un factor que en América Latina pesa más que en casi cualquier otra región: la altitud. Bogotá está a unos dos mil seiscientos metros y Quito a unos dos mil ochocientos, y a esa altura el aire es menos denso y transporta menos calor. Los fabricantes lo reflejan reduciendo la temperatura ambiente máxima admitida a medida que se sube, típicamente alrededor de un grado por cada trescientos metros por encima de novecientos. En la práctica, un nodo denso certificado para treinta y cinco grados a nivel del mar tiene bastante menos margen en la sabana de Bogotá o en Quito.

Lo demás es disciplina de sala: pasillo frío y pasillo caliente bien separados, paneles ciegos en todas las unidades libres, sellado de los pasos de cable y verificación de que el caudal de aire disponible cubre lo que el chasis pide a plena carga. Un nodo de aceleradores se protege bajando su propio rendimiento cuando la temperatura sube, así que un problema térmico no se manifiesta como una alarma sino como un rendimiento que no coincide con lo prometido. Medir la temperatura de entrada por rack, y no solo la de la sala, evita esa discusión.

Conviene empezar por el caso más común, que es el que casi nadie discute: si el trabajo cabe en un solo nodo, la red entre nodos no importa. Para inferencia, veinticinco gigabits por servidor sobran en la inmensa mayoría de los despliegues, porque lo que viaja son peticiones y respuestas, no tensores. La red se vuelve crítica solo cuando el entrenamiento se reparte entre varios equipos y las operaciones de reducción colectiva pasan a dominar el tiempo de cada iteración. Ese es el umbral que hay que verificar antes de presupuestar una red cara.

Cuando ese umbral se cruza, hay dos caminos. RDMA sobre Ethernet convergente reutiliza el mismo ecosistema de switches que el resto del centro de datos y el mismo personal, a cambio de una configuración exigente: control de flujo por prioridad, notificación explícita de congestión y un control de congestión afinado, todo consistente de extremo a extremo. InfiniBand llega con menos trabajo de ajuste y un control de congestión propio, a costa de un ecosistema separado con su propia gestión, sus propios repuestos y su propia curva de aprendizaje para el equipo de operación.

Para clústeres pequeños, de dos a cuatro nodos, la recomendación honesta es Ethernet, y preferiblemente el mismo modelo de switch que ya opera en su centro de datos, porque el ahorro de complejidad supera la diferencia de rendimiento. A partir de ahí la decisión deja de ser técnica en abstracto y pasa a depender de con qué puede convivir su equipo de operación a las dos de la mañana. Lo que no funciona nunca es montar RDMA sobre una red configurada como red de oficina y esperar resultados de laboratorio.

El almacenamiento de un proyecto de IA se diseña en capas y casi nunca con una sola tecnología. Abajo está el repositorio del corpus, donde manda el costo por terabyte y sirve almacenamiento por objetos o un sistema de archivos en red sobre servidores de alta densidad de discos. Arriba está el espacio de trabajo local en NVMe, que es lo que realmente alimenta al acelerador durante el entrenamiento. Y en medio está el conjunto de datos ya preparado, que idealmente cabe entero en el disco local del nodo para no depender de la red en cada época.

La regla práctica de dimensionamiento es pensar en ancho de banda por acelerador y no en capacidad total. Cargas de visión con imágenes pequeñas pueden exigir uno o dos gigabytes por segundo por GPU; los modelos de lenguaje, que leen secuencias ya convertidas a unidades léxicas, piden bastante menos. El enemigo silencioso son los archivos pequeños: un corpus de millones de ficheros de pocos kilobytes hunde cualquier sistema de archivos en red por sobrecarga de metadatos. Empaquetar el conjunto en bloques secuenciales grandes suele multiplicar el rendimiento sin comprar nada.

Falta lo que casi nadie presupuesta: los puntos de control. Un entrenamiento serio escribe copias del estado del modelo con regularidad, y esas escrituras son grandes, sostenidas y ocurren mientras los aceleradores esperan. Reservar espacio, ancho de banda y una política de retención evita que el disco se llene a mitad de una corrida de varios días. Y conviene decidir desde el principio qué se respalda —el corpus, los puntos de control, los modelos entregados— porque no todo merece el mismo tratamiento ni el mismo costo por terabyte.

La parte incómoda de esta guía: en una fracción importante de los proyectos que llegan a cotización, el hardware correcto no es un servidor de aceleradores. Clasificación de tickets, extracción de datos de facturas, detección de fraude, motores de recomendación, previsión de demanda, buena parte de la analítica y muchos modelos de visión ya entrenados corren perfectamente en procesadores modernos con bibliotecas optimizadas, sobre servidores de cómputo general disponibles en condición refurbished certificada. Comprar aceleradores para esas cargas es gastar en capacidad que quedará ociosa la mayor parte del tiempo.

Del mismo modo, entrenar un modelo grande desde cero casi nunca se justifica para un operador o una empresa de la región. Lo que sí se justifica es el ajuste fino sobre un modelo abierto ya entrenado, que en muchos casos cabe en una sola GPU de gama media usando métodos de bajo rango. Y cuando hace falta más, alquilar cómputo por horas para una campaña de entrenamiento concreta suele ser mejor decisión financiera que inmovilizar capital en aceleradores que se usarán unas pocas semanas al año y quedarán obsoletos antes de amortizarse.

Entonces, qué justifica cómputo propio. Tres razones concretas y verificables: datos que por regulación o por política interna no pueden salir del país o de la empresa; volumen de inferencia sostenido, donde el costo recurrente en la nube supera al de amortizar hardware; y latencia, porque el trayecto hacia los grandes proveedores desde varias ciudades de la región agrega decenas de milisegundos que en aplicaciones interactivas se notan. Si su caso encaja en alguna de las tres, la inversión se sostiene. Si no encaja en ninguna, conviene revisar el plan antes de comprar.