Welcome to
the Forum

Engineering teams building with generative AI are facing a challenge: How do you move faster while making sure customers can trust your technology? Recently, Solidigm’s Jeniece Wnorowski and I sat down with Priya Sawant, senior vice president of engineering at ASAPP, to talk through that tension. ASAPP builds the chat and voice AI agents that power contact centers for large enterprises, and Priya’s teams sit at the center of a shift redefining how engineers work and what they build. ‍

Speed Without Sacrificing Trust

Priya described the change as twofold: Her engineers now write code with a different set of tools, and the products they ship look different, too. Generative AI is probabilistic by nature, she said, and you have to make sure that your customers believe that your technology is doing exactly what you’re saying it’s doing. Building evaluation outputs and visibility into agent behavior became a priority for her teams. Speed matters at ASAPP, she said, but not at the cost of the hygiene that earned the company its customers in the first place.

Golden Pathways’ to Adoption

Priya said her platform teams design tools that make engineers’ jobs easier, creating “golden pathways that everyone else can follow.”  

She breaks the discipline into three phases:

1. ‍Design: Teams interview internal users to understand their problems and craft solutions to address them. ‍
2. Build: Teams pull out the backlog item most needed now. ‍
3. Adoption: A surge of early interest settles into steady, lasting use.  

A platform built without attention to developer experience creates friction, Priya said, and friction kills adoption.  

Look for the Common Denominator

Priya said that when addressing internal engineering problems, you have to identify “the common denominator of the challenges that you want to solve for” and provide flexibility on top of that. Security and reliability, for example, stay fixed, while other components are more pliable. She pointed out that bottom-up adoption, spread through engineer-champions who find real value early and convey that enthusiasm to their peers, works better than top-down mandates. ASAPP borrows a page from open-source communities here, running user groups where engineers weigh in on different tools and the build plan.  

The Expanding Surface Area

Platform teams still do what Priya calls “glue work”: stitching disparate systems into a coherent experience for internal customers, and AI tools are giving these teams the same productivity boost that product engineers already enjoy. But with this boost comes more complexity: The surface area that platform teams need to cover has grown fast, spanning new models, inference platforms, frameworks and experimentation tools that shift by the week. ASAPP’s own tooling shows that shift in miniature. Engineers used to build language-based frameworks that baked in the company’s best practices, making it easier to spin up a new service. Now the team builds a base agent framework so that anyone plugging a new agent into ASAPP’s platform starts from a shared foundation rather than building one from scratch. That same instinct shows up in the product itself, as an observability suite letting enterprise customers verify that their deployed agents hold to business policy, paired with what Priya calls “the agent flywheel”: a system that mines usage data to surface the next automation opportunity. Human-in-the-loop design rounds out the approach, keeping a person in the workflow wherever regulation or customer preference calls for one.

The TechArena Take

Priya’s conversation offers a lesson for engineering leaders navigating the AI transition. Successful teams will build evaluation, observability and developer experience into the product at the start instead of patching them on after something breaks. Underneath all of it sits a storage and compute layer that has to keep pace with what these agents demand. ASAPP’s golden-pathway approach to platform engineering, paired with attention to what internal engineers need, offers a working model for enterprises that want to move fast on AI without losing the trust that took years to build.

To hear the full conversation, listen to the podcast episode or visit asapp.com.

Global data center power demand is projected to rise 27% in 2026 to 132 GW, en route to roughly 290 GW by 2030, per recent industry forecasts.  

In the latest edition of The Control Plane, guest Zane Ball, chief technology officer of the Open Compute Project Foundation (OCP), joined hosts Allyson Klein, CEO of TechArena, and Colin Brix, Vice President of Marketing at AMI, a Lattice company, to discuss the growth of open hardware and what Zane calls the upcoming “golden age of firmware.”

Zane spent almost 30 years at Intel, most recently leading its data center and AI engineering team, before retiring and joining OCP. OCP was founded 15 years ago after Facebook and other hyperscalers started designing their own servers and going directly to Taiwan’s ODM ecosystem for manufacturing. What began as a gathering of a few hundred people has grown into a community of more than 500 member companies collaborating across over 150 technical projects, grown to more than 10,000 attendees at OCP’s most recent global summit.

AI and Open Hardware

The conversation centered on why open hardware matters more, not less, as AI scales. Zane explained that AI’s tightly coupled nature, where chip design, model design, software, the data center, and the power grid all influence one another, creates real pressure toward proprietary, vertically integrated stacks. That approach pays off short term, he said, but grows costly once an operator needs to adapt to a different geography, climate, or energy profile.  

As Zane put it, “Fragility is the reason proprietary solutions can be challenged.” Finding the right interface points is what allows competition and innovation to flourish both above and below them, he added.

That thinking carries directly into what Zane sees as a defining shift for the industry: firmware’s rising importance. He said the industry is entering “a golden age of firmware,” driven by AI data centers that bring together battery energy storage systems, low-voltage DC power, liquid cooling units, and IT racks, all of which need to read the same telemetry and act in concert.  

A major benefit of interoperable systems is improved reliability. “AI systems are not super reliable. With cloud systems, you can isolate every piece of the machine from every other piece. AI systems aren't like that. If one GPU goes down over here, it affects everything else. If you have better manageability, better firmware, and better collaboration across all these systems, guess what? You can build more reliable systems,” said Zane.

Power grid opportunity

According to Zane, citing studies from the Duke University Nicholas Institute, if the power grid could curtail demand for just half a percent of the year, roughly 44 hours, close to 100 gigawatts of capacity that already exists in North America would become available today. This statistic illustrates the other big opportunity for open source. If data centers could flex their consumption during rare grid stress events, the industry could unlock enormous latent capacity without new infrastructure.  

Colin brought the firmware vendor’s perspective to the discussion. AMI has spent 40 years managing the disaggregated hardware that makes platforms work, and the company is stepping out of a purely behind-the-scenes role.  

“We’ve been this quiet player that just makes things work,” he said, adding that AMI wants to bring the voice of the end customer upstream, so reliability and security get designed in early rather than addressed after deployment.

Asked whether operators will start demanding open source firmware in their RFPs, Zane said many already do. Most cloud companies use open BMCs rather than proprietary manageability firmware, largely because they want visibility into the code running in their own data centers.  

Not every layer needs to be open, he added. A BIOS configuring registers close to the silicon can reasonably stay proprietary, while the bigger opportunity lies in the layer above it, where firmware delivers security and manageability features across the whole data center. Taking inspiration from Robert Frost’s famous line ‘good fences make good neighbours’ which his old colleague Jim Keller often quoted, Zane said the goal is to build clear interfaces that let each layer of the stack innovate independently.

Key takeaway

Zane’s conversation makes a clear case for open innovation in firmware. The bigger opportunity extends past the data center walls: if operators, chipmakers, and firmware vendors like AMI agree on the right open interfaces, the industry can unlock existing grid capacity, improve reliability, and avoid the fragility of fully proprietary stacks.

With AI deployments fundamentally changing the data center infrastructure conversation, firmware has become the trusted source of telemetry driving automated decisions across workload placement, power balancing, cooling optimization, and predictive maintenance.

For our last 5 Fast Facts Q&A in our summer series on AI infrastructure requirements, we sat down with Colin Brix, vice president of marketing at AMI, a Lattice Company, to discuss the critical role firmware plays in managing the components of the AI stack and AMI's emphasis on an open, unified codebase. Here's what we learned.

Q1: AMI's firmware runs from the BIOS and BMC on a single server up to fleet-level management across a data center. What are operators asking that firmware to do today that they weren't a year ago?

A: A year ago, operators were primarily focused on server health, uptime, and traditional infrastructure monitoring. Today, AI deployments have fundamentally changed the conversation.

Operators are demanding much deeper visibility into the resources that directly impact token production and infrastructure efficiency. That means granular telemetry around GPU performance, accelerator utilization, power consumption, thermal behavior, interconnect performance, and rack-level power dynamics. They are also asking firmware to provide increasingly sophisticated power management capabilities, allowing them to optimize performance-per-watt without sacrificing workload throughput.

Just as importantly, operators are looking for real-time data that can feed higher-level AI factory orchestration systems. Firmware is no longer just reporting health status. It's becoming the trusted source of telemetry that drives automated decisions around workload placement, power balancing, cooling optimization, and predictive maintenance.

In short, firmware is evolving from a management layer into a data and control layer for the AI factory.

Q2: The boot-to-workload chain is invisible when it works and everything when it doesn't. Where in that chain do AI deployments most often run into trouble?

A: The biggest challenges emerge at the intersection between rapidly evolving hardware and increasingly complex software stacks.

AI infrastructure combines CPUs, GPUs, accelerators, networking fabrics, storage, power systems, and orchestration software that often come from multiple vendors. Any mismatch in firmware versions, configuration settings, security policies, device initialization, or hardware inventory can create failures that are difficult to diagnose and expensive to resolve.

What makes AI environments unique is that issues that might only affect a single server in a traditional environment can impact an entire training cluster. A node that is misconfigured, running an inconsistent firmware level, or failing attestation checks can prevent thousands of GPUs from operating at full efficiency.

This is why operators place such a premium on consistency and trust throughout the boot chain. Secure provisioning, firmware integrity validation, hardware attestation, and automated fleet-wide lifecycle management have become critical because the cost of a single misbehaving node is dramatically higher in an AI environment.

From AMI's perspective, success comes from creating a trusted and repeatable path from power-on to productive workload execution across the entire fleet.

Q3: MegaRAC OneTree pulls management of compute, power, cooling, and networking into one open codebase across different silicon. What changes for an operator when those sit in one place instead of separate tools?

A: MegaRAC OneTree's unified codebase enables operators to focus on maximizing the token output of their AI factory instead of spending time maintaining dozens of independent management stacks.

With separate management domains, every platform, subsystem, and vendor often comes with its own codebase, update cycle, security process, telemetry model, and operational workflow. That creates tremendous operational complexity and introduces risk every time an update or security patch must be deployed.

A unified codebase changes that equation. When a vulnerability is discovered or a feature enhancement is required, it can be addressed once and propagated consistently across the heterogeneous fleet. Operators gain a common operational model regardless of whether they're managing compute nodes, accelerators, power infrastructure, cooling systems, or networking equipment.

Equally important, every component speaks the same language. Telemetry becomes normalized, automation becomes simpler, and fleet-wide optimization becomes practical. By creating uniformity across a heterogeneous AI factory, OneTree removes friction from daily operations and allows teams to focus on efficiency, performance, and scale rather than infrastructure complexity.

Q4: As fleets scale into AI factories, what has to be true about telemetry and automation for one team to actually run tens of thousands of nodes?

A: At AI factory scale, telemetry must be accurate, consistent, and synchronized.

Decisions about workload placement, power allocation, thermal management, and capacity planning are only as good as the data feeding those decisions. Accurate telemetry combined with precise timestamps is essential because operators are increasingly correlating events across thousands of systems simultaneously.

Beyond accuracy, standardization and unification become absolute requirements. AI factories are inherently heterogeneous environments containing compute platforms, accelerators, networking fabrics, power infrastructure, cooling systems, and storage resources. If each subsystem exposes different management interfaces and telemetry formats, automation becomes fragile and operational overhead grows exponentially.

Successful operators require systems that expose common telemetry models, common APIs, and common lifecycle management processes. Only then can automation safely aggregate fleet-wide data, identify anomalies, trigger remediation actions, and maintain optimal performance at scale.

The reality is that nobody manually operates a 50,000-node AI factory. The telemetry and automation architecture must be designed so the fleet effectively manages itself, with humans focusing on policy and optimization rather than individual device administration.

Q5: What does an operator need from the control plane to be able to promise a predictable and trustworthy cost per token?

A: A predictable cost per token begins with complete visibility and control across the entire AI factory.

Operators must continuously optimize compute utilization, networking efficiency, power consumption, and cooling performance on a second-by-second basis. Any blind spot or inconsistency directly affects infrastructure efficiency and drives up token costs.

To achieve this, operators need a control plane that is fast, reliable, and unified. They need a single operational framework that provides trusted telemetry, consistent automation, and coordinated management across all infrastructure domains. Their engineering teams should spend their time optimizing AI production rather than reconciling conflicting data sources or maintaining multiple management stacks.

Trust is equally critical. The control plane must be built on a common hardware root of trust that validates systems from initial power-on through workload execution. Operators need assurance that every system in the fleet is running authorized firmware, trusted software, and verified hardware.

Ultimately, predictable cost per token requires three things: trusted data, automated optimization, and strong security. AMI's role is to provide the foundational management infrastructure that enables all three at AI factory scale.

As AI inference workloads shift toward agentic AI, memory capacity increasingly determines the cost to serve them.

This summer, TechArena has been asking the companies that build AI infrastructure how their requirements are changing as deployments scale. We sat down with Randy Kreiser, Field CTO at Graid Technology, which has developed a portfolio of storage performance and resilience products. Using GPU-accelerated RAID for KV cache offloading, he said, makes time to first token (TTFT) roughly three times faster than running with no cache offload at all.

We also discussed what a storage tier has to deliver to keep pace with the GPU and where storage fits into the industry's shift toward rack-scale AI systems designed as a whole. Here's what we learned.

Q1: AI infrastructure conversations used to start and end with FLOPS, but inference has moved the constraint to memory. From your vantage point, how did memory become the gating factor for inference economics, and why can't GPU memory alone solve it?

A: Training is limited by how fast you can process data; inference is limited by how much conversational state you can keep available. Every active request carries a KV cache, the model's working memory of the conversation, and cache demand grows with context length and concurrent users, not simply with model size.

That matters especially for agentic AI. A long-running multistep agent can create substantial cache demand even when GPU compute is not the limiting resource. The constraint is not the GPU; it is the memory available to hold and reuse state.

GPU memory alone cannot solve the problem economically. HBM comes attached to an accelerator, so adding memory often means buying compute you do not need. When cache capacity is exhausted, the system evicts state and recomputes it later. GPU utilization may still look healthy, but useful work declines because the system is regenerating context it already processed.

Q2: KV cache offloading essentially turns NVMe storage into an extension of the memory hierarchy. What has to be true of the storage layer for that tiering to work at inference speed rather than becoming the next bottleneck?

The cache must be faster to retrieve than it is to recompute. If it is not, offloading simply adds latency to the inference path.

A: The threshold is higher than many teams expect. In a controlled vLLM and LMCache benchmark using a 235 billion-parameter MoE model across four NVIDIA H200 GPUs, Linux MD RAID5 increased TTFT from 29.4 seconds with no offload to 36.6 seconds. Adding protection to an insufficiently fast storage path can make inference worse, not better.

For NVMe to serve as an effective inference-memory tier, it needs:

• A direct path into GPU memory, avoiding unnecessary host-DRAM copies.
• Predictable tail latency, because inference SLAs are governed by p99 behavior, not average bandwidth.
• Sufficient capacity in a unified namespace, avoiding manual tier management.
• Resilience without a runtime performance penalty; a rebuild cannot cut production throughput in half.

Miss any one of these, and the storage tier becomes the next bottleneck. Graid Technology's innovative volume management capabilities deliver all of these.

Q3: Traditional RAID architectures were built for a CPU-centric world and burn the very cycles and PCIe lanes AI servers can't spare. What convinced Graid Technology that RAID logic belonged on the GPU, and what does that unlock in an AI data center that a hardware RAID card or software RAID can't?

A: RAID is fundamentally parallel parity math: XOR and Galois-field operations. Traditional architectures placed that work on a RAID-controller ASIC because CPUs were poorly suited to it and there was no better parallel processor in the server.

That is no longer true. Modern AI servers already contain massively parallel GPUs, while NVMe has exposed the limits of conventional RAID designs. A hardware controller can become a bandwidth ceiling as Gen5 NVMe arrays scale up. Software RAID avoids that controller bottleneck but consumes host CPU cores and PCIe resources that AI workloads need for feeding accelerators.

GPU-accelerated RAID changes the tradeoff: SupremeRAID AE uses a small portion (approximately 4% or 6 SMs) of an installed GPU rather than a dedicated RAID card, preserves host CPU resources, and enables a direct storage-to-GPU-memory path. The result is protected, high-throughput storage designed around the AI server rather than bolted onto it.

Q4: You've positioned SupremeRAID AE around KV cache offloading, citing roughly 3x improvement in TTFT. Walk us through how GPU-accelerated storage changes the inference pipeline in practice. Where do those gains actually come from?

A: Correct, we measured 3.26x faster TTFT than no offload and 4x faster than Linux MD RAID5, reducing mean TTFT from 29.4 seconds to 9.0 seconds.

The gain is not merely faster storage. It comes from avoiding unnecessary GPU computation. TTFT is heavily influenced by prefill, the work required to process the full prior context before the model can generate its first token. In long-context agentic workflows, that prefill work is expensive and often repeated.

When the KV cache already exists, the system can retrieve it instead of recomputing it. A sufficiently fast storage read is far cheaper than rerunning attention across a large context window. That releases GPU cycles for decoding and serving additional requests. The business case is simple: Fetch must beat recompute. If it does not, the offload tier works against you. SupremeRAID is proven to be faster than recompute.

Q5: The industry is moving from components bought off spec sheets to rack-scale systems designed as a whole. As storage becomes a design partner to the GPU rather than a peripheral, how does Graid Technology's roadmap fit into that integration story, and what does storage look like in the AI data center two years out?

A: Our Agentic AI Storage Portfolio is organized by deployment scale, KV Cache Server, KV Cache Rack and KV Cache Platform, rather than by individual SKUs. That reflects a shift in AI infrastructure design: Once the rack is the unit of deployment, storage cannot be treated as a component to integrate afterward.

KV Cache Platform aligns with NVIDIA's STX reference architecture. The roadmap includes native BlueField-4 DPU execution in H2 2026 and expanded drive-count support, allowing one SupremeRAID instance to span multiple CMX chassis and present a virtualized pool to an entire rack of STX nodes.

Over the next two years, storage will increasingly be evaluated in inference outcomes rather than raw capacity: cost per million tokens served, cache-hit rate, and TTFT. Terabytes remain necessary, but they stop being the headline metric. RAID and I/O processing will follow the available parallel compute, from GPUs today to DPUs in the next phase.

Co-packaged optics change manufacturing and integration requirements for electro-optic polymers, said Robert Blum, senior vice president of sales and marketing at Lightwave Logic, which develops EO polymers. That means much closer integration with the switch ASIC, CPU or GPU, he said, along with hybrid bonding processes that run at higher temperatures than optical assemblies for pluggable transceivers.

This summer, TechArena has been asking the companies that build AI infrastructure how their requirements are changing as deployments scale. We sat down with Robert, who discussed where interconnect materials science needs to go next, what separates EO polymers from competing approaches, and what's standing in the way of faster industry-wide adoption of optical solutions over copper. Here's what we learned.

Q1: Copper, pluggables and now co-packaged optics have each marked a step change in how data moves inside the data center. Where does interconnect materials science need to go next to keep pace with AI bandwidth demand?

A: There has been tremendous progress in both the materials used for lasers and modulators. III-V materials have improved, enabling higher-power lasers and electro-absorption modulators up to 200 Gb/s per lane. Silicon photonics has improved, achieving 200 Gb/s with micro-ring modulators and highly doped p-n junctions.  

But new materials are required for the next modulator generation where 400 Gb/s speeds are needed. That's where thin-film lithium niobate and electro-optic polymers come into play. We see strong momentum behind EO polymers, because they can be easily integrated into standard silicon photonics foundry processes.

Q2: Electro-optic polymers are one of several competing approaches to improving modulator performance, alongside indium phosphide and lithium niobate. What does the industry still get wrong about how these materials compare?

A: EO polymers have really improved in performance and reliability, thanks in part to the lessons learned from the OLED industry, and are now ready for deployment. They integrate much more easily with silicon photonics than lithium niobate, so the foundries love these materials. And customers like them because they can enable much more compact modulators with lower drive voltages than lithium niobate. The real race is about ramping production capacity and getting the 400G ecosystem in place.

Q3: Given copper's physical limitations in the interconnect layer as data rates climb, what is the bottleneck to faster adoption of optical solutions industry-wide?

A: Optics tends to be more complicated than copper. High-fiber-count detachable optical connectors are one of the bottlenecks. Form factors for optical engines are not standardized, so many solutions are proprietary or require custom designs and packages.

Silicon photonics foundries have ramped capacity at astonishing rates, but lead times can still be quite long. On the other hand, there is a large payback for going to optical at these higher data rates, so many suppliers are eager to make the transition.

Q4: Lightwave Logic is developing electro-optic polymers that can be used for co-packaged optics (CPO) in AI and hyperscale data centers. What does co-packaging change about the requirements for your polymer, versus a pluggable transceiver?

A: Optical assemblies that go into pluggable transceivers tend to have more forgiving process requirements. Going through standard solder reflow or wire bonding is one of the main requirements.  

For CPO, you need to integrate much more tightly with the switch ASIC, CPU or GPU. So you potentially start to look at hybrid bonding, which has higher processing temperatures and also much more complex assemblies in general. All this requires much closer collaboration with system integrators.

Q5: With five Fortune Global 500 customers actively engaged in prototype testing, what's the biggest technical gate left between prototype and the high-volume production you're targeting for 2027?

A: There are several items that are required for true high-volume production: Silicon photonics foundries need to mature their slot waveguide processes, which means that the doping profiles and slot dimensions, for example, are within their required tolerances.  

The back end of line process transfer needs to be completed and qualified. And customers need to complete the design and qualification of their own module.  

Finally, the rest of the 400G per lane ecosystem needs to be ready, which typically is focused on DSPs and SerDes but may also include new optical and electrical connector assemblies and higher-power laser sources.

This summer, TechArena has been talking to the companies building the power and cooling infrastructure behind AI data centers.  

We caught up with Rich Whitmore, president and CEO of Motivair by Schneider Electric, which designs and manufactures liquid cooling systems, including coolant distribution units, for high-density AI and HPC deployments.

As rack densities climb and heat removal becomes as critical to AI deployment as power delivery, liquid cooling has become a foundational part of data center design from the outset. We talked about how Motivair builds cooling into AI projects from the beginning, how far liquid cooling can scale as rack power keeps rising, and what the company is engineering next as AI infrastructure demands continue to grow. Here’s what we learned.

Q1: Cooling has moved from the back of the house to the center of the design. How does Motivair help operators build cooling in from the start rather than add it at the end?

A: Cooling is now a foundational design decision for AI infrastructure. Motivair works alongside Schneider Electric’s power and digital infrastructure portfolio to help customers design liquid cooling into the project from day one. That integrated approach supports higher-density computing, simplifies deployment and helps customers reduce time to power by avoiding costly redesigns later in the project.

Q2: As rack power keeps climbing, how far can liquid cooling scale, and what changes along the way?

A: Liquid cooling is designed to scale alongside the growing demands of AI, from today’s high-density racks to tomorrow’s AI factories. As rack power increases, the challenge shifts from simply removing heat to delivering reliable, efficient and scalable thermal management across an entire facility. Motivair by Schneider Electric is advancing this next generation of liquid cooling with solutions such as coolant distribution units designed to support multimegawatt AI deployments and beyond. The future of cooling requires deeper integration with power, controls and digital infrastructure so operators can deploy faster, optimize performance and support the next wave of AI workloads.

Q3: What separates cooling that works for a supercomputer from cooling that works across thousands of racks in production?

A: Production environments require more than excellent thermal performance. They require repeatability, uptime, ease of service and seamless integration with the rest of the infrastructure. Motivair combines decades of liquid cooling expertise with Schneider Electric’s end-to-end infrastructure capabilities to help customers deploy AI at scale while reducing operational complexity and accelerating deployment.

Q4: When an operator chooses Motivair over another cooling option, what usually tips the decision in your favor?

A: Customers are looking for proven technology backed by deep engineering expertise and the ability to deploy quickly. Motivair offers high-performance liquid cooling that is part of Schneider Electric’s broader AI infrastructure portfolio, giving customers confidence that power, cooling, controls and services are engineered to work together. That integration helps reduce project risk and improve time to deployment.

Q5: What are you engineering for next, beyond today’s deployments?

A: The industry is moving toward even higher-density AI infrastructure with greater demands for efficiency, flexibility and speed of deployment. We’re focused on advancing liquid cooling technologies, expanding manufacturing capacity, and developing integrated solutions that help customers deploy next-generation AI infrastructure with greater confidence, scalability and operational efficiency.

The cost of serving a model increasingly comes down to how fast accelerators can move data between one another as AI inference workloads shift toward multistep reasoning and mixture-of-experts models.  

Faster chips are not the answer, said Aanchal Sharma, senior director of product management at Astera Labs, because they buy more compute, not less waiting. Put the fastest chip in the world behind a slow fabric, and you have built what she calls “an expensive space heater.”

We sat down with Aanchal as part of our series about how companies that build AI infrastructure are seeing requirements change as deployments scale. Astera Labs builds fabric switches and connectivity products that let AI accelerators from different vendors work together inside a rack.  

She talked about what it takes to prove multi-vendor interoperability before deployment, why Astera Labs builds Scorpio and Taurus as open rather than proprietary interconnects, and where the fabric has to scale next as clusters grow toward hundreds of thousands of accelerators. Here’s what we learned.

Q1: Rack-scale AI infrastructure now depends on many vendors' silicon working together inside one system: accelerators, memory and fabric all from different suppliers. What does that interoperability require in practice, and where does it tend to break down?

A: At rack scale, physics doesn't care whose logo is on the silicon. A GPU from one vendor, a CPU from another, memory from a third: They all have to hold a stable low-latency link under real production traffic every hour of every day for years. That's the bar.  

Most failures show up exactly where you'd expect: signal integrity breaking down across longer or noisier channels, firmware that was never tested together choking on link training, and faults that only appear once hundreds of accelerators fire the same collective operation at the same instant.  

We stress-test these exact combinations in our Cloud-Scale Interop Lab before a customer ever racks a single unit so customers can deploy with confidence and focus their engineering resources on AI innovation rather than infrastructure integration challenges.

Q2: Fabric switches and retimers now have to work across GPUs, CPUs and memory sourced from different vendors within the same rack. What does proving that kind of multi-vendor interoperability involve before a customer can put it into production?

A: It involves validating the rack as a complete system, not just each component in isolation.  

We re-create the customer's topology with the specific CPUs, GPUs, memory devices, fabric switches and retimers, then test across operating systems, software stacks, workloads and protocols. Working with ecosystem partners, we use co-emulation, test automation and continuous regression testing to identify compatibility issues and confirm seamless integration before deployment.

The result is a validated configuration that reduces integration risk and accelerates time to deployment. That's the entire point of an interop lab: catch every integration risk on our bench months before a customer ever has to.

Q3: Astera Labs builds Scorpio and Taurus as open multi-vendor scale-up fabric rather than a single vendor's proprietary interconnect. What does an open fabric let operators do that a closed single-vendor interconnect can't?

A: An open fabric means an operator never has to bet the entire rack on one company's roadmap. Mix the best GPU with the best CPU with the best memory; swap a supplier when lead times blow out; carry hardware forward across generations instead of tearing it out.  

Taurus supports this model across Ethernet, UALink and ESUN, while Scorpio provides an open software-defined fabric architecture that supports diverse accelerators, system topologies, and both open and platform-specific protocols.  

Compared with a closed interconnect, this keeps architecture and supplier choices open as performance, availability and platform requirements change.

Q4: As inference moves into production, a growing share of what it costs to serve a model comes from moving data between accelerators, not from the accelerators themselves. Why can't faster chips alone fix that?

A: Faster chips buy more compute. They don't buy less waiting.  

As inference workloads move toward multistep reasoning and mixture-of-experts architectures, more of the total job becomes accelerators talking to each other rather than accelerators doing math. Put the fastest chip in the world behind a slow, high-latency fabric and you've built an expensive space heater, with GPUs sitting idle waiting on data instead of generating tokens.  

That's exactly why Scorpio builds acceleration for collective operations, like Hypercast, directly into the fabric; why Taurus keeps those links clean and low power across Ethernet, UALink and ESUN as clusters scale; and why COSMOS gives operators the visibility to find and kill communication bottlenecks in real time. Tokens per watt and tokens per dollar get decided in the fabric long before anyone reads a chip's spec sheet.

Q5: As clusters grow toward hundreds of thousands of accelerators spread across racks and rows, where does the connecting fabric have to go next? How do open standards and products built on them fit that path?

A: The fabric has to scale in three directions at once: scale up inside the rack, scale out across racks and rows, and increasingly scale across between clusters and sites.  

Scale-up keeps pushing toward higher radix and lower latency inside the rack. Scale-out has to connect racks and rows without the distance tax of added latency and cost eating the gains. Scale-across is the newest of the three, holding performance together across distances that scale-up and scale-out were never built to cover.  

That means more optical connectivity, higher-density switching, and fabric that carries intelligence, not just bits, accelerating collective operations instead of passively relaying them. Open standards like CXL, Ethernet, PCIe, UALink and ESUN give customers one way to build that path without betting the company, but that's only part of the story. Some of the largest deployments we support run on NVLink Fusion, and others need a fully custom link built around one customer's architecture. Products like Taurus and Scorpio are built to make all three paths work.

As new AI cloud providers appear, many compete on a single number: how many GPUs they can rent by the hour. Dan Brown, who leads hardware engineering at DigitalOcean, sees the real contest elsewhere. In a recent TechArena Data Insights episode, Solidigm’s Jeniece Wnorowski and I talked with Dan and Solidigm account executive Ty MacAdam about building and delivering holistic data center infrastructure solutions for AI workloads. Dan's argument was consistent throughout: raw GPU capacity means little if data cannot reach it quickly, and that is where DigitalOcean is placing its bet.

The Data Velocity Problem

Dan frames the core AI infrastructure challenge around three factors: where and how data sets are captured, how quickly that data can travel from its source into an AI cluster, and how fast systems can exchange tokens between systems in the AI cluster to reduce the data down into a meaningful set that can be used for inference. When any of those steps drags, the entire pipeline slows.

“The AI solution designs are limited by what we call data velocity,” Dan said. “How quickly can you get your data in, transform it, and get it back out for next useful step in the pipeline.”

Much of the friction, he noted, comes from customers trying to run modern AI against aging storage. Many arrive with legacy arrays that have been in service for a decade or more, then discover that infrastructure cannot keep pace. Moving that data into DigitalOcean’s high-performance block and object storage, or directly onto the AI machines, is where the gains show up. Solidigm supplies the high-speed NVMes, including PCIe Gen5 drives, that sit close to the GPUs and keep the read and write cycle tight.

More Than a GPU Landlord

Dan is direct about how DigitalOcean differs from the wave of providers rushing into AI hosting. Many, he argues, do one thing only.

“They’re taking GPUs and servers, shoving them into boxes and then selling them by the hour to customers,” Dan said. “We call it a GPU landlord.” With those providers, he explained, customers must bring their own data scientists, hardware engineers, and expertise to make the hardware useful.

DigitalOcean’s answer is a full suite of compute and storage products that surround the GPU and share the same backbone network and data center, tightly coupled to improve velocity. Rather than selling raw capacity by the hour, Dan said, the company is building a unified cloud where every resource around the AI cluster exists to make that cluster faster and more cost effective to run.

Preference-Aware Routing

A clear expression of that approach is DigitalOcean Inference Router, which reads the intent behind each request and matches it to the model that best fits the developer’s task and priorities, whether they are optimizing for quality, cost, or latency, without any application-side routing logic. The approach is grounded in years of preference-aware routing research from the team behind the open-source Arch-Router work, now part of DigitalOcean. Dan described the result as token as a service, and he said the productivity effect has been striking.

Dan said the productivity gain has been dramatic: teams can now prototype a working product for a few hundred dollars in minutes, rather than standing up entire teams of administrators and data scientists to build the back end first.  

Density and the Nanosecond

Asked what organizations still overlook, Dan pointed to density and reached for a piece of computing history. Admiral Grace Hopper famously wore an 11.8-inch-long coil of copper wire. She used this to illustrate that for every such length of copper in a system, a nanosecond of delay is introduced in that system. Across a large AI cluster, Dan noted, miles of copper and fiber add up to real delay.

DigitalOcean’s response is to build the densest possible clusters, adopt liquid cooling, and keep local Solidigm storage on each server so data moves host to host in microseconds rather than milliseconds. That translates directly into shorter compute time, faster time to first token, and lower customer costs.

Ty reinforced the point from the storage side. “Storage used to be a passive layer where everybody just thought of it as where the data would sit. That doesn’t hold up anymore,” he said. “Storage isn’t where the data sits. It’s more about how fast intelligence moves.” He added that Solidigm’s high density quad-level call (QLC) NAND puts more data closer to compute at lower power, which reshapes the total cost of ownership math at deployment scale.

The TechArena Take

DigitalOcean’s message to technology decision makers is a useful reminder to a market fixated on GPU counts. Buying accelerators and fast networking is only part of the equation. If data cannot reach those GPUs quickly, or if teams overspend on oversized models for narrow jobs, the investment underperforms. Refreshing legacy storage, right-sizing a model to a task, treating proximity between data and compute as a design decision rather than an afterthought are practical places to start to get the most out of an AI infrastructure investment. As agentic workloads raise the pressure further, the providers building for velocity, not just capacity, look best positioned for what comes next.

For more information, listen to the full podcast and visit DigitalOcean.com.

The same chip architecture that Axelera AI built for the power, cost and latency constraints of edge vision AI can now also handle multiuser generative AI workloads at the edge, using the same Metis and Europa chip family and toolchain.

We sat down with Manuel Botija of Axelera AI, which builds AI chips for edge devices. Manuel said that expanding capability matters as more AI workloads move beyond the data center and edge devices are asked to run increasingly complex models. Europa, he said, is built to run vision-language models and agentic AI directly on edge hardware.

We also talked about what digital in-memory computing changes about chip performance; how customers worldwide are using Axelera AI’s technology; and what it takes to offer a predictable cost per token as inference workloads grow.  

Here’s what we learned.

Q1: Much of the progress in AI to date has come from scaling the data center, but only a handful of players can build at that scale. Where did Axelera AI see a different path?

A: Most of the industry has tried to scale AI from the data center out to the edge, and that direction has never really worked. Data center architectures are built for abundant power, abundant budget and abundant time. None of that is available at the edge. So the chips and systems built for one environment were getting forced into a location they were never designed for, which meant serious tradeoffs had to be made.

We believed there was a different way and started by holding those “limits” as real limits. We built an architecture that solves for small power envelopes, limited budgets and time from the beginning, because at the edge, those constraints are real.  

Our first architecture, the Metis AIPU, had to hit real performance within a tight power envelope and a real price point, and that discipline is exactly what let us scale to the Europa AIPU without compromising the efficiency we perfected. We have even taken that edge architecture with both Metis and Europa and built server-class products supporting customers globally with full-length, full-height PCIe cards built around multiple AIPUs.

Q2: Axelera AI made its name at the edge with the Metis platform. What are customers using the products you’ve brought to market to solve?

A: Customers are putting Metis to work solving real problems in places most people never think to look.  

A large global convenience store chain uses it for real-time shelf monitoring, catching stockouts as they happen. An agritech company in New Zealand built it into automated apple sorters, and a healthcare technology company in Europe uses it inside an automated pill sorting machine, both cases where accuracy and speed directly affect people’s safety.  

The utilization keeps expanding. A drone company in Croatia deploys Metis in a drone pack built for search and rescue missions. In India, a company built a cargo monitoring system for the country’s busiest port, bringing computer vision to logistics at scale.

These are just a handful of the deployments in production, with new uses for vision and localized models emerging around the world. What stands out is how different these use cases are from one another, and how each one found its way to edge AI because it was the only architecture that could meet their constraints on power, cost and latency at once. It’s a reminder of how much innovation is happening at the edge, in every corner of the world.

Q3: At the heart of your chips is digital in-memory computing on a RISC-V core. What does moving the math into memory change about performance and efficiency?

A: Traditional processors spend most of their energy and time moving data back and forth between memory and compute, especially for the matrix-vector multiplication that makes up roughly 80% of AI inference workloads.  

Digital in-memory computing performs that math directly inside the memory cell, so the data barely has to move at all. That single change removes the biggest bottleneck in conventional architectures and turns into real gains in both speed and power. The RISC-V controlled dataflow is what makes this programmable and precise rather than a fixed-function shortcut. It gives us four independently programmable cores that can run parallel model execution with deterministic, digital accuracy, unlike analog in-memory approaches that trade precision for efficiency.  

That combination is why the Metis architecture delivers up to 15 TOPS per watt and three times better performance per watt than GPU-based solutions, all while keeping accuracy indistinguishable from a full floating-point model. The result is an architecture that scales cleanly. The same principles that made the Metis AIPU efficient at 214 TOPS carry through to the Europa AIPU at 629 TOPS, which means moving the math into memory isn’t just a one-time efficiency trick. It’s the foundation of our roadmap.

Q4: Axelera AI is scaling one architecture from Metis at the edge up to Europa for multiuser generative AI. What does that move open up for your customers?

A: The Europa AIPU is built on the same digital in-memory computing and RISC-V dataflow foundation as Metis, but with meaningful additions: twice the AI cores, native video decode, and 16 vector cores dedicated to pre- and post-processing, all of which make Europa perfectly suited for larger and more complex models and analytics. Those additions are what make native transformer support and multiuser generative AI workloads possible at the edge.

What stays constant for customers is the development experience. The same Voyager toolchain carries across both chips, so a team that built a pipeline on Metis isn’t starting over on Europa. That continuity is what turns an architectural leap into a growth path instead of a rebuild.  

Metis remains an efficient powerhouse for computer vision use cases at the edge, including embedded systems where power and space are tightly constrained. Europa extends that foundation into a highly flexible AI accelerator built for a broader range of inferencing needs, from vision-language models and agentic AI to dozens of concurrent high-resolution video streams running natively at the edge. For customers, that means the same tooling and philosophy they already trust, now available across an even wider set of use cases.

Q5: Two years out, what will separate an inference platform that lets an operator promise a predictable cost per token from one that can’t?

A: Digital in-memory computing removes the data movement bottleneck that makes costs scale unpredictably as workloads grow, so the economics hold steady whether an operator is running a handful of streams or scaling to dozens of concurrent workloads.

The other separator is architectural flexibility. Operators locked into separate chips for CNNs and separate chips for transformer-based models face a cost structure that multiplies every time they add a new model type. A unified architecture that handles both on the same silicon keeps cost per token stable as workloads evolve from vision to generative AI, which is the discipline that will define the platforms operators can build a business on two years from now. Europa delivers that flexibility to customers.

Lastly, when models are run on one’s own infrastructure, the cost per token is much more manageable than running models in the clouds through providers that change cost structures at their discretion. With the Axelera Voyager toolchain, customers can use open-source models tuned to their weights and deploy them in-house. This includes Voyager Wingman, an agentic platform that can build pipelines based on natural language prompts.

Solidigm and io.net discuss neo-cloud economics, GPU pricing, decentralized AI compute, and inference cost cutting versus hyperscaler cloud infrastructure.

We sat down with David Driggers, CEO and founder of Cirrascale Cloud Services, a neocloud that runs dedicated hardware for AI workloads across NVIDIA, AMD, Qualcomm and Tenstorrent accelerators. Cirrascale’s approach is relevant now as enterprises move from proof-of-concept AI deployments toward production and need infrastructure that matches each workload to the chip built for it.

We talked about how Cirrascale matches workloads to the right accelerator as models grow, how its billing model creates cost predictability, and what separates neoclouds built for low-latency inference from those built for training alone. Here's what we learned.

Q1: Why run every accelerator on dedicated hardware?

A: Cirrascale gets classified as a neocloud, but we were building this hardware before the category had a name. We designed the industry’s first 8-GPU server back in 2012 working directly with NVIDIA, and we were infrastructure partners to OpenAI when they were still an 8-10 person team. That hardware DNA is why we can run NVIDIA, AMD, Qualcomm and Tenstorrent side by side, alongside our work with Google on Google Distributed Cloud, and actually know what each one is good for. No single chip serves a 1B-parameter model and a 400B-parameter model economically, so our customers get the accelerator that fits their workload instead of bending their workload to fit whatever one vendor is selling.

Q2: How does billing create predictability?

A: We don’t charge for data ingress or egress, which removes one of the biggest hidden cost swings customers deal with elsewhere. We also give customers the choice between token-based pricing for intermittent workloads and GPU-hour billing for anything running 24/7, so the bill follows how they use the platform. And because we track token consumption at a granular level, customers get real insight into where they’re burning input tokens inefficiently. That data helps them optimize the model, not just the invoice. Inference is forever, as we like to put it, and those costs compound. That’s why we built a cost calculator: Customers can model their own workload before they commit to anything.

Q3: What’s standing between customers and more capacity, and what’s changed?

A: Most enterprises are still in the POC phase with models like Gemini, GPT and Claude, trying to prove utilization before they can get more approved budget. Nobody’s handing out incremental AI spend without proof it moves the needle. That’s part of why we run Private Gemini on Google Distributed Cloud. It gets a frontier model into production inside the customer’s own security boundary instead of leaving it stalled in evaluation. On the hardware side, we’re pushing into multimodal, larger-context inference. What’s changed in the last year is that hybrid deployment, on-prem for steady workloads plus neocloud for real-time workloads across regions, is becoming the norm. I expect that to be standard by the end of this year and accelerate hard through 2027.

Q4: What have you learned matching workload to chip?

A: We built the load balancing in the Cirrascale Inference Platform ourselves, specifically because a model’s ideal hardware changes as it grows. An 8B model that becomes a 70B model isn’t cost-optimal on its original chip anymore, and that kind of migration is really hard to do on-prem. The single biggest cost lever is capacity utilization. The platform puts each workload on the most efficient capacity that still clears its latency target, so customers aren’t paying premium rates for headroom they don’t need.  

Q5: What separates the neoclouds that thrive from the ones that fade?

A: Training and inference are completely different animals. In training, you can run a thousand GPUs and barely notice a network hiccup. In inference, that same hiccup is a failed request in front of a customer. The neoclouds that survive are the ones built for real-time workloads and low latency from the ground up, not the ones bolting inference onto training infrastructure. Carrier-hotel-grade connectivity is a big part of that, which is why we partnered with Telehouse to deploy the Cirrascale Inference Platform inside their data centers. It also means being able to serve regulated industries, where FedRAMP High and CMMC 2.0 are the price of entry rather than a roadmap item. We also give customers real ownership flexibility. Some customers own their GPUs outright while we run the networking and storage around them. And we’re expanding our data center footprint this year to put that capacity and failover closer to where the inference actually happens.

Nicklas Frahm of Corti on domain-specific AI, built-in compliance, and the Kubernetes Engine powering sovereign healthcare infrastructure.

This summer, TechArena has been talking to the companies building the AI data centers of tomorrow.  

We caught up with Steven Carlini, chief advocate for AI and data centers at Schneider Electric, which designs power, cooling and controls for AI facilities as one integrated system. As rack densities climb and utility power becomes the tightest constraint on new AI capacity, how quickly that infrastructure can be designed and deployed is becoming one of the sharpest bottlenecks in the industry.

We talked about the changing role of power in AI projects, what’s driving how fast new AI capacity can come online today, and where the gap is widest between what AI buildouts need and what today’s grid and supply chain can deliver.

Q1: AI infrastructure is shifting from separately bought parts to one integrated system. How does Schneider Electric help operators design power, cooling and control as a whole?

A: AI infrastructure performs best when power, cooling, controls and software are designed as one integrated technology system instead of assembled piece by piece. Schneider Electric acts as an energy technology partner by bringing together electrical distribution, liquid cooling, racks, digital management and services into a unified architecture in the form of reference designs and prefabricated modules. These help customers reduce complexity, uncertainty and risk, and they help accelerate deployment. By designing these systems together from the outset, operators can improve efficiency, simplify operations and reduce time to power for new AI capacity.

Q2: As the rack becomes the unit of design, how is power’s role on an AI project changing?

A: Power has become a strategic enabler of AI deployment. As rack densities continue to climb, we are bumping up against the laws of physics and running out of physical space for the power inputs. Delivering reliable power to each rack is as challenging as delivering liquid cooling and as important as delivering power to the facility. Every decision around electrical distribution, cooling and controls affects how quickly infrastructure can be commissioned. Designing around the rack helps operators maximize available power, support higher densities and bring AI capacity online faster.

Q3: What determines how quickly new AI capacity can come online right now?

A: Today, speed is driven by time to power. Access to utility power or constructing onsite or adjacent prime power (energy parks) dedicated to the data center, electrical infrastructure, cooling and coordinated supply chains all influence how quickly AI clusters can be deployed. Organizations that take an integrated approach to infrastructure planning and use validated, end-to-end solutions can reduce project complexity, shorten commissioning timelines, and accelerate time to revenue.

Q4: Where is the widest gap between what AI buildouts need and what today’s grid and supply chain can deliver?

A: Demand for AI infrastructure is growing much faster than traditional power infrastructure can expand. Operators need more capacity, higher density cooling and shorter deployment timelines than existing facilities were designed to support. Closing that gap requires maximizing every available megawatt through efficient infrastructure, modernizing the grid, streamlining processes for expansion and access, building new energy parks where needed, and deploying integrated and intelligent power distribution solutions that reduce time to power.

Q5: What is the next hard problem in power that the industry hasn’t solved yet?

A: The next challenge is not only securing more power; it is reducing the time it takes to bring that power into service and making every available kilowatt work harder to generate tokens and intelligence. As AI workloads continue to scale, operators need infrastructure that can adapt dynamically across power, cooling and operations. The path forward is not simply adding more capacity but creating smarter infrastructure that helps organizations accelerate time to power while meeting the growing demands of AI. That requires moving from disconnected systems to intelligent, integrated infrastructure. With EcoStruxure, Schneider Electric connects energy, power and facility systems to help operators gain real-time visibility, improve efficiency and optimize performance.

Want to learn more about Schneider Electric's AI data center deployments? Check out this article.

Per aspera ad astra: through hardship, to the stars. It’s a fitting concept for this industry, where the work that gets us somewhere extraordinary can look ordinary. Cooling systems. Fabrics. Data layers. Control planes. These critical systems often don’t get the attention they deserve given they determine how far AI can actually go. When we launched Ad Astra: AI Infrastructure Competition as an official media partner of the 2026 AI Infra Summit, we wanted to aim a light at that work.

We asked for 200 words. Make the case for why your technology belongs among this year’s most significant advances in AI infrastructure. Our judging panel composed of TechArena Advisors evaluated every entry against three criteria:

• alignment to one of the summit’s focus areas

• real-world impact backed by measurable outcomes

• clarity that a senior technical or business decision-maker could absorb without decoding jargon

Today I’m pleased to announce the results.

Winner: Airsys

Airsys took the top spot with LiquidRack, a liquid cooling system built around a straightforward observation: AI is driving rack densities that existing cooling infrastructure was never designed to handle.

Rather than routing cooling through centralized facility infrastructure, LiquidRack integrates it directly into the rack. Airsys makes the case that this changes the deployment math for operators, who can add AI capacity incrementally, expand over time, and extract more compute from the power they already have rather than overhauling an entire facility to get there.

The company backs the approach with specifics. Airsys reports that its patented spray cooling technology transfers heat up to three times more efficiently than conventional approaches, freeing more power for compute. It cites a PUE below 1.02, no water consumption, and roughly 80% less dielectric fluid than immersion cooling. The company also notes that LiquidRack has been validated in customer deployments across multiple industries and geographies, which moves the conversation past the lab.

Our TechArena Advisor Laura St. John gave the following reasoning for choosing Airsys as the winner:

“Airsys’s LiquidRack paired a clear innovation with the strongest real-world evidence in the pool, backed by validated deployments across multiple industries, not just projections. In a field tackling one of AI infrastructure's biggest bottlenecks, cooling density, LiquidRack stood out as ready to deploy today.”

Honorable Mentions

Three additional companies earned recognition from our Advisors.

VAST Data argued that AI has transformed computing while much of the underlying data infrastructure still reflects an earlier era of enterprise IT, with separate storage systems, databases, event streams, and vector stores endlessly copying the same information. The VAST AI OS collapses those layers into a single shared platform. The company says it now powers more than 3 million GPUs worldwide, including AI factories where one system serves over a billion CUDA cores.

Cornelis Networks made a data movement case that emphasizes the network’s critical role in the AI era. The company points to production AI clusters running at 30 to 50 percent model FLOPs utilization, with the gap lost to congestion and synchronization stalls. Its CN6000 SuperNIC carries Omni-Path, RoCEv2, and Ultra Ethernet on a single 800 Gbps adapter. Cornelis modeling indicates AllReduce collectives complete roughly 24 percent faster than standard Ethernet, which the company translates to about 13% less training time for a 250-billion-parameter model on a simulated 10,000 GPU cluster.

Rafay addressed the operational sprawl of running an AI data center, unifying Kubernetes, virtual machines, SLURM, bare metal, GPUs, and AI services under one control plane, with Token Factory extending that model into inference by turning GPU capacity into metered, standardized services. In production environments, Rafay reports improving GPU cluster efficiency by 25% to 40% and supporting three to five times more tenants without adding headcount.

The TechArena Take

The binding constraint on AI infrastructure has moved off the chip and into everything surrounding it, and the companies competing hardest right now are the ones working that perimeter. Airsys addressed thermal and power headroom, VAST Data addressed the data layer, Cornelis Networks addressed movement between GPUs, and Rafay addressed the operational model that holds the whole thing together. Congratulations to Airsys, VAST Data, Cornelis Networks, and Rafay. We will see you in Santa Clara this September.

Read more about our winners here.

Free Tickets and Discounts from TechArena

If you haven’t yet registered for the AI Infra Summit, now is the time to act! As part of our partnership, we’re pleased to offer benefits to our TechArena followers who want to join the conversation in Santa Clara this fall:

• Free expo tickets (valued at $447) are available to qualified individuals working within the AI infrastructure field. Apply for free expo tickets.

• A registration discount is available for full access and VIP tickets. Quote TECHARENA15 on the registration page to save 15%.

TechArena has won two Gold Stevie Awards as part of the 23rd Annual International Business Awards, organizers of the prestigious competition announced today.  

The “In the Arena” podcast, hosted by TechArena founder and CEO Allyson Klein, earned Gold in the technology category, and the TechArena Forum, the company’s online platform devoted to AI technologies, infrastructure and the people who build them, earned Gold for achievement in web writing and content.

“This is such a proud day for TechArena and every team member who has contributed, from landing a podcast guest, to developing a question set, to recording and editing our content, to drafting an article that speaks to our North Star of educating on AI infrastructure’s advancement," Klein said.  

Back-to-Back Recognition for Podcast

The Gold marks the second straight year "In the Arena” has earned a Stevie. TechArena’s flagship podcast brings listeners inside the conversations shaping AI, data centers, silicon, edge computing and sustainability, drawing guests from the companies that are building that future.  

“To have the judges recognize that for a second year, and with Gold, means the world to this team," Klein said.

The judges took notice of both the show's pace and its pull.  

"Keeping up a clip of 260+ episodes since 2024 is hard enough, but landing a Nobel laureate and Fermilab experts shows how much industry pull this show has," one judge wrote. "Allyson skips the surface-level AI hype and gets right into the actual, deep infrastructure problems enterprise tech is facing."

A second judge wrote, "TechArena has worked hard to become a trusted, independent platform that has earned recognition as a vital voice in the global technology community." The judge also pointed out the high-caliber guest list, which has featured leaders from Synopsys, Arm, Intel, Cerebras, Walmart and CoreWeave, calling the show "one of enterprise tech's most prolific voices."  

A TechArena Forum First

The Forum's Gold marks the first Stevie recognition for TechArena's written editorial platform, which in a two-year span has published 734 pieces across 11 topic verticals including AI, quantum computing, silicon, edge, sustainability and cybersecurity. The Forum pairs original reporting and analysis from TechArena's editorial team with contributed perspectives from technologists and executives across the industry.

The judges singled out the substance behind that output. "Remarkably substantial editorial output ... with genuine expert contributors from major companies," one wrote. "Real editorial rigor rather than vendor-driven filler content."

Another judge praised the Forum for delivering "high-quality, insightful content with impressive technical depth while making complex topics accessible to enterprise audiences," adding that its editorial model and diversity of expert contributors "create a valuable knowledge platform."

"Building the Forum has been a labor of love from Day 1. It was something Allyson and I discussed at the dawn of TechArena," said Rachel Horton, head of content and editorial.  

What Comes Next

The double win caps a banner stretch for TechArena, and the team is not slowing down. New episodes of “In the Arena” publish weekly, and the Forum continues to expand its roster of expert voices across the technologies reshaping the enterprise.

The International Business Awards, the world's premier business awards program, honor achievement by organizations of every size and type across more than 60 nations. Last year's competition drew more than 3,800 nominations from organizations in 78 nations and markets. Winners were determined by the average scores of executives worldwide serving on the program's judging committees, and Gold marks the highest score tier a nomination can achieve.

Quantum technology has spent years as a domain defined by its promise rather than its deployments. That is beginning to change. The question now is not if quantum belongs on technological roadmaps for real business environments but how quickly it can be made reliable, integrated and usable.

That challenge sits at the center of the work being done at Q-CTRL. Recently, I had the chance to explore that work with the company's vice president of product, Alex Shih, alongside my "Data Insights" cohost, Solidigm's Jeniece Wnorowski. What emerged from the conversation is a clear view that the path for quantum, from laboratory demonstration to enterprise deployment, runs directly through software.

From Deep Science to Deployable Solutions

Q-CTRL's core work is translating quantum physics and quantum control expertise into products that customers can run. Alex described his role as taking deep science and turning it into scalable solutions for data centers, high-performance computing facilities and enterprise businesses. The company also delivers a quantum education platform to help organizations build and scale quantum talent, along with quantum sensing solutions for navigation.

Alex came to the field after a career spanning big technology companies, startups and space technology, most recently at Slack. He was drawn to quantum for its long-term potential. "I've always viewed quantum as a generational step-change technology that would introduce a new compute paradigm," he said.

Controlling Instability With Software

The central technical challenges in quantum systems are hardware instability, driven in large part by noise from both the hardware itself and the surrounding environment, and the difficulty of scaling that hardware. Q-CTRL develops what Alex described as AI-powered error-reduction quantum infrastructure software, which reduces that noise and suppresses the resulting errors so the hardware behaves reliably enough to build on.

That reliability serves two audiences. For hardware teams, it helps accelerate the development of their qubits. For enterprises developing and testing applications on real quantum hardware, it means the output can be trusted, which, as Alex noted, is what allows customers to properly assess how their applications perform.

Built for the Real World, Not the Journal

Alex was emphatic that Q-CTRL's purpose is to put quantum tools into working business environments. "While important to showcase progress in the field, we are not in the business of just publishing papers but rather removing barriers for customers to use our tools," he said. The goal, he explained, is for those tools to be accessible and used by companies around the world.

That focus is reflected in a recent deployment. Q-CTRL went live in Colorado with Elevate Quantum in a time frame that Alex described as a record for the industry, moving from the announcement of a planned system to a working one in only five months, at a fraction of the typical cost. He framed the achievement as a blueprint rather than a one-time result, expecting subsequent deployments to move even faster. "We've seen Murphy's Law at play; we've seen everything that can go wrong, did go wrong. But now we have ways to mitigate that," Alex said.

Broadening the User Base

Q-CTRL has been serving quantum algorithm developers through Fire Opal, which focuses on error reduction for algorithmic execution, and Boulder Opal, delivering autocalibration for hardware vendors. Since then, the company has built layers of abstraction that expand the range of people it can serve, including domain experts such as chemistry analysts and optimization specialists who can submit data in formats familiar to them.

Application developers represent another audience. Companies including ColibriTD in France and Qunova Computing in South Korea have integrated their own applications on top of Q-CTRL's core pipeline and reported improved performance. The company's education platform, Black Opal, meanwhile, targets traditional software developers who are interested in quantum and continues to drive adoption.

Toward Mainstream Integration

Looking ahead, Alex expressed confidence that quantum will integrate into enterprise workflows and production technology stacks. He pointed to Q-CTRL's work with Riken in Japan, home to the Fugaku supercomputer, an IBM Quantum System Two and a Quantinuum system, as an example of exploring hybrid workflows that combine quantum and classical compute.

Based on hardware vendor roadmaps and the company's experience with customer problems, Alex sees commercial quantum computing advantage in just a few years,   following the company's recent demonstration of practical quantum advantage. "We have confidence that in the next two to three years, we will see meaningful quantum advantage in specific workflows, especially around optimization," he said. He cited a case study with Mazda, where quantum methods required five times less training data to reach a vehicle frame design the company had previously optimized with best-in-class tools, translating directly into reduced research and development cost.

The TechArena Take

Quantum computing has long carried the reputation of a technology perpetually a few years away. What stands out in Q-CTRL's approach is its insistence on accessibility and deployment. By positioning software as the connective layer that brings hardware, control electronics and classical infrastructure together, the company is helping shorten a development cycle that has historically demanded teams of specialists and significant capital. For technology decision-makers, the practical takeaway is that quantum commercial readiness may hinge less on any single hardware breakthrough and more on the software and integration work that makes these systems performant at scale.

Learn more about Q-CTRL at q-ctrl.com, or watch the full podcast episode for more information.

As the AI Infra Summit approaches, TechArena has been chatting with the builders of AI infrastructure about how their requirements are changing as deployments scale.

We sat down with Marc Austin, CEO and co-founder of Hedgehog, a company that builds open software-defined networking for AI clusters. Hedgehog’s approach is mattering more now, as AI infrastructure spreads from single racks to multiple sites and a single misconfigured switch can leave GPUs across a cluster waiting on the network.

We talked about how Hedgehog’s software replaces switch-by-switch network engineering with a declarative operating model, why the company holds reference architecture validation from both NVIDIA and the Open Compute Project, and what it takes to keep job completion times down as clusters scale across sites. Here’s what we learned.

Q1: Hedgehog builds an open software-defined fabric that operators manage as one system rather than as a network stitched together switch by switch. What does that let an operator do at scale that the box-by-box model can’t?

A: It turns the network from a monthslong engineering project into a product you deploy.  

Designing an AI network from scratch means making thousands of interdependent decisions (topology, QoS, congestion control, failure domains) and then keeping them consistent across hundreds of switches by hand.  

With Hedgehog, an operator declares the cluster they want, and the fabric handles Day-0 through Day-N automatically: provisioning, lossless Ethernet tuning, congestion-aware routing and failure recovery, all through Kubernetes-native operations.  

That’s what lets a lean cloud team network like a hyperscaler.  

Q2: Hedgehog supports the NVIDIA Cloud Partner reference architecture, validated for Spectrum-X, and the Open Compute Project (OCP) reference architectures for AI training and inference. Why does that dual validation matter to an operator deciding how to build an AI cluster today?

A: At NVIDIA GTC 2026, we announced support for NVIDIA Spectrum-X Ethernet and the NVIDIA Cloud Partner reference architecture. At the 2026 OCP EMEA Summit, our AI training and inference fabric designs became OCP Accepted: 100% open source, hyperscaler reviewed, with complete BOMs available today on the OCP Marketplace.  

An operator can standardize on Spectrum-X, deploy a fully open SONiC-based fabric on OCP hardware, or run both, and keep a single declarative operating model across all of it. No other network vendor gives operators that freedom at the architecture layer.

Q3: In an AI cluster, every idle GPU is usually waiting on the network. What does the fabric have to get right to keep job completion times down, and why is that harder to do with closed, manually operated networks?

A: The metric that matters is job completion time, and the network defends it or destroys it.  

The fabric has to get five things right at once: lossless Ethernet with properly configured RoCEv2 QoS; congestion-aware routing; rail-optimized topology; dual-plane resilience, so a single failure never stalls a training run; and telemetry with automated recovery, so problems are fixed faster than a GPU can starve.  

In a closed, manually operated network, each of those is a specialist tuning exercise repeated per deployment. Any one misconfigured switch quietly taxes every job on the cluster. Hedgehog ships them as validated defaults in the reference architecture and enforces them continuously in software so that the fabric stays out of the GPUs’ way.

Q4: As infrastructure becomes composable, the network becomes the reassembling component. What does that demand from network software?

A: Composability is fundamentally a network abstraction problem, and hyperscalers already showed the answer: open networking plus VPC abstractions. Hedgehog brings that same model to AI clusters.  

Tenants get VPCs that can span multiple accelerator types and pods, with policy-based multitenant isolation, composed and recomposed in software rather than recabled. We’ve proven this live with disaggregated inference: NVIDIA GPUs handling prefill, SambaNova RDUs handling decode and Intel Xeon orchestration, all running across one Hedgehog fabric with no network penalty.  

Because the whole thing is operated through a declarative, Kubernetes-native model, AI infrastructure can be run with a small team.

Q5: As clusters grow, multiply, and spread across sites, where does network software have to go next? What role do open reference architectures play in letting the industry scale without every operator redesigning the network from scratch?

A: Network software has to scale in two directions at once: up and out.  

“Up” means prescriptive scale-out designs, with our OCP reference architectures defining Open Pod Group scalable units from 64 to 1,024 xPUs and a roadmap to Ultra Ethernet as the interconnect evolves.  

“Out” means treating many pods, clusters, and sites as one operable system, with hybrid multicloud routing and multitenant security built in rather than bolted on.  

Open reference architectures are what make that repeatable: Instead of every operator rederiving the design math, validated architectures with complete BOMs are published on the OCP Marketplace for anyone to build from. Everyone gets to network like a hyperscaler, and the industry scales without redesigning the network from scratch each time.