fix: add Pascal CUDA architectures#970
Conversation
Signed-off-by: Nanook Claw <nanook@agentmail.to>
There was a problem hiding this comment.
Code Review
This pull request configures CUDA architectures in the Dockerfile for llamacpp. However, the specified architectures '120' and '121' are invalid and will cause compilation to fail, while the important Hopper architecture ('90') is missing. The reviewer recommends updating the list to use valid compute capabilities.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| -DGGML_NATIVE=OFF \ | ||
| -DGGML_OPENMP=OFF \ | ||
| -DGGML_CUDA=ON \ | ||
| -DCMAKE_CUDA_ARCHITECTURES=61;62;70;75;80;86;89;120;121 \ |
There was a problem hiding this comment.
The CUDA architectures 120 and 121 are invalid. CUDA compute capabilities (architectures) do not go up to 120 or 121; these numbers likely confuse CUDA software versions (12.0, 12.1) with GPU architectures. Passing these invalid values will cause nvcc to fail during compilation with an error like nvcc fatal : Unsupported gpu architecture 'compute_120'.
Additionally, the list is missing Hopper (90), which is a highly important enterprise GPU architecture (e.g., NVIDIA H100).
Please update the list to use valid compute capabilities, such as 61;62;70;75;80;86;89;90.
-DCMAKE_CUDA_ARCHITECTURES=61;62;70;75;80;86;89;90 \
References
- Focus on correctness, safety, and maintainability — in that order. Critical issues include correctness bugs. (link)
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- Hard-coding
CMAKE_CUDA_ARCHITECTURESin the Dockerfile makes it harder to support future GPU generations; consider wiring this through a build ARG or environment variable so the list can be overridden without editing the image definition. - Since the semicolon-separated architectures are passed through shell and command substitution, it may be safer to either quote the
-DCMAKE_CUDA_ARCHITECTURES=...argument or document this behavior near thecmake-flagsusage to avoid accidental word-splitting changes in future edits.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Hard-coding `CMAKE_CUDA_ARCHITECTURES` in the Dockerfile makes it harder to support future GPU generations; consider wiring this through a build ARG or environment variable so the list can be overridden without editing the image definition.
- Since the semicolon-separated architectures are passed through shell and command substitution, it may be safer to either quote the `-DCMAKE_CUDA_ARCHITECTURES=...` argument or document this behavior near the `cmake-flags` usage to avoid accidental word-splitting changes in future edits.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
Eventually we should use to using llama.cpp artefacts from llama.cpp directly... We will support whatever they deem suitable to support... @ilopezluna PTAL |
Summary
Closes #929.
This sets
CMAKE_CUDA_ARCHITECTURESexplicitly for the native llama.cpp CUDA build so the image includes Pascal targetssm_61andsm_62. The list follows the issue's suggested architecture set and keeps the existing newer CUDA targets covered:61;62;70;75;80;86;89;120;121Without an explicit value, recent CUDA/CMake defaults can omit Pascal, which leaves GTX 10-series and similar cards without a compatible CUDA kernel and causes Docker Model Runner to fall back to CPU inference.
Validation
git diff --checkcmake-flagscommand-substitution patternI did not run a full CUDA image build locally because that requires pulling the NVIDIA CUDA builder image and compiling llama.cpp; there does not appear to be a focused lightweight Dockerfile flag test in this repo.