Denise Muyco,RAVEL联合创始人兼首席执行官-访谈系列

中文版正在随流水线自动整理，稍后刷新即可；可先阅读下方英文原文。

本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Interviews

Denise Muyco, Co-Founder and CEO of RAVEL – Interview Series

Add Unite.AI to your preferred sources on Google

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 acr

Auto-fetched and translated by AI Gem Box. All rights belong to the original author.