A few days ago, Unsloth made Qwen3.8-27B available, and I downloaded it to run locally with Ollama. I had heard about the benchmarks for this model, so naturally it caught my attention right away. Not because running an LLM on your own computer is still something new, but because we are starting to see relatively compact models that, at least on paper, promise capabilities that until recently were associated with much larger systems. Unsloth says that Qwen3.8-27B can run locally starting from around 17 GB of RAM or VRAM, while the version distributed through Ollama is about 18 GB and comes with a 256K context window.
In my case, I also happen to have a machine that, according to Apple, should be particularly well suited to this kind of test: a Mac mini M4 Pro with 48 GB of unified memory. It is certainly not a cheap computer, but neither is it a workstation dedicated to AI. It is simply the machine I use every day. Programming, browsers, databases, containers, various applications and everything else all live there, so it seemed like a good example of what “local AI” might actually mean for a developer.
Installing the model with Ollama was genuinely trivial. After waiting a couple of minutes, I found myself with a 27-billion-parameter model running entirely on my machine. If we stop for a second and think about it, that is pretty impressive: I am not calling an API, I am not paying for every generated token, and the code or documents I give it never leave my computer. The problem is that being able to run a model and being able to work with it are two very different things, and the second one was what I really wanted to understand.
A benchmark tells you how good a model is. I want to understand what it is like to work with it
Qwen3.8-27B comes with some very interesting numbers for developers. The benchmarks published on the Ollama page report 73.0 on Terminal Bench 2.1, 61.7 on SWE-bench Pro, 79.0 on QwenSWEBench and, most notably, 90.3 on LiveCodeBench v6. In the same table, the previous Qwen3.6-27B scores 83.9 on LiveCodeBench, while Qwen3.7-Plus reaches 89.6.
Those are important results and they explain why a 27B model like this is interesting, but they also need to be read for what they are. The model I am using through Ollama is quantized and running on a Mac, so my environment is not necessarily the same one used to produce those numbers. More importantly, a benchmark measures only certain capabilities of a model particularly well. It does not necessarily measure what it is like to use that model as a programming tool for several hours every day.
Out of curiosity, I am still running LiveCodeBench locally as well, because I wanted at least one standardized reference alongside my own impressions. The benchmark is taking quite a long time, and I will probably add a few final numbers once the test is complete, but while it was running I realized that I had already found the answer to the question I cared about most. It had very little to do with a few percentage points more or less.
To understand why, instead of giving Qwen only algorithmic problems, I asked it to build something.
Qwen, Ollama and a game of Snake
Some time ago, I used GPT with Sol for a fairly simple experiment: I asked it to build a complete version of Snake using HTML5, CSS, JavaScript and Canvas. I did not want the usual tutorial example with a few squares moving around the screen, but a small arcade game with its own visual identity, different modes, audio, visual effects, multiple control methods and enough detail to feel like a finished product.
So I used essentially the same specification with Qwen3.8-27B through Ollama.
The result surprised me in a positive way. Qwen generated an application of roughly 1,600 lines contained in a single HTML file, with four game modes, power-ups, obstacles, a combo system, particle effects, audio generated through the Web Audio API, keyboard, touch and gamepad controls, persistent high scores, settings and a whole range of arcade-style visual elements.
I do not want to go too deeply into code quality in this article because we would end up turning it into a code review, while the point that interests me is something else. I will probably publish the original prompt on GitHub together with both versions, the one produced by GPT/Sol and the one produced by Qwen, so anyone interested can compare them directly. What I can say is that I was not looking at the usual hastily generated block of code: Qwen had organized the application into separate components for audio, particles, input and game management, and the result was complete enough to open in a browser and actually use.
From that point of view, the test had already succeeded. A quantized 27B model running entirely locally had taken a reasonably complex specification and built something non-trivial without using any cloud service.
There was, however, one detail that was hard to ignore: Qwen took almost an hour to complete the job.
And that number, much more than any benchmark, is what changed the way I looked at local AI.
It can code. The real question: can I code with it?
An hour is not necessarily an absurd amount of time if I treat Qwen as a system to which I assign a task and then come back later to collect the result. I can give it something to do, let it work while I focus on something else, and return when it has finished. In some cases, that could actually be an excellent compromise, especially if I am working with material that, for privacy or confidentiality reasons, I would rather not send to an external service.
The problem starts when I try to fit it into a normal software development process, because programming with an AI assistant is almost always iterative. I ask it to implement something, test the result, notice that something is wrong, ask it to fix the problem, change a requirement, add a feature, find an edge case and keep going. The value is not only in the quality of the first answer, but also in how quickly I can move through those cycles.
That is also one of the things I noticed when comparing the experience with GPT/Sol. I am not particularly interested in deciding which one wrote the “better” version of Snake, partly because that would mean comparing systems operating under completely different conditions. With GPT, the computationally expensive part of the work happens on cloud infrastructure that I cannot see and do not have to manage, while with Qwen every token is generated by the Mac sitting in front of me. The final result may be comparable, but the way I get there is very different.
When I use a cloud model, I do not care how many GPUs are processing my request or how much memory they have available. From my point of view, I send the work and wait for the result, while my computer keeps doing everything else. With Qwen, I get all the advantages of running locally because the model is under my control, I do not need to send the code outside the machine and there is no meter increasing the cost with every generated token, but I am also the one providing all the compute.
That difference becomes particularly obvious when generation takes a long time. If a complex request takes almost an hour and the next modification takes another significant amount of time, the model may continue to produce excellent code, but the way I use it changes. I start assigning it work that I can leave running instead of constantly interacting with it, and at that point it starts to resemble a batch-processing system more than an interactive programming assistant.
This is not necessarily a problem with the model itself. It is a question of the feasibility of the entire system, meaning the model, quantization, inference engine and the hardware I am trying to run it on.
That is precisely why the reported 90.3 score on LiveCodeBench and the hour required to produce Snake are not contradictory at all. The first number says something about the model’s capabilities; the second tells me what it costs, in terms of time and resources, to make those capabilities available on a personal computer.
They are two different measurements and, if I have to choose a tool that I intend to use every day, both matter to me.
The Mac kept its promise, perhaps a little too well
At this point it would be easy to conclude that a Mac mini M4 Pro with 48 GB of memory is simply not powerful enough for serious local AI, but I think that would be almost the opposite of what this experiment actually demonstrates.
The Mac managed to run, without any particular difficulty, a quantized 27B model that Ollama distributes at around 18 GB, and that model produced a complete application. For a general-purpose machine, that is a remarkable result, especially considering that the same computer also has to be the workstation on which I do everything else.
Perhaps the problem is not that the Mac fails to deliver on the promise of local AI, but that this promise is often interpreted too simplistically. The fact that a computer can run a model does not necessarily mean that it is also the ideal solution for serving that model continuously throughout an entire working day.
When a local LLM goes from being something I open occasionally to becoming a permanent part of my development environment, I am asking the same machine to perform two fairly different roles. On one side, it has to be my workstation, running the IDE, browser, containers, databases, builds and everything else. On the other, it is supposed to become an inference machine, ideally ready to generate long and complex responses every time I ask.
The fact that it can do both does not necessarily mean that I want it to work that way.
And this is where machines such as NVIDIA DGX Spark or some of the newer high-memory AMD systems started to make much more sense to me than they did before.
Not necessarily because they can do something that is impossible on the Mac, but because they separate those two jobs.
“Local” does not necessarily mean “on the same computer”
We are used to thinking about local AI as a model that we download onto the laptop or desktop sitting in front of us. It is a natural definition, but it is not the only possible one.
My computer can store several terabytes of data, but if I want storage that is always available and shared across multiple devices, I use a NAS. I can run servers, databases and containers on my workstation, but when a service needs to be continuously available, it often makes more sense to move it onto a dedicated machine. It does not stop being local because of that.
I do not see why AI should necessarily follow a different logic.
I could have a dedicated machine on my network keeping Qwen or other models in memory, while the Mac simply sends requests to it. Ollama already exposes APIs that make this kind of architecture fairly natural, so from the application’s point of view relatively little would change. The difference is that the computer I am using for development would no longer have to carry the entire inference workload itself.
The data could still remain inside my network, I would still control which models I use and I would not have to pay a provider for every token. “Local AI” would simply stop meaning “AI running on the computer my keyboard is connected to” and start meaning “AI running on hardware that I control”.
The more I experiment with local models of this size, the more interesting this second definition becomes.
We could even see a fairly common new product category emerge: a kind of personal AI server, a machine dedicated primarily to inference, with a large amount of memory and bandwidth, always available on the network and accessible simultaneously from a desktop, laptop and perhaps other applications or devices.
In that case, we would have three very different scenarios that today tend to be mixed together under the same definition of local AI: cloud services running on completely external infrastructure, smaller models that genuinely run on-device, and larger models running on dedicated personal infrastructure.
After this experiment, that third scenario feels much less exotic to me than it did before.
So, can you actually work with it?
As far as I am concerned, Qwen3.8-27B has already answered the less interesting part of the question: yes, a local model of this size can code. The Snake test does not prove that it is better than GPT, nor does it pretend to replace more rigorous benchmarks, but it demonstrates something much simpler and more concrete: I can give a fairly detailed specification to a model running entirely on my Mac and eventually get a real application back.
The part I still have doubts about is the everyday experience. Waiting almost an hour for a substantial generation may be perfectly acceptable if I treat the task as something I can leave running, but it becomes much harder to accept when that generation is only the first step in a long sequence of changes.
That is why, paradoxically, this test convinced me more about the capabilities of local AI than about the idea of always running it on my main computer.
The limitation I encountered was not “Qwen is not good enough”. It was something much more practical: Qwen is good enough to make me want to use it, but it is not yet fast enough on my hardware to make me forget that I am using a local model.
And that is an important difference, because it means the next step may not simply be better models or computers with more RAM. It may be time to start thinking about local AI as a real component of personal infrastructure, separate from the machine on which we actually work.
My Mac can run Qwen3.8-27B and, after this test, I have very few doubts that local models in this class can become serious programming tools.
The problem is that, if I really want to use them for hours every day, I do not think the solution is simply to buy a more powerful Mac. At that point, it makes more sense to separate the roles: let the Mac remain my workstation and move inference to a dedicated machine, always available on the network, with much more memory and bandwidth and designed specifically for that kind of workload.
This is where products such as NVIDIA DGX Spark or HALO AI by AMD stop looking like exotic hardware for enthusiasts and start to make practical sense: not as replacements for the main computer, but as a kind of personal AI server.
So perhaps the future of local AI will not be a laptop capable of doing everything. It may be a normal workstation in front of us and, somewhere on the network, a second machine whose only job is to run the models.