#2627 adds a deviceType parameter so device_type=gpu|cuda can be set on the LightGBM learners. The parameter works — it reaches the native layer, verified by LightGBM rejecting it by name. But it cannot actually train on a GPU, because the native library SynapseML ships is CPU-only.
That is the other half of GPU support, and it is a build problem rather than a code problem.
Evidence
build.sbt pins com.microsoft.ml.lightgbm:lightgbmlib 3.3.510. Scanning the bundled lib_lightgbm.so:
OpenCL 0 occurrences
clCreateKernel 0 occurrences
cuda_tree_learner 0 occurrences
Training with device_type=gpu fails with GPU Tree Learner was not enabled in this build., and cuda with the CUDA equivalent. Those strings are compiled into the shipped binary.
No dependency bump fixes this
com.microsoft.ml.lightgbm:lightgbmlib publishes one artifact and 3.3.510 is the newest that exists (19 versions, newest 2023-05-15). We are already on it.- Every other
lightgbm artifact on Maven Central is either older, a PMML/conversion tool, or a different binding.
- The one newer binding,
io.github.metarank:lightgbm4j (LightGBM 4.4.0), ships CPU-only natives too. Its README is explicit that GPU requires you to rebuild LightGBM yourself with -DUSE_CUDA=1 -DUSE_SWIG=ON and point LIGHTGBM_NATIVE_LIB_PATH at the result.
So there is no artifact to switch to. Someone has to build the native.
What this would involve
- Build LightGBM from source with
-DUSE_GPU=1 (OpenCL) and/or -DUSE_CUDA=1, plus -DUSE_SWIG=ON, for each platform we support.
- Decide how it ships. A GPU build needs an OpenCL/CUDA runtime present at load time, so it likely cannot simply replace the current native in the main jar without breaking CPU-only users — a classifier, a separate artifact, or runtime selection with fallback.
- Add a load path that prefers the GPU native when present and falls back to the CPU one, so nothing regresses for users without a GPU.
- Get GPU CI capacity, or accept that this stays manually verified.
Why it is worth doing separately
Step 2 is the real design question and it affects packaging for every SynapseML user, GPU or not. It should not ride along inside a parameter PR.
Worth noting the ordering is fine either way: #2627's GPU tests assert that a device request is never silently downgraded to CPU, accepting either a successful fit or a failure naming the tree learner. On a GPU-capable native they start passing by training instead of by failing, with no test changes needed.
#2627 adds a
deviceTypeparameter sodevice_type=gpu|cudacan be set on the LightGBM learners. The parameter works — it reaches the native layer, verified by LightGBM rejecting it by name. But it cannot actually train on a GPU, because the native library SynapseML ships is CPU-only.That is the other half of GPU support, and it is a build problem rather than a code problem.
Evidence
build.sbtpinscom.microsoft.ml.lightgbm:lightgbmlib3.3.510. Scanning the bundledlib_lightgbm.so:Training with
device_type=gpufails withGPU Tree Learner was not enabled in this build., andcudawith the CUDA equivalent. Those strings are compiled into the shipped binary.No dependency bump fixes this
com.microsoft.ml.lightgbm:lightgbmlibpublishes one artifact and3.3.510is the newest that exists (19 versions, newest 2023-05-15). We are already on it.lightgbmartifact on Maven Central is either older, a PMML/conversion tool, or a different binding.io.github.metarank:lightgbm4j(LightGBM 4.4.0), ships CPU-only natives too. Its README is explicit that GPU requires you to rebuild LightGBM yourself with-DUSE_CUDA=1 -DUSE_SWIG=ONand pointLIGHTGBM_NATIVE_LIB_PATHat the result.So there is no artifact to switch to. Someone has to build the native.
What this would involve
-DUSE_GPU=1(OpenCL) and/or-DUSE_CUDA=1, plus-DUSE_SWIG=ON, for each platform we support.Why it is worth doing separately
Step 2 is the real design question and it affects packaging for every SynapseML user, GPU or not. It should not ride along inside a parameter PR.
Worth noting the ordering is fine either way: #2627's GPU tests assert that a device request is never silently downgraded to CPU, accepting either a successful fit or a failure naming the tree learner. On a GPU-capable native they start passing by training instead of by failing, with no test changes needed.