AMD calls its shot, but the real race is engineering velocity

At AMD’s Advancing AI event, Lisa Su called her shot – just like Babe Ruth. The question now is whether AMD has built the engineering machine to hit it. Last week, we argued that AMD’s next reinvention did not require it to beat Nvidia. Rather, we said, the company needed to become the indispensable second platform in a rapidly expanding AI infrastructure market. That thesis was well received. But at Advancing AI, Lisa Su raised the stakes considerably.

AMD didn’t present its new products like Venice, Instinct MI455X, Helios and ROCm as “respectable alternatives.” It claimed outright leadership across CPUs, GPUs, rack-scale performance, memory capacity, network bandwidth and tokens per dollar. And it extended the argument across enterprise AI, robotics, ultra-low-latency inference and a rapidly expanding partner ecosystem.

The obvious narrative coming out of the event is whether AMD’s model of Open Co-Innovation can match Nvidia’s Extreme Co-Design. We initially framed the debate that way ourselves. But we now believe that is only a surface-level debate.

In fact, we think the real race is what we’re calling Engineering Velocity – i.e. which organization can turn silicon, software, development infrastructure, automated validation, customer feedback and increasingly AI-assisted engineering into the fastest continuously improving platform.

In this Breaking Analysis, we’ we’ll compare those two organizational models, define the emerging engineering factory, examine the technical evidence surfaced by SemiAnalysis, quantify AMD’s networked partner strategy, separate benchmark claims from production reality, and assess whether Helios can convert Lisa Su’s ambition into sustained customer outcomes.

Because in AI infrastructure, the winner may not be the company with the best benchmark on keynote day. It will more likely be the company whose engineering system learns, validates and improves the entire platform, faster than anyone else.

Last week, we posited that AMD did not have to beat Nvidia. It only had to become the indispensable second AI platform in a huge market growing fast enough to support more than one major winner.

At Advancing AI, Lisa Su effectively raised the ambition well beyond our initial thinking. Specifically, AMD claimed leadership across CPUs, GPUs, rack-scale systems, memory capacity, network bandwidth and tokens per dollar – with direct callouts against Nvidia. So the obvious debate coming out of the event was whether AMD’s model of Open Co-Innovation could match Nvidia’s Extreme Co-Design.

That was our initial framing as well at the event. But believe that is the surface-level debate.

A deep technical analysis from SemiAnalysis helped expose something deeper. Their work argues that AMD’s software progress is real – but that the limiting factor is increasingly not engineering talent. It is engineering infrastructure – i.e. stable internal GPU clusters, continuous integration, automated validation and enough testing capacity to support a rapidly expanding number of AI coding agents.

SemiAnalysis deserves credit for identifying that operational constraint. But, we think the observation points to a much larger competitive dimension. The real race is what we’re calling Engineering Velocity. Engineering Velocity is not a third strategy. It is the competitive outcome for which both organizational models are attempting to optimize.

Nvidia pursues it through Extreme Co-Design, which is a tightly integrated engineering system with deep control (by Nvidia) across silicon, software, networking and systems.

AMD is pursuing the outcome through Open Co-Innovation – a networked engineering system spanning its own teams, a curated group of customers and partners; and of course open-source communities.

So the deeper question is not which philosophy sounds better – or even who wins a benchmark on keynote day. Rather – it is:

Which organization can learn, validate and improve the entire platform faster – and turn that advantage into a flywheel that creates production outcomes that create business value?

That is the viewpoint we’ll use throughout this Breaking Analysis.

With the premise established, let’s compare the two organizational models.

Nvidia operates what we would describe as an integrated engineering system. Its Extreme Co-Design model brings silicon, software, networking, interconnects, systems and rack-scale architecture into a tightly coordinated roadmap. Nvidia works with manufacturing and ecosystem partners, of course, but it retains unusually strong control over the architecture and the points of integration.

That control can reduce coordination latency. Hardware and software teams can optimize against a common design target, validate changes across the stack and make tradeoffs within one tightly managed engineering system.

AMD is pursuing a different model. We describe it as a networked engineering system.

AMD still owns core assets like EPYC, Instinct, ROCm, Pensando and the Helios architecture – but it is deliberately bringing customers, partners and open-source communities into the development process. Meta contributes workload and networking requirements. OpenAI and Anthropic contribute frontier-model experience. Neoclouds such as TensorWave contribute operational feedback. Open standards widen the number of participants that can influence and improve the platform.

That creates potential advantages for AMD. Specifically, more sources of insight, broader workload exposure and potentially greater ecosystem adaptability.

But it also creates a coordination challenge. A networked engineering model only works when the interfaces are clear, the software composes reliably and predictably, the responsibilities are well-understood and customer feedback moves rapidly back into the product.

This is not an argument that open is inherently better than proprietary – that’s not the point. Nor is the point that integration is inherently better than collaboration. These are two different organizational models pursuing the same objective – i.e.:

Engineering Velocity.

Which philosophy is more appealing is a religious debate best left to vendor marketing. What operators should care about is which model can learn faster, validate more accurately and continuously improve the entire AI platform at the highest sustained rate.

And that raises the next obvious question:

What actually determines Engineering Velocity? The answer, in our view, is the quality of the engineering factory behind the platform.

If Engineering Velocity is the outcome, the mechanism behind it is what we call the Engineering Factory.

In the graphic below, we define this concept a little further. By Engineering Velocity, we mean an organization’s ability to continuously improve its AI platform faster than competitors – not just by writing better code, but by combining software development, access to hardware, automated testing, validation, customer feedback and increasingly AI-assisted engineering, into a continuously learning system.

The distinction is important to our premise because the CI/CD pipeline alone is not the moat. Rather the moat is the entire engineering factory surrounding it.

What do we mean by that? Well, AI coding agents can now generate kernels, identify bugs, suggest optimizations and explore many more software paths in parallel than human engineering teams could previously attempt. But remember, every one of those changes still has to be compiled. They have to be tested on real hardware. They must be checked for accuracy, measured for performance. The must be run across different models and configurations. And they must be validated to ensure an apparent gain in one workload has not introduced a bottleneck somewhere else.

The point is:

As AI makes software generation easier and more plentiful, validation infrastructure becomes more important – and potentially less plentiful.

This is why stable internal GPU clusters are a competitive advantage. It is why continuous integration and merge-gating coverage are critical. [Merge-gating coverage is a software development practice that requires minimum testing thresholds on specific lines or blocks of code which have been modified in a pull request before the changes are allowed into a production-level feature branch of the code]. It is why the time required to support a newly released model is so important. And it is why the speed with which production feedback gets incorporated into the next software release becomes a competitive measure.

The metrics on the right hand side of the above chart give us a starting point for testing our thesis:

• How quickly does a platform support a new model?
• How much of the software stack is continuously tested before code is merged?
• How much measurable performance improvement arrives with each release?
• How stable is the internal development infrastructure?
• How quickly are regression deltas detected and fixed?
• And how effectively does customer experience flow back into product development?

SemiAnalysis deserves credit for highlighting the underlying engineering-infrastructure issue inside AMD. Their work suggests AMD’s software talent and software quality have improved, but that unstable development clusters and inadequate validation capacity can constrain the rate at which those gains accrue.

We believe that observation points to a much broader conclusion.

The engineering factory – not any single chip or rack performance – is becoming a competitive asset.

In the next section, we’ll look at three SemiAnalysis data points that help quantify both AMD’s progress and the constraints on that progress.

Now let’s put some data behind the Engineering Velocity framework.

As we said, one of the most useful technical analyses following Advancing AI came from SemiAnalysis in a post titled “Can AMD break the CUDA Moat?”

Their work is valuable in the context of our premise because this is more than commentary from an independent source. According to their post, the team there uses AMD accelerators directly, repeatedly reports software bugs, contributes upstream fixes, and tracks vLLM and SGLang continuous integration alongside model-level performance. [vLLM and SGLang are two widely respected, open-source engines used to run large language models very quickly].

To be clear – we are not adopting every conclusion in their report, and these figures have not been independently verified by theCUBE Research or any other source to our knowledge.

But three key points are especially relevant.

The first is progress. SemiAnalysis reports that AMD delivered as much as an 18-times improvement in Kimi K2.5 interactivity in less than 30 days through software changes around AITER and vLLM. [AITER is AI Tensor Engine for ROCm, an open-source library created by AMD].

To be clear – this does not mean ROCm has caught CUDA. It does, however, show that AMD’s software iteration rate can accelerate dramatically when the hardware, software teams and optimization cycles line up.

The second signal is the 90% gating target shown in the middle here.

According to SemiAnalysis, AMD was working toward at least 90% parity with CUDA on vLLM merge-gating tests by the Advancing AI conference. But SemiAnalysis claims that instability and reassignment of internal development clusters for other priorities disrupted that effort.

Here’s where we need to step back a bit and take this in. A passing demo – in other words a successful, live demonstration of a software feature that proves the code works and can be called: “Done…” – tells us that a workload can run. A merge-gating test prevents code from entering the software stack unless it passes correctness and regression testing checks. This is how software quality improves over time rather than repeatedly breaking, fixing and re-breaking.

But there’s a third key point which is internal capacity – what we show as the Capacity Gap on the above slide.

SemiAnalysis estimates that even after AMD adds thousands of accelerators to its development environment, the company’s stable internal GPU capacity remains more than an order of magnitude below Nvidia’s.

Again, we cannot independently validate that exact comparison. But the takeaway is strategically important in that AMD may no longer be constrained primarily by the quality of its engineers. It may increasingly be constrained by the scale and stability of the engineering factory supporting them.

AI coding agents intensify that problem.

Why is that? Because when one engineer can launch many agents in parallel – each generating kernels, testing configurations and proposed optimizations – the volume of code rises much faster than the capacity required to validate it.

Every change needs stable hardware to do: Regression testing, quality checks, performance validations, etc. And this has to be repeated at scale across models, frameworks and topologies.

So the bottom line is this:

AMD’s software velocity is accelerating – but its engineering factory may limit how quickly those gains can be realized at scale.

And here’s where it gets interesting…AMD’s strategy is not to simply build more internal infrastructure. It is also attempting to extend the engineering factory outward – through Meta, OpenAI, Anthropic, TensorWave and other partners. This is where the networked engineering model moves from theory into practice and is a key competitive dimension we’re watching.

This is where AMD’s Open Co-Innovation story moves from philosophy to proof that we can measure – or at least observe.

What AMD showed on stage, and we’re showing below, are not simply logo relationships in a “Barney Deal.” Each partner is contributing a different capability, workload input or operating input back into AMD’s networked engineering system.

Meta is working with AMD on networking, scale-up, scale-out and broader system co-design, within a partnership framework targeting up to six gigawatts. The important contribution is not just demand for GPUs. Meta is bringing production-scale infrastructure requirements into the engineering process.

OpenAI is contributing frontier-workload requirements, hardware and software optimization, and future-system co-design under a deployment framework of up to six gigawatts.

Anthropic adds model stand ups, ROCm feedback and deployment collaboration, with plans for up to two gigawatts of Helios. These relationships give AMD direct exposure to the workloads that will stress the next generation of AI infrastructure.

TensorWave contributes something different but vital – i.e. operator learning feedback.

As an AMD-native Neocloud, TensorWave is qualifying the platform, identifying operational issues and feeding those lessons back into AMD. CEO Darrick Horton said on theCUBE the company could target one to two gigawatts of Helios capacity in 2027.

Cerebras is different. It is not core Helios co-design in the same sense. AMD is using that partnership to fill a workload gap – disaggregated, ultra-low-latency inference – with a joint service expected later this year. It’s AMD’s version of the Nvidia Groq acquisition and launch of LPX for ultra low latency workloads.

The scale of relationships is significant, but precision and matters. So let’s be precise. These are “up to” commitments, targets and partnership frameworks – this is not fully deployed capacity, booked revenue or independently proven platform economics. Some of these arrangements also include substantial financial incentives.

In other words…A gigawatt target demonstrates engagement and strategic intent. It does not, by itself, prove demand economics or production success.

What these relationships do show is that AMD is not merely asking customers to consume a finished product. It is inviting major customers and partners into the engineering process. Such is the promise of a networked engineering model and it creates a differentiated strategy for AMD:

• More workload insight;
• More production feedback;
• More participants contributing to the learning system;
• Potentially greater Engineering Velocity.

The risk is coordination. AMD still has to convert that breadth of participation into software quality, platform integration, validation and execution speed comparable to Nvidia’s more mature integrated system.

And that brings us to the distinction between ambition and hard evidence – because partnership scale and keynote claims still have to translate into independently validated production outcomes.

AMD did not make subtle claims at Advancing AI.

The company said Helios would deliver roughly 15% more compute, 50% more HBM capacity, 50% more scale-out bandwidth and up to 30% more tokens per dollar than Nvidia’s Vera Rubin platform.

Those are notable claims. But they require careful interpretation. As we understand the methodology, AMD combined its own specifications, measurements and modeling with publicly available information about Nvidia’s un-released Vera Rubin system.

That does not make the analysis invalid. But it does mean these are not yet equivalent to independently reproduced, side-by-side production tests on commercially deployed systems.

We asked AMD’s Soni Jiandani directly about the benchmark methodology because comparisons this aggressive will naturally attract attention; and deserve scrutiny.

[Listen to AMD’s Soni Jiandani’s explanation of the benchmark’s validity].

Our takeaway is not that AMD exaggerated its results. Nor is it that Nvidia has somehow disproved them. Despite Soni’s response, the honest answer is that we do not yet have sufficient independent evidence to declare a production winner. AMD presented ambitious engineering claims, supported by its own internal benchmarks against Nvidia’s published product specifications. Observers would be wise to assess workload assumptions, configurations, optimizations, etc. We’ll also be interested in Nvidia’s own internal analysis once it gets a hold of AMD’s products. Regardless, the most important proof will be independent validation on real workloads – and ultimately production experiences.

And this Breaking Analysis, or any of our analysis for that matter, does not rise or fall on keynote claims and vendor benchmark numbers.

Engineering claims deserve engineering evidence. Specs establish potential. Benchmarks establish a claim. Production establishes truth. What matters in our view is whether Helios delivers sustained performance, software maturity, high utilization, operational reliability and compelling economics when customers deploy it at scale.

And this connects directly back to Engineering Velocity.

AMD pulled a strong move at Advancing AI by claiming top gun at their event.  That’s not the main issue. What really matters is whether AMD can learn from production, repair defects, improve software, incorporate customer feedback and make Helios materially better with every release. Because the benchmark debate will ultimately be settled in operating environments – not on keynote slides.

That is why execution becomes the ultimate test. Helios is simply the first proving ground for whether AMD’s networked engineering model can convert its ambition into repeatable production outcomes.

Ultimately, Engineering Velocity only matters if it can be translated into customer success.

AMD has already cleared several important hurdles. The architecture is defined. The silicon is coming into focus. The portfolio has expanded dramatically. As we said last week, AMD has compressed a 15 year Nvidia lead into five years through organic R&D, M&A and ecosystem expansion. Let’s agree that the customer partnerships are substantial and virtually all leading players want an alternative to Nvidia to keep them honest, improve negotiating leverage and secure more supply. And with AMD making bold claims about performance and economics, many in the industry will cheer. But this race is just getting started and AMD has lots to prove.

The production journey as we know is filled with danger and is often unforgiving. A compelling vision has to become an integrated architecture. The architecture has to survive customer qualification. The benchmarks have to translate into sustained utilization. The software has to become dependable. And the complete system has to deliver operational excellence – not once in a controlled environment, but repeatedly, across thousands of accelerators running expensive workloads for days or weeks at a time.

That is where Helios becomes critical.

Not because this entire analysis depends on one rack design. Helios is simply the first major proving ground for AMD’s networked engineering model. The company must demonstrate platform integration across EPYC, Instinct, ROCm, networking and rack-scale systems. It must prove software maturity, operational readiness and production reliability. And importantly, the ability to absorb field experience and improve the platform quickly once customers begin deploying it at scale.

TensorWave CEO Darrick Horton was extremely candid on this point.

According to Horton, TensorWave already has access to Helios, but he described the current period as testing and validation ahead of production. He acknowledged that there will be issues to work through – but also expressed confidence that AMD has learned from the difficulties associated with earlier next-generation rack-scale deployments across the industry – namely those of Nvidia.

That’s a reasonable way to think about this in our view.

The existence of early problems would not, in and of themselves, invalidate the architecture. Every major new rack-scale system introduces new challenges in power, cooling, cabling, networking, software and serviceability. The real measure we think is how quickly the engineering system detects those problems, identifies root causes, deploys fixes and incorporates the lessons into the next release.

That is this idea we’re putting forth of Engineering Velocity in production. And the broader lesson extends well beyond AMD. This report began as an assessment of Lisa Su’s claims at Advancing AI. But it has evolved into a larger question about how AI companies compete.

The market will not remember who won the keynote benchmarketing. It will remember which platform delivered reliable production outcomes – and which organization learned fast enough to improve those outcomes continuously.

Execution, not ambition, determines credibility.

And that leads directly to our action item:

How should infrastructure operators and ecosystem partners evaluate platforms when current benchmark leadership may be less important than the demonstrated ability to improve?

Let’s close where we began. The obvious debate coming out of Advancing AI was Open Co-Innovation versus Extreme Co-Design.  But we think this is much more than a debate about open vs. closed. Nvidia will respond – and already has with its version of open with Nemotron and open weight models, Spectrum-X based on standard protocols and early this week, Nvidia announced the Open Secure AI Alliance along with three dozen high profile companies. Nvidia is contributing open models, model weights, data and new agent harness research to the alliance to accelerate the development of novel cybersecurity tools and techniques.

And so it goes.

We believe the less obvious and more interesting competitive takeaway is about organizational and ecosystem learning.

Nvidia and AMD are pursuing Engineering Velocity through fundamentally different models. Nvidia’s integrated engineering system emphasizes tight architectural control, coordinated roadmaps and optimization across silicon, software, networking and systems. AMD’s networked engineering system seeks to expand the learning loop through customers, partners, open standards and broader ecosystem participation.

Neither model wins by definition alone. The winner will be the platform that can learn from production faster, validate changes more rigorously, repair problems more quickly and translate those lessons into sustained improvements across the entire system that drive value for customers.

So here is our Breaking Analysis Action Item for AI infrastructure operators and ecosystem partners:

Over the next 6 to 18 months, add Engineering Velocity to your platform qualification evals – and use it to determine both where you deploy and where your organization can create differentiated value. If installing Helios in your neocloud can drive incremental revenue and customer value; and bring sorely needed AI capacity to your customers – that makes sense. If reselling an AMD Helios means your value add is simply a distribution channel for AMD’s new rack, depending on your business model and margin goals, that might not be the best fit. 

Moreover…Do not evaluate a platform only by where it sits today.

Measure how quickly it is improving. Look at time to day-zero support for important new models. Evaluate software release cadence. Assess continuous integration and validation coverage. Monitor production reliability and utilization. Measure time to detect and resolve failures. Focus on the quality of customer co-development. And importantly, judge management’s record of delivering the roadmap.

For infrastructure operators, that means qualifying platforms on current performance and demonstrated rate of improvement.

For ecosystem partners, it means choosing the platform where your engineering contribution can create genuine differentiation – not merely another channel for reselling the same hardware.

Strategic optionality still matters. But optionality should not mean spreading resources indiscriminately across every architecture. It means identifying the ecosystems whose engineering systems are improving fast enough to earn deeper qualification, investment and participation.

The next generation of AI leaders will still have to build and ship great chips. No doubt about it. But their sustainable, durable and differentiable advantage will be defined by the engineering systems they build to make the entire platform – i.e. silicon, software, networking and operations – better, faster than anyone else.

In the AI infrastructure era, today’s benchmark leader may not prove to be tomorrow’s most valuable platform. The fastest-learning platform may very well be the deciding factor.

Image: theCUBE Research