Local Vision for z.ai GLM-5.1: 8B Model Closes 70% of the Gap to the Frontier

Разработчик показал, как убрать одну из главных слабостей дешёвых кодинг-моделей: слепоту к собственному UI. Для z.ai GLM-5.1 он собрал локальный vision-sidecar, который читает скриншоты, возвращает структуру интерфейса в JSON и позволяет агенту самому проверять результат после генерации кода.

В чем была проблема

Проблема знакома почти всем, кто пробовал экономичные модели вместо дорогих frontier-систем. Агент может написать HTML, поднять страницу, прогнать Playwright и сохранить скриншот, но дальше упирается в стену: картинка есть, а понимания нет. Если кнопка уехала, таблица обрезалась, текст налез на карточку или мобильная сетка развалилась, модель этого не замечает.

В итоге человек снова вручную проверяет интерфейс и превращается не в постановщика задач, а в постоянного QA между итерациями. Автор исходил из простой гипотезы: для такой обратной связи не нужна самая сильная мультимодальная система на рынке. На скриншотах веб-интерфейса обычно важны не абстрактные рассуждения, а извлечение фактов: OCR, список кнопок, структура блоков, наличие обрезки и корректность таблиц.

Если это правда, значит компактную открытую vision-модель можно превратить в дешёвый сенсорный слой для кодинг-агента и замкнуть цикл «написал -> посмотрел -> исправил» без облачного API.

Как устроили пайплайн В качестве зрения использовали qwen3-vl:8b, развёрнутую локально через Ollama.

Поверх неё автор собрал MCP-сервер vision-sidecar-mcp, который принимает скриншоты и отдаёт структурированное описание экрана. Такой слой не делает из GLM-5.1 полноценную мультимодальную модель, но даёт ей то, чего не хватало в практической разработке: возможность читать визуальный результат своей работы через текстовый интерфейс.

На обычном GPU или Apple Silicon вся схема, по словам автора, поднимается примерно за 20 минут. qwen3-vl:8b как локальная vision-модель Ollama для быстрого развёртывания MCP-сервер с методами analyze_image, analyze_structured и extract_table JSON-ответы, которые можно сразу передавать кодинг-агенту Ключевая инженерная часть оказалась не в дообучении весов, а в настройке инференса. Автор зафиксировал seed, ужесточил sampling через top_p=0.

9 и top_k=20, а также перевёл ответы в строгую JSON-схему. Отдельное поле для символов и иконок помогло убрать типичные ошибки распознавания, когда декоративные glyphs читались неправильно. Это важный вывод: если задача сводится к извлечению структуры, хороший промпт, схема и дисциплина генерации иногда дают больше пользы, чем попытка сразу идти в fine-tuning.

Какие цифры получились

Проверку провели на десяти скриншотах реального веб-приложения, от маленького мобильного экрана 320×568 до десктопа 1440×900. Сравнивались три режима: базовая qwen3-vl:8b, та же модель после тюнинга и Claude Opus 4.7 как верхняя планка. Средний балл вырос с 3,99 до 4,70 из 5, а разрыв до фронтира сократился с 1,01 до 0,30. Иными словами, локальная 8B-модель закрыла около 70% отставания без fine-tuning и без дополнительных данных.

«Цикл тестирования замкнут.

Модель больше не слепая». После тюнинга связка вышла почти в паритет там, где для агента важна практическая проверка интерфейса: OCR и точное извлечение текста детекция UI-элементов и CTA понимание структуры layout извлечение таблиц и пригодность для дальнейшей автоматической обработки Главный нерешённый разрыв связан с галлюцинациями и визуальными нюансами. Локальная модель могла путать оттенки, неверно трактовать мелкие декоративные элементы и слабее считывала дизайнерский intent, особенно там, где цвет сам несёт статус или приоритет. Но для задач вроде проверки clipping, наличия CTA, корректности таблиц и структуры секций это не выглядит блокером: критические ошибки интерфейса она уже умеет замечать достаточно надёжно и предсказуемо.

Что это значит

Практический вывод простой: дорогие frontier-модели остаются полезными как проверочный слой для сложных случаев, но основную массу UI-итераций уже можно отдать локальной связке из кодера, скриншотов и компактной vision-модели. Следующий логичный шаг — routing, при котором простые экраны обрабатываются локально, а спорные автоматически уходят на более сильную модель или к человеку. Для команд, которые считают бюджет на inference и хотят больше автономности во фронтенд-разработке, это выглядит уже не как эксперимент, а как рабочая схема.