ModelExpress is a model distribution cache layer in NVIDIA Dynamo. It sits between the workers and the model source (MatrixHub or Hugging Face). The first worker triggers a download into the ModelExpress cache. Every subsequent worker gets the model from that cache — no second download.

In this test we deploy two Dynamo vLLM workers for Qwen/Qwen2.5-1.5B-Instruct (~3 GB) and compare the model acquisition time of the first worker (cache miss) versus the second worker (cache hit).

Environment​

How it works​

┌──────────┐     ┌──────────────┐     ┌────────────┐
│ Worker 1 │────▶│ ModelExpress │────▶│ MatrixHub  │
│ Worker 2 │────▶│   (cache)    │     │  (registry) │
│ Worker N │────▶│              │     └────────────┘
└──────────┘     └──────────────┘

• First request: ModelExpress downloads the model from MatrixHub into its local cache, then streams the files to the requesting worker over gRPC.
• Subsequent requests: ModelExpress streams directly from its local cache. No download from MatrixHub.

Compared to a plain MatrixHub setup (Blog 1), the decode component adds three environment variables:

• VLLM_PLUGINS=modelexpress — enable the ModelExpress vLLM plugin
• MODEL_EXPRESS_NO_SHARED_STORAGE=1 — use gRPC streaming instead of a shared filesystem
• MODEL_EXPRESS_URL — the ModelExpress server address

Deployment files​

Worker 1: dgd-blog2-c-mx.yaml​

apiVersion: nvidia.com/v1beta1
kind: DynamoGraphDeployment
metadata:
  name: vllm-7b-c
  namespace: dynamo-system
spec:
  components:
    - name: Frontend
      type: frontend
      replicas: 1
      podTemplate:
        spec:
          containers:
            - name: main
              image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:latest
              workingDir: /workspace
              env:
                - name: HF_ENDPOINT
                  value: "http://<matrixhub-endpoint>"
              command: ["python3", "-m", "dynamo.frontend"]
              args: ["--http-port", "8000"]
              resources:
                requests:
                  cpu: "2"
                  memory: "4Gi"
                limits:
                  cpu: "2"
                  memory: "4Gi"
    - name: decode
      type: decode
      replicas: 1
      podTemplate:
        spec:
          containers:
            - name: main
              image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:latest
              workingDir: /workspace
              env:
                - name: HF_ENDPOINT
                  value: "http://<matrixhub-endpoint>"
                - name: VLLM_PLUGINS
                  value: "modelexpress"
                - name: MODEL_EXPRESS_NO_SHARED_STORAGE
                  value: "1"
                - name: MODEL_EXPRESS_URL
                  value: "http://<modelexpress-service>:8001"
              command: ["python3", "-m", "dynamo.vllm"]
              args:
                - --model
                - Qwen/Qwen2.5-1.5B-Instruct
                - --served-model-name
                - Qwen/Qwen2.5-1.5B-Instruct
                - --tensor-parallel-size
                - "1"
                - --gpu-memory-utilization
                - "0.85"
                - --max-model-len
                - "8192"
                - --no-enable-log-requests
              resources:
                requests:
                  cpu: "4"
                  memory: "16Gi"
                  nvidia.com/vgpu: "1"
                  nvidia.com/gpucores: "30"
                  nvidia.com/gpumem: "10000"
                limits:
                  cpu: "4"
                  memory: "16Gi"
                  nvidia.com/vgpu: "1"
                  nvidia.com/gpucores: "30"
                  nvidia.com/gpumem: "10000"

Worker 2: dgd-blog2-c2-mx.yaml​

Worker 2 is a separate DynamoGraphDeployment with the same configuration but a different name (vllm-7b-c2). The full YAML is identical except for metadata.name.

Clear the ModelExpress cache​

ModelExpress stores model files on a PVC (local-path). Restarting the pod alone does not remove the cached files. To start from a clean state:

kubectl exec -n model-express deploy/model-express-modelexpress \
  -- rm -rf /root/models--Qwen--Qwen2.5-1.5B-Instruct /root/blobs

kubectl rollout restart deployment/model-express-modelexpress -n model-express
kubectl rollout status deployment/model-express-modelexpress -n model-express

Verify:

kubectl exec -n model-express deploy/model-express-modelexpress \
  -- ls /root/models--Qwen--Qwen2.5-1.5B-Instruct
# Expected: ls: cannot access ... No such file or directory

Deploy Worker 1​

kubectl apply -f dgd-blog2-c-mx.yaml
kubectl get pods -n dynamo-system -o wide -w

Watch the decode pod logs:

kubectl logs -n dynamo-system -f <c-decode-pod>

2026-07-06T02:28:45 INFO dynamo_llm::hub: Successfully connected to ModelExpress server
2026-07-06T02:28:45 INFO modelexpress_client: Requesting model: Qwen/Qwen2.5-1.5B-Instruct from provider: HuggingFace
2026-07-06T02:28:45 INFO modelexpress_client: Model Qwen/Qwen2.5-1.5B-Instruct: Model download in progress
2026-07-06T02:29:24 INFO modelexpress_client: Model Qwen/Qwen2.5-1.5B-Instruct: Model download completed successfully
2026-07-06T02:29:24 INFO modelexpress_client: Shared storage disabled, streaming files from server for model Qwen/Qwen2.5-1.5B-Instruct
2026-07-06T02:29:24 INFO modelexpress_client: Streaming model Qwen/Qwen2.5-1.5B-Instruct files to "/home/dynamo/.model-express/cache" with chunk size 32768 bytes
2026-07-06T02:29:48 INFO modelexpress_client: Streaming complete: received 8 files (3098967011 bytes) for model Qwen/Qwen2.5-1.5B-Instruct

Worker 1 waited 38.3 seconds for ModelExpress to download the model from MatrixHub, then received the files over gRPC streaming in 24.2 seconds.

Deploy Worker 2​

After Worker 1 is ready, deploy Worker 2:

kubectl apply -f dgd-blog2-c2-mx.yaml
kubectl get pods -n dynamo-system -o wide -w

Watch the decode pod logs:

kubectl logs -n dynamo-system -f <c2-decode-pod>

2026-07-06T02:32:35 INFO dynamo_llm::hub: Successfully connected to ModelExpress server
2026-07-06T02:32:35 INFO modelexpress_client: Requesting model: Qwen/Qwen2.5-1.5B-Instruct from provider: HuggingFace
2026-07-06T02:32:35 INFO modelexpress_client: Model Qwen/Qwen2.5-1.5B-Instruct: Model already downloaded
2026-07-06T02:32:35 INFO modelexpress_client: Shared storage disabled, streaming files from server for model Qwen/Qwen2.5-1.5B-Instruct
2026-07-06T02:32:35 INFO modelexpress_client: Streaming model Qwen/Qwen2.5-1.5B-Instruct files to "/home/dynamo/.model-express/cache" with chunk size 32768 bytes
2026-07-06T02:32:58 INFO modelexpress_client: Streaming complete: received 8 files (3098967011 bytes) for model Qwen/Qwen2.5-1.5B-Instruct

Worker 2 sees Model already downloaded — ModelExpress skips the download entirely and streams directly from its local cache in 22.8 seconds.

Verify the inference service​

After both workers are ready, test that each can serve inference requests:

# Worker 1
kubectl exec -n dynamo-system <c-frontend-pod> -- \
  curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-1.5B-Instruct","messages":[{"role":"user","content":"hi"}],"max_tokens":20}' \
  | python3 -m json.tool

# Worker 2
kubectl exec -n dynamo-system <c2-frontend-pod> -- \
  curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-1.5B-Instruct","messages":[{"role":"user","content":"hello"}],"max_tokens":20}' \
  | python3 -m json.tool

Both return a normal response:

{
    "choices": [
        {
            "message": {
                "content": "Hello! How can I assist you today?",
                "role": "assistant"
            },
            "finish_reason": "stop"
        }
    ],
    "model": "Qwen/Qwen2.5-1.5B-Instruct"
}

Results​

For comparison, without ModelExpress (Blog 1):

Worker 2 saved the full 38.3-second MatrixHub download. With more workers, the saving multiplies: N workers share one download.

Notes​

First-worker overhead. The first worker through ModelExpress (62.5 s) is slower than a direct MatrixHub download (29 s), because the model passes through an extra gRPC streaming hop (~24 s). ModelExpress pays off when multiple workers need the same model.

Streaming throughput. The gRPC streaming stage transfers 3 GB in ~23 seconds (~131 MB/s). The current implementation uses a 32 KB chunk size with about 94,000 iterations. With shared storage (NO_SHARED_STORAGE=0), workers can mount the ModelExpress cache directory directly and skip streaming entirely — model acquisition drops to near zero for cached models.

When to use what.

SGLang, Transformers, vLLM, and many other tools fetch model files through the Hugging Face Hub protocol. If every service pulls directly from public Hugging Face, startup time depends on public network bandwidth, rate limits, and remote availability.

In this test, we use Qwen/Qwen3-0.6B to compare two startup paths:

• SGLang pulls model files through MatrixHub's Hugging Face-compatible endpoint.
• SGLang pulls model files directly from Hugging Face.

Prepare the model cache in MatrixHub​

First, create a Hugging Face Registry in MatrixHub and use it from a Proxy Project.

The Proxy Project is a Hugging Face-compatible proxy entrypoint. It is still empty right after creation. MatrixHub does not automatically sync all upstream models when the project is created.

The cache is created when a client first requests model files. You can pre-warm it with hf download:

HF_ENDPOINT=http://127.0.0.1:3002

hf download Qwen/Qwen3-0.6B

The hf CLI sends the request to MatrixHub's Hugging Face-compatible API. If the files are not cached yet, MatrixHub pulls them from upstream Hugging Face and stores them locally. Later, SGLang, vLLM, or other clients can hit the MatrixHub cache directly without going back to Hugging Face.

After the cache is populated, the model detail page shows the cached files.

Experiment 1: Start SGLang through MatrixHub​

Before each run, remove the local Hugging Face cache to avoid measuring local cache hits:

rm -rf ~/.cache/huggingface/hub/models--Qwen--Qwen3-0.6B

Then start SGLang with HF_ENDPOINT pointing to MatrixHub:

SGLANG_USE_MLX=1 HF_ENDPOINT=http://127.0.0.1:3002 python -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 \
  --port 30000 \
  --disable-cuda-graph

The key part is:

HF_ENDPOINT=http://127.0.0.1:3002

Here, 127.0.0.1:3002 is the Hugging Face-compatible endpoint exposed by MatrixHub.

The startup log confirms the endpoint used for model downloads:

Hugging Face endpoint for model downloads: http://127.0.0.1:3002

The model files are then fetched and the server becomes ready:

Fetching 7 files: 100%
Download complete: 100% 1.50G/1.50G
MLX model loaded in 3.39s
The server is fired up and ready to roll!

From the screenshot:

Verify the inference service​

After the server is ready, call the OpenAI-compatible API:

curl http://127.0.0.1:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen3-0.6B",
    "messages": [
      {"role": "user", "content": "你好，简单介绍一下你自己"}
    ],
    "max_tokens": 128,
    "temperature": 0.6
  }'

The model returns a normal response, which confirms that the model was loaded successfully and the inference service is usable.

Experiment 2: Start SGLang directly from Hugging Face​

Next, run the same model with the same SGLang arguments, but point the endpoint back to Hugging Face:

SGLANG_USE_MLX=1 HF_ENDPOINT=https://huggingface.co python -m sglang.launch_server \
  --model-path Qwen/Qwen3-0.6B \
  --host 0.0.0.0 \
  --port 30000 \
  --disable-cuda-graph

This path also starts successfully, but it takes longer:

MLX model loaded in 72.97s
The server is fired up and ready to roll!

From the screenshot:

Results​

Both runs cleared the local Hugging Face cache first. The model and SGLang arguments stayed the same. The only major difference was HF_ENDPOINT.

In this test, the MatrixHub path reduced startup time from about 125 seconds to about 35 seconds.

Qwen3-0.6B is a small model. With larger models, or with multiple machines repeatedly pulling the same models, a shared cache layer becomes much more valuable.

Why MatrixHub helps​

MatrixHub acts as a Hugging Face-compatible model cache layer:

SGLang / vLLM / Transformers
        ↓
HF_ENDPOINT
        ↓
MatrixHub Proxy Project
        ↓
MatrixHub cache or upstream Hugging Face

The first request fills the cache. Later requests for the same model can be served by MatrixHub directly.

The client still uses the original Hugging Face repo name:

Qwen/Qwen3-0.6B

And the integration only requires setting the endpoint:

export HF_ENDPOINT=http://127.0.0.1:3002

This gives several practical benefits:

• Fewer repeated downloads for the same model.
• More predictable startup time.
• A single model entrypoint for SGLang, vLLM, Transformers, and other Hugging Face-compatible clients.
• Better fit for private networks, shared development environments, and inference clusters.

• Experiment 1: Deploy Dynamo on a GPU Kubernetes cluster and pull model weights from an internal MatrixHub. The result is an OpenAI-compatible inference service that can answer chat requests for the qwen3-0.6b model.
• Experiment 2: Repeat the same setup, but pull the weights from public Hugging Face instead, and compare the first-download time of the two runs.

Experiment 1​

Environment​

• Dynamo is installed — the Dynamo operator is already deployed in the cluster and can pick up the deployment file in step 2 and bring up the service automatically.
• GPU node — one NVIDIA A800 80GB, sliceable into 10 vGPUs. The node runs HAMi (a GPU virtualization component) that splits a physical GPU into several slices so multiple services can share the same card.
• In-network model hub (MatrixHub) — a MatrixHub model-weight registry is deployed internally (matrixhub.internal:30001). Weights are pulled from here, never over the public internet. The chenyang-qwen/qwen3-0.6b model was pre-cached on MatrixHub with hf download.
• Network reachability — the cluster node <cluster-node> can pull container images (nvcr.io) and reach the internal weight source MatrixHub (matrixhub.internal:30001).

Confirm the above first, especially that Dynamo and vGPU are ready.

Before you start​

• The cluster kubeconfig file
• A machine with kubectl installed

Step 1: Connect to the cluster​

Open a terminal and set the kubeconfig (do this once per new terminal):

# Replace with the actual path to your kubeconfig file
export KUBECONFIG=<path-to-your-kubeconfig>

Verify connectivity:

kubectl get nodes

If you see the node list, you are good.

Step 2: Prepare the deployment file​

Create a file dgd-vllm-vgpu.yaml with the following content:

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: vllm-qwen-vgpu
  namespace: dynamo-system
spec:
  services:
    Frontend:
      componentType: frontend
      replicas: 1
      resources:
        requests:
          cpu: "2"
          memory: "4Gi"
        limits:
          cpu: "2"
          memory: "4Gi"
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.1.1
          workingDir: /workspace
          env:
            - { name: HF_ENDPOINT, value: "http://matrixhub.internal:30001" }
          command: ["python3", "-m", "dynamo.frontend"]
          args: ["--http-port", "8000"]

    decode:
      componentType: worker
      subComponentType: decode
      replicas: 1
      resources:
        requests:
          cpu: "4"
          memory: "16Gi"
          custom:
            nvidia.com/vgpu: "1"          # 1 vGPU slice
            nvidia.com/gpumem: "10000"    # memory limit, MB (~10GB)
            nvidia.com/gpucores: "30"     # compute limit, 0-100
        limits:
          cpu: "4"
          memory: "16Gi"
          custom:
            nvidia.com/vgpu: "1"
            nvidia.com/gpumem: "10000"
            nvidia.com/gpucores: "30"
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.1.1
          workingDir: /workspace
          env:
            - { name: HF_ENDPOINT, value: "http://matrixhub.internal:30001" }
          command: ["python3", "-m", "dynamo.vllm"]
          args:
            - --model
            - chenyang-qwen/qwen3-0.6b
            - --served-model-name
            - chenyang-qwen/qwen3-0.6b
            - --tensor-parallel-size
            - "1"
            - --gpu-memory-utilization
            - "0.85"
            - --max-model-len
            - "8192"
            - --no-enable-log-requests

Note: the HF_ENDPOINT environment variable points to the internal MatrixHub address http://matrixhub.internal:30001.

Common things you may want to change later:

Step 3: Deploy​

kubectl apply -f dgd-vllm-vgpu.yaml

Step 4: Wait for it to come up​

kubectl -n dynamo-system get pods -l nvidia.com/dynamo-graph-deployment-name=vllm-qwen-vgpu -w

Wait until both pods show 1/1 Running (the first deploy pulls images and may take a few minutes).

Check the service logs:

kubectl -n dynamo-system logs <pod-name> --tail=50

Because MatrixHub is deployed internally and the model is already cached (HF_ENDPOINT points to MatrixHub), the model download takes about 10 seconds:

Step 5: Test the service​

First get the frontend pod name:

kubectl -n dynamo-system get pods | grep frontend

Test with that name (replace <frontend-pod> with what you found above):

kubectl -n dynamo-system exec <frontend-pod> -- curl -s http://localhost:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"chenyang-qwen/qwen3-0.6b","messages":[{"role":"user","content":"Introduce yourself in one sentence"}],"max_tokens":64}'

If the model returns a reply, the deployment succeeded.

Experiment 2​

Everything else is identical to Experiment 1. Just remove the HF_ENDPOINT environment variable from the deployment YAML, and it falls back to pulling model weights from public Hugging Face.

Without MatrixHub (downloading from public Hugging Face), the logs show the model download takes about 6 minutes:

Results: first-download time comparison​

Measured per-stage timings for the two cases — "internal MatrixHub with the model pre-cached" vs. "no MatrixHub" — using the qwen3-0.6b model. The first-download comparison is shown below:

Conclusion​

An in-network MatrixHub significantly accelerates Dynamo's first model-weight download.

But if you're operating in an enterprise environment, especially air-gapped or private deployments, you'll quickly realize one thing:

The model is not the biggest problem. Distribution is.

During our attempt to deploy DeepSeek v4 in an internal network, we ran into a lot of issues. In the end, they can all be boiled down to three fundamental problems.

1. You think it's a download problem, but it's actually an architecture problem​

Hugging Face doesn't work well in enterprise environments​

• Unstable or completely unavailable network
• Slow downloads and large-file interruptions
• Lack of access control

It looks like a slow-download issue, but in reality:

Hugging Face is built for research collaboration, not controlled enterprise distribution.

2. You try to fix it yourself, but make it worse​

Common workarounds all break down​

• Manual file transfer leads to version chaos and no auditability
• NFS and NAS hit IO bottlenecks and still have no caching
• Each node downloading independently exhausts bandwidth and slows cold starts

Especially in vLLM and SGLang scenarios:

Every node downloading the same model multiplies bandwidth pressure by N.

3. The real problem is actually just one thing​

All these issues can be summarized in one sentence:

You're missing a model distribution infrastructure layer, like a container registry for model artifacts.

Just like you wouldn't use Docker Hub directly in production, you'd use a private registry instead. But in the model world, this layer has been missing for a long time.

4. Our solution​

Core idea​

Public Model Source (Hugging Face)
        ↓
Proxy / Caching Layer
        ↓
Unified Internal Distribution
        ↓
vLLM / Inference Services

This follows a pattern that has already been proven elsewhere:

• Docker -> Docker Hub -> Harbor
• Maven -> Central -> Nexus
• PyPI -> pip -> Private Registry

Model distribution is fundamentally the same kind of problem.

Key capabilities​

This distribution layer should provide:

1. Proxy access to Hugging Face, not a replacement
2. Automatic model caching
3. Resume support for interrupted transfers
4. Access control and permissions
5. Internal network distribution
6. Compatibility with vLLM and SGLang

5. We built it into a project​

MatrixHub is essentially:

An enterprise-grade Hugging Face proxy and model distribution acceleration layer.

It provides:

• A Hugging Face proxy for public-network constraints
• A model cache layer to eliminate repeated downloads
• A unified enterprise access entry for permissions and governance

You can think of it as:

• Harbor for models
• The container registry of the AI era

6. Quick start​

Step 1: Start the service​

Download docker-compose.yaml and config.yaml, and make sure the two files are in the same folder.

docker compose -f docker-compose.yaml up -d

Default service endpoint:

http://127.0.0.1:3001

Verify:

curl http://127.0.0.1:3001

Step 2: Login​

• Username: admin
• Password: changeme

Change the password immediately.

Step 3: Create a remote registry to proxy Hugging Face​

Key configuration:

Remote URL: https://hf-mirror.com ( or https://huggingface.co )
Type: HuggingFace
Recommended name: huggingface

How it works:

Request -> MatrixHub -> Hugging Face -> Response

Step 4: Create a proxy project​

Purpose:

User -> Proxy Project -> Remote Repo (HF) -> Cache

When creating the project:

• Select the huggingface remote registry
• Specify the model organization: deepseek-ai

Step 5: Client integration​

export HF_ENDPOINT="http://127.0.0.1:3001"

What this does:

• Redirects client requests
• Lets the first request fetch from Hugging Face
• Automatically caches locally
• Keeps all later requests inside the intranet

Step 6: Download the model​

6.1 Start the download​

hf download deepseek-ai/DeepSeek-V4-Pro

6.2 First node: populate the cache​

In our test environment, the first download took 6 hours and 56 minutes. This initial request fetched the model from the upstream Hugging Face source and populated the MatrixHub cache. Replace http://x.x.x.x:3001 with your actual MatrixHub service address.

root@node1:/data/matrixhub# export HF_ENDPOINT="http://x.x.x.x:3001"
root@node1:/data/matrixhub# export HF_HUB_DOWNLOAD_TIMEOUT=120
root@node1:/data/matrixhub# nohup time -p hf download deepseek-ai/DeepSeek-V4-Pro --local-dir /data/matrixhub/deepseek-v4

6.3 Second node: reuse the cached model​

The second download, from another node in the same internal network, completed in 86 minutes because the model files were already cached by MatrixHub.

root@node2:/data/matrixhub# export HF_ENDPOINT="http://x.x.x.x:3001"
root@node2:/data/matrixhub# export HF_HUB_DOWNLOAD_TIMEOUT=120
root@node2:/data/matrixhub# time hf download deepseek-ai/DeepSeek-V4-Pro --local-dir /data/matrixhub/deepseek-v4

6.4 Verify the model in the UI​

After the download finishes, you can see the DeepSeek-V4-Pro model under the deepseek-ai project in the UI.

6.5 Inspect cached model files​

Open the model details page to inspect the cached files and verify that the artifacts are available for internal distribution.

Verify cache effectiveness​

Use curl to observe request behavior.

First request: cache miss​

curl -I http://127.0.0.1:3001/deepseek-ai/DeepSeek-V4-Pro/resolve/main/config.json

Characteristics:

• Longer response time
• Contains upstream headers

Second request: cache hit​

curl -I http://127.0.0.1:3001/deepseek-ai/DeepSeek-V4-Pro/resolve/main/config.json

Characteristics:

• Very fast response
• No longer hits Hugging Face

Final thoughts​

If you're deploying large models in an enterprise environment, you will inevitably face:

• Slow downloads
• Bandwidth exhaustion
• Repeated downloads across nodes
• Lack of access control

These are not edge cases. They are architectural gaps.

MatrixHub simply fills that missing layer.

If you're working on similar problems, feel free to connect:

https://github.com/matrixhub-ai/matrixhub

Common use cases​

Intranet vLLM cluster distribution​

• Scenario: A production intranet runs a vLLM inference cluster with 100 GPU servers. Because model files can be huge, such as a 70B model exceeding 130GB, having every machine pull from public Hugging Face is slow and may trigger outbound bandwidth throttling.
• Flow overview:
  1. Single access point: Set the HF_ENDPOINT environment variable of all vLLM nodes to the internal MatrixHub endpoint.
  2. Pull once, cache for all: When the first node requests a model, MatrixHub pulls it from the public network and persists it locally; subsequent nodes hit the intranet cache directly.

As a user, I want to point the hf download endpoint to MatrixHub so that later downloads inside the same network become much faster after the first request has already cached the model.

Steps​

1. Visit the MatrixHub address http://x.x.x.x:3001 and open the login page.

2. Log in as the admin user and open the model repository list.

3. Click the top-right user menu, then go to Platform Settings and Registry Management.

4. Create a target registry: select Hugging Face as the provider, set the registry name to hf, enter the target URL https://hf-mirror.com, enable remote certificate verification, and click OK.

5. Go to Project Management and open the project list page.

6. Click Create Project: set the project name to qwen, set it to Public, enable Proxy, select the registry, set the proxy organization to Qwen, and click OK.

7. Pull the model.

   • First node: about 3m37.318s

• Second node: about 0m8.500s

8. View the model information in MatrixHub.