Planificación de direcciones IP para aplicaciones de IA

Planificar direcciones IP se ha vuelto una tarea crítica para cualquier organización que despliegue cargas de trabajo de IA. Y no exagero: entrenar modelos, servir inferencias a escala y orquestar clústeres de GPU genera una demanda de IPv4 que pocos equipos de red vieron venir hace cinco años. En este artículo repasamos por qué la IA dispara el consumo de espacio de direccionamiento, cómo dimensionar subredes según la arquitectura que elijas y qué prácticas conviene aplicar para que tu plan no se quede corto a los seis meses de vida del proyecto. Porque pasa, y más de lo que parece.

Por qué la IA multiplica el consumo de direcciones IPv4

Un clúster tradicional de servidores web podía tirar años con un par de bloques /24. Un entorno de IA rompe ese esquema, y lo hace por tres razones bien concretas:

• Densidad de pods y contenedores: en Kubernetes, cada pod consume una IP del rango del CNI. Un job de entrenamiento con 500 pods y sidecars duplica esa cifra con facilidad.
• Nodos efímeros: los clústeres de GPU se escalan y reducen constantemente. Las IP se liberan, sí, pero el pool hay que dimensionarlo para el pico, no para la media. Ahí está la trampa.
• Servicios de tipo LoadBalancer: cada punto de entrada de inferencia (API de modelos, endpoints de batch, webhooks) suele requerir una IP pública o, como mínimo, una IP virtual interna.

A esto se suma el transporte: si publicas modelos vía proxies o balanceadores, cada región de despliegue necesita su propio rango enrutable. El resultado es llamativo. Un equipo que gestionaba 512 direcciones puede necesitar hoy 4.096 o más sin que la empresa haya crecido ni un solo empleado.

Dimensionamiento de subredes: de /24 a /20 según arquitectura

¿Cuánto espacio necesitas? Depende del patrón de despliegue. Como referencia práctica:

1. Inferencia ligera en un único clúster: un /24 (256 direcciones) puede bastar si separas pods y servicios en rangos distintos. Realista solo para pilotos, eso sí.
2. Entrenamiento distribuido: los jobs AllReduce generan comunicación intensa entre todos los nodos. Un /22 o /23 por clúster evita cuellos de botella de direccionamiento y simplifica las reglas de security groups.
3. Plataforma multi-tenant de ML: varios clústeres, entornos de staging, pipelines de datos… en este escenario un /20 (4.096 direcciones) es el punto de partida sensato.

Dos consejos accionables. Primero, reserva siempre al menos un 30 % del rango como colchón para picos de escalado. Segundo, evita CIDR que colisionen con rangos de VPC de proveedores cloud (el 172.17.0.0/16 de Docker por defecto, por ejemplo), porque te obligarán a rediseñar más adelante. Y créeme: rediseñar direccionamiento en producción no es divertido.

Planificación de direcciones IP: buenas prácticas para no quedarte corto

Una planificación sólida se apoya en cuatro pilares:

• Documentar el mapa de asignaciones: qué rango va a cada clúster, entorno y región, con propietario y fecha de asignación. Sin esto, todo lo demás se tambalea.
• Jerarquizar por función: bloques contiguos para entrenamiento, inferencia, gestión y datos. Facilita el firewalling y el troubleshooting.
• Prever el agotamiento: si tu /20 supera el 70 % de consumo, empieza a tramitar espacio adicional antes de necesitarlo. Una transferencia IPv4 lleva semanas; el agotamiento llega antes de lo que esperas.
• Complementar con IPv6 y CGNAT: para tráfico de salida masivo (scraping de datasets, descarga de repositorios), el CGNAT sobre un pool propio reduce la presión sobre las IP públicas dedicadas.

Si tu organización necesita ampliar espacio, tener un prefijo /24 o mayor con documentación limpia en el RIR correspondiente y LOA en regla es imprescindible para anunciarlo vía BGP o integrarlo mediante BYOIP en tu proveedor cloud. Plataformas como IP4 Market facilitan esa gestión al concentrar vendedores verificados y precios competitivos, con la trazabilidad necesaria para que tu plan de direcciones crezca al ritmo de tus proyectos de IA.

IPv4 frente a IPv6 en clústeres de entrenamiento e inferencia

Dentro de un clúster de entrenamiento de GPU, el tráfico que manda es Este-Oeste: all-gather, sincronización de gradientes y checkpoints moviéndose entre nodos a 100-400 Gbps. Para ese tráfico interno, da igual si las direcciones son IPv4 o IPv6; el rendimiento apenas nota la diferencia. El asunto se juega en el plano de gestión y en la exposición de servicios. Ahí sí que importa cómo has planificado tus direcciones:

• Tráfico interno: rangos privados RFC 1918 (o IPv6 ULA si el tamaño lo exige). Un /16 para nodos de cómputo y un /20 para almacenamiento suele bastar, incluso con clústeres de miles de GPUs. Y evita NAT dentro del tejido de entrenamiento. Añade latencia y complica el debugging de NCCL, que ya es suficientemente difícil de depurar por sí solo.
• Exposición de endpoints de inferencia: aquí IPv4 sigue siendo imprescindible. Muchos clientes corporativos, SDK legacy y balanceadores en tránsito aún solo resuelven registros A. Si tu API de inferencia tiene que ser alcanzable desde internet, necesitas direcciones IPv4 públicas anunciadas vía BGP. No hay vuelta atrás, al menos de momento.
• Dual-stack como estrategia por defecto: publica AAAA y A a la vez. IPv6 alivia la presión sobre tu pool IPv4 (menos CGNAT, menos NAT44 en el edge), pero ojo: no lo elimina.

Un consejo práctico que me ha ahorrado más de un dolor de cabeza: reserva bloques /24 alineados con fronteras geográficas o funcionales. Un /24 para inferencia en Europa, otro para Latinoamérica. Cuando llegue el momento de montar anycast, aplicar políticas de filtrado o hacer anuncios BGP parciales, lo agradecerás.

Comprar, arrendar o BYOIP: cómo conseguir espacio IPv4 de forma segura (LOA, RPKI/ROA)

El mercado IPv4 sigue siendo escaso. Los precios de referencia se mueven habitualmente entre 25 y 45 USD por dirección en compra directa (depende del bloque y del RIR), mientras que el arrendamiento ronda los 0,10-0,40 USD por IP y mes. Para un despliegue de IA con necesidades crecientes, tienes tres vías:

1. Compra: la opción sólida si tu plataforma de IA es un activo a largo plazo. Pero verifica que el bloque esté limpio: sin listados en DNSBL, sin conflictos en la base de datos del RIR (RIPE NCC, ARIN, LACNIC) y con una historia de routing razonable. Exige contrato de transferencia y revisa la documentación de titularidad. Con lupa.
2. Arrendamiento: ideal para picos de capacidad, despliegues regionales temporales o un PoC de inferencia. Asegúrate de que el contrato incluya un LOA (Letter of Authorization) que te permita anunciar el prefijo desde tu propio ASN. Sin ese papel, poco has comprado.
3. BYOIP: si trabajas con AWS, GCP o Azure, BYOIP te permite llevar tu propio rango IPv4 al cloud conservando la propiedad y la reputación del bloque. Esto último es crítico: evita listas negras heredadas y problemas de deliverability. Requiere un ROA en el RIR que autorice al ASN del cloud, además del LOA correspondiente.

En cualquier escenario, activa RPKI desde el primer día. Crea un ROA con maxlen ajustado (por ejemplo, /24 exacto para un /24) y firma tus anuncios. Un prefijo sin ROA válido queda expuesto a secuestro de ruta y a un filtrado más agresivo por parte de los grandes operadores. Y antes de cerrar cualquier operación, revisa la reputación histórica del bloque en bases como Spamhaus o SORBS: heredar un rango contaminado degrada la confianza en tus endpoints de IA antes incluso de escribir la primera línea de tráfico.

Conclusiones: una red preparada para escalar sin fricciones

Planificar direcciones IP para cargas de IA no es un trámite administrativo. Es una decisión de arquitectura. Un modelo jerárquico y segmentado (gestión, cómputo, almacenamiento, inferencia), dual-stack por defecto y con bloques /24 alineados con fronteras de anuncio te ahorra renumeraciones costosas cuando el clúster duplique su tamaño. Y lo hará, casi seguro.

Tres recomendaciones para llevar a la práctica:

• Documenta y automatiza: gestiona el plan con IPAM y aprovisiona direcciones vía IaC (Terraform, NetBox como fuente de verdad). La gestión manual de direcciones no escala. Punto.
• Asegura la propiedad: compra o arrienda con contratos claros, LOA en regla y ROA/RPKI activos antes del primer anuncio BGP.
• Planifica con holgura: dimensiona los bloques pensando en un crecimiento a 3-5 años, no en la carga actual. La carga actual es lo de menos.

Con un espacio IPv4 propio y bien gobernado, tus endpoints de inferencia mantienen reputación, tus anuncios BGP son estables y la infraestructura de IA crece al ritmo del negocio. Sin fricciones de red, sin sorpresas de última hora cada vez que despliegues una región nueva.