Model or dataset
eleiton/ollama-intel-arc avatar
eleiton/ollama-intel-arc

ollama-intel-arc: a native SYCL backend for Ollama on Intel Arc

Make use of Intel Arc Series GPU to Run Ollama, StableDiffusion, Whisper and Open WebUI, for image generation, speech recognition and interaction with Large Language Models (LLM).

413 stars56 forksDockerfileApache-2.0

At a glance

What is it?
eleiton/ollama-intel-arc is a set of Podman compose files that run Ollama, Open WebUI, ComfyUI or SD.Next and Whisper against Intel Arc GPUs. The interesting part is the Ollama image: a native llama.cpp ggml-sycl backend compiled from Ollama source, with a Vulkan path for people who do not want to build.
Who is it for?
Use ollama-intel-arc if you have an Intel Arc GPU, discrete or integrated, and want Ollama running with a backend built from upstream source rather than a patched engine. Start with the Vulkan compose and benchmark it before committing to the SYCL build, since the README says the two are often competitive on Meteor Lake and Xe-LPG parts and only one of them needs a local compile.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 8 days ago.
What is it written in?
Mainly Dockerfile, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 18, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What the stack is

The repository is a set of compose files plus two Dockerfiles, and it wires up five services. Ollama serves the models. Open WebUI provides the chat interface. ComfyUI and SD.Next handle image generation. An optional Whisper container does automatic speech recognition.

The composition matters less than the Ollama image. The README says the container runs a native llama.cpp ggml-sycl backend built directly from upstream Ollama, explicitly without IPEX-LLM. That is a different approach from most Intel GPU inference setups, which route through Intel's own patched inference engine.

The image is built locally in two stages. Stage one builds libggml-sycl.so with oneAPI, compiled with icpx against Level Zero. Stage two places that library next to the official Ollama binary on a slim Ubuntu runtime carrying the Intel GPU user-space drivers: Level Zero, compute-runtime, IGC and GMM.

SYCL or Vulkan

Two Ollama paths ship. docker-compose.ollama-sycl.yml builds the image described above, so the first run compiles locally. docker-compose.ollama-vulkan.yml uses the stock ollama/ollama image and builds nothing.

The README gives a concrete reason to try Vulkan: on Meteor Lake and Xe-LPG integrated GPUs the Vulkan backend is often competitive with SYCL while requiring no custom build, and it suggests benchmarking on your own hardware. That is a fair framing. The SYCL path is the one with the tuned defaults and the fp16 math flag, and the Vulkan path is the one that starts in a minute.

A legacy docker-compose.yml based on the intelanalytics/ipex-llm-inference-cpp-xpu image is still in the repository, and the README labels it outdated and kept for reference only.

Setting it up

Configuration lives in a .env file copied from the example, and the README's setup is three commands:

bash
git clone https://github.com/eleiton/ollama-intel-arc.git
cd ollama-intel-arc
cp .env.example .env

Then bring up the SYCL stack, which builds the image the first time:

bash
podman compose -f docker-compose.ollama-sycl.yml up -d --build

Or the Vulkan stack, which pulls a prebuilt image:

bash
podman compose -f docker-compose.ollama-vulkan.yml up -d

Image generation and speech recognition are separate composes run alongside: docker-compose.comfyui.yml, docker-compose.sdnext.yml and docker-compose.whisper.yml. To confirm Ollama came up, the README checks the port:

bash
curl http://localhost:11434/

That should answer Ollama is running. If the Arc GPU was detected, the container log prints Found 1 SYCL devices followed by a table listing level_zero:gpu:0 and the device name.

The environment variables that decide performance

Runtime behaviour is set through the .env file and passed through by the compose files. The README's table gives seven defaults, and adds that they are tuned for an Intel Arc Graphics Meteor Lake-P integrated GPU with shared UMA memory, which is worth knowing before copying them to a discrete card.

OLLAMA_CONTEXT_LENGTH defaults to 8192, with the note that larger contexts grow the KV cache and shrink the model that fits. OLLAMA_KV_CACHE_TYPE defaults to q4_0, and the README suggests f16 or q8_0 on a UMA iGPU with plenty of RAM, since it can be faster and better at no real memory cost. OLLAMA_FLASH_ATTENTION is true and is said to work on both paths. OLLAMA_NUM_GPU is 999, offloading all transformer layers. GGML_SYCL_F16 is 1, enabling fp16 math in the SYCL backend.

Two defaults carry a judgement. OLLAMA_NUM_PARALLEL is 1 because, per the README, UMA iGPUs are bandwidth-bound and parallelism buys no throughput. OLLAMA_KEEP_ALIVE is 2h, keeping models resident to avoid reload latency.

How Open WebUI is configured

The interface uses the official Open WebUI distribution with several flags set for local use. WEBUI_AUTH is turned off, so there is no login. ENABLE_OPENAI_API is off and ENABLE_OLLAMA_API is on, which restricts interaction to the Ollama backend.

Image generation is wired in: ENABLE_IMAGE_GENERATION is true and IMAGE_GENERATION_ENGINE is set to automatic1111, which the README notes SD.Next is compatible with. That is why the image generation composes are worth starting if you want the feature to do anything.

The no-auth default is convenient on a home network and is the wrong setting anywhere the port is reachable by other people. Nothing in the README discusses exposing it safely.

Where it will disappoint

Defaults target one specific configuration. They are tuned for an integrated Meteor Lake-P GPU with shared memory, so an owner of a discrete Arc card should expect to change context length, KV cache type and possibly parallelism rather than take the file as shipped.

Bandwidth is the real ceiling on integrated parts, which is why the default is one request at a time. Anyone expecting to serve several users will not get there by raising OLLAMA_NUM_PARALLEL.

Not everything uses the native backend either. Only Ollama does. The Stable Diffusion and Whisper containers are still built on Intel Extension for PyTorch, so those parts carry a different dependency chain and a different update cadence. And the SYCL path compiles oneAPI code locally, which is a long first build and a build that has to be repeated when the Ollama version moves, as it does often: 3.4.7 moved to 0.32.4, 3.4.8 to 0.32.6 and 3.4.9 to 0.34.0, across July and September 2026.

IPEX-LLM as the other route

The alternative this project defines itself against is IPEX-LLM, and the repository once shipped a compose file built on Intel's ipex-llm-inference-cpp-xpu image. The difference in approach is where the GPU support comes from.

IPEX-LLM is Intel's own inference stack, maintained as a separate engine with its own model conversion and its own release schedule. Running Ollama through it means depending on that engine tracking upstream Ollama.

This repository instead compiles llama.cpp's SYCL backend straight from Ollama source, so the Ollama version is whatever upstream released, at the cost of a local build against oneAPI. Choosing between them is mostly a question of whether you would rather build locally or wait on an engine release, and the Vulkan compose is the third option for anyone who wants neither.

Licence and upkeep

The repository is Apache-2.0. The last push was on 2026-09-10, and release 3.4.9 carries the same date, so it tracks Ollama releases closely.

Upkeep is dominated by that tracking. Every Ollama bump means rebuilding the SYCL image, and the compose files pin the runtime through the .env file, so an upgrade touches both. The compose commands in the README use podman rather than docker, which is a deliberate choice by the author and worth knowing before you start typing.

Editorial conclusion

Use ollama-intel-arc if you have an Intel Arc GPU, discrete or integrated, and want Ollama running with a backend built from upstream source rather than a patched engine. Start with the Vulkan compose and benchmark it before committing to the SYCL build, since the README says the two are often competitive on Meteor Lake and Xe-LPG parts and only one of them needs a local compile. If you own a discrete card, treat the .env defaults as a starting point rather than a recommendation, because they were tuned for a shared-memory integrated GPU with one request at a time.

Frequently asked questions

Can I run Ollama on an Intel iGPU?

Yes. The default settings in .env.example are tuned for an Intel Arc Graphics Meteor Lake-P integrated GPU with shared UMA memory, and the README recommends benchmarking the Vulkan backend on Meteor Lake and Xe-LPG iGPUs since it needs no custom build.

Do I have to build the Ollama image myself?

Only on the SYCL path, where docker-compose.ollama-sycl.yml builds a native ggml-sycl backend locally. The Vulkan compose uses the stock ollama/ollama image and builds nothing.

Which port does Ollama use in this stack?

The README says port 11434 is exposed for other tools to connect, and suggests curl http://localhost:11434/ to confirm the service is up, which should reply Ollama is running.

Is the IPEX-LLM compose file still supported?

No. The README calls the docker-compose.yml based on intelanalytics/ipex-llm-inference-cpp-xpu outdated and says it is kept for reference only, with the SYCL and Vulkan composes as the recommended path.

Official sources

  1. eleiton/ollama-intel-arc on GitHub
  2. Issues
  3. License: Apache-2.0
  4. README
  5. Releases
Community notes

Community notes