In this article
The GTX 1080 refresh 11 Gbps value is a memory data rate, not 11 GB; both variants here remain 8 GB devices.
Do not confuse Gbps with GB
The original GTX 1080 has 8 GB GDDR5X, NVIDIA listed memory data rate of 10 Gbps and board power of 180 W. NVIDIA later announced an 11 Gbps refresh; that does not make it an 11 GB GPU. GTX 1080 Ti is another identity. Power for the particular refresh board is not verified here and remains unknown. The table concerns one GPU. Preserve AIB identity and each revision’s source so a catalog parser cannot turn data rate into capacity and create an incorrect workload budget. Keep units explicit in the inventory.
| Official variant | Memory per GPU | Memory type | Board power | Evidence |
|---|---|---|---|---|
| NVIDIA GeForce GTX 1080 — Original 8 GB GDDR5X 10 Gbps | 8 GB | GDDR5X | 180 W | Specification |
| NVIDIA GeForce GTX 1080 — 8 GB GDDR5X 11 Gbps refresh | 8 GB | GDDR5X | Not verified | Specification |
Validate conditional Pascal inference
NVIDIA lists GTX 1080 CC 6.1, below the current vLLM floor of 7.5, so that backend’s support is not claimed. Choose an exact llama.cpp CUDA commit, target and bounded GGUF workload, observing actual GPU execution and offload. CUDA 13 removes pre-7.5 offline compilation, requiring a documented compatible legacy build, such as suitable CUDA 12 and driver. This guarantees no arbitrary current kernel. Preserve answer, terminal state, GPU memory and CPU/RAM. Compare memory revisions only with matched inputs and software conditions rather than deriving TPS from Gbps. The data rate is a specification, not an application result.
Give Cycles independent acceptance
Blender 5.2 specifies CUDA CC 5.0, with OptiX also requiring driver 575 or newer under its documented conditions. Pascal clears that general floor but needs a suitable build and detection. GTX 1080 has no RTX RT cores; this does not universally prohibit OptiX scenarios. Preserve scene, assets and settings, then check backend, image and VRAM/RAM. Host memory use is another mode rather than added card capacity. Another renderer needs its own documentation. A passing project establishes neither a maximum scene nor arbitrary frame duration for both GTX revisions. Keep output and execution evidence together.
Preserve uncertain power explicitly
Inventory stores capacity separately from data rate and AIB source. Do not replace unknown refresh power with the original reference 180 W without confirmation. Current telemetry is not an official board limit either. Check connectors, dimensions and cooling for the actual design. Preserve driver, toolkit and binary target so upgrades cannot silently replace a working legacy build with an unsuitable one. Account for CPU/RAM during offload and previous ownership before queue handover. Forced clocks or disabled protections cannot resolve software restrictions; explain the original failure on a supported path first. Keep specification unknowns separate from observed operating values.
Verify units and revision through evidence
The package contains raw specification, separate GB/Gbps fields, model and scene manifests and results. If parsing creates 11 GB instead of 8 GB, correct inventory before admission rather than testing an unvalidated budget. With correct units but a failing operation, inspect build and kernels; for memory pressure, inspect footprint. The conclusion concerns a particular GTX 1080 and legacy environment. It promises neither current vLLM nor universal fit, known TPS or gains matching a memory data-rate ratio. Preserved units distinguish actual hardware properties from a specification interpretation error. Retain the tested boundary with accepted jobs.
Build llama.cpp CUDA binaries for multiple GPU architectures · Coding LLMs on 8GB VRAM: Start with a Bounded Task · GPU catalog