Clound ia is a misspelled search for cloud AI, and the traffic behind the typo behaves like any other navigational query: people typing clound ia are usually trying to reach a managed AI platform or to price GPU capacity, not hunting for another definition. For engineering teams in Portugal and the wider EU, the practical decision behind the misspelling is rarely definitional. It is which GPU capacity you rent for inference and at what effective hourly cost, and that decision in 2026 is dominated by a single hardware family — NVIDIA’s Hopper-generation H100 and H200 — packaged very differently by each cloud provider. If you want the procurement framing first, the practical engineering guide to cloud AI covers the consumption model. This article stays on the metal: instance shapes, GPU memory, interconnect and discount mechanics.

What Clound IA Searchers Want

Searchers who type clound ia split into two groups with the same underlying need. The first group reads the string as “cloud + ia”, pairing the English word with the Portuguese abbreviation for inteligência artificial; they are Portuguese speakers looking for where to run AI workloads in the cloud. The second group simply mistypes a vendor console URL or a generic query about AI platforms. Neither group is well served by another glossary page. What both groups actually face, the moment they move from searching to building, is a capacity question: rent H100-class instances, rent H200-class instances, or skip raw GPUs entirely and call a per-token API. That last option has its own economics, covered in detail in the cloud AI model pricing comparison. The rest of this article assumes you have already decided that self-managed inference — for latency, data-residency or cost-at-scale reasons — is on the table.

H200 Memory Rewrites Inference

The single most consequential hardware change for inference economics is memory bandwidth, and this is where the H200 breaks from the H100. On NVIDIA’s own datasheet, the H200 delivers 141 GB of HBM3e memory running at 4.8 TB/s with 1.4X more memory bandwidth than H100, nearly double the capacity in the same power envelope. Decode throughput for large language models is memory-bandwidth-bound: every generated token requires streaming the model weights from HBM to the compute units, so a 1.4X bandwidth uplift translates almost linearly into tokens per second on large models. The practical consequence for capacity planning is that an H200 node serves more concurrent requests at the same latency target than an H100 node, which means fewer nodes for the same throughput. NVIDIA reports up to 1.9X faster Llama 2 70B inference on H200 versus H100 in its published benchmarks, largely through larger feasible batch sizes. For teams in Europe, the H200 also keeps long-context workloads feasible: 141 GB per GPU accommodates 70B-class models at high precision with generous key-value cache headroom, reducing the quantization compromises that smaller-memory GPUs force.

GPU Instances Compared

The three hyperscalers package the same silicon quite differently. On AWS, the flagship training-and-inference shape is the p5.48xlarge, which p5.48xlarge pairs eight H100 GPUs with 640 GB of HBM3 memory on a single host, with 192 vCPUs, 2 TiB of host RAM and up to 3,200 Gbps of Elastic Fabric Adapter networking; the p5e.48xlarge variant swaps in eight H200s for 1,128 GB of HBM3e. On Azure, the equivalent H200 offering is the ND-H200-v5 series: a single VM carrying eight NVIDIA H200 Tensor Core GPUs interconnected with 900 GB/s NVLink, with a dedicated 400 Gbps InfiniBand connection per GPU for scale-out runs. Google Cloud’s A3 family attaches H100 80GB GPUs to accelerator-optimized machine types such as a3-highgpu-8g. The table below lines up the comparable shapes.

Two patterns stand out. First, AWS and Azure both expose eight-GPU hosts with roughly comparable host memory, so cross-cloud porting of a serving stack is realistic if you standardize on vLLM or TensorRT-LLM containers. Second, GPU memory per host now ranges from 640 GB to well over a terabyte, which changes how many model replicas fit per node — a full p5e.48xlarge can hold two 70B-class models at FP8 with cache to spare, collapsing what used to be a two-node deployment into one.

Spot Versus Reserved Capacity

Hourly list prices are the least useful number in GPU planning because almost nobody pays them. Google Cloud documents that Spot VM GPU pricing provides discounts of 60-91% off the corresponding on-demand price for most machine types and GPUs, with the trade-off that Spot capacity can be reclaimed. For batch evaluation, offline embedding generation, fine-tuning runs that checkpoint aggressively and overnight load tests, Spot is almost always the right choice. For latency-sensitive production inference, the calculus inverts: preemption mid-generation is visible to users, so production serving wants on-demand capacity, capacity reservations, or committed-use discounts. Google’s committed-use discounts require attaching a reservation for the GPU at purchase time, and that reservation cannot be modified or deleted for the commitment’s duration — a constraint that makes one-year commitments the pragmatic ceiling for fast-moving inference fleets, since hardware generations now turn over faster than three-year terms. The same logic applies on AWS (Savings Plans and Capacity Blocks) and Azure (reservations), though the exact discount percentages vary by region and program.

Matching GPUs to Workloads

Use this ordered procedure to converge on a shape instead of guessing:

1. Measure current tokens per second and p95 latency per request from your existing serving logs; these two numbers define the throughput floor any candidate instance must clear.
2. Size model memory first: model weights plus key-value cache at your peak concurrent batch must fit in per-GPU memory. If FP8 70B plus cache exceeds 80 GB per GPU, start with H200-class instances.
3. Estimate cost per million tokens for each candidate shape by dividing effective hourly price by measured tokens-per-hour, including Spot pricing for non-interactive workloads.
4. Run a two-day canary on the winning shape with production traffic shadowed, recording GPU memory pressure and tail latency under realistic batch sizes.
5. Lock capacity with a one-year commitment only after the canary, and keep a Spot-based fallback pool sized for at least 20 percent of peak traffic.

For most EU teams the answer that falls out of this procedure in 2026 is boring and defensible: H100-class eight-GPU hosts for steady-state serving, H200 hosts where long contexts or higher batch densities justify the premium, and Spot aggressively for everything asynchronous. The clound ia typo will keep sending searchers in circles; the capacity decision it hides has a clean, evidence-based answer.

Sources

• Amazon EC2 P5 Instances — AWS product page
• ND-H200-v5 size series — Microsoft Learn
• NVIDIA H200 GPU — official specifications
• GPU pricing — Google Cloud documentation