Recursive представи Flint на 21 октомври за локални coding агенти. Компанията твърди, че нейна автоматизирана изследователска система е участвала в разработката. Това не доказва автономно самоусъвършенстване без човешки надзор.

Малко активни параметри, отделен избор на изпълнение

Моделната карта уточнява 39,8 милиарда общи параметри и приблизително 2,5 милиарда активни на токен, включително изходния слой. Публикуваният тук BF16 checkpoint е различен от отделно подготвените квантизирани варианти. Документираният контекст е 262 144 токена, общо за входа и изхода. Анонсът говори за поддръжка до 512K, но препоръчва работа в рамките на 256K; за внедряване бихме следвали конкретната конфигурация на избрания checkpoint.

Практическият извод е да не се превръща активният размер в обещание за нужната памет. Той описва частта от модела, използвана при обработката на токен, а не цялата инсталация. При оценка бихме записали точния файл с тегла, точността, runtime и свободната памет при реалната дължина на разговора. Без тази информация две демонстрации на „Flint на лаптоп“ може да описват различни условия.

Скоростта е твърдение с условия

Recursive съобщава над 125 токена в секунда на M4 Pro MacBook Pro и над 150 на RTX Spark с 64 GB при кратък контекст и оптимизиран engine. Това са фирмени измервания, не наш тест. Лицензът на теглата е Apache 2.0. Отвореното изтегляне не означава безплатен хардуер, еднаква скорост във всеки runtime или автоматично право на достъп до файловете на потребителя.

Официалната документация предлага локални маршрути през rec, Ollama, LM Studio и llama.cpp и свързване към отделен coding harness. Тя препоръчва начален тест върху познато малко хранилище с преглед на diff и резултатите от тестовете. Посочените hosted възможности имат собствени ограничения за капацитет и употреба; те не трябва да се смесват с локалната обработка.

Какво всъщност бихме сравнили

Нашият предложен пилот е задача с известен дефект, описан очакван резултат и тест, който го различава от старата грешка. Първо агентът обяснява релевантния код, после предлага промяна. Бихме отчели дали тестът е полезен, дали промяната засяга ненужни файлове и колко човешка преработка е необходима. Това е по-информативно за екипа от бързото генериране на много редове.

Отделно бихме задали границите на работната среда: разрешени директории, мрежови връзки и действия, нуждаещи се от преглед. Моделът предлага инструментални извиквания, но приложението определя дали да ги изпълни. Дори успешен малък тест не е основание същият агент да получи производствени ключове или разрешение за публикуване без конкретна задача.

За по-дълги задачи бихме запазили и междинните резултати. Ако моделът открие проблема, но изчерпи времето преди проверката, това не е завършена поправка. Ако генерира правилен отговор веднъж, бихме повторили задачата, преди да наречем поведението надеждно. Тук не публикуваме собствени benchmark резултати или спестени разходи.

За потребителя решаващ остава по-тесният, проверим въпрос: може ли избраната версия да завърши неговата задача с приемливо качество, ресурс и контрол? Бихме взели решение след сравнение с известния досегашен процес. Нито по-бързият отговор, нито привлекателното обяснение за произхода на модела сами определят дали предложената поправка трябва да бъде приета.

Корица: концептуална AI илюстрация на локален coding модел; не е снимка или интерфейс на реален продукт.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.