Hmm… for now, the entry-point problem looks pretty simple, but there may still be another trap after that:
The first thing I would try is this:
docker model pull hf.co/ecastera/eva-dolphin-llama3-8b-spanish
The reason is that the error you posted does not appear to be coming from Hugging Face at all.
Your log says:
resolving docker.io/ecastera/eva-dolphin-llama3-8b-spanish:latest
...
insufficient_scope: authorization failed
So at that point Docker Model Runner is trying to resolve the name under Docker Hub (docker.io), not under Hugging Face.
Docker’s current docker model pull documentation makes the source distinction explicit. For example:
# Docker Hub
docker model pull ai/smollm2
# Hugging Face
docker model pull hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF
So I would treat hf.co/ here less as “the final fix” and more as the cheapest useful routing test: first make sure the request is actually going to the source you intended.
That also explains why changing or recreating HF_TOKEN would probably not help with the particular error in the post: the failing request shown in the log has not reached Hugging Face yet.
HF_TOKEN is still a real and relevant Hugging Face authentication mechanism, so if the corrected command later reaches HF and gives an HF-side 401/403, then token/access becomes the right branch to investigate.
A small decision tree might be:
docker model pull hf.co/ecastera/eva-dolphin-llama3-8b-spanish
|
+-- pull succeeds
| |
| +-- run succeeds
| | -> probably done
| |
| +-- run/load fails
| -> now look at model format / backend / LoRA handling
|
+-- Hugging Face-side 401 / 403
| -> now inspect HF_TOKEN / gated or private access
|
+-- a different pull/import error
-> that new error identifies the next failing layer
So even if the error changes, that is useful information rather than necessarily a failed fix.
There is, however, a second reason I would not assume this specific model is finished once the hf.co/ issue is fixed: the current repository looks much more like a PEFT/LoRA adapter artifact than a self-contained 8B checkpoint.
Why the first error looks like a source/registry problem
I think it helps to separate several stages that can all produce superficially similar “some models work, some do not” symptoms:
model reference
↓
source / registry resolution
↓
authentication / authorization
↓
download / Hugging Face import
↓
local model packaging
↓
backend selection
↓
model preload
↓
inference
The first observable difference in your case is already at the source-resolution stage:
docker.io/ecastera/eva-dolphin-llama3-8b-spanish
That is why I would not start by diagnosing Hugging Face credentials.
Docker’s broader Model Runner documentation also treats Docker Hub/OCI registries and Hugging Face as distinct model sources.
A useful debugging rule here is:
When an error contains words such as authorization, first check which host/service actually emitted it before changing credentials.
For example, these would point in very different directions:
docker.io/...
huggingface.co/...
cas-bridge.xethub.hf.co/...
local vLLM / llama.cpp logs
That distinction is often more informative than the generic word “authorization”.
There is also a small documentation wrinkle worth knowing: the individual docker model pull page currently describes the HF example mainly in terms of GGUF, while Docker’s newer inference-engine documentation also documents Safetensors / Hugging Face models through the vLLM backend.
So I would use the pull page as strong evidence for the hf.co/... source syntax, but I would not infer from its GGUF-focused example that current Docker Model Runner can only consume GGUF from Hugging Face.
The current Hugging Face repository has a second, separate wrinkle
The current ecastera/eva-dolphin-llama3-8b-spanish repository contains, among other configuration/tokenizer files:
adapter_config.json
adapter_model.safetensors ~336 MB
config.json
but it does not currently contain the multi-gigabyte full-model Safetensors shards one would normally expect from a standalone Llama 3 8B checkpoint.
Its PEFT metadata identifies the adapter as LoRA and points at:
cognitivecomputations/dolphin-2.9-llama3-8b
as the base model. The relevant repository history can be seen in this commit.
That structure is meaningful in PEFT terms. Hugging Face’s PEFT configuration documentation describes adapter_config.json as the metadata that tells the loader which PEFT method is involved and which base model the adapter belongs to.
In other words, these two things are not equivalent:
A) complete standalone model weights
and
B) base model + LoRA adapter
A .safetensors extension by itself does not tell you which one you have.
That distinction becomes relevant only after fixing the current registry-routing issue.
Why Docker Model Runner may still be able to pull/package it, without that proving it can run it
I looked at the current Docker Model Runner Hugging Face importer because this boundary is easy to blur.
In the current pkg/distribution/huggingface/repository.go, model files are classified fairly generically:
- Safetensors files are treated as weight files.
- GGUF files are treated as weight files.
- config/chat-template files are collected separately.
- if at least one Safetensors file exists, the repository is recognized as a Safetensors model candidate.
So from the importer’s point of view, a file named:
adapter_model.safetensors
still satisfies the generic “this repository contains Safetensors weights” condition.
I do not see a PEFT/LoRA-specific distinction in that importer layer.
That suggests an important separation:
Hugging Face repository ingestion
!=
correct interpretation of the model semantics at runtime
So it is quite plausible that:
hf.co/... fixes the source routing;- DMR successfully downloads/packages the repository as a Safetensors artifact;
- only later, at model load time, the distinction between “full model” and “LoRA adapter” becomes important.
I would therefore avoid both extremes:
- “This repo has LoRA, so Docker Model Runner definitely cannot pull it.”
- “If Docker Model Runner pulls it, that proves the model is runnable.”
Those are different contracts.
What vLLM normally expects for LoRA
This is where the adapter structure becomes interesting.
The current vLLM LoRA documentation describes LoRA serving explicitly as a base model plus adapter arrangement:
vllm serve BASE_MODEL \
--enable-lora \
--lora-modules name=ADAPTER
For example, their documented form is conceptually:
base model:
meta-llama/Llama-3.2-3B-Instruct
adapter:
some-user/some-lora
rather than treating the adapter repository itself as though it contained all base-model weights.
Recent vLLM also supports a richer --lora-modules form where the adapter’s base_model_name can be recorded explicitly.
This matches the PEFT model: the adapter carries a relatively small set of learned parameters, while the original base-model weights remain a separate dependency.
That does not prove Docker Model Runner cannot add its own adapter-aware behavior. It only tells us what the normal vLLM interface looks like, and therefore what to investigate if a later runtime error points toward model loading.
A small sanity check on the current repository
I also did a small T4 sanity check, mainly because this is the sort of boundary that is hard to infer reliably from documentation alone.
Using the current adapter repository directly as the model argument to a plain vLLM server:
vllm serve ecastera/eva-dolphin-llama3-8b-spanish
the loader resolved the architecture as LlamaForCausalLM, selected the BitsAndBytes path from the model config, and then attempted to load the approximately 336 MB Safetensors checkpoint as model weights.
It eventually failed on adapter-style parameter names, with an error along the lines of:
ValueError: There is no module or parameter named 'base_model'
in LlamaForCausalLM
Separately, PEFT was able to read the same repository as a LoraConfig and identify:
cognitivecomputations/dolphin-2.9-llama3-8b
as its base model.
That is consistent with this interpretation:
PEFT view:
base model + adapter metadata + adapter weights
plain vLLM model-load view in this test:
"here is a Llama model repository; load its Safetensors as the model"
and those are not the same operation.
However, I would treat this only as a supporting sanity check, not as a Docker Model Runner reproduction.
I did not reproduce the whole DMR path end-to-end, and the exact vLLM version/backend used by a given Docker Model Runner installation may differ from the standalone vLLM version used in the test.
So the useful conclusion is narrower:
If hf.co/... fixes the current pull problem but docker model run later fails while loading weights, the PEFT/LoRA structure is a strong next place to look.
It is not enough evidence to say “Docker Model Runner definitely cannot run this repo.”
Why the Hugging Face page itself can make this confusing
There is another reason I would not frame this as simply “you used the model incorrectly”.
The current Hugging Face model page itself presents these local-app commands:
vllm serve "ecastera/eva-dolphin-llama3-8b-spanish"
and:
docker model run hf.co/ecastera/eva-dolphin-llama3-8b-spanish
You can see them on the model’s current “Use this model” page.
So trying the DMR route is entirely reasonable.
What I have not found is a public guarantee that the appearance of a generated Local Apps command means that every current repository layout has been end-to-end validated against that runtime.
For this case I would therefore let the observed runtime behavior win over assumptions in either direction:
command is displayed
-> worth trying
command successfully pulls
-> proves ingestion works
command successfully loads/runs
-> proves runtime compatibility
Those are three different levels of evidence.
The repository history may also explain apparently contradictory behavior
There is a useful historical detail in the repository.
At an older revision, the repository contained approximately 6 GB of files including:
adapter_model.safetensors ~336 MB
model-00001-of-00002.safetensors ~4.09 GB
model-00002-of-00002.safetensors ~1.61 GB
You can still inspect that older state here.
The full-model shards were subsequently removed, leaving the much smaller adapter-oriented repository shape visible today.
The adapter metadata was also changed from a local filesystem base-model path to the public HF model identifier cognitivecomputations/dolphin-2.9-llama3-8b.
I would not call that repository “broken” based on this alone. But it does mean that:
an older recipe, an older successful load, the current repository contents, and an automatically generated usage command do not necessarily all refer to exactly the same artifact shape.
For anyone reproducing older behavior, the repository revision is therefore useful context.
If the pull works but the next error is about the backend
If the corrected HF pull succeeds and the next failure is clearly vLLM/backend-related, then the environment becomes relevant.
Docker’s current inference-engine guide documents the vLLM backend as the Safetensors/Hugging Face path and currently lists:
- Linux x86_64
- NVIDIA CUDA
- no CPU-only inference for vLLM
as the supported shape.
On Docker Engine/Linux, the relevant checks are inexpensive:
docker model status
docker model version
and, if necessary:
docker model logs
The documented vLLM runner installation path is:
docker model install-runner --backend vllm --gpu cuda
I would only go down this branch if the new error actually points there, though.
Nothing in the current docker.io/... insufficient_scope error tells us whether your GPU/backend configuration is right or wrong, so checking all of that before fixing the source prefix would mostly add noise.
If LoRA really does become the blocker
Even then, I would not jump straight to abandoning Docker Model Runner or rebuilding the model.
There are several increasingly invasive options:
-
First see what DMR actually does with the corrected hf.co/... reference.
This preserves your current intended workflow and gives the most information for almost no extra work.
-
If the error is specifically about loading an adapter as a standalone model, check whether the runtime offers an explicit base+LoRA path.
This is the native conceptual model used by PEFT/vLLM.
-
Only if a standalone artifact is really required, consider merging the LoRA into its base model.
PEFT supports merging adapters into a base model for deployment, but this is a much heavier operation: it requires the base weights and creates a substantially larger artifact.
So I would not make “merge the adapter” the first recommendation. It solves a different layer from the one currently failing and may turn out not to be necessary.
So, in short, I think there are probably two separate questions hiding here:
1. Why is the command currently failing with "authorization"?
-> because the posted command is resolving against docker.io,
not Hugging Face.
2. Will this particular HF repository run directly once routing is fixed?
-> maybe, but the current repo is a PEFT/LoRA adapter-shaped artifact,
so that is a separate compatibility question.
For the first one, the one-line test is:
docker model pull hf.co/ecastera/eva-dolphin-llama3-8b-spanish
If that changes the current docker.io/... insufficient_scope error into something else, I would consider that progress: the new error should tell you which layer is actually next.