# How to Troubleshoot Mixed NVIDIA Package Versions in uv pip list Output

> Troubleshoot mixed NVIDIA package versions in uv pip list output by clearing cache, deleting lock files, and resyncing with proper CUDA extras. Resolve stale wheel metadata issues.

- Repository: [Th3Unknovvn/uv-install-torch](https://github.com/baonguyen6742/uv-install-torch)
- Tags: how-to-guide
- Published: 2026-02-26

---

**Clear the uv cache, delete `uv.lock` and `.venv`, then run `uv sync --extra cu124` to resolve mixed NVIDIA package versions caused by stale wheel metadata when switching between CPU and CUDA PyTorch extras.**

When managing PyTorch installations with Astral's uv package manager, switching between CPU-only and CUDA-enabled extras can leave your environment in an inconsistent state. The **baonguyen6742/uv-install-torch** repository demonstrates how optional dependencies and index-specific sources configured in [`pyproject.toml`](https://github.com/baonguyen6742/uv-install-torch/blob/main/pyproject.toml) lead to mixed NVIDIA package versions appearing in `uv pip list`. This guide extracts the exact remediation steps from the repository's source code to restore a clean, CUDA-compatible environment.

## Understanding the Root Cause

Mixed NVIDIA package versions typically occur when `uv` resolves dependencies using cached metadata from a previous installation with a different **extra** (e.g., `cpu` instead of `cu124`).

### Extra-Aware Index Selection

In the repository's [`pyproject.toml`](https://github.com/baonguyen6742/uv-install-torch/blob/main/pyproject.toml), torch-related packages are defined as optional dependencies tied to specific PyPI indexes:

```toml
[project.optional-dependencies]
cpu = ["torch==2.4.1", "torchvision==0.19.1", "torchaudio==2.4.1"]
cu124 = ["torch==2.4.1", "torchvision==0.19.1", "torchaudio==2.4.1"]

[tool.uv.sources]
torch = [
  { index = "pytorch-cpu", extra = "cpu" },
  { index = "pytorch-cu124", extra = "cu124" },
]

```

When you run `uv sync --extra cu124`, uv pulls CUDA-enabled wheels from the `pytorch-cu124` index. However, transitive dependencies like `nvidia-cublas-cu12` are not part of the extra definition and are pulled from the default PyPI source. If a previous `cpu` extra installation left cached wheels or lock file references, uv may reuse CPU-only torch wheels while still installing CUDA-specific NVIDIA packages, creating a hybrid environment.

### Cache Reuse and Lock File Stalemates

**uv** caches wheels globally to speed up repeated installations. If you previously synced with `--extra cpu`, the CPU-only torch wheel remains in the cache. Subsequent attempts to sync with `--extra cu124` may reference the stale lock file or cache entries, causing uv to install `torch` compiled for CPU alongside `nvidia-cublas-cu12` and `nvidia-cudnn-cu12` wheels intended for CUDA 12.4.

## Identifying Mixed Version Symptoms

The conflict manifests in `uv pip list` output showing NVIDIA packages (e.g., `nvidia-cublas-cu12`, `nvidia-cudnn-cu12`) alongside a `torch` package lacking CUDA suffixes. Runtime errors include:

- `torch.cuda.is_available()` returning `False` despite CUDA drivers being installed
- Import failures or undefined symbol errors when importing `torch`
- Version mismatches where the torch wheel reports `2.4.1+cpu` while NVIDIA packages report `cu12` suffixes

## Step-by-Step Resolution

Follow the remediation protocol documented in the repository's [`README.md`](https://github.com/baonguyen6742/uv-install-torch/blob/main/README.md) (lines 101-106) to purge stale state and force a clean resolution.

### 1. Clear the Package Cache

Remove stale wheel files that could be reused mistakenly:

```bash

# Clear all unused cached wheels

uv cache prune

# Or target only torch-related artifacts

uv cache clean torch

```

### 2. Delete Lock File and Virtual Environment

Force `uv sync` to resolve the dependency graph from scratch, guaranteeing that only the selected extra is installed:

```bash
rm -f uv.lock
rm -rf .venv

```

### 3. Re-install the Torch Stack

Invoke `uv sync` with the correct CUDA extra to pull wheels exclusively from the `pytorch-cu124` index:

```bash
uv sync --extra cu124

```

If leftover packages persist, force an explicit uninstall before syncing:

```bash
uv pip uninstall -y torch torchvision torchaudio
uv sync --extra cu124

```

### 4. Verify CUDA Compatibility

Confirm the environment contains only CUDA-compatible packages:

```bash
uv pip list | grep -E 'torch|cuda|nvidia'

```

Run a Python sanity check to validate CUDA availability:

```bash
uv run python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

```

Expected output: `2.4.1+cu124 True`.

## Distinguishing Normal from Problematic NVIDIA Packages

After a clean reinstall, seeing `nvidia-cublas-cu12`, `nvidia-cudnn-cu12`, and similar packages is normal. These are legitimate transitive dependencies of the CUDA-enabled torch wheel and should all share the same CUDA version suffix (e.g., `cu12`).

**Mismatched versions**—such as `nvidia-cublas-cu11` alongside `torch==2.4.1+cu124`—indicate that the wrong index was consulted or remnants of a previous installation remain. Similarly, if `torch` reports a `+cpu` build tag while NVIDIA packages are present, the mixed state persists and requires repeating the cache clearing steps.

## Summary

- **Clear the uv cache** using `uv cache prune` to remove stale CPU-only wheels that contaminate CUDA installations.
- **Regenerate lock files** by deleting `uv.lock` and `.venv` to force a fresh dependency resolution for the target extra.
- **Use explicit extras** (`--extra cu124` or `--extra cpu`) to ensure `uv` selects wheels from the correct index defined in [`pyproject.toml`](https://github.com/baonguyen6742/uv-install-torch/blob/main/pyproject.toml).
- **Verify with `torch.cuda.is_available()`** to confirm the runtime environment matches the expected CUDA version.

## Frequently Asked Questions

### Why do I see NVIDIA packages after installing the CPU extra?

NVIDIA packages should not appear when using `--extra cpu`. If they do, a previous CUDA installation left artifacts in the cache or lock file. Run `uv cache clean` and delete `uv.lock` to remove these remnants, then resync with `--extra cpu`.

### Is it safe to delete the `uv.lock` file and `.venv` directory?

Yes. `uv.lock` is a generated file that locks resolved dependency versions, and `.venv` contains the installed packages. Deleting both forces uv to re-resolve and re-download dependencies according to your current [`pyproject.toml`](https://github.com/baonguyen6742/uv-install-torch/blob/main/pyproject.toml) configuration, which is the recommended fix for mixed-version scenarios.

### Why does uv reuse cached wheels from different extras?

**uv** caches wheels globally based on package name and version, not by extra. A `torch==2.4.1` wheel cached from the CPU index appears identical to the resolver as one from the CUDA index. Without clearing the cache or lock file, uv may install the cached CPU wheel when you request the CUDA extra, leading to the mixed NVIDIA package state.

### How do I know if my NVIDIA packages are the correct version?

Run `uv pip list` and check that all `nvidia-*` packages share the same CUDA version suffix as your torch extra (e.g., `cu12` for `cu124`). Then execute `python -c "import torch; print(torch.version.cuda)"`. The output should match the CUDA version (e.g., `12.4`) associated with your installed NVIDIA packages.