dennii/Hermes-Ollama_Models
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

revert: remove Hugging Face model integration

Browse Source
This commit is contained in:
Hermes Agent
2026-08-28 19:30:35 +10:00
parent bc47cf8152
commit 309947d353
7 changed files with 9 additions and 423 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -5
View File
@@ -83,8 +83,6 @@ The full validation scan covered 7,230 raw public variants: 604 were classified
Available downloads now combine Ollama's popular API response with the public `https://ollama.com/library` index and each public family tag page. This means models that are not currently popular and are not installed locally—such as `ornith-1.5:9b` and `ornith-1.5:35b`—are discoverable. The catalog refresh found 235 public family slugs and 7,230 raw variants during validation. The existing MLX exclusion and host-RAM fit filter still apply, so very large variants such as `ornith-1.5:397b` remain hidden when they cannot fit the detected host RAM.
Model search can optionally query the public Hugging Face Hub API when **Search Hugging Face** is checked and the query contains at least two characters. Hugging Face results are labeled **Hugging Face**, show repository metadata such as pipeline, library, downloads, and likes, and include an **Open on Hugging Face** link. Repositories with GGUF files also show **Download GGUF**. The picker groups split GGUF shards into one complete selectable set, downloads all required files, checks available disk space, and imports the first shard into local Ollama with `ollama create` when Ollama shares the dashboard filesystem. Transformers/safetensors/FP8-only repositories remain viewable but are not falsely offered as Ollama downloads. For example, `Qwen/Qwen3.8-Flash-Next` is searchable, while `unsloth/Qwen3.8-Flash-Next-GGUF` exposes complete GGUF sets.
The Live runtime panel now shows overall CPU usage, logical CPU count, load averages, overall GPU utilization, and per-GPU VRAM usage. When multiple logical CPUs are detected, it expands into a scrollable responsive per-core grid. When multiple GPUs are detected, it expands into a responsive per-GPU grid showing utilization, VRAM used/free, temperature, and power when the driver reports them. The grids use auto-fit sizing and bounded scrolling so the panel scales to larger CPU and GPU counts without overflowing the dashboard.
@@ -158,9 +156,7 @@ The dashboard plugin API is mounted when the dashboard starts. Restart Hermes af
## Download storage
The plugin does not store normal Ollama model blobs in Hermes. It sends Ollama's native `POST /api/pull` request to the selected endpoint. Therefore a normal Ollama download goes to the Ollama instance shown in the job message, and the Ollama service owns the model storage location. The exact path is controlled by Ollama's `OLLAMA_MODELS` setting; common Linux service/user locations are `/usr/share/ollama/.ollama/models` and `~/.ollama/models`. Check the Ollama service environment on the target host to determine the authoritative path.
Hugging Face downloads are separate: the checkbox enables Hub search, and **Download GGUF** downloads a selected complete GGUF file or shard set under the Hermes home `huggingface/<owner>/<repository>/` directory. The plugin revalidates the repository metadata and filename, checks free disk space when the Hub publishes sizes, and reports progress in the jobs panel. On a non-containerized host where Ollama is on the same filesystem, it writes a temporary Modelfile and runs `ollama create` to import the GGUF. If Ollama is remote or containerized with a different filesystem, the file is downloaded but automatic import is not attempted; the UI says so explicitly. Transformers, safetensors, and FP8-only repositories remain browseable through their Hugging Face link but are not treated as Ollama-compatible downloads.
The plugin does not store model blobs in Hermes. It sends Ollama's native `POST /api/pull` request to the selected endpoint. Therefore a download goes to the Ollama instance shown in the job message, and the Ollama service owns the model storage location. The exact path is controlled by Ollama's `OLLAMA_MODELS` setting; common Linux service/user locations are `/usr/share/ollama/.ollama/models` and `~/.ollama/models`. Check the Ollama service environment on the target host to determine the authoritative path.
## Security limits