M5 Macs and the Metal Tensor API: Why llama.cpp Fails to Start and the Fix to Use

If you run a local LLM on an M5 Mac, the only question that matters before speed is whether the model loads at all. On M5, M5 Pro and M5 Max machines running certain macOS 26 point releases in the 26.2 to 26.4 range, ggml compiled its Metal library from source at runtime to enable the Metal 4 tensor API, that runtime compile failed, and the model never started. M1 through M4 Macs were never affected. Upstream fixed the underlying cause on September 1, 2026, and the fix ships in every llama.cpp build from b10734 onward, including the current b11028 from September 17, 2026.

Does it run on your Mac? The short answer

Three things to take from that table. First, if your Mac is M1 to M4, this article is not about you and nothing here applies. Second, the failure was documented against specific macOS point releases, not against every M5 Mac in existence. Third, the interesting question for M5 owners today is no longer "does it start" but "which build am I actually running", because that single line decides the answer.

What actually happens at startup

The whole mechanism is visible in upstream ggml/src/ggml-metal/ggml-metal-device.m. Four steps, in order:

1. dev->props.has_tensor = [dev->mtl_device supportsFamily:MTLGPUFamilyMetal4_GGML]; The device declares whether it is Metal 4 capable.

2. A name guard then clears the flag for everything that is not an M5, M6, A19 or A20 chip: ggml_metal_device_init: tensor API disabled for pre-M5 and pre-A19 devices. This is why older Macs never enter the tensor path at all.

3. Only if has_tensor is still true does ggml double-check the tensor API by compiling a small dummy kernel from source: testing tensor API for f16 support, then ggml_metal_library_init_from_source: error compiling source.

4. When that compile returns nothing, ggml logs - the tensor API is not supported in this environment - disabling, sets has tensor = false, and carries on. On the affected M5 machines the model did not carry on with it.

The exact log signature that users reported, from whisper.cpp issue 3722:

ggml_metal_device_init: testing tensor API for f16 support
Compiler failed to build request
ggml_metal_library_init_from_source: error compiling source
ggml_metal_device_init: - the tensor API is not supported in this environment - disabling
ggml_metal_device_init: GPU family: MTLGPUFamilyApple10 (1010)
ggml_metal_device_init: has bfloat = true
ggml_metal_device_init: has tensor = false

On the affected machines that was not a cosmetic warning. The Prism ML troubleshooting note adds a follow-on line, ggml_metal_synchronize: error: command buffer 0 failed with status 5, and reports that the failed compile can leave the GPU in a bad state, after which run_llama.sh and start_llama_server.sh produce no output at all. Their issue 93, filed against prebuilt binaries b9591 on an M5 with 24 GB on macOS 26.3.1, ends in repeated out-of-memory errors and no generated tokens.

Why M1 to M4 are not affected

This is the part of the story that is usually explained badly. The common claim is that pre-M5 Macs load the embedded, precompiled Metal library and therefore never compile shaders at runtime. The first half is true, the reasoning is not the reason.

The real reason M1 to M4 escape the bug is step 2 above: the tensor API is switched off by chip name before any probe runs. On an M4, the device even reports Metal 4 family membership, and the flag is still cleared.

We checked this on the machine this article was written on, a MacBook Pro with an M4 and 16 GB of unified memory running macOS 26.6.2 (build 25G83), with llama.cpp build 8230:

ggml_metal_device_init: tensor API disabled for pre-M5 and pre-A19 devices
ggml_metal_library_init: using embedded metal library
ggml_metal_device_init: GPU family: MTLGPUFamilyMetal4  (5002)
ggml_metal_device_init: has bfloat            = true
ggml_metal_device_init: has tensor            = false

Note what that log shows: MTLGPUFamilyMetal4 is present, and has tensor is still false. The device name guard, not the Metal family, is what protects older Macs.

The embedded versus from-source distinction is real but it is a build-time choice (GGML_METAL_EMBED_LIBRARY) that applies to every chip equally. A build compiled with the embedded library off compiles kernels from source at runtime on an M4 too. It is not a pre-M5 privilege, and it is not what kept those machines running.

Two different error signatures, one symptom

The reported failures are not all the same compiler error, and the difference matters when you decide whether a given fix applies to you.

Signature A, the one upstream diagnosed and fixed: the compiler cannot see the tensor headers at all.

program_source:6:17: error: use of undeclared identifier 'mpp'
using namespace mpp::tensor_ops;
program_source:7:46: error: use of undeclared identifier 'dextents'

This is upstream issue 27473, filed on 2026-08-21 against build 10150, still open at the time of writing. The root cause is that MTLCompileOptions.languageVersion was never set, so the shader compiler defaulted to a Metal language version that does not expose metal_tensor and MetalPerformancePrimitives. The reporter isolated it by setting the version by hand: unset fails, 3.2 fails the same way, 4.0 passes. Upstream PR 27461, merged on 2026-09-01 as commit d5d993a09, requests Metal 4.0 when has_tensor is set, loads the tensor kernels from a separate metallib, and adds a guard that clears has_tensor when the library came from a precompiled metallib. That commit is build b10734, published 2026-09-01, and it is an ancestor of b11028.

Signature B, the one with no confirmed fix: the headers compile far enough to hit a type assertion inside Apple's own framework.

error: static_assert failed due to requirement '__tensor_ops_detail::__is_same_v<bfloat, half>'
"Input types must match cooperative tensor types"

This is Ollama issue 15594, filed on 2026-04-15 against Ollama 0.20.7 on an M5 with 16 GB running macOS 26.3.1. It is still open, with the last activity in April 2026, and the reporter notes that OLLAMA_LLM_LIBRARY=cpu does not help because the runner initializes the Metal library before it gets that far. The same top-level signature shows up in whisper.cpp issue 3722, filed 2026-03-26 on an M5 Max with macOS 26.4 and closed in April, where the reporter's own workaround was GGML_METAL_TENSOR_DISABLE=1.

Both signatures end in the same place, the same warning line, and a model that does not load. But they are different compiler failures, and the September fix addresses the first one. If your machine is showing the bfloat and half assertion from Signature B on a build newer than b10734, you are not looking at a regression of the fixed bug.

The fix, in the order you should try it

1. Move to llama.cpp b10734 or newer. The fix merged on 2026-09-01 and shipped in b10734 that same day. The current build at the time of writing is b11028 from 2026-09-17.

2. Confirm the tensor API is actually live. Run any binary that initializes the Metal device and read the init log. You want has tensor = true and no error compiling source line.

3. If you are pinned to an older build, or to an application that bundles its own ggml, disable the tensor API:

GGML_METAL_TENSOR_DISABLE=1 ./scripts/run_llama.sh -p "Hello"
GGML_METAL_TENSOR_DISABLE=1 ./scripts/start_llama_server.sh

4. Do not reach for a CPU fallback as your first move. It is much slower, and on Ollama it did not even avoid the crash, because the Metal library is initialized regardless.

On the flag itself, one correction worth stating plainly: GGML_METAL_TENSOR_DISABLE is not an invention of a third-party fork. It is read in upstream llama.cpp in ggml/src/ggml-metal/ggml-metal-device.m, right next to GGML_METAL_BF16_DISABLE and the inverse GGML_METAL_TENSOR_ENABLE. It is a source-level environment switch, not a documented user-facing option in the upstream docs we could find, so treat it as a diagnostic and compatibility lever rather than an official supported setting.

What you give up by setting it is the tensor path, which is the Neural Accelerator prefill boost. The vendor note frames it that way: full Metal speed is kept, and only the accelerator-assisted prefill is lost. We have not found an independently verified, same-machine, same-build measurement of that gap. The only quantified claim we found is a third-party LM Studio bug report stating that an upstream build with has tensor = true delivered 2 to 3 times faster prompt processing at identical generation speed on an M5 Max. That report also claims a May 2026 upstream build passed the tensor check, which contradicts the upstream root cause that dates the regression to November 2025. We could not test either claim on M5 hardware, so both are unverified. Treat the size of the gain as real but unquantified.

Compatibility by unified memory tier on M5

Every row below is a documented data point, not an extrapolation. Where we found no source, the row says so.

If your tier is not listed, that is because we found no M5-specific log for it. The mechanism does not depend on memory size, so the tier does not change whether you are affected. What changes with memory is only what you can load once the model starts, which is a separate question covered in our M5 Pro 24GB vs 48GB comparison and the M5 Pro and M5 Max local LLM overview.

What is still broken on M5 after the fix

Disabling the tensor API is still a useful lever in September 2026, just for a different reason. Upstream issue 28748, filed on 2026-09-11 and open at the time of writing, reports that once the tensor path is active on an M5, kernel_mul_mm computes wrong slice addresses when the offset between the slice address and the tensor base address reaches 2 GB or more. The environment in that report is a MacBook Air 13 inch with an M5 and 16 GB running macOS 26.6.2 (build 25G83), with the Metal compiler at version 32023.883. A proposed fix is in review. Until it lands, GGML_METAL_TENSOR_DISABLE=1 remains a legitimate workaround for anyone hitting tensor-path corruption on large tensors.

On the current OS side, macOS Tahoe 26.7 shipped on 2026-09-14, after 26.6 on 2026-07-27 and 26.6.2 on 2026-08-17. In our search of the upstream trackers we found no post-fix report of the original startup failure on 26.5, 26.6 or 26.7, and the only post-fix M5 report we found was the different tensor-kernel bug above. That is a statement about what we could find, not a reproduction. We tested on an M4, and we cannot claim an M5 result we did not observe. If you are on an M5 with macOS 26.5 or later and an older pinned build, upgrade the build before you conclude anything.

How to check your own machine

Two commands settle it. First, what are you running:

sw_vers
llama-server --version

Then read the Metal initialization block. This works with llama-server, llama-cli or llama-bench:

llama-server --version 2>&1 | grep -E "tensor|embedded|GPU family"

On an M5 family Mac with a fixed build you want has tensor = true. On an M1 to M4 Mac you want, and will get, this:

ggml_metal_device_init: tensor API disabled for pre-M5 and pre-A19 devices
ggml_metal_library_init: using embedded metal library
ggml_metal_device_init: has tensor            = false

If you see error compiling source followed by the tensor API is not supported in this environment - disabling on an M5 Mac, your build predates b10734 or your application bundles an older ggml. Update the build, or set GGML_METAL_TENSOR_DISABLE=1 and get back to work.

FAQ

Does this affect my M1, M2, M3 or M4 Mac?

No. The tensor API is disabled by chip name before any runtime compile happens, so those machines never enter the failing code path. We verified the guard in upstream source and reproduced the disabled state on an M4 running macOS 26.6.2.

Is GGML_METAL_TENSOR_DISABLE an official llama.cpp option?

It exists in upstream llama.cpp source, in ggml/src/ggml-metal/ggml-metal-device.m, alongside GGML_METAL_TENSOR_ENABLE and GGML_METAL_BF16_DISABLE. We could not find it in the upstream documentation, so call it a source-level switch rather than a documented, supported setting.

Do I still need the workaround in September 2026?

For the startup failure, no, if you run b10734 or newer. For the separate large-tensor bug filed on 2026-09-11 (issue 28748), yes, disabling the tensor API is still the available workaround until that fix lands.

How much speed do I lose by disabling the tensor API?

Only the Neural Accelerator prefill boost, according to the vendor note. We found no independently verified same-machine measurement of the gap, so treat any specific multiplier, including the 2 to 3 times claim from a third-party LM Studio report, as unverified.

My Ollama install still fails on an M5 Mac. Why?

Ollama bundles its own ggml, so your Ollama version decides whether you have the September fix. Issue 15594, filed in April 2026 against Ollama 0.20.7 on an M5 with macOS 26.3.1, shows a different compiler error from the one upstream fixed, and it is still open. Check your Ollama version against the current release before assuming the upstream fix reached you, and see our Ollama on Mac install guide for the version check commands.

Related on ModelFit: M5 Pro and M5 Max for local LLMs in 2026 · M5 Pro 24GB vs 48GB · llama.cpp 0.4.0 on Mac: lazy tensors, RDMA, sparse attention · Install Ollama on Mac