Limitations
Once the setup with Aider, Ollama, Grafana, and Streamlit was working, I decided to push it a little further.
The idea was to test a newer model based on a different approach from traditional autoregressive models: DiffusionGemma.
The model I wanted to try was:
google/diffusiongemma-26B-A4B-it
The naming is interesting:
26B = total number of parameters
A4B = approximately 4B active parameters
This is a Mixture-of-Experts model, but that does not mean it runs like a 4B model.
When running it locally, you still have to handle a very large model.
Why I Did Not Use It with Aider
My main workflow was:
Aider → Ollama → local model
However, DiffusionGemma was not supported by Ollama in my setup. I therefore changed the goal: instead of using it with Aider, I tested it directly with the dedicated llama.cpp runner.
I did not expect it to become part of my daily workflow, but I still wanted to run a technical experiment.
Installing the Hugging Face CLI
Inside WSL, I installed the Hugging Face CLI using its dedicated installer:
cd ~
curl -LsSf https://hf.co/cli/install.sh | bash
exec $SHELL -l
Then I verified the installation:
hf --help
Downloading the GGUF Model
I downloaded the Q4_K_M quantization:
mkdir -p ~/models/diffusiongemma
hf download unsloth/diffusiongemma-26B-A4B-it-GGUF \
--local-dir ~/models/diffusiongemma \
--include "*Q4_K_M*"
Then I checked that the file was present:
find ~/models/diffusiongemma -name "*.gguf" -type f
The download completed successfully, but the file is large: approximately 16 GB.
Building the Dedicated Runner
To test the model without Ollama, I used the DiffusionGemma branch of llama.cpp.
First, I installed the required dependencies:
sudo apt update
sudo apt install -y git cmake build-essential
Then I cloned the repository and checked out the relevant branch:
mkdir -p ~/src
cd ~/src
git clone https://github.com/ggml-org/llama.cpp llama.cpp-diffusiongemma
cd llama.cpp-diffusiongemma
git fetch origin pull/24423/head:diffusiongemma
git checkout diffusiongemma
For a CPU-only build:
cmake -B build -DGGML_NATIVE=ON
cmake --build build -j $(nproc) --config Release --target llama-diffusion-cli
To verify the build:
ls -l build/bin/llama-diffusion-cli
Running the Model
I stored the model path in a variable:
MODEL=$(find ~/models/diffusiongemma -name "*Q4_K_M*.gguf" -type f | head -n 1)
echo "$MODEL"
Then I launched the runner:
cd ~/src/llama.cpp-diffusiongemma
./build/bin/llama-diffusion-cli \
-m "$MODEL" \
-ngl 0 \
-cnv \
-n 256
The command ran successfully, but on the machine I was using, performance was far too slow for practical use.
I also tried a lower output limit:
./build/bin/llama-diffusion-cli \
-m "$MODEL" \
-ngl 0 \
-cnv \
-n 32
And another variant with an explicit thread count:
./build/bin/llama-diffusion-cli \
-m "$MODEL" \
-ngl 0 \
-cnv \
-n 64 \
-t 10
The Bottleneck
My machine has:
Intel Core i7-1355U
48 GB of RAM
Intel Iris Xe
no dedicated GPU
The available RAM is enough to load many quantized models, but that does not make them fast enough for interactive use.
The real bottlenecks are:
mobile CPU
memory bandwidth
lack of dedicated VRAM
the higher computational cost of the diffusion architecture
The fact that a model is described as 26B-A4B does not mean it is equivalent to a dense 4B model.
It only means that a subset of the parameters is activated for each token. The full model is still large, and when running it locally, you still pay the cost in memory usage, I/O, and runtime complexity.
Top comments (0)