Run Llama 3.3 70B locally on a MacBook.

What you actually need

Hardware: 64 GB or more.

Llama 3.3 70B at Q4_K_M needs ~42 GB of unified memory just for the weights. Your Mac also needs enough headroom for context (~4–8 GB) and the rest of your stack (browser, terminal, Docker if you use it). Realistic minimum: a 64 GB Mac with a deliberately lean foreground.

The honest numbers

Tokens per second on Apple Silicon.

A viral post claimed 71 tok/s for Llama 3.3 70B on an M4 MacBook Pro. That figure is fiction. The realistic ceiling on M-series unified memory for a 70B at Q4_K_M is closer to 8–20 tok/s, bottlenecked by memory bandwidth, not FLOPS.

Why bandwidth matters: generating each token requires streaming the active weights through memory once. A 42 GB Q4_K_M model on 546 GB/s bandwidth gives a theoretical ceiling of about 13 tok/s before any other overhead. Quoting numbers above the bandwidth-derived ceiling without speculative decoding is a tell that something else is being measured (or fabricated).

The setup · 15 minutes

Step by step.

1. Install Ollama from ollama.com. It registers itself as a local service on port 11434.
2. Install DevPulse from devpulse.sh. The menu bar app shows you what's eating unified memory; the bundled devpulse CLI runs the pre-flight check.
3. Pre-flightbefore pulling the model so you know it'll fit:

$ devpulse ai --before-load 42000 --auto-clean
before: Won't fit — 8.2 GB short
  - unloaded idle ollama model: qwen2.5:7b (4.2 GB)
  - killed 6 zombie procs (812 MB reclaimed)
after:  Fits comfortably — 4.4 GB headroom
$ echo $?
0   # safe to load

4. Pull and run the model. First pull is ~42 GB — grab coffee.

$ ollama pull llama3.3:70b
$ ollama run llama3.3:70b

5. For long batches: babysit.Hours-long agent loops need a watchdog so they don't lose progress when memory tightens:

$ devpulse babysit --target-free-mb 8192 --json > babysit.log &
$ ollama run llama3.3:70b < my-task-queue.txt

The agent-loop pattern

Process a queue, checkpoint on pressure events.

The reason the “11-hour-flight” pattern works isn't the model. It's the loop: process a task, save output to disk, advance, save state every N tasks. devpulse babysit's NDJSON event stream feeds directly into that pattern.

# pseudocode — drop into your shell or python loop
while task = pop_next(queue):
    output = ollama_chat("llama3.3:70b", task.prompt)
    write_output(task.id, output)
    if task.id % 12 == 0:
        save_checkpoint(queue.position)

# meanwhile, in another pane:
$ tail -f babysit.log | jq 'select(.event == "cleanup")' \
  | while read evt; do
      save_checkpoint  # extra checkpoint on memory pressure
    done

Want a fully agentic loop instead of a queue? Pair this setup with Aider, Codex, or Hermes Agent — all of which run against the same local 70B and fit the same babysit pattern.

When it goes wrong

Common failures.