v0.3.39 Windows wheel failed to load ggml-cpu-alderlake.dll on i9-12900K, causing ValueError at load_tensors

[qqba]

Environment:

OS: Windows 11 Pro [Version 10.0.26200.8457]

CPU: Intel Core i9-12900K (Alder Lake Architecture)

GPU: NVIDIA GeForce RTX 3090 (24 GB, CUDA 12.4)

Python: 3.12.10

Package: llama_cpp_python-0.3.39+cu124-cp312-cp312-win_amd64.whl

Issue Description:
When upgrading to v0.3.39, the model failed to load during load_tensors with ValueError: Failed to load model from file.

Since my CPU is a 12th Gen i9-12900K (Alder Lake), the loader was supposed to load ggml-cpu-alderlake.dll. However, looking at the logs, it seems ggml_backend_load_all_from_path() failed to load any CPU backend DLLs, resulting in a registry count of only 1 (CUDA only):

Plaintext
load_backend: loaded CUDA backend from ...\llama_cpp\lib\ggml-cuda.dll
Llama.init: Loaded ggml backend registry count: 1
...
load_tensors: loading model tensors...
ValueError: Failed to load model from file
Downgrading to v0.3.38+cu124.basic completely resolved the issue and the model loaded fine. It seems like there might be a regression or missing runtime dependencies (like LLVM/Clang runtime artifacts) when dynamically loading the alderlake CPU backend on certain Windows environments.

[JamePeng]

@qqba Could you please take a screenshot of the site-packages/llama_cpp/lib folder within your installation directory so I can see what files are inside?

like this:

[JamePeng]

The compilation pipeline is producing the expected Alder Lake DLL output.

[JamePeng]

My test showed it loading normally. I suspect you have multiple Python virtual environments or different llama-cpp-python installations.

[qqba]

[PROVEN FIX] v0.3.39 Windows wheel missing libomp140.x86_64.dll, causing ValueError at load_tensors

Environment:

OS: Windows 11 Pro [Version 10.0.26200.8457]

CPU: Intel Core i9-12900K (Alder Lake Architecture)

GPU: NVIDIA GeForce RTX 3090 (24 GB, CUDA 12.4)

Python: 3.12.10

Package: llama_cpp_python-0.3.39+cu124-cp312-cp312-win_amd64.whl

Issue Description:
When upgrading to v0.3.39, the model failed to load during load_tensors with ValueError: Failed to load model from file.

Diagnostic Process (with the help of an AI collaborator):
To crack this mystery, I collaborated with an AI assistant to analyze the dynamic library dependencies. By digging into the Loaded ggml backend registry count: 1 clue from my logs and inspecting ggml-cpu-alderlake.dll via DependenciesGui.exe, we successfully found the smoking gun: ggml-base.dll strictly requires libomp140.x86_64.dll (LLVM OpenMP runtime), which is currently missing from the prebuilt wheel package. (Please see the attached screenshot).

Because the toolchain recently migrated to LLVM/Clang, the compiler linked OpenMP dynamically, but the corresponding runtime DLL was not bundled into the llama_cpp/lib/ directory. Your dev machine can load it because it exists in your global PATH, but a clean user environment will silently fail to register the CPU backends entirely.

Verification & Fix:
Following our analysis, I manually downloaded libomp140.x86_64.dll and dropped it into site-packages/llama_cpp/lib/.

It completely resolved the issue! The CPU backend successfully registered (registry count became 2), and the Qwen3.6-27B model loaded and ran perfectly.

Including libomp140.x86_64.dll into the packaged wheel's installation path will permanently fix this for all Windows users in the next release. Thanks for your awesome work on this project!

[JamePeng]

OK, it's possible that my local machine and the action server have a compilation environment, which is why the program can find libomp140.x86_64.dll correctly. I can optimize a version of the Windows workflow, recompile version 0.3.39 to include this DLL file, and pull one from the compilation environment.

[qqba]

"Awesome! Thanks for the quick response and looking forward to the updated workflow! Keep up the great work!"

[JamePeng]

I am rebuilding the 0.3.39 Windows wheels with the corrected packaging logic so that the LLVM OpenMP runtime is included properly.

The rebuilt wheels are expected to be completed and published within the next 4 hours.