server : implement /api/version endpoint for ollama compatibility (#15167 )

[albert-polak]

This PR implements a minimal /api/version endpoint to make llama.cpp compatible with tools expecting the Ollama API, such as the copilot chat VS Code extension.

Fixes #15167

[65a]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

[Green-Sky]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

I think so too.
I also don't really see the point in faking/pretending to be ollama by default.

[albert-polak]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

I think so too. I also don't really see the point in faking/pretending to be ollama by default.

yeah, that is probably a better idea, but the llama.cpp versioning convention probably doesn't comply with the ollama one.

Would you suggest spliting it manually by inserting dots?

[65a]

In the example, I'd return 6121 unless overriden, I guess.

[albert-polak]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

I think so too. I also don't really see the point in faking/pretending to be ollama by default.

yeah, that is probably a better idea, but the llama.cpp versioning convention probably doesn't comply with the ollama one.

Would you suggest spliting it manually by inserting dots?

It actually does comply with the ollama versioning, it is treated as 6121.0.0. Commited some changes.

[ngxson]

If it's purely for compatibility, why don't we hard-code the version number to something like 99.99.99.99 ?

Tbh I don't feel confident spending a lot of code just to match a short-lived integration. VSCode will eventually has OAI-compat support, the ollama-compat is currently a short-term solution.

[ngxson]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

What's the use case? Does nay downstream app check for this version? And even if it checks, does an incorrect version number blocks you from doing certain things?

[albert-polak]

Drive-by comment, not an approver. Maybe we should return the actual llama.cpp version on this endpoint, and have a generic LLAMA_API_VERSION_OVERRIDE env var for cases where it's necessary to return specific values?

What's the use case? Does nay downstream app check for this version? And even if it checks, does an incorrect version number blocks you from doing certain things?

That's exactly right, if the endpoint isn't there the vs code copilot chat extension can't get the model list due to a certain commit (linked in the issue #15167 ). It's connected to this PR #12896. But just returning llama cpp build version works as I commented above. It treats it as 6121.0.0 which won't ever be surpassed I think

[Green-Sky]

ggml presents it's version as 0.0.xxxx.

[albert-polak]

ggml presents it's version as 0.0.xxxx.

Llama build version as in ./llama-cli --version is being treated as "build_version.0.0"