# Benchmark grounding — UI-TARS-1.5-7B (`0000/ui-tars-1.5-7b-q8_0:7b`) vs gemma4

**Date :** 2026-06-08
**Modèle évalué :** `0000/ui-tars-1.5-7b-q8_0:7b` (UI-TARS-1.5-7B, grounder GUI spécialisé, q8_0)
**Backend :** Ollama `http://localhost:11434` (tunnel DGX)
**Harness réutilisé :** identique aux benchs gemma4 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`).

---

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

1. **UI-TARS ne peut PAS être benché : l'import Ollama sur le DGX est cassé.** Le GGUF re-téléchargé est **text-only, sans son projecteur de vision (mmproj/CLIP)**. Toute requête avec image est rejetée par Ollama.
2. **Preuve dure et reproductible** : `/api/chat` → `HTTP 500 "image input is not supported - hint: ... you may need to provide the mmproj"` ; `/api/generate` → `HTTP 400 "Multimodal data provided, but model does not support multimodal request"`. Sur les 16 cas, **0 appel image abouti**.
3. **Confirmé par les métadonnées du modèle** : `capabilities = ['tools', 'completion']` — **pas de `vision`** ; `projector_info = {}` ; un seul blob `FROM`, aucun `ADAPTER`/mmproj. À comparer à `gemma4:26b` (`vision` présent) et `qwen2.5vl:7b-rpa` (`vision` présent).
4. **UI-TARS ne bat donc PAS gemma4:26b en grounding aujourd'hui : il ne tourne pas du tout en multimodal.** Accuracy non mesurable (modèle aveugle aux images). Le text-only répond (0,5 s) mais part en hallucination culinaire (« a quick, easy and healthy recipe ») — le template Ollama de cet import n'est même pas le format UI-TARS attendu.
5. **Impact production à signaler** : `core/execution/input_handler.py` appelle **exactement ce modèle** au niveau 2 de la cascade (`_grounding_ui_tars`, ligne 591) et il figure dans `FALLBACK_VLM_MODELS` (`core/detection/vlm_config.py:41`). En l'état, **le grounding niveau 2 retourne HTTP 500 en silence** sur le DGX. **gemma4:26b reste l'acteur grounding de référence.**

---

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

| Modèle | Accuracy | Correct/16 | Clics dangereux | Cible démo « Enregistrer » | Latence/appel |
|---|---|---|---|---|---|
| **UI-TARS-1.5-7B** (`0000/...q8_0`) | **N/A — modèle aveugle** | 0/16 (aucun appel image abouti) | N/A | **Échec dur (HTTP 500/400)** | image rejetée ; text-only ~0,5 s |
| gemma4:26b | 0,6875 | 11/16 | **0** | 1/2 (b2090514 ✅ ~centre, b2de7a6a abstain) | ~mesuré le 2026-06-08 |
| gemma4:31b | 0,7500 | 12/16 | 1 | (cf. rapport 31b) | ~plus lent |
| qwen2.5vl:7b-rpa | 0,5625 | 9/16 | **6** | (cf. rapport qwen) | ~rapide |

> Chiffres gemma4/qwen re-vérifiés via le scoreur sur les prédictions existantes (`accuracy 0.6875 dangerous 0` pour 26b, `0.75 dangerous 1` pour 31b, `0.5625 dangerous 6` pour qwen2.5vl). La ligne UI-TARS est vide **non par choix méthodo mais par impossibilité technique** : pas d'inférence vision possible.

---

## Détail technique du blocage (mesures réelles)

### Appel image — `/api/chat`
```
HTTP 500
{"error":{"code":500,"message":"image input is not supported -
 hint: if this is unexpected, you may need to provide the mmproj"}}
```

### Appel image — `/api/generate`
```
HTTP 400
{"error":{"code":400,"message":"Multimodal data provided, but model
 does not support multimodal request"}}
```

### Métadonnées Ollama (`/api/show`)
| Champ | UI-TARS (`0000/...`) | gemma4:26b | qwen2.5vl:7b-rpa |
|---|---|---|---|
| `capabilities` | `['tools','completion']` | `['completion','vision','tools','thinking']` | `['completion','vision']` |
| `projector_info` | `{}` (vide) | présent | présent |
| blobs `FROM` | 1 seul, pas d'`ADAPTER`/mmproj | — | — |
| `family` | `qwen2vl` | — | — |

### Test text-only (sanity)
- Sans image : `HTTP 200` en **0,5 s**, le modèle charge bien sur le DGX.
- Réponse au prompt `"Click on 'Enregistrer'"` (text-only, sans écran) : `" to a quick, easy and healthy recipe"` → le template Ollama de cet import ne correspond pas au format de sortie UI-TARS (`click(start_box='(x,y)')`). L'import est doublement défaillant : pas de vision **et** template inadéquat.

---

## Ce qui était prévu (et reste valide quand le modèle sera réparé)

Le harness UI-TARS-natif était prêt :
- **Entrée** : screenshot + instruction courte `Click on '<target>'`.
- **Sortie attendue** : `click(start_box='(576,312)')`, coordonnées **normalisées 0-1000** → `x_frac = 576/1000`, parsing regex sur `start_box` (déjà implémenté en prod : `core/execution/input_handler.py:_parse_ui_tars_coordinates`).
- **Pas de mode thinking**, prompt direct.

Dès que le modèle est réimporté **avec son mmproj**, ce harness peut produire la ligne manquante du tableau sans autre changement (mêmes 16 cas, même scoreur → comparaison directe valide).

---

## Limites sur écrans santé FR

Non évaluables ce jour : le modèle ne voit aucune image. **Aucune conclusion ne peut être tirée** sur la robustesse d'UI-TARS face aux écrans Easily Assure / Windows FR, ni sur la cible démo « Enregistrer ». Toute affirmation contraire serait infondée.

---

## Cause racine & remédiation

**Cause :** le pull `0000/ui-tars-1.5-7b-q8_0:7b` (upload communautaire Hub) ne package que le GGUF du LLM, **sans le fichier mmproj** (projecteur vision CLIP). UI-TARS étant intrinsèquement un VLM, sans projecteur il est aveugle.

**Remédiation (à valider avec Dom) :**
1. Réimporter via un Modelfile incluant le mmproj : `FROM ui-tars-1.5-7b.gguf` **+** `FROM ui-tars-1.5-7b-mmproj.gguf` (récupérer le mmproj depuis la même source GGUF).
2. Vérifier après import : `capabilities` doit contenir `vision`, `projector_info` non vide.
3. Sanity image avant de relancer le bench : un appel `/api/chat` avec image doit renvoyer `HTTP 200`.

---

## Recommandation — acteur grounding

**Garder `gemma4:26b` comme acteur grounding de référence sur le DGX.** Justification chiffrée :
- gemma4:26b : **0 clic dangereux** sur 16 cas, accuracy 0,6875, vise correctement la cible démo b2090514 (~centre de la zone attendue) — c'est le compromis sûreté/précision le plus défendable face à une audience clinique.
- gemma4:31b : meilleure accuracy (0,75) mais **1 clic dangereux** → arbitrage sûreté à trancher.
- qwen2.5vl:7b-rpa : rapide mais **6 clics dangereux** → écarté pour le runtime santé.
- **UI-TARS** : indisponible (import cassé). Tant que le mmproj n'est pas réintégré, **ne pas compter dessus au niveau 2** ; pire, l'appel niveau 2 en prod échoue actuellement en `HTTP 500` silencieux.

**Action prioritaire indépendante du bench :** comme `input_handler.py:591` et `vlm_config.py:41` pointent ce modèle cassé, le niveau 2 de la cascade et le fallback VLM sont **inopérants sur le DGX** jusqu'à réimport correct. À signaler à Dom (impact runtime, pas seulement bench).

---

## Garanties méthodo

- Aucun token, secret ni identité patient dans ce rapport.
- Mesures réelles, échec rapporté honnêtement (UI-TARS n'a pas pu être benché — c'est le résultat, pas une approximation).
- Aucun code de production modifié ; tous les scripts de test sont jetables (`/tmp/vlm_bench/`).