Feat/modelscope support

[yrk111222]

Overview

This PR introduces ModelScope integration for model downloading and loading.
Related PR: #20941

Key changes:

1. Added new cli arguments: -ms (ModelScope repo ID), -msf (file), and -mst (token).
2. Added corresponding environment variables support for seamless configuration.
   Enabled community model downloading via MODEL_ENDPOINT (defaults to https://modelscope.cn/), allowing flexible usage with or without explicit endpoint specification.

Usage examples:

# 1. Download via ModelScope ID (uses default or MODEL_ENDPOINT)
./build/bin/llama-cli -ms Qwen/Qwen3-0.6B-GGUF:Q8_0 -p "hello"
or
MODEL_ENDPOINT=https://modelscope.cn/ ./build/bin/llama-cli -ms Qwen/Qwen3-0.6B-GGUF:Q8_0 -p "hello"

# 2. Specify file and token explicitly (or set 'MS_TOKEN' env)
./build/bin/llama-cli -ms <repo> -msf <file> -mst <token> -p "hello"

Additional information

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: NO

[angt]

Thanks for your contribution.

Could you avoid modifying the hf-cache code to support ModelScope ?
Introducing a separate ms-cache would make more sense here. It might seem easier at first, but it will likely become painful to maintain in the long run.

Also, please make sure to fully align with the ModelScope CLI across all OS, especially regarding cache directory layout and environment variables. I’d be surprised if ModelScope handles all these subtleties the same way as HF.

[yrk111222]

Thanks for your contribution.

Could you avoid modifying the hf-cache code to support ModelScope ? Introducing a separate ms-cache would make more sense here. It might seem easier at first, but it will likely become painful to maintain in the long run.

Also, please make sure to fully align with the ModelScope CLI across all OS, especially regarding cache directory layout and environment variables. I’d be surprised if ModelScope handles all these subtleties the same way as HF.

Thank you for your suggestion. I have received it and will introduce a separate ms-cache and judgment mechanism for ModelScope, which may take some time. 🙏

[ngxson]

I remember there was a discussion in the past, #12664, in which we agreed not to add a new argument, otherwise it will be too bloated

If we really need it, I think the better way is to add only -ms and re-purpose other flags like --hf-file or --hf-token

[yrk111222]

I remember there was a discussion in the past, #12664, in which we agreed not to add a new argument, otherwise it will be too bloated

If we really need it, I think the better way is to add only -ms and re-purpose other flags like --hf-file or --hf-token

Understood!😄 I will limit the new arguments to only -ms and reuse --hf-file and --hf-token.

One quick question about private models: should we also reuse --hf-token and the HF_TOKEN environment variable for ModelScope authentication? For example, would users set HF_TOKEN="ms-xxxxxxx" when accessing private MS repos? Or should the code internally check for MS_TOKEN env as a fallback?

[ngxson]

I think adding an exception for MS_TOKEN is ok, maybe simply add a logic into common_params_parse_ex, something like:

const char * ms_token = get_env("MS_TOKEN");
if (ms_token) {
  params.hf_token = ms_token
}

Btw, we should technically change the name of hf_token to something more generic, like download_token, CC @angt if you think that can be a good idea. The CLI arg can stay as --hf-token, and we can add alias --ms-token and --download-token for it

[angt]

Absolutely, maybe --bearer-token too.
Ideally, I think only the -hf (and the new -ms flag) should stay.

[ngxson]

No strong opinion, but --bearer-token is a little bit ambiguous I think, someone can misunderstand it as "same with server's --api-key"