What Can You Run on an Intel Core Ultra iGPU with OpenVINO?

Intel Core Ultra laptops are unusually interesting for local AI because system RAM is also the memory pool available to the integrated GPU. That makes a 16 GB, 32 GB, or 64 GB machine meaningfully different from a conventional discrete-GPU system with a fixed VRAM ceiling.

This article focuses on what can be run on Core Ultra integrated graphics through the OpenVINO stack. The goal is not to compare every model available today, but to establish a useful model-to-RAM map using current model generations.

The runtime throughout this guide is OpenVINO, with OpenVINO Model Server (OVMS) used when a server/API deployment is appropriate. This is deliberately not a llama.cpp guide.

The RAM tiers

The simplest way to think about a Core Ultra iGPU system is by system memory:

System RAM	Practical target class
8 GB	Qwen3.6-35B-A3B with disk streaming as an extreme memory-constrained configuration, where the hardware and current OpenVINO support allow it
16 GB	Qwen3.5-9B, plus Qwen3.6-35B-A3B with disk streaming
32 GB	Qwen3.6-35B-A3B INT4 and Qwen3.8-27B INT4 become serious targets
64 GB	Higher-precision Qwen3.8-27B and substantially larger aggressively quantized models become possible

These are not hard compatibility boundaries. Context length, KV-cache settings, operating-system memory use, model precision, and OpenVINO’s memory behavior all affect the usable ceiling.

For the large-model cases where the model is too large to keep resident, see How to Run MoE Models on OpenVINO with Disk Streaming.

8 GB: an extreme MoE use case

An 8 GB Core Ultra system is severely memory constrained, but that does not necessarily mean that large MoE models are completely irrelevant. The combination of aggressive quantization and OpenVINO’s disk-streaming support can make Qwen3.6-35B-A3B an experimental target even on very small-memory configurations, provided the particular GPU supports the required offloading path.

Qwen3.6-35B-A3B has 35 billion total parameters but only about 3 billion active parameters per token. That makes it a fundamentally different memory and compute problem from a 35B dense model. Disk streaming moves eligible expert weights out of the resident memory requirement and brings them in as needed.

This is not the configuration to expect the best performance from. It is the configuration that demonstrates why MoE offloading exists in the first place: a model whose total parameter count would normally be far beyond an 8 GB machine can potentially be made usable by trading memory capacity for storage traffic and latency.

For the exact OpenVINO disk-streaming workflow and OFFLOAD_RATIO configuration, see How to Run MoE Models on OpenVINO with Disk Streaming.

16 GB: Qwen3.5-9B and streamed Qwen3.6-35B-A3B

A 16 GB Core Ultra machine has two interesting directions.

Qwen3.5-9B

For normal local inference, Qwen3.5-9B is the sensible starting point. A properly quantized version leaves considerably more room for the operating system, runtime, and KV cache than a much larger model would.

The particularly interesting option is pairing Qwen3.5-9B with a supported speculative-decoding workflow such as DFlash. DFlash is a separate draft-model mechanism rather than a different target model, so it should be thought of as an optimization layered on top of the normal OpenVINO model deployment.

For the actual DFlash conversion workflow, see How to Convert and Run DFlash Models with OpenVINO.

Qwen3.6-35B-A3B with disk streaming

The other direction is much more aggressive: Qwen3.6-35B-A3B with INT4 quantization and OpenVINO disk streaming. The model’s MoE structure makes this particularly interesting because only a fraction of its parameters are active for each token, while offloading reduces the resident weight requirement further.

On a 16 GB machine, this is not equivalent to having a 32 GB system. Streaming has a performance cost, and available memory after the operating system and other applications is much lower than the headline 16 GB number. Still, this is precisely the type of configuration that the OpenVINO offloading feature is intended to make possible.

See How to Run MoE Models on OpenVINO with Disk Streaming for the setup and tuning procedure.

32 GB: the sweet spot for large models

32 GB is where Core Ultra iGPUs become much more interesting for large local models.

Qwen3.6-35B-A3B

The current Qwen3.6-35B-A3B is a 35-billion-parameter MoE model with about 3 billion parameters active per token. An INT4 OpenVINO export is the natural configuration to investigate on a 32 GB system.

With 32 GB, there is substantially more room for the model, runtime allocations, and KV cache than on a 16 GB machine. Disk streaming remains useful when the model cannot comfortably remain resident, but it does not need to be pushed as aggressively.

See How to Run MoE Models on OpenVINO with Disk Streaming when the resident-memory requirement is the limiting factor.

Qwen3.8-27B

The other major 32 GB target is Qwen3.8-27B. This is a 27B dense model, not an MoE model.

The current OpenVINO Qwen3.8-27B packages are an evolving part of the stack, so the exact model package and OpenVINO version should be checked before deployment. For an experimental/nightly model, treat the required OpenVINO and Optimum versions as part of the model’s compatibility requirements rather than assuming an older stable installation will work.

At 32 GB, INT4 is the natural place to start. The model is large enough that higher-precision variants consume a substantial portion of the available shared memory, while INT4 keeps the weights in a much more practical range.

64 GB: more room for precision and scale

64 GB changes the equation again. Once the system has enough RAM to hold substantially larger model representations, you no longer have to treat INT4 as the only interesting configuration.

Qwen3.8-27B at higher precision

A 64 GB Core Ultra system is a much better environment for experimenting with Qwen3.8-27B at less aggressive quantization. The model’s 27B parameter count means the raw weight footprint scales quickly as precision increases, but 64 GB gives the system considerably more room for weights, runtime allocations, KV cache, and the operating system.

The point of the 64 GB tier is therefore not simply to run the same INT4 model with more empty memory. It gives you room to move upward in precision while retaining a model size that is still meaningful on an integrated GPU.

Larger models with aggressive quantization

64 GB also opens the door to substantially larger models when an appropriate OpenVINO export exists. Large MoE models are particularly interesting because their total parameter count can be far larger than the amount of computation performed for each token.

The limiting factor is model availability in the OpenVINO ecosystem. A Hugging Face checkpoint existing is not the same thing as having a working OpenVINO export, OpenVINO GenAI support, and an OVMS deployment path.

That distinction is especially important with the newest Qwen releases. Model names and architectures have changed quickly, so a configuration that was sensible for an older Qwen generation should not automatically be applied to the current one.

OpenVINO is the common layer

All of these configurations are based around the same basic software stack:

Hugging Face model
        |
        v
Optimum Intel / OpenVINO export
        |
        v
OpenVINO IR / OpenVINO GenAI
        |
        +------> GPU plugin
        |
        v
OpenVINO Model Server
        |
        v
OpenAI-compatible API / application

The important point is that the RAM tier tells you what class of model is interesting, while the OpenVINO version and model package determine whether the exact configuration is currently usable.

Nightly features need to be treated differently

The OpenVINO ecosystem moves quickly enough that some of the most interesting features arrive in nightly builds before they become part of a normal stable release.

DFlash support and newer model integrations should therefore be checked against the current OpenVINO and Optimum Intel versions before following an older command from a blog post or GitHub issue.

The same rule applies to newly released Qwen architectures. A model card that exists today does not guarantee that the current stable OpenVINO release has the exact export and runtime path required by that model.

For that reason, the RAM tiers above should be treated as a practical map rather than a promise that every listed configuration will work on every Core Ultra laptop.

The practical map

• 8 GB: Qwen3.6-35B-A3B with aggressive quantization and disk streaming is an extreme experimental target. See How to Run MoE Models on OpenVINO with Disk Streaming.
• 16 GB: Qwen3.5-9B is the straightforward target, with DFlash available where the current OpenVINO workflow supports it. Qwen3.6-35B-A3B with disk streaming is the more ambitious option. See How to Run MoE Models on OpenVINO with Disk Streaming.
• 32 GB: Qwen3.6-35B-A3B INT4 is one of the strongest large-model targets. Qwen3.8-27B INT4 is another important target as its OpenVINO support matures.
• 64 GB: Qwen3.8-27B becomes interesting at higher precision, while larger aggressively quantized models become increasingly viable when OpenVINO provides the required export and runtime support.

The important takeaway is that Core Ultra system RAM is part of the AI hardware budget. With OpenVINO, the useful question is not simply how much VRAM the GPU has. It is how much shared memory the system has, what precision the model can use, and whether the current OpenVINO stack supports that model.