Auto-detect TornadoVM backend in llama-tornado / llamaTornado#137
Merged
Conversation
mikepapadim
added a commit
to mikepapadim/GPULlama3.javaF
that referenced
this pull request
Jul 23, 2026
…ign edits into RFC - Add docs/VLLM-ALIGNMENT-AND-FEATURES.md: vLLM v1 (engine/core/worker/executor/ sample/spec_decode/attention) -> GPULlama3 target mapping; supported-vs-planned feature matrix; open-PR analysis + land order. - RFC + roadmap: fold in four vLLM-derived edits -> M4 chunked prefill + KVCacheSpec + EngineCore/async(sync) + persistent batch; M3 pluggable attention-backend seam (flash-attn gap); P0 land order beehive-lab#132->beehive-lab#128->beehive-lab#134->beehive-lab#129 then beehive-lab#120/beehive-lab#137, beehive-lab#131 findings-only.
mikepapadim
approved these changes
Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR enables the automatic detection of the sdk, so users do not need to use the
opencl/--ptx/--cuda/--metalflags fromllama-tornadoandllamaTornado.The backend is now auto-detected from the installed TornadoVM SDK (
$TORNADOVM_HOME/etc/tornado.backend, which the TornadoVM installer already writes, e.g.tornado.backends=cuda-backend), so the same command works unmodified against any single-backend SDK -5.1.0-jdk25-opencl,-ptx,-cuda, or-metal.If an SDK bundles more than one backend, priority order
cuda > ptx > opencl > metalpicks one. If users need to use a lower priority backend, they can still use theopencl/--ptx/--cuda/--metalflags fromllama-tornadoandllamaTornado.Both scripts print which backend they picked, e.g.: Detected TornadoVM backend: cuda (from .../etc/tornado.backend).
Why
Backend selection was a manual flag that had to match whatever SDK happened to be on
TORNADOVM_HOME— easy to get out of sync (wrong flag against a single-backend SDK silently produces confusing failures downstream). Since the SDK itself already records which backend(s) it was built with, the launcher can just read that instead of asking the user to repeat it.The existing flags are becoming optional, and remain as a way that users can explicitly ask for a backend in case an SDK bundles multiple backends.
Compatibility
llamaTornado(Java) was missing aCUDAbackend case entirely (only hadOPENCL/PTX/METAL), so it couldn't previously build a working command against a CUDA-backend SDK at all. Added, mirroringllama-tornado.--bench/--serverfeatures merged in frommainin the meantime — both still resolve the backend before dispatching toLlamaBench/OpenAIServer/LlamaApp, no flag collisions. Found and fixed 3 README examples for those features that used the now-removed--cudaflag (would have errored if copy-pasted), and refreshed the stale--helpdump.Where
llama-tornado,llamaTornado— the actual auto-detection + CUDA support.github/workflows/build-and-run.yml,.github/actions/run-inference/action.yml- drop now-redundant--<backend>flags (each CI matrix leg already builds and pointsTORNADOVM_HOMEat a single-backend SDK)scripts/benchmark_backends.sh,scripts/all.sh- sameREADME.md,.claude/skills/build-n-run-engine/SKILL.md,.claude/agents/gpullama-benchmarking-specialist.md- docsHow to test
Point
TORNADOVM_HOMEat any single-backend TornadoVM SDK (source ./set_pathsor equivalent) and confirm$TORNADOVM_HOME/etc/tornado.backendexists.Auto-detection + correct backend wiring:
Both should print Detected TornadoVM backend: (from .../tornado.backend) and the printed java command should reference that backend's exportLists/-exports and tornado.drivers. module.
For example on M4 with OpenCL and Metal:
Command should target bench.LlamaBench / server.OpenAIServer respectively, still with the correct backend's exports/modules.
5. Real end-to-end run (drop --show-command, or add --execute-after-show) against an actual GGUF model, to confirm the JVM actually starts and TornadoVM initializes on the detected backend.
6. If SDKs for more than one backend are available, repeat step 2 against each to confirm detection tracks whichever TORNADOVM_HOME is currently set, with no stale state between runs.
Repo CI (build-and-run.yml) exercises the opencl/ptx/cuda matrix end-to-end on push, which is the main regression check for backend wiring across all three.
Test with SDKs that contain multiple backends
Use the full option from SDKMAN!, or if you do not have SPIR-V build with at least two backends:
or
Then go to root directory of GPULlama3 and build the project.
and it dumps a message when multiple backends are available, the system runs on the highest priority backend which is defined as:
To explicitly use the CUDA backend
To explicitly use the OpenCL backend
However, there is the option to use the flag
--opencl,--metal,--cuda,--ptxto explicitly ask to run with this backend.