--- title: "Luma Runs Production Inference on AMD and Tensorwave" description: "Luma is building the frontier infrastructure for multimodal AGI alongside AMD and TensorWave. Here’s how we scaled one of our most demanding pipelines: video-to-video." canonical: "https://lumalabs.ai/news/luma-runs-production-inference-on-amd-and-tensorwave" source: "https://lumalabs.ai/news/luma-runs-production-inference-on-amd-and-tensorwave.md" --- # Luma Runs Production Inference on AMD and Tensorwave _July 22, 2026_ Luma’s mission is to build multimodal AGI that can generate, understand, and operate in the physical world. That mission requires frontier models, and frontier infrastructure to run them. With compute from partners like Tensorwave, AMD hardware supports inference for every major Luma model today. Thousands of AMD Instinct MI325X GPUs serve generation requests across our platform, spanning the text, image, video, and multimodal workloads behind our flagship video model, Ray3.2; our new multimodal reasoning model, Uni-1; and Luma Agents, the platform that brings them together. This is the story of how we got there, told through the migration of one of our most demanding pipelines: video-to-video. ## **Why Video Models Are Hard to Serve** Modern video and world models are not single networks. They are pipelines composed of many submodels, including variational autoencoders, ControlNets, LoRAs, and the denoiser backbone, each with its own compute profile and memory footprint. Ray3.2’s video-to-video capability can take an ordinary scene, perhaps even one shot on an iPhone, and reimagine it as an entirely different world while preserving the original structure and motion. That level of control gives creatives tremendous influence over the final product and reduces the need for expensive costumes and sets by orders of magnitude. It also creates a genuinely complex serving problem. The modern AI stack demands a thorough understanding of and control over every layer, from silicon to scheduler. For pipelines like ours, two hardware characteristics matter enormously: memory capacity and interconnect speed. The MI325X delivers both. The large VRAM capacity of AMD hardware lets us keep every submodel in a pipeline resident in memory. This matters more than it might seem. The alternatives are CPU offloading, which is slow, or more aggressive model sharding across devices, which increases communication volume. Sufficient memory per card allows us to avoid both. When communication is unavoidable, AMD’s fast interconnects keep it efficient. ## **The Migration** Our internal training platform runs on a separate cluster, so bringing the model to AMD for inference meant porting a large, continuously evolving codebase. What surprised us was how little porting it needed. AMD’s PyTorch backend allowed roughly 90% of our code to run immediately. Every standard PyTorch operation we rely on was already supported. Our custom networks for video-to-video control signals migrated trivially. Our lower-precision ablations, including FP8, transferred just as easily. Even our custom Triton kernels ran out of the box through Triton’s AMD backend, requiring only validation on our side. The attention operation was the one place we intervened manually. We located the point where our stack dispatched calls to our attention implementation and rerouted them to AMD’s implementation in the AITER library. We then confirmed with the AMD team that the performance we observed for our specific shapes matched their expectations for the MI325X. It did. For our multimodal model, which requires KV caching and uses a unique disaggregated setup, we relied on AMD’s FlashInfer support. We needed some help reaching our target performance, and the AMD team engaged quickly. We got there. Then came the less visible but essential work: robust validation and end-to-end testing. Taking the video-to-video pipeline from migration through production readiness required two to three engineers and approximately two weeks. The multimodal model, with its additional serving complexity, required three engineers and approximately four weeks to reach our performance targets. Much of that time, however, was not specific to AMD. This was the first multimodal model Luma had ever served to customers, and bringing it into production would have required the same work on any platform. The result that mattered most was no regression in quality, as validated by human evaluators. Videos generated on AMD hardware are indistinguishable from those our pipelines produced before. ## **A Software Ecosystem That Keeps Up With Research** Serving frontier models means continually shipping novel algorithms, and novel algorithms require custom kernels. This is where AMD’s software stack has impressed us. Beyond broad PyTorch coverage, the open-source ecosystem around AMD hardware is thriving. HipKittens, FlyDSL, and Triton’s AMD backend give our engineers multiple productive paths for writing and optimizing kernels as new ideas emerge. For our LLM workloads, our custom fork of vLLM runs on AMD as a first-class citizen. When we have encountered issues, AMD’s support has been consistently responsive. That partnership at the engineering level is a major reason why the migration progressed as quickly as it did. ## **Looking Ahead** We are pleased with the performance we are seeing on AMD, and we continue to deepen this work: bringing new models, new modalities, and new serving techniques to AMD hardware as our research advances toward multimodal AGI. We are a talent-dense team based in Redwood City, California, and we love working with ambitious people who work hard to reshape the world according to their vision. If you are as excited about this future as we are, come build it with us. Explore how Luma Agents and Ray3.2 are powering the next wave of cinematic content creation.