devops : only build some specific targets for full image

[ngxson]

Normally, the docker full-* image tag build all the targets. However, the entrypoint tools.sh only handle 3 tools: cli, server and quantize

This makes the build very wasteful, since most of the build time and storage space ended up not being used. Some CI run also breaks due to out of space (ref: https://github.com/ggerganov/llama.cpp/actions/runs/10584764326/job/29329766919)

This PR fixes the issue by only build targets used by tools.sh

• I have read the contributing guidelines
• Self-reported review complexity:
  • Low
  • Medium
  • High

[ggerganov]

AFAIU #9213 should reduce the build size dramatically because of linking ggml and llama dynamically.

[ngxson]

@ggerganov @slaren The current dockerfile introduced in #9213 only build llama-cli target for full-cuda image. I added llama-quantize and llama-server as required by tools.sh

Please let me know if this is OK. Thank you.

[slaren]

That was a mistake, I forgot to remove the --target.

[ngxson]

@slaren No problem! In fact, I just want to ask if it's ok to build only these 3 targets for full image (that's contrary to what you wanted to do, which is to build all binaries by removing --target)

For now, tools.sh does not provide entrypoint for other binaries like llama-bench or llama-perplexity. So, user can't access them without overriding --entrypoint in the docker run command. I'm not sure if anyone does that, though.

[slaren]

I have no idea who uses the full image, however with dynamic linking each executable should be <1MB, and building all of them will only increase the size of the image slightly (in my local build, the entire bin directory of a full build is only 32MB). Considering that the image is ~10GB, I don't see a good reason to not just build everything, even if only to avoid breaking it for people who depend on that.

[ngxson]

@slaren Hmm ok that makes sense. I think the better way would be to provide entrypoint to other tools via tools.sh. I'll do that in another PR then. Thanks for the response!

Maybe we should also bring dynamic link to full-rocm and full image.