GitLab

- FROM /path/to/{safetensors,pytorch}
- FROM /path/to/fp{16,32}.bin
- FROM model:fp{16,32}

The model processing was recently changed to be deferred but
this test scenario hadn't been adjusted for that change in behavior.

This moves all the env var reading into one central module
and logs the loaded config once at startup which should
help in troubleshooting user server logs

This also bumps up the default to be 50 queued requests
instead of 10.

This gives us more headroom on the scheduler tests to tamp
down some flakes.

log when the waiting for the process to stop to help debug when other tasks execute during this wait.
expire timer clear the timer reference because it will not be reused.
close will clean up expireTimer if calling code has not already done this.

fix runner expire during active use.  Clearing the expire timer as it is used.  Allowing the finish to assign an expire timer so that the runner will expire after no use.

- return descriptive error messages when unauthorized to create blob or push a model
- display the local public key associated with the request that was denied

Prior refactoring passes accidentally removed the logic to bypass VRAM
checks for CPU loads.  This adds that back, along with test coverage.

This also fixes loaded map access in the unit test to be behind the mutex which was
likely the cause of various flakes in the tests.

* reload model if `num_gpu` changes

* dont reload on -1

* fix tests

Give the go routine a moment to deliver the expired event

This change adds support for multiple concurrent requests, as well as
loading multiple models by spawning multiple runners. The default
settings are currently set at 1 concurrent request per model and only 1
loaded model at a time, but these can be adjusted by setting
OLLAMA_NUM_PARALLEL and OLLAMA_MAX_LOADED_MODELS.

* terminate subprocess if receiving `SIGINT` or `SIGTERM` signals while model is loading

* use `unload` in signal handler

This is a quick fix to help users who are stuck on the "pull" step at
99%.

In the near future we're introducing a new registry client that
should/will hopefully be smarter. In the meantime, this should unblock
the users hitting issue #1736.