dashAI ships CPU-only desktop installers and an AVX2 floor you can trip over

The installers need AVX2, and the failure is an illegal instruction

The requirements table has two columns, one for the desktop installers and one for a PyPI or source install, and the CPU row is where they diverge in a way that can cost you an afternoon. The installers require x86_64 with AVX2, described as Intel Haswell 2013 or newer and AMD Excavator or Zen+, or Apple Silicon. The PyPI route needs x86_64 or Apple Silicon with AVX2 not required.

The note explaining why is the most useful paragraph in the file. The installers ship with CPU-only PyTorch and `llama-cpp-python`, and both contain native libraries compiled for AVX2, PyTorch itself and the `libggml` inside llama-cpp. On older hardware, whichever of those two is imported first kills the process with `Illegal instruction`.

That phrasing is doing real work. There is no friendly error, no capability check, no message naming the instruction set. You get a crash at import time and you work out the cause yourself.

The suggested fix is to clone the repository and install from source, because that path pulls wheels which run on older CPUs. The documentation is honest that it may still fail on a very old CPU and recommends trying anyway.

The default branch is production, and the README is reStructuredText

Small repository facts that tell you what kind of project this is. The default branch is `production`, not `main`, and the README file is `README.rst` with `CHANGELOG.rst` and `CONTRIBUTING.rst` beside it, written as reStructuredText with `.. image::` directives and `.. code::` blocks rather than Markdown. A documentation site is served from the same repository, given the presence of a `CNAME` file and a `docs/` directory.

The packaging is thorough. `dashai.spec` is a PyInstaller specification, `appimage/` and `installer/` hold the Linux and installer build inputs, and there are two Dockerfiles, a general one and `Dockerfile.cuda`. `alembic.ini` means database schema migrations, and `.dvc/` with `dvc.yaml` means data is versioned with DVC alongside the code, which is the right call for a toolbox whose inputs are datasets.

`tsconfig.json` and the frontend build inside the container tell you the interface is not Python, and `hooks/` with `.git-hooks/` and a pre-commit config say the repository enforces its own conventions before a commit lands.

uv tool install is the one-liner, and the GPU is a separate decision

The PyPI route is presented in three steps, and the third is the one that matters. Step one creates an isolated environment, and four variants are given: `uv venv --python 3.12`, plain `python3 -m venv .venv`, the PowerShell equivalent on Windows, and a conda environment created with `conda create -n dashai python=3.12`. Step two installs the package, with `uv pip install dashai` and `pip install dashai` as equivalents.

There is also a shortcut above the steps for the common case. `uv tool install dashai` puts a `dashai` command on your PATH in one line, in its own isolated environment, with the default PyTorch build for your platform. The documentation says to follow the longer path instead when you want GPU acceleration, a CPU-slim install, or GGUF model support.

Step three is the optional one, and it is where the hardware choice happens. Installing dashAI already brings in a working PyTorch, so on CPU nothing is needed. Reinstalling from a different index is how you switch: the CPU index for a smaller install, because the default PyTorch wheel on Linux ships the large CUDA build, cu128 for NVIDIA, and rocm6.4 for AMD. Every command in that step also works as `uv pip install` with the same flags.

llama-cpp-python is never installed automatically, and only the CPU wheel skips build tools

Running GGUF models inside the app, so Llama, Mistral, Qwen and similar, needs `llama-cpp-python`, and the documentation is explicit that it is never installed automatically. You add it in the third step if you want it.

The three variants of that one command show the cost curve better than any explanation. For CPU there is a precompiled wheel on a dedicated extra index, with the note that it needs no build tools:

$ pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu --force-reinstall --no-cache-dir

For NVIDIA it becomes a source build with a CMake argument, `-C cmake.args="-DGGML_CUDA=on"`, and the flags `--force-reinstall --no-cache-dir --verbose`, with a note that build tools are required. AMD is the same shape with `-DGGML_HIP=on`. So a GPU user with GGUF models needs a compiler toolchain on the machine, and a CPU user does not, and that asymmetry is the practical difference between the two paths.

The torch command sits next to it and is the same idea in simpler form, reinstalling `torch torchvision` from the matching index.

pip is a declared dependency because the app installs plugins with it

The dependency list contains a line that looks wrong until you read its comment: `pip>=22.2` is a runtime requirement, not a build requirement. The explanation is that plugins are installed at runtime by invoking `sys.executable -m pip`, and that a uv-managed virtual environment ships no pip while a bundled build has no interpreter to bootstrap one, so pip has to be a real dependency. The version floor is explained too: 22.2 is the first release with `pip install --report`.

That is a design decision with consequences. The application modifies its own Python environment at runtime, which means the install story is not finished when `pip install dashai` returns. It also means an air-gapped or locked-down machine needs its own package source configured before the plugin dialog will work, and the 22.2 floor exists because the app wants a machine-readable install report rather than parsing log output.

Everything else in the list is a normal scientific Python surface: FastAPI with all extras, SQLAlchemy and alembic, pandas, scikit-learn, datasets, diffusers, transformers 5 or newer, sentence-transformers, evaluate, accelerate, optuna with cmaes and hyperopt for search, plotly and shap for inspection, sacrebleu for text metrics, and opencv-python and Pillow for images.

The container syncs the CPU extra, runs as --no-browser, and binds 0.0.0.0

The Dockerfile is two stages and short enough to hold in your head. Stage one is `node:22-alpine`, which enables corepack and runs `yarn install --frozen-lockfile` followed by a build of the frontend, producing static assets. Stage two is `python:3.11-slim`, copies the uv binary from its own registry image at version 0.11, copies the repository, copies the built frontend in, and runs `uv sync --locked --extra cpu --no-dev --no-cache`.

Three details in those last lines decide how the container behaves. The `--extra cpu` flag means the image you build by default has no GPU support, so a CUDA deployment is a different command, and there is a separate `Dockerfile.cuda` for it. `--no-browser` is the entrypoint, so the container does not try to open a window on a machine that has none. And `DASHAI_HOST=0.0.0.0` with port 8000 exposed means the server inside the container listens on every interface, which is what you want for a published container and something to be deliberate about on a shared host.

There is also a `docker-compose.demo.yml` at the root, which is a useful hint that a demo deployment is a supported shape rather than an afterthought.

Three dependency ceilings exist because upstream broke, and the comments say which

A resolver cap in a dependency list is a scar, and this one has the comments attached. `arviz<1.0.0` is there because pymc still imports the pre-1.0 arviz API, including `InferenceData` and `concat`, while pymc's own metadata declares no upper bound, so the cap has to be applied here. Without it, an unpinned resolve picks a newer arviz and the import fails at runtime rather than at install time.

Two other ceilings are uncommented but equally informative. `pandas<3.0.0` and `scikit-learn<1.8.0` are both major-version guards on libraries that changed APIs, while `transformers>=5.0.0` is a floor, which tells you the project has moved to the 5.x line rather than merely tolerating it. `setuptools` is bounded on both ends at `>=65.0.0,<82`.

That is a project doing dependency management deliberately, which is a better signal than the absence of pins would be. The version story is a plain sequence: v0.9.7.post1 on 2026-08-07, v0.9.7.post2 on 2026-08-12, and v0.10.0 on 2026-09-25, which matches the `version = "0.10.0"` in the packaging metadata. Licence is MIT, the default branch is `production`, and the last push to the repository was 2026-09-30.

Editorial conclusion

Adopt dashAI if you want a graphical path to fine-tuning and evaluation without assembling a Python environment, and if your hardware is a CPU from 2013 or later or Apple Silicon, since that is the documented floor for the installers. Do not adopt the installer on an Intel Mac, because there is no build, and do not expect the installer to reach a GPU, since NVIDIA and AMD acceleration both require the pip route and a second PyTorch install. Verify three things first: whether your CPU has AVX2, because the bundled PyTorch and llama-cpp native libraries are compiled for it and the process dies with `Illegal instruction` otherwise, that glibc is 2.35 or newer and FUSE 2 is present if you take the Linux AppImage, and whether your air-gapped setup can tolerate an app that installs plugins by shelling out to pip at runtime. Licence is MIT, v0.10.0 shipped on 2026-09-25, and the last push was 2026-09-30.

Frequently asked questions

Official sources

1. DashAISoftware/dashAI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases