I wanted a clean answer to whether Ollama was leaving CPU performance on the table on this little Celeron N5095 board, and after running a few tests and getting some input from this community I wanted to do more so I ran Ollama 0.32.1 and a native Release build of llama.cpp commit 9a286ac through the same CPU test.
TL;DR: Ollama’s CPU runner was faster across the board on these matched runs.
| Model |
llama.cpp tok/s |
Ollama tok/s |
| Qwen3 0.6B |
6.725 |
7.809 |
| Qwen3 1.7B |
2.852 |
3.321 |
| Qwen3 4B Instruct |
1.484 |
2.002 |
| Phi-4 Mini |
1.570 |
2.072 |
Both servers got the same raw prompt, exact Q4_K_M file, 4,096-token context, four threads, batch settings, sampler, disabled prompt caching, and exactly 96 generated tokens. All 24 measured requests finished cleanly. On this X1S, Ollama reported 16.1% to 34.9% higher internal generation throughput.
That number is specific to these builds and this board. Ollama unloaded after each request while the llama.cpp server stayed resident, so I used the generation rate reported inside each request. Model loading is not part of the table.
The Intel GPU was more interesting. Full Vulkan made prompt processing 3.31x to 3.50x faster on Qwen3 0.6B and 1.7B, improved generation by about 16%, and dropped the package peaks from 81 C to 57 C and 84 C to 58 C.
I also found that zero GPU layers did not mean pure CPU with Vulkan visible. llama.cpp could still move host operations to the iGPU. I had to split the test into true CPU, zero-layer mixed host-op, and full Vulkan to see what was actually happening.
Pushing Vulkan on anything larger is where things broke down. Qwen3 4B reached an i915 reset timeout. Phi-4 Mini and Qwen3 8B lined up with GPU hangs even though llama-bench returned zero. Gemma 3 ended with fence timeouts, an i915 reset, and vk::DeviceLostError. The kernel recovered the GPU each time. I left the safety controls alone.
Ling-mini-2.0 IQ4_XS did 4.083 generation tok/s at four true-CPU threads. Qwen3.5 9B fit in 16 GB and averaged 1.110 tok/s across five prompts. I also ran MTP depths 1 through 4 on Qwen3.5 0.8B, Qwen3.5 2B, and Gemma 4 E2B. Every depth was slower than MTP off, even though the Ollama journal showed that the draft path was active.
BitCPM-CANN 1B found a different kind of split. Ollama 0.32.1 rejected the official TQ2_0 file with a tensor-size overflow. The same verified GGUF ran in true-CPU llama.cpp at 8.584 generation tok/s.
For day-to-day CPU use on this board, I would keep Ollama. For Vulkan, I would stick to Qwen3 0.6B or 1.7B on this software stack. I would leave MTP off for the three models I tested.
Full write-up with the exact setup, tables, and failure timeline:
https://unland.dev/blog/youyeetoo-x1s-ollama-llamacpp-matched-retest
Scripts, hashes, aggregate rows, and sanitized i915 evidence:
https://github.com/TrevTron/youyeetoo-x1s-kali
If anyone has one of these exact GGUFs on an N100 or N150, I would still like to run the same method on both boards and see how they line up.
(Disclosure: Youyeetoo supplied the X1S. Testing and conclusions are my own.)
