Moteur : --parallel 1 explicite — la VRAM d'avant est de retour

Les llama-server récents ouvrent 4 slots par défaut : des tampons de
calcul GPU multipliés par quatre, pour un serveur qui ne sert qu'un
utilisateur. Résultat vécu après une mise à jour du moteur : une config
27B qui tournait très bien meurt en « cudaMalloc failed: out of
memory » en pleine génération, sans qu'aucun réglage n'ait changé. On
repasse explicitement à un slot — le comportement historique — et
PARALLEL=n reste disponible dans le preset pour qui veut du parallèle.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/loki/backend_serve.go

@@ -108,6 +108,14 @@ func cmdServe(args []string) error {
 		"-ub", get("UBATCH", "512"),
 		"--host", get("HOST", "0.0.0.0"),
 		"--port", get("PORT", "8080"),
+		// --parallel 1 EXPLICITE : les llama-server récents ouvrent 4 slots par
+		// défaut, soit des tampons de calcul GPU ×4 — pour un serveur mono-
+		// utilisateur comme Loki, c'est de la VRAM brûlée pour rien. Vécu : une
+		// config 27B/60k ctx qui tournait très bien est morte en « cudaMalloc
+		// failed: out of memory » après une mise à jour du moteur, uniquement à
+		// cause de ce nouveau défaut. PARALLEL=n dans le preset pour qui veut
+		// vraiment servir plusieurs requêtes à la fois.
+		"--parallel", get("PARALLEL", "1"),
 	}
 	// NGL=auto : on n'envoie PAS -ngl, et llama.cpp choisit lui-même combien de
 	// couches tiennent dans la VRAM libre (common_fit_params). Il s'en abstient