By AI infrastructure pilots routinely pass lab validation and then break down the moment they touch production. The lab does not replicate production power envelopes, real thermal loads, or actual network topology, so the performance and cost numbers it produces are unreliable. Organizations that act on those numbers commit capital to configurations that do not hold up, and the gaps surface only after deployment.
In this interview on TFiR, Denise Muyco, CEO and Co-Founder at RAVEL, walks through why the pilot-to-production failure is a structural infrastructure problem, how the Amphix platform is built to close that gap, and how federated orchestration through RAVEL’s Orchestrate AI software keeps distributed AI factories from wasting power and stranding capacity.
Guest: Denise Muyco, CEO and Co-Founder at RAVEL
Show: TFiR
Here is what every platform engineer and AI infrastructure decision-maker needs to know.
Technical Deep Dive
Q: Why do AI pilots succeed in the lab but fail when moved to production?
Denise Muyco, CEO and Co-Founder at RAVEL, explains that lab environments almost never replicate the conditions that matter: production power levels, real thermal loads, and actual network configurations. Because the pilot runs on infrastructure that does not match the production stack, the performance and cost data it generates is misleading. Organizations then make large capital commitments based on that data and only discover the gaps after the money has been spent.
“AI infrastructure is expensive and you shouldn’t have to learn what works after you spent the money.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: What is the Amphix platform and what problem is it designed to solve?
Amphix is a production-oriented AI infrastructure platform that lets customers run real workloads on production-grade infrastructure before making technical or capital commitments. Muyco describes a three-stage model: first, prove the workload performs as expected on real infrastructure; second, capture that validated configuration as a repeatable blueprint; third, scale that blueprint across additional sites with ecosystem partners integrated as a single system. The goal is to eliminate the science-project POC cycle and replace it with a direct path to production.
“Amphix lets customers run real workloads on real production-grade infrastructure so they can validate performance, understand the power requirements, and understand the operations before making those big capital commitments.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: Who is Amphix designed for and what risks does it address?
Amphix serves two primary customer segments: traditional enterprise customers and data center operators. The core risk both groups face is purchasing infrastructure configurations that are not optimized for their specific workloads because workloads are not connected to compute, network, and storage configuration decisions at the time of purchase. A one-size-fits-all procurement model fails because an LLM workload has fundamentally different VRAM and throughput requirements than a generative AI workload, and hardware differences across Nvidia, AMD, and Intel amplify that divergence.
“An LLM is very different than generative AI, and those workloads require different VRAM. A B300 is very different than a Vera Rubin, which is different than an H100.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: How does Amphix turn a validated pilot into a repeatable path to production?
Repeatability in Amphix operates on two axes. The first is workload definition: capturing the file sizes, file constitution, and the engines and models in use, then fine-tuning that combination until performance is confirmed. The second is engineering configuration: mapping the validated workload to the precise VRAM allocation, data flow architecture, and hardware configuration so that the same result can be reproduced at any additional site. Once both axes are locked, scaling means adding compute resources at new locations without re-running discovery from scratch.
“Fine-tuning the workload, which consists of file size, engines, and models, is something that is repeatable and scalable within Amphix, and the end customers are not left to their own devices trying to figure that out.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: What does a real customer deployment through Amphix look like?
RT1, a large data center and NEO cloud company headquartered in Brazil, came to RAVEL wanting to skip the POC stage entirely and go directly to a structured pilot. RAVEL and RT1 designed a pilot together covering six or seven distinct workload types, each mapped to a corresponding hardware configuration, with some cross-over between types. The objective was to determine the optimal workload mix across configurations before committing to production infrastructure across multiple locations. The federation model that emerged from that pilot allowed RT1 to optimize cost and efficiency by shifting workloads to sites where capacity and power were available, while also addressing power moratorium constraints.
“You have to really understand those workload types, those engines, those models, the file sets. You have to know all of that as an overall system to really extract all inherent value out of the equipment and the system that you’re buying.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: What is RAVEL’s specific role within the Amphix ecosystem?
RAVEL operates on two levels within Amphix. The first is consultative and engineering: understanding customer workloads, advising on purchase decisions, and fine-tuning engines and models before infrastructure is acquired. The second is software: RAVEL’s Orchestrate AI platform deploys workloads across the federated infrastructure in the most efficient manner, ensuring no compute resource sits idle and no capacity is wasted. After completing Amphix validation, customers have two paths: remain within the Amphix commercial environment, or carry the validated blueprint into their own data center or enterprise environment.
“Ravel’s real role is making sure that the infrastructure is properly federated throughout Amphix and that the end customer experiences all of what is to be done in their own production environment.”
Denise Muyco, CEO and Co-Founder, RAVEL
Q: Why is orchestration critical as AI infrastructure becomes more distributed?
The core problem driving federated AI infrastructure is power: building new large-scale generation capacity to power centralized AI factories is economically and logistically prohibitive. The more practical answer, which Muyco traces to a discussion at a national lab two years ago, is to shift workloads to locations where power capacity already exists. RAVEL’s Orchestrate AI software ingests telemetry from the connected infrastructure system and uses a policy engine to move workloads intelligently across federated sites, matching each job to the location where capacity, power, and configuration are best aligned.
“Rather than spending hundreds of billions of dollars retooling generators and large industrial infrastructure, it makes better sense to shift those workloads to other locations where capacity is available and where one can optimize that capacity.”
Denise Muyco, CEO and Co-Founder, RAVEL
Resources & Documentation
- RAVEL (ravelinc.com), producer of the Amphix production validation platform and Orchestrate AI workload orchestration software
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: When we take on AI projects, the project can succeed and still tell you almost nothing because the lab wasn’t running your real workload. It rarely has production power, real thermals or your actual network. So organizations commit millions in capital on just guesswork and only find the gaps after the money is spent and then they try it in production. That is the typical pilot to production failure story that we hear most of the time. Now Revel is addressing that which what they call Amphix platform built as a response to this problem. And today we have with us Dennis Michael, CEO and co founder of Revel. Dennis, it’s great to have you on the show.
Denise Muyco: Hi, pleasure to be here. Thank you.
Swapnil Bhartiya: Before we get into this problem, India, I would love to know a bit about the company. What is your focus area, how old is the company and what led you to co create it?
Denise Muyco: Yeah, so the company was founded about 16 years ago and so similar to what you shared with me earlier about your background in media entertainment, we also started in media entertainment as well as. And so that background was primarily focusing on heavy compute resources that would be to basically manage visual effects and the heavy compute and processing in order to render images. That’s how the business was started, which was taking infrastructure that was meant for again these, these HPC or high performance compute resources and enabling that among multiple different studios and production companies within a particular location. In this case it happened to be Vancouver and so Vancouver and Los Angeles they all had the same basic problem which was using this high performance compute, not having the capital to buy more infrastructure. But then once someone did buy all the infrastructure, it was really about the lack of power. So then that’s kind of how the business started was by focusing on taking those compute resources, taking you know, and finding the power and then confederating all of these different locations into one system.
Swapnil Bhartiya: Let’s talk about MFIX now. What problem is it designed to solve?
Denise Muyco: Yeah, so Amphix as you already mentioned is a production oriented AI infrastructure platform where customers can validate real workloads on an integrated production ready infrastructure before both technical and capital investments are made. And so the way I think about it is kind of a three prong approach where there’s a prove it model and there is building the blueprint and scaling it. So that first part, or we’ll call it first chapter, is really about de risking AI before you invest. So that AI infrastructure is expensive and you shouldn’t have to learn what works after you spent the money. Ampix Lets the customers run real workloads on real production grade infrastructure so they can validate performance, understand the power cost, what the power requirements are and what those operations are before making those big capital commitments. That’s the prove it before you buy it model. Then once you prove it, Chapter two, it’s about scaling it. Ampix isn’t about doing another science project or another POC and seeing where that goes. It’s really there to validate those actual works. The use of the data to establish reference configurations, training the operators, and then taking that knowledge into production across additional sites. So that’s the validate it and build a blueprint to scale it part. And then the third thing I would say, or the third chapter is really about building or bringing all of those ecosystem partners together. And it needs to act as a system as opposed to individual components. So nothing is possible about without all those AI ecosystem components. And Ravel makes those ecosystem components work as one system. So an AI factory really isn’t one piece of technology. As I just discussed, it’s compute, storage, network, power, cooling, software and the workloads, all of it has to work together. And Ravel brings that technology system together, validates it through the Amphix and the Orchestrate AI, which is Ravel’s premier product, provides that intelligence layer that manages and optimizes all the systems.
Swapnil Bhartiya: And if you look at the target audience, who is Amphix designed for and what risk does it help organizations address as they move AI from pilot into production?
Denise Muyco: Yeah, so who it’s for? There are different types of customers. There are your traditional enterprise customers and then you have data center customers. Right. So those are the two primary customers groups or segments that Amphics serves. And what, what Amphics is meant to do is, you know, it’s, it’s always challenging. So what, what we have found is that a lot of data centers and a lot of enterprises need the same things which are, you know, they, they understand they have to buy infrastructure, they understand they have put it all together, but the workloads generally are not connected to the configuration of the compute resources in connection with network or with storage, that it all has to work as a single system. And that has been the biggest challenge is how do the end customers, whether it be enterprise customers or their data center customers, how do they purchase the correct configurations for the different workloads? And rather than, you know, it’s a one size fits all system, this is really about optimizing for those different kinds of workloads. Those workloads you know, an LLM is very different than generative AI and so those, those workloads require different VRAM and different, you know, a B300 is very different than you know, a Vera Rubin which is different than an H100. Right, very. And then you get into different. It’s not just, you know, we talked about Nvidia, but there are other technologies including AMD and Intel. They all have different value propositions and different types of use case optimizations.
Swapnil Bhartiya: After a pilot runs and is validated, how does MFIX take what teams learn and and turn it into repeatable path to production and then scale?
Denise Muyco: Yeah. So the repeatable path is basically twofold. Right. One is when you’re what’s repeatable. So again is again focusing initially on the, when we talk about the workload, the workload is a combination of what are the size of the files, what’s the constitution of those files and what is the engines and models that are being used. So that ability to fine tune that is something that is repeatable and scalable within the mfix. Right. So the end customers are not left to their own devices trying to figure that out. That is something that in terms of accelerating one’s ability to move to production quickly, it’s really focusing on that workload again which consists of file file size and those engines and those models. Fine tuning that is something that’s I would say extremely critical. That’s repeatable and amp fixnose has to do very well. The second part of that is when you’re going into the engineering part of the configuration and making sure all of that is associated with that workload. So again we talk about getting down into the nitty gritty of the VRAM and how the data flows through the entire system that is also repeatable, scalable and once you have that then you just add, you continue to add on into additional compute resources regardless of the location.
Swapnil Bhartiya: Is it possible for you to talk about a customer who went through Amphix and what their feedback was? How did they turn their pilot into, into a successful production system?
Denise Muyco: One customer we can talk about is a company called RT1. RT1 is a large data center company and they also happen to be their own NEO cloud company and so they are headquartered out of Brazil and they are looking to have multiple locations and there was no question about leveraging Ravel software as that orchestration layer that would intelligently move the workloads and optimize how the workloads are deployed into different types of infrastructure and different locations and the other piece of that was adding in cost. And cost could be a function of power, it could be a function of the chip itself, it could be a function of several different, different facets. But at the end of the day, you know, the. All of this is great in conjecture and theory and the CEO of RT1 really cared deeply about not wasting, you know, capital and money. So that’s where the M fix was, where he came in and said, yes, I’d like to run. You know, kind of skipped the. He skipped the trial and the POC and went directly to the pilot. The pilot was interesting in that it was basically something that we designed together and that we’re going to suit his needs. In terms of the different types of workloads, we came up with six or seven different workload types and six or seven different configurations that are associated with those workload types are some crossovers, right? So, you know, the big question is, well, how many of this workload versus that workload and how do you, how do you optimize that? And that is kind of really where, you know, we, you have to really understand those workload types, those engines, those models, the file sets. You have to know all of that as an overall system to really kind of extract all inherent value out of, out of, out of the equipment and the system that you’re buying. The great value proposition, all of this is that there can be optimizations by way of federating the different locations and different sites. And that federation model has really been a very good way to again, do two things, optimize on cost and efficiencies and turning those AI jobs around quickly. But also it’s, you know, being responsible. And that word is a. Could be a pretty excitable word, but responsibly could mean efficiencies. It could mean based on one’s utilization of power. There’s lots of reasons that, you know, power moratoriums are being now implemented. So those are all ways in which both Amphics and Ravel are solving the problem of optimization and of both power utilization, cost, et cetera.
Swapnil Bhartiya: Amphix touches infrastructure, teams, technology and operating partners. What is Revel’s role within that ecosystem?
Denise Muyco: So Ravel’s role within the ecosystem is really about the. Well, there’s two parts to it. One is there is a little bit of a, I would say a consultative and engineering nature, which is again, understanding and knowing what those workloads are and helping make purchase decisions or give advice for those purchase decisions and doing some of the fine tuning of the engines. And models. That’s part one. But the Ravel pardon on this is the software itself and the ability to deploy those workloads in a manner that is the most efficient and basically making sure that no resources is going unused. And again, maximizing the full, I would say, extent of the capacity of each part of that, I would call it the ecosystem infrastructure value chain. So there’s no waste. It’s all about how do you optimize so there’s no waste, whether that be power, whether that be utilization of a chip, whether that be making sure that there’s the right amount of VRAM and that there’s not just some excess capacity. You always want to have a little bit of excess capacity, but you don’t want, you know, to get into that waste category. So that’s what Ravel’s real role is, is making sure that that infrastructure is properly, you know, federated throughout the AMP fix and that the end customer experiences are all of what is to be done into their own production environment. So there’s basically two paths for an end customer, which is do the trial, do a poc, do a pilot, and then once you want to go to production, when I say production, you’re going to commercialization where you have other customers, you have two paths. One is continue on in the amp fix and go amphics commercial. And the other is you want to bring that to your own data center. You want to bring that to your own enterprise. So those are the two paths that the amphic centers of excellence can really do for an end customer.
Swapnil Bhartiya: As AI infrastructure becomes more distributed, what does federated AI infrastructure look like? And why is orchestration becoming so critical?
Denise Muyco: Yes, I’ll tell a little share story about When I was at one of the national labs two years ago, the big question was how do large industrial companies like Caterpillar and these large, I would call them parts of the ecosystem components, like with Nvidia or these OEMs like, like a Super Micro or Adel. How do they build, you know, AI factories that are not going to have huge taxes or big implications on the power grid. And the, the big, the big aha moment for everyone was, well, rather than building, you know, big generators or, you know, having to spend, you know, hundreds of billions of dollars into retooling generators and this large, you know, infrastructure, industrial infrastructure, it would make better sense to shift those workloads to other locations where capacity is available and where one can optimize that, that capacity. And that capacity is power capacity in connection with the physical infrastructure that sits there and those, those configurations. So the way in which Ravel, in connection with that federation component that is part of Ravel’s policy engine, it really is about ingesting that information and that telemetry that’s going on within the connected system by which the Ravel orchestrate AI, that’s our software, basically does that movement, that intelligent movement of those workloads.
Swapnil Bhartiya: Deniz, thank you so much for joining me and sharing these great insights. And those who are watching, please go and check revelink.com to learn more about how Revel can solve your problem. Denis, it was good talking to you, and I’d love to have you back on the show. Thank you.
