RAVEL 聯合創辦人兼 CEO Denise Muyco 訪談

Denise Muyco is the Co-Founder and CEO of RAVEL, where she leads the development of orchestration software for complex compute and AI infrastructure. A trained engineer, her career spans power infrastructure, process optimization, digital media, data centers, and virtual studios. Before focusing on AI, she helped develop shared high-performance computing infrastructure for Vancouver’s visual effects community, giving roughly 30 studios access to compute and secure connectivity. That experience shaped her approach to coordinating expensive, constrained resources. At RAVEL, she applies a systems-engineering perspective to workload placement, infrastructure utilization, interoperability, and the growing demands of distributed and sovereign AI environments.

RAVEL develops software that helps organizations deploy, manage, and scale compute and AI workloads across cloud, on-premises, and hybrid infrastructure. Its products include RAVEL Orchestrate for high-performance virtual workstations, RAVEL Orchestrate AI for workload automation and optimization, and Boost for software licensing and telemetry. The company’s tools connect infrastructure, applications, virtualization, and security while providing centralized controls and operational visibility. RAVEL serves data centers, service providers, enterprise IT teams, AI research groups, and creative studios. Building on its roots in digital content creation, the company focuses on simplifying complex environments and helping teams use their available infrastructure more effectively.

You founded RAVEL after years of working at the intersection of engineering, media infrastructure, and distributed computing. What ultimately led you to start the company, and how has RAVEL’s mission evolved as generative AI has dramatically increased demand for compute?

I’m an engineer by training, and I’ve worked at the intersection of power, compute and infrastructure long before today’s AI boom. Early in my career I interned at a nuclear power plant, and later my work in media and visual effects exposed me to GPUs, large compute demands and the constraints of physical infrastructure.

About 16 years ago, Vancouver’s growing visual effects industry was running into those constraints directly. Studios needed enormous amounts of high-performance compute to process (or render) increasingly complex film and television content for high-value projects, but few could justify building enough dedicated infrastructure to meet peak demand in a secure environment. Power was also becoming a constraint. We developed shared infrastructure that gave roughly 30 studios access to high-performance computing and secure, high-bandwidth connectivity.

Sharing infrastructure solved one problem but created another: how do you allocate expensive, constrained resources efficiently across organizations and workloads? That experience ultimately led to RAVEL’s approach to intelligent infrastructure orchestration.

AI is a much larger version of the same fundamental challenge—with far greater complexity and capital at stake. The workloads and infrastructure have changed, but the need to make expensive, constrained resources work together efficiently has only become more important.

Before RAVEL, you helped create a consortium of roughly 30 Vancouver studios, sound stages, production companies, and visual effects houses that could share access to high-performance computing infrastructure. What did that experience teach you about distributed compute, and what parallels do you see between Hollywood’s rendering challenges then and the AI industry’s infrastructure challenges today?

My work with the VFX industry taught me that building and configuring the infrastructure was only half the problem. Expensive compute had to be shared securely and used efficiently, while the broader infrastructure—including a secure network capable of moving enormous files—had to work together. Workloads had to be scheduled, capacity allocated, and massive volumes of data moved—all while production teams pushed for increasingly ambitious results within strict budgets and deadlines. Infrastructure had to be continuously optimized for utilization and performance.

AI is a much larger version of that same fundamental challenge. Organizations are investing heavily in infrastructure, but adding capacity alone doesn’t guarantee that expensive resources will be used efficiently. AI infrastructure is also becoming increasingly distributed across locations, providers and environments, driven by power, capacity, security, economics, geography, regulation and sovereignty requirements. Rendering and AI can be very different workloads, but they share an important infrastructure and ecosystem challenge: both depend on high-performance compute, networking, security and storage working together efficiently.

As AI infrastructure grows more complex, simply adding compute doesn’t solve the operational challenge of making that capacity work efficiently. This is where orchestration and the policies governing the broader infrastructure ecosystem become critical. Together, they help organizations make better use of expensive, constrained resources while coordinating workloads across increasingly distributed environments.

RAVEL describes itself as an orchestration layer for distributed AI factories. What does an “AI factory” mean to you, and what is missing from the infrastructure stack today that makes an orchestration layer necessary?

The way I see it, an AI factory is more than GPUs and high-performance clusters; it’s an integrated infrastructure ecosystem that brings together compute, networking, storage, security, power, cooling, and the operational layers needed to run AI workloads. AI factories are evolving from isolated clusters to become ecosystems of interconnected resources spanning multiple sites and regions. That complexity becomes increasingly difficult to manage manually or with disjointed point solutions. An orchestration layer addresses this by coordinating the diverse and complex pieces of the stack and abstracting some of that underlying complexity, making the infrastructure easier for operators to manage as a coordinated system.

As organizations adapt existing data centers for AI, many facilities were not originally designed around the demands of today’s AI workloads. AI today faces a structural mismatch that breaks down into three key problems. The first is power, or finding a location with enough reliable power to run workloads at scale. Second is ecosystem fragmentation, as AI stacks are often split across isolated environments and aren’t designed to work together. Third is limited visibility into total cost of operation and ownership, which can obscure the real cost of AI infrastructure. As a result, workloads can go unoptimized, hardware can be underutilized, and unexpected operational costs can drive up total cost of ownership, ultimately contributing to higher token costs.

AI infrastructure is increasingly spread across hyperscale clouds, private data centers, on-premise systems, and specialized GPU providers. What are the biggest challenges organizations encounter when trying to manage AI workloads across these different environments?

For the past several years, the AI infrastructure race has been defined by a simple assumption: build bigger. Bigger data centers. Bigger clusters. More GPUs. More capacity. But the build-bigger model is increasingly running into physical, economic and regulatory constraints.

Power is constrained. Grid access takes time. Economics, geography and sovereignty increasingly dictate where infrastructure can, and should, be built. The new challenge is not simply how to build more AI infrastructure, but how to build the right infrastructure in the right places, while making all those environments operate as a coordinated system. That becomes particularly difficult when capacity is spread across hyperscale clouds, private data centers, on-premises infrastructure and specialized providers that were not necessarily designed to operate together.

Power is the sharpest of these constraints. Increasingly, power availability is determining where AI infrastructure gets built in the first place.

That’s where federation becomes critical. It connects infrastructure across environments into a common operational environment. Intelligent orchestration then determines where workloads should run based on capacity, power, performance, cost, policy, resiliency and sovereignty.

As AI infrastructure spreads further, whether across locations or providers, the competitive advantage won’t come simply from owning more capacity. It will come from making that capacity work together. Federation creates the infrastructure model for this new reality, while intelligent orchestration makes that model operational at scale.

This is the model one of our customers, RT-One, the developer of Latin America’s largest AI technology parks and data centers, is pursuing as it plans federated infrastructure across the Americas: connecting distributed capacity so it can ultimately be managed as a coordinated environment.

GPU scarcity has received enormous attention, but simply adding more accelerators does not necessarily translate into more useful AI compute. Where do you see the largest sources of inefficiency in today’s AI infrastructure, and how much additional capacity could companies unlock through better orchestration?

The AI infrastructure race has focused heavily on how many gigawatts of new capacity are planned and how much capital is being committed to build it. It is tempting to treat AI’s infrastructure problem as simply a shortage of GPUs or capacity, but this framing misses where inefficiency truly resides. It is important to note that planned capacity isn’t the same as usable capacity.

GPU clusters can appear fully booked, but expensive GPUs can still sit idle when performance bottlenecks emerge elsewhere in the stack. These can include storage throughput, data pipelines, network congestion, job scheduling inefficiencies, security requirements and mismatches across architecture, applications, drivers and dependencies. Adding GPUs doesn’t always translate into additional usable compute.

Adding more infrastructure doesn’t automatically increase efficiency. In many cases, it creates more silos while driving up costs.

Organizations need greater visibility and control so they can improve utilization, automate infrastructure decisions and better align workloads with available resources and business priorities. Greater visibility and control can help turn a collection of infrastructure resources into a more coordinated operating environment. There is no exact or universal number tied to how much capacity could be unlocked through orchestration; each workload has unique requirements. But one thing is clear: the answer to stranded or underutilized capacity isn’t simply to buy or build more.

RAVEL has emphasized interoperability between infrastructure, virtualization technologies, identity systems, and applications. Why is interoperability becoming particularly important as AI workloads become more complex and distributed?

As infrastructure becomes more heterogeneous, organizations need flexibility to use different technologies and environments without creating more isolated infrastructure silos. Interoperability allows compute, storage, networking and applications from different vendors and environments to work together, preserving choice as infrastructure evolves. But interoperability alone doesn’t determine how those resources should be used.

That’s where orchestration comes in—coordinating where workloads run, how they move and how policies are enforced across environments. As AI infrastructure becomes increasingly distributed and federated, interoperability provides the flexibility to operate across technologies, while orchestration turns those resources into a coordinated operating environment.

RAVEL Orchestrate AI provides a common orchestration layer across compute, storage, networking and other infrastructure technologies, coordinating AI workloads across cloud, on-premises and hybrid environments.

Data sovereignty is becoming a major consideration for governments and enterprises deploying AI. How does the growth of sovereign AI infrastructure change the way organizations need to think about workload placement, data movement, security, and orchestration?

Sovereign AI is now a strategic priority. With it, a more fundamental question emerges: What does it actually mean to be sovereign? The conversation has largely focused on data residency, but I believe that definition is too narrow.

I define Sovereign AI as the ability of a nation, enterprise, government agency, or other organization to maintain policy-defined control over its AI workloads—including the data, models, compute infrastructure, access, security, operations and jurisdiction governing those workloads. Sovereignty does not necessarily mean that every workload must remain in one data center or even on infrastructure owned by a single organization. Rather, it means that the organization defines where a workload is permitted to run, where its data may reside or travel, who may access it, what infrastructure may execute it, and what security, regulatory, geographic, operational and business policies must always be preserved. This workload-centric definition is consistent with the broader industry movement toward treating sovereignty as control over the full AI environment rather than data residency alone.

RAVEL’s approach is particularly differentiated when Sovereign AI meets federation. RAVEL Orchestrate AI can treat sovereignty requirements as constraints within the orchestration and policy layer: a workload may be eligible to run across a federation of sites, clouds, data centers, edge locations or other infrastructure, but only across resources that satisfy that workload’s sovereign policies. Within that approved boundary, RAVEL can then determine the appropriate infrastructure based on factors such as power, cost, performance, capacity, utilization, network characteristics, location and priority. Federation does not eliminate sovereignty; rather, federation can operate within sovereignty-defined boundaries. A sensitive government workload might remain entirely within approved U.S. facilities, for example, while still being dynamically orchestrated among multiple authorized sites. The result is a model in which organizations can gain the utilization and resiliency advantages of distributed AI infrastructure without surrendering control over where and how their most sensitive workloads operate.

RAVEL originated in industries such as media, entertainment, gaming, and design where workloads can be extremely compute-intensive. How have the requirements of generative AI changed the platform compared with the infrastructure challenges you were originally solving for creative professionals?

RAVEL was born solving infrastructure problems where artists and engineers were already running massive rendering, simulation, and content-creation workloads across expensive compute, storage and networking resources. The fundamental challenge was how to make heterogeneous infrastructure easier to access, share and orchestrate while maximizing utilization and performance.

Generative AI has dramatically increased the scale and complexity of that same problem. Instead of primarily orchestrating applications and render workloads, we now have to account for AI models, engines, agents, training and inference workloads, different GPU architectures, rapidly changing software stacks, enormous data movement and significantly greater constraints around power, cost, security and availability.

As a result, RAVEL has evolved from primarily orchestrating compute into providing an intelligent control and optimization layer for AI infrastructure. Orchestrate AI uses telemetry and policy to determine not simply whether infrastructure is available, but where and how a workload should run based on factors such as cost, speed, power, performance, utilization, location and sovereignty requirements.

Federation has also become increasingly important because AI infrastructure can no longer be treated as a collection of isolated data centers; organizations need the ability to intelligently use capacity across sites while maintaining governance and security. In many ways, generative AI didn’t change the fundamental problem RAVEL set out to solve—it made the problem dramatically larger and more complex, making intelligent orchestration, optimization and federation increasingly important.

Your career has taken you from mechanical engineering and process optimization at Starbucks to digital media, data centers, virtual studios, and now AI infrastructure. How has that engineering background influenced the way you approach building companies and solving infrastructure problems?

My engineering background has probably influenced almost everything about how I build companies. Mechanical engineering teaches you to look at a system—not just an individual component—and ask where the constraints are, where energy or resources are being wasted, and how the entire system can perform better. At Starbucks, I applied that thinking to process optimization; later, in digital media and visual effects, the system became compute, storage, networking, applications and eventually entire data centers. The technology changed, but the way I approached the problem really didn’t. I’m always asking: Where is the bottleneck? What is underutilized? What can we simplify? And how do we make the whole system work better rather than just optimizing one piece of it?

That’s very much how we built RAVEL. I don’t think the AI infrastructure problem is simply about getting more GPUs or building more data centers. It’s a systems-engineering problem involving compute, power, storage, networking, software, workloads, people and increasingly geography and sovereignty. You can have the fastest GPU in the world, but if the rest of the system isn’t optimized, you’ve simply created a very expensive bottleneck. So our approach with RAVEL is to make the infrastructure itself more intelligent—using telemetry, policy, orchestration and federation to continually determine how and where workloads should run. I started my career optimizing physical systems; today we’re applying that same engineering discipline to optimize the infrastructure powering AI.

Looking ahead, how do you expect AI infrastructure to evolve as models, agents, and applications demand increasingly large amounts of distributed compute? Do you envision AI factories becoming a standardized layer of enterprise infrastructure in much the same way cloud computing did over the past decade?

I absolutely believe AI factories will become a foundational layer of enterprise infrastructure, much like cloud computing did—but I don’t think they will look like a single standardized data center or cloud. As models, agents, and applications consume increasingly large amounts of compute, enterprises will operate across a heterogeneous mix of GPUs, CPUs, private infrastructure, neoclouds, hyperscalers, edge environments and specialized AI systems.

Power availability, cost, sovereignty, performance, and location will become just as important as compute availability. The real challenge won’t simply be building more infrastructure; it will be making all of that distributed infrastructure behave like one intelligent system. The AI factory of the future isn’t a single building—it’s a federated infrastructure environment spanning compute, power, data and the resources required to run AI workloads wherever it makes the most sense.

That’s where I think the next major infrastructure layer emerges. Cloud computing abstracted servers and made compute easier to consume; the next step is to abstract the complexity of the entire AI infrastructure stack. Enterprises shouldn’t have to manually determine which GPU, data center, cloud, power source or geography should run every model or agent. The infrastructure should increasingly make those decisions itself, using telemetry and policy to optimize for cost, speed, power, performance, availability and sovereignty. That’s the future we’re building toward at RAVEL: an intelligent orchestration layer that allows workloads to move across a federated AI infrastructure while preserving the policies and controls of the organization. Cloud made compute available on demand. I believe the next generation of AI infrastructure will make optimization available on demand.

Thank you for the great interview, readers who wish to learn more about orchestrating AI workloads across distributed infrastructure should visit RAVEL.