Infinite loop / CPU 100% in /api/tags when parsing specific GGUF models (e.g. translategemma-12b)

[sealter]

I call curl http://localhost:8080/api/tags , there is no response, and cpu 100%, I remove all models and try again, that's ok. And then I fox pull mradermacher/translategemma-12b-it-GGUF:Q8_0 , try curl http://localhost:8080/api/tags cpu 100% and no response.

curl http://localhost:8080 is ok.

[ManuelSLemos]

Fixed. Good catch on including curl http://localhost:8080/ working, that's what pointed at it straight away.

/api/tags was computing the SHA-256 of every .gguf in the models directory before responding. On my 27 GB models dir that's 51.6 seconds with a core pinned. /api/ps and /api/show did it too. / was instant because it never touches disk, so the server looked dead instead of just slow.

That's why both things you saw happened: with no models there's nothing to hash, and the 12B Q8_0 is ~13 GB on its own.

The reason it got worse rather than better is that the cache was only written after a hash completed, and there was no sharing of work already in flight. Every retry started a fresh hash of the whole directory on another blocking thread. So re-running curl, or Open WebUI polling, just piled more of them up. If you hit this on a build before the fix, the first call does finish eventually and the result is cached until you restart the server, so leaving one call alone is the way through it.

The fix: digest now comes from the file's name, size and mtime instead of its contents. Still sha256:, still changes when you replace a model file, but it identifies the file rather than hashing it. You can't produce a content hash without reading the whole file and a listing endpoint can't afford that. Ollama gets away with a real hash because its blobs are content-addressed and hashed once at pull; fox serves plain GGUFs out of a directory you can also drop files into by hand. Nothing in fox looks up a model by digest, and /api/pull was already emitting sha256:, so nothing was verifying it. It's still a Tier 1 change under the compatibility policy, so it goes in a minor bump.

Same directory now answers in 22 ms, and eight concurrent requests finish in 30 ms. There's a test that lists a 16 GiB sparse file and fails if the endpoint takes more than five seconds.

Two other things fixed while in there:

• modified_at was returning wrong dates. It approximated the calendar as year = 1970 + days/365 with 30-day months, so no leap years and drift within each year. A file touched on 2025-08-04 came back as 2025-08-20. Now uses a proper conversion, checked day by day against the real calendar over 200 years.
• /api/ps was re-reading the models directory once per loaded model. Reads it once now.

In 0.21.0.

[teddytennant]

This looks already fixed. /api/tags used to hash the contents of every .gguf in the models dir on the request path, and the cache was only written after a hash finished with no sharing of in-flight work, which is why retrying made it worse and why / stayed instant. 9f863a9 moved the digest to name+size+mtime and that shipped in 0.21.0, after this was filed.

I reproduced both sides with a 13G sparse file named the way fox pull writes it: 0.20.5 times out at 10s, develop answers in 6ms, and /api/ps and /api/show answer too. Worth a retest on 0.22.1 before closing.