Error: read GGUF metadata "...": unsupported tensor "blk.12.ffn_up.weight" offset+size exceeds file size means the model file on disk is shorter than its own header says: the blob was cut off, usually by an interrupted copy or a full disk. Remove the model with ollama rm and pull it again. A plain ollama pull on top of it prints success and leaves the broken file where it is.

To see which file is damaged, compare each blob with the manifest. Every blob is named after the SHA-256 hash of its content, so a size or hash that does not match its own name is proof.

The error

PS> ollama run qwen2.5:0.5b "Reply with the single word ready."
Error: read GGUF metadata "C:\\...\\models\\blobs\\sha256-c5396e06af294bd101b30dce59131a76d2b773e76950acc870eda801d3ab0515": unsupported tensor "blk.12.ffn_up.weight" offset+size exceeds file size

Why it happens

A pulled model is a manifest plus a few blobs in models\blobs; the large one is the GGUF file with the weights. Before Ollama starts a runner it reads the GGUF header, which lists every tensor and where it starts. When a tensor would end past the end of the file, it stops with this message. Other damage shows other faces of the same problem: 

Error: read GGUF metadata "...": unsupported file type [88 88 88 88]
Error: 500 Internal Server Error: llama-server process has terminated: exit status 1: error loading model: llama_model_loader: failed to load model from ...
Error: prediction aborted, token repeat limit reached

The first came from overwriting the four bytes that should read GGUF. Neither GGUF reader message left a line in the server log; only the client printed it. A tensor shape changed in the header got past that reader and stopped the llama-server runner instead, with the log naming a tensor whose offset was not the expected one. The worst case is the last: 64 KiB of garbage inside the weights, same file size, loaded without complaint and the model printed @@@@ until Ollama aborted it. Nothing in that message points at the file.

A plain pull does not help, apparently because a blob with the right name is already there. In the test, ollama pull showed 100% for the 200 MB stub and for the same-size damaged copy, printed verifying sha256 digest and success, and the blob afterwards was exactly as damaged as before.

The fix

param([string]$Models = "$env:USERPROFILE\.ollama\models", [string]$Name = 'qwen2.5', [string]$Tag = '0.5b')
$manifest = Join-Path $Models "manifests\registry.ollama.ai\library\$Name\$Tag"
$m = Get-Content $manifest -Raw | ConvertFrom-Json
foreach ($layer in @($m.config) + @($m.layers)) {
    $file = Join-Path $Models ('blobs\' + ($layer.digest -replace ':', '-'))
    if (-not (Test-Path $file)) { '{0,-45} missing' -f $layer.mediaType; continue }
    $size = (Get-Item $file).Length
    $hash = 'sha256:' + (Get-FileHash $file -Algorithm SHA256).Hash.ToLower()
    $state = 'ok'
    if ($size -ne $layer.size) { $state = 'WRONG SIZE' } elseif ($hash -ne $layer.digest) { $state = 'WRONG HASH' }
    '{0,-45} {1,10} of {2,10} bytes  {3}' -f $layer.mediaType, $size, $layer.size, $state
}
PS> .\check-blobs.ps1 -Models $env:OLLAMA_MODELS
application/vnd.ollama.image.model             397807936 of  397807936 bytes  WRONG HASH
PS> ollama rm qwen2.5:0.5b
deleted 'qwen2.5:0.5b'
PS> ollama pull qwen2.5:0.5b
...
success
PS> .\check-blobs.ps1 -Models $env:OLLAMA_MODELS
application/vnd.ollama.image.model             397807936 of  397807936 bytes  ok
PS> ollama run qwen2.5:0.5b "Reply with the single word ready."
ready

Save the first block as check-blobs.ps1. On a default Windows install run it without -Models; the test passed its own folder. Only the model layer's line is shown above; the small layers all read ok. ollama rm removed the damaged blob with the model, so the next pull had to download it again, and the run answered normally.

How it was reproduced

On Windows 11 with Ollama 0.40.11 in Windows PowerShell 5.1, against a separate ollama serve on 127.0.0.1:15101 with its own OLLAMA_MODELS folder; that port and folder are the test's own, so the installed app's models were never touched. qwen2.5:0.5b was pulled (a 397,807,936-byte GGUF blob) and a Python script, with the original kept aside, cut the blob to 200,000,000 bytes, overwrote its first four bytes, halved one tensor dimension in the header, and wrote 64 KiB of 0xFF into the middle. Each copy was run with ollama run, and the fix was confirmed with the hash check and a one-word reply.

Frequently asked

How do I fix a corrupted Ollama model?
Remove it with ollama rm and pull it again. In the test a plain ollama pull over a damaged blob printed success and left the file unchanged; only rm followed by pull downloaded it again and the model answered normally.
How can I check whether an Ollama model file is corrupted?
Every file in the models blobs folder is named after its SHA-256 hash, and the manifest lists each blob's size. Compute the hash, for example with Get-FileHash on Windows, and compare it with the name. Any difference means the file is damaged.
Why does Ollama print @@@@ and then 'token repeat limit reached'?
In the test this came from a model blob with damaged bytes inside the weights: the file had the right size, loaded, and produced garbage until Ollama stopped it. Check the blob's hash first; if it matches, the file is not the cause.

More decoded errors in the Fixes category. If the runner ends with signal: killed instead, the file is fine and memory is short: llama-server process has terminated: signal: killed.