GTX 1080 Ti and Tesla P40 After CUDA 13 Dropped Pascal

Short answer: your Pascal card still runs local models today, but only on a CUDA 12 build. Ollama's release archive ships a CUDA v12 runner and a CUDA v13 runner side by side and picks the right one at load time, so stock Ollama still covers a GTX 1080 Ti or Tesla P40. llama.cpp still publishes a Windows CUDA 12.4 binary alongside its 13.3 and 13.4 ones — and that 12.4 build is the one that includes compute capability 6.1. Anything compiled against CUDA 13 drops Maxwell, Pascal and Volta.

And if you own a GTX 1660 or an RTX 2060: you are not affected at all. Those are Turing, compute 7.5, on the supported side of the cut. The title of this page names them because that is what people search — the honest answer is that the cliff is one generation older than most of the panic assumes.

---

The Short Version

Five sentences, then the detail. CUDA 13 dropped pre-Turing architectures. Ollama and llama.cpp both still build a CUDA 12 path that explicitly includes compute 6.1, and both shipped those builds in releases dated mid-August 2026. So nothing is broken right now. What changed is the direction of travel: every project that moves to a CUDA 13-only toolchain loses Pascal automatically, without anyone having to announce a deprecation. Your job is to know which binary you are running and to stop auto-updating blind.

---

Which Cards Are Actually Affected

The line is drawn at Turing (compute capability 7.5). Everything below it is on the wrong side. Ollama's hardware-support doc publishes a compute-capability table; here is the part that matters, with the CUDA 13 status added.

Source: Ollama hardware support doc, read 18 August 2026.

Three practical notes on that table:

• The GTX 16-series is Turing, not Pascal. The 1650, 1650 Ti, 1660, 1660 Super and 1660 Ti are TU-series silicon at compute 7.5. They keep working. If you searched "best llm for gtx 1650" and landed here worried, stop worrying — worry about the 4GB of VRAM instead, which is the real constraint. Our VRAM calculator will tell you what fits.
• The P102-100 and other mining-market Pascal cards are GP102 derivatives, the same family as the 1080 Ti and P40, so they sit in the 6.1 bucket even though no vendor table lists them by name.
• Tesla P40 owners are the most exposed group — 24GB is exactly why people bought them for local LLMs, and 24GB is exactly what you cannot cheaply replace on the supported side of the line. Our Tesla P40 guide covers the card itself; this page is the toolchain footnote it needs.

---

What CUDA 13 Removed

NVIDIA did not publish one big "Pascal is dead" banner — the removal shows up library by library in the CUDA 13.x release notes. The cuFFT section states support was "Removed... for Maxwell, Pascal, and Volta GPUs, corresponding to compute capabilities earlier than Turing." cuSPARSE carries the same note, phrased as dropping support for pre-Turing architectures. Read across the notes and Turing is the effective floor for CUDA 13.x.

The cleaner evidence, honestly, is in what downstream projects do about it. llama.cpp's CUDA backend encodes the rule directly in ggml/src/ggml-cuda/CMakeLists.txt:

if (CUDAToolkit_VERSION VERSION_LESS "13")
    list(APPEND CMAKE_CUDA_ARCHITECTURES 50-virtual 61-virtual 70-virtual)
endif ()

list(APPEND CMAKE_CUDA_ARCHITECTURES 75-virtual 80-virtual 86-real)

That is the whole story in five lines. Maxwell (50), Pascal (61) and Volta (70) are appended only when the toolkit is older than 13. Build the same source tree against CUDA 13 and those three architectures vanish from the binary, with no error and no warning — you find out when the runtime says no kernel image is available for your device.

Two details worth internalising:

• The Pascal entry is 61-virtual, meaning PTX only. Your card gets JIT-compiled code on first load rather than pre-baked SASS. That is a one-time startup delay per binary (cached under ~/.nv/ComputeCache), not a per-token penalty — but it is why a first ollama run on a Pascal box can feel oddly slow.
• The comment above that block notes 61 == Pascal, __dp4a instruction (per-byte integer dot product). That instruction is precisely why Pascal is still usable for quantised inference: the int8 dot-product path exists. What Pascal lacks is fast FP16 throughput, which is why FP16 workloads on these cards have always been miserable and why you should stay on Q4/Q5 quants. Our CUDA optimization notes go deeper on that.

---

Ollama: Still Fine, For Now

Ollama v0.32.14 (15 August 2026) still builds and ships a CUDA v12 runner that includes compute 6.1. You can see it in the project's own Dockerfile, which has separate llama-server-cuda_v12 and llama-server-cuda_v13 build stages and copies both into the release archive alongside the CPU, Vulkan and MLX runners:

COPY --from=llama-server-cpu      dist/lib/ollama /lib/ollama/
COPY --from=llama-server-cuda_v12 dist/lib/ollama /lib/ollama/
COPY --from=llama-server-cuda_v13 dist/lib/ollama /lib/ollama/
COPY --from=llama-server-vulkan   dist/lib/ollama /lib/ollama/

The two CUDA stages have different architecture lists in llama/server/CMakePresets.json:

Note the v12 Linux preset builds 60 and 61 as real device code, not just PTX — so on Linux, Ollama gives Pascal a better deal than a stock llama.cpp release does. The v13 presets start at 75. Turing is the floor, exactly as expected.

The driver requirement is the thing people miss. Ollama's doc: compute capability 5.0+ and driver 550 or newer in general, but "Nvidia GPUs with compute capability 5.0 through 6.2 require driver version 570 or newer." If your Pascal box is sitting on an older driver because it has been stable for two years, that is the upgrade to make before anything else. Verify with:

nvidia-smi --query-gpu=name,compute_cap,driver_version,memory.total --format=csv

If that prints 6.1 in the compute_cap column, you are in the affected group and you want driver 570+. If it prints 7.5 or higher, close this tab and go read something more useful, like what actually fits in your VRAM.

How long does this last? We are not going to invent a date. Ollama has published no Pascal end-of-life notice we could find, and the CUDA v12 stage is still in main today. What we can say with confidence is the mechanism: the day the CUDA v12 stage is deleted from that Dockerfile, Pascal support disappears from the next release with no other announcement. That single file is the thing to watch.

---

llama.cpp: Pick the Right Download

Windows Pascal users want the cuda-12.4 asset, not the cuda-13.3 one. Release b10472 (17 August 2026) published these, among others:

Two things follow from that list.

First, there is no prebuilt CUDA binary for Linux in llama.cpp releases. Linux Pascal owners have three options: run Ollama (which does ship a CUDA v12 runner), run the Vulkan build, or compile llama.cpp yourself against a CUDA 12.x toolkit. If you build it, be explicit rather than trusting the default:

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES="61"
cmake --build build --config Release -j $(nproc)

That fails outright if nvcc is from CUDA 13 — which is the failure you want, because it tells you at build time instead of at inference time. Check first with nvcc --version.

Second, the CUDA 12.4 assets are two downloads, not one. Grab the runtime DLL zip as well or the binaries will not start.

---

The Vulkan Escape Hatch

Vulkan removes the CUDA version question entirely, and both projects now ship it by default — but we have not measured the speed cost on Pascal, so we are not going to quote one.

What is verifiable:

• Ollama's doc says Vulkan support covers Windows and Linux and is "enabled by default when the backend is installed", with most Windows GPU drivers bundling Vulkan already and most Linux distributions needing extra packages (Mesa or vendor-specific).
• llama.cpp publishes Vulkan binaries for Windows x64 and Ubuntu x64/arm64 in every release.
• Ollama warns that Vulkan needs extra capabilities or root to read free VRAM; without that the scheduler uses approximate model sizes to decide what fits, which is a real source of surprise offloading. On Linux the fix is sudo setcap cap_perfmon+ep /usr/local/bin/ollama.
• You can turn it off with OLLAMA_VULKAN=0, or select devices with GGML_VK_VISIBLE_DEVICES.

What we cannot tell you honestly is the tokens-per-second delta versus the CUDA 12 path on a 1080 Ti or a P40, because we do not have those cards in the bench. Anyone quoting you a precise percentage for Pascal-on-Vulkan without naming the card, the quant and the context length is guessing. Measure it yourself — same model, same quant, same prompt, once with the CUDA runner and once with OLLAMA_VULKAN=1 and CUDA disabled — and trust your own number.

---

Check Before You Update

Run these four commands before you touch a working Pascal box. They take a minute and they tell you exactly where you stand.

# 1. What architecture and driver do you actually have?
nvidia-smi --query-gpu=name,compute_cap,driver_version --format=csv

# 2. Which CUDA toolkit would a source build use?
nvcc --version

# 3. Is Ollama really on the GPU, or has it quietly fallen back to CPU?
ollama ps

# 4. Which runner did it load? (Linux/macOS; check the service log on Windows)
journalctl -u ollama --no-pager | grep -i -E "cuda|vulkan|rocm|library"

Read them like this:

• compute_cap of 6.1 or lower → affected. Driver must be 570+ for Ollama.
• ollama ps showing 100% CPU on a machine with a working GPU is the classic symptom of a missing or mismatched runner. Our Ollama troubleshooting guide walks the full decision tree for that.
• If you see no kernel image is available for execution on the device anywhere in the logs, that is the exact error string for "this binary was not built for your architecture". On a Pascal card in 2026 it almost always means you are running a CUDA 13 build. Swap to the CUDA 12 asset.

And the boring but real advice: pin your versions. Note the Ollama version and the llama.cpp build number that work, keep the installer, and read release notes before upgrading. On a supported card, auto-update is fine. On a card one architecture below the support floor, auto-update is how a working machine becomes a broken one overnight.

---

The Cheapest Supported Upgrade

Anything Turing or newer — compute 7.5 and up — is on the supported side, and the first card that is both supported and genuinely useful for LLMs is the RTX 3060 12GB.

We are deliberately not printing prices. Used-GPU pricing moves weekly, varies enormously by region, and the wider market has been distorted by the memory shortage — see why GPU prices are up for that context. What does not move is the capability map:

If you are shopping, read our used GPU buying guide with the architecture column in mind, and check what actually fits before you buy: best models for 12GB VRAM and best models for 24GB VRAM are the two tiers most of this decision comes down to.

The blunt verdict. A 1080 Ti or a P40 is still a working local-AI card in August 2026, and if the machine is stable, leave it alone and enjoy it. Just do not buy one expecting three more years of toolchain updates, and do not let an unattended package upgrade decide your architecture support for you. When it is time to move, move to Turing or later once, rather than to another card that is already a generation behind the floor.

---

Sources

• NVIDIA CUDA Toolkit Release Notes — pre-Turing removal recorded per-library (cuFFT, cuSPARSE) in the CUDA 13.x notes; latest documented version at time of writing was 13.3 Update 1
• ggml-org/llama.cpp — ggml/src/ggml-cuda/CMakeLists.txt architecture logic and release b10472 assets (17 August 2026)
• ollama/ollama — docs/gpu.mdx compute-capability and driver table, llama/server/CMakePresets.json architecture presets, Dockerfile build stages; release v0.32.14 (15 August 2026)
• All repository files and release assets were read directly from the projects' default branches on 18 August 2026. Version-dependent details change fast — re-check before acting on them.

---

FAQ