ollama - 💡(How to fix) Fix pull gpt-oss-safeguard:120b fails with "Error: EOF" on aarch64 (0.23.2 / 0.23.3-rc1)

Summary

ollama pull gpt-oss-safeguard:120b fails with Error: EOF on aarch64 (NVIDIA DGX Spark / GB10). Reproduces on both 0.23.2 (stable) and 0.23.3-rc1. Reproduces inside the official ollama/ollama:0.23.2 and ollama/ollama:0.23.3-rc1 Docker images.

The 20 GB sibling gpt-oss-safeguard:20b and unrelated models (tinyllama:1.1b-chat) pull normally on the same host. So the issue is specific to this model, not the registry, network, or local environment.

Steps to reproduce

docker run --rm --gpus all -v ollama:/root/.ollama --name ollama-test \
    ollama/ollama:0.23.2 serve &
sleep 5
docker exec ollama-test ollama pull gpt-oss-safeguard:120b

Expected

Layers download (the model layer is 65,369,799,840 bytes).

Actual

pulling manifest
Error: EOF

The server-side response (captured with curl against 127.0.0.1:11434/api/pull from inside the container):

HTTP/1.1 200 OK
Content-Type: application/x-ndjson
Transfer-Encoding: chunked

{"status":"pulling manifest"}
{"error":"EOF"}

The POST /api/pull returns ~280 ms after the request — fast enough that the manifest has been fetched and parsed, but no layer-download events appear before the EOF.

What was ruled out

1. Registry / CDN — the manifest and the 65 GB layer blob both fetch cleanly via plain curl from inside the same Ollama container:

   $ curl -sI https://registry.ollama.ai/v2/library/gpt-oss-safeguard/manifests/120b
   HTTP/2 200
   ollama-content-digest: 45be44f7918ac49a9faa8bcb10b1ebc26a77b03ba63f5e2f8c74e9d6d9f8ea19
   ...
   $ curl -sI https://registry.ollama.ai/v2/library/gpt-oss-safeguard/blobs/sha256:e5a44e5a8c7c31d572d002d48e9ae37354adf6973d45b2085802260c14a7274d
   HTTP/2 200
   content-type: application/octet-stream
   content-length: 65369799840

2. Disk space — 3.4 TB free.
3. Memory — 121 GiB total / 111 GiB free. MXFP4 116.8B model is ~65 GB.
4. Ollama version — same failure on 0.23.2 (stable) and 0.23.3-rc1.
5. Other models — tinyllama:1.1b-chat pulls fine; gpt-oss-safeguard:20b pulls fine (same model family, same MXFP4 quant, smaller).
6. OLLAMA_DEBUG=1 — set and confirmed in the container env, but produces no additional log lines for the failed pull. Only the GIN access line POST "/api/pull" 200 in ~280 ms appears.

Manifest

{
  "schemaVersion": 2,
  "config": {
    "digest": "sha256:de898dbfdba5d7189a22dc042ed0b47793c35202923e3651d6d3cd883bc1124d",
    "size": 490
  },
  "layers": [
    {"mediaType": "application/vnd.ollama.image.model",    "digest": "sha256:e5a44e5a8c7c31d572d002d48e9ae37354adf6973d45b2085802260c14a7274d", "size": 65369799840},
    {"mediaType": "application/vnd.ollama.image.template", "digest": "sha256:fa6710a93d78da62641e192361344be7a8c0a1c3737f139cf89f20ce1626b99c", "size": 7240},
    {"mediaType": "application/vnd.ollama.image.license",  "digest": "sha256:f60356777647e927149cbd4c0ec1314a90caba9400ad205ddc4ce47ed001c2d6", "size": 11353},
    {"mediaType": "application/vnd.ollama.image.params",   "digest": "sha256:12e88b2a8727339b5a4a8b3e2d0d637ac1c61085b1072e77865f0c25d6e468eb", "size": 28}
  ]
}

Config blob:

{
  "model_format": "gguf",
  "model_family": "gptoss",
  "model_families": ["gptoss"],
  "model_type": "116.8B",
  "file_type": "MXFP4",
  "architecture": "amd64",
  "os": "linux",
  ...
}

Environment

Note on architecture: amd64

The config blob for both :120b and :20b reports "architecture": "amd64" while the host is aarch64. The 20b variant pulls fine despite the same architecture stamp, so this doesn't seem to be the cause — but flagging it in case it interacts with model-size handling.