How to Profile Local AI on Mac with Instruments

Direct answer: profile the real application workflow, mark its user-visible stages, and capture a trace that includes model activity beside CPU, memory, graphics, audio, and file work. Start before model load and stop after the final artifact is usable. Separate download, validation, specialization, cold load, prefill, generation, decoding, and export. Repeat a warm run in the same process. The Core AI Instruments template can reveal startup delays, repeated uncached loads, processor use, and runtime events, but it cannot decide whether output is correct. Pair every trace with a fixed input, model revision, task-quality result, and wall-clock measurement.

Trace plan

Create signposts around product stages

Name intervals in terms a product team understands: open project, prepare model, submit text, first audio, final audio, save file, cancel. Keep model-internal markers as a second layer. Without these boundaries, a detailed trace can optimize a 20 millisecond operation while missing a two-second asset check. Use one fixed input and record the action sequence. Capture the first run after launch and a warm repeat without changing settings.

Find repeated and serialized work

Look for model assets loaded more than once, specialization during a frequent path, tokenizer or audio setup recreated per segment, large buffers copied between stages, and work serialized behind the main actor. Confirm each hypothesis with a controlled change and a second trace. A colored band in Instruments is evidence of activity, not proof of causation. Keep the before and after capture plus the code or configuration change that explains it.

Profile failure and cancellation paths

Start a long task, cancel it, and observe how quickly execution stops and memory returns. Repeat with a malformed model, missing file, full destination volume, and memory pressure. A fast success trace says little about a production queue that cannot release a decoder. The local AI threat model also recommends checking what diagnostic data contains before traces or logs are shared.

Turn traces into regression budgets

Save a small set of named scenarios and acceptable limits for cold ready time, first useful output, p95 completion, peak memory, and cancellation. Re-run them when the runtime, model, quantization, or minimum OS changes. Pair the trace with the benchmark disclosure. The goal is a reproducible explanation and a user-visible budget, not one perfect screenshot from a developer machine.

Production acceptance record

Before acting on this profile local AI Mac Instruments recommendation, create an acceptance record for the exact feature and release. Name the owner, reviewer, user task, minimum Mac, operating system, application version, runtime, model revision, precision, input fixture, expected artifact, and pass threshold. Attach cold and warm annotated traces, product-stage signposts, one confirmed bottleneck experiment. Keep upstream documentation in one section and measurements from your own machine in another. Record every unsupported path, timeout, crash, incorrect output, and manual repair. A result counts as a pass only when the artifact is usable for the stated job. Fast but incomplete output, an unrecoverable cancellation, or a file that cannot be reopened remains a failure.

Run the record once on a clean launch, once after warmup, once with realistic companion applications open, and once after deliberately interrupting the workflow. Exercise the operating steps that matter most here: Profile the complete user workflow. Mark stages with stable names. Capture cold and warm runs. Save raw timings and checks instead of copying only a winning screenshot. Include rejected options and the reason each lost, so a later framework or model update can reopen the decision without starting from memory. Assign an update trigger such as a new runtime release, model revision, minimum operating system, material support issue, or change in licensing. Review the record before changing defaults, removing a fallback, or publishing a broad performance claim.

Evidence to collect before publication

Capture and annotate three traces from the same Mac: cold success, warm success, and cancellation under memory pressure. Export a sanitized trace or screenshots with stage labels, then provide the fixed input, model revision, run conditions, and quality result. Demonstrate one verified bottleneck change with before and after numbers.

• Cold and warm annotated traces
• Product-stage signposts
• One confirmed bottleneck experiment
• Cancellation and memory release
• Sanitized trace-sharing checklist

Reader worksheet

For each scenario, write the user action, expected artifact, start marker, end marker, intermediate stages, model and runtime revision, cold or warm state, foreground applications, and success threshold. Add one hypothesis before opening the trace. Record whether the data supported it. Use the compute-path guide when processor placement appears relevant.

Practical checklist

1. Profile the complete user workflow.
2. Mark stages with stable names.
3. Capture cold and warm runs.
4. Test cancellation and failures.
5. Confirm hypotheses with a second trace.
6. Convert results into regression budgets.

Frequently asked questions