Por qué los data centers para inferencia de IA NO deberían compartir site con tu ERP

Tu CFO aprobó presupuesto para una iniciativa de IA. Tu CIO compró GPUs para correr inferencia. Tu CTO instaló los servidores en el mismo data center donde corre tu ERP. Tres meses después tienes problemas: latencia impredecible en transacciones financieras, ruido eléctrico en la red que afecta la inferencia, y disputas entre equipos por presupuesto de cooling. La causa raíz: mezclar workloads de naturaleza completamente distinta en la misma infraestructura física.

Por qué los workloads son incompatibles

Un sistema ERP transaccional y un cluster de inferencia de IA tienen perfiles de operación fundamentalmente distintos. La diferencia importa porque afecta carga eléctrica, ruido eléctrico, perfil de red, ciclo de mantenimiento y SLAs.

Diferencias operativas concretas

Perfil de consumo eléctrico

Un servidor ERP típico consume 200-400W constante. Su consumo es predecible, sin picos importantes. Un servidor GPU para inferencia consume 1-3 kW constante pero tiene picos del 200-300% cuando llega un batch de preguntas. Esos picos propagan al UPS, al generador y al sistema de distribución eléctrica. Un ERP que comparte UPS con un cluster GPU ve esos picos como caídas de voltaje momentáneas — el tipo de cosa que genera errores de transacción sin disparar las alarmas tradicionales.

Perfil de ruido eléctrico y armónicos

Las fuentes de alimentación de GPU de alta densidad generan armónicos de corriente que degradan la calidad de la energía. Un cluster de 20-50 GPUs introduce distorsión armónica total (THD) del 8-15% en su circuito — el doble del estándar aceptable. Para motores de base de datos SQL y sistemas de storage sensibles, ese ruido eléctrico se traduce en latencia I/O impredecible y errores de checksum en operaciones críticas.

Perfil de red

La inferencia moderna usa tráfico este-oeste entre GPUs (tensor parallel, pipeline parallel). Una sola query de LLM puede generar 5-20 GB de tráfico entre nodos del cluster. Una red de 10 GbE convencional se satura. La respuesta típica es agregar uplinks de 25 o 100 GbE al cluster AI — pero eso consume capacidad del switch core que también sirve al ERP. El resultado: ambos sistemas ven latencia incrementada durante picos de inferencia.

El argumento comercial para separar

Más allá de los problemas técnicos, hay tres razones comerciales que justifican infraestructura separada:

1. SLA diferenciado. Un ERP corporativo necesita 99.95% de uptime con RTO de minutos. Una aplicación de inferencia típicamente tolera 99% con RTO de horas. Compartir infraestructura obliga a operar al estándar más estricto, lo que sube el costo total.
2. Seguridad y compliance. Los datos que alimentan un modelo de inferencia (documentos internos, código, datos de clientes) tienen clasificación de seguridad distinta a un ERP financiero. Mezclar ambos en el mismo segmento de red complica el cumplimiento de ISO 27001, SOC 2 o LFPDPPP.
3. Ciclos de mantenimiento. El cluster AI requiere actualizaciones de driver de GPU cada 2-4 semanas, mantenimiento del firmware de red más frecuente, y ventanas de mantenimiento coordinadas con el equipo de ML. El ERP solo se parchea una vez al mes con ventanas de cambio preaprobadas. Compartir equipo de operaciones lleva a conflictos de calendario que retrasan todo.

Cómo separar sin construir un DC nuevo

Hay tres niveles de separación, de menor a mayor costo:

1. Separación lógica. Segmentos de VLAN separados, firewalls entre ambos, priorización de tráfico con QoS. Costo bajo, beneficio moderado. No resuelve los problemas físicos de ruido eléctrico.
2. Separación física en el mismo data center. Rack rows dedicadas, PDUs separados, UPS dedicado o circuito derivado. Costo medio, resuelve los problemas de ruido eléctrico y permite mantener dos presupuestos operativos.
3. Sitio separado. Dos data centers en ubicaciones distintas (puede ser el mismo edificio en pisos diferentes, o edificio gemelo a 5 km). Costo alto, máxima independencia operativa. Útil cuando el workload AI tiene SLA distinto al del ERP.

Cómo diagnosticar si tu DC actual tiene el problema

Tres mediciones rápidas que te dicen si ya estás sufriendo este problema:

1. Medir la distorsión armónica (THD) en el circuito del ERP con un analizador de calidad de energía (Fluke 435, Dranetz PowerVisa o equivalente). Si THD supera 5%, ya tienes problema. Si supera 8%, el problema es severo.
2. Comparar la latencia P99 de tu base de datos SQL antes y después del despliegue de GPUs. Si la latencia P99 del ERP subió 20-50% después de instalar el cluster AI, la correlación es fuerte. La causa raíz es ruido eléctrico y contención de red.
3. Preguntar a tu equipo de finanzas cuántas conciliaciones manuales ha hecho en los últimos 3 meses. Si el número subió, probablemente estás teniendo errores de transacción por caídas de voltaje no detectadas.

Cuándo el costo de la separación es menor que el costo del problema

El umbral típico donde la separación física se justifica financieramente: cuando el costo mensual de los problemas (horas extra del equipo de operaciones, conciliaciones manuales, tiempo de respuesta a incidentes, horas de retraso en deployment) supera el costo mensual del capex de separación amortizado. Para un ERP mediano en México, ese umbral suele estar entre $80-150k MXN mensuales. Si tu CFO está firmando conciliaciones manuales cada semana, ya estás arriba del umbral.

Recomendación práctica

Si tienes menos de 10 racks totales o tu presupuesto es limitado, separación lógica con buena instrumentación puede ser suficiente para empezar. Si superas los 20 racks y la inferencia es un workload de producción, separación física en el mismo data center con PDUs y UPS dedicados vale la inversión. La separación de sitio (dos data centers separados) solo se justifica si el workload AI es crítico o tiene requisitos de compliance distintos. No mezcles cargas a menos que tengas instrumentación para medir latencia y ruido eléctrico en cada circuito.

Fuentes

1. NVIDIA — homepage — https://www.nvidia.com/en-us/data-center/
2. Uptime Institute — Tier Classification framework (resilient infrastructure) — https://uptimeinstitute.com/tier-certification
3. TIA-942 — Telecommunications Infrastructure Standard for Data Centers — https://www.tiaonline.org/
4. IEEE 1100 — homepage — https://www.ieee.org/