Во сколько раз локальная модель для Computer Use быстрее облачного API

Чем локальная модель для Computer Use отличается от облачного API

Локальная модель вроде CUA-S1-FORMS принимает решение прямо на твоём железе за миллисекунды, без похода в сеть - независимый бенчмарк ONNX-конверсии показывает медиану 15,0 мс на запрос. Облачный API вроде GPT-4.1 или Claude тратит на первый токен от 450 до 2400 мс, потому что запрос летит на чужой сервер и обратно. Разница в 30-150 раз реально ощутима только там, где агент принимает решения одно за другим без пауз - например, построчно заполняет форму. Для агента, который щёлкает раз в пару секунд, экономия на глаз не заметна.

Я слежу за темой не из академического интереса - у меня свой парк агентов гоняет Playwright и упирается именно в задержку между решением "куда кликнуть" и самим кликом. Поэтому разбираю CUA-S1 не как ещё одну строчку в ленте GitHub Trending, а с прицелом "стоит ли мне вообще с этим возиться".

Что такое CUA-S1 и зачем нужна модель на 706 тысяч параметров

CUA - open-source платформа для агентов, которые работают с компьютером: облачные "флоты" рабочих столов, драйвер для управления приложениями на macOS/Windows/Linux, локальные VM на Apple Silicon и бенчмарк-платформа для тренировки агентов. Репозиторий trycua/cua собрал 26,3 тысячи звёзд и 1,8 тысячи форков на GitHub - для нишевого инструментария это много.

Кроме моделей, в платформу входят Cua Fleets - облачные изолированные рабочие столы, которые поднимаются через run.cua.ai; Cua Driver - CLI/MCP/SDK для управления приложениями с фоновой доставкой команд без захвата фокуса окна; Lume - локальные VM macOS и Linux на Apple Silicon через Virtualization Framework; и Cua Bench - платформа для сборки задач компьютерного использования и экспорта траекторий на обучение агентов. CUA-S1 - самый свежий кусок этого набора, и первый, который целится не в "агента целиком", а в конкретный дешёвый шаг внутри агентского цикла.

19 сентября 2026 года команда представила CUA-S1 - семейство "моделей System One": маленьких, специализированных, заточенных под быстрые ограниченные решения. Аналогия с "быстрым мышлением" psychology 101 тут не случайна - модель не генерирует ответ токен за токеном, как обычная LLM, а за один проход прямого распространения оценивает, что сделать с конкретным полем формы: заполнить конкретным значением или оставить как есть.

Первый релиз в семье - CUA-S1-FORMS: 706 048 обучаемых параметров, около 2,8 МБ на диске. Архитектура - двухслойный трансформер-энкодер шириной 128 с четырьмя головами внимания, byte-level эмбеддинги, обучали 6 эпох батчами по 128. Лицензия MIT - в отличие от части остального CUA-стека, где кусок с распознаванием экрана (cua-som) идёт под AGPL-3.0-or-later, а perception-расширение - под AGPL-3.0 плюс Apache-2.0. Модель именно про формы: банковские заявки, регистрации, чекауты - там, где на входе структурированные поля, а не произвольный текст. Через Ollama её не запустить - это не чат-модель, а классификатор решений, весы лежат на Hugging Face отдельно от кода, доступны PyTorch-чекпойнт и сторонние конвертации в ONNX и CoreML.

Насколько CUA-S1-FORMS точнее облачного API: 99,7% против 83,6%

На карточке модели на Hugging Face Cua приводит одно прямое сравнение с облаком: на своей задаче CUA-S1-FORMS даёт 99,7% точности против 83,6% у захостенного API jev-latest от TypeSafe. На синтетическом тесте, не пересекающемся с обучающей выборкой, модель показывает 99,95%, а на реальной проверке из 196 решений по трём формам и трём PDF - 100%. При этом на тесте с перемешанным контекстом точность падает до 37% - модель честно спотыкается, если контекст сломан, а не выдаёт уверенный, но неверный ответ.

Важная оговорка: это единственное официальное сравнение с облаком, которое опубликовала Cua. Более широких заявлений о точности и тем более прямых сравнений задержки с хостинг-провайдерами компания не делала - разбор релиза на ai-tldr.dev прямо отмечает, что "hosted-provider comparisons and checkpoint accuracy stay out of scope" для остальных, ещё не выпущенных моделей семейства. Так что число "в 30 раз быстрее", которое обычно всплывает при пересказе релиза, не официальный бенчмарк Cua, а чья-то арифметика - разберём её ниже, честно показав, откуда она берётся.

Во сколько раз локальная модель быстрее облака

Официальных цифр по задержке CUA-S1 не публиковала. Зато есть независимый бенчмарк ONNX-конверсии модели (автор - Mohamed Yasser, конвертация опубликована на Hugging Face): на Google Colab, ONNX Runtime на CPU, батч 1 из 8 кандидатов - медиана 15,0 мс, среднее 16,8 мс, P95 - 24,3 мс, throughput около 60 решений в секунду. Автор конверсии прямо пишет, что это замеры именно его деплоя, не официальный бенчмарк CUA-S1.

Чтобы понять масштаб разницы, нужна вторая половина сравнения - задержка облачных API. Бенчмарк LLM API 2026 года (Toronto, промпт около 200 токенов, тест март-сентябрь 2026) даёт такие цифры по time-to-first-token:

Если сравнить локальные 15 мс с самой быстрой массовой моделью (Gemini 2.5 Flash, ~450 мс), выходит разница около 30 раз - вот, судя по всему, откуда взялось число в теме этой статьи. Против медленных моделей вроде GPT-4.1 Mini разница доходит до 150-160 раз. Это моя арифметика поверх двух разных замеров, а не единый прямой тест - у Cua и у бенчмарка LLM API разное железо, разные задачи и разные условия сети, так что относиться к "30 разам" стоит как к порядку величины, а не к гарантированному числу.

Где задержка в миллисекундах реально решает: пример моего QA-агента

У меня есть похожая, хоть и не идентичная история - агентский QA-пайплайн для DnD-приложения в Telegram, я про него уже писал отдельно. Там агент гоняет игровые сценарии через Playwright, а не заполняет формы моделью на 706 тысяч параметров, но узкое место то же самое - задержка на каждое действие. Каждый вызов инструмента через Playwright MCP стоит 500-1500 мс накладных расходов сверху над самим действием. На одном действии это незаметно, а вот на 26 ходах партии за прогон уже выливается в разницу между "агент управился за полчаса" и "агент душит минут пятнадцать лишних".

Решение там было не "переехать на локальную модель", а допилить батчинг: вместо 15 отдельных вызовов evaluate() - один вызов с массивом операций и одним JSON-ответом. Кратное сокращение накладных расходов - и без всякой локальной модели. Для задач типа "агент решает, куда кликнуть на сложном экране" я бы тоже сначала проверил, не съедает ли задержку сетевой оверхед инструмента, а не сама модель - и только потом думал про переезд на что-то локальное и узкоспециализированное вроде CUA-S1.

Есть и обратный сценарий, где задержка API - не главная проблема. У нас в проекте есть сравнительная таблица "когда что использовать": для регрессионных QA-сьютов с повторяемыми сценариями годится обычный Playwright MCP или CLI, а вот для кросс-приложенных workflow (Telegram плюс браузер плюс десктоп в одной задаче) без агента вроде Anthropic Computer Use не обойтись - там счёт не на миллисекунды одного клика, а на то, умеет ли агент вообще ориентироваться между разными интерфейсами.

Когда стоит переносить агентские задачи на локальный инференс, а когда нет

Ключевой критерий - не "миллисекунды дороги сами по себе", а плотность решений на единицу времени и стоимость ошибки конкретного шага.

CUA-S1-FORMS - это не замена агенту, а протез для одного конкретного узкого места: типовое решение по полю формы, которое иначе гоняли бы через дорогой облачный вызов ради результата размером в одно слово. Экономика такого протеза бьёт по двум фронтам сразу - и по задержке (15 мс против сотен), и по деньгам (модель на 2,8 МБ почти не грузит GPU, в отличие от дорогого оркестратора, который перегоняет каждый мелкий шаг через Opus). Разница похожа на то, что я разбирал, когда считал реальную стоимость прогона агента по задаче, а не по токену - дешёвый по токену вызов ещё не значит дешёвый по задаче, и наоборот: узкая локальная модель может быть дороже во внедрении, чем кажется по цифре "15 мс".

Мой вывод

Стоит переезжать не тогда, когда где-то мелькнула цифра "в 30 раз быстрее", а тогда, когда посчитал: сколько решений в секунду реально проходит через узкое место, и сколько стоит его облачная версия при таком темпе. Окупится ли это лично у тебя? Смотря сколько решений в минуту. Если их мало и они редкие - разница в миллисекундах потеряется в шуме сети, а время на внедрение отдельной локальной модели уйдёт впустую. Если решений сотни в минуту и они однотипные (как в форме) - тогда 706 тысяч параметров на своём железе действительно окупаются, причём не столько скоростью, сколько тем, что перестаёшь платить за токены на задачу, у которой ответ по сути один бит "заполнить или пропустить".

Официальных бенчмарков против полноразмерных обычных агентов Cua пока не публиковала, так что переносить чужой узкий кейс с формами на свой агентский пайплайн один в один я бы не спешил - но сам принцип "не всякое решение агента достойно похода в облако" у меня уже работает и без CUA-S1, просто на уровне батчинга вызовов.