Разработката на AI агенти среща локален coding модел с 2.5B активни параметъра
2.5B активни параметъра в рамките на модел с 39.8B е числото, което има значение в този релийз. На 21 октомври 2026 г. Recursive Superintelligence представи Flint — локален coding модел за агенти, който според компанията може да работи на Apple Silicon Mac с 48 GB памет или на NVIDIA GPU с 48 GB. За екипите, които се занимават с разработка на AI агенти, това измества разговора от хвалби с benchmark-и към по-практичен въпрос: може ли един локален coding модел да бъде достатъчно бърз, достатъчно евтин и достатъчно управляем, за да се впише в реален pipeline за софтуерна доставка?
Според отразяването на пускането от MarkTechPost, Flint се предлага като Apache 2.0 open weights в Hugging Face и е насочен към анализ на codebase, отстраняване на бъгове, feature разработка и писане на тестове чрез OpenAI-compatible tool calls. Следя релийзи като този, защото разликата между demo агент и production агент обикновено не е в model IQ. Тя е в memory budget, поведението на инструментите и в това дали системата още работи след третата неуспешна стъпка в терминала.
Recursive пуска Flint за локални coding агенти
Основните спецификации са необичайно удобни за deployment в този клас модели:
- 39.8B общо параметри, около 2.5B активни на token
- Документиран context window от 262,144 token-а, като в блога се споменава до 512k
- 4-bit weights около 23 GB, което прави локалния inference реалистичен на машини с 48 GB
- Над 125 tokens/sec на M4 Pro MacBook Pro и 150+ tokens/sec на NVIDIA RTX Spark, според Recursive
Тази комбинация е важна, защото повечето custom AI агенти се провалят заради скучни инфраструктурни детайли. В един клиентски проект тази година успяхме да накараме вътрешен coding асистент да покрие eval-ите, а после го видяхме да се срива в production, защото latency-то на hosted модела правеше tool-use loop-овете твърде бавни, за да бъдат търпими за разработчиците. Локален модел с прилична coding производителност променя това уравнение.
Recursive прави и ход по линия на лицензирането. Flint се разпространява под Apache 2.0, а weights са публикувани в Hugging Face. За enterprise екипите това е съществено различно от research demo с неясни търговски права.
Как MoE архитектурата на Flint държи compute-а нисък
Flint е decoder-only mixture-of-experts Transformer с 49 слоя: 2 dense слоя, последвани от 47 MoE слоя. Всеки MoE слой има 256 routed experts, като router-ът избира 6 experts на token плюс 1 винаги активен shared expert. Така Recursive достига модел от клас 40B, като същевременно държи активния compute близо до 2.5B параметъра.
От гледна точка на архитектурата за AI интеграция това е частта, която бих следил най-внимателно. MoE моделите често изглеждат отлично по cost-per-token, но реалното им поведение зависи от стабилността на routing-а и качеството на kernel-ите. Recursive твърди, че вътрешната му Eureka Machine е помогнала да се оптимизират както архитектурата, така и inference kernel-ите. В блога се отбелязва още, че 35 слоя използват sliding window от 513 token-а, а 14 слоя използват full attention без positional encoding.
Това не е просто любопитен детайл за model researcher-и. При AI automation агентите дизайнът на attention-а се усеща директно като потребителска болка. Sliding window може да е напълно достатъчен за итеративни редакции по код, но reasoning върху цяло repository, дълги bug trail-ове и refactor-и в множество файлове често натоварват именно онези части от управлението на контекста, които benchmark-ите изглаждат.
Ако екипът ви се опитва да вкара локални coding агенти в build pipeline, тук дисциплината по имплементация е по-важна от суровите резултати. Най-подходящият service path тук е AI DevOps workflow automation, защото Flint става полезен едва когато е свързан с repo достъп, тестване, CI trigger-и, обработка на откази и rollback логика. Моделът е лесната част. Оркестрацията е трудната.
Какво промени Eureka Machine в процеса на изграждане
Recursive твърди, че автоматизираната ѝ изследователска система Eureka Machine е допринесла на три места: търсене на архитектура, quantization и kernel-и. За мен това е най-интересната част от релийза, защото подсказва, че model vendor-ите вече автоматизират целия стек за изграждане на модели, а не само inference-time агенти.
Конкретното твърдение, което си струва да се отбележи, е quantization на lm_head до 4 bits, което според Recursive противоречи на обичайната практика. Компанията съобщава, че offline distillation стъпка е възстановила точността и че NVFP4 версията е останала в рамките на 0.7 точки от 16-bit модела в нейните тестове. Ако това се потвърди в независими репликации, резултатът е инженерно значим.
Другият оперативен детайл е работата по kernel-ите. Recursive казва, че е написала специализирани kernel-и за low-bit projections, MoE операции, attention и обработка на prompt-и, включително Metal megakernel за Apple Silicon, който обединява целия decode forward pass. Тези твърдения ми звучат правдоподобно, защото на практика жизнеспособността на локалните модели често се печели или губи при kernel-ите, а не в model card-овете.
За екипите по AI implementation services това означава едно: benchmark-вайте конкретния runtime, а не само checkpoint-а. Модел, който на хартия изглежда ефективен в BF16, може да стане неизползваем, ако стекът ви зависи от по-бавен runtime path в llama.cpp, Ollama или vLLM.
Benchmark числата на Flint разказват разделена история
Това не е чиста история тип „Flint печели“. Това е история за разделени резултати.
| Benchmark | Flint BF16 | Flint NVFP4 | Notable comparator |
|---|---|---|---|
| SWE-bench Verified | 74.2% | 74.1% | Qwen 3.6: 73.4% |
| LiveCodeBench v6 | 80.3% | 80.8% | Qwen 3.6: 80.4% |
| IFEval | 95.1% | 94.6% | Gemma 4: 94.6% |
| Terminal-Bench 2.1 | 54.9% | 53.7% | Qwen 3.8: 73.0% |
Източници: launch материалите на Recursive, както са отразени от MarkTechPost, плюс сравнения между модели с Qwen, Gemma и други benchmark-и, публикувани от разработчици.
Най-силното число е 95.1% на IFEval. Най-важното число от търговска гледна точка може да е 74.2% на SWE-bench Verified. Но предупреждението е 54.9% на Terminal-Bench 2.1, особено когато собствената сравнителна таблица на Recursive показва 73.0% за Qwen 3.8.
Тази разлика е важна, защото terminal-heavy задачите са мястото, където много проекти за AI business automation и developer агенти се провалят в реални условия. Един coding агент може да изглежда умен, докато чете файлове и предлага patch-ове, а после да загуби време, когато shell командите, настройката на средата или многостъпковото изпълнение започнат да се отклоняват. Виждал съм точно този модел: добро качество на patch-овете, слабо завършване на задачите.
Затова тенденцията не е „локалният MoE бие всичко“. Тенденцията е по-тясна: локалните модели вече стават достатъчно добри за code-centric agent задачи, така че екипите могат да ги оценяват сериозно, но все още изискват внимателно benchmark-ване спрямо dense алтернативи при terminal и execution-heavy workflow-и.
Какъв хардуер е нужен, за да пуснете Flint локално
Хардуерната история на Recursive е една от причините този модел да получи реални пилоти. Компанията казва:
- INT4 MLX weights са около 22.6 GB на Apple Silicon
- NVFP4 GGUF е около 22.9 GB за NVIDIA конфигурации
- 48 GB памет е практичният минимум за поддържаните Mac и GPU варианти
- 80 GB BF16 checkpoint изисква H200 или B300 клас server GPU за всяка реплика
Това са конкретни числа и съвпадат с начина, по който enterprise оценките обикновено се случват. Един екип може да пусне това на MacBook Pro с повече памет или на workstation с 48 GB GPU, без да иска нов бюджет за клъстер. Това намалява триенето при пилотите.
Компромисът е ясен: локалният deployment ви дава по-ниска latency, по-стегнат контрол и по-малко притеснения около трансфера на данни, но също така прехвърля повече отговорност към вашия екип. Трябва да управлявате runtime-и, context ограничения, observability, prompt caching и tool permissions. Hosted моделите все още печелят по удобство.
Какво означава това за екипите по разработка на AI агенти
Моят прочит е, че Flint е важен не защото е взел най-висок резултат навсякъде, а защото намалява цената на това да изпробвате сериозни локални coding агенти през 2026 г. MoE модел с 39.8B параметъра, 2.5B активни параметъра, 23 GB 4-bit weights и отчетени 125+ tokens/sec на MacBook Pro е достатъчен, за да премести един пилот от теория към реална имплементация.
Въпреки това бих държал пилота тесен по обхват. Добри първи цели са търсене в repository, генериране на тестове, подготвяне на patch-ове и offline цикли за code review. Бих избягвал да давам на Flint пълна автономност при terminal-heavy release дейности, докато нямате данни за отказите в собствената си среда.
По-широката тенденция в разработката на AI агенти става все по-ясна: екипите вече не избират само между „малък локален модел“ и „най-добрия hosted модел“. Вече има и трета пътека: локално разгръщани coding агенти с прилични benchmark резултати и работещ memory footprint. Това не премахва нуждата от custom AI агенти, AI API интеграция или силна оценка. Просто прави пътя до имплементация по-реалистичен.
Martin Kuvandzhiev
Co-Founder & CEO, encorp.ai
CEO and Founder of Encorp.io with expertise in AI and business transformation
LinkedIn