Upgrading My Laptop for Local LLM Development
Running LLMs locally has become a surprisingly useful part of my development workflow.
I have been using local models for coding, experimentation and AI-assisted development for some time. My previous machine was already reasonably capable:
- HP EliteBook 845 G10
- AMD Ryzen 9 7940HS
- 64 GB RAM
- Radeon 780M
- Linux
- Ollama
- Vulkan GPU acceleration
It worked.
But there was one major limitation: the Radeon 780M was becoming the bottleneck for local LLM inference. Its compute performance and memory bandwidth limited the practical speed of larger models, while 64 GB of system memory also constrained how large a model and context I could run alongside the rest of my development environment.
That was the main reason for my upgrade.
My new machine is an HP ZBook Ultra G1a with:
- AMD Ryzen AI Max+ PRO 395
- 128 GB unified memory
- significantly more capable integrated GPU
- Linux
- Lemonade
- Vulkan GPU acceleration
The difference turned out to be more significant than I initially expected.
The Real Upgrade: GPU Performance, Memory Bandwidth, and Capacity
At first glance, going from one AMD laptop APU to another might not look particularly exciting.
The important change for local AI is not simply the CPU generation.
It is this:
Previous machine
64 GB
│
├── Operating system
├── VS Code
├── Browser
├── Development tools
└── LLM
└── limited model size
New machine
128 GB
│
├── Operating system
├── VS Code
├── Browser
├── Development tools
└── LLM
└── much larger models
With 64 GB, a large model can quickly become a compromise between model size, context size and the memory required by the rest of the development environment.
With 128 GB, there is substantially more room.
This does not mean that every model suddenly becomes fast. Memory capacity and inference performance are different problems.
But it changes the set of models that are practical to run at all.
For local AI development, that distinction matters.
From Ollama to Lemonade
On the previous laptop, I used Ollama as the local inference server.
It is an excellent way to get started with local LLMs, and its simple CLI and model management make it very convenient.
On the new machine, I switched to Lemonade.
One reason was its integration with the AMD ecosystem and its support for different inference backends. Lemonade also provides an OpenAI-compatible API, which makes it possible to connect applications that already understand the OpenAI API without requiring a custom integration.
For this setup, I used llama.cpp with the Vulkan backend.
This is important because I wanted to compare the overall experience rather than changing everything at once.
Both machines used Vulkan GPU acceleration.
The major changes were therefore:
Old:
Ryzen 9 7940HS
64 GB 5600 MHz
Radeon 780M
Ollama
│
▼
Local LLM
New:
Ryzen AI Max+ PRO 395
128 GB 8533 MHz
Larger integrated GPU
Lemonade
│
▼
Local LLM
Lemonade exposes an OpenAI-compatible API, including the standard /api/v1/chat/completions endpoint and model discovery through /api/v1/models.
That turned out to be particularly useful for the next part of the setup.
Connecting Cline to a Local Model
The goal was not simply to have a local chatbot.
I wanted the local model to become part of the actual development workflow.
That meant integrating it with Cline in VS Code.
The connection was straightforward because Lemonade provides an OpenAI-compatible API.
Conceptually:
VS Code
│
│ Cline
▼
OpenAI-compatible API
│
▼
Lemonade
│
▼
llama.cpp
│
▼
Vulkan
│
▼
AMD GPU
In Cline, I configured the provider as an OpenAI-compatible API and pointed it at the local Lemonade server.
This is one of the things I particularly like about using an API-compatible local inference server.
The IDE does not need to know how the model is actually executed.
It only needs an API endpoint that behaves like the interface it already understands.
That also makes the architecture much more flexible:
┌── Local Lemonade
│
Cline ── OpenAI API ┼── Cloud provider
│
└── Another local server
The development tool can remain largely unchanged while the inference backend changes underneath it.
The Real Difference: Agentic Coding
The biggest improvement was not that a chat response became dramatically more impressive.
It was the combination of model size and speed when using an agentic coding workflow.
Cline is doing considerably more than sending one prompt and displaying the answer.
It can:
- inspect files
- search the repository
- reason about the existing architecture
- propose changes
- modify files
- execute commands
- inspect the results
- iterate on the implementation
That means the model is repeatedly called during a single development task.
If inference is slow, the whole development loop becomes slow.
For example:
Inspect code
↓
Reason
↓
Generate change
↓
Run command
↓
Read output
↓
Reason again
↓
Fix problem
↓
Run tests
A few seconds of additional latency in each generation can become minutes during a larger task.
This is where the new machine feels substantially better.
Speed Matters More Than Raw Benchmark Numbers
I would estimate that the old setup was in the high-teens to low-20s tokens/sec range for the coding models I was using, depending heavily on model size and workload.
The new system moves into a noticeably higher range, roughly around 30-50+ tokens/sec for comparable workloads, again depending heavily on the model and context.
I would not treat these numbers as a scientific benchmark.
The model, quantization, context size, Vulkan version, llama.cpp build and prompt itself can all change the result significantly.
What matters more is the subjective development loop.
The new machine feels much less like:
“I started a request. Now I wait.”
and more like:
“The agent is working.”
That distinction becomes especially noticeable when Cline performs many sequential operations.
The Bigger Model Is More Important Than the Faster Model
There is another benefit that is arguably more important than raw token generation speed.
I can use a larger model.
This changes the quality of the local development experience.
A smaller model may be perfectly capable of:
"Write this function."
But real software engineering often looks more like:
"Understand this repository,
follow the existing architecture,
identify the appropriate application/domain boundary,
modify several crates,
preserve the existing interfaces,
run the tests,
and fix any compilation errors."
That requires considerably more reasoning and context.
The additional 64 GB of memory makes these larger local models much more practical.
And this is where I think the value of a 128 GB local AI machine becomes clearer.
It is not simply about getting more tokens per second.
It is about being able to choose from a larger class of models without immediately running into memory constraints.
Why Unified Memory Is Interesting for Local LLMs
The ZBook’s architecture is particularly interesting for this use case because the CPU and integrated GPU share a large pool of memory.
For traditional discrete GPUs, model size is often constrained by dedicated VRAM.
A 24 GB GPU, for example, cannot simply use the rest of a 64 or 128 GB system memory pool as if it were equally fast VRAM.
A large-memory integrated GPU changes that trade-off.
The model can occupy a much larger shared memory space.
Of course, shared memory is not equivalent to dedicated high-bandwidth VRAM.
There are still bandwidth and compute limitations.
But for local LLM experimentation, capacity itself is extremely valuable.
This is one of the reasons systems with 128 GB of unified memory are becoming interesting alternatives for developers who want to run larger models locally.
Why I Chose Vulkan
I deliberately used Vulkan on both systems.
Lemonade supports llama.cpp with multiple backends, including Vulkan and ROCm, and the Vulkan backend supports AMD GPUs on Linux.
For this particular experiment, I was more interested in getting a stable and comparable setup than in squeezing out every last token per second.
That also reflects how I generally approach local AI infrastructure.
I want something that is:
- local
- reproducible
- easy to integrate
- accessible through a standard API
- usable from development tools
- easy to replace or upgrade later
The inference engine should be infrastructure, not something that dictates the entire development workflow.
Local AI Becomes a Development Environment
The most interesting result of this upgrade is that I no longer think of the LLM as a separate tool.
The components now form a small local AI development platform:
┌──────────────────────────────┐
│ VS Code │
│ │
│ Cline │
└──────────────┬───────────────┘
│
│ OpenAI-compatible API
▼
┌──────────────────────────────┐
│ Lemonade │
│ │
│ Model management │
│ API / inference │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ llama.cpp │
│ Vulkan │
└──────────────┬───────────────┘
│
▼
┌──────────────────────────────┐
│ AMD Ryzen AI Max+ │
│ │
│ 128 GB RAM │
└──────────────────────────────┘
The important part is that every layer has a relatively clean boundary.
Cline does not need to know how inference works.
Lemonade does not need to know what project Cline is working on.
The model does not need to know anything about the hardware beyond what the inference backend exposes.
That makes the whole setup surprisingly modular.
Is the Upgrade Worth It?
For normal software development, moving from a Ryzen 9 7940HS with 64 GB RAM to a Ryzen AI Max+ PRO 395 with 128 GB is certainly an upgrade, but it is not necessarily transformative.
For local LLM development, however, it is a different story.
The additional memory changes which models I can realistically run.
The larger GPU makes those models usable at interactive speeds.
And the combination with Cline means that the performance improvement is felt throughout an actual development workflow rather than just in a benchmark.
The most important upgrade was therefore not simply:
64 GB → 128 GB
It was:
64 GB + smaller model + slower agent loop
↓
128 GB + larger model + faster agent loop
That is a much more meaningful improvement.
Demo
Github
Youtube
Final Thoughts
I originally saw the laptop upgrade primarily as a hardware upgrade.
After using the new system with Lemonade and Cline, I see it more as an upgrade to my development environment.
The combination of large unified memory, a capable integrated GPU, local inference, an OpenAI-compatible API and an IDE agent creates something that is genuinely useful for everyday software engineering.
It also changes the economics of experimentation.
I can download a model, run it locally, connect it to my development environment and evaluate it without depending on a remote API.
For coding agents in particular, that combination of model capacity, inference speed and integration matters much more than any individual benchmark.
The interesting question is no longer whether local LLMs can replace cloud models completely.
It is whether a sufficiently capable local machine can provide a fast, private and flexible development environment where local models become another part of the engineering toolchain.
For me, with 128 GB of memory and a much faster AMD APU, the answer is increasingly yes.
