ollama/llama
Jesse Gross efaee8c2d6 ggml: Backport scale kernel fixes
The GGML scale kernel uses signed 32-bit ints to represent
the number of elements in the tensor. For large images,
mistral-small3.2 overflows this, triggering CUDA errors due
to negative arguments.

Currently, this can happen when the user passes a large image
to mistral-small3.2. However, with upcoming changes to reserve
CUDA memory, it happens every time mistral-small is loaded as
we reserve using a worst case batch.

This patch is part of an upstream GGML commit and should be removed
after GGML is updated past 0a1b398 "ggml: add ops for WAN video model
(cuda && cpu) (#15669)".

Fixes #10388
2025-09-30 15:04:43 -07:00
..
llama.cpp disable output_all (#11959) 2025-08-18 17:45:40 -07:00
patches ggml: Backport scale kernel fixes 2025-09-30 15:04:43 -07:00
.gitignore Re-introduce the llama package (#5034) 2024-10-08 08:53:54 -07:00
build-info.cpp update vendored llama.cpp and ggml (#11823) 2025-08-14 14:42:58 -07:00
build-info.cpp.in chore: update gitattributes (#8860) 2025-02-05 16:37:18 -08:00
llama_test.go llama: move grammar tests to llama_test.go (#8411) 2025-01-14 12:55:45 -08:00
llama.go Fix image cannot be seen with slice image on llama engine 2025-09-12 16:25:12 -07:00
README.md docs: improve syntax highlighting in code blocks (#8854) 2025-02-07 09:55:07 -08:00
sampling_ext.cpp update vendored llama.cpp and ggml (#11823) 2025-08-14 14:42:58 -07:00
sampling_ext.h api: remove unused sampling parameters (#10581) 2025-05-08 08:31:08 -07:00

llama

This package provides Go bindings to llama.cpp.

Vendoring

Ollama vendors llama.cpp and ggml. While we generally strive to contribute changes back upstream to avoid drift, we carry a small set of patches which are applied to the tracking commit.

If you update the vendoring code, start by running the following command to establish the tracking llama.cpp repo in the ./vendor/ directory.

make -f Makefile.sync apply-patches

Updating Base Commit

Pin to new base commit

To change the base commit, update FETCH_HEAD in Makefile.sync.

When updating to a newer base commit, the existing patches may not apply cleanly and require manual merge resolution.

Start by applying the patches. If any of the patches have conflicts, the git am will stop at the first failure.

make -f Makefile.sync apply-patches

If there are conflicts, you will see an error message. Resolve the conflicts in ./vendor/, and continue the patch series with git am --continue and rerun make -f Makefile.sync apply-patches. Repeat until all patches are successfully applied.

Once all patches are applied, commit the changes to the tracking repository.

make -f Makefile.sync format-patches sync

Generating Patches

When working on new fixes or features that impact vendored code, use the following model. First get a clean tracking repo with all current patches applied:

make -f Makefile.sync clean apply-patches

Iterate until you're ready to submit PRs. Once your code is ready, commit a change in the ./vendor/ directory, then generate the patches for ollama with

make -f Makefile.sync format-patches

In your ./vendor/ directory, create a branch, and cherry-pick the new commit to that branch, then submit a PR upstream to llama.cpp.

Commit the changes in the ollama repo and submit a PR to Ollama, which will include the vendored code update with your change, along with the patches.

After your PR upstream is merged, follow the Updating Base Commit instructions above, however first remove your patch before running apply-patches since the new base commit contains your change already.