llama-cpp: support every Linux prebuilt backend (CUDA, ROCm, SYCL, OpenVINO)

[cosmincc]

Requested by Cosmin

✍️ Description

var_backend in the llama.cpp script now covers every Linux prebuilt llama.cpp publishes. Each backend gets the runtime that upstream's .github/workflows/release.yml builds against:

• cpu and vulkan: unchanged. auto is still the default: Vulkan when a GPU is passed through, otherwise CPU.
• cuda: picks the CUDA 12 or 13 build from the host driver (driver below 580 gets 12, which is x64 only). The matching cudart-llama-* tarball is also deployed into /opt/llama-cpp.
• rocm: ubuntu-rocm-<ver>-x64, plus the same ROCm release of AMD's TheRock wheels (rocm[libraries]==<ver>.* from stable.repo.amd.com/rocm/whl-next/) in a uv venv under /opt/llama-cpp_data/rocm, which is added to LD_LIBRARY_PATH. On update, the runtime follows when upstream moves the build to a newer ROCm.
• sycl-fp16 / sycl-fp32: intel-oneapi-runtime-libs from Intel's oneAPI apt repo (via setup_deb822_repo), with its lib dirs registered in ld.so.conf.d. Also installs the Level Zero loader (libze1_*+u24.04_amd64.deb from oneapi-src/level-zero, as in release.yml) and libze-intel-gpu1 from intel/compute-runtime.
• openvino: ubuntu-openvino-*-x64 with libtbb12, ocl-icd-libopencl1 and Level Zero. GGML_OPENVINO_DEVICE=GPU is set when /dev/dri/renderD* exists, otherwise CPU.

Other changes:

• Removed the outdated "no Linux ROCm/CUDA build" comments and the rocm→vulkan remap, because upstream now ships ubuntu-rocm and ubuntu-cuda. An old install that recorded rocm but has no ROCm runtime keeps updating as Vulkan.
• check_for_gh_release / fetch_and_deploy_gh_release use the b tag prefix, because only bNNNN tags carry binaries. Updates keep the backend recorded in /opt/llama-cpp_data/.backend.
• var_backend, var_model_repo, var_ctx_size, var_offload_layers, var_api_key and var_port are now exported from the CT script. Before this they were declared in app_vars but never reached the container. When var_backend is unset, the install asks through prompt_select (unattended runs default to auto).
• JSON: added the new var_backend options and rewrote the backend note.

🔗 Related PR / Issue

Link: #2124

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

var_arm64 is left as it was. cpu, vulkan and cuda (13 only) have arm64 assets. rocm, sycl and openvino are x64 only, and the install now stops with a clear error if one of them is picked on arm64.

---

🖥️ Tested on (X in brackets)

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus – Created on an Incus host and the app works.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose – The application is installed bare-metal; Docker is not used.
• No git pull – Updates use fetch_and_deploy_gh_release, fetch_and_deploy_codeberg_release, fetch_and_deploy_gl_release, or fetch_and_deploy_from_url instead of git pull.

---

🤖 AI Assistance (X in brackets)

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

Claude Code (Claude Opus, low reasoning effort) ported an earlier draft onto the DevScripts versions of the scripts. It checked the helper signatures against community-scripts/core (check_for_gh_release / fetch_and_deploy_gh_release tag-prefix argument, prompt_select, setup_hwaccel) and the asset names against the current llama.cpp release (b11609). shellcheck shows only the source warnings every script in the repo has. Not yet tested on a Proxmox host.

---

📋 Additional Information (optional)

Asset names checked against b11609: ubuntu-cuda-12.8-x64, ubuntu-cuda-13.4-{x64,arm64} (+ cudart- tarballs), ubuntu-rocm-10.0-x64, ubuntu-sycl-{fp16,fp32}-x64, ubuntu-openvino-2026.4.1-x64, ubuntu-vulkan-{x64,arm64}, ubuntu-{x64,arm64}.

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• https://github.com/ggml-org/llama.cpp (.github/workflows/release.yml for the per-backend build dependencies)
• https://github.com/oneapi-src/level-zero
• https://github.com/intel/compute-runtime
• https://stable.repo.amd.com/rocm/whl-next/

🤖 Generated with Claude Code

[github-actions]

Try this script

ct/llama-cpp.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/cosmincc/PVE-DevScripts/feat/llama-cpp-backends \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/cosmincc/PVE-DevScripts/feat/llama-cpp-backends/ct/llama-cpp.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.

[asylumexp]

Not yet tested on a Proxmox host.

Go test it.