Plus aucune compilation CUDA : le runtime part de
ghcr.io/ggml-org/llama.cpp:server-cuda (llama-server précompilé et maintenu
par l'équipe amont, backends .so chargés dynamiquement, archs GPU courantes,
repli CPU fonctionnel). Le build complet passe de ~40 min à ~4 min et tous
les pièges du build CUDA sans GPU (stubs libcuda, espace disque du runner,
choix des architectures) disparaissent.
- Dockerfile : 2 étapes (Go + image officielle), build-arg LLAMACPP_IMAGE
pour épingler une version ou passer en CPU/Vulkan
- entrypoint : BIN=/app/llama-server
- workflow GHCR : purge disque et CUDA_ARCHS supprimés, cache max
- compose/.env/README à l'avenant
Validé : build 3 min 55, UI HTTP 200, healthcheck healthy, superviseur PID
OK, llama-server démarre (repli CPU) et n'échoue que sur un modèle factice.
- Dockerfile 3 étapes : llama.cpp CUDA (flags de backend_build.go, sauf
GGML_NATIVE=OFF — l'image est bâtie sur un runner, pas sur la machine
cible), binaire Go statique, runtime CUDA léger (tini, git, nodejs pour
les serveurs MCP npx).
- docker-entrypoint.sh : sème BIN/HOST/PORT (+ MODEL/CTX/NGL depuis l'env,
au premier boot seulement), lance le moteur en supervision PID puis
'loki web' au premier plan. UI seule exposée (8090) ; le moteur (8080,
non authentifié) reste interne.
- Nouvelle commande 'loki config [get|set]' : configuration non interactive
(la config vit dans bbolt, pas dans un fichier plat).
- docker-compose.yml (build local, réservation GPU) + variante Unraid
(image GHCR, runtime nvidia) ; volumes /data (LOKI_HOME) et /models.
Un seul conteneur car llm_client.go joint le moteur sur localhost (hérité
de l'amont).
L'ancien Loki (FastAPI + React + Ollama) est remplacé par le fork d'AJEAN.
Tout reste accessible dans l'historique (git show bb4fb1b:backend/app/agent.py).
Backend :
- agent_config : num_ctx dans la config, envoyé à Ollama (0 = défaut modèle)
- ollama_client : méthode ps() (placement GPU/CPU via /api/ps)
- autotune : placement() lit size vs size_vram pour savoir si le modèle est sur GPU
- routes/config : POST /api/config/auto (détecte GPU + modèle, calcule et applique
num_ctx/max_tokens, renvoie la détection et le placement)
Frontend :
- client/store : autoTune(), état tuning + résultat
- SettingsView : bouton ⚡ Réglage auto, bannière de détection (GPU/VRAM,
contexte, placement GPU/CPU), slider Contexte (num_ctx)
Config :
- GPU_VRAM_MB / GPU_NAME pour déclarer la VRAM si Ollama est distant
Tests : recommandation (8B sur 12 Go -> ctx 32768), route /auto + persistance,
transmission num_ctx aux options Ollama, placement via /api/ps.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SVay7z3y7q2gEe54ByAE6N
Le conteneur écoutait sur 8717 alors que le mapping pointait host:8717 ->
conteneur:8080, d'où la connexion refusée. On standardise sur un seul numéro de
port (8717) identique dedans/dehors, et on laisse le HEALTHCHECK de l'image
gérer le bon port (suppression des healthcheck compose codés en dur sur 8080).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SVay7z3y7q2gEe54ByAE6N
- Sépare le port hôte (HOST_PORT, défaut 8717) du port interne du conteneur (8080)
- docker-compose.yml : mapping ${HOST_PORT:-8717}:8080
- docker-compose.unraid.yml : 8717:8080
- .env.example : HOST_PORT=8717
- README : références de port mises à jour
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SVay7z3y7q2gEe54ByAE6N
Loki
Claude
MichaelandClaude Opus 4.8