Microsoft выпустил Fara-7B на основе Qwen-2.5 VL 7B. Модель для агентов, самостоятельно работающих на компе. Любопытно

Куда на самом деле движется индустрия LLM (спойлер: вы выбираете не модель - вы выбираете стек).

Пост навеян свежим релизом Opus 4.5, а именно ее доп фичами как Context Editing - нам показывают действительно впечатляющие демки… Но постойте - это же (очередная) не-фича foundation модели. Это не что-то в весах. Это инфраструктурный middleware, который живет между вами и моделью. И если вы проанализируете (особенно глазами разработчика) релизы последнего года, то вы увидите что мы все дальше от бога от LLM как модели, и тем ближе к LLM как infrastructure-as-a-service. Давайте поговорим, куда нас ведет индустрия и что из этого следует, но начнем с начала.

Большинство людей (в том числе многие разработчики) когда говорят про условный ChatGPT не видят весь спектр между "моделью" и "продуктом" - ведь это одновременно и foundation model, и старый добрый completions API, и вполне себе агентный Responses API c Code Interpreter, File Search (RAG прямо в "модельке", ага) и т.д.

Что на самом деле продают вендоры

OpenAI Responses API - это целая инфра, включая NoSQL БД для истории, хранилище файлов и тд. Вы отдали им state management.

Code Interpreter и Code Execution - это PaaS: managed sandbox - $0.03 за сессию платите за инфру, не за "умную модель".

Claude Context Editing - middleware с настраиваемой стратегией pruning (keep last 3 tool uses, clear 5000+ tokens). Оркестрация, а не интеллект.

Google Grounding и Maps tool - dynamic retrieval: модель решает нужен ли поиск, генерит queries, получает доступ к индексу (глубже публичного API), делает reranking, отдает с citations. Вы покупаете gateway к индексу, не модель.

Даже Structured Outputs - это частично заслуга инфры, а не весов - constrained decoding через CFG (конвертит JSON Schema в грамматику, маскирует невалидные токены). Компилятор поверх модели.

Большинство не осознают, как растет пропасть между проприетарными infrastructure-as-a-service от OpenAI/Google/Anthropic и голыми весами open-source моделей. Проприетарные LLM превращаются из inference провайдеров в операционки для intelligence.

Что из этого следует и что следует иметь в виду

1. Понимать уровни зависимости, я выделяю три:
- State (Threads, File API, memory) - критический lock-in, вы не владеете памятью системы
- Execution (Code Interpreter, sandboxes) - средний lock-in, нужна своя инфра для рантайма
- Behavior (Grounding, Computer Use) - средне-высокий, модель часто обучена под "свои" инструменты

Перед использованием любой фичи спрашивайте: "Где живут данные? Кто контролирует логику? Смогу ли я воспроизвести это сам?"

2. Integration Tax vs Migration Tax - ключевая асимметрия. Проприетарные фичи дают быстрый старт, но стоимость выхода растет экспоненциально. Это не обязательно плохо - это trade-off, который нужно делать осознанно.

3. Разделять Core и периферию
Core (ваша уникальная ценность, основа продукта) - инвестируйте в независимость: свой state management, своя оркестрация и тд.
Пример: AI-агент для support как продукт - владение историей диалогов критично, а вот Code Interpreter для внутренней аналитики - это ок.

4. Есть обратная сторона. Чем глубже расходятся продуктовые слои провайдеров, тем сложнее делать model-agnostic продукты, которые работают так же хорошо. Manus поняли это рано - выжали максимум из Anthropic, не пытаясь быть совместимыми со всеми, и сделали продукт-звезду. Возможно, по той же причине Claude Code так хорош?

5. Учитывайте свою стадию. 0→1 (поиск PMF) - максимально используйте проприетарные фичи, скорость важнее. Когда растете - можно строить абстракции: gateway, свой state для core функций. На стадии масштабирования - еще больше контроля и взаимозаменяемости компонентов (interoperability это дорого).

Главное

Проприетарные AI-платформы - это managed infrastructure, как AWS. Вы платите не только деньгами, но и зависимостью. И этот тренд будет расти. Часто это правильный trade-off, особенно на старте. Но это решение нужно принимать с открытыми глазами - понимать, какую часть системы отдаете "в управление", и делать это осознанно для каждого компонента продукта.

Ждем на днях новую модель - лидера в генерации видео по тексту

Кстати, один из лидеров по картинкам - Z-Image от Али-Бабы, опенсорс и работает на машинках с 16Гб памяти. Мне кажется, надо брать

🍌 Awesome Nano Banana - лучшие промпты, стили, приёмы и полезные материалы для визуальных экспериментов.

Всё собрано в одном репозиториит и аккуратно структурировано.

Что внутри
• промпты, которые реально дают сильные и выразительные результаты
• коллекция визуальных стилей для разных задач
• примеры, разборы и ресурсы, помогающие глубже понять механику Nano Banana
• удобный набор ссылок, если хочешь расширять свой набор техник

https://github.com/ZeroLu/awesome-nanobanana-pro

@ai_machinelearning_big_data

Hunyuan 3D Studio версии 1.1 - новинка для тех, кто интересуется 3D моделированием

https://3d.hunyuan.tencent.com/studio

И новоая моделька на 106B параметров - Intellect 3. Честно говоря, пока мало что о ней можно сказать..

Hugging face тут интересное выкладывает. Кстати, народ говорит, что по подписке за 9 баксов в месяц у них можно получить много инференса на открытых моделях. Тем, кому нужна моделька по апи может быть интересно

Кстати, сделали тут с Claude Opus 4.5 файл с основыми инструкциями для Claude Code - попытался прописать туда все основные вопросы, с которыми сталкиваюсь. Как и положено для таких промптов, очень кратко - уложились в 100 строк.

Смотрите, может кому пригодится. Положить этот файл надо в директорию .claude в корень (это для маков) - чтобы открыть доступ к этой скрытой директории в корне директории юзера нажмите Cmnd+Shift+.

Ну и кстати, вчера сделал свой первый публичный репозиторий в GitHub с небольшой программкой, на которую ссылаюсь в правилах - это передача паролей в программы с использованием Bitwarden (я раньше писал важный пост, о том, как выстроить систему работы с паролями, доступ к которым есть только у вас).

Теперь никакие пароли и API нигде не видны в виде теста. Программы все-равно получают к ним доступ, и модели в рамках запущенных процессов тоже, но извлечь их из них будет сложнее. Порадовало, что я не один такой, есть и аналоги.

Если делать совсем ультимативное решение, то надо делать МСР сервер, который передает ключи по требованию - может и займусь этим, но история более геморная, мне пока это не нужно. Вот когда продукты будут как-то активно использоваться, нужно будет озаботиться.