Posted in Artificial Intelligence, Cloud & Infrastructure

IBM’s Telum II and the z17: How IBM Built AI Acceleration Directly Into the Mainframe

IBM’s broader Power11 and watsonx push covers enterprise AI generally. But IBM’s mainframe line has its own, much narrower AI story: a processor called Telum II, built into the z17 mainframe, that puts an AI accelerator on the same die as the processor cores running a bank’s core transaction workload. It’s a fundamentally different approach to AI acceleration than the GPU clusters behind most generative-AI infrastructure — and it exists for a specific reason: scoring transactions for fraud in real time, without sending data anywhere else.

At a Glance

ItemDetail
ProcessorTelum II — 8 cores, 5.5GHz, built on Samsung 5nm process
MainframeIBM z17 — announced April 8, 2025; generally available June 18, 2025
On-chip AI acceleratorUp to 24 TOPS per chip; up to 192 TOPS per fully configured 8-chip drawer
Companion acceleratorIBM Spyre Accelerator — 32 AI cores per PCIe card, stackable
IBM’s claimed throughputMore than 450 billion inference operations/day (IBM-reported, ~50% more than z16)
IBM’s claimed latency1 millisecond response time (IBM-reported internal/extrapolated benchmark)

What Telum II Actually Is

Telum II is IBM’s latest mainframe processor, introduced alongside the z17 system. IBM describes it as built on Samsung’s 5-nanometer process with eight high-performance cores running at 5.5GHz. Cache capacity grew roughly 40% over the prior generation, reaching a virtual L3 cache of 360MB and a virtual L4 cache of 2.88GB shared across the system — large on-chip caches that matter because mainframe transaction workloads are extremely cache-sensitive. Telum II also adds a dedicated data processing unit (DPU) to handle I/O acceleration, offloading that work from the main cores.

The On-Chip AI Accelerator

The part that matters here is Telum II’s integrated AI accelerator — a block of matrix-math hardware sitting on the same die as the processor cores, not a separate card reached over a bus. IBM says each accelerator’s compute capacity is roughly 4x higher than the previous Telum generation, reaching 24 trillion operations per second (TOPS), and added INT8 precision support, which IBM says improves efficiency and enables newer model types. In a fully populated processor drawer, any of the system’s cores can dispatch work to any of the drawer’s eight AI accelerators, which IBM says improves load balancing — and across all eight, IBM cites up to 192 TOPS available when fully configured.

Why This Is Different From GPU-Based AI Acceleration

A GPU cluster is a separate pool of compute that data has to travel to — over PCIe, NVLink, or a network fabric — before and after inference. That round trip adds latency and is usually fine for workloads like training large models or running chatbots, where milliseconds of network time don’t matter. It’s a poor fit for scoring a credit card swipe before the transaction is approved, where the system has a few milliseconds, total, to decide. IBM’s answer is to put a comparatively much smaller AI accelerator directly on the processor die, right next to the cores already executing the transaction. There’s no separate card, no PCIe hop, and no network call: the model runs in the same silicon, close to the same memory, as the business logic it’s scoring. IBM frames the payoff this way in its own benchmarking: more than 450 billion inference operations per day on z17, a claimed 50% increase over z16, with a 1 millisecond response time — figures IBM describes as extrapolated from internal tests using a synthetic credit-card fraud detection model, so they should be read as IBM’s own reported benchmark rather than an independently audited figure.

IBM Spyre: A Second, Complementary Accelerator

Not every AI workload fits on Telum II’s on-chip accelerator, which is sized for high-volume, low-latency scoring rather than large generative models. For that, IBM pairs the mainframe with the IBM Spyre Accelerator, a separate PCIe card containing 32 AI accelerator cores built on an architecture similar to Telum II’s on-chip engine. Multiple Spyre cards can be attached to a single z17 or LinuxONE system, and IBM positions it for generative-AI and larger-model workloads that complement, rather than replace, the real-time scoring done on-chip.

The Fraud Detection Use Case

IBM’s flagship example for Telum II is an ensemble approach to fraud and compliance. A traditional, relatively small neural network running on the on-chip accelerator gives an initial risk score for a transaction in real time; that score can then be combined with a large language model (typically run elsewhere, such as on Spyre) to improve accuracy without slowing down the initial decision. IBM describes applying the same ensemble pattern to detecting suspicious financial activity and supporting regulatory compliance work — cases where the first-pass model has to run inline with the transaction, and a heavier model can refine the result afterward.

On-Chip vs Spyre vs a Typical GPU Accelerator

AcceleratorLocationConnects ViaBest ForLatency Profile
Telum II on-chipSame die as CPU coresIntegrated — no external linkSmall models, real-time transaction scoringSub-millisecond, in-line with transaction
IBM SpyreSeparate cardPCIeLarger models, generative AILow, but higher than on-chip
Typical GPU acceleratorSeparate card or nodePCIe or network fabric (NVLink/InfiniBand/Ethernet)Training, large-scale inferenceHigher — depends on network hop

Trade-offs

  • The on-chip accelerator’s 24 TOPS per chip is tiny next to a modern training GPU, but it isn’t trying to compete on raw throughput — it’s optimized to never leave the transaction path.
  • IBM’s headline performance figures (450 billion inferences/day, 1ms latency) come from IBM’s own internal and extrapolated benchmarks, not third-party testing, and should be treated as vendor-reported.
  • Running AI on a mainframe only makes sense for organizations already running core transaction workloads on IBM Z; it isn’t a general-purpose AI platform the way a GPU cloud is.
  • Spyre adds generative-AI capacity, but it’s a separate card with different latency characteristics than the on-chip accelerator — the two aren’t interchangeable.

Bottom Line

Telum II and the z17 represent a narrower, more specific bet than GPU clusters: instead of moving data to a big pool of accelerators, IBM moved a small AI accelerator onto the same chip as the workload it needs to score. For something like real-time fraud detection, where the entire decision window is a few milliseconds, that architecture has a real structural advantage over any design that requires a PCIe or network hop — even though the raw compute numbers look small next to a data-center GPU.

FAQ

Is Telum II a GPU?
No. It’s a general-purpose mainframe CPU with an integrated AI accelerator block on the same die, designed for inline inference on structured transaction data rather than the large matrix workloads GPUs handle.

How fast is the z17’s AI accelerator really?
IBM states up to 24 TOPS per Telum II chip and up to 192 TOPS across a fully configured 8-chip processor drawer. For context, that’s a small fraction of a modern data-center GPU’s throughput — it’s built for latency on small models, not raw volume.

What’s the difference between Telum II’s accelerator and IBM Spyre?
Telum II’s accelerator is built into the processor die for the fastest possible, real-time inference on the transaction path. Spyre is a separate PCIe card with 32 AI cores aimed at larger generative-AI workloads that don’t need to run inline with a single transaction.

Are IBM’s performance claims independently verified?
No. IBM’s published figures — more than 450 billion inferences/day and 1ms latency — come from IBM’s own internal and extrapolated benchmarks using a synthetic fraud-detection model, and IBM itself notes results may vary.

Sources

Posted in Artificial Intelligence, Cloud & Infrastructure

Nvidia’s Networking Stack: How NVLink, InfiniBand, and Spectrum-X Tie AI Data Centers Together

When Nvidia talks about AI infrastructure, the GPU gets most of the attention — but a cluster of thousands of GPUs is only as fast as the links between them. Nvidia’s networking stack, built around NVLink, InfiniBand, and the newer Spectrum-X Ethernet platform, is what turns racks of individual accelerators into a single, coordinated system. This piece looks at what each technology actually does, why interconnect bandwidth is now as important as raw compute for large training runs, and how Nvidia’s 2020 acquisition of Mellanox put all three technologies under one roof.

At a Glance

TechnologyScopeTypical BandwidthPrimary Use
NVLink / NVLink-C2CChip-to-chip, GPU-to-GPU within a server or moduleUp to 1,800 GB/s per GPU (Blackwell, 5th-gen NVLink)Scale-up links inside a node (GPU-GPU, CPU-GPU)
NVLink SwitchRack-scale, multi-node GPU fabric130 TB/s aggregate per NVL72 domain (Blackwell)Making 72 GPUs act as one accelerator
InfiniBand (Quantum-2)Server-to-server, scale-out cluster fabric400 Gb/s per port; 51.2 Tb/s per switchConnecting thousands of GPU servers in dedicated AI/HPC clusters
Spectrum-XServer-to-server, Ethernet-based AI fabricUp to 1.6x stock Ethernet performance; scales to 128K GPUs (Nvidia claim)Standards-based Ethernet for AI clouds

Why the Network Matters as Much as the GPU

Training a large model is a tightly synchronized job spread across hundreds or thousands of GPUs. At set intervals, every GPU has to exchange gradients or activations with many others before the next step can start — a pattern built on collective operations like all-reduce and all-to-all. If the network is slow or congested, GPUs sit idle waiting for data no matter how fast they can individually compute. That’s the practical reason Nvidia sells networking silicon alongside GPUs: a cluster’s effective throughput is capped by whichever is slower, compute or communication, and at the scale of a modern training cluster the network is frequently the binding constraint.

NVLink and NVLink-C2C: Wiring Chips and Servers Together

NVLink is Nvidia’s direct GPU-to-GPU interconnect, and it operates at a different layer from a traditional data-center network. Nvidia states that the 5th-generation NVLink used in Blackwell GPUs provides 1,800 GB/s of bidirectional bandwidth per GPU across 18 links — roughly double the prior Hopper generation’s 900 GB/s. Nvidia’s roadmap lists a 6th generation for its upcoming Vera Rubin platform at 3,000 GB/s per GPU across 36 links, though the company explicitly labels these as preliminary specifications that may change.

A related technology, NVLink-C2C, extends the same coherent, high-bandwidth connection down to the chip-to-chip level — for example, linking a Grace CPU to Blackwell GPUs inside a single “Superchip” module. Nvidia says NVLink-C2C can deliver up to 6x the energy efficiency and 3.5x the area efficiency of a PCIe Gen 6 physical layer. Through a licensing program called NVLink Fusion, Nvidia also opens this chip-to-chip link to partners who want to pair custom CPUs or ASICs with Nvidia GPUs in semi-custom designs.

NVLink Switch and the Rack-Scale Fabric

On its own, NVLink only connects the GPUs inside one server. NVLink Switch chips extend that same all-to-all connectivity across multiple servers in a rack. In Nvidia’s NVL72-class systems, NVLink Switches tie 72 Blackwell GPUs into a single non-blocking domain, with Nvidia citing 130 TB/s of aggregate GPU bandwidth inside that domain — letting the rack behave, from a software standpoint, like one very large accelerator rather than 72 separate ones.

InfiniBand: Nvidia’s Scale-Out Fabric for Supercomputing Clusters

Once a workload needs more GPUs than a single rack can hold, it moves from NVLink’s “scale-up” domain to a “scale-out” network connecting many servers — InfiniBand’s job. Nvidia’s current Quantum-2 platform runs each port at 400 Gb/s, with a single switch offering 64 such ports (or 128 ports at 200 Gb/s) for 51.2 Tb/s of aggregate bidirectional throughput and more than 66.5 billion packets per second. A key feature is in-network computing: Nvidia’s third-generation SHARP technology performs data aggregation and reduction operations inside the switch itself rather than making GPUs handle that work, which Nvidia says delivers up to 32x more AI acceleration power per switch than the prior generation. Nvidia states the platform can scale to more than a million 400 Gb/s nodes in a three-hop DragonFly+ topology.

Spectrum-X: Making Ethernet Behave Like a Supercomputer Network

InfiniBand has long been the default fabric for HPC and AI supercomputers, but most enterprise and cloud data centers run on Ethernet. Spectrum-X is Nvidia’s attempt to bring InfiniBand-like performance to standards-based Ethernet. The platform pairs Spectrum-X switches (the SN5000 and SN6000 series) with “SuperNICs” — network accelerators that handle RDMA over Converged Ethernet (RoCE) between GPU servers. Nvidia says Spectrum-X delivers up to 1.6x the network performance of off-the-shelf Ethernet, and a companion technology, Spectrum-XGS, is built to link multiple data centers together, with Nvidia citing 1.9x higher NCCL (GPU collective-communication) performance across sites. Nvidia also markets Spectrum-X Ethernet Photonics, using co-packaged optics the company says deliver 5x better power efficiency. On scaling, Nvidia describes Spectrum-X as able to reach 128,000 GPUs in a flat two-tier topology — a figure the company says is 64 times larger than single-plane networks can reach. Importantly, Nvidia positions this as fully standards-based Ethernet that supports open network operating systems like SONiC, not a proprietary fabric.

The Mellanox Acquisition: How Nvidia Became a Networking Company

None of this would exist in its current form without Nvidia’s purchase of Mellanox Technologies, the company that built much of the industry’s InfiniBand and high-performance Ethernet silicon. Nvidia announced the deal in March 2019 and closed it on April 27, 2020, for roughly $7 billion. At the time, Nvidia CEO Jensen Huang said, “With Mellanox, the new NVIDIA has end-to-end technologies from AI computing to networking.” That combination is the direct ancestor of today’s stack: Mellanox’s ConnectX network adapters and switch silicon became the base for both the Quantum InfiniBand line and the Spectrum Ethernet line, while Mellanox’s SHARP in-network computing technology was folded into Nvidia’s collective-communication software. In effect, the acquisition gave Nvidia control of both ends of the AI data center — the GPUs doing the computing and the fabric moving data between them — which is part of why Nvidia can now sell a complete rack-scale system rather than just a chip.

NVLink vs InfiniBand vs Spectrum-X

DimensionNVLink (+ NVLink Switch)InfiniBand (Quantum-2)Spectrum-X
ConnectsGPUs/CPUs within a node or rackServers across a clusterServers across a cluster
Network typeProprietary coherent interconnectProprietary lossless fabricStandards-based Ethernet
Typical scale (claimed)Up to 72 GPUs per NVL72 domainOver 1M nodesUp to 128K GPUs
In-network computeN/A (direct links)SHARPv3RoCE with congestion control, adaptive routing
Best fitTightest-coupled training within a rackDedicated AI/HPC supercomputersMulti-tenant AI clouds wanting Ethernet operability

Trade-offs

  • NVLink’s bandwidth is unmatched, but it only works within Nvidia’s own rack-scale systems — it isn’t a general data-center network.
  • InfiniBand offers the most mature in-network computing, but it requires a dedicated fabric and ecosystem separate from a customer’s existing Ethernet operations.
  • Spectrum-X is more familiar to enterprise network teams, but Nvidia’s performance multipliers (1.6x, 1.9x, 5x, etc.) are vendor-reported figures, not independently audited benchmarks.
  • All three layers are now Nvidia-controlled end to end, which concentrates the AI networking supply chain around a single vendor.

Bottom Line

GPUs get the headlines, but Nvidia’s AI data center pitch increasingly rests on the fabric connecting them. NVLink and NVLink-C2C handle the tightest-coupled links inside a server or module, NVLink Switch extends that into 72-GPU “single accelerator” domains, InfiniBand remains the proven scale-out fabric for the largest dedicated AI/HPC clusters, and Spectrum-X is Nvidia’s bet that most future AI clouds will want Ethernet-level interoperability without giving up supercomputer-grade performance. The thread tracing back through all of it is Mellanox — the 2020 acquisition that gave Nvidia the silicon to build a full-stack data center rather than just a chip.

FAQ

Is InfiniBand faster than Ethernet for AI workloads?
Nvidia’s Quantum-2 InfiniBand switches support 400 Gb/s ports and in-network computing features like SHARP that have historically given InfiniBand an edge in latency and collective-operation performance. Spectrum-X narrows that gap for Ethernet with similar congestion control and offload features, and Nvidia reports up to 1.6x better performance than stock Ethernet — but that is a vendor figure, not a neutral third-party benchmark.

What’s the difference between NVLink and InfiniBand?
NVLink connects GPUs (and increasingly CPUs) directly, within a server or, via NVLink Switch, within a rack-scale system like the NVL72. InfiniBand connects separate servers to each other across a cluster. They operate at different layers of the same system and aren’t interchangeable.

Why did Nvidia buy Mellanox?
Mellanox brought Nvidia the InfiniBand and high-performance Ethernet silicon — switches, NICs, and software — that Nvidia lacked. The roughly $7 billion deal, completed in April 2020, let Nvidia pair its GPUs with its own networking stack instead of depending on third-party network vendors.

Can Spectrum-X replace InfiniBand entirely?
Nvidia sells both and positions them for different buyers: InfiniBand for dedicated AI/HPC supercomputers, Spectrum-X for Ethernet-based, often multi-tenant, AI clouds. Nvidia has not stated that either is being discontinued.

Sources

Posted in Artificial Intelligence, Engineering

Google’s Other Infrastructure Bets: TPU Chips for AI and the Go Programming Language

Google doesn’t get the same AI-infrastructure headlines as Nvidia or OpenAI, but it quietly runs two pieces of foundational tech that power a huge share of the industry: custom TPU chips for AI training and inference, and the Go programming language that underpins much of the cloud-native world’s backend infrastructure. Neither gets much coverage on its own; together they say a lot about how Google builds for scale.

At a Glance

TechnologyCategoryCurrent state
Ironwood (TPU v7)AI accelerator chipGA; Google’s 7th-gen TPU, built for inference
Trillium (TPU v6e)AI accelerator chipGA; prior generation, still widely used
Go (Golang)Programming languageGo 1.27 (Aug 2026), patch 1.27.3 (Oct 2026)

Short Verdict

TPUs are now a credible third option alongside Nvidia GPUs and AWS’s Trainium for serious AI workloads — Anthropic’s decision to scale Google TPU usage toward a million chips is hard to argue with. Go, meanwhile, has become unglamorous infrastructure plumbing in the best sense: not exciting, but running Kubernetes, Docker, and a huge share of cloud-native backend systems, with steady, incremental language improvements rather than hype-driven changes.

TPU Chips: Google’s AI Silicon

Google’s current-generation TPUs span two chips. Trillium (TPU v6e), generally available, delivers 918 TFLOPs of bf16 compute and 32GB of HBM per chip at 1,638GB/s bandwidth, scaling to 256-chip pods; Google claims it’s 67% more energy-efficient and offers 4.7x higher peak compute per chip than the previous generation. Ironwood (TPU v7), which Google calls its “first TPU built for the age of inference,” is the newer chip: 192GB of HBM per chip at 7.37TB/s bandwidth, scaling to pods of up to 9,216 chips delivering a claimed 42.5 exaflops. Google has described Ironwood as roughly 2x more power-efficient than Trillium in its original launch materials, though a separate Google Cloud page frames the generational jump as “4x better performance per chip” — both are Google’s own figures from different pages, worth noting as evolving marketing language rather than a hard contradiction.

TPUs are rented through Google Cloud as “slices” — a dedicated portion of a pod that behaves as one unified machine, orchestrated through Google Kubernetes Engine. The software stack leans heavily on JAX (a NumPy-style array computation library with composable transforms) and the XLA/OpenXLA compiler, though PyTorch and TensorFlow are also supported.

The clearest validation of TPUs at frontier scale comes from Anthropic, which announced in late 2025 that it’s expanding its use of Google Cloud TPUs to up to 1 million chips, adding well over a gigawatt of capacity coming online through 2026. Anthropic uses TPUs alongside Nvidia GPUs and AWS Trainium as part of a deliberate multi-chip strategy, rather than relying on any single vendor. Other named Google Cloud TPU customers include Citadel Securities (claiming 2–4x faster workloads at 30% lower cost) and Lightricks (claiming 40% more daily training steps after migrating to JAX/TPU). Reports that Apple trained some of its on-device Apple Intelligence models on TPUs rather than Nvidia GPUs are well-corroborated by tech press but are best described as “reportedly,” since this piece did not independently verify that detail against Apple’s own primary technical documentation.

Go: Quiet Infrastructure for the Cloud-Native World

Go was designed at Google starting in 2007 by Robert Griesemer, Rob Pike, and Ken Thompson, out of frustration with the build times and complexity of existing languages at Google’s scale, and open-sourced in 2009. Today go.dev describes it simply as “an open-source programming language supported by Google” — language evolution now runs through a public change-proposal process, though Google retains some structural control over the project’s infrastructure (code review runs on Google’s own Gerrit instance, and certain compliance rules require Google employee involvement in some changes).

The current stable release is Go 1.27 (released August 2026, with security patch 1.27.3 in October 2026), which added generic methods, new strict JSON handling packages, post-quantum cryptographic signature support, and cheaper small-object allocation. The prior release, Go 1.26, enabled a new garbage collector by default (claimed 10–40% reduction in GC overhead) and added faster cgo calls. Go’s defining feature remains its concurrency model: goroutines are lightweight functions the runtime multiplexes onto OS threads, cheap enough to create hundreds of thousands of at once, communicating through channels modeled on Hoare’s CSP rather than shared-memory locking.

Go’s real impact shows up in what’s built with it: Kubernetes, Docker, and Terraform — three of the most widely used pieces of cloud infrastructure software in existence — are all written in Go, which is part of why it’s become the default language for cloud-native tooling, CLIs, and backend network services, generally favored over Python for performance and over Java/C++ for its simpler build model and faster compile times.

Pros

  • TPUs: proven at frontier scale via Anthropic’s million-chip commitment, with a mature JAX/XLA software stack and strong perf-per-watt claims from Google.
  • TPUs: Cloud TPU slices let teams rent a fraction of a pod rather than committing to an entire cluster.
  • Go: exceptionally fast compile times and a concurrency model that scales to hundreds of thousands of lightweight goroutines without heavyweight thread management.
  • Go: steady, backward-compatible releases on a predictable six-month cycle, rather than disruptive breaking changes.

Cons

  • TPUs: tied exclusively to Google Cloud, unlike Nvidia GPUs which run on every major cloud.
  • TPUs: Google’s own marketing language around generational performance gains (Ironwood’s “2x” vs “4x” framing in different materials) isn’t always perfectly consistent.
  • Go: lacks Rust’s compile-time memory-safety guarantees, relying on garbage collection instead.
  • Go: its standard library and idioms deliberately avoid some abstractions (generics arrived late, no traditional class hierarchy), which some developers coming from Java or C++ find limiting.

Who It’s a Good Fit For

Teams already on Google Cloud training large models at scale are a natural fit for TPUs, especially with JAX-based workflows. For Go: teams building cloud infrastructure tooling, CLIs, network services, or anything where fast compilation, simple deployment (a single static binary), and high-concurrency networking matter more than maximal runtime performance or compile-time memory safety.

Who Should Look Elsewhere

Teams not already on Google Cloud, or needing cross-cloud portability, will find Nvidia GPUs or AWS’s Trainium more practical than TPUs. For Go: teams needing compile-time memory-safety guarantees without a garbage collector should look at Rust; teams needing dynamic prototyping speed over performance may still prefer Python.

Bottom Line

TPUs and Go don’t get bundled together often, but both reflect the same Google trait: building deeply vertically integrated infrastructure, then letting the results speak through adoption rather than marketing noise. TPUs have earned a real seat at the AI-chip table via Anthropic’s scale commitment; Go has quietly become the default language underneath most of the cloud-native stack most engineers use every day.

FAQ

Can I use TPUs outside Google Cloud?
No. TPUs are proprietary Google silicon, available only through Google Cloud’s Cloud TPU service.

Is Go still controlled by Google?
Go is open-source and changes go through a public proposal process, but Google retains meaningful structural control — the canonical repository, code review tooling, and certain compliance requirements still run through Google.

What major software is written in Go?
Kubernetes, Docker, and Terraform are among the best-known infrastructure projects written in Go, which is a large part of why it’s the default language for cloud-native tooling.

Sources

Posted in Artificial Intelligence, Cloud & Infrastructure

Nvidia’s Data Center AI Empire: Blackwell GPUs, CUDA, and the Software Moat Nobody Else Has

Every custom AI chip from AWS, Google, and everyone else gets measured against one thing: Nvidia’s data center GPU lineup and the CUDA software stack built around it. Nvidia’s advantage isn’t just silicon anymore — it’s a decade-plus of software that makes its GPUs the default choice even when a competitor’s chip is cheaper on paper. Here’s what’s actually in the current lineup.

At a Glance

ProductGenerationKey spec (per Nvidia)
H200Hopper141GB HBM3e, 4.8TB/s bandwidth
GB300 NVL72Blackwell Ultra72 GPUs + 36 Grace CPUs, 20TB GPU memory, rack-scale
Vera RubinNext-gen (roadmap)Announced; full specs not yet published by Nvidia
CUDA / TensorRT / NIMSoftware stackCompiler, inference engines, prebuilt model microservices

Short Verdict

Nvidia’s hardware lead is real but no longer the whole story — H200’s gains over H100 are almost entirely about memory, not raw compute, and custom chips from AWS, Google, and others are closing the hardware gap in specific workloads. What keeps Nvidia dominant is CUDA: a massive, mature software ecosystem (cuDNN, TensorRT, NIM microservices, the AI Enterprise suite) that every major cloud supports natively, which makes switching away from Nvidia a real engineering cost even when a competitor’s chip looks better on a spec sheet.

The Current Lineup: Hopper and Blackwell

The H100 and its successor H200 (both Hopper-generation) remain widely deployed. Nvidia’s own spec sheets show something worth calling out directly: H200’s FP8 and FP16 compute throughput is identical to H100’s on paper — the real upgrade is memory, with H200 carrying 141GB of HBM3e at 4.8TB/s versus H100’s smaller, slower memory pool. Nvidia claims this translates to roughly 1.6–1.9x faster inference on large models like Llama 2 70B and GPT-3 175B, which tracks with memory-bound inference workloads benefiting disproportionately from more bandwidth.

The newer Blackwell generation is a bigger architectural jump. The Blackwell GPU die itself packs 208 billion transistors across two reticle-limited dies fused by a 10TB/s link, presented to software as a single GPU. At rack scale, the flagship GB300 NVL72 combines 72 Blackwell Ultra GPUs with 36 Grace CPUs (2,592 Arm Neoverse V2 cores) into one liquid-cooled unit, with 20TB of GPU memory at up to 576TB/s of aggregate bandwidth and NVLink providing 130TB/s of GPU-to-GPU bandwidth within the rack. Nvidia claims this delivers up to 65x more AI compute than Hopper-based systems for reasoning-style inference workloads — a large claim worth treating as a vendor benchmark rather than an independently verified figure, since Nvidia doesn’t publish the full comparison methodology.

Nvidia has also announced its next architecture, Vera Rubin, as a rack-scale “agentic AI supercomputer” built from co-designed Rubin GPUs and Arm-based Vera CPUs. At the time of writing, Nvidia’s own dedicated spec page for Vera Rubin wasn’t accessible for detailed verification, and most specific numbers circulating about it (core counts, exact shipping dates) come from secondary tech press rather than Nvidia’s own published specs — treat Vera Rubin as a confirmed-to-exist roadmap product with unconfirmed specifics for now.

The Real Moat: CUDA and the Software Stack

Hardware specs only tell half the story. Nvidia’s CUDA Toolkit — the compiler, libraries, and runtime that let developers program GPUs directly from C++, Python, or Fortran — has over a decade of accumulated tooling built around it: cuDNN for deep-learning primitives (accelerating PyTorch, TensorFlow, JAX, and others), TensorRT for inference optimization (Nvidia claims up to 36x speedup versus CPU-only inference in some configurations, an unqualified marketing figure worth independently benchmarking for your own workload), and NIM (NVIDIA Inference Microservices), which packages optimized foundation models into containers deployable with a single command and an OpenAI-compatible API.

Above that sits NVIDIA AI Enterprise, a commercial software suite bundling NIM, pre-built “Blueprints,” the NeMo framework for LLM training, and Omniverse — available through every major cloud marketplace (AWS, Azure, GCP, and OCI) as well as direct from Nvidia. This is the part of Nvidia’s business that’s genuinely hard for AWS, Google, or anyone else to replicate quickly: switching chip vendors means re-validating an entire software stack, not just swapping hardware.

Available Everywhere, Unlike the Alternatives

Unlike AWS’s Trainium or Google’s TPUs, Nvidia GPUs are available across every major cloud: AWS (P5/P5e/P5en for Hopper, P6-B200/B300 and P6e-GB200 UltraServers for Blackwell), Azure (ND H200 v5 series), Google Cloud (A3/A3 Ultra for Hopper, A4/A4X for Blackwell), and Oracle Cloud Infrastructure (H100 through GB200 at supercluster scale). That universal availability, combined with CUDA’s maturity, is why Nvidia GPUs remain the default starting point for most AI teams even as custom silicon alternatives multiply.

Pros

  • Available on every major cloud, with no single-vendor lock-in the way custom chips (Trainium, TPUs) require.
  • CUDA’s software maturity (cuDNN, TensorRT, NIM, broad framework support) remains unmatched by any competing chip ecosystem.
  • Rack-scale Blackwell systems (GB200/GB300 NVL72) deliver genuine architectural advances in interconnect bandwidth and memory, not just incremental clock-speed bumps.
  • NIM microservices meaningfully lower the barrier to deploying optimized models in production without deep inference-engineering expertise.

Cons

  • Many of Nvidia’s headline performance multipliers (“50x,” “65x,” “36x”) are vendor benchmarks without disclosed methodology — useful as directional signals, not hard guarantees for your workload.
  • H200’s gains over H100 are almost entirely memory-driven, not compute-driven, which is easy to miss if you only read the marketing bullet points.
  • Production use of NIM and AI Enterprise requires a paid license beyond the free developer tier.
  • Demand still regularly outstrips supply for the newest Blackwell-class hardware, which can mean real-world lead times longer than cloud providers advertise.

Who It’s a Good Fit For

Teams that want cloud portability, access to the broadest possible software ecosystem, or need to deploy pre-optimized models quickly via NIM rather than building custom inference pipelines. Also the default safe choice for teams without the engineering bandwidth to port workloads to a custom-chip SDK like AWS’s Neuron or Google’s JAX/TPU stack.

Who Should Look Elsewhere

Teams locked into a single cloud who are willing to invest engineering time to port to that cloud’s custom silicon (Trainium on AWS, TPUs on Google Cloud) may find meaningfully lower costs at scale, trading some ecosystem breadth for price-performance.

Bottom Line

Nvidia’s hardware is still excellent, but the real reason it remains the default is CUDA — the software ecosystem built around its GPUs over more than a decade, which every cloud supports and almost every AI framework targets first. Custom chips are catching up on raw price-performance for specific workloads, but replicating Nvidia’s software depth is a much longer project than matching its silicon specs.

FAQ

Is H200 faster than H100?
Only in memory-bound workloads. Nvidia’s own specs show identical FP8/FP16 compute throughput between the two — H200’s advantage is its larger, faster memory (141GB HBM3e vs H100’s smaller pool), which Nvidia claims yields up to 1.9x faster inference on large models.

What is NIM?
NVIDIA Inference Microservices — prebuilt, optimized containers for deploying foundation models with an OpenAI-compatible API, requiring a paid AI Enterprise license for production self-hosting beyond the free developer tier.

Can I run Nvidia GPUs on any cloud?
Yes. Current-generation Nvidia GPUs are available on AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure, among others — unlike custom chips such as AWS Trainium or Google’s TPUs, which are tied to their respective clouds.

Sources

Posted in Artificial Intelligence, Cloud & Infrastructure

AWS Trainium and Inferentia: Do Amazon’s Custom AI Chips Actually Beat Nvidia GPUs?

AWS has spent years building its own silicon rather than relying entirely on Nvidia for AI compute — Trainium for training, Inferentia for inference. The pitch is simple: comparable or better performance at meaningfully lower cost than GPU instances, at a scale few other companies can match. Anthropic’s enormous “Project Rainier” cluster is the proof point AWS leans on hardest. Here’s what these chips actually are and how AWS’s own numbers hold up.

At a Glance

ChipRoleCurrent instance types
Trainium2Large-scale model trainingTrn2 (16 chips), Trn2 UltraServer (64 chips)
Trainium3Next-gen training (3nm process)UltraServers up to 144 chips
Inferentia2InferenceInf2 (up to 12 chips/instance)

Short Verdict

Trainium and Inferentia are real, shipping, and used at serious scale — this isn’t vaporware. Anthropic’s Project Rainier cluster, reportedly built from hundreds of thousands of Trainium2 chips, is the single strongest piece of evidence that these chips can handle frontier-scale training. AWS’s own cost/performance claims (30–40% better price-performance than its Nvidia-based instances) are real numbers from AWS, but AWS is comparing against its own GPU instance pricing, not publishing head-to-head benchmarks naming Nvidia directly, so treat the comparison as AWS-favorable by construction rather than neutral.

What Trainium and Inferentia Are

Trainium is AWS’s custom silicon for large-scale model training. The current generation in general availability, Trainium2, ships in the Trn2 instance (16 chips connected via NeuronLink, rated at 20.8 peak petaflops) and the Trn2 UltraServer, which combines four Trn2 servers into a single 64-chip unit with 83.2 peak petaflops. AWS’s own GA announcement claims Trn2 delivers 30–40% better price-performance than its existing Nvidia GPU-based P5e/P5en instances — a real AWS-published number, though it’s a comparison against AWS’s own competing instance line rather than an independent benchmark.

Trainium3, announced at re:Invent in December 2024, is AWS’s first chip built on a 3nm process. Per-chip, AWS claims roughly 2x the compute throughput of Trainium2 and 144GB of HBM3e memory at 4.9TB/s bandwidth (1.7x Trainium2’s bandwidth). Trainium3 UltraServers scale up to 144 chips, with AWS claiming roughly 4x the performance of Trainium2 UltraServers. AWS’s own materials describe “UltraClusters 3.0” scaling to hundreds of thousands of chips.

On the inference side, Inferentia2 powers the EC2 Inf2 instance family (up to 12 chips per instance) and is the first Inferentia generation to support distributed inference across multiple chips. AWS claims up to 4x higher throughput and up to 10x lower latency than the original Inferentia, with up to 190 TFLOPS of FP16 performance per chip and 32GB of HBM — four times the memory of the first-generation chip.

The Anthropic Connection

The clearest evidence that Trainium works at frontier scale is Anthropic’s “Project Rainier” cluster, confirmed directly by AWS: a compute cluster built from nearly half a million Trainium2 chips, organized into tens of thousands of 64-chip UltraServers spread across multiple U.S. data center sites (AWS names one, in St. Joseph County, Indiana). AWS describes the cluster as giving Anthropic more than 5x its previous training compute, with Claude expected to run on more than a million Trainium2 chips across training and inference combined. It’s worth noting Anthropic uses a multi-chip strategy — it also runs workloads on Nvidia GPUs and, separately, on Google’s TPUs — so Trainium is one leg of its infrastructure, not the only one.

AWS’s own Trainium2 GA announcement also names Databricks (claiming up to 30% lower total cost of ownership) and poolside (claiming 40% savings versus AWS’s P5 GPU instances) as customers, alongside integrations with Hugging Face’s Optimum Neuron and Google’s JAX via OpenXLA. Reports that Apple also uses Trainium chips come from secondary tech press rather than an AWS- or Apple-published primary source, so that specific claim should be read as “reportedly,” not confirmed.

The Software Layer: Neuron SDK

Both chip families run on AWS’s Neuron SDK, which includes a compiler and runtime, native integration with PyTorch, JAX, and TensorFlow, and support for more than 100,000 models from the Hugging Face hub. For teams that want lower-level control, the Neuron Kernel Interface (NKI) allows writing custom kernels directly. Orchestration is supported through Ray, Slurm, Amazon EKS, ECS, AWS Batch, and SageMaker HyperPod — meaning teams aren’t locked into a single orchestration tool to use these chips.

Pros

  • Proven at genuinely enormous scale — Anthropic’s Project Rainier cluster is one of the largest AI training clusters AWS has ever disclosed.
  • AWS-published price-performance claims (30–40% better than its own Nvidia-based instances) are real numbers, not vague marketing language.
  • Broad framework support (PyTorch, JAX, TensorFlow) and orchestration flexibility (EKS, Slurm, SageMaker HyperPod, Ray) reduce lock-in risk at the tooling layer.
  • A full generational roadmap already in motion — Trainium3 is shipping on a new 3nm process rather than being a one-off project.

Cons

  • AWS’s cost/performance comparisons are against its own GPU-based instances, not independently verified head-to-head benchmarks against Nvidia hardware on neutral terms.
  • Available only on AWS — there’s no equivalent of running Trainium workloads on another cloud, unlike Nvidia GPUs which are available everywhere.
  • Ecosystem and tooling maturity, while improving fast, still trails the sheer breadth of the CUDA ecosystem that’s grown around Nvidia GPUs over more than a decade.

Who It’s a Good Fit For

Teams already committed to AWS who want meaningfully lower training or inference costs than Nvidia-based EC2 instances and can tolerate some additional porting/tuning work via the Neuron SDK. Large-scale training teams in particular, given the proof point of Project Rainier running at this scale successfully.

Who Should Look Elsewhere

Teams that need portability across clouds, rely heavily on CUDA-specific tooling or libraries with no Neuron equivalent, or are running smaller workloads where the cost difference won’t offset the porting effort, may be better served staying on standard Nvidia GPU instances for now.

Bottom Line

Trainium and Inferentia are no longer experimental — they’re running some of the largest AI training workloads in the world, with real, AWS-published cost advantages over the company’s own GPU instances. Whether that translates into an advantage over Nvidia hardware broadly depends on workload specifics AWS doesn’t publish in a neutral, third-party-verified form, but the scale at which these chips are now deployed is itself a serious data point.

FAQ

Is Trainium only usable on AWS?
Yes. Trainium and Inferentia are custom AWS silicon, available exclusively through AWS EC2 and related AWS services.

Does Anthropic only use AWS chips?
No. Anthropic uses a multi-chip strategy that includes AWS Trainium, Nvidia GPUs, and Google’s TPUs, in addition to the large Trainium2-based Project Rainier cluster built with AWS.

How does Trainium’s software ecosystem compare to CUDA?
The Neuron SDK supports PyTorch, JAX, and TensorFlow and is actively developed, but it’s newer and narrower than Nvidia’s CUDA ecosystem, which has had over a decade to accumulate libraries, tools, and community support.

Sources

Posted in Artificial Intelligence, Cloud & Infrastructure

IBM Power11 and watsonx: What IBM’s Enterprise AI Infrastructure Actually Offers

While AWS, Google, and Microsoft fight over GPU supercluster bragging rights, IBM is running a different playbook: AI infrastructure built around its own Power chips, dedicated AI accelerator silicon, and a software layer (watsonx) aimed squarely at regulated enterprises that want AI running on-premises, not just in a public cloud. Here’s what’s actually in IBM’s stack.

At a Glance

ComponentWhat it isStatus
Power11IBM’s current server CPU familyShipping since July 2025
Telum IIMainframe processor with on-chip AI acceleratorPowers IBM z17 / LinuxONE 5
Spyre AcceleratorDedicated AI accelerator card (32 cores)Commercially available on Z/LinuxONE; rolling out to Power11
watsonxIBM’s AI platform (ai / data / governance / Orchestrate)Runs on Red Hat OpenShift AI, on-prem or IBM Cloud

Short Verdict

IBM isn’t trying to out-GPU Nvidia’s hyperscaler customers, and it shouldn’t be judged on that basis. Its bet is that a large slice of enterprise AI workloads — banking, insurance, government, telecom — need to run where the data already lives, under existing compliance controls, with hardware-level reliability guarantees that general-purpose cloud VMs don’t offer. Power11 plus the Telum II/Spyre accelerator lineup plus watsonx is a coherent answer to that specific problem. It is a weak answer if what you actually want is the cheapest possible path to training a frontier-scale foundation model.

What’s in IBM’s AI Infrastructure Stack

Power11 is IBM’s current-generation Power server CPU family, announced in July 2025 and the first time IBM simultaneously launched high-end, mid-range, and edge/low-end Power models together. The lineup spans the S1112 (edge/remote deployments with built-in AI acceleration), the S1122 and S1124, the E1150 (up to 120 Power11 cores, 16TB of DDR5 per 4U chassis), and the flagship E1180. IBM’s own materials don’t publish per-chip clock speeds or process node for Power11 — a genuine gap in IBM’s public documentation — but IBM does claim, in its own internal benchmarks, up to 55% faster core performance than Power9 on commercial workloads and up to 45% more processor resources than Power10 on its lower-end systems, along with roughly double the performance-per-watt of comparable x86 servers.

IBM’s AI-specific silicon sits one layer up. Telum II, built on a 5nm process and first detailed at Hot Chips in 2024, is the processor inside IBM’s z17 mainframe and LinuxONE 5 systems; it carries an on-chip AI accelerator and, in a fully configured system drawer, is rated for up to 192 TOPS of on-chip AI inference — aimed at running fraud-detection and risk models directly alongside transaction processing, with no round trip to a separate AI system. The Spyre Accelerator is IBM’s dedicated AI accelerator card: 32 AI cores on a 5nm, 75-watt PCIe card, now commercially available for IBM Z and LinuxONE systems (GA’d in late 2025) and extended to Power11 shortly after. Up to 48 Spyre cards can be clustered on Z/LinuxONE, and up to 16 on Power systems, for larger on-premises inference workloads.

watsonx: The Software Layer

watsonx is IBM’s umbrella AI platform, split into several named products: watsonx.ai (a studio for building and deploying custom AI applications, including IBM’s own Granite foundation models), watsonx.data (data integration and governance across hybrid and multicloud sources), watsonx.governance (AI risk management, regulatory compliance, and explainability tooling), and watsonx Orchestrate (building and deploying AI agents for business process automation).

Critically, watsonx is built on top of Red Hat OpenShift, and watsonx.ai specifically uses OpenShift AI’s accelerator support (which includes GPU kernel contributions from Nvidia, AMD, and Intel) and KServe for model serving. That means watsonx isn’t locked to IBM’s own chips — it can serve models like Llama 3 and Mistral alongside IBM’s own Granite models, and can be deployed fully air-gapped for workloads with strict data-isolation requirements. IBM has also confirmed that watsonx.data is being made available directly on Power11 and that Power11 integrates with Red Hat OpenShift AI.

Pros

  • On-chip AI acceleration (Telum II) built directly into transaction-processing hardware, aimed at real-time fraud/risk use cases banks and insurers actually run.
  • watsonx runs on open infrastructure (Red Hat OpenShift AI) rather than a proprietary stack, and supports third-party models alongside IBM’s own Granite models.
  • Strong hybrid/on-prem story: workloads can run fully air-gapped where data residency or regulatory rules require it.
  • Built-in quantum-safe encryption and a hardware-level ransomware detection feature (“Power Cyber Vault”) on Power11.

Cons

  • IBM does not publish basic chip specs (clock speed, process node, per-core detail) for Power11 the way competitors routinely do — third-party outlets fill in some of these numbers, but they aren’t confirmed directly by IBM.
  • Not positioned, and not competitive, for large-scale foundation-model pretraining at the scale AWS, Google, or Oracle’s GPU superclusters support.
  • The AI accelerator story is currently split across two different chip families (Telum II for mainframes, Spyre as an add-in card) rather than one unified roadmap, which adds complexity to evaluating the lineup.

Who It’s a Good Fit For

Banks, insurers, telcos, and government agencies that already run IBM Z, LinuxONE, or Power infrastructure and need AI inference (fraud detection, risk scoring, document processing) running close to transactional data under strict compliance and uptime requirements. Also a fit for enterprises that want a hybrid-cloud AI platform built on open infrastructure (OpenShift) rather than a single public cloud’s proprietary stack.

Who Should Look Elsewhere

Teams training large foundation models from scratch, or anyone who just wants the cheapest/fastest path to a large GPU cluster, should look at AWS, Google Cloud, Oracle, or Nvidia’s own cloud partners instead — IBM’s AI hardware story is about enterprise inference and governance, not frontier-scale training.

Bottom Line

IBM’s AI infrastructure play is narrower than the hyperscalers’ but more coherent for its target customer: enterprises that need AI inference running on the same hardware as their core transaction systems, under compliance regimes that make “just use a public cloud GPU instance” a non-starter. Power11, Telum II, Spyre, and watsonx add up to a real, differentiated hybrid-AI stack — just not a frontier-training one.

FAQ

Is watsonx only for IBM hardware?
No. watsonx runs on Red Hat OpenShift AI and can be deployed on IBM Power, IBM Cloud, other public clouds, or on-premises, and it can serve non-IBM models like Llama 3 and Mistral alongside IBM’s own Granite models.

What’s the difference between Telum II and Spyre?
Telum II is the main processor inside IBM’s z17 mainframe and LinuxONE 5 systems, with an AI accelerator built into the chip itself. Spyre is a separate, dedicated AI accelerator card that plugs into Z, LinuxONE, or Power systems for additional AI inference capacity.

Can IBM’s infrastructure train large language models from scratch?
It’s not positioned or marketed for that. IBM’s AI hardware emphasizes on-premises inference and governance for enterprise workloads; large-scale pretraining is better suited to GPU-cluster-focused clouds like AWS, Google Cloud, or Oracle.

Sources

Posted in Artificial Intelligence, Cloud & Infrastructure

Oracle Cloud Infrastructure for AI: Is OCI a Real Alternative to AWS, Azure, and GCP for GPU Workloads?

Oracle spent most of the cloud era as an afterthought behind AWS, Azure, and Google Cloud. In AI infrastructure, that’s changed: Oracle Cloud Infrastructure (OCI) now runs some of the largest publicly disclosed GPU superclusters in the industry, and it’s become a default landing spot for AI labs that need massive GPU capacity fast. Here’s what OCI actually offers for AI training and inference, and where its claims hold up.

At a Glance

OfferingWhat it isScale (per Oracle)
OCI SuperclusterBare-metal GPU clusters with RDMA networkingUp to ~131,000 NVIDIA B200 GPUs; roadmap to 1M+ GPUs by end of 2027
GPU shapesNVIDIA H100/H200/B200/GB200, AMD MI300XBare-metal, 8-GPU instances, no hypervisor overhead
OCI Enterprise AI / Generative AIManaged LLM, RAG, and AI agent toolingBuilt on OCI Data Science and OCI’s generative AI service

Short Verdict

OCI is a legitimate option for large-scale GPU training, not just a marketing claim. Oracle publishes real bare-metal pricing per GPU-hour (rather than burying it behind a sales call for every tier), its RDMA cluster networking numbers are credible, and it has landed genuine customers like Databricks/MosaicML and Cohere. It is not yet a broad AI platform the way AWS or Google Cloud are — OCI’s AI-specific managed services are thinner, and some of its own marketing pages are inconsistent on basic numbers. For teams that mainly need raw GPU capacity at competitive pricing, OCI is worth a serious look. For teams that want a mature ecosystem of managed AI services around the GPUs, AWS and Google Cloud are still further ahead.

What OCI’s AI Infrastructure Actually Is

OCI’s pitch for AI workloads centers on bare-metal GPU instances — meaning customers get direct hardware access with no hypervisor layer between them and the silicon — connected by Oracle’s own RDMA cluster network. Oracle calls the resulting pooled hardware an “OCI Supercluster.” According to Oracle’s own AI infrastructure page, a single OCI Supercluster can scale up to roughly 131,000 NVIDIA B200 GPUs, more than 100,000 GB200 Grace Blackwell Superchips, 65,536 H200 GPUs, or 16,384 AMD MI300X GPUs, depending on which generation of hardware a customer provisions. Oracle has also stated a roadmap target of extending this architecture to more than 1 million NVIDIA GPUs with over 3 gigawatts of capacity by the end of 2027 — a forward-looking target, not a currently deployed figure.

Worth flagging directly: Oracle’s own AI infrastructure page is not perfectly internally consistent. The written copy cites “up to 131,072” B200 GPUs in one place while an accompanying diagram on the same page shows 128,000 — a minor discrepancy, but one that suggests these maximum-scale figures should be read as approximate marketing ceilings rather than exact, audited numbers.

GPU Shapes and Pricing

Unlike some competitors, Oracle publishes real per-GPU hourly pricing for several of its bare-metal shapes directly in its own product announcements:

  • BM.GPU.H200.8 — 8x NVIDIA H200 GPUs (141GB HBM3e each, 4.8TB/s bandwidth) via NVLink, dual 56-core Intel Sapphire Rapids CPUs, 3TB DDR5 RAM, 8×3.84TB local NVMe. Oracle’s own GA announcement states this ships at $10 per GPU per hour — the same price as the prior-generation H100 shape.
  • BM.GPU.MI300X.8 — 8x AMD MI300X GPUs (192GB HBM3 each, ~1.5TB total), dual 56-core Sapphire Rapids CPUs, 2TB DDR5 RAM. Oracle’s own GA announcement states this ships at $6.00 per GPU per hour.
  • GB200 NVL72 / B200 — Oracle’s current Blackwell-generation shapes, offered via OCI Supercluster at scale; Oracle does not publish a flat per-GPU hourly rate for these on its main marketing pages, and we could not independently confirm a specific dollar figure for this tier from an Oracle-published source.

Oracle’s cluster-level networking claims include RDMA over Converged Ethernet (RoCE v2) using NVIDIA ConnectX-7 NICs, cluster bandwidth up to 3,200 Gb/s per 8-GPU instance, and sub-10-microsecond network latency (Oracle’s own materials give slightly different numbers in different places — as low as 2.5 microseconds in one spot and a 2.5–9.1 microsecond range in another, which is worth noting rather than papering over). RDMA networking, block storage, and the first 10TB of monthly egress are included at no additional charge, which is a genuine differentiator versus cloud providers that meter network egress aggressively.

Managed AI Services on Top of the Hardware

Above the raw GPU layer, Oracle offers OCI Data Science (managed notebooks and an Accelerated Data Science SDK, billed only for the compute and storage actually consumed) and a generative AI layer that Oracle has marketed under more than one name over time — it has documented an “OCI Generative AI Service” for LLM and RAG workflows, and its current top-level marketing increasingly uses the name “OCI Enterprise AI” for AI app, agent, and governance tooling. Readers evaluating this layer specifically should check Oracle’s current docs directly, since the branding appears to be in flux.

On the partnership side, Oracle has a deep full-stack relationship with NVIDIA (NVIDIA AI Enterprise is built into the OCI Console, NVIDIA NIM is available via OCI Marketplace, and GB200/GB200 NVL72 racks are deployed on OCI) and a separate relationship with AMD around the MI300X shape.

Pros

  • Published, bare-metal per-GPU-hour pricing for H200 and MI300X, rather than quote-only pricing for every tier.
  • No hypervisor overhead on bare-metal shapes, and RDMA networking, storage, and the first 10TB of egress included free.
  • Real supercluster scale, with concrete customer wins (Databricks/MosaicML, Cohere, Palantir, Stanford among others cited by Oracle).
  • Both NVIDIA and AMD GPU options, rather than a single-vendor lock-in.

Cons

  • Thinner managed-AI-service ecosystem than AWS Bedrock/SageMaker or Google Vertex AI, and the branding of Oracle’s generative AI layer has shifted, which makes it harder to evaluate from the outside.
  • Oracle’s own marketing pages contain small internal inconsistencies in headline numbers (GPU counts, latency figures), so treat maximum-scale claims as approximate.
  • Oracle rarely names AWS, Azure, or Google directly in comparative claims (“up to 220% better pricing than other cloud providers”), which makes its competitive claims hard to independently check.
  • Flat per-GPU pricing isn’t published for every GPU generation, so budgeting for the newest Blackwell-class shapes may still require a sales conversation.

Who It’s a Good Fit For

Teams training large models who need a lot of bare-metal GPU capacity, want predictable per-GPU pricing without egress surprises, or are already running Oracle Database/applications and want to keep AI workloads in the same cloud. It’s also a reasonable second-cloud option for teams hedging against GPU scarcity on AWS or Azure.

Who Should Look Elsewhere

Teams that want a deep, mature managed-AI-services layer (fine-tuning pipelines, model registries, a wide first-party model catalog) with less DIY infrastructure work will likely find AWS, Google Cloud, or Azure more complete today. Teams that need the absolute newest Blackwell-class hardware at a clearly published flat rate may also need to get a quote rather than relying on OCI’s public pricing pages alone.

Bottom Line

OCI’s AI infrastructure claims are largely backed by real, Oracle-published numbers — bare-metal GPU shapes with transparent per-GPU-hour pricing on at least two major tiers, credible RDMA networking specs, and genuine large customers. It’s a credible fourth option alongside AWS, Azure, and Google Cloud for raw GPU capacity, with the caveat that its managed AI-service layer and some of its headline marketing numbers are less polished and less consistent than its hyperscaler rivals.

FAQ

Does OCI support both NVIDIA and AMD GPUs?
Yes. OCI offers NVIDIA H100, H200, B200, and GB200 Grace Blackwell Superchip shapes, plus AMD MI300X bare-metal shapes.

Is OCI cheaper than AWS or Azure for GPU training?
Oracle claims significantly better price-performance than “other cloud providers,” but does not name competitors directly or publish a verifiable methodology, so this should be benchmarked for your specific workload rather than taken at face value.

Who is actually using OCI for AI training?
Oracle has publicly named Databricks/MosaicML, Cohere, Palantir, Stanford, Suno, and together.ai, among others, as customers running AI workloads on OCI.

Sources