Metal is not CUDA with different syntax. The two stacks diverge at the memory model before they diverge at the kernel language, and that is the part teams underestimate when they budget a port to Apple silicon. CUDA assumes a discrete device with explicit host-to-device transfers; Metal on Apple silicon assumes unified memory with shared buffers. Rewriting the kernels is the cheap half of the work. Re-architecting the data movement — or deleting it, since unified memory removes a whole class of copies — is where the estimate actually lives.
Where do Metal and CUDA diverge?
At the point where you decide who owns the data. A CUDA codebase that has been optimised for a discrete GPU carries assumptions in its structure: pinned host buffers, asynchronous copy streams overlapped with compute, tiling chosen around a specific shared-memory size and occupancy target. On Apple silicon there is no PCIe hop to hide, so the copy-overlap machinery becomes dead weight, while the occupancy heuristics tuned for NVIDIA streaming multiprocessors do not transfer. This is the same portability cost we see in any CUDA exit: CUDA-specific memory patterns do not port performantly, and Metal is no exception.
The corollary is more useful than the warning. Because the divergence is architectural, the portable fraction of a codebase is measurable before anyone writes a line of Metal Shading Language. In our GPU work the three numbers that decide the scope are the count of kernels needing a genuine rewrite, the share of runtime currently spent inside vendor libraries with no Metal equivalent, and the host-device transfer volume that unified memory eliminates outright.
Scoping table
| Question to answer | What it tells you |
|---|---|
| How many kernels are portable logic vs NVIDIA-specific optimisation? | Whether this is a two-sprint deliverable or a parallel codebase |
| What share of runtime sits in cuDNN-class libraries? | The size of the ecosystem gap you must reimplement or accept |
| How much host-device transfer disappears under unified memory? | The one structural win Apple silicon hands you for free |
| Is the Mac target a workstation, a creative tool, or a training rig? | Whether Metal is the only first-class path or the wrong one |
| What is the three-year maintenance cost of two GPU paths? | Whether the port ever amortises |
When a Metal port is worth scoping
The details of Metal vs CUDA matter at this point. If the target is training or large-batch inference, the ecosystem gap dominates any raw throughput comparison — cuDNN-class library coverage, profiler maturity, and multi-GPU scaling have no direct Metal equivalent, and no amount of favourable per-chip bandwidth closes that. On-device inference for Apple platforms sits in the first camp; a Metal path there is not a portability exercise but the product requirement.
The uncomfortable answer for teams wanting one codebase across Apple, AMD, Intel, and NVIDIA hardware is that portability layers move the cost rather than removing it. We treat this as an audit question, not a preference question: our GPU acceleration and optimisation practice starts a port assessment by classifying kernels as portable logic or vendor-encoded optimisation, because that split is what turns a Metal decision into a number.
So the question worth asking before the first kernel is translated: what fraction of your current GPU runtime is logic you own, and what fraction is NVIDIA’s library work you have been renting?
