# Benchmark grounders GUI SOTA via vLLM sur DGX Spark

**Date :** 2026-06-08
**Infra :** NVIDIA DGX Spark (GB10, aarch64, sm_121, 121 Go mémoire unifiée), `aivanov@192.168.1.45`
**Moteur :** vLLM `vllm/vllm-openai:cu130-nightly` (image arm64 déjà pullée, ID `ffa30d66ff5c`), API OpenAI-compatible
**Modèles évalués :** InfiGUI-G1-7B, Holo1.5-7B, Qwen3-VL-4B-Instruct (un seul servi à la fois, container recréé)
**Harness :** identique aux benchs gemma4/qwen2.5vl du 2026-06-08 — mêmes 16 cas LeaBench (`benchmarks/computer_use/cases/leabench_extended_2026-05-24.jsonl`), mêmes images, même scoreur (`core.evaluation.computer_use_bench`). Scripts jetables dans `/tmp/vlm_bench/`. **Aucun code de production modifié, Ollama (`:11434`) non touché.**

---

## Résumé exécutif (verdict tranché)

1. **vLLM démarre proprement sur le DGX Spark (ARM64/Blackwell) pour les 3 modèles.** Pas de blocage flash-attn : vLLM sélectionne `FLASH_ATTN v2` et il fonctionne. Aucun flag exotique nécessaire — **le seul piège réel a été la mémoire** (voir §Montage). `--enforce-eager` non nécessaire.
2. **Gagnant net : Qwen3-VL-4B-Instruct.** Avec garde-fou de présence : **accuracy 0,875 (14/16), 1 seul clic dangereux, ~1,1 s/cas, cible démo « Enregistrer » 2/2.** Meilleur que tous les gemma4 et que les deux grounders spécialisés, **pour seulement 4B**. Confirme le pari du leaderboard llm-stats sur écrans FR réels.
3. **Les grounders « spécialisés » (Holo1.5, InfiGUI-G1) sont d'excellents localisateurs mais de mauvais décideurs seuls.** En sortie brute (raw, toujours-clic) ils visent juste sur les vraies cibles mais cliquent partout sur les écrans pièges → 9 à 12 clics dangereux. Leur sécurité dépend entièrement d'un gate externe.
4. **Reste-t-il sûr ? Non en standalone.** Aucun modèle n'atteint 0 clic dangereux + haute accuracy seul. **La cascade de validation existante (OCR/template + vérif état UI avant/après clic) reste obligatoire AU-DESSUS du grounder.** Le grounder propose, la cascade vérifie.
5. **Moteur recommandé : vLLM `cu130-nightly`, `--gpu-memory-utilization 0.40`** (Ollama occupe ~42 Go de la mémoire unifiée). Vision native préservée (safetensors HF, pas de GGUF/mmproj) — exactement ce qu'il fallait après l'échec UI-TARS/Ollama.

---

## Tableau comparatif (LeaBench 16 cas — même harness, comparaison directe)

Protocole « gated » = grounding natif + une passe de présence (yes/no) donnant au grounder pur une chance d'abstenir équitablement (identique au protocole du bench UI-TARS). « raw » = localisateur pur, toujours-clic si parsable (expose le comportement brut et les clics dangereux sans garde-fou).

| Modèle | Variante | Accuracy | Correct/16 | Clics dangereux | Cible démo « Enregistrer » | Latence/cas | Parsable | Licence |
|---|---|---|---|---|---|---|---|---|
| **Qwen3-VL-4B-Instruct** | **gated** | **0,875** | **14/16** | **1** | **2/2 ✅** | **~1,1 s** | 14/16 | Apache-2.0 |
| Qwen3-VL-4B-Instruct | raw | 0,4375 | 7/16 | 9 | 2/2 ✅ | ~1,0 s | 14/16 | Apache-2.0 |
| Holo1.5-7B | gated | 0,5625 | 9/16 | 4 | 0/2 (gate trop strict) | ~3,2 s | 16/16 | Apache-2.0 |
| Holo1.5-7B | raw | 0,25 | 4/16 | 12 | 2/2 ✅ (localisation) | ~3,0 s | 16/16 | Apache-2.0 |
| InfiGUI-G1-7B | gated | 0,50 | 8/16 | 7 | 2/2 ✅ | ~14,6 s | 16/16 | Apache-2.0 |
| InfiGUI-G1-7B | raw | 0,3125 | 5/16 | 11 | 2/2 ✅ (localisation) | ~14,3 s | 16/16 | Apache-2.0 |
| — *référence Ollama* — | | | | | | | | |
| gemma4:31b | — | 0,75 | 12/16 | 1 | (cf. rapport 31b) | (plus lent) | — | — |
| gemma4:26b | — | 0,6875 | 11/16 | **0** | 1/2 | (mesuré 06-08) | — | — |
| qwen2.5vl:7b-rpa | — | 0,5625 | 9/16 | 6 | (cf. rapport qwen) | (rapide) | — | — |
| qwen3vl:8b (Ollama) | — | 0,3125 | 5/16 | 0 | — | — | — | — |
| UI-TARS-1.5-7B (Ollama) | — | N/A (aveugle, import sans mmproj) | 0/16 | N/A | échec HTTP 500 | — | — | — |

> Chiffres gemma4/qwen re-vérifiés via le scoreur sur les prédictions existantes (`gemma4:26b` 0,6875/0 dangereux ; `gemma4:31b` 0,75/1 ; `qwen2.5vl:7b-rpa` 0,5625/6 ; `qwen3vl:8b` 0,3125/0). Latences vLLM = moyenne mesurée sur les 2 appels (grounding + présence) des 16 cas.

---

## Montage vLLM (statut OK + flags utilisés)

**Commande de référence (identique pour les 3 modèles, seul `--model` change) :**
```
docker run -d --name vllm-grounder --device nvidia.com/gpu=all \
  -p 8000:8000 -v ~/.cache/huggingface:/root/.cache/huggingface --ipc=host \
  vllm/vllm-openai:cu130-nightly \
  --model <repo> --port 8000 \
  --gpu-memory-utilization 0.40 --max-num-seqs 4 --max-model-len 8192 \
  --trust-remote-code
```

| Modèle | Repo HF | Démarrage | Détails |
|---|---|---|---|
| InfiGUI-G1-7B | `InfiX-ai/InfiGUI-G1-7B` | **OK** | archi `Qwen2_5_VLForConditionalGeneration`, KV cache 496k tokens, init ~60 s |
| Holo1.5-7B | `Hcompany/Holo1.5-7B` | **OK** | base Qwen2.5-VL, non-gated, download ~16 Go |
| Qwen3-VL-4B-Instruct | `Qwen/Qwen3-VL-4B-Instruct` | **OK** | archi `Qwen3VLForConditionalGeneration`, KV cache 253k tokens, init ~63 s |

**Pièges rencontrés et résolution :**
1. **Mémoire (le vrai blocage, pas l'ARM).** Avec `--gpu-memory-utilization 0.85` (recommandation blog vLLM Spark) : `ValueError: Free memory on device cuda:0 (79.65/121.63 GiB) ... less than desired (103.38 GiB)`. **Ollama + autres process occupent ~42 Go de mémoire unifiée.** Résolu en passant à **0.40** (un 7B + KV cache tient largement dans ~48 Go ; concurrence max 60×).
2. **flash-attn : aucun problème.** Contrairement à la crainte du doc recherche, vLLM cu130-nightly utilise `FLASH_ATTN v2` sans crash sur sm_121. `--enforce-eager` **non nécessaire**.
3. **CUDA 13 / sm_121 :** l'image `cu130-nightly` gère nativement, aucune erreur `libcudart.so.12`.
4. Aucun modèle gated, aucun token HF requis (warning rate-limit bénin).

Sanity vision confirmé pour chaque modèle (`/v1/chat/completions`, image base64 data-URI, HTTP 200, sortie non vide et au bon format coordonnées).

---

## Format natif par modèle (le piège « prompt unifié » évité)

Chaque modèle a un format distinct — adapté individuellement, **résolu empiriquement quand la doc était ambiguë.**

- **InfiGUI-G1-7B** (model card HF) : système `<think></think>` ; user `The screen's resolution is {W}x{H}. Locate the UI element(s) for "{instr}", output ... [{"point_2d":[x,y]}]`. Sortie = **pixels de l'image envoyée** + un bloc `<think>` de raisonnement (d'où sa latence ~10 s). `x_frac = x/W`.
- **Holo1.5-7B** (hai-cookbook H Company) : `Localize an element on the GUI image according to the provided target and output a click position.` + cible. Sortie demandée en JSON `{"action":"click_absolute","x","y}` = **pixels de l'image envoyée**. `x_frac = x/W`. Pas de raisonnement → très rapide.
- **Qwen3-VL-4B** : **format de coordonnées ambigu dans la doc** (issues QwenLM #1486/#1927 : pixels vs 0-1000). **Résolu par sanity call** : sur image 800×500, sortie `{"point_2d":[458,605]}` → en pixels y=605 impossible (>500) ; en **0-1000 normalisé** → (0,458 ; 0,605) ≈ cible connue (0,448 ; 0,612). Donc **coordonnées 0-1000**, `x_frac = x/1000`. **C'est exactement le piège à ne pas rater** : un parsing pixel aurait donné des clics hors écran silencieux.

Particularité Qwen3-VL : il **refuse nativement** sur cible absente (« There are none. », 2/16 non parsables = vraies abstentions du grounder lui-même), ce que ni Holo ni InfiGUI ne font.

---

## Licences (vérifiées)

| Modèle | Licence | Source |
|---|---|---|
| InfiGUI-G1-7B | **Apache-2.0** | model card HF `InfiX-ai/InfiGUI-G1-7B` |
| Holo1.5-7B | **Apache-2.0** | model card HF `Hcompany/Holo1.5-7B` (« License: apache-2.0 ») — *note : le doc recherche le disait « open-weight », il est en réalité Apache-2.0, donc plus permissif qu'attendu* |
| Qwen3-VL-4B-Instruct | **Apache-2.0** | repo `Qwen/Qwen3-VL-4B-Instruct` |

**Les 3 candidats sont Apache-2.0** → déployables en clinique sans friction licence. Bonne nouvelle : le fallback comme le gagnant sont tous deux permissifs.

---

## Verdict tranché

**Grounder recommandé : Qwen3-VL-4B-Instruct, servi par vLLM (`cu130-nightly`, `--gpu-memory-utilization 0.40`).**

Justification chiffrée :
- **Accuracy la plus haute du panel (0,875), 1 seul clic dangereux**, devant gemma4:31b (0,75/1) et gemma4:26b (0,6875/0).
- **Cible démo « Enregistrer » : 2/2** (les deux cas save-as), là où gemma4:26b n'en réussit qu'1/2. Coordonnées (0,458;0,605) et (0,428;0,573) bien dans le rayon.
- **Le plus léger (4B) ET le plus rapide (~1 s/cas)** → meilleur ratio précision/VRAM/latence, idéal multi-postes Léa via l'API vLLM.
- **Apache-2.0**, vision native (pas de GGUF), abstention partiellement native.

**Holo1.5-7B = fallback / challenger.** Localisateur brut excellent (vise juste sur les vraies cibles, 2/2 sur la démo en raw) et très rapide (3 s, pas de CoT), mais son jugement de présence séparé est trop strict (gate refuse 2 vraies cibles) → 0,5625 gated. À reconsidérer si on remplace la passe présence par la cascade interne du projet.

**InfiGUI-G1-7B = écarté pour ce besoin.** Bonne localisation mais le mode `<think>` impose ~14 s/cas (rédhibitoire temps-réel) et son gate de présence est faible (7 clics dangereux). Pas d'avantage face à Qwen3-VL-4B.

**UI-TARS-1.5 : non rebenché** (import Ollama cassé sans mmproj, cf. rapport dédié du 06-08). Le doc recherche le classait déjà dernier des spécialisés — confirmé non prioritaire.

### Sécurité de clic (santé) — reste-t-il sûr ?
**Non en standalone.** Même le gagnant produit 1 clic dangereux/16 et dépend d'une passe de présence externe pour ne pas en produire 9 (cf. variante raw). **Conserver impérativement la cascade de validation existante au-dessus du grounder** (OCR/template + vérification état UI avant/après clic, garde-fou « ne clique pas si pas sûr à 100 % »). Le grounder VLM propose une coordonnée ; la cascade tranche. Choisir vLLM (vision fiable) plutôt qu'Ollama renforce ce contrat.

### Reco moteur
**vLLM `vllm/vllm-openai:cu130-nightly` sur le DGX Spark**, épinglé au digest (pas le tag nightly mouvant), `--gpu-memory-utilization 0.40` tant qu'Ollama cohabite. API OpenAI-compatible → un serveur central sert N postes Léa. Plan B x86 RTX 5070 inutile ici : la stack ARM a tenu sans contournement lourd.

---

## Limites & honnêteté méthodo

- **16 cas seulement** (notepad/save-as/menu Démarrer Windows FR), pas Easily Assure dense haute résolution. Les scores sont indicatifs, pas un verdict ScreenSpot-Pro. Re-bencher sur écrans Easily réels avant décision finale POC.
- Le protocole « gated » mélange grounding natif + une passe présence maison ; il avantage les modèles dont le jugement de présence est calibré (Qwen3-VL) et pénalise les localisateurs purs (Holo). En production, la passe présence sera remplacée par la cascade interne du projet → les chiffres « raw localisation » sont alors plus représentatifs de ce que le grounder apporte vraiment (et là Holo/Qwen3-VL/InfiGUI visent tous juste sur les vraies cibles).
- Latences = mémoire unifiée LPDDR5X du Spark, mono-requête. Le débit multi-postes réel reste à mesurer.
- Aucun secret/token/identité patient dans ce rapport. Container vLLM supprimé en fin de run (`docker rm -f vllm-grounder`), Ollama vérifié intact (HTTP 200).