UI-TARS Desktop self-hostable? 32k stelle su GitHub, hardware da datacenter

Free Claude Code, 29k stelle su GitHub: ma di Claude non c'è niente

Free Claude Code spaccia per gratis un proxy che dirotta ANTHROPIC_BASE_URL su 17 backend terzi: claude code alternativa gratis o solo clickbait?

32.000 stelle, hardware da datacenter. UI-TARS Desktop di ByteDance è il computer-use agent open-weights più chiacchierato del 2025, lo scarichi gratis con licenza Apache 2.0 e su GitHub ha appena toccato 32,9k stelle. La parte che nessuno scrive sotto al video YouTube è semplice: il modello che davvero gira in casa è uno solo, il 72B se lo permette solo chi ha una workstation, e il modello frontier — UI-TARS-2 — i pesi non li ha rilasciati affatto.

Open-weights non vuol dire self-hostable. È la sbavatura semantica più diffusa di tutto il 2025 sull'AI locale, e UI-TARS è il caso da manuale per smontarla. Lo dico da uno che ha appena dovuto ammettere, guardando il proprio rack, che il post che stai leggendo nasce dalla domanda "ce la faccio a girarlo io?" — e la risposta, per ora, è no.

La tesi: "i pesi sono pubblici, quindi è tuo"

Il framing dominante su UI-TARS Desktop è che, essendo i pesi del modello pubblici e la licenza Apache 2.0, l'utente medio possa girarlo in casa e bypassare cloud, abbonamenti e API. È vero a metà: i pesi esistono, ma la versione realmente scaricabile è una sola — UI-TARS-1.5-7B, rilasciato il 21 aprile 2025 — e ByteDance sul model card HuggingFace dichiara 29.021 download al mese, segno che la gente effettivamente lo prova.

I numeri sui benchmark, peraltro, sono onesti. Su OSWorld a 100 step UI-TARS-1.5 chiude al 42,5%, contro 36,4% di OpenAI Operator e 28% di Claude 3.7. Su ScreenSpotPro — il test che misura il "grounding" GUI, cioè quanto bene il modello capisce cosa cliccare guardando uno screenshot — UI-TARS sta a 61,6% mentre Claude 3.7 si ferma a 27,7% e Operator a 23,4%. Anche su WindowsAgentArena tocca il 42,1% contro lo state-of-the-art precedente fermo al 29,8%. Tradotto: come modello vision-language per il computer use, è il più forte aperto in circolazione.

Aggiungici l'argomento economico e la suggestione si chiude: sulla pagina OpenRouter il 7B costa 0,10 dollari per milione di token in input e 0,20 in output, con context da 128k, contro circa 3 e 15 dollari di Claude Sonnet sul medesimo pattern computer-use. Un fattore 30 di sconto. Se il modello vince i benchmark, costa una frazione e i pesi sono pubblici, la domanda "perché non lo girano tutti in locale?" sembra retorica. È qui che il framing crolla.

L'antitesi: cosa serve davvero per girarlo a casa

Comincia dal nome. "7B" è branding: i metadati HuggingFace dichiarano 8B parametri effettivi, tensor type F32. Non cambia la vita, ma il taglio comunicativo lo rivela. Il problema vero arriva subito dopo: il 7B in FP16 con KV cache abilitata satura 17 GB di VRAM. Lo certifica un utente sulla issue #15 del repo ufficiale, che sintetizza così: "I just barely fit the 7B model on 17gb using vllm w/ fp8 kv cache". Per chi traduce dalle release di Nvidia: stai parlando di una 3090, una 4090 o una A4000 — non di una GPU consumer da gaming.

Se uno pensa "vado sul 72B che è più grosso", peggio mi sento. Il 72B esiste in GGUF community (bartowski) ma il file Q4_K_M pesa 47,42 GB e l'Q8_0 sfiora i 77 GB. I download su HuggingFace dicono tutto: 1.553 al mese per il 72B contro 29.021 per il 7B. È il rapporto fra chi posta lo screenshot del comando di download e chi davvero lo tiene acceso. Per girare quel modello in modo sensato servono una Mac Studio M3 Ultra con memoria unified da 128 GB o uno chassis con due 3090 in NVLink. Roba da 4.000-6.000 euro di hardware. Il prezzo dell'auto, non del rack.

Dal portafoglio si passa al fatto che il modello frontier, nel frattempo, resta proprietario. Il paper UI-TARS-2 (arXiv 2509.02544, settembre 2025) descrive un'architettura MoE con 230B di parametri totali e 23B attivi, costruita su Seed-thinking-1.6. Score: OSWorld 47,5%, AndroidWorld 73,3%, Online-Mind2Web 88,2%, WindowsAgentArena 50,6%. Pesi pubblici: zero. La pagina HuggingFace del paper è solo descrittiva, la demo gira su sandbox ByteDance. Il messaggio implicito è chiaro: il modello che vince i benchmark di oggi non lo scarichi, il modello aperto resta indietro di una generazione, e l'utente self-hoster lavora di rincorsa.

Il gap che nessun demo YouTube mostra

Il dato meno citato delle demo di UI-TARS è la distanza dal target umano. OSWorld è un benchmark realistico su Linux desktop. Le persone vere chiudono il 72,4% dei task. Tutti i modelli aperti — UI-TARS-1.5 incluso, al 42,5% — stanno trenta punti sotto. Significa che su uno scenario reale di automazione GUI il fallimento è la norma, non l'eccezione. Eppure nei video promozionali si vedono solo i task che hanno funzionato al primo colpo, e la latenza dei tre-quattro tentativi tagliata via in fase di montaggio.

Si aggiunga un dettaglio che la stessa model card ammette: il modello "may occasionally generate inaccurate descriptions, misidentify GUI elements, or take suboptimal actions based on incorrect inferences—especially in ambiguous or unfamiliar environments". Non è una boutade, è la nota del produttore. Drag-and-drop precisi, CAD e video editing restano scogli noti per gli agent GUI in generale — non solo per UI-TARS. Ma il fatto che ByteDance metta nero su bianco hallucination e azioni subottimali, mentre i video gridano "agente autonomo", andrebbe ricordato.

Sicurezza: l'agente che vede (e fa) troppo

Il capitolo sicurezza, per un agente che riceve il permesso Screen Recording e Accessibility sul tuo Mac dovrebbe pesare quanto i benchmark. Brave Research e Simon Willison hanno dimostrato a ottobre 2025 che istruzioni nascoste in uno screenshot — testo azzurro chiaro su giallo, invisibile a occhio umano — vengono lette ed eseguite dagli agenti vision-language. Citando Brave: "indirect prompt injection is not an isolated issue, but a systemic challenge facing the entire category". Un VLM che vede solo screenshot è strutturalmente vulnerabile a qualunque pagina, PDF o cattura manipolata. Dare a un agente del genere la possibilità di muovere il mouse e digitare ovunque, fuori da una VM, è una scelta che ha bisogno di sandbox seria. Ne avevo già parlato guardando l'MCP e i suoi rischi — UI-TARS Desktop espone esattamente la stessa categoria di problemi, amplificata dal vettore screenshot.

Confessione: il mio rack non lo gira

Questo post è nato da una domanda banale: ce la faccio a girare UI-TARS sul mio lab? Inventario, niente filtri. Il server pve ha un Ryzen 7 1800X 8C/16T con 48 GB di RAM, nessuna GPU dedicata. Il pve2 monta un i7-6700K con 8 GB di RAM, anch'esso senza GPU. La mia 2070 Super da 8 GB di VRAM, architettura Turing, esiste ma al momento è smontata e parcheggiata in un cassetto. Risultato: senza rimontare la GPU non c'è partita.

Sul Ryzen 1800X con llama.cpp e quantizzazione Q4 il 7B tecnicamente parte — ma a uno-tre token al secondo. Per un agent loop in cui ogni step è uno screenshot da analizzare e una decisione da prendere, quei tempi sono inutilizzabili: trenta secondi per cliccare un menu uccidono qualunque flusso reale. È esattamente il discorso che facevo nel post sui costi hardware per LLM locale: la VRAM non è un dettaglio, è il primo collo di bottiglia. La 2070 Super da 8 GB, una volta rimontata, dovrebbe far girare il Q4_K_M (4,78 GB sul disco) in inferenza pura. Ma il KV cache di Qwen2.5-VL con immagini ad alta risoluzione brucia memoria velocemente, e già con due-tre screenshot in coda il context utile crolla.

Per ora la 2070 Super dorme. Quando la rimonto faccio il test reale con vLLM e UI-TARS-1.5-7B Q4_K_M, scrivo i numeri veri e aggiorno questo post. Senza montaggio. Nel frattempo, la decisione razionale per chi non ha già 16-24 GB di VRAM è la stessa che descrivevo per AI locale e privacy con Ollama e Open WebUI: chiamarsi fuori dall'hype del "local-first a tutti i costi" e valutare quando vale davvero.

Sintesi: "open-weights" è una promessa di ispezionabilità, non di esecuzione

L'equivoco da rompere è proprio questo. Apache 2.0 sui pesi significa che il modello è ispezionabile, modificabile, ridistribuibile, fine-tune pronto. È un grande regalo all'ecosistema. Non significa che gira sul tuo PC senza pensieri. Il modello "vive" su un hardware specifico — VRAM, bandwidth, KV cache, batch size — e se quell'hardware costa quanto una Mac Studio Ultra, l'aggettivo "self-hostable" diventa una cortesia retorica.

Per la stragrande maggioranza dei task GUI automation reali, UI-TARS-1.5-7B su OpenRouter a 0,10 e 0,20 dollari per milione di token è la scelta economicamente sensata. Tenere accesa una 3090 ventiquattr'ore al giorno per saturarla con uno-due task all'ora non torna. Per chi invece ha dati EU sensibili in mezzo — pensiamo al GDPR — l'endpoint Volcengine ByteDance è fuori discussione, il self-hosting on-prem diventa l'unica opzione, e quindi il costo dell'hardware non è più un "costo" ma una condizione di compliance. Sono due mondi diversi che il framing "open source = self-host" sovrappone in modo sciatto.

Anche UI-TARS non è l'unico open in scena. OpenCUA-32B e Agent S2 di Simular AI hanno superato CUA e Claude su OSWorld-Verified a marzo 2025. Browser Use, Skyvern, Playwright + Claude API restano alternative concrete per chi vuole automazione browser senza dover diventare ricercatore Nvidia. Sul fronte coding agent, il pattern di Archon visto qualche settimana fa mostra che la "stella GitHub" non sempre racconta chi davvero gira il software in produzione. Vale per Archon, vale per UI-TARS.

Quindi, tornando alla domanda iniziale: UI-TARS Desktop è davvero self-hostable? Sì, se per "self-hostable" intendiamo "posso scaricare i pesi, leggere il codice, modificarlo, fargli fine-tuning, e teoricamente farlo girare". No, se per "self-hostable" intendiamo "l'utente con una GPU consumer ci tira fuori un agent loop produttivo". E la frontiera vera, quella che vince i benchmark del 2025, resta proprietaria. Le 32.000 stelle non bastano a riempire 47 GB di VRAM.

Fonti: GitHub UI-TARS-desktop, HF UI-TARS-1.5-7B model card, Paper UI-TARS-2 (arXiv), OpenRouter pricing 1.5-7B, GGUF 7B (Mungert), GGUF 72B (bartowski), issue #15 VRAM requirements, Simon Willison unseeable prompt injection, Brave Research prompt injection, VentureBeat OpenCUA, MarkTechPost UI-TARS-1.5 launch.