无法启动，或识别不到 GPUmacOS最后更新 2026年11月6日

Apple Silicon: model won't use the GPU / Metal not engaged

My M-series Mac is running the model on the CPU

作者 Jakub Rusinowski

错误信息

ggml_metal_init: failed to allocate buffer
你遇到的是哪一种？
如果你看到原因是前往
Activity Monitor's GPU History stays flat while the model generatesMetal is not engaged; the model runs on the CPUFix 2: run a native arm64 build
uname -m prints x86_64 in your terminalThe terminal, and everything it starts, runs under RosettaFix 2: run a native arm64 build
ggml_metal_init: failed to allocate buffer while loadingWeights plus cache exceed the GPU's share of unified memoryFix 1, then Fix 4
Metal is engaged, but only some layers are on the GPUThe GPU-layer setting is too lowFix 3: push layers onto the GPU

何时出现

On an M1/M2/M3/M4 Mac the model either runs slowly with no GPU activity in Activity Monitor, or it dies with a Metal buffer allocation error. You expected the Apple GPU to do the work and it isn't — or it tried and ran out of room.

  • Running an Ollama or llama.cpp build installed through an Intel Homebrew under /usr/local, which runs under Rosetta.
  • Loading a model whose weights alone take most of your unified memory, such as a 14B model at Q8 on a 16 GB Mac.
  • Setting a long context, which adds gigabytes of cache on top of weights that fit.
  • Running a llama.cpp command copied from a CPU-only tutorial that sets -ngl 0.
  • Keeping a browser, an IDE and a second model open, so less memory is free for the GPU.

实际原因

Apple Silicon shares one pool of unified memory between the CPU and GPU, and llama.cpp/Ollama use Apple's Metal backend to run on the GPU. Two things go wrong: either Metal isn't engaged (an x86 build running under Rosetta, or zero GPU layers), so everything falls to the CPU; or Metal *is* engaged but the model plus context exceeds the slice of unified memory macOS will hand the GPU, so the buffer allocation fails. Either way it ties back to size — big models crowd a shared memory pool. The GPU's share is a limit Metal reports as recommendedMaxWorkingSetSize, which llama.cpp prints when it starts. It is commonly around 65–75% of unified memory, depending on the Mac and the macOS version, and that ceiling — not the total on the box — is what each buffer allocation is checked against. It can be raised with a system setting, but the extra memory comes from macOS and your other apps, so treat that as a last step rather than a first one.

如何修复

  1. 1

    Pick a model sized for your unified memory最常见的修复方法

    On a Mac your "VRAM" is a portion of total unified memory, and macOS won't give all of it to the GPU. An 8 GB Mac comfortably runs 3B–7B models at Q4; 16 GB opens up larger ones; 32 GB+ handles the big ones. Matching the model to your memory is what keeps Metal allocations from failing. Check what your specific Mac can hold before downloading.

    生效了吗？The model loads, and the recommendedMaxWorkingSetSize that llama.cpp prints at startup is larger than the model's size plus its context cache.
    检查哪些模型适配你的硬件see which models fit your Mac’s unified memory打开显存检查器 →
  2. 2

    Make sure you are running a native arm64 build

    An Intel build of llama.cpp running under Rosetta will not use Metal — it runs on the CPU only. Confirm your binary is native arm64. If you built from source, build with Metal enabled.

    bash
    # should print "arm64", not "x86_64"
file $(which ollama)
uname -m
    生效了吗？Both commands report arm64. If uname -m prints x86_64, the terminal itself runs under Rosetta: quit it, untick Open using Rosetta in the terminal app's Get Info window, and reopen it.
  3. 3

    Push layers onto the GPU (llama.cpp)

    With the Metal build, offload all layers to the GPU. On llama.cpp that's -ngl set high (or -1). Ollama enables Metal automatically, so if it's still on CPU there, suspect a Rosetta/x86 install.

    bash
    ./llama-cli -m model.gguf -ngl 999
    生效了吗？The load log reports every layer offloaded, and Activity Monitor's GPU History shows sustained activity while tokens are generated.
  4. 4

    Lower context if the Metal buffer fails

    If Metal is engaged but you hit the allocation error, the KV cache for a long context is likely tipping you over the unified-memory slice. Reduce the context length and retry.

    生效了吗？The model loads at the shorter context. If you need the longer one, the remaining options are a smaller quant or raising the GPU memory limit.

如果以上都没用

If the build is native, the model fully offloaded and generation still slow, check whether the Mac is swapping or throttling — both look like a GPU problem and are not. If Metal allocations fail on a model that should fit, the GPU's memory ceiling is the next thing to examine.

上报问题时请附上这些信息
  • The ggml_metal_init lines from the log, including recommendedMaxWorkingSetSize
  • Mac model, chip and unified memory size
  • Output of uname -m and file $(which ollama)
  • Model, quantization and context length

相关内容

常见问题

Does my Mac's GPU have separate VRAM?

No. Apple Silicon uses unified memory shared by the CPU and GPU. Your effective "VRAM" is a portion of total RAM, and macOS reserves some for the system — so a 16 GB Mac does not give all 16 GB to the model.

How do I confirm the model is using the GPU on a Mac?

Open Activity Monitor → Window → GPU History (or run sudo powermetrics --samplers gpu_power) while generating. Real GPU activity means Metal is engaged; a flat line means it is running on the CPU.

Why does the same model run on my friend’s Mac but not mine?

Almost always unified-memory size. A 32 GB or 64 GB Mac can hold models that simply do not fit on an 8 GB or 16 GB machine. Pick a model matched to your memory rather than theirs.

How much of my Mac's memory can the GPU use?

By default macOS lets the GPU use a working set of roughly 65–75% of unified memory, depending on the machine and the macOS version. llama.cpp prints the exact figure as recommendedMaxWorkingSetSize when it starts. The limit can be raised, but the memory then has to come from macOS and your other apps.

Is MLX faster than llama.cpp on a Mac?

Sometimes. MLX is Apple's own framework and is often competitive or faster for the models it supports well, but the gap varies by model family and quantization, and llama.cpp-based tools such as Ollama are simpler to set up. Benchmark both on the model you actually use before switching.

Do Intel Macs have this problem?

Not in this form. These tools do not get Apple Silicon's unified-memory GPU path on an Intel Mac, so models run on the CPU there. That is a hardware limit rather than a setting you can change, and the Intel Mac page covers what still works and at what speed.

Does Ollama use the GPU on a Mac automatically?

Yes, on Apple Silicon. The macOS app and the official binary are built with Metal and offload layers to the GPU without any flag. If ollama ps shows 100% CPU on an M-series Mac, suspect an x86 install running under Rosetta or a model too large for the GPU's share of memory, in that order.