Hello all
I am setting up a AI lab at home and I would like know if there is going to be a release of the optimum-intel via intel or conda forge. I do not see them there and the option is to use pip but Since I want to stick to all conda/mamba env I do not want to mix pip with this. If you know how I can install this module that will help in the learning.
thank you
seems complicated…
optimum (base Optimum) is on conda-forge. (anaconda.org)optimum-intel is documented as a pip-installed, “fast-moving” project (including install-from-source examples). (Hugging Face)pip install optimum[openvino,nncf]). (docs.openvino.ai)Intel does have a conda channel, but it’s primarily for Intel/oneAPI component packages (not an Optimum Intel distribution channel). (Intel)
I did not find an official promise or timeline. Practically, conda-forge packages happen when someone contributes/maintains a recipe via staged-recipes → feedstock. (conda-forge)
Given the frequent dependency pinning/friction visible in real issues (example below), it’s also the kind of package that tends to need active maintenance. (GitHub)
optimum-intel without “mixing pip into your env”You have two realistic paths:
Below is the strict conda-only approach first.
optimum-intel, then install via conda/mambaThis keeps your runtime env “conda-installed only.”
(You may use pip indirectly during the build step, but the resulting artifact is installed with conda.)
--use-local. (Conda Documentation)mamba create -n build-optimum-intel -c conda-forge python=3.11 conda-build grayskull
mamba activate build-optimum-intel
grayskull pypi optimum-intel
Grayskull’s purpose and scope are documented here. (conda.github.io)
conda build optimum-intel
Create your runtime env (example includes OpenVINO from conda-forge):
mamba create -n ov-lab -c conda-forge python=3.11 openvino transformers accelerate
mamba activate ov-lab
conda install --use-local optimum-intel
conda install --use-local ... is the documented way to install your newly built local package. (Conda Documentation)
Expect to sometimes edit the generated recipe (dependency names/pins). A concrete example of why: users hit dependency conflicts involving numpy constraints and other pinned packages in the Optimum Intel dependency graph. (GitHub)
If you later decide “pip in the env is acceptable as long as it’s controlled,” the safest pattern is:
This is explicitly recommended in conda’s environment management guidance. (Conda Documentation)
Use conda-forge for OpenVINO + core deps first, then:
pip install ...) (Hugging Face)--no-deps after you’ve already installed dependencies via conda (prevents pip from reshuffling versions)If you ever allow pip packages, conda-lock can lock the dependencies.pip section of an environment.yml. (conda.github.io)
optimum-intel is treated upstream as pip-first and fast-moving. (Hugging Face)If your rule is “no pip installs in the runtime env”, do Option A now:
optimum-intel once as a local conda artifact,That aligns with your constraint and avoids most “dependency resolver churn” problems that show up in real-world Optimum Intel installs. (GitHub)
thank you for the information. I will look into grayskull and see if that resolved my issue.
Hello I took option A and create the meta.yaml file. I was able to install the module but all the supporting dep were not installed since they do not exist in any of the conda channels. I will attach my file but note I had to rem out the pip install like so it would create the compress file but that also had issue.
I used google AI to assist with the troubleshooting of this since I am not able to upload the file I will post some of it here is I am allowed .
{% set version = “1.27.0” %}
package:
name: optimum-intel
version: {{ version }}
source:
url: https://pypi.org/packages/source/o/optimum-intel/optimum_intel-{{ version }}.tar.gz
sha256: 06c2b38c90912d231677118888388b8e8b073f8bd240e9e1279f48708341b3de
build:
entry_points:
requirements:
host:
- diffusers #
#- intel-extension-for-pytorch >=2.8 # moved to pip script
#- transformers >=4.45,<4.58 # version 4.45 but less than 4.58 altered rem milti entry need one only
- accelerate #
#- neural-compressor >=3.4.1 # moved to pip script
#- transformers >=4.45,<4.58 # version 4.45 but less than 4.58 alterd rem milti entry need one only
- datasets >=1.4.0,<4.0.0 # change the version to a grater than 1.4.0 version
#- nncf >=2.19.0 # rem milti entry need one only
#- openvino >=2025.4.0 # rem milti entry need one only
# - openvino-tokenizers >=2025.4.0 # rem milti entry need one only
- black >=23.1,<24.dev0
- ruff ==0.4.4 #
- pytest >=7.2.0,<8.0.0
- parameterized
- Pillow >=10.0 # prevent it from looking at older py27 versions
- evaluate
- py-cpuinfo
- sacremoses
- sentencepiece
- torchaudio
- rjieba
- timm
#- invisible-watermark >=0.2.0 Moved to pip script above
#- transformers_stream_generator Moved to pip script above
- einops
- tiktoken
- sentence-transformers
#- open_clip_torch >=2.26.1 Moved to pip script above
- peft
# - datasets >=1.4.0,<4.0.0 # rem milti entry need one only
- tbb
- langchain-huggingface
#- hf_xet Moved to pip script above
- num2words
#- vocos Moved to pip script above
#- vector_quantize_pytorch Moved to pip script above
#- openvino-genai # rem milti entry need one only
test:
imports:
about:
home: https://www.intel.com
summary: Optimum Library is an extension of the Hugging Face Transformers library, providing a framework to integrate third-party libraries from Hardware Partners and interface with their specific functionality.
license: Apache-2.0
license_file: LICENSE
extra:
recipe-maintainers:
Hmm…
conda-build does not behave like pip install optimum-intel[extras]In a conda recipe, your build script:
python -m pip install . --no-deps
intentionally installs only optimum-intel (no dependency resolution). The dependency solver is conda/mamba, and it only installs what you list under requirements: run, and only if those packages exist in your configured channels.
So if you list PyPI-only deps (or misnamed conda packages) in requirements: run, you’ll get exactly what you saw:
Your recipe includes quality/test tooling (black, ruff, pytest, etc.) and many “extras” dependencies as if they were required at runtime. On PyPI, optimum-intel advertises many optional extras (openvino, nncf, ipex, neural-compressor, diffusers, tests, quality, …). (PyPI)
In conda packaging, you generally model these as separate outputs (metapackages) or keep them out of run: and document them as optional installs.
These three are the most common “it doesn’t exist” cases because the conda package names use dashes:
| You tried | Conda(-forge) name | Evidence |
|---|---|---|
hf_xet |
hf-xet |
(Anaconda) |
vector_quantize_pytorch |
vector-quantize-pytorch |
(Anaconda) |
open_clip_torch |
open-clip-torch (available in conda ecosystem; conda-forge is referenced by maintainers) |
(GitHub) |
So if your goal was “conda-only”, a chunk of your list becomes solvable just by renaming.
optimum-onnx + a few PyPI-only packagesoptimum-intel depends on optimum-onnxA metadata view of optimum-intel shows required deps include optimum-onnx (plus torch, transformers). (pypistats.org)
And Hugging Face’s Transformers docs explicitly install Optimum ONNX via pip (uv pip install optimum-onnx) when discussing ONNX export tooling. (Hugging Face)
If optimum-onnx is not available in your conda channels, then a conda-native optimum-intel package is incomplete unless you:
optimum-onnx into conda first, oroptimum-intel to make that dependency optional (usually not recommended unless upstream supports it).OpenVINO Runtime is available via conda-forge. (docs.openvino.ai)
But OpenVINO GenAI is distributed via PyPI and archives, not conda. (docs.openvino.ai)
So if your dependency chain truly requires openvino-genai, you won’t get a “pure conda-forge solve” without creating and maintaining your own conda package for it.
For example these are clearly PyPI packages:
They might be packageable into conda (some are pure Python), but they’re not guaranteed to already exist in your channels.
If you are willing to use “conda-only” but not strictly “conda-forge-only”:
neural-compressor exists on Intel’s channel.intel-extension-for-pytorch exists on Anaconda’s main channel, but the listing shown is very old (v1.12.1 from 2023), which is unlikely to match modern PyTorch (2.x). (Anaconda)That mismatch is a common reason conda recipes “can’t solve” when you try to pin intel-extension-for-pytorch>=2.8.
You’re already halfway there.
Goal: keep your runtime installs 100% conda/mamba by packaging whatever is missing into your own channel (local directory channel), then install with -c file:///....
Priority order to package:
optimum-onnx (because it’s a required dep) (pypistats.org)transformers-stream-generator, invisible-watermark, vocos) (PyPI)optimum-intelWhy this works: conda can only solve against packages it can see. Once you provide conda artifacts (even locally), mamba can do a clean solve without pip.
optimum-intel conda-packaged, but make extras separate and optional (how conda-forge typically wants it)Model the PyPI extras as separate metapackages:
optimum-intel (base)optimum-intel-openvino (depends on optimum-intel, openvino, openvino-tokenizers, nncf, …)optimum-intel-neural-compressor (depends on optimum-intel, neural-compressor)This matches the fact that upstream documents pip extras (e.g., optimum-intel[openvino]). (GitHub)
Also note: OpenVINO Runtime itself is well supported in conda-forge. (docs.openvino.ai)
Upstream’s own install guidance for Optimum Intel is pip-first. (GitHub)
If you ever change your mind: install the heavy compiled stack via conda (torch/openvino/nncf), then pip-install only the few missing pure-Python bits last. This minimizes conflicts.
meta.yaml (so your package behaves predictably)requirements: runMove dev/test tools to test: requires (or remove entirely). Keep runtime minimal.
Replace:
hf_xet → hf-xet (Anaconda)vector_quantize_pytorch → vector-quantize-pytorch (Anaconda)open_clip_torch → open-clip-torch (GitHub)This is a key conda-forge norm: dependencies must be declared, not downloaded during build.
noarch: python is usually correct hereoptimum-intel ships as a universal wheel (py3-none-any), so it’s typically noarch. (PyPI)
If you pin Python to exactly 3.10, noarch becomes awkward—prefer python >=3.10,<3.12 style constraints instead.
entry_points if upstream already defines themLet pip install . install the console scripts from the package metadata unless you have a specific reason. (Hardcoding can drift from upstream.)
I can’t point to a public commitment or an existing conda-forge feedstock/PR for optimum-intel right now. Your Hugging Face forum thread (Jan 26, 2026) is exactly the kind of place that usually gets an authoritative answer from maintainers if one exists. (Hugging Face Forums)
Practically, the packaging blockers are consistent with what you ran into: required deps like optimum-onnx and optional deps like openvino-genai that are not clearly available on conda channels. (pypistats.org)
optimum-intel for Stable Diffusion/OpenVINO flows (good for validating your environment end-to-end). (docs.openvino.ai)optimum-onnx first (local channel). (pypistats.org)hf-xet, vector-quantize-pytorch, open-clip-torch). (Anaconda)openvino-genai as non-conda unless you commit to packaging it yourself. (docs.openvino.ai)If you do those four steps, you’ll convert your current situation from “unsatisfiable” to “mostly solvable,” and the remaining gaps will be explicit and controllable.
thank you for the detail information on how I can overcome this issue. I would like to ask what is your thinking if most of the items are Pip Installs what is the pro or cons of just moving to an All Python env and run my test there. per AI I proposed the same question and it seems Conda is c/c++ base and runs faster but since this is a learning lab. What do you think about the pip instead of conda/mamba env
This isn’t limited to virtual environments, but for AI-related backends requiring speed, the critical parts are often implemented in C/C++ or Rust rather than pure Python. The choice of virtual or physical environment likely has a limited impact on speed.
While it’s not particularly relevant here, if you’re using multiple processes extensively in Python, making the bottleneck process a local server might be the better approach…
A key point for your question about performance: the environment manager (conda vs pip) does not inherently make your code faster. Performance depends on which binary builds you install (e.g., whether NumPy/PyTorch/OpenVINO are built with specific optimizations). Wheels can contain compiled extensions too, so “pip = pure Python = slower” is not true in general. (Python Packaging)
python -m pip install --upgrade-strategy eager "optimum-intel[openvino]". (Hugging Face)pip install optimum[openvino,nncf]). (OpenVINO Document)In other words: if most of your stack is pip-first (as you’ve already discovered by trying to conda-package optimum-intel), a pip-native workflow is often the “path of least resistance” for learning.
This is the biggest practical win in your situation: Optimum Intel and several extras are published and tested primarily via pip. (Hugging Face)
optimum-intel[openvino]Extras are a pip ecosystem feature; conda does not have an identical built-in concept. When you stay in pip, the published dependency metadata is exactly what upstream expects. (Hugging Face)
Many performance-critical Python packages ship wheels with compiled code. Wheels are explicitly designed to distribute binaries and avoid recompiling during install. (Python Packaging)
OpenVINO documents pip installation and explicitly walks through using a virtual environment (venv). (OpenVINO Document)
If a package (or one of its dependencies) doesn’t provide a wheel for your OS/Python version, pip may attempt a source build, which can require compilers/system headers.
Conda can be easier in those edge cases because it can provide prebuilt binaries for many compiled dependencies.
Conda can install shared libraries and non-Python tools more directly. pip generally doesn’t, although many wheels bundle the needed shared libraries.
For example, PyTorch GPU installs via either pip or conda typically still depend on correct system drivers (e.g., NVIDIA drivers), and the binaries often ship the CUDA runtime dependencies themselves. (PyTorch Forums)
(For Intel GPU/NPU with OpenVINO, drivers are also outside the Python env.)
With pip-only, you’ll want to pin versions and use a lock strategy (requirements/lockfile tooling) so that “works today” keeps working later.
What can be true:
What is not generally true:
Why:
So, for a learning lab, speed differences from “conda vs pip” are usually not the deciding factor. The deciding factor is: how quickly can you get a working, stable stack that matches upstream docs?
Given your experience (conda recipe installs but can’t satisfy many deps from conda channels), a pip-only venv is the most practical way to:
If later you find you need:
This “use the right tool per environment” approach is common, and conda even documents pip interoperability (though it notes it’s experimental). (docs.conda.io)
This follows the same pattern OpenVINO recommends (venv + pip). (OpenVINO Document)
python -m venv .venv
# Linux/macOS:
source .venv/bin/activate
# Windows (PowerShell):
# .\.venv\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install --upgrade-strategy eager "optimum-intel[openvino]"
That last command is directly from Optimum Intel’s install docs. (Hugging Face)
For PyTorch, use the official selector and install command from pytorch.org (pip is fully supported). (PyTorch)
Use pip-only if:
Use conda/mamba if:
In your situation (Optimum Intel + many pip-only deps), I would run pip-only for the Optimum Intel/OpenVINO test environment, and keep conda/mamba as a separate tool for environments that are conda-native.