Resumen

  • Una nube de GPU vende tres cosas separables —un acelerador, una máquina anfitriona que lo alimenta y una ruta de red que hace entrar y salir el trabajo— y las factura con una sola cifra. El expediente público de Genesis Cloud documenta la tercera capa y deja las dos primeras en buena medida ilegibles.
  • La herramienta de enrutamiento de Hurricane Electric registra AS209045 a nombre de Genesis Cloud Limited, país de origen Malta, con dos prefijos IPv6 anunciados y ningún prefijo IPv4, y pares IPv6 observados en euNetworks y OVH.
  • Una lectura resumida de esa misma página, capturada el 18 de octubre de 2026, indica que el ASN no ha sido visible en la tabla de enrutamiento global desde el 16 de abril de 2026. El expediente no dice por qué.
  • La mecánica de facturación del sector explica la brecha: la capacidad se aprovisiona por instancia pero se anuncia por hora-GPU, la salida de datos se mide aparte por volumen, y el rendimiento multi-GPU depende de la topología de interconexión mucho más que del modelo de acelerador.

La cifra que se compara

Toda conversación sobre cómputo para inteligencia artificial empieza por una cifra que parece un precio y se comporta como un eslogan: el dólar por hora-GPU. Es la cifra que aparece en las hojas de cálculo de compras, en las tablas comparativas que circulan por canales internos y en la diapositiva que un equipo financiero prepara cuando quiere saber si un programa de entrenamiento es financiable.

También es la cifra que responde a la pregunta menos interesante de la sala. Una hora-GPU indica cuánto cuesta ocupar un acelerador durante sesenta minutos. No indica cuánto cuesta su trabajo, porque su trabajo no es un acelerador inmóvil. Su trabajo es una secuencia de operaciones en la que un acelerador espera el ancho de banda de memoria de un anfitrión, una ruta de almacenamiento, un salto de red y la interconexión que permite que varios aceleradores se comporten como una máquina más grande. La unidad facturada y la unidad entregada son objetos distintos, y la brecha entre ambas es exactamente donde vive el riesgo de compra.

Esa brecha suele describirse como un asunto de opacidad de los proveedores. Se entiende mejor como un problema de capas separables que se presentan como si estuvieran fundidas. Una nube de GPU no vende una GPU. Vende un acelerador, más un anfitrión, más una ruta, y la hoja de precios es una cifra única que cubre las tres, con la composición dejada a la imaginación del comprador.

Este artículo toma el expediente público de un operador y plantea una pregunta estrecha: cuál de las tres capas puede verificarse realmente con documentos al alcance de un comprador, y cuáles se aceptan por confianza. El operador es la sociedad inscrita en el directorio de BTW bajo el nombre Genesis Cloud Routing, Peering and DNS, proveedor de nube de GPU cuya identidad de enrutamiento resulta estar mucho mejor documentada que su producto de cómputo.

Tres capas, tres estados de prueba

Separar las capas no es un recurso retórico. Cambia lo que cuenta como prueba.

La capa de acelerador pertenece al marketing. Se describe con nombres de producto, tamaños de memoria y promesas generacionales, y es la capa que los compradores creen estar comparando. Para este operador no pudo leerse: la página de precios, las condiciones del servicio y las páginas de instancias GPU no devolvieron texto extraíble en los intentos realizados los días 17 y 18 de octubre de 2026. Queda la autodescripción de la empresa como proveedor de infraestructura en la nube especializado en aceleración GPU, y una ficha de base de datos corporativa que la registra como organización privada del mercado de nube de GPU. Ninguna de las dos establece un catálogo de aceleradores.

La capa de anfitrión es la que casi nadie documenta. Abarca el equilibrio entre procesador y GPU, la memoria del sistema por acelerador, el rendimiento del almacenamiento local y la política de planificación que decide si su instancia comparte máquina con un vecino cuya carga satura el mismo bus de memoria. No es información exótica; los grandes proveedores la publican. Pero es la capa donde la capacidad barata se vuelve barata, y es la capa que ningún documento público de este expediente aborda.

La capa de red resultó ser la documentada, no porque el operador la publicara, sino porque el enrutamiento de Internet es un hecho público por construcción. Los registros y las herramientas de enrutamiento anotan quién posee un número de sistema autónomo, qué espacio de direcciones anuncia y con quién se interconecta. Ese expediente existe quiera la empresa o no, y para este sujeto es la única capa donde puede citarse un documento en lugar de repetirse una afirmación.

Tres capas, entonces, en tres estados: proclamada, ausente y documentada. La pregunta interesante no es que las dos primeras sean delgadas. Es que la tercera lo sea de una manera concreta y medible, y que esa delgadez sea invisible para quien solo lee la página de producto.

Qué mide en realidad una hora-GPU

La mecánica de facturación de la nube de GPU no es secreta. Simplemente no está resumida en la hoja de precios.

La capacidad se aprovisiona como instancia —una máquina virtual con una porción definida de un anfitrión físico— mientras se cotiza y se compara como un importe por hora-GPU. Las dos unidades no son la misma. Como expone una nota explicativa del sector sobre facturación de nube de GPU, los proveedores facturan a nivel de instancia incluso cuando los costes se calculan y se anuncian por hora-GPU, y la granularidad de esa facturación varía según el proveedor, del segundo al minuto y a la hora (nota explicativa sobre facturación de nube de GPU). La granularidad suena a detalle contable hasta que se encadenan muchos trabajos cortos: un proveedor que redondea a la hora y otro que redondea al segundo pueden diferir en un múltiplo importante sobre la misma carga, con una tarifa de cabecera idéntica.

La misma fuente señala el segundo rasgo estructural: los precios bajo demanda y los reservados divergen con fuerza, y la reserva convierte un coste variable en un compromiso cuyo valor depende de una utilización que el comprador debe prever. Es una decisión de financiación disfrazada de descuento.

El tercer rasgo es el que más a menudo descarrila un presupuesto después de los hechos. El ancho de banda de salida se factura con frecuencia por separado, medido por el volumen de datos que abandonan la red del proveedor, y en cargas de IA de alto rendimiento puede alterar de forma sustancial el coste total de propiedad. Un precio por hora-GPU no contiene ninguna salida de datos. Un punto de control de modelo escrito cada noche, un conjunto de datos releído en cada época, un corpus de entrenamiento replicado entre regiones: cada uno añade una línea que la hoja de precios nunca mostró.

Reúna esos tres elementos y la aritmética de un trabajo terminado ya no se parece en nada a la aritmética de una hora de acelerador. El coste por trabajo es función del tiempo de acelerador, el equilibrio del anfitrión, la ruta de almacenamiento, la eficiencia de la interconexión, el volumen de salida y las cláusulas de interrupción. La cifra anunciada cubre el primer término y hace un gesto hacia los demás.

La topología es un término de rendimiento, no una especificación

Si hay un hecho técnico que desmonta la idea de la hora-GPU como unidad de trabajo, es este: el rendimiento multi-GPU lo gobierna la forma en que los aceleradores se comunican entre sí.

La documentación técnica de NVIDIA es directa al respecto. NVLink proporciona una interconexión directa de alta velocidad que evita los límites del bus PCIe para el acceso a memoria de GPU a GPU, y las cargas de entrenamiento de alto rendimiento se apoyan en ella para evitar cuellos de botella de comunicación durante la sincronización de gradientes entre varias GPU (NVIDIA sobre NVLink y la eficiencia del entrenamiento multi-GPU). Cuando los aceleradores se conectan en su lugar por PCIe, la interconexión pasa a ser la restricción, y los aceleradores pasan sus horas facturadas esperando.

La guía de facturación del sector formula el mismo punto desde el lado comercial: el rendimiento multi-GPU depende en gran medida de la topología de interconexión, con NVLink ofreciendo comunicación GPU a GPU de alto ancho de banda y baja latencia frente al PCIe estándar, e InfiniBand desplegándose habitualmente para la comunicación rápida entre nodos en clústeres de cálculo intensivo.

Esto importa porque la topología de interconexión no es una propiedad del acelerador. Dos proveedores pueden anunciar el mismo modelo de acelerador a la misma tarifa horaria y entregar rendimientos radicalmente distintos en un trabajo multi-GPU, porque uno ha cableado ocho dispositivos en una fábrica coherente y el otro no. El comprador que compara dólares por hora-GPU compara una constante con una variable. Eso no es una comparación de precios; es un error de categoría con un proceso de compras adjunto.

Hay una consecuencia de segundo orden que rara vez aparece en los comparativos. La topología determina cómo escala una carga, y el escalado determina cuántos aceleradores hay que alquilar para terminar en un tiempo de reloj dado. Una configuración mal interconectada puede consumir más horas-GPU para completar el mismo trabajo. La tarifa horaria más barata cuesta entonces más por trabajo, y la factura que llega parece un fallo de previsión en lugar de lo que es: la compra de la unidad equivocada.

Qué dice realmente AS209045

Frente a esa niebla comercial, el expediente de enrutamiento es casi sorprendentemente concreto.

La herramienta de enrutamiento de Hurricane Electric, que publica relaciones entre números de sistema autónomo, prefijos y titulares, registra AS209045 a nombre de Genesis Cloud Limited, con país de origen Malta y dos prefijos anunciados en total (ficha AS209045 en la herramienta de enrutamiento de Hurricane Electric). El extracto literal del expediente dice:

AS209045 Genesis Cloud Limited

Country of Origin: Malta

Prefixes Originated (all): 2

AS209045 IPv6 Peers — AS13237 AS16276 — AS16276 OVH SAS, AS13237 euNetworks GmbH

Prefix Description 2a09:7000::/31 Genesis Cloud LIR Admin; 2a09:7007::/36 Genesis Cloud LIR Admin

De ahí se siguen directamente tres hechos, y cada uno es comprobable por cualquiera con un navegador.

Primero, el nombre del titular en el expediente de enrutamiento es un nombre con forma jurídica —Genesis Cloud Limited— con una jurisdicción concreta: Malta. Es un tipo de afirmación distinto de la etiqueta descriptiva bajo la que la empresa aparece en un directorio. Es una declaración de registro, hecha en un sistema diseñado exactamente para eso.

Segundo, el espacio de direcciones anunciado son dos prefijos IPv6 y nada más. No aparece ningún prefijo IPv4 en el expediente. Ambos prefijos llevan la descripción «Genesis Cloud LIR Admin», que apunta a una administración de registro local de Internet más que a un rango de servicio orientado a clientes.

Tercero, los pares IPv6 observados son dos operadores europeos bien conocidos: euNetworks, proveedor de fibra y conectividad de centros de datos, y OVH, el grupo francés de alojamiento y nube. Una observación de dos pares es una porción estrecha de una tabla de enrutamiento, no una topología completa, pero dice al comprador algo que una hoja de precios nunca dirá: que esta ruta de red se ancla en infraestructura de operadores y alojamiento europeos en lugar de en una red troncal mundial propia.

Dos prefijos y ningún IPv4

Vale la pena detenerse en lo pequeña que es esa huella, porque el tamaño aquí no es un insulto. Es una medición.

Un sistema autónomo que anuncia dos prefijos IPv6 y ningún espacio IPv4 no gestiona un patrimonio amplio de direcciones públicas. No anuncia miles de rutas a la tabla global. Es un registro estrecho, coherente con un operador que llega a sus clientes a través de redes ajenas, con relaciones de tránsito e interconexión haciendo el trabajo que de otro modo haría una gran huella autoanunciada.

Es una forma perfectamente corriente de operar una nube. La mayoría de los proveedores no anuncian el tráfico de sus clientes como propio; compran tránsito y se interconectan en puntos de intercambio, y su número de sistema autónomo transporta tráfico de gestión y borde en lugar de la suma de su actividad comercial. El error sería leer el número de sistema autónomo como una medida de la huella de cómputo. No lo es, y este artículo no lo hace.

Pero la misma observación corta en sentido contrario para el comprador. Si la ruta de red es estrecha y está en buena medida externalizada hacia relaciones con operadores, entonces los determinantes del coste de red de un trabajo —dónde se factura la salida, qué rutas se toman, cómo llega el tráfico al cliente— residen en condiciones comerciales y no en un expediente de enrutamiento público. El expediente de enrutamiento dice que la ruta existe y aproximadamente dónde aterriza. No dice cuánto cuesta cruzarla.

Y esa es precisamente la asimetría que este artículo quería someter a prueba. La capa documentada públicamente es la que menos pesa en el precio de un trabajo terminado. Las capas que dominan el precio —el equilibrio del anfitrión y las condiciones de salida— son las que no tienen ningún documento público.

La cuestión del retiro

La línea más cargada de consecuencias del expediente es también la que exige más cuidado.

La lectura resumida de esa misma página de herramienta, capturada el 18 de octubre de 2026, indica que AS209045 no ha sido visible en la tabla de enrutamiento global desde el 16 de abril de 2026. Es una afirmación sobre visibilidad, no sobre intención. Un registro puede persistir mientras los anuncios se detienen, y las razones de tal detención son numerosas y en su mayoría mundanas: una renumeración, una migración a otro tránsito, un cambio de proveedor, un periodo de reestructuración interna o una decisión operativa de dejar de anunciar un espacio que ya no se usa.

El expediente no establece cuál de estas explicaciones se aplica. Lo que sí establece es la forma de la cosa que un comprador nunca vería desde el lado del producto. Una empresa puede seguir presentando una oferta de nube de GPU mientras la presencia de enrutamiento pública asociada a su nombre de red registrado se queda en silencio durante seis meses. Nada de eso es necesariamente incorrecto. Pero los dos hechos no están conectados en ningún documento que un comprador sea probablemente a leer, y esa conexión es exactamente el tipo de cosa que un proceso de diligencia técnica se supone que produce.

También da al artículo su ilustración más clara de la tesis. La ruta de red no es un atributo permanente de un proveedor; es un estado operativo vivo que puede cambiar sin ninguna modificación correspondiente en una hoja de precios, una página de marketing o una conversación de ventas. Si el modelo de coste de un comprador depende de dónde aterriza el tráfico y de cómo llega allí, entonces un cambio en la visibilidad de los anuncios es un hecho material, y aparece en una herramienta de enrutamiento, no en las condiciones de un proveedor.

El nombre en la ficha y el nombre en el registro

La ficha de directorio de este sujeto está archivada bajo un nombre descriptivo: Genesis Cloud Routing, Peering and DNS. Ese nombre es una etiqueta útil. No es una identidad jurídica, y no es lo que dice el expediente de enrutamiento.

El expediente de enrutamiento dice Genesis Cloud Limited. Los metadatos de la ficha de directorio admiten ellos mismos la brecha: su rol conocido es el genérico «operador de infraestructura de red», su única base de prueba citada es una consulta RDAP de autnum para AS209045, y sus lagunas declaradas enumeran como no verificados el país de la entidad jurídica, los servicios actuales, los activos visibles, los vínculos de matriz o filial y los contactos públicos de dirección responsables. La ficha se publicó automáticamente.

Una etiqueta descriptiva de directorio y un nombre de titular en el registro son dos tipos distintos de afirmación, y el espacio entre ambos es donde las identidades se suponen en lugar de establecerse. «Genesis Cloud» aparece en el expediente de enrutamiento, en la presencia web de la propia empresa y en una ficha de base de datos corporativa que la registra como organización privada del mercado de nube de GPU (perfil de Genesis Cloud en Crunchbase). Es un patrón coherente, y la coherencia no es confirmación: ningún documento obtenido para este artículo establece la relación societaria entre el negocio de nube de GPU y el titular de AS209045 más allá del nombre compartido y de la mención de administración de registro local en los prefijos.

Para un artículo sobre verificabilidad, esa distinción no es pedantería. Es todo el asunto. La capa que parecía más sólida —una empresa nombrada en un registro— resulta sólida sobre un nombre y silenciosa sobre la entidad comercial que lo sostiene. El producto de cómputo, mientras tanto, se describe en primera persona por un sitio web que no pudo leerse.

Qué no pudo leerse, y cuándo

Una frontera fechada es más útil que una impresión vaga, así que aquí está completa. Todo lo siguiente se intentó y falló entre el 17 y el 18 de octubre de 2026.

El expediente de registro sobre el que descansa la identidad del directorio. La consulta RDAP de autnum para AS209045, citada por la ficha de directorio como su única base de prueba, no devolvió ningún candidato de origen (la consulta RDAP citada por la ficha de directorio). El texto del registro —titular, país, identificadores de contacto, observaciones— no se ha leído, por tanto, en el curso de este trabajo. Lo que este artículo sabe del titular del ASN proviene de una base de enrutamiento de terceros, no del registro.

El producto y las condiciones comerciales del operador. Los intentos de acceder al sitio principal, a la página de precios, a las condiciones del servicio y a las páginas de instancias GPU no devolvieron texto extraíble (sitio de Genesis Cloud; el mismo sitio en www). Ningún modelo de acelerador, configuración de memoria, especificación de anfitrión, detalle de interconexión, granularidad de facturación, tarifa de salida, crédito de servicio o cláusula de interrupción quedan establecidos en este artículo.

Política de interconexión y presencia en puntos de intercambio. La ficha de PeeringDB de AS209045 tenía acceso restringido en la consulta, de modo que la política de interconexión publicada, la presencia en puntos de intercambio, los ratios de tráfico y la postura abierta o selectiva no pudieron extraerse (ficha AS209045 en PeeringDB).

Corroboración independiente de los hechos de enrutamiento. La vista de bgp.tools sobre el mismo ASN también tenía acceso restringido, y la página de estado de RIPEstat no contenía texto descriptivo de titular ni de enrutamiento (vista AS209045 en bgp.tools; página de RIPEstat para AS209045). Los hechos de prefijos y pares descansan, por tanto, en una única fuente de terceros. Son literales y comprobables, pero no están doblemente contrastados en este expediente.

Rendimiento medido. No se encontró ninguna medición independiente de rendimiento sostenido para ninguna instancia de Genesis Cloud. Ninguna cifra de tokens por segundo, ninguna curva de escalado multi-nodo, ningún rendimiento de almacenamiento, ningún coste real de finalización de trabajo.

Esa es la frontera. Es amplia, está fechada y es asimétrica: la capa con infraestructura pública —el enrutamiento— está documentada; las capas con contenido comercial —catálogo, condiciones, salida, rendimiento— no lo están.

Por qué la ausencia es el tema y no el escándalo

Sería fácil, y equivocado, escribir esto como la historia de una empresa que esconde cosas. Nada en el expediente lo sostiene. Las páginas fallan por razones que no tienen que ver con la intención: protección contra robots, bloqueo regional, renderizado dependiente de scripts, un sitio detrás de un desafío que una recuperación automatizada no puede superar. Una hoja de precios publicada tampoco es una obligación legal para una sociedad privada que vende a empresas por venta directa.

Lo que el expediente sostiene es una observación estructural sobre el mercado de nube de GPU en su conjunto. La información que un comprador necesita para presupuestar un trabajo no es la información que el mercado hace comparable. Las horas-GPU anunciadas son comparables entre proveedores precisamente porque están despojadas del equilibrio del anfitrión, la interconexión, la salida y las cláusulas de interrupción. Esos términos se negocian, se cotizan o se entierran en un anexo. La única cifra comparable es, por tanto, la que no determina el coste, y las cifras que sí lo determinan son las que no pueden compararse.

Un mercado que funciona así no produce compradores irracionales. Produce compradores que optimizan la variable visible y luego descubren en la factura que estaban optimizando un sustituto. El correctivo no es la indignación. Es un proceso de compra que exige las otras capas por escrito: especificaciones a nivel de instancia, topología de interconexión, tarifas de salida, cláusulas de interrupción y crédito, y una medición sobre la carga del propio comprador en lugar de sobre un gráfico del proveedor.

Qué puede hacer un comprador con tres capas

Si una nube de GPU son tres compras, la diligencia debida tiene tres partes, y pueden especificarse.

Para la capa de acelerador, las preguntas útiles son aburridas y contestables: qué generaciones de dispositivo se ofrecen, cuánta memoria por instancia y cuál es la relación entre acelerador, procesador anfitrión y memoria del sistema. Esa última relación es la que decide si el acelerador se alimenta o se muere de hambre, y es la que más a menudo se omite.

Para la capa de anfitrión, pida el modelo de planificación y la garantía de tenencia. ¿Está una instancia dada en un anfitrión dedicado o compartido? ¿Qué ocurre cuando un coinquilino satura el ancho de banda de memoria? ¿Cuál es el rendimiento del almacenamiento local y está conectado por red? Estas preguntas tienen respuesta, y un proveedor incapaz de responderlas le está diciendo algo.

Para la capa de red, las preguntas son las que el expediente de enrutamiento no puede responder: cuál es la tarifa de salida por gigabyte, si se factura la entrada, si existe un descuento por volumen comprometido y dónde abandona físicamente el tráfico la red del proveedor. Un comprador que hace estas tres preguntas antes de firmar aprende más sobre el coste entregado que lo que jamás le revelará una comparación de tarifas de cabecera.

Y para las tres, el control más barato es una medición sobre su propia carga, ejecutada antes del compromiso, con la factura contrastada contra la medición y no contra la hoja de precios.

Qué cambiaría este relato

Las conclusiones aquí están acotadas por la recuperación, no por la conducta, y se moverían si cualquiera de los siguientes elementos estuviera disponible.

Un expediente RDAP de autnum legible que nombrara al mismo titular, con identificadores de contacto y observaciones, movería la identidad del ASN de la atribución de terceros al hecho de registro. Una hoja de precios y unas condiciones del servicio publicadas moverían las capas de acelerador y salida de la frontera a la prueba. Una ficha de PeeringDB que enunciara la política de interconexión y la presencia en puntos de intercambio corroboraría o complicaría la observación de dos pares.

Una medición independiente de rendimiento sostenido pondría a prueba si la interconexión detrás de esta oferta puede soportar una carga multi-GPU al ritmo que un comprador necesitaría. Cualquiera de esos elementos bastaría para desplazar el centro de gravedad del artículo, y todos son el tipo de documento que un proveedor serio de este mercado acaba publicando.

Hasta entonces, la afirmación honesta es la más estrecha: la capa de enrutamiento está documentada, las capas de cómputo no, y la brecha entre ambas es donde descansa actualmente el modelo de coste de un comprador.

La unidad que un comprador debería presupuestar

Una hora-GPU es una unidad de ocupación. Un trabajo terminado es una unidad de trabajo. Todo lo que determina la segunda —equilibrio del anfitrión, interconexión, ruta de almacenamiento, salida, cláusulas de interrupción— queda fuera de la primera, y un mercado que solo cotiza la primera está pidiendo a los compradores que presupuesten un sustituto y lo llamen coste.

El expediente público de Genesis Cloud hace esa abstracción inusualmente visible, porque documenta una capa y deja las otras en la oscuridad. AS209045 es Genesis Cloud Limited de Malta, anunciando dos prefijos IPv6, interconectándose con euNetworks y OVH, y según la lectura resumida del expediente, no visible en la tabla de enrutamiento global desde el 16 de abril de 2026. Es un conjunto de hechos reales, comprobables y concretos sobre una ruta de red. Es también, por sí solo, una base insuficiente para cualquier afirmación sobre la velocidad a la que correrá un trabajo de entrenamiento o sobre lo que costará.

La disciplina que el expediente recompensa es simple y poco gloriosa: presupueste el trabajo, no el acelerador; pida las condiciones, no el gráfico; y trate la capa documentada públicamente como un punto de partida y no como un resumen del conjunto. Las tres cosas que vende una nube de GPU son separables. Los compradores que las separan obtienen un coste. Los que no, obtienen una tarifa.