Test de CUA-Lite : un meilleur harness pour agents computer-use ?

Un agent capable d’utiliser un ordinateur ne se limite pas à un modèle : il lui faut un poste de travail, un navigateur ou un téléphone à piloter, ainsi qu’un évaluateur fiable. CUA-Lite est une plateforme ouverte de Berkeley RDI, lancée en 2026, qui cible précisément cette couche manquante. Son principal atout est de fournir des environnements GUI reproductibles sans /dev/kvm ; sa limite majeure est que Docker n’offre pas la même frontière de sécurité qu’une machine virtuelle.

Verdict sur CUA-Lite : une infrastructure utile, pas un nouvel agent

CUA-Lite n’est ni un modèle de fondation ni une application d’automatisation grand public. C’est un framework qui réunit agents, sandboxes, jeux de données, évaluation, fine-tuning supervisé (SFT) et reinforcement learning (RL) pour des environnements desktop, navigateur et mobile. Le site officiel du projet et le dépôt GitHub annoncent plus de 30 000 tâches vérifiables, plus de 10 jeux de données, plus de 10 agents intégrés et plus de 15 benchmarks.

Ces chiffres reflètent l’étendue publiée du projet, pas un niveau de performance identique pour toutes les intégrations. CUA-Lite mérite un pilote lorsque la préparation des environnements ou l’accès à /dev/kvm constitue le principal frein ; ce n’est pas un remplacement systématique de l’isolation par VM.

Une architecture pensée pour réutiliser les mêmes briques

CUA-Lite réduit le code de raccord habituellement répété entre les interactions, les données et les objets de résultat utilisés par l’évaluation comme par l’entraînement.

lite.gym unifie les interactions

L’interface lite.gym fournit des captures d’écran et des informations d’accessibilité, puis reçoit des clics, glisser-déposer, frappes clavier et invocations Bash. Les identifiants suivent un format composable, par exemple lite.demo@create_file ou lite.osworld@osworld_chrome_030eeff7.

Une même factory d’agent peut ainsi viser plusieurs familles d’environnements. Cela ne supprime pas les installations propres à chaque environnement : WebArena, AndroidWorld et les environnements desktop conservent leur documentation de configuration distincte.

LiteSample met les données d’entraînement au même format

LiteSample enregistre des actions unitaires ou des trajectoires sous forme de données Parquet accompagnées d’images. Le dépôt répertorie notamment les corpus convertis Aguvis, CAGUI, GUI-360, GUIAct, GUIOdyssey, Multimodal-Mind2Web, OpenCUA, ScaleCUA et UI-Genie-Agent.

Des adaptateurs par modèle transforment ces enregistrements communs selon le format de prompt et d’historique attendu par chacun. Le stockage reste donc unifié, tandis que le scaffolding demeure spécifique à chaque modèle.

Un même résultat pour l’évaluation et l’entraînement

Une trajectoire échantillonnée renvoie un LiteRLSample contenant episode_return, les indicateurs de terminaison, les étapes de chaque tour et le LiteSample sous-jacent. Le dépôt définit episode_return comme une récompense de tâche, où 1.0 correspond à une réussite. Un rollout noté peut donc servir de résultat d’évaluation ou de donnée d’entraînement, sans second schéma de tâche.

C’est particulièrement utile pour la distillation par rejection sampling et le RL : une équipe peut conserver les trajectoires réussies, les utiliser pour le fine-tuning, puis exploiter les récompenses de l’environnement pour GRPO. Cela ne démontre toutefois pas qu’une politique se généralise au-delà des tâches sélectionnées.

Lite.OSWorld améliore surtout la portabilité, pas la vitesse

L’affirmation la plus concrète de CUA-Lite concerne Lite.OSWorld : les tâches et évaluateurs OSWorld s’exécutent dans un conteneur Docker GNOME, plutôt que dans une machine virtuelle QEMU/KVM.

Le chiffre de 4.6× correspond essentiellement au ratio mémoire : 4.1 divisé par 0.9 donne environ 4.56. Il ne signifie ni un modèle 4.6× plus rapide, ni des tâches exécutées 4.6× plus vite ; le démarrage à froid gagne 6.1 secondes, soit environ 20.4%. Le bénéfice pratique est de tourner sur des infrastructures cloud et CI compatibles Docker, sans exposer /dev/kvm.

L’analyse technique de SnackOnAI interprète elle aussi ce chiffre de densité comme un calcul mémoire, et souligne que les charges desktop réelles peuvent rester limitées par le GPU. MarkTechPost rapporte des scores identiques entre Lite.OSWorld et la VM OSWorld sur 13 modèles. Les résumés publiés ne donnent ni matrice d’accord par tâche, ni intervalles de confiance, ni tableau de scores par modèle : cette parité doit donc être vérifiée sur votre propre charge de travail.

Quand le compromis Docker n’est plus acceptable

Les conteneurs Docker partagent le noyau de l’hôte, tandis qu’une VM ajoute une frontière d’hyperviseur ; la documentation de sécurité de Docker rappelle que l’isolation des conteneurs dépend des contrôles du noyau et de la configuration. Pour des tâches de benchmark fiables, c’est souvent un compromis réaliste. En revanche, des commandes shell arbitraires générées par un modèle exigent une architecture plus stricte. Utilisez une VM éphémère externe ou conservez QEMU/KVM pour le code non fiable.

Les exemples desktop documentés par CUA-Lite reposent sur GNOME/Linux. Une infrastructure VM complète reste le choix le plus sûr pour les redémarrages, le comportement du BIOS, les opérations sur disque brut, les modules noyau personnalisés et les tests dépendant d’un comportement OS de bas niveau. Les images applicatives et X11 headless doivent également être validées pour les tâches sensibles au pixel : elles ne doivent pas être présumées identiques à un pipeline d’affichage natif.

Ce que CUA-Lite permet d’exécuter aujourd’hui

Le dépôt répertorie les familles d’agents et groupes d’environnements suivants :

La page d’accueil présente cette couverture comme plus de 15 benchmarks ; le README compte 16 intégrations lorsque les groupes listés sont additionnés. La prise en charge par registre n’est pas clé en main : clés API, serving de modèles locaux et préparation des environnements restent variables.

Un essai CUA-Lite minimal mais utile

Utilisez la section évaluation du README officiel comme un test progressif, au lieu de supposer que « one command » signifie absence totale de configuration.

1. Installez les dépendances avec uv sync --all-extras ; n’initialisez le sous-module Slime que si l’entraînement est nécessaire.
2. Lancez le démarrage rapide lite.demo@create_file avec gpt-5.5 et enregistrez la trajectoire.
3. Exécutez une petite évaluation lite.osworld avec la configuration de modèle correspondante, puis inspectez summary.json.
4. Répétez la même classe de tâches dans OSWorld d’origine si la parité influence une décision de production.
5. Mesurez la mémoire, l’utilisation GPU, le temps de réinitialisation et l’accord par tâche sur vos propres images applicatives.

Le README montre Qwen/Qwen3-VL-8B-Instruct avec --concurrency 256 pour ScreenSpot-Pro, mais --concurrency 8 pour Lite.OSWorld. Prévoyez des budgets de concurrence distincts entre grounding statique et tâches desktop avec état.

Résultats d’entraînement et piège de configuration

Le dépôt documente un exemple SFT : Qwen3-VL-2B-Instruct entraîné sur des trajectoires desktop Lite.ScaleCUA, puis évalué sur un split lite.osworld de 332 tâches avec deux GPU. Lors de cette exécution rapportée, le retour moyen par épisode passe de 0.138 à 0.237.

Il s’agit d’un exemple documenté, pas d’un résultat général reproduit indépendamment. Le README précise que la configuration Qwen compacte réduit la résolution et utilise history_n=1 afin de tenir dans la VRAM d’entraînement. Évaluez le checkpoint avec la même configuration compacte que celle employée à l’entraînement ; basculer vers le réglage par défaut en pleine résolution peut faire paraître un fine-tune valide défectueux, simplement parce que le harness a changé.

Pour le RL, CUA-Lite documente GRPO sur MobileGym, avec 416 tâches réparties dans 28 applications. Les commandes font appel à un serveur d’environnement et à un conteneur d’entraînement Slime. Les sources ne fournissent ni coût d’entraînement universel, ni durée murale, ni gain de taux de réussite.

FAQ CUA-Lite

CUA-Lite est-il open source ?

Le projet publie son code sur GitHub et ses jeux de données via Hugging Face. Vérifiez la licence actuelle du dépôt ainsi que celle de chaque jeu de données avant toute adoption commerciale : pouvoir télécharger gratuitement un élément ne remplace pas une revue de licence.

CUA-Lite est-il un modèle ?

Non. CUA-Lite est une plateforme et un harness qui relient des modèles API ou locaux pris en charge à des environnements, jeux de données, benchmarks et flux de travail SFT et RL.

CUA-Lite peut-il remplacer les VM OSWorld ?

Uniquement dans le périmètre de charge de travail qu’il vise. Utilisez Lite.OSWorld pour l’évaluation GUI portable et fiable lorsque la RAM ou /dev/kvm est un facteur limitant. Conservez une frontière VM pour le code hostile, les tâches OS de bas niveau ou les workflows nécessitant le comportement natif de Windows/macOS.

CUA-Lite se comprend avant tout comme un harness d’agents computer-use moins coûteux et plus portable. Le compromis encore ouvert n’est pas de savoir si les conteneurs économisent de la mémoire dans la comparaison publiée, mais si vos tâches nécessitent l’isolation et la fidélité bas niveau apportées par la VM.