Summary

  • A GPU cloud sells three separable things — an accelerator, a host machine that feeds it, and a network path that carries work in and out — and quotes a single number for all three. Genesis Cloud's public record documents the third layer and leaves the first two largely unreadable.
  • Hurricane Electric's BGP Toolkit records AS209045 as Genesis Cloud Limited, country of origin Malta, originating two IPv6 prefixes and no IPv4 prefix, with observed IPv6 peers at euNetworks and OVH.
  • The same record's summary, captured on 18 October 2026, states that the ASN has not been visible in the global routing table since 16 April 2026. The record does not say why.
  • Industry billing mechanics explain the gap: capacity is provisioned per instance but advertised per GPU-hour, egress is metered separately by volume, and multi-GPU throughput is set by interconnect topology rather than by the accelerator model alone.

The number that gets compared

Every conversation about AI compute begins with a figure that looks like a price and behaves like a slogan: dollars per GPU-hour. It is the number that appears in procurement spreadsheets, in the comparison tables that circulate on internal chat channels, and in the slide that a finance team builds when it wants to know whether a training programme is affordable.

It is also the number that answers the least interesting question in the room. A GPU-hour tells you what an accelerator costs to occupy for sixty minutes. It does not tell you what your job costs, because your job is not an accelerator sitting still. Your job is a sequence of operations in which an accelerator waits on a host's memory bandwidth, on a storage path, on a network hop, and on the interconnect that lets many accelerators behave like one larger machine. The billed unit and the delivered unit are different objects, and the gap between them is where procurement risk lives.

That gap is usually discussed as a matter of vendor opacity. It is better understood as a problem of separable layers that are reported as if they were fused. A GPU cloud is not selling a GPU. It is selling an accelerator, plus a host, plus a path — and the price sheet is a single figure covering all three, with the composition left to the buyer's imagination.

This article takes one operator's public record and asks a narrow question: which of the three layers can actually be verified from documents a buyer can reach, and which are being taken on trust? The operator is the company filed in the BTW directory as Genesis Cloud Routing, Peering and DNS, a GPU-cloud provider whose routing identity turns out to be far better documented than its compute product.

Three layers, three evidence states

Separating the layers is not a rhetorical device. It changes what counts as evidence.

The accelerator layer is the one marketing owns. It is described in product names, memory sizes and generational claims, and it is the layer buyers believe they are comparing. For this operator, that layer could not be read: the pricing page, the terms of service and the GPU instance pages did not return extractable text when this article's reporting attempted to open them across 17 and 18 October 2026. What remains is the company's own self-description as a cloud infrastructure provider specialising in GPU acceleration, and a corporate database listing that records it as a private organisation in the GPU cloud market. Neither establishes an accelerator catalogue.

The host layer is the one almost nobody documents. It covers the CPU-to-GPU balance, system memory per accelerator, local storage throughput, and the scheduling policy that decides whether your instance shares a machine with a neighbour whose workload saturates the same memory bus. This is not exotic information; hyperscalers publish it. But it is the layer where cheap capacity is made cheap, and it is the layer that no public document in this record addresses at all.

The network layer is the one that turned out to be documented — not because the operator published it, but because internet routing is a public fact by construction. Registries and routing toolkits record who holds an autonomous system number, which address space it originates, and who it peers with. That record exists whether or not a company wants it to, and for this subject it is the only layer where a document can be cited rather than a claim repeated.

Three layers, then, in three states: asserted, absent, and documented. The interesting question is not that the first two are thin. It is that the third is thin in a specific, measurable way — and that its thinness is invisible to anyone reading only the product page.

What a GPU-hour actually meters

The mechanics of GPU cloud billing are not secret. They are simply not summarised on the price sheet.

Capacity is provisioned as an instance — a virtual machine with a defined slice of a physical host — while it is quoted and compared as a per-GPU-hour figure. The two units are not the same. As an industry explainer on GPU cloud billing sets out, providers bill at the instance level even when costs are calculated and advertised per GPU-hour, and the granularity of that billing varies by provider, from the second to the minute to the hour (GPU cloud billing explainer). Granularity sounds like an accounting detail until you run many short jobs: a provider that rounds to the hour and a provider that rounds to the second can differ by a large multiple on the same workload, with an identical headline rate.

The same source records the second structural feature: on-demand and reserved pricing diverge sharply, and reservation converts a variable cost into a commitment whose value depends on utilisation the buyer has to forecast. That is a financing decision dressed as a discount.

The third feature is the one that most often breaks a budget after the fact. Egress bandwidth is frequently charged separately, metered by the volume of data leaving the provider's network, and for high-throughput AI workloads it can materially change total cost of ownership. A GPU-hour price contains no egress. A model checkpoint written out nightly, a dataset streamed in per epoch, a training corpus replicated across regions — each of these adds a line the price sheet never showed.

Put those three together and the arithmetic of a completed job looks nothing like the arithmetic of an accelerator-hour. Cost per job is a function of accelerator time, host balance, storage path, interconnect efficiency, egress volume and interruption terms. The advertised figure covers the first term and gestures at the rest.

Topology is a performance term, not a specification

If there is a single technical fact that dismantles the idea of the GPU-hour as a unit of work, it is this: multi-GPU throughput is governed by how the accelerators talk to each other.

NVIDIA's own technical documentation is blunt about it. NVLink provides a direct, high-speed interconnect that bypasses the limits of the PCIe bus for GPU-to-GPU memory access, and high-throughput training workflows rely on it to avoid communication bottlenecks during gradient synchronisation across multiple GPUs (NVIDIA on NVLink and multi-GPU training efficiency). Where accelerators are attached over PCIe instead, the interconnect becomes the constraint, and the accelerators spend their billed hours waiting.

Industry billing guidance makes the same point from the commercial side: multi-GPU throughput depends heavily on interconnect topology, with NVLink providing high-bandwidth, low-latency GPU-to-GPU communication compared with standard PCIe, and InfiniBand commonly deployed for fast inter-node communication in high-performance clusters.

This matters because interconnect topology is not a property of the accelerator. Two providers can list the same accelerator model at the same hourly rate and deliver radically different throughput on a multi-GPU job, because one has wired eight devices into a coherent fabric and the other has not. The buyer comparing dollars per GPU-hour is comparing a constant against a variable. That is not a pricing comparison; it is a category error with a procurement process attached.

There is a second-order consequence that rarely appears in vendor comparisons. Topology determines how a workload scales, and scaling determines how many accelerators you must rent to finish in a given wall-clock time. A configuration with poor interconnect can consume more GPU-hours to complete the same work. The cheaper hourly rate then costs more per job, and the invoice that arrives looks like a forecasting failure rather than what it is: a purchase of the wrong unit.

What AS209045 actually says

Against that commercial fog, the routing record is almost shockingly concrete.

Hurricane Electric's BGP Toolkit, which publishes ASN-to-prefix and ASN-to-holder relationships, records AS209045 as Genesis Cloud Limited, with country of origin Malta and two prefixes originated in total (Hurricane Electric BGP Toolkit record for AS209045). The verbatim record reads:

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

Three facts follow directly, and each of them is checkable by anyone with a browser.

First, the holder name on the routing record is a legal-entity style name — Genesis Cloud Limited — with a specific jurisdiction attached: Malta. That is a different kind of claim from the descriptive label under which the company appears in a directory. It is a registration statement, made in a system designed for exactly that purpose.

Second, the originated address space is two IPv6 prefixes and nothing else. No IPv4 prefix appears in the record. Both prefixes carry the description "Genesis Cloud LIR Admin", which points at local internet registry administration rather than at a customer-facing service range.

Third, the observed IPv6 peers are two well-known European network operators: euNetworks, a fibre and data-centre connectivity provider, and OVH, the French hosting and cloud group. A two-peer observation is a narrow slice of a routing table, not a complete topology, but it does tell a buyer something a price sheet never will — that this network path is anchored in European carrier and hosting infrastructure rather than in a global backbone of its own.

Two prefixes and no IPv4

It is worth pausing on how small that footprint is, because size here is not an insult. It is a measurement.

An autonomous system that originates two IPv6 prefixes and no IPv4 space is not running a broad public address estate. It is not advertising thousands of routes to the global table. It is a narrow registration, consistent with an operator that reaches its customers over other people's networks — transit and peering relationships doing the work that a large self-announced footprint would otherwise do.

That is a perfectly ordinary way to run a cloud. Most cloud providers do not announce their customers' traffic as their own; they buy transit and peer at exchanges, and their ASN carries management and edge traffic rather than the sum of their commercial activity. The mistake would be to read the ASN as a measure of compute footprint. It is not, and this article does not.

But the same observation cuts the other way for the buyer. If the network path is thin and largely outsourced to carrier relationships, then the determinants of a job's network cost — where egress is priced, which routes are taken, how traffic reaches the customer — sit inside commercial terms rather than inside a public routing record. The routing record tells you the path exists and roughly where it lands. It does not tell you what crossing it costs.

And that is precisely the asymmetry this article set out to test. The layer that is publicly documented is the layer that matters least to the price of a completed job. The layers that dominate the price — host balance and egress terms — are the ones with no public document at all.

The withdrawal question

The most consequential line in the record is also the one that requires the most care.

The summary of the same toolkit page, captured on 18 October 2026, states that AS209045 has not been visible in the global routing table since 16 April 2026. That is a statement about visibility, not about intention. A registration can persist while announcements stop, and the reasons for such a stop are numerous and mostly mundane: a renumbering, a migration to a different upstream, a change of provider, a period of internal restructuring, or an operational decision to stop announcing space that is no longer in use.

The record does not establish which of these applies. What it does establish is the shape of the thing a buyer would never see from the product side. A company can continue to present a GPU cloud offering while the public routing presence associated with its registered network name goes quiet for six months. Nothing about that is necessarily wrong. But the two facts are not connected in any document a buyer is likely to read, and the connection is exactly the kind of thing a technical due-diligence process is supposed to make.

It also gives the article its clearest illustration of the thesis. The network path is not a permanent attribute of a provider; it is a live operational state that can change without any corresponding change to a price sheet, a marketing page, or a sales conversation. If a buyer's cost model depends on where traffic lands and how it gets there, then a change in announcement visibility is a material fact — and it appears in a routing toolkit, not in a vendor's terms.

The name on the card and the name in the registry

The directory entry for this subject is filed under a descriptive name: Genesis Cloud Routing, Peering and DNS. That name is a useful label. It is not a legal identity, and it is not what the routing record says.

The routing record says Genesis Cloud Limited. The directory card's own metadata concedes the gap: its known role is the generic "network infrastructure operator", its sole cited evidence basis is an RDAP autnum lookup for AS209045, and its recorded data gaps list the legal entity country, current services, visible assets, parent or subsidiary links, and responsible public leadership contacts as unverified. The card was auto-published.

A descriptive directory label and a registry holder name are different kinds of claim, and the space between them is where identities get assumed rather than established. "Genesis Cloud" appears in the routing record, in the company's own web presence, and in a corporate database entry that lists it as a private organisation in the GPU cloud market (Crunchbase's Genesis Cloud profile). That is a consistent pattern, and consistency is not the same as confirmation: no document retrieved for this article establishes the corporate relationship between the GPU-cloud business and the holder of AS209045 beyond the name they share and the LIR administration description on the prefixes.

For an article about verifiability, that distinction is not pedantry. It is the whole point. The layer that looked most solid — a named company in a registry — turns out to be solid about a name and silent about the commercial entity behind it. The compute product, meanwhile, is described in the first person by a website that could not be read.

What could not be read, and when

A dated boundary is more useful than a vague impression, so here is the boundary in full. Everything below was attempted and failed between 17 and 18 October 2026.

The registry record the directory identity rests on. The RDAP autnum lookup for AS209045, cited by the directory card as its only evidence basis, returned no source candidates (the RDAP autnum lookup cited by the directory card). The registry text itself — holder, country, contact handles, remarks — has therefore not been read in the course of this reporting. What this article knows about the ASN's holder comes from a third-party routing database, not from the registry.

The operator's own product and commercial terms. Attempts to reach the main site, the pricing page, the terms of service and the GPU instance pages failed to return extractable text (Genesis Cloud's site; the same site over www). No accelerator model, memory configuration, host specification, interconnect detail, billing granularity, egress rate, service credit or interruption term is established in this article.

Peering policy and exchange presence. The PeeringDB entry for AS209045 was access-restricted at retrieval, so published peering policy, internet-exchange presence, traffic ratios and open-versus-selective posture could not be extracted (PeeringDB's AS209045 entry).

Independent corroboration of the routing facts. bgp.tools' view of the same ASN was likewise access-restricted, and RIPEstat's status page carried no descriptive holder or routing summary text (bgp.tools' AS209045 view; RIPEstat's page for AS209045). The prefix and peer facts therefore rest on a single third-party source. They are verbatim and checkable, but they are not double-sourced in this record.

Measured performance. No independent sustained-throughput measurement was found for any Genesis Cloud instance. No tokens-per-second figure, no multi-node scaling curve, no storage throughput number, no real-world job-completion cost.

That is the boundary. It is wide, it is dated, and it is asymmetric: the layer with public infrastructure — routing — is documented; the layers with commercial content — catalogue, terms, egress, performance — are not.

Why the absence is the story, not the scandal

It would be easy, and wrong, to write this as a story about a company that hides things. Nothing in the record supports that. Pages fail to load for reasons that have nothing to do with intent: bot protection, regional blocking, script-dependent rendering, a site behind a challenge that automated retrieval cannot pass. A published price sheet is also not a legal obligation for a private company selling to enterprises through direct sales.

What the record does support is a structural observation about the GPU cloud market as a whole. The information a buyer needs in order to price a job is not the information the market makes comparable. Advertised accelerator-hours are comparable across vendors precisely because they are stripped of host balance, interconnect, egress and interruption terms. Those terms are negotiated, quoted, or buried in an annex. So the one figure that can be compared is the one figure that does not determine cost, and the figures that do determine cost are the ones that cannot be compared.

A market that works this way does not produce irrational buyers. It produces buyers who optimise the visible variable, and then discover in the invoice that they were optimising a proxy. The corrective is not outrage. It is a purchase process that asks for the other layers in writing — instance-level specifications, interconnect topology, egress rates, interruption and credit terms, and a benchmark on the buyer's own workload rather than on a vendor's chart.

What a buyer can actually do with three layers

If a GPU cloud is three purchases, then due diligence has three parts, and they can be specified.

For the accelerator layer, the useful questions are boring and answerable: which device generations are offered, how much device memory per instance, and what the ratio of accelerator to host CPU and system memory is. That last ratio is the one that decides whether the accelerator is fed or starved, and it is the one most often omitted.

For the host layer, ask for the scheduling model and the tenancy guarantee. Is a given instance on a dedicated host or a shared one? What happens when a co-tenant saturates memory bandwidth? What is the local storage throughput, and is it network-attached? These questions have answers, and a provider that cannot answer them is telling you something.

For the network layer, the questions are the ones the routing record cannot answer: what is the egress rate per gigabyte, is ingress charged, is there a committed-volume discount, and where does traffic physically leave the provider's network? A buyer who asks these three questions before signing learns more about delivered cost than any comparison of headline GPU rates will ever reveal.

And for all three, the cheapest single control is a benchmark on your own workload, run before commitment, with the invoice checked against the benchmark rather than against the price sheet.

What would change this account

The conclusions here are bounded by retrieval, not by conduct, and they would move if any of the following became available.

A readable RDAP autnum record naming the same holder, with contact handles and remarks, would move the ASN identity from third-party attribution to registry fact. A published price sheet and terms of service would move the accelerator and egress layers from boundary to evidence. A PeeringDB entry stating peering policy and exchange presence would corroborate or complicate the two-peer observation. An independent sustained-throughput measurement would test whether the interconnect behind this offering can carry multi-GPU work at the rate a buyer would need.

Any one of those would change the article's centre of gravity, and all of them are the sort of document that a serious provider in this market eventually publishes.

Until then, the honest statement is the narrow one: the routing layer is documented, the compute layers are not, and the gap between them is where a buyer's cost model currently rests.

The unit a buyer should price

A GPU-hour is a unit of occupancy. A completed job is a unit of work. Everything that determines the second — host balance, interconnect, storage path, egress, interruption terms — falls outside the first, and a market that quotes only the first is asking buyers to price a proxy and call it a cost.

Genesis Cloud's public record makes that abstraction unusually visible, because it documents one layer and leaves the others dark. AS209045 is Genesis Cloud Limited of Malta, originating two IPv6 prefixes, peering with euNetworks and OVH, and according to the record's summary, not visible in the global routing table since 16 April 2026. That is a real, checkable, specific set of facts about a network path. It is also, on its own, an insufficient basis for any statement about how fast a training job will run or what it will cost.

The discipline the record rewards is simple and unglamorous: price the job, not the accelerator; ask for the terms, not the chart; and treat the layer that is publicly documented as a starting point rather than a summary of the whole. The three things a GPU cloud sells are separable. Buyers who separate them get a cost. Buyers who do not get a rate.