Dom/rpa_vision_v3
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(dgx): snapshot consolidation WIP pour transfert poc DGX
Some checks failed
tests / Lint (ruff + black) (push) Failing after 1m44s
Details
tests / Tests unitaires (sans GPU) (push) Failing after 1m49s
Details
tests / Tests sécurité (critique) (push) Has been skipped
Details

Browse Source 
Regroupe le WIP non committé requis pour le clone/runtime DGX (Option A) :
- api_stream.py : préflight replay + smoke santé modèles + handler 403 WP-B
- de-hardcode VLM : vlm_config, gpu/*, vram_orchestrator, ollama_manager
- stream_processor, semantic_matcher, agent_chat (app/planner/intent)
- workflows.db (acquis ; le transfert artifacts le mettra à jour + rewrite chemins)
- docs : plans DGX, benchmarks VLM/grounders, recherche SOTA, coordination 8 juin

Snapshot destiné à la branche poc-dgx poussée sur Gitea pour cloner le DGX.
Scan anti-secret : clean. graphify (repo embarqué) exclu.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Dom
2026-06-08 16:33:58 +02:00
parent f18de016d7
commit 6d34b3cb68
204 changed files with 15744 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
docs/recherche/2026-06-08_SOTA_grounders_et_moteurs_inference.md Normal file
View File

@@ -0,0 +1,141 @@
# SOTA grounders GUI + moteurs d'inférence — recherche tranchée
> Date : 2026-06-08 · Auteur : recherche assistée · Projet : rpa_vision_v3
> Objectif : aider Dom à TRANCHER quel grounder GUI et quel moteur d'inférence adopter
> Contraintes : 100 % local (pas de cloud), santé (sécurité de clic forte), écrans Windows applicatifs + web FR accentués, cible matériel = NVIDIA DGX Spark (GB10, Grace Blackwell, aarch64, sm_121).
---
## TL;DR — reco tranchée
**Modèle : Holo1.5-7B** (grounder spécialisé Computer-Use, open-weight) comme grounder principal, **InfiGUI-G1-7B en challenger/fallback**.
**Moteur : vLLM** (image `vllm/vllm-openai:cu130-nightly`, serveur OpenAI-compatible) sur le DGX Spark ; **Transformers (HF)** comme filet de sécurité si un build vLLM casse.
**Ne PAS servir le grounder via Ollama** : bug récurrent de perte du `mmproj` (projecteur vision) sur les imports GGUF Qwen-VL → vision silencieusement cassée. Ollama reste OK pour le chat/décision texte, pas pour le grounding.
UI-TARS-1.5 n'est **plus** le meilleur choix mi-2026 pour le pur grounding : il est dépassé par Holo1.5 et InfiGUI-G1 sur ScreenSpot-Pro à taille égale (7B). UI-TARS reste pertinent comme agent natif bout-en-bout (planner+actor), pas comme grounder le plus précis.
---
## 1. État de l'art des grounders GUI (mi-2026)
### Le benchmark qui compte : ScreenSpot-Pro
ScreenSpot-Pro est le benchmark de grounding le plus dur : 1 581 instructions, 23 applications professionnelles, 3 OS, **cibles minuscules (0,07 % de la surface écran en moyenne** vs 2,01 % pour ScreenSpot d'origine), haute résolution. C'est le test le plus représentatif d'écrans applicatifs denses type Easily Assure / DPI. ScreenSpot-V2 est plus facile (cibles larges) et sature au-dessus de 90 % — peu discriminant désormais.
Sources : [arXiv 2504.07981](https://arxiv.org/abs/2504.07981), [HF blog ScreenSpot-Pro](https://huggingface.co/blog/Ziyang/screenspot-pro).
### Deux familles à ne pas confondre
- **Grands VLM généralistes** (Qwen3-VL, Qwen3.5, GPT-5.x, Claude, Gemini) : scores élevés mais via raisonnement/taille, latence et VRAM lourdes.
- **Grounders spécialisés Computer-Use** (Holo1.5, InfiGUI-G1, UI-TARS, OS-Atlas, UGround) : petits (3B/7B), optimisés localisation, déployables localement.
### Classement — grounders spécialisés open-weight (taille ≤ 7B, focus santé/local)
Scores ScreenSpot-Pro (avg), source = paper InfiGUI-G1 ([arXiv 2508.05731](https://arxiv.org/html/2508.05731v1)) et blog Holo1.5 ([hcompany.ai](https://www.hcompany.ai/blog/holo-1-5)) :
| Rang | Modèle | Taille | ScreenSpot-Pro | ScreenSpot-V2 | Base | Licence |
|------|--------|--------|----------------|---------------|------|---------|
| 1 | **Holo1.5-7B** | 7B | **57,9 %** | ~93 % | Qwen2.5-VL | open-weight (HF) |
| 2 | **InfiGUI-G1-7B** | 7B | **51,9 %** (58,0 % avec exploration) | 93,5 % | Qwen2.5-VL-7B | **Apache-2.0** |
| 3 | Qwen2.5-VL-7B (généraliste) | 7B | 47,6 %* | 88,8 % | — | Apache-2.0 |
| 4 | InfiGUI-G1-3B | 3B | 45,2 % | 91,1 % | Qwen2.5-VL-3B | Apache-2.0 |
| 5 | OS-Atlas-Base-7B | 7B | 41,4 %* | 85,1 % | — | open |
| 6 | UI-TARS-1.5-7B | 7B | **35,7 %** | 91,6 % | — | open |
\* Valeurs telles que reportées dans les tables comparatives du paper InfiGUI-G1 (les chiffres exacts varient selon protocole d'éval ; OS-Atlas a aussi été reporté à ~18,9 % en éval full-screen stricte plus ancienne — [emergentmind](https://www.emergentmind.com/topics/screenspot-pro)).
**Holo1.5 existe en 3B / 7B / 72B**, gain annoncé de +10 % d'accuracy vs Holo1, présenté comme nouvel état de l'art localisation surpassant UI-TARS-1.5 ([MarkTechPost 2025-09](https://www.marktechpost.com/2025/09/18/h-company-releases-holo1-5-an-open-weight-computer-use-vlms-focused-on-gui-localization-and-ui-vqa/)).
### Classement — grands VLM généralistes (réf. plafond, leaderboard llm-stats)
Source : [llm-stats ScreenSpot-Pro](https://llm-stats.com/benchmarks/screenspot-pro) (snapshot juin 2026). Note : ce leaderboard ne liste PAS les grounders spécialisés, seulement les gros VLM/propriétaires.
| Modèle | Score | Type |
|--------|-------|------|
| Claude Opus 4.8 | 0,879 | propriétaire (cloud) |
| GPT-5.2 | 0,863 | propriétaire (cloud) |
| Qwen3.5-122B-A10B | 0,704 | open (lourd) |
| Qwen3.5-27B | 0,703 | open |
| Qwen3-VL-235B-A22B | 0,620 | open (lourd) |
| Qwen3-VL-30B-A3B | 0,605 | open |
| **Qwen3-VL-4B** | **0,595** | open (léger !) |
| Qwen3-VL-8B | 0,546 | open |
| Qwen2.5-VL-7B | 0,290 | open |
> Fait notable : **Qwen3-VL-4B Instruct atteint 0,595 sur ScreenSpot-Pro** — supérieur à Holo1.5-7B (0,579) pour 4B. Si confirmé hors-leaderboard, c'est un candidat sérieux par son rapport précision/VRAM. À benchmarker en interne (le leaderboard llm-stats utilise un protocole différent des papers spécialisés, comparaison à prendre avec prudence).
### Extrapolation (non sourcée directement) — UI-TARS-2
Aucune source fiable < 6 mois ne confirme un « UI-TARS-2 » publié comme grounder dédié supérieur mi-2026. Les avancées 2025-2026 référencées (UI-AGILE, LASER, ScreenSeekeR, GUI-G, POINTS-GUI-G, UI-Venus-1.5) sont surtout des techniques/papers, pas des modèles open-weight prêts à déployer aussi matures que Holo1.5/InfiGUI-G1. **À considérer comme veille, pas comme option de prod aujourd'hui.**
---
## 2. Moteur d'inférence : Ollama vs vLLM vs Transformers vs SGLang
### (a) Préservation correcte de la vision — critère éliminatoire pour un grounder
- **Ollama = risque réel sur la vision.** Bugs ouverts et récurrents en 2026 : imports GGUF Qwen-VL + `mmproj` qui s'enregistrent comme « vision-capable » mais **plantent ou ignorent l'image** au premier appel image, alors que les **mêmes fichiers fonctionnent avec llama.cpp** (`llama-mtmd-cli --mmproj`). Exemples : [ollama#16264](https://github.com/ollama/ollama/issues/16264), [ollama#14388](https://github.com/ollama/ollama/issues/14388), [ollama#14730](https://github.com/ollama/ollama/issues/14730). → Pour du grounding (où une coordonnée fausse = clic dangereux), c'est rédhibitoire. C'est exactement le piège déjà rencontré sur ce projet (`RPA_VLM_MODEL` perdu/mmproj).
- **vLLM / SGLang / Transformers** : chargent le modèle vision natif (safetensors HF), pas de conversion GGUF lossy du projecteur. Vision préservée par construction.
### (b) Latence / débit
Sources : [particula.tech](https://particula.tech/blog/sglang-vs-vllm-inference-engine-comparison), [yottalabs](https://www.yottalabs.ai/post/vllm-vs-sglang-which-inference-engine-should-you-use-in-2026), [sesamedisk](https://sesamedisk.com/local-inference-engines-2026-comparison/).
| Moteur | TTFT / débit | Vision VLM | Déploiement |
|--------|--------------|-----------|-------------|
| **vLLM** | TTFT ~10 ms (GPTQ), ~6× plus rapide qu'Ollama ; PagedAttention | oui, large support VLM | serveur OpenAI-compatible, multi-postes facile |
| **SGLang** | +29 % débit vs vLLM sur charges à contexte partagé (RadixAttention) ; meilleur en multi-tours/agents | oui (VLM supporté) | container CUDA, OpenAI-compatible |
| **Transformers (HF)** | plus lent (pas de batching avancé) mais référence de correction | oui, support modèle le plus précoce | simple à scripter, dur à scaler |
| **Ollama** | TTFT ~65 ms ; mono-utilisateur, ne scale pas | **vision fragile (cf. a)** | ultra-simple mais plafonne |
### (c) Déploiement multi-postes
vLLM et SGLang exposent une API OpenAI-compatible → un serveur central (le DGX) sert N postes Léa. Ollama est pensé mono-utilisateur. Transformers nécessite d'écrire son propre service.
### Reco communauté
Pour du **grounding GUI temps-réel local** : **vLLM** est le défaut robuste (écosystème, support VLM, multi-postes), **SGLang** si charge concurrente/agents multi-tours élevée. **Ollama à éviter pour la branche vision** du pipeline.
---
## 3. Faisabilité sur DGX Spark (GB10, aarch64, sm_121, CUDA 12/13, Ubuntu 24.04)
### Statut mi-2026 : ça marche, mais via stack dédiée sm_121
- **vLLM : officiellement supporté.** Le blog officiel vLLM du **2026-06-01** documente le DGX Spark : serveur OpenAI-compatible standard, image **`vllm/vllm-openai:cu130-nightly`** (CUDA 13), flags tunés mémoire unifiée (`--gpu-memory-utilization 0.85`, `--max-num-seqs 4`). ([vllm.ai blog](https://vllm.ai/blog/2026-06-01-vllm-dgx-spark)).
- **SGLang : supporté** via containers `v0.5.10.post1-cu130` (multi-arch arm64, CUDA 13) ; NVIDIA fournit un guide officiel [build.nvidia.com/spark/sglang](https://build.nvidia.com/spark/sglang). Suivi : [sglang#11658](https://github.com/sgl-project/sglang/issues/11658).
- **Transformers : OK** via l'image NGC PyTorch 25.11 (PyTorch 2.10), seule source fiable de PyTorch ARM64 + CUDA Blackwell.
### Pièges concrets (sourcés)
1. **Wheels ARM64 manquants** : PyTorch 2.9.0 cu124 n'a **pas** de wheels ARM64 (index officiel = x86_64 only). Il faut l'image NGC PyTorch 25.11 (PyTorch 2.10 ARM64+CUDA) ou builds nightly cu130. ([vllm#36821](https://github.com/vllm-project/vllm/issues/36821)).
2. **sm_121 hors plage** : les binaires PyTorch packagés ne compilent les kernels que jusqu'à sm_120 → `vLLM` peut échouer au démarrage si on utilise une roue standard. Résolu par les images cu130-nightly / forks dédiés (PR vllm#31740). ([vllm#31128](https://github.com/vllm-project/vllm/issues/31128)).
3. **CUDA 13 vs 12** : kernels précompilés attendant CUDA 12 → erreurs `libcudart.so.12` sur système CUDA 13. Utiliser la stack cu130 cohérente.
4. **flash-attn** : pas de wheel ARM/sm_121 stable garanti ; certaines stacks le désactivent. Ne pas forcer flash-attn sans validation.
5. **Débit modéré** : la mémoire unifiée LPDDR5X plafonne le débit. Repères mesurés communauté : Qwen3.5-35B-A3B ~31 tok/s, Qwen3.5-122B-A10B ~51 tok/s, modèles denses ~27B BF16 ~4 tok/s. Un grounder 7B sera nettement plus rapide, mais le DGX Spark n'est pas une bête de course — **dimensionner sur 7B max pour le temps-réel.** ([forums NVIDIA](https://forums.developer.nvidia.com/t/run-qwen3-5-27b-with-spark-vllm-docker/362563), [github adadrag](https://github.com/adadrag/qwen3.5-dgx-spark)).
6. **VLM vision confirmée** : un guide communautaire confirme image description, OCR, object detection, spatial reasoning fonctionnels en VLM sur Spark via vLLM. ([github adadrag](https://github.com/adadrag/qwen3.5-dgx-spark)).
> Conséquence pratique : la stack DGX Spark est **jeune mais utilisable** (juin 2026). Épingler une image (digest), pas un tag « nightly » mouvant. Garder le plan B x86 RTX 5070 si instabilité (cf. décision POC existante).
---
## 4. Reco synthèse (tranchée)
| Critère | Choix | Pourquoi |
|---------|-------|----------|
| **Grounder principal** | **Holo1.5-7B** | meilleur ScreenSpot-Pro sub-10B (57,9 %), spécialisé Computer-Use, surpasse UI-TARS-1.5, base Qwen2.5-VL (déjà maîtrisée dans le projet), tient en 7B sur le Spark |
| **Grounder fallback** | **InfiGUI-G1-7B** | 51,9 % (58 % avec exploration), **licence Apache-2.0 nette**, même base Qwen2.5-VL → swap trivial, bon sur icônes |
| **À benchmarker en interne** | **Qwen3-VL-4B** | 0,595 reporté pour seulement 4B → meilleur ratio précision/VRAM/latence si confirmé sur écrans FR |
| **Moteur** | **vLLM** (`cu130-nightly`, OpenAI-compatible) | vision préservée (pas de GGUF), supporté DGX Spark officiellement, multi-postes Léa via API |
| **Moteur filet** | **Transformers (HF)** image NGC 25.11 | référence de correction si build vLLM casse ; même poids safetensors |
| **À NE PAS faire** | servir le grounder via **Ollama** | bug mmproj/vision GGUF récurrent → coordonnées fausses → clics dangereux (inacceptable en santé) |
### UI-TARS reste-t-il le bon choix ?
**Non, plus comme grounder pur.** À taille 7B, UI-TARS-1.5 (35,7 % SS-Pro) est nettement derrière Holo1.5 (57,9 %) et InfiGUI-G1 (51,9 %). UI-TARS garde de la valeur comme **agent natif end-to-end** (planner+actor+grounder intégré), mais le contrat « grounder précis » de rpa_vision_v3 est mieux rempli par Holo1.5/InfiGUI-G1.
### Sécurité de clic (santé)
Aucun modèle n'atteint 100 % sur SS-Pro (plafond open ~58 %). → Conserver la **cascade de validation existante** (OCR/template + vérification état UI avant/après clic) AU-DESSUS du grounder VLM. Le grounder propose une coordonnée, la cascade vérifie. Ne jamais cliquer sur la seule sortie VLM sans garde-fou. Cela renforce le choix d'un moteur à vision fiable (vLLM/Transformers) plutôt qu'Ollama.
### Notes de prudence (faits vs extrapolation)
- **Faits sourcés** : scores Holo1.5/InfiGUI-G1/UI-TARS, support officiel vLLM/SGLang sur DGX Spark, bugs Ollama mmproj, pièges ARM/sm_121.
- **À vérifier en interne** : protocoles d'éval différents entre llm-stats (gros VLM) et papers spécialisés → ne pas comparer les deux tables ligne à ligne sans re-benchmark maison sur écrans Easily Assure FR. Le score Qwen3-VL-4B vient du leaderboard généraliste, pas d'un paper grounder dédié.
- **Pas de UI-TARS-2 mûr** identifié mi-2026 ; rester en veille.
---
## Sources
- [ScreenSpot-Pro — arXiv 2504.07981](https://arxiv.org/abs/2504.07981) · [HF blog](https://huggingface.co/blog/Ziyang/screenspot-pro) · [emergentmind](https://www.emergentmind.com/topics/screenspot-pro)
- [InfiGUI-G1 — arXiv 2508.05731](https://arxiv.org/html/2508.05731v1) · [HF InfiGUI-G1-7B](https://huggingface.co/InfiX-ai/InfiGUI-G1-7B) · [GitHub InfiXAI](https://github.com/InfiXAI/InfiGUI-G1)
- [Holo1.5 — blog H Company](https://www.hcompany.ai/blog/holo-1-5) · [MarkTechPost](https://www.marktechpost.com/2025/09/18/h-company-releases-holo1-5-an-open-weight-computer-use-vlms-focused-on-gui-localization-and-ui-vqa/) · [HF Holo1.5-7B](https://huggingface.co/Hcompany/Holo1.5-7B)
- [llm-stats ScreenSpot-Pro leaderboard](https://llm-stats.com/benchmarks/screenspot-pro)
- Moteurs : [particula.tech](https://particula.tech/blog/sglang-vs-vllm-inference-engine-comparison) · [yottalabs](https://www.yottalabs.ai/post/vllm-vs-sglang-which-inference-engine-should-you-use-in-2026) · [sesamedisk](https://sesamedisk.com/local-inference-engines-2026-comparison/)
- Ollama vision/mmproj : [#16264](https://github.com/ollama/ollama/issues/16264) · [#14388](https://github.com/ollama/ollama/issues/14388) · [#14730](https://github.com/ollama/ollama/issues/14730)
- DGX Spark : [vLLM blog 2026-06-01](https://vllm.ai/blog/2026-06-01-vllm-dgx-spark) · [vllm#31128](https://github.com/vllm-project/vllm/issues/31128) · [vllm#36821](https://github.com/vllm-project/vllm/issues/36821) · [sglang#11658](https://github.com/sgl-project/sglang/issues/11658) · [build.nvidia.com/spark/sglang](https://build.nvidia.com/spark/sglang) · [github adadrag/qwen3.5-dgx-spark](https://github.com/adadrag/qwen3.5-dgx-spark) · [forums NVIDIA Qwen3.5-122B](https://forums.developer.nvidia.com/t/qwen3-5-122b-a10b-on-single-spark-up-to-51-tok-s-v2-1-patches-quick-start-benchmark/365639)