← Back to blog

Efficient Local AI Models for an M2 Max with 64 GB RAM: What Fits and What to Choose

This is a dated snapshot. Model releases, quantized downloads, runtime support, and benchmark rankings change quickly. The recommendations below reflect the research available on October 8, 2026.

I tested Bonsai, KAT, and Qwen on my own MacBook Pro with an M2 Max and 64 GB of unified memory. The benchmark figures cited in this article come from published third-party results and are separate from my own testing.

1. The practical recommendation

For an M2 Max with 64 GB of unified memory, Qwen3.6-35B-A3B in MLX 6-bit, at approximately 29.1 GB, is the starting recommendation. It offers a useful balance of model capability, modest active parameter count, and memory headroom. Its official model card and available Apple Silicon packages make it a practical baseline for comparing alternatives.12

The choice changes with the intended workload:

  • General assistance, reasoning, and mixed tasks: start with Qwen3.6-35B-A3B.
  • A coding-focused model derived from Qwen3.6: try KAT-Coder-V2.5-Dev.
  • A larger model for coding agents: consider Qwen3-Coder-Next, provided the reduced memory headroom is acceptable.
  • A smaller multimodal alternative: consider Gemma 4 26B-A4B IT.
  • Compact text and agent workloads: compare Nemotron 3.5 Lightning 30B-A3B.
  • An experimental candidate with a promising independent benchmark result: investigate K2-Horizon-MoVA-36B-A4B, while accounting for its runtime limitations.
  • Very small downloads through aggressive compression: examine Bonsai 2 27B, while recognizing that it is a dense model with special loading requirements.

My recommendations focus on an M2 Max with 64 GB of unified memory. The best fit for your workload depends on answer quality, prompt processing, generation speed, context length, and how much memory you need for other applications.

2. Shortlist and approximate download sizes

The sizes below refer to the specific quantized packages listed, not the original full-precision models. A different publisher, quantization method, or inclusion of vision components can change the download size substantially.

Model Main reason to consider it Example local package Approximate download Assessment for 64 GB
Qwen3.6-35B-A3B Versatile baseline with multimodal capabilities MLX 6-bit 29.1 GB Good starting balance of quality and headroom
KAT-Coder-V2.5-Dev Coding specialization based on Qwen3.6 GGUF Q5_K_M / Q6_K 25.02 / 30.05 GB Attractive coding option within a comfortable weight budget
Qwen3-Coder-Next Larger model for coding and agent workflows MLX 4-bit 44.9 GB Feasible, but requires more care with context and other apps
Gemma 4 26B-A4B IT Compact text-and-image alternative MLX 4-bit 15.4 GB Leaves substantial memory headroom
Nemotron 3.5 Lightning 30B-A3B Efficient text and agent workloads MLX 4-bit 17.8 GB Compact alternative worth testing
K2-Horizon-MoVA-36B-A4B Promising quality with a different MoE architecture MLX package labeled 4-bit, using mixed precision 26.4 GB Weights fit well; runtime and long-context caveats matter
Occamy 1.0 Another Qwen3.6-based agent specialization MLX 6-bit 28.17 GB Interesting, but Mac acceptance was still pending
Ternary Bonsai 2 27B Aggressive compression of a dense model GGUF PTQ1_0 / PQ2_0; MLX 2-bit 5.95 / 7.21 GB; 8.60 GB Very small download, but requires the correct specialized loader

Package sources: Qwen,2 KAT,3 Coder-Next,4 Gemma,5 Nemotron,6 K2,7 Occamy,8 and Bonsai.910

For Bonsai, the two GGUF figures cover the language model; its optional Q8 vision component adds approximately 0.63 GB. The 8.60 GB MLX package already includes vision components. These figures therefore do not describe identical bundles.910

3. What MoE means for an M2 Max with 64 GB

Total parameters and active parameters are different

The relevant Qwen model name is Qwen3.6-35B-A3B. In this naming convention, 35B describes the approximate total parameter count, while A3B indicates approximately three billion active parameters per token.1

An MoE model routes each token through a subset of its experts. This reduces the computation needed for each token compared with activating every parameter in a similarly sized dense model.

However, a model with three billion active parameters does not have the memory footprint of a three-billion-parameter dense model. For straightforward local GPU inference, the stored experts and the model’s other weights still need to be available in memory. Offloading introduces a different performance tradeoff.

Two separate questions therefore matter:

  1. How much memory does the complete quantized model occupy?
  2. How efficiently can the runtime process the active computation?

Active parameter count is useful context, but it does not by itself predict tokens per second. Memory access, attention, context length, implementation quality, and prompt processing also affect performance.

Quantization reduces storage, with tradeoffs

Quantization stores weights at lower precision. Four-bit and six-bit packages are usually much smaller than full-precision weights, but the exact method matters. Some tensors may remain at higher precision, and scales, metadata, embeddings, and other components add overhead.

For example, the ideal arithmetic for 35 billion parameters stored at exactly four bits each is:

35,000,000,000 × 4 ÷ 8 = 17,500,000,000 bytes
                            ≈ 17.5 GB

That is a simplified lower-level calculation, not the actual Qwen download size. The referenced MLX 4-bit package is approximately 20.4 GB.11

4. Model-by-model assessment

Qwen3.6-35B-A3B: the default starting point

Qwen3.6-35B-A3B is my baseline recommendation for general local use. Its combination of MoE inference, multimodal capabilities, and available local packages makes it a useful first model for this hardware configuration.112

Three practical MLX options are available:

Quantization Approximate download When to choose it
4-bit 20.4 GB More headroom for long prompts and other applications
6-bit 29.1 GB The recommended starting balance on a 64 GB Mac
8-bit 37.7 GB A less aggressive quantization when extra memory use is acceptable

The figures come from the corresponding package listings.11213

I recommend starting with six-bit, but it will not necessarily give a measurable advantage over four-bit. Compare whether the larger package produces better results on your actual tasks and whether those improvements justify its memory and bandwidth cost.

KAT-Coder-V2.5-Dev: a Qwen3.6 coding specialization

KAT-Coder-V2.5-Dev applies supervised fine-tuning and reinforcement learning to Qwen3.6-35B-A3B. The released weights are text-only and omit the vision tower, despite inherited multimodal metadata.14

The publisher reports these results under its own evaluation setup:

Benchmark KAT-Coder-V2.5-Dev Qwen3.6-35B-A3B
SWE-bench Verified 69.4 64.4
SWE-bench Pro 45.96 40.63

Each evaluation used one run per model. The publisher notes an approximately ten-percentage-point gap between its Qwen baseline and Qwen’s official SWE-bench results, attributed mainly to evaluation differences. These are not tests of the local quantized packages.14

For an M2 Max with 64 GB, the 25.02 GB Q5_K_M and 30.05 GB Q6_K GGUF packages are practical candidates. Start with Q5_K_M if memory headroom matters; compare Q6_K when coding quality is the priority.3

Qwen3-Coder-Next: a larger coding option

Qwen3-Coder-Next has 80 billion total parameters and approximately three billion active parameters. It targets coding agents, including workflows involving tools, execution feedback, and recovery from unsuccessful attempts. It operates only in non-thinking mode.15

The referenced MLX 4-bit download is approximately 44.9 GB. This makes it plausible on a 64 GB M2 Max, but it occupies a much larger share of available memory than the other main recommendations.4

Its advertised context window is 262,144 tokens. Using the full window alongside other applications may not be practical on an M2 Max with 64 GB.15

This is the model to test when the workload is strongly coding-oriented and its results justify giving up some memory flexibility.

Gemma 4 26B-A4B IT: a smaller multimodal alternative

Gemma 4 26B-A4B is an MoE model. Its official specification lists approximately 25.2 billion total parameters and 3.8 billion active parameters; the model name rounds those figures.

The IT variant is instruction-tuned for assistant use. It supports text and image input and function calling. Audio capabilities elsewhere in the Gemma family should not be assumed to apply to this particular variant.16

At approximately 15.4 GB for the referenced MLX 4-bit package, it leaves considerable headroom for other applications and context. It is a sensible comparison model when a smaller package is preferable to Qwen’s larger six-bit download.5

Nemotron 3.5 Lightning 30B-A3B: efficient text and agent work

NVIDIA’s Nemotron 3.5 Lightning combines Mamba-2, attention, and MoE components. The model discussed here is text-only.17

An NVIDIA-branded model does not inherently require an NVIDIA GPU for local inference. Apple Silicon packages are available: the referenced MLX 4-bit download is approximately 17.8 GB, and an alternative GGUF Q4_0 package is approximately 18.9 GB.618

It deserves a place in a practical comparison for text and agent workloads. Its compact package is appealing, but the architectural differences make real task testing more informative than comparing active parameter counts alone.

K2-Horizon-MoVA-36B-A4B: promising, with integration caveats

K2-Horizon-MoVA-36B-A4B is a 36B-total, approximately 4B-active model with a MoVA architecture and an advertised 512K context window.19

At the research snapshot, Artificial Analysis reported an Intelligence Index score of 25 for K2, compared with 18 for Qwen3.6-35B-A3B under the then-current index. This supports considering it as a quality candidate; it does not establish the same ranking for local quantized inference or a particular coding workflow.2021

The referenced MLX package is approximately 26.4 GB. Although labeled 4-bit, it uses mixed precision. Its model card documents several constraints:

  • The architecture required bundled model code rather than native upstream support.
  • The documented MLX-LM server integration did not parse K2’s tool-call format.
  • Thinking tags could remain in ordinary response content.
  • The stated KV-cache estimate was approximately 192 KB per token, or roughly 24 GB at 128K context, before other runtime memory.

Those limits make K2 an experimental choice for this hardware configuration, particularly when reliable tool use or long context is required. Its weight size alone does not establish practical memory use.7

Occamy 1.0: another Qwen3.6-based specialization

Occamy 1.0 is another derivative of Qwen3.6-35B-A3B, with additional post-training for agent workflows involving files, application state, and APIs.

The publisher lists approximately 28.17 GB for its MLX 6-bit package and 19.51 GB for MLX 4-bit. However, its documentation explicitly stated that Mac Metal acceptance was pending at the snapshot.

This puts Occamy on the watchlist rather than ahead of the more established starting options. The existence of an MLX download should not be confused with completed validation of the full workflow on a Mac.8

5. Bonsai: a 7.2 GB file is not a 7.2B-parameter model

Bonsai is interesting for local inference, but it belongs in a separate category.

A download listing around 7.2 GB can refer to a compressed 27B-class model. It does not mean the model has 7.2 billion parameters, nor does that file size identify an MoE architecture.

The earlier Bonsai 27B release was based on Qwen3.6-27B.22 The current Ternary Bonsai 2 27B model in this snapshot is a dense derivative of Qwen3.8-27B. Neither should be confused with the Qwen3.6-35B-A3B MoE model. Bonsai 2’s ternary representation uses the three weight values −1, 0, and +1, together with scales and specialized transforms.9

Available packages

Package Approximate download Included components
GGUF PTQ1_0 5.95 GB Language model
GGUF PQ2_0 7.21 GB Language model
Optional GGUF Q8 vision component 0.63 GB extra Vision component
MLX 2-bit 8.60 GB total Language and vision components

These sizes are package-specific and should be compared with their included components in mind.910

The loader matters

The cited GGUF packages require Prism’s llama.cpp fork. The cited MLX package requires its bundled rotation-aware loader. A generic loader is not automatically compatible; the wrong path can reject the file or produce incorrect output.910

Use the package’s documented setup and the publisher’s Bonsai demo repository, rather than treating an automatically generated application snippet as proof of support.

My own testing included Bonsai, although I have not included speed measurements from those tests here. Results from a different Mac or an earlier Bonsai build may not apply to the version and configuration you use.

Recommendation: investigate Bonsai when reducing download and weight memory is a priority and additional setup is acceptable. Treat its quality and speed as things to measure, rather than assuming the smallest download is the most efficient overall choice.

6. What 64 GB of unified memory actually permits

The M2 Max uses unified memory shared across the CPU, GPU, operating system, and applications. The advertised 64 GB is therefore the machine’s shared memory pool, rather than a separate 64 GB GPU allocation on top of system RAM.23

For planning purposes:

  • About 20–35 GB of model downloads is a comfortable starting range when a browser, editor, and other applications must remain open.
  • Around 45 GB can be workable for a single larger model, but requires more attention to context, runtime allocation, and other applications.
  • A package that fits on disk, or whose weight size is below 64 GB, is not automatically comfortable during inference.

These ranges are practical recommendations, not fixed hardware limits.

Download size is not total inference memory

Actual memory use can include:

  • Model weights and any additional vision components.
  • The KV cache, which stores attention information for the current context, plus architecture-specific recurrent state.
  • Temporary buffers used while processing prompts.
  • Runtime and framework allocations.
  • macOS and other running applications.

The relationship between context length and memory depends on the architecture and runtime. A cache estimate for one model should not be reused for another.

The download figures in this article follow repository listings, generally in decimal GB. Tools may report memory in GiB, or label values differently. Benchmark memory measurements below are reproduced as reported; they are not a second estimate of download size.

Begin with a moderate context window

Start with 16K or 32K context, then increase it if the task benefits and memory remains comfortable. This is a starting configuration, not a claimed maximum.

Very long advertised windows are model capabilities. Their practical use depends on the available memory, the runtime, cache handling, and the time needed to ingest the prompt.

Loading an entire repository can make prompt processing the dominant delay. For reasoning models, generating many thinking tokens can also extend the wait before the final answer. Tokens per second alone do not capture either experience.

7. What published M2 Max measurements suggest

The following results are historical examples from the oMLX benchmark site. They were recorded on M2 Max systems with 64 GB RAM and 30 GPU cores, using specific model packages and software versions.

These figures come from published benchmarks, separate from my own tests of Bonsai, KAT, and Qwen. They do not establish a current, controlled comparison between the recommended downloads.

Qwen3.6-35B-A3B, MLX 5-bit

A May 12, 2026 result using oMLX 0.3.9.dev1 reported:

Prompt size Generation speed Reported peak memory
4K 72.5 tokens/s 24.6 GB
16K 62.0 tokens/s 25.8 GB
32K 50.4 tokens/s 27.3 GB

This is evidence that the model can perform usefully on this hardware class. These measurements used a 5-bit package; speeds may differ with the 6-bit package I recommend above.24

Qwen3-Coder-Next, MLX 4-bit

A May 9, 2026 result using oMLX 0.3.8 and a 4K prompt reported:

Metric Reported result
Generation speed 56.1 tokens/s
Prompt processing speed 461.2 tokens/s
Time to first token 8.88 seconds
Peak memory 44.0 GB

This supports the feasibility of the larger model on a 64 GB M2 Max at that tested configuration. It does not demonstrate comfortable operation at the model’s maximum context.25

Actual results will vary with the M2 Max GPU configuration, runtime version, quantization, prompt, context length, thermal conditions, and concurrent applications.

8. Runtime choice on Apple Silicon

MLX

MLX packages are a natural starting point for Apple Silicon. The MLX-LM project provides local inference tooling, while compatible applications can offer a graphical interface or local API.2627

For the ordinary packages in this shortlist, MLX is worth testing first. Check the exact model card for architecture support and loading instructions, particularly for K2 and Bonsai.

GGUF with a Metal-capable runtime

GGUF is the other practical route, commonly through llama.cpp-based software with Metal acceleration. It is especially relevant for the concrete KAT downloads listed above.327

A file ending in .gguf is not a guarantee that every runtime can load it. The model architecture and quantization format must both be supported. Bonsai’s custom formats are a clear example.9

LM Studio and macOS requirements

LM Studio is a convenient starting application because it supports local MLX and GGUF workflows and can expose a local API.27

At the snapshot:

  • LM Studio required macOS 14 or later on Apple Silicon.28
  • MLX-LM documented a macOS 15 or later requirement for its memory-wiring optimization.26

The M2 Max processor alone does not establish that the installed macOS version meets a particular application’s requirements.

9. A sensible order for trying the models

For a general-purpose setup:

  1. Start with Qwen3.6-35B-A3B MLX 6-bit. Use it as the baseline for quality, responsiveness, and memory use.
  2. Compare a smaller alternative. Gemma 4 is relevant when image input matters; Nemotron is relevant for text and agent tasks.
  3. If coding dominates, test KAT-Coder-V2.5-Dev. Compare it on the same repository tasks and tool workflow.
  4. Try Qwen3-Coder-Next if a larger coding model is justified. Begin with moderate context and one loaded model.
  5. Treat K2, Occamy, and Bonsai as additional experiments. Their respective integration, validation, or loading caveats are part of the decision.

Use a small set of representative tasks: a real coding change, a long document, a reasoning problem, image input if relevant, and the languages used in everyday work. Record answer quality, time to first token, total completion time, and memory pressure.

The starting choice for this hardware remains Qwen3.6-35B-A3B at roughly 29.1 GB in MLX 6-bit. KAT is the most directly relevant Qwen3.6 coding specialization in this shortlist; Coder-Next is the larger coding option. Bonsai is worth examining for compression, but it should be evaluated as a dense model with a specialized runtime path.


Sources and snapshot limitations

Model publishers’ cards establish architecture, intended use, and release details. Quantization repositories establish the approximate package sizes and loading requirements. Publisher benchmarks, independent benchmark services, and community runtime measurements answer different questions and should not be treated as interchangeable evidence.

This article draws on research completed on October 8, 2026. Package revisions and runtime updates after the research date may change the practical recommendations.

  1. Qwen, Qwen3.6-35B-A3B model card. ↩ ↩2 ↩3

  2. MLX Community, Qwen3.6-35B-A3B 6-bit package files. ↩ ↩2 ↩3

  3. Bartowski, KAT-Coder-V2.5-Dev GGUF packages and size table. ↩ ↩2 ↩3

  4. MLX Community, Qwen3-Coder-Next 4-bit package files. ↩ ↩2

  5. MLX Community, Gemma 4 26B-A4B IT 4-bit package files. ↩ ↩2

  6. MLX Community, Nemotron 3.5 Lightning 4-bit package. ↩ ↩2

  7. MLX Community, K2-Horizon mixed-precision package, cache estimate, and integration limitations. ↩ ↩2

  8. Accio Lab, Occamy 1.0 model card, packages, and validation status. ↩ ↩2

  9. Prism ML, Ternary Bonsai 2 27B GGUF model card, formats, and required runtime. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  10. Prism ML, Ternary Bonsai 2 27B MLX 2-bit package and loader requirements. ↩ ↩2 ↩3 ↩4

  11. MLX Community, Qwen3.6-35B-A3B 4-bit package files. ↩ ↩2

  12. LM Studio, Qwen3.6 model page. ↩

  13. MLX Community, Qwen3.6-35B-A3B 8-bit package files. ↩

  14. Kwaipilot, KAT-Coder-V2.5-Dev model card and publisher evaluations. ↩ ↩2

  15. Qwen, Qwen3-Coder-Next model card. ↩ ↩2

  16. Google, Gemma 4 26B-A4B IT model card. ↩

  17. NVIDIA, Nemotron 3.5 Lightning 30B-A3B model card. ↩

  18. GGML, Nemotron 3.5 Lightning GGUF packages. ↩

  19. IFM, K2-Horizon-MoVA-36B-A4B model card. ↩

  20. Artificial Analysis, K2-Horizon-MoVA-36B-A4B evaluation. Score cited from the research snapshot, not a permanent ranking. ↩

  21. Artificial Analysis, Qwen3.6-35B-A3B comparison page. Qwen score cited from the same research snapshot. ↩

  22. Prism ML, Original Bonsai 27B announcement and Qwen3.6-27B lineage, July 14, 2026. ↩

  23. Apple, M2 Pro and M2 Max architecture and unified memory announcement. ↩

  24. oMLX, Qwen3.6-35B-A3B 5-bit benchmark on M2 Max with 64 GB, May 12, 2026. ↩

  25. oMLX, Qwen3-Coder-Next 4-bit benchmark on M2 Max with 64 GB, May 9, 2026. ↩

  26. ML Explore, MLX-LM documentation. ↩ ↩2

  27. LM Studio, MLX support and local inference workflows. ↩ ↩2 ↩3

  28. LM Studio, System requirements. ↩