# Thinking model recomendation for core ultra 5 135u **URL:** \ **Category:** Beginners\ **Created:** [April 16, 2026, 3:33am UTC](https://discuss.huggingface.co/t/thinking-model-recomendation-for-core-ultra-5-135u/175297 "2026-04-16T03:33:45Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![vrj123](https://avatars.discourse-cdn.com/v4/letter/v/ee59a6/32.png) [@vrj123](https://discuss.huggingface.co/u/vrj123)\ **Post date:** [April 16, 2026, 3:33am UTC](https://discuss.huggingface.co/t/thinking-model-recomendation-for-core-ultra-5-135u/175297/1 "2026-04-16T03:33:46Z")
Hi very new to setting up AI. This will be my first attempt. I would like any advice on what will work well on an intel core ultra 5 135u with 32 gig ram For reasoning, from what I managed to research it seems like DeepSeek-R1-Distill-Qwen-14B should work well I dont know which is the better implementation. **IPEX-LLM (SYCL):** llama.cpp using CPU + iGPU hybrid offloading **OpenVINO:** llama.cpp backend attempting GPU + NPU load-splitting. Currently, is the OpenVINO NPU-offload mature enough for 14B models, or should I stick to the IPEX-LLM iGPU. I am also using windows voice access. In task manager it looks like windows is using the gpu to implement it Any general advice at all since this will be my first attempt Thanks ---
**Author:** ![John6666](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/john6666/32/27664_2.png) [@John6666](https://discuss.huggingface.co/u/John6666)\ **Post date:** [April 16, 2026, 2:38pm UTC](https://discuss.huggingface.co/t/thinking-model-recomendation-for-core-ultra-5-135u/175297/2 "2026-04-16T14:38:06Z")
I’m not very familiar with the stack for Intel GPUs/NPUs… As a safe bet for LLMs in general, the latest model families—such as [Gemma 4](https://huggingface.co/collections/google/gemma-4) and [Qwen 3.5](https://huggingface.co/collections/Qwen/qwen35)—are worth recommending, but they’re so new that software support might still be lacking. The previous Qwen 3 family, which has good software support, also includes [a small but well-known Thinking model](https://huggingface.co/Qwen/Qwen3-4B-Thinking-2507). * * * For a **Core Ultra 5 135U with 32 GB RAM** , I would **not** make **OpenVINO NPU offload** the main plan for **DeepSeek-R1-Distill-Qwen-14B**. On your machine, the safer answer today is: **use CPU + iGPU first** , keep the **NPU as optional experimentation** , and strongly consider starting with a **7B–8B** model before you move up to 14B. The short version of the recommendation is: - **Best first success:** **Qwen3-8B** or **Phi-4-mini-reasoning**. ([Hugging Face](https://huggingface.co/Qwen/Qwen3-8B "Qwen/Qwen3-8B")) - **Best DeepSeek-family fit:** **DeepSeek-R1-Distill-Qwen-7B** first, **14B** second. - **Best backend direction overall:** **OpenVINO** as the strategic stack, but **CPU/GPU first** , not NPU-first, on your exact laptop. ([GitHub](https://github.com/openvinotoolkit/openvino "OpenVINO™ is an open source toolkit for optimizing and ...")) - **Best answer to your exact 14B question:** if you must choose today between **IPEX-LLM iGPU hybrid** and **OpenVINO NPU-offload** , the **iGPU/CPU route is more realistic for 14B on a 135U**. ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes")) ## 1. What your hardware actually is Your **Core Ultra 5 135U** is not a bad local AI chip. It is just a **modest** one. Intel’s official specs list: - **Intel Graphics** with **4 Xe-cores** - about **8 TOPS** on the GPU side - **Intel AI Boost** NPU with **11 TOPS** - support for **OpenVINO** , **WindowsML** , **DirectML** , and **ONNX Runtime** on the NPU. ([intel.com](https://www.intel.com/content/www/us/en/products/sku/237328/intel-core-ultra-5-processor-135u-12m-cache-up-to-4-40-ghz/specifications.html "Intel® Core™ Ultra 5 Processor 135U")) That means your system is capable of local AI, but it is not a high-end “throw a 30B model at it” machine. It is better thought of as a **good 4B–8B machine** , a **usable 7B/8B reasoning machine** , and a **stretch 14B machine**. ([intel.com](https://www.intel.com/content/www/us/en/products/sku/237328/intel-core-ultra-5-processor-135u-12m-cache-up-to-4-40-ghz/specifications.html "Intel® Core™ Ultra 5 Processor 135U")) ## 2. Why 14B is the hard point Your model choice, **DeepSeek-R1-Distill-Qwen-14B** , is reasonable as a reasoning target. The official DeepSeek repo is real and widely converted into GGUF builds for local use. Hugging Face shows many community GGUF versions of that model, including **Q4\_K\_M** , **Q5** , **Q6** , and **Q8** style variants. That is why people even discuss running it locally at all. ([Hugging Face](https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Qwen-14B "deepseek-ai/DeepSeek-R1-Distill-Qwen-14B")) But 14B is where your laptop starts paying for every compromise at once: - RAM pressure - shared-memory pressure from the iGPU - slower prompt ingestion - longer generation latency - more backend fragility if you try to force NPU participation. ([intel.com](https://www.intel.com/content/www/us/en/products/sku/237328/intel-core-ultra-5-processor-135u-12m-cache-up-to-4-40-ghz/specifications.html "Intel® Core™ Ultra 5 Processor 135U")) That is why my recommendation is not “14B is impossible.” It is: > **14B is possible, but it is not the cleanest first target on a 135U.** ([Hugging Face](https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF "bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF")) ## 3. The direct answer to IPEX-LLM vs OpenVINO ### OpenVINO This is the better **long-term** stack. OpenVINO is active, supports **CPU** , **GPU** , and **NPU** , and Intel is clearly steering local AI tooling in that direction. Intel’s own 2025.4 announcement highlights **GGUF support** , a preview **OpenVINO backend for llama.cpp/Ollama-style workflows** , and broader local AI guidance for Intel client hardware. ([GitHub](https://github.com/openvinotoolkit/openvino "OpenVINO™ is an open source toolkit for optimizing and ...")) OpenVINO’s own supported-model pages also say that **similar architectures may work even if not explicitly validated** , which is useful, but it is not the same as saying every new model family is already polished on every device path. ([openvinotoolkit.github.io](https://openvinotoolkit.github.io/openvino.genai/docs/supported-models/ "Supported Models | OpenVINO GenAI")) ### IPEX-LLM This is the worse **long-term** stack because the repo is now **archived** and read-only. GitHub shows it was archived on **January 28, 2026**. That does not erase the fact that it can still run models. It does mean I would not build a long-term plan around it if I had another option. ([GitHub](https://github.com/intel/ipex-llm "intel/ipex-llm: Accelerate local LLM inference and ...")) ### So which one for your exact question? If the question is specifically: > **OpenVINO NPU-offload for 14B right now, or IPEX-LLM iGPU hybrid right now?** Then my answer is: > **Use the iGPU/CPU route for 14B. Do not make NPU-offload the main plan.** ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes")) But there is a second layer: > **Do not over-invest in IPEX-LLM as your long-term foundation, because it is archived.** > If you can use a more general **llama.cpp/GGUF** path or an **OpenVINO CPU/GPU** path instead, that is strategically cleaner. ([GitHub](https://github.com/intel/ipex-llm "intel/ipex-llm: Accelerate local LLM inference and ...")) ## 4. Is OpenVINO NPU-offload mature enough for 14B on your chip? My answer is **no, not as the primary first-attempt path on a 135U**. There are several reasons. ### Reason 1: Intel’s own NPU precision caveat on Series 1 OpenVINO’s release notes say that **NF4-FP16** became the recommended precision for models like **deepseek-r1-distill-qwen-14b** , but they also explicitly say that **this quantization is not supported on Intel Core Ultra Series 1** , where only **symmetrically quantized channel-wise or group-wise INT4-FP16** models are supported. Your **135U is Core Ultra Series 1**. That is a major limitation for the exact path you are asking about. ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes")) ### Reason 2: OpenVINO’s verified-model story is stronger for smaller models OpenVINO’s verified-model matrix validates **DeepSeek-R1-Distill-Qwen-14B** for **CPU** and **CPU+GPU** depending precision, but the clearer NPU-verified paths are on smaller models like **DeepSeek-R1-Distill-Qwen-7B** , **Qwen3-8B INT4** , and **Phi-4-mini-reasoning INT4**. That is a strong signal about what the stack considers comfortable today. ### Reason 3: NPU path still has visible real-world edge cases OpenVINO GenAI issues include things like **garbled output** when pushing NPU settings too far and **driver exceptions** with NPU model runs. That does not mean NPU is unusable. It means I would not choose it as the primary stress point for a **first** local 14B experiment on a modest laptop. ### Reason 4: OpenVINO’s own NPU guide still describes special behavior The NPU guide documents NPU-specific behavior and setup differences, and Intel’s recent release activity is still adding important NPU features. That is consistent with a stack that is improving quickly, but still not the one I would bet your first success on for 14B. ([OpenVINO Document](https://docs.openvino.ai/2026/openvino-workflow-generative/inference-with-genai/inference-with-genai-on-npu.html "OpenVINO GenAI on NPU")) ## 5. What I would actually run first ### Best “first attempt” model I would start with **Qwen3-8B** or **Phi-4-mini-reasoning**. Why: - **Qwen3-8B** is a current model family with strong reasoning, instruction following, and multilingual support. ([Hugging Face](https://huggingface.co/Qwen/Qwen3-8B "Qwen/Qwen3-8B")) - **Phi-4-mini-reasoning** is explicitly a lightweight reasoning model with **128K context** and is built for constrained environments. ([Hugging Face](https://huggingface.co/microsoft/Phi-4-mini-reasoning "microsoft/Phi-4-mini-reasoning")) - OpenVINO validates **Qwen3-8B INT4** and **Phi-4-mini-reasoning INT4** across **CPU/GPU/NPU** paths, which makes them much safer first steps on Intel hardware than 14B. ### Best DeepSeek-family first attempt If you specifically want the DeepSeek R1 style, I would start with **DeepSeek-R1-Distill-Qwen-7B** , not 14B. Intel’s IPEX-LLM NPU quickstart explicitly names the **1.5B** and **7B** DeepSeek distills as verified examples on Meteor Lake / Lunar Lake / Arrow Lake NPU setups. That is much closer to your machine and much more comforting than jumping straight to 14B. ### When to try 14B After you already have one working install and one known-good benchmark path. Then try **DeepSeek-R1-Distill-Qwen-14B** in **GGUF** form with a conservative quantization such as a **Q4-class build**. The GGUF ecosystem for that model is mature enough that you will not be inventing the wheel. ([Hugging Face](https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF "bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF")) ## 6. My specific recommendation ladder ### Option A. Most sensible overall - **Backend:** OpenVINO as your long-term stack - **Actual first run:** CPU/GPU path, not NPU-first - **Model:** **Qwen3-8B** or **Phi-4-mini-reasoning** This is the cleanest combination of support, quality, and chance of success. ### Option B. If you really want DeepSeek - **Backend:** llama.cpp-style **GGUF** path with CPU + iGPU help - **Model:** **DeepSeek-R1-Distill-Qwen-7B** first, then **14B** This stays aligned with your reasoning interest without making the hardest possible first choice. ([Hugging Face](https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF "bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF")) ### Option C. If you insist on 14B first - **Backend choice:** choose **CPU + iGPU** , not NPU-offload - **Model:** **DeepSeek-R1-Distill-Qwen-14B GGUF** - **Expectation:** usable, but not fast, and more fragile if you push context too hard. ([Hugging Face](https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF "bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF")) ## 7. What about Windows Voice Access and Task Manager showing GPU usage? Your observation is plausible, but it needs careful wording. Microsoft’s Voice Access docs say setup downloads **language files for on-device speech recognition** , and Microsoft says Voice Access can be used **without an internet connection** after setup. That means there is indeed a **local speech model** involved. ([Microsoft support](https://support.microsoft.com/en-us/topic/set-up-voice-access-9fc44e29-12bf-4d86-bc4e-e9bb69df9a0e "Set up voice access")) Separately, Microsoft documents **Windows Studio Effects** as using AI on supported devices with a compatible **NPU** for things like **Voice Focus** , background blur, and camera/microphone effects. Intel’s 135U spec page also says your chip supports **Windows Studio Effects**. ([Microsoft Learn](https://learn.microsoft.com/en-us/windows/apps/develop/windows-integration/studio-effects "Windows Studio Effects Overview - Windows apps")) So the practical reading is: - **Voice Access itself** is an **on-device speech recognition** feature. ([Microsoft support](https://support.microsoft.com/en-us/topic/set-up-voice-access-9fc44e29-12bf-4d86-bc4e-e9bb69df9a0e "Set up voice access")) - **Windows audio/video AI features** may also use AI hardware, especially the **NPU** for Studio Effects on supported systems. ([Microsoft Learn](https://learn.microsoft.com/en-us/windows/apps/develop/windows-integration/studio-effects "Windows Studio Effects Overview - Windows apps")) - **Task Manager GPU activity** does **not** prove that Voice Access alone is using the GPU in that moment. It may reflect the desktop compositor, browsers, media pipelines, other Windows AI components, or a combination. That exact attribution is not something Microsoft documents in the Voice Access pages I found. ([Microsoft support](https://support.microsoft.com/en-us/topic/set-up-voice-access-9fc44e29-12bf-4d86-bc4e-e9bb69df9a0e "Set up voice access")) The practical advice is simple: > When benchmarking local LLMs, close or reduce other AI-heavy or media-heavy Windows features and apps so the shared GPU/power budget is not noisy. ([intel.com](https://www.intel.com/content/www/us/en/products/sku/237328/intel-core-ultra-5-processor-135u-12m-cache-up-to-4-40-ghz/specifications.html "Intel® Core™ Ultra 5 Processor 135U")) ## 8. General advice for a first attempt ### Start with one clean success, not the “best theoretical” setup Do **not** make your first attempt a three-variable experiment with: - a new model family - a preview backend - NPU offload - and a 14B reasoning model That is how beginners waste a weekend and learn nothing useful. The right sequence is: 1. get **one smaller model** working 2. confirm the backend 3. benchmark prompt + generation speed 4. only then move to 14B. This is a recommendation synthesized from Intel’s backend maturity signals, model validation patterns, and the known NPU edge cases above. ### Prefer model sizes that match the machine For your laptop, the good local tier is roughly: - **1B–4B:** easy, fast, educational - **7B–8B:** best balance - **12B–14B:** stretch tier - **24B+:** not the right target for this machine as a daily driver. That conclusion follows from your hardware specs and the current validated-model landscape. ([intel.com](https://www.intel.com/content/www/us/en/products/sku/237328/intel-core-ultra-5-processor-135u-12m-cache-up-to-4-40-ghz/specifications.html "Intel® Core™ Ultra 5 Processor 135U")) ### Treat NPU as a bonus, not the core path On your machine, the NPU is useful, but its current limitations and model-specific caveats make it a poor first point of dependence for 14B reasoning models. CPU/GPU first is the saner posture. ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes")) ### Use current stacks, but do not confuse “current” with “mature” OpenVINO is current. That is good. OpenVINO NPU-offload for **your** exact 14B case is not yet something I would call fully settled. That is the distinction that matters. ([OpenVINO Document](https://docs.openvino.ai/2026/openvino-workflow-generative/inference-with-genai/inference-with-genai-on-npu.html "OpenVINO GenAI on NPU")) ## 9. Final answer My final recommendation is: 1. **Do not use OpenVINO NPU-offload as the main plan for DeepSeek-R1-Distill-Qwen-14B on a Core Ultra 5 135U.** ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes")) 2. **For 14B today, use a CPU + iGPU / GGUF path first.** ([Hugging Face](https://huggingface.co/bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF "bartowski/DeepSeek-R1-Distill-Qwen-14B-GGUF")) 3. **Do not make IPEX-LLM your long-term foundation, because it is archived.** ([GitHub](https://github.com/intel/ipex-llm "intel/ipex-llm: Accelerate local LLM inference and ...")) 4. **Best first models:** **Qwen3-8B** , **Phi-4-mini-reasoning** , or **DeepSeek-R1-Distill-Qwen-7B**. ([Hugging Face](https://huggingface.co/Qwen/Qwen3-8B "Qwen/Qwen3-8B")) 5. **Best first backend posture:** **OpenVINO overall, but CPU/GPU first; NPU later.** ([GitHub](https://github.com/openvinotoolkit/openvino "OpenVINO™ is an open source toolkit for optimizing and ...")) So, in one sentence: > **Use OpenVINO as the ecosystem you learn, but use CPU/GPU as the path you trust first. Start with 7B–8B, not 14B, and treat 14B NPU-offload as a later experiment rather than your first build.** ([OpenVINO Document](https://docs.openvino.ai/2025/about-openvino/release-notes-openvino.html "OpenVINO Release Notes"))