OpenAI x Broadcom — The OpenAI Podcast Ep. 8

In this OpenAI Podcast episode I sat down with Greg Brockman and our partners Hock Tan and Charlie Kawwas from Broadcom to announce a major new collaboration: co-designing custom chips and an end-to-end systems platform to scale AI inference and deliver dramatically more compute to the world. The conversation—published by OpenAI—covers the technical choices, the scale we’re planning, why we’re building chips now, and what this partnership means for the path toward more capable models and ultimately AGI.

As the person who helped lead this initiative at OpenAI, I want to explain what we announced, why it matters, how we’re approaching the engineering challenges, and what people and organizations should expect in the years to come. Below I’ll walk through the announcement, the technical and strategic rationale, the timeline, and some of the broader implications—written in the first person because I want this to read like the conversation we had and the commitments we’re making.

🤝 Announcing the partnership

Today we publicly announced that OpenAI and Broadcom are partnering to design a custom chip and a complete systems stack optimized for our modern AI workloads. The work began roughly 18 months ago focused on a chip tailored for inference, and it quickly expanded into building a full system—the racks, the networking, the cooling, the data center integration—the entire vertical from transistor to token.

This is not just a chip project. It’s a systems and infrastructure project at a scale that few people outside the industry fully appreciate. We plan to begin deploying racks powered by this custom platform starting late next year, and to ramp the deployment very rapidly over the subsequent three years. The headline number we announced is an incremental 10 gigawatts of compute capacity delivered by these new systems. To be clear: that’s additional capacity on top of all the GPUs and data centers we already run with other partners.

"10 gigawatts of these racks of these systems and our chip, which is a gigantic amount of computing infrastructure to serve the needs of the world to use advanced intelligence." — Sam Altman

Why Broadcom? Because Broadcom is one of the most capable partners globally for building silicon and complex systems at scale. Hock and Charlie’s teams have deep experience across semiconductor manufacturing, networking, and system design. For us, partnering with Broadcom allowed OpenAI to couple intimate workload knowledge with industrial-grade execution and vertical integration expertise.

🔧 Why we’re designing chips and systems now

At OpenAI we’ve always focused first on the ideas and algorithms that move us toward AGI. That hasn’t changed. But over the last several years we’ve repeatedly observed a simple empirical fact: progress often follows compute. Models get stronger as they scale, and a lot of the most surprising gains came when we pushed on computation. From the early days of our Dota 2 experiments to the modern GPT series, scale unlocked capabilities we didn’t anticipate.

That realization pushed us to engage with many parts of the hardware and systems ecosystem. We spent years working with a number of chip vendors and cluster providers, giving feedback about workload shape, memory patterns, network topology, and software interactions. Over time it became obvious that for certain classes of workloads—especially inference at massive scale—there’s an opportunity to get dramatically better efficiency if you co-design hardware and software specifically for those workloads.

There are three practical reasons we decided to build our own chips and systems:

• Workload specialization: Training and inference have different sweet spots. A design that maximizes TFLOPS for training may be far from optimal for inference, where memory capacity and memory bandwidth often dominate. Designing hardware optimized for inference can drastically reduce cost and increase throughput.
• System-level efficiency: When you control silicon, rack design, networking, and software, you can optimize across the stack. Small cross-layer wins compound into large overall efficiency gains per watt and per dollar.
• Control and direction: We were sometimes frustrated that external vendors didn’t prioritize the exact direction we believed was best for model architecture and deployment. Building our own path lets us realize our vision faster and, hopefully, set patterns that others will adopt.

All that said, GPUs remain incredibly valuable. They’re flexible and excellent for research. We will continue to use and depend on GPUs. But as I put it in the podcast: when you become more confident about the shape of the future, a very optimized system that’s aligned to the workload will let you squeeze a lot more intelligence out of each unit of energy.

⚡ The scale: what 10 gigawatts means

Numbers like "10 gigawatts" are big and abstract, so I want to make this concrete. When I started, the first clusters I remember were a couple megawatts. Over the last few years we’ve scaled up to operate multiple gigawatts across partnerships. This project is an incremental 10 gigawatts of new, custom systems. That’s a huge amount of compute by current industry standards—enough to power data centers the size of small cities.

But the important context is that demand scales nonlinearly. Historically, whenever we make models faster, smarter, or cheaper, people discover ten times more ways to use them. We’ve seen this again and again: improve throughput or reduce latency and demand explodes. That’s why even tens of gigawatts is just the beginning relative to the total global need if very capable AI becomes widely available.

"10 gigawatts is a gigantic amount of capacity. And yet, if we do as good of a job as we hope... the world will absorb it super fast and just find incredible new things to use it for." — Sam Altman

Importantly, this 10GW is incremental. It sits alongside the GPUs and other silicon we already use and alongside our collaborations with other vendors. We’re building towards a future with far more than 10GW in total—this partnership is a meaningful step on that path.

🧩 Vertical integration: transistor to token

One of the themes we emphasized in the podcast is vertical integration. That phrase gets tossed around a lot, but in this project it literally means designing from the transistor up to the final token that a user sees when calling ChatGPT or an API. That end-to-end view unlocks optimizations that are not possible when different parties each optimize only their layer.

Practically, vertical integration involves:

• Transistor-level decisions: choices about process node, power, and logic layout.
• Chip architecture: the XPU (AI accelerator) design that balances compute, memory capacity, and on-chip bandwidth for inference workloads.
• Multi-die and stacking strategies: exploring 2D tiling and 3D stacking to pack more compute per area and per watt.
• Networking and switching: high-bandwidth, low-latency interconnects so chips can be aggregated into large clusters efficiently.
• Racks and systems engineering: thermal designs, optics integration, and rack-level power distribution.
• Software and model shaping: adjusting model architecture and runtime to match hardware primitives and exploit hardware features.

That end-to-end coordination is what allows us to "ring out" more intelligence per unit of energy. We often use the shorthand "intelligence per watt"—the idea that the tighter you optimize the whole pipeline, the more useful work you can get for each joule consumed.

🧠 Designing for workloads: training vs inference

Not every workload benefits from the same hardware trade-offs. Broadly speaking, training workloads often value sheer math throughput (TFLOPS) and high-precision arithmetic, while inference places a premium on memory capacity, memory bandwidth, quantization support, and latency. Investing in the right balance of these factors changes the economics of serving models dramatically.

Key workload trade-offs we considered:

• Memory vs compute: Inference often needs large memory and fast memory access. Increasing on-chip memory and optimizing memory subsystems reduces off-chip transfers and latency.
• Precision: Inference can often use lower numeric precision than training. That reduces energy per operation and increases effective throughput when supported by hardware.
• Latency and tail behaviour: Users care about latency and the rare slow requests. Architectural and network design choices target predictable low-latency responses at scale.
• Network topology: Inference at global scale needs different networking choices compared to large-scale training—different balance of bisection bandwidth, topology, and switching technology.

All of these workload distinctions drove how we shaped the XPU and the broader system. The exciting part is that the best solution for inference, when combined with good software and model design, can unlock major efficiency and cost gains that make more capabilities affordable for more people.

🤖 AI-assisted chip design and collaborative engineering

One of the really interesting technical developments in this project is the use of AI tools to optimize the chip and the system design. Greg explained this in the podcast: we fed our models of the workload and design constraints into optimization systems that then proposed design changes. The results were often unexpected, but when our engineers reviewed them they recognized those changes as things they would have eventually tried.

Model-driven design sped up the process in multiple ways:

• Search at scale: Design spaces in modern chips are enormous. AI-driven search can explore many more configurations faster than manual exploration alone.
• Optimization for specific constraints: Models can optimize for power, area, latency, and other constraints simultaneously.
• Discovering non-human heuristics: The optimizations sometimes surfaced combinations that human designers wouldn’t have prioritized early, allowing us to reach better trade-offs faster.

To be clear, human expertise remains central. Experts validated and refined the outputs. But the combination of human judgment and model-driven search turned what would have been months of iteration into something we could accomplish on a much tighter schedule.

"We were able to apply our own models to designing this chip... You take components that humans have already optimized and just pour compute into it and the model comes out with its own optimizations." — Greg Brockman

This iterative co-design approach—AI helping design chips that will run AI—feels both practical and symbolic of how this industry is evolving. As models get better at design tasks, they become tools that accelerate the very infrastructure needed to run them.

🌐 Systems engineering: racks, networking, optics and stacking

Chips are necessary but not sufficient. The real leverage comes from building systems that scale and interoperate reliably. That’s why the project moved from "chip-first" to "system-first." We realized that to meet global inference demand, we needed control of the entire chain: switches, racks, interconnects, and data center integration.

Some key systems aspects we’re working on:

• High-bandwidth switching: We’re exploring integrated optics and high-throughput switching. Broadcom announced technologies targeting 100 terabits of switching with optics integrated into the chip—this is critical when many accelerators need to talk to each other at high speed.
• Multi-die and stacking: Rather than being limited by a single die’s area, we’re designing clusters of die tiled in two dimensions and considering vertical stacking in the third dimension. Stacking lets us increase compute density without stepping into increasingly expensive lithography nodes prematurely.
• Thermal and power engineering: Packing more compute per rack demands new approaches to cooling and power delivery. We’re designing novel rack layouts, thermal transfer mechanisms, and power distribution to keep efficiency high.
• Networking topologies: For inference it’s often optimal to keep compute close to where users query it. That means optimizing inter-rack and inter-cluster topologies for low-latency global access, using optics and intelligent switching.

Combining these systems innovations with the XPU means we don’t just have a faster chip; we have a fundamentally different unit of compute—one that can be deployed in dense clusters, integrated into global networks, and scaled up quickly to meet demand.

🏗️ Historical perspective and building the next generation operating system

People like analogies—railroads, the internet, the great public works of history. I don’t love exact historical equivalences because each epoch has unique features, but it’s useful to put scale and coordination into context. The industrial efforts to build national infrastructure—rail, highways, electrification—required coordination across industries, governments, and capital. Building the AI infrastructure layer feels similar in scope.

We often say: we’re building what could become civilization’s next-generation operating system. That’s not hyperbole. When you make intelligent systems broadly available, they become foundational utilities that other applications and sectors layer on top of. For that to be successful, we need engineers, chipmakers, network builders, data center operators, and governments to collaborate.

"We're defining civilization's next generation operating system." — Hock Tan

That phrase captures both the potential and the responsibility. If these capabilities become integral to how people organize work, create products, and solve problems, then their robustness, accessibility, and safety matter enormously. That’s why scale and openness are both important conversations in this project: scale so that more people can access these capabilities; openness so that standards, interoperability, and a healthy ecosystem can flourish.

🚀 What this enables: agents, Codex, and everyday impacts

One of the most tangible threads in our conversation was how more capacity and better efficiencies let us move from interactive models—things you ask questions of—to persistent agents that do work on your behalf 24/7. For example, features like Pulse or personalized assistants are currently limited to higher tiers because running a persistent agent for every user is computationally expensive.

With more efficient infrastructure we can imagine everyone having an agent that helps them achieve goals continuously: managing schedules, drafting and iterating on complex documents, monitoring markets and systems, pursuing personalized learning, or doing multi-step research tasks that require hours or days of computation.

Concrete examples already visible today include:

• Code generation and software engineering: Codex and similar tools already allow developers to write and refactor code faster. As models become capable of doing multi-day or multi-week tasks at a high level, the productivity impact multiplies.
• Knowledge work amplification: For writers, analysts, designers, and scientists, models that can reason, synthesize, and iterate over long horizons will change workflows.
• Industry-specific automation: From healthcare and legal to finance and manufacturing, domain-adapted agents could handle tedious, supervisory, or analysis tasks—freeing humans to focus on the corner cases and high-level judgment.

Each step of improvement in capability tends to unlock much more demand. That’s why we’re trying to make compute more abundant: to match the latent demand and to ensure a broad set of people benefit from the increased intelligence available.

📅 Timeline: when you’ll start seeing this

We talked through timing in the podcast. The short answer: silicon back late next year, followed by rapid deployment over the next three years. We’re already working at pace—Greg and I meet weekly with Hock and Charlie—and silicon development is underway.

Broadly, the timeline looks like this:

1. Design and tape-out: Continue chip and systems design in the near term, with tape-out for initial silicon targeted in the coming months.
2. Silicon validation and systems integration: Once initial silicon returns, validate at scale, iterate on software and firmware, and build rack prototypes.
3. Pilot deployments: Late next year we expect to place initial racks in production environments and begin serving workloads on the custom systems.
4. Ramp deployment: The following one to three years will focus on rapid deployment to reach the announced incremental 10GW and beyond in coordination with data center and energy partners.

These timelines are aggressive but realistic; Broadcom’s manufacturing and systems experience helps compress the end-to-end schedule significantly relative to what it would take for a smaller, standalone effort. Still, building chips and systems is inherently hard and involves iteration, validation, and careful reliability work.

⚖️ Risks, responsibilities, and mission alignment

As we scale compute and build infrastructure, we’re mindful of responsibilities. Scaling capabilities carries both positive potential and risks. It is central to OpenAI’s mission that AGI benefits all of humanity. That requires not only technical progress but also governance, safety engineering, and equitable access.

Key responsibility areas we’re focused on:

• Safety and alignment: We invest heavily in research to reduce risks from model misuse, unexpected behavior, or misuse amplified by scale.
• Economic implications: As agents automate tasks, we must think about workforce transitions, economic redistribution, and policies that ensure broad benefits.
• Energy and environmental impacts: Building many gigawatts of compute has energy implications. That’s why energy efficiency per watt is not just a cost question—it’s an environmental one. Our design choices prioritize intelligence-per-watt improvements.
• Standards and interoperability: We believe in open standards where possible so an ecosystem can flourish. Our partnership with Broadcom aims to produce technology and interfaces that enable broader participation, even if Broadcom will also work with other partners.

We don’t have all the answers. But we are committed to aligning our engineering choices, deployment strategies, and organizational practices with the mission of maximizing benefit and minimizing harm.

🌱 How others can participate and ecosystem effects

This project doesn’t happen in a vacuum. We’re working closely with datacenter operators, energy providers, cloud partners, and other silicon vendors. Our aim is not to monopolize a new class of hardware, but to catalyze an ecosystem where specialized accelerators and systems complement general-purpose GPUs and other platforms.

Ways others can participate:

• Data center operators: Partnering on power, cooling, and rack deployment logistics to bring these systems live globally.
• Software and model developers: Adapting models to exploit new hardware features and optimizations from the stack.
• Standards bodies and open projects: Working on interoperability standards for networking, optics, and runtime interfaces so different vendors can interoperate.
• Policy makers and civil society: Engaging early on the social and economic consequences to create policies that maximize public benefit and safety.

We hope other companies will build complementary systems and standards so the entire industry advances. The scale of demand will be enormous and diverse; a single vendor or architecture will not be sufficient. That diversity is healthy. What we aim to provide is a clear, fast example of what optimized inference systems can look like and to help raise the bar for energy and cost efficiency across the industry.

🔭 Closing thoughts and next steps

To me, this partnership with Broadcom represents a pragmatic, ambitious step toward enabling more abundant compute for the world. We’re tackling the problem at multiple levels: algorithmically (models and software), architecturally (XPU design), and infrastructurally (racks, optics, networking). The goal is straightforward—more intelligence per watt so that more people can use capable models affordably and with low latency.

I want to reiterate a few points:

• This is a systems project: Building a chip alone wouldn’t have solved our problems. We needed the racks, the networking, and the data center integration to realize the gains.
• Demand is insatiable: Whenever we make models faster, better, and cheaper, the world finds new uses. Building capacity is a necessary, ongoing project.
• We’ll continue to use GPUs: Flexible accelerators remain vital, especially for research. The custom systems we’re building are complementary, not replacements.
• Safety and access matter: Technical progress must be paired with safety research, governance, and efforts to ensure wide access.

We’re excited to get the first silicon back and begin testing. Over the next year we’ll be sharing more technical details as we validate the design and as we move into pilot deployments. For everyone watching—engineers, operators, policy makers—the next few years will be a period of intense progress and consequential choices. I’m optimistic. The technical work is hard and ambitious, but it’s deeply worthwhile because of the enormous potential to improve how people work and create.

Thank you to Hock, Charlie, Greg, and teams at Broadcom and OpenAI who have pushed this forward. I’m looking forward to continuing the conversation, sharing results, and building this responsibly and collaboratively.

Key takeaways

• OpenAI and Broadcom are partnering to co-design a custom AI chip and a full system optimized for large-scale inference.
• The project targets an incremental 10 gigawatts of capacity starting late next year with rapid deployment over the following three years.
• Vertical integration across transistor, chip, rack, and software enables major energy and cost efficiencies.
• Workload-specific design choices—memory vs compute, precision, latency—drive the architecture for inference-centric accelerators.
• AI-assisted chip design and integrated optics and stacking are among the technical innovations being pursued.
• Scaling compute is both an opportunity and a responsibility; safety, environmental impact, and equitable access are central to our approach.

Further reading and follow-ups

I’ll be writing more technical follow-ups as we validate the design and begin pilots. Expect deeper dives on the XPU architecture, interconnect topologies, thermal and power design, and practical performance per watt comparisons as soon as we have validated data to share. In the meantime, keep an eye on OpenAI’s channels for technical posts and Broadcom’s publications for the silicon and systems perspective.