APIC portability onto other devices

Description

Currently, Warp APIC can save captured graphs as .wrp files with companion kernel artifacts such as .cubin or .ptx files. This is useful because it allows a graph captured in Python to be loaded later from Python or from a standalone C++ runtime. However, the exported artifact is still tied closely to the GPU architecture used during capture, especially when the saved modules are architecture-specific .cubin files.

This becomes a limitation when the export machine and deployment machine do not have the same GPU architecture. A common workflow is to export a graph on a server or desktop GPU, then deploy the saved artifact onto a different runtime device. In those cases, the .wrp file should ideally describe the captured computation in a way that can be compiled or resolved for the target device at load time.

ONNX and TorchScript are useful examples of this kind of portability. They serialize a higher-level representation of the computation, and the runtime can then optimize, compile, or lower that representation for the target platform. A similar workflow for Warp APIC would make .wrp files more useful as deployment artifacts across different CUDA devices.

The request is for Warp to provide a first-class portable export/load workflow for .wrp files.

Context

When performing export tasks, it is common to capture or save the graph on a development machine, build server, or desktop workstation, then move the artifacts to a runtime device for inference or deployment. The runtime device may be a different GPU generation than the machine that produced the .wrp file, so requiring the same compute capability makes the export less portable.

This matters for workflows where .wrp files are treated as deployment artifacts rather than local cache files. If the graph can only be loaded reliably on the same GPU architecture used during export, then users need to regenerate the artifact for each target device or maintain separate exports for each architecture. That adds friction to deployment and makes the export process harder to automate.

It would be helpful if Warp documented and supported a portable mode for APIC exports. For example, users could export a .wrp file once with architecture-independent kernel information, then load it on a different CUDA device and have Warp compile or select the correct kernel module for that device.

At a minimum, the load-time error should clearly explain when a .wrp file is missing support for the current GPU architecture and what the user should do to produce a compatible artifact. Ideally, the .wrp workflow would support cross-architecture portability directly, including for standalone C++ replay.