- Titre "Backend llama.cpp" -> "MOTEUR".
- Passage au vouvoiement dans tous les textes de la section.
- Nouveau lien "verifier la version" sur chaque moteur (rapide/optimise) :
interroge la derniere version dispo (endpoints check existants) SANS installer,
et affiche le resultat en toast avant tout lancement d'install.
- BIN devient un libelle lisible : "rapide" (moteur precompile), "optimise"
(compile), ou "custom : <chemin>" sinon (via in_use / prebuilt.in_use de
/api/llamacpp). Le chemin complet reste en tooltip.
- Ajout d'une ligne "n-cpu-moe" quand --n-cpu-moe est present dans EXTRA_ARGS.
Nouvel endpoint /api/ram (lecture /proc/meminfo, used/total en Mo, 0 hors Linux)
et bloc RAM dans la sidebar a cote du GPU, rafraichi toutes les 3 s. Masque si
pas de /proc/meminfo (Windows/mac).
Les modeles hybrides (Laguna S 2.1) qui repondent SANS reflechir n envoyaient
que `content` (ni reasoning_content, ni </think>, retire par le backend a
--reasoning-format). jean, avec REASONING=on, supposait un bloc <think> ouvert
par le prompt et vidait toute la reponse dans la bulle thinking. On streame
desormais le contenu en direct par defaut et on ne bascule en reasoning qu au
vu d un </think> reel. La coupe de la queue anti-</think> est realignee sur une
frontiere de rune UTF-8 pour ne plus casser les accents (e -> mojibake).
Corrige la confusion : deux endroits ecrivaient la ligne BIN et se battaient
(la barre laterale changeait le BIN global + redemarrait, puis selectionner un
preset remettait le BIN du preset). Desormais :
- la section laterale 'Backend llama.cpp' sert UNIQUEMENT a installer / mettre
a jour les moteurs (rapide / optimisee), elle ne change plus le BIN actif
- le choix du moteur se fait PAR MODELE, dans l'editeur de preset, avec 3
options claires : Rapide (precompile) / Optimise (compile) / Personnalise
(chemin libre ou backend depose dans le dossier backends de jean, detecte)
- detection auto de l'option a l'ouverture selon le BIN du preset ; l'astuce
indique le dossier ou deposer un binaire custom
- /api/llamacpp expose backends_dir ; l'endpoint /use n'est plus utilise par l'UI
v0.4.11
Refonte de la section pour la rendre utilisable sans connaissances techniques :
- suppression du badge a cote du titre et de tous les details (commit, retard
git, arch CUDA, nombre de jobs, chemins) ; une seule ligne 'Moteur actif : …'
- deux cartes claires : Version rapide (precompile, conseillee) / Version
optimisee (compilee) ; un clic installe, active ou bascule
- bascule instantanee entre deux versions deja installees (nouvel endpoint
/api/llamacpp/use : repointe BIN + redemarre, sans recompiler)
- carte active : '✓ Actif' + 'mettre a jour' ; progression et logs replies sous 'details'
Alternative rapide a la compilation locale : telechargement des binaires
officiels de ggml-org/llama.cpp publies a chaque release (~2 min au lieu de
~40 de build CUDA). Le variant est choisi selon la machine (CUDA Windows avec
selection de la version selon le pilote + cudart, Vulkan, Metal, ROCm, CPU),
extrait dans backends/llama.cpp-prebuilt et BIN repointe dessus.
- backend_prebuilt.go : detection release/variant, telechargement avec
progression, extraction zip/tar.gz anti zip-slip, marqueur VERSION
- UI : bouton 'binaires precompiles' + 'compiler (sources)', le statut
distingue le mode actif (precompile vs build local), 'verifier les maj'
compare a la derniere release officielle en mode precompile
- CLI : 'jean llamacpp prebuilt'
- le build local reste sur le disque : bascule possible via l'editeur de preset
Limites : builds generiques (pas de tuning natif) ; pas de build CUDA officiel
Linux (variant Vulkan) ; la compilation locale reste requise pour les forks.
Apres une MAJ depuis l'UI, plus besoin de SSH sur le serveur pour finir : sur
Linux/systemd le service jean-link est relance tout seul (differe + --no-block,
la reponse HTTP part d'abord ; jean.service/llama-server n'est PAS touche pour
ne pas recharger le modele). La cle E2E survit au restart, l'UI se reconnecte
seule. Poste client/Windows : comportement inchange (message d'indice).
Le chat E2E d'app.ajean.link traverse Cloudflare (ajean.link, proxy orange) qui
bufferise le flux SSE par lots : la queue du replay arrivait 20-30s apres le reste,
de facon intermittente (surtout Safari iOS). Corrige par la technique standard :
padding d'amorcage en tete de flux + padding sur caught_up (force le flush de la
queue), Cache-Control: no-transform (interdit a Cloudflare de bufferiser/compresser),
et heartbeat 15s->4s (borne le pire cas).
Au refresh, le client rejouait tout le journal depuis seq 0 et forcait un reflow
synchrone par evenement (scrollMaybe lisait scrollHeight ; collapseInstant lisait
offsetHeight) sur un DOM grandissant -> cout quadratique, 20-30s pour que les
derniers messages s'affichent. Le scroll est desormais fait une seule fois a la
fin du replay (caught_up), plus aucun reflow force pendant le rejeu -> O(n).
- Compaction automatique du contexte facon Hermes (head/torso/tail, elagage des
vieux tool outputs + resume du torse par le modele local) : discussions quasi
illimitees sans 'vider', declenchee sur le vrai decompte de tokens
- Historique et generation deplaces CToe SERVEUR : une seule conversation partagee
entre tous les appareils, persistee sur disque, generation autonome (fermer le
navigateur n'arrete plus la reponse), replay complet au refresh (outils/vitesses)
- Un seul process (jean-link) sert le tunnel ET le :8090 local -> meme historique
entre jean.n27.fr et app.ajean.link
- Relais toujours 100% boite noire (chiffrement E2E inchange)
- Nombreux polish UI (replay coalesce rapide, pas de clignotement au refresh, envoi
resilient, reorganisation des reglages)
Le process jean-link sert desormais AUSSI l'UI locale sur :8090 avec le MEME mux
que le tunnel -> une seule conversation en memoire, partagee entre jean.n27.fr et
app.ajean.link. Fini les deux process avec des historiques divergents qui
s'ecrasaient sur le meme fichier. Le 'jean web' autonome n'est plus necessaire.
nathaninline