Installer llama.cpp sur Debian 12 et héberger ton LLM “HAL” (API + WebUI)

But : installer llama.cpp sur Debian 12, lancer un modèle GGUF (ex: Qwen2.5 7B) via un service systemd, et utiliser la WebUI.
Chemin repo (chez toi) : /home/llama.cpp
Chemin modèles (SSD conseillé) : /home/llama.cpp/models/...

Sommaire

Installer les prérequis
Cloner et compiler llama.cpp
Mettre le modèle sur SSD (gros gain)
Tester llama-server à la main
Créer un service systemd propre (HAL)
Logs : journalctl + fichier + logrotate
WebUI : build via Docker (sans npm local)
Fix Vite “Blocked request / allowedHosts”
Dépannage rapide (UI “Server unavailable”, cache, alias…)

Prérequis Debian 12 (compilation CPU)

Installez le minimum :

sudo apt update
sudo apt install -y git build-essential cmake pkg-config

Optionnel mais pratique :

sudo apt install -y htop curl jq

Astuce ✅
Même si vous n’installez pas Node/npm sur ta Debian, vous pouvez builder la WebUI via Docker (voir plus bas). Zéro pollution système.

Cloner llama.cpp au bon endroit

Vous utilisez ce “Path” :

cd /home
git clone https://github.com/ggml-org/llama.cpp.git
cd / /home/llama.cpp

Compiler llama.cpp (CPU)

Compilation simple (CMake) :

cmake -S . -B build
cmake --build build -j"$(nproc)"

Vérifiez que le serveur est là :

ls -lh build/bin/llama-server

Attention ⚠️ (GPU)
Si vous voyez dans les logs : warning: no usable GPU found, c’est normal si vous compilez CPU-only. L’option --gpu-layers est ignorée tant que vous n’avez pas compilé avec support GPU.

Mettre le modèle sur SSD (le meilleur “tweak”)

Vous l’avez constaté : HDD/USB = chargement lent, SSD = chargement quasi instant.

Préparez un répertoire modèles sur SSD :

sudo mkdir -p /home/llama.cpp/models/qwen2.5-7b
sudo chown -R lolo:lolo /home/llama.cpp

Exemple de modèles (GGUF) :

qwen2.5-7b-instruct-q4_k_m.gguf (~4.4G)
qwen2.5-7b-instruct-q5_k_m.gguf (~5.1G)

Astuce ✅
Si tu as une WebUI qui dit “Server unavailable” au démarrage, c’est souvent juste que tu l’ouvres pendant le chargement du modèle. Sur SSD ça disparaît en quelques secondes.

Test rapide : lancer `llama-server` à la main

Avant systemd, on teste :

/home/llama.cpp/build/bin/llama-server \
  -m /home/llama.cpp/models/qwen2.5-7b/qwen2.5-7b-instruct-q5_k_m.gguf \
  -t 18 -tb 18 \
  -c 32768 \
  -np 4 \
  -ngl 0 \
  -fa auto \
  --host 0.0.0.0 --port 8080

Vérifiez l’écoute :

ss -lntp | grep 8080

Créer un service systemd “HAL” (production propre)

Créez le fichier :

sudo nano /etc/systemd/system/llama-server.service

Exemple de service (propre, stable)

[Unit]
Description=llama.cpp server (HAL) - Qwen2.5 7B Q5
After=network.target

[Service]
Type=simple
User=lolo
WorkingDirectory=/home/llama.cpp

ExecStart=/home/llama.cpp/build/bin/llama-server \
  -m /home/llama.cpp/models/qwen2.5-7b/qwen2.5-7b-instruct-q5_k_m.gguf \
  -t 18 -tb 18 \
  -c 32768 \
  -np 4 \
  -ngl 0 \
  -fa auto \
  --host 0.0.0.0 --port 8080 \
  --alias HAL-Qwen2.5-7B-Q5 \
  --chat-template-file / /home/llama.cpp/templates/hal-chatml.jinja \
  --cache-type-k q4_0 --cache-type-v q4_0

Restart=on-failure
RestartSec=2
Environment=LLAMA_LOG_COLORS=auto
TimeoutStopSec=20
KillSignal=SIGINT
LimitNOFILE=65535
Nice=5

# Logs en fichier (optionnel)
StandardOutput=append:/var/log/llama-server.log
StandardError=append:/var/log/llama-server.log

Activez et démarrez :

sudo systemctl daemon-reload
sudo systemctl enable --now llama-server.service
sudo systemctl status llama-server.service --no-pager

Suivre les logs :

sudo journalctl -u llama-server.service -b -f -o short-iso

Attention ⚠️ (cache navigateur / alias)
Si l’UI affiche encore un ancien nom (ex: “HAL-Qwen…Q4”) alors que vous avez changé --alias, c’est souvent le cache de la conversation côté navigateur (ou storage local). Nouveau chat / refresh hard / vider storage peut suffire.

Logs propres : logrotate (si tu logges en fichier)

Si vous avez mis StandardOutput=append:/var/log/llama-server.log, ajoute une rotation :

sudo nano /etc/logrotate.d/llama-server

/var/log/llama-server.log {
  daily
  rotate 14
  compress
  missingok
  notifempty
  copytruncate
}

Test (sans appliquer) :

sudo logrotate -d /etc/logrotate.d/llama-server

Installer / builder la WebUI (sans npm local)

Vous avez fait la méthode “clean” : build via Docker Node.

Va dans :

cd /home/llama.cpp/tools/server

Build :

docker run --rm -u "$(id -u):$(id -g)" \
  -v "$PWD:/srv" -w /srv/webui \
  node:20-bullseye \
  bash -lc "npm ci || npm install && npm run build"

Résultat : ça écrit dans tools/server/public/ (ex: index.html.gz).

Astuce ✅
Si tu avais des erreurs EACCES mkdir ../public/_app/..., c’est quasiment toujours un problème de répertoire cible non writable ou un montage Docker pas au bon niveau. Le montage -v "$PWD:/srv" -w /srv/webui (depuis tools/server) est le bon.

Fix Vite preview : “Blocked request. This host is not allowed.”

Si vous lancez un npm run preview et que Vite bloque debian12, modifie :

📍 Fichier : tools/server/webui/vite.config.js

Ajoutez allowedHosts :

import { defineConfig } from "vite";
import { sveltekit } from "@sveltejs/kit/vite";

export default defineConfig({
  plugins: [sveltekit()],

  server: {
    host: true,
    allowedHosts: ["hostname", "localhost", "127.0.0.1"],
  },

  preview: {
    host: true,
    port: 4173,
    strictPort: true,
    allowedHosts: ["debian12", "localhost", "127.0.0.1"],
  },
});

Attention ⚠️
Exposer preview sur le LAN, c’est pratique, mais pensez à sécuriser derrière (reverse-proxy, auth, firewall).

Dépannage express

UI “Server unavailable” pendant ~1–2 minutes

Le modèle charge encore (surtout si modèle sur HDD/USB).
Solution : mettre le GGUF sur SSD (tu l’as fait → ~3s).

Vérifier que le serveur répond

curl -s http://127.0.0.1:8080/health | jq .

Vérifier les slots (si endpoint actif)

curl -s http://127.0.0.1:8080/slots | jq . 2>/dev/null || true

Conclusion

Avec ce setup, vous obtennez :

un LLM local stable via systemd,
des temps de chargement ultra courts grâce au SSD,
une WebUI buildée proprement via Docker,
des logs “propres” (journalctl + fichier + rotation).