Услуги за AI интеграция за on-device vision агенти
Liquid AI пусна LFM2.5-VL-3B вчера и от гледна точка на внедряването това е причината услугите за AI интеграция изведнъж да имат по-голямо значение от самата benchmark графика. Вече имаме 3.1B vision-language модел, който чете екрани, локализира обекти, обработва документи и генерира tool calls, като се побира в приблизително 3 GB. За екипи, които изграждат локални GUI агенти, OCR потоци или приложения за теренна работа, това променя изцяло сметката за пилотните проекти. Според анализа на MarkTechPost за пускането, моделът излиза още от първия ден в native, GGUF, ONNX и MLX формати.
Какво всъщност беше пуснато и защо да ме интересува, ако отговарям за delivery?
Интересува ме, защото това не е просто поредният multimodal release с приятно демо видео. Liquid AI казва, че LFM2.5-VL-3B е non-reasoning модел, създаден за директни отговори и по-ниска латентност, с отчетена производителност от 228 tokens в секунда на Apple M5 Max и около 20 tokens в секунда на Galaxy S26 Ultra. Тази комбинация има значение, когато задачата е да се прочете екран, да се кликне правилната цел, да се извлече поле от фактура или да се сравнят две изображения без изчакване за cloud round trip.
Практическата страна на внедряването е по-силна от обичайното. Checkpoint-ът е наличен във формати, които нормалните екипи могат да използват веднага: ONNX, MLX, GGUF и native weights, с runtime поддръжка, включително llama.cpp, vLLM и SGLang. В един клиентски проект тази година самият модел не беше блокерът; блокерът беше дали екипът може да побере inference в съществуващия си runtime и device budget. Отпечатък от 3 GB минава този първи праг за много повече пилоти.
Защо screen understanding е частта, която бих тествал преди всичко друго?
Защото повечето production провали в тази категория не са от типа „моделът е слаб“. Те са coordinate failures, viewport failures и OCR failures. Liquid AI отчита 80.7 на ScreenSpot-v2, с 78.7 на desktop, 81.2 на mobile и 82.2 на web. Това е типът число, на който обръщам внимание, защото показва дали един агент може да издържи на реална UI вариативност, а не просто дали може да генерира caption за screenshot.
Архитектурата помага да се обясни защо. Vision tower-ът използва SigLIP2 NaFlex, който работи с native resolution, като разделя големите изображения на 512×512 patches плюс thumbnail на цялото изображение. При screen и document задачи това обикновено е по-добро от наивното resize-ване, защото дребният текст, границите на бутоните и клетките в таблиците обикновено изчезват първи, когато резолюцията се свие. Миналия месец гледах как по-голям cloud модел пропусна малък, но критичен confirmation checkbox в browser flow три пъти поред. Точно заради такива пропуски обработката в native resolution има по-голямо значение от един общ усреднен benchmark.
От playbook-а на Encorp: Когато един модел твърди, че разбира добре UI, не започвам от средната benchmark стойност. Започвам с десет грозни вътрешни екрана, два счупени PDF файла и един workflow, който вече струва реални часове на ops екипа всяка седмица. Правилният пилот доказва точност на координатите, retry поведение и латентност под натоварване, преди някой да разшири обхвата. Подходящ пример за внедряване е AI Business Process Automation.
Какво добавя function calling отвъд обикновените vision и OCR възможности?
Function calling е разликата между „виждам го“ и „мога да направя нещо с него“. Liquid AI добави tool use към тази VL линия и отчетените подобрения са големи: ToolSandbox се покачва от 26.4 до 59.5, а BFCL v4 от 20.5 до 32.5. Моделът генерира Pythonic извиквания между специални tool-call токени, което означава, че можете да изградите ограничен action layer около него, вместо да карате модела да описва какво би трябвало да се случи после.
За работа по AI API интеграция това има голямо значение. Локален модел може да прочете support dashboard, да идентифицира статус, да извика ticketing функция и да върне контрола, без да предава цялата screen сесия на hosted agent. За AI automation агенти това е по-чист модел от опита да се парсва свободен текст от screenshot и след това отделно да се изпълнява intent логика.
Компромисът също е ясен: това е non-reasoning модел. Затова не бих му възложил дълго, двусмислено, многостъпково планиране. Бих го използвал за ясно ограничени задачи с кратък хоризонт: прочети, локализирай, извлечи, извикай, потвърди.
Къде AI решенията за интеграция около този модел имат най-много смисъл като първа стъпка?
Бих започнал с процеси, при които локалното vision изпълнение е по-добро от cloud алтернативата заради латентност или излагане на данни. Четири области изпъкват.
Първо, GUI автоматизация и QA. Ако вече поддържате browser или mobile app test suites, малък локален VL модел може да стане визуален fallback за потоци, в които hard-coded selectors се чупят. Второ, извличане на данни от документи. Liquid AI отчита 91.1 на DocVQA и 81.3 на ChartQA, което е напълно достатъчно, за да оправдае тестове върху фактури, касови бележки, формуляри и operations dashboards. Трето, field apps за офлайн среда или лоша свързаност. В автомобилния, индустриалния и consumer electronics контекст локалният inference премахва зависимостта от стабилен uplink. Четвърто, image workflows в retail и e-commerce, особено когато екипите имат нужда от custom AI интеграции за проверки на каталози, сравнение на множество изображения или capture на формуляри.
Това, което не бих направил първо, е да изграждам широк executive assistant около него. Стойността тук е по-тясна и по-оперативна. Това е инструмент за конкретни задачи с тежък визуален компонент, а не универсален агент.
Как се представя спрямо по-големите модели на практика, а не само на хартия?
По отчетените от Liquid AI данни LFM2.5-VL-3B има среден резултат 69.4 в 28 vision benchmark-а. Това го изравнява с InternVL-3.5-4B и го поставя само на 0.7 зад Qwen3.5-4B, въпреки че и двата сравнителни модела са в клас 4.7B. На хартия това е силна история за ефективност.
На практика чета този резултат така: ако натоварването ви е основно screen reading, OCR, grounding и кратки tool calls, по-малкият модел може да е по-добрият избор за внедряване, дори ако по-голям cloud модел печели при няколко по-тежки reasoning задачи. По-ниските изисквания към паметта и поддръжката за локален runtime намаляват инженерното триене. Според източника моделът поддържа и 16 езика, както и context window от 32,768 токена, което разширява приложимостта му в многоезични document и UI потоци.
Все пак има и компромиси. CountBenchQA се е понижил от 92.2 до 87.3. Това ми подсказва да не приемам автоматично, че всяко визуално умение е подобрено. А ако даден workflow зависи от по-тежко reasoning през много стъпки, по-големите multimodal системи все още са по-сигурният избор.
До каква степен лицензът променя решението за покупка?
Много повече, отколкото екипите обикновено очакват. LFM Open License v1.0 на Liquid AI е базиран на Apache-2.0, но безплатната търговска употреба спира, след като една компания премине $10M годишни приходи. За research, education и non-profit употреба този праг не се прилага.
Така че за startup-и и SMB компании картината е ясна: можете да пилотирате и потенциално да внедрите комерсиално без лицензни разходи, ако сте под прага. За по-големите компании моделът може да остане технически привлекателен, но procurement трябва да влезе в разговора рано. Виждал съм пилоти да спират не защото моделът се е провалил, а защото екипът е открил лицензно ограничение, след като прототипът вече е привлякъл вниманието на ръководството.
Ако предоставяте AI интеграции за бизнес клиенти в няколко дъщерни дружества или региона, това е от онези детайли, които трябва да валидирате преди първия production architecture review.
Какво бих включил в първия двуседмичен пилотен план?
През първата седмица изберете един runtime и един workflow. Не тествайте пет стека едновременно. Ако целта е Apple хардуер, MLX е очевидната първа стъпка. Ако целта е по-широко edge или server внедряване, ONNX или llama.cpp може да са по-бързият път към доказателство. След това дефинирайте по една метрика за успех за латентност, точност на извличането и точност на действието.
През втората седмица пуснете грозните тестове. Имам предвид завъртени screenshots, dark mode, modal popups, частична оклузия, нискокачествени сканове и остарели UI състояния. За услуги по AI внедряване точно тези случаи показват дали имате продукт или лабораторно демо. Бих записвал и всяка грешна координата, всеки неуспешен tool call и всяко връщане към human review. Тези три лога обикновено казват истинската история.
По-широкият извод е прост. Това пускане е по-интересно не като benchmark заглавие, а като събитие, свързано с реална внедряемост. Първи ще спечелят екипите, които имат тесен workflow, ясен runtime target и достатъчно инженерна дисциплина да тестват там, където локалните multimodal системи обикновено се чупят.
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation