M5 Macs: llama.cpp runtime 2.21 fails Metal tensor-API check — Neural Accelerators unused, 2–3× prefill lost (GGUF; MLX nax pack unaffected)

[oooseun]

Summary

On M5-generation Macs, LM Studio's llama.cpp runtime never enables the Metal 4 tensor API (GPU Neural Accelerators), even though the runtime's binaries contain the upstream tensor-API code. Every GGUF model load logs:

ggml_metal_device_init: - the tensor API is not supported in this environment - disabling

The same GGUF files on the same machine with an upstream llama.cpp release binary (b9592) pass the tensor-API check (has tensor = true) and deliver 2–3× faster prompt processing at identical generation speed. The MLX side is fine — the mlx-llm-mac-arm64-apple-metal-nax-advsimd pack targets M5 and uses the accelerators. Only the GGUF/llama.cpp runtime misses them.

Environment

• MacBook Pro, M5 Max (40-core GPU), 128 GB, macOS 26.5 (25F71)
• LM Studio / lms 0.4.14+4
• Runtime: llama.cpp-mac-arm64-apple-metal-advsimd@2.21.0 (newest on stable and beta as of 2026-06-11)

Evidence

1. The runtime contains the tensor-API code — strings on the shipped libggml-metal.dylib includes GGML_METAL_TENSOR_DISABLE, testing tensor API for f16 support, tensor API disabled for pre-M5 and pre-A19 devices, etc. So this is not an old llama.cpp snapshot; the runtime runs the environment self-test and fails it. A plausible cause is the bundled/prebuilt Metal library being compiled against a pre-Metal-4 SDK or deployment target, so the tensor-op test kernels fail to compile at init.

2. Upstream llama.cpp on the same machine passes the check. Release b9592 (stock macOS arm64 binary, no rebuild) logs has tensor = true on M5 Max.

3. A/B on the same model files (llama-bench -fa 1 -p 2048 -n 128 -r 2; tensor API toggled via GGML_METAL_TENSOR_DISABLE=1):

Model (GGUF)	tensor OFF (≈ LM Studio behavior)	tensor ON	delta
gpt-oss-120b MXFP4 — pp2048	877 t/s	1,833 t/s	2.09×
gpt-oss-120b — tg128	104.9	105.1	unchanged
Step-3.7-Flash IQ3_XXS — pp2048	342 t/s	833 t/s	2.44×
Step-3.7-Flash — tg128	58.2	56.0	unchanged (within noise)

LM Studio's own serving path measures in line with the "tensor OFF" column or below (e.g. ~270 t/s prefill for Step-3.7-Flash via the REST API at ~3.3k-token prompts).

Generation speed is unaffected (memory-bandwidth-bound), so this is invisible in casual chat — but time-to-first-token on long prompts, RAG, and agentic/tool-call workloads is 2–3× slower than the hardware can do.

Expected behavior

The llama.cpp runtime enables the Metal tensor API on M5-family devices running macOS ≥ 26.2, matching upstream llama.cpp defaults (upstream PR ggml-org/llama.cpp#16634) — or ships an M5-targeted pack the way the MLX nax pack already does.

Repro

1. Any M5/M5 Pro/M5 Max Mac on macOS ≥ 26.2, LM Studio with llama.cpp runtime 2.21.0.
2. Load any GGUF model; check the server log for ggml_metal_device_init.
3. Observe the tensor API is not supported in this environment - disabling.
4. Compare prompt-processing speed against upstream llama-bench b9592 on the same file.

Happy to provide full logs or run diagnostics on this machine if useful.

[wintercharm]

Having the same issue -- you can see it in the logs:

2026-07-05 21:08:17 [DEBUG]
0.00.035.692 E ggml_metal_library_init_from_source: error compiling source
0.00.035.697 W ggml_metal_device_init: - the tensor API is not supported in this environment - disabling

This is on an M5 Max Macbook Pro.

[Portll]

I've confirmed the root cause: the engine binaries are built with minos 14.0 / sdk 14.5, so the runtime shader compile defaults to Metal 3.2, where <metal_tensor> doesn't exist. This bug is still present in runtime 2.28.2.

Environment

LM Studio	0.4.20+1 (build 0.4.20+1)
macOS	26.4 (build 25E246)
Hardware	MacBook Pro, Apple M5 Pro (20-core GPU, 38(48) GB), Metal 4
Runtimes affected	llama.cpp-mac-arm64-apple-metal-advsimd 2.25.2, 2.27.1, 2.28.2 (all tested)
MLX	unaffected (mlx-llm-…-nax-advsimd@1.11.0 works, as OP noted)

Root cause

The OP's hypothesis — "compiled against a pre-Metal-4 SDK or deployment target" — is exactly right. Proof chain:

1. The shipped binaries target macOS 14

$ otool -l ~/.lmstudio/extensions/backends/llama.cpp-mac-arm64-apple-metal-advsimd-2.28.2/libggml-metal.dylib \
    | grep -A4 LC_BUILD_VERSION
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 14.0
      sdk 14.5

(llama-server itself: same minos 14.0 / sdk 14.5.)

2. ggml never sets an explicit Metal language version

The only MTLCompileOptions setter referenced by libggml-metal.dylib is setPreprocessorMacros: — there is no setLanguageVersion:. Per Apple's documented behavior, the default languageVersion for a runtime newLibraryWithSource: compile follows the calling binary's deployment target — for a minos-14 binary that resolves to Metal 3.2, which predates the tensor API.

3. The exact probe kernel compiles fine on this machine — just not at Metal 3.2

I extracted the embedded tensor-API test kernel (the mpp::tensor_ops::matmul2d dummy_kernel) from the shipped dylib and compiled it via MTLDevice.makeLibrary(source:) from a plain Swift process:

Language version	Result
default (modern deployment target)	✅ compiles OK
explicit .version4_0	✅ compiles OK
explicit .version3_2 (= a minos-14 binary's default)	❌ fails

The 3.2 failure:

program_source:6:17: error: use of undeclared identifier 'mpp'
using namespace mpp::tensor_ops;
                ^
program_source:9:26: error: use of undeclared identifier 'dextents'
    tensor<device  half, dextents<int32_t, 2>> A [[buffer(0)]],
                         ^

That is what ggml_metal_library_init_from_source: error compiling source is swallowing — this code path logs the no-detail variant (%s: error compiling source) rather than the variant that includes the NSError (%s: error compiling source: %s), which is why the real diagnostic has never appeared in anyone's logs.

4. Why upstream passes on the same machine

This also explains the OP's observation that upstream release b9592 logs has tensor = true on the same hardware: upstream binaries are built with a newer deployment target, so their default language version is ≥ 4.0.

Repro harness

Self-contained Swift file. The kernel is the f16 probe embedded in the shipped 2.28.2 dylib (identical modulo trailing whitespace — extract your own copy to verify:

python3 -c "import re;d=open('libggml-metal.dylib','rb').read();print([s for s in re.findall(rb'#include <metal_stdlib>.{0,2000}?\x00',d,re.S) if b'metal_tensor' in s][0].decode())").

// tensor_probe.swift — run with: swift tensor_probe.swift
import Metal

let src = """
#include <metal_stdlib>
#include <metal_tensor>
#include <MetalPerformancePrimitives/MetalPerformancePrimitives.h>

using namespace metal;
using namespace mpp::tensor_ops;

kernel void dummy_kernel(
    tensor<device  half, dextents<int32_t, 2>> A [[buffer(0)]],
    tensor<device  half, dextents<int32_t, 2>> B [[buffer(1)]],
    device float * C [[buffer(2)]],
    uint2 tgid [[threadgroup_position_in_grid]])
{
    auto tA = A.slice(0, (int)tgid.y);
    auto tB = B.slice((int)tgid.x, 0);

    matmul2d<
        matmul2d_descriptor(16, 16, dynamic_extent),
        execution_simdgroups<4>> mm;

    auto cT = mm.get_destination_cooperative_tensor<decltype(tA), decltype(tB), float>();

    auto sA = tA.slice(0, 0);
    auto sB = tB.slice(0, 0);
    mm.run(sB, sA, cT);

    auto tC = tensor<device float, dextents<int32_t, 2>, tensor_inline>(C, dextents<int32_t, 2>(16, 16));

    cT.store(tC);
}
"""

guard let dev = MTLCreateSystemDefaultDevice() else { fatalError("no Metal device") }
print("device: \(dev.name)")

let cases: [(String, MTLLanguageVersion?)] = [
    ("default", nil),
    ("4.0", .version4_0),
    ("3.2 (= minos-14 binary default)", .version3_2),
]
for (label, ver) in cases {
    let opts = MTLCompileOptions()
    if let v = ver { opts.languageVersion = v }
    do {
        _ = try dev.makeLibrary(source: src, options: opts)
        print("[\(label)] COMPILE OK")
    } catch {
        print("[\(label)] COMPILE FAILED:")
        print("\(error.localizedDescription.prefix(600))")
    }
}

Output on this machine (M5 Pro, macOS 26.4):

device: Apple M5 Pro
[default] COMPILE OK
[4.0] COMPILE OK
[3.2 (= minos-14 binary default)] COMPILE FAILED:
program_source:6:17: error: use of undeclared identifier 'mpp'
...

Suggested fix

Either works:

1. Build the engine packs against a macOS 26 SDK / raise the deployment target; or
2. Cheaper, keeps minos 14: set MTLCompileOptions.languageVersion = MTLLanguageVersion4_0 explicitly (guarded by an OS-version check) when compiling the tensor-API probe and the Metal library from source.

Also worth logging the NSError on the probe-compile failure path so this class of issue is self-diagnosing in future.

Happy to run further diagnostics on this machine.