Hardware and infrastructure
NVIDIA sells OpenAI not chips, but the finished ability to turn them on
NVIDIA, SB Energy, SoftBank, and OpenAI announced the PORTS-Pike project in
Ohio. SB Energy will build and operate the campus, OpenAI will lease it for 20
years, and NVIDIA will serve as exclusive compute-platform supplier and
guarantor of land, power, and ready buildings.
The first agreement covers 4.25 IT GW, with an option for another 3.75. NVIDIA
is also investing $1.5 billion in SB Energy. The participants promise at least
10 GW of new generation, $4.2 billion in grid infrastructure, and staged
commissioning beginning in 2028.
These figures describe contracts and intentions, not an operating cluster. The
gigawatts still have to be generated, carried through the grid, delivered into
completed halls, and turned into available compute. That is precisely why the
deal matters: frontier AI scarcity can no longer be solved by a GPU shipment
alone.
NVIDIA is becoming less a component vendor than an integrator of the whole
production loop. Its product is no longer a box with an accelerator, but a
financeable chain: land -> grid -> data center -> compute. Technological
advantage increasingly depends on guaranteeing the entire chain, not one
generation of silicon.
Source: NVIDIA on PORTS-Pike.
Kubeflow becomes mature infrastructure exactly as its job changes
CNCF granted Kubeflow Graduated status after an external security audit,
formalized governance, and maturity review. The foundation counts nearly 260
million PyPI package downloads, more than 6,600 developers, over a thousand
participating organizations, and roughly 33,000 stars across the repositories.
Those numbers do not reveal how many production clusters actually run Kubeflow.
The status establishes something else: the Kubernetes-native layer for data
processing, notebooks, distributed training, fine-tuning, and serving is no
longer an experimental application around Kubernetes.
The irony is that graduation arrives during another change of subject. Kubeflow
grew as an MLOps platform for training and deployment; now it must serve LLM
orchestration, post-training, and agentic workloads. A mature foundation does
not finish the project. It prevents rebuilding the lower floors when a new
class of system appears above them.
Source: CNCF announcement.
Google turns a compatible API into a model control point
Google Cloud release notes introduced model routing for API Gateway. One
OpenAI-compatible endpoint accepts a request, transforms it, and routes it by
explicit rules to Model Garden models including Gemini, Claude, and GPT. Routing
tables, conditions, and a default fallback are expressed through OpenAPI
extensions.
For now, this is a traffic-management primitive, not a smart router with proven
benefit. Google provides no benchmark showing automated model selection improving
quality or cost. Even without one, the release moves the architectural boundary:
client code no longer knows which provider executes the request.
OpenAI API compatibility becomes less a migration aid than a control plane. One
gateway can centralize credentials, policy, failover, and future model choice.
The price of convenience is obvious: a routing-rule error now affects multiple
models and every client behind one endpoint.
Source: Google Cloud release notes.