Proposition : Remise en état AI Orchestrator + Win11

Date : 10/02/2026 Status : IMPLEMENTEE Contexte : Depuis la coupure de courant + modifications multi-GPU, instabilité croissante. Wan21 63% d'échec, musicgen plante silencieusement, Ollama 10 000 échecs en 7 jours.

Diagnostic (3 audits réalisés)

Win11 - État actuel

• Ollama DOWN : pas démarré depuis le reboot de 19h48. startup.ps1 lance Ollama SANS CUDA_VISIBLE_DEVICES=0 ni OLLAMA_HOST=0.0.0.0 → écoute locale uniquement, mauvais GPU
• NFS non montés : X: et Y: absents
• Wan2.1 PID 336 bloqué : 16.9 Go RAM, 0% GPU, 0 MiB VRAM - process mort
• Aucun port AI ouvert : ni 11434 (ollama) ni 7867 (musicgen) ni rien d'autre

DB - Erreurs 7 derniers jours

Code - Vulnérabilités identifiées

1. SSH hang cascade : wan21/facefusion → SSH bloque 45min, cleanup SSH aussi → 75min total
2. Musicgen : Gradio API, si process crash → attend 300s pour rien
3. start_tool() : lance ssh -f cmd /c start_tool.bat mais si ça échoue → health check loop 30-180s
4. startup.ps1 incohérent avec start_ollama_gpu0.bat (manque CUDA_VISIBLE_DEVICES et OLLAMA_HOST)

Plan de remise en état (3 phases)

Phase 1 : Fix immédiat win11 (5 min)

1a. Tuer le wan21 zombie et relancer Ollama

# Sur win11 via SSH
taskkill /F /PID 336    # wan21 bloqué
taskkill /F /IM python.exe  # tous les wrappers orphelins

# Monter NFS
cmd /c mount 192.168.1.10:/stock_8to X:
cmd /c mount 192.168.1.10:/stock_36to/data Y:

# Lancer Ollama avec les bons params
$env:CUDA_VISIBLE_DEVICES="0"
$env:OLLAMA_HOST="0.0.0.0:11434"
Start-Process ollama -ArgumentList 'serve' -WindowStyle Hidden

1b. Fix startup.ps1 pour qu'il soit cohérent avec le .bat

# startup.ps1 corrigé
cmd /c mount 192.168.1.10:/stock_8to X:
cmd /c mount 192.168.1.10:/stock_36to/data Y:
$env:CUDA_VISIBLE_DEVICES = "0"
$env:OLLAMA_HOST = "0.0.0.0:11434"
Start-Process 'C:\Users\gouro\AppData\Local\Programs\Ollama\ollama.exe' -ArgumentList 'serve' -WindowStyle Hidden

Phase 2 : Fix start_tool dans l'orchestrateur (code)

Problème : start_tool() lance un .bat via SSH mais n'a aucune garantie que le service démarre. Si le .bat échoue silencieusement, le health check loop attend 30-180s avant de déclarer l'échec.

Fix : Après le SSH start, vérifier le return code SSH ET le health check en parallèle. Si le process SSH échoue → fail immédiatement au lieu de boucler.

Pas de code à écrire maintenant - juste identifier le fix.

Phase 3 : Stabilisation wan21/musicgen

Wan21 :

• Le process generate.py avec --offload_model True charge 16.9 Go en RAM avant de transférer sur GPU
• Si le chargement échoue (RAM insuffisante, fichier modèle corrompu) → process bloqué indéfiniment
• Fix : vérifier que le process écrit dans stdout/stderr pendant l'exécution. Si aucune sortie pendant 2 min → kill

Musicgen :

• Gradio API sur port 7867
• Si le serveur Gradio crash pendant la génération → le GET SSE stream ne retourne jamais
• Le timeout de 300s est la seule protection
• Fix : le watchdog GPU détecte déjà ce cas (ajouté cette session). Réduire la grace period si possible.

Ordre d'exécution proposé

1. Phase 1a : tuer zombie + relancer Ollama (SSH direct, immédiat)
2. Phase 1b : fix startup.ps1 (SSH direct, 2 min)
3. Test : soumettre 1 ollama + 1 wan21 pour vérifier
4. Phase 2 + 3 : dans un prochain commit si besoin, après validation de la stabilité

Ce qui a déjà été fait cette session

• Cleanup jobs fantômes au démarrage (commit 4737cfb)
• Timeout par outil sur la phase generating (commit 4737cfb)
• Watchdog GPU idle pour détecter les jobs morts (commit 63478d4)
• Hook pre_deploy optional: true dans smart-deploy (commit 4d829ff)

Ce qui ne sera PAS touché

• La config multi-GPU (fonctionne pour ollama, le plus gros volume)
• Les timeouts existants sur les outils HTTP (déjà corrects)
• Le code des outils individuels (bark, triposr, yolo, applio - pas de problème identifié)