Did Vulkan make the X1S faster for local LLMs?

For Qwen3 0.6B and 1.7B, yes. Those two Vulkan runs were clean, prompt processing was much faster, and package temperatures were lower. The 4B and 8B runs were not clean enough for a performance claim because the kernel logged reset timeouts or GPU hangs.

Did Ollama beat llama.cpp on the X1S?

This round cannot support a runtime winner. Five rows reused the same Q4_K_M files, but Ollama ran a natural-language API request at 4,096-token context while llama.cpp ran a synthetic llama-bench pp128/tg96 workload. Ollama used a 96-token ceiling and some responses stopped at 54, 56, or 84 tokens. The main llama.cpp matrix also did not explicitly set the same 4,096-token context. The recorded values remain useful as separate observations, but a fair winner claim needs a same-prompt rerun with every material setting matched.

What failed during the Vulkan tests?

Qwen3 4B reached a kernel reset timeout, and Phi-4 Mini and Qwen3 8B coincided with i915 GPU hangs even though llama-bench returned normally. Gemma 3 4B later failed explicitly with fence timeouts, an i915 preemption reset, and vk::DeviceLostError. The kernel recovered the GPU each time, but only the 0.6B and 1.7B Vulkan rows are treated as clean measurements.

How fast are Qwen3.5 0.8B and 2B on the Celeron N5095?

Using official Ollama Q8_0 tags, the two warm Qwen3.5 0.8B runs averaged 10.44 tokens per second and the two warm Qwen3.5 2B runs averaged 4.89 tokens per second. Their recorded package peaks were 70 and 75 C.

Were Gemma 4 E2B and E4B tested, or only Gemma 3n E2B?

Both official Gemma 4 variants are now separate measured results. The Q4_K_M E2B tag averaged 3.38 warm tokens per second with a 77 C package peak, while E4B averaged 1.78 with a 78 C peak. The earlier gemma3n:e2b result was 3.24 tokens per second and must not be labeled as Gemma 4.

Does BitCPM-CANN 1B TQ2_0 run on the X1S?

The official GGUF ran in llama.cpp CPU mode at 13.30 prompt tokens per second and 8.63 generation tokens per second, with zero GPU layers and a 68 C package peak. Ollama 0.32.1 rejected the same verified file during model loading with a tensor size overflow.

Hardware · August 23, 2026

Ollama, llama.cpp, and Vulkan on the Youyeetoo X1S

I tested Ollama, llama.cpp, Intel Vulkan, Qwen3.5, Gemma 4, and BitCPM on a Celeron N5095 Youyeetoo X1S, with thermals and i915 evidence.

After getting the X1S stable as a Kali-on-NVMe cyberdeck, I tested Ollama, a local llama.cpp build, and the Jasper Lake Intel GPU. The CPU values come from different harnesses, so they do not establish a runtime winner. The useful comparison was inside llama-bench: Vulkan helped Qwen3 0.6B and 1.7B, while the larger runs exposed kernel instability.

What the CPU measurements show

Five rows reused the same Q4_K_M GGUF files. Ollama ran my natural-language API request at a 4,096-token context and used a 96-token ceiling, but some responses stopped at 54, 56, or 84 tokens. llama.cpp ran a synthetic llama-bench pp128/tg96 workload, and the main matrix did not explicitly set the same context. The numbers are separate observations, not proof that either runtime is faster.

Vulkan results that held up

Within llama-bench, the two clean Vulkan runs lifted Qwen3 0.6B from 7.42 to 8.56 tok/s and Qwen3 1.7B from 2.98 to 3.48 tok/s. Their prompt processing ran at 3.3 to 3.5 times the CPU rate, with package peaks 26 to 27 °C lower.

Qwen3 4B reached a kernel reset timeout. Phi-4 Mini and Qwen3 8B coincided with i915 GPU hangs even though llama-bench returned normally. Gemma 3 later ended with vk::DeviceLostError. Those numbers remain available as diagnostic evidence, but they are not clean performance results.

Official candidate results

Using the same guarded Ollama request and two warm measurements, Qwen3.5 0.8B averaged 10.44 tok/s with a 70 °C peak, Qwen3.5 2B averaged 4.89 tok/s with a 75 °C peak, Gemma 4 E2B averaged 3.38 tok/s with a 77 °C peak, and Gemma 4 E4B averaged 1.78 tok/s with a 78 °C peak. The 0.8B model was the fastest text-generation result in this X1S work.

BitCPM runtime compatibility

The official BitCPM-CANN 1B TQ2_0 GGUF ran in llama.cpp CPU mode at 13.30 prompt tok/s and 8.63 generation tok/s with a 68 °C package peak. Ollama 0.32.1 rejected the same verified file during model loading with a tensor size overflow.

What I would use

I am keeping Ollama for ordinary use because it is already installed and gives me the simplest workflow, not because this round proved it faster. Vulkan was useful with the two smallest tested models, but I would not use the larger Vulkan rows for performance claims on this stack. The kernel evidence matters more than a zero process return code.

Read the original X1S Kali build article. The GitHub repository contains the protocol, result summaries, Gemma patch script, and retained GPU-hang evidence.