On 25 August Apple announced a computer that makes very little sense as a computer. The Mac Studio with the M5 Ultra starts at USD 5,499. The version I am actually writing about will carry 512 GB of unified memory, arrives in late October and has no price yet. According to AppleInsider, in the United States it will pass USD 10,000 before you put a display on the desk.
I am writing about it because I have two reference points within reach. In my bag there is a MacBook Pro with 128 GB of unified memory. A month ago a Lenovo ThinkStation PGX passed through our lab - the corporate sibling of the NVIDIA DGX Spark, with 128 GB and the GB10 superchip - and I gave it a proper workout before it shipped to a client. So when I read about 512 GB in a single machine, I do not read it as a hardware review. I read it as a calculation: should SNOK buy this machine for proofs of concept and model fine-tuning? And why does a price that looks absurd from a distance start to make sense up close?
One caveat first, because without it this text would be dishonest. SNOK is a Lenovo Platinum partner and sells PGX workstations. I have a commercial interest in recommending the GB10 to you. That is exactly why I think I should write down where the Mac Studio wins.
What to compare it with
The first trap in any discussion of this hardware is the wrong comparison. Line the Mac Studio up against a gaming PC or an RTX workstation and it always ends the same way: in CPU and rendering tests the Mac looks expensive, and in anything that depends on CUDA it loses. Both conclusions are true and both are irrelevant to the person who will actually buy the machine.
I owe the angle that convinced me to Cordero Core of the University of Washington’s eScience Institute, who published his take on Medium a few days after the announcement. His observation is simple: Apple is not trying to persuade anyone who is building a gaming PC. Apple is going after the person who was about to buy several DGX Sparks.
That person knows the numbers by heart. One DGX Spark costs USD 4,699 at NVIDIA’s list price, in force since February 2026. It provides 128 GB of coherent unified memory, 273 GB/s of bandwidth, a GB10 Grace Blackwell superchip and NVIDIA’s entire software stack on a small Ubuntu machine. According to the vendor, a single unit runs inference on models up to 200 billion parameters and fine-tunes models up to 70 billion. Two units joined over the built-in ConnectX-7 at 200 Gb/s handle models up to 405 billion parameters; four units go up to 700 billion.
That is where the arithmetic of this comparison begins. Memory grows one box at a time, 128 GB per box: two Sparks give you 256 GB for USD 9,398, and four Sparks give you 512 GB for USD 18,796 - that is how much NVIDIA hardware it takes to match the capacity of a single Mac Studio in the configuration I am writing about. Those are the two numbers Apple wants to compete with.
What I have in my hands, and what I do not
Before the arithmetic, a division between what I know first-hand and what I do not.
On the 128 GB PGX we built a complete working environment in the lab, not benchmarks for their own sake. The gpt-oss-120b model in MXFP4 quantisation takes about 63 GB and generates 56-60 tokens per second in llama.cpp. A dense 70-billion-parameter model at 4-bit takes about 40 GB, fits in memory without trouble and generates about 3 tokens per second, which is useless in a single conversation. Qwen3-235B-A22B in a 3-bit quantisation takes 104 GB, squeezes in, delivers about 15 tokens per second and leaves room for nothing else. Those three numbers are enough to understand the rest of this text.
On the 128 GB MacBook the same gpt-oss-120b fits by size, because 63 GB is 63 GB. I have not measured its speed with a method comparable to the lab, so I will not quote a number. What I do know is that on the same laptop I can have the model open alongside a development environment, e-mail and a client call, and that changes how I work more than any specification sheet suggests.
I do not have an M5 Ultra in my hands. Nobody outside Apple does. Every performance figure for that chip you read below is a vendor claim from Apple’s own tests in July 2026. Independent measurements arrive after 22 September.
The memory arithmetic that runs this market
A parameter count feels abstract until you turn it into bytes. A dense 70-billion-parameter model stored at 16-bit precision needs 140 GB for its weights alone. At 8-bit, 70 GB. At 4-bit, 35 GB. That is only the checkpoint.
The runtime still needs memory for the key-value cache that holds the conversation context, for intermediate activations, for framework overhead and for whatever runs beside the model. Increase the context window or serve several users at once and the key-value cache can eat more than the weights do. That is why “the file fits” and “the model runs well” are two different sentences.
Mixture-of-Experts models complicate the calculation in an interesting way. A model can contain 320 billion parameters and activate only a fraction of them for each token. That reduces the compute per token, but the full set of weights still has to live somewhere. Sparse activation makes the model cheaper to run. It does not shrink the file.
We saw this first-hand on the GB10. The gpt-oss-120b model takes more memory than the dense 70B at 4-bit, yet generates roughly twenty times faster. Decoding speed comes down, roughly, to memory bandwidth divided by the number of active parameters. At 273 GB/s the model’s architecture matters more than its size.
Now the memory tiers start to mean something. B stands for billions of parameters.
128 GB - one DGX Spark, one PGX or a 128 GB MacBook. Comfortably: mixture-of-experts models up to about 120 billion parameters at 4-bit, and dense models up to 27-30 billion. At a squeeze: 235 billion in a mixture-of-experts architecture at 3-bit, with no memory left for anything else.
256 GB - two Sparks or a Mac Studio with 256 GB. Comfortably: the same 235 billion, this time with headroom for a long context and a second model beside it. At a squeeze: 320 billion at 4-bit, which is 160 GB, plus the rest of the pipeline.
512 GB - four Sparks or a single Mac Studio from late October. Comfortably: 405 billion at 4-bit, which is 202.5 GB, with room for the whole pipeline. At a squeeze: 700 billion at 4-bit, which is 350 GB, and Kimi K3 pruned down to 350 GB in the MLX port published by PipeNetwork.
Memory bandwidth decides how quickly the stored weights can be fed into the computation. Autoregressive inference often spends more time moving weights than doing arithmetic, especially when serving one request at a time. That is why the M5 Ultra’s 1.2 TB/s matters more here than another percentage point in a CPU test. That is 4.4 times the GB10’s 273 GB/s. The model is a very thick book: capacity decides whether the book fits on the desk, bandwidth decides how fast you turn the pages. Apple has made the desk bigger and the pages turn faster. How much that buys in practice, only independent tests will tell.
The cost that is not on the specification sheet
The most interesting question about any of these machines is what happens when the model fills the memory.
Cordero Core reports that on two Sparks a model in the 300-billion-parameter class can generate 25-35 tokens per second while serving six requests at once. For hardware sitting on a desk, that is impressive. The more important limitation appears when you ask what else those machines can run. The model saturates the memory of both boxes. There is no room for a serious document-recognition model. Add vision, an embedding model for retrieval, a reranker or any other local service, and you need a third machine. Four boxes do not remove the problem, they move it up one level: a larger model fits, and the question of where the rest of the pipeline goes comes back in exactly the same form.
We saw the same thing. With gpt-oss-120b, an embedding model and the Hermes agent on one PGX there was still headroom. With Qwen3-235B on the same machine there was nothing left. Choosing a model stopped being a decision about answer quality and became a decision about whether the pipeline would fit on the desk at all.
Real AI applications rarely stop at one model. A document system needs text recognition, embeddings, reranking, vision and the language model that assembles the answer. An agent adds speech and safety models on top. When the primary model fills two Sparks, those services spill onto another machine, and every additional machine is another network hop, another deployment target and another failure boundary.
The Mac Studio is being sold with a different assumption. Apple gives one system up to 512 GB of memory, a CPU, an 80-core GPU, hardware media engines, six Thunderbolt 5 ports and macOS. You load the model, leave memory for the rest of the pipeline and keep using the computer. Extra memory does not guarantee good orchestration, but it gives the pipeline room to coexist inside one system. That is closer to how people build software than a tokens-per-second chart for a single model.
Unified memory is the product
The phrase “unified memory” has appeared in Apple keynotes for so long that it is easy to hear it as marketing. For local AI it is the product.
In a conventional workstation the CPU has system memory and a discrete graphics card has its own video memory. The model has to fit in the card’s memory, or the system shuffles pieces across PCIe. You can add cards, but then you pay for several memory pools and for the networking that has to coordinate them.
Apple Silicon changes that layout: the CPU, the GPU and the Neural Engine address the same physical memory. In a 512 GB Mac Studio that memory does not sit beside the accelerator. The accelerator simply addresses it. The result is a machine that holds models no consumer card can touch, even if a discrete NVIDIA card beats it on raw throughput for a smaller model that fits in video memory.
The distinction matters because capacity and speed are two different problems. NVIDIA wins most speed problems: CUDA is mature, the kernels are polished and the hardware was built for this work. Apple is attacking the capacity problem with a memory architecture you can put under a desk. The M5 Ultra adds Neural Accelerators in every GPU core and a claim of up to 4.3 times the peak AI compute of the M3 Ultra. Before that claim becomes a fact, let us wait for somebody else’s measurement.
The word “training” is doing too much work
Apple says data scientists can train local models on expansive datasets. NVIDIA says the Spark lets you develop models up to 200 billion parameters and fine-tune models up to 70 billion. Both sentences are defensible. Neither means you will train the next frontier model under your desk.
Several different activities hide inside the word “training”. Pretraining starts from a model with random weights and teaches it from an enormous corpus. It requires repeatedly storing activations, computing gradients, updating weights and synchronising optimiser state. The memory requirement can be many times the size of the checkpoint. That belongs to a cluster and will stay there.
Full fine-tuning starts from an existing model but updates all of its weights. It is cheaper than pretraining and still demanding. Parameter-efficient methods such as LoRA update small adapter matrices while most of the base model stays frozen. Quantised LoRA goes further and keeps the base at lower precision. That is the kind of training that makes sense on a desk. Add smaller models trained from scratch, embedding models, classifiers and domain-specific networks.
For SNOK that distinction turns into a concrete list: fine-tuning LoRA adapters on 27- to 120-billion-parameter models; distilling a larger model into a smaller one for a single process; generating synthetic data to test agents; evaluating several models on the same task set; document classifiers. None of these needs a cluster. Every one of them needs memory that holds the base model, the adapter, the optimiser and the data at the same time, plus room for a judge model beside them.
One thing needs to be clear here. In our lab we fine-tune on synthetic and anonymised data. Client data covered by a non-disclosure agreement never lands on our hardware; if fine-tuning has to happen on it, it happens in the client’s environment, on a machine that stands on their premises. And this is where the sentence that matters most in our industry sits: in medical, financial and public-sector environments, and in every company with a non-disclosure agreement, the model may be public but the dataset cannot leave the organisation. Local compute then decides whether the experiment is allowed to start at all.
A container for every purpose, or the Linux machine Apple shipped first
There is a part of this launch that only makes sense next to something Apple showed in June at WWDC 2026: Container Machine.
Container Machine is a lightweight, persistent Linux environment built on Apple’s open-source Containerization framework. It understands OCI images, starts quickly, mirrors your macOS user and working directory, and lets you allocate CPU and memory to a long-lived Linux machine without leaving the Mac workflow.
Why does that matter to someone pricing hardware for proofs of concept? Because a proof of concept is rarely just the model. Around the model stand an API, an agent harness, a vector database, data-processing workers, an evaluation service and everything that is meant to land on a Linux server at the client in a few months. The DGX Spark sells exactly that workflow: CUDA containers, PyTorch images, inference servers, deployment scripts. The prototype is built on a Spark and the same containerised workload moves to DGX Cloud or a data centre without changing anything underneath.
Apple’s answer to that workflow was historically incomplete. The Mac could run the model through Metal or MLX, but the production environment lived somewhere else, and Docker Desktop approximated it through a virtual machine, inserting another layer between developer and hardware. Now the pieces fit into one workstation: the model runs natively on macOS through MLX, Metal or Core ML, and beside it, in Container Machine, run the Linux services that turn a model into an application. Each in its own container, for its own purpose: a vector database for retrieval, an agent harness for orchestration, an OCR service for documents, an evaluator to measure quality.
One piece is missing, and it is an important one. Apple’s container stack does not currently provide supported GPU access from inside a container. A PyTorch process in Container Machine cannot reach the M5 Ultra’s GPU through Metal, and you cannot treat the Linux environment like a CUDA container on a Spark. Apple’s repository tracks GPU access as an open feature request. The architecture therefore has a seam: the heavy model server runs natively on macOS, and the Linux services call it through a local endpoint. That works, but do not buy this machine assuming an existing CUDA-container workflow will transfer unchanged. It will not.
On the PGX that seam does not exist. DGX OS is Ubuntu, CUDA containers are at home there, and what you build in the lab moves to the client’s data centre without rewriting the runtime layer. That is the GB10’s strongest card in any conversation about proofs of concept, and I have no intention of playing it down.
One chip or four boxes
Apple has given Thunderbolt 5 Macs a mechanism borrowed from the data centre: RDMA, direct access to another machine’s memory without both CPUs babysitting every transfer. Several Mac Studios can be joined into a small AI cluster this way. If one M5 Ultra is not enough, the clustering layer already exists, and Apple claims that four Mac Studios joined this way deliver up to three times faster inference than a single system.
Even so, the advantage comes from the memory layout, not from the cluster. One M5 Ultra with 256 or 512 GB keeps its whole working set inside a single chip. The GPU reaches unified memory through the local fabric. There is no second operating system to coordinate and no network link between parts of the model.
Four Sparks, which together give you the same 512 GB, have to divide the work four ways. Their ConnectX-7 ports were built for exactly that, and 200 Gb/s is serious networking. But 200 gigabits per second is 25 gigabytes per second before protocol overhead, and Apple’s local memory bandwidth is 1.2 terabytes per second. Those numbers are not directly comparable, because one describes a network link and the other a memory fabric, but the gap explains why partitioning matters. A well-partitioned model minimises communication. A poorly partitioned one waits for tensors to cross the wire. RDMA lowers that cost, but the transfer still crosses a physical link slower than local memory. The 512 GB configuration delays the moment a developer has to split a model across machines and live with the consequences.
NVIDIA squeezed from both ends
None of this means NVIDIA is in trouble. The company still owns the dominant accelerator ecosystem, the most familiar developer stack and the path from a desk prototype to a cloud deployment. It has, however, stopped being the only company deciding what AI hardware looks like.
In the last week of August OpenAI published results for its own inference chip, Jalapeño, designed with Broadcom: 1.5 to 1.9 times higher throughput per kilowatt and 1.7 to 3.6 times lower latency than NVIDIA GB200 and GB300 systems on GPT-OSS 120B, DeepSeek R1 and Kimi K2.5, at 700 watts against the GB300’s 1,400. Those are vendor-reported numbers, Jalapeño is an inference chip, and OpenAI says it will keep buying NVIDIA accelerators. The relevant point is different: a customer large enough to justify its own silicon can design around the parts of NVIDIA’s stack it no longer wants to rent.
Pressure came from another direction too. An anonymous model called Ox Alpha rose to the top of the OpenRouter and OpenCode usage charts before it was revealed as Zhipu AI’s GLM-5.3-Flash: 320 billion parameters, 18 billion active. Zhipu says the preview processed 62 trillion tokens on a cluster of 100,000 chips made in China, but has not named those chips or published enough detail for anyone to verify it. The public fact is narrower: developers sent real traffic to that model before learning that, according to the vendor, the stack serving it contained no NVIDIA hardware.
Apple applies pressure at a much smaller scale, but in the same place. Rather than replacing an NVIDIA data centre, it is asking whether a developer, a research group, a video studio or a university lab needs to enter NVIDIA’s ecosystem for the very first local machine. And the first machine matters, because tools accumulate around it. Code gets written for its APIs. Teams learn its failure modes. A hardware purchase becomes a software decision, and the software decision makes the next hardware purchase easier. NVIDIA understands this better than anyone: the DGX Spark is a small box with a deliberately paved road to DGX Cloud. Apple has just started competing for that first purchase.
What Apple still has to prove
Hardware capacity opens the door. Software decides whether developers stay.
CUDA remains NVIDIA’s deepest advantage. PyTorch support, optimised attention kernels, quantisation libraries, TensorRT-LLM, NIM containers, profiling tools and years of answers buried in forums all shorten the distance from a model repository to a working deployment. On Apple Silicon things are improving: MLX offers an array framework designed around unified memory, llama.cpp and LM Studio make local inference accessible to anyone, PyTorch’s Metal backend covers more than it used to, Core ML is useful when the destination is an Apple application. The pieces are there. They are not interchangeable with CUDA.
On 3 September NVIDIA extended that advantage into a layer nobody usually thinks about when buying hardware: it announced the acquisition of Hugging Face for USD 12.93 billion, of which USD 11.9 billion goes to shareholders and USD 1 billion to retaining the team. The deal is expected to close in the first half of 2027. Hugging Face is where we get model weights: more than three million models, half a million datasets, over eighteen million users. NVIDIA says the platform will stay open to the whole ecosystem and will keep hosting open-weight models whichever vendor’s hardware they run on.
For the calculation I am running here, that matters. NVIDIA’s advantage no longer stops at CUDA; it now reaches the layer where a model is described, versioned and downloaded, including when you download it onto a Mac. I am not assuming bad faith and I have no grounds to predict a closed platform. My point is narrower: if the convenient paths, the ready-made formats and the runnable examples start appearing for the platform owner’s hardware first, the CUDA advantage will begin to reproduce itself at the distribution layer. So Apple has to prove two things at once: that its libraries can match CUDA, and that a model pulled from the largest repository in the world starts on a Mac as smoothly as it does on a Spark.
A model may technically fit in 512 GB and still lack an efficient Metal kernel for one operation. A training recipe may assume NVIDIA’s collective-communication libraries. A quantisation format may land on CUDA months before an Apple runtime supports it. We have seen it ourselves at small scale: our runbook for Qwen3.8-27B on the GB10 relies on NVFP4 and SGLang, while on the Mac the same model family lives in different formats and different tools. Distributed examples target NCCL, not Macs joined over Thunderbolt.
If Apple wants the Mac Studio to become an AI workstation rather than a workstation that happens to run large models, it has to make the software path boring: installation, distributed execution, monitoring, recovery and framework compatibility need the same attention Apple gave the memory fabric. NVIDIA sells confidence that the next repository will probably work, and it has just bought the place where those repositories live. Apple has to build that confidence one library and one missing kernel at a time.
The calculation for SNOK
The price narrows the audience before any benchmark does. For most people the M5 Ultra Mac Studio is a bad purchase. The M5 Max at USD 2,499 is already more computer than most developers will use. A PC with an NVIDIA card remains the obvious choice when the work depends on CUDA. For most buyers there is no hidden bargain here.
The bargain is very specific and it applies to someone who was already preparing to spend five figures on local AI hardware. That is where my calculation begins.
AppleInsider read Apple’s US configurator on launch day. The step from the base 96 GB to 256 GB costs USD 4,000. A 256 GB Mac Studio comes to USD 9,499 with the smaller chip variant or USD 10,799 with the full 36-core CPU and 80-core GPU. Two Sparks, which deliver the same capacity in two boxes, cost USD 9,398. The difference is USD 101 or USD 1,401 respectively. For that difference I get one memory pool instead of two halves joined by a cable, 4.4 times the bandwidth, and a machine on which I also write the code, clean the dataset, cut the demo and take the client call. I give up CUDA.
The 512 GB version has no price, so all I can honestly say is this: four Sparks, which deliver the same total memory in four boxes, cost USD 18,796. If Apple prices 512 GB below that, and the upgrade ladder so far suggests it will, price stops being the argument against. The Polish store does not yet show pricing for the memory options.
What would I use the machine for? Three things I cannot do comfortably on a PGX. First, proofs of concept with several models at once: document recognition, embeddings, reranking, a 235- to 400-billion-parameter language model and a judge model, all in one memory pool, without a third box. Second, fine-tuning adapters on 27- to 120-billion-parameter models with synthetic and anonymised data, with the base model, the optimiser and the evaluator side by side. Third, comparing models we currently reject on size alone, before we get to test their quality on Polish documents.
And what would I not use it for? Anything meant to reach production at a client on NVIDIA hardware within the year. There the PGX, with its CUDA containers, is the right machine, because it shortens the road from lab to data centre to copying an image. That split is the heart of the whole calculation for me: the Mac Studio for what stays in the lab and needs capacity, the PGX for what ships to the client and needs to match the client’s world.
There is one more cost that rarely gets written down: a local deployment moves the duty of patching hardware and models onto whoever set them up. In the lab that is us, and that is fine. At a client that duty needs a name attached to it; without one, local AI merely moves the risk instead of closing it. That principle does not depend on the logo on the case.
I have not bought yet. I am waiting for the 512 GB price and for the first measurements taken by someone outside Apple. Yet the shortlist for local AI hardware, which usually ended with NVIDIA, now has two lines on it for me.
Capacity and speed are two different problems. NVIDIA wins speed. Apple has just bought itself a seat in the conversation about capacity.
If that conversation is only starting in your organisation, the timing is good: most firms are still choosing their first machine for local models. We have written about building an AI factory for SAP without the cloud and about taking an AI agent from idea to production. Choosing the first machine for local models is part of both journeys. If you would like to run this calculation on your own data and processes, get in touch - we will show you what actually fitted on the desk in our lab, before we propose anything for you to buy.
Sources
- Apple Newsroom, “Apple introduces new Mac Studio with M5 Max and M5 Ultra”, 25 August 2026: https://www.apple.com/newsroom/2026/08/apple-introduces-new-mac-studio-with-m5-max-and-m5-ultra/
- Apple Newsroom, “Apple introduces M6 and M5 Ultra for a big leap in performance and AI compute”, 25 August 2026: https://www.apple.com/newsroom/2026/08/apple-introduces-m6-and-m5-ultra-for-a-big-leap-in-performance-and-ai-compute/
- AppleInsider, “Apple isn’t taking pre-orders for every configuration of M5 Ultra Mac Studio”, 25 August 2026: https://appleinsider.com/articles/26/08/25/you-can-spend-18299-on-a-mac-studio-today-or-more-in-october
- NVIDIA, DGX Spark specifications, read 8 September 2026: https://www.nvidia.com/en-us/products/workstations/dgx-spark/
- NVIDIA Blog, “NVIDIA to Acquire Hugging Face”, 3 September 2026: https://blogs.nvidia.com/blog/nvidia-to-acquire-hugging-face/
- TechCrunch, “Nvidia confirms it will buy Hugging Face for $12.9 billion”, 3 September 2026: https://techcrunch.com/2026/09/03/nvidia-confirms-it-will-buy-hugging-face-for-12-9-billion/
- VideoCardz, “NVIDIA officially raises DGX Spark Founders Edition MSRP to $4,699”, February 2026: https://videocardz.com/newz/nvidia-officially-raises-dgx-spark-founders-edition-msrp-to-4699
- Cordero Core, “Apple’s New M5 Ultra Mac Studio Isn’t What You Think”, Medium, August 2026: https://medium.com/@cdcore/apples-new-m5-ultra-mac-studio-isn-t-what-you-think-11fc3d8e893c
- Apple Developer, WWDC26, “Discover container machines”: https://developer.apple.com/videos/play/wwdc2026/389/
- apple/containerization, “GPU access from containers on Apple Silicon”, issue #46: https://github.com/apple/containerization/issues/46
- Tom’s Hardware, “OpenAI says its Jalapeño chip beats Nvidia’s GB300 in first published benchmarks”, 26 August 2026: https://www.tomshardware.com/tech-industry/semiconductors/openai-says-its-jalapeno-chip-beats-nvidias-gb300-in-first-published-benchmarks
- South China Morning Post, “Zhipu AI shares jump as viral Ox Alpha model revealed as GLM-5.3-Flash on Chinese chips”, 28 August 2026: https://www.scmp.com/tech/big-tech/article/3365433/zhipu-ai-shares-jump-viral-ox-alpha-model-revealed-glm-53-flash-chinese-chips
- SNOK, “Lenovo ThinkStation PGX hands-on: we put the NVIDIA GB10 AI workstation through its paces”, 5 August 2026, and our own measurements in our GB10 lab (July-August 2026)