One Highly General-Purpose Codebase Connecting On-Device and Cloud AI

Qualcomm is expanding its front from chips to the AI software stack.

On September 25, during the second day of the 2026 Snapdragon Summit, Chris Lattner, Executive Vice President of Advanced AI Software and Platforms at Qualcomm Technologies and co-founder of Modular, announced Qualcomm’s latest plans for the Modular platform: developers will be able to use the same programming model and software stack to run AI workloads on different types of hardware, including GPUs, NPUs, and data center ASICs, and migrate them between local devices and the cloud.

This is not simply about adding an SDK to the Snapdragon NPU. Qualcomm wants to build an AI software infrastructure spanning phones, PCs, cars, edge devices, and data centers, leaving differences between underlying chips as much as possible to compilers, runtimes, and hardware backends instead of requiring developers to rewrite code for every accelerator.

“The Same Code” Addresses an Old AI Deployment Problem

Today’s AI software still depends heavily on hardware vendors’ toolchains.

On NVIDIA GPUs, developers typically optimize around ecosystems such as CUDA and TensorRT. Migrating to AMD GPUs requires reworking compilation, operators, and performance tuning. Switching to an NPU in a phone or PC introduces different hardware execution models, supported data types, memory structures, and operator sets. Even when the model itself remains unchanged, engineering teams often have to maintain multiple backend codebases.

This kind of adaptation is not as simple as changing a few configuration options. GPUs generally organize computation using grids and thread blocks, while NPUs may schedule tasks according to the number of cores, threads, or hardware compute units. Different devices also use different parallel execution models, memory hierarchies, and instruction sets. The execution model used by data center accelerators such as Qualcomm Cloud AI 100 is fundamentally different from that of a typical GPU.

Modular’s goal is to establish a unified software layer across this hardware:

• Developers use a unified language and computational abstractions to describe algorithms;
• The compiler generates corresponding code for GPUs, NPUs, or ASICs;
• The graph compiler handles model partitioning, fusion, and scheduling;
• The runtime selects devices, manages memory, and executes tasks;
• The serving framework handles model loading, batching, and inference requests.

Its ideal form can be summarized as follows:

AI models and application code
        ↓
Mojo / Python interfaces and unified operator abstractions
        ↓
MAX graph compiler, inference services, and runtime
        ↓
Hardware backends and device driver connectivity layer
        ↓
GPU │ Snapdragon NPU │ Cloud AI ASIC │ Other accelerators

Therefore, “the same code adapting to every chip” should not be understood as copying a single binary directly to any device and running it there. More precisely, application code, operator interfaces, and deployment workflows should remain as consistent as possible, while the platform handles compilation and scheduling for different hardware.

This still requires support from hardware backends, and it does not mean that every device will achieve exactly the same performance. However, compared with maintaining a separate software stack every time a chip changes, a unified abstraction can significantly reduce duplicated development work.

Mojo Is the Key Piece Qualcomm Is Adding

The most noteworthy part of this platform is Mojo.

Lattner positions Mojo as a programming language that combines ease of use with system-level performance. Its syntax and user experience are close to Python, but its goal is not to become another Python dialect. Instead, it is intended to let developers express memory layouts, parallel computation, and hardware-specific optimizations, and compile the code for different processor backends.

This directly addresses a major gap in AI development: researchers are accustomed to using Python to build models quickly, but once those models enter production, performance-sensitive components often have to be handed off to C++, CUDA, or a vendor-specific language. Model development and low-level optimization are handled by two languages and two groups of engineers, making modification and debugging expensive.

Mojo aims to shorten this distance. Developers can structure programs in a way that is close to Python while moving to lower-level control when necessary, managing data types, vectorization, memory, and parallel execution strategies.

After Qualcomm acquired Modular, the language was no longer merely an experimental project from an independent startup. According to the roadmap disclosed at the event, Mojo and the MAX software stack will become part of Qualcomm’s complete product portfolio, covering Snapdragon endpoint platforms and data center AI accelerators.

Microsoft also announced a partnership with Modular to provide native Windows support for Mojo. This is especially important to Qualcomm: the Snapdragon X series has already entered Windows PCs, and if Mojo, MAX, Windows, and the Snapdragon NPU can form a complete development chain, Qualcomm could lower the barrier to adapting local AI applications for Windows on Arm.

Qualcomm Did Not Acquire Modular Just to Build a Better SDK

On June 24, Qualcomm announced that it had reached a definitive agreement to acquire Modular, and the transaction was completed on July 29. The all-stock deal was valued at approximately $3.9 billion to $4.0 billion.

A price approaching $4 billion indicates that Qualcomm was not buying merely a collection of compiler components. It was buying an entry point into the software ecosystem of the AI era.

In the past, Qualcomm’s most distinctive label was Snapdragon. It can provide smartphone SoCs, connectivity, low-power computing, and NPUs, but hardware performance does not automatically translate into a developer ecosystem. A device having a nominal computing capacity of dozens of TOPS does not mean application developers can use it smoothly. If model conversion is difficult, operators are unsupported, or debugging tools are immature, the end result may still be limited to a handful of system-level demonstrations.

NVIDIA’s moat is a counterexample. Its advantage is not limited to GPUs; it also includes years of accumulated work in compilers, mathematical libraries, inference engines, debugging tools, and developer experience. Developers often choose NVIDIA not because other chips are completely unable to run a model, but because the risk and cost of migrating the software are too high.

Qualcomm now wants to bypass this single-vendor ecosystem competition. Rather than replicating a closed toolchain serving only Snapdragon, it would be more advantageous to make Modular a unified compute layer spanning multiple types of hardware, with Snapdragon and Qualcomm’s data center chips becoming some of its best-supported and most efficient target platforms.

This idea is more ambitious than “building another SDK for Snapdragon,” and it better fits Qualcomm’s actual situation: it needs to attract teams with existing experience in NVIDIA, AMD, or Apple development instead of requiring everyone to learn Qualcomm-specific interfaces from scratch.

The Real Challenge Is Not Running, but Running Fast Enough

A unified software stack sounds appealing, but abstracting AI hardware has always been difficult.

The differences between CPUs, GPUs, NPUs, and specialized ASICs extend beyond instruction sets. They also differ in their preferences for precision formats, sparse computation, dynamic shapes, memory access, operator fusion, and task scheduling. If an abstraction is too general-purpose, it may sacrifice performance. If it exposes too many hardware details, it returns to the starting point of “one codebase per chip.”

Modular must answer three questions at the same time:

1. How broad is the compatibility range? Running common Transformer models is relatively easy. When developers encounter custom operators, dynamic control flow, or new model architectures, can Modular still provide a consistent development experience?
2. How much performance is lost? Software may run across platforms, but if it is significantly slower than a vendor’s native toolchain, enterprises will still maintain specialized backends for core workloads.
3. Is the ecosystem open enough? Developers need clarity on which components are open source, which interfaces are stable, and whether third-party chip vendors can independently integrate and optimize their backends.

Therefore, in the short term, the Modular platform is more likely to first unify model deployment workflows and common operators, then gradually expand into lower-level high-performance computing. It will not immediately eliminate hardware differences, nor will it make manual optimization irrelevant.

That does not diminish its significance. Most enterprises are not trying to push every operator to its theoretical peak. They care more about development cycles, hardware choice, inference costs, and production stability. If one platform can deliver performance close to that of native backends while compressing three deployment projects into one, its commercial value is already clear enough.

The On-Device-to-Cloud Transition Is Qualcomm’s Real Story

Qualcomm covers a wide range of devices: phones, PCs, cars, wearables, industrial terminals, and data center accelerators. In the past, although all of these products could run AI, their software environments were relatively fragmented.

Modular could help Qualcomm repackage these products as a distributed AI platform. The same application could choose where to execute based on latency, power consumption, privacy, and cost:

• Lightweight models run locally on the NPU in a phone or PC;
• Complex tasks are assigned to an edge server;
• Large-scale batch processing or high-load inference is sent to a cloud ASIC;
• Sensitive data stays on the device, with only necessary intermediate results sent to the cloud.

Take a personal AI assistant as an example. Wake-word detection, screen-content understanding, and local file retrieval are suitable for on-device execution because they provide fast responses without requiring the original data to be uploaded. More complex planning or large-model inference can be shifted to the cloud. If the on-device and cloud environments use the same model toolchain, development teams do not need to maintain two entirely different engineering systems.

This is also why Qualcomm frequently emphasizes “distributed AI.” It does not intend to directly replicate NVIDIA in large-scale training. Instead, it wants to capture the expansion of inference from the cloud to PCs, phones, cars, and edge devices. Energy efficiency is Qualcomm’s traditional strength, while a unified software stack is necessary to turn that hardware advantage into platform capabilities.

In the Software Ecosystem Battle, Qualcomm Is Finally Catching Up

The Modular platform currently looks more like a clear roadmap than a completed industry standard. Whether it ultimately succeeds will depend on Qualcomm’s ability to continue investing in compilers, framework compatibility, debugging tools, and third-party hardware support, rather than treating Mojo merely as a marketing label for Snapdragon.

If the platform ultimately provides the best experience only on Qualcomm’s own chips while other backends receive slow updates, the so-called “cross-hardware” platform will degenerate into another vendor ecosystem. If it can make NVIDIA GPUs, AMD GPUs, Apple Metal, Qualcomm NPUs, and cloud ASICs equal targets within the same development workflow, Modular may genuinely change how developers choose hardware.

Qualcomm’s assessment is correct: AI competition has shifted from peak computing power to system efficiency and developer ecosystems. Chips determine the performance ceiling, while software determines how much of that performance real applications can actually use.

The problem is that a software ecosystem cannot be built overnight through a single acquisition or product launch. CUDA’s moat comes from long-term compatibility, mature tools, and developer trust. Qualcomm has spent nearly $4 billion to buy its ticket into the competition. It must now prove that the same code can not only “run” on different chips, but also “run well” with sufficiently low cost and dependable stability.

This battle is more difficult than launching a new chip, but it may determine whether Qualcomm is merely a computing-power supplier in the AI era or a true platform company.

Sources

• ITHome: Qualcomm Bets on the AI Ecosystem, with One Software Stack Across All Devices — On-site coverage of the Snapdragon Summit, introducing the Modular platform, Mojo’s native Windows support, and Qualcomm’s on-device and cloud AI software strategy.