feat(scale): ML inference scaling (Triton Inference Server + GPU pool + batch + queue)

[Yanstart]

Cadrage stratégique 2026 (mai 2026) — PIVOT PRODUIT

ML inference passage à l'échelle pour produit multi-tenant. Foundation
models = volumes GPU significatifs, doivent être servis efficacement.
Voir `.claude/memory/VISION_ALIGNMENT.md §0.6`.

Contexte

Aujourd'hui : 3 backends `MLWorkerProvider` (subprocess, in-process, Triton stub).
Inference largement "in-process" — modèle chargé dans le worker FastAPI.
Acceptable PoC. Pour un produit multi-tenant servant N modèles fine-tunés
(un par tenant, Wave 10), il faut un serveur d'inférence dédié.

Cible

1. Triton Inference Server activé en production (le stub Wave 4 sprint 11 devient implémentation complète)
2. GPU pool partagé : 1 cluster GPU sert tous les tenants, pas 1 GPU par tenant
3. Batch inference : N requêtes regroupées en 1 batch GPU pour throughput
4. Queue + back-pressure : si GPU saturé, queue avec back-pressure 429 / Retry-After
5. Model hot-swap : déploiement nouveau modèle sans downtime
6. Multi-tenant model registry : Triton sert `tenant_id/model_name/version`

Approche technique proposée

1. `backend/services/ml/worker_provider/triton_worker.py` : implémentation complète (le stub actuel)
2. Triton config : `triton/model_repository/` avec foundation models UNI/CONCH/Virchow + fine-tuned per tenant
3. Batching : configuration Triton dynamic batching (preferred batch size, max queue delay)
4. Queue + back-pressure : ajout d'une queue Redis (Wave 13 #N13) entre FastAPI et Triton, FastAPI répond 202 Accepted + polling endpoint
5. Model auto-loading : Triton load on demand, unload after timeout
6. Métriques Prometheus : Triton expose nativement métriques (requests, batch size, GPU utilization, queue depth)

Acceptance criteria

• `TritonClientMLWorker` complet (plus stub)
• Triton container ajouté à `docker-compose.yml --profile prod`
• Foundation models UNI/CONCH/Virchow déployables sur Triton
• Dynamic batching configuré et testé (throughput ×3 vs no-batch)
• Queue Redis avec back-pressure 429 si saturé
• Model auto-loading on demand (pas tous les modèles RAM en permanence)
• Multi-tenant : isolation modèles par tenant (Triton model_repository structuré par tenant)
• Tests de charge : 50 req/s simultanés sans crash
• Métriques Prometheus exposées + dashboard Grafana
• Documentation runbook `docs/Admin/services/ml-inference-triton.md`

Dépendances

• Wave 10 N1 (foundation model registry) : alimente Triton model_repository
• Wave 10 N2 (fine-tuning workflow) : produit les modèles à servir
• Wave 13 feat(scale): multi-tenant data isolation + auth federation #354 (multi-tenant) : isolation modèles per tenant
• Wave 13 #N13 (cache + WS) : Redis pour queue
• Wave 13 #N14 (observability) : métriques Triton

Références

• `.claude/memory/VISION_ALIGNMENT.md §0.6`
• Existing : `backend/services/ml/worker_provider/triton_worker.py` (stub)
• Triton : https://github.com/triton-inference-server/server
• Dynamic batching : https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/user_guide/model_configuration.html#dynamic-batcher