{"slug": "build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4", "title": "Build in the VM, Think on the Mac GPU: Debian 13 on Apple container With a Local Gemma 4", "summary": "A developer documented a workflow for running a Debian 13 Linux VM under Apple's container CLI on Apple silicon while offloading LLM inference to a local Gemma 4 model via Ollama on the Mac's Metal GPU. The setup splits work between the VM, which hosts the application, and macOS, which runs the model, with the VM reaching Ollama over the VM network at 192.168.64.1:8000. The writeup also flags that the official debian:13 image lacks /sbin/init and fails to boot silently under container machine create.", "body_md": "This article walks through building a Debian 13 machine under Apple's `container` CLI on an Apple silicon Mac, and then wiring that machine to a local LLM running on the Mac's own GPU.\n\n**The VM is where your app lives. The Mac is where the model thinks.** A Linux VM under `container` gets virtual CPUs and virtual devices and no Metal access, so running a model inside it wastes the one piece of hardware that makes a Mac good at this. The split that works is the obvious one once you see it: customize your app in a real Debian box, run it with `container machine run`, and have it call Ollama on macOS over the VM network.\n\nGetting there has two halves, and the first one fails silently. `container machine create debian:13` succeeds. The machine is created. It just never boots, and nothing on the command line tells you why.\n\n`debian:13` image has no `/sbin/init`` stopped` forever.`systemd-sysv`` 192.168.64.1``0.0.0.0`` brew services restart` silently undoes that`gemma4:e2b` answered at [https://github.com/xbill9/apple-container-debian-tips](https://github.com/xbill9/apple-container-debian-tips)\n\nEverything below was run on 2026-09-13:\n\n|  | Mac | VM | \n|---|---|---|\n| Hardware | Apple M3, 8 GB | 2 CPUs, 2 GB | \n| OS | macOS 27.0 (26A428) | Debian GNU/Linux 13 (trixie) | \n| Kernel | Darwin | Linux 6.18.35 aarch64 | \n| Runtime | `container` 1.4.1 | systemd, `running` | \n| LLM | Ollama 0.33.3 on Metal | calls `http://192.168.64.1:8000` | \n\n**8 GB is the constraint that shapes every choice here.** One model, one 2 GB machine, and the image builder stopped when it is not building.\n\n`container` does not run on anything else.\nSteps 0 through 5 build the VM. Steps 6 through 9 add the model. The two halves are independent, and **Step 7 tests the Mac on its own before a VM is involved**, which is what makes a failure in Step 9 easy to place.\n\nThis distinction caused the most confusion, so it goes first. `container` runs Linux in two ways:\n\n|  | **Container** | **Machine** | \n|---|---|---|\n| What runs | one program from the image | a whole booted Linux system (systemd) | \n| Disk | throwaway | persistent | \n| Your Mac home folder | not mounted | mounted at `/Users/<you>` | \n| You are | root | your own Mac user (uid 501) | \n| Official `debian:13` works? | **yes, as-is** | **no** | \n\nA container is fine for running one command. **A machine is what you want for an app you keep customizing** — packages you installed yesterday are still there, your source tree is already mounted, and services start under systemd like they would on any Debian server.\n\nAnd `container` is not Docker. There is no Docker Desktop, no `dockerd` and no containerd process. Each container and each machine runs in its own lightweight VM, managed by Apple's own launchd agents. The images, though, are ordinary OCI images, so Docker Hub works.\n\nDownload the signed `.pkg` from [https://github.com/apple/container/releases](https://github.com/apple/container/releases) and verify it:\n\n```\npkgutil --check-signature container-1.4.1-installer-signed.pkg\n# Developer ID Installer: Apple Inc. - Containerization (UPBK2H6LZM)\n# Notarization: trusted by the Apple notary service\n```\n\n**`sudo installer` needs a real TTY**, so either run it in a Terminal window or use the GUI installer:\n\n```\nopen container-1.4.1-installer-signed.pkg\n```\n\nThen start the services. `container system start` stops to ask about downloading a Linux kernel, and a script cannot answer that prompt, so set the kernel explicitly:\n\n```\ncontainer system start\ncontainer system kernel set --recommended\ncontainer system status\n#    status              running\n#    client.version      1.4.1\n#    server.version      1.4.1\n```\n\nThat pulls the Kata Containers kernel. Without it, nothing runs.\n\n**This step exists because the failure is invisible.** Pull the image and look for an init:\n\n```\ncontainer image pull docker.io/library/debian:13\ncontainer run --rm debian:13 sh -c 'ls -l /sbin/init; command -v ps ip less sudo; echo done'\nls: cannot access '/sbin/init': No such file or directory\ndone\n```\n\nNo init, and no `ps`, `ip`, `less` or `sudo` either. A container never boots, so its image does not need an init. A machine boots a kernel, and Apple's `/sbin.machine/init` ends with a hard-coded `exec /sbin/init`. Try it anyway and the logs say so:\n\n```\ncontainer machine create debian:13 --name debian13-vm   # creates, but never boots\ncontainer machine logs debian13-vm\n# /sbin.machine/init: 74: exec: /sbin/init: not found\ncontainer machine delete debian13-vm\n```\n\n**`container machine logs <n>` is the first place to look when a machine will not boot.** Apple's own docs use `alpine:3.22` because BusyBox happens to provide `/sbin/init`.\n\nIn an empty directory, create `Dockerfile`:\n\n```\nFROM debian:13\nENV DEBIAN_FRONTEND=noninteractive\nRUN apt-get update \\\n    && apt-get install -y --no-install-recommends \\\n        systemd-sysv dbus sudo ca-certificates procps less iproute2 iputils-ping curl \\\n    && rm -rf /var/lib/apt/lists/*\nRUN systemctl mask systemd-modules-load.service\nRUN : > /etc/machine-id && rm -f /var/lib/dbus/machine-id\nCMD [\"/sbin/init\"]\n```\n\nEvery line is there because something broke without it:\n\n| Line | Why | \n|---|---|\n| `systemd-sysv` | Provides `/sbin/init` , the one hard requirement | \n| `procps less iproute2 iputils-ping curl ca-certificates` | The basic tools the official image leaves out. `curl` is how the VM will call the model. | \n| `sudo` | First boot already gives your Mac user passwordless sudo; only the package is missing | \n| `dbus` | The system message bus that systemd services use | \n| `systemctl mask systemd-modules-load.service` | Apple's kernel has no loadable modules, so this unit always fails and systemd reports `degraded` | \n| `: > /etc/machine-id && rm -f /var/lib/dbus/machine-id` | Installing dbus writes a machine ID into the image. Without this line **every machine from the image shares one ID** | \n| `CMD [\"/sbin/init\"]` | Ignored by machines, but marks this as a machine image | \n\nThe machine-id line is the one I found the hard way. Every machine I created had the same ID, across separately built images and even from a snapshot whose `/etc/machine-id` was emptied — because systemd copies dbus's build-time copy into an empty `/etc/machine-id` at boot. Emptying one file is not enough. Remove the other.\n\nBuild it. The builder holds 2 CPUs and 2 GB while it runs, and `container build` starts it but never stops it:\n\n```\ncontainer builder start\ncontainer build -t debian13-machine .\ncontainer builder stop\n```\n\nThe build took about 10 seconds. `debconf: ... Readline` lines only mean there is no terminal.\n\nThis is the check I skipped the first time:\n\n```\ncontainer run --rm debian13-machine sh -c 'ls -l /sbin/init; wc -c < /etc/machine-id; ls /var/lib/dbus/machine-id'\nphp\nlrwxrwxrwx 1 root root 22 Apr 13 19:38 /sbin/init -> ../lib/systemd/systemd\n0\nls: cannot access '/var/lib/dbus/machine-id': No such file or directory\n```\n\nYou want `/sbin/init` present, a 0-byte machine-id, and no dbus copy. Check with `ls`, not `readlink -f` — `readlink -f /sbin/init` prints a path even when the file is missing.\n\n```\ncontainer machine create debian13-machine --name dev-vm --cpus 2 --memory 2G\n```\n\n`create` returns in about a second, **before the VM has booted**. A command sent straight away fails with an error that points in completely the wrong direction:\n\n```\nError: The operation couldn’t be completed. Operation not supported on socket\n```\n\nThat is not a socket problem and not a TTY problem. It is a machine that has not finished booting. Poll until it answers — 13 seconds here:\n\n```\nuntil container machine run -n dev-vm --root -- true 2>/dev/null; do sleep 2; done\n```\n\nThen give systemd a few more seconds. `systemctl is-system-running` says `initializing` for a while after first boot.\n\n```\ncontainer machine run -n dev-vm -- '. /etc/os-release; echo \"$PRETTY_NAME\"; uname -srm; systemctl is-system-running; id; sudo -n id -u; nproc'\nDebian GNU/Linux 13 (trixie)\nLinux 6.18.35 aarch64\nrunning\nuid=501(xbill) gid=20(dialout) groups=20(dialout)\n0\n2\n```\n\n`running`, not `degraded` or `initializing`: systemd is fully up.` id`: you are your Mac user, created in the VM on first boot.` sudo -n id -u` printed `0`: passwordless sudo works.`/Users/<you>`.\n**Pass a command as one quoted argument.** `machine run` joins its arguments with spaces and re-parses them with `/bin/bash -c` inside the VM, so your host-side quoting is lost:\n\n```\ncontainer machine run -n mkdm-test-vm --root -- echo '$0' 'a    b'\n# /bin/bash a b          ($0 expanded in the VM, spaces collapsed)\n```\n\nSo `-- sh -c '...'` silently runs the wrong command and prints nothing. The snippet is already run by bash; hand it over whole.\n\nThis is the part a container cannot do. Anything you install lives on the machine's own disk:\n\n```\ncontainer machine run -n dev-vm --root -- 'apt-get update && apt-get install -y --no-install-recommends git vim-tiny'\n```\n\nAnd it survives a restart:\n\n```\ncontainer machine stop dev-vm                         # takes about 10 s\ncontainer machine run -n dev-vm -- 'git --version'    # boots it again\n# git version 2.47.3\n```\n\nAfter a restart, `machine run` answers before systemd does — `systemctl` said `Failed to connect to system scope bus` for the first few seconds. Wait before using it.\n\n**Deleting the machine deletes these changes.** To keep them, add the packages to the Dockerfile and rebuild, or snapshot the machine into an image.\n\nInteractive shells need a real Terminal window; from scripts and agent tools they fail with the same \"not supported\" error as Step 4:\n\n```\ncontainer machine run -n dev-vm            # shell as you\ncontainer machine run -n dev-vm --root     # shell as root\n```\n\nSteps 2 through 5 are what `bin/mkdebian-machine` in the repo does, including the `/sbin/init` check, the boot poll, and stopping the builder if it was stopped before. A `--setup` script runs inside the new machine as root:\n\n```\nbin/mkdebian-machine new -t debian13-machine -m dev-vm -p sudo\nbin/mkdebian-machine new -m dev-vm -p \"git vim\" --setup ./setup-dev.sh\n```\n\n`-p` packages are baked into the image. `--setup` changes only that machine. `bin/mkdebian-machine publish dev-vm <ref>` snapshots a hand-customized machine into an image and scrubs your user, SSH host keys and logs first.\n\n**A VM gets no GPU.** Linux inside `container` sees virtual CPUs and virtual devices and has no Metal access. A model running there runs on CPU, in the 2 GB you gave the machine.\n\nSo the model runs on **macOS**, where Ollama uses the M3 GPU, and the VM calls it over the VM network:\n\n```\ndev-vm      192.168.64.x         (changes on restart)\n    │  default route + DNS → 192.168.64.1\n    ▼\nvmenet0 ─ bridge100 on the Mac  192.168.64.1   ← the Mac itself on the VM network\n    │\nOllama  *:8000  →  Metal GPU\n```\n\n`bridge100`. It is the VM's gateway and DNS server, and `host.docker.internal` or `host.container.internal`. Use the IP.` 127.0.0.1` the VM cannot reach it.\nInstall Ollama and a model that fits in 8 GB:\n\n```\nbrew install ollama\nbrew services start ollama\nOLLAMA_HOST=127.0.0.1:8000 ollama pull gemma4:e2b\n```\n\nOllama runs as a Homebrew launchd service. This Mac's plist had already been customized to port 8000 with `OLLAMA_KV_CACHE_TYPE=q4_0` and `OLLAMA_FLASH_ATTENTION=1`, so only the host changes. Homebrew's own default is `127.0.0.1:11434`; set port 8000 too, or adjust the URLs below.\n\n```\nP=~/Library/LaunchAgents/homebrew.mxcl.ollama.plist\ncp -p \"$P\" \"$P.bak-$(date +%Y%m%d%H%M%S)\"\n/usr/libexec/PlistBuddy -c 'Set :EnvironmentVariables:OLLAMA_HOST 0.0.0.0:8000' \"$P\"\n\n# restart so launchd rereads the plist\nlaunchctl bootout gui/$(id -u)/homebrew.mxcl.ollama\nlaunchctl bootstrap gui/$(id -u) \"$P\"\n\nlsof -nP -iTCP:8000 -sTCP:LISTEN     # ollama  *:8000\n```\n\n**Do not use `brew services restart ollama`.** It regenerates the plist from the formula, which sets only `OLLAMA_FLASH_ATTENTION=1` and `OLLAMA_KV_CACHE_TYPE=q8_0`. That silently puts `OLLAMA_HOST` back to localhost — and the VM stops reaching the model with no change on the VM side at all.\n\nThis setup is open on purpose. With `0.0.0.0` and the macOS application firewall off, Ollama was also reachable from the Wi-Fi network. For a demo on a home network that is the point. Anywhere else, it is the first thing to change.\n\n`bin/test-mac-ollama` checks Ollama on the Mac without a VM involved: the listener, localhost and `192.168.64.1`, the plist, the native, streaming and OpenAI-compatible APIs, and GPU placement. It unloads the models on exit and exits 0 only when every check passes.\n\n```\nbin/test-mac-ollama\n== 1. listener on port 8000\n  ollama *:8000\n  PASS  ollama listens on all interfaces, so VMs can reach it\n== 2. HTTP on http://127.0.0.1:8000\n  PASS  Ollama 0.33.3 answers on http://127.0.0.1:8000\n== 3. VM-facing address 192.168.64.1\n  PASS  Ollama answers on http://192.168.64.1:8000 (bridge100), the address VMs use\n== 4. launchd config\n  info  OLLAMA_HOST in plist: 0.0.0.0:8000\n== 5. models\n  PASS  gemma4:e2b is installed\n== 6. native API\n  23 tokens @ 43.6 tok/s, load 5.7 s\n  PASS  gemma4:e2b answered through /api/generate\n== 7. streaming\n  PASS  streaming delivers incremental chunks\n== 8. OpenAI-compatible API\n  PASS  /v1/chat/completions returned text\n== 9. GPU\n  PASS  gemma4:e2b loaded 100% on the GPU (1.6 GB)\n== 10. second model: gemma4:e2b-it-qat\n  33 tokens @ 43.3 tok/s, load 7.5 s\n  PASS  gemma4:e2b-it-qat answered through /api/generate\n  PASS  gemma4:e2b-it-qat loaded 100% on the GPU (3.3 GB)\n\n10 passed, 0 failed\nOllama works on the Mac. Next: bin/test-vm-ollama\n```\n\n**The order is the point.** If this passes and the VM test fails, the problem is the VM or the network path, not Ollama. Its check 3 is skipped until a container or machine has created `bridge100`, which is one more reason to build the VM first.\n\nNow from inside Debian. These runs used my long-lived machine, `debian13-vm`, built from the same kind of image; substitute `dev-vm`. The native API:\n\n```\ncontainer machine run -n debian13-vm -- 'curl -s http://192.168.64.1:8000/api/generate -d \"{\\\"model\\\":\\\"gemma4:e2b\\\",\\\"prompt\\\":\\\"Say hello from a Debian VM in five words.\\\",\\\"stream\\\":false,\\\"think\\\":false}\"'\n# \"response\":\"Hello from Debian VM.\"\n```\n\nAnd the OpenAI-compatible API, with base URL `http://192.168.64.1:8000/v1`:\n\n```\ncontainer machine run -n debian13-vm -- 'curl -s http://192.168.64.1:8000/v1/chat/completions -H \"Content-Type: application/json\" -d \"{\\\"model\\\":\\\"gemma4:e2b\\\",\\\"messages\\\":[{\\\"role\\\":\\\"user\\\",\\\"content\\\":\\\"Name one Debian release codename.\\\"}],\\\"reasoning_effort\\\":\\\"none\\\"}\"'\n# \"content\":\"One Debian release codename is **Bookworm**.\"\n```\n\n**That second endpoint is the whole argument.** Anything in the VM that speaks the OpenAI API — your app, your agent, your test harness — takes `http://192.168.64.1:8000/v1` as its base URL and gets a model on the Mac GPU. The app is customized and run in Debian. The inference never touches the VM's 2 GB.\n\n`bin/test-vm-ollama` runs the whole path from inside a machine, then asks the Mac's `/api/ps` where the model actually loaded. It needs `curl` in the machine and `jq` on the Mac:\n\n```\nbin/test-vm-ollama                          # debian13-vm, gemma4:e2b + gemma4:e2b-it-qat\nbin/test-vm-ollama -n dev-vm -m gemma4:e2b --no-qat\n== 1. network path\n  PASS  VM reaches http://192.168.64.1:8000 (connect 0.002372 s, Ollama 0.33.3)\n== 2. models\n  gemma4:e2b-it-qat gemma4:e2b gemma4:e4b\n  PASS  gemma4:e2b is listed\n== 3. native API\n  reply: Debian is a free and open-source operating system that forms the basis for many other Linux distributions.\n  22 tokens @ 45.2 tok/s, load 5.4 s\n  PASS  gemma4:e2b answered through /api/generate\n== 4. streaming\n  14 chunks: 1, 2, 3, 4, 5\n  PASS  streaming delivers incremental chunks\n== 5. OpenAI-compatible API\n  PASS  /v1/chat/completions returned text\n== 6. GPU (asked from the Mac)\n  PASS  gemma4:e2b loaded 100% on the GPU (1.6 GB)\n== 7. second model: gemma4:e2b-it-qat\n  35 tokens @ 38.9 tok/s, load 12.4 s\n  PASS  gemma4:e2b-it-qat answered through /api/generate\n  PASS  gemma4:e2b-it-qat loaded 100% on the GPU (3.3 GB)\n\n8 passed, 0 failed\n```\n\n**The VM hop costs almost nothing.** Connect time was 2 ms. `gemma4:e2b` generated at 45.2 tok/s through the VM against 43.6 tok/s from the Mac itself — single runs each, so that is run-to-run variation, not the VM being faster. Generation here is limited by the M3's memory, not by the network between Debian and macOS.\n\nThe GPU check reads `size_vram / size` from `/api/ps`, the same numbers `ollama ps` prints as `100% GPU`. A wrong URL fails at step 1 and exits 1; a missing machine or missing `curl` exits 2.\n\nGemma 4 is a reasoning model. With a small token limit, the whole budget goes to hidden reasoning and the answer comes back **empty** — with an HTTP 200 and valid JSON:\n\n| Request | Result | \n|---|---|\n| native, `num_predict: 40` | ❌ `\"response\":\"\"` ,`done_reason: length` | \n| OpenAI, `max_tokens: 20` | ❌ `\"content\":\"\"` ,`finish_reason: length` ;`message.reasoning` starts`Thinking Process:` | \n| native, `\"think\": false` | ✅ `Hello from Debian VM.` in 6 tokens | \n| OpenAI, `\"reasoning_effort\": \"none\"` | ✅ an answer in 11 tokens | \n| OpenAI, no limit | ⚠️ `Bookworm` , but 159 tokens, mostly reasoning | \n\n**Check `finish_reason` in your app, not just the status code.** Turn thinking off for quick answers, or leave room for the reasoning.\n\n|  | Model | Quantization | Loaded | Speed | \n|---|---|---|---|---|\n| 🥇 | `gemma4:e2b` | Q4_K_M | 1.7 GB | ~44 tok/s | \n| 🥈 | `gemma4:e2b-it-qat` | Q4_0, QAT (Google) | 3.6 GB | ~38–44 tok/s | \n| — | `gemma4:e4b` | Q4_K_M | not run | 9.6 GB on disk, more than this Mac's RAM | \n\n`gemma4:e2b` is the comfortable choice. The QAT build is better quality at 4 bits, but free memory dropped to 6% with a machine running. When you are done, unload it rather than leaving 3.6 GB pinned:\n\n```\ncurl -s http://127.0.0.1:8000/api/generate -d '{\"model\":\"gemma4:e2b-it-qat\",\"keep_alive\":0}'\n```\n\n`mkdebian-machine publish`, and hand the image to someone else.` http://192.168.64.1:8000/v1` is an OpenAI-compatible endpoint. Point the same app at a different Ollama or llama.cpp server with `--url` and nothing in the VM changes.\nThe VM does the work that needs Linux. The Mac does the work that needs the GPU, and neither side pretends to be the other.\n\n| Symptom | Cause | Fix | \n|---|---|---|\n| Machine stays `stopped` ; logs show`exec: /sbin/init: not found` | Plain `debian:13` , no init | Step 2 | \n| `Operation not supported on socket` /`by device` | Machine still booting, or an interactive shell with no TTY | Step 4 poll; pass a command | \n| `systemctl is-system-running` →`degraded` | `systemd-modules-load.service` failed | Mask it (Step 2) | \n| Two machines share `/etc/machine-id` | Image carries `/var/lib/dbus/machine-id` | Last `RUN` line of Step 2 | \n| A quoted command prints nothing | Arguments joined and re-parsed by bash | One quoted argument | \n| `Plugin 'container-images' not found` | Typed `container images ls` | `container image ls` | \n| VM gets no HTTP 200 from `192.168.64.1:8000` | Ollama back on localhost, often after `brew services restart` | Step 7, then `bin/test-mac-ollama` | \n| Reply is empty, `finish_reason: length` | Gemma 4 spent the budget thinking | `think: false` /`reasoning_effort: \"none\"` | \n\n```\n# 0. install, start, kernel\ncontainer system start\ncontainer system kernel set --recommended\n\n# 1. the official image cannot boot as a machine\ncontainer run --rm debian:13 sh -c 'ls -l /sbin/init'\n\n# 2. build a Debian image with an init (Dockerfile above)\ncontainer builder start\ncontainer build -t debian13-machine .\ncontainer builder stop\n\n# 3. check it\ncontainer run --rm debian13-machine sh -c 'ls -l /sbin/init; wc -c < /etc/machine-id'\n\n# 4. create, then wait for it\ncontainer machine create debian13-machine --name dev-vm --cpus 2 --memory 2G\nuntil container machine run -n dev-vm --root -- true 2>/dev/null; do sleep 2; done\n\n# 5. check it\ncontainer machine run -n dev-vm -- 'systemctl is-system-running; id; sudo -n id -u'\n\n# 6. customize it\ncontainer machine run -n dev-vm --root -- 'apt-get update && apt-get install -y git'\n\n# 2-5, the short way\nbin/mkdebian-machine new -t debian13-machine -m dev-vm -p sudo\n\n# 7. Ollama on all interfaces, restarted with launchctl\n/usr/libexec/PlistBuddy -c 'Set :EnvironmentVariables:OLLAMA_HOST 0.0.0.0:8000' ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist\nlaunchctl bootout gui/$(id -u)/homebrew.mxcl.ollama\nlaunchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/homebrew.mxcl.ollama.plist\n\n# 8. the Mac on its own\nbin/test-mac-ollama\n\n# 9. the model from the VM\ncontainer machine run -n dev-vm -- 'curl -s http://192.168.64.1:8000/v1/models'\n\n# 10. the whole round trip\nbin/test-vm-ollama -n dev-vm\n\n# clean up\ncontainer machine stop dev-vm\ncontainer machine delete dev-vm\ncontainer image rm debian13-machine\n```\n\nThe goal of this article was to get a persistent Debian 13 machine running under Apple's `container` CLI, and then let apps inside it use a local LLM on the Mac's GPU. The key to the solution was splitting the two: build an image the machine can actually boot, and leave the model on macOS where Metal is, reached over the VM network at `192.168.64.1`. The results were:\n\n`bin/test-mac-ollama` reported `10 passed, 0 failed` and `bin/test-vm-ollama` reported `8 passed, 0 failed`\n`brew services restart ollama` silently reverts Ollama to localhost, and the VM loses the model\nScope: one Apple M3 Mac with 8 GB on macOS 27.0 (26A428), `container` 1.4.1, a Debian 13 machine with 2 CPUs and 2 GB, Ollama 0.33.3 with `OLLAMA_KV_CACHE_TYPE=q4_0` and flash attention on. Each throughput figure is a single run from the test scripts on 2026-09-13, and the model replies vary from run to run.\n\nThe strategy for running a customized Debian machine on Apple container with a local LLM on the Mac GPU was validated with an incremental step by step approach.", "url": "https://wpnews.pro/news/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4", "canonical_source": "https://dev.to/gde/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-gemma-4-2d8b", "published_at": "2026-09-14 00:57:31+00:00", "updated_at": "2026-09-14 01:25:37.360586+00:00", "lang": "en", "topics": ["large-language-models", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Apple", "Debian", "Ollama", "Gemma 4", "Apple container", "Metal", "Kata Containers", "Docker Hub"], "alternates": {"html": "https://wpnews.pro/news/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4", "markdown": "https://wpnews.pro/news/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4.md", "text": "https://wpnews.pro/news/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4.txt", "jsonld": "https://wpnews.pro/news/build-in-the-vm-think-on-the-mac-gpu-debian-13-on-apple-container-with-a-local-4.jsonld"}}